Construindo sua primeira aplicação com Docker
Veja como Docker pode transformar seu ambiente de desenvolvimento, simplificando a criação e a execução de aplicações em qualquer lugar.
ASP.NET no Kubernetes: Como fazer deploy da sua aplicação localmente
Neste artigo guiaremos você através do processo de configuração, desenvolvimento e deploy de uma aplicação .NET simples usando Kubernetes localmente
Como usar variáveis/segredos no GitHub Actions
Neste artigo iremos explorar como na prática podemos guardar dados sensíveis como chaves, senhas ou connection strings para serem utilizadas em seu fluxo de CI/CD no GitHub.
Git Tag, Release e Versioning: Entendendo a rastreabilidade de software
Na gestão de software, versões de lançamento são cruciais para manter a rastreabilidade, garantir a qualidade e facilitar a colaboração entre as equipes. Para desenvolvedores que ainda não estão familiarizados com práticas de DevOps, termos como Git Tag, Release e Semantic Versioning podem parecer complexos. Este artigo tem como objetivo desmistificar esses conceitos e mostrar como eles se relacionam na prática. Todo exemplo usado neste artigo estará disponível neste projeto público aqui: https://github.com/toolbox-playground/terraform-exemplo-gcp Git Tag: marcos de código O conceito de tag no Git é fundamental para marcar pontos específicos no histórico de commits de um repositório, como se fosse uma ‘conquista’. Como boa prática, sempre devemos criar esses marcos a partir da branch mais estável e que represente o código em produção (normalmente usamos a branch main para isso). Uma tag no Git é essencialmente um rótulo fixo que você pode atribuir a um commit específico no seu repositório. Diferente dos branches, que continuam a evoluir conforme novos commits são adicionados, uma tag aponta para um commit específico e permanece imutável. Isso é particularmente útil para marcar releases de software, versões específicas ou conquistas importantes. Vamos imaginar que você esteja prestes a lançar uma nova versão estável do seu software. Após a conclusão do desenvolvimento e os testes finais, você decide criar uma tag para marcar esse momento no histórico do seu repositório Git. Isso pode ser feito da seguinte forma: git tag -a v1.4 -m “my version 1.4” git push –follow-tags origin main Release: Formalizando e publicando versões de software Numa fábrica de qualquer produto, toda matéria prima se torna um produto final, numa pipeline de softwares não é diferente. Uma Release é uma entrega formal de uma versão do software que foi preparada para distribuição. Geralmente, essa entrega está associada a uma tag e inclui: Versão do software: definida através do Semantic Versioning. Release Notes: um resumo das principais mudanças, melhorias, novos recursos e correções de bugs incluídos na versão. Essas notas são cruciais para informar ao público usuários e desenvolvedores sobre o que esperar da nova versão. Artefatos: em alguns casos, especialmente para projetos em linguagens compiladas, o release pode incluir binários ou outros arquivos necessários para a execução do software. Na prática, podemos considerar qualquer biblioteca disponível para download ou software como um exemplo real de um Release na prática. Abaixo, temos o exemplo da própria ferramenta Git. Cada Release gera um documento oficial, conforme abaixo, em que vemos uma das releases do Git: Semantic Versioning Semantic Versioning (SemVer) é uma convenção de versionamento para softwares que segue um padrão específico para nomear versões. Esse padrão é composto por três números separados por pontos: MAJOR.MINOR.PATCH. Cada um desses números tem um significado específico e uma regra de incremento baseada nas mudanças feitas no software. MAJOR: incrementado quando há mudanças incompatíveis na API (breaking changes); MINOR: incrementado quando funcionalidades são adicionadas de maneira compatível com versões anteriores; PATCH: incrementado quando correções de bugs são feitas de maneira compatível com versões anteriores. Por exemplo, a versão 2.1.3 pode indicar: 2: segunda versão maior do software, possivelmente com mudanças significativas e incompatíveis com a versão 1.x.x; 1: primeira atualização menor, adicionando funcionalidades novas, mas mantendo compatibilidade com a versão maior; 3: terceira correção de bugs desde a última atualização menor. Há várias formas de decidir o momento em que sua empresa ou time irão atualizar a versão do software e o fator maturidade do time pode contar muito no momento de desenhar essa lógica. Há situações em que o software efetua a troca de versão por “tipo de mensagem” no commit, como o padrão commit–zen apresenta. Há softwares que geram novas versões por tempo de projeto, como o SQL Server, que lançava sempre uma versão a cada dois anos: SQL Server 2012, SQL Server 2014, SQL Server 2016. Não há certo ou errado ao assumir qualquer estratégia e lembre-se sempre de adequar uma estratégia que faça sentido para o momento e a senioridade do seu time. Acelere a sua carreira conosco! A Mentoria DevOps é um programa de mentoria de 12 meses com encontros semanais ao vivo, com um grupo seleto e restrito, onde estaremos do seu lado para mantê-lo relevante e atualizado no mercado de tecnologia, aprendendo e implementando as melhores práticas e ferramentas de DevOps. Clique aqui para entrar na prioridade pela melhor oferta de lançamento Conclusão Todos esses conceitos, quando bem aplicados, garantem o que chamamos de rastreabilidade de software, permitindo que desenvolvedores, operadores e usuários finais saibam exatamente o que esperar de cada versão e até mesmo retornem para uma versão anterior se tiverem necessidade. A partir de agora, com base no conteúdo que vimos neste artigo, você pode adotar essas práticas em seus projetos ou mesmo fomentar seu uso no seu time e empresa.
Pipeline no Azure DevOps para uma aplicação ASP.NET Core
Neste artigo vamos te guiar passo a passo na configuração de um pipeline usando a estratégia de uso dos arquivos YAMLs dentro do Azure DevOps.
Melhores práticas para testes de software em pipelines
A qualidade de software é um fator crucial para o sucesso de qualquer aplicação. Em um ambiente de desenvolvimento ágil, em que mudanças são rápidas e frequentes, manter um alto padrão de qualidade pode ser desafiador. É aí que podemos utilizar estratégias do mundo DevOps para nos auxiliar. Este artigo vai explorar como garantir a qualidade do software durante o ciclo de CI/CD, destacando ferramentas e boas práticas que podem ser adotadas mesmo por quem é novo no assunto. Os mandamentos da pipeline Para um ciclo excelente de qualidade em sua esteira de software, podemos dividir em 3 grandes pilares que são: Testes de software Análise de segurança Versionamento de artefatos Neste artigo, focaremos no pilar de Testes de Software e para garantir que nossa abordagem funcione corretamente e produza resultados de alta qualidade, devemos considerar esses 3 pilares como inegociáveis e que uma vez implementado, toda a cadeia de pessoas responsável pelo software como produto final deverá entender seus benefícios e trabalhar em prol dos resultados. Lembre-se sempre: não há ferramenta ou processo que faça milagre em um ambiente em que se negocie qualidade. Os testes de um software Dentro de um processo de CI/CD, podemos executar vários tipos de testes. Cada um desses tipos teste tem uma finalidade e por esse motivo eles podem e devem ser alocados em momentos estratégicos durante uma pipeline. Testes de componentes Os testes de componentes são ideais para validar a integração entre componentes do sistema. À medida que seu sistema cresce, naturalmente a quantidade de componentes também cresce e isso pode se tornar um problema, pois muitas das vezes a pipeline irá aguardar o fim do teste para prosseguir para a próxima fase. Num cenário ideal, esses testes não devem passar de 20 minutos e devem ser programados para serem executados no ambiente de testes para não tornar o processo de CI/CD um pouco mais lento. Ferramentas que podemos utilizar nesse processo são: JUnit, Jest, PyTest, Mocha, TestNG e Cypress. Testes fim-a-fim ( End-to-end ) Aconselhável habilita-los em qualquer ambiente com o intuito de garantir que as features básicas do sistema estejam minimamente operacionais. Como naturalmente são testes complexos que asseguram que cenários reais, seu tempo pode variar entre 10 minutos a 40 minutos. Ferramentas que podemos utilizar nesse processo são: Puppeteer, Selenium, Robot Framework ou Cucumber. Testes de contrato O teste de contrato ideal é utilizado para garantir que o código desenvolvido em questão corresponde aos acordos escritos previamente em contrato/documentação. Podemos economizar tempo nos pipelines apenas testando no ambiente de pré-produção, pois, assim como testes de componentes, os testes de contrato aumentam seu tempo de execução a cada nova implementação e validação, principalmente se há uma grande quantidade de comunicação entre serviços. Ferramentas que podemos utilizar nesse processo são: Swagger, Pact.io. Testes de regressão Os testes que têm a maior carga e se não um dos mais importantes para qualquer release. Esse tipo de execução acaba exigindo muitas horas de execução, pois tem a necessidade de realizar testes em versões anteriores do sistema para garantir que a sua evolução não cause nenhuma surpresa. Normalmente esses tipos de testes acabam levando horas para serem executados tornando inviável a execução de forma diária ou durante qualquer chamada no fluxo de CI/CD. O mais ideal para esse tipo de teste seria que todo recurso computacional obsoleto ( provavelmente de madrugada ) possa ser utilizado para validar todas as evoluções do sistema. Alguns serviços de pipelines como Bitbucket e Azure DevOps permitem que algumas pipelines possam ser executadas através de um gatilho ou até mesmo através de tarefas agendadas, o que seria o mais ideal para esse tipo de testes. Teste de web-page-quality Como esses testes fazem análise estática dos componentes web, podemos executá-los no ambiente de produção fora da janela de horário comercial. Não há teste de funcionalidades nem carga no sistema com esse teste. Esses testes são executados para entender o comportamento e performance dos componentes de front-end. Ferramentas que podemos utilizar nesse processo são: Lighthouse. Testes de performance O ideal seria utilizar o máximo de recurso computacional das pipelines para simular a quantidade real de usuários ou cenários de picos de requisições de usuários. Outro conselho é executar os testes de performance em janelas fora do horário comercial devido ao excessivo uso da pipeline, que pode se tornar um gargalo durante o horário comercial. Ferramentas que podemos utilizar nesse processo são: K6, Jmeter. Benefícios Durante o processo de implementação das práticas descritas, podemos esbarrar em uma variável muito importante: o tempo total de execução de uma pipeline. Quanto mais atividades e processos colocamos em uma pipeline, ela tende a aumentar exponencialmente o seu tempo de execução, exigindo muito provavelmente uma maior capacidade computacional ou quantidade maior de servidores disponíveis para sua execução. Para resolver esse problema, a ideia que apresentamos é que cada teste pode ser executado em diferentes momentos em uma pipeline e evitados em outros, exatamente para evitar o consumo total das máquinas e tornar o processo muito mais eficiente e produtivo. Desde que o processo de pipeline execute todos os testes, não há problema em separarmos o momento de execução de cada uma das partes do processo para melhorar sua eficiência. Grande parte dos serviços de pipelines no mercado nos possibilitam tirar uma grande vantagem no processo de execução de testes através de condicionais e análise dos resultados de testes. Podemos até abortar um processo de deployment se eventualmente algum dos testes não se comportar da forma que esperávamos ou se os resultados extraídos dos testes não atingiram o mínimo solicitado. O uso de ferramentas como o Sonar durante as pipelines nos possibilitam usar seu Quality Gate para analisar a qualidade dos testes e do código, evitando assim de prosseguir com qualquer mudança que não atingir a qualidade exigida. Acelere a sua carreira conosco! A Mentoria DevOps é um programa de mentoria de 12 meses com encontros semanais ao vivo, com um grupo seleto e restrito, onde estaremos do seu lado para mantê-lo relevante e atualizado no
CI/CD com Bitbucket: primeiros passos
O Bitbucket Pipelines é uma ferramenta poderosa que permite a automação de builds, testes e implantações diretamente do Bitbucket. Para um profissional de DevOps, compreender e utilizar essa ferramenta pode otimizar significativamente o fluxo de trabalho e garantir maior eficiência nas entregas de software. Neste artigo vamos explorar os primeiros passos para configurar e utilizar o Bitbucket Pipelines. Introdução ao Bitbucket Pipelines Um dos pontos positivos do Bitbucket é que ele faz parte do ecossistema de soluções da Atlassian, que também é proprietária de ferramentas como Zendesk, Jira, Trello e Confluence. Se você ainda não conhece essas ferramentas, um dia muito provavelmente irá conhecer pelo seu potencial ou pela sua popularidade na indústria de desenvolvimento de software. O ponto positivo é a facilidade de integração entre as ferramentas e todo suporte ao ecossistema que você tem, deixando tudo centralizado e fácil para administrar. Assim como seus concorrentes, o Bitbucket Pipelines é uma ferramenta focada em CI/CD, possibilitando automação de processos, compilação, testes de código e deploys. Estrutura do Bitbucket Pipelines Dentro do Bitbucket, temos a tradicional hierarquia de Organizações, Projetos e Repositórios. Dentro de cada repositório, você pode criar uma pipeline de execução. Dentro do repositório, os pré requisitos que você tem que ter para executar esse passo a passo são: ter um código versionado; ter permissões suficientes para alterar as configurações básicas do repositório. Em configurações, habilite o repositório para executar a pipeline. A própria ferramenta irá sugerir um template para facilitar a sua vida. Nesse momento, podemos ignorar e aceitar a sugestão da ferramenta apenas para criar nosso exemplo. Esse arquivo é padrão e obrigatório para criarmos pipelines no Bitbucket, ou seja, ele sempre precisará estar na raiz do projeto e se chamar bitbucket-pipelines.yml. Pipeline na prática Para fins didáticos, utilizaremos um exemplo de “Hello world” em Node.js que está disponível aqui. Neste exemplo básico, definiremos apenas a instalação dos pacotes do Node.js. Abaixo temos o conteúdo do arquivo bitbucket-pipelines.yml, que define a estrutura da pipeline. image: node:lts-alpine3.19 pipelines: default: – step: name: Build and Test caches: – node script: – npm install Vamos analisar cada linha do código do arquivo bitbucket-pipelines.yml fornecido e entender o que ela faz: image: define a imagem do Docker a ser usada para executar o passo. Neste caso, a imagem “node:lts-alpine3.19” será usada, que contém o Node.js instalado. pipelines: define a seção “pipelines” do arquivo YAML. As pipelines são usadas para definir os passos ou estágios de um processo de integração contínua. default: define a seção “default” dentro da seção “pipelines”. A seção “default” é usada para definir os passos padrão que serão executados quando nenhum outro estágio específico for especificado. – step: define um passo dentro da seção “default”. Um passo é uma tarefa específica que será executada durante o processo de integração contínua. name: Build and Test: define o nome do passo como “Build and Test”. É uma descrição opcional que ajuda a identificar o objetivo do passo. caches: define a seção “caches” dentro do passo. Os caches são usados para armazenar dados em cache entre as execuções dos passos, a fim de melhorar o desempenho. – node: define um cache chamado “node”. Neste caso, o cache “node” será usado para armazenar as dependências do Node.js, a fim de evitar a necessidade de instalá-las novamente a cada execução. script: define a seção “script” dentro do passo. A seção “script” contém os comandos que serão executados durante o passo. Aqui é onde você preenche todos os passos que sua aplicação deverá seguir, seja instalação de pacotes, execução de testes e etc. Cada comando pode ser representado separadamente assim: script: – npm install – npm test – npm x Variáveis e Segredos Podemos utilizar o recurso de variáveis e segredos no Bitbucket para armazenar informações sensíveis, parâmetros de configuração que variam entre ambientes e etc. Dentro de configurações de repositório, em Pipelines, encontramos a opção para criar variáveis. Para utilizar as variáveis dentro do arquivo YAML, basta referenciar o nome da variável criada, precedido de $, por exemplo: script: – npm install – npm test – echo $Teste Scripts Uma outra funcionalidade muito importante é a capacidade de executar scripts dentro da pipeline. Desde que o arquivo exista dentro do repositório em que você irá criar a pipeline, você também consegue criar scripts bash para serem executados dentro dela: script: – ./deploy.sh Triggers: decidindo quando uma pipeline será executada No contexto de DevOps e integração contínua (CI), as triggers de pipeline são mecanismos essenciais para automatizar e controlar a execução dos pipelines com base em eventos específicos. No Bitbucket Pipelines, as triggers definem quando e como um pipeline deve ser iniciado, oferecendo flexibilidade e controle para diferentes fluxos de trabalho. Para o Bitbucket, temos alguns tipos de trigger e iremos explorá-las para entender melhor como configurar a execução de sua pipeline. Triggers de Branches Nessa configuração, você poderá executar diferentes scripts para branchs distintas. Para a branch Master, a pipeline irá executar a mensagem: “Pipeline para a branch master” e para a Develop “Pipeline para a branch develop”. Esse tipo de estratégia é excelente quando você precisa economizar tempo de pipelines, executando apenas trechos ou eliminando a necessidade de executar o mesmo script sempre: pipelines: branches: master: – step: script: – echo “Pipeline para o branch master” develop: – step: script: – echo “Pipeline para o branch develop” Triggers de Pull Requests Executam pipelines quando um pull request é criado ou atualizado. Isso é útil para garantir que as alterações propostas não introduzem erros. pipelines: pull-requests: ‘**’: – step: script: – echo “aqui só vai executar no momento do Pull Request” Triggers Agendadas ou CRON Permitem executar pipelines em horários específicos, independentemente de commits ou pull requests. Isso é útil para tarefas de manutenção, backups ou testes periódicos. Esse tipo de operação é muito utilizado para fazer check-ups durante a madrugada ou fora do horário comercial, fazendo com que você desafogue a maior parte das execuções excessivas ou que demore muito para um horário menos concorrido de execução. Para isso, basta
MTTx: a arte das métricas de DevOps
Quando trazemos à tona o tema DevOps, é natural que as pessoas sempre pensem em automações, pipelines e cloud, mas DevOps vai muito além disso. Dentro de DevOps, podemos dividir 5 grandes pilares, que foram comentados no artigo sobre Cultura DevOps, como Cultura, Automação, Lean, Medição e Compartilhamento. Hoje, nesse artigo, exploraremos o pilar de Medição e iremos refletir sobre como métricas e dados podem auxiliar toda a construção de um software. No coração do DevOps estão as métricas, e entre elas as MTTx (Mean Time To X) são fundamentais. Vamos explorar o que são essas métricas e por que elas são tão importantes. O que são as Métricas MTTx? MTTx são indicadores que ajudam a medir a eficiência e a eficácia dos processos de DevOps envolvidos na fase de criação de um software. O “MTT” significa “Mean Time To” (Tempo Médio Para) e podemos medir diversos eventos que o processo do nosso desenvolvimento podem gerar para poder fazer esse tipo de cálculo. As mais comuns são: MTTR (Mean Time to Recovery): Tempo Médio para Recuperação. MTTA (Mean Time to Acknowledge): Tempo Médio para Identificação. MTTD (Mean Time to Detect): Tempo Médio para Detecção. MTTR (Mean Time to Repair): Tempo Médio para Reparação. Métricas: imagine o uso de CPU e taxa de erros como termômetros do desempenho do seu sistema. As métricas são agregações numéricas de dados medidos regularmente ao longo do tempo que oferecem uma visão de alto nível do estado operacional. Métricas são dados conhecidos, ou seja pré-definidos, e capazes de ser mensuráveis ao longo do tempo. Todas essas métricas são geradas em diferentes momentos e ferramentas do processo, até a execução de uma versão do sistema, e é de responsabilidade da pessoa que ocupa o papel de DevOps agrupar esses dados para tomada de decisão. Iremos explorar cada uma dessas métricas e onde elas impactam no processo do desenvolvimento de um sistema. MTTA (Mean Time to Acknowledge): Tempo Médio para Identificação. MTTA mede o tempo médio que leva para identificar a causa raiz de um problema após a sua detecção. Para que isso ocorra, o sistema deverá conter mecanismos e ferramentas de observação pró-ativa para gerar logs/telemetria sobre o comportamento do sistema e assim avisar, através de alertas, que o sistema está com comportamento inesperado ou que não corresponde aos sinais vitais comuns. Benefícios do MTTA Agilidade na resolução de problemas, pois com processos e mecanismos de gerenciamento de incidentes, qualquer pessoa pode ser notificada a qualquer momento para ao menos ter conhecimento do que está acontecendo. Redução de impacto: quanto mais rápido um problema é identificado, o time pode adotar estratégias como rollback de deployment para mitigar os problemas do sistema. MTTD (Mean Time to Detect): Tempo Médio para Detecção É o tempo médio que leva para detectar o problema ocorrido, logo após a notificação do problema. Esta métrica é crucial para a quantificação de proatividade nos incidentes e também na capacidade de “troubleshooting” que o time tem para detectar a causa raiz de um problema. Dentro dessa métricas, podemos tirar lições aprendidas como: falta de treinamento e capacitação nas pessoas que suportam a operação, documentação defasada e falta de procedimento. Importância do MTTD Detecção precoce de problemas: quanto mais cedo um problema é detectado, mais rápido pode ser tratado. Prevenção de grandes falhas: detectar problemas cedo pode evitar que eles se transformem em grandes falhas. MTTR (Mean Time to Recovery): Tempo Médio para Recuperação Mede o tempo médio que uma equipe leva para restaurar um sistema ou serviço após uma interrupção ou falha. O MTTR começa a ser contado a partir do momento em que a falha é detectada e termina quando o serviço está totalmente restaurado e funcional. Essa métrica força os times a criarem mecanismos de deployment resilientes e tolerantes a falhas como: blue-green, canary, hot-hot, etc. Importância do MTTR Minimização do downtime: reduzir o tempo que um serviço fica indisponível é essencial para manter a satisfação do cliente e a continuidade dos negócios. Aumento da confiança do cliente: clientes confiam mais em serviços que são rapidamente restaurados após problemas, demonstrando a competência e a prontidão da equipe de TI. MTTR (Mean Time to Repair): Tempo Médio para Reparação Essa métrica mede o tempo médio necessário para reparar um sistema ou componente específico após a ocorrência de uma falha. O MTTR é calculado a partir do momento em que a falha é detectada até que o sistema ou componente esteja totalmente reparado e livre da última causa que tornou o sistema inoperante, assim tornando-se funcional novamente com a entrega que é necessária. Importância do MTTR Aprendizado: a excelência dessa métrica é alcançar maturidade no processo ao ponto de que bugs sejam reparados em um espaço curto de tempo e que times como suporte e desenvolvimento possam juntos encontrar a solução de forma rápida para a entrega do que é desejável. Melhoria na satisfação do cliente: clientes e usuários finais são menos impactados por falhas quando os tempos de reparação são curtos, aumentando a confiança nos serviços oferecidos. Acelere a sua carreira conosco! A Mentoria DevOps é um programa de mentoria de 12 meses com encontros semanais ao vivo, com um grupo seleto e restrito, onde estaremos do seu lado para mantê-lo relevante e atualizado no mercado de tecnologia, aprendendo e implementando as melhores práticas e ferramentas de DevOps. Clique aqui para entrar na prioridade pela melhor oferta de lançamento Conclusão Entender e monitorar as métricas MTTx é essencial para qualquer equipe de DevOps que busca melhorar a eficiência, a confiabilidade e a satisfação do seu software. Cada métrica oferece uma visão diferente e importante sobre como os processos estão funcionando e onde há espaço para melhorias. Aprender a gerar dados e medir todos esses pilares é sempre desafiador, mas são possíveis com as ferramentas existentes de mercado como Jira, pipelines ou ferramentas de monitoramento como OpenTelemetry.
Infra as Code com Pulumi: primeiros passos
Pulumi é uma ferramenta de infraestrutura como código open source que une o melhor do gerenciamento de infraestrutura de forma declarativa com as principais linguagens de programação de mercado, como Python, Node, .NET, entre outras. Essa ferramenta suporta diversos tipos de nuvens, infraestrutura nativa de nuvem, fornecedores de SaaS como Datadog ou TravisCI , e até mesmo nuvens privadas e híbridas. Cuidados Iniciais! O primeiro erro que muitos cometem na indústria quando o tema é Infra como Código e comparar Terraform e Pulumi. Não há uma conclusão objetiva de “X é melhor que Y”. Pulumi e Terraform têm dinâmicas diferentes, mesmo que entreguem o mesmo resultado. Pulumi, por exemplo, tem a vantagem de abstrair a complexidade de criação do manifesto da sua infraestrutura por uma linguagem que se aproxima muito do dia a dia de um desenvolvedor. Usar código elimina a necessidade de apontar e clicar na interface da nuvem para configurar a infraestrutura, um processo que é manual, tedioso, propenso a erros, irrepetível e simplesmente caótico. Exemplo em Python Outro ponto a se pensar é a polêmica na aquisição do Terraform pela IBM recentemente e querer usar o Pulumi por ser Open Source. Pulumi sim é open source, porém é grátis apenas para uso individual. Em qualquer cenário de uso em empresas, ele também acarreta custos e recursos, assim como Terraform. Como funciona o Pulumi? Pulumi é uma ferramenta desenvolvida por desenvolvedores para desenvolvedores. Isso significa que ela cria um ambiente totalmente intuitivo e acolhedor para permitir uma experiência boa para quem utiliza a ferramenta. Pulumi tem a vantagem de usar o sistema “language-host”, onde você pode utilizar linguagens de programação para intermediar a criação da sua infra estrutura. Por trás das cenas, o Pulumi traduz a sua requisição na linguagem que você escreveu seu código, avalia as mudanças solicitadas, comparando com as últimas execuções feitas e dispara a arquitetura solicitada para seu cloud provider. Como fica a estrutura de um projeto Pulumi ? Dentro de um projeto, o Pulumi se divide em Projeto e Stack. O projeto é a pasta onde você armazenará todas as configurações que você irá implementar em conjunto com o arquivo Pulumi.yaml. Esse arquivo é responsável por representar as informações básicas do projeto e em qual linguagem iremos trabalhar name: my-project runtime: name: nodejs options: typescript: false Exemplo de Pulumi para Node.js Outro ponto interessante é que o Pulumi tem nativamente o controle de Projetos e “ambientes” que chamamos de Stack. Diferentemente do Terraform, que é necessário o uso do Terragrunt para gerenciar complexidades de ambientes, o Pulumi vem com a solução nativa. Esses ambientes são chamados de “stack” e isolam completamente a sua execução para diferentes ambientes. Comandos básicos para usar o Pulumi Os comandos básicos que você utilizará no dia a dia serão os seguintes: pulumi new: Cria um novo projeto pulumi pulumi stack: Administra as stacks pulumi config: Configuração de variáveis e chaves e qualquer outro atributo nesse sentido. pulumi up: Faz o deploy das configurações solicitadas pulumi preview: Apresenta o que será publicado antes de ser aplicado pulumi destroy: Destrói toda infra estrutura solicitada Para aprofundar na lista de comandos do Pulumi, acesse a lista de comandos oficiais: https://www.pulumi.com/docs/cli/ Bora testar na prática? Todo exemplo utilizado está localizado aqui. Nele vamos criar uma instância de Cloud Run na GCP apontando para uma imagem Docker previamente publicada. Primeiro, ao executar o comando pulumi new, nosso terminal irá apresentar alguns questionamentos sobre nome do projeto, descrição e o nome da stack que usaremos para criar esse recurso dentro do projeto. No final da execução, teremos a estrutura de pastas seguindo essa lógica. No arquivo index.js, colocamos todo o código responsável por executar a criação de uma cloud-run. const pulumi = require(“@pulumi/pulumi”); const gcp = require(“@pulumi/gcp”); const _default = new gcp.cloudrun.Service(“default”, { name: “cloudrun-srv”, location: “us-central1”, template: { spec: { containers: [{ image: “gcr.io/toolbox-sandbox-388523/flask-app:latest”, }], }, }, }); const noauth = gcp.organizations.getIAMPolicy({ bindings: [{ role: “roles/run.invoker”, members: [“allUsers”], }], }); const noauthIamPolicy = new gcp.cloudrun.IamPolicy(“noauth”, { location: _default.location, project: _default.project, service: _default.name, policyData: noauth.then(noauth => noauth.policyData), }); // Export the status of the created Cloud Run service exports.grun = _default.status; Em seguida, executaremos o comando pulumi up para criar a nova infra estrutura. E pronto! Nossa API está criada! Se executarmos uma requisição HTTP, veremos o resultado: Acelere a sua carreira A Mentoria DevOps é um programa de mentoria de 12 meses com encontros semanais ao vivo, com um grupo seleto e restrito, onde estaremos do seu lado para mantê-lo relevante e atualizado no mercado de tecnologia, aprendendo e implementando as melhores práticas e ferramentas de DevOps. Clique aqui para entrar na prioridade pela melhor oferta de lançamento Conclusão Pulumi pode se tornar uma ótima opção para desenvolvedores e testadores de software se aventurarem, essa ferramenta tenta abstrair as dificuldades do mundo Ops com o atrativo de usar sua linguagem de programação preferida, além de uma comunidade ativa e um repositório de códigos prontos para você praticar.
MELT: Os pilares da Observabilidade
Observar sistemas é mais do que uma necessidade, é uma arte que distingue os verdadeiros heróis da engenharia de software.