Pulumi: Infrastructure as Code

Olá, daqui é o Alex da DEV STORIES DOT EU. Pulumi: Infrastructure as Code, episódio 1 de 10. E se pudesses escrever a tua infraestrutura cloud usando exatamente a mesma linguagem de programação que usas para a tua aplicação? Acabou-se o context-switching entre a lógica da tua aplicação e milhares de linhas de markup personalizado. A Infraestrutura do Developer: Porquê o Pulumi? aborda exatamente esta mudança. Historicamente, Infrastructure as Code significava escrever domain-specific languages ou blocos intermináveis de YAML. Se quisesses fazer deploy de uma base de dados e de um servidor, tinhas de aprender uma sintaxe exclusiva dessa ferramenta de provisionamento específica. Perdias o rico ecossistema da engenharia de software standard. Não podias escrever facilmente um loop, integrar frameworks de testes standard, ou partilhar lógica usando package registries standard. O Pulumi muda esta base. É uma plataforma de Infrastructure as Code que te permite construir, fazer deploy e gerir recursos cloud usando linguagens de programação de propósito geral. Em vez de aprenderes uma linguagem de configuração feita à medida, usas TypeScript, Python, Go, C# ou Java. Imagina um developer a definir recursos cloud usando TypeScript. Com as ferramentas tradicionais, fazes constantemente context-switching para consultar schemas YAML num web browser. Com o Pulumi, ficas no teu editor. Instancias uma classe de recurso, escreves um ponto, e o auto-completion standard do IDE mostra-te exatamente que propriedades estão disponíveis. Tens type-checking inline antes sequer de correres um deploy. Se precisares de três storage buckets idênticos, escreves um for-loop standard. Se a tua empresa impõe regras de segurança específicas em cada servidor, abstrais essa lógica numa função standard, publicas num package registry standard, e deixas que outras equipas a importem tal como qualquer library de código normal. Aqui está o ponto-chave. Como escreves esta infraestrutura em linguagens imperativas, podes assumir que o Pulumi é apenas um script de automação que chama APIs cloud sequencialmente. Não é um script de execução imperativa. O Pulumi continua a usar um state model declarativo altamente robusto nos bastidores. Quando executas o teu programa Pulumi, ele não provisiona imediatamente os recursos linha a linha. Em vez disso, o teu código corre para construir o state final desejado da tua infraestrutura. O motor do Pulumi captura estas definições de recursos e constrói um dependency graph rigoroso. Depois, compara este state desejado com o state real atual do teu ambiente cloud. O Pulumi calcula a diferença exata e executa apenas as operações específicas de create, update ou delete necessárias para fazer a realidade corresponder ao teu código. Escreves com o flow expressivo de uma linguagem imperativa, mas tens a segurança e a previsibilidade de um motor de deploy declarativo. Ao adotares linguagens de propósito geral, desbloqueias o acesso a linters, frameworks de unit testing e pipelines de continuous integration existentes. O Pulumi simplesmente deixa de tratar a infraestrutura como um domínio de configuração separado e transforma-a em software standard, regido exatamente pelo mesmo rigor e tooling que a tua aplicação principal. Se quiseres ajudar a apoiar o programa, podes encontrar-nos pesquisando por DevStoriesEU no Patreon. Gostaria de tirar um momento para te agradecer por ouvires — ajuda-nos imenso. Tem um ótimo dia!

Olá, daqui é o Alex da DEV STORIES DOT EU. Pulumi: Infrastructure as Code, episódio 2 de 10. Instancias uma classe Python standard no teu editor, fazes deploy, e segundos depois um storage bucket existe na cloud. Como é que exatamente um objeto local em memória se traduz num recurso físico remoto? Hoje, vamos responder a isso olhando para o Under the Hood: a arquitetura do Pulumi. Existe um equívoco comum sobre como esta ferramenta funciona. Quando escreves um script de deployment, o teu código não comunica com as APIs da cloud. O environment que corre o teu código Python, Node ou Go não faz a menor ideia de como falar com a Amazon Web Services. Em vez disso, o Pulumi divide o processo de deployment por três componentes distintos: o Language Host, o Deployment Engine e os Resource Providers. Tudo começa com o Language Host. Este componente avalia o teu programa e extrai a tua intenção. Considera um script Python onde declaras um bucket AWS S3 inicializando um objeto bucket. O Python Language Host corre o teu script linha a linha. Quando chega a essa declaração do bucket, não faz um network request para a AWS. Simplesmente envia um registration request para o Deployment Engine. Diz ao engine que queres que exista um bucket com propriedades específicas. O Language Host comunica este desired state através de uma ligação local e depois para, à espera de uma resposta antes de avaliar a próxima linha de código. O Deployment Engine recebe este registration request. Este componente é o orquestrador. O engine não sabe nada sobre a sintaxe de Python, e não sabe nada sobre a API da AWS. O seu único trabalho é o state management. Ele olha para o desired state enviado pelo Language Host e compara-o com o último actual state conhecido da tua infraestrutura. Se o engine vir que este bucket S3 exato não existe no state atual, calcula um diff e determina que é necessária uma operação de create. Para construir realmente o bucket, o engine passa a tarefa para o terceiro componente, o Resource Provider. Os providers são plugins standalone descarregados para plataformas específicas, como a AWS, o Azure ou o Kubernetes. O deployment engine envia uma instrução ao Resource Provider da AWS, dizendo-lhe para criar o bucket com as propriedades pedidas. Aqui está o ponto chave. O Resource Provider é o único componente em toda esta chain que sabe como falar com a cloud. Ele pega no comando genérico de criação do engine, traduz isso nas REST API calls específicas exigidas pela AWS, e executa-as através da rede. Assim que a AWS provisiona o bucket S3, devolve um physical resource ID. O Resource Provider apanha este physical ID e devolve-o ao Deployment Engine. O engine atualiza o seu state interno para registar que o bucket agora existe no mundo real. Finalmente, o engine sinaliza de volta ao Language Host que o recurso está pronto, passando quaisquer output properties como o nome ou o URL do bucket. O Language Host retoma a execução, e o teu script Python continua para a instrução seguinte. Esta separação rigorosa de language evaluation, state orchestration e cloud execution é o que dá à arquitetura a sua flexibilidade. Podes adicionar uma nova linguagem de programação sem tocar nos cloud providers, e adicionar um novo cloud provider sem modificar os language hosts. Ficamos por aqui neste episódio. Até à próxima!

Olá, daqui é o Alex da DEV STORIES DOT EU. Pulumi: Infraestrutura como Código, episódio 3 de 10. Configurar um projeto de infraestrutura cloud costumava significar horas a lutar com ficheiros boilerplate e estruturas de pastas antes de conseguires escrever uma única linha de lógica. Hoje, consegues fazer o scaffold de um ambiente completo em segundos. Vamos focar-nos no Hello Azure: Creating Your First Project para ver exatamente como isso acontece. Um equívoco comum é achar que correr o comando de criação do projeto faz logo o build da infraestrutura na cloud. Não faz. O comando que estamos a discutir apenas gera ficheiros locais e prepara o tracking do teu state. Nenhum recurso real do Azure é criado até executares explicitamente um comando de deploy mais tarde. Para fazeres o bootstrap de um novo projeto, usas a command line interface. Primeiro, crias uma pasta vazia e entras nela. A seguir, corres o comando pulumi new seguido do nome de um template. Para o Azure, este template é normalmente azure dash e a tua linguagem de programação de eleição, como azure dash typescript ou azure dash python. Quando corres isto, a interface torna-se interativa. Guia-te por uma série de prompts para configurares o teu ambiente. Primeiro, pede um nome para o projeto, que por default é o nome da tua pasta. A seguir, pede uma descrição do projeto. Depois, pede o nome da stack. Uma stack é uma instância isolada do teu projeto, normalmente a representar um ambiente como development ou production. A stack default chama-se dev. Por fim, os templates do Azure pedem uma location do Azure, como WestUS, que será guardada como a tua região de deploy default. Assim que responderes aos prompts, a ferramenta faz o download do template, instala as dependências de linguagem necessárias e cria alguns ficheiros na tua pasta. Aqui está o ponto chave. O ficheiro mais importante gerado é o Pulumi dot yaml. Este é o ficheiro core do teu projeto. Define o nome do projeto, o runtime que usa e a descrição. Essencialmente, diz ao sistema como executar o teu código. Também vais ver um ficheiro chamado Pulumi dot dev dot yaml se tiveres aceite o nome default da stack. Este ficheiro secundário guarda os valores de configuração específicos dessa stack, incluindo a região do Azure que acabaste de selecionar. Juntamente com estes, tens os teus ficheiros de dependências standard, que variam dependendo da linguagem que escolheste, e o teu ficheiro de entrypoint. Dentro do ficheiro de entrypoint, o template default do Azure fornece um exemplo funcional de uma storage account do Azure. A lógica do código flui em três passos claros. Primeiro, importa o package Azure Native. Segundo, declara um novo Azure Resource Group, dando-lhe um nome lógico para o state file fazer o tracking. Terceiro, declara uma Azure Storage Account. É aqui que a coisa fica interessante. Em vez de fazer hardcode do nome do resource group, a storage account vai buscar a propriedade name diretamente ao objeto do resource group criado no passo anterior. Isto cria uma dependência implícita. O sistema agora sabe que tem de terminar de criar o resource group antes de tentar criar a storage account. O template também preenche automaticamente os argumentos necessários para a storage account, como o account replication type e o account tier. Mesmo no fim do ficheiro, o código exporta um valor. Neste exemplo com scaffold, exporta a primary storage key da storage account recém-definida. Quando finalmente fizeres o deploy, este valor exportado será impresso diretamente na tua consola, facilitando a recuperação de connection strings ou endpoints sem teres de fazer login no portal do Azure. Passas de uma pasta vazia para um programa de infraestrutura totalmente configurado simplesmente por responderes a alguns prompts, dando-te uma base sólida e com a sintaxe correta para começares a construir a tua própria arquitetura. Obrigado por ouvires, happy coding a todos!

Olá, daqui é o Alex da DEV STORIES DOT EU. Pulumi: Infrastructure as Code, episódio 4 de 10. O teu script de deploy corre perfeitamente no teu portátil. Fazes push do teu código, a tua pipeline automatizada dispara, e a build falha imediatamente porque não consegue encontrar um ficheiro de source. Nada no código mudou, mas o diretório onde o comando foi executado alterou-se ligeiramente. Esta é uma armadilha clássica de paths, e evitá-la requer perceber Projects e Paths: Estruturar o Teu Código. Na sua essência, um projeto Pulumi é simplesmente uma pasta que contém um ficheiro chamado Pulumi.yaml. Este ficheiro é a âncora. Ele diz à command line interface que este diretório específico contém a tua lógica de infraestrutura. Dentro do ficheiro Pulumi.yaml, declaras metadados como o nome do projeto, uma descrição e a linguagem de runtime. A propriedade runtime é o que decide como o teu código realmente corre. Se especificares Python, o runtime procura um ficheiro Python principal nesse diretório. Se especificares Node, ele procura o entrypoint definido no teu package file, que normalmente é um ficheiro index. Se preferires manter o teu source code numa subpasta em vez do diretório principal do projeto, podes fazer override explícito deste comportamento ao definir a propriedade main no teu ficheiro Pulumi.yaml para apontar para essa subpasta específica. Agora, vamos olhar para a confusão comum em relação aos file paths. Supõe que estás a fazer a build de uma container image Docker como parte da tua infraestrutura, e o teu Dockerfile está num subdireório chamado app, localizado mesmo ao lado do teu código Pulumi. Os engenheiros costumam passar um absolute path das suas máquinas locais para dizer ao Pulumi onde está o Dockerfile. Mas um absolute path inclui o teu diretório de utilizador pessoal. Quando um colega de equipa faz pull do código e corre um update, o engine vê um absolute path diferente na máquina dele. Ele regista isto como uma mudança estrutural no recurso, criando um drift desnecessário no state da tua infraestrutura. Para corrigir isto, podes mudar para um relative path standard, como ponto barra app. Os relative paths standard dependem inteiramente do current working directory do terminal que está a executar o código. Se o teu sistema de continuous integration correr o comando a partir de um diretório acima no repositório, o relative path é resolvido incorretamente, e o deploy crasha. Aqui está o ponto chave. Precisas de paths que sejam completamente independentes da máquina onde correm, e independentes de onde o utilizador escreveu o comando de execução. Precisas de project-relative paths. O Pulumi fornece uma built-in function para obter a localização exata do ficheiro Pulumi.yaml durante a execução. Dependendo da tua linguagem de programação, esta função é tipicamente chamada get root directory ou algo semelhante. Quando chamas esta função, o runtime devolve o absolute path para a pasta que contém o teu ficheiro Pulumi.yaml. Em vez de fazeres hardcode de um path para o teu Dockerfile, constróis o path dinamicamente. Pegas no resultado da função root directory e fazes append do teu subdiretório app. Como esta função é avaliada dinamicamente a cada execução, o path resultante está sempre perfeitamente adaptado ao ambiente que está a correr o código. A tua máquina local, o portátil do teu colega de equipa, e o build server remoto vão todos gerar o absolute path correto para os seus file systems específicos. O file path é resolvido de forma consistente todas as vezes, e o engine deteta zero alterações à definição do recurso. O teu código de infraestrutura nunca deve querer saber onde vive num disco rígido. Ancora sempre os teus file assets à função root directory do Pulumi, garantindo que o teu projeto se mantém completamente portátil em qualquer ambiente. É tudo por este episódio. Obrigado por ouvires, e continua a construir!

Olá, daqui é o Alex da DEV STORIES DOT EU. Pulumi: Infrastructure as Code, episódio 5 de 10. Fazer copy-paste do teu código de infraestrutura para criar um ambiente de staging é uma receita para drift e desastre. Acabas por manter várias pastas com ficheiros quase idênticos e, mais cedo ou mais tarde, alguém se esquece de atualizar a produção. A solução é tratar os teus ambientes como instâncias isoladas de uma única codebase usando Stacks. Antes de avançarmos, vamos esclarecer um ponto de confusão muito comum. Um Project no Pulumi é simplesmente um diretório que contém o teu código-fonte. São apenas as instruções. Uma Stack é uma instância de deploy ativa desse código. Escreves o Project uma vez e fazes o deploy várias vezes como diferentes Stacks. As Stacks permitem-te gerir diferentes ambientes, como desenvolvimento, staging e produção, sem duplicar qualquer código. Quando corres um Pulumi update, ele aplica o código do teu Project à Stack que estiver ativa no momento. Cada Stack mantém o seu próprio state file isolado, acompanhando apenas os recursos criados para esse ambiente específico. A gestão destes ambientes acontece diretamente no teu terminal. Crias um novo ambiente ao correr o comando stack initialize, dando-lhe um nome como dev ou prod. O Pulumi regista esta nova instância e cria um state novo para ela. Para mudar de contexto, usas o comando stack select. A CLI do Pulumi memoriza qual é a Stack que está ativa. Se selecionares a Stack dev e correres um update, o Pulumi olha apenas para o state de desenvolvimento. Ele provisiona ou modifica a infraestrutura de desenvolvimento, deixando os teus ambientes de staging e produção completamente intactos. Isto cobre o deploy de ambientes isolados. Mas o que acontece quando estes ambientes precisam de comunicar entre si? Às vezes, uma Stack depende de informação gerada por outra. Podes ter um Project a gerir a infraestrutura core e um Project totalmente separado a lidar com o código da aplicação. Imagina que tens um Project de infraestrutura que provisiona um cluster de Kubernetes. Fazes o deploy disto como uma Stack chamada base-infra-prod. Durante o deploy, o cluster gera uma connection string dinâmica. Agora, tens um segundo Project para um microsserviço que precisa de fazer deploy exatamente nesse cluster. Não queres fazer hardcode da connection string, e não queres fazer merge dos dois Projects num único state file enorme e lento. É aqui que a coisa fica interessante. Podes interligar estes deploys com segurança usando uma Stack Reference. Uma Stack Reference permite que uma Stack leia os outputs exportados de outra Stack. Para configurar isto, o programa do teu cluster de Kubernetes deve exportar explicitamente a connection string no final da sua execução. Um export é simplesmente uma variável que o Pulumi guarda no state da Stack especificamente para que possa ser lida do exterior. Depois, no programa do teu microsserviço, crias um objeto Stack Reference. Passas-lhe o nome da Stack de infraestrutura da qual queres ler. A seguir, chamas um método get output nessa referência, pedindo a connection string pelo seu nome exportado. O teu microsserviço já pode usar esse valor para configurar o seu deploy. A Stack do microsserviço não pode modificar a Stack do cluster. Só pode ler os valores específicos que a Stack do cluster escolheu exportar. Isto garante uma separação clara. Podes atualizar e escalar a tua infraestrutura de rede core de forma totalmente independente dos workloads da tua aplicação, enquanto passas com segurança os detalhes de conexão necessários. Ao desacoplar o teu código da instância do ambiente, garantes que cada camada do teu sistema passa exatamente pela mesma lógica, eliminando os riscos ocultos da duplicação manual. Por este episódio é tudo. Obrigado por ouvires, e continua a desenvolver!

Olá, daqui fala o Alex da DEV STORIES DOT EU. Pulumi: Infrastructure as Code, episódio 6 de 10. Fazes o deploy do teu código de infraestrutura, a sintaxe está impecável, e ele falha imediatamente porque o nome de um storage bucket já está a ser usado. Ou pior, atualizas uma instância de base de dados, e a tua ferramenta apaga a antiga antes de criar a nova, causando um outage grave. Podes resolver ambos os problemas ao perceberes como a tua ferramenta de infraestrutura lida com a identidade. É exatamente isso que vamos abordar hoje: The Building Blocks: Pulumi Resources. No Pulumi, um recurso é um objeto que representa uma peça de infraestrutura. Existem dois tipos principais com os quais vais trabalhar. O primeiro é um Custom Resource. Este mapeia diretamente para um objeto físico gerido por um cloud provider. Quando declaras um Custom Resource, o Pulumi faz uma API call à Amazon, Azure ou Google Cloud para criar esse objeto exato, como uma virtual machine ou um load balancer. O segundo tipo é um Component Resource. Um Component Resource não mapeia para uma única peça de infraestrutura cloud. Em vez disso, é um container lógico para outros recursos. Usas Component Resources para construir abstrações de mais alto nível. Por exemplo, podes criar um único Component Resource chamado Secure Web Server que, internamente, provisiona uma virtual machine, um security group e um endereço IP. O próprio Component Resource apenas os agrupa no teu state file, tornando o teu código mais limpo e fácil de gerir. Quer estejas a definir um Custom Resource ou um Component Resource, todos eles exigem um nome. Isto levanta uma fonte comum de frustração. As pessoas escrevem um nome no seu código, fazem o deploy, e depois vão verificar o seu cloud console apenas para descobrir que o seu recurso tem uma string aleatória de caracteres adicionada ao final do nome. Isto não é um bug. É uma feature central da forma como o Pulumi funciona, e precisas de perceber a diferença entre um logical name e um physical name. O logical name é o nome que escreves no teu código como argumento. O Pulumi usa este logical name para fazer o tracking do recurso dentro do seu state file. É assim que o Pulumi sabe que a base de dados no teu código hoje é exatamente a mesma base de dados da qual fizeste deploy ontem. O physical name é como o cloud provider realmente chama o recurso no seu próprio sistema. Por default, o Pulumi pega no teu logical name, adiciona um sufixo aleatório, e usa essa string combinada como o physical name. A isto chama-se auto-naming. Aqui está o ponto chave. O auto-naming evita colisões globais de nomes e permite substituições com zero downtime. Imagina provisionar vários storage buckets idênticos num loop usando o Azure. O Azure exige que os nomes das storage accounts sejam globalmente únicos em todos os clientes. Se tentares forçar um physical name estrito, o segundo bucket no teu loop vai falhar porque o nome já está ocupado, ou pior, outra pessoa no mundo já pode ser a dona dele. Com o auto-naming, podes simplesmente usar um logical name como archive-bucket dentro do teu loop. O Pulumi vai fazer o tracking de cada iteração logicamente, garantindo que cada bucket recebe um physical name matematicamente único no Azure. O auto-naming também protege o uptime do teu sistema. Se fizeres uma alteração que force a substituição de um recurso, o Pulumi cria o novo recurso primeiro, verifica se funciona, e só depois apaga o antigo. Se fizeres override do auto-naming e forçares um physical name estrito, o cloud provider não vai permitir que dois recursos partilhem o mesmo nome ao mesmo tempo. O Pulumi seria forçado a apagar o teu recurso antigo primeiro, causando downtime enquanto o novo é provisionado. Se quiseres ajudar a manter o programa a andar, podes procurar por DevStoriesEU no Patreon. Mantém os teus physical names flexíveis. Deixa a ferramenta gerir os sufixos aleatórios, porque, embora o teu state file exija um logical name para manter a ordem, o teu ambiente de produção depende da flexibilidade física para se manter online. Obrigado por ouvirem. Fiquem bem.

Olá, daqui é o Alex do DEV STORIES DOT EU. Pulumi: Infrastructure as Code, episódio 7 de 10. Fazer hardcode de uma password de base de dados no teu código de infraestrutura é uma falha de segurança garantida. Mas injetar variáveis de ambiente manualmente em cada pipeline de deploy é frágil e difícil de rastrear. Precisas de uma forma de ligar valores específicos e encriptados a ambientes específicos automaticamente. Isto é Manter Segredos: Gestão de Configuração. A ideia principal aqui é separar o teu código da tua configuração. Queres escrever a tua lógica de infraestrutura exatamente uma vez. Depois, quando fazes deploy para a tua stack de desenvolvimento, o código provisiona instâncias pequenas. Quando fazes deploy para produção, provisiona instâncias grandes e usa as credenciais da base de dados de produção. O Pulumi lida com isto através de um sistema de configuração integrado. Um ponto comum de confusão é como estes valores são realmente guardados. Definir um valor de configuração do Pulumi não define variáveis de ambiente do sistema operativo local. Em vez disso, guarda os valores diretamente num ficheiro chamado Pulumi ponto stack-name ponto yaml. Como cada stack tem o seu próprio ficheiro de configuração distinto, a tua configuração de dev e a tua configuração de prod vivem lado a lado no teu repositório, claramente separadas pelo nome do ficheiro. Adicionas dados a este ficheiro usando a command line interface do Pulumi. Se executares o comando pulumi config set frontendPort 8080, o Pulumi escreve esse par key-value diretamente no ficheiro yaml da tua stack atualmente ativa. Para usares esse valor no teu código de infraestrutura, instancias um objeto Config. Depois, chamas um método como get ou require nesse objeto, passando o nome da key. A diferença é simples. Chamar get devolve o valor se ele existir, ou nada se não existir. Chamar require vai lançar um erro e parar o teu deploy se a key de configuração estiver em falta. Esta é uma ótima forma de garantir que um deploy nunca avança sem uma configuração obrigatória. Não estás limitado a strings simples. Podes guardar e recuperar dados estruturados, como um bloco JSON que define parâmetros de scaling, e fazer o parse diretamente para um objeto no teu código. Agora, o que acontece quando esse valor de configuração é altamente sensível? Imagina que a tua aplicação precisa de se ligar a uma base de dados externa, e tens de passar a password da base de dados para a tua infraestrutura. Não podes, de todo, guardar isto em plaintext no teu ficheiro yaml, porque é feito o commit desse ficheiro para o version control. É aqui que entram os secrets do Pulumi. Usas exatamente a mesma command line interface, mas adicionas uma flag secret. Corres pulumi config set dbPassword a-tua-password dash dash secret. O Pulumi encripta o valor antes de o guardar no ficheiro yaml. Se alguém olhar para o ficheiro no teu repositório, vai ver apenas uma string de ciphertext encriptada com segurança pelo encryption provider da tua stack. No teu código, recuperas isto com segurança chamando um método secret específico no teu objeto Config, como requireSecret. Aqui está o ponto-chave. Quando recuperas um secret desta forma, o Pulumi envolve-o num tipo secret especial. À medida que este valor flui pelo teu código de infraestrutura e é passado para os resources, o motor do Pulumi rastreia-o. Garante que o valor em plaintext é mascarado no output da tua consola durante um deploy, e garante que o valor permanece encriptado dentro do teu ficheiro de state do Pulumi. A configuração permite-te escrever código de infraestrutura uma vez e promovê-lo com segurança entre ambientes. A encriptação nativa de secrets garante que as tuas credenciais sensíveis conduzem esses deploys sem nunca vazarem para o teu version control ou para os teus ficheiros de state. Obrigado por passares uns minutos comigo. Até à próxima, fica bem.

Olá, daqui fala o Alex da DEV STORIES DOT EU. Pulumi: Infrastructure as Code, episódio 8 de 10. Copias e colas um bloco de código de storage e networking pela quinta vez esta semana. O teu código de infraestrutura está a crescer, mas não está a ficar mais inteligente. Em vez de repetires configurações de cloud idênticas sempre que precisas de um setup standard, podes gerá-las com uma única unidade lógica. Esse é o foco deste episódio: Scaling Up: Component Resources no Azure. Quando começas a usar o Pulumi, declaras raw resources. Um resource group aqui, uma storage account ali. Mas, à medida que o teu sistema cresce, fazer o deploy de uma peça standard de arquitetura exige provisionar o mesmo conjunto de primitivas vezes sem conta. Isto viola a regra de não te repetires. Os Component Resources resolvem isto ao permitir-te encapsular múltiplos cloud resources físicos numa única abstração reutilizável. Pensa num component resource como uma class custom que defines na tua linguagem de programação de eleição. Uma vez definida, instancias essa class exatamente como um resource built-in do Pulumi. Considera um cenário onde fazes frequentemente o deploy de static websites no Azure. Um setup mínimo requer um Azure Resource Group, uma Storage Account configurada para static website hosting, e um objeto Blob a servir de index document. Em vez de escreveres essas três definições no teu programa principal todas as vezes, crias um component de static website para o Azure. Para construíres isto, defines uma nova class que herda da base class ComponentResource do Pulumi. O constructor da tua class recebe um name, um conjunto de arguments para customização, e resource options standard. A primeira coisa que o teu constructor faz é chamar o constructor da base class. Passas-lhe um type token único, como custom dois pontos infrastructure dois pontos static website, juntamente com o name. Este type token diz ao engine como rastrear a tua nova abstração no state file. A seguir, defines as primitivas reais do Azure dentro do teu constructor. Declaras o resource group. Declaras a storage account dentro desse group. Fazes o upload do index blob para essa account. Aqui está o ponto chave. Quando crias estes resources internos, tens de dizer explicitamente ao engine que eles pertencem ao teu novo component. Fazes isto passando a própria instance do component para as resource options, debaixo da property parent. Muitos engenheiros esquecem-se deste passo. Se omitires a option parent, os child resources vão ser provisionados com sucesso, mas serão tratados como top-level resources. O output da tua command line será uma lista plana e confusa. Ao definires a property parent para a tua instance do component, o engine organiza a state tree. Quando corres um update, a interface aninha visualmente o resource group, a storage account e o blob diretamente debaixo do teu component de website custom. Isto mantém o teu state gerível e o teu output legível. Finalmente, o teu programa principal provavelmente precisa de saber o web address do site recém-criado. Dentro do teu component, depois de definires a storage account, mapeias o seu web endpoint principal para uma public property na tua class. A seguir, chamas um method chamado register outputs. Isto finaliza a inicialização e garante que o address final é exposto ao resto do teu programa e impresso na consola quando o deploy terminar. No teu main file, já não vês o boilerplate. Simplesmente instancias o teu component de website, passas-lhe um index file, e fazes o deploy. Os resources subjacentes são geridos de forma segura por trás da abstração. O verdadeiro poder do infrastructure as code é tratar a cloud architecture como software, e os component resources são a forma de construíres uma library standard e fiável para a tua equipa. É tudo por este episódio. Obrigado por ouvires, e continua a construir!

Olá, daqui fala o Alex da DEV STORIES DOT EU. Pulumi: Infrastructure as Code, episódio 9 de 10. Não precisas de deitar fora anos de código existente para começares a usar uma nova ferramenta de infraestrutura hoje. A temida reescrita massiva de um sistema é um risco enorme e, felizmente, é totalmente opcional. A estratégia que torna isto possível chama-se Coexistência Pacífica: Ler o State do Terraform. Uma ideia errada muito comum é achar que mudar para o Pulumi significa que tens de migrar toda a tua infraestrutura existente de uma só vez. Isso não é verdade. O Pulumi consegue ler e depender nativamente de recursos que são geridos ativamente pelo Terraform. Podes adotar novas ferramentas de forma incremental, lado a lado com as tuas pipelines de deploy existentes. Considera um ambiente empresarial típico. A tua empresa tem uma Virtual Private Cloud core da AWS, gerida por uma equipa central de redes a usar Terraform. És um developer a construir uma nova aplicação e queres usar o Pulumi para fazer deploy de tasks do Elastic Container Service. Os teus contentores têm de correr dentro dessa mesma VPC. Não queres reescrever o código da VPC para Pulumi e, certamente, não queres assumir a gestão da rede subjacente. Para lidar com isto, usas o provider de Terraform do Pulumi. Este provider inclui um componente específico concebido para ler ficheiros de state, chamado remote state reference. O processo depende da forma como o Terraform armazena os seus dados de execução. Primeiro, o código Terraform que gere a rede tem de expor explicitamente os dados de que a tua nova aplicação precisa. Faz isto usando blocos de output standard do Terraform. A equipa de redes configura o seu código para fazer output do identificador da VPC e de uma lista de identificadores de subnets privadas. Quando o Terraform aplica a sua configuração, esses outputs são gravados no ficheiro de state do Terraform, que normalmente é guardado remotamente num backend, como um bucket do AWS S3 ou na Terraform Cloud. De seguida, passas para o teu programa Pulumi. Escreves código para instanciar a remote state reference. Forneces a este objeto os mesmos detalhes de configuração de backend que o Terraform usa para encontrar o seu ficheiro de state. Isto inclui o tipo de backend, o local de armazenamento, a região e a key específica do ficheiro de state. Quando executas o teu deploy com o Pulumi, o engine liga-se a esse backend remoto, abre o ficheiro de state do Terraform e faz o parse dos outputs disponíveis. Aqui está o ponto chave. O Pulumi trata o state do Terraform como estritamente read-only. Nunca modifica o ficheiro de state do Terraform e não assume a propriedade dos recursos de rede. Simplesmente consulta os valores atuais e conhecidos da infraestrutura. Assim que o Pulumi recupera os identificadores da VPC e das subnets a partir do state, tratas esses valores como qualquer outra variável no teu código. Passas-os diretamente para a lógica de deploy do teu novo cluster de contentores. O Pulumi provisiona os teus novos contentores de forma transparente na rede existente. Esta arquitetura mantém as responsabilidades completamente separadas. A equipa central continua a gerir o ciclo de vida da rede usando Terraform. Se atualizarem uma route table ou adicionarem uma tag, usam o seu workflow standard. Se modificarem um output, como a criação de uma nova subnet, o Pulumi vai ler automaticamente o ficheiro de state atualizado durante o seu próximo update e ajustar o deploy dos teus contentores em conformidade. Usar remote state references cria uma fronteira de dependência unidirecional e limpa, permitindo-te construir novos sistemas com capacidades modernas com confiança, enquanto te apoias numa base estável gerida por código legado. É tudo por este episódio. Obrigado por ouvires, e continua a construir!

Olá, daqui fala o Alex da DEV STORIES DOT EU. Pulumi: Infrastructure as Code, episódio 10 de 10. Testar lógica de infraestrutura complexa é notoriamente difícil. Escreves milhares de linhas de configuração, mas verificar se uma combinação específica de regras de firewall realmente se comporta como esperado antes do deploy muitas vezes parece adivinhação. A Grande Migração: Converter HCL para Pulumi é como resolves isto. Migrar de Terraform para Pulumi não é um simples find-and-replace sintático. Não se trata de trocar chavetas por parênteses. Trata-se de pegar numa configuração estática e transformá-la num programa executável, dando-te acesso imediato a loops nativos, funções e frameworks de teste standard. Pensa numa configuração de security group de Terraform altamente complexa e repetitiva. Provavelmente tens dezenas de intervalos de portas sobrepostos, IP allowlists específicas e definições de blocos pesadas. Em HCL, gerir isto requer estruturas rígidas, e validar a lógica exige correr um plan contra um live cloud state. A transição começa com o comando pulumi convert. Navegas até uma diretoria que contém os teus ficheiros Terraform existentes e corres este comando, especificando a tua linguagem de destino, como TypeScript ou Python. A ferramenta faz o parse do teu source code HCL, lê as tuas variáveis, recursos principais e outputs, e gera um programa Pulumi equivalente. Ela traduz a intenção declarativa do HCL para a estrutura imperativa da linguagem de programação que escolheste. Assim que esse código é gerado, os benefícios estratégicos da migração ficam claros. Agora podes fazer refactor àquela enorme lista de regras de security group para um array limpo de data objects, ou extraí-las de um ficheiro de configuração externo. Podes iterar sobre esse array para gerar regras de firewall dinamicamente usando loops standard de TypeScript ou Python. Aqui está o ponto-chave. Como a tua infraestrutura agora está escrita numa linguagem de propósito geral, podes testá-la exatamente como código aplicacional. Podes escrever um unit test usando frameworks standard como Jest ou PyTest. Crias um test case que faz mock do runtime do Pulumi e faz assert que a tua função de builder do security group nunca expõe acidentalmente a porta vinte e dois para toda a internet. Corres estes testes em milissegundos, completamente offline, apanhando erros lógicos antes mesmo do início da fase de plan da infraestrutura. Esta mudança desbloqueia uma integração profunda com a linguagem. O teu código de infraestrutura pode partilhar standard libraries, lógica de validação e typing definitions diretamente com o código da tua aplicação. Ganhas acesso aos ecossistemas maduros de package managers como NPM ou pip, permitindo-te fazer package e distribuir padrões de infraestrutura com a mesma facilidade que qualquer outra software library. O comando de conversão faz o trabalho pesado de traduzir o teu state atual, mas a verdadeira migração acontece quando mudas a tua mentalidade de escrever ficheiros estáticos para desenvolver sistemas testáveis. A maior vantagem de converter o teu código é passar de simplesmente configurar a infraestrutura para realmente programá-la. Recomendo vivamente que leias a documentação oficial do Pulumi, pegues num pequeno módulo de Terraform e tentes correr a conversão tu mesmo para veres o output. Se tiveres ideias sobre quais tópicos técnicos devemos abordar na nossa próxima série, visita devstories dot eu e diz-nos. É tudo por este episódio. Obrigado por ouvires, e continua a construir!