Forem: Carlos Nogueira

[PT-BR] Kubectl: boas práticas

Carlos Nogueira — Thu, 23 Apr 2026 22:18:42 +0000

Boas práticas para usar o kubectl de forma eficiente e segura:

Use contextos e namespaces de forma explícita

Defina o contexto atual com kubectl config use-context para evitar operações no cluster errado.
Sempre especifique o --namespace ou configure o namespace padrão no contexto.
Liste e alterne entre contextos com kubectl config get-contexts.

Aliases e autocompletion para ganhar velocidade

Crie aliases comuns, por exemplo:

  alias k='kubectl'
  alias kgp='kubectl get pods'
  alias ksys='kubectl --namespace kube-system'

Habilite o autocomplete (Bash/Zsh) – isso reduz erros de digitação e acelera comandos.

Use kubectl explain para documentação rápida

Antes de escrever um YAML, consulte os campos disponíveis:

  kubectl explain pod.spec.containers

Manipulação segura de recursos

Nunca use kubectl delete sem antes validar com --dry-run=client ou kubectl get.
Prefira kubectl apply -f em vez de create/replace – é declarativo e seguro.
Para edição, use kubectl edit (o editor respeita o schema) e evite editar YAMLs baixados manualmente.

Aproveite os comandos integrados para debugging

kubectl logs --previous – vê logs do container anterior (útil após crash).
kubectl exec -it -- /bin/sh – acesso interativo.
kubectl port-forward – expõe serviços localmente sem alterar o cluster.
kubectl top pod/node – métricas de CPU/memória (requer Metrics Server).

Formatação e filtros de saída

Use -o wide, -o yaml ou -o json conforme necessário.
Combine com jq ou custom-columns para extrair informações específicas:

  kubectl get pods -o json | jq '.items[].metadata.name'
  kubectl get pods -o custom-columns=NAME:.metadata.name,STATUS:.status.phase

Plugins e extensões

Instale o Krew (gerenciador de plugins) e experimente:
- kubectl tree – mostra donos de recursos.
- kubectl ns – troca de namespace rapidamente.
- kubectl neat – remove campos gerados de YAMLs.

Evite comandos imperativos em produção

Prefira arquivos YAML versionados (Git) a comandos como kubectl run ... --image=.... Isso garante reprodutibilidade e revisão.

Limite escopo de ações

Use --all-namespaces apenas quando realmente necessário – pode retornar milhares de objetos.
Combine --selector (label selector) para operações em subconjuntos de recursos.

Segurança

Nunca exponha o kubeconfig (ele contém certificados ou tokens).
Revise permissões com kubectl auth can-i antes de executar ações críticas.

Seguindo essas práticas, você reduz riscos, ganha produtividade e mantém o controle sobre clusters Kubernetes.

Referências
https://kubernetes.io/docs/reference/kubectl/
https://krew.sigs.k8s.io/

[PT-BR] Ciclo de Vida de Desenvolvimento de Software com assistência de IA

Carlos Nogueira — Sun, 19 Apr 2026 21:11:25 +0000

Um bom questionamento nos dias atuais é:

"Será que as coisas mudaram mesmo no mundo de desenvolvimento de software?"

Pergunta necessária e que me fez lembrar que nunca é demais reforçar/revisitar os fundamentos.

Até porque a área de tecnologia sempre esteve sob influência de atores aleatórios e hypes sem sentido que estão bem longe de agregar valor às organizações, ou que são apenas chuva de verão.

De qualquer forma, neste processo de revisitar fundações, uma lupa no Ciclo de vida de Desenvolvimento de Software se faz necessária e considerar os casos de sucesso (e desastres) do hype atual ajuda a perceber experiências válidas a se compartilhar.

Fluxo SDLC

O fluxo SDLC (Software Development Life Cycle) é o processo de etapas para desenvolver software de forma estruturada. Um fluxo tradicional (em Cascata) inclui:

Planejamento: Definição de escopo, custos e riscos.
Análise de Requisitos: Levantamento do que o sistema deve fazer.
Design: Arquitetura, componentes, interfaces e banco de dados.
Implementação (Codificação): Escrita do código fonte.
Testes: Verificação de bugs e validação dos requisitos.
Implantação (Deploy): Disponibilização do sistema em produção.
Manutenção: Correções, melhorias e atualizações contínuas.

Variações comuns do fluxo:

· Modelo em V: Testes pareados com cada fase de desenvolvimento.
· Iterativo/Incremental: Ciclos curtos entregando partes funcionais.
· Ágil (Scrum/Kanban): Iterações rápidas (sprints) com feedback contínuo.
· Espiral: Foco em análise de riscos e prototipação.
· Continuos Delivery: Integração contínua e entrega contínua (CI/CD), unindo desenvolvimento e operações.

Cada projeto escolhe o fluxo conforme requisitos, tamanho da equipe e necessidade de entregas rápidas ou documentação rígida.

SDLC com assistência de IA

O fluxo SDLC em 2026 pode apresentar mudanças influenciadas por assistência de IA: o processo de desenvolvimento está a deixar de ser uma série de tarefas em sua maioria manuais e está se transformando em uma cadeia de valor contínua e inteligente, na qual a IA participa ativamente de todas as fases.

O Modelo de Maturidade da 3Pillar and Forrester ¹ ajuda a descrever como as organizações podem evoluir nesse cenário.

O Caminho da Maturidade

A integração da IA no SDLC não é um evento único, mas uma jornada com níveis crescentes de sofisticação e impacto.

· Nível 0: SDLC Clássico: Práticas tradicionais (Ágil, Kanban), com processos majoritariamente manuais. É a base estável e conhecida, mas sem automação inteligente ¹.
· Nível 1: Assistido por IA: A experimentação começa de forma individual e pontual, com ferramentas como assistentes de código, geradores de design e automação de testes. O progresso é real, porém inconsistente ¹
· Nível 2: Otimizado por IA: A organização formaliza a adoção, estabelecendo governança, seleção de ferramentas e integração para gerar ganhos de eficiência mensuráveis em todo o ciclo ¹.
· Nível 3: Aumentado por Agentes: Agentes de IA assumem o gerenciamento de workflows completos, coordenando tarefas e ferramentas. Humanos migram para uma posição de supervisão estratégica ("over the loop") ¹.
· Nível 4: Nativo em Agentes: As equipes operam em ambientes totalmente orquestrados por IA, com o foco humano em estratégia, design e criação de valor. O processo é desenhado para otimizar a colaboração entre humanos e máquinas ¹.

Entender em qual nível sua organização se encontra é o primeiro passo para planejar a transformação, caso seja aplicável/necessário.

Como a IA Pode Influenciar Cada Etapa do SDLC

De forma geral, a IA Generativa (GenAI) tem o maior impacto nas fases de design, implementação, teste e documentação, com mais de 70% dos desenvolvedores relatando uma redução de pelo menos 50% do tempo gasto em tarefas repetitivas ². Já nas fases iniciais, como planejamento e análise de requisitos, os benefícios ainda são menores ².

Aqui está um panorama mais detalhado da transformação em cada etapa:

Planejamento e Requisitos

· O Que a IA Faz: Gera histórias de usuário a partir de conversas, identifica conflitos em requisitos e cria rascunhos de documentação³ ⁴.
· Papéis e Ferramentas: Agente de Requisitos, Documentos de Requisitos de Negócio (BRDs), Jira, documentação assistida por IA ³.

Design e Arquitetura

· O Que a IA Faz: Propõe padrões arquiteturais (ex: eventos para alta escalabilidade), gera especificações (OpenAPI, C4) e documenta decisões de design ³.
· Papéis e Ferramentas: Agente de Design, OpenAPI, geradores de diagramas C4, Designers e Arquitetos de IA ³.

Codificação (Implementação)

· O Que a IA Faz: Gera código, refatora e resolve erros automaticamente com ferramentas mais avançadas (Agente de Codificação) ³.
· Papéis e Ferramentas: Agente de Codificação (GitHub Copilot, Amazon Q) e Engenheiro de Prompt para guiar a geração de código ⁵.

Testes (QA)

· O Que a IA Faz: Cria casos de teste, gera scripts de automação (Selenium, Cucumber), realiza automação de QA (Agente de QA) e testa de forma autônoma (Agente de Teste Autônomo) ³ ⁴.
· Papéis e Ferramentas: Agente de QA (Autonomous Quality Engineering), Selenium, Cucumber, estruturas de teste de IA ⁴.

Implantação (Deploy)

· O Que a IA Faz: Gerencia pipelines de CI/CD, toma decisões sobre os estágios de deploy e, com IAs mais avançadas (Agente de DevOps), orquestra e monitora o ciclo inteiro ⁵.
· Papéis e Ferramentas: Agente de DevOps, pipelines de CI/CD, ferramentas de monitoramento ⁵.

Manutenção e Operações

· O Que a IA Faz: Monitora sistemas, sugere correções proativas e auxilia na autoria de patches para self-healing ³
· Papéis e Ferramentas: Agente de Operações, sistemas de monitoramento, ferramentas de self-healing ³.

A Evolução das Equipes

Nem toda organização se enquadra ou precisa necessariamente entrar na jornada de evolução e maturidade do modelo.

Deve existir a devida curadoria tecnológica, metodológica e estratégica que vislumbre se adicionar assistência de AI no SDLC é algo que vai agregar valor real.

No caso que se enquadre, com a IA automatizando a criação de artefatos (código, testes, documentação), o papel humano vai se deslocar para as atividades de maior valor.

· O Profissional como "Condutor" (Conductor): A nova função principal é a de orquestrar agentes de IA, compor workflows e garantir a aderência aos padrões e objetivos de negócio.
· Surgem Novas Funções Especializadas: Vemos o aparecimento de carreiras como Arquiteto de SDLC Nativo em IA, Desenvolvedor de Engenharia de Prompt e Escritor Técnico de Workflows de IA, focados em criar as instruções e estruturas que guiam as IAs.

Os Novos Desafios e Gargalos

A velocidade trazida pela IA expõe e até amplifica gargalos existentes ¹¹.

· O Gargalo da Revisão: A maior dificuldade atualmente não é gerar código, mas sim revisar o dilúvio de código gerado pelas IAs. A capacidade humana de revisão tornou-se o principal ponto de estrangulamento ¹².
· Dívida Técnica e Segurança: Código gerado em alta velocidade pode introduzir dívida técnica, vulnerabilidades de segurança e problemas de manutenibilidade se não for devidamente governado ¹²
· Necessidade de "Guardrails": É crucial estabelecer regras claras, supervisão humana e processos de validação automatizados para mitigar os riscos. A saída da IA deve ser tratada como a de um novo desenvolvedor: potencialmente falha e que precisa ser revisada ¹² ¹⁵

Frameworks e Ferramentas Prontas

Para navegar por essa nova realidade, diversas metodologias e ferramentas já estão disponíveis.

· AWS AI-Driven Development Lifecycle (AI-DLC): Uma metodologia open-source de três fases (Inception, Construction, Operations) que integra IA em cada etapa, com gatekeepers humanos nos pontos críticos. Pode ser implementada com o Amazon Q Developer ⁹.
· Agentic DevOps (Microsoft): Uma abordagem que utiliza agentes de IA como colegas de equipe em todas as fases, do planejamento à modernização, usando ferramentas como o GitHub Copilot ¹⁰.
· 3Pillar AI-Enabled SDLC Maturity Model: Um framework útil para diagnosticar em que nível de maturidade sua organização se encontra e planejar os próximos passos ¹.
· Outras Soluções: Ferramentas como o Kiro (AWS) (IDE agente)⁸ e metodologias de empresas como EPAM (Native AI SDLC) e AMPECO (CoOperator Dev Agent) também oferecem caminhos práticos para a adoção ⁶ ⁷.

Síntese e Próximos Passos

Integrar IA no SDLC é uma oportunidade estratégica para aumentar a velocidade e a qualidade, mas exige planejamento. O primeiro passo prático é avaliar em qual nível de maturidade sua equipe se encontra, identificar os gargalos atuais e começar com projetos-piloto bem definidos, caso seja identificado a necessidade de utilização de SDLC com assistência de IA.

Referências

[PT-BR] Pois é! Um post sobre o hype.

Carlos Nogueira — Fri, 06 Feb 2026 01:04:17 +0000

Enfim, resolvi dar uma pausa na escrita do livro para escrever sobre um tema que, como muitos que acompanham as #engineeringsessions já perceberam, me incomoda bastante.

DISCLAIMER: SEMPRE enfatizo que as críticas não são à tecnologia. Tirando o lado óbvio dos prejuízos ao meio-ambiente ¹ ² e à saúde mental ocasionados pelo hype de LLM ³ ⁴ ⁵

"É ÉLE-ÉLE-EME, nada de botar a culpa na conta da AI, que por sinal é uma área muito mais abrangente do que o hype vende.⁶ ⁷ ⁸"

Sem falar na carga pesada de propaganda do tipo "comprem meu produto", "façam meu treinamento", "assinem meu serviço" coisas que tentam deturpar (até) os próprios conceitos que fazem parte do núcleo base da tecnologia que tá sendo empurrada em nossa direção pelo hype.

DISCLAIMER 2: A Stack HOMOLOGADA do seu trabalho é(ou ao menos deveria ser) de utilização OBRIGATÓRIA do profissional de T.I. que faz parte dos times técnicos.

Logo, se vc veio aqui "se queixar que o Carlos está a incentivar a não utilização de ferramentas de LLM no trabalho", pode dar meia-volta.

Não sou "hater de AI", aliás, nem acredito que esta persona exista no mundo profissional real.

Pois se não tem como evitarmos a utilização, não existe essa pessoa que vai chegar com os gestores e dizer "ME RECUSO A USAR!".

Cada um usa o que bem entender, traça a estratégia que achar mais adequada para sua própria vida profissional/carreira, ninguém precisa de "babá de tecnologia/stack" e cada um sabe onde o calo aperta.

Apesar disso, não utilizar no trabalho ferramentas que não sejam homologadas pela sua organização é requisito básico de compliance.

"NÃO DÁ PRA DERROTAR QUEM JÁ TÁ NO CHÃO"

É ruim "bater em bêbado", quando o assunto é falhas de cybersegurança⁹, ou as diversas reticências no que diz respeito aos desafios de manter¹⁰ um software gerado por ferramentas de LLM que auxiliam na codificação.

Então essas são outras coisas que NÃO irei abordar aqui.

"NÃO, ESTE HYPE NÃO É IGUAL AOS OUTROS"

Muitos comentam que "este hype é parecido com o de microsserviços" (por exemplo).

Não, não é.

Poderia ser só mais uma (boa) tecnologia para acrescentarmos à nossa stack e ao nosso trabalho.

O problema é que MUITA GENTE tenta vender como um "PARADIGMA", algo que vai "MATAR os Devs", ou substituir a engenharia de software como ela é hoje.

E é nessa parte que a propaganda me pega.

(Sob meu ponto de vista) Chega a ser ultrajante desconsiderar os avanços da engenharia depois de mais de 40 anos de história.

Existe um fluxo para a evolução e implementação da Engenharia.

Os últimos anos consolidaram um conjunto de processos, organização de times, metodologias, frameworks de trabalho, matérias relacionadas a automação, plataformas e maturidade das tecnologias que são base de tudo que é utilizado para a confecção de produtos digitais.

O fator preponderante do que nós vemos no mercado hoje, é o papel cada vez mais presente do método científico servir como base para as engenharias.

O embate entre quem se preocupa com a forma e "agradabilidade de leitura" do código(artesãos) e quem "só" deseja resolver os problemas(engenheiros) havia encontrado o chão comum: a ciência.

"Dave Farley aborda o papel da ciência na evolução das engenharias aqui neste vídeo:
-Engineering for Software"

Esse fluxo não sumiu(e nem vai tão cedo). Ele está aí e construir produtos digitais ainda obedece aos mesmos fundamentos.

Quando aquela pessoa Dev amiga (de verdade) diz pra você "utilize a LLM para auxiliar no código, mas tenha senso crítico", na realidade ela não está nada mais do que afirmando nas entrelinhas que você precisa estudar os fundamentos da engenharia moderna para poder implementar.

Isso não mudou, mesmo que a propaganda tente vender as técnicas de engenharia (Ágil,Cloud Native,FLOSS,Entrega Contínua,12factor app, OpenAPI,DDD,BDD,TDD,etc.) usando outro nome, outra roupagem.

O desafio está em conseguir filtrar o que é evolução de fundação, do que é propaganda de uma solução proprietária.

Muitas "novidades" alardeadas pelo hype, não passam de imagens de contêineres que fazem chamadas para consumir alguma API proprietária, ou padrões(como OpenAPI) "repaginados"(por vezes mal implementados) para a "nova realidade".

"PARE DE TREINAR O MODELO DOS OUTROS E VÁ TREINAR O SEU CÉREBRO!"

Se você faz parte de times com pouca senioridade (estou falando sobre senioridade do TIME e não individual), muito provavelmente a utilização de codificação assistida por LLM vai acelerar o prejuízo e dívida técnica que o seu time naturalmente já iria produzir¹¹.

Então sabendo disso, você deve atuar para auxiliar na evolução do conhecimento de engenharia do seu time.

Este deveria ser o papel de quem é Senior++ e gestores, porém a situação atual pede que todas e todos que fazem parte da equipe tenham de procurar um papel de compartilhamento de conhecimento no time.

Neste caso, as ferramentas de AI também podem auxiliar.

Toda equipe, mesmo antes do hype, já deveria ter um contexto de gestão do conhecimento. Isso agora tem um papel muito mais forte.

"PROPAGANDA NÃO É FUNDAMENTO, SOFTWARE PROPRIETÁRIO NÃO É FLOSS(Free Libre Open Source Software)"

Propaganda não é fundamento, o "método de utilização do software do zezinho" não é o mesmo do software do pedrinho.

Aliás, nem as metodologias de desenvolvimento estão fincadas em pedra.

XP foi uma experiência que deu certo com o Kent Beck naqueles projetos, mas talvez não vá dar certo na sua organização.

Em resumo: ATÉ as experiências que deram certo no passado, muito provavelmente não vão funcionar no caso da sua organização.

Mas por que ressaltar isso?

O hype atual emula EXPERIÊNCIAS QUE NÃO DERAM CERTO no passado.

focar em soluções proprietárias ¹²
aproximar programação da linguagem humana¹³ ¹⁵ ¹⁶ ¹⁷

Não é "discurso de doidinho do GNU/Linux". O core das bigtechs/Cloud e principais produtos digitais do mercado é FLOSS (FOSS analytical). E o hype não tem como base FLOSS.

Ano passado(2025) as primeiras iniciativas mais relevantes começaram a aparecer ¹⁸, o problema é que estão vindo tarde ¹⁹.

E para completar, o ritmo de surgimento de "padrões" e "especificações" é frenético, a ponto de vermos a "morte" de padrões que não duram sequer 3 meses²⁰.

"CUIDADO COM O SENIOR++ ENDOSER DO HYPE"

Desde o surgimento do hype de LLM diversas pesquisas já demonstraram que isto acelera sua equipe(pro bem e/ou pro mal)²¹.

Se a equipe for boa, vai acelerar a qualidade boa da entrega.

Se a equipe for ruim, vai acelerar os problemas.²²

Essa lógica vale pros devs Seniors++ individualmente também.

A pessoa tem os fundamentos bem definidos na memória muscular, já têm bastante vivência de mercado. Daí fica fácil enxergar o grande valor que a ferramenta pode gerar no trabalho do dia-a-dia.

E isso é um problema.

Nós temos nossas experiências pessoais, porém da mesma forma devs e projetos crescem em conjunto, seja num time, seja numa organização, seja na comunidade de profissionais de tecnologia.

Não existe time de uma pessoa só!

Dev senior consegue aproveitar, mas TEM DE SER SENIOR e não dá pra fingir que "todo time é repleto de seniors".

Não dá pra fingir que times com senioridade baixa não existem, se bobear são a grande maioria no mercado.

Então muito cuidado com Dev Senior++ que está empolgado nas redes sociais. A experiencia desse tipo de pessoa NÃO É a mesma que a sua, principalmente se você tem pouca senioridade e ainda tem um caminho grande de estudo/trabalho por percorrer.

CONCLUSÃO DO DESABAFO

E é isso, este foi um desabafo que estava a correr na minha cabeça já tem umas semanas.

Sugestões de Eps das Sessões de Engenharia relacionados ao texto:
- "Vida do Profissional de Tecnologia": https://youtu.be/3hNH881-5cw
- "Engenheiros Staff+": https://youtu.be/15Zbg7Vk8Kw
- "Retrospectiva 2025": https://youtu.be/kdkPBE7fj20
- "Limites da Simplicidade": https://youtu.be/byl4QAPajrU
- "Velocidade":
https://youtu.be/QWRsLrbFch0
- "Filosofia UNIX: https://youtu.be/mWXR_OBwjqY
- "BDD":
https://youtu.be/VMY_Z2jDl00
- "O Mítico Homem-mês": https://youtu.be/f3z794AMpng
- "DDD":
https://youtu.be/rt0gSnwqcGY
- "Complexidade Acidental":
https://youtu.be/IO4kOGfyVds
- "TDD":
https://youtu.be/H3N2B5gcGYs
- "12 Factor App":
https://youtu.be/8SMdEiNSKf4

*A leitura fica mais completa com consulta aos links das referências no texto.

Crossplane: GKE Installation

Carlos Nogueira — Wed, 24 Feb 2021 14:27:50 +0000

..Crossplane is an open source Kubernetes add-on that supercharges your Kubernetes clusters enabling you to provision and manage infrastructure, services, and applications from kubectl. (crossplane.io)

Crossplane is a CNCF sandbox project, open source, community driven solution and add-on for your kubernetes API to manage and compose infrastructure.

It uses a team centric approach with Open Application Model.

The idea is to use a kubernetes cluster as a single control panel. where there is freedom to provision resources in any cloud and link these services with the cluster itself. The cluster does not need to be in the same cloud as the services.

Crossplane Application Architecture Example

Basically a provider is configured in the cluster linked to a service account of a specific cloud.

Crossplane CRDs use this provider to deploy and link services across the cluster.

Each cloud service has its particularity and is defined through structures of compositions, definitions and namespaced k8s specifications.

The CRDs that define the crossplane providers services are called XRDs.

Crossplane has an external CLI and its own CRDs that are deployed in the cluster.

Since CRDs and XRDs are deployed, the provisioning operation no longer requires the local CLI. Just having kubectl configured needed to re-deploy the types of resources that are already configured.

Installation

Follows ansible to automate the installation of a crossplane + GCP Provider in a GKE cluster

Requirements

GKE
Google Cloud SDK (316.+)
bq (2.0.62+)
core (2020.10.23.+)
gsutil (4.54.+)
Kubernetes(1.16.+)
kubectl(1.16.+)
Helm(3.+)
ansible (2.10.+)
openshift python client (0.11.+)
PyYAML (5.3.+)

Deploy

1 - Git clone the repo to bastion

  - $ git clone https://gitlab.com/cedon/crossplane-gcp.git

2 - Check if roles/crossplane/defaults/main.yml is right for the environment you want to deploy

3 - Deploy with ansible command:

  - $ ansible-playbook -i ./hosts -e \ 
'ansible_python_interpreter=/usr/bin/python3' crossplane.yml 
\ --tags "install, gcp" -vvv

After the Deploy you must take care about the file creds.json. It will be located at the repo root, and has the service account credentials.

4 - Check Crossplane Installation

  - $ kubectl get all -n crossplane-system
  - $ kubectl crossplane --help

References

Crossplane - https://crossplane.io
Crossplane Install and Configure V1.0 - https://crossplane.io/docs/v1.0/getting-started/install-configure.html
Crossplane Provision Infrastructure - https://crossplane.io/docs/v1.0/getting-started/provision-infrastructure.html

Linkerd: Service Mesh Overview

Carlos Nogueira — Thu, 19 Nov 2020 05:37:26 +0000

Linkerd is a ultralight, ultrafast, security-first service mesh for Kubernetes.

Linkerd Service Mesh comes to solve the problem to add 3 layers at Cloud-Native Kubernetes app:

Observability
Security
Reliability

Going back in monolith time, we have to deal with one language technology stack(for example: Java). And 3 operations teams to interact, deploy, operate with it: Devs, Networking and Security.

But if we look at a Cloud-Native Kubernetes app, we have multi-language and architecture scenarios. So, the chalengers are most complex, and add Observability, Security Layer and Reliability becomes a implementation and operations difficult task.

On earliest 2010 years, Twitter, Netflix and Google dealt with this situations making native languages libraries for their microservices stacks.

Twitter has evolved its jvm based library Finable to deal with a multilanguage architecture. Then changed the name to Linkerd on 2016. Became the first Service Mesh Plataform.

In 2017 Linkerd was donated to CNCF.

In 2018 was launched the Linkerd 2.0 version. With several changes. Now we have a Linkerd2-proxy Rust-based and Control Plane Golang-based.

Implement a network of proxies that communicate securely(mTLS) using HTTP and gRPC. It was the solution found to inject the mesh layer. Each microservice meshed has a proxy injected like a side-car container.

The name of the proxies network layer is Data Plane. This is the base of collected metrics and active operations.

Data Plane

The other module is the Control Plane. This is the Linkerd Plataform Owners API Operations interface. Can be access by CLI or Browser.

Linkerd 2.x Architecture

Linkerd Features:

Observability: Service-level golden metrics: success rates, latencies, throughput. Service topologies
Reliability: Retries, timeouts, load balancing, circuit breaking
Security: Transparent mTLS, cert management and rotation, policy

Most Service Mesh Plataforms are based on Envoy Proxy, but it isn't The Linkerd case.

Use a "micro-proxy" Rust-based let the project to..

avoid a entire class of memory vulnerabilities.
compiles to native code(no runtime env/GC). So it can be ultralight and ultrafast
built on Tokio, Hyper, H2, Tower and the rest of modern Rust async networking stack.

Linkerd has huge numbers and benchmark results:

4+ years in production
5,000+ Slack channel members
10,000+ GitHub stars
100+ contributors
Weekly edge releases
Open governance, neutral home
Tl;dr: really fast. Not as fast as "no service mesh", but significantly smaller and faster than Istio.

Don't use Linkerd if your app..

..is a monolith
..that communicate purely via Kafka or another distributed queue

Linkerd: Install and Basic Ops

References

Linkerd Docs - https://linkerd.io/docs
Course: Introduction to Service Mesh with Linkerd
CNCF - https://www.cncf.io/
gRPC - https://grpc.io/
Rust - https://www.rust-lang.org/
Golang - https://golang.org/
Kinvolk Benchmark - https://kinvolk.io/blog/2019/05/performance-benchmark-analysis-of-istio-and-linkerd/
Tokio - https://tokio.rs/
Hyper - https://github.com/hyperium/hyper
H2 - https://github.com/hyperium/h2
Tower - https://github.com/tower-rs/tower
Kafka - https://kafka.apache.org/intro

Linkerd: Install and Basic Ops

Carlos Nogueira — Sun, 01 Nov 2020 01:59:27 +0000

Linkerd Installation, Basic Operations and My Thoughts About it.

Requirements(Works on Production too)

GKE or Minikube or kind
Kubernetes(1.16+)
kubectl(1.16+)
Linkerd 2.x

1 - Install Linkerd CLI

- $ curl -sL https://run.linkerd.io/install | sh
- $ export PATH=$PATH:$HOME/.linkerd2/bin
- $ linkerd version

2 - Validate Kubernetes Cluster

- $ linkerd check --pre
OUTPUT:
..
pre-kubernetes-capability
-------------------------
‼ has NET_ADMIN capability
    found 1 PodSecurityPolicies.. 
‼ has NET_RAW capability
    found 1 PodSecurityPolicies..

(on GKE ignore this warnings. This is because there's no linkerd previously installation and the pods security policies are on. But, dont worry)

3 - Deploy Linkerd

- $ linkerd install | kubectl apply -f -
- $ linkerd check
- $ kubectl get all -n linkerd

(now the linkerd check command must have all green checks output)

4 - Access the Dashboard

- $ linkerd dashboard
OUTPUT:
Linkerd dashboard available at:
http://localhost:50750
Grafana dashboard available at:
http://localhost:50750/grafana
Opening Linkerd dashboard in the default browser

You can use port-forward to expose the dashboard.

- $ kubectl port-forward --address 127.0.0.1 \
service/linkerd-web 5000:8084 -n linkerd

Dashboard is referenced by the linkerd-web service. If you are executing from a bastion, you can define the bastion IP editing the deployment.apps/linkerd-web

- $ kubectl edit deployment.apps/linkerd-web -n linkerd
# you must edit the address on the arg enforced-host:
# BEFORE EDIT:-enforced-host=^(localhost|127\.0\.0\.1|..
# AFTER  EDIT:-enforced-host=^(bastionhost|192\.168\.0\.9|..

- $ kubectl port-forward --address 0.0.0.0 \
service/linkerd-web 5000:8084 -n linkerd

Now you can open the Dashboard with bastion IP(192.168.0.9 as the example) and port 5000

With dashboard we can visualize our microservices architecture in selected namespace

Clicking on the Grafana icon link at the pod line, we can see the pod stats on a template pre-configurated

Each meshed pod will have a pre-configured Grafana Dashboard.

The Linkerd is a lightweight powerful service mesh plataform, and had the advantage to be strongly decoupled architecture. It can be added and removed without influencing your app.

Linkerd is unique in that it is part of the Cloud Native Foundation (CNCF), which is the organization responsible for Kubernetes.

The CLI had a simple and intuitive user experience.

You can mesh your deployed microservice with simple commands

#add with linkerd inject command on a deployed app
- $ kubectl get -n YOUR_APP_NAMESPACE deploy -o yaml \
  | linkerd inject - \
  | kubectl apply -f -

or add few yaml instructions(two config lines on the app deployment yaml)

#example:
annotations:
  checksum/config: 37b064423157b6fe14ddeba6924195c1075bd17feb
  linkerd.io/inject: enabled

#this values are extract from the command
- $ kubectl get -n YOUR_APP_NAMESPACE deploy -o yaml \
  | linkerd inject -

To reverse the mesh on your app do:

- $ kubectl get -n YOUR_APP_NAMESPACE deploy -o yaml \
  | linkerd uninject - \
  | kubectl apply -f -

To uninstall Linkerd

- $ linkerd uninstall | kubectl apply -f -

References

Linkerd Docs - https://linkerd.io/docs

Converting Helm Charts to K8S SDK Templates

Carlos Nogueira — Fri, 16 Oct 2020 07:37:55 +0000

If you are working on a helm chart, however, you need to make customizations or debug in a more native way. An alternative is to convert it to kubernetes SDK templates.

Requirements

Kubernetes(1.16+)
helm (3+)
kubectl(1.16+)

The process is simple:
(mongodb example)

1 Install desired chart generic release

- $ kubectl create ns mgodb-ns
- $ helm install mongodb --namespace mgodb-ns stable/mongodb

2 Extract default generated chart values from the release

- $ helm get values mongodb -a --output yaml > values.yaml

3 Convert the chart to template

- $ helm template --values ./values.yaml --output-dir \
./manifests stable/mongodb

OUTPUT: 
wrote ./manifests/mongodb/templates/secrets.yaml
wrote ./manifests/mongodb/templates/pvc-standalone.yaml
wrote ./manifests/mongodb/templates/svc-standalone.yaml
wrote ./manifests/mongodb/templates/deployment-standalone.yaml

Now you can work on native SDK k8s yamls at the directory manifests/mongodb/templates/

4 Don't forget to delete the generic release

- $ helm uninstall mongodb
- $ kubectl delete ns mgodb-ns

Deploy BigchainDB using Docker Compose

Carlos Nogueira — Sun, 20 Oct 2019 21:37:35 +0000

BigchainDB is a "blockchain database"..

..With high throughput, low latency, powerful query functionality, decentralized control, immutable data storage and built-in asset support, BigchainDB is like a database with blockchain characteristics.(bigchaindb.com)

It's a good choice for who wants to work with immutable databases.

Here's a tutorial to deploy a local infrastructure docker based.
(I'm using Debian Buster, but the project recommends latests Ubuntu and CentOS)

Requirements

Docker(19.03+)
Docker-Compose (2.0+)
python3.6+
pip3+
bigchaindb_driver(for the tests, install via pip3)

Clone Repo

$ git clone https://github.com/bigchaindb/bigchaindb.git

Install

Bigchaindb Dependences

$ sudo bash bigchaindb/pkg/scripts/bootstrap.sh --operation install

Deploy Docker Compose

$ docker-compose -f bigchaindb/docker-compose.yaml up -d

Check Containers

$ sudo docker ps
CONTAINER ID        IMAGE                           COMMAND                  CREATED             STATUS                    PORTS                                                        NAMES
6b9dcd4f524d        bigchaindb_bigchaindb           ".ci/entrypoint.sh"      32 minutes ago      Up 32 minutes (healthy)   0.0.0.0:9984-9985->9984-9985/tcp, 0.0.0.0:32770->26658/tcp   bigchaindb_bigchaindb_1
4b4c08cc3680        tendermint/tendermint:v0.31.5   "sh -c 'tendermint i…"   33 minutes ago      Up 32 minutes             0.0.0.0:26656-26657->26656-26657/tcp                         bigchaindb_tendermint_1
443b20abbb7d        mongo:3.6                       "docker-entrypoint.s…"   33 minutes ago      Up 32 minutes             0.0.0.0:27017->27017/tcp                                     bigchaindb_mongodb_1
3afee461139c        nginx                           "nginx -g 'daemon of…"   33 minutes ago      Up 32 minutes             0.0.0.0:33333->80/tcp                                        bigchaindb_vdocs_1

Testing db

Create testdb.py to test your installation:

from bigchaindb_driver import BigchainDB
from bigchaindb_driver.crypto import generate_keypair
from time import sleep
from sys import exit

alice, bob = generate_keypair(), generate_keypair()

bdb_root_url = 'http://localhost:9984'  # Use YOUR BigchainDB Root URL here

bdb = BigchainDB(bdb_root_url)

bicycle_asset = {
    'data': {
        'bicycle': {
            'serial_number': 'abcd1234',
            'manufacturer': 'bkfab'
        },
    },
}

bicycle_asset_metadata = {
    'planet': 'earth'
}

prepared_creation_tx = bdb.transactions.prepare(
    operation='CREATE',
    signers=alice.public_key,
    asset=bicycle_asset,
    metadata=bicycle_asset_metadata
)

fulfilled_creation_tx = bdb.transactions.fulfill(
    prepared_creation_tx,
    private_keys=alice.private_key
)

sent_creation_tx = bdb.transactions.send_commit(fulfilled_creation_tx)

txid = fulfilled_creation_tx['id']

asset_id = txid

transfer_asset = {
    'id': asset_id
}

output_index = 0
output = fulfilled_creation_tx['outputs'][output_index]

transfer_input = {
    'fulfillment': output['condition']['details'],
    'fulfills': {
        'output_index': output_index,
        'transaction_id': fulfilled_creation_tx['id']
    },
    'owners_before': output['public_keys']
}

prepared_transfer_tx = bdb.transactions.prepare(
    operation='TRANSFER',
    asset=transfer_asset,
    inputs=transfer_input,
    recipients=bob.public_key,
)

fulfilled_transfer_tx = bdb.transactions.fulfill(
    prepared_transfer_tx,
    private_keys=alice.private_key,
)

sent_transfer_tx = bdb.transactions.send_commit(fulfilled_transfer_tx)

print("Is Bob the owner?",
    sent_transfer_tx['outputs'][0]['public_keys'][0] == bob.public_key)

print("Was Alice the previous owner?",
    fulfilled_transfer_tx['inputs'][0]['owners_before'][0] == alice.public_key)

Execute Test Script

   $ python3 testdb.py 
   [out]Is Bob the owner? True
   [out]Was Alice the previous owner? True

References

Bigchaindb Docs - http://docs.bigchaindb.com/

Deploying A Private Storage Cloud (SeaFile) Using Docker

Carlos Nogueira — Fri, 18 Oct 2019 13:04:14 +0000

Seafile...

..is an open source file sync&share solution designed for high reliability, performance and productivity. Sync, share and collaborate across devices and teams.(SeaFile.com)

Here we have a powerful suite: service, desktop/mobile clients, cli and web interface. A good private alternative to public clouds.

Features includes storage, sharing, security and LDAP integration.

Here's a video review

Compose

For this configuration the host just need allow services using the web ports(80,443).

The docker compose sets 3 containers: mariadb, memcached and seafile.

The seafile container responds to the service. It have a proxy nginx redirecting que request to internal service listen at port 8000.

Let's Encrypt

To use Let's Encrypt, you must set this parameters:

    ports:
      ...
      - "443:443" 
      ...
    environment:
      ...
      - SEAFILE_SERVER_LETSENCRYPT=true 
      - SEAFILE_SERVER_HOSTNAME=your.domain.com

The domain your.domain.com must be valid and internet reachable, or the LetsEncrypt handshakes wont work.

MariaDB Connection and SeaFile Authentication

You must check the database connection.

Change the value db_secret for your mysql connection password.

MYSQL_ROOT_PASSWORD=db_secret must be the same value of DB_ROOT_PASSWD=db_secret.

DB_HOST=db must be the same of the mariadb service name db.

services:
  db:
   ...
    environment:
      - MYSQL_ROOT_PASSWORD=db_secret 
  seafile:
  ...
    environment:
      - DB_HOST=db
      - DB_ROOT_PASSWD=db_secret

The SeaFile Authentication uses e-mail as login name.

Change the value a_secret for your admin password.

services:
  ... 
  seafile:
  ...
    environment:
     - SEAFILE_ADMIN_EMAIL=me@example.com
     - SEAFILE_ADMIN_PASSWORD=a_secret

Deploy SeaFile

Requirements

Docker(19.03+)
Docker-Compose (2.0+)

Deploy:

clone repository

git clone https://gitlab.com/cedon/seafile.git

here two ways to deploy:

1.official seafile sample docker-compose.yaml file.

1.1. edit compose file seafile/docker-compose.yml

1.2. deploy infrastructure

docker-compose -f seafile/docker-compose.yaml up -d

2.setting the parameters on .env files.

2.1. set the environment parameters on files:

mariadb:env/db.env
seafile:env/seafile.env

2.2. deploy infrastructure

docker-compose -f seafile/docker-compose.sec.yaml up -d

Setting Up the service

After the deploy, you must access System Admin > Settings

Set the Service URL: http://your.domain.com:8000
Set the File Server Root: http://your.domain.com/seafhttp

References

SeaFile Project - www.seafile.com
Cedon's SeaFile Example Repository - gitlab.com/cedon/seafile

Autoscaling Group With AWS Elastic Load Balancing

Carlos Nogueira — Fri, 18 Oct 2019 00:09:56 +0000

If you want to deploy an Autoscaling EC2 infrastructure on AWS using ELB, you'll need to follow this steps:

Launch EC2 Instance
- EC2 Dashboard > Launch Instance
- Configure your web app
Transform into AMI
- Select Instance > Action > Image > Create Image
- Instance > Delete EC2 Instantes
- Delete Security Group created with the Instance
Deploy AMI across different zones
- Load Balancer > Create Load Balancer > Application Load Balancer
- Select Zones
Configure Secure Groups
- Create New Secure Group
Configure Target Groups
- Define a Target Group name
Launch Configurations
- Choose the AMI created early
- Define Launch Configuration name
- Allow traffic just to the Load Balancer Security Group
Configure the Autoscaling Group
- Autoscaling Group > Create Autoscaling Group
- Define Name
- Group Size
- Choose the subnets
- Choose Target Groups
- Health Check Type: ELB
Define the Scaling Policies
- Create Increase and Decrease Alarms
- Set Notifications

The Autoscaling Group will launch the AMI instances based on the Increase/Decrease alarms and the minimal requirements.

References

Elastic Load Balancing - https://aws.amazon.com/elasticloadbalancing/
Elastic Compute Cloud - https://aws.amazon.com/ec2/

How to Deploy YAMLs with Deprecated Parameters on Kubernetes 1.16.0

Carlos Nogueira — Thu, 17 Oct 2019 00:43:21 +0000

The Kubernetes version 1.16.0 stopped to serve the following deprecated APIs:

NetworkPolicy (in the extensions/v1beta1 API group):
Migrate to use the networking.k8s.io/v1 API, available since v1.8. Existing persisted data can be retrieved/updated via the networking.k8s.io/v1 API.
PodSecurityPolicy (in the extensions/v1beta1 API group):
Migrate to use the policy/v1beta1 API, available since v1.10. Existing persisted data can be retrieved/updated via the policy/v1beta1 API.
DaemonSet, Deployment, StatefulSet, and ReplicaSet (in the extensions/v1beta1 and apps/v1beta2 API groups)

You must check your older YAMLs. But changing the listed parameters in all files can be an exhausting task.

An option would be to convert the older files.

For example, lets deploy a NGINX using the file nginx.yaml.

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  labels:
   run: nginx
  name: deploy-nginx
spec:
  selector:
     matchLabels:
      run: nginx
  template:
     metadata:
      labels:
        run: nginx
    spec:
      containers:
      - image: nginx
        name: nginx

The files nginx.yaml sets apiVersion: extensions/v1beta1 and it's compatible with kubernetes older versions, but not run on The last.
To convert the older YAML, using client 1.16 execute kubectl with the option convert:

kubectl convert -f nginx.yaml

Command screen output would be like:

apiVersion: apps/v1
kind: Deployment
metadata:
  creationTimestamp: null
  labels:
    run: nginx
  name: deploy-nginx
spec:
  progressDeadlineSeconds: 2213489811
  revisionHistoryLimit: 2213489811
  selector:
    matchLabels:
      run: nginx
  strategy:
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 1
    type: RollingUpdate
  template:
    metadata:
      creationTimestamp: null
      labels:
        run: nginx
    spec:
      containers:
      - image: nginx
        imagePullPolicy: Always
        name: nginx
        resources: {}
        terminationMessagePath: /dev/termination-log
        terminationMessagePolicy: File
      dnsPolicy: ClusterFirst
      restartiPolicy: Always
      schedulerName: defaul-scheduler
      securityContext: {}
      terminationGracePeriodSeconds: 28
status: {}

Paste the command output to a file(ex: nginxOUT.yaml)

kubectl convert -f nginx.yaml > nginxOUT.yaml

Deploy

Using output file

kubectl create -f nginxOUT.yaml

Directly with the older file

kubectl convert -f nginx.yaml | kubectl create -f -

References

https://kubernetes.io/blog/2019/07/18/api-deprecations-in-1-16/

Forem: Carlos Nogueira

[PT-BR] Kubectl: boas práticas

[PT-BR] Ciclo de Vida de Desenvolvimento de Software com assistência de IA

Fluxo SDLC

SDLC com assistência de IA

O Caminho da Maturidade

Como a IA Pode Influenciar Cada Etapa do SDLC

A Evolução das Equipes

Os Novos Desafios e Gargalos

Frameworks e Ferramentas Prontas

Síntese e Próximos Passos

Referências

[PT-BR] Pois é! Um post sobre o hype.

Crossplane: GKE Installation

Installation

Requirements

Deploy

References

Linkerd: Service Mesh Overview

Previous Post

References

Linkerd: Install and Basic Ops

References

Converting Helm Charts to K8S SDK Templates

Deploy BigchainDB using Docker Compose

Requirements

Clone Repo

Install

Check Containers

Testing db

Execute Test Script

References

Deploying A Private Storage Cloud (SeaFile) Using Docker

Compose

Let's Encrypt

MariaDB Connection and SeaFile Authentication

Deploy SeaFile

Requirements

Deploy:

Setting Up the service

References

Autoscaling Group With AWS Elastic Load Balancing

References

How to Deploy YAMLs with Deprecated Parameters on Kubernetes 1.16.0

Deploy

Using output file

Directly with the older file

References