Forem: Guilherme Lira

ARM vs x86 em Docker

Guilherme Lira — Fri, 05 Apr 2024 21:50:01 +0000

Intro

Hoje bem sabemos que processadores de arquitetura ARM, vem se tornado cada vez mais presentes em servidores, notebooks e em gabinetes e até como opções de flavors para instâncias computacionais em clouds públicas. Sabendo disso meus caros amigos e amigas, vi que podemos ter alguns pequenos desafíos ao trabalhar com o nosso querido Docker. Então escrevi esse artigo pra entendermos um pouco sobre a diferença dessas arquiteturas e o que elas impactam no nosso Container Engine tão amado que é o Docker.

Diferença entre ARM e x86

A principal diferença entre processadores ARM e x86 é que os precessadores do tipo ARM são RISC e os x86 são CISC. Como precisamos ter uma noção sobre essas arquiteturas para darmos seguimeto com o artigo, irei dar uma pequena expicação, nada muito profundo, sobre essas arquiteturas.

RISC ( Reduced Instruction Set Computer ) o que significa que suas instruções são mais reduzidas e que tendem ser mais simples e executadas em ciclos de relógio mais curtos. Uma instrução no padrão RISC é quebrada em instruções menores para que caibam em um ciclo de relógio. Todas as instruções tem um tamanho específico. Diferente do CISC ( Complex Instruction Set Computer ). No modelo CISC temos instruções mais complexas, sendo elas sem tamanho determinado podendo assumir dimensões variáveis de acordo com a quantidade de operações que deverão ser executadas.

💡 Um ciclo de relógio é a frequência medida em Hertz que determina quantos impulsos serão realizados por segundo naquele computador.

Como buildar uma imagem para uma arquitetura específica

Tendo em mente que a grande maioria dos notebooks, computadores de mesa e datacenters usam processadores x86, vai ser normal gerar nossas imagens nessas máquinas e isso pode acarretar em alguns problemas.

Também partindo do pressuposto que sabemos que um container nada mais é do que um isolamento dentro do SO ( Sistema Operacional ), e por isso ao fazer a geração de uma imagem, não adequada, para uma máquina com a CPU de arquitetura diferente de onde a imagem será executadada, vai acerretar nos problemas que veremos a seguir.

💡 Geralmente imagens muito usadas como RabbitMQ, Ubuntu ou até NodeJs são multi-plataforma, elas já tem imagens expecificas para cada arquitetura de CPU, então não será necessário expecificar, veremos isso mais ao decorrer do artigo.

Possíveis erros que vão acontecer

Bom como vimos acima para cada tipo de arquitetura as instruções são organizadas de uma maneira específica, então é claro que se executarmos um "build", dentro de uma máquina com processador x86, e tentar executar essa imagem dentro de uma máquina de processador ARM, vamos ter o seguinte erro.

$ docker-compose up -d
$ ... The requested image`s platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested

Um ponto muito importante, mais pra frente do artigo veremos como fazer o build correto para cada arquitetura, mas devemos ter uma atenção maior para as dependências do seu código, pois, mesmo que a imagem seja criada da maneira correta, talvez as suas dependências não foram buildadas para arquitetura ARM. Para resolver esse problema em NodeJs, podemos fazer da seguinte maneira, e com um simples comando:

$ npm install --cpu arm64 --os XPTO 
# Esse é so um exemplo você pode usar o SO que quiser

💡 Quando der um pull na sua imagem será possível ver para qual tipo de arquitetura sua imagem foi gerada, com o seguinte comando:
$ docker image inspect rabbitmq:latest --format='{{.Architecture}}'
arm64 # Retorno do comando
Dessa maneira, antes mesmo de usar a imagem, podemos saber se será compativel com a arquitetura da CPU, evitando erros futuros.

Como saber a arquitetura da sua CPU

Para saber qual a arquitetura da sua CPU é so digitar o camando, se você estiver em uma máquina com linux, o seguinte comando:

# Mac M1
$ uname -m
arm64 

# Maquina com processador Intel
$ uname -m
x86_64

Estratégias de build

Como vimos durante todo o artigo, imagens Docker podem suportar múltiplas plataformas. Isso significa que uma simples imagem do Docker pode conter variantes para diferentes arquiteturas. Mais acima comentei que quando imagens tem suporte a multi-pltaforma, o Docker automaticamente seleciona a imagem que corresponde a arquitetura e SO da máquina onde a imagem será baixada. Sabendo disso, vamos ver duas possibilidades de criar uma imagem multi-plataforma.

Antes de começarmos preciso falar um pouco sobre nosso amigo docker buildx, Buildx é um componente do Docker que tem ótimas funcionalidades para geração de imagem, e uma delas é a multi-plataforma. Todas as imagens geradas por ele são executadas com o Moby Buildkit.

Para fazer a criação de imagens multi-plataforma, antes devemos criar uma builder instance, para criar segue o comando abaixo:

$ docker buildx create --use

Ao criar uma imagem multiplataforma a partir de um Dockerfile, efetivamente seu Dockerfile é construído uma vez para cada plataforma. No final da compilação, todas essas imagens são mescladas em uma única imagem multiplataforma.

FROM alpine
RUN echo "Hello" > /hello

Por exemplo, nesse caso acima onde temos um simples Dockerfile, ao executar o comando docker buildx build --platform=linux/amd64,linux/arm64 ., o BuildKit vai subir duas imagens Alpine de diferentes versões, uma para cada tipo de arquitetura passada no comando, e vai executar todas as camandas para cada tipo de arquitetura. Por isso, é muito importante ter uma imagem base que tenha suporte para várias arquiteturas.

Emulação

Para executar esse tipo de build é bem simples, no exemplo acima já ocorre com a estratégia de Emulação, onde seram literalmente emulados os comandos em containers preparados para a arquitetura desejada. Para esse tipo de estratégia não é preciso alteração no Dockerfile. É maneira mais simples de obter uma imagem com suporte a multi-plataforma, mas com essa facilidade vem alguns problemas. Os binários executados dessa maneira precisam converter constantemente suas instruções entre arquiteturas e, portanto, não são executados com velocidade nativa. Ocasionalmente, você também pode encontrar um caso que desencadeia um bug na camada de emulação.
Mas o problema da estratégia de emulação não vai ocorrer na Cross Compilation, que veremos a seguir.

Corss Compilation

Nessa estratégia vamos ter um pouco mais de trabalho, vamos precisar fazer algumas alterações dentro de um Dockerfile, vou usar um caso bem simples, que será a do Alpine. Para conseguirmos uma imagem do alpine que seja mutliplataforma podemos usar algumas variáveis globais pré definidas como o BUILDPLATAFORM, ela sempre corresponderá à plataforma ou ao seu sistema atual e o construtor vai preencher o valor correto para gente.

FROM --platform=$BUILDPLATFORM alpine

Segue a lista com todas as veriaveis:

BUILDPLATFORM — Corresponde a plataforma da máquina atual. (linux/amd64)

BUILDOS — Componente de SO da BUILDPLATFORM. (linux)

BUILDARCH — Tipo de arquitetura da máquina atual. (amd64, arm64, riscv64)

BUILDVARIANT — Usado para definir a variante ARM. (v7)

TARGETPLATFORM — O valor definido com o flag --platform na compilação

TARGETOS - SO definido na flag --platform. (linux)

TARGETARCH - Tipo da arquitetura definida na --platform. (arm64)

TARGETVARIANT

Vamos ver um exemplo bem simples de uma imagem com a estratégia de cross compilation.

FROM --platform=$BUILDPLATFORM alpine AS build
RUN apk add mycompiler
COPY src src
ARG TARGETPLATFORM
RUN compile -target=$TARGETPLATFORM -o /out/mybinary /src

FROM alpine
RUN apk add helperapp
COPY --from=build /out/mybinary /bin

No Dockerfile acima conseguimos ver como vai funcionar nossa imagem. É so uma imagem de exemplo, mas é possível entender que a imagem terá que ser desenvolvida para se adaptar e gerar seus binários de acordo com a arquitetura escolhida. Para cada linguagem de programação, por exemplo, existe uma maneira de gerar os pacotes ou binários, para a lingauem Go funciona da seguinte maneira, segue o exemplo:

FROM --platform=$BUILDPLATFORM golang:1.17-alpine AS build
WORKDIR /src
COPY . .
ARG TARGETOS TARGETARCH
RUN GOOS=$TARGETOS GOARCH=$TARGETARCH go build -o /out/app .

FROM alpine
COPY --from=build /out/app /bin

E é isso pessoal, espero que esse artigo tenha ajudado vocês de alguma maneira.

Que danado é um pod?

Guilherme Lira — Sun, 07 Nov 2021 03:50:00 +0000

Neste post eu vou tentar destrinchar cada ponto dentro do contexto de um pod, sendo assim vamos ver um pouco de redes, politicas de rede, persistência de dados para pods, exemplos práticos e mais umas coisinhas aí. Esse primeiro post será a parte um de alguns posts sobre Kubernetes que vou soltar por aqui. Esse é a parte 1 sobre pods que eu vou postar.

$ O que é um pod?

Um pod nada mais é do que o menor artefato possível de implementação dentro de um cluster Kubernetes. É nele que podemos subir um ou mais containers, compartilhando storage e recursos de rede.

Cada container em um pod executa no próprio cgroup, mas eles compartilham alguns namespaces.

Uma característica interessante dos pods, é que eles foram criados para serem efêmeros, sendo assim quando um pod cai ele automaticamente é iniciado novamente.

Podemos subir um pod de duas maneiras, usando um manifesto (.yaml) ou por linha de comando, para faze-lo é preciso ter um ambiente com um cluster k8s rodando com kind, minikube ou de outro modo. Tendo nosso cluster rodando e com o kubectl, kubelet, e o kubeadm instalados, podemos subir um pod somente pela linha de comando, basta executarmos o comando:

alias k=kubectl
# Como exemplo vou subir um pod com um container NGINX
k run nginx --image=nginx

Para saber se seu container subiu é so rodar o comando:

k get pods

# Ele vai retornar algo como
NAME        READY      STATUS       RESTARTS        AGE
nginx       1/1        Running      0               8m54s

Caso você queira saber mais sobre seu pod, como quais containers estão rodando nele, dados de rede, condições do seu pod, volumes e mais alguns dados, é so executar o comando:

k describe pod ${nome do pod}

Conseguimos subir um pod somente com o nosso kubectl run, agora vamos subir o mesmo pod com uma manifesto. O manifesto que nada mais é do que um arquivo yaml ou json, mas o que é geralmente mais usado é o yaml. Com o nosso manifesto e tendo as configurações necessárias conseguimos deployar qualquer objeto que a API do Kubernetes consiga criar, inclusive o pod.

No manifesto de um pod estão inclusos alguns campos e atributos essenciais para o deploy do nosso pod, como:

Uma seção de metadata que descreve o Pod e seus rótulos. Rótulos esse
Outra seção de spec para descrever os volumes

apiVersion: v1
# kind será o valor do tipo de objeto que vamos criar 
kind: Pod
metadata:
  name: myapp
  labels:
    # O label é muito importante pois é por ele que outros objetos podem achar nosso pod
    name: myapp
spec:
  containers:
  - name: pod-learn
    image: nginx
    resources:
      # limits delimita o limite de CPI e memory do nosso container
      limits:
        memory: "128Mi"
        cpu: "500m"
    ports:
      - containerPort: 80

E para subir um pod a partir de um manifesto é so executar o comando:

k apply -f ${nome do arquivo}.yaml

$ Como usa-lo ?

Ao usar manifestos o Pod pode ser usado de maneiras diferentes, por objetos diferentes, como:

Deployment
Job
DeamonSet

Vamos entender como funciona um pouquinho cada um desses carinhas

~> Deployment

O objeto Deployment é uma das maneira de usar um Pod. Ao criar um deployment, o k8s cria juntamente com o pod, um ReplicaSet. O Deployment existe para gerenciar o lançamento de versões. Como esse post não é focado em Deployments, por isso não vou me estender sobre ele.
ReplicaSets
- Os ReplicaSets, são os responsáveis por controlar e manter a quantidade de réplicas que estabelecidas para o nosso deployment. E esses pods são identificados pela metadata pertencente ao deployment.
- A quantidade de réplicas são ditas na hora da criação do deployment.

Aqui está um exemplo de como criar um Deployment

  # Exemplo coletado no https://kubernetes.io/docs/concepts/workloads/controllers/deployment/
  apiVersion: apps/v1
  kind: Deployment
  metadata:
    name: nginx-deployment
    labels:
      app: nginx
  spec:
    # Replicas é a quantidade de réplicas que o ReplicaSet vai levantar e manter
    replicas: 3
    selector:
      matchLabels:
        app: nginx
    template:
      metadata:
        labels:
          app: nginx
      spec:
        containers:
        - name: nginx
          image: nginx:1.14.2
          ports:
          - containerPort: 80

~> DeamonSet

Quando falamos de DeamonSets, vem na cabeço os processos que rodam no seu linux do tipo daemon, são processos que rodam em background, e assim que seu sistema é iniciado eles são iniciados também. Como um serviço do mysql, docker e por ai vai.
E não é muito diferente aqui no nosso Kubernetes, ao subir o DeamonSet, um pod vai rodar em "background" em um, em mais de um ou em todos os nodes do seu cluster. Com isso podemos usa-lo para subir um pod com prometheus por exemplo, para fazer a parte de monitoramento do cluster.
E para entender mais de como funciona esse tal do DeamonSet é só olhar a doc oficial do Kubernetes sobre DEAMONSETS

~> Job

O Pod também é usado quando subimos um objeto do tipo Job. O Job é responsável por criar e gerenciar Pods definidos em um template na especificação do job. Em geral, esses Pods executam até serem concluídos com sucesso, caso aconteça uma falha o controlador do job vai levantar outro pod, com base no template do pod presente.
Para entender mais sobre, como funcionam os jobs, basta olhar na doc oficial do Kubernetes sobre JOBS

Agora que conseguimos subir um pod, vamos entender de que maneiras podemos usar esse pod

$ Como funciona a comunicação entre pods?

Os pods podem se comunicar facilmente tanto estando no mesmo node, quando em nodes diferentes, isso por causa de que cada pod recebe um ip ao ser criado. Porém não é muito inteligente usar o ip do pod criado, para fazer a conexão entre dois pods, pois os pods foram feitos para serem efêmeros, sendo assim, toda vez que um pod for derrubado e levantado em seguida, ele vai receber um novo ip, assim perdendo a conexão entre os pods.

Para mantermos esta conexão podemos apontar um service para o pod ou para um deployment, assim não vamos perder a conexão entre os pods. A comunicação dentro do cluster por hostname, só é possível através do servidor DNS que roda como um serviço Kubernetes. Podemos fazer a comunicação da seguinte maneira:

Namespace default ~> {serviceName}.svc.cluster.local
Em outro namespace ~> {serviceName}.{namespaceName}.svc.cluster.local

Dessa maneira é possível fazer a comunicação entre pods, tanto no mesmo node, quanto em node diferentes. Para que tudo isso funcione, é preciso que no seu cluster tenha instalado ou o kube-dns, que é o serviço de DNS nativo do k8s, ou configurar o core dns como o serviço de dns principal do seu cluster, vou deixar alguns links no final do artigo para quem quiser fazer a configuração.

$ Conclusão

Neste post conseguimos entender um pouco sobre o Pod, entendemos um pouco de o que é um pod, maneiras diferentes de como outros objetos do kubernetes usam ele e também uma breve passagem sobre a comunicação entre pods.

Na parte dois desse post, vou falar mais e adentrar mais sobre a network entre pods, e persistência de dados para um pod.

Agradeço quem leu todo o post, ressaltando que esse post é uma via de estudo que eu encontrei, e decidi, compartilhar com qualquer um que queira entender um pouco de Kubernetes assim como eu.

Até o próximo post!!!