# Tech Preta Texto integral dos posts publicados de Natália Granato (https://nataliagranato.xyz). Idioma: pt-BR. ## História e Evolução da Engenharia de Plataforma - URL: https://nataliagranato.xyz/blog/historia-evolucao-engenharia-de-plataforma - Data: 2026-03-21T00:00:00.000Z - Resumo: A Engenharia de Plataforma não surgiu do nada; ela é uma resposta aos desafios crescentes no desenvolvimento de software, o aumento da complexidade, a necessidade cada vez maior de agilidade para entregar novas funcionalidades ao usuário final de algum serviço interno ou externo, a complexidade da infraestrutura, etc. - Tags: platform, sre, devops A Engenharia de Plataforma não surgiu do nada; ela é uma resposta aos desafios crescentes no desenvolvimento de software: o aumento da complexidade, a necessidade cada vez maior de agilidade para entregar novas funcionalidades ao usuário final de algum serviço interno ou externo, a complexidade da infraestrutura etc. Um longo caminho foi percorrido até chegarmos até aqui. Por volta do final dos anos 90 e início dos 2000, o cenário era dominado pelo "SysAdmin" ou administradores de sistemas, profissional que era central e atuava como único "guardião" dos sistemas, resultando em experiências ruins para desenvolvedores e operações. No modelo tradicional, os SysAdmin eram o único ponto de falha e controle para a maioria das configurações dos sistemas. Esse formato organizacional causava atritos constantes entre equipes de operações e de desenvolvimento, pois o trabalho era realizado de forma isolada, com objetivos diferentes, levando a experiências ruins para ambos os setores e ineficiência. Os desenvolvedores tinham que entregar algo novo ou corrigir um problema em seu código e, para isso, precisavam passar por "SysAdmins"; estes queriam manter a "estabilidade" do sistema. A simples criação de um usuário poderia demorar semanas. Ao longo do tempo, tornou-se insustentável esse modelo de organização e desenvolvimento, pois ambos atuavam com diferentes propósitos e objetivos, sem pensar no negócio. Administradores de sistemas estavam esgotados com tickets e a responsabilidade de manter tudo funcionando, e desenvolvedores cansados com a "burocracia" para realizar suas atividades. Essa realidade exigia uma nova abordagem para otimizar o desenvolvimento de software. ## Das Origens à Consolidação A jornada até a Engenharia de Plataforma pode ser visualizada através de marcos importantes: - **2001: Manifesto Ágil** Foco em maiores interações, maior colaboração e software funcional. Adoção de automações e scripts. - **2009-2010: Cultura DevOps** Resulta do trabalho em conjunto entre Desenvolvimento (Dev) e Operações (Ops), buscando eficiência e agilidade na entrega de softwares. Promovendo a integração entre equipes de desenvolvimento e TI, com automação de processos e responsabilidade compartilhada. Estabelece os pilares de Integração Contínua (CI) e Entrega Contínua (CD), com ênfase em "feedback rápido" e "falhe rápido", proporcionando agilidade para realizar o deploy ou corrigir problemas. Apesar dos benefícios, a realidade do DevOps evoluiu para algo complexo, onde os desenvolvedores continuavam sobrecarregados pela infraestrutura e ferramentas, visto que a cada dia surgia novas funcionalidades, ferramentas, vulnerabilidades; isso levou a uma carga cognitiva muito alta, levando novamente equipes inteiras a exaustão. - **2012-2020: A Era "Tudo Como Código" (Everything as Code)** Infraestrutura como Código (IaC), Configuração como Código. Mais automação. No entanto, gráficos mostram que a complexidade e o tempo de entrega aumentaram significativamente após a era DevOps e na era do "Tudo como Código". A proliferação de ferramentas (Terraform, Ansible, Docker, Kubernetes, Jenkins, Flux, Argo, Puppet, Chef) e artefatos de manutenção levou à "confusão de propriedade e fragmentação de ferramentas". - **2018-2019: O Nascimento da Engenharia de Plataforma** Em 2018, Evan Bottcher (Thoughtworks) deu nome ao que muitas organizações estavam construindo: uma Plataforma Digital (hoje conhecida como Plataforma Interna do Desenvolvedor - IDP), definindo-a como "uma fundação de APIs de autoatendimento, ferramentas, serviços, conhecimento e suporte, que são organizados como um produto interno atraente". A ideia de que plataformas devem ser tratadas como um produto tornou-se um aspecto fundamental. Em 2019, Matthew Skelton e Manuel Pais lançaram o livro "Team Topologies", que se tornou uma "bíblia da engenharia de plataforma". O livro aborda a equipe de plataforma e sua relação com o resto da organização de engenharia, propondo uma clara separação de preocupações e identificando antipadrões de DevOps. Os primeiros meetups de engenharia de plataforma começaram em Berlim em 2019. A Engenharia de Plataforma foi definida como a "disciplina de projetar e construir cadeias de ferramentas e fluxos de trabalho que possibilitam recursos de autoatendimento na era nativa da nuvem". ## 2020 - Hoje: Crescimento e Reconhecimento da Engenharia de Plataforma - **Março de 2020:** Spotify lança o Backstage como código aberto. - **2021:** O canal Slack da Comunidade de Engenharia de Plataforma é iniciado. - **2022:** Plataforma Engineering.org é lançada. - **2022:** O Gartner coloca a Engenharia de Plataforma em seu Hype Cycle. - **Outubro de 2022:** Gartner nomeia a Engenharia de Plataforma como uma das "Top Strategic Technology Trends para 2023". - **Novembro de 2022:** Humanitec publica o primeiro "State of Platform Engineering Report". - **2023:** A popularidade do Platform Engineering "disparou". A comunidade cresceu para mais de 20.000 membros ativos no Slack e mais de 20.000 membros em Meetups globais. - **2024:** A Engenharia de Plataforma "explodiu" na frente do Gartner, aparecendo em mais de 10 Hype Cycles diferentes e ganhando seu próprio Hype Cycle dedicado. - **Previsão para 2026:** O Gartner prevê que 80% das grandes organizações de engenharia de software terão equipes dedicadas de Engenharia de Plataforma. - **Previsão para 2028:** O mercado de ferramentas e serviços de Engenharia de Plataforma deve ultrapassar US$50 bilhões. ![Platform Engineering Overview](https://gleecus.com/wp-content/uploads/2024/01/Platform-Engineering-101-Enabling-Self-Service-Capabilities-for-Software-Development-Image.png) ## O Conceito Central de Platform Engineering A Engenharia de Plataforma é definida como a "prática de criar e manter plataformas de autoatendimento que abstraem a complexidade da infraestrutura, permitindo que os desenvolvedores provisionem e gerenciem recursos de maneira simples". Em termos mais simples, é a "arte de juntar tudo isso, com um 'tempero' a mais: CI/CD, Infraestrutura como Código, Automação". Seu objetivo principal é permitir que os desenvolvedores se concentrem na entrega de valor ao cliente, enquanto os desafios de infraestrutura e operações são resolvidos de forma centralizada. Isso é alcançado através de um produto integrado, frequentemente referido como Plataforma Interna do Desenvolvedor (IDP). As IDPs são projetadas para: - Orientar os desenvolvedores através de "caminhos dourados" (golden paths) e "estradas pavimentadas" que correspondem ao nível de abstração preferido do desenvolvedor individual. - Fornecer uma interface de autoatendimento onde o desenvolvedor solicita um novo projeto, e uma série de automações criam um "esqueleto" com tudo pré-existente (infraestrutura, pipelines, manifestos). - Consolidar e simplificar os elementos do processo de desenvolvimento, tornando o trabalho diário mais gerenciável, eficiente e colaborativo. - Centralizar o conhecimento especializado em todo o ciclo de vida de desenvolvimento e operações. ## Tendências de Mercado Atuais O campo da Engenharia de Plataforma está em constante evolução, com várias tendências moldando seu futuro: - **Plataforma como Produto (Platform as a Product):** Essa é uma tendência fundamental e um dos conceitos mais importantes. Significa que a equipe de plataforma trata os desenvolvedores como seus clientes internos, realizando pesquisa de usuário, definindo roteiros de produto, medindo métricas de uso e realizando marketing interno para garantir a adoção e o alinhamento com a liderança. - **Engenharia de Plataforma de Infraestrutura (Infrastructure Platform Engineering - IPE):** Uma subdisciplina crucial que se concentra em transformar a infraestrutura em um produto de autoatendimento, melhorando a eficiência, automação e segurança. O Gartner prevê que mais de 75% das empresas Fortune 1000 terão organizações formais de IPE até 2027. Isso é visto como a construção de uma "máquina de venda automática" de "produtos" de infraestrutura. - **Orquestradores de Plataforma (Platform Orchestrators):** Termo novo no mercado que tem o potencial de substituir ferramentas como Terraform e Ansible. Eles são vistos como o "elo que faltava" que complementa os portais de desenvolvedores e faz a ponte para a engenharia de plataforma de infraestrutura. - **Modelos de Maturidade da Engenharia de Plataforma:** Estruturas como o modelo de maturidade da CNCF TAG App Delivery fornecem um roteiro para as organizações avaliarem suas capacidades e planejarem melhorias em áreas como investimento, adoção, interfaces, operações e medição. - **Ambientes de Desenvolvimento na Nuvem (Cloud Development Environments - CDEs):** Uma nova categoria que visa aprimorar a produtividade do desenvolvedor, melhorar a segurança e apoiar a conformidade. - **Automação e Padronização:** Continuam sendo os principais impulsionadores da engenharia de plataforma. - **Uso de IA/ML:** A IA está sendo gradualmente integrada à engenharia de plataforma, com 52,40% dos engenheiros de plataforma usando IA "um pouco" e 13,20% usando "extensivamente". A expectativa é que a IA e o ML otimizem e automatizem tarefas complexas, prevejam falhas e personalizem experiências de desenvolvimento. - **Backends baseados em Gráficos (Graph-based backends):** Vistos como mais flexíveis e escaláveis para orquestração de plataformas, em contraste com os baseados em pipeline. - **SaaS e Nuvem como "Commodity":** Grandes empresas tendem a transformar suas plataformas internas em produtos (PaaS). O futuro prevê a infraestrutura completamente abstraída, com a nuvem sendo um "mero detalhe" em um cenário multi-cloud. ## O Crescimento e Importância da Engenharia de Plataforma em Empresas de Tecnologia A Engenharia de Plataforma está se consolidando como a espinha dorsal da produtividade do desenvolvedor e da melhoria da experiência do desenvolvedor (DevEx). ### Impacto no Negócio - Acelera o tempo de colocação de produtos no mercado e o ritmo da inovação. - Reduz custos operacionais através de processos mais eficientes e automatizados, otimizando recursos. Empresas relatam reduções de até 50% no tempo de lançamento de produtos e 30% no tempo de configuração/manutenção. - Melhora a segurança e conformidade. - Aumenta a agilidade dos negócios e permite adaptação rápida às mudanças do mercado. - Impulsiona o crescimento da receita ao acelerar a entrega de produtos e serviços inovadores. - É vista como crucial para o sucesso da transformação digital. - Gartner prevê que é essencial para desbloquear todo o potencial de negócios da IA. ### Impacto nos Desenvolvedores e Equipes - Aumenta a produtividade do desenvolvedor ao simplificar a gestão de infraestrutura e automatizar tarefas repetitivas. - Reduz a sobrecarga cognitiva e o trabalho manual, permitindo que os desenvolvedores se concentrem na escrita de código e na inovação. - Promove o autoatendimento para desenvolvedores, eliminando "TicketOps" (dependência de solicitações manuais). - Melhora a satisfação e retenção de talentos de engenharia, criando um ambiente de trabalho moderno e eficiente. A menor rotatividade é uma métrica importante de sucesso. - As equipes de plataforma atuam como educadores, testando e mostrando as soluções mais úteis aos desenvolvedores. ### Adoção e Projeções - Não é exclusiva de grandes empresas; mesmo empresas menores podem se beneficiar. Recomenda-se considerar uma IDP para organizações com mais de 20-30 desenvolvedores. - O papel dos engenheiros de plataforma é uma função em ascensão (bleeding-edge role), com salários que, em média, são mais altos do que os de especialistas em DevOps (26,6% a mais na América do Norte, 22,78% na Europa). - Em 2024, o GitHub é o sistema de controle de versão mais usado (56% dos entrevistados), seguido por GitLab (31%) e Bitbucket (17%). - A Engenharia de Plataforma é um investimento no futuro. ## Casos de Sucesso em Empresas que Utilizam Platform Engineering A Engenharia de Plataforma tem sido adotada e demonstrado valor significativo em diversas empresas: - **Netflix:** Construiu uma plataforma interna robusta sobre Kubernetes e arquitetura de microserviços. Isso permitiu que seus desenvolvedores se concentrassem na inovação, enquanto a plataforma cuidava da escalabilidade, monitoramento e automação. O sucesso da Netflix em fornecer uma experiência de streaming perfeita para milhões é um testemunho do poder da Engenharia de Plataforma. - **Spotify:** Criou o Backstage, um framework de código aberto para a construção de Portais Internos de Desenvolvedores (IDPs), que foi doado à CNCF. Mais de 3.000 empresas já adotaram o Backstage para construir seus próprios IDPs. As 700 equipes de P&D do Spotify dependem do Backstage diariamente. O Spotify agora está expandindo para um negócio de software empresarial com o "Spotify Portal for Backstage". O Backstage domina o mercado de portais de desenvolvedores, e sua força reside no sucesso de uma solução de código aberto. - **American Airlines, T-Mobile, DoorDash, Brex, Expedia Group, Unity, Zalando:** Essas são algumas das 100+ empresas publicamente listadas que adotaram o Backstage. A experiência da Brex é um exemplo notável, mostrando a importância de pesquisas com desenvolvedores para identificar problemas reais e garantir que o investimento na IDP seja eficaz, evitando construir uma "solução em busca de um problema". A adição de um sistema de scorecard/checagem em IDPs existentes, que pontua as equipes com base em boas práticas, surpreendentemente impactou mais o engajamento dos desenvolvedores, incentivando a melhoria contínua. - **Google:** A Google, com sua filosofia de "foco no usuário", acredita que as plataformas são, antes de tudo, um produto e que o foco em seus usuários é fundamental. Equipes que se concentram no usuário têm 40% maior desempenho organizacional. O Google Cloud ajuda a aumentar a produtividade do desenvolvedor, melhorar a confiabilidade e a segurança, e acelerar o tempo de lançamento no mercado através da engenharia de plataforma. - **Nike e Politiet:** Em outubro de 2022, o Gartner destacou que as plataformas nessas organizações permitiram respostas mais rápidas a mudanças, aceleração do tempo de lançamento no mercado e inovação mais rápida. - **Outras Empresas (Generalizado):** Empresas que adotam engenharia de plataforma podem ter equipes com menos de 20 pessoas, suportando milhares de desenvolvedores e centenas de projetos. Elas relatam reduções significativas no tempo de lançamento de novos produtos digitais (até 50%) e no tempo gasto em tarefas de configuração e manutenção (até 30%). ## Modelo de Maturidade de Engenharia de Plataforma - URL: https://nataliagranato.xyz/blog/mode-maturidade-platform-eng - Data: 2026-03-21T00:00:00.000Z - Resumo: A Engenharia de Plataforma (Platform Engineering) é uma disciplina que tem ganhado destaque no cenário tecnológico atual, focando na criação e manutenção de plataformas de autoatendimento que abstraem a complexidade da infraestrutura, permitindo que os desenvolvedores provisionem e gerenciem recursos de maneira simples. - Tags: platform, maturity, cncf # Modelo de Maturidade de Platform Engineering A Engenharia de Plataforma (Platform Engineering) é uma disciplina que tem ganhado destaque no cenário tecnológico atual, focando na criação e manutenção de plataformas de autoatendimento que abstraem a complexidade da infraestrutura, permitindo que os desenvolvedores provisionem e gerenciem recursos de maneira simples. Trata-se de uma evolução natural do DevOps, visando otimizar a produtividade dos desenvolvedores e acelerar o tempo de entrega de valor ao negócio. Gartner prevê que, até 2026, 80% das grandes organizações de engenharia de software terão equipes dedicadas à Engenharia de Plataforma. Para entender e avaliar a evolução de uma organização nesse campo, a Cloud Native Computing Foundation (CNCF) desenvolveu um Modelo de Maturidade de Platform Engineering. Este modelo não é uma fórmula rígida, mas um framework para guiar organizações em sua jornada de Platform Engineering, ajudando-as a identificar onde estão e para onde podem evoluir. ## Detalhamento dos Níveis de Maturidade O modelo da CNCF categoriza a maturidade da Platform Engineering em quatro níveis principais, avaliados em dimensões como Investimento, Adoção, Interfaces, Operações e Medição. ### Provisional (Provisório) Neste estágio inicial, as soluções de plataforma são ad-hoc e criadas por necessidade imediata, sem um investimento dedicado ou planejamento formal. #### Investimento É voluntário ou temporário; as capacidades são construídas e mantidas por equipes "tigres" ou indivíduos designados temporariamente, sem financiamento central ou planejamento de longo prazo. Há queixas de burnout e frustração. #### Adoção É errática e inconsistente. Não há uma estratégia organizacional clara, e as equipes podem preferir usar ferramentas externas em vez das soluções internas. #### Interfaces Utilizam processos personalizados e não padronizados, muitas vezes dependendo de intervenção manual e suporte profundo dos provedores. O conhecimento é compartilhado de pessoa para pessoa. #### Operações São baseadas em solicitações (by request); as plataformas e capacidades são desenvolvidas e atualizadas de forma reativa. A responsabilidade pela manutenção é informal. #### Medição É ad hoc, com métricas de uso e satisfação coletadas de forma inconsistente, se é que são coletadas. As decisões são baseadas em dados anedóticos e incompletos. ### Operationalized (Operacionalizado) Neste nível, a organização reconhece o valor das plataformas, e há uma equipe dedicada responsável por fornecer um conjunto de capacidades comuns para acelerar a entrega de software. #### Investimento Possui uma equipe dedicada com alocação de orçamento e pessoal. Essas equipes focam em atender a requisitos técnicos reativos e são frequentemente vistas como centros de custo, dificultando a medição de seu impacto direto. A maioria das organizações (43.28%) se encontra neste nível. #### Adoção É impulsionada por um "extrinsic push" (impulso externo), com diretrizes internas incentivando ou exigindo o uso de serviços da plataforma. #### Interfaces Utilizam ferramentas padronizadas e caminhos dourados (golden paths) na forma de documentação e templates. Ainda assim, soluções podem exigir expertise de domínio profundo e suporte dos mantenedores. #### Operações São rastreadas centralmente com algum grau de organização. Há expectativas para coletar dados de uso e feedback, embora a tradução em ações seja um desafio. #### Medição Foca na coleta consistente de feedback estruturado dos usuários, mas a organização pode ter dificuldade em integrar efetivamente esse feedback no roadmap da plataforma. ### Scalable (Escalável) Neste estágio, a plataforma é tratada como um produto interno, com foco explícito em usabilidade, automação e eficiência. Os usuários são atraídos pelo valor intrínseco da plataforma. #### Investimento É como o investimento em um produto (as product), baseado no valor esperado para os clientes internos. A gestão de produto e a experiência do usuário são explicitamente consideradas. Há uso de dados para alocar fundos e pessoal, otimizando o negócio e contribuindo para a rentabilidade. Cerca de 35.71% das organizações estão aqui. #### Adoção É por "intrinsic pull" (atração intrínseca); os usuários escolhem a plataforma por seu valor claro em reduzir a carga cognitiva e fornecer serviços de alta qualidade. #### Interfaces Oferecem soluções de autoatendimento, dando autonomia aos usuários com pouco suporte dos mantenedores. Há consistência nas interfaces, facilitando a descoberta e portabilidade da experiência do usuário. #### Operações São centralmente habilitadas, com as equipes de plataforma compreendendo as necessidades da organização e priorizando o trabalho. Existem processos padronizados para contribuição de novas capacidades e contínuos delivery. #### Medição Gera insights que vão além da mera coleta de dados, focando em medidas de confiabilidade e estabilidade do serviço. As decisões são impulsionadas por dados e feedback, visando melhorias antes que os problemas causem frustração. ### Optimizing (Otimizado) No nível mais alto, a plataforma está totalmente integrada ao ecossistema da empresa, com melhorias contínuas, automação e autonomia para os times de produto. O foco é na otimização de toda a organização. #### Investimento Resulta em um ecossistema habilitado, onde as equipes de plataforma otimizam o time-to-market, reduzem custos, permitem governança e conformidade eficientes, e escalam cargas de trabalho. Apenas 12.18% das organizações alcançaram este nível. #### Adoção É participativa, indicando que a cultura da organização está totalmente alinhada com o uso da plataforma. #### Interfaces Oferecem serviços integrados de forma nativa e coesa. #### Operações São serviços gerenciados, onde o ciclo de vida de cada capacidade é automatizado e padronizado. As atualizações são contínuas, sem impacto para os usuários, com um modelo claro de responsabilidade compartilhada. #### Medição É quantitativa e qualitativa, profundamente integrada à cultura da organização. Há uma democratização dos dados, e os stakeholders estão ativamente envolvidos na identificação e medição de melhorias. O foco está em métricas de liderança (leading measures) para antecipar necessidades. ![Modelo de Maturidade de Platform Engineering](https://substackcdn.com/image/fetch/$s_!-Sp9!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F6fbaccac-2d71-44fb-bbc4-4de12e939b92_1444x888.png) ## Estratégias de Evolução para Cada Estágio A evolução de um estágio para o outro exige intencionalidade e planejamento. A chave é adotar uma mentalidade de produto, tratando os desenvolvedores como clientes e buscando resolver suas dores de forma incremental. ### Para sair do Provisório O primeiro passo é reconhecer os problemas e a necessidade de uma solução. É fundamental formar uma equipe dedicada para a plataforma e estabelecer uma missão clara para ela, evitando que seja vista apenas como um help desk. Comece com um Produto Mínimo Viável (MVP) ou Plataforma Viável Mais Fina (TVP), focando nas dores mais comuns dos desenvolvedores. ### Para ir do Operacionalizado ao Escalável A plataforma deve começar a ser tratada como um produto, com foco em user research para entender as reais necessidades dos desenvolvedores e implementar feedback loops eficazes. Invista em interfaces de autoatendimento para empoderar os desenvolvedores, reduzindo gargalos e dependência de equipes de operações. Padronize e automatize o máximo possível, desde o provisionamento de infraestrutura até os pipelines de CI/CD. ### Para alcançar o Otimizado O foco deve ser em escalar e otimizar o produto para muitos usuários e equipes. Isso envolve a integração da plataforma ao ecossistema da empresa, permitindo que especialistas (como segurança, desempenho) estendam as capacidades da plataforma. A automação precisa ser abrangente, com o ciclo de vida das capacidades gerenciado de forma padronizada e automática, garantindo melhorias contínuas sem impacto para os usuários. A utilização de IA e Machine Learning no futuro pode potencializar ainda mais essa otimização, prevendo falhas e automatizando tarefas complexas. ## Como Avaliar a Maturidade de uma Organização A avaliação da maturidade não visa classificar uma organização como um único nível, mas sim identificar as características presentes em cada aspecto para entender oportunidades de melhoria. ### Reflexão e Autoavaliação O modelo da CNCF serve como um guia para a autoavaliação, ajudando as equipes a refletirem sobre suas práticas atuais em cada uma das cinco dimensões (Investimento, Adoção, Interfaces, Operações, Medição). ### Mapeamento e Identificação Compare as características da sua organização com as descrições de cada nível. É comum que uma organização apresente características de diferentes níveis em diferentes aspectos. ### Foco em Melhoria Contínua O verdadeiro valor da avaliação não é o nível alcançado, mas a lista de ações para melhoria. Assegure-se de que a evolução seja um processo contínuo, adaptando-se às necessidades do projeto, organização e momento. ### Uso de Métricas Colete dados quantitativos e qualitativos. ## Impacto da Maturidade nos Resultados de Negócio A maturidade em Platform Engineering tem um impacto direto e significativo nos resultados de negócio de uma organização: - **Aceleração da Entrega de Valor:** Plataformas maduras permitem que as empresas lancem produtos e funcionalidades mais rapidamente no mercado. O foco na abstração da infraestrutura permite que os desenvolvedores se concentrem na inovação. - **Aumento da Produtividade e Eficiência:** Reduz a carga cognitiva dos desenvolvedores, elimina o ticket ops e automatiza tarefas repetitivas, liberando as equipes para trabalhos de maior valor agregado. A Siemens, por exemplo, alcançou uma proporção de 20 desenvolvedores para 1 engenheiro de plataforma, demonstrando ganhos notáveis em eficiência e velocidade. - **Redução de custos:** A padronização, automação e gestão eficiente de recursos levam à otimização de custos operacionais e de infraestrutura. A automação de provisionamento de bancos de dados pode, por exemplo, gerar economias substanciais. - **Melhora na Qualidade e Segurança:** A incorporação de security by design e a padronização de ambientes e ferramentas desde o início reduzem riscos, vulnerabilidades e garantem conformidade com regulamentações. - **Atração e Retenção de Talentos:** Um ambiente de desenvolvimento moderno e eficiente é mais atraente para profissionais de alto nível, reduzindo a rotatividade (attrition). Engenheiros de plataforma, em média, recebem salários mais altos do que seus colegas DevOps, refletindo a demanda por suas habilidades especializadas. - **Resiliência e Adaptação:** A Platform Engineering cria uma base robusta que permite às empresas se adaptarem rapidamente às mudanças do mercado e às demandas dos clientes. Incidentes e erros se transformam em oportunidades de melhoria contínua da plataforma. Em suma, a Engenharia de Plataforma não é apenas uma tendência tecnológica, mas um catalisador de inovação que transforma a forma como o software é desenvolvido e entregue, resultando em benefícios tangíveis para o negócio e posicionando a organização de forma mais competitiva no mercado digital. ## Docker Offload: Acelerando o desenvolvimento e democratizando a construção de containers - URL: https://nataliagranato.xyz/blog/docker-offload - Data: 2025-08-09T00:00:00.000Z - Resumo: O Docker Offload é uma funcionalidade do Docker Desktop que permite o uso de recursos computacionais superiores na nuvem para executar builds e containers - Tags: containers, docker, devops ## O Que é Docker Offload? O Docker Offload é uma funcionalidade do Docker Desktop que permite o uso de recursos computacionais superiores na nuvem para executar builds e containers. Antes de escrever esse artigo experimentei o Offload e realizei um teste comparativo entre o build com ele e o local. O projeto está [disponível](https://github.com/Tech-Preta/docker-offload) no Github. ![docker-offload](https://www.docker.com/app/uploads/2024/12/2400x1260_docker-evergreen_logo_blog_D-1536x806.png) Ele é especialmente útil em cenários como: - **Builds complexos:** Para projetos com muitas dependências, onde o tempo de compilação é um desafio. - **Tarefas intensivas:** Ideal para Inteligência Artificial (IA), Machine Learning (ML) e processamento de grandes volumes de dados. - **Hardware limitado:** Permite que desenvolvedores com computadores ou máquinas virtuais mais simples acessem poder de processamento de ponta. - **Equipes distribuídas:** Facilita o compartilhamento de cache de builds, agilizando o trabalho colaborativo. --- ## Vantagens Principais ### Performance Superior Com o Docker Offload, você tem acesso a: - **Hardware de ponta:** CPUs mais rápidas, maior quantidade de RAM e, crucialmente, GPUs disponíveis para cargas de trabalho que dependem de processamento gráfico. - **Builds paralelos:** Execute múltiplos builds simultaneamente sem comprometer o desempenho. - **Cache inteligente:** O cache de builds é compartilhado entre os desenvolvedores, o que acelera significativamente os processos para toda a equipe. - **Otimizações nativas:** O motor Docker na nuvem é otimizado para extrair o máximo de performance. ### Democratização do Desenvolvimento O Docker Offload torna o desenvolvimento de alta performance acessível a todos: - **Acesso universal:** Qualquer desenvolvedor pode utilizar hardware de ponta, independentemente do seu equipamento local. - **Sem investimento inicial:** Não há necessidade de comprar hardware caro e robusto. - **Escalabilidade:** Os recursos da nuvem se ajustam à sua demanda, crescendo conforme a necessidade do projeto. - **Flexibilidade:** Pague apenas pelo que usar, otimizando custos. ### Aceleração do Desenvolvimento e Testes de IA/ML Este é um dos grandes destaques do Docker Offload para o universo de Inteligência Artificial e Machine Learning: - **GPU disponível:** Treine modelos complexos sem a exigência de uma GPU local. - **Processamento paralelo:** Execute múltiplas instâncias de treinamento ou processamento de dados simultaneamente. - **Cache de modelos:** Reutilize modelos pré-treinados e camadas de dependência de forma eficiente. - **Ambiente padronizado:** Garanta que toda a equipe de IA/ML esteja trabalhando no mesmo ambiente otimizado, eliminando inconsistências. --- ## Benefícios para Equipes A colaboração é significativamente aprimorada: - **Cache compartilhado:** Builds mais rápidos para todos, reduzindo o tempo de espera. - **Ambiente consistente:** Garante que todos os membros da equipe estejam utilizando o mesmo hardware e configurações, minimizando erros. - **Colaboração aprimorada:** Menos problemas de "funciona na minha máquina", pois o ambiente de build é padronizado. - **Onboarding acelerado:** Novos desenvolvedores se tornam produtivos mais rapidamente, sem a necessidade de configurações complexas de ambiente. --- ## Como Funciona A arquitetura do Docker Offload é intuitiva: ``` ┌─────────────────┐ ┌──────────────────┐ ┌─────────────────┐ │ Seu Computador │ │ Docker Cloud │ │ Resultados │ │ │ │ │ │ │ │ • Interface │◄──►│ • Build Engine │◄──►│ • Containers │ │ • Docker CLI │ │ • Cache Shared │ │ • Images │ │ • Local Config │ │ • High-end HW │ │ • Artifacts │ └─────────────────┘ └──────────────────┘ └─────────────────┘ ``` O fluxo de execução é simples: 1. **Comando Local:** Você executa `docker build` ou `docker run` no seu terminal. 2. **Análise:** O Docker Desktop identifica se a tarefa se beneficia do offload para a nuvem. 3. **Transferência:** O contexto do seu projeto e o Dockerfile são enviados de forma segura para a nuvem. 4. **Execução:** O build ou o container é executado no ambiente de alta performance na nuvem. 5. **Resultado:** A imagem ou o artefato final é retornado para o seu ambiente local. --- ## Caso de Estudo: Testes Reais Para medir o impacto prático do Docker Offload utilizei um cenário sintético, focado puramente em CPU. A ideia foi isolar o ganho no tempo de build e execução de uma carga determinística, evitando interferências de rede, disco ou I/O externo. ### Carga Sintética (heavy_task.py) A carga é um loop matemático intensivo que: - Executa N iterações (ITERATIONS, default 100_000_000). - Mantém tudo em memória (sem I/O). - Usa recorrência trigonométrica (atualização de sin(i) e cos(i)) para evitar chamadas repetidas a funções mais custosas do módulo math. - Produz um resultado acumulado (result) apenas para impedir otimizações agressivas. - Mede somente o tempo de CPU (time.time() no início e fim). - Indica o ambiente de execução (local ou Offload) via variável de ambiente DOCKER_OFFLOAD_ACTIVE. Trecho central da função: ```python def run_heavy_computation(iterations): sin_i, cos_i = 0.0, 1.0 sin_1, cos_1 = math.sin(1), math.cos(1) for i in range(iterations): result += sin_i * cos_i / (math.sqrt(i + 1)) sin_i, cos_i = sin_i * cos_1 + cos_i * sin_1, cos_i * cos_1 - sin_i * sin_1 ``` Características desejadas: - CPU-bound puro (ideal para evidenciar diferenças de build e execução). - Determinístico (mesmo resultado dado o número de iterações). - Escalável (basta aumentar ITERATIONS para intensificar a carga). - Reprodutível em qualquer máquina com Python. ### Objetivo do Caso 1. Comparar tempo total (build + execução) local vs Offload. 2. Verificar se o ganho principal está no build (camadas + dependências) ou na execução da carga. 3. Validar consistência (sem cache prévio injusto). ### Reprodutibilidade Dockerfile simplificado (exemplo): ```dockerfile FROM python:3.12-slim WORKDIR /app COPY heavy_task.py . ENV PYTHONUNBUFFERED=1 ENTRYPOINT ["python", "heavy_task.py"] ``` Build local: ```bash docker build -t offload-test:local . docker run --rm -e ITERATIONS=100000000 offload-test:local ``` Build usando Offload (no Docker Desktop com Offload habilitado): ```bash docker build -t offload-test:offload . docker run --rm -e ITERATIONS=100000000 -e DOCKER_OFFLOAD_ACTIVE=1 offload-test:offload ``` ### Metodologia de Testes A [metodologia](https://github.com/Tech-Preta/docker-offload/blob/main/docs/METODOLOGIA.md) garantiu que não houvesse vantagens artificiais, eliminando o cache antes e entre os testes, e controlando explicitamente o ambiente: - Limpeza de cache antes de cada build. - Mesma configuração de rede e sem interferência de volumes externos. - Repetição de execuções para estabilizar variação (descarte de outliers). - Registro automatizado de tempos (build e execução) para comparação objetiva. --- ## Resultados Comprovados Os resultados foram claros: | Cenário | Tempo Total | Performance | | -------------- | -------------- | ------------------ | | Docker Local | 66.62 segundos | Linha de base | | Docker Offload | 54.66 segundos | 17% mais rápido 🎉 | A principal vantagem do Docker Offload reside na otimização do processo de build, que é onde a economia de tempo é mais perceptível. --- ## Cenários Ideais para Docker Offload O Docker Offload é uma ferramenta poderosa para: - **Desenvolvimento de IA/ML:** Permite o uso de GPUs na nuvem para treinamento e execução de modelos, sem a necessidade de hardware especializado localmente. - **Builds Complexos:** Ideal para projetos com muitas dependências, onde o tempo de build pode ser um gargalo. - **Hardware Limitado:** Ótima solução para desenvolvedores com laptops ou VMs de menor capacidade. - **Equipes Distribuídas:** Garante um ambiente de desenvolvimento consistente e acelera os builds para todos através do cache compartilhado. - **Pipelines de CI/CD:** Pode ser integrado para acelerar os builds em ambientes de Integração Contínua e Entrega Contínua. --- ## Conclusão O Docker Offload é mais do que uma simples funcionalidade; é uma mudança fundamental na forma como o desenvolvimento de software é abordado. Ele democratiza o acesso a recursos computacionais de ponta, acelera significativamente processos de build e testes, especialmente em áreas como IA/ML, e otimiza a colaboração em equipes. Nossos testes comprovam uma melhoria real de 17% no tempo total, sem vantagens artificiais, confirmando que os ganhos são genuínos e se traduzem em maior produtividade. Para desenvolvedores e equipes que buscam eficiência, agilidade e acesso a recursos de alto desempenho sem o custo de investimento em hardware, o Docker Offload se mostra uma ferramenta essencial capaz de transformar a experiência de desenvolvimento. ### Referências - [Docker Build Cloud Documentation](https://docs.docker.com/build/cloud/) - [Docker Desktop Features](https://www.docker.com/products/docker-desktop/) - [Docker Build Best Practices](https://docs.docker.com/develop/dev-best-practices/) ## Otimizando e Corrigindo Vulnerabilidades com Docker Scout - URL: https://nataliagranato.xyz/blog/docker-scout - Data: 2025-06-26T00:00:00.000Z - Resumo: O Docker Scout é uma ferramenta poderosa para otimizar imagens Docker e corrigir vulnerabilidades de segurança. Neste artigo, vamos explorar como utilizá-lo para melhorar a segurança e eficiência das suas aplicações. - Tags: devops, security # Conhecendo o Docker Scout O Docker Scout se tornou uma ferramenta fundamental no meu dia a dia de trabalho, principalmente pela possibilidade de otimizar imagens, identificar rapidamente vulnerabilidades e corrigir rapidamente problemas de segurança, tudo isso pelo terminal, de forma simples e rápida. Você também pode utilizar na console do Docker Hub, no Docker Desktop ou no Gitlab CI e GitHub Actions. Antes de mostrar como instalar e utilizar o Docker Scout, vamos relembrar alguns conceitos importantes sobre imagens Docker e vulnerabilidades de segurança. Quando construímos uma imagem de container, ela utiliza uma série de camadas, é uma boa prática reduzir ao máximo o número de camadas e dependências desnecessárias, pois isso não só reduz o tamanho da imagem, mas também minimiza a superfície de ataque, tornando a aplicação mais segura. Podemos utilizar o chamado `multi-stage build` para criar imagens mais enxutas, onde apenas os artefatos necessários são mantidos na imagem final ou até mesmo usar soluções como o `distroless`, que cria imagens sem um sistema operacional completo, reduzindo ainda mais o tamanho e a superfície de ataque. Porém, mesmo com essas práticas, é comum que imagens ainda contenham vulnerabilidades de segurança, como dependências desatualizadas, uma vulnerabilidade nova relacionada a alguma biblioteca e etc. É aí que entra o Docker Scout. ![Docker Scout](https://www.docker.com/app/uploads/2024/10/2400x1260_generic-scout-blog_d-1110x583.png) ### Software Bill of Materials (SBOM) O Software Bill of Materials (SBOM) é uma lista detalhada de todos os componentes de software, incluindo bibliotecas e dependências, que compõem uma aplicação. O Docker Scout gera um SBOM automaticamente durante a análise da imagem, facilitando a identificação de componentes vulneráveis e a aplicação de correções. Existem banco de dados de vulnerabilidades, como o NVD (National Vulnerability Database), que são utilizados pelo Docker Scout para identificar problemas conhecidos nas dependências. Aqui https://docs.docker.com/scout/deep-dive/advisory-db-sources/ você pode ver as fontes de dados de vulnerabilidades utilizadas pelo Docker Scout. ### Instalação do Docker Scout Para instalar o Docker Scout, você pode usar o seguinte comando: ```bash curl -fsSL https://raw.githubusercontent.com/docker/scout-cli/main/install.sh -o install-scout.sh sh install-scout.sh ``` Agora você pode verificar se a instalação foi bem-sucedida e ver as opções disponíveis com o comando: ```bash docker scout ``` A saída deve ser algo como: ``` Available Commands attestation Manage attestations on images cache Manage Docker Scout cache and temporary files compare Compare two images and display differences (experimental) config Manage Docker Scout configuration cves Display CVEs identified in a software artifact enroll Enroll an organization with Docker Scout environment Manage environments (experimental) help Display information about the available commands integration Commands to list, configure, and delete Docker Scout integrations policy Evaluate policies against an image and display the policy evaluation results (experimental) push Push an image or image index to Docker Scout quickview Quick overview of an image recommendations Display available base image updates and remediation recommendations repo Commands to list, enable, and disable Docker Scout on repositories version Show Docker Scout version information watch Watch repositories in a registry and push images and indexes to Docker Scout (experimental) ``` Agora vamos fazer uma análise de uma imagem que eu nao mantenho a mais de um ano, para ver o que o Docker Scout pode nos mostrar. ```bash docker scout quickview nataliagranato/rundeck-exporter:1 ``` Ele me mostrou o seguinte resultado: ``` ✓ Image stored for indexing ✓ Indexed 62 packages Target │ nataliagranato/rundeck-exporter:1 │ 3C 8H 13M 1L digest │ d83736b9c402 │ ℹ️ Base image was auto-detected. To get more accurate results, build images with max-mode provenance attestations. Review docs.docker.com ↗ for more information. ``` ### Análise de Vulnerabilidades | Componente | Nome | Critical | High | Medium | Low | | :----------------------- | :---------------------------------- | :------- | :----- | :----- | :---- | | **Target** | `nataliagranato/rundeck-exporter:1` | 3C | 8H | 13M | 1L | | Digest | `d83736b9c402` | | | | | | **Base image** | `python:3-alpine` | 3C | 8H | 8M | 0L | | **Refreshed base image** | `python:3-alpine` | 0C | 0H | 0M | 0L | | | _Redução de vulnerabilidades_ | **-3** | **-8** | **-8** | **0** | | **Updated base image** | `python:3-alpine3.21` | 0C | 0H | 0M | 0L | | | _Redução de vulnerabilidades_ | **-3** | **-8** | **-8** | **0** | **Legenda das vulnerabilidades:** - **C** = Critical (Críticas) - **H** = High (Altas) - **M** = Medium (Médias) - **L** = Low (Baixas) ### Analisando o Resultado O Docker Scout me mostrou que temos 3 vulnerabilidades críticas, 8 altas e 13 médias na imagem `nataliagranato/rundeck-exporter:1` e temos vulnerabilidades na imagem base `python:3-alpine` também. Mas além de dar visibilidade para as vulnerabilidades, ele mostra os próximos passos para resolver esses problemas. Algo como: ```bash What's next: View vulnerabilities → docker scout cves nataliagranato/rundeck-exporter:1 View base image update recommendations → docker scout recommendations nataliagranato/rundeck-exporter:1 ``` Com a opção de `docker scout cves`, você pode ver cada vulnerabilidade identificada, sua criticidade, em que versão ela foi corrigida, além de poder acessar um link com maiores detalhes, como os pacotes afetados. Use: ```bash docker scout cves nataliagranato/rundeck-exporter:1 ``` A saída será algo como: ``` 0C 0H 0M 1L certifi 2024.2.2 pkg:pypi/certifi@2024.2.2 ✗ LOW CVE-2024-39689 [Insufficient Verification of Data Authenticity] https://scout.docker.com/v/CVE-2024-39689 Affected range : >=2021.5.30 : <2024.7.4 Fixed version : 2024.7.4 25 vulnerabilities found in 9 packages CRITICAL 3 HIGH 8 MEDIUM 13 LOW 1 ``` Depois disso o Docker Scout te dará recomendações para corrigir os problemas encontrados, explicando os benefícios de cada ação. Isso fica a cargo de `docker scout recommendations`: ```bash docker scout recommendations nataliagranato/rundeck-exporter:1 ``` Vamos ver o que ele recomenda: ``` ## Recommended fixes Base image is python:3-alpine Name │ 3-alpine Digest │ sha256:c583b8590a197db1f6efece2dd244b0259cb6f82c4acc654bfbe48e00e20a7b9 Vulnerabilities │ 3C 8H 8M 0L Pushed │ 1 year ago Size │ 21 MB Packages │ 56 Flavor │ alpine OS │ 3.19 Runtime │ 3.12.3 │ The base image is also available under the supported tag(s) 3.12-alpine , alpine . If you want to display │ recommendations specifically for a different tag, please re-run the command using the --tag flag. Refresh base image Rebuild the image using a newer base image version. Updating this may result in breaking changes. Tag │ Details │ Pushed │ Vulnerabilities ───────────────────────────┼────────────────────────────────────────────────────────┼─────────────┼────────────────────────────── 3-alpine │ Benefits: │ 2 weeks ago │ 0C 0H 0M 0L Newer image for same tag │ • Same OS detected │ │ -3 -8 -8 Also known as: │ • Minor runtime version update │ │ • alpine │ • Newer image for same tag │ │ • alpine3.22 │ • Image is smaller by 3.7 MB │ │ • 3.13.5-alpine │ • Image contains 17 fewer packages │ │ • 3.13.5-alpine3.22 │ • Tag is preferred tag │ │ • 3.13-alpine │ • Tag was pushed more recently │ │ • 3.13-alpine3.22 │ • Image introduces no new vulnerability but removes 19 │ │ • 3-alpine3.22 │ • 3-alpine was pulled 51K times last month │ │ │ │ │ │ Image details: │ │ │ • Size: 17 MB │ │ │ • Flavor: alpine │ │ │ • OS: 3.22 │ │ │ • Runtime: 3.13.5 │ │ │ │ │ │ │ │ │ │ │ Change base image The list displays new recommended tags in descending order, where the top results are rated as most suitable. Tag │ Details │ Pushed │ Vulnerabilities ───────────────────────────────┼────────────────────────────────────────────────────────┼─────────────┼────────────────────────────── 3-alpine3.21 │ Benefits: │ 2 weeks ago │ 0C 0H 0M 0L Minor runtime version update │ • Same OS detected │ │ -3 -8 -8 Also known as: │ • Minor runtime version update │ │ • alpine3.21 │ • Image is smaller by 3.9 MB │ │ • 3.13.5-alpine3.21 │ • Image contains 18 fewer packages │ │ • 3.13-alpine3.21 │ • Tag was pushed more recently │ │ │ • Image introduces no new vulnerability but removes 19 │ │ │ │ │ │ Image details: │ │ │ • Size: 17 MB │ │ │ • Flavor: alpine │ │ │ • OS: 3.21 │ │ │ • Runtime: 3.13.5 │ │ │ │ │ │ │ │ │ │ │ 3.12-alpine │ Benefits: │ 3 weeks ago │ 0C 0H 0M 0L Minor runtime version update │ • Same OS detected │ │ -3 -8 -8 Also known as: │ • Minor runtime version update │ │ • 3.12.11-alpine │ • Image is smaller by 2.6 MB │ │ • 3.12.11-alpine3.22 │ • Tag was pushed more recently │ │ • 3.12-alpine3.22 │ • Image introduces no new vulnerability but removes 19 │ │ │ • Image contains similar number of packages │ │ │ │ │ │ Image details: │ │ │ • Size: 18 MB │ │ │ • Flavor: alpine │ │ │ • OS: 3.22 │ │ │ • Runtime: 3.12.11 │ │ │ │ │ │ │ │ │ │ │ 3.12-alpine3.21 │ Benefits: │ 3 weeks ago │ 0C 0H 0M 0L Minor runtime version update │ • Same OS detected │ │ -3 -8 -8 Also known as: │ • Minor runtime version update │ │ • 3.12.11-alpine3.21 │ • Image is smaller by 2.8 MB │ │ │ • Tag was pushed more recently │ │ │ • Image introduces no new vulnerability but removes 19 │ │ │ • Image contains equal number of packages │ │ │ │ │ │ Image details: │ │ │ • Size: 18 MB │ │ │ • Flavor: alpine │ │ │ • OS: 3.21 │ │ │ • Runtime: 3.12.11 │ │ │ │ │ │ │ │ │ │ │ ``` Ou seja, na imagem `3.12-alpine3.21` lançada há três semanas, todas as vulnerabilidades foram removidas e a imagem foi reduzida em 2.8 MB. Esse é o funcionamento geral do Docker Scout, nem sempre há uma vulnerabilidade identificada que já possua uma correcao, mas isso te deixa ciente do problema. ### Referências - [Docker Scout - Documentação Oficial](https://docs.docker.com/scout/) - [SBOM - Software Bill of Materials](https://www.fortinet.com/br/resources/cyberglossary/sbom) - [NVD - National Vulnerability Database](https://nvd.nist.gov/) ## DORA metrics com Apache DevLake - URL: https://nataliagranato.xyz/blog/dora-metrics-devlake - Data: 2025-05-04T00:00:00.000Z - Resumo: DevOps Research and Assessment - DORA metrics fornecem insights sobre o desempenho da metodologia DevOps. - Tags: devops # O que são Métricas DORA? O [DevOps Research and Assessment (DORA)](https://dora.dev/guides/dora-metrics-four-keys/), ou simplesmente Métricas DORA, foi criado há seis anos por uma equipe de pesquisadores que visavam entender o desempenho de equipes de desenvolvimento de software. O DORA se tornou um framework padrão focado na estabilidade e velocidade dos processos de desenvolvimento. O DORA é utilizado para tomar decisões estratégicas, para justificar investimentos em melhorias de processos ou para comparar o desempenho de uma equipe com os padrões do setor. Existem quatro **métricas DORA** para medir aspectos críticos do DevOps: ![DORA Metrics](https://devlake.apache.org/assets/images/dora-intro-e3847646d8dbe47220e6c8347ab14f7b.png) Dentro da velocidade, existem duas métricas principais: - **Frequência de deploy**: Número de deployments bem-sucedidos em produção. Com que rapidez sua equipe está entregando aos usuários? A frequência de implantação é o número médio de implantações de código concluídas diariamente em qualquer ambiente. Este é um indicador da eficiência geral do DevOps, pois mede a velocidade da equipe de desenvolvimento, suas capacidades e o nível de automação. - **Tempo de espera para mudanças (Lead time for changes)**: Quanto tempo leva desde o commit até o código estar rodando em produção? Essa métrica demonstra com qual rapidez uma equipe pode responder aos requisitos de usuários. Em organizações que não adotam a cultura DevOps, onde é mais comum mensurar as famosas GMUDs, medir o tempo de espera para mudanças pode ajudar a corrigir fluxos de trabalho e a maneira como uma implantação é feita. A estabilidade é composta por duas métricas principais: - **Taxa de falha de mudança (Change Failure Rate)**: Com que frequência um deploy causa falhas em produção? Para responder a essa pergunta, é preciso obter a porcentagem dessas falhas. Essa métrica é desafiadora, mas importante, pois frequentemente uma nova release ou um deploy para atender a um requisito pode inserir um bug em produção. A redução de tarefas em andamento e o aumento da automação podem ajudar na redução dessa métrica. - **Tempo Médio para Restauração do Serviço (MTTR)**: Quanto tempo leva para uma equipe se recuperar adequadamente após ocorrer uma falha e ela ser identificada? Seja para corrigir uma ameaça de segurança ou um bug, as equipes de DevOps devem ser capazes de responder rapidamente com: - Correções de bugs - Atualizações - Correções de vulnerabilidades Você pode experimentar mensurar o desempenho de entrega de software da sua equipe em alguns minutos utilizando o [Take the DORA Quick Check](https://dora.dev/quickcheck/). A comunidade DORA fornece aprendizado, discussões e materiais sobre o tema, acessíveis em [https://dora.community/](https://dora.community/). # Implementando DORA metrics com Apache DevLake O Apache DevLake é uma plataforma de dados que ingere, analisa e visualiza dados de ferramentas DevOps, entre elas o Git. Se a sua equipe de DevOps é adepta da integração contínua, provavelmente o Git é utilizado como a principal fonte da verdade. ## O que pode ser realizado com o DevLake? **Integração de dados unificada:** Reúna dados de DevOps de todo o ciclo de vida de desenvolvimento de software. **Insights prontos para uso:** Acesso a métricas de engenharia por meio de dashboards intuitivos no Grafana. **Customizável:** É possível estender o DevLake, adicionando diferentes [fontes de dados](https://devlake.apache.org/docs/DataSources), [métricas](https://devlake.apache.org/docs/Metrics) e [dashboards](https://devlake.apache.org/docs/Dashboard) conforme as necessidades. **Implementação de padrões:** Use o DevLake para aplicar [métricas DORA](https://devlake.apache.org/docs/Metrics/DORA) e para otimizar o desempenho de DevOps. **Crie uma cultura próspera:** O DevLake é centrado em práticas saudáveis que podem ajudar as equipes a adotar e construir uma cultura prática orientada por dados. O Apache DevLake pode ser implementado usando `Docker Compose` ou `Helm`. Agora vamos a uma demonstração: ### Instalando via Docker Compose 1. Faça o download do arquivo `docker-compose.yml` e `env.example` da release mais recente e estável, nesse caso utilizaremos a v1.0.1, acessível para [download](https://github.com/apache/incubator-devlake/releases/tag/v1.0.1) aqui. 2. Renomeie o arquivo `env.example` para `.env`. Este arquivo contém as variáveis ​​de ambiente que o servidor Devlake usará. 3. Gere uma chave de criptografia segura usando um método como o OpenSSL. Eexecute o seguinte comando para gerar uma string de 128 caracteres composta por letras maiúsculas: ``` openssl rand -base64 2000 | tr -dc 'A-Z' | fold -w 128 | head -n 1 ``` Copie a string gerada. Defina o valor da variável de ambiente ENCRYPTION_SECRET no arquivo `.env`. 4. Agora execute `docker compose up -d` para iniciar o servidor. A saída será algo semelhante a: ``` [+] Running 4/4 ✔ Container devlake-mysql-1 Running 0.0s ✔ Container devlake-grafana-1 Running 0.0s ✔ Container devlake-devlake-1 Running 0.0s ✔ Container devlake-config-ui-1 Started 0.4s ``` Você pode acessar o DevLake em `http://localhost:4000/` e o Grafana em `http://localhost:3002/`, utilizando `admin` como usuário e senha. ### Realizando integrações e coletando dados 1. Na página inicial, clique em `Connections`. Aqui podemos fazer integrações com `Github`, `Gitlab`, `Jenkins` e utilizar `Webhook`. 2. Utilizarei o Github como conexão em `Create a new Connection`. O nome da minha conexão será `nataliagranato.github.io` e será realizada com o `Personal Access Token`. 3. Em projetos, clique em `Create New Project` e informe um nome. 4. Com a conexão e o projeto criados, precisamos adicionar nosso escopo de dados à conexão e associá-lo a um projeto existente. É possível obter métricas de uma organização inteira, um perfil ou um único repositório. Em seu projeto, você verá a opção `Add a Connection`. Selecione a que você criou anteriormente e clique em `next`. Selecione seu `Data Scope` e clique em `save`. Agora inicie a coleta de dados em `Collect Data`. Será disparada uma pipeline para obter seus dados, que podem ser visualizados no menu Advanced. 5. O Grafana do DORA possui alguns dashboards que contribuem com a visualização dos dados, por exemplo: ![Métricas DORA](/static/images/dora1.png) Aqui eu tenho dados de quantos pull requests foram mesclados no repositório, quantos foram mesclados ao longo do mês, quais não foram vinculados, tempo médio de mesclagem e etc. ![Métricas DORA](/static/images/dora2.png) Nesse outro exemplo, temos o tempo médio de um ciclo de pull request, tempo médio de codificação, de revisão e etc. ### Referências - [What is Apache DevLake?](https://devlake.apache.org/docs/Overview/Introduction) - [DevOps Research and Assessment (DORA) metrics](https://docs.gitlab.com/user/analytics/dora_metrics/) - [DORA Community](https://dora.community/) ## O que é uma Arquitetura Cloud Native? - URL: https://nataliagranato.xyz/blog/o-que-arquitetura-cloud-native - Data: 2025-03-22T00:00:00.000Z - Resumo: A orquestração de containers é essencial para gerenciar aplicações em ambientes de produção, garantindo que elas atendam a requisitos críticos de desempenho, escalabilidade e confiabilidade. Ferramentas de orquestração, como Kubernetes, Docker Swarm e Apache Mesos, automatizam a implantação, o gerenciamento e a escalabilidade de containers, proporcionando uma infraestrutura robusta e eficiente para aplicações modernas. - Tags: cloud-native # O que é Cloud Native? A ideia da arquitetura cloud native é otimizar seu software para eficiência de custos, confiabilidade e tempo de lançamento no mercado mais rápido, utilizando uma combinação de padrões de design culturais, tecnológicos e arquitetônicos. O termo cloud native pode ser encontrado em várias definições: algumas focam em tecnologias, enquanto outras destacam aspectos culturais. ![Containers](https://raw.githubusercontent.com/Tech-Preta/trailmap/refs/heads/master/CNCF_TrailMap_latest.png) ## A Cloud Native Computing Foundation define da seguinte forma: “Tecnologias cloud native capacitam organizações a criar e executar aplicações escaláveis em ambientes modernos e dinâmicos, como nuvens públicas, privadas e híbridas. Containers, malhas de serviço (service meshes), microsserviços, infraestrutura imutável e APIs declarativas exemplificam essa abordagem. Essas técnicas permitem sistemas fracamente acoplados, resilientes, gerenciáveis e observáveis. Combinadas com automação robusta, elas permitem que engenheiros realizem mudanças de alto impacto com frequência e previsibilidade, com esforço mínimo. [...]” Aplicações tradicionais ou legadas geralmente são projetadas com uma abordagem monolítica, ou seja, são autocontidas e incluem todas as funcionalidades e componentes necessários para executar uma tarefa. Um aplicativo monolítico normalmente tem uma única base de código e é fornecido como um único arquivo binário executável em um servidor. Por exemplo, pense em um software de comércio eletrônico para uma loja online: um aplicativo monolítico incluiria todas as funcionalidades, desde a interface gráfica, listagem de produtos, carrinho de compras, checkout, processamento de pedidos e muito mais. Embora seja fácil desenvolver e implantar um aplicativo nesse formato, gerenciar a complexidade, escalar o desenvolvimento entre várias equipes, implementar mudanças rapidamente e dimensionar o aplicativo de forma eficiente sob alta demanda pode ser igualmente desafiador. A arquitetura cloud native oferece soluções para a complexidade crescente das aplicações e a demanda cada vez maior dos usuários. A ideia central é dividir seu aplicativo em partes menores, tornando-o mais gerenciável. Em vez de concentrar todas as funcionalidades em um único aplicativo, você terá vários componentes independentes que se comunicam em rede. Usando o exemplo anterior, poderíamos ter um aplicativo para a interface do usuário, outro para o checkout e assim por diante. Esses componentes independentes, com escopo bem definido, são chamados de microsserviços. Isso permite que múltiplas equipes assumam a responsabilidade por diferentes funcionalidades do aplicativo, além de operar e escalar cada parte individualmente. Por exemplo, se muitos usuários tentarem finalizar compras, é possível escalar serviços sob alta carga, como o carrinho de compras ou o checkout. ## Característica de uma arquitetura Cloud Native ### Alto nível de automação Para gerenciar todos os componentes dinâmicos de uma aplicação cloud native, recomenda-se a automação em todas as etapas, do desenvolvimento à implantação. Isso pode ser alcançado com ferramentas modernas de automação e pipelines de Integração Contínua/Entrega Contínua (CI/CD) (falaremos mais sobre pipelines adiante no curso, mas, por ora, entenda que um pipeline CI/CD é um conceito usado para as múltiplas etapas necessárias ao entregar uma nova versão do software), suportados por um sistema de controle de versão como o git. Construir, testar e implantar aplicações — bem como a infraestrutura — com intervenção humana mínima permite que mudanças rápidas, frequentes e incrementais sejam feitas em produção. Um sistema automatizado confiável também facilita a recuperação de desastres, caso seja necessário reconstruir todo o sistema. A automação reduz erros humanos, acelera a entrega de valor aos usuários e garante consistência em ambientes complexos, essencial para manter a eficiência e a resiliência inerentes ao modelo cloud native. ### Self healing ou "auto cura" Aplicações e infraestruturas falham eventualmente. Isso é esperado e, por isso, os frameworks de aplicações cloud native e os componentes de infraestrutura incluem verificações de integridade (health checks) que monitoram a aplicação internamente e as reiniciam automaticamente, se necessário. Além disso, como a aplicação está compartimentalizada (dividida em partes independentes), há a possibilidade de que apenas algumas funcionalidades parem de funcionar ou fiquem mais lentas, enquanto outras continuam operando normalmente. Essa capacidade de autocorreção minimiza interrupções e garante que a aplicação se adapte a falhas sem exigir intervenção manual constante. Ao isolar problemas em componentes específicos, o sistema mantém sua operacionalidade global, reforçando a confiabilidade e a experiência do usuário final. ### Escalável Sua aplicação descreve o processo de lidar com uma carga maior enquanto ainda proporciona uma experiência agradável para o usuário. Uma maneira de escalar pode ser iniciar várias cópias da mesma aplicação e distribuir a carga entre elas. Automatizar esse comportamento com base em métricas da aplicação, como CPU ou memória, também pode garantir a disponibilidade e o desempenho dos seus serviços. ### Eficiência de custo Assim como escalar sua aplicação para situações de alto tráfego, reduzir a escala da sua aplicação e os modelos de preços baseados em uso dos provedores de nuvem podem economizar custos se o tráfego estiver baixo. Para otimizar o uso da sua infraestrutura, sistemas de orquestração como o Kubernetes podem ajudar com um posicionamento mais eficiente e denso das aplicações. ### Fácil de manter Usar Micro serviços permite dividir as aplicações em partes menores e torná-las mais portáteis, mais fáceis de testar e de distribuir entre várias equipes. ### Seguro por padrão Ambientes de nuvem são frequentemente compartilhados entre vários clientes ou equipes, o que exige diferentes modelos de segurança. No passado, muitos sistemas eram divididos em diferentes zonas de segurança que negavam acesso de diferentes redes ou pessoas. Uma vez dentro de uma zona, você poderia acessar todos os sistemas internos. Padrões como a [computação zero trust](https://en.wikipedia.org/wiki/Zero_trust_architecture) mitigam isso ao exigir autenticação de cada usuário e processo. Uma boa linha de base e ponto de partida para sua jornada em cloud native é o [twelve-factor app](https://12factor.net/pt_br/). O twelve factor app é um guia para desenvolver aplicações cloud native, que começa com coisas simples como controle de versão da sua base de código, configuração sensível ao ambiente e padrões mais sofisticados como statelessness e concorrência da sua aplicação. Embora esses padrões e tecnologias proporcionem plena vantagem se executados na nuvem, eles também podem oferecer muitos benefícios quando aplicados a sistemas on-premises. Por último, mas não menos importante, eles permitem uma transição mais suave se você migrar suas aplicações e infraestrutura para a nuvem. ### Autoscaling O padrão de autoscaling descreve o ajuste dinâmico de recursos com base na demanda atual. CPU e memória são as métricas óbvias para decidir quando escalar aplicações à medida que a carga aumenta ou diminui, mas outros métodos baseados em tempo ou métricas de negócios também podem ser considerados para escalar seus serviços para cima ou para baixo. Tipicamente, quando falamos de autoscaling estamos falando de escalonamento horizontal, que descreve o processo de gerar novos recursos de computação que podem ser novas cópias do seu processo de aplicação, máquinas virtuais ou - de uma maneira menos imediata - até mesmo novos racks de servidores e outros hardwares. O escalonamento vertical, por outro lado, descreve a mudança no tamanho do hardware subjacente, que só funciona dentro de certos limites de hardware para bare metal, mas também para máquinas virtuais. Máquinas virtuais e processos podem ser facilmente escalados para cima, permitindo que consumam mais CPU e memória, o limite superior é definido pela capacidade de computação e memória do hardware subjacente. O próprio hardware pode ser escalado para cima, por exemplo, adicionando mais RAM, mas somente até que todos os slots de RAM estejam ocupados. Para ilustrar a diferença entre escalonamento vertical e horizontal, imagine que você tem que carregar um objeto pesado que não consegue levantar. Você pode ganhar músculos para carregá-lo sozinho, mas seu corpo tem um limite superior de força. Isso é escalonamento vertical. Você também pode chamar seus amigos e pedir que eles ajudem e compartilhem o trabalho. Isso é escalonamento horizontal. ![Horizontal vs Vertical Scaling](https://d36ai2hkxl16us.cloudfront.net/course-uploads/e0df7fbf-a057-42af-8a1f-590912be5460/q2cr3c5d6279-Horizontalvsverticalscaling.png) ### Horizontal vs vertical scaling Configurar autoscaling em vários ambientes requer a configuração de um limite mínimo e máximo de instâncias (máquinas virtuais ou contêineres) e uma métrica que aciona a escalabilidade. Para configurar a escalabilidade correta, muitas vezes é necessário realizar muitos testes de carga (quase de produção) e analisar o comportamento e o balanceamento de carga quando sua aplicação é escalada. Ambientes de nuvem que dependem de modelos de preços sob demanda baseados em uso fornecem plataformas muito eficazes para escalabilidade automática, com a capacidade de provisionar uma grande quantidade de recursos em segundos ou até mesmo escalar para zero, se os recursos não forem temporariamente necessários. Mesmo que a escalabilidade de suas aplicações e da infraestrutura subjacente não esteja automatizada inicialmente, a capacidade de escalar sua aplicação pode aumentar a disponibilidade e a resiliência de seus serviços em ambientes mais tradicionais. ## O que é Kubernetes? - URL: https://nataliagranato.xyz/blog/o-que-e-kubernetes - Data: 2025-03-22T00:00:00.000Z - Resumo: Um sistema de código aberto para automatizar a implantação, escalabilidade e gerenciamento de aplicações containerizadas. - Tags: kubernetes, containers ### O que é Kubernetes? ![Containers](https://atraca.com.br/wp-content/uploads/2024/06/o-que-e-kubernetes.png) "Kubernetes é um sistema de código aberto para automatizar a implantação, escalabilidade e gerenciamento de aplicações containerizadas". Kubernetes vem da palavra grega **κυβερνήτης**, que significa timoneiro ou piloto de navio. Com essa analogia em mente, podemos pensar no Kubernetes como o piloto de um navio de containers. Kubernetes também é referido como **k8s**, pois há 8 caracteres entre o k e o s. Kubernetes é altamente inspirado pelo sistema Google Borg, um orquestrador de containers e cargas de trabalho para suas operações globais, que o Google tem usado por mais de uma década. É um projeto de código aberto escrito na linguagem Go e licenciado sob a Licença Apache, Versão 2.0. Kubernetes foi iniciado pelo Google e, com seu lançamento v1.0 em julho de 2015, o Google o doou para a Cloud Native Computing Foundation (CNCF), uma das maiores sub-fundações da Linux Foundation. Novas versões do Kubernetes são lançadas em ciclos de 4 meses. ![[Pasted image 20241113175127.png]] ### Do Borg ao Kubernetes De acordo com o resumo do [artigo sobre o Borg](https://research.google/pubs/large-scale-cluster-management-at-google-with-borg/) do Google, publicado em 2015, "O sistema Borg do Google é um gerenciador de clusters que executa centenas de milhares de tarefas, de milhares de diferentes aplicações, em vários clusters, cada um com até dezenas de milhares de máquinas". Por mais de uma década, o Borg tem sido o segredo do Google, executando suas cargas de trabalho containerizadas em produção em todo o mundo. Serviços que usamos do Google, como Gmail, Drive, Maps, Docs, etc., são todos atendidos usando o Borg. Entre os autores iniciais do Kubernetes estavam funcionários do Google que usaram e desenvolveram o Borg no passado. Eles aplicaram seu valioso conhecimento e experiência ao projetar o Kubernetes. Várias características/objetos do Kubernetes que podem ser rastreados até o Borg, ou a lições aprendidas com ele, são: - **API servers** - **Pods** - **IP-per-Pod** - **Services** - **Labels** ### Funcionalidades do Kubernetes Kubernetes oferece um conjunto muito rico de funcionalidades para orquestração de containers. Algumas de suas funcionalidades totalmente suportadas são: #### Empacotamento automático Kubernetes agenda automaticamente containers com base nas necessidades de recursos e restrições, para maximizar a utilização sem sacrificar a disponibilidade. #### Projetado para extensibilidade Um cluster Kubernetes pode ser estendido com novos recursos personalizados sem modificar o código-fonte original. #### Auto-recuperação Kubernetes substitui e reprograma automaticamente containers de nós que falharam. Ele termina e reinicia containers que se tornam não responsivos a verificações de saúde, com base em regras/políticas existentes. Também impede que o tráfego seja roteado para containers não responsivos. #### Escalabilidade horizontal Kubernetes escala aplicações manualmente ou automaticamente com base na utilização de CPU ou métricas personalizadas. #### Descoberta de serviços e balanceamento de carga Containers recebem endereços IP do Kubernetes, enquanto ele atribui um único nome de Sistema de Nomes de Domínio (DNS) a um conjunto de containers para ajudar no balanceamento de carga das solicitações entre os containers do conjunto. ### Funcionalidades adicionais: #### Rollouts e rollbacks automatizados Kubernetes implementa e reverte atualizações de aplicações e mudanças de configuração de forma contínua, monitorando constantemente a saúde da aplicação para evitar qualquer tempo de inatividade. #### Gerenciamento de segredos e configurações Kubernetes gerencia dados sensíveis e detalhes de configuração de uma aplicação separadamente da imagem do container, para evitar a reconstrução da imagem respectiva. Segredos consistem em informações sensíveis/confidenciais passadas para a aplicação sem revelar o conteúdo sensível para a configuração da pilha, como no GitHub. #### Orquestração de armazenamento Kubernetes monta automaticamente soluções de armazenamento definido por software (SDS) em containers a partir de armazenamento local, provedores de nuvem externos, armazenamento distribuído ou sistemas de armazenamento em rede. #### Execução em lote Kubernetes suporta execução em lote, trabalhos de longa duração e substitui containers que falharam. #### Suporte Dual-Stack IPv4/IPv6 Kubernetes suporta endereços IPv4 e IPv6. Kubernetes suporta funcionalidades comuns específicas de Plataforma como Serviço, como implantação de aplicações, escalabilidade e balanceamento de carga, mas permite que os usuários integrem suas soluções desejadas de monitoramento, registro e alerta através de plugins opcionais. ### Por que usar Kubernetes? Uma das grandes forças do Kubernetes é sua portabilidade. Ele pode ser implantado em muitos ambientes, como máquinas virtuais locais ou remotas, bare metal, ou em configurações de nuvem pública/privada/híbrida/multi-nuvem. A extensibilidade do Kubernetes permite que ele suporte e seja suportado por muitas ferramentas de código aberto de terceiros que aprimoram suas capacidades e proporcionam uma experiência rica em recursos para seus usuários. Sua arquitetura é modular e plugável. Ele não apenas orquestra aplicações do tipo microsserviços modulares e desacoplados, mas também sua arquitetura segue padrões de microsserviços desacoplados. A funcionalidade do Kubernetes pode ser estendida escrevendo recursos personalizados, operadores, APIs personalizadas, regras de agendamento ou plugins. Para um projeto de código aberto bem-sucedido, a comunidade é tão importante quanto ter um ótimo código. O Kubernetes é suportado por uma comunidade próspera em todo o mundo. Ele tem mais de 3.500 colaboradores, que, ao longo do tempo, realizaram mais de 120.000 commits. Existem grupos de encontro em diferentes cidades e países que se reúnem regularmente para discutir o Kubernetes e seu ecossistema. A comunidade é dividida em Grupos de Interesse Especial (SIGs), grupos que se concentram em tópicos especiais, como escalabilidade, bare metal, redes, armazenamento, etc. ### Usuários do Kubernetes Em menos de uma década desde sua estreia, o Kubernetes se tornou a plataforma de escolha para muitas empresas de diversos tamanhos para executar suas cargas de trabalho. É uma solução para gerenciamento de cargas de trabalho em setores como bancos, educação, finanças e investimentos, jogos, tecnologia da informação, mídia e streaming, varejo online, compartilhamento de viagens, telecomunicações, pesquisa nuclear e muitas outras indústrias. Existem inúmeros estudos de caso e histórias de sucesso no site do Kubernetes: - BlackRock - Booking.com - Box - CapitalOne - Huawei - IBM - ING - Nokia - OpenAI - Pearson - Spotify - Wikimedia - E muitos mais. Esses exemplos demonstram a versatilidade e a eficácia do Kubernetes em diferentes setores, destacando sua capacidade de gerenciar cargas de trabalho complexas e variadas de maneira eficiente e escalável. ### Cloud Native Computing Foundation (CNCF) ![[Pasted image 20241113180406.png]] A **Cloud Native Computing Foundation (CNCF)** é um dos maiores subprojetos hospedados pela Linux Foundation. A CNCF tem como objetivo acelerar a adoção de containers, microsserviços e aplicações nativas da nuvem. A CNCF hospeda uma infinidade de projetos, com mais a serem adicionados no futuro. A CNCF fornece recursos para cada um dos projetos, mas, ao mesmo tempo, cada projeto continua a operar de forma independente sob sua estrutura de governança pré-existente e com seus mantenedores existentes. Os projetos dentro da CNCF são categorizados com base em seus níveis de maturidade: Sandbox, Incubating e Graduated. No momento da escrita deste texto, mais de uma dúzia de projetos haviam alcançado o status Graduated, com muitos outros em Incubating e no Sandbox. #### Projetos Graduados Populares (a partir de março de 2024): - **Kubernetes**: Orquestrador de containers. - **Argo**: Motor de workflow para Kubernetes. - **etcd**: Armazenamento de chave-valor distribuído. - **CoreDNS**: Servidor DNS. - **containerd**: Runtime de container. - **CRI-O**: Runtime de container. - **Envoy**: Proxy nativo da nuvem. - **Fluentd**: Para logging unificado. - **Flux**: Entrega contínua para Kubernetes. - **Harbor**: Registro de containers. - **Helm**: Gerenciamento de pacotes para Kubernetes. - **Linkerd**: Malha de serviços para Kubernetes. - **Open Policy Agent**: Motor de políticas. - **Prometheus**: Sistema de monitoramento e banco de dados de séries temporais. - **Rook**: Orquestrador de armazenamento nativo da nuvem para Kubernetes. #### Principais Projetos em Incubação: - **Buildpacks.io**: Constrói imagens de aplicação. - **Contour**: Controlador de ingress para Kubernetes. - **gRPC**: Para chamada de procedimento remoto (RPC). - **CNI**: Para rede de containers Linux. - **Knative**: Containers serverless em Kubernetes. - **KubeVirt**: Gerenciador de Máquinas Virtuais baseado em Kubernetes. - **Notary**: Para segurança de dados. - E muitos mais. Existem muitos projetos dinâmicos no Sandbox da CNCF voltados para métricas, monitoramento, identidade, scripting, serverless, nodeless, edge, esperando alcançar o status de Incubating e possivelmente Graduated. Enquanto muitos projetos ativos estão se preparando para decolar, outros estão sendo arquivados uma vez que se tornam menos ativos e não mais demandados. Os primeiros projetos a serem arquivados são o runtime de container rkt, o OpenTracing distribuído, a ferramenta de automação orientada a eventos Brigade e a Interface de Malha de Serviços. Os projetos sob a CNCF cobrem todo o ciclo de vida de uma aplicação nativa da nuvem, desde sua execução usando runtimes de containers, até seu monitoramento e logging. Isso é muito importante para atender aos objetivos da CNCF. ## O é Orquestração de Containers? - URL: https://nataliagranato.xyz/blog/o-que-e-orquestracao-de-containers - Data: 2025-03-22T00:00:00.000Z - Resumo: A orquestração de containers é essencial para gerenciar aplicações em ambientes de produção, garantindo que elas atendam a requisitos críticos de desempenho, escalabilidade e confiabilidade. Ferramentas de orquestração, como Kubernetes, Docker Swarm e Apache Mesos, automatizam a implantação, o gerenciamento e a escalabilidade de containers, proporcionando uma infraestrutura robusta e eficiente para aplicações modernas. - Tags: kubernetes, containers A **orquestração de containers** é o processo de gerenciar, automatizar e coordenar a implantação, o funcionamento e a escalabilidade de containers em ambientes de produção. Containers são unidades leves e portáteis que empacotam uma aplicação e suas dependências, permitindo que ela seja executada de forma consistente em diferentes ambientes. No entanto, em cenários de produção, onde há múltiplos containers distribuídos em vários servidores, gerenciá-los manualmente se torna inviável. Ferramentas de orquestração, como **Kubernetes**, **Docker Swarm** e **Apache Mesos**, são usadas para resolver esse problema. Elas automatizam tarefas como: - **Implantação**: Garantem que os containers sejam iniciados e configurados corretamente. - **Escalabilidade**: Ajustam automaticamente o número de containers com base na demanda. - **Tolerância a falhas**: Reiniciam containers em caso de falhas e redistribuem cargas de trabalho. - **Balanceamento de carga**: Distribuem o tráfego entre os containers para otimizar o desempenho. - **Gerenciamento de recursos**: Garantem o uso eficiente de CPU, memória e armazenamento. - **Atualizações contínuas**: Permitem atualizações e rollbacks sem interrupções. A orquestração de containers é essencial para atender a requisitos de **desempenho**, **escalabilidade** e **confiabilidade** em ambientes modernos, especialmente em arquiteturas baseadas em microsserviços. Ela permite que empresas gerenciem aplicações complexas de forma eficiente, reduzindo custos e aumentando a agilidade operacional. Em ambientes de Desenvolvimento (Dev), executar containers em um único host para desenvolvimento e teste de aplicações pode ser uma opção adequada. No entanto, ao migrar para ambientes de Garantia de Qualidade (QA) e Produção (Prod), isso deixa de ser uma opção viável porque as aplicações e serviços precisam atender a requisitos específicos: - Tolerância a falhas. - Escalabilidade sob demanda. - Uso otimizado de recursos. - Auto-descoberta para descobrir e se comunicar automaticamente. - Acessibilidade do mundo exterior. - Atualizações/rollbacks contínuos sem tempo de inatividade. Os orquestradores de containers são ferramentas que agrupam sistemas para formar clusters onde a implantação e o gerenciamento de containers são automatizados em escala, atendendo aos requisitos mencionados acima. Os sistemas em cluster conferem as vantagens dos sistemas distribuídos, como aumento de desempenho, eficiência de custos, confiabilidade, distribuição de carga de trabalho e redução de latência. ### Benefícios da Orquestração de Containers: 1. **Tolerância a Falhas**: Garante que as aplicações continuem funcionando mesmo em caso de falhas de hardware ou software. 2. **Escalabilidade Sob Demanda**: Permite aumentar ou diminuir a quantidade de recursos alocados para as aplicações com base na demanda. 3. **Uso Otimizado de Recursos**: Garante que os recursos de computação sejam utilizados de forma eficiente, evitando desperdícios. 4. **Auto-descoberta**: Facilita a comunicação entre diferentes serviços e aplicações dentro do cluster. 5. **Acessibilidade**: Garante que as aplicações sejam acessíveis de fora do cluster, permitindo a interação com usuários e outros sistemas. 6. **Atualizações Contínuas**: Permite realizar atualizações e rollbacks de forma contínua, sem causar interrupções no serviço. A orquestração de containers é essencial para gerenciar aplicações em ambientes de produção, garantindo que elas atendam a requisitos críticos de desempenho, escalabilidade e confiabilidade. Ferramentas de orquestração, como Kubernetes, Docker Swarm e Apache Mesos, automatizam a implantação, o gerenciamento e a escalabilidade de containers, proporcionando uma infraestrutura robusta e eficiente para aplicações modernas. ### Orquestradores de Containers Com as empresas containerizando suas aplicações e movendo-as para a nuvem, há uma demanda crescente por soluções de orquestração de containers. Embora existam muitas soluções disponíveis, algumas são apenas redistribuições de ferramentas de orquestração de containers bem estabelecidas, enriquecidas com recursos e, às vezes, com certas limitações em flexibilidade. Embora não seja exaustiva, a lista abaixo fornece algumas das diferentes ferramentas e serviços de orquestração de containers disponíveis hoje: #### Amazon Elastic Container Service Amazon Elastic Container Service (ECS) é um serviço hospedado fornecido pela Amazon Web Services (AWS) para executar containers em escala em sua infraestrutura. #### Azure Container Instances Azure Container Instance (ACI) é um serviço básico de orquestração de containers fornecido pela Microsoft Azure. #### Kubernetes Kubernetes é uma ferramenta de orquestração de código aberto, originalmente iniciada pelo Google, hoje parte do projeto da Cloud Native Computing Foundation (CNCF). #### Nomad Nomad é o orquestrador de containers e cargas de trabalho fornecido pela HashiCorp. #### Docker Swarm Docker Swarm é um orquestrador de containers fornecido pela Docker, Inc. Faz parte do Docker Engine. ### Por que usar orquestradores de containers? Embora possamos manter manualmente alguns containers ou escrever scripts para gerenciar o ciclo de vida de dezenas de containers, os orquestradores tornam as coisas muito mais fáceis para os usuários, especialmente quando se trata de gerenciar centenas ou milhares de containers em uma infraestrutura global. A maioria dos orquestradores de containers pode: - **Agrupar hosts**: Criar um cluster para aproveitar os benefícios dos sistemas distribuídos. - **Agendar containers**: Executar containers nos hosts do cluster com base na disponibilidade de recursos. - **Habilitar comunicação**: Permitir que containers em um cluster se comuniquem entre si, independentemente do host em que estão implantados. - **Vincular containers e recursos de armazenamento**: Garantir que os containers tenham acesso aos recursos de armazenamento necessários. - **Agrupar e balancear carga**: Agrupar conjuntos de containers semelhantes e vinculá-los a estruturas de balanceamento de carga para simplificar o acesso às aplicações containerizadas, criando uma interface, um nível de abstração entre os containers e o cliente. - **Gerenciar e otimizar o uso de recursos**: Garantir que os recursos de computação sejam utilizados de forma eficiente. - **Implementar políticas de segurança**: Permitir a implementação de políticas para proteger o acesso às aplicações que estão sendo executadas dentro dos containers. Com todos esses recursos configuráveis e flexíveis, os orquestradores de containers são uma escolha óbvia quando se trata de gerenciar aplicações containerizadas em escala. ### Onde implantar orquestradores de containers? A maioria dos orquestradores de containers pode ser implantada na infraestrutura de sua escolha - em bare metal, Máquinas Virtuais, on-premises, em nuvens públicas e híbridas. O Kubernetes, por exemplo, pode ser implantado em uma estação de trabalho, com ou sem uma camada de isolamento, como um hipervisor local ou runtime de container, dentro do data center de uma empresa, na nuvem em instâncias do AWS Elastic Compute Cloud (EC2), VMs do Google, OpenStack, etc. Além disso, existem soluções de nuvem turnkey que permitem a instalação de clusters Kubernetes de produção com apenas alguns comandos. Essas soluções abriram caminho para a orquestração de containers gerenciada como serviço, mais especificamente a solução Kubernetes gerenciada como serviço (KaaS), oferecida e hospedada pelos principais provedores de nuvem. Exemplos de soluções KaaS são Amazon Elastic Kubernetes Service (Amazon EKS), Azure Kubernetes Service (AKS), DigitalOcean Kubernetes, Google Kubernetes Engine (GKE), IBM Cloud Kubernetes Service, Oracle Container Engine for Kubernetes, ou VMware Tanzu Kubernetes Grid. Os orquestradores de containers, como o Kubernetes, oferecem flexibilidade para serem implantados em diversas infraestruturas, desde ambientes locais até nuvens públicas e híbridas. As soluções gerenciadas de Kubernetes simplificam ainda mais a implantação e o gerenciamento de clusters Kubernetes, permitindo que as empresas se concentrem no desenvolvimento e na operação de suas aplicações, enquanto os provedores de nuvem cuidam da infraestrutura subjacente. ## O que são Containers? - URL: https://nataliagranato.xyz/blog/o-que-sao-containers - Data: 2025-03-22T00:00:00.000Z - Resumo: Um método centrado em aplicações para entregar aplicações de alto desempenho e escaláveis em qualquer infraestrutura de sua escolha. - Tags: kubernetes, docker, containers # O que são Containers? Containers são um método centrado em aplicações para entregar aplicações de alto desempenho e escaláveis em qualquer infraestrutura de sua escolha. Containers são mais adequados para entregar microsserviços, fornecendo ambientes virtuais portáteis e isolados para que as aplicações sejam executadas sem interferência de outras aplicações em execução. ![Containers](https://www.docker.com/app/uploads/2021/11/docker-containerized-appliction-blue-border_2.png) #### Implantação de Containers Microsserviços são aplicações leves escritas em várias linguagens de programação modernas, com dependências específicas, bibliotecas e requisitos ambientais. Para garantir que uma aplicação tenha tudo o que precisa para ser executada com sucesso, ela é empacotada junto com suas dependências. Containers encapsulam microsserviços e suas dependências, mas não os executam diretamente. Containers executam imagens de containers. Uma imagem de container agrupa a aplicação junto com seu runtime, bibliotecas e dependências, e representa a fonte de um container implantado para oferecer um ambiente executável isolado para a aplicação. Containers podem ser implantados a partir de uma imagem específica em muitas plataformas, como estações de trabalho, Máquinas Virtuais, nuvem pública, etc. ### Uma demonstração prática Este é o arquivo principal da aplicação. Ele contém o código de um microserviço simples escrito em Python usando o framework Flask. O microserviço tem um endpoint `/health` que retorna um JSON com o status de saúde do serviço, o ID do container e o ambiente em que está sendo executado. ```python # micro_service.py from flask import Flask, jsonify import os app = Flask(__name__) @app.route('/health') def health_check(): return jsonify({ "status": "healthy", "container_id": os.getenv('HOSTNAME', 'local'), "environment": os.getenv('ENV', 'development') }) if __name__ == '__main__': app.run(host='0.0.0.0', port=8080) ``` Este arquivo define como construir a imagem do container para o microserviço. Ele especifica a imagem base, copia os arquivos necessários, instala as dependências e define o comando para iniciar a aplicação. ```dockerfile # Dockerfile FROM python:3.9-slim # Ambiente isolado WORKDIR /app # Dependências da aplicação COPY requirements.txt . RUN pip install -r requirements.txt # Código da aplicação COPY micro_service.py . # Configuração do container ENV ENV=production # Porta do microserviço EXPOSE 8080 # Comando para executar CMD ["python", "micro_service.py"] ``` Este arquivo lista as dependências da aplicação que precisam ser instaladas. No caso deste microserviço, ele especifica a versão do Flask que deve ser instalada. ```bash # requirements.txt flask==2.0.1 ``` Para construir e executar: ```bash # Construir a imagem do container docker build -t meu-microservice . # Executar o container docker run -d -p 8080:8080 meu-microservice # Verificar o serviço curl http://localhost:8080/health ``` Este exemplo demonstra os conceitos chave mencionados: - Aplicação centrada em container (application-centric) - Ambiente virtual isolado. - Empacotamento de dependências. - Imagem do container como fonte única. - Portabilidade entre diferentes plataformas. ### Vantagens dos Containers: 1. **Portabilidade**: Containers podem ser executados em qualquer ambiente que suporte a tecnologia de containers, garantindo que a aplicação funcione da mesma maneira em diferentes plataformas. 2. **Isolamento**: Cada container opera em um ambiente isolado, evitando conflitos entre diferentes aplicações e suas dependências. 3. **Escalabilidade**: Containers permitem escalar aplicações de forma eficiente, seja manualmente ou automaticamente, com base na demanda. 4. **Eficiência de Recursos**: Containers compartilham o kernel do sistema operacional, tornando-os mais leves e eficientes em termos de recursos em comparação com Máquinas Virtuais. 5. **Desenvolvimento e Implantação Consistentes**: Containers garantem que o ambiente de desenvolvimento seja idêntico ao de produção, reduzindo problemas de compatibilidade e facilitando o processo de implantação. Containers revolucionaram a forma como desenvolvemos, implantamos e gerenciamos aplicações. Eles oferecem uma solução eficiente e flexível para entregar microsserviços e outras aplicações modernas, permitindo que as empresas aproveitem ao máximo os recursos de computação disponíveis e mantenham suas aplicações escaláveis, portáteis e fáceis de gerenciar. ## Realizando um troubleshooting básico de redes no Kubernetes - URL: https://nataliagranato.xyz/blog/troubleshooting-básico-de-redes-k8s - Data: 2025-02-26T00:00:00.000Z - Resumo: Um guia passo a passo para solucionar problemas de rede em um cluster Kubernetes, utilizando uma aplicação de exemplo (Jaeger). - Tags: kubernetes, network, troubleshooting ## Passos de Troubleshooting ### 1. Obter o DNS Interno do Kubernetes O DNS interno de um serviço no Kubernetes segue o formato: ``` ..svc.cluster.local ``` Por exemplo, para o serviço `jaeger-collector` no namespace `jaeger`, o DNS interno seria: ``` jaeger-collector.jaeger.svc.cluster.local ``` ### 2. Obter o Endereço IP do Serviço Para obter o endereço IP de um serviço específico, use o comando `kubectl get svc` no namespace apropriado. ```sh kubectl get svc jaeger-collector -n jaeger ``` **Saída esperada:** ``` NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE jaeger-collector ClusterIP 172.28.100.178 14250/TCP,14268/TCP,4317/TCP 33d ``` O endereço IP do serviço é o valor na coluna `CLUSTER-IP`. ### 3. Teste de Resolução de DNS Verifique se o nome do serviço está sendo resolvido corretamente. ```sh kubectl run dns-test --image=busybox:1.28 --rm -it --restart=Never -- nslookup jaeger-collector.jaeger.svc.cluster.local ``` ### 4. Descrever o Serviço Verifique os detalhes do serviço para garantir que ele está configurado corretamente. ```sh kubectl describe svc jaeger-collector -n jaeger ``` ### 5. Verificar Endpoints Verifique os endpoints associados ao serviço. ```sh kubectl get endpoints jaeger-collector -n jaeger ``` ### 6. Teste HTTP/Thrift (via curl) Teste a conectividade HTTP com o serviço usando `curl`. #### Usando o nome do serviço: ```sh kubectl run curl-test --image=curlimages/curl --rm -it -- curl -v http://jaeger-collector.jaeger.svc.cluster.local:14268/api/traces ``` #### Usando o endereço IP do serviço: ```sh kubectl run curl-test --image=curlimages/curl --rm -it -- curl -v http://172.28.100.178:14268/api/traces ``` ### 7. Verificar Pods Verifique os pods associados ao serviço. ```sh kubectl get pods -n jaeger -l app.kubernetes.io/component=collector ``` ### 8. Teste de Conectividade com Curl Crie um pod de depuração e teste a conectividade com o serviço usando `curl`. ```sh kubectl run debug-pod -n jaeger --image=curlimages/curl -- sleep infinity kubectl exec -it debug-pod -n jaeger -- sh ``` Dentro do container: ```sh curl -v http://jaeger-collector.jaeger.svc.cluster.local:14268/api/traces ``` ### 9. Teste de Conectividade Externa Teste a conectividade com um endpoint externo para garantir que a rede externa está funcionando. ```sh curl -v -k https://jaeger-http-collector.nataliagranato.xyz/api/traces ``` ### 10. Teste de Conectividade com Ping Teste a conectividade com o serviço usando `ping`. ```sh ping jaeger-collector.jaeger.svc.cluster.local ``` ## Conclusão Se algum dos testes acima falhar, pode haver um problema de configuração de DNS, rede ou serviço no cluster Kubernetes. Verifique as configurações de DNS, as políticas de rede e a configuração do serviço para resolver o problema. ## Referências - [Handling Networking Errors in Kubernetes](https://komodor.com/blog/handling-networking-errors-in-kubernetes/) - [Netshoot](https://github.com/nicolaka/netshoot) - [Cluster Networking](https://kubernetes.io/docs/concepts/cluster-administration/networking/) ## Introdução a Requests e Limits no Kubernetes - URL: https://nataliagranato.xyz/blog/introduction-requests-limits-kubernetes - Data: 2025-02-20T00:00:00.000Z - Resumo: Quando você especifica o requerimento de recursos em um Pod, o kube-scheduler utiliza esta informação para decidir a qual nó o Pod será atribuído. - Tags: kubernetes, resources, containers # Introdução a Requests e Limits no Kubernetes: Gerenciamento de Recursos No Kubernetes, o gerenciamento de recursos é essencial para garantir a estabilidade e eficiência de aplicações em execução. Requests e Limits são mecanismos que permitem definir, respectivamente, a alocação mínima e máxima de recursos (CPU e memória) para contêineres. Este documento explica como utilizar essas configurações para otimizar o uso do cluster e evitar problemas como esgotamento de recursos ou contêineres sendo terminados. ## Requests e Limits no Kubernetes No Kubernetes, requests e limits são usados para gerenciar os recursos de CPU e memória que os contêineres podem usar. Eles ajudam a garantir que os recursos do cluster sejam utilizados de maneira eficiente e que os contêineres não consumam mais recursos do que o necessário. ### Requests Os `requests` especificam a quantidade mínima de CPU e memória que um Pod ou contêiner precisa para funcionar. Ao configurar `requests`, você está reservando essa quantidade de recursos do total disponível no cluster para uma determinada aplicação. O Kubernetes usa esses valores para decidir em qual nó do cluster o contêiner será agendado. Se um nó não tiver recursos suficientes para atender aos `requests` de um contêiner, o Kubernetes não agendará o contêiner nesse nó. #### Exemplo de mensagem falta de recursos: Aqui está um exemplo de log que pode ser gerado pelo Kubernetes quando um contêiner não pode ser agendado devido à falta de recursos: ``` Warning FailedScheduling 2m (x3 over 5m) default-scheduler 0/3 nodes are available: 1 Insufficient cpu, 2 Insufficient memory. ``` Neste exemplo, o log indica que o agendador do Kubernetes tentou agendar um Pod, mas falhou porque nenhum dos nós disponíveis tinha recursos suficientes. Especificamente, um nó não tinha CPU suficiente e dois nós não tinham memória suficiente para atender aos `requests` do Pod. #### Ou: Aqui estão alguns exemplos de logs que indicam falta de recursos em um nó no Kubernetes: **Log de falta de CPU em um nó:** ``` Warning EvictionThresholdMet 1m (x5 over 10m) kubelet, node-1 Attempting to reclaim CPU resource ``` **Log de falta de memória em um nó:** ``` Warning EvictionThresholdMet 2m (x3 over 15m) kubelet, node-2 Attempting to reclaim memory resource ``` **Log de OOM (Out of Memory) em um nó:** ``` Warning OOMKilling 3m (x2 over 20m) kubelet, node-3 Memory cgroup out of memory: Kill process 12345 (example-process) score 1000 or sacrifice child ``` **Log de falta de espaço em disco em um nó:** ``` Warning EvictionThresholdMet 4m (x4 over 25m) kubelet, node-4 Attempting to reclaim disk resource ``` Esses logs são gerados pelo `kubelet` em cada nó e indicam que o nó está tentando recuperar recursos devido à falta de CPU, memória ou espaço em disco. #### Exemplo de configuração de requests: ```yaml apiVersion: v1 kind: Pod metadata: name: example-pod spec: containers: - name: example-container image: nginx resources: requests: memory: '64Mi' cpu: '250m' ``` ### Limits Os `limits` especificam a quantidade máxima de CPU e memória que um Pod ou contêiner pode usar. Se um contêiner tentar usar mais recursos do que os especificados nos `limits`, ele será restringido. Para a CPU, o contêiner será limitado ao valor máximo especificado. Para a memória, se o contêiner tentar usar mais do que o limite, ele será encerrado (killed) pelo Kubernetes. #### Exemplo de configuração de limits: ```yaml apiVersion: v1 kind: Pod metadata: name: example-pod spec: containers: - name: example-container image: nginx resources: limits: memory: '128Mi' cpu: '500m' ``` ### Configuração Completa de Requests e Limits Normalmente, `requests` e `limits` são configurados juntos para garantir que os contêineres tenham os recursos necessários para funcionar corretamente, mas sem consumir mais do que o necessário. #### Exemplo de configuração completa: ```yaml apiVersion: v1 kind: Pod metadata: name: example-pod spec: containers: - name: example-container image: nginx resources: requests: memory: '64Mi' cpu: '250m' limits: memory: '128Mi' cpu: '500m' ``` ## Considerações - **Planejamento de Capacidade**: Configurar `requests` e `limits` ajuda no planejamento de capacidade do cluster, garantindo que os recursos sejam alocados de maneira eficiente. - **Qualidade de Serviço (QoS)**: O Kubernetes usa `requests` e `limits` para determinar a classe de qualidade de serviço (QoS) de um Pod. Existem três classes de QoS: Guaranteed, Burstable e BestEffort. - **Prevenção de Sobrecarga**: Definir `limits` ajuda a prevenir que um único contêiner sobrecarregue o nó, afetando outros contêineres. Ao configurar `requests` e `limits`, é importante entender as necessidades dos seus aplicativos e ajustar os valores de acordo. Isso garante que os aplicativos tenham os recursos necessários para funcionar corretamente, enquanto mantém a eficiência do uso dos recursos do cluster. ## Importância de Configurar Requests e Limits no Kubernetes Configurar `requests` e `limits` no Kubernetes é crucial para garantir a eficiência e a estabilidade do cluster. Aqui estão alguns pontos importantes: - **Eficiência de Recursos**: Ao definir `requests`, você garante que os recursos mínimos necessários para os contêineres sejam reservados, evitando que eles sejam agendados em nós que não podem suportá-los. Isso ajuda a utilizar os recursos do cluster de maneira eficiente. - **Prevenção de Sobrecarga**: Definir `limits` impede que um contêiner consuma mais recursos do que o necessário, evitando que ele sobrecarregue o nó e afete outros contêineres. Isso é especialmente importante em ambientes compartilhados. - **Qualidade de Serviço (QoS)**: O Kubernetes usa `requests` e `limits` para determinar a classe de qualidade de serviço (QoS) de um Pod. Isso ajuda a priorizar recursos para contêineres críticos e garantir que eles tenham os recursos necessários para funcionar corretamente. - **Estabilidade das Aplicações**: Configurar `requests` e `limits` ajuda a garantir que as aplicações tenham os recursos necessários para funcionar de maneira estável, evitando falhas devido à falta de recursos. ## Comandos para Verificar Configurações de Requests e Limits Você pode usar os seguintes comandos `kubectl` para verificar as configurações de `requests` e `limits` dos Pods e contêineres no seu cluster: ### Verificar Requests e Limits de um Pod Específico: ```sh kubectl get pod -o jsonpath='{.spec.containers[*].resources}' ``` ### Listar Todos os Pods com Requests e Limits: ```sh kubectl get pods --all-namespaces -o custom-columns='NAMESPACE:.metadata.namespace,POD:.metadata.name,CONTAINER:.spec.containers[*].name,REQUESTS_CPU:.spec.containers[*].resources.requests.cpu,REQUESTS_MEMORY:.spec.containers[*].resources.requests.memory,LIMITS_CPU:.spec.containers[*].resources.limits.cpu,LIMITS_MEMORY:.spec.containers[*].resources.limits.memory' ``` ### Verificar a Classe de Qualidade de Serviço (QoS) de um Pod: ```sh kubectl get pod -o jsonpath='{.status.qosClass}' ``` ### Verificar Recursos de um Nó: ```sh kubectl describe node ``` Esses comandos ajudam a monitorar e garantir que os `requests` e `limits` estejam configurados corretamente, contribuindo para a eficiência e estabilidade do seu cluster Kubernetes. ## Comando `kubectl top nodes` Sim, você pode usar o comando `kubectl top nodes` para verificar os recursos disponíveis e o uso atual de CPU e memória em cada nó do cluster. Este comando fornece uma visão geral rápida do consumo de recursos no nível do nó. ### Comando `kubectl top nodes` ```sh kubectl top nodes ``` ### Exemplo de Saída ```plaintext NAME CPU(cores) CPU% MEMORY(bytes) MEMORY% node-1 500m 25% 1024Mi 50% node-2 300m 15% 512Mi 25% node-3 700m 35% 2048Mi 75% ``` ### Explicação - **NAME**: Nome do nó. - **CPU(cores)**: Uso atual de CPU em milicores. - **CPU%**: Porcentagem de uso da CPU em relação à capacidade total do nó. - **MEMORY(bytes)**: Uso atual de memória em bytes. - **MEMORY%**: Porcentagem de uso da memória em relação à capacidade total do nó. Este comando é útil para monitorar o uso de recursos e identificar possíveis gargalos ou nós sobrecarregados no cluster. # Ferramentas úteis sobre recursos no Kubernetes - [kube-capacity](https://github.com/robscott/kube-capacity): Uma CLI simples que fornece uma visão geral dos requests, limits e utilização de recursos em um cluster Kubernetes. - [kubectl-df-pv](https://github.com/yashbhutwala/kubectl-df-pv): Plugin do kubectl que oferece aos administradores uma utilidade semelhante ao `df` (disk free) para volumes persistentes. - [krr](https://github.com/robusta-dev/krr): Recomendações de recursos do Kubernetes baseadas no Prometheus. - [goldilocks](https://github.com/FairwindsOps/goldilocks): Obtenha seus requests de recursos "na medida certa". ## Referências - [Understanding Kubernetes Limits and Requests](https://sysdig.com/blog/kubernetes-limits-requests/) - [Kubernetes Requests and Limits: A Practical Guide and Solutions](https://blog.kubecost.com/blog/requests-and-limits/) - [Gerenciamento de recursos em Pods e contêineres](https://kubernetes.io/pt-br/docs/concepts/configuration/manage-resources-containers/) ## Linux e Testes de Hardware - URL: https://nataliagranato.xyz/blog/linux-e-os-testes-de-hardware - Data: 2025-01-30T00:00:00.000Z - Resumo: Neste guia forneço um passo a passo para realizar a instalação de ferramentas de testes de hardware para realização de testes de hardware, que nos permite verificar a saúde dos componentes dos nossos computadores. - Tags: linux, hardware, testes ## 1. Instalando as ferramentas de teste ### 1.1 Monitoramento de Temperatura e Voltagem (sensors) ```bash sudo apt install lm-sensors -y sudo sensors-detect ``` ### 1.2 Verificação de Saúde do Disco (smartctl) ```bash sudo apt install smartmontools -y ``` ### 1.3 Teste de Desempenho Gráfico (glmark2) ```bash sudo apt install glmark2 -y ``` ## 2. Execução de Testes de Hardware ### 2.1 Monitoramento de Temperatura e Voltagem ```bash sensors ``` ### 2.2 Verificação de Saúde do Disco ```bash sudo smartctl -a /dev/sda ``` ### 2.3 Teste de Desempenho Gráfico ```bash glmark2 ``` ## 3. Análise de Logs do Sistema ### 3.1 Visualização de Logs do Kernel ```bash dmesg ``` ### 3.2 Visualização de Logs do Systemd ```bash journalctl -xe ``` ## 4. Testes de Rede ### 4.1 Teste de Conexão ```bash ping google.com ``` ### 4.2 Teste de Velocidade ```bash sudo apt install speedtest-cli speedtest ``` ## 5. Testes de Memória ### 5.1 Instalação do memtest86+ ```bash sudo apt install memtest86+ ``` ### 5.2 Execução do Teste de Memória Reinicie o sistema e selecione memtest86+ no menu de boot. ## 6. Testes de CPU ### 6.1 Instalação do stress ```bash sudo apt install stress ``` ### 6.2 Execução de Teste de Estresse ```bash stress --cpu 4 --timeout 60s ``` Recentemente me deparei com um problema no meu desktop, que estava reiniciando sem parar e precisei descobrir o que estava causando isso, então decidi realizar testes nos principais componentes do computador para descobrir o que estava causando o problema. No fim o problema estava relacionado a um defeito de um slot de memória RAM na placa mãe. ## Monitoramento do Consumo de Energia de Contêineres com Kepler - URL: https://nataliagranato.xyz/blog/kepler-monitorando-energia-kubernetes - Data: 2025-01-01T00:00:00.000Z - Resumo: Kepler (Exportador Eficiente de Nível de Energia baseado em Kubernetes) utiliza eBPF para coletar estatísticas do sistema relacionadas à energia e as exporta como métricas do Prometheus. - Tags: kepler, sustentabilidade, kubernetes O Brasil é um dos países com a energia mais cara do mundo. O consumo de energia é um dos principais custos de operação de data centers e servidores. Monitorar o consumo de energia de contêineres em um cluster Kubernetes pode ajudar a reduzir custos e melhorar a eficiência energética. # O que é o Kepler? Kepler (Exportador Eficiente de Nível de Energia baseado em Kubernetes) utiliza eBPF para coletar estatísticas do sistema relacionadas à energia e as exporta como métricas do Prometheus. ## Monitoramento do Consumo de Energia de Contêineres com Kepler O Exportador Kepler expõe estatísticas de uma aplicação em execução em um cluster Kubernetes em um formato compatível com o Prometheus, que pode ser acessado por qualquer banco de dados que entenda esse formato, como Prometheus e Sysdig. O Exporter do Kepler expõe uma variedade de métricas sobre o consumo de energia de componentes do Kubernetes, como Pods e Nodes. Com ele é possível monitorar o consumo de energia contêineres com as métricas disponibilizadas pelo Exporter Kepler. ![Kepler Exporter](https://raw.githubusercontent.com/sustainable-computing-io/kepler/main/doc/kepler-arch.png) Todas as métricas específicas do Exporter Kepler têm o prefixo **kepler**. --- ## Métricas do Kepler para Consumo de Energia de Contêineres ### **kepler_container_joules_total (Counter)** Essa métrica representa o consumo agregado de energia dos componentes CPU, DRAM, GPUs e outros do host para um determinado contêiner. Cada componente possui métricas individuais detalhadas mais adiante. Essa métrica simplifica as métricas do Prometheus para melhorar o desempenho, evitando consultas muito extensas que podem causar sobrecarga significativa. ### **kepler_container_core_joules_total (Counter)** Mede o consumo total de energia nos núcleos da CPU usados por um contêiner. - **RAPL disponível**: Reflete o consumo proporcional de energia dos núcleos do processador. - **RAPL indisponível**: O Kepler pode estimar essa métrica usando o servidor de modelos. ### **kepler_container_dram_joules_total (Counter)** Descreve a energia total consumida na DRAM por um contêiner. ### **kepler_container_uncore_joules_total (Counter)** Mede o consumo cumulativo de energia por componentes "uncore", como cache de último nível, GPU integrada e controlador de memória. Dependendo do sistema, esta métrica pode não estar disponível. ### **kepler_container_package_joules_total (Counter)** Representa o consumo cumulativo de energia no soquete da CPU, incluindo todos os núcleos e componentes "uncore". Caso o RAPL não esteja disponível, o Kepler pode estimar essa métrica. ### **kepler_container_other_joules_total (Counter)** Mede o consumo cumulativo de energia em outros componentes do host além da CPU e DRAM. Utiliza sensores de energia disponíveis via kernel ACPI ou IPMI. ### **kepler_container_gpu_joules_total (Counter)** Mede o consumo total de energia em GPUs usadas por um contêiner. - Atualmente, suporta GPUs NVIDIA e usa o pacote NVML para calcular o consumo energético. ### **kepler_container_energy_stat (Counter)** Contém diversas métricas de energia do contêiner, rotuladas com métricas de utilização de recursos, usadas para previsões no servidor de modelos. --- ## Métricas do Kepler para Utilização de Recursos de Contêineres ### **Base Metric** - **kepler_container_bpf_cpu_time_us_total** Mede o tempo total de CPU usado pelo contêiner por meio de rastreamento BPF. ### **Hardware Counter Metrics** - **kepler_container_cpu_cycles_total**: Mede ciclos de CPU usados. - **kepler_container_cpu_instructions_total**: Mede instruções de CPU usadas. - **kepler_container_cache_miss_total**: Mede falhas de cache de último nível. ### **IRQ Metrics** - **kepler_container_bpf_net_tx_irq_total**: Mede pacotes transmitidos. - **kepler_container_bpf_net_rx_irq_total**: Mede pacotes recebidos. - **kepler_container_bpf_block_irq_total**: Mede chamadas de E/S em bloco. --- ## Métricas do Kepler para Informação de Nós ### **kepler_node_info (Counter)** Exibe metadados do nó, como a arquitetura do CPU. --- ## Métricas do Kepler para Consumo de Energia em Nós - **kepler_node_core_joules_total**: Consumo total dos núcleos da CPU. - **kepler_node_uncore_joules_total**: Consumo de componentes "uncore". - **kepler_node_dram_joules_total**: Consumo de energia na DRAM. - **kepler_node_package_joules_total**: Consumo total do soquete da CPU. - **kepler_node_other_joules_total**: Consumo de outros componentes do host. - **kepler_node_gpu_joules_total**: Consumo total das GPUs. - **kepler_node_platform_joules_total**: Consumo total de energia do host. --- ## Explorando Métricas no Prometheus As métricas de consumo de energia são definidas como contadores. O uso da função **rate()** pode transformar o consumo em energia por segundo (Watts). Por exemplo: ```promQL sum by (pod_name, container_name, container_namespace, node)(irate(kepler_container_joules_total{}[1m])) ``` ## Iniciando o nosso laboratório Vamos criar um cluster Kubernetes local com o [Kind](https://kind.sigs.k8s.io/), instalar o Kepler e monitorar o consumo de energia de contêineres. Crie um arquivo chamado `kind.yaml` com o seguinte conteúdo: ```yaml kind: Cluster apiVersion: kind.x-k8s.io/v1alpha4 nodes: - role: worker - role: worker - role: worker - role: control-plane kubeadmConfigPatches: - | kind: InitConfiguration nodeRegistration: kubeletExtraArgs: node-labels: "ingress-ready=true" extraPortMappings: - containerPort: 80 hostPort: 80 protocol: TCP - containerPort: 443 hostPort: 443 protocol: TCP ``` Execute o comando abaixo para criar o cluster: ```bash kind create cluster --config kind.yaml ``` Obtenha o kubeconfig do cluster: ```bash kind get kubeconfig > kubeconfig.yaml export KUBECONFIG=$(pwd)/kubeconfig.yaml ``` Utilizaremos o **Kube Prometheus Stack** para instalar o Prometheus, Grafana e Alertmanager. Execute o comando abaixo para instalar o Kube Prometheus Stack: ```bash helm repo add prometheus-community https://prometheus-community.github.io/helm-charts helm repo update helm install prometheus prometheus-community/kube-prometheus-stack \ --namespace monitoring \ --create-namespace \ --wait ``` Instale o Kepler no cluster: ```bash helm repo add kepler https://sustainable-computing-io.github.io/kepler-helm-chart helm repo update helm install kepler kepler/kepler \ --namespace kepler \ --create-namespace \ --set serviceMonitor.enabled=true \ --set serviceMonitor.labels.release=prometheus \ ``` Acesse o Prometheus e Grafana: ```bash kubectl port-forward -n monitoring svc/prometheus-grafana 3000:80 kubectl port-forward -n monitoring svc/prometheus-kube-prometheus-prometheus 9091:9090 kubectl port-forward -n kepler svc/kepler 9102 ``` Acesse o Grafana em http://localhost:3000 com usuário `admin` e senha `prom-operator`. E importe a dashboard do Kepler disponível em [Kepler Exporter Dashboard](https://github.com/sustainable-computing-io/kepler/blob/main/grafana-dashboards/Kepler-Exporter.json). Agora você pode explorar as métricas do Kepler no Prometheus e Grafana. ![Kepler Dashboard](https://www.wonderingchimp.com/content/images/2024/06/Pasted-image-20240601105840.png) A partir de agora, você pode monitorar o consumo de energia de contêineres no seu cluster Kubernetes com o Kepler. Conheça o grupo de trabalho da CNCF sobre sustentabilidade em TI: [Sustainable Computing](https://github.com/cncf/tag-env-sustainability) --- Este artigo foi baseado no projeto [Kepler](https://github.com/sustainable-computing-io/kepler). Acesse o repositório para mais informações sobre o projeto. ## Escalando Aplicações Nativas em Nuvem com KEDA - URL: https://nataliagranato.xyz/blog/keda - Data: 2024-10-28T00:00:00.000Z - Resumo: KEDA é um projeto de código aberto projetado para estender o Kubernetes, capacitando os desenvolvedores a escalarem suas aplicações de forma contínua em resposta a cargas de trabalho variáveis desencadeadas por eventos. - Tags: kubernetes, keda, scaling ## O que é o KEDA? No mundo Cloud Native estamos em constantes mudanças, a escalabilidade é uma preocupação importante. O Kubernetes, como uma plataforma de orquestração de contêineres, aborda muitos desafios, e pode exigir ferramentas adicionais para scaling eficiente e automatizado. É aqui que o Kubernetes Event-Driven Autoscaling (KEDA) surge como uma solução. KEDA é um projeto de código aberto projetado para estender o Kubernetes, capacitando os desenvolvedores a escalarem suas aplicações de forma contínua em resposta a cargas de trabalho variáveis desencadeadas por eventos. Esses eventos podem variar desde mudanças na profundidade das filas de mensagens até solicitações HTTP recebidas ou métricas definidas pelo usuário. O KEDA atua como uma ponte entre o Kubernetes e as fontes de eventos, permitindo o escalonamento automático de cargas de trabalho em contêineres. A natureza agnóstica do KEDA em relação a fornecedores capacita os desenvolvedores, independentemente da escolha do provedor de nuvem. Essa flexibilidade o torna uma opção atraente para desenvolvedores que constroem aplicações orientadas a eventos em ambientes de nuvem. Ao integrar o KEDA em suas aplicações, os desenvolvedores podem garantir a utilização ideal dos recursos, eficiência de custos e capacidade de resposta às demandas em tempo real. Antes de falar sobre o KEDA e suas funcionalidades, vamos dar um passo atrás e entender a necessidade de escalonamento automático e quais opções temos no Kubernetes para escalar nossas cargas de trabalho. ## O que é Autoscaling? Autoscaling, em geral, refere-se à capacidade de um sistema de ajustar automaticamente seus recursos, como poder de computação, armazenamento ou largura de banda de rede, com base na carga de trabalho ou demanda atual. Esse conceito é particularmente importante na computação em nuvem e em sistemas nativos em nuvem, onde as cargas de trabalho podem variar significativamente ao longo do tempo. Autoscaling é um conceito fundamental em ciência da computação que desempenha um papel crucial na construção de sistemas flexíveis, eficientes e resilientes, capazes de se adaptar às demandas em mudança e garantir desempenho e custo-efetividade ótimos. O autoscaling no Kubernetes estende essa automação para ajustar dinamicamente o número de instâncias em execução (pods) com base no uso de recursos e outras métricas. ## Horizontal Pod Autoscaling (HPA) É um recurso da API do Kubernetes e um controlador pertencente à versão de API `autoscaling/v2`, atualiza automaticamente um recurso de carga de trabalho, como um Deployment ou StatefulSet, com o objetivo de escalar automaticamente a carga de trabalho para corresponder à demanda. A escalabilidade horizontal envolve a implantação de mais Pods para responder ao aumento da carga. Se a carga diminuir e o número de Pods estiver acima do mínimo configurado, o `HorizontalPodAutoscaler` instrui o recurso de carga de trabalho, seja Deployment, StatefulSet ou outro recurso semelhante, a reduzir a escala. O controlador Horizontal Pod Autoscaling, executado dentro do control pĺane do Kubernetes, ajusta periodicamente a escala desejada de seu alvo (para cima ou para baixo) para corresponder às métricas observadas, como utilização média de CPU, utilização média de memória ou qualquer outra métrica personalizada que você especificar. ## A necessidade do KEDA O KEDA tem uma importância significativa no ambiente moderno de aplicações nativas em nuvem, abordando a necessidade de escalonamento granular e dinâmico com base em eventos em tempo real. Diferente das soluções tradicionais de escalonamento, o KEDA vai além do Horizontal Pod Autoscaler (HPA) padrão, oferecendo uma abordagem mais versátil para atender às demandas de cargas de trabalho acionadas por eventos. O KEDA permite que as aplicações escalem com base em eventos específicos, como mudanças na profundidade da fila, em vez de depender exclusivamente de métricas como uso de CPU ou memória. Isso garante uma estratégia de escalonamento mais responsiva e eficiente, alinhada com as necessidades reais da aplicação. Ao permitir que as aplicações escalem com base em métricas personalizadas e eventos externos, o KEDA facilita a utilização ideal dos recursos. Isso é crucial para provedores de serviços em nuvem, como aqueles que operam em provedores de nuvem pública, onde a relação custo-benefício e o desempenho são preocupações primárias. O KEDA suporta uma ampla gama de fontes de eventos, desde Azure Queues até RabbitMQ e Kafka. Essa flexibilidade o torna adaptável a diversas arquiteturas e cenários de aplicação, proporcionando aos desenvolvedores a liberdade de escolher a fonte de eventos mais adequada para seu caso de uso. ## Comparação entre KEDA e HPA Enquanto o Horizontal Pod Autoscaler (HPA) é um recurso nativo do Kubernetes que escala com base em métricas como uso de CPU e memória, ele pode ser insuficiente em cenários onde eventos impulsionam mudanças na carga de trabalho. ### KEDA vs. HPA | Critério | KEDA | HPA | | ---------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------- | | **Trigger de Escalonamento** | Orientado por eventos, permitindo escalonamento com base em métricas personalizadas ou eventos externos. | Orientado por métricas, tipicamente escalando com base na utilização de CPU ou memória. | | **Versatilidade** | Altamente versátil, suportando uma ampla gama de fontes de eventos. | Limitado ao escalonamento com base em métricas diretamente associadas aos pods. | | **Casos de Uso** | Ideal para aplicações com cargas de trabalho variáveis acionadas por eventos, como profundidade de filas de mensagens ou gatilhos externos. | Bem adequado para aplicações com necessidades de escalonamento previsíveis com base em métricas de recursos padrão. | A capacidade do KEDA de fornecer escalonamento orientado por eventos complementa o HPA, oferecendo aos desenvolvedores um conjunto de ferramentas poderoso para abordar um espectro mais amplo de requisitos de escalonamento no ambiente dinâmico de nuvem atual. ## Um Exemplo Vamos considerar um cenário teórico onde um provedor de serviços em nuvem, que utiliza uma nuvem popular para sua infraestrutura, enfrenta um desafio com o processamento eficiente de mensagens de uma fila de mensagens. A aplicação responsável por processar essas mensagens experimenta cargas de trabalho variáveis com base na taxa de mensagens recebidas. ### Cenário: Serviço de Processamento de Mensagens com Carga de Trabalho Variável O provedor de serviços em nuvem tem um componente crítico em sua arquitetura que processa mensagens de uma fila de mensagens. A carga de trabalho desse serviço de processamento varia ao longo do dia, com picos de tempo em que a taxa de mensagens recebidas aumenta significativamente. Durante esses períodos de pico, a implantação existente luta para lidar com o volume de forma eficiente, levando a um aumento na latência e ao potencial de atrasos no processamento de mensagens. Os dois desafios mais comuns são a utilização ineficiente de recursos e a latência e atrasos. A utilização ineficiente de recursos ocorre devido à configuração estática da implantação atual do serviço de processamento de mensagens, levando à subutilização durante períodos de tráfego baixo e sobrecarga durante os períodos de pico. A razão para a latência e atrasos é que a implantação fixa causa atrasos no processamento de mensagens durante os períodos de pico, impactando a capacidade de resposta geral do sistema. O KEDA oferece uma solução para escalar dinamicamente o serviço de processamento de mensagens com base na carga de trabalho real, abordando esses desafios. ### Benefícios de usar o KEDA | Benefício | Descrição | | ----------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Escalonamento Dinâmico com Base na Profundidade da Fila** | Integrando o KEDA, o provedor de serviços em nuvem configura o sistema para escalar dinamicamente o serviço de processamento de mensagens com base na profundidade da fila de mensagens. O KEDA permite que a implantação escale automaticamente para cima ou para baixo em resposta às mudanças no número de mensagens aguardando na fila. | | **Utilização Ótima de Recursos** | Quando o tráfego de mensagens é baixo, o KEDA garante que a implantação seja reduzida, economizando recursos e cortando custos ao minimizar o uso de poder computacional desnecessário. Por outro lado, durante os períodos de pico, o KEDA escala rapidamente a implantação para lidar com as cargas de mensagens aumentadas, otimizando a utilização de recursos. | | **Melhoria na Capacidade de Resposta** | Com o KEDA, o serviço de processamento de mensagens pode manter baixa latência mesmo durante os períodos de pico. À medida que a profundidade da fila cresce, o KEDA aciona o escalonamento da implantação, garantindo que haja instâncias suficientes do serviço de processamento para lidar com as mensagens recebidas prontamente. | | **Eficiência de Custos** | O escalonamento dinâmico fornecido pelo KEDA ajuda a alcançar eficiência de custos ao alinhar o consumo de recursos com a demanda real. Isso é crucial para um provedor de serviços em nuvem, pois impacta diretamente os custos operacionais. | ## Componentes Principais do KEDA ### Como o KEDA Funciona O KEDA é um componente leve e de propósito único que pode ser adicionado a qualquer cluster Kubernetes. O KEDA pode expandir a funcionalidade sem sobrescrever ou duplicar componentes existentes quando usado em conjunto com outros componentes padrão do Kubernetes, como o Horizontal Pod Autoscaler. Com o KEDA, você pode mapear aplicações diretamente para uma escala orientada por eventos enquanto mantém outras aplicações operacionais. Por causa disso, o KEDA pode ser usado de forma segura e adaptável com qualquer número de outros frameworks ou aplicações Kubernetes. Existem três funções principais que o KEDA desempenha em um cluster Kubernetes: 1. **Agente**: O KEDA permite que as implantações do Kubernetes escalem para zero e a partir de zero na ausência de eventos. O contêiner `keda-operator` é responsável por isso no cluster. Ele é executado após o KEDA ser habilitado no cluster. 2. **Métricas**: O KEDA expõe diretamente métricas como atraso de fluxo e comprimento da fila de mensagens para o HPA, permitindo que ele escale as implantações com base nas métricas obtidas. Assim, o KEDA também atua como um servidor de métricas do Kubernetes. O contêiner `keda-operator-metrics-apiserver` é responsável por esse serviço de métricas. 3. **Admission Webhooks**: O KEDA pode ser usado em conjunto com um controlador de admissão para detectar automaticamente mudanças na configuração de recursos, mantendo as implantações e o cluster em um estado estável. Ele também preserva um alvo de escala de ser escalado por múltiplos `ScaledObjects`. ## Arquitetura do KEDA O KEDA integra-se com o já mencionado Horizontal Pod Autoscaler no Kubernetes. Componentes como fontes de eventos externas e o armazenamento de dados etcd também são usados para ler eventos no cluster e escalar conforme necessário. Aqui está uma representação visual da arquitetura: ![Arquitetura do KEDA](https://d36ai2hkxl16us.cloudfront.net/course-uploads/e0df7fbf-a057-42af-8a1f-590912be5460/ubfs7ii23wye-LFEL10144x.png) Na imagem acima, o recurso `ScaledObject` define como um alvo de escala, como uma implantação, recursos personalizados, jobs ou StatefulSets, deve ser escalado pelo KEDA. O "bloco KEDA" trabalha com uma fonte de eventos externa, monitorando-a para eventos que devem acionar a escalabilidade do recurso alvo. O KEDA transfere a solicitação de escalonamento para o HPA, que escala a carga de trabalho. Um "escalador" detecta se uma implantação deve ser ativada ou desativada e fornece métricas personalizadas para uma fonte de eventos específica. Existem vários escaladores disponíveis dependendo das fontes de eventos externas e das métricas do cluster. Alguns exemplos de fontes de eventos suportadas são: Google Cloud Platform Storage, memória, Redis, PostgreSQL, entre outros. ## Definições de Recursos Personalizados (CRDs) do KEDA O Kubernetes vem com um conjunto de recursos de API que permite aos usuários criar objetos como pods, deployments e jobs. Quando o KEDA é instalado em um cluster Kubernetes, ele vem com quatro Definições de Recursos Personalizados (CRDs) como parte da instalação do KEDA. Esses CRDs funcionam de maneira semelhante a outros recursos de API, permitindo que os usuários mapeiem fontes de eventos. Eles permitem a autenticação para acessar eventos dessas fontes e suportam o escalonamento de alvos como Deployments, StatefulSets, Jobs ou outros recursos personalizados. ### CRDs do KEDA #### scaledobjects.keda.sh [`ScaledObjects`](command:_github.copilot.openSymbolFromReferences?%5B%22%22%2C%5B%7B%22uri%22%3A%7B%22scheme%22%3A%22file%22%2C%22authority%22%3A%22%22%2C%22path%22%3A%22%2Fhome%2Fnataliagranato%2FDownloads%2Fnataliagranato.github.io%2Fdata%2Fblog%2Fescalando-apps-nativas-em-nuvem-com-keda.mdx%22%2C%22query%22%3A%22%22%2C%22fragment%22%3A%22%22%7D%2C%22pos%22%3A%7B%22line%22%3A100%2C%22character%22%3A288%7D%7D%5D%2C%22bae0cab4-2d92-4a2b-a74d-4a6f1428c9f1%22%5D 'Go to definition') define como o KEDA deve escalar uma implantação ou carga de trabalho específica. A configuração para [`ScaledObjects`](command:_github.copilot.openSymbolFromReferences?%5B%22%22%2C%5B%7B%22uri%22%3A%7B%22scheme%22%3A%22file%22%2C%22authority%22%3A%22%22%2C%22path%22%3A%22%2Fhome%2Fnataliagranato%2FDownloads%2Fnataliagranato.github.io%2Fdata%2Fblog%2Fescalando-apps-nativas-em-nuvem-com-keda.mdx%22%2C%22query%22%3A%22%22%2C%22fragment%22%3A%22%22%7D%2C%22pos%22%3A%7B%22line%22%3A100%2C%22character%22%3A288%7D%7D%5D%2C%22bae0cab4-2d92-4a2b-a74d-4a6f1428c9f1%22%5D 'Go to definition') inclui os seguintes elementos principais: - **scaleTargetRef**: Especifica a implantação ou carga de trabalho alvo que o KEDA irá escalar. - **triggers**: Define as fontes de eventos e os parâmetros correspondentes que acionam o escalonamento automático. - **minReplicaCount** e **maxReplicaCount**: Especificam o número mínimo e máximo de réplicas para a carga de trabalho alvo. Exemplo de código de [`ScaledObject`](command:_github.copilot.openSymbolFromReferences?%5B%22%22%2C%5B%7B%22uri%22%3A%7B%22scheme%22%3A%22file%22%2C%22authority%22%3A%22%22%2C%22path%22%3A%22%2Fhome%2Fnataliagranato%2FDownloads%2Fnataliagranato.github.io%2Fdata%2Fblog%2Fescalando-apps-nativas-em-nuvem-com-keda.mdx%22%2C%22query%22%3A%22%22%2C%22fragment%22%3A%22%22%7D%2C%22pos%22%3A%7B%22line%22%3A109%2C%22character%22%3A28%7D%7D%5D%2C%22bae0cab4-2d92-4a2b-a74d-4a6f1428c9f1%22%5D 'Go to definition'): ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: my-scaledobject spec: scaleTargetRef: name: my-deployment triggers: - type: azure-queue metadata: queueName: my-queue connection: azure-secret queueLength: '5' minReplicaCount: 1 maxReplicaCount: 10 ``` #### scaledjobs.keda.sh `ScaledJob` é um recurso personalizado projetado para escalonamento automático de Jobs do Kubernetes. Semelhante ao [`ScaledObject`](command:_github.copilot.openSymbolFromReferences?%5B%22%22%2C%5B%7B%22uri%22%3A%7B%22scheme%22%3A%22file%22%2C%22authority%22%3A%22%22%2C%22path%22%3A%22%2Fhome%2Fnataliagranato%2FDownloads%2Fnataliagranato.github.io%2Fdata%2Fblog%2Fescalando-apps-nativas-em-nuvem-com-keda.mdx%22%2C%22query%22%3A%22%22%2C%22fragment%22%3A%22%22%7D%2C%22pos%22%3A%7B%22line%22%3A109%2C%22character%22%3A28%7D%7D%5D%2C%22bae0cab4-2d92-4a2b-a74d-4a6f1428c9f1%22%5D 'Go to definition'), ele define `scaleTargetRef` e `triggers` específicos para Jobs. Ele também permite o escalonamento automático com base em eventos de conclusão ou falha de jobs. Exemplo de código de `ScaledJob`: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledJob metadata: name: my-scaledjob spec: scaleTargetRef: name: my-job triggers: - type: job-completion ``` #### triggerauthentications.keda.sh `TriggerAuthentication` é usado para proteger a comunicação entre o KEDA e as fontes de eventos externas. Ele garante que apenas fontes autenticadas possam acionar o escalonamento automático. A configuração requer detalhes de autenticação, como chaves de API e segredos para as fontes de eventos externas. Exemplo de código de `TriggerAuthentication`: ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: my-triggerauth spec: secretTargetRef: - parameter: apiKey name: my-secret key: api-key ``` #### clustertriggerauthentications.keda.sh Semelhante ao `TriggerAuthentication`, mas aplicado ao nível do cluster. É usado quando você deseja compartilhar detalhes de autenticação entre vários [`ScaledObjects`](command:_github.copilot.openSymbolFromReferences?%5B%22%22%2C%5B%7B%22uri%22%3A%7B%22scheme%22%3A%22file%22%2C%22authority%22%3A%22%22%2C%22path%22%3A%22%2Fhome%2Fnataliagranato%2FDownloads%2Fnataliagranato.github.io%2Fdata%2Fblog%2Fescalando-apps-nativas-em-nuvem-com-keda.mdx%22%2C%22query%22%3A%22%22%2C%22fragment%22%3A%22%22%7D%2C%22pos%22%3A%7B%22line%22%3A100%2C%22character%22%3A288%7D%7D%5D%2C%22bae0cab4-2d92-4a2b-a74d-4a6f1428c9f1%22%5D 'Go to definition'). Sua configuração define detalhes de autenticação como `TriggerAuthentication`, mas é aplicável no escopo do cluster. Exemplo de código de `ClusterTriggerAuthentication`: ```yaml apiVersion: keda.sh/v1alpha1 kind: ClusterTriggerAuthentication metadata: name: my-cluster-triggerauth spec: secretTargetRef: - parameter: apiKey name: my-secret key: api-key ``` Esses recursos coletivamente permitem a configuração de escalonamento automático dinâmico e orientado por eventos em um ambiente Kubernetes usando o KEDA. ## Configurando e Removendo o KEDA ### Instalação do KEDA O KEDA pode ser implantado por vários métodos: usando o Operator Hub, um arquivo YAML ou o Helm chart. Aqui, focaremos na implantação via Helm. É importante notar que o KEDA requer um cluster Kubernetes versão 1.24 ou superior. Como qualquer outra implantação Helm, isso envolve apenas três etapas simples: 1. Adicionar o repositório Helm: ```sh helm repo add kedacore https://kedacore.github.io/charts ``` 2. Atualizar o repositório Helm: ```sh helm repo update ``` 3. Instalar o Helm chart do KEDA: ```sh helm upgrade --install keda kedacore/keda --namespace keda --create-namespace ``` Após instalar o KEDA, você pode verificar se ele foi instalado corretamente usando o comando `helm status`. Aqui está um exemplo de como fazer isso: 4. **Verifique o status da instalação do KEDA:** ```sh helm status keda --namespace keda ``` A saída esperada deve ser semelhante a esta: ```plaintext NAME: keda LAST DEPLOYED: Sun Oct 27 16:46:01 2024 NAMESPACE: keda STATUS: deployed REVISION: 1 TEST SUITE: None Kubernetes Event-driven Autoscaling (KEDA) - Application autoscaling made simple. Get started by deploying Scaled Objects to your cluster: - Information about Scaled Objects : https://keda.sh/docs/latest/concepts/ - Samples: https://github.com/kedacore/samples Get information about the deployed ScaledObjects: kubectl get scaledobject [--namespace my-namespace] Get details about a deployed ScaledObject: kubectl describe scaledobject scaled-object-name [--namespace my-namespace] Get information about the deployed ScaledObjects: kubectl get triggerauthentication [--namespace my-namespace] Get details about a deployed ScaledObject: kubectl describe triggerauthentication trigger-authentication-name [--namespace my-namespace] Get an overview of the Horizontal Pod Autoscalers (HPA) that KEDA is using behind the scenes: kubectl get hpa [--all-namespaces] [--namespace my-namespace] Learn more about KEDA: - Documentation: https://keda.sh/ - Support: https://keda.sh/support/ - File an issue: https://github.com/kedacore/keda/issues/new/choose ``` ### Desinstalando o KEDA Para desinstalar o KEDA, siga os dois passos abaixo: 1. **Remova quaisquer ScaledObjects e ScaledJobs que você tenha criado:** ```sh kubectl delete $(kubectl get scaledobjects.keda.sh,scaledjobs.keda.sh -A -o jsonpath='{"-n "}{.items[*].metadata.namespace}{" "}{.items[*].kind}{"/"}{.items[*].metadata.name}{"\n"}') ``` 2. **Desinstale o Helm chart:** ```sh helm uninstall keda -n keda ``` ### Desinstalando o KEDA Para desinstalar o KEDA, siga os dois passos abaixo: 1. **Remova quaisquer ScaledObjects e ScaledJobs que você tenha criado:** ```sh kubectl delete $(kubectl get scaledobjects.keda.sh,scaledjobs.keda.sh -A -o jsonpath='{range .items[*]}-n {.metadata.namespace} {.kind}/{.metadata.name}{"\n"}{end}') ``` 2. **Desinstale o Helm chart:** ```sh helm uninstall keda -n keda ``` Este artigo foi traduzido e adaptado do curso gratuito da Linux Foundation [Scaling Cloud Native Applications with KEDA](https://training.linuxfoundation.org/express-learning/scaling-cloud-native-applications-with-keda-lfel1014/). ### Fontes Utilizadas: - [Documentação Oficial do KEDA](https://keda.sh/docs/latest/) - [Repositório GitHub do KEDA](https://github.com/kedacore/keda) - [Curso da Linux Foundation: Scaling Cloud Native Applications with KEDA](https://training.linuxfoundation.org/express-learning/scaling-cloud-native-applications-with-keda-lfel1014/) ## Fundamentos de Scalers do KEDA - URL: https://nataliagranato.xyz/blog/fundamentos-de-scalers-do-keda - Data: 2024-10-27T00:00:00.000Z - Resumo: KEDA é um projeto de código aberto projetado para estender o Kubernetes, capacitando os desenvolvedores a escalarem suas aplicações de forma contínua em resposta a cargas de trabalho variáveis desencadeadas por eventos. - Tags: kubernetes, keda, scaling ## O que são os scalers? Os scalers do KEDA são objetos que ajudam suas aplicações a funcionarem sem problemas enquanto economizam recursos. Esses componentes inteligentes atuam como mecanismos de escalonamento automático orientados por eventos, reagindo a sinais externos e instruindo suas implantações a escalarem para cima ou para baixo conforme necessário. Pense neles como guardas vigilantes, constantemente monitorando o ambiente e acionando ações de escalonamento com base em regras predefinidas. Vamos verificar como eles funcionam. ## O que os Scalers do KEDA Fazem? Os scalers do KEDA oferecem várias vantagens em comparação com os autoscalers tradicionais. Em vez de depender de métricas internas, o KEDA responde a eventos externos. Os scalers do KEDA oferecem uma abordagem mais responsiva e adaptável a ambientes dinâmicos. ### Vantagens dos Scalers do KEDA #### Reagem a eventos externos Ao contrário dos autoscalers tradicionais baseados em recursos, os scalers do KEDA dependem de "eventos" externos (pense neles como sinais de diferentes fontes) para acionar ajustes. Esses eventos podem vir de várias fontes, como filas de mensagens, bancos de dados, sistemas de monitoramento ou até mesmo serviços personalizados. #### Conduzem o escalonamento dinâmico Com base nos dados dos eventos, os scalers do KEDA determinam a ação de escalonamento apropriada. Isso pode envolver aumentar ou diminuir o número de réplicas dentro da sua implantação, ajustar os limites de recursos dos contêineres ou até mesmo pausar implantações quando a demanda diminui. #### Oferecem estratégias de escalonamento personalizáveis Você tem controle total sobre como suas aplicações respondem aos eventos. Os scalers do KEDA permitem que você defina limites, regras de escalonamento e até mesmo janelas de tempo para acionar ações, garantindo respostas precisas e adaptáveis. ### Exemplos de Scalers do KEDA em Ação - **Escalonamento de um servidor web com base no tráfego HTTP**: Imagine um scaler do KEDA monitorando as solicitações HTTP recebidas. Quando o tráfego aumenta, o scaler aumenta automaticamente o número de réplicas do servidor para lidar com a carga. - **Processamento de um backlog de jobs com KEDA e Kafka**: Um scaler conectado a uma fila Kafka pode acionar o escalonamento de uma aplicação de trabalho com base no número de mensagens pendentes, garantindo um processamento eficiente dos jobs. - **Ajuste de recursos do banco de dados com base na carga de consultas**: Um scaler do KEDA monitorando métricas do banco de dados pode alocar dinamicamente recursos para sua instância de banco de dados à medida que o volume de consultas aumenta, prevenindo a degradação do desempenho. ## Explorando Scalers Populares do KEDA Até abril de 2024, existiam mais de 60 scalers no ecossistema KEDA, incluindo opções integradas e externas. Os seguintes scalers estão entre os mais comumente usados, graças à sua capacidade de trabalhar com plataformas e serviços amplamente adotados em vários ambientes, proporcionando opções de escalonamento flexíveis e dinâmicas para implantações Kubernetes. ### Scalers Populares do KEDA | Scaler | Descrição | | ------------------------- | ---------------------------------------------------------------------------------------------- | | **HTTP Scaler** | Escala com base no número de conexões HTTP ativas. | | **Azure Queue Scaler** | Escala com base no comprimento de uma fila do Azure. | | **Kafka Scaler** | Escala com base em métricas de tópicos Kafka, como atraso ou número de mensagens em um tópico. | | **RabbitMQ Scaler** | Escala com base no número de mensagens em uma fila RabbitMQ. | | **AWS CloudWatch Scaler** | Escala com base em métricas do AWS CloudWatch. | | **Prometheus Scaler** | Escala com base em uma consulta a um servidor Prometheus. | | **MySQL Scaler** | Escala com base em uma consulta a um banco de dados MySQL. | | **Cron Scaler** | Escala com base em uma programação Cron, útil para escalonamento baseado em tempo. | Cada scaler é implementado como um recurso personalizado no Kubernetes, e você o define em seus arquivos de manifesto do Kubernetes (YAML). Por exemplo, se você quiser escalar uma implantação com base no comprimento de uma fila do Azure Service Bus, você definiria um `ScaledObject` em seu arquivo YAML do Kubernetes que referencia o scaler do Azure Service Bus. Esse scaler então monitoraria a fila e ajustaria o número de pods em sua implantação com base no número de mensagens na fila. A flexibilidade do KEDA reside em sua capacidade de se integrar com uma ampla variedade de fontes de eventos e métricas, tornando-o uma ferramenta versátil para escalonamento automático no Kubernetes. Isso permite que desenvolvedores e equipes de operações garantam que as aplicações sejam escaladas precisamente de acordo com a demanda, otimizando o uso de recursos e custos. ## Melhores Práticas do KEDA Para aproveitar ao máximo as capacidades do KEDA, é recomendável seguir um conjunto de melhores práticas. Essas recomendações ajudam a otimizar o escalonamento automático em seu ambiente de nuvem, aumentando a eficácia do KEDA. ### Melhores Práticas no Uso do KEDA | Prática | Descrição | | ------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Compreenda a Fonte de Eventos** | Conhecimento Profundo da Integração: Tenha um entendimento completo da fonte de eventos (por exemplo, fila de mensagens, banco de dados, etc.) que aciona o escalonamento. Esse conhecimento ajuda a configurar corretamente o KEDA para responder às métricas ou eventos certos. Seleção Apropriada de Métricas: Escolha métricas que reflitam com precisão a carga e a necessidade de escalonamento. Por exemplo, em uma fila de mensagens, o número de mensagens pode ser uma métrica mais relevante do que a idade da mensagem mais antiga. | | **Teste de Escalabilidade** | Teste de Desempenho: Antes de implantar em produção, teste como sua aplicação escala sob diferentes cargas. Isso ajuda a ajustar os parâmetros de escalonamento. Simule Eventos: Use ferramentas para simular a carga da fonte de eventos para entender como o KEDA reagirá em vários cenários. | | **Otimize os Parâmetros de Escalamento** | Períodos de Resfriamento: Configure períodos de resfriamento apropriados para evitar ações de escalonamento muito frequentes que podem levar à instabilidade do sistema. Limites e Limiares: Defina limites e limiares razoáveis para o escalonamento para evitar o superescalonamento, que pode levar ao esgotamento de recursos, e o subescalonamento, que pode afetar o desempenho. | | **Gerenciamento Eficaz de Recursos** | Solicitações e Limites de Recursos: Defina solicitações e limites de recursos do Kubernetes para seus Pods para garantir que o processo de escalonamento automático respeite a disponibilidade de recursos no cluster. Configurações do HPA: Se estiver usando o KEDA com HPA, certifique-se de que as configurações do HPA estejam alinhadas com os requisitos de desempenho e disponibilidade da sua aplicação. | | **Considerações de Segurança** | Acesso Seguro às Fontes de Eventos: Garanta acesso seguro às suas fontes de eventos. Use controle de acesso baseado em funções (RBAC) e gerenciamento de segredos para credenciais. Auditoria e Monitoramento: Audite e monitore regularmente o acesso às fontes de eventos e as atividades de escalonamento para possíveis problemas de segurança. | | **Use Métricas Personalizadas Quando Apropriado** | Use Scalers Personalizados: Pode haver situações em que os scalers predefinidos não se alinham totalmente com seus requisitos específicos. Isso pode ser devido a lógica de negócios única, fontes de eventos personalizadas ou métricas específicas que são críticas para o desempenho e escalabilidade da sua aplicação, mas não são cobertas pelas opções integradas do KEDA. | | **Monitoramento e Observabilidade** | Coleta de Métricas: Colete métricas para o processo de escalonamento automático e a fonte de eventos para entender o comportamento de escalonamento ao longo do tempo. Logging: Habilite logs detalhados para solução de problemas e obtenção de insights sobre o processo de escalonamento. | | **Mantenha os Componentes do KEDA Atualizados** | Melhorias de Desempenho: Atualize regularmente o KEDA para se beneficiar dos recursos mais recentes, correções de bugs e patches de segurança. Ao manter-se atualizado, você garante que seus mecanismos de escalonamento automático estejam otimizados para eficiência e segurança, mitigando possíveis vulnerabilidades. Compatibilidade: Manter o KEDA atualizado garante compatibilidade com outros componentes em seu ecossistema nativo da nuvem, prevenindo problemas de integração. | | **Use Rótulos e Anotações de Forma Inteligente** | Categorize Eficientemente: Rótulos e anotações são pares chave/valor associados a objetos do Kubernetes, servindo como ferramentas flexíveis para categorizar, filtrar e gerenciar recursos dentro do seu ambiente Kubernetes. Ao aplicar rótulos estrategicamente, você pode agrupar recursos relacionados, como Pods ou Serviços, com base em características como ambiente, versão da aplicação ou qualquer outro critério personalizado relevante para suas necessidades operacionais. Anotações complementam os rótulos fornecendo um meio de anexar metadados não identificáveis aos seus recursos. | | **Engajamento e Suporte da Comunidade** | Mantenha-se Conectado: A comunidade KEDA é dedicada ao avanço e uso eficaz do Kubernetes Event-Driven Autoscaling. Ao participar dessa comunidade, você pode acessar conhecimento e suporte de colegas que enfrentaram desafios semelhantes. Esse engajamento pode assumir várias formas, incluindo fóruns de discussão, chamadas comunitárias, contribuição ou revisão de documentação e participação em encontros online ou presenciais. | ## Primeiro laboratório: configurando o ambiente Vamos configurar o ambiente de laboratório com as seguintes ferramentas: - **Docker**: Usado pelo kind para provisionar o cluster Kubernetes. - **kind**: Usado para criar clusters Kubernetes. - **kubectl**: Usado para gerenciar o cluster Kubernetes. - **Helm**: Usado para gerenciamento de pacotes Kubernetes. - **Siege**: Uma ferramenta de teste de carga. #### Configuração do Ambiente Linux Usaremos um host Ubuntu 22.04 e um cluster Kubernetes configurado usando kind. Para configurar o Docker, siga estas etapas: 1. **Instale o Docker:** ```sh curl -fsSL https://get.docker.com/ | sh ``` 2. **Habilite o Docker para iniciar na inicialização:** ```sh sudo systemctl enable --now docker ``` 3. **Verifique se o serviço Docker está em execução:** ```sh sudo systemctl status docker ``` 4. **Adicione o usuário atual ao grupo Docker:** ```sh sudo usermod -aG docker $USER ``` 5. **Atualize a sessão do shell (saindo e entrando novamente).** 6. **Verifique a instalação do Docker:** ```sh docker ps ``` Para instalar a versão mais recente do kubectl, execute os comandos abaixo: 1. **Baixe o binário:** ```sh curl -sSL -O "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl" ``` 2. **Modifique as permissões:** ```sh chmod +x kubectl ``` 3. **Mova para `/usr/local/bin`:** ```sh sudo mv kubectl /usr/local/bin ``` Para instalar a versão mais recente do Helm, execute as seguintes etapas: 1. **Faça a instalação do Helm:** ```sh curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 chmod 700 get_helm.sh ./get_helm.sh ``` Para instalar a versão mais recente do Siege, execute o seguinte comando: 1. **Instale o binário:** ```sh sudo apt-get install siege ``` O Siege é uma ferramenta de teste de carga HTTP/FTP com múltiplas threads e utilitário de benchmarking. Para instalar o kind, execute o seguinte comando: 1. **Para AMD64/x86_64:** ```sh [ $(uname -m) = x86_64 ] && curl -Lo ./kind https://kind.sigs.k8s.io/dl/v0.24.0/kind-linux-amd64 ``` 2. **Modifique as permissões:** ```sh chmod +x ./kind ``` 3. **Mova o binário do kind para `/usr/local/bin`:** ```sh sudo mv ./kind /usr/local/bin/kind ``` 4. **Crie o cluster:** ```sh kind create cluster ``` Saída esperada: ```plaintext Creating cluster "kind" ... ✓ Ensuring node image (kindest/node:v1.27.3) 🖼 ✓ Preparing nodes 📦 ✓ Writing configuration 📜 ✓ Starting control-plane 🕹️ ✓ Installing CNI 🔌 ✓ Installing StorageClass 💾 Set kubectl context to "kind-kind" You can now use your cluster with: kubectl cluster-info --context kind-kind ``` 5. **Verifique o cluster:** ```sh kubectl get ns ``` Saída esperada: ```plaintext NAME STATUS AGE default Active 36s kube-node-lease Active 36s kube-public Active 36s kube-system Active 36s local-path-storage Active 30s ``` ### Configuração do Metric Server no Kubernetes Para instalar o metric server no Kubernetes, execute os comandos abaixo: 1. **Adicione o repositório Helm:** ```sh helm repo add metrics-server https://kubernetes-sigs.github.io/metrics-server/ ``` 2. **Instale o metric server:** ```sh helm upgrade --install metrics-server metrics-server/metrics-server -n kube-system --set "args[0]=--kubelet-insecure-tls" ``` 3. Verifique a instalação: ``` kubectl get pods -n kube-system -l=app.kubernetes.io/name=metrics-server ``` Agora o nosso ambiente está pronto! ## Segundo laboratório: implementando o HPA no Kubernetes ### Pré-requisitos Cluster Kubernetes com o metric server instalado conforme o Lab 1. ### Exercício 2.1: Implantar Aplicação de Exemplo no Kubernetes Neste primeiro exercício, vamos implantar uma aplicação de exemplo no Kubernetes. Esta aplicação será usada para demonstrar as estratégias de autoscaling do HPA disponíveis no Kubernetes. 1. **Crie o arquivo `webapp.yaml` com o conteúdo abaixo. Este arquivo define uma implantação Kubernetes para sua aplicação de exemplo:** ```yaml apiVersion: apps/v1 kind: Deployment metadata: name: webapp spec: replicas: 2 selector: matchLabels: app: webapp template: metadata: labels: app: webapp spec: containers: - image: nginx name: nginx resources: limits: cpu: '10m' requests: cpu: '10m' ``` 2. **Implante a aplicação:** ```sh kubectl apply -f webapp.yaml ``` 3. **Verifique a implantação:** ```sh kubectl get deployments ``` Saída esperada: ```plaintext NAME READY UP-TO-DATE AVAILABLE AGE webapp 2/2 2 2 89s ``` 4. **Configure o port forwarding para acessar a aplicação.** Neste passo, estamos estabelecendo uma regra de port forwarding que redireciona o tráfego de rede de uma porta específica em sua máquina local para a porta correspondente no pod Kubernetes que hospeda o servidor. Ao fazer isso, você habilita o acesso direto ao servidor via `http://localhost:8080` a partir do seu computador local. Esta ação conecta o ambiente local ao pod Kubernetes isolado, permitindo que você teste e interaja com a aplicação implantada como se ela estivesse sendo executada localmente. É importante executar isso em uma nova aba do terminal para manter o port forwarding ativo durante toda a sessão de teste. ```sh kubectl port-forward deploy/webapp 8080:80 ``` Saída esperada: ```plaintext Forwarding from 127.0.0.1:8080 -> 80 Forwarding from [::1]:8080 -> 80 ``` 5. **Teste a aplicação de exemplo enviando uma solicitação HTTP:** ```sh curl http://localhost:8080/ ``` Saída esperada: ```html Welcome to nginx!

Welcome to nginx!

``` ### Exercício 2.2: Configurar e Testar o HPA Neste exercício, vamos configurar o Horizontal Pod Autoscaler no Kubernetes. 1. **Crie um recurso HPA.** Este recurso irá escalar automaticamente sua implantação com base na utilização da CPU. Vamos começar criando um Horizontal Pod Autoscaler para nossa implantação Kubernetes usando o comando `kubectl autoscale`: ```sh kubectl autoscale deployment webapp --min=2 --max=5 --cpu-percent=20 ``` Saída esperada: ```plaintext horizontalpodautoscaler.autoscaling/webapp autoscaled ``` 2. **Verifique se o HPA foi implantado corretamente:** ```sh kubectl get hpa ``` Saída esperada: ```plaintext NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE webapp Deployment/webapp 0%/20% 2 5 2 23s ``` 3. **Gere carga usando o Siege.** Neste passo, estamos usando a ferramenta Siege para gerar tráfego para nossa aplicação. À medida que o uso da CPU ultrapassa os limites definidos, o HPA responde automaticamente acionando seu mecanismo de escalonamento. O HPA aumenta o número de réplicas de pods para lidar com a carga aumentada. Este escalonamento garante que a aplicação mantenha seu desempenho e capacidade de resposta, apesar da demanda aumentada. ```sh siege -q -c 2 -t 1m http://localhost:8080 ``` 4. **Monitore o autoscaling.** Neste passo, estamos monitorando ativamente o comportamento do Horizontal Pod Autoscaler enquanto ele responde à carga aumentada. Executando `kubectl get hpa`, você pode observar a resposta em tempo real do HPA à mudança na utilização da CPU. Este comando exibe métricas cruciais, como o uso atual da CPU, o uso alvo (definido em 20% em nossa configuração) e o número atual de réplicas. O HPA opera monitorando continuamente métricas especificadas - neste caso, a utilização da CPU - e ajustando o número de réplicas de pods para atender à utilização alvo desejada. Quando a carga aumenta e o uso da CPU ultrapassa o limite de 20%, o HPA responde escalando o número de pods. ```sh kubectl get hpa -w ``` Saída esperada: ```plaintext NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE webapp Deployment/webapp 20%/20% 2 5 3 85s ``` A saída acima mostra que o HPA escalou a implantação `webapp` para 3 réplicas. Esta ação de escalonamento é uma resposta direta ao aumento da utilização da CPU, que ultrapassou o limite definido de 20%. Os aspectos importantes a serem observados aqui são os seguintes: - **TARGETS**: Indica a utilização atual/média da CPU (20%) em relação ao alvo definido (20%). A correspondência aqui acionou o escalonamento. - **MINPODS e MAXPODS**: Representam o número mínimo (2) e máximo (5) de pods que o HPA pode escalar. Neste caso, o número de réplicas aumentou, mas ainda está dentro dos limites definidos. - **REPLICAS**: Mostra a contagem atual de réplicas (3), que aumentou a partir da contagem original para lidar com a carga maior. 5. **Limpeza do HPA, delete o HPA e a implantação:** ```sh kubectl delete hpa webapp kubectl delete deploy webapp ``` ## Terceiro laboratório: instalando o KEDA e Configurando o Cron Scaler ### Pré-requisitos Cluster Kubernetes com o servidor de métricas instalado conforme o laboratório 1. ### Exercício 3.1: Instalar o KEDA Usando o Helm Chart Neste exercício, vamos instalar o KEDA usando um Helm chart. 1. **Instale o KEDA usando o Helm.** Execute os seguintes comandos para começar: ```sh helm repo add kedacore https://kedacore.github.io/charts helm repo update helm upgrade -i keda kedacore/keda --namespace keda --create-namespace ``` ````markdown ## Terceiro laboratório: instalando o KEDA e Configurando o Cron Scaler Este laboratório fornece experiência prática na instalação do KEDA em um ambiente Kubernetes. Faremos uso do Cron ScaledObject para dimensionar a aplicação com base em um cronograma de tempo. ### Pré-requisitos Cluster Kubernetes com o servidor de métricas instalado conforme o Laboratório 1. ### Exercício 3.1: Instalar o KEDA Usando o Helm Chart Neste exercício, vamos instalar o KEDA usando um Helm chart. 1. **Instale o KEDA usando o Helm.** Execute os seguintes comandos para começar: ```sh helm repo add kedacore https://kedacore.github.io/charts helm repo update helm upgrade -i keda kedacore/keda --namespace keda --create-namespace ``` ```` 2. **Verifique se os pods do KEDA estão em execução no cluster, usando o comando abaixo:** ```sh kubectl get deployment -n keda ``` 3. **Crie uma implantação usando o comando abaixo:** ```sh kubectl create deploy myapp --image nginx --replicas=2 ``` 4. **Verifique a implantação:** ```sh kubectl get deployments ``` 5. **Crie um arquivo `cron.yaml` com o conteúdo abaixo. Este arquivo define um Kubernetes ScaledObject para sua aplicação de amostra:** ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cron-scaledobject namespace: default spec: scaleTargetRef: name: myapp triggers: - type: cron metadata: timezone: Asia/Kolkata start: 30 * * * * end: 45 * * * * desiredReplicas: '10' ``` 6. **Crie o ScaledObject usando o comando abaixo:** ```sh kubectl apply -f cron.yaml ``` 7. **Verifique o ScaledObject:** ```sh kubectl get scaledobject.keda.sh ``` 8. **O ScaledObject dimensionará os pods da aplicação para o número desejado de réplicas quando o cronograma for acionado.** ```sh watch kubectl get all ``` O dimensionador Cron permite que você defina um intervalo de tempo no qual deseja dimensionar suas cargas de trabalho para cima e para baixo. Quando a janela de tempo começar, ele dimensionará do número mínimo de réplicas para o número desejado de réplicas com base em sua configuração. Neste exercício de laboratório, fizemos uso de um dimensionador Cron simples, que dimensiona as aplicações com base em um cronograma específico. Você pode explorar ainda mais os diferentes dimensionadores disponíveis. --- Este artigo foi traduzido e adaptado do curso gratuito da Linux Foundation [Scaling Cloud Native Applications with KEDA](https://training.linuxfoundation.org/express-learning/scaling-cloud-native-applications-with-keda-lfel1014/). ### Fontes Utilizadas: - [Documentação Oficial do KEDA](https://keda.sh/docs/latest/) - [Repositório GitHub do KEDA](https://github.com/kedacore/keda) - [Curso da Linux Foundation: Scaling Cloud Native Applications with KEDA](https://training.linuxfoundation.org/express-learning/scaling-cloud-native-applications-with-keda-lfel1014/) ``` --- Este artigo foi traduzido e adaptado do curso gratuito da Linux Foundation [Scaling Cloud Native Applications with KEDA](https://training.linuxfoundation.org/express-learning/scaling-cloud-native-applications-with-keda-lfel1014/). ### Fontes Utilizadas: - [Documentação Oficial do KEDA](https://keda.sh/docs/latest/) - [Repositório GitHub do KEDA](https://github.com/kedacore/keda) - [Curso da Linux Foundation: Scaling Cloud Native Applications with KEDA](https://training.linuxfoundation.org/express-learning/scaling-cloud-native-applications-with-keda-lfel1014/) ``` ## Política como código com o Kyverno - URL: https://nataliagranato.xyz/blog/kyverno101 - Data: 2024-09-24T00:00:00.000Z - Resumo: Kyverno é uma engine de políticas projetado para o Kubernetes. - Tags: kubernetes, kyverno, security # O que é o Kyverno? O Kyverno é uma ferramenta de política de código aberto para o Kubernetes. Ele fornece uma maneira de definir políticas de validação, mutação, geração de recursos Kubernetes, também realiza varreduras em segundo plano e varreduras de repositório de código-fonte. O Kyverno é implantado como um controlador de recursos Kubernetes e não requer um servidor de webhook de admissão. Ele permite segurança, automação, conformidade e governança usando política como código. As políticas do Kyverno podem ser gerenciadas como recursos do Kubernetes e não requerem o aprendizado de uma nova linguagem. Kyverno é projetado para funcionar bem com ferramentas que você já usa, como kubectl, kustomize e Git. ## Experimentando Vamos criar um cluster kind e instalar o Kyverno. Primeiro, crie um cluster kind: ```bash kind create cluster --name kyverno ``` Em seguida, instale o Kyverno: ```bash kubectl create -f https://github.com/kyverno/kyverno/releases/download/v1.11.1/install.yaml ``` Agora, vamos criar uma política de exemplo para o Kyverno. Crie um arquivo chamado `disallow-latest-tag.yaml` com o seguinte conteúdo: ```yaml apiVersion: kyverno.io/v1 kind: ClusterPolicy metadata: name: disallow-latest-tag annotations: policies.kyverno.io/title: Disallow Latest Tag policies.kyverno.io/category: Best Practices policies.kyverno.io/minversion: 1.6.0 policies.kyverno.io/severity: medium policies.kyverno.io/subject: Pod policies.kyverno.io/description: >- The ':latest' tag is mutable and can lead to unexpected errors if the image changes. A best practice is to use an immutable tag that maps to a specific version of an application Pod. This policy validates that the image specifies a tag and that it is not called `latest`. spec: validationFailureAction: Enforce background: true rules: - name: require-image-tag match: any: - resources: kinds: - Pod validate: message: 'An image tag is required.' pattern: spec: containers: - image: '*:*' - name: validate-image-tag match: any: - resources: kinds: - Pod validate: message: "Using a mutable image tag e.g. 'latest' is not allowed." pattern: spec: containers: - image: '!*:latest' ``` Agora, aplique a política ao cluster: ```bash kubectl apply -f disallow-latest-tag.yaml ``` O retorno será: ```bash clusterpolicy.kyverno.io/disallow-latest-tag created ``` A política `disallow-latest-tag` possui a configuração `validationFailureAction: Enforce`, o que significa que ela rejeitará qualquer recurso que viole a política. Agora, vamos criar um arquivo chamado `pod.yaml` com o seguinte conteúdo: ```yaml apiVersion: v1 kind: Pod metadata: name: nginx spec: containers: - name: nginx image: nginx:latest ``` Agora, aplique o arquivo ao cluster para validar se a política irá rejeitar a criação do pod com a tag de imagem `latest`: ```bash kubectl apply -f pod.yaml ``` O Kyverno deve rejeitar a criação do pod porque a política `disallow-latest-tag` não permite o uso de tags `latest`. Para verificar, execute o seguinte comando: ```bash kubectl get pod ``` Você verá que o pod foi rejeitado. A saída será algo como: ```bash Error from server: error when creating "pod.yml": admission webhook "validate.kyverno.svc-fail" denied the request: resource Pod/default/nginx was blocked due to the following policies disallow-latest-tag: validate-image-tag: 'validation error: Using a mutable image tag e.g. ''latest'' is not allowed. rule validate-image-tag failed at path /spec/containers/0/image/' ``` O output acima mostra que o Kyverno rejeitou a criação do pod porque a política `disallow-latest-tag` não permite o uso de tags `latest`. Isso mostra como o Kyverno pode ser usado para aplicar políticas de segurança e conformidade em um cluster Kubernetes. ## Provisionamento de um Rancher HA - URL: https://nataliagranato.xyz/blog/rancher-ha - Data: 2024-09-19T00:00:00.000Z - Resumo: Este guia fornece instruções detalhadas para a instalação do Rancher em um ambiente de alta disponibilidade (HA) em um cluster Kubernetes dedicado. - Tags: kubernetes, rancher ### Introdução ao Rancher O Rancher é uma plataforma de gerenciamento de Kubernetes que simplifica a operação de clusters Kubernetes em ambientes de produção. Ele oferece uma interface amigável e um conjunto robusto de ferramentas para facilitar a administração, monitoramento e escalabilidade de clusters Kubernetes. #### Benefícios do Rancher 1. **Gerenciamento Centralizado**: Permite gerenciar múltiplos clusters Kubernetes a partir de uma única interface, seja em ambientes on-premises, na nuvem ou em ambientes híbridos. 2. **Facilidade de Uso**: Oferece uma interface gráfica intuitiva que facilita a criação, configuração e monitoramento de clusters Kubernetes, mesmo para usuários com pouca experiência. 3. **Segurança e Controle**: Inclui recursos avançados de segurança, como autenticação, autorização e controle de acesso baseado em funções (RBAC), garantindo que apenas usuários autorizados possam acessar e modificar os recursos do cluster. 4. **Automação e Escalabilidade**: Suporta a automação de tarefas comuns, como atualizações de cluster e escalabilidade de aplicativos, permitindo que as equipes de DevOps se concentrem em tarefas mais estratégicas. 5. **Integração com Ferramentas de DevOps**: Integra-se facilmente com ferramentas populares de DevOps, como Jenkins, Prometheus e Grafana, proporcionando uma experiência de desenvolvimento e operações contínuas (CI/CD) mais eficiente. Com o Rancher, as organizações podem acelerar a adoção do Kubernetes, reduzir a complexidade operacional e melhorar a eficiência das equipes de TI, garantindo que os aplicativos sejam executados de forma confiável e segura em qualquer ambiente. ## Passos para Instalação ### Pré-requisitos - Um cluster Kubernetes dedicado. - Acesso ao cluster Kubernetes via `kubectl`. - Helm instalado e configurado. ### Passos Detalhados para Instalação ### 1. Instalação do NGINX Ingress Controller O NGINX Ingress Controller é necessário para gerenciar o tráfego de entrada para os serviços no cluster Kubernetes. 1. Crie o namespace para o NGINX Ingress Controller: ```sh kubectl create ns nginx-ingress ``` Este comando cria um namespace chamado `nginx-ingress` no cluster Kubernetes. 2. Instale o NGINX Ingress Controller usando Helm: ```sh helm install nginx-ingress oci://ghcr.io/nginxinc/charts/nginx-ingress -n nginx-ingress ``` Este comando instala o NGINX Ingress Controller no namespace `nginx-ingress` usando o Helm. 3. Verifique os serviços criados e obtenha o IP do LoadBalancer: ```sh kubectl get svc -n nginx-ingress ``` Este comando lista todos os serviços no namespace `nginx-ingress`, incluindo o IP do LoadBalancer. Anote este IP, pois ele será necessário para configurar o apontamento do DNS. ### 2. Instalação do Cert-manager O Cert-manager é necessário para gerenciar certificados SSL/TLS automaticamente. 1. Aplique as CustomResourceDefinitions (CRDs) necessárias: ```sh kubectl apply -f https://raw.githubusercontent.com/jetstack/cert-manager/release-0.9/deploy/manifests/00-crds.yaml ``` Este comando aplica as definições de recursos personalizados necessárias para o Cert-manager. 2. Crie o namespace para o Cert-manager: ```sh kubectl create namespace cert-manager ``` Este comando cria um namespace chamado `cert-manager` no cluster Kubernetes. 3. Adicione um rótulo ao namespace para desabilitar a validação: ```sh kubectl label namespace cert-manager certmanager.k8s.io/disable-validation=true ``` Este comando adiciona um rótulo ao namespace `cert-manager` para desabilitar a validação. 4. Adicione o repositório Helm do Cert-manager: ```sh helm repo add jetstack https://charts.jetstack.io --force-update ``` Este comando adiciona o repositório Helm do Cert-manager. 5. Instale o Cert-manager usando Helm: ```sh helm install \ cert-manager jetstack/cert-manager \ --namespace cert-manager \ --create-namespace \ --version v1.15.3 \ --set crds.enabled=true ``` Este comando instala o Cert-manager no namespace `cert-manager` usando o Helm. ### 3. Instalação do Rancher O Rancher é uma plataforma de gerenciamento de Kubernetes que facilita a operação de clusters Kubernetes em ambientes de produção. 1. Adicione o repositório Helm do Rancher: ```sh helm repo add rancher-stable https://releases.rancher.com/server-charts/stable ``` Este comando adiciona o repositório Helm do Rancher. 2. Instale o Rancher usando Helm: ```sh helm upgrade -i rancher rancher-stable/rancher --set hostname=rancher.nataliagranato.xyz -n cattle-system ``` Este comando instala o Rancher no namespace `cattle-system` usando o Helm. O parâmetro `--set hostname=rancher.nataliagranato.xyz` define o hostname personalizado para o Rancher. ### Utilização de um Domínio Personalizado Ao instalar o Rancher, é importante utilizar um domínio personalizado (por exemplo, `rancher.nataliagranato.xyz`). Este domínio será usado para acessar a interface do Rancher. **Não troque este DNS após a instalação**, pois isso pode causar problemas de acesso e funcionamento do Rancher. O domínio personalizado deve estar configurado corretamente no seu DNS para apontar para o IP do Ingress Controller obtido anteriormente. ### Pós-instalação O servidor Rancher foi instalado. Note que pode levar alguns minutos para que o Rancher seja totalmente inicializado. Durante esse tempo, os certificados serão emitidos, os contêineres serão iniciados e a regra de Ingress será configurada. Confira a documentação oficial em [Rancher Docs](https://rancher.com/docs/). Se você forneceu sua própria senha de bootstrap durante a instalação, acesse [https://rancher.nataliagranato.xyz](https://rancher.nataliagranato.xyz) para começar. Se esta é a primeira vez que você instalou o Rancher, execute o seguinte comando e clique na URL gerada: ```sh echo https://rancher.nataliagranato.xyz/dashboard/?setup=$(kubectl get secret --namespace cattle-system bootstrap-secret -o go-template='{{.data.bootstrapPassword|base64decode}}') ``` ### RUNBOOKS ### Configuração do Domínio Personalizado para o Rancher 1. **Obtenha o IP do LoadBalancer**: ```sh kubectl get svc -n nginx-ingress ``` Anote o IP do LoadBalancer listado no serviço `nginx-ingress`. 2. **Configure o apontamento do DNS**: - Acesse o painel de controle do seu provedor de DNS. - Crie um registro A para o domínio `rancher.nataliagranato.xyz` apontando para o IP do LoadBalancer obtido no passo anterior. ### Solução de Problemas com o Ingress Se, por algum motivo o deploy do Rancher ocorreu corretamente, mas você não está conseguindo acessar a url, é possível que o Ingress criado para acessar o Rancher, não obtive o valor do Ingress Controller, será necessário editar manualmente: 1. Edite o Ingress do Rancher: ```sh kubectl edit ingress rancher -n nginx-ingress ``` 2. Adicione a annotation do seu Ingress Controller e salve para acessar a URL. ```yaml annotations: kubernetes.io/ingress.class: 'nginx' ``` ## Removendo um Namespace em estado terminanting - URL: https://nataliagranato.xyz/blog/remove-namespace - Data: 2024-07-15T00:00:00.000Z - Resumo: O erro de namespace em estado “Terminating” ocorre quando um namespace (ou espaço de nomes) no Kubernetes está sendo desligado ou excluído. - Tags: kubernetes # Removendo um Namespace em Estado Terminanting O erro de namespace em estado “Terminating” ocorre quando um namespace (ou espaço de nomes) no Kubernetes está sendo desligado ou excluído. Vamos explorar os detalhes desse erro: **Contexto:** Um namespace é uma unidade lógica de isolamento que agrupa recursos no Kubernetes. Quando você exclui um namespace, o Kubernetes inicia um processo de término para limpar todos os recursos associados a ele. **Fase de Término:** Durante a fase de término, o namespace entra no estado “Terminating”. Nesse estado, o Kubernetes começa a desalocar os recursos dentro do namespace. Isso inclui a exclusão de pods, services, deployments, configmaps, secrets e outros objetos relacionados. **Recursos em Término:** Os recursos dentro do namespace em término são marcados para exclusão. O Kubernetes aguarda até que todos esses recursos sejam removidos com sucesso. Se algum recurso estiver preso ou não puder ser excluído, o namespace permanecerá no estado “Terminating”. **Possíveis Causas:** - Pods Pendentes: Se houver pods pendentes (que não podem ser encerrados), o namespace não poderá ser completamente excluído. - Volumes Persistentes: Volumes persistentes associados a pods podem impedir o término do namespace. - Controladores de Recursos: Controladores como Deployments, StatefulSets ou DaemonSets também podem afetar o término. **Soluções:** - Verifique os pods pendentes e tente corrigir quaisquer problemas. - Garanta que os volumes persistentes sejam liberados. - Analise os controladores de recursos e seus recursos associados. Lembre-se de que o estado “Terminating” é temporário e, uma vez que todos os recursos sejam removidos com sucesso, o namespace será excluído completamente. 🚀 ## Caso não consiga remover recursos "presos" no namespace, tente a solução abaixo: 1. Salve um arquivo JSON como no exemplo a seguir: ``` kubectl get ns zabbix -o json > tempfile.json ``` O conteúdo do arquivo será algo como: ``` { "apiVersion": "v1", "kind": "Namespace", "metadata": { "annotations": { "cattle.io/status": "{\"Conditions\":[{\"Type\":\"ResourceQuotaInit\",\"Status\":\"True\",\"Message\":\"\",\"LastUpdateTime\":\"2024-04-23T13:55:17Z\"},{\"Type\":\"InitialRolesPopulated\",\"Status\":\"True\",\"Message\":\"\",\"LastUpdateTime\":\"2024-04-23T13:55:18Z\"}]}", "field.cattle.io/containerDefaultResourceLimit": "{}", "field.cattle.io/projectId": "c-m-zrkmsvsf:p-cssw8", "lifecycle.cattle.io/create.namespace-auth": "true" }, "creationTimestamp": "2024-04-23T13:55:16Z", "finalizers": [ "controller.cattle.io/namespace-auth" ], "labels": { "field.cattle.io/projectId": "p-cssw8", "kubernetes.io/metadata.name": "zabbix" }, "name": "zabbix", "resourceVersion": "111297880", "uid": "81f426de-3a70-4078-86de-a07e30b408b3" }, "spec": { "finalizers": [ "kubernetes" ] }, "status": { "phase": "Active" } } ``` 2. Remova o bloco de finalizadores na seção spec do JSON: ``` "spec" : { } ``` 3. Aplique as mudanças com o comando a seguir: ``` kubectl replace --raw "/api/v1/namespaces/TERMINATING_NAMESPACE/finalize" -f ./tempfile.json ``` 4. Verifique se o namespace em questão foi removido: ``` kubectl get namespaces ``` ## Build de Imagens no Kubernetes com Gitlab Runner e Kaniko - URL: https://nataliagranato.xyz/blog/build-de-imagens-no-kubernetes - Data: 2024-06-28T00:00:00.000Z - Resumo: Veremos como configurar e utilizar o Gitlab Runner em um cluster Kubernetes para construir imagens de container usando o Kaniko. - Tags: gitlab, kanino, kubernetes ## O que é o Gitlab Runner? O Gitlab Runner é uma aplicação de código aberto que executa os jobs definidos em seus pipelines do Gitlab CI/CD. Ele pode ser instalado em diferentes plataformas, incluindo máquinas virtuais, servidores bare-metal e Kubernetes. ## Registro do Runner em seus projetos Após o deploy do Gitlab Runner no Kubernetes, você precisa registrar o runner em seus projetos para que ele possa executar os jobs. 1. Acesse a seção `Settings > CI/CD` do seu projeto no Gitlab. 2. Expanda a seção `Runners`. 3. Clique em `Register a runner`. 4. Copie o token de registro exibido. 5. Execute o seguinte comando no seu cluster Kubernetes, substituindo `YOUR_REGISTRATION_TOKEN` pelo token copiado: ```sh kubectl exec -it gitlab-runner-gitlab-runner-XXXXX-XXXXX -- gitlab-runner register \ --non-interactive \ --url https://gitlab.example.com/ \ --registration-token YOUR_REGISTRATION_TOKEN \ --executor kubernetes ``` ## Deploy do Gitlab Runner no Kubernetes usando Helm Para instalar o Gitlab Runner no Kubernetes usando Helm, siga estes passos: 1. Adicione o repositório do Helm: ```sh helm repo add gitlab https://charts.gitlab.io/ ``` 2. Atualize os repositórios: ```sh helm repo update ``` 3. Instale o Gitlab Runner: ```sh helm install gitlab-runner gitlab/gitlab-runner \ --set gitlabUrl=https://gitlab.example.com/ \ --set runnerRegistrationToken=YOUR_REGISTRATION_TOKEN ``` Substitua `https://gitlab.example.com/` pela URL do seu Gitlab. Substitua `YOUR_REGISTRATION_TOKEN` pelo token de registro do runner, obtido na seção de CI/CD do seu projeto no Gitlab. ## Pontos de atenção no values.yaml ``` rules: - resources: - configmaps - pods - pods/attach - secrets - services verbs: - get - list - watch - create - patch - update - delete - apiGroups: - '' resources: - pods/exec verbs: - create - patch - delete ### runners: cache: {} config: | [[runners]] [runners.kubernetes] image = "ubuntu:20.04" wait_for_services_timeout = "-1" privileged = true allow_privilege_escalation = true image_pull_secrets = ["aws-ecr"] configPath: '' name: globalweb-gitlab-runner privileged: true runUntagged: true tags: docker, share_cache, share_cache1, amd64 secrets: [] securityContext: allowPrivilegeEscalation: false capabilities: drop: - ALL privileged: false readOnlyRootFilesystem: false runAsNonRoot: true service: enabled: false type: ClusterIP serviceAccount: annotations: {} imagePullSecrets: null name: null sessionServer: enabled: false shutdown_timeout: 0 strategy: {} terminationGracePeriodSeconds: 3600 tolerations: null topologySpreadConstraints: {} useTini: false volumeMounts: null volumes: null gitlabUrl: https://gitlab.com/ global: cattle: systemProjectId: p-mpfgv runnerRegistrationToken: glrt-1234567891011121415 ``` # Explicação do Arquivo de Configuração ## Regras (`rules`) Esta seção define permissões para acessar recursos do Kubernetes. - **resources**: Lista de recursos do Kubernetes que o runner pode acessar. Isso inclui `configmaps`, `pods`, `pods/attach`, `secrets`, e `services`. - **verbs**: Ações que podem ser realizadas nos recursos listados acima, como `get`, `list`, `watch`, `create`, `patch`, `update`, e `delete`. - **apiGroups**: Grupos de API do Kubernetes. Neste caso, está vazio (`''`), indicando o grupo principal. - **resources**: Lista de recursos específicos do grupo de API acima. Aqui, `pods/exec`. - **verbs**: Ações que podem ser realizadas no recurso `pods/exec`, como `create`, `patch`, e `delete`. ## Runners (`runners`) Esta seção define a configuração dos runners. - **cache**: Configuração de cache, atualmente vazio (`{}`). - **config**: Configuração dos runners em formato TOML. - **runners.kubernetes**: Configuração específica para runners Kubernetes. - **image**: Imagem de container a ser utilizada (`ubuntu:20.04`). - **wait_for_services_timeout**: Tempo de espera para serviços (`-1`, indicando infinito). - **privileged**: Permissão privilegiada para o container (`true`). - **allow_privilege_escalation**: Permissão para escalonar privilégios (`true`). - **image_pull_secrets**: Segredos utilizados para puxar imagens do container (`aws-ecr`). - **configPath**: Caminho de configuração, atualmente vazio (`''`). - **name**: Nome do runner (`globalweb-gitlab-runner`). - **privileged**: Indicação de execução privilegiada (`true`). - **runUntagged**: Indicação se deve executar tarefas não etiquetadas (`true`). - **tags**: Tags associadas ao runner (`docker, share_cache, share_cache1, amd64`). ## Secrets (`secrets`) Lista de segredos, atualmente vazia (`[]`). ## SecurityContext (`securityContext`) Configurações de segurança para os containers. - **allowPrivilegeEscalation**: Permissão para escalonar privilégios (`false`). - **capabilities**: Capacidades do container. - **drop**: Capacidades a serem removidas (`ALL`). - **privileged**: Indicação se o container é privilegiado (`false`). - **readOnlyRootFilesystem**: Indicação se o sistema de arquivos raiz é somente leitura (`false`). - **runAsNonRoot**: Indicação se o container deve ser executado como um usuário não root (`true`). ## Service (`service`) Configurações do serviço. - **enabled**: Indicação se o serviço está habilitado (`false`). - **type**: Tipo de serviço (`ClusterIP`). ## ServiceAccount (`serviceAccount`) Configurações da conta de serviço. - **annotations**: Anotações, atualmente vazias (`{}`). - **imagePullSecrets**: Segredos para puxar imagens, atualmente `null`. - **name**: Nome da conta de serviço, atualmente `null`. ## SessionServer (`sessionServer`) Configurações do servidor de sessão. - **enabled**: Indicação se o servidor de sessão está habilitado (`false`). ## Shutdown Timeout (`shutdown_timeout`) Tempo de espera para o desligamento (`0`). ## Strategy (`strategy`) Estratégia de implantação, atualmente vazia (`{}`). ## Termination Grace Period Seconds (`terminationGracePeriodSeconds`) Período de tempo de espera antes de forçar a terminação (`3600` segundos). ## Tolerations (`tolerations`) Tolerâncias para nós, atualmente `null`. ## Topology Spread Constraints (`topologySpreadConstraints`) Restrições de dispersão topológica, atualmente vazias (`{}`). ## UseTini (`useTini`) Indicação se deve usar tini como init, atualmente `false`. ## VolumeMounts (`volumeMounts`) Montagens de volume, atualmente `null`. ## Volumes (`volumes`) Volumes, atualmente `null`. ## GitLab URL (`gitlabUrl`) URL do GitLab (`https://gitlab.com/`). ## Runner Registration Token (`runnerRegistrationToken`) Token de registro do runner (`glrt-1234567891011121415`). Essas configurações combinadas permitem que um GitLab Runner seja executado em um cluster Kubernetes com permissões e configurações específicas para realizar tarefas de CI/CD. ## Utilizando o novo runner em pipelines do Gitlab CI Para utilizar o novo runner em seus pipelines do Gitlab CI, adicione a tag `kubernetes` ao job que você deseja executar no Kubernetes. Por exemplo: ```yaml build_image: stage: build image: alpine:latest tags: - kubernetes script: - echo "Building image..." ``` ## Kubernetes não utiliza Docker como container runtime e agora? O Kaniko pode resolver esse problema O Kubernetes não utiliza o Docker como container runtime por padrão. Isso pode ser um problema para pipelines de CI/CD que dependem do Docker para construir imagens. O Kaniko é uma ferramenta que permite construir imagens de container sem precisar do Docker. ## O que é o Kaniko e como ele funciona? O Kaniko é uma ferramenta de código aberto que constrói imagens de container a partir de um Dockerfile dentro de um container ou cluster Kubernetes. Ele funciona extraindo o filesystem do container base, executando os comandos do Dockerfile e empacotando o resultado em uma imagem de container. ## Configurando variáveis de ambiente no Gitlab CI Para que o Kaniko funcione corretamente, você precisa configurar algumas variáveis de ambiente no Gitlab CI. Essas variáveis incluem credenciais para acessar seu registro de container e informações sobre o projeto. ### Passos para configurar variáveis de ambiente para a sua pipeline 1. Acesse a seção `Settings > CI/CD` do seu projeto no Gitlab. 2. Expanda a seção `Variables`. 3. Adicione as seguintes variáveis, sem a flag de proteção: - `AWS_REGION`: Define a região da Amazon Web Services (AWS) onde os recursos serão criados e gerenciados. - `AWS_ACCESS_KEY_ID`: É a chave de acesso pública da AWS que, junto com o AWS_SECRET_ACCESS_KEY, é usada para autenticar e autorizar chamadas para os serviços da AWS. - `AWS_SECRET_ACCESS_KEY`: É a chave de acesso secreta da AWS, usada em conjunto com o AWS_ACCESS_KEY_ID para autenticar e autorizar chamadas para os serviços da AWS. - `REGISTRY`: Refere-se ao registro de contêineres onde as imagens Docker são armazenadas e gerenciadas. ## Exemplo `.gitlab-ci.yml` de build e push de imagens de containers com o Kaniko O exemplo a seguir demonstra como usar o Kaniko em um pipeline do Gitlab CI para construir e enviar uma imagem de container para um registro: ``` build: stage: build image: name: gcr.io/kaniko-project/executor:debug entrypoint: [""] script: - mkdir -p /kaniko/.docker - echo "{\"credsStore\":\"ecr-login\",\"credHelpers\":{\"$REGISTRY/portal-colaborador-hml\":\"ecr-login\"}}" > /kaniko/.docker/config.json - >- /kaniko/executor --context "${CI_PROJECT_DIR}" --dockerfile "${CI_PROJECT_DIR}/Dockerfile" --build-arg AWS_REGION=$AWS_REGION --build-arg AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID --build-arg AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY --destination "${REGISTRY}/portal-colaborador-hml:${CI_COMMIT_SHORT_SHA:0:5}" tags: - docker, share_cache, share_cache1, amd64 only: - main - develop ``` Essa configuração permite que o GitLab CI/CD construa e empurre uma imagem Docker usando Kaniko, autenticando-se no registro de contêineres utilizando credenciais da AWS, e apenas executando este processo nas branches main e develop. ## Conclusão Utilizar o Gitlab Runner em conjunto com o Kaniko no Kubernetes permite construir e enviar imagens de container de forma eficiente e segura, sem depender do Docker como runtime. Esta configuração aproveita o poder do Kubernetes para escalar e gerenciar suas builds de CI/CD, garantindo maior flexibilidade e desempenho em seus pipelines. ## Criando um Cluster Kubernetes em Instâncias EC2 - URL: https://nataliagranato.xyz/blog/criando-kubernetes-aws-ec2 - Data: 2024-05-07T00:00:00.000Z - Resumo: Criando um cluster em instância EC2 com o Kubeadm. - Tags: aws, ec2, kubernetes # Criando um Cluster Kubernetes em Instâncias EC2 Este guia detalha o processo de criação de um cluster Kubernetes em instâncias EC2 na AWS, com base nas configurações e comandos fornecidos. ![kubernetes](https://www.ibm.com/content/dam/adobe-cms/instana/media_logo/Kubernetes.component.complex-narrative-xl.ts=1698760458686.png/content/adobe-cms/br/pt/products/instana/supported-technologies/kubernetes-monitoring/_jcr_content/root/table_of_contents/body/content_section_styled/content-section-body/complex_narrative/logoimage) ## Configurações das Instâncias EC2 - **Nome**: k8s - **Número de Instâncias**: 5 - **Imagem da Máquina**: Ubuntu Server 22.04 LTS (HVM), SSD Volume Type - **Arquitetura**: 64 bits (x86) - **Tipo de Instância**: t2.medium - **Key Pair**: key_par_k8s - **Configuração de Armazenamento**: Volume do tipo gp3 ## Configurações do Cluster Kubernetes Para criar um cluster Kubernetes usando o kubeadm, é necessário liberar algumas portas no grupo de segurança das instâncias EC2. Essas portas são essenciais para o funcionamento correto do cluster. A seguir, estão as portas que precisam ser liberadas: - **Porta 6443**: Essa porta é usada pelo servidor de API do Kubernetes para comunicação com os componentes do cluster. É necessário permitir o tráfego TCP na porta 6443 para que os nós do cluster possam se comunicar com o servidor de API. - **Portas 10250-10259**: Essas portas são usadas pelo kubelet, kube-scheduler e kube-controller-manager para comunicação interna no cluster. É necessário permitir o tráfego TCP nessas portas para que os componentes do cluster possam se comunicar entre si. - **Porta 30000-32767**: Essas portas são usadas para serviços NodePort no Kubernetes. É necessário permitir o tráfego TCP nessas portas para que os serviços NodePort possam ser acessados externamente. - **Portas 6783-6784**: Essas portas são usadas pelo Weave Net para comunicação interna no cluster. É necessário permitir o tráfego UDP nessas portas para que o Weave Net possa funcionar corretamente. - **Portas 2379-2380**: Essas portas são usadas pelo etcd para comunicação interna no cluster. É necessário permitir o tráfego TCP nessas portas para que o etcd possa funcionar corretamente. Além disso, é importante lembrar de liberar a porta 22 para permitir a conexão SSH com as instâncias EC2. Certifique-se de configurar corretamente as regras de entrada no grupo de segurança das instâncias EC2 para permitir o tráfego nessas portas. As regras de saída podem ser mantidas com as configurações padrão da AWS. TCP - Portas 10250-10259 - Security Group ID - Kubelet API, kube-scheduler e kube-controller-manager. **Regras de Saída**: Não irei específicar as regras de saída, portanto, usarão as configurações padrão da AWS. ## Conectando-se às Instâncias Para se conectar às instâncias EC2, é necessário usar a chave privada associada ao key pair usado durante a criação das instâncias. A seguir, está o comando para se conectar a uma instância EC2 usando a chave privada: ```bash sudo chmod 400 sua_chave_privada.pem ssh -i "sua_chave_privada.pem" ubuntu@ip_da_instância.compute-1.amazonaws.com ``` Substitua `sua_chave_privada.pem` pelo caminho da sua chave privada e `ip_da_instância.compute-1.amazonaws.com` pelo endereço IP público da instância EC2. Altere o hostname da máquina: ```bash sudo su - hostnamectl set-hostname k8s-1 ``` ## Configurando os Nós 1. Desativando a Memória Swap: ```bash sudo swapoff -a ``` Este comando desativa a memória swap em seu sistema. No contexto do Kubernetes, a memória swap pode interferir no desempenho do sistema e causar problemas de estabilidade, portanto, é recomendado desativá-la. 2. Configurando os Módulos de Kernel: ```bash sudo nano /etc/modules-load.d/k8s.conf ``` Este comando abre o editor de texto nano para editar o arquivo k8s.conf localizado no diretório /etc/modules-load.d/. Este arquivo é usado para especificar quais módulos do kernel devem ser carregados durante a inicialização do sistema. Adicione as seguintes linhas ao arquivo: ```bash br_netfilter overlay ``` Esses módulos do kernel são necessários para o funcionamento adequado do Kubernetes. O br_netfilter é usado para configurar a ponte de rede do Docker, enquanto o overlay é usado para suportar a camada de sobreposição de contêineres. Salve e feche o arquivo. 3. Carregando os Módulos de Kernel: ```bash sudo modprobe br_netfilter sudo modprobe overlay ``` 4. Em seguida, execute: ```bash cat < -o /etc/apt/keyrings/docker.asc sudo chmod a+r /etc/apt/keyrings/docker.asc echo \ "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu \ $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | \ sudo tee /etc/apt/sources.list.d/docker.list > /dev/null sudo apt-get update sudo apt-get install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin ``` 1. `sudo apt-get update`: Atualiza a lista de pacotes disponíveis e suas versões, mas não instala ou atualiza nenhum pacote. 2. `sudo apt-get install ca-certificates curl`: Instala os pacotes `ca-certificates` e `curl`. `ca-certificates` é usado para verificar a confiabilidade dos servidores remotos, e `curl` é usado para baixar dados de ou para um servidor. 3. `sudo install -m 0755 -d /etc/apt/keyrings`: Cria o diretório `/etc/apt/keyrings` com permissões `0755`. 4. `sudo curl -fsSL -o /etc/apt/keyrings/docker.asc`: Baixa a chave GPG do repositório Docker e a salva no arquivo `/etc/apt/keyrings/docker.asc`. 5. `sudo chmod a+r /etc/apt/keyrings/docker.asc`: Altera as permissões do arquivo `docker.asc` para que todos os usuários possam lê-lo. 6. O comando `echo` cria uma nova entrada na lista de fontes do APT para o repositório Docker. 7. `sudo apt-get update`: Novamente, atualiza a lista de pacotes disponíveis e suas versões. 8. `sudo apt-get install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin`: Instala o Docker, o CLI do Docker, o Containerd, o plugin Docker Buildx e o plugin Docker Compose. 9. Configurando o Containerd: ```bash sudo containerd config default | sudo tee /etc/containerd/config.toml sudo sed -i 's/SystemdCgroup = false/SystemdCgroup = true/g' /etc/containerd/config.toml sudo systemctl restart containerd sudo systemctl status containerd ``` 8. Habilitando o serviço do Kubelet: ```bash sudo systemctl enable --now kubelet systemctl status kubelet ``` **Nota**: A partir daqui, execute os comandos como `root` para evitar problemas de permissões, erros de certificado, etc. # Criando o cluster Kubernetes na versão v1.30 1. Inicializando o cluster: ```bash sudo kubeadm init --pod-network-cidr=10.10.0.0/16 --apiserver-advertise-address= # Configurando o Acesso ao Kubernetes: mkdir -p $HOME/.kube sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config sudo chown $(id -u):$(id -g) $HOME/.kube/config ``` 2. Adicionando nós workers ao cluster: ```bash sudo kubeadm join --token --discovery-token-ca-cert-hash sha256: ``` 3. Instalando o Wave Net para a rede do cluster: ```bash kubectl apply -f https://github.com/weaveworks/weave/releases/download/v2.8.1/weave-daemonset-k8s.yaml ``` 4. Verificando o status do cluster: ```bash kubectl get nodes kubectl get pods -A ``` Agora você tem um cluster Kubernetes funcional em execução em instâncias EC2 na AWS. Você pode implantar aplicativos, serviços e recursos no cluster e começar a explorar as capacidades do Kubernetes. ## Criando um servidor NFS e utilizando como StorageClass - URL: https://nataliagranato.xyz/blog/criando-um-servidor-nfs - Data: 2024-05-07T00:00:00.000Z - Resumo: Natália Granato - Tags: linux, nfs, storageclass, kubernetes # Servidor NFS (Network File System) O **Servidor NFS** é uma solução que permite compartilhar sistemas de arquivos entre computadores em uma rede. Ele é amplamente usado em ambientes Linux/Unix para compartilhar diretórios e arquivos entre servidores e clientes. ## O que é um servidor NFS? - **NFS** (Network File System) é um protocolo que permite que um sistema acesse arquivos em outro sistema como se estivessem em seu próprio sistema de arquivos local. - O servidor NFS exporta (disponibiliza) diretórios ou sistemas de arquivos para os clientes NFS. - Os clientes NFS montam esses sistemas de arquivos exportados, tornando-os acessíveis como se fossem locais. ## Criando um servidor NFS Para criar um servidor NFS, siga estas etapas: 0. Crie o diretório que deseja compartilhar: ``` sudo mkdir /mnt/nfs ``` 1. **Instale o servidor NFS**: - Instale o pacote `sudo apt-get install nfs-kernel-server nfs-common` (ou similar) no seu servidor. - Inicie e habilite o serviço NFS. 2. **Configure os diretórios a serem exportados**: - Edite o arquivo `/etc/exports` para definir os diretórios que deseja compartilhar. - Exemplo de linha no arquivo `/etc/exports`: ``` /mnt/nfs *(rw,sync,no_root_squash,no_subtree_check) ``` 3. **Reinicie o serviço NFS**: - Execute o comando para aplicar as alterações: ``` sudo systemctl restart nfs-server ``` 4. **Configure as regras de firewall**: - Abra as portas necessárias (geralmente 2049 para NFS) no firewall do servidor. 5. **Monte o compartilhamento nos clientes**: - Nos clientes, use o comando `mount` para montar o compartilhamento NFS: ``` sudo mount servidor:/caminho/do/diretorio /caminho/local ``` 6. Verifique se o NFS está funcionando corretamente: - Use o comando `showmount` para verificar os compartilhamentos exportados: ``` showmount -e ``` A saída deve mostrar os diretórios exportados e os clientes que têm permissão para acessá-los. ``` Export list for ip-172-31-58-237: /mnt/nfs * ``` ## Criando um StorageClass do tipo NFS Para criar um StorageClass do tipo NFS no Kubernetes, você pode usar o seguinte exemplo: ```yaml apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: nfs provisioner: kubernetes.io/no-provisioner reclaimPolicy: Retain volumeBindingMode: WaitForFirstConsumer parameters: archiveOnDelete: 'false' ``` Agora vamos criar volumes que utilizam esse StorageClass: ```yaml apiVersion: v1 kind: PersistentVolume metadata: name: meu-pv-nfs labels: storage: nfs spec: capacity: storage: 1Gi accessModes: - ReadWriteOnce persistentVolumeReclaimPolicy: Retain nfs: server: 3.90.82.216 path: '/mnt/nfs' storageClassName: nfs ``` Agora iremos criar um PersistentVolumeClaim (PVC) que utiliza esse PV: ````yaml apiVersion: v1 kind: PersistentVolumeClaim metadata: name: meu-pvc spec: accessModes: - ReadWriteOnce resources: requests: storage: 1Gi storageClassName: nfs selector: matchLabels: storage: nfs Agora iremos criar um Pod que utiliza esse PVC: ```yaml apiVersion: v1 kind: Pod metadata: name: nginx-pod spec: containers: - name: nginx image: nginx:latest ports: - containerPort: 80 volumeMounts: - name: meu-pvc mountPath: /usr/share/nginx/html volumes: - name: meu-pvc persistentVolumeClaim: claimName: meu-pvc ```` Agora você tem um Pod que utiliza um volume NFS no Kubernetes. ## Certificado TLS com openssl e Secret do tipo TLS no Kubernetes - URL: https://nataliagranato.xyz/blog/utilizando-tls-secret - Data: 2024-05-07T00:00:00.000Z - Resumo: Aprende a gerar e utilizar um certificado TLS como secret no Kubernetes. - Tags: tls, secret, openssl, kubernetes # Certificado TLS com openssl e Secret do tipo TLS no Kubernetes Utilize o openssl, projeto de código aberto dos protocolos ssl e tls para gerar o seu certificado autoassinado. Use `openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout chave-privada.key -out certificado.crt`. Para criar um Secret do tipo TLS, você pode usar o comando `kubectl create secret tls meu-servico-web-tls-secret --cert=certificado.crt --key=chave-privada.key` seguido sempre pelo nome da Secret e a localização dos arquivos de certificado e chave. Verificando os dados de uma Secret, você pode usar o comando `kubectl get secret meu-servico-tls-secret -o yaml` para visualizar os dados de uma Secret. Aqui está um exemplo do arquivo de configuração do nginx para utilizar tls: ```yaml http { server { listen 80; listen 443 ssl; ssl_certificate /etc/nginx/tls/certificado.crt; ssl_certificate_key /etc/nginx/tls/chave-privada.key; location / { return 200 'Hello, World!'; add_header Content-Type text/plain; } } } ``` # Criando um ConfigMap para adicionar um arquivo no Pod e configurar o SSL no Nginx Para criar um ConfigMap para adicionar um arquivo no Pod e configurar o SSL no Nginx, você pode usar o comando `kubectl create configmap nginx-config --from-file=nginx.conf` seguido pelo nome do ConfigMap e o arquivo a ser incluído. ```yaml apiVersion: v1 kind: Pod metadata: name: gita-pod labels: app: gita-pod spec: containers: - name: gita-container image: nginx:1.26 ports: - containerPort: 80 - containerPort: 443 volumeMounts: - name: meu-volume mountPath: /etc/nginx/nginx.conf subPath: nginx.conf - name: nginx-tls mountPath: /etc/nginx/tls volumes: - name: nginx-config-volume configMap: name: nginx-config - name: nginx-tls secret: secretName: meu-servico-tls-secret items: - key: certificado.crt path: certificado.crt - key: chave-privada.key path: chave-privada.key ``` Recapirulando, aprendemos o que são as Secrets do Kubernetes, os tipos de Secrets e o que é a codificação base64, como criar uma Secret do tipo Opaque, como utilizar o nosso Secret como variável de ambiente dentro do Pod, como criar uma Secret para autenticação no Docker Hub, como criar um Secret do tipo TLS e como criar um ConfigMap para adicionar um arquivo no Pod e configurar o SSL no Nginx. Para realizar o passo a passo: 1. Crie o seu certificado TLS: `openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout chave-privada.key -out certificado.crt`. 2. Crie a secret do tipo TLS com o comando `kubectl create secret tls meu-servico-tls-secret --cert=certificado.crt --key=chave-privada.key`. 3. Crie o ConfigMap com o comando `kubectl create configmap nginx-config --from-file=nginx.conf`. 4. Crie o Pod com o comando `kubectl apply -f nginx-pod.yml`. 5. Crie um service para expor o Pod criado com o comando `kubectl expose pod nginx`. Liste o service com `kubectl get svc`. 6. Faça o port-forward do service para acessar o Nginx com o comando `kubectl port-forward service/nginx 4443:443`. Para testar o Nginx, acesse o endereço `https://localhost:4443` ou `https://127.0.0.1:4443` e você verá a mensagem `Bem-vindo ao Nginx!`. Você também pode utilizar o `curl -k https://localhost:4443` e verá a seguinte mensagem: Bem-vindo ao Nginx! ## Parâmetros avançados no Docker Compose - URL: https://nataliagranato.xyz/blog/parametros-compose - Data: 2024-04-08T00:00:00.000Z - Resumo: O Docker Compose é uma ferramenta poderosa para gerenciar aplicativos em contêineres. Vamos explorar alguns parâmetros avançados que você pode usar no seu arquivo `docker-compose.yml`. - Tags: docker, compose, containers # Utilizando parâmetros avançados no Docker Compose ## O que é o Docker Compose? O Docker Compose é uma ferramenta exclusiva para a plataforma Docker, projetada especificamente para gerenciar containers. Ele não é compatível com outras plataformas de containers. Para ilustrar as funcionalidades do Docker Compose, vamos analisar o seguinte exemplo de um arquivo docker-compose.yml: ```yaml version: '3.9' services: giropops-senhas: build: . ports: - '5000:5000' networks: - giropops-senhas environment: - REDIS_HOST=redis volumes: - natalia:/granato deploy: replicas: 1 resources: reservations: cpus: '0.25' memory: 128M limits: cpus: '0.50' memory: 256M redis: image: redis command: redis-server --appendonly yes networks: - giropops-senhas healthcheck: test: ['CMD', 'curl', '-f', 'http://localhost:5000'] interval: 30s timeout: 5s retries: 3 start_period: 10s networks: giropops-senhas: driver: bridge volumes: natalia: ``` Neste exemplo, temos dois serviços definidos: `giropops-senhas` e `redis`. O serviço giropops-senhas é construído a partir do Dockerfile no diretório atual (indicado pelo ponto), expõe a porta 5000 e usa a rede `giropops-senhas`. Além disso, ele define uma variável de ambiente `REDIS_HOST` e utiliza um volume chamado natalia. Já o serviço redis utiliza a imagem oficial do Redis do Docker Hub, executa o servidor Redis em modo append-only e também usa a rede giropops-senhas. Além disso, ele possui um healthcheck que verifica a saúde do serviço a cada 30 segundos. A rede `giropops-senhas` é definida como uma rede do tipo bridge, e o volume natalia é criado sem qualquer configuração adicional. Este exemplo demonstra a flexibilidade e o poder do Docker Compose na definição e gerenciamento de múltiplos containers e suas interações. ## Alguns comandos para facilitar o seu dia a dia O Docker Compose é uma ferramenta que permite definir e gerenciar aplicativos multi-container. Ele utiliza um arquivo de configuração chamado docker-compose.yml para especificar os serviços, redes e volumes necessários para a execução desses contêineres. Aqui estão algumas das instruções que você mencionou e o que elas fazem: - `docker compose up -d`: Inicia os serviços definidos no arquivo docker-compose.yml em segundo plano (-d). Isso cria e inicia os contêineres conforme as configurações especificadas. - `docker compose ps`: Exibe o status dos serviços definidos no arquivo docker-compose.yml. Mostra quais contêineres estão em execução, parados ou com erro. - `docker compose down`: Encerra todos os serviços e contêineres definidos no arquivo docker-compose.yml. Isso também remove as redes e volumes associados. - `docker compose pause`: Pausa a execução dos serviços e contêineres definidos no arquivo docker-compose.yml. Isso pode ser útil para depurar ou realizar manutenção. - `docker compose unpause`: Retoma a execução dos serviços e contêineres pausados. - `docker compose logs -f`: Exibe os logs dos serviços em tempo real (-f). Isso é útil para depurar problemas ou monitorar a saída dos contêineres. ## Docker compose build, replicas e resources ### Funcionalidade `build` A funcionalidade build é utilizada no arquivo docker-compose.yml para construir a imagem de um serviço a partir de um Dockerfile localizado no diretório atual. Isso permite personalizar a imagem do serviço antes de executá-lo. Exemplo: ```yaml services: giropops-senhas: build: . ``` Neste exemplo, o serviço giropops-senhas está sendo construído a partir do Dockerfile localizado no diretório atual (.). ### Funcionalidade replicas A funcionalidade `replicas` define o número de réplicas de um serviço que serão criadas e executadas. Ela permite dimensionar horizontalmente os serviços, distribuindo a carga entre várias instâncias do mesmo serviço. Exemplo: ```yaml services: giropops-senhas: ... deploy: replicas: 3 ```` Neste exemplo, o serviço `giropops-senhas` terá três réplicas em execução. ### Funcionalidade resources A funcionalidade resources permite definir limites e reservas de recursos para um serviço. Isso inclui especificações de CPU e memória para garantir que os recursos sejam alocados de forma eficiente e equitativa entre os serviços. Exemplo: ```yaml services: giropops-senhas: ... deploy: resources: reservations: cpus: '0.25' memory: 128M limits: cpus: '0.50' memory: 256M ```` Neste exemplo, o serviço `giropops-senhas` tem uma reserva de 0,25 CPUs e 128MB de memória por réplica, com um limite máximo de 0,50 CPUs e 256MB de memória por réplica. ## Comandos úteis do Docker Compose Essas funcionalidades fornecem flexibilidade e controle sobre a construção, replicação e alocação de recursos dos serviços definidos no arquivo `docker-compose.yml`. - `docker compose -f docker-compose.yml up -d`: Inicia os serviços definidos no arquivo docker-compose.yml em segundo plano (-d). Isso cria e inicia os contêineres conforme as configurações especificadas. - `docker compose -f docker-compose.yml up -d --scale redis=3`: Inicia os serviços definidos no arquivo docker-compose.yml em segundo plano (-d) e escala o serviço redis para 3 réplicas. Isso cria e inicia múltiplos contêineres do serviço redis. - `docker compose -f docker-compose.yml build`: Constrói as imagens dos serviços definidos no arquivo docker-compose.yml. Isso é útil quando você fez alterações nos Dockerfiles ou nas configurações dos serviços. Esses comandos são úteis para gerenciar e monitorar os serviços definidos no arquivo `docker-compose.yml` de forma eficiente e eficaz. # Qual é a diferença entre Docker e Docker Compose? - **Docker**: O Docker é uma plataforma de virtualização de contêineres que permite empacotar, distribuir e executar aplicativos em ambientes isolados chamados contêineres. Ele fornece uma maneira consistente de empacotar aplicativos, suas dependências e configurações em um único pacote. Cada contêiner é uma instância isolada de um aplicativo, com seu próprio sistema de arquivos, bibliotecas e recursos. O Docker usa imagens para criar contêineres. As imagens são como modelos que contêm todas as instruções para criar um contêiner. É amplamente utilizado para desenvolvimento, teste e implantação de aplicativos. - **Docker Compose**: O Docker Compose é uma ferramenta que simplifica a orquestração de vários contêineres. Ele permite definir e gerenciar aplicativos multi-container usando um arquivo de configuração chamado docker-compose.yml. No arquivo docker-compose.yml, você pode especificar serviços, redes, volumes e outras configurações necessárias para seus contêineres. Com o Docker Compose, você pode iniciar, parar, escalar e gerenciar todos os contêineres de um aplicativo com um único comando. É útil para cenários em que você precisa executar vários contêineres juntos, como aplicativos que dependem de bancos de dados, cache, servidores web, etc. Em resumo, o Docker é a base para criar e executar contêineres individuais, enquanto o Docker Compose é usado para definir e gerenciar aplicativos compostos por vários contêineres interconectados. Ambos são essenciais para o desenvolvimento e implantação eficiente de aplicativos baseados em contêineres. 🐳 Espero que essas informações sejam úteis para você! Se tiver mais dúvidas ou precisar de mais informações, não hesite em perguntar. ## Iniciando com o Ansible - URL: https://nataliagranato.xyz/blog/iniciando-com-o-ansible - Data: 2024-04-04T00:00:00.000Z - Resumo: O Ansible permite automatizar tarefas como configuração de sistemas, implantação de aplicativos e provisionamento de recursos de nuvem. - Tags: ansible, ssh, automação # Ansible: Uma Visão Geral ## Automatização de Tarefas O Ansible permite automatizar tarefas como configuração de sistemas, implantação de aplicativos e provisionamento de recursos de nuvem. Ele segue uma abordagem sem agentes, o que significa que não é necessário instalar um agente de software nos sistemas que você deseja gerenciar. Pode ser executado em qualquer sistema operacional que suporte Python. ## Modelagem Declarativa Em vez de escrever scripts para automatizar tarefas, os usuários definem o estado desejado dos sistemas usando uma linguagem de modelagem chamada YAML. O Ansible traduz essas definições em ações reais nos sistemas. ## Playbooks Os playbooks são arquivos YAML que descrevem as tarefas a serem executadas pelo Ansible. Eles definem o fluxo de trabalho e as configurações desejadas. Com os playbooks, você pode automatizar tarefas complexas e sequenciais. ## Integração com Nuvem e Contêineres O Ansible tem integrações nativas com várias plataformas de nuvem, incluindo AWS, Azure, Google Cloud Platform e OpenStack. Também pode ser usado para gerenciar contêineres, como Docker e Kubernetes. ## Arquitetura O Ansible usa um conjunto de módulos escritos principalmente em Python. Esses módulos são executados em um controlador remoto para gerenciar os sistemas. O Ansible não requer a instalação de um agente nos sistemas, pois se comunica diretamente com eles via SSH. ### Um projeto prático 1. **Instalação do Ansible** Certifique-se de que o Ansible está instalado na sua máquina controladora. Caso não esteja, você pode instalá-lo via gerenciador de pacotes (por exemplo, apt, yum, brew, etc.). Se preferir utilize: ``` python3 -m pip install --user ansible ``` 2. **Criação de Chaves SSH** Se você ainda não possui um par de chaves SSH, gere um usando o comando: ``` ssh-keygen -t rsa -b 4096 -f ~/.ssh/id_rsa ``` - Isso criará as chaves pública (id_rsa.pub) e privada (id_rsa) no diretório ~/.ssh/. 3. **Envio da Chave Pública para o Host de Destino**: - Copie a chave pública para o host de destino (onde você deseja executar o Ansible). Você pode fazer isso manualmente ou usar o Ansible para automatizar o processo. - Manualmente: ``` ssh-copy-id -i ~/.ssh/id_rsa.pub user@host ``` - Usando Ansible (em um playbook): ``` --- - hosts: seu_host tasks: - name: Copiar chave pública para o host authorized_key: user: seu_usuario key: "{{ lookup('file', '~/.ssh/id_rsa.pub') }}" ``` 4. **Configuração do Inventário** - Crie um arquivo de inventário (por exemplo, hosts.ini) com os detalhes dos hosts que você deseja gerenciar com o Ansible. - Exemplo de arquivo hosts.ini: ``` [servidores] servidor1 ansible_host=192.168.1.10 servidor2 ansible_host=192.168.1.20 ``` 5. **Teste a Conexão SSH** - Antes de tudo, verifique se o Ansible pode se conectar aos hosts. Execute o comando abaixo onde está localizado o seu arquivo de inventário: ``` ansible -i hosts.ini -m ping servidores ``` - Caso tenha sucesso você verá algo como: ``` 192.168.0.146 | SUCCESS => { "changed": false, "ping": "pong" } ``` 6. Crie Seus Playbooks: - Agora você pode criar seus playbooks Ansible para automatizar tarefas nos servidores. # Executando o Ansible Node Exporter Faça o clone do repositório e modifique o inventário de acordo com os servidores que deseja gerenciar. Não se esqueça de seguir os passos anteriores para ter acesso aos servidores. ``` https://github.com/Tech-Preta/ansible-node-exporter.git ``` Para executar o playbook instalar_node_exporter.yml, você pode usar o comando `ansible-playbook`. Certifique-se de estar no diretório onde o playbook está localizado. Aqui está o comando que você pode usar: ``` ansible-playbook instalar_node_exporter.yml --ask-become-pass ``` Se o seu playbook estiver em um diretório específico, você precisará fornecer o caminho completo para o playbook: ``` ansible-playbook /caminho/para/o/playbook/instalar_node_exporter.yml ``` Em caso de sucesso, a saída será semelhante a: ``` PLAY [seus_servidores] ******************************************************************************************************* TASK [Gathering Facts] ******************************************************************************************************* ok: [192.168.0.146] PLAY [Configurar tipos de chave de host permitidos] ************************************************************************** TASK [Adicionar tipos de chave de host ao cliente SSH] *********************************************************************** ok: [192.168.0.146] => (item=HostKeyAlgorithms ssh-ed25519,ecdsa-sha2-nistp256,ssh-rsa,rsa-sha2-512,rsa-sha2-256) PLAY [seus_servidores] ******************************************************************************************************* TASK [Gathering Facts] ******************************************************************************************************* ok: [192.168.0.146] TASK [node_exporter : Baixar o Node Exporter] ******************************************************************************** changed: [192.168.0.146] TASK [node_exporter : Criar diretório para o Node Exporter] ****************************************************************** ok: [192.168.0.146] TASK [node_exporter : Extrair o Node Exporter] ******************************************************************************* changed: [192.168.0.146] TASK [node_exporter : Mover o Node Exporter para /usr/local/bin] ************************************************************* changed: [192.168.0.146] TASK [node_exporter : Criar usuário para o Node Exporter] ******************************************************************** ok: [192.168.0.146] TASK [node_exporter : Copiar o serviço systemd do Node Exporter] ************************************************************* changed: [192.168.0.146] TASK [node_exporter : Definir permissões nos arquivos temporários do Ansible] ************************************************ changed: [192.168.0.146 -> localhost] TASK [node_exporter : Habilitar e iniciar o serviço do Node Exporter] ******************************************************** ok: [192.168.0.146] PLAY RECAP ******************************************************************************************************************* 192.168.0.146 : ok=11 changed=5 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 ``` Certifique-se de ter um arquivo de inventário configurado corretamente e definido os hosts alvo no playbook ou passá-los como argumentos na linha de comando, conforme necessário. Isso garantirá que o Ansible execute as tarefas definidas no playbook nos hosts especificados. ## Referências - [O que é Ansible - 4Linux](https://4linux.com.br/o-que-e-ansible/) - [O que é o Ansible - CursoDevOps](https://cursodevops.com.br/o-que-e-o-ansible/) - [Blog do Ansible - InterOp](https://www.interop.com.br/blog/ansible/) Este texto foi construído com a ajuda das IAs Copilot e ChatGPT. ## Testes de carga no Kubernetes - URL: https://nataliagranato.xyz/blog/testes-de-carga-kubernetes - Data: 2024-04-04T00:00:00.000Z - Resumo: Os testes de carga desempenham um papel crucial na avaliação e otimização do desempenho de aplicativos implantados no Kubernetes. - Tags: kubernetes, testes, kubecarga ## A Importância dos testes de carga no Kubernetes: Garantindo a resiliência e escalabilidade Em um ecossistema digital cada vez mais dinâmico e complexo, a capacidade de garantir que as aplicações permaneçam funcionais e responsivas mesmo sob pesadas cargas de trabalho é crucial. É aqui que os testes de carga entram em cena, desempenhando um papel fundamental na garantia de que as aplicações hospedadas no Kubernetes possam enfrentar desafios de escalabilidade e resiliência. O Kubernetes, com sua capacidade de orquestrar e gerenciar contêineres em escala, oferece um ambiente altamente flexível para implantar e executar aplicações distribuídas. No entanto, a escalabilidade dinâmica proporcionada pelo Kubernetes também pode apresentar desafios únicos. À medida que o tráfego aumenta, é crucial garantir que os recursos alocados possam lidar com a demanda adicional sem comprometer a qualidade do serviço. A finalidade dos testes de carga no Kubernetes é simular condições de uso intensivo, submetendo as aplicações e infraestrutura a cargas de trabalho cada vez maiores, a fim de avaliar seu desempenho e identificar possíveis gargalos. Esses testes não apenas ajudam a determinar os limites de escalabilidade de uma aplicação, mas também fornecem insights valiosos sobre o comportamento do sistema sob diferentes condições de carga. ### Planejamento Adequado: - Planeje requisitos de hardware, distribuição e topologia da infraestrutura. - Facilite o dimensionamento e a manutenção do cluster. ### Configuração de Rede: - Escolha uma solução de rede adequada. - Utilize segmentação de rede para segurança. ### Gerenciamento de Recursos: - Defina limites e solicitações de recursos para os pods. - Monitore o uso de recursos e implemente escalonamento automático. ### Backup e Recuperação: - Garanta a integridade dos dados armazenados nos volumes persistentes. - Use ferramentas de backup confiáveis. ### Testes de Carga Realistas: - Simule cenários reais com ferramentas como k6 ou loadtest. - Identifique problemas de desempenho. ### Monitoramento Contínuo: - Monitore o desempenho e o uso de recursos. - Faça ajustes conforme necessário. ### Automação de Escalonamento: - Use recursos nativos de escalonamento automático do Kubernetes. ## Ferramentas Recomendadas: - **k6**: Ferramenta de teste de carga baseada em JavaScript. - **Locust**: Ferramenta rica em recursos para testes de carga complexos. - **Kubecarga**: O teste cria deployments de forma contínua em intervalos regulares para simular carga no cluster. Em resumo, o Kubernetes e suas ferramentas oferecem um ecossistema robusto para testes de carga, garantindo que seus aplicativos sejam resilientes e dimensionados adequadamente. # Um exemplo prático com Kubecarga Este é um exemplo de teste de carga em Go para clusters Kubernetes. O teste cria deployments de forma contínua em intervalos regulares para simular carga no cluster. ## Pré-requisitos - Go instalado na máquina local - Acesso a um cluster Kubernetes (local ou remoto) - Configuração do Kubernetes (`kubectl`) ou arquivo `kubeconfig` para autenticação e autorização ## O que o código faz O código cria deployments no cluster Kubernetes em intervalos regulares. No exemplo fornecido, ele cria deployments usando a imagem `nginx`, mas pode ser adaptado para outras imagens e tipos de recursos do Kubernetes. ## Pontos de atenção - Caso não seja setado no momento da execução o caminho do KUBECONFIG ele herdará das variáveis de ambiente. - O teste é para criação de deployments, caso deseje mudar o Namespace, Name, Imagem e etc realize a alteração entre as linhas 67-89. ### Clone este repositório ```bash git clone https://github.com/Tech-Preta/kubecarga.git cd kubecarga ``` ### Inicialize o módulo Go Execute o seguinte comando para inicializar um novo módulo Go: ```bash go mod init ``` ### Instalação das dependências Para instalar as dependências necessárias, execute os seguintes comandos: ```bash go get k8s.io/client-go/kubernetes go get k8s.io/client-go/rest go get k8s.io/client-go/tools/clientcmd ``` Esses comandos irão baixar e instalar os pacotes e suas dependências, e também atualizarão os arquivos go.mod e go.sum. ### Construindo o projeto Agora que temos todas as dependências instaladas, podemos criar o executável para isso utilize o comando abaixo: ```bash go build -o kube-carga . ``` Isso irá compilar o código e criar o executável no diretório atual. ### Como executar Finalmente podemos executar a nossa aplicação com o comando abaixo: ```bash sudo chmod +x kube-carga ./kube-carga -kubeconfig /caminho/para/seu/kubeconfig ``` ## Referências - [k6](https://test.k6.io/) - [Kubernetes Distributed Performance Testing using Locust](https://thechief.io/c/cloudplex/kubernetes-distributed-performance-testing-using-locust/) - [Load Testing in Kubernetes: tools and best practices](https://testkube.io/learn/load-testing-in-kubernetes-tools-and-best-practices) Este texto foi construído com a ajuda das IAs Copilot e ChatGPT. [Você também pode realizar um laboratório prático: Teste de carga distribuída usando o Kubernetes no Google Cloud Skills Boost](https://www.cloudskillsboost.google/focuses/967?locale=pt_BR&parent=catalog) ## O que é o Helm? - URL: https://nataliagranato.xyz/blog/o-que-e-o-helm - Data: 2023-08-05T00:00:00.000Z - Resumo: O Helm é um gerenciador de pacotes para Kubernetes, que facilita a instalação e o gerenciamento de aplicativos em clusters do Kubernetes. - Tags: helm, Kubernetes ## O que é o Helm? O Helm é um gerenciador de pacotes para Kubernetes, que facilita a instalação e o gerenciamento de aplicativos em clusters do Kubernetes. Ele é usado para empacotar, distribuir e instalar aplicativos, bem como para gerenciar suas dependências. O Helm funciona usando um modelo de pacote, onde os aplicativos são empacotados em arquivos chamados “charts”. Esses charts são compostos de um conjunto de arquivos YAML que definem os recursos do Kubernetes que serão implantados e configurados no cluster. O Helm também inclui um sistema de gerenciamento de repositórios, onde os charts podem ser armazenados e compartilhados entre diferentes usuários e equipes. Isso permite que as equipes de desenvolvimento e operações compartilhem seus aplicativos com outras equipes e simplifiquem a implantação e a gestão de aplicativos em clusters Kubernetes. \*\*Alguns dos recursos mais importantes do Helm são: \***\*Gerenciamento de dependências:** O Helm permite que as dependências dos aplicativos sejam gerenciadas automaticamente, facilitando a implantação de aplicativos complexos que precisam de vários componentes diferentes. **Rollbacks:** O Helm permite reverter rapidamente as alterações feitas em um aplicativo, em caso de problemas ou erros. **Templates:** O Helm permite que os arquivos YAML sejam configurados dinamicamente, usando variáveis de modelo. Isso torna a implantação de aplicativos mais flexível e fácil de personalizar. **Valores de configuração:** O Helm permite que os valores de configuração sejam definidos separadamente dos arquivos YAML do chart. Isso simplifica o gerenciamento de configurações em diferentes ambientes. O Helm é uma ferramenta de código aberto, mantida pela comunidade e hospedada no GitHub. Ele é amplamente utilizado no ecossistema Kubernetes e possui uma grande comunidade de usuários e desenvolvedores. Aqui estão alguns dos principais comandos do Helm que podem ser usados para debug: ``` helm install --dry-run --debug ``` Esse comando executa uma simulação da instalação do chart, exibindo informações detalhadas do processo de instalação, como os valores de configuração, recursos do Kubernetes que serão criados e outras informações relevantes. Ele é útil para verificar se as configurações estão corretas antes de fazer a instalação real. ``` helm lint ``` Esse comando executa uma verificação estática no chart para garantir que ele esteja formatado corretamente e siga as melhores práticas do Helm. Ele verifica se o chart tem arquivos obrigatórios, se os valores estão definidos corretamente e se a sintaxe está correta. ``` helm get manifest ``` Esse comando exibe o manifesto Kubernetes que foi gerado para um determinado release do Helm. Isso permite que você visualize o que será criado no Kubernetes antes de fazer a instalação real. ``` helm get values ``` Esse comando exibe os valores de configuração que foram definidos para um determinado release do Helm. Isso é útil para verificar se os valores foram definidos corretamente antes da instalação. ``` helm rollback ``` Esse comando faz o rollback para uma versão anterior do release do Helm. Ele é útil para reverter uma atualização que pode ter causado problemas no ambiente Kubernetes. ``` helm delete --purge ``` Esse comando remove um release do Helm e todos os seus recursos associados do cluster Kubernetes. É útil para limpar um ambiente que não está sendo mais utilizado. Esses são apenas alguns dos principais comandos do Helm para debug. Existem outros comandos e opções disponíveis que podem ser úteis para diferentes cenários de debug. Consulte a documentação oficial do Helm para obter mais informações. ## Introducing Multi-part Posts with Nested Routing - URL: https://nataliagranato.xyz/blog/nested-route/introducing-multi-part-posts-with-nested-routing - Data: 2021-05-02T00:00:00.000Z - Resumo: The blog template supports posts in nested sub-folders. This can be used to group posts of similar content e.g. a multi-part course. This post is itself an example of a nested route! - Tags: multi-author, next-js, feature # Nested Routes The blog template supports posts in nested sub-folders. This helps in organisation and can be used to group posts of similar content e.g. a multi-part series. This post is itself an example of a nested route! It's located in the `/data/blog/nested-route` folder. ## How Simplify create multiple folders inside the main `/data/blog` folder and add your `.md`/`.mdx` files to them. You can even create something like `/data/blog/nested-route/deeply-nested-route/my-post.md` We use Next.js catch all routes to handle the routing and path creations. ## Use Cases Here are some reasons to use nested routes - More logical content organisation (blogs will still be displayed based on the created date) - Multi-part posts - Different sub-routes for each author - Internationalization (though it would be recommended to use [Next.js built-in i8n routing](https://nextjs.org/docs/advanced-features/i18n-routing)) ## Note - The previous/next post links at bottom of the template are currently sorted by date. One could explore modifying the template to refer the reader to the previous/next post in the series, rather than by date.