DEV Community: Carlos Nogueira

[EN] Best Practices for Managing Secrets in Kubernetes

Carlos Nogueira — Sat, 25 Apr 2026 12:09:29 +0000

Managing secrets in Kubernetes requires careful attention. The default implementation has significant security limitations. Encoding secrets in base64 offers no real protection, it’s a strategy that exposes sensitive data to serious risks.

Essential Practices for Cluster Administrators

1. Encrypt Secrets at Rest

It is critical to encrypt secret data stored in etcd, Kubernetes’ internal database.

· Immediate action: Configure an encryption provider on the Kubernetes API server. You can do this using an encryption configuration file. For managed clusters (EKS, AKS, GKE), simply enable the managed encryption option.
· Advanced approach (KMS): For stronger security and control, use a Key Management Service provider (AWS KMS, Google Cloud KMS, Azure Key Vault). This enables envelope encryption, where keys are managed externally, reducing the risk of direct etcd access.

2. Control Access with Least Privilege (RBAC)

RBAC is the primary tool for controlling who or what can access secrets.

· Avoid unnecessary privileges: Never grant list, watch, or get permissions on secrets to users or service accounts that don’t explicitly need them. Remember that list permission can be used to view secret content.
· Use namespaces for isolation: Isolate secrets by namespace and use RoleBindings instead of ClusterRoleBindings to restrict access scope.

3. Protect etcd and Cluster Components

Beyond encryption, other measures help secure etcd, the cluster’s core datastore.

· Secure communication: Configure TLS between etcd nodes to protect data in transit.
· Sanitize storage: When decommissioning etcd persistent storage, use secure wiping methods (wipe or shred) to prevent data recovery.

4. Monitor and Audit Access

Auditing can help to detecting unauthorized access.

· Configure audit logs in Kubernetes to generate alerts for suspicious events: example, a single user reading many secrets in a short time.
· Integrate with a SIEM (Security Information and Event Management) tool for deeper analysis.

Essential Practices for Developers

1. Never Hardcode or Share Manifests with Secrets

Avoid storing literal values in code or sharing YAML manifests with plain‑text secrets, even in private repositories. The risk of exposure is too high.

2. Adopt Advanced Secret Management Tools

Instead of relying solely on native Secret resources, use tools that raise the security bar:

· External Secrets Operator (ESO): Synchronizes secrets from an external vault to Kubernetes. The cluster becomes a consumer, not the primary source of sensitive data.
· Secrets Store CSI Driver: Mounts secrets as a volume directly into a pod, avoiding storage in etcd or the Kubernetes API. The application reads the secret from the filesystem.
· OpenBao: A HashiCorp Vault FLOSS fork maintained by Linux Foundation that is a complete solution for high‑compliance environments, managing the full lifecycle of secrets with advanced access and auditing features.

3. Adopt Secure GitOps
If you store manifests in Git (standard GitOps practice), never commit secrets in plain text. Use encryption tools:

· Sealed Secrets : Encrypts the secret inside the Git repository. Only the controller in the cluster can decrypt it.
· Mozilla SOPS (Secrets OPerationS): Encrypts secret files, which can be versioned in Git, using keys from services such as AWS KMS, GCP KMS, Azure Key Vault, or PGP.

4. Automate Secret Rotation

· Automate with cloud provider : Use automated rotation from your cloud secrets manager (AWS Secrets Manager) combined with ESO. When a secret changes, ESO updates it in the cluster, and the pod can be configured to refresh the environment variable without restarting.
· Handle application restarts : For changes that require pod restarts, use tools like rolloutRestartTargets (from the Vault Secrets Operator) to orchestrate the process automatically.

Myths vs. Reality

It is important to distinguish between encoding and encryption.

Myth - What Kubernetes does not do by default

"A Secret in Kubernetes is encrypted by default."

Reality: No. A Secret is simply a base64‑encoded string, which offers zero security. Anyone with access to the cluster can decode it.
"If my RBAC is configured, my data is safe."

Reality: RBAC alone is not enough. Direct access to etcd (or its backups) or to the Kubernetes API (kubectl get secret) exposes all data in plain text, regardless of RBAC.

Summary and Recommendations

Build a robust secret management strategy by starting with the fundamentals and increasing complexity as needed.

Step 1 - Foundation (for everyone)

· Enable encryption at rest for etcd on your managed cluster.
· Implement RBAC with least privilege.
· Educate your team to never store secrets as plain text in Git.

Step 2 - Evolution (for most teams)

· Adopt an external secret manager. Start with the External Secrets Operator (ESO), which is simpler and offers an excellent balance between security and usability.

Step 3 - Advanced (for high compliance)

· If you operate under strict compliance regimes (SOC2, HIPAA) or in multi‑cloud environments, invest in OpenBao.
· For teams deeply invested in GitOps, use Sealed Secrets or SOPS to encrypt manifests before versioning.

References

[PT-BR] Guia de Módulo OpenTofu AWS EC2: Requisitos, Testes e Estratégia BDD

Carlos Nogueira — Fri, 24 Apr 2026 15:04:52 +0000

Introdução

A criação de módulos reutilizáveis para provisionamento de instâncias EC2 na AWS é uma prática essencial para equipes que buscam infraestrutura como código (IaC) consistente, segura e escalável. Um módulo bem‑escrito vai além da definição de recursos, exige planejamento de requisitos, suíte de testes automatizados e abordagem orientada ao comportamento (BDD) para garantir que atenda às necessidades de negócio e operacionais. Este guia substitui o uso do Terraform pelo OpenTofu, uma ferramenta que surgiu como um fork da última versão de código aberto do Terraform (1.5.7) e é mantida sob governança neutra da Linux Foundation, oferecendo alternativa totalmente open‑source sob a licença MPL.

Todo o conteúdo apresentado a seguir é totalmente compatível com o OpenTofu: o provedor AWS utilizado é exatamente o mesmo, a sintaxe HCL é idêntica, e o fluxo de trabalho permanece praticamente inalterado. Portanto, você pode aplicar este guia diretamente em seus projetos com OpenTofu sem qualquer modificação adicional.

1. Requisitos para Gerar um Módulo OpenTofu de EC2

1.1 Pré‑requisitos de Infraestrutura e CLI

· OpenTofu CLI instalado (versão 1.6.0 ou superior).
· AWS CLI configurada com credenciais que tenham permissões para criar EC2, VPC, sub‑redes e grupos de segurança.
· Um par de chaves SSH (key pair) existente na AWS, utilizado para acesso à instância.
· Uma VPC e pelo menos uma sub‑rede (subnet) onde a instância será lançada. O ID da sub‑rede é um parâmetro obrigatório para o módulo.

1.2 Estrutura Essencial do Módulo

Um módulo deve seguir uma estrutura padrão, composta por três arquivos principais dentro de um diretório (ex.: modules/ec2/):

· main.tofu: contém o recurso aws_instance e demais recursos associados.
· variables.tofu: declara todas as variáveis de entrada.
· outputs.tofu: expõe informações úteis como ID da instância e IP público.

Alternativamente, você pode manter a extensão .tf – o OpenTofu lê ambos os formatos perfeitamente.

1.3 Componentes Obrigatórios no main.tofu

resource "aws_instance" "this" {
  ami                    = var.ami_id
  instance_type          = var.instance_type
  subnet_id              = var.subnet_id
  vpc_security_group_ids = var.security_group_ids
  key_name               = var.key_name
  tags                   = var.tags
}

Argumentos adicionais, como user_data, root_block_device e ebs_block_device, podem ser incluídos conforme a necessidade.

1.4 Boas Práticas de Segurança e Organização

· Não inserir credenciais diretamente no módulo; utilizar variáveis de ambiente ou backend remoto.
· Validar variáveis com blocos validation (ex.: restringir instance_type a uma lista permitida).
· Documentar todas as variáveis e outputs no arquivo README.md.
· Utilizar namespaces consistentes nas tags (ex.: Environment, Application).

2. Plano de Testes para o Módulo EC2

Um módulo só é confiável se for testado adequadamente. O plano a seguir cobre desde verificações estáticas até testes de integração e testes nativos do OpenTofu.

2.1 Tipos de Teste e Ferramentas

Tipo de Teste | Objetivo | Ferramentas
Análise estática | Validar sintaxe, formatação e boas práticas | tofu fmt, tofu validate, tflint (com wrapper)

Análise de segurança | Identificar configurações inseguras (portas abertas, falta de criptografia) | checkov, tfsec, tofu_checkov

Teste de unidade (mock) | Executar o módulo em ambiente simulado | tofu test com simulação de provedores

Teste de integração nativo | Provisionar recursos reais e realizar asserções diretamente em HCL | tofu test (comandos nativos)

Teste de integração avançado | Testes mais complexos com orquestração em Go | Terratest (compatível com OpenTofu)

Teste de regressão | Verificar se mudanças não quebram versões anteriores | tofu test + versionamento do módulo

2.2 Fase 1: Testes Estáticos

Execute os comandos na raiz do módulo:

tofu fmt -recursive -check
tofu init -backend=false
tofu validate
tflint --init && tflint
checkov -d .

Critério de sucesso: nenhum erro ou warning crítico. O tflint pode ser utilizado com o wrapper para OpenTofu, e ferramentas como tofu_checkov estão disponíveis para substituir o checkov legado.

2.3 Fase 2: Testes de Segurança (checkov/tfsec)

Verificações obrigatórias:

· A instância não deve estar em sub‑rede pública sem restrições.
· O grupo de segurança não deve permitir 0.0.0.0/0 para SSH (porta 22) em produção.
· Volumes EBS devem ter encrypted = true.
· O módulo não deve expor variáveis sensíveis nos outputs.

O OpenTofu é suportado nativamente por essas ferramentas de análise estática.

2.4 Fase 3: Testes Nativos com tofu test

A partir da versão 1.6, o OpenTofu inclui o comando tofu test, que permite escrever testes de integração diretamente em HCL. O comando cria infraestrutura real (em uma conta AWS de teste), executa asserções e, ao final, destrói os recursos criados automaticamente.

Exemplo de arquivo de teste (tests/ec2.tofutest.hcl)

# tests/ec2.tofutest.hcl
run "basic_ec2_creation" {
  command = plan

  variables {
    instance_name = "test-instance"
    ami_id        = "ami-0c02fb55956c7d316"
    instance_type = "t3.micro"
    subnet_id     = "subnet-12345678"
    key_name      = "my-key"
    security_group_ids = ["sg-12345678"]
  }

  assert {
    condition     = aws_instance.this.instance_type == "t3.micro"
    error_message = "Instance type não corresponde ao esperado"
  }

  assert {
    condition     = aws_instance.this.tags["Name"] == "test-instance"
    error_message = "Tag Name não foi aplicada corretamente"
  }
}

Para executar:

cd modules/ec2
tofu init
tofu test -test-directory=tests

O OpenTofu executará o teste, criando recursos reais e destruindo‑os ao final. A partir da versão 1.8, o tofu test também suporta a simulação de provedores completos, o que facilita testes de unidade sem depender de recursos externos.

2.5 Fase 4: Testes de Integração Avançados com Terratest

Para cenários que exigem mais controle ou múltiplas etapas, o Terratest (framework em Go) pode ser utilizado. Como o OpenTofu é um substituto direto (“drop‑in replacement”) do Terraform, nenhuma alteração no código dos testes é necessária – basta garantir que o binário tofu esteja disponível no ambiente.

Exemplo simplificado:

package test

import (
    "testing"
    "github.com/gruntwork-io/terratest/modules/terraform"
    "github.com/gruntwork-io/terratest/modules/aws"
    "github.com/stretchr/testify/assert"
)

func TestEC2Module(t *testing.T) {
    t.Parallel()

    terraformOptions := &terraform.Options{
        TerraformDir: "../fixtures",
        Vars: map[string]interface{}{
            "instance_name": "integration-test",
            "ami_id":        "ami-0c02fb55956c7d316",
            "instance_type": "t3.micro",
            "subnet_id":     "subnet-12345678",
            "key_name":      "my-key",
            "security_group_ids": []string{"sg-12345678"},
        },
    }

    defer terraform.Destroy(t, terraformOptions)
    terraform.InitAndApply(t, terraformOptions)

    instanceID := terraform.Output(t, terraformOptions, "instance_id")
    instance := aws.GetEc2InstanceById(t, instanceID, "us-east-1")
    assert.Equal(t, "running", instance.State.Name)
}

Cenários a serem cobertos:

· Criação básica (valores mínimos).
· Com user_data para executar script de bootstrap.
· Com volume EBS adicional.
· Com tipo de instância inválido (deve falhar).
· Destruição limpa (verificar ausência de recursos órfãos).

2.6 Critérios de Aceitação do Plano de Testes

· tofu validate: sem erros.
· tofu fmt: 0 diferenças.
· tflint (com wrapper): sem warnings de nível ERROR.
· checkov/tofu_checkov: todos os checks de severidade HIGH aprovados.
· tofu test: todos os cenários de teste nativos aprovados.
· Teste de criação básica (via Terratest): sucesso.
· Teste de conectividade SSH: sucesso.
· Teste de destruição: nenhum recurso remanescente.

3. Estratégia BDD (Behavior-Driven Development) para o Módulo EC2

O BDD permite descrever o comportamento esperado em linguagem natural, garantindo que o módulo atenda aos requisitos de negócio e operacionais. A ferramenta terraform‑compliance (que é compatível com OpenTofu) permite escrever cenários em Gherkin e validá‑los contra o plano gerado.

3.1 Ferramentas Recomendadas

· terraform-compliance: executa cenários escritos em Gherkin contra o plano do OpenTofu.
· tofu test com blocos run e assert (pode ser usado para validar comportamentos específicos).

3.2 Estrutura de Diretórios para BDD

modules/ec2/tests/bdd/
├── features/
│   ├── creation.feature
│   ├── security.feature
│   ├── connectivity.feature
│   └── destruction.feature
└── steps/
    └── steps.py (opcional, para customizações)

3.3 Exemplos de Cenários Gherkin

Criação básica (creation.feature):

Feature: EC2 Instance Creation

  Scenario: Successfully create an EC2 instance with minimal required parameters
    Given I have a OpenTofu module "ec2" with configuration:
      """
      module "ec2" {
        source      = "../.."
        instance_name = "bdd-test-instance"
        ami_id        = "ami-0c02fb55956c7d316"
        instance_type = "t3.micro"
        subnet_id     = "subnet-12345678"
        key_name      = "my-key"
        security_group_ids = ["sg-12345678"]
      }
      """
    When I apply the OpenTofu configuration
    Then the EC2 instance should exist
    And its state should be "running"
    And it should have tag "Name" with value "bdd-test-instance"

Segurança (security.feature):

Feature: Security Configuration

  Scenario: SSH access should be limited to authorized IPs
    Given I have an EC2 instance created with security group "allow-ssh-from-office"
    When I inspect the security group rules
    Then inbound rule for port 22 should exist
    And the CIDR block should be "203.0.113.0/24"
    And no inbound rule should allow 0.0.0.0/0 for port 22

  Scenario: EBS volumes must be encrypted
    Given I have an EC2 instance with root block device
    Then the "encrypted" attribute of the root volume must be true

Conectividade (connectivity.feature):

Feature: Connectivity and User Data

  Scenario: Instance should be reachable via SSH
    Given I have a running EC2 instance with public IP address
    And I have the private key file "my-key.pem"
    When I try to SSH into the instance as user "ec2-user"
    Then the connection should succeed within 60 seconds

Destruição (destruction.feature):

Feature: Resource Cleanup

  Scenario: All resources are destroyed after deletion
    Given I have applied the EC2 module
    When I run `tofu destroy`
    Then the EC2 instance should no longer exist
    And any associated EBS volumes should be deleted
    And the OpenTofu state should be empty

3.4 Execução com terraform-compliance

Instalação:

pip install terraform-compliance

Execução:

cd modules/ec2/tests/bdd
tofu init
tofu plan -out plan.out
terraform-compliance -f ../features -p plan.out

Integração contínua (GitHub Actions):

- name: Run BDD scenarios
  env:
    AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
    AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
  run: |
    cd modules/ec2/tests/bdd
    tofu init
    tofu plan -out plan.out
    terraform-compliance -f ../features -p plan.out

3.5 Matriz de Cenários Obrigatórios

Feature | Cenário | Prioridade
Creation | Criar com valores mínimos | Must-have

Security | SSH restrito por IP | Must-have

Security | EBS criptografado | Must-have

Security | Sem portas administrativas para 0.0.0.0/0 | Must-have

Connectivity | SSH reachable | Should-have

Destruction | Destruição remove todos os recursos | Must-have

3.6 Critérios de Aceitação BDD

· 100% dos cenários classificados como “Must‑have” devem ser aprovados.
· Nenhum cenário pode falhar devido a dependências externas (sub‑redes inexistentes, etc.). Utilize variáveis consistentes ou mocks (via tofu test).
· Os arquivos .feature devem ser revisados pelas equipes de operações e segurança.

Conclusão

Desenvolver um módulo OpenTofu para EC2 vai muito além de escrever um recurso aws_instance. É necessário planejar requisitos, estruturar código de forma reutilizável/segura, implementar bateria de testes (estáticos, de segurança, integração nativa com tofu test, e destrutivos) e adotar estratégia BDD para alinhar o comportamento do módulo às expectativas de negócio.

A transição para o OpenTofu não exige mudanças no código que é um substituto direto do Terraform, com a vantagem adicional de ser totalmente open‑source e governado pela comunidade, eliminando questões de licenciamento e garantindo a perenidade do seu investimento em IaC.

Ao seguir este guia, você terá um módulo robusto, testável e production ready, além de facilitar a colaboração entre equipes de desenvolvimento, operações e segurança.

Referências

[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/

DEV Community: Carlos Nogueira

[EN] Best Practices for Managing Secrets in Kubernetes

Essential Practices for Cluster Administrators

Essential Practices for Developers

Myths vs. Reality

Summary and Recommendations

References

[PT-BR] Guia de Módulo OpenTofu AWS EC2: Requisitos, Testes e Estratégia BDD

Introdução

1. Requisitos para Gerar um Módulo OpenTofu de EC2

2. Plano de Testes para o Módulo EC2

3. Estratégia BDD (Behavior-Driven Development) para o Módulo EC2

Conclusão

[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