DEV Community: Natália Granato

Build de Imagens no Kubernetes com Gitlab Runner e Kaniko

Natália Granato — Fri, 19 Jul 2024 19:19:30 +0000

O que é o Gitlab Runner?

O Gitlab Runner é uma aplicação de código aberto que executa os jobs definidos em seus pipelines do Gitlab CI/CD. Ele pode ser instalado em diferentes plataformas, incluindo máquinas virtuais, servidores bare-metal e Kubernetes.

Registro do Runner em seus projetos

Após o deploy do Gitlab Runner no Kubernetes, você precisa registrar o runner em seus projetos para que ele possa executar os jobs.

Acesse a seção Settings > CI/CD do seu projeto no Gitlab.
Expanda a seção Runners.
Clique em Register a runner.
Copie o token de registro exibido.

Execute o seguinte comando no seu cluster Kubernetes, substituindo YOUR_REGISTRATION_TOKEN pelo token copiado:

kubectl exec -it gitlab-runner-gitlab-runner-XXXXX-XXXXX -- gitlab-runner register \
  --non-interactive \
  --url https://gitlab.example.com/ \
  --registration-token YOUR_REGISTRATION_TOKEN \
  --executor kubernetes

Deploy do Gitlab Runner no Kubernetes usando Helm

Para instalar o Gitlab Runner no Kubernetes usando Helm, siga estes passos:

Adicione o repositório do Helm:

helm repo add gitlab https://charts.gitlab.io/

Atualize os repositórios:
```
helm repo update
```
Instale o Gitlab Runner:
```
helm install gitlab-runner gitlab/gitlab-runner \
  --set gitlabUrl=https://gitlab.example.com/ \
  --set runnerRegistrationToken=YOUR_REGISTRATION_TOKEN
```
Substitua https://gitlab.example.com/ pela URL do seu Gitlab.

Substitua YOUR_REGISTRATION_TOKEN pelo token de registro do runner, obtido na seção de CI/CD do seu projeto no Gitlab.

Pontos de atenção no values.yaml

  rules:
    - resources:
        - configmaps
        - pods
        - pods/attach
        - secrets
        - services
      verbs:
        - get
        - list
        - watch
        - create
        - patch
        - update
        - delete
    - apiGroups:
        - ''
      resources:
        - pods/exec
      verbs:
        - create
        - patch
        - delete
### 
runners:
  cache: {}
  config: |
    [[runners]]
      [runners.kubernetes]
        image = "ubuntu:20.04"
        wait_for_services_timeout = "-1"
        privileged = true
        allow_privilege_escalation = true
        image_pull_secrets = ["aws-ecr"]

  configPath: ''
  name: globalweb-gitlab-runner
  privileged: true
  runUntagged: true
  tags: docker, share_cache, share_cache1, amd64
secrets: []
securityContext:
  allowPrivilegeEscalation: false
  capabilities:
    drop:
      - ALL
  privileged: false
  readOnlyRootFilesystem: false
  runAsNonRoot: true
service:
  enabled: false
  type: ClusterIP
serviceAccount:
  annotations: {}
  imagePullSecrets: null
  name: null
sessionServer:
  enabled: false
shutdown_timeout: 0
strategy: {}
terminationGracePeriodSeconds: 3600
tolerations: null
topologySpreadConstraints: {}
useTini: false
volumeMounts: null
volumes: null
gitlabUrl: https://gitlab.com/
global:
  cattle:
    systemProjectId: p-mpfgv
runnerRegistrationToken: glrt-1234567891011121415

Explicação do Arquivo de Configuração

Regras (`rules`)

Esta seção define permissões para acessar recursos do Kubernetes.

resources: Lista de recursos do Kubernetes que o runner pode acessar. Isso inclui configmaps, pods, pods/attach, secrets, e services.
verbs: Ações que podem ser realizadas nos recursos listados acima, como get, list, watch, create, patch, update, e delete.
apiGroups: Grupos de API do Kubernetes. Neste caso, está vazio (''), indicando o grupo principal.
resources: Lista de recursos específicos do grupo de API acima. Aqui, pods/exec.
verbs: Ações que podem ser realizadas no recurso pods/exec, como create, patch, e delete.

Runners (`runners`)

Esta seção define a configuração dos runners.

cache: Configuração de cache, atualmente vazio ({}).
config: Configuração dos runners em formato TOML.
- runners.kubernetes: Configuração específica para runners Kubernetes.
- image: Imagem de container a ser utilizada (ubuntu:20.04).
- wait_for_services_timeout: Tempo de espera para serviços (-1, indicando infinito).
- privileged: Permissão privilegiada para o container (true).
- allow_privilege_escalation: Permissão para escalonar privilégios (true).
- image_pull_secrets: Segredos utilizados para puxar imagens do container (aws-ecr).
configPath: Caminho de configuração, atualmente vazio ('').
name: Nome do runner (globalweb-gitlab-runner).
privileged: Indicação de execução privilegiada (true).
runUntagged: Indicação se deve executar tarefas não etiquetadas (true).
tags: Tags associadas ao runner (docker, share_cache, share_cache1, amd64).

Secrets (`secrets`)

Lista de segredos, atualmente vazia ([]).

SecurityContext (`securityContext`)

Configurações de segurança para os containers.

allowPrivilegeEscalation: Permissão para escalonar privilégios (false).
capabilities: Capacidades do container.
- drop: Capacidades a serem removidas (ALL).
privileged: Indicação se o container é privilegiado (false).
readOnlyRootFilesystem: Indicação se o sistema de arquivos raiz é somente leitura (false).
runAsNonRoot: Indicação se o container deve ser executado como um usuário não root (true).

Service (`service`)

Configurações do serviço.

enabled: Indicação se o serviço está habilitado (false).
type: Tipo de serviço (ClusterIP).

ServiceAccount (`serviceAccount`)

Configurações da conta de serviço.

annotations: Anotações, atualmente vazias ({}).
imagePullSecrets: Segredos para puxar imagens, atualmente null.
name: Nome da conta de serviço, atualmente null.

SessionServer (`sessionServer`)

Configurações do servidor de sessão.

enabled: Indicação se o servidor de sessão está habilitado (false).

Shutdown Timeout (`shutdown_timeout`)

Tempo de espera para o desligamento (0).

Strategy (`strategy`)

Estratégia de implantação, atualmente vazia ({}).

Termination Grace Period Seconds (`terminationGracePeriodSeconds`)

Período de tempo de espera antes de forçar a terminação (3600 segundos).

Tolerations (`tolerations`)

Tolerâncias para nós, atualmente null.

Topology Spread Constraints (`topologySpreadConstraints`)

Restrições de dispersão topológica, atualmente vazias ({}).

UseTini (`useTini`)

Indicação se deve usar tini como init, atualmente false.

VolumeMounts (`volumeMounts`)

Montagens de volume, atualmente null.

Volumes (`volumes`)

Volumes, atualmente null.

GitLab URL (`gitlabUrl`)

URL do GitLab (https://gitlab.com/).

Runner Registration Token (`runnerRegistrationToken`)

Token de registro do runner (glrt-1234567891011121415).

Essas configurações combinadas permitem que um GitLab Runner seja executado em um cluster Kubernetes com permissões e configurações específicas para realizar tarefas de CI/CD.

Utilizando o novo runner em pipelines do Gitlab CI

Para utilizar o novo runner em seus pipelines do Gitlab CI, adicione a tag kubernetes ao job que você deseja executar no Kubernetes. Por exemplo:

build_image:
  stage: build
  image: alpine:latest
  tags:
    - kubernetes
  script:
    - echo "Building image..."

Kubernetes não utiliza Docker como container runtime e agora? O Kaniko pode resolver esse problema

O Kubernetes não utiliza o Docker como container runtime por padrão. Isso pode ser um problema para pipelines de CI/CD que dependem do Docker para construir imagens. O Kaniko é uma ferramenta que permite construir imagens de container sem precisar do Docker.

O que é o Kaniko e como ele funciona?

O Kaniko é uma ferramenta de código aberto que constrói imagens de container a partir de um Dockerfile dentro de um container ou cluster Kubernetes. Ele funciona extraindo o filesystem do container base, executando os comandos do Dockerfile e empacotando o resultado em uma imagem de container.

Configurando variáveis de ambiente no Gitlab CI

Para que o Kaniko funcione corretamente, você precisa configurar algumas variáveis de ambiente no Gitlab CI. Essas variáveis incluem credenciais para acessar seu registro de container e informações sobre o projeto.

Passos para configurar variáveis de ambiente para a sua pipeline

Acesse a seção Settings > CI/CD do seu projeto no Gitlab.
Expanda a seção Variables.
Adicione as seguintes variáveis, sem a flag de proteção:
- AWS_REGION: Define a região da Amazon Web Services (AWS) onde os recursos serão criados e gerenciados.
- AWS_ACCESS_KEY_ID: É a chave de acesso pública da AWS que, junto com o AWS_SECRET_ACCESS_KEY, é usada para autenticar e autorizar chamadas para os serviços da AWS.
- AWS_SECRET_ACCESS_KEY: É a chave de acesso secreta da AWS, usada em conjunto com o AWS_ACCESS_KEY_ID para autenticar e autorizar chamadas para os serviços da AWS.
- REGISTRY: Refere-se ao registro de contêineres onde as imagens Docker são armazenadas e gerenciadas.

Exemplo `.gitlab-ci.yml` de build e push de imagens de containers com o Kaniko

O exemplo a seguir demonstra como usar o Kaniko em um pipeline do Gitlab CI para construir e enviar uma imagem de container para um registro:

build:
  stage: build
  image:
    name: gcr.io/kaniko-project/executor:debug
    entrypoint: [""]
  script:
    - mkdir -p /kaniko/.docker
    - echo "{\"credsStore\":\"ecr-login\",\"credHelpers\":{\"$REGISTRY/portal-colaborador-hml\":\"ecr-login\"}}" > /kaniko/.docker/config.json
    - >-
      /kaniko/executor
      --context "${CI_PROJECT_DIR}" 
      --dockerfile "${CI_PROJECT_DIR}/Dockerfile" 
      --build-arg AWS_REGION=$AWS_REGION 
      --build-arg AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID 
      --build-arg AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY 
      --destination "${REGISTRY}/portal-colaborador-hml:${CI_COMMIT_SHORT_SHA:0:5}"

  tags:
    - docker, share_cache, share_cache1, amd64
  only:
    - main
    - develop

Essa configuração permite que o GitLab CI/CD construa e empurre uma imagem Docker usando Kaniko, autenticando-se no registro de contêineres utilizando credenciais da AWS, e apenas executando este processo nas branches main e develop.

Conclusão

Utilizar o Gitlab Runner em conjunto com o Kaniko no Kubernetes permite construir e enviar imagens de container de forma eficiente e segura, sem depender do Docker como runtime. Esta configuração aproveita o poder do Kubernetes para escalar e gerenciar suas builds de CI/CD, garantindo maior flexibilidade e desempenho em seus pipelines.

A Importância dos testes de carga no Kubernetes: Garantindo a resiliência e escalabilidade

Natália Granato — Fri, 19 Jul 2024 19:16:42 +0000

Em um ecossistema digital cada vez mais dinâmico e complexo, a capacidade de garantir que as aplicações permaneçam funcionais e responsivas mesmo sob pesadas cargas de trabalho é crucial. É aqui que os testes de carga entram em cena, desempenhando um papel fundamental na garantia de que as aplicações hospedadas no Kubernetes possam enfrentar desafios de escalabilidade e resiliência.

O Kubernetes, com sua capacidade de orquestrar e gerenciar contêineres em escala, oferece um ambiente altamente flexível para implantar e executar aplicações distribuídas. No entanto, a escalabilidade dinâmica proporcionada pelo Kubernetes também pode apresentar desafios únicos. À medida que o tráfego aumenta, é crucial garantir que os recursos alocados possam lidar com a demanda adicional sem comprometer a qualidade do serviço.

A finalidade dos testes de carga no Kubernetes é simular condições de uso intensivo, submetendo as aplicações e infraestrutura a cargas de trabalho cada vez maiores, a fim de avaliar seu desempenho e identificar possíveis gargalos. Esses testes não apenas ajudam a determinar os limites de escalabilidade de uma aplicação, mas também fornecem insights valiosos sobre o comportamento do sistema sob diferentes condições de carga.

Planejamento Adequado:

Planeje requisitos de hardware, distribuição e topologia da infraestrutura.
Facilite o dimensionamento e a manutenção do cluster.

Configuração de Rede:

Escolha uma solução de rede adequada.
Utilize segmentação de rede para segurança.

Gerenciamento de Recursos:

Defina limites e solicitações de recursos para os pods.
Monitore o uso de recursos e implemente escalonamento automático.

Backup e Recuperação:

Garanta a integridade dos dados armazenados nos volumes persistentes.
Use ferramentas de backup confiáveis.

Testes de Carga Realistas:

Simule cenários reais com ferramentas como k6 ou loadtest.
Identifique problemas de desempenho.

Monitoramento Contínuo:

Monitore o desempenho e o uso de recursos.
Faça ajustes conforme necessário.

Automação de Escalonamento:

Use recursos nativos de escalonamento automático do Kubernetes.

Ferramentas Recomendadas:

k6: Ferramenta de teste de carga baseada em JavaScript.
Locust: Ferramenta rica em recursos para testes de carga complexos.
Kubecarga: O teste cria deployments de forma contínua em intervalos regulares para simular carga no cluster.

Em resumo, o Kubernetes e suas ferramentas oferecem um ecossistema robusto para testes de carga, garantindo que seus aplicativos sejam resilientes e dimensionados adequadamente.

Um exemplo prático com Kubecarga

Este é um exemplo de teste de carga em Go para clusters Kubernetes. O teste cria deployments de forma contínua em intervalos regulares para simular carga no cluster.

Pré-requisitos

Go instalado na máquina local
Acesso a um cluster Kubernetes (local ou remoto)
Configuração do Kubernetes (kubectl) ou arquivo kubeconfig para autenticação e autorização

O que o código faz

O código cria deployments no cluster Kubernetes em intervalos regulares. No exemplo fornecido, ele cria deployments usando a imagem nginx, mas pode ser adaptado para outras imagens e tipos de recursos do Kubernetes.

Pontos de atenção

Caso não seja setado no momento da execução o caminho do KUBECONFIG ele herdará das variáveis de ambiente.
O teste é para criação de deployments, caso deseje mudar o Namespace, Name, Imagem e etc realize a alteração entre as linhas 67-89.

Clone este repositório

git clone https://github.com/Tech-Preta/kubecarga.git
cd kubecarga

Inicialize o módulo Go

Execute o seguinte comando para inicializar um novo módulo Go:

go mod init

Instalação das dependências

Para instalar as dependências necessárias, execute os seguintes comandos:

go get k8s.io/client-go/kubernetes
go get k8s.io/client-go/rest
go get k8s.io/client-go/tools/clientcmd

Esses comandos irão baixar e instalar os pacotes e suas dependências, e também atualizarão os arquivos go.mod e go.sum.

Construindo o projeto

Agora que temos todas as dependências instaladas, podemos criar o executável para isso utilize o comando abaixo:

go build -o kube-carga .

Isso irá compilar o código e criar o executável no diretório atual.

Como executar

Finalmente podemos executar a nossa aplicação com o comando abaixo:

sudo chmod +x kube-carga
./kube-carga -kubeconfig /caminho/para/seu/kubeconfig

Você também pode realizar um laboratório prático: Teste de carga distribuída usando o Kubernetes no Google Cloud Skills Boost

Kubernetes Vanilla em instâncias ec2

Natália Granato — Fri, 19 Jul 2024 18:29:06 +0000

Criando um Cluster Kubernetes em Instâncias EC2

Este guia detalha o processo de criação de um cluster Kubernetes em instâncias EC2 na AWS, com base nas configurações e comandos fornecidos.

Configurações das Instâncias EC2

Nome: k8s
Número de Instâncias: 5
Imagem da Máquina: Ubuntu Server 22.04 LTS (HVM), SSD Volume Type
Arquitetura: 64 bits (x86)
Tipo de Instância: t2.medium
Key Pair: key_par_k8s
Configuração de Armazenamento: Volume do tipo gp3

Configurações do Cluster Kubernetes

Para criar um cluster Kubernetes usando o kubeadm, é necessário liberar algumas portas no grupo de segurança das instâncias EC2. Essas portas são essenciais para o funcionamento correto do cluster. A seguir, estão as portas que precisam ser liberadas:

Porta 6443: Essa porta é usada pelo servidor de API do Kubernetes para comunicação com os componentes do cluster. É necessário permitir o tráfego TCP na porta 6443 para que os nós do cluster possam se comunicar com o servidor de API.
Portas 10250-10259: Essas portas são usadas pelo kubelet, kube-scheduler e kube-controller-manager para comunicação interna no cluster. É necessário permitir o tráfego TCP nessas portas para que os componentes do cluster possam se comunicar entre si.
Porta 30000-32767: Essas portas são usadas para serviços NodePort no Kubernetes. É necessário permitir o tráfego TCP nessas portas para que os serviços NodePort possam ser acessados externamente.
Portas 6783-6784: Essas portas são usadas pelo Weave Net para comunicação interna no cluster. É necessário permitir o tráfego UDP nessas portas para que o Weave Net possa funcionar corretamente.
Portas 2379-2380: Essas portas são usadas pelo etcd para comunicação interna no cluster. É necessário permitir o tráfego TCP nessas portas para que o etcd possa funcionar corretamente.

Além disso, é importante lembrar de liberar a porta 22 para permitir a conexão SSH com as instâncias EC2.

Certifique-se de configurar corretamente as regras de entrada no grupo de segurança das instâncias EC2 para permitir o tráfego nessas portas. As regras de saída podem ser mantidas com as configurações padrão da AWS.
TCP - Portas 10250-10259 - Security Group ID - Kubelet API, kube-scheduler e kube-controller-manager.

Regras de Saída:

Não irei específicar as regras de saída, portanto, usarão as configurações padrão da AWS.

Conectando-se às Instâncias

Para se conectar às instâncias EC2, é necessário usar a chave privada associada ao key pair usado durante a criação das instâncias. A seguir, está o comando para se conectar a uma instância EC2 usando a chave privada:

sudo chmod 400 sua_chave_privada.pem
ssh -i "sua_chave_privada.pem" ubuntu@ip_da_instância.compute-1.amazonaws.com

Substitua sua_chave_privada.pem pelo caminho da sua chave privada e ip_da_instância.compute-1.amazonaws.com pelo endereço IP público da instância EC2.

Altere o hostname da máquina:

sudo su -
hostnamectl set-hostname k8s-1

Configurando os Nós

Desativando a Memória Swap:

sudo swapoff -a

Este comando desativa a memória swap em seu sistema. No contexto do Kubernetes, a memória swap pode interferir no desempenho do sistema e causar problemas de estabilidade, portanto, é recomendado desativá-la.

Configurando os Módulos de Kernel:

sudo nano /etc/modules-load.d/k8s.conf

Este comando abre o editor de texto nano para editar o arquivo k8s.conf localizado no diretório /etc/modules-load.d/. Este arquivo é usado para especificar quais módulos do kernel devem ser carregados durante a inicialização do sistema.

Adicione as seguintes linhas ao arquivo:

br_netfilter
overlay

Esses módulos do kernel são necessários para o funcionamento adequado do Kubernetes. O br_netfilter é usado para configurar a ponte de rede do Docker, enquanto o overlay é usado para suportar a camada de sobreposição de contêineres.

Salve e feche o arquivo.

Carregando os Módulos de Kernel:

sudo modprobe br_netfilter
sudo modprobe overlay

Em seguida, execute:

cat <<EOF | sudo tee /etc/sysctl.d/k8s.conf
net.bridge.bridge-nf-call-iptables  = 1
net.bridge.bridge-nf-call-ip6tables = 1
net.ipv4.ip_forward                 = 1
EOF

sudo sysctl --system

Estes comandos são usados para configurar os parâmetros do sistema no Linux, especialmente para preparar o ambiente para a execução do Kubernetes.

cat <<EOF | sudo tee /etc/sysctl.d/k8s.conf: Este comando redireciona a entrada para um arquivo chamado k8s.conf localizado no diretório /etc/sysctl.d/. O conteúdo que vem após <<EOF é inserido neste arquivo. Neste caso, estamos definindo três parâmetros do sistema relacionados ao funcionamento do Kubernetes:
- net.bridge.bridge-nf-call-iptables = 1: Habilita a chamada do iptables para encaminhamento de pacotes entre interfaces de rede.
- net.bridge.bridge-nf-call-ip6tables = 1: Habilita a chamada do ip6tables para encaminhamento de pacotes IPv6 entre interfaces de rede.
- net.ipv4.ip_forward = 1: Habilita o encaminhamento de IP no sistema, permitindo que os pacotes sejam roteados entre diferentes interfaces de rede.

O EOF indica o fim do texto que será redirecionado para o arquivo.

sudo sysctl --system: Este comando é usado para recarregar as configurações do sistema sem precisar reiniciar. Isso faz com que o sistema leia e aplique as configurações definidas no arquivo k8s.conf e em outros arquivos de configuração no diretório /etc/sysctl.d/.

Instalando kubectl, kubeadm e kubelet:

sudo apt-get install -y apt-transport-https ca-certificates curl gnupg
curl -fsSL https://pkgs.k8s.io/core:/stable:/v1.30/deb/Release.key | sudo gpg --dearmor -o /etc/apt/trusted.gpg.d/kubernetes-archive-keyring.gpg
echo "deb [signed-by=/etc/apt/trusted.gpg.d/kubernetes-archive-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v1.30/deb/ /" | sudo tee /etc/apt/sources.list.d/kubernetes.list
sudo apt-get update
sudo apt-get install -y kubelet kubeadm kubectl
sudo apt-mark hold kubelet kubeadm kubectl

Instalando e configurando o Containerd:

sudo apt-get update
sudo apt-get install ca-certificates curl
sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL <https://download.docker.com/linux/ubuntu/gpg> -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc

echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu \
  $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | \
  sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
sudo apt-get update

sudo apt-get install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

sudo apt-get update: Atualiza a lista de pacotes disponíveis e suas versões, mas não instala ou atualiza nenhum pacote.
sudo apt-get install ca-certificates curl: Instala os pacotes ca-certificates e curl. ca-certificates é usado para verificar a confiabilidade dos servidores remotos, e curl é usado para baixar dados de ou para um servidor.
sudo install -m 0755 -d /etc/apt/keyrings: Cria o diretório /etc/apt/keyrings com permissões 0755.
sudo curl -fsSL <https://download.docker.com/linux/ubuntu/gpg> -o /etc/apt/keyrings/docker.asc: Baixa a chave GPG do repositório Docker e a salva no arquivo /etc/apt/keyrings/docker.asc.
sudo chmod a+r /etc/apt/keyrings/docker.asc: Altera as permissões do arquivo docker.asc para que todos os usuários possam lê-lo.
O comando echo cria uma nova entrada na lista de fontes do APT para o repositório Docker.
sudo apt-get update: Novamente, atualiza a lista de pacotes disponíveis e suas versões.
sudo apt-get install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin: Instala o Docker, o CLI do Docker, o Containerd, o plugin Docker Buildx e o plugin Docker Compose.
Configurando o Containerd:


sudo containerd config default | sudo tee /etc/containerd/config.toml


sudo sed -i 's/SystemdCgroup = false/SystemdCgroup = true/g' /etc/containerd/config.toml

sudo systemctl restart containerd
sudo systemctl status containerd

Habilitando o serviço do Kubelet:

sudo systemctl enable --now kubelet
systemctl status kubelet

Nota: A partir daqui, execute os comandos como root para evitar problemas de permissões, erros de certificado, etc.

Criando o cluster Kubernetes na versão v1.30

Inicializando o cluster:

sudo kubeadm init --pod-network-cidr=10.10.0.0/16 --apiserver-advertise-address=<ip-controlplane>

# Configurando o Acesso ao Kubernetes:
mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config

Adicionando nós workers ao cluster:

sudo kubeadm join <ip-controlplane:6443> --token <token> --discovery-token-ca-cert-hash  sha256:<hash>

Instalando o Wave Net para a rede do cluster:

kubectl apply -f https://github.com/weaveworks/weave/releases/download/v2.8.1/weave-daemonset-k8s.yaml

Verificando o status do cluster:

kubectl get nodes
kubectl get pods -A

Agora você tem um cluster Kubernetes funcional em execução em instâncias EC2 na AWS. Você pode implantar aplicativos, serviços e recursos no cluster e começar a explorar as capacidades do Kubernetes.

Parâmetros avançados no Docker Compose

Natália Granato — Fri, 19 Jul 2024 18:22:01 +0000

O que é o Docker Compose?

O Docker Compose é uma ferramenta exclusiva para a plataforma Docker, projetada especificamente para gerenciar containers. Ele não é compatível com outras plataformas de containers.

Para ilustrar as funcionalidades do Docker Compose, vamos analisar o seguinte exemplo de um arquivo docker-compose.yml:

version: '3.9'

services:
  giropops-senhas:
    build: .
    ports:
      - "5000:5000"
    networks:
      - giropops-senhas
    environment:
      - REDIS_HOST=redis
    volumes:
      - natalia:/granato
    deploy:
      replicas: 1
      resources:
        reservations:
          cpus: '0.25'
          memory: 128M
        limits:
          cpus: '0.50'
          memory: 256M

  redis:
    image: redis
    command: redis-server --appendonly yes
    networks:
      - giropops-senhas
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:5000"]
      interval: 30s
      timeout: 5s
      retries: 3
      start_period: 10s
networks:
  giropops-senhas:
    driver: bridge

volumes:
  natalia:

Neste exemplo, temos dois serviços definidos: giropops-senhas e redis. O serviço giropops-senhas é construído a partir do Dockerfile no diretório atual (indicado pelo ponto), expõe a porta 5000 e usa a rede giropops-senhas. Além disso, ele define uma variável de ambiente REDIS_HOST e utiliza um volume chamado natalia.

Já o serviço redis utiliza a imagem oficial do Redis do Docker Hub, executa o servidor Redis em modo append-only e também usa a rede giropops-senhas. Além disso, ele possui um healthcheck que verifica a saúde do serviço a cada 30 segundos.

A rede giropops-senhas é definida como uma rede do tipo bridge, e o volume natalia é criado sem qualquer configuração adicional.

Este exemplo demonstra a flexibilidade e o poder do Docker Compose na definição e gerenciamento de múltiplos containers e suas interações.

Alguns comandos para facilitar o seu dia a dia

O Docker Compose é uma ferramenta que permite definir e gerenciar aplicativos multi-container. Ele utiliza um arquivo de configuração chamado docker-compose.yml para especificar os serviços, redes e volumes necessários para a execução desses contêineres.

Aqui estão algumas das instruções que você mencionou e o que elas fazem:

docker compose up -d: Inicia os serviços definidos no arquivo docker-compose.yml em segundo plano (-d). Isso cria e inicia os contêineres conforme as configurações especificadas.
docker compose ps: Exibe o status dos serviços definidos no arquivo docker-compose.yml. Mostra quais contêineres estão em execução, parados ou com erro.
docker compose down: Encerra todos os serviços e contêineres definidos no arquivo docker-compose.yml. Isso também remove as redes e volumes associados.
docker compose pause: Pausa a execução dos serviços e contêineres definidos no arquivo docker-compose.yml. Isso pode ser útil para depurar ou realizar manutenção.
docker compose unpause: Retoma a execução dos serviços e contêineres pausados.
docker compose logs -f: Exibe os logs dos serviços em tempo real (-f). Isso é útil para depurar problemas ou monitorar a saída dos contêineres.

Docker compose build, replicas e resources

Funcionalidade `build`

A funcionalidade build é utilizada no arquivo docker-compose.yml para construir a imagem de um serviço a partir de um Dockerfile localizado no diretório atual. Isso permite personalizar a imagem do serviço antes de executá-lo.

Exemplo:

services:
  giropops-senhas:
    build: .

Neste exemplo, o serviço giropops-senhas está sendo construído a partir do Dockerfile localizado no diretório atual (.).

Funcionalidade replicas

A funcionalidade replicas define o número de réplicas de um serviço que serão criadas e executadas. Ela permite dimensionar horizontalmente os serviços, distribuindo a carga entre várias instâncias do mesmo serviço.

Exemplo:

```yaml

services:
giropops-senhas:
...
deploy:
replicas: 3




Neste exemplo, o serviço `giropops-senhas` terá três réplicas em execução.

### Funcionalidade resources

A funcionalidade resources permite definir limites e reservas de recursos para um serviço. Isso inclui especificações de CPU e memória para garantir que os recursos sejam alocados de forma eficiente e equitativa entre os serviços.

Exemplo:



      ```yaml
services:
  giropops-senhas:
    ...
    deploy:
      resources:
        reservations:
          cpus: '0.25'
          memory: 128M
        limits:
          cpus: '0.50'
          memory: 256M

Neste exemplo, o serviço giropops-senhas tem uma reserva de 0,25 CPUs e 128MB de memória por réplica, com um limite máximo de 0,50 CPUs e 256MB de memória por réplica.

Comandos úteis do Docker Compose

Essas funcionalidades fornecem flexibilidade e controle sobre a construção, replicação e alocação de recursos dos serviços definidos no arquivo docker-compose.yml.

docker compose -f docker-compose.yml up -d: Inicia os serviços definidos no arquivo docker-compose.yml em segundo plano (-d). Isso cria e inicia os contêineres conforme as configurações especificadas.
docker compose -f docker-compose.yml up -d --scale redis=3: Inicia os serviços definidos no arquivo docker-compose.yml em segundo plano (-d) e escala o serviço redis para 3 réplicas. Isso cria e inicia múltiplos contêineres do serviço redis.
docker compose -f docker-compose.yml build: Constrói as imagens dos serviços definidos no arquivo docker-compose.yml. Isso é útil quando você fez alterações nos Dockerfiles ou nas configurações dos serviços.

Esses comandos são úteis para gerenciar e monitorar os serviços definidos no arquivo docker-compose.yml de forma eficiente e eficaz.

Qual é a diferença entre Docker e Docker Compose?

Docker:

O Docker é uma plataforma de virtualização de contêineres que permite empacotar, distribuir e executar aplicativos em ambientes isolados chamados contêineres. Ele fornece uma maneira consistente de empacotar aplicativos, suas dependências e configurações em um único pacote. Cada contêiner é uma instância isolada de um aplicativo, com seu próprio sistema de arquivos, bibliotecas e recursos. O Docker usa imagens para criar contêineres. As imagens são como modelos que contêm todas as instruções para criar um contêiner. É amplamente utilizado para desenvolvimento, teste e implantação de aplicativos.

Docker Compose:

O Docker Compose é uma ferramenta que simplifica a orquestração de vários contêineres. Ele permite definir e gerenciar aplicativos multi-container usando um arquivo de configuração chamado docker-compose.yml. No arquivo docker-compose.yml, você pode especificar serviços, redes, volumes e outras configurações necessárias para seus contêineres. Com o Docker Compose, você pode iniciar, parar, escalar e gerenciar todos os contêineres de um aplicativo com um único comando. É útil para cenários em que você precisa executar vários contêineres juntos, como aplicativos que dependem de bancos de dados, cache, servidores web, etc.

Em resumo, o Docker é a base para criar e executar contêineres individuais, enquanto o Docker Compose é usado para definir e gerenciar aplicativos compostos por vários contêineres interconectados. Ambos são essenciais para o desenvolvimento e implantação eficiente de aplicativos baseados em contêineres. 🐳

Espero que essas informações sejam úteis para você! Se tiver mais dúvidas ou precisar de mais informações, não hesite em perguntar.

Certificado TLS no Kubernetes

Natália Granato — Fri, 19 Jul 2024 18:19:22 +0000

Utilize o openssl, projeto de código aberto dos protocolos ssl e tls para gerar o seu certificado autoassinado. Use openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout chave-privada.key -out certificado.crt.

Para criar um Secret do tipo TLS, você pode usar o comando kubectl create secret tls meu-servico-web-tls-secret --cert=certificado.crt --key=chave-privada.key seguido sempre pelo nome da Secret e a localização dos arquivos de certificado e chave.

Verificando os dados de uma Secret, você pode usar o comando kubectl get secret meu-servico-tls-secret -o yaml para visualizar os dados de uma Secret.

Aqui está um exemplo do arquivo de configuração do nginx para utilizar tls:

http {
    server {
        listen 80;
        listen 443 ssl;
        ssl_certificate /etc/nginx/tls/certificado.crt;
        ssl_certificate_key /etc/nginx/tls/chave-privada.key;

        location / {
            return 200 'Hello, World!';
            add_header Content-Type text/plain;
        }
    }
}

Criando um ConfigMap para adicionar um arquivo no Pod e configurar o SSL no Nginx

Para criar um ConfigMap para adicionar um arquivo no Pod e configurar o SSL no Nginx, você pode usar o comando kubectl create configmap nginx-config --from-file=nginx.conf seguido pelo nome do ConfigMap e o arquivo a ser incluído.

apiVersion: v1
kind: Pod
metadata:
  name: gita-pod
  labels:
    app: gita-pod
spec:
  containers:
  - name: gita-container
    image: nginx:1.26
    ports:
    - containerPort: 80
    - containerPort: 443
    volumeMounts:
    - name: meu-volume
      mountPath: /etc/nginx/nginx.conf
      subPath: nginx.conf
    - name: nginx-tls
      mountPath: /etc/nginx/tls
  volumes:
  - name: nginx-config-volume
    configMap:
      name: nginx-config
  - name: nginx-tls
    secret:
      secretName: meu-servico-tls-secret
      items:
      - key: certificado.crt
        path: certificado.crt
      - key: chave-privada.key
        path: chave-privada.key

Recapirulando, aprendemos o que são as Secrets do Kubernetes, os tipos de Secrets e o que é a codificação base64, como criar uma Secret do tipo Opaque, como utilizar o nosso Secret como variável de ambiente dentro do Pod, como criar uma Secret para autenticação no Docker Hub, como criar um Secret do tipo TLS e como criar um ConfigMap para adicionar um arquivo no Pod e configurar o SSL no Nginx.

Para realizar o passo a passo:

Crie o seu certificado TLS: openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout chave-privada.key -out certificado.crt.
Crie a secret do tipo TLS com o comando kubectl create secret tls meu-servico-tls-secret --cert=certificado.crt --key=chave-privada.key.
Crie o ConfigMap com o comando kubectl create configmap nginx-config --from-file=nginx.conf.
Crie o Pod com o comando kubectl apply -f nginx-pod.yml.
Crie um service para expor o Pod criado com o comando kubectl expose pod nginx. Liste o service com kubectl get svc.
Faça o port-forward do service para acessar o Nginx com o comando kubectl port-forward service/nginx 4443:443.

Para testar o Nginx, acesse o endereço https://localhost:4443 ou https://127.0.0.1:4443 e você verá a mensagem Bem-vindo ao Nginx!.

Você também pode utilizar o curl -k https://localhost:4443 e verá a seguinte mensagem:

Bem-vindo ao Nginx!

Iniciando com o Ansible

Natália Granato — Fri, 19 Jul 2024 17:57:14 +0000

Ansible: Uma Visão Geral

Automatização de Tarefas

O Ansible permite automatizar tarefas como configuração de sistemas, implantação de aplicativos e provisionamento de recursos de nuvem. Ele segue uma abordagem sem agentes, o que significa que não é necessário instalar um agente de software nos sistemas que você deseja gerenciar. Pode ser executado em qualquer sistema operacional que suporte Python.

Modelagem Declarativa

Em vez de escrever scripts para automatizar tarefas, os usuários definem o estado desejado dos sistemas usando uma linguagem de modelagem chamada YAML. O Ansible traduz essas definições em ações reais nos sistemas.

Playbooks

Os playbooks são arquivos YAML que descrevem as tarefas a serem executadas pelo Ansible. Eles definem o fluxo de trabalho e as configurações desejadas. Com os playbooks, você pode automatizar tarefas complexas e sequenciais.

Integração com Nuvem e Contêineres

O Ansible tem integrações nativas com várias plataformas de nuvem, incluindo AWS, Azure, Google Cloud Platform e OpenStack. Também pode ser usado para gerenciar contêineres, como Docker e Kubernetes.

Arquitetura

O Ansible usa um conjunto de módulos escritos principalmente em Python. Esses módulos são executados em um controlador remoto para gerenciar os sistemas. O Ansible não requer a instalação de um agente nos sistemas, pois se comunica diretamente com eles via SSH.

Um projeto prático

Instalação do Ansible Certifique-se de que o Ansible está instalado na sua máquina controladora. Caso não esteja, você pode instalá-lo via gerenciador de pacotes (por exemplo, apt, yum, brew, etc.). Se preferir utilize:

python3 -m pip install --user ansible

Criação de Chaves SSH Se você ainda não possui um par de chaves SSH, gere um usando o comando:

ssh-keygen -t rsa -b 4096 -f ~/.ssh/id_rsa

Isso criará as chaves pública (id_rsa.pub) e privada (id_rsa) no diretório ~/.ssh/.

Envio da Chave Pública para o Host de Destino:

Copie a chave pública para o host de destino (onde você deseja executar o Ansible). Você pode fazer isso manualmente ou usar o Ansible para automatizar o processo.
Manualmente:

ssh-copy-id -i ~/.ssh/id_rsa.pub user@host

Usando Ansible (em um playbook):

---
- hosts: seu_host
  tasks:
    - name: Copiar chave pública para o host
      authorized_key:
        user: seu_usuario
        key: "{{ lookup('file', '~/.ssh/id_rsa.pub') }}"

Configuração do Inventário
Crie um arquivo de inventário (por exemplo, hosts.ini) com os detalhes dos hosts que você deseja gerenciar com o Ansible.
Exemplo de arquivo hosts.ini:

[servidores]
servidor1 ansible_host=192.168.1.10
servidor2 ansible_host=192.168.1.20

Teste a Conexão SSH
Antes de tudo, verifique se o Ansible pode se conectar aos hosts. Execute o comando abaixo onde está localizado o seu arquivo de inventário:

ansible -i hosts.ini -m ping servidores

Caso tenha sucesso você verá algo como:

192.168.0.146 | SUCCESS => {
    "changed": false,
    "ping": "pong"
}

Crie Seus Playbooks:
Agora você pode criar seus playbooks Ansible para automatizar tarefas nos servidores.

Executando o Ansible Node Exporter

Faça o clone do repositório e modifique o inventário de acordo com os servidores que deseja gerenciar. Não se esqueça de seguir os passos anteriores para ter acesso aos servidores.

https://github.com/Tech-Preta/ansible-node-exporter.git

Para executar o playbook instalar_node_exporter.yml, você pode usar o comando ansible-playbook. Certifique-se de estar no diretório onde o playbook está localizado. Aqui está o comando que você pode usar:

ansible-playbook instalar_node_exporter.yml --ask-become-pass

Se o seu playbook estiver em um diretório específico, você precisará fornecer o caminho completo para o playbook:

ansible-playbook /caminho/para/o/playbook/instalar_node_exporter.yml

Em caso de sucesso, a saída será semelhante a:

PLAY [seus_servidores] *******************************************************************************************************

TASK [Gathering Facts] *******************************************************************************************************
ok: [192.168.0.146]

PLAY [Configurar tipos de chave de host permitidos] **************************************************************************

TASK [Adicionar tipos de chave de host ao cliente SSH] ***********************************************************************
ok: [192.168.0.146] => (item=HostKeyAlgorithms ssh-ed25519,ecdsa-sha2-nistp256,ssh-rsa,rsa-sha2-512,rsa-sha2-256)

PLAY [seus_servidores] *******************************************************************************************************

TASK [Gathering Facts] *******************************************************************************************************
ok: [192.168.0.146]

TASK [node_exporter : Baixar o Node Exporter] ********************************************************************************
changed: [192.168.0.146]

TASK [node_exporter : Criar diretório para o Node Exporter] ******************************************************************
ok: [192.168.0.146]

TASK [node_exporter : Extrair o Node Exporter] *******************************************************************************
changed: [192.168.0.146]

TASK [node_exporter : Mover o Node Exporter para /usr/local/bin] *************************************************************
changed: [192.168.0.146]

TASK [node_exporter : Criar usuário para o Node Exporter] ********************************************************************
ok: [192.168.0.146]

TASK [node_exporter : Copiar o serviço systemd do Node Exporter] *************************************************************
changed: [192.168.0.146]

TASK [node_exporter : Definir permissões nos arquivos temporários do Ansible] ************************************************
changed: [192.168.0.146 -> localhost]

TASK [node_exporter : Habilitar e iniciar o serviço do Node Exporter] ********************************************************
ok: [192.168.0.146]

PLAY RECAP *******************************************************************************************************************
192.168.0.146              : ok=11   changed=5    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

Certifique-se de ter um arquivo de inventário configurado corretamente e definido os hosts alvo no playbook ou passá-los como argumentos na linha de comando, conforme necessário. Isso garantirá que o Ansible execute as tarefas definidas no playbook nos hosts especificados.

Referências

Este texto foi construído com a ajuda das IAs Copilot e ChatGPT.

Policy as Code with Kyverno

Natália Granato — Fri, 19 Jul 2024 17:50:15 +0000

O que é o Kyverno?

O Kyverno é uma ferramenta de política de código aberto para o Kubernetes. Ele fornece uma maneira de definir políticas de validação, mutação, geração de recursos Kubernetes, também realiza varreduras em segundo plano e varreduras de repositório de código-fonte. O Kyverno é implantado como um controlador de recursos Kubernetes e não requer um servidor de webhook de admissão.

Ele permite segurança, automação, conformidade e governança usando política como código. As políticas do Kyverno podem ser gerenciadas como recursos do Kubernetes e não requerem o aprendizado de uma nova linguagem. Kyverno é projetado para funcionar bem com ferramentas que você já usa, como kubectl, kustomize e Git.

Como funciona - uma demo

Vamos criar um cluster kind e instalar o Kyverno. Primeiro, crie um cluster kind:

kind create cluster --name kyverno

Em seguida, instale o Kyverno:

kubectl create -f https://github.com/kyverno/kyverno/releases/download/v1.11.1/install.yaml

Agora, vamos criar uma política de exemplo para o Kyverno. Crie um arquivo chamado disallow-latest-tag.yaml com o seguinte conteúdo:

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: disallow-latest-tag
  annotations:
    policies.kyverno.io/title: Disallow Latest Tag
    policies.kyverno.io/category: Best Practices
    policies.kyverno.io/minversion: 1.6.0
    policies.kyverno.io/severity: medium
    policies.kyverno.io/subject: Pod
    policies.kyverno.io/description: >-
      The ':latest' tag is mutable and can lead to unexpected errors if the
      image changes. A best practice is to use an immutable tag that maps to
      a specific version of an application Pod. This policy validates that the image
      specifies a tag and that it is not called `latest`.      
spec:
  validationFailureAction: Enforce
  background: true
  rules:
  - name: require-image-tag
    match:
      any:
      - resources:
          kinds:
          - Pod
    validate:
      message: "An image tag is required."
      pattern:
        spec:
          containers:
          - image: "*:*"
  - name: validate-image-tag
    match:
      any:
      - resources:
          kinds:
          - Pod
    validate:
      message: "Using a mutable image tag e.g. 'latest' is not allowed."
      pattern:
        spec:
          containers:
          - image: "!*:latest"

Agora, aplique a política ao cluster:

kubectl apply -f disallow-latest-tag.yaml

O retorno será:

clusterpolicy.kyverno.io/disallow-latest-tag created

A política disallow-latest-tag possui a configuração validationFailureAction: Enforce, o que significa que ela rejeitará qualquer recurso que viole a política.

Agora, vamos criar um arquivo chamado pod.yaml com o seguinte conteúdo:

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: nginx
    image: nginx:latest

Agora, aplique o arquivo ao cluster para validar se a política irá rejeitar a criação do pod com a tag de imagem latest:

kubectl apply -f pod.yaml

O Kyverno deve rejeitar a criação do pod porque a política disallow-latest-tag não permite o uso de tags latest. Para verificar, execute o seguinte comando:

kubectl get pod

Você verá que o pod foi rejeitado. A saída será algo como:

Error from server: error when creating "pod.yml": admission webhook "validate.kyverno.svc-fail" denied the request: 

resource Pod/default/nginx was blocked due to the following policies 

disallow-latest-tag:
  validate-image-tag: 'validation error: Using a mutable image tag e.g. ''latest''
    is not allowed. rule validate-image-tag failed at path /spec/containers/0/image/'

O output acima mostra que o Kyverno rejeitou a criação do pod porque a política disallow-latest-tag não permite o uso de tags latest.

Isso mostra como o Kyverno pode ser usado para aplicar políticas de segurança e conformidade em um cluster Kubernetes.

Explicando o Dockerfile

Natália Granato — Sun, 21 Jan 2024 19:52:22 +0000

O Dockerfile é composto por uma série de instruções que especificam como a imagem Docker deve ser construída, incluindo as dependências e configurações necessárias para a aplicação funcionar corretamente dentro do contêiner Docker.

Uma imagem Docker é uma representação auto-suficiente e portável de um ambiente de execução que inclui tudo o que é necessário para executar uma aplicação, como bibliotecas, dependências e configurações. Uma imagem Docker pode ser executada em qualquer sistema operacional ou ambiente em que o Docker esteja instalado, independentemente de suas bibliotecas e configurações.

Dockerizar uma aplicação significa criar uma imagem Docker que encapsula a aplicação e suas dependências, tornando-a fácil de distribuir e executar em diferentes ambientes, independentemente das configurações do sistema local. Isso oferece uma série de benefícios, incluindo:

Portabilidade: a aplicação pode ser executada em qualquer sistema compatível com Docker, independentemente do sistema operacional, configuração ou infraestrutura subjacente.
**
Reprodutibilidade:** a imagem Docker contém todas as dependências necessárias para executar a aplicação, garantindo que a mesma versão da aplicação seja executada de forma consistente em diferentes ambientes.

Escalabilidade: as imagens Docker são leves e portáteis, o que facilita a implantação e o escalonamento de aplicativos em ambientes de nuvem ou clusters de servidores.

Facilidade de implantação: as imagens Docker podem ser facilmente implantadas em diferentes ambientes, o que economiza tempo e esforço em comparação com a configuração manual de ambientes e servidores.

Além disso, a Dockerização de uma aplicação permite que ela seja executada em contêineres isolados e seguros, que podem ser gerenciados e implantados em grande escala com mais facilidade. Isso é especialmente útil para ambientes de produção, onde a segurança e a confiabilidade são essenciais.

**FROM
**O comando FROM em um Dockerfile é usado para especificar a imagem base a partir da qual a imagem Docker está sendo construída. Essa instrução é obrigatória em um Dockerfile e deve ser a primeira instrução a ser definida no arquivo. Por exemplo, se quisermos construir uma imagem Docker que execute uma aplicação Node.js, podemos começar com uma imagem base do Node.js. Para fazer isso, podemos usar o comando FROM com a imagem base do Node.js, como no exemplo abaixo:

FROM node:14-alpine

*RUN *
O comando RUN em um Dockerfile é usado para executar comandos dentro do contêiner Docker durante o processo de construção da imagem. Esses comandos podem ser usados para instalar dependências, configurar o ambiente e executar outras tarefas necessárias para construir a imagem Docker. Por exemplo, para instalar o pacote “nginx” em uma imagem Docker baseada em Ubuntu, podemos usar o comando RUN com o comando “apt-get” para instalar o pacote, como no exemplo abaixo:

RUN apt-get update && apt-get install -y nginx

Neste exemplo, o comando “apt-get update” é executado para atualizar os repositórios de pacotes do Ubuntu, e em seguida, o comando “apt-get install -y nginx” é executado para instalar o pacote nginx.

Cada vez que o comando RUN é executado, ele cria uma nova camada na imagem Docker. Isso significa que o Docker pode usar o cache de camadas anteriores para acelerar o processo de construção da imagem, desde que o comando RUN e suas dependências não tenham sido alterados.

O comando RUN é uma das instruções mais usadas em um Dockerfile, pois permite que os desenvolvedores definam as dependências e configurações de suas aplicações de forma clara e consistente, garantindo que a imagem Docker possa ser reproduzida em qualquer sistema em que o Docker esteja instalado.

CMD

*LABEL *
Uma LABEL em um Dockerfile é uma diretiva que permite adicionar metadados (informações descritivas) a uma imagem Docker. Esses metadados podem incluir informações como a versão da imagem, o mantenedor, a descrição e outras informações relevantes. Por exemplo, para adicionar uma LABEL que especifique o mantenedor da imagem, pode-se usar a seguinte diretiva no Dockerfile:

LABEL maintainer="seu_nome"

**
EXPOSE
ENV
ADD
COPY
ENTRYPOINT
VOLUME
USER
WORKDIR
ARG
ONBUILD
STOPSIGNAL
HEALTHCHECK
SHELL**

O que é o Helm?

Natália Granato — Sun, 21 Jan 2024 19:49:34 +0000

O Helm é um gerenciador de pacotes para Kubernetes, que facilita a instalação e o gerenciamento de aplicativos em clusters do Kubernetes. Ele é usado para empacotar, distribuir e instalar aplicativos, bem como para gerenciar suas dependências.

O Helm funciona usando um modelo de pacote, onde os aplicativos são empacotados em arquivos chamados “charts”. Esses charts são compostos de um conjunto de arquivos YAML que definem os recursos do Kubernetes que serão implantados e configurados no cluster.

O Helm também inclui um sistema de gerenciamento de repositórios, onde os charts podem ser armazenados e compartilhados entre diferentes usuários e equipes. Isso permite que as equipes de desenvolvimento e operações compartilhem seus aplicativos com outras equipes e simplifiquem a implantação e a gestão de aplicativos em clusters Kubernetes.

**Alguns dos recursos mais importantes do Helm são:

***Gerenciamento de dependências:* O Helm permite que as dependências dos aplicativos sejam gerenciadas automaticamente, facilitando a implantação de aplicativos complexos que precisam de vários componentes diferentes.

Rollbacks: O Helm permite reverter rapidamente as alterações feitas em um aplicativo, em caso de problemas ou erros.

Templates: O Helm permite que os arquivos YAML sejam configurados dinamicamente, usando variáveis de modelo. Isso torna a implantação de aplicativos mais flexível e fácil de personalizar.

Valores de configuração: O Helm permite que os valores de configuração sejam definidos separadamente dos arquivos YAML do chart. Isso simplifica o gerenciamento de configurações em diferentes ambientes.

O Helm é uma ferramenta de código aberto, mantida pela comunidade e hospedada no GitHub. Ele é amplamente utilizado no ecossistema Kubernetes e possui uma grande comunidade de usuários e desenvolvedores.

Aqui estão alguns dos principais comandos do Helm que podem ser usados para debug:

helm install --dry-run --debug

Esse comando executa uma simulação da instalação do chart, exibindo informações detalhadas do processo de instalação, como os valores de configuração, recursos do Kubernetes que serão criados e outras informações relevantes. Ele é útil para verificar se as configurações estão corretas antes de fazer a instalação real.

helm lint

Esse comando executa uma verificação estática no chart para garantir que ele esteja formatado corretamente e siga as melhores práticas do Helm. Ele verifica se o chart tem arquivos obrigatórios, se os valores estão definidos corretamente e se a sintaxe está correta.

helm get manifest <release-name>

Esse comando exibe o manifesto Kubernetes que foi gerado para um determinado release do Helm. Isso permite que você visualize o que será criado no Kubernetes antes de fazer a instalação real.

helm get values <release-name>

Esse comando exibe os valores de configuração que foram definidos para um determinado release do Helm. Isso é útil para verificar se os valores foram definidos corretamente antes da instalação.

helm rollback <release-name> <revision-number>

Esse comando faz o rollback para uma versão anterior do release do Helm. Ele é útil para reverter uma atualização que pode ter causado problemas no ambiente Kubernetes.

helm delete --purge <release-name>

Esse comando remove um release do Helm e todos os seus recursos associados do cluster Kubernetes. É útil para limpar um ambiente que não está sendo mais utilizado.

Esses são apenas alguns dos principais comandos do Helm para debug. Existem outros comandos e opções disponíveis que podem ser úteis para diferentes cenários de debug. Consulte a documentação oficial do Helm para obter mais informações.

Seu ambiente de laboratório Kubernetes com k3d

Natália Granato — Mon, 23 Jan 2023 01:23:24 +0000

Implemente o seu ambiente de laboratório

k3d é um pequeno programa feito para executar um cluster K3s no Docker. O K3s é um projeto Sandbox e uma distribuição Kubernetes leve e certificada pela CNCF. Projetado para ambientes de poucos recursos, o K3s é distribuído como um único binário que usa menos de 512 MB de RAM.

O k3d facilita muito a criação de clusters k3s de um ou vários nós no docker, por exemplo, para desenvolvimento local no Kubernetes.

Requisitos
Tenha o docker instalado para poder utilizar o k3d.
O kubectl para interagir com o cluster Kubernetes.

Instalação via script

wget -q -O - https://raw.githubusercontent.com/k3d-io/k3d/main/install.sh | bash

Criando um cluster k3s de alta disponibilidade com o k3d

Como as práticas recomendadas de alta disponibilidade do Kubernetes, devemos criar um cluster de alta disponibilidade com pelo menos três nós control plane.

Podemos conseguir isso no k3d em um comando:

k3d cluster create --servers 3 --image rancher/k3s:v1.23.15-k3s1-amd64

Aprendendo o comando:

Comando base: k3d cluster create
Opções:
– server 3: solicita que três nós sejam criados.

– image rancher/k3s:v1.19.3-k3s2: especifica a imagem K3S a ser usada.

Agora podemos verificar o que foi criado a partir dos diferentes pontos de vista:

kubectl get nodes --output wide

Scale

Graças ao k3d e ao fato de nosso cluster ser executado em contêineres, podemos simular rapidamente a adição de outro nó control plane ao cluster HA:

k3d node create extraCPnode --role=server --image=rancher/k3s:v1.19.3-k3s2

Aprendendo o comando:

Comando base: k3d node create

Opções:

extraCPnode: nome base que o k3d usará para criar o nome do nó.

role=server: define a função do nó como um control plane.

image rancher/k3s:v1.19.3-k3s2: especifica a imagem K3s a ser usada.

Limpando os recursos

k3d cluster delete

Tradução livre:
https://www.suse.com/c/rancher_blog/set-up-k3s-in-high-availability-using-k3d/

Seu ambiente de laboratório Kubernetes com KinD

Natália Granato — Fri, 20 Jan 2023 15:56:15 +0000

Se você está iniciando agora os seus estudos sobre Kubernetes é importante ter um cluster para se familiarizar com os componentes, comandos e etc. Existem muitas plataformas que oferecem clusters kubernetes para experimentar, entre elas o minikube, k3s, microk8s e etc, não recomendadas para produção. Para isso você pode ir com GKE (Google Cloud), EKS (AWS).

Existem plataformas como o Play with Kubernetes que oferecem ambientes temporários, com isso você pode perder o seu aprendizado e objetos deployados no playground. Nos provedores de nuvem temos que desembolsar um valor considerável para ter um cluster, por isso o KinD - Kubernetes em Docker é uma boa alternativa pra quem está iniciando agora sua jornada e necessita de um ambiente de desenvolvimento e testes.

*Siga os passos abaixo para ter um cluster pra chamar de seu:
*

1. Instale o Docker:
Este exemplo baixa o script de https://get.docker.com/ e o executa para instalar a versão estável mais recente do Docker no Linux:

curl -fsSL https://get.docker.com -o get-docker.sh
sudo sh get-docker.sh

Você pode acessar a documentação oficial para verificar como instalar em outros sistemas operacionais.

*2. Instale o Kubectl:
*
A instalação do kubectl em sua máquina permitirá que você acesse o cluster que iremos criar e outros no futuro.

sudo apt-get update
sudo apt-get install -y kubectl

O Kubectl também está disponível para macos e windows, clique aqui.

*3. Instale o KinD:
*

curl -Lo ./kind https://kind.sigs.k8s.io/dl/v0.9.0/kind-linux-amd64
chmod +x ./kind
mv ./kind /usr/local/bin/kind

4. Criando um cluster:
Agora temos o necessário para criar o nosso cluster, se você executar o comando:

kind create cluster

Ele irá criar um cluster com as configurações padrões, mas a partir de um arquivo de configuração podemos informar quantos nós desejamos.

4.1. Criando um arquivo de configuração do KinD:
A documentação oficial fornece um exemplo, acessível clicando aqui.

cat > kind-config.yaml <<EOF
# um cluster com 3 nós control plane e 3 workers
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
- role: control-plane
- role: control-plane
- role: control-plane
- role: worker
- role: worker
- role: worker
EOF

4.2 Criando o nosso cluster:

kind create cluster --name k8s-playground --config kind-config.yaml

Agora o cluster está pronto e você pode usar comandos kubectl para trabalhar no cluster.

5. Deletando um cluster:

kind delete cluster --name k8s-playground

Deploying Rancher Server com o Vagrant

Natália Granato — Thu, 06 Oct 2022 20:40:50 +0000

As etapas a seguir implantam rapidamente um Rancher Server com um cluster de nó único anexado.

Atenção

A intenção desse guia é lançar rapidamente um sandbox que você pode usar para conhecer o Rancher. Não se destinam a ambientes de produção.

Pré-requisitos

Vagrant: Vagrant é necessário, pois é usado para provisionar a máquina com base no Vagrantfile.

Virtualbox: As máquinas virtuais que o Vagrant provisiona precisam ser provisionadas para o VirtualBox.
Pelo menos 4 GB de RAM livre.

Observação

O Vagrant exigirá plugins para criar VMs do VirtualBox. Instale-os com os seguintes comandos:

vagrant plugin instalar vagrant-vboxmanage
vagrant plugin instalar vagrant-vbguest

Começando

Clone Rancher Quickstart para uma pasta usando

git clone https://github.com/rancher/quickstart

Vá para a pasta que contém o Vagrantfile executando

cd quickstart/rancher/vagrant

Opcional: edite config.yaml para:

Altere o número de nós e as alocações de memória, se necessário. (node.count, node.cpus, node.memory)
Altere a senha do usuário administrador para fazer login no Rancher. (senha do administrador)
Para iniciar a criação do ambiente execute:

vagrant up --provider=virtualbox

Quando o provisionamento terminar, acesse https://192.168.56.101 no navegador. O usuário/senha padrão é admin/adminPassword.

Resultado: o Rancher Server e seu cluster Kubernetes estão instalados no VirtualBox.

Destruindo o Meio Ambiente

Na pasta quickstart/rancher/vagrant execute

vagrant destroy -f.

Aguarde a confirmação de que todos os recursos foram destruídos.

DEV Community: Natália Granato

Build de Imagens no Kubernetes com Gitlab Runner e Kaniko

O que é o Gitlab Runner?

Registro do Runner em seus projetos

Deploy do Gitlab Runner no Kubernetes usando Helm

Pontos de atenção no values.yaml

Explicação do Arquivo de Configuração

Regras (rules)

Runners (runners)

Secrets (secrets)

SecurityContext (securityContext)

Service (service)

ServiceAccount (serviceAccount)

SessionServer (sessionServer)

Shutdown Timeout (shutdown_timeout)

Strategy (strategy)

Termination Grace Period Seconds (terminationGracePeriodSeconds)

Tolerations (tolerations)

Topology Spread Constraints (topologySpreadConstraints)

UseTini (useTini)

VolumeMounts (volumeMounts)

Volumes (volumes)

GitLab URL (gitlabUrl)

Runner Registration Token (runnerRegistrationToken)

Utilizando o novo runner em pipelines do Gitlab CI

Kubernetes não utiliza Docker como container runtime e agora? O Kaniko pode resolver esse problema

O que é o Kaniko e como ele funciona?

Configurando variáveis de ambiente no Gitlab CI

Passos para configurar variáveis de ambiente para a sua pipeline

Exemplo .gitlab-ci.yml de build e push de imagens de containers com o Kaniko

Conclusão

A Importância dos testes de carga no Kubernetes: Garantindo a resiliência e escalabilidade

Planejamento Adequado:

Configuração de Rede:

Gerenciamento de Recursos:

Backup e Recuperação:

Testes de Carga Realistas:

Monitoramento Contínuo:

Automação de Escalonamento:

Ferramentas Recomendadas:

Um exemplo prático com Kubecarga

Pré-requisitos

O que o código faz

Pontos de atenção

Clone este repositório

Inicialize o módulo Go

Instalação das dependências

Construindo o projeto

Como executar

Kubernetes Vanilla em instâncias ec2

Criando um Cluster Kubernetes em Instâncias EC2

Configurações das Instâncias EC2

Configurações do Cluster Kubernetes

Conectando-se às Instâncias

Configurando os Nós

Criando o cluster Kubernetes na versão v1.30

Parâmetros avançados no Docker Compose

O que é o Docker Compose?

Alguns comandos para facilitar o seu dia a dia

Docker compose build, replicas e resources

Funcionalidade build

Funcionalidade replicas

Comandos úteis do Docker Compose

Qual é a diferença entre Docker e Docker Compose?

Certificado TLS no Kubernetes

Criando um ConfigMap para adicionar um arquivo no Pod e configurar o SSL no Nginx

Iniciando com o Ansible

Ansible: Uma Visão Geral

Automatização de Tarefas

Modelagem Declarativa

Playbooks

Integração com Nuvem e Contêineres

Arquitetura

Um projeto prático

Executando o Ansible Node Exporter

Referências

Policy as Code with Kyverno

O que é o Kyverno?

Como funciona - uma demo

Explicando o Dockerfile

Regras (`rules`)

Runners (`runners`)

Secrets (`secrets`)

SecurityContext (`securityContext`)

Service (`service`)

ServiceAccount (`serviceAccount`)

SessionServer (`sessionServer`)

Shutdown Timeout (`shutdown_timeout`)

Strategy (`strategy`)

Termination Grace Period Seconds (`terminationGracePeriodSeconds`)

Tolerations (`tolerations`)

Topology Spread Constraints (`topologySpreadConstraints`)

UseTini (`useTini`)

VolumeMounts (`volumeMounts`)

Volumes (`volumes`)

GitLab URL (`gitlabUrl`)

Runner Registration Token (`runnerRegistrationToken`)

Exemplo `.gitlab-ci.yml` de build e push de imagens de containers com o Kaniko

Funcionalidade `build`