DEV Community: Cristiano Lemes

Isolando cargas de trabalho no k8s com kata container

Cristiano Lemes — Thu, 12 Dec 2024 21:26:12 +0000

Introdução

Containers revolucionaram a forma como implantamos e gerenciamos aplicações, oferecendo portabilidade, escalabilidade e eficiência no uso de recursos. No entanto, apesar dessas vantagens, containers tradicionais não são projetados para fornecer isolamento total entre cargas de trabalho. Eles compartilham o kernel do sistema operacional do host, o que significa que, em cenários de ataque, vulnerabilidades no kernel ou nos próprios mecanismos de conteinerização, como namespaces e cgroups, podem ser exploradas para comprometer o ambiente do host ou outros containers.

Além disso, ataques como container escape permitem que um invasor rompa as barreiras de isolamento e obtenha acesso a recursos do host. Essa preocupação é ainda mais relevante em ambientes multi-tenant, onde múltiplas cargas de trabalho de diferentes equipes ou clientes podem estar sendo executadas lado a lado.

Por conta dessas limitações, surge a necessidade de soluções mais robustas para isolamento de cargas de trabalho. Tecnologias como Kata Containers e Firecracker oferecem maior segurança ao combinarem a leveza dos containers com o isolamento robusto de máquinas virtuais (VMs), criando uma camada adicional de proteção sem sacrificar a eficiência operacional.

Neste guia, exploraremos como integrar essas tecnologias ao Kubernetes para isolar cargas de trabalho de forma eficaz, reduzindo riscos de segurança em ambientes sensíveis.

Ferramentas Utilizadas

Cilium
Terraform
Ansible
Equinix Metal
Kata Container
Firecraker
Helm

Ambiente Local
Ferramentas instaladas

Metal Cli (Ferramenta de linha de comando da Equinix Metal)

go install github.com/equinix/metal-cli/cmd/metal@latest

Ansible no Linux com pipx ou uv:

pipx install ansible-core

uvx ansible

Ansible no Windows com Docker:
Crie os alias no seu $PROFILE

function runansible { 
  docker run -ti --rm `
    -v "$HOME\.ssh:/root/.ssh" `
    -v "$HOME\.aws:/root/.aws" `
    -v "${PWD}:/apps" `
    -w /apps `
    alpine/ansible ansible @args
}  
New-Alias -Name ansible -Value runansible

function playbook {
  docker run -ti --rm `
    -v "$HOME\.ssh:/root/.ssh" `
    -v "$HOME\.aws:/root/.aws" `
    -v "${PWD}:/apps" `
    -w /apps alpine/ansible `
   bash -c `
   "chmod -R 700 /root/.ssh && ansible-playbook $($args -join ' ')"
}
New-Alias -Name ansible-playbook -Value playbook

Terraform siga a instalação para sua plataforma

Parte 1: Criando servidores

Nessa guia eu vou usar a Equinix Metal para o ambiente de servidores, você também pode usar seu provedor de Bare metal preferido, ou ambiente de virtualização local se seu ambiente suportar virtualização aninhada (Nested VT-x/AMD-V).
os requisitos são mínimo 2 servidores com 2CPU e 4GB de Ram .

Criando ambiente na Equinix Metal

1. Crie uma conta na Equinix Metal , ou caso já tenha faça login.

No momento eles estão oferendo um crédito de $250,00 para testar a plataforma, o suficiente para seguir esse tutorial. O uso é cobrado por hora em instancias on demand, com cobrança mínima de 1 hora (Não adianta desligar depois de 1 minuto, vai cobrar 1 hora).

2. Crie uma chave de API para acessar a Equinix.

No console da equinix, selecione o projeto em qual você vai criar suas maquinas, vá em project settings, e em api keys, adicione uma chave com permissão readwrite.

Criando scripts Terraform para a implantação das máquinas

Siga as instruções abaixo para criar os arquivos e configurar a infraestrutura.

1. Estrutura de Arquivos

📂 k8s-metal-fire/
├── 📂 terraform/
│ ├── 📄 main.tf
│ ├── 📄 output.tf
│ ├── 📄 providers.tf
│ ├── 📄 terraform.tfvars
│ ├── 📄 variables.tf
│ └── 📝 inventory.sh
├── 📂 ansible/
....

Crie a estrutura de pastas e arquivos. Use os comandos abaixo:

mkdir -p k8s-metal-fire/terraform
mkdir -p k8s-metal-fire/ansible/{build,inventory,scripts/devmapper}

touch k8s-metal-fire/terraform/{main.tf,output.tf,providers.tf,terraform.tfvars,variables.tf}
touch k8s-metal-fire/ansible/{build/firecracker,inventory/hosts.yml,scripts/devmapper/{create.sh,reload.sh}}
touch k8s-metal-fire/{cluster_bootstrap.yml,k8s_environment.yml,k8s_firecracker.yml,main.yml}

2. Crie o arquivo main.tf

Esse arquivo define os recursos que serão provisionados no Equinix Metal.

Conteúdo:

resource "equinix_metal_device" "k8s_master" {
  count            = var.k8s_master.num_instances
  hostname         = "k8s-master-${count.index + 1}"
  plan             = var.k8s_master.plan
  metro            = var.em_region
  operating_system = var.k8s_master.operating_system
  billing_cycle    = var.billing_cycle
  project_id       = var.em_project_id

  tags = ["kubernetes", "master"]
}

resource "equinix_metal_device" "k8s_worker" {
  count            = var.k8s_nodes.num_instances
  hostname         = "k8s-worker-${count.index + 1}"
  plan             = var.k8s_nodes.plan
  metro            = var.em_region
  operating_system = var.k8s_nodes.operating_system
  billing_cycle    = var.billing_cycle
  project_id       = var.em_project_id

  tags = ["kubernetes", "worker"]
}

O que faz:

Define dois tipos de máquinas:
- Masters: Controlam o cluster Kubernetes.
- Workers: Executam os workloads (cargas de trabalho).

3. Crie o arquivo output.tf

Esse arquivo define as saídas dos recursos provisionados.

Conteúdo:

output "master_ips" {
  value = {
    for device in equinix_metal_device.k8s_master :
    device.hostname => {
      "public_ip"  = device.access_public_ipv4
      "private_ip" = device.access_private_ipv4
    }
  }
  description = "IP addresses of master nodes"
}

output "worker_ips" {
  value = {
    for device in equinix_metal_device.k8s_worker :
    device.hostname => {
      "public_ip"  = device.access_public_ipv4
      "private_ip" = device.access_private_ipv4
    }
  }
  description = "IP addresses of worker nodes"
}

O que faz:

Mostra os IPs públicos e privados dos masters e workers após a execução do Terraform.

4. Crie o arquivo providers.tf

Esse arquivo configura o provedor do Terraform.

Conteúdo:

terraform {
  required_providers {
    equinix = {
      source  = "equinix/equinix"
      version = "2.11.0"
    }
  }
  # backend "gcs" {
  #   bucket = "cslemes-terraform"
  #}
}

provider "equinix" {
  auth_token = var.em_api_token
}

O que faz:

Configura o provedor Equinix Metal para gerenciar os recursos.
Inclui um exemplo comentado de backend remoto para armazenar o estado do Terraform.

5. Crie o arquivo terraform.tfvars

Esse arquivo define os valores das variáveis.

Conteúdo:

em_api_token  = "xxxxxxxxxxxxxxxxxxxxxxxxx"
em_project_id = "xxxxxxxxxxxxxxxxxxxxxxxxxx"
em_region     = "da"

billing_cycle = "hourly"

k8s_master = {
  plan             = "c3.small.x86"
  ipxe_script_url  = ""
  operating_system = "ubuntu_24_04"
  num_instances    = 3
  tags             = ["k8s_master"]
}

k8s_nodes = {
  plan             = "c3.small.x86"
  ipxe_script_url  = ""
  operating_system = "ubuntu_24_04"
  num_instances    = 2
  tags             = ["k8s-nodes"]
}

O que faz:

Define as credenciais (API token e ID do projeto).
Configura os planos e características das máquinas para os masters e workers.

6. Crie o arquivo variables.tf

Esse arquivo declara as variáveis usadas no projeto.

Conteúdo:

variable "em_api_token" {
  description = "Equinix Metal API Key"
  type        = string
}

variable "em_project_id" {
  description = "Equinix Metal Project ID"
  type        = string
}

variable "em_region" {
  description = "Equinix Metal region to use"
  type        = string
}

variable "billing_cycle" {
  description = "value of billing cycle"
  type        = string
}

variable "k8s_master" {
  description = "k8s master"
  type = object({
    plan             = string
    ipxe_script_url  = optional(string)
    operating_system = string
    num_instances    = number
    tags             = optional(list(string), [])
  })
}

variable "k8s_nodes" {
  description = "k8s nodes"
  type = object({
    plan             = string
    ipxe_script_url  = optional(string)
    operating_system = string
    num_instances    = number
    tags             = optional(list(string), [])
  })
}

O que faz:

Declara as variáveis obrigatórias, como token, projeto, região, e configurações dos nós.

Com esses arquivos criados, você pode iniciar a implantação executando os seguintes comandos no diretório terraform:

terraform init      # Inicializa o projeto
terraform plan      # Exibe o plano de execução
terraform apply     # Aplica as configurações e provisiona os recursos

7. Crie o arquivo inventory.sh

Esse script vai pegar o output do terraform e gerar o arquivo de inventory para o ansible.

terraform output -json | jq -r '
  .master_ips.value as $masters |
  .worker_ips.value as $workers |
  {
    all: {
      children: {
        k8s_master: {
          hosts: (
            $masters | to_entries | map({
              (.key): {
                ansible_host: .value.public_ip,
                ansible_user: "root"
              }
            }) | add
          )
        },
        k8s_workers: {
          hosts: (
            $workers | to_entries | map({
              (.key): {
                ansible_host: .value.public_ip,
                ansible_user: "root"
              }
            }) | add
          )
        }
      }
    }
  }
' | yq -P > ../ansible/hosts.yaml

Criando manifestos Ansible para configuração do cluster Kubernetes

Você pode criar os arquivos necessários para o Ansible em uma estrutura organizada. Aqui está um guia passo a passo para criar e organizar os arquivos mencionados:

1. Estrutura de diretórios

Crie os seguintes diretórios e arquivos no seu projeto:

📂 ansible/
├── 📂 group_vars/
├── 📂 host_vars/
├── 📂 roles/
│ ├── 📂 k8s_environment/
│ │ ├── 📂 scripts/
│ │ │ ├── 📂 devmapper/
│ │ │ │ ├── 📄 create.sh
│ │ │ │ └── 📄 reload.sh
│ │ │ └── 📄 devmapper_reload.service
│ │ ├── 📂 tasks/
│ │ │ └── 📄 main.yml
│ ├── 📂 k8s_bootstrap/
│ │ ├── 📂 build/
│ │ │ └── 📄 firecraker
│ │ ├── 📂 tasks/
│ │ │ └── 📄 main.yml
│ ├── 📂 k8s_firecracker/
│ │ ├── 📂 tasks/
│ │ │ └── 📄 main.yml
│ ├── 📂 apply_kata/
│ │ ├── 📂 tasks/
│ │ │ └── 📄 main.yml
├── 📄 hosts.yml
└── 📄 playbook.yml

2. Arquivo hosts.yml

Define os grupos de hosts (master e workers), vamos cria-lo a partir do output do terraform aqui é um exemplo:

all:
  children:
    k8s_master:
      hosts:
        node1:
          ansible_host: 147.75.45.67
          ansible_user: root
    workers:
      hosts:
        node:
          ansible_host: 147.28.197.223
          ansible_user: root

3. Arquivo playbook.yml

O ponto de entrada principal do Ansible:

- name: Setup Kubernetes cluster
  hosts: all
  become: yes
  tasks:
    - name: Install Kubernetes dependencies
      import_role:
        name: k8s_environment

- name: Configure Firecracker
  hosts: all
  become: yes
  tasks:
    - name: Configure Firecracker
      import_role:
        name: k8s_firecracker

- name: Add kube-vip
  hosts: k8s_master
  become: yes
  tasks:
    - name: Generate kube-vip manifest
      include_tasks: kube-vip.yaml

- name: Bootstrap Kubernetes cluster
  hosts: k8s_master
  become: yes
  tasks:
    - name: Bootstrap cluster
      import_role:
        name: k8s_bootstrap

- name: Apply Kata manifests
  hosts: k8s_master
  become: yes
  tasks:
    - name: Apply Kata
      import_role:
        name: apply_kata

- name: Join worker nodes
  hosts: k8s_workers
  become: yes
  tasks:
    - name: Join cluster
      command: "{{ hostvars[groups['k8s_master'][0]]['join_command'] }}"
      args:
        creates: /etc/kubernetes/kubelet.conf

4. Arquivo roles/k8s_environment/tasks/main.yml

Responsável por configurar o ambiente do Kubernetes:

---
- name: Update apt cache
  ansible.builtin.apt:
    update_cache: yes

- name: Install required packages
  ansible.builtin.apt:
    name:
      - apt-transport-https
      - ca-certificates
      - curl
      - gnupg
      - lsb-release
      - thin-provisioning-tools
      - lvm2
      - bc
    state: present

- name: Install Container runtime
  ansible.builtin.apt:
    name:
      - containerd
    state: present

- name: Enable and start container runtime
  ansible.builtin.systemd:
    name: containerd
    state: started
    enabled: yes

- name: Create Containerd Directory
  ansible.builtin.file:
    path: /etc/containerd
    state: directory
    mode: "0755"

- name: Configure containerd default
  ansible.builtin.shell: |
    mkdir -p /etc/containerd
    containerd config default > /etc/containerd/config.toml
    sed -i 's/SystemdCgroup = false/SystemdCgroup = true/' /etc/containerd/config.toml

- name: Reload containerd
  ansible.builtin.systemd:
    name: containerd
    state: started

- name: Download Kubernetes GPG key
  ansible.builtin.get_url:
    url: https://pkgs.k8s.io/core:/stable:/v1.31/deb/Release.key
    dest: /tmp/kubernetes-release.key

- name: Crege keyring directory
  ansible.builtin.file:
    path: /etc/apt/keyrings
    state: directory

- name: Convert and move Kubernetes GPG key
  ansible.builtin.command:
    cmd: gpg --yes --dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg /tmp/kubernetes-release.key

- name: Add Kubernetes repository
  ansible.builtin.lineinfile:
    path: /etc/apt/sources.list.d/kubernetes.list
    line: "deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v1.31/deb/ /"
    create: yes

- name: Update apt cache
  apt:
    update_cache: yes

- name: Install Kubernetes packages
  apt:
    name:
      - kubelet
      - kubeadm
      - kubectl
    state: present

- name: Hold Kubernetes packages
  dpkg_selections:
    name: "{{ item }}"
    selection: hold
  loop:
    - kubelet
    - kubeadm
    - kubectl

- name: Disable swap
  command: swapoff -a
  when: ansible_swaptotal_mb > 0

- name: Remove swap from /etc/fstab
  lineinfile:
    path: /etc/fstab
    regexp: '^[^#].*\sswap\s.*'
    state: absent

- name: Enable kernel modules
  modprobe:
    name: "{{ item }}"
    state: present
  loop:
    - overlay
    - br_netfilter

- name: Add kernel modules to load on boot
  copy:
    dest: /etc/modules-load.d/k8s.conf
    content: |
      overlay
      br_netfilter

- name: Set kernel parameters for Kubernetes
  sysctl:
    name: "{{ item.name }}"
    value: "{{ item.value }}"
    state: present
    reload: yes
  loop:
    - { name: "net.bridge.bridge-nf-call-iptables", value: "1" }
    - { name: "net.bridge.bridge-nf-call-ip6tables", value: "1" }
    - { name: "net.ipv4.ip_forward", value: "1" }

- name: Set extra args for kubelet
  ansible.builtin.lineinfile:
    path: /etc/default/kubelet
    regexp: "^KUBELET_EXTRA_ARGS="
    line: 'KUBELET_EXTRA_ARGS="--cloud-provider=external"'
    state: present

5. Arquivo roles/k8s_bootstrap/tasks/main.yml

Responsável pelo bootstrap do cluster Kubernetes:

---
- name: Get the IP address of the master node
  set_fact:
    advertise_address: "{{ ansible_default_ipv4.address }}"
    # advertise_address: "10.70.191.131"
- name: Initialize Kubernetes cluster
  command: kubeadm init --skip-phases=addon/kube-proxy --pod-network-cidr=10.244.0.0/16 --apiserver-advertise-address {{ advertise_address }}
  register: kubeadm_init
  args:
    creates: /etc/kubernetes/admin.conf
- name: Create .kube directory
  file:
    path: /root/.kube
    state: directory
    mode: "0755"
- name: Copy admin.conf to root's kube config
  copy:
    src: /etc/kubernetes/admin.conf
    dest: /root/.kube/config
    remote_src: yes
    owner: root
    group: root
    mode: "0644"
- name: Deploy Calico
  command: kubectl apply -f https://raw.githubusercontent.com/projectcalico/calico/v3.29.1/manifests/calico.yaml
- name: Get join command
  command: kubeadm token create --print-join-command
  register: join_command
- name: Store join command
  set_fact:
    join_command: "{{ join_command.stdout }}"

6. Arquivo roles/k8s_firecracker/tasks/main.yml

Configura o Firecracker:

---
- name: Copy Firecracker binary
  copy:
    src: build/firecracker
    dest: /usr/local/bin/firecracker
    mode: "0755"

- name: Create DevMapper directories
  ansible.builtin.file:
    path: /var/lib/containerd/io.containerd.snapshotter.v1.devmapper
    state: directory
    mode: "0755"

- name: Move and set permissions for DevMapper scripts
  copy:
    src: "{{ item.src }}"
    dest: "{{ item.dest }}"
    mode: "0755"
  with_items:
    - {
        src: scripts/devmapper/create.sh,
        dest: /usr/local/bin/devmapper-create.sh,
      }
    - {
        src: scripts/devmapper/reload.sh,
        dest: /usr/local/bin/devmapper-reload.sh,
      }

- name: Run initial DevMapper creation script
  ansible.builtin.command: /usr/local/bin/devmapper-create.sh
  ignore_errors: yes

- name: Containerd Configuration Firecracker
  ansible.builtin.shell: |
    CONFIG_FILE="/etc/containerd/config.toml"
    sudo cp "$CONFIG_FILE" "${CONFIG_FILE}.bak"

    sudo sed -i '/\[plugins."io.containerd.snapshotter.v1.devmapper"\]/,/^$/d' "$CONFIG_FILE"
    sudo sed -i '/\[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.kata-fc\]/,/^$/d' "$CONFIG_FILE"

    cat <<EOF >> /etc/containerd/config.toml
    [plugins."io.containerd.snapshotter.v1.devmapper"]
    pool_name = "devpool"
    root_path = "/var/lib/containerd/io.containerd.snapshotter.v1.devmapper"
    base_image_size = "40GB"

    [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.kata-fc]
    snapshotter = "devmapper"
    runtime_type = "io.containerd.kata-fc.v2"
    EOF

- name: Create DevMapper reload systemd service
  copy:
    dest: /lib/systemd/system/devmapper-reload.service
    content: |
      [Unit]
      Description=Devmapper reload script
      After=network.target

      [Service]
      Type=oneshot
      ExecStart=/usr/local/bin/devmapper-reload.sh
      RemainAfterExit=yes

      [Install]
      WantedBy=multi-user.target

- name: Enable and reload systemd daemon
  systemd:
    name: devmapper-reload.service
    enabled: yes
    daemon_reload: yes

- name: Restart containerd
  systemd:
    name: containerd.service
    state: restarted

7. Arquivo roles/apply_kata/tasks/main.yml

Aplica os manifestos Kata:

---
- name: Install Kata RBAC
  ansible.builtin.command: kubectl apply -f https://raw.githubusercontent.com/kata-containers/kata-containers/main/tools/packaging/kata-deploy/kata-rbac/base/kata-rbac.yaml
- name: Install Kata Deploy
  ansible.builtin.command: kubectl apply -f https://raw.githubusercontent.com/kata-containers/kata-containers/main/tools/packaging/kata-deploy/kata-deploy/base/kata-deploy.yaml
- name: Install Kata Runtime
  ansible.builtin.command: kubectl apply -f https://raw.githubusercontent.com/kata-containers/kata-containers/main/tools/packaging/kata-deploy/runtimeclasses/kata-runtimeClasses.yaml
- name: Install Rke LocalPath
  ansible.builtin.command: kubectl apply -f https://raw.githubusercontent.com/rancher/local-path-provisioner/v0.0.30/deploy/local-path-storage.yaml

8. Executando o Ansible

Com tudo configurado, execute o seguinte comando para aplicar o playbook:

ansible-playbook -i hosts.yml playbook.yml

Estrutura de diretórios: Usamos roles para separar as responsabilidades.
Playbook: Importa os roles para configurar diferentes partes do cluster.
Hosts: Define os grupos de servidores para os nós mestres e trabalhadores.
Execução: O comando ansible-playbook aplica todas as tarefas nos servidores.

Rodando tudo junto

Crie um arquivo make file.

.PHONY: all init plan apply destroy ansible-lint terraform-lint ansible-deploy help

# Directories
TERRAFORM_DIR := terraform
ANSIBLE_DIR := ansible

# Default target
all: init plan apply create-inventory ansible-deploy
    @echo "Complete deployment finished successfully!"

help:
    @echo "Available targets:"
    @echo "  init           - Initialize Terraform"
    @echo "  plan           - Create Terraform plan"
    @echo "  apply          - Apply Terraform changes"
    @echo "  destroy        - Destroy Terraform infrastructure"
    @echo "  create-inventory - Generate Ansible inventory from Terraform outputs"
    @echo "  ansible-lint   - Run Ansible linter"
    @echo "  ansible-deploy - Run Ansible playbook"
    @echo "  terraform-lint - Run Terraform formatting and validation"
    @echo
    @echo "Example usage:"
    @echo "  make all       - Runs init, plan, apply, inventory, and ansible-deploy"

# Terraform targets
init:
    cd $(TERRAFORM_DIR) && terraform init

plan:
    cd $(TERRAFORM_DIR) && terraform plan

apply:
    cd $(TERRAFORM_DIR) && terraform apply -auto-approve

destroy:
    cd $(TERRAFORM_DIR) && terraform destroy -auto-approve

# Generate Ansible inventory
create-inventory:
    cd $(TERRAFORM_DIR) && ./inventory.sh

# Ansible targets
ansible-lint:
    ansible-lint $(ANSIBLE_DIR)/

ansible-deploy:
    ansible-playbook -i $(ANSIBLE_DIR)/hosts.yml $(ANSIBLE_DIR)/playbook.yml

# Terraform linting and validation
terraform-lint:
    cd $(TERRAFORM_DIR) && terraform fmt -check && terraform validate

Este Makefile automatiza o processo de gerenciamento de infraestrutura com Terraform e Ansible, organizando os comandos em alvos específicos para facilitar o uso e manutenção. Aqui está um resumo das principais funcionalidades:

Alvo Principal (all):

Executa todo o pipeline, incluindo init, plan, apply, criação do inventário (create-inventory) e a execução do playbook Ansible.
Gerenciamento com Terraform:
- init: Inicializa o Terraform.
- plan: Gera o plano de execução.
- apply: Aplica as alterações na infraestrutura.
- destroy: Destroi a infraestrutura provisionada.
Inventário Dinâmico:
- create-inventory: Gera o inventário do Ansible com base na saída do Terraform.
Ansible:
- ansible-lint: Executa o linter para validar os playbooks.
- ansible-deploy: Executa o playbook principal (playbook.yml).
Linting e Validação de Terraform:
- terraform-lint: Valida a formatação e os arquivos de configuração do Terraform.
Ajuda (help):

Exibe os alvos disponíveis e um exemplo de uso.

Teste
Crie um manifesto para um nginx
Adicione runtimeClassName: kata-fc em specs.

   apiVersion: v1
   kind: Pod
   metadata:
     creationTimestamp: null
     labels:
       run: nginx1
     name: nginx1
   spec:
     runtimeClassName: kata-fc
     containers:
     - image: nginx
       name: nginx1
       resources: {}
     dnsPolicy: ClusterFirst
     restartPolicy: Always
   status: {}

Verifique a versão do kernel do container

   $ k exec -it nginx1 -- bash -c "uname -a"
   Linux nginx1 6.1.62 #1 SMP Fri Nov 15 11:22:02 UTC 2024 x86_64 GNU/Linux

E o kernel do host

   root@k8s-master-1:~# uname -a
    Linux k8s-master-1 6.8.0-49-generic #49-Ubuntu SMP PREEMPT_DYNAMIC Mon      Nov  4 02:06:24 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

Referências

Repositório do Projeto
Aws Firecracker Kata Containers

Implantando Aplicações Serverless no Google Cloud Run

Cristiano Lemes — Mon, 18 Nov 2024 18:25:35 +0000

Introdução

Nesse guia vou demonstrar como implantar aplicações Serverless usando Google cloud Run

Arquitetura na GCP

Não será usada nenhuma ferramenta de automação complexa, tudo será feita pela console, integrando com o Github e fazendo o deploy das imagens a cada commit na main.
Usaremos:

Cloud Run - Para as aplicações web
Cloud SQL - Para o banco de dado MySQL
GCE - Para rodar o Teomebot
Cloud Storage - Object Storage (S3)
Cloud Build - Para criar o deploy das aplicações
Secret Manager - Salvar as credencias da aplicação de forma segura.

Obtendo as aplicações

Visite o GitHub do TeoMeWhy e faça o fork das aplicações relacionadas ao projeto.
Na página do repositório, clique em Starred e depois em Fork.
Na página de fork, dê um nome ao fork e clique em Create fork.
Repita o processo para os outros repositórios do projeto caso queira replicar todo o ambiente.
Faça o clone do fork para ajustar o necessário na aplicação antes de enviá-la para o GCP.

git clone git@github.com:cslemes/points-to-go.git

Criando o Dockerfile para criação da imagem de container

Navegue até a pasta do repositório clonado. O repositório já contém um Dockerfile pensado para o Docker. Vamos analisá-lo:

```
FROM golang:latest
WORKDIR /app/
COPY . .
RUN go build main.go
CMD ["./main"]
```

Esse Dockerfile está funcional, mas vamos otimizá-lo usando multi-stage builds para reduzir o tamanho da imagem final. Como o Go não requer dependências externas, podemos usar uma imagem base mínima como scratch.

Troque a imagem de build por uma versão mais leve e nomeie-a para referência em outros estágios.
```
FROM golang:1.23.1-alpine3.20 AS build
```
Adicione o comando go mod download para cachear as dependências e go mod verify para garantir que elas correspondem aos checksums no arquivo go.sum.
```
RUN go mod download && go mod verify
```
Para otimizar o binário para produção, adicione os parâmetros abaixo:
- CGO_ENABLED=0: Desativa o suporte a CGO. CGO é a funcionalidade do Go que permite chamar código em C, mas ao desativá-lo, você obtém um binário completamente estático, sem dependências de bibliotecas externas.
- GOARCH=amd64: Define a arquitetura de destino para a compilação. amd64 é a arquitetura usada em máquinas com processadores de 64 bits, como a maioria dos servidores e desktops modernos.
- GOOS=linux: Define o sistema operacional de destino para a compilação. Aqui está configurado para linux, o que significa que o binário gerado será executável em sistemas Linux.
- go build -o /app/points: Compila o código e salva o binário no caminho especificado (/app/points).
- -a: Força a recompilação de todos os pacotes, incluindo dependências, mesmo que não tenham mudado. Pode ser útil para garantir que tudo seja recompilado com as novas flags e configurações.
- -ldflags="-s -w": Essas são flags de otimização de tamanho.
- -s remove a tabela de símbolos de depuração do binário.
- -w remove as informações de stack tracing (rastreamento de pilha). Essas opções reduzem o tamanho do binário final.
- -installsuffix cgo: Adiciona um sufixo ao diretório de instalação para diferenciar binários com CGO desativado. Isso pode evitar conflitos com binários que usam CGO.
```
RUN CGO_ENABLED=0 GOARCH=amd64 GOOS=linux go build -o /app/points -a -ldflags="-s -w" -installsuffix cgo
```
(opcional) Para deixar a imagem ainda menor podemos comprimir o binário usando upx, O upx (Ultimate Packer for eXecutables) é uma ferramenta que comprime binários executáveis para reduzir o tamanho de arquivos, como binários Go. Os pontos negativos é que vai ter maior tempo de build, e um delay maior no startup do container, então deve ser avaliado o é mais benéfico para sua implantação. Como o objetivo e usar no cloud Run que já possui Cold Start, ele pausa o container quando está sem uso, não vamos utilizar porque vai aumentar o tempo de inicialização do container.
```
RUN apk add --no-cache curl upx
RUN upx --ultra-brute -qq points && upx -t points
```

upx --ultra-brute -qq points: Comprime o binário points de forma agressiva, usando todas as opções de compressão possíveis e sem exibir mensagens de saída.
upx -t points: Testa o binário comprimido para garantir que ele ainda funcione corretamente.
Agora com o binário pronto vamos fazer o segundo estágio, que é copiar o binário para uma imagem limpa.
```
 FROM scratch AS prod
 WORKDIR /app
 COPY --from=build /app/points /
 CMD ["./points"]
```
- scratch é uma imagem base especial no Docker que representa uma imagem completamente vazia, sem qualquer sistema operacional ou dependência. Usar FROM scratch é comum em imagens minimalistas para aplicações Go, onde um binário estático é suficiente.

Arquivo completo

FROM golang:1.23.1-alpine3.20 AS build
WORKDIR /app/
COPY . .
RUN go mod download && go mod verify
RUN CGO_ENABLED=0 GOARCH=amd64 GOOS=linux go build -o /app/points -a -ldflags="-s -w" -installsuffix cgo

## Comprime o binário opcional
RUN apk add --no-cache curl upx 
RUN upx --ultra-brute -qq points && upx -t points

FROM scratch AS prod
WORKDIR /app
COPY --from=build /app/points /
CMD ["./points"]

Comparando builds
A otimização do Dockerfile e o uso do upx resultam em uma imagem até 3 vezes menor.
A análise da imagem original com Trivy mostra 904 CVEs, enquanto a imagem scratch é livre de CVEs.

Imagem	Tipo	Tamanho
points-to-go	Otimizado	14MB
points-to-go	Com upx	5.77MB
points-to-go	original	1.76GB

Repita essas definições para os outros repositórios.

Implantando o banco de dados

No console, acesse SQL no menu lateral.
Ou busque "SQL" na barra de pesquisa e selecione SQL na lista.
Na página do Cloud SQL, clique em Criar Instância e escolha MySQL.
Selecione Enterprise em edição.
Em "Predefinições da edição", escolha Sandbox.
Deixe a versão do banco de dados em MySQL 8.0.
Dê um nome à instância em ID da Instância e defina uma senha.
você consegue especificar as politicas de senha expandindo política de senha
Defina a zona e região, e vamos deixar em uma única zona.
Em personalizar instância podemos ajustar o hardware de acordo com nossas necessidades, as opções vão variar de acordo com a edição que escolhemos.
Ajuste a CPU para 1 e o disco para 10GB conforme necessário.
Em conexões, desmarque IP público e marque IP particular.
Em conexão de acesso privado clique em Configurar Conexão
Selecione use um intervalo alocado automaticamente
Clique em Continuar
Clique em Criar conexão
Clique em Criar Instância e aguarde a criação.
Para conectar à instância, ative o Cloud Shell e execute:
```
gcloud sql connect tmwdb --user=root
```

Coloque a senha atribuída na etapa anterior.
E então você vai receber um erro de conexão, porque o cloud shell não tem acesso a sua VPC privada.
Para simplificar a conexão via Cloud shell, vamos editar a instância e marcar IP público, no apêndice vou mostrar como criar o VPC peering para acessar o DB pelo Cloud Shell
Tente conectar novamente.
Crie o banco de dados da aplicação:
```
CREATE DATABASE points;
```
O Cloud Shell ainda tem um editor de texto baseado no VSCode, é possível fazer algumas atividades direto por ele, ele tem 5GB de volume persistente no seu /home, o hardware é um VM e2-small com 1vCPU e 1.7GB de RAM.

Criando containers no Cloud Run

No console do Google Cloud, acesse o Cloud Run pelo menu lateral ou barra de pesquisa.
Na página do Cloud Run, clique em Implantar Contêiner e escolha a opção Serviço.
Escolhendo o Método de Implantação
Existem três opções para implantar um serviço:
- Usar uma imagem de contêiner de um registry.
- Conectar diretamente a um repositório.
- Criar uma função (utilizando o Cloud Functions, integrado ao Run).
Para este guia, selecione Implantação Contínua com GitHub, permitindo que o Google configure a pipeline de CI/CD automaticamente.
Clique em Configurar com o Cloud Build.
Configurando a Conexão com o GitHub
Clique em Autenticar para permitir a integração do Google com seu GitHub.
Autorize o acesso, escolhendo entre permitir acesso a todos os repositórios ou apenas um específico.
Após concluir o login, clique em Próxima.
Escolhendo Tipo de Build
Na etapa de build, selecione entre usar um Dockerfile ou Aplicações com suporte e Buildpacks do GCP.
Opte por Dockerfile e ajuste o caminho/nome do arquivo, se necessário
Configurações de Serviço
Configure os seguintes parâmetros:
- Autenticação: Selecione Permitir chamadas não autenticadas.
- Alocação de CPU: Escolha A CPU é alocada somente durante o processamento da solicitação.
- Controle de entrada: Selecione Interno.
Ajuste a porta do container, conforme a necessário para a aplicação.
Na aba segurança, em conta de serviço, clique em criar Nova conta de serviço
Adicione as roles
- Administrador de objeto do Storage
- Administrador do Cloud Run
- Assessor de secret do Secret Manager
- Cliente do Cloud SQL
- Conta de serviço do Cloud Build
- Gravador do Artifact Registry
- Usuário da conta de serviço

Analisando o código da aplicação, precisamos passar as variáveis de ambiente para o banco de dados.

// db.go
...
func OpenDBConnection() (*gorm.DB, error) {

godotenv.Load(".env")
    HOST_DB := os.Getenv("HOST_DB")
        PORT_DB := os.Getenv("PORT_DB")
USER_DB := os.Getenv("USER_DB")
PASSWORD_DB := os.Getenv("PASSWORD_DB")

...

Vamos ter que alterar o código da aplicação para o padrão do Cloud Sql que usa Unix sockets, e o Cloud Run não acessa diretamente o DB ele usa o Cloud SQL Auth Proxy.

// db.go
...
        HOST_DB := os.Getenv("HOST_DB")
     //PORT_DB := os.Getenv("PORT_DB")
        USER_DB := os.Getenv("USER_DB")
    PASSWORD_DB := os.Getenv("PASSWORD_DB")

 //log.Println(PORT_DB)
     // UNIX dsn
    dsn := "%s:%s@unix(/cloudsql/%s)/%s?      charset=utf8mb4&parseTime=True&loc=Local"
    //dsn := "%s:%s@tcp(%s:%s)/%s?charset=utf8mb4&parseTime=True&loc=Local"
       dsn = fmt.Sprintf(dsn, USER_DB, PASSWORD_DB, HOST_DB, "points")
 ...

Em contêiner, vamos na aba variáveis e secrets e clicar em adicionar variável.
Adicione as variáveis necessárias.
O endereço do banco segue o padrão, PROJECT_ID:REGION:INSTANCE_NAME, você também pode obter o nome mais abaixo, no item 16.
A senha do banco vamos botar em REFERENCIAR UM SECRET
Se a opção criar novo secret estiver desativado é porque precisa ativar a Api.
Clique em CRIAR NOVO SECRET
Defina o nome da secret e clique em Criar Secret
Em Conexões do Cloud SQL vamos adicionar a URL do banco que criamos
Para criação do schema da da aplicação, no código exige que passemos o argumento migrations=true.
Vamos adicionar migrations=true ao argumento da função, depois removemos na próxima revisão do container.
Deixe os demais campos no padrão e clique em Criar
Testando a aplicação usando Thunder Client.
criando um cliente
lendo os clientes cadastrados

Criando serviço Teomebot

O chatbot não será implantado no Cloud Run, será instalando no Google Compute Engine (GCE). Diferente do Cloud Run, o Compute Engine é ideal porque o chatbot precisa estar ativo continuamente para interagir com o chat.

Além disso, abordaremos o uso de containers, gerenciamento de secrets e a configuração do Cloud Build para automação do deploy.

Criando uma VM no Google Compute Engine (GCE)

Acesse o Compute Engine no menu lateral do Console do GCP.
Clique em Criar Instância.
Insira um nome para a instância (ex.: teomebot-instance).
Configure a região e a zona conforme necessário e anote essas informações para uso posterior.
Em Configuração da máquina, escolha o tipo E2 e, em Predefinição, selecione e2-micro.
Clique na aba Contêiner e clique em Implantar Contêiner.
Use temporariamente a imagem nginx:latest para concluir a configuração inicial.
Adicione as variáveis de ambiente:
- TWITCH_BOT: Nome do bot.
- TWITCH_CHANNEL: Nome do canal da Twitch.
- HOST_DB: IP privado do banco de dados Cloud SQL.
- USER_DB: Usuário do banco.
- PORT_DB: Porta do banco.
- URL_POINTS: Endpoint do serviço Points-to-Go.
Clique em Selecionar
Em Identidade e acesso à API, selecione a conta de serviço configurada para este projeto.
Deixe o restante das configurações no padrão e clique em Criar.

Adicionando Secrets com o Secret Manager

Você deve ter percebido que não passamos as secrets, no compute engine não tem um jeito simples de passar como no cloud run. Minha solução foi adicionar uma função no código da aplicação para ler a informação direto do secret manager.
Acesse o Secret Manager no Console do GCP.
Clique em Criar Secret
Insira um nome descritivo (ex.: twitch-token) e adicione o valor correspondente.
Copie o caminho do secret gerado (ex.: projects/123456/secrets/twitch-token/versions/latest).
1. Crie um novo arquivo utils/gcp.go

Altere o utils/db.go para chamar a função, passando o caminho do secret manager como parâmetro.

func OpenDBConnection() (*gorm.DB, error) {

    PASSWORD_DB := accessSecretVersion("projects/******/secrets/tmwdb-root/versions/latest")

    //godotenv.Load(".env")
    HOST_DB := os.Getenv("HOST_DB")
    PORT_DB := os.Getenv("PORT_DB")
    USER_DB := os.Getenv("USER_DB")
    //PASSWORD_DB := os.Getenv("PASSWORD_DB")
    
    dsn := "%s:%s@tcp(%s:%s)/%s?charset=utf8mb4&parseTime=True&loc=Local"
    dsn = fmt.Sprintf(dsn, USER_DB, PASSWORD_DB, HOST_DB, "teomebot")
    db, err := gorm.Open(mysql.Open(dsn), &gorm.Config{})
    return db, err
}

Altere o main.go para pegar as credencias da Twitch
```
func main() {
```

migration := flag.Bool("migrations", false, "Realizar migrations do banco de dados")

flag.Parse()

godotenv.Load()
user := os.Getenv("TWITCH_BOT")
// alteração
oauth := utils.AccessSecretVersion("projects/551619572964/secrets/twitch-token/versions/latest")

channel := os.Getenv("TWITCH_CHANNEL")
```

Cloud Build

Configurando o Cloud Build

O Cloud Build será usado para automatizar a criação da imagem do container e sua implantação no Compute Engine.

Crie um arquivo cloudbuild.yaml na raiz do repositório com o conteúdo abaixo:

Substitutions

substitutions:
  _VERSION: "v1.0.${COMMIT_SHA}"

A variável _VERSION é definida com um valor que combina v1.0. com o hash do commit atual (${COMMIT_SHA}). Isso cria uma versão única para cada build, garantindo que cada imagem seja identificável pela versão e pelo commit.

Steps
A seção steps define as etapas que o Cloud Build deve executar. Aqui, temos quatro etapas: build, push (duas vezes) e update.

Etapa 1: Build da Imagem Docker

  - name: "gcr.io/cloud-builders/docker"
    args:
      - "build"
      - "--no-cache"
      - "-t"
      - "gcr.io/$PROJECT_ID/teomebot:$_VERSION"
      - "-t"
      - "gcr.io/$PROJECT_ID/teomebot:latest"
      - "."
    id: Build

Esta etapa executa um build da imagem Docker:

"--no-cache": força o build sem utilizar o cache.
"-t": define tags para a imagem criada:
- gcr.io/$PROJECT_ID/teomebot:$_VERSION: imagem com a tag que usa o hash do commit.
- gcr.io/$PROJECT_ID/teomebot:latest: imagem com a tag latest.
".": define o diretório atual como o contexto do build.

A tag id: Build é um identificador opcional para a etapa, útil para referência e depuração.

Etapa 2: Push da Imagem com Tag de Versão

  - name: "gcr.io/cloud-builders/docker"
    args:
      - "push"
      - "gcr.io/$PROJECT_ID/teomebot:$_VERSION"
    id: Push

Essa etapa faz o push da imagem com a tag específica ($_VERSION) para o Google Container Registry, permitindo que a versão gerada no build seja armazenada no repositório.

Etapa 3: Push da Imagem com Tag latest

  - name: "gcr.io/cloud-builders/docker"
    args:
      - "push"
      - "gcr.io/$PROJECT_ID/teomebot:$_VERSION"
    id: Push

Esta etapa faz o push da imagem com a tag latest para o Google Container Registry, atualizando a imagem latest com a versão mais recente.

Etapa 4: Atualização do Container em uma Instância GCE

  - name: "gcr.io/cloud-builders/gcloud"
    args:
      - "compute"
      - "instances"
      - "update-container"
      - "teomebot-instance"
      - "--container-image=gcr.io/$PROJECT_ID/teomebot:latest"
      - "--zone=$_DEPLOY_ZONE"
      - "--container-restart-policy=always"

Essa etapa usa o comando gcloud para atualizar o container em uma instância do Google Compute Engine:

"teomebot-instance": especifica o nome da instância que executa o container.
--container-image: define a imagem do container que a instância deve usar. Aqui, usa a versão latest da imagem.
--zone=$_DEPLOY_ZONE: usa uma variável para especificar a zona de implantação.
--container-restart-policy=always: define a política de reinicialização do container para sempre reiniciar em caso de falha.

Options

options:
  logging: CLOUD_LOGGING_ONLY

A opção logging: CLOUD_LOGGING_ONLY especifica que o Cloud Build deve registrar apenas no Cloud Logging, economizando dados e foco nos logs do GCP.

Arquivo final

substitutions:
  _VERSION: "v1.0.${COMMIT_SHA}"
steps:
  - name: "gcr.io/cloud-builders/docker"
    args:
      - "build"
      - "--no-cache"
      - "-t"
      - "gcr.io/$PROJECT_ID/teomebot:$_VERSION"
      - "-t"
      - "gcr.io/$PROJECT_ID/teomebot:latest"
      - "."
    id: Build
  - name: "gcr.io/cloud-builders/docker"
    args:
      - "push"
      - "gcr.io/$PROJECT_ID/teomebot:$_VERSION"
    id: Push
  - name: "gcr.io/cloud-builders/docker"
    args:
      - "push"
      - "gcr.io/$PROJECT_ID/teomebot:latest"
  - name: "gcr.io/cloud-builders/gcloud"
    args:
      - "compute"
      - "instances"
      - "update-container"
      - "teomebot-instance"
      - "--container-image=gcr.io/$PROJECT_ID/teomebot:latest"
      - "--zone=$_DEPLOY_ZONE"
      - "--container-restart-policy=always"

options:
  logging: CLOUD_LOGGING_ONLY

Criando Gatilho para Criação da Imagem de Container

Configurando a Conta de Serviço

Acesse o Cloud Build no console do Google Cloud.
Vá em Configurações.
Clique em Permissões de Conta de Serviço.
Localize a conta de serviço criada para o Cloud Run.
Ative a opção Definir como conta de serviço preferida
Habilite a função Administrador da Instância do Compute à conta de serviço. Criando o Gatilho
No menu lateral, clique em Gatilhos e depois em Criar Gatilho.
Insira um nome descritivo para o gatilho.
Em Repositórios, clique em Conectar Repositório e selecione o repositório Teomebot.
Em Configuração, selecione a opção Arquivo de Configuração do Cloud Build.
Adicione a variável de substituição _DEPLOY_ZONE com o valor correspondente à zona em que a instância foi criada.
Em conta de serviço verifique a conta selecionada se está conforme configuramos no passo 6.
Clique em Salvar. Executando o Gatilho
Na tela de visão geral, na linha do gatilho recém criado, clique em executar para rodar o processo manualmente.
Nos detalhes do processo, acompanhe os passos do build da imagem para verificar possíveis erros.

Testando a Aplicação

No painel do Compute Engine, copie o comando de ssh para acessar a instancia, ou use o cliente web ssh, e connect a instância.
Conecte-se à instância e execute os comandos abaixo para verificar o estado do container:
```
docker ps
docker container logs <container_id>
```

Resolvendo Problemas de Certificado

Caso ocorra um erro relacionado a certificados (causado pela imagem base scratch), substitua-a pela imagem distroless. No Dockerfile, altere a linha que define a imagem base de:
```
FROM scratch
```

para:

```
FROM gcr.io/distroless/static-debian12
```

Dockerfile atualizado:

```Dockerfile
FROM golang:1.23.1-alpine3.20 AS build
WORKDIR /app
COPY . .
RUN go mod download && go mod verify
RUN CGO_ENABLED=0 GOARCH=amd64 GOOS=linux go build -o /app/tmwbot -a -ldflags="-s -w" -installsuffix cgo

FROM gcr.io/distroless/static-debian12 AS prod
WORKDIR /app
COPY --from=build /app/tmwbot /
ENTRYPOINT ["/tmwbot"]
```

Ajustando Permissões para o Secret Manager

Alterar o escopo da conta de serviço para acessar o Secret Manager.
Acesse o Console do Google Cloud.
No menu lateral, vá para Compute Engine > Instâncias de VM.
Encontre e clique no nome da sua instância de VM.
Na página de detalhes da VM, clique em Parar para desligar a instância (essa etapa é necessária, pois o escopo de conta de serviço só pode ser modificado com a instância parada).
Depois que a instância for interrompida, clique em Editar na parte superior da página.
Role até a seção Identidade e API de acesso.
Em Conta de Serviço, selecione a conta de serviço que sua aplicação usa.
Em Escopos de acesso da API, selecione Permitir acesso total a todas as APIs do Cloud ou clique em Definir escopos específicos de acesso da API e adicione o escopo https://www.googleapis.com/auth/cloud-platform.
Após ajustar o escopo, clique em Salvar para aplicar as mudanças.
Reinicie a instância clicando em Iniciar.

Ou pela linha de comando, parando a instância, rodando o comando e iniciando depois.

 gcloud compute instances set-service-account teomebot-instance --scopes=https://www.googleapis.com/auth/cloud-platform --zone "us-central1-a"

Adicionando mais containers

Os demais serviços seguem o mesmo processo do points-to-go, para os serviços que comunicam entre si crie variáveis de ambiente para configurar o endereço dos endpoints, que serão sempre https porta 443.

Para comunicação com outros serviços ajustei o código para receber mais uma variável de ambiente com a url do serviço, no points por exemplo ficou assim:

```go
...
var URL_POINTS = os.Getenv("URL_POINTS")
...

url := fmt.Sprintf("https://%s/customers/", URL_POINTS)

...
```

Testanto o bot

Testando a comunicação do bot com a Twitch.

Ajuste de Segurança na Rede
Após finalizar os testes, coloque os container para ser acessados somente internamente na VPC.

Conclusão

Com isso finalizamos a migração do sistema do TeoMeWhy, o guia serve de base para migrar os outros serviços do TeoMeWhy.

Os principais objetivos alcançados foram:

Realizações Técnicas

Migração de aplicações conteinerizadas para o Cloud Run, permitindo escalabilidade automática e redução de custos
Otimização de imagens Docker através de multi-stage builds, reduzindo significativamente o tamanho das imagens e vulnerabilidades
Implementação de banco de dados gerenciado com Cloud SQL, garantindo alta disponibilidade e segurança
Configuração de CI/CD automatizado usando Cloud Build, possibilitando deploys automáticos a partir do GitHub
Gestão segura de credenciais utilizando Secret Manager

Melhorias na Arquitetura

Separação clara de responsabilidades entre serviços
Utilização de conexões privadas para maior segurança
Implementação de padrões serverless para otimização de custos
Automação de processos de build e deploy
Integração contínua com repositórios do GitHub

Benefícios Obtidos

Custos: Redução de custos através do modelo serverless e otimização de recursos
Manutenibilidade: Facilidade de manutenção com deploys automatizados
Segurança: Gestão apropriada de secrets e conexões privadas
Escalabilidade: Capacidade de escalar automaticamente conforme a demanda
Monitoramento: Melhor visibilidade da infraestrutura através das ferramentas nativas da GCP

Apêndice

Habilitar a API do Secret Manager

No console do Google Cloud, pesquise por Secret Manager API.
Clique na API nos resultados da pesquisa.
Na tela de detalhes, clique em Ativar.

Referências

AWS ECS Básico

Cristiano Lemes — Mon, 11 Nov 2024 22:19:46 +0000

Introduc¸a˜o\large\texttt{Introdução}

Neste guia vamos abordar a criação de um cluster ECS (Elastic Container Service) no AWS Fargate.

Imagem documentação ECS

Fundamentais\large\texttt{Conceitos Fundamentais}

O que é ECS

O ECS (Elastic Container Service) é um serviço de orquestração de containers da AWS que traz uma forma mais simples que o Kubernetes de gerenciar containers, sendo mais simples, porém menos flexível, já que usa uma tecnologia proprietária da AWS e não permite customizações avançadas. Ele permite executar, parar e gerenciar contêineres em um cluster de instâncias EC2, no AWS Fargate (serverless) ou on-premises usando ECS Anywhere.
Recursos:

Gerenciamento simplificado comparado ao Kubernetes
Integração nativa com serviços AWS
Menor curva de aprendizado
Flexibilidade de deployment (EC2, Fargate, on-premises)

Diferenças entre ECS e Kubernetes

Característica	ECS	Kubernetes
Complexidade	Menor	Maior
Flexibilidade	Limitada	Alta
Vendor Lock-in	Sim	Não
Integração AWS	Nativa	Via plugins
Curva de aprendizado	Suave	Média

Componentes do ECS

Task Definition: Contém as definições de como o container deve ser executado, similar a um Deployment no Kubernetes. Define recursos como:

Imagem do container
Recursos de CPU e memória
Variáveis de ambiente
Mapeamento de portas
Volumes
Configurações de rede

Exemplo de uma Task definition:

{
  "family": "app-task",
  "containerDefinitions": [
    {
      "name": "web",
      "image": "nginx:latest",
      "cpu": 256,
      "memory": 512,
      "essential": true,
      "portMappings": [
        {
          "containerPort": 80,
          "hostPort": 80,
          "protocol": "tcp"
        }
      ]
    }
  ],
  "requiresCompatibilities": ["FARGATE"],
  "networkMode": "awsvpc",
  "cpu": "256",
  "memory": "512"
}

Task: É uma instância em execução de uma Task Definition, sendo a menor unidade do ECS, equivalente a um Pod no Kubernetes. Uma task pode conter um ou mais containers que trabalham juntos.
Service: Garante que um número específico de tasks esteja sempre rodando, similar ao ReplicaSet e DaemonSets do Kubernetes. O service oferece:
- Auto-healing (reinicia containers que falharam)
- Balanceamento de carga
- Escalabilidade
- Rolling updates

Launch Types

EC2 Launch Type
No modelo EC2, você define:

Tipo de instância EC2
Capacidade máxima do cluster
Auto Scaling Groups
Políticas de escalabilidade

O ECS gerencia:

Alocação dos containers no cluster
Processos de inicialização e parada
Monitoramento de saúde
Distribuição de carga entre instâncias

Ideal para:

Cargas de trabalho previsíveis
Necessidade de controle granular sobre a infraestrutura
Otimização de custos para cargas constantes

Fargate Launch Type
No modelo Fargate, você:

Define apenas os recursos necessários (CPU/RAM)
Especifica limites de scaling
Não gerencia infraestrutura

AWS gerencia:

Provisionamento de recursos
Escalabilidade
Patches e manutenção
Alta disponibilidade

Ideal para:

Cargas variáveis
Aplicações que precisam escalar rapidamente
Redução de overhead operacional
Ambientes de desenvolvimento e teste

ECS Anywhere Launch Type
Usando o ECS Anywhere, você pode:

Gerenciar containers em ambiente híbrido
Usar hardware on-premises
Manter conformidade com requisitos de residência de dados
Executar cargas de trabalho em edge locations

Casos de uso:

Aplicações que precisam rodar próximas aos usuários
Workloads com requisitos específicos de hardware
Ambientes regulados que exigem controle total sobre a infraestrutura
Migração gradual para nuvem

Volumes persistentes

Caso seu contêiner precise de montar um volume persistente, você pode montar volumes o EFS (Elastic File System), que é um sistema de arquivos NFS disponível na AWS, o armazenamento pode ser compartilhado pelos contêineres e fica disponível em múltiplas zonas de disponibilidades (AZ) dentro da mesma região.
EFS (Elastic File System)

Sistema de arquivos NFS gerenciado pela AWS
Escalável automaticamente
Disponível em múltiplas AZs
Ideal para compartilhamento de dados entre containers Montagem de volume EFS

{
  "volumes": [
    {
      "name": "efs-volume",
      "efsVolumeConfiguration": {
        "fileSystemId": "fs-1234",
        "rootDirectory": "/",
        "transitEncryption": "ENABLED",
        "authorizationConfig": {
          "accessPointId": "fsap-1234",
          "iam": "ENABLED"
        }
      }
    }
  ]
}

Segurança e IAM

Task Role
O Task Role define as permissões que os containers dentro da task têm para acessar outros serviços AWS. Por exemplo:

Acesso ao S3 para armazenamento de arquivos
Acesso ao DynamoDB para persistência
Acesso ao SQS/SNS para mensageria
Acesso ao Secrets Manager para segredos

Exemplo de política IAM para Task Role:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject"
      ],
      "Resource": "arn:aws:s3:::my-bucket/*"
    }
  ]
}

Task Execution Role
O Task Execution Role é usado pelo serviço ECS para:

Pull de imagens do ECR
Envio de logs para o CloudWatch
Recuperação de segredos do Secrets Manager/Parameter Store

console\large\texttt{Criando um cluster ECS usando a console}

Não vamos abordar criação de VPCs e security groups, vamos usar o padrão.

No console de gerenciamento do ECS, clique no botão Create cluster.

Especifique o nome para o cluster em Cluster Name

Em Infrasctructure deixe marcado somente AWS Fargate
Você pode deixar marcado Amazon EC2 instance, você deixando o Desired capacity em 0, ele somente vai alocar uma EC2 quando você criar uma Task definition escolhendo o EC2 como launch type.

Clique em Create Agora nosso cluster ECS está criado. Clicando no nome do cluster vai abrir a visão geral do cluster, a unica guia que vai ter informação é infrastructure, com os capacity providers do Fargate, conforme selecionamos.

Criando uma Task Definition

A task definition cria as definições da task, como um manifesto do kubernetes, para depois usarmos para fazer a implantação do Service.

No menu lateral vamos em task definition, clique no botão Create Task definition.

Defina um nome para usar task definition
Em Launch Type deixe marcado Fargate
Em Operating System/Architecture usaremos Linux x86_64, mas também pode usar Arm e Windows.
Em Task size defina os recursos necessários para aplicação.
Task Role, não vamos usar, mas é usado para dar acesso ao container à outros serviços aws, como uma conta de serviço.
Taks execution Role, deixe o padrão, se a rote não existir ele vai criar automaticamente uma com as permissões adequadas.

Em Container colocamos os dados do container, no caso vamos usar a imagem do nginx.

Agora vamos criar um service.

Voltando em Cluster, clicando no cluster que criamos, em services, clique no botão Create.

Em Compute options podemos deixar em Capacity provider strategy para AWS definir automaticamente qual capacity provider usar, como temos só Fargate não faz diferença, marcando Launch Type, e em Launch Type você consegue selecitionar o tipo de launch type caso tenha mais de um disponível no cluster.

Em Deployment Configuration, Aplication type escolha Service. A opção task é para usar em jobs que executam a partir de um agendamento ou manualmente e depois param.
Em Family escolha a Task Definition criada anteriormente.
Em Service name coloque um nome para o serviço.

Em Deployment option vamos deixar em Rolling update, que funciona como Rolling update do kubernetes, ele vai atualizar um container sempre mantendo uma quantidade ativa, de acordo com o percentual estipulado, para não ter queda no serviço.
Em replica, você define a quantidade de containers do mesmo serviço que vai ser implatando.
Em Networking escolha a VPC, e as subnets, lembrando que o ECS é MultiAZ então você pode escolher uma subnet de cada AZ. Você pode deixar

Em security group, vamos criar um novo security group, e liberar o acesso http ao container.
Public IP, deixe ativo
Não é obrigatório usar Load Balancer, você pode expor um único container. Para ter alta disponibilidade, usar autoscaling, ter SSL/TTL gerenciados, você vai precisar de um Load Balancer.

O Progresso da criação pode ser visto clicando em view cloudformation

Tarefa finaliza em services

Em Tasks, clicando na task que criamos, podemos ver todos os detalhes, como ip externo.

Detalhes da task.

Conclusa˜o\large\texttt{Conclusão}

O ECS oferece uma forma simplificada de executar containers na AWS, com forte integração com outros serviços AWS. Seguindo este guia e as melhores práticas, você pode criar uma infraestrutura resiliente e escalável para suas aplicações conteinerizadas.

Também criei um as definições do terraform para criar esse ambiente, acesse no link abaixo.

Adicionais\large\texttt{Recursos Adicionais}

Aprendendo AWS

Cristiano Lemes — Tue, 23 Jul 2024 19:48:26 +0000

Introdução

Neste artigo, vamos explorar os conceitos básicos da AWS na prática, utilizando um cenário de instalação de um blog usando Ghost.
Vamos utilizar uma variedade de serviços da AWS, incluindo:

Criando a Infraestrutura na AWS

1. Criando usuários usando o IAM

Vamos pular a parte de criar a conta na AWS, para não ficar tão longo, já que o processo é simples, qualquer dúvida, pode olhar na documentação oficial
Vamos criar um usuário no Aws Console, não é recomendado usar a conta root para tarefas guarde ela para caso haja algum problemas nas contas Admin e precise recupera-las.

1.1. Regras básicas sobre usuários, grupos e politicas.

As permissões na AWS são definidas por politicas
Há politicas pré definidas com diferentes tipos de acesso nos serviços da AWS, como leitura, escrita e acesso total.
Uma política pode ser aplicada a um Grupo ou diretamente a um usuário(para facilitar a gestão melhor aplicar sempre a grupos)
Um grupo pode receber N politicas
Um usuário pode participar de N grupos
Um grupo não pode ser membro de outro grupo
Quando um usuário pertence a mais de um grupo, as politicas aplicadas aos grupos que ele pertence são somadas.

*Relação entre grupos, políticas e usuários

1.2. Criando um Grupo e definindo permissões

Vá até Página inicial do console
Na barra de pequisa digite IAM
Em services, IAM, marque a estrela se quiser deixar nos favoritos.
Click em User Groups
Click em Create Group
Escolha um nome para o grupo, esse nome é exclusivo somente na sua organização.
Marque a política padrão, Administrator Access. Há várias predefinições de políticas, e você também pode criar novas, o recomendado é ser mais específico possível e habilitar somente o recurso que cada time precisa para efetuar o seu trabalho, no caso vamos escolher administradores, para seguir esse tutorial.
Click em Create group

1.3. Criando o usuário e adicionando ao grupo criado

Estando em IAM, click em Users
Click em Create User
Em **User details*, escreva o nome de usuário, ele é exclusivo somente dentro da organização. Não é recomendado o uso de usuários genéricos, então crie um usuário para cada pessoa do time.
Marque Provide user access to the AWS Management Console
Escolha I want to create an IAM user.
Click em Next
Em User groups escolha o grupo que acabamos de criar, no caso AWS-Admins
Click em Next
Click em Create User
Conta de Usuário criado com êxito, na tela de criação podemos obter a senha do usuário, que deixamos em criar automaticamente, e o login direto para a console.
Efetue logoff com da conta root e logue com o usuário IAM criado.

2. Configurando o Budget na AWS

Importante saber que na AWS não conseguimos travar os gastos com os serviços, uma maneira de controlar os gastos é criando budgets, com os budgets podemos definir um valor e receber alertas quando ele for atingido.

2.1. Criando um Orçamento custo zero.

Vá até a Página inicial do Aws console
Escreva billing na barra de pesquisa
Click em Billing and Cost Management
Marque a estrela para deixar nos favoritos (opcional)
Click em Budgets
Click em Create a Budget
Escolha Use a template (simplified)
Escolha My Zero-Spend Budget
Digite o email para onde serão envidas as notificações.
Click em Create budget
Seu orçamento My Zero-Spend Budget foi criado.

2.2. Criando um orçamento mensal estipulando um valor

Estando em Billing and Cost Management
Click em Budgets
Click em Create Budget
Escolha Use a template (simplified)
Escolha Monthly cost budget
Vou colocar 5 doláres
Digite o email para onde serão enviadas as notificações
Click em Create budget
Seu orçamento My Monthly Cost Budget foi criado.

2.3. Analisando Custos

Em explorador de custos você tem um relatório com os gastos, com opção de vários filtros, como intervalo de datas e nome de serviços entre outros, se você usou algum serviço Free Tier, você pode visualizar o quanto usou dele em nível gratuito.

3. Criando a infraestrutura de redes

O primeiro item de infraestrutura que vamos criar é a rede, você pode criar outros itens não tendo a rede criada, mas nesse caso a AWS vai criar automaticamente uma rede padrão para este serviço.
Vamos criar duas subnets uma vai ter ip público, vai poder ser e outra vai ter apenas ips privados.
Nossa infra não será muito grande, por isso vamos uma VPC /22 vai ser suficiente.

Os 3 Primeiros ips de cada subrede são reservados pela AWS, o primeiro ip é para o VPC Router (Gateway), o segundo é o DNS da Amazon, o terceiro está reservado para uso futuro.
Lembrando que o primeiro ip da Subnet é o id de rede, é o ultimo é o ip de Broadcast, que também não podem serem usados.

3.1 Overview serviços da VPC

VPC: Significa Virtual Private Cloud, permite que você crie uma rede virtual, permitindo isolamento entre recursos.
Subnet: É uma subdivisão do intervalo de ip da VPC, serve para organizar, criar rotas, regras de segurança, permitindo uma gerencia do tráfego na VPC.
RouteTable: É uma tabela de roteamento, que por padrão já adiciona automaticamente todas rotas da VPC, você vai adicionar manualmente rota para fora da vpc, como outras vpcs, serviços da Aws como s3 e rds, e rotas para internet.
Nat Gateway: É um roteador que não está voltado para internet, não fornecendo ip publico para as instancias, ele é totalmente gerenciado pela AWS, possuindo alta disponibilidade, escalabilidade e segurança nativos.
Internet Gateway: É um roteador que fornecesse acesso a internet, tanto atribuindo um ip público diretamente a instância, como fornecendo internet atraves de NAT pelo Nat gateway.
Security Groups: Age como firewall, permitindo que você controle o tráfego de redes com base de regras, é atribuído a nivel de instância, configurando regras baseado em endereços IP de origem ou destino, portas e protocolos, como TCP, HTTP. Uma importante saber, é que as regras são statefull, significa que ele salva o estado das conexões, portanto quando você crie uma regra, as repostas de saídas já são liberadas automaticamente.
NACL: Siginifica Network Access Control List, ele adiciona mais uma camada de segurança, ele é associado a subrede, quer dizer, as regras são aplicadas a todas as instancias dentro da mesma subrede por padrão já vem com tudo liberado, do mesmo modo que security group você pode criar regras com ips, portas e protocolos de origem, mas você pode tanto permitir quando negar um acesso, e seguem a ordem que você estabelece numericamente, parando de processar quando tem o match. Importante saber que ele é stateless, não salva o estado das conexões, quer dizer, quando criar uma regra de entrada tem que criar também a regra de saída.
VPC Endpoints: VPC Endpoints fornecem conexões diretas a serviços gerenciados pela AWS, como S3, DynamoDB e SNS, sem a necessidade de roteamento pela Internet pública. Eles garantem uma comunicação segura e eficiente entre a VPC e esses serviços, contribuindo para uma arquitetura mais robusta e segura na nuvem.

3.2. Criando uma VPC

Vá até a Página inicial do Aws console
Escreva vpc na barra de pesquisa
Click em VPC
Marque a estrela para deixar nos favoritos (opcional)
Click em Create VPC
Marque VPC only
Em Name tag, coloque o nome da rede vpc-01
Deixe marcado IPv4 CIDR block
Em IPv4 CIDR4 coloque 10.1.0.0/22
Deixe marcado No IPv6 CIDR block
Click em Create VPC

3.3. Criando Subnets

Vamos criar duas subnets na AZ a, uma pública e outra privada.

Estando em VPC
Click em Subnets
Em VPC ID escolha a VPC que acabamos de criar
Em Subnet settings click em Add New Subnet, 2 vezes.
Primeira subnet
- Subnet name: PublicSubnetA
- Availability Zone: sa-east-1a
- IPv4 subnet CIDR block: 10.1.0.0/24
Segunda subnet
- Subnet name: PrivateSubnetA
- Availability Zone: sa-east-1a
- IPv4 subnet CIDR block: 10.1.1.0/24

3.4. Configurando a subnet pública

3.4.1. Habilitando Subnet para receber ips públicos por padrão

Estando em VPC
Click em Subnets
Na lista de subnets , click com botão direito em PublicSubnetA, escolha edit subnet settings
Em Auto-assign IP settings, marque a opção Enable auto-assign public IPv4 address
Click em save

3.4.2. Criando um internet gateway

Estando em VPC
Click em Internet gateways
Click no botão Create internet gateways
Em Name tag, vamos colocar IGW01
Click em Create internet gateway

3.4.3. Anexando o internet gateway a VPC

Estando em VPC
Em Internet gateways
Na lista de Internet gateways , click com botão direito em IGW01, escolha attach to VPC
Em available VPCs, click em Attach internet gateway

3.4.4 Criando a tabela de roteamento

Estando em VPC
Vá em Rote Tables
Click no botão Create route table
Em name vamos colocar, PublicRouteTable
Em VPC, vamos selecionar vpc-01
Click em Create route table

3.4.5. Criando rota padrão na subnet pública

Estando em VPC
Vá em Rote Tables
Selecione a rota PublicRouteTable
Click em Actions e em Edit Routes
Note que já existe uma rota padrão para VPC local
Em edit routes, click em Add route
Ele vai criar uma entrada Route 2
Em destination coloque 0.0.0.0/0¹
Em target, selecion Internet Gateway
Selecione o IGW01
Click em Save changes

A rota 0.0.0.0/0 vai encaminhar toda rota que não estiver definida explicitamente para o internet gateway.

3.4.6. Associando a route table a subnet pública

Estando em VPC
Vá em Rote Tables
Selecione a rota PublicRouteTable
Click em Actions e em Edit subnet associations
Em Available subnets
Marque PublicSubnetA
Click em Save associations

3.5 Configurando a subnet privada

3.5.1. Criando um NAT gateway

Estando em VPC
Click em NAT gateways
Click no botão Create NAT gateways
Em Name tag, vamos colocar NATGW01
Em subnet vamos escolher PublicSubnetA¹
Connectivity type Public
Em Elastic IP allocation ID, click Allocate Elastic IP²
Click em create NAT gateway

O NATGateway não pode estar na mesma subnet que será usado, e ele precisa de um internet gateway para sair para internet, por isso estamos colocando na PublicSubnetA para ser usado pela PrivateSubnetA.
O Elastic IP é um ip publico que vai ficar reservado a sua conta, ele não é apagado quando deletamos o objeto que ele está associado, ex: se apagar o NAT gateway, o elastic ip vai continuar existindo, só será desalocado e poderá ser usado por outra instância.
O NAT Gateway é cobrado por hora, mesmo não sendo usado.

3.5.2. Criando a route table privada

Estando em VPC
Vá em Rote Tables
Click no botão Create route table
Em name vamos colocar, PrivateRouteTable
Em VPC, vamos selecionar vpc-01
Click em Create route table

3.5.3. Criando rota padrão na subnet privada

Estando em VPC
Vá em Rote Tables
Selecione a rota PrivateRouteTable
Click em Actions e em Edit Routes
Em edit routes, click em Add route
Ele vai criar uma entrada Route 2
Em destination coloque 0.0.0.0/0
Em target, selecione NAT Gateway
Selecione o NATGW01
Click em Save changes

3.5.4. Associando a route table a subnet privada

Estando em VPC
Vá em Rote Tables
Selecione a rota PrivateRouteTable
Click em Actions e em Edit subnet associations
Em Available subnets
Marque PrivateSubnetA
Click em Save associations

4. Criando um Security Group

Vá até a Página inicial do Aws console
Escreva vpc na barra de pesquisa
Click em VPC
No menu lateral navegue até Security
Em Security click em Security groups
Click no botão Create security group
Vamos chamar de WebServers
Em Description, vamos colocar, Allows ssh and https access
Em VPC escolha a vpc-01
Em Inbound rules click em Add rule
Em Type escolha http
Em Source escolha Anywhere IPv4
Vamos adicionar mais duas regras
Click em Add rule
Em Type escolha https
Em Source escolha Anywhere IPv4
Click em Add rule
Em type escolha ssh
Em Source escolha Anywhere IPv4¹
Click em Create security group

Em source, por segurança, você pode escolher a opção My IP, ele vai pegar seu ip atual de internet, mas lembre que normalmente você recebe ip dinâmico em internets domesticas, deste modo, se você perdeu o acesso, vale verificar se seu ip mudou.

5. Criando uma VMs usando EC2

5.1. Criando um Bastion Host
Como a máquina de produção não estará de frente para internet, vamos criar uma vm na internet publica e a partir dela acessar a maquina que estará na rede privada.

Vá até a Página inicial do Aws console
Escreva EC2 na barra de pesquisa
Click em EC2
Marque a estrela para deixar nos favoritos (opcional)
No menu lateral click em Instances
Em Instances, click em Launch instances
Em Name and Tags, vamos colocar Bastion
Em Application and OS images, escolha Amazon Linux 2023
Em Instance type, escolha t2.micro
Em key pair, click em Create new key pair
Vamos colocar o nome de bastionkey, manter as opções RSA e .pem.¹
Ele vai baixar o .pem automaticamente para sua máquina, certifique-se de colocar em um local acessível para usarmos no futuro.
Em Network settings, vamos clicar em Edit
Em VPC, escolha a vpc01
Em Subnet, escolha PublicSubnetA
Auto-assign public IP, mantenha Enabled
Em Firewall Security Group, escolha WebServers.
As demais opções, mantenha no padrão
Click no botão, Launch intance.

Se você usa Windows anterior a Windows 10, vai ter que gerar uma chave .ppk, para ser usada no aplicativo Putty.

5.2. Criando o servidor Ghost

Estando em EC2
No menu lateral click em Instances
Em Instances, click em Launch instances
Em Name and Tags, vamos colocar GhostServer
Em Application and OS images, escolha Ubuntu 22.04 LTS
Em Instance type, escolha t2.micro
Em key pair, click em Create new key pair
Vamos colocar o nome de ghostkey, manter as opções RSA e .pem.
Em Network settings, vamos clicar em Edit
Em VPC, escolha a vpc01
Em Subnet, escolha PrivateSubnetA
Auto-assign public IP, mantenha Disable
Em Firewall Security Group, escolha WebServers.
As demais opções, mantenha no padrão
Click no botão, Launch intance.

5.3. Instalando os requisitos para aplicação

5.3.1. Conectando à instancia usando EC2 Instance Connect

Em instances, selecione a instância, Bastion
Em Actions click em Connect
Em Connect to Instance
Selecione a aba EC2 Instance Connect
Em connection type, certifique-se que está Connect use EC2 Instance Connect
Click no botão **Connect
Ele vai abrir um nova via conectada ao shell do servidor

5.3.2. Conectando ao servidor usando o cliente de ssh

Em Instances, selecione a instância, Bastion
Em Actions click em Connect
Em Connect to Instance
Selecione a Aba SSH client
Certifique-se que seu arquivo pem está de acordo com as instruções
Copie o comando em example de conexão de ssh
Abra seu terminal e execute o comando de conexão
Exemplo:

ssh -i "bastionkey.pem" ec2-user@54.207.206.108

5.3.3. Instalação dos pré-requisitos

Em Instances, selecione GhostServer
Vá até a aba Networking
Em private IPv4 Address, copie o ip.
Abra o arquivo bastionkey.pem eu seu computador, usando um editor de texto
Copie todo conteúdo do arquivo
Conecte-se ao host Bastion
Crie um arquivo novo chamado bastionkey.pem e cole o conteúdo copiado.
Salve o arquivo e rode um chmod 400 para ajustar as permissões
Conecte-se via ssh ao servidor GhostServer a partir do bastion
Exemplo:

ssh -i "bastionkey.pem" ubuntu@10.1.1.156

5.3.4. Instalando os pré-requisitos para o Ghost

Estando conectado ao GhostServer, siga os passos:
Crie o usuário para rodar a aplicação.

sudo adduser ghostuser

Ele vai pedir a senha, coloque uma senha forte.
Adicione o usuario ao grupo sudoers.

usermod -aG sudo ghostuser

Faça login com o usuário ghostuser

sudo su - ghostuser

Atualize o sistema

# Atualiza lista de pacotes
sudo apt-get update

# Atualiza os pacotes intalados
sudo apt-get upgrade

Instale o Ngnix

sudo apt-get install nginx

Configure o firewall do ubuntu para liberar as portas do Ngnix

sudo ufw allow 'Nginx Full'

Instale o Node.js

# Baixando e atualizando as chave GPG
sudo apt-get update
sudo apt-get install -y ca-certificates curl gnupg
sudo mkdir -p /etc/apt/keyrings
curl -fsSL https://deb.nodesource.com/gpgkey/nodesource-repo.gpg.key | sudo gpg --dearmor -o /etc/apt/keyrings/nodesource.gpg

# Adicione a fonte a lista de repositorios
NODE_MAJOR=18 # Verão mais nova suportada pela aplicação
echo "deb [signed-by=/etc/apt/keyrings/nodesource.gpg] https://deb.nodesource.com/node_$NODE_MAJOR.x nodistro main" | sudo tee /etc/apt/sources.list.d/nodesource.list

# Atualize a lista de pacotes, e instale o nodejs
sudo apt-get update
sudo apt-get install nodejs -y

Instale o Ghost Cli

sudo npm install ghost-cli@latest -g

***6. Criando um Application LoadBalancer

6.1 Criando Target Groups

Estando em EC2
No menu lateral, na seção Load Balancing click em Target Groups
Click no botão Create taget group
Em Basic Configuration
Em Choose a target type marque Instances
Em Target group name, coloque GhostServers
Em Protocol: Port selecione HTTP
Em IP address type selecione IPv4
Em VPC selecione vpc-01
Matenha as demais opções padrão e click em Next
Em Register targets
Em Available instancess selecione GhostServer
Click no botão Include as pending below
Click em Create target group

6.2 Criando o Application Load Balancer

É mandatório para ter duas subnets associadas ao Load Balancers, crie uma nova subnet publica, chamada PublicSubnetB, com endereço 10.1.2.0/24, seguindo os passos da seção 3.3 deste artigo, mas na Az escolha sa-east-1b. Associe a PublicRouteTable a esta subnet.

Estando em EC2
No menu lateral, na seção Load Balancing click em Load Balancers
Em Load balancers, click em Create load balancer
Escolha Application Load Balancers, click em Create
Em base Configuration, coloque o nome Ghost-nlb
Em Scheme marque Internet facing
Em IP Address Type deixe marcado IPv4
Em Network mapping, selecione a vpc-01
Marque sa-east-1a (sae1-az1) e sa-east-1b (sae1-az2)
Em Security Group selecione WebServers
Em listener, matenha o protocolo HTTP
Em Default action, em Forward to, selecione GhostServers
Click em Create load Balancer

7. Criando um o banco de dados usando RDS

Vá até a Página inicial do Aws console
Escreva RDS na barra de pesquisa
Click em RDS
No menu lateral, click em Databases
Click em Create database
Em Choose a database creation method
Escolha Standard create
Em Engine options, Engine type, Escolha MySQL
Em Engine Version, certifique-se de selecionar a versão 8
Em Templates escolha Free tier
Em Settings, DB instance identifier, coloque GhostDB
Pode manter o Master como admin
Em Credentials Management, escolha Self managed
Coloque uma senha, e anote.
Deixe as configurações de Storage padrão
Em Connectivity, marque Don't connect to an EC2 compute resource
Em Virtual private cloud escolha a vpc-01
Em DB subnet group escolha, Create new DB Subnet Group
Em Public access marque No
Em VPC security group marque Create new
Em VPC security group name, coloque sg-ghostdb
Em Availability Zone escolha sa-east-1a
Deixe as demais opções no padrão e click em Create database

8. Instalando a Aplicação (Ghost)

8.1 Obtendo Informações dos passos anteriores

Em Load balancers, selecione Ghost-nlb
Em Details copie o DNS
Ex: Ghost-nlb-2094178475.sa-east-1.elb.amazonaws.com
Em RDS, Databases, click em ghostdb
Em Connectivity & security, copie o endereço do Endpoint
Ex: ghostdb.c34m8468ic7f.sa-east-1.rds.amazonaws.com
Tenha em mão o usuario e senha do banco de dados.

8.2 Instalando o Ghost

Crie o diretório para a página do ghost, altere o owner e ajuste as permissões

sudo mkdir -p /var/www/ghostweb
sudo chown ghostuser:ghostuser /var/www/ghostweb
sudo chown ghostuser:ghostuser /var/www/ghostweb

Troque para o usuario ghostuser

sudo su - ghostuser

Entre na pasta e execute a instalação

cd /var/www/ghostweb

Execute o instalador

ghost install

Após checar o requisitos e baixar componentes, o instalador vai solicitar as informações do ambiente, favos informar conforme coletamos anteriormente.
1. Enter your blog URL: http://ghost-nlb-2094178475.sa-east-1.elb.amazonaws.com
2. Enter your MySQL hostname: ghostdb.c34m8468ic7f.sa-east-1.rds.amazonaws.com
3. Enter your MySQL username: admin
4. Enter your MySQL password: [hidden]
5. Enter your Ghost database name: ghostdb
6. Do you wish to set up Nginx? Yes
7. Do you wish to set up Systemd? Yes
8. Do you want to start Ghost? Yes

O ngnix retornou erro nginx: [emerg] could not build server_names_hash, you should increase server_names_hash_bucket_size: 64
nginx: configuration file /etc/nginx/nginx.conf test failed A solução foi ajustar o parametro server_names_hash_bucket_size 128 no /etc/ngnix/ngnix.conf e reiniciar o ngnix.

9. Teste na Aplicação

Acessando a url do blog

Acessando a url admin.

10. Considerações finais.

Neste artigo, aprendemos a configurar e implantar um ambiente de hospedagem web utilizando o Ghost CMS, além de utilizar serviços da AWS como EC2, RDS, Load Balancer e Elastic IP. Inicialmente, criamos recursos na AWS como VPC, Subnets, Security Groups e Public Route Table. Em seguida, provisionamos as instâncias EC2 para o banco de dados (RDS) e os servidores web (Ghost). Ao implantar a aplicação Ghost, configuramos um balanceador de carga para distribuir o tráfego entre os servidores web. Após concluída a instalação e configuração das dependências, tivemos sucesso ao acessar o blog utilizando a URL fornecida pelo load balancer e também através do painel administrativo.

Usando Cilium no WSL

Cristiano Lemes — Wed, 12 Jun 2024 15:54:44 +0000

Criando um ambiente de teste do Cilium no WSL

eBPF a base do Cilium

O eBPF é umas das tecnologias mais faladas nos últimos tempos na comunidade de tecnologia,

isso graças sua capacidade de estender as funções do kernel sem precisar alterar código do kernel ou carregar modulos. Com eBPF você escreve programas em C ou Rust que são compilados em bytecode.

Guia Ilustrado do eBPF

Afinal, o que é Cilium?

Cilium é um software de código aberto que aproveita das funcionalidades do eBPF para entregar ao kubernetes soluções para Ingress, gateways api, service mesh, segurança e observabilidade entre outras. Ele consegue atuar de forma transparente sem uso de container sidecar como Envoy.

Documentação Cilium

"eBPF é uma tecnologia de kernel revolucionária que permite aos desenvolvedores escrever
código que pode ser carregado no kernel dinamicamente, mudando a maneira como o kernel
se comporta.
Isso permite uma nova geração de redes de alto desempenho, observabilidade e
ferramentas de segurança. E como você verá, se quiser instrumentar um aplicativo com essas ferramentas baseadas em eBPF, você não precisa modificar ou reconfigurar o aplicativo de qualquer forma, graças ao ponto de vista do eBPF dentro do kernel."
Liz Rice, no seu livro gratuíto Learning eBPF

A isovalent também contem vários labs gratuitos para aprender usar o Cilium e outras ferramentas da Isovalent, como o hubble, e ainda você ganha badges do Creddly 😍.

Compilando um novo Kernel para o WSL

Para conseguir carregar os módulos necessários vamos precisar compilar um kernel já com as funcionalidades necessárias ativas, o WSL padrão vem com o kernel 5.15, mas já que vamos precisar recompilar tudo, vamos colocar logo um mais novo, vamos baixar o kernel 6.8, que é a versão padrão do Ubuntu 24.04, também alguma features do Cilium somente estão disponíveis em versões mais novas do kernel como pode ver na tabela abaixo.

Meu ambiente
Sistema operacional: Windows 11 23H2
Distro WSL: Ubuntu 24.04 LTS
Versão do WSL: 2.1.5.0
Docker Desktop: 4.30
Gerenciador de pacotes: Scoop

Cilium Feature	Minimum Kernel Version
Bandwidth Manager	>= 5.1
Egress Gateway	>= 5.2
VXLAN Tunnel Endpoint (VTEP) Integration	>= 5.2
WireGuard Transparent Encryption	>= 5.6
Full support for Session Affinity	>= 5.7
BPF-based proxy redirection	>= 5.7
Socket-level LB bypass in pod netns	>= 5.7
L3 devices	>= 5.8
BPF-based host routing	>= 5.10
IPv6 BIG TCP support	>= 5.19
IPv4 BIG TCP support	>= 6.3

Abra o shell do Ubuntu WSL, no seu gerenciador de terminal, o meu é o Windows Terminal,
e siga os passos

Instale as ferramentas necessárias para compilação

sudo apt update && sudo apt install build-essential flex bison libssl-dev libelf-dev bc python3 pahole

Baixe o kernel no repositório do linux, baixando só a branch que vamos usar no casol linux-6.8.y.

## baixando do repositorio
git clone --depth 1 --branch linux-6.8.y https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
### Entre na pasta
cd linux

Estando dentro da pasta, linux, vamos baixar o arquivo de configuração padrão do kernel do Wsl e salva-lo como .config.

wget https://raw.githubusercontent.com/microsoft/WSL2-Linux-Kernel/linux-msft-wsl-6.1.y/arch/x86/configs/config-wsl -O .config

Vamos fazer o replace das entrada LOCALVERVSION para generic

sed -i 's/microsoft-standard-WSL2/generic/' ./.config

Vamos ajustar o arquivo .config para atender a todos os requisitos do Cilium

Vamos criar um arquivo chamado cilium_modules e colocar o conteudo abaixo dentro.

## linux/cilium_modules
## Base requirements
CONFIG_BPF=y
CONFIG_BPF_SYSCALL=y
CONFIG_NET_CLS_BPF=y
CONFIG_BPF_JIT=y
CONFIG_NET_CLS_ACT=y
CONFIG_NET_SCH_INGRESS=y
CONFIG_CRYPTO_SHA1=y
CONFIG_CRYPTO_USER_API_HASH=y
CONFIG_CGROUPS=y
CONFIG_CGROUP_BPF=y

## Iptables-based Masquerading
CONFIG_NETFILTER_XT_SET=m
CONFIG_IP_SET=m
CONFIG_IP_SET_HASH_IP=m

## L7 and FQDN Policies
CONFIG_NETFILTER_XT_TARGET_TPROXY=m
CONFIG_NETFILTER_XT_TARGET_CT=m
CONFIG_NETFILTER_XT_MATCH_MARK=m
CONFIG_NETFILTER_XT_MATCH_SOCKET=m

## IPsec
CONFIG_XFRM=y
CONFIG_XFRM_OFFLOAD=y
CONFIG_XFRM_STATISTICS=y
CONFIG_XFRM_ALGO=m
CONFIG_XFRM_USER=m
CONFIG_INET_ESP=m
CONFIG_INET_IPCOMP=m
CONFIG_INET_XFRM_TUNNEL=m
CONFIG_INET_TUNNEL=m
CONFIG_INET6_ESP=m
CONFIG_INET6_IPCOMP=m
CONFIG_INET6_XFRM_TUNNEL=m
CONFIG_INET6_TUNNEL=m
CONFIG_INET_XFRM_MODE_TUNNEL=m
CONFIG_CRYPTO_AEAD=m
CONFIG_CRYPTO_AEAD2=m
CONFIG_CRYPTO_GCM=m
CONFIG_CRYPTO_SEQIV=m
CONFIG_CRYPTO_CBC=m
CONFIG_CRYPTO_HMAC=m
CONFIG_CRYPTO_SHA256=m
CONFIG_CRYPTO_AES=m

Agora, vamos criar um script Python chamado enable_conf.py , para obter o conteúdo arquivo cilium_modules e ajustar o .config.

import re
# Lê o conteúdo do arquivo 'cilium_modules
config_replacements = {}
with open('cilium_modules', 'r', encoding='utf-8') as file1:
    for line in file1:
        line = line.strip()
        # Ignora linhas vazias e comentários
        if not line or line.startswith('##'):
            continue
        key, value = line.split('=')
        config_replacements[key] = value
# Lê o conteúdo do arquivo '.config'
with open('.config', 'r') as file2:
    file2_lines = file2.readlines() 
# Mantém um conjunto para controle das chaves que foram atualizadas
updated_keys = set()
# Substitui linhas correspondentes em '.config'
with open('.config', 'w', encoding='utf-8') as file2:
    for line in file2_lines:
        # Verifica se a linha contém alguma chave de 'cilium_modules' usando regex
        for key, value in config_replacements.items():
            if re.search(r'\b' + re.escape(key) + r'\b', line):
                # Se a linha estiver comentada, remove o símbolo de comentário e atualiza
                if line.startswith('# ' + key):
                    line = f"{key}={value}\n"
                # Atualiza o valor da linha
                elif re.search(r'^\s*' + re.escape(key) + r'\b', line):
                    line = f"{key}={value}\n"
                updated_keys.add(key)
                break
        file2.write(line)
    # Adiciona as chaves que não foram encontradas ao '.config'
    for key, value in config_replacements.items():
        if key not in updated_keys:
            file2.write(f"{key}={value}\n")

Gist

Execute o script

python3 enable_conf.py

Agora só rodar o Make, pode deixar todas perguntas no padrão.

make -j $(nproc)

Finalizando a compilação, instale os moduloes.

sudo make modules_install

Vamos criar uma pasta no Windows, para colocar o kernel novo, lembrando que todas as do WSL compartilham o mesmo kernel, então vamos colocar no drive C:.
No Ubuntu crie o diretório.

mkdir /mnt/c/wslkernel

Copie o novo kernel para a pasta vamos renomear para kernelcilium

cp arch/x86/boot/bzImage /mnt/c/wslkernel/kernelcilium

Agora vamos alterar o .wslconfig para as distros subirem com o kernel novo, pode usar o seu editor de texto de preferencia, estando no windows, navegue até a pasta, $env:USERPROFILE e edite o .wslconfig, e adicione a configuração conforme abaixo.

[wsl2]
kernel = C:\\wslkernel\\kernelcilium

Feche as janelas abertas com o wsl e derrube todas as distros.

wsl --shutdown

Abra o Ubuntu novamente e confirme se está usando o kernel novo.

uname -r

Vamos criar o arquivo de configuração para os modulos necessários carregarem na inicialização.

awk '(NR>1) { print $2 }' /usr/lib/modules/$(uname -r)/modules.alias | sudo tee /etc/modules-load.d/cilium.conf

Vamos reiniciar o daemon e o serviço de modulos

sudo systemctl daemon-reload

sudo systemctl restart systemd-modules-load

Checando se está tudo certo

$cris /kind ❱❱ sudo systemctl status systemd-modules-load
● systemd-modules-load.service - Load Kernel Modules
     Loaded: loaded (/usr/lib/systemd/system/systemd-modules-load.service; static)
     Active: active (exited) since Tue 2024-06-11 11:23:40 -03; 4h 59min ago
       Docs: man:systemd-modules-load.service(8)
             man:modules-load.d(5)
    Process: 56 ExecStart=/usr/lib/systemd/systemd-modules-load (code=exited, status=0/SUCCESS)
   Main PID: 56 (code=exited, status=0/SUCCESS)

Notice: journal has been rotated since unit was started, output may be incomplete.
$cris /kind ❱❱ lsmod
Module                  Size  Used by
ipcomp6                12288  0
xfrm6_tunnel           12288  1 ipcomp6
tunnel6                12288  1 xfrm6_tunnel
esp6                   24576  0
xfrm_user              53248  4
xfrm4_tunnel           12288  0
ipcomp                 12288  0
xfrm_ipcomp            12288  2 ipcomp6,ipcomp
esp4                   24576  0
xfrm_algo              16384  4 esp6,esp4,xfrm_ipcomp,xfrm_user
ip_set_hash_netportnet    49152  0
ip_set_hash_netnet     49152  0
ip_set_hash_netiface    45056  0
ip_set_hash_netport    45056  0
ip_set_hash_net        45056  0
ip_set_hash_mac        24576  0
ip_set_hash_ipportnet    45056  0
ip_set_hash_ipportip    40960  0
ip_set_hash_ipport     40960  0
ip_set_hash_ipmark     40960  0
ip_set_hash_ipmac      40960  0
....

Criando o Cluster kubernetes com Kind

Instalando o client Cilium, você pode fazer todas a instalação também usando Helm.

A partir de agora usaremos somente o powershell para criação dos recursos, primeiramente vamos criar um cluster usando o Kind.

Crie o arquivo de configuração do kind, vamos desativar a rede padrão e o kubeproxy.

kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
- role: control-plane
  extraPortMappings:
  # localhost.run proxy
  - containerPort: 32042
    hostPort: 32042
  # Hubble relay
  - containerPort: 31234
    hostPort: 31234
  # Hubble UI
  - containerPort: 31235
    hostPort: 31235
- role: worker
- role: worker
networking:
  disableDefaultCNI: true
  kubeProxyMode: "none"

Agora vamos instalar o Cilium no cluster para isso vamos usar o cliente do cilium, a instalação também pode ser feita via helm.
- Baixe a ultima release do Cilium para sua plataforma, e descompacte em uma pasta de sua preferencia, lembrando que para executar em qualquer prompt precisa colocar o local do executavel na varivel de ambiente PATH.

## Baixando
aria2c https://github.com/cilium/cilium-cli/releases/download/v0.16.10/cilium-windows-amd64.zip

## descompactando
unzip.exe .\cilium-windows-amd64.zip

A opção que prefiro é usar o Scoop, o Cilium não está em nenhum bucket official, então vamos precisar criar uma instalação customizada.
Crie uma arquivo chamado cilium.json e coloque o conteúdo abaixo.

{
  "bin": "cilium.exe",
  "version": "v0.16.10",
  "url": https://github.com/cilium/ciliumcli/releases/download/v0.16.10/cilium-windows-amd64.zip"
}

Agora é somente instalar com o scoop apontando para o arquivo json.

scoop install cilium.json

Agora é só executar o comando do cilium para instalar ele no cluster ele vai achar seu cluster pelo contexto atual do .kube/config, pode confirmar usando o comando kubectl config get-contexts ,

cilium install

$cris /kind ❱❱ cilium install
🔮 Auto-detected Kubernetes kind: kind
✨ Running "kind" validation checks
✅ Detected kind version "0.23.0"
ℹ️  Using Cilium version 1.15.5
🔮 Auto-detected cluster name: kind-kind
ℹ️  Detecting real Kubernetes API server addr and port on Kind
🔮 Auto-detected kube-proxy has not been installed
ℹ️  Cilium will fully replace all functionalities of kube-proxy

Depois de alguns minutos o Cilium está pronto, podemos verificar os status do cilium com o cli.

cris /kind ❱❱ cilium status
    /¯¯\
 /¯¯\__/¯¯\    Cilium:             OK
 \__/¯¯\__/    Operator:           OK
 /¯¯\__/¯¯\    Envoy DaemonSet:    disabled (using embedded mode)
 \__/¯¯\__/    Hubble Relay:       disabled
    \__/       ClusterMesh:        disabled

Deployment             cilium-operator    Desired: 1, Ready: 1/1, Available: 1/1
DaemonSet              cilium             Desired: 3, Ready: 3/3, Available: 3/3
Containers:            cilium             Running: 3
                       cilium-operator    Running: 1
Cluster Pods:          3/3 managed by Cilium
Helm chart version:
Image versions         cilium             quay.io/cilium/cilium:v1.15.5@sha256:4ce1666a73815101ec9a4d360af6c5b7f1193ab00d89b7124f8505dee147ca40: 3
                       cilium-operator    quay.io/cilium/operator-generic:v1.15.5@sha256:f5d3d19754074ca052be6aac5d1ffb1de1eb5f2d947222b5f10f6d97ad4383e8: 1

Caso exiba algum erro, você pode dar uma olhada no status do daemont set, e conferir os logs dos pods.

$cris /kind ❱❱ k get daemonsets -n kube-system
Events:
  Type    Reason            Age    From                  Message
  ----    ------            ----   ----                  -------
  Normal  SuccessfulCreate  6m47s  daemonset-controller  Created pod: cilium-c74rc
  Normal  SuccessfulCreate  6m47s  daemonset-controller  Created pod: cilium-b7rrn
  Normal  SuccessfulCreate  6m47s  daemonset-controller  Created pod: cilium-wmxlx

Verficando o status dos pods

k get pods -l k8s-app=cilium -n kube-**system**
k logs -l k8s-app=cilium -n kube-system

Se der algum erro em modulo, pode ter faltado algum passo da etapa build do kernel, pode analisar novamente. Pode pegar o nome do modulo que deu erro e tentar carrega-lo, usando modprobe.
Ex:

sudo modprobe xt_TPROXY

Se não der erro e aparecer no lsmod, provalmente só faltar por ele no boot do linux, como foi feito na parte 12 da compilação do kernel.

Testando o ambiente.

Para o teste vamos usar o app Star Wars Demo do lab Getting Started with Cilium da Isovalent.
Neste lab, fazemos o deploy de um microserviço simples, temos um deployment chamado DeathStar, que vai receber as requisições POST dos pods xwing e tiefigher, vamos usar o Cilium para controlar a comunicação entre os pods, baseando-se nos labels configurados.

Os Labels:

Death Star: org=empire, class=deathstar
Imperio TIE fighter: org=empire, class=tiefighter
Rebel X-Wing: org=alliance, class=xwing

Vamos usar criar o app no cluster usando o yaml http-sw-app.yaml:.

k apply -f https://raw.githubusercontent.com/cilium/cilium/HEAD/examples/minikube/http-sw-app.yaml

Checando a criação dos recursos.

$cris /kind ❱❱ k get pod,deploy,svc
NAME                             READY   STATUS    RESTARTS   AGE
pod/deathstar-689f66b57d-9c92f   1/1     Running   0          29m
pod/deathstar-689f66b57d-b4ps7   1/1     Running   0          29m
pod/tiefighter                   1/1     Running   0          29m
pod/xwing                        1/1     Running   0          29m

NAME                        READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/deathstar   2/2     2            2           29m

NAME                 TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)   AGE
service/deathstar    ClusterIP   10.96.120.87   <none>        80/TCP    29m
service/kubernetes   ClusterIP   10.96.0.1      <none>        443/TCP   130m

O manifesto cria também um serviço para gerenciar a comunicação com a DeathStar, vamos usar o exec para simular que estamos execuntando o comando a partir dos pods xwing.

k exec tiefighter -- curl -s -XPOST deathstar.default.svc.cluster.local/v1/request-landing

k exec xwing -- curl -s -XPOST deathstar.default.svc.cluster.local/v1/request-landing

No momento sem politicas ativas, as duas naves podem pousar e a api responde "Ship landed"
Vamos criar uma politica usando o cilium, abaixo o manifesto da politica, vamos fazer um bloqueio simples de porta.
Essa politica abaixo atua nas camadas de rede 3 e 4, em suma podemos controlar IP e Porta.

apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
  name: "rule1"
spec:
  description: "L3-L4 policy to restrict deathstar access to empire ships only"
  # definindo o pod que vai receber a requisição (No caso a DeathStar)
  endpointSelector:
    matchLabels:
      org: empire
      class: deathstar
  ingress:
  # definindo a origem da conexão, somente permitindo o pod com o label org = empire de acessar na porta 80.
  - fromEndpoints:
    - matchLabels:
        org: empire
    toPorts:  
    - ports:
      - port: "80"
        protocol: TCP

Aplicando a política.

k apply -f https://raw.githubusercontent.com/cilium/cilium/HEAD/examples/minikube/sw_l3_l4_policy.yaml

Testando as politicas

k exec xwing  -- curl -s -XPOST deathstar.default.svc.cluster.local/v1/request-landing

k exec tiefighter -- curl -s -XPOST deathstar.default.svc.cluster.local/v1/request-landing

Agora só o tiefighter recebe o retorno da API, o xwing não consegue conectar, pode dar um CTRL+C para sair.

Agora queremos que o tiefighter somente use a área de pouso, nossa api tem outros endpoints, mas somente queremos que utilize o /request-landing, para isso precisamos criar um regra de HTTP, como nas regras de cama 3 e 4 só trabalhamos com ip e porta, vamos precisar criar uma regra de camada 7, para controlar o tráfego http:

Endpoints:

$cris /kind ❱❱ k exec tiefighter -- curl -s -get deathstar.default.svc.cluster.local/v1
{
        "name": "Death Star",
        "hostname": "deathstar-689f66b57d-9c92f",
        "model": "DS-1 Orbital Battle Station",
        "manufacturer": "Imperial Department of Military Research, Sienar Fleet Systems",
        "cost_in_credits": "1000000000000",
        "length": "120000",
        "crew": "342953",
        "passengers": "843342",
        "cargo_capacity": "1000000000000",
        "hyperdrive_rating": "4.0",
        "starship_class": "Deep Space Mobile Battlestation",
        "api": [
                "GET   /v1",
                "GET   /v1/healthz",
                "POST  /v1/request-landing",
                "PUT   /v1/cargobay",
                "GET   /v1/hyper-matter-reactor/status",
                "PUT   /v1/exhaust-port"
        ]
}

Para ajustar o yaml para controlar o trafego http, simplesmente adicionamos o campo rules no manifesto, adicionando mais refino da politica.

apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
  name: "rule1"
spec:
  description: "L7 policy to restrict access to specific HTTP call"
  endpointSelector:
    matchLabels:
      org: empire
      class: deathstar
  ingress:
  - fromEndpoints:
    - matchLabels:
        org: empire
    toPorts:
    - ports:
      - port: "80"
        protocol: TCP
      rules:
        http:
        - method: "POST"
          path: "/v1/request-landing"

Antes de ter politicas, conseguimos facilmente destruir a DeathStar.

$cris /kind ❱❱ k exec tiefighter -- curl -s -XPUT deathstar.default.svc.cluster.local/v1/exhaust-port
Panic: deathstar exploded

goroutine 1 [running]:
main.HandleGarbage(0x2080c3f50, 0x2, 0x4, 0x425c0, 0x5, 0xa)
        /code/src/github.com/empire/deathstar/
        temp/main.go:9 +0x64
main.main()
        /code/src/github.com/empire/deathstar/
        temp/main.go:5 +0x85

Aplicando a politica

k apply -f https://raw.githubusercontent.com/cilium/cilium/HEAD/examples/minikube/sw_l3_l4_l7_policy.yaml

Testando.

k exec tiefighter -- curl -s -XPOST deathstar.default.svc.cluster.local/v1/request-landing

k exec tiefighter -- curl -s -XPUT deathstar.default.svc.cluster.local/v1/exhaust-port

Continuamos conseguindo pousar, mas a porta de exaustão está protegida contra Tiefighters.

$cris /kind ❱❱ k exec tiefighter -- curl -s -XPOST deathstar.default.svc.cluster.local/v1/request-landing
Ship landed

$cris /kind ❱❱ k exec tiefighter -- curl -s -XPUT deathstar.default.svc.cluster.local/v1/exhaust-port
Access denied

Referências

WSL Kernel
Falco WSL
WSL Kernel Cilium

Talos Linux uma distro k8s

Cristiano Lemes — Tue, 04 Jun 2024 21:44:54 +0000

O que é o Talos Linux?

Talos é uma distribuição Linux otimizada para uso de container e Kubernetes, ele vem com o mínimo de recursos possível tornar o sistema operacional mais rápido e seguro, seus destaques são.

1. Imutável:

Os servidores ou outros componentes são configurados uma única vez e nunca são alterados. Qualquer modificação necessária é realizada criando uma nova versão do componente.

2. Efêmero:

Pode ser criado e destruído rapidamente conforme necessário, sem a intenção de permanência.

3. Atômico:

Todo o Talos é distribuído como uma única imagem autocontida, que é versionada, assinada e imutável. Isso garante que todas as partes do sistema estão incluídas e integradas em um único pacote indivisível.

4. Minimalista:

Contém apenas o essencial, sem componentes ou dependências desnecessárias. O design é simplificado para manter a eficiência e clareza.

5. Seguro por padrão:

Foi projetado para ser seguro desde o início, sem a necessidade de configurações adicionais para garantir a segurança. As práticas de segurança são incorporadas desde a concepção.

6. É Gerenciado através de um único arquivo de configuração declarativo e API gRPC:

Toda a gestão e configuração são centralizadas em um único arquivo de configuração, onde as instruções são declarativas (especificam o que deve ser feito, não como). A interação e gestão são feitas através de uma API gRPC, que permite comunicação eficiente e de alto desempenho entre serviços.

Testando o Talos Localmente.

A maneira mais simples de testar o talos é usando o Docker, você consegue criar um cluster Kubernetes localmente usando a ferrmanta de cli talosctl, com isso além de testar o Talos você ainda vai ter disponivel um cluster kubernetes local, podendo usa-lo para criar cluster de testes em sua máquina no lugar de usar kind ou minikube.

Vamos seguir o passos seguintes para criar um cluster Kubernetes usando Docker e Talos.
Requisitos:

Instalando Cli do talos
O Cliente do talos pode ser instalado usando seu gerenciador de pacotes.
No MacOS.

brew install siderolabs/tap/talosctl

No linux.

curl -sL https://talos.dev/install | sh

No windows:

scoop install talosctl

Versões compiladas podem ser baixados no github Talos Release

Criando o cluster

Agora podemos rodar o comando de criação do cluster, especificando a quantidade de nós do tipo worker..

talosctl cluster create --name docker-talos --workers 2

Após criar o cluster, ele vai exibir na tela as configurações e já vai gerar o arquivo kubeconfig.

E é só isso, criamos um cluster Kubernetes local utilizando o Talos Linux, com apenas alguns comandos simples. Este processo é uma ótima maneira de testar e experimentar com Kubernetes de forma segura e rápida, sem a necessidade de instalar e configurar um ambiente de produção. Com o Talos, você pode criar clusters de teste em sua máquina local, o que é especialmente útil para desenvolvedores e profissionais de TI que precisam testar e demonstrar soluções de forma rápida e eficiente.

Para apagar o cluster rode:

talosctl cluster destroy --name docker-talos

Até mais!!

Instalando Kubernetes do Zero

Cristiano Lemes — Sun, 03 Mar 2024 13:39:33 +0000

Introdução

O Kubernetes emergiu como a principal plataforma de orquestração de containers, permitindo que organizações gerenciem e dimensionem aplicativos de maneira eficiente em ambientes de produção e desenvolvimento. Com sua arquitetura distribuída e recursos de automação robustos, o Kubernetes simplifica a implantação, o gerenciamento e a escalabilidade de aplicativos em containers.

Neste artigo, vamos explorar o processo de instalação do Kubernetes a partir do zero, utilizando o Kubeadm. O Kubeadm é uma ferramenta de linha de comando que facilita a configuração de clusters Kubernetes, oferecendo um método simplificado para inicializar e configurar um ambiente Kubernetes.
Estaremos fazendo toda instalando manualmente para fins didáticos, mas para esse tipo de instalação pode ser usado um gerenciador de configuração como Ansible para automatizar esse processo, que pode ser feito tanto em um servidor baremetal quanto em uma VM.

Arquitetura do kubernetes

Componentes do Controlplane:

kube-apiserver: É o componente central do Kubernetes que expõe a API do Kubernetes. Todas as operações do cluster, como criação, atualização e exclusão de recursos, são realizadas através desta API.
etcd: Um banco de dados chave-valor distribuído usado para armazenar o estado do cluster Kubernetes, incluindo configurações, metadados e informações sobre os nós e os pods.
kube-scheduler: Responsável por agendar pods em execução nos nós do cluster. Ele considera requisitos de recursos, afinidades e restrições ao tomar decisões sobre onde os pods devem ser executados.
kube-controller-manager: É responsável pela execução dos controladores do Kubernetes. Os controladores monitoram o estado do cluster e fazem ajustes para garantir que o estado desejado seja mantido. Exemplos de controladores incluem o controlador de replicação, o controlador de endpoints e o controlador de serviço.

Componentes do Node:

kubelet: Agente que executa nos nós do cluster e é responsável por garantir que os containers estejam em execução em um nó. Ele se comunica com o kube-apiserver para receber instruções sobre quais pods devem ser executados e garante que os containers nos pods estejam saudáveis.
kube-proxy: É um proxy de rede que executa no nó e mantém as regras de encaminhamento de rede. Ele gerencia o tráfego de rede para os pods no nó, permitindo que os mesmos se comuniquem entre si e com recursos externos.
Container runtime: Um container runtime é uma parte essencial do ecossistema de contêineres. Ele é responsável por executar e gerenciar os containers. Ele provê isolamento de recursos, como cpu, memoria, redes e volumes, e faz a gestão do ciclo de vida do container. Ele é o componente reposnavel pela comunicação entre o container e o kernel.

Tipos implantação do Kubernetes

O método mais comum atualmente é utilizar uma distribuição de Kubernetes gerenciada, oferecida por provedores como Amazon, Google e Microsoft. No entanto, existem três abordagens principais para usar o Kubernetes.

Plataformas Gerenciadas: No Kubernetes gerenciado, você não terá controle sobre o control plane, que é o nó responsável por gerenciar o cluster Kubernetes. Isso simplifica a manutenção do cluster, porém limita algumas personalizações. Por exemplo, você não poderá atualizar a versão do Kubernetes por conta própria; essa tarefa fica a cargo do provedor, e você só terá acesso às versões que eles validaram.

Distribuiçoes Kubernetes: Existem distribuições que vêm empacotadas, que auxiliam desde da instalação da máquina, virtual ou baremetal, algumas tendo inclusive sistema operacional customizado para o kubernetes como é o caso do RKE, os instaladores vão fazer toda parte de instalação do cluster e configurar ferramentas auxiliares como helm e stacks de monitoramento, entregado o cluster pronto para uso no final.

Implantação Manual: Ao criar o cluster a partir do zero e instalar manualmente cada componente, você tem controle total sobre o cluster, podendo personalizá-lo e utilizar qualquer versão do Kubernetes. No entanto, isso implica em mais etapas de manutenção e uma maior responsabilidade sobre o cluster.

Kubernetes Gerenciado:

EKS Amazon Elastic Kubernetes Service
AKS Azure Kubernetes Service
GKE Google Kuberneste Engine
DOKS DigitalOcean Kubernetes

Distribuições Kubernetes:

RKE Rancher Kubernetes Engine (OpenSource)
RedHat OpenShift (Comercial, mas tem a versão aberta chamada OKD)
VMware Tanzu (Comercial)

Implantação Manual:

kubeadm: O que usarei neste artigo
kops: Ferramenta para criar o cluster de forma automatizada
kubepray: Ferramenta que usa o ansioble para provisionar o cluster

Configurações mínimas para o cluster:

SO Linux
CPU: 2
Memória: 2GB
Conexão de rede entre todas as máquinas no cluster
Swap desabilitado.
Acesso ssh aos servidores

Portas necessárias:

Libere essas portas no firewall para comunicação entre os nós.

Protocolo	Direção	Intervalo de Portas	Propósito	Utilizado por
TCP	Entrada	6443	Servidor da API do Kubernetes	Todos
TCP	Entrada	2379-2380	API servidor-cliente do etcd	kube-apiserver, etcd
TCP	Entrada	10250	API do kubelet	kubeadm, Camada de gerenciamento
TCP	Entrada	10259	kube-scheduler	kubeadm
TCP	Entrada	10257	kube-controller-manager	kubeadm
TCP	Entrada	10250	API do Kubelet	kubelet, Camada de gerenciamento
TCP	Entrada	30000-32767	Serviços NodePort	Todos
TCP	Entrada	6783	Weave Pod Network	Todos
UDP	Entrada	6783-6784	Weave Pod Network	Todos

Requisitos de máquinas para o cluster.

Para seguir este tutorial pode ser usado VM locais, ou máquinas de um provedor de cloud, estaremos usando três máquinas, mas dá para testar em apenas uma, lembrando que o controlplane por padrão não roda container de aplicações, apenas de serviços do control-plane, mas configuração que pode ser alterada facilmente usando taints.

Configurando os nós do Cluster.

Acessando cada nó do cluster, vamos iniciar instalando e configurando os pré-requisitos para rodar o kubernetes, estarei utilizando o Sistema Operacional Ubuntu 22.04.

1- Deslique o SWAP, Kubelet não funciona com SWAP Ativa, e remova sua entrada do arquivo /etc/fstab/.

sudo swapoff -a
sudo sed -i '/ swap / s/^\(.*\)$/#\1/g' /etc/fstab

2- Habilite os modulos do kernel necessários para o funcinamento do cluster, para isso vamos criar o arquivo k8s.conf em /etc/modules-load.d/, depois use o modprobe para carregar os modulos sem ser necessario dar um reboot.

sudo modprobe overlay
sudo modprobe br_netfilter

3- Configurando parametros de rede, vamos criar o arquivo k8s.conf agora na pasta do systcl etc/sysctl.d/ para que o linux possa visualizar o tráfego de redes, depois use o sysctl para aplicar as mudanças sem ser necessário dar um reboot.

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

sudo sysctl --system

Intalando binarios do kubernetes

1- Atualize o repositorio apt e instale os pacotes basicos para baixar do repositorio oficial do kubernetes:

sudo apt-get update
sudo apt-get install -y apt-transport-https ca-certificates curl gpg

2- Faça download da chave pública do Google cloud:

curl -fsSL https://pkgs.k8s.io/core:/stable:/v1.30/deb/Release.key | sudo gpg --dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg

3- Adicione o repositório apt do Kubernetes:

echo 'deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v1.30/deb/ /' | sudo tee /etc/apt/sources.list.d/kubernetes.list

4- Atualize o apt e instale o kubelet, o kubeadm e o kubectl. Use o hold para fixar as versões para evitar problemas em atualizações automaticas.

sudo apt-get update
sudo apt-get install -y kubelet kubeadm kubectl
sudo apt-mark hold kubelet kubeadm kubectl

Instalando um container runtime, iremos utilizar o containerd.

1- Instale o containerd

sudo apt-get install containerd.io

2- Gere arquivo de configuraça padrão do Containerd.

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

3- Configure o systemd como cgroup driver, use o comando sed para alterar o arquivo gerado no passo anterior.

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

4- Confirme que o serviço containerd está habilitado e reinicie-o para aplicar a alteração do arquivo.

sudo systemctl enable containerd
sudo systemctl restart containerd

Criando o Cluster

Essas etapas devem ser feitas no nó que funcionará como controlplane.

Inicie o controlplane usando o kubeadm.

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

Há parametros opcionais que podem ser usados com o kubeadm, como --apiserver-advertise-address onde você espifica qual ip do nó vai ser usado pela api do controlplane, util se tiver mais de uma interface de rede configurado na maquina. Você consegue obter facilmente usando o comando ip a, tendo um ip publico e outro privado escolha o privado.

Output do kubeadm init

Your Kubernetes control-plane has initialized successfully!

To start using your cluster, you need to run the following as a regular user:

  mkdir -p $HOME/.kube
  sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
  sudo chown $(id -u):$(id -g) $HOME/.kube/config

You should now deploy a Pod network to the cluster.
Run "kubectl apply -f [podnetwork].yaml" with one of the options listed at:
  /docs/concepts/cluster-administration/addons/

You can now join any number of machines by running the following on each node
as root:

  kubeadm join <control-plane-host>:6443 --token <token> --discovery-token-ca-cert-hash sha256:<hash>

Ele vai imprimir na tela o comando para adicionar os nós do cluster, se você perder o token, você pode executar no servidor control-plane.

kubeadm token list

Crie o arquivo de configuração do kubernetes para gerenciar o cluster, apos executar o init o kubeadm gera as credenciais para o cluster em /etc/kubernetes/admin.conf, é necessarios por o conteudo deste arquivo

mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config

Agora já pode verificar o status do cluster

kubectl get nodes

NAME                         STATUS     ROLES           AGE     VERSION
k8s-lab   NotReady   control-plane   5m30s   v1.30.7

Adicionando outros nós no cluster. Agora que o cluster está up, execute o comando kubeadm join com as especificaçãos obtidas no output da criação do cluster

  kubeadm join <control-plane-host>:6443 --token <token> --discovery-token-ca-cert-hash sha256:<hash>

Verificando novamente os nós, agora temos todos listados, mas ainda está com status NotReady, o kubernetes não possui nativamente gerencimanto de rede, por isso devemos instalar um plugin para suprir essa necessidade.

kubectl get nodes

NAME                         STATUS     ROLES           AGE     VERSION
ubuntu-s-2vcpu-2gb-sfo3-01   NotReady   <none>          8s      v1.30.7
ubuntu-s-2vcpu-2gb-sfo3-02   NotReady   control-plane   5m30s   v1.30.7
ubuntu-s-2vcpu-2gb-sfo3-03   NotReady   <none>          7s      v1.30.7

Adicionando Plugin de Redes.

O kubernetes possui uma interface padronizada para que os plugins possam se integrar facilmente a ele, chamado CNI container network interface, com ele podemos escolher entre varias opções de plugins que se adequem a nossa necessidade.
Alguns dos principais plugins CNI usados em ambientes de containers, especialmente em clusters Kubernetes, incluem:

Calico: Um plugin de rede de código aberto que oferece funcionalidades avançadas de rede, incluindo políticas de rede baseadas em identidade e suporte a BGP (Border Gateway Protocol) para escalabilidade e interoperabilidade.
Flannel: Um plugin de rede simples e leve que cria uma rede sobreposta (overlay network) para conectar os containers em um cluster. Ele é popular por sua simplicidade e escalabilidade.
Weave: Outro plugin de rede de sobreposição que cria uma rede virtual privada (VPN) entre os nós do cluster. Weave oferece suporte a funcionalidades como criptografia de ponta a ponta e descoberta automática de serviços.
Cilium: Um plugin de rede e segurança que combina roteamento baseado em BPF (Berkeley Packet Filter) com política de segurança de camada 7. Ele fornece recursos avançados de segurança e observabilidade para containers e microsserviços.
Kube-router: Um plugin de rede que integra o roteamento baseado em BGP diretamente no Kubernetes, permitindo o balanceamento de carga de entrada e saída do cluster.

Para esse tutorial estarei utilizando o flannel.

Instale o plugin usando o yaml.

kubectl apply -f https://github.com/flannel-io/flannel/releases/latest/download/kube-flannel.yml

---
namespace/kube-flannel created
serviceaccount/flannel created
clusterrole.rbac.authorization.k8s.io/flannel created
clusterrolebinding.rbac.authorization.k8s.io/flannel created
configmap/kube-flannel-cfg created
daemonset.apps/kube-flannel-ds created

Verificando o cluster e efetuando testes.

Após a instalação do cluster os Status muda para Ready

kubectl get nodes
NAME                         STATUS   ROLES           AGE   VERSION
ubuntu-s-2vcpu-2gb-sfo3-01   Ready    <none>          33m   v1.30.7
ubuntu-s-2vcpu-2gb-sfo3-02   Ready    control-plane   43m   v1.30.7
ubuntu-s-2vcpu-2gb-sfo3-01   Ready    <none>          34m   v1.30.7

Checando os pods de sistema.

kubectl get pods -n kube-system
NAME                                                 READY   STATUS    RESTARTS        AGE
coredns-76f75df574-bsn9k                             1/1     Running   0               47m
coredns-76f75df574-mfpt2                             1/1     Running   0               47m
etcd-ubuntu-s-2vcpu-2gb-sfo3-02                      1/1     Running   0               48m
kube-apiserver-ubuntu-s-2vcpu-2gb-sfo3-02            1/1     Running   0               47m
kube-controller-manager-ubuntu-s-2vcpu-2gb-sfo3-02   1/1     Running   0               48m
kube-proxy-4vfvf                                     1/1     Running   0               47m
kube-proxy-4vfvf                                     1/1     Running   0               47m
kube-proxy-t67tm                                     1/1     Running   0               38m
kube-scheduler-ubuntu-s-2vcpu-2gb-sfo3-02            1/1     Running   0               47m
weave-net-g9m6f                                      2/2     Running   1 (5m20s ago)   5m28s
weave-net-rvt2v                                      2/2     Running   1 (5m21s ago)   5m28s
weave-net-g9m6f                                      2/2     Running   1 (5m22s ago)   5m28s

Criando um container para testar o cluster.

kubectl create deployment nginx-web --image nginx --replicas 3

4- Checando a criação dos container todos devem estar Running

kubectl get pods

NAME                         READY   STATUS    RESTARTS   AGE
nginx-web-5b757f798d-d9g2s   1/1     Running   0          24s
nginx-web-5b757f798d-pj57v   1/1     Running   0          24s
nginx-web-5b757f798d-z5bfx   1/1     Running   0          24s

Conclusão
Neste artigo, exploramos o processo de instalação do Kubernetes a partir do zero, utilizando o Kubeadm como ferramenta principal. O Kubernetes emergiu como a principal plataforma de orquestração de containers, oferecendo uma arquitetura distribuída e recursos de automação robustos para gerenciar e escalar aplicativos em ambientes de produção e desenvolvimento.

Ao longo do artigo, cobrimos os seguintes pontos:

Componentes do Controlplane e dos Nodes do Kubernetes, destacando suas funções e importância dentro do ecossistema do Kubernetes.
Exploramos os diferentes tipos de implantação do Kubernetes, desde plataformas gerenciadas até implantações manuais, destacando as vantagens e considerações de cada abordagem.
Especificamos as configurações mínimas e as portas necessárias para configurar um cluster Kubernetes.
Detalhamos o processo de configuração dos nós do cluster, incluindo a desativação do SWAP, a instalação de binários do Kubernetes e a configuração do Container Runtime.
Demonstrações passo a passo para criar um cluster Kubernetes usando Kubeadm, desde a inicialização do controlplane até a adição de nós adicionais.
Finalmente, instalamos e configuramos um plugin de rede, essencial para que os pods possam se comunicar entre si e com recursos externos.

Em resumo, o Kubernetes oferece uma base sólida para implantar, gerenciar e escalar aplicativos em containers de maneira eficiente e escalável. Com o conhecimento adquirido neste artigo, os administradores de sistemas e desenvolvedores estão equipados para iniciar e gerenciar clusters Kubernetes, seja para ambientes de desenvolvimento, teste ou produção.

Referências:

Cluster Kubernetes na Azure com Terraform

Cristiano Lemes — Sat, 24 Feb 2024 00:37:09 +0000

Criando um Cluster Kubernetes na Azure com Terraform e AKS

Neste tutorial, vamos explorar o processo passo a passo para criar um cluster Kubernetes na plataforma Azure usando o Terraform e o Azure Kubernetes Service (AKS). Este guia é especialmente útil para iniciantes que desejam iniciar sua jornada com o Kubernetes na nuvem.

Conteúdo

Criação da conta Azure
Configurando o Ambiente Local
Criando o Cluster
Destruindo o Cluster

1. Criação da conta Azure

Criando uma conta na Azure.

Se você ainda não possui uma conta Azure, pode aproveitar os benefícios de recursos gratuitos por 12 meses, além de um crédito de $200 para uso durante 30 dias. Embora os recursos deste tutorial não estejam incluídos na camada gratuita de 12 meses, os $200 podem ser suficientes seguindo os passos e removendo os recursos após o tutorial.

Acesse a página inicial do Azure.
Clique em "Conta Gratuita" no canto superior direito.
Selecione "Experimente Gratuitamente" e siga as instruções para criar uma nova conta ou fazer login com uma conta existente da Microsoft.
Na tela de login, você pode logar com uma conta microsoft já existe, ou criar uma conta nova, se você criar uma conta nova, pode usar um email atual de qualquer provedor.
Preencha a região e data de nascimento.
Proceda com a verificação do email.
Preencha os detalhes do perfil, e confirme o numero de telefone, marque a caixa verificar identidade por telefone e enviar sms, ou receber ligação.
Preencha os dados do endereço, confirme os termos de uso e clique avançar.
Adicione os dados do cartão de crédito, e clique em increver-se.

Caso você não tenha crédito liberado, ou já tenha passado dos limites ou do tempo do uso dos crédito você terá que habilitar o pagamento pelo uso, Pay as you go, para poder acessar os recursos.

2. Configurando o ambiente local

Neste tutorial, usaremos o Windows 11, mas as etapas podem ser seguidas em sistemas Linux ou macOS.

1. Instalando o Azure Cli

Existem várias maneiras de instalar o Azure CLI. Para instalação local:
Windows
Instalar usando o Msi
Azure Cli Msi

Instalar usando um gerenciador de pacotes,
Usando Scoop

scoop install azure-cli

Usando Winget

winget install -e --id Microsoft.AzureCLI

Ubuntu

curl  -sL  https://aka.ms/InstallAzureCLIDeb | sudo  bash

Mac OS

brew  update && brew  install  azure-cli

2. Instalando o Kubectl

Windows

Baixando o binario diretamente, você colocar em qualquer diretorio quie preferir, depois adicione esse diretorio a variavel de sistema PATH , para poder executar de qualquer pasta na linha de comando.

[Kubectl Windows Binario]https://dl.k8s.io/release/v1.29.2/bin/windows/amd64/kubectl.exe

Ulizando um gerenciador de pacotes.
Scoop

scoop install kubectl

Winget

winget install -e --id Kubernetes.kubectl

Linux
Faça o donwload do binario

curl  -LO  "https://dl.k8s.io/release/$(curl  -L  -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"

Configure as permissões e mova para pasta bin.

sudo  chmod  +x  kubectl
sudo  mv  ./kubectl  /usr/local/bin/

Mac OS
Instalando usando homebrew

brew  install  kubectl

3. Instalando o Terraform

Windows
Baixando o binario, descompacte o zip e coloque em uma pasta de sua preferencia, lembrando que deve por a pasta na variavel PATH.

Terrafom zip

Usando gerenciador de pacotes.
Scoop

$ scoop  install  terraform

Winget

$ winget install --id=Hashicorp.Terraform -e

Linux
Utilizando o gerenciador de pacotes (Ubuntu)

$ wget -O- https://apt.releases.hashicorp.com/gpg | sudo  gpg  --dearmor  -o  /usr/share/keyrings/hashicorp-archive-keyring.gpg
$ echo  "deb [signed-by=/usr/share/keyrings/hashicorp-archive-keyring.gpg] https://apt.releases.hashicorp.com $(lsb_release  -cs) main" | sudo  tee  /etc/apt/sources.list.d/hashicorp.list
$ sudo  apt  update && sudo  apt  install  terraform

Mac OS

$ brew  tap  hashicorp/tap
$ brew  install  hashicorp/tap/terraform

Instalando GIT

Windows

Utilizando o instalador.
Execute o instalador, pode manter todas as configurações padrões.
Git Windows Instaler
Utilizando gerenciador de pacotes
Scoop

$ scoop install git

Winget

$ winget install --id Git.Git -e --source winget

Linux
A maioria das distros já vem com git, utilize o gerenciador de pacotes para instalar caso necessário.
Ubuntu

$ apt-get  install  git

Mac OS

$ brew  install  git

Agora precisamos configurar o ambiente local para acessar o Azure.

Fazendo login na conta Azure usando o azure cli, na linha de comando digite.

$ az login

Ele vai abrir o navegador padrão e solicitar as credenciais do azure, entre com as credencias ele automaticamente vai configurar a linha de comando para poder acessar, os dados ficaram salvo na pasta ~./azure.

3. Criando o Cluster

Para criar o cluster, siga estes passos:

Vamos baixar o template AKS da HashiCorp para servir como ponto de partida, clone o repositorio usando o git.

$ git clone https://github.com/hashicorp/learn-terraform-provision-aks-cluster aks-cluster

Para ajustar os arquivos você pode utilizar o editor de código de sua preferencia, eu estarei utilizando o Visual Studio Code.

Com o Vscode aberto, vá em arquivo abrir pasta, escolha a pasta que acabou criar no passo anterior, ou navegue até a pasta usando a linha de comando e digite code .

Gerando credenciais para o Terraform

Vá na linha de comando

$ az ad sp create-for-rbac --skip-assignment

Ele vai gerar os dados que vamos usar para configurar o acesso ao Azure utilizando Terraform
Exemplo da saida.

{

"appId": "aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa",
"displayName": "azure-cli-2019-04-11-00-46-05",
"password": "aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa",
"tenant": "aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa"
}

Editando os arquivos do terraform Edite o arquivo terraform.tfvar e adicione os valores de appId e password que você obteve da saida do comando anterior. Edit o arquivo aks-cluster.tf em kubernetes altere para uma versão do kubernetes que seja suportado pelo aks, no momento "1.28.3", para verificar as versões do kubernetes disponiveis use o comando abaixo, eu vou manter a zona com West US2.

$ az aks get-versions --location westus2 --output table

Kubernetes Version Upgrades
------------------- -----------------------

1.28.3 None available
1.28.0  1.28.3
1.27.7  1.28.0, 1.28.3
1.27.3  1.27.7, 1.28.0, 1.28.3
1.26.10  1.27.3, 1.27.7
1.26.6  1.26.10, 1.27.3, 1.27.7

Cada nó do cluster AKS precisa ter no minimo 2vCPU e 4GB de memoria, neste caso vou utilizar a maquina mais barata disponivel com essas configurações que é a Standard_B2s.
para verficar os preços de maquinas pode verificar no site do azure.
O arquivo aks-cluster.tf final fica assim:

# Copyright (c) HashiCorp, Inc.
# SPDX-License-Identifier: MPL-2.0

resource "random_pet" "prefix" {}

provider "azurerm" {
  features {}
}

resource "azurerm_resource_group" "default" {
  name     = "${random_pet.prefix.id}-rg"
  location = "West US 2"

  tags = {
    environment = "Demo"
  }
}

resource "azurerm_kubernetes_cluster" "default" {
  name                = "${random_pet.prefix.id}-aks"
  location            = azurerm_resource_group.default.location
  resource_group_name = azurerm_resource_group.default.name
  dns_prefix          = "${random_pet.prefix.id}-k8s"
  kubernetes_version  = "1.28.3"

  default_node_pool {
    name            = "default"
    node_count      = 2
    vm_size         = "Standard_B2s"
    os_disk_size_gb = 30
  }

  service_principal {
    client_id     = var.appId
    client_secret = var.password
  }

  role_based_access_control_enabled = true

  tags = {
    environment = "Demo"
  }
}

Agora vamos inicializar o terrform na linha de comando digite:


$ terraform init

Initializing the backend...
Initializing provider plugins...

- Reusing previous version of hashicorp/random from the dependency lock file
- Reusing previous version of hashicorp/azurerm from the dependency lock file
- Installing hashicorp/random v3.5.1...
- Installed hashicorp/random v3.5.1 (signed by HashiCorp)
- Installing hashicorp/azurerm v3.67.0...
- Installed hashicorp/azurerm v3.67.0 (signed by HashiCorp)


Terraform has made some changes to the provider dependency selections recorded
in the .terraform.lock.hcl file. Review those changes and commit them to your
version control system if they represent changes you intended to make.
Terraform has been successfully initialized!

You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.

If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.

Com isso o terraform instala todos os modulos necessários.

Agora vamos rodar o terraform plan, o terraform plan vai simular a criação do recursos na cloud, é recomendado salvar o plano em um arquivo para posterior execução do apply.

$ terraform plan --out plan1

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the

following symbols:

+ create
Terraform will perform the following actions:
......
Plan: 3 to add, 0 to change, 0 to destroy.
Changes to Outputs:

+ kubernetes_cluster_name = (known after apply)
+ resource_group_name = (known after apply)

Com o plano sem erros podemos rodar o apply.

$ terraform apply "plan1"
---

Apply complete! Resources: 3 added, 0 changed, 0 destroyed.
Outputs:

kubernetes_cluster_name = "apt-tortoise-aks"
resource_group_name = "apt-tortoise-rg"

Capture os dados do output para os dados do cluster, e execute o comando abaixo para configurar o kubectl.

az aks get-credentials --resource-group apt-tortoise-rg --name apt-tortoise-aks --file ~/.kube/config

Agora o cluster está rodando, vamos verifcar com o kubectl.

$ kubectl get nodes

NAME STATUS ROLES AGE VERSION
aks-default-27467048-vmss000000 Ready agent 3m17s v1.28.3
aks-default-27467048-vmss000001 Ready agent 3m26s v1.28.3

Vamos fazer um pequeno deploy para testar o nosso cluster de um servidor Nginx.


$ kubectl create deployment website --replicas 3 --image nginx
$ kubectl expose deployment/website --type="LoadBalancer" --port 80

O Loadbalancer do Azure vai disponibilizar um IP publico para o serviço, e nesta configuração padrão não tem regras de segurança, então ele vai estar acessivel de qualquer lugar. Verificando os pods, criado com a quantidade de replicas que solicitamos.


$ kubectl get svc

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.0.0.1 <none> 443/TCP 13m
website LoadBalancer 10.0.195.30 x.x.x.x 80:30707/TCP 45s

$ kubectl get pods
NAME READY STATUS RESTARTS AGE
website-6784674d46-6xddr 1/1 Running 0 8m42s
website-6784674d46-7nsl6 1/1 Running 0 8m42s
website-6784674d46-vn5r4 1/1 Running 0 8m42s

Efetuando um curl no ip fornecido você deve receber a pagina padrão do nginx

$ curl 4.246.49.237
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
html { color-scheme: light dark; }
body { width: 35em; margin: 0 auto;
font-family: Tahoma, Verdana, Arial, sans-serif; }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>
<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>
<p><em>Thank you for using nginx.</em></p>
</body>
</html>

4. Destruindo o Cluster

Agora para não ficar gerando custos desnecessários para um ambiente de testes, vamos destruir o cluster, sempre que quiser é só criar o cluster novamente rodando o apply.

$ terrafom destroy

Plan: 0 to add, 0 to change, 3 to destroy.

Changes to Outputs:
- kubernetes_cluster_name = "apt-tortoise-aks" -> null
- resource_group_name = "apt-tortoise-rg" -> null

Do you really want to destroy all resources?
Terraform will destroy all your managed infrastructure, as shown above.
There is no undo. Only 'yes' will be accepted to confirm.
Enter a value: yes

Conclusão

Este guia fornece uma visão geral abrangente para criar e gerenciar um cluster Kubernetes na Azure. Lembre-se de revisar cuidadosamente e adaptar as etapas conforme necessário para atender às suas necessidades específicas e às últimas práticas recomendadas.

Referências

Ilustração

Docker GPU no Windows com WSL2

Cristiano Lemes — Sat, 17 Feb 2024 01:22:57 +0000

Configurando Ambiente de Desenvolvimento com GPU no Windows usando Docker e WSL2

Este guia detalhado ajudará você a configurar um ambiente de desenvolvimento com GPU no Windows usando Docker, WSL2 e as ferramentas relacionadas da Nvidia.

Passo 1: Verificar os Drivers da GPU

Para começar, verifique se os drivers da sua GPU estão funcionando corretamente. No PowerShell, execute o comando nvidia-smi.

nvidia-smi

Se o comando não funcionar, você pode instalar o driver mais recente para sua GPU no site da Nvidia.

Passo 2: Instalar e Configurar o Docker Desktop e WSL2

Se ainda não tiver o Docker Desktop instalado, baixe-o e instale-o.
Abra o Docker Desktop e clique em "Settings" (Configurações ⚙️).
Em "General", habilite a opção 'Use the WSL 2 base engine'.

Passo 3: Instalar e Configurar o WSL2

No PowerShell, execute o comando para instalar a versão mais recente do WSL:

wsl --install

Instale a distribuição do Ubuntu no WSL:

wsl --install -d Ubuntu

Verifique se a versão do WSL está correta:

wsl -l -v

Se a coluna "version" estiver como 1, atualize para a versão 2 usando o comando:

wsl.exe --set-version NAME 2

Configure a versão padrão do WSL para 2 com o comando:

wsl.exe --set-default-version 2

Passo 4: Integração do Docker com WSL

No Docker Desktop, vá para "Settings" (Configurações ⚙️) > "Resources" > "WSL Integration" e marque "Enable integration with my default WSL distro".

Passo 5: Instalar o Toolkit do Nvidia Container

Remova chaves GPG antigas

sudo apt-key del 7fa2af80

Configure o repositório:

curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey | sudo gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg \
&& curl -s -L https://nvidia.github.io/libnvidia-container/stable/deb/nvidia-container-toolkit.list | \
sed 's#deb https://#deb [signed-by=/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g' | \
sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list

Atualize o repositório e instale o Toolkit:

sudo apt-get update
sudo apt-get install -y nvidia-container-toolkit

Passo 6: Testar a Instalação

Execute o comando nvidia-smi para verificar se a instalação foi bem-sucedida.

Passo 7: Testar o Container Nvidia

Você pode testar o contêiner disponibilizado pela Nvidia usando o comando a seguir:

docker run --gpus all nvcr.io/nvidia/k8s/cuda-sample:nbody nbody -gpu -benchmark

Extra: Testar Ambiente com Ollama

Inicie o contêiner Ollama:

docker run -d --gpus=all -v ollama:/root/.ollama -p 11434:11434 --name ollama ollama/ollama

Execute um modelo, como o TinyLlama, para verificar se está tudo funcionando corretamente:

docker exec -it ollama ollama run TinyLlama

Pronto! Se tudo estiver correto, você está pronto para começar a usar o ambiente.

Referências:

Oh My Posh: O Oh My Zsh do Windows

Cristiano Lemes — Thu, 15 Feb 2024 23:09:29 +0000

O Oh My Zsh é uma ferramenta bem conhecida para customizar o terminal Zsh, usado em distribuições Linux e no macOS. Além de oferecer uma variedade de temas, o Oh My Zsh também possui uma ampla gama de plugins, como completions, que ajudam a aumentar a produtividade.

Para aqueles que utilizam o Windows e desejam explorar algumas possibilidades oferecidas pelo Oh My Zsh, decidi escrever este artigo sobre o Oh My Posh. O Oh My Posh pode ser usado em vários shells, não apenas no PowerShell, e também é multiplataforma. Isso significa que ele pode ser executado tanto no Windows quanto em qualquer shell do Linux e no macOS, além de ser gratuito e de código aberto. No entanto, ele se limita à funcionalidade de temas e não oferece gerenciamento de plugins como o Oh My Zsh. O PowerShell, por sua vez, possui várias funções de completions que podem ser configuradas, mas estão fora do escopo deste artigo. Demonstrarei como instalá-lo no Windows.

O primeiro passo é garantir que você tenha um terminal adequado no Windows. Para isso, vá até a Microsoft Store e baixe o Windows Terminal. Você também pode usar um gerenciador de pacotes via linha de comando.

Via Winget (nativo do Windows 11):

winget install --id Microsoft.WindowsTerminal -e

Via Chocolatey (não oficial):

choco install microsoft-windows-terminal

Via Scoop (não oficial):

scoop bucket add extras
scoop install windows-terminal

Em seguida, instale o PowerShell Core. No Windows padrão, o PowerShell antigo vem pré-instalado, mas você pode optar por instalar o PowerShell Core usando o pacote .msi disponibilizado pela Microsoft ou usando o Winget. Como não encontrei referências na documentação da Microsoft sobre a instalação usando outros gerenciadores, não posso recomendar neste momento.

Via MSI:

PowerShell-7.4.1-win-x64.msi

Via Winget:


winget install --id Microsoft.PowerShell --source winget

Após instalar o PowerShell Core, abra o Windows Terminal e defina-o como o terminal padrão. Para fazer isso, vá em Configurações, clique na seta para baixo ao lado do botão '+' na aba de título da janela e, em seguida, em Perfil Padrão, escolha PowerShell (não Windows PowerShell).

Agora, finalmente, vamos instalar o Oh My Posh, seguindo as instruções da documentação oficial. Existem opções para instalar usando gerenciadores de pacotes, mas neste caso, vamos utilizar o script PowerShell para instalar.

No Windows Terminal com PowerShell Core, execute a seguinte linha de comando e pressione Enter:

Set-ExecutionPolicy Bypass -Scope Process -Force; Invoke-Expression ((New-Object System.Net.WebClient).DownloadString('https://ohmyposh.dev/install.ps1'))

Agora, você deve configurar o Oh My Posh para iniciar junto com seu terminal. Para isso, edite o arquivo de perfil do PowerShell. A localização do arquivo fica armazenada na variável de ambiente $PROFILE. Você pode usar o Notepad para isso:

notepad $PROFILE

Vá para a última linha do arquivo e adicione:

oh-my-posh init --shell pwsh | Invoke-Expression

Salve e feche o Notepad, e reinicie seu terminal. Deve abrir conforme a imagem abaixo, porém sem os ícones.

Para carregar os ícones, é necessário ter uma fonte que suporte esses caracteres. Para isso, vamos utilizar o Nerd Fonts. Basta escolher uma fonte, baixá-la e instalá-la com um duplo clique no Windows. Você também pode fazer isso por linha de comando usando o cmdlet do Oh My Posh para instalar fontes. Por exemplo, para instalar a fonte MesloLG, você pode executar o seguinte comando:

oh-my-posh font install MesloLG

Agora, é necessário ir nas configurações do Windows Terminal. Em "Perfis" > "Padrões" > "Aparência", selecione o tipo de fonte e troque para a fonte escolhida. Salve e feche as configurações. O Windows Terminal aplicará as alterações na janela atual.

Referências

https://learn.microsoft.com/pt-br/windows/terminal/
https://learn.microsoft.com/pt-br/powershell/scripting/install/installing-powershell-on-windows
https://ohmyposh.dev/