Revisão do Skaffold para desenvolvimento em Kubernetes

Há um ano e meio, em 5 de março de 2018, a Google lançou a primeira versão alfa de seu projeto Open Source para CI/CD chamado Skaffold, cujo objetivo é criar "um desenvolvimento simples e reproduzível em Kubernetes", permitindo que os desenvolvedores se concentrem no desenvolvimento em vez de na administração. O que pode ser interessante no Skaffold? Aparentemente, ele tem algumas cartas na manga que podem torná-lo uma ferramenta poderosa tanto para desenvolvedores quanto para engenheiros de operações. Vamos conhecer o projeto e suas funcionalidades.

NB: A propósito, já falamos brevemente sobre o Skaffold em nossa análise geral de ferramentas para desenvolvedores, cuja vida está ligada ao Kubernetes.

Teoria. Finalidade e funcionalidades

Assim, falando de forma geral, o Skaffold resolve a tarefa de automação do ciclo CI/CD (nas etapas de build, push, deploy), oferecendo ao desenvolvedor feedback rápido, ou seja, a capacidade de obter rapidamente o resultado de mudanças no código — na forma de uma aplicação atualizada, funcionando no cluster Kubernetes. E ele pode operar em diferentes ambientes (dev, stage, production...), para os quais o Skaffold ajuda a descrever os pipelines correspondentes para implantação.

O código fonte do Skaffold é escrito na linguagem Go, é distribuído sob a licença Apache License 2.0 (GitHub).

Vamos considerar as principais funções e características. As primeiras podem incluir o seguinte:

• O Skaffold oferece ferramentas para a criação de pipelines de CI/CD.
• Permite monitorar em segundo plano as mudanças no código fonte e iniciar o processo automatizado de compilação do código em imagens de contêiner, publicando essas imagens no Docker Registry e implantando-as no cluster Kubernetes.
• Sincroniza arquivos no repositório com o diretório de trabalho no contêiner.
• Realiza testes automaticamente com o container-structure-test.
• Encaminha portas.
• Lê logs da aplicação executada no contêiner.
• Ajuda na depuração de aplicações escritas em Java, Node.js, Python, Go.

Agora — sobre as características:

• O próprio Skaffold não possui componentes do lado do cluster. Ou seja, não é necessário configurar o Kubernetes adicionalmente para usar essa ferramenta.
• Diferentes pipelines para seu aplicativo. Precisa implantar o código em um Minikube local enquanto desenvolve, e depois em stage ou production? Para isso, existem suporte. de isolamento de chamadas de sistema. Para executar um programa em modo isolado, basta indicar o nome da aplicação como argumento da ferramenta firejail, por exemplo, "firejail firefox" ou "sudo firejail /etc/init.d/nginx start." e as configurações do usuário, variáveis de ambiente e flags, que permitem descrever diferentes pipelines para um único aplicativo.
• CLI. Apenas uma ferramenta de linha de comando e configurações em YAML. Na internet, há menções a tentativas de criar uma GUI experimental, no entanto, no momento isso significa mais que alguém precisa dela, mas não muito.
• Modularidade. O Skaffold não é uma ferramenta autônoma, mas visa usar módulos separados ou soluções já existentes para tarefas específicas.

Ilustração do último:

• Na fase de construção, pode-se utilizar:
  • docker build localmente, no cluster com kaniko ou no Google Cloud Build;
  • Bazel localmente;
  • Jib Maven e Jib Gradle localmente ou no Google Cloud Build;
  • scripts de build personalizados, executados localmente. Se for necessário executar outra solução (mais flexível/conhecida/…) para a construção, ela é descrita no script para que o Skaffold a execute exatamente (exemplo da documentação). Isso permite usar qualquer builder que possa ser chamado através de um script;
• Na fase de teste, é suportado o já mencionado container-structure-test;
• Para o deploy, estão previstos:
  • Kubectl;
  • Helm;
  • kustomize.

Por causa disso, o Skaffold pode ser considerado uma espécie de framework para construção de CI/CD. Aqui está um exemplo de fluxo de trabalho ao seu uso (da documentação do projeto):

Como se dá, em geral, o funcionamento do Skaffold?

1. A ferramenta monitora mudanças no diretório do código-fonte. Se arquivos são modificados, eles são sincronizados com o pod do aplicativo no cluster Kubernetes. Se possível — sem recriação da imagem. Caso contrário — uma nova imagem é criada.
2. A imagem criada é verificada com o container-structure-test, etiquetada e enviada ao Docker Registry.
3. Depois disso, a imagem é implantada — desdobrada no cluster Kubernetes.
4. Se a execução foi iniciada com o comando skaffold dev, começamos a receber logs do aplicativo, enquanto o Skaffold aguarda mudanças para repetir todas as ações novamente.

Ilustração das principais etapas do funcionamento do Skaffold

Prática. Experimentando o Skaffold

Para demonstrar o uso do Skaffold, pegarei um exemplo do repositório do GitHub do projeto. Por sinal, lá mesmo pode-se encontrar muitos outros exemplos levando em conta diferentes especificidades. Todas as ações serão executadas localmente no Minikube. A instalação é simples e levará alguns minutos, e para iniciar é necessário o kubectl.

Vamos instalar o Skaffold:

curl -Lo skaffold https://storage.googleapis.com/skaffold/releases/latest/skaffold-linux-amd64
chmod +x skaffold
sudo mv skaffold /usr/local/bin
skaffold version
v0.37.1

Vamos clonar o repositório do Skaffold com os exemplos necessários:

git clone https://github.com/GoogleContainerTools/skaffold
cd skaffold/examples/microservices

Escolhi um exemplo com dois pods, cada um contendo um pequeno aplicativo em Go. Um aplicativo é o frontend (leeroy-web), que redireciona a solicitação para o segundo aplicativo — o backend (leeroy-app). Vamos ver como isso se parece:

~/skaffold/examples/microservices # tree
.
├── leeroy-app
│   ├── app.go
│   ├── Dockerfile
│   └── kubernetes
│       └── deployment.yaml
├── leeroy-web
│   ├── Dockerfile
│   ├── kubernetes
│   │   └── deployment.yaml
│   └── web.go
├── README.adoc
└── skaffold.yaml
 
4 diretórios, 8 arquivos

leeroy-app e leeroy-web contêm código em Go e Dockerfiles simples para compilar esse código localmente:

~/skaffold/examples/microservices # cat leeroy-app/Dockerfile
FROM golang:1.12.9-alpine3.10 as builder
COPY app.go .
RUN go build -o /app .
 
FROM alpine:3.10
CMD ["./app"]
COPY --from=builder /app .

Não vou fornecer o código dos aplicativos — basta saber que leeroy-web aceita solicitações e as redireciona para leeroy-app. Portanto, nos arquivos Deployment.yaml existe um Service apenas para app (para roteamento interno). A porta do pod web será exposta para acesso rápido ao aplicativo.

Como é o aspecto do skaffold.yaml:

~/skaffold/examples/microservices # cat skaffold.yaml
apiVersion: skaffold/v1beta13
kind: Config
build:
  artifacts:
    - image: leeroy-web
      context: ./leeroy-web/
    - image: leeroy-app
      context: ./leeroy-app/
deploy:
  kubectl:
    manifests:
      - ./leeroy-web/kubernetes/*
      - ./leeroy-app/kubernetes/*
portForward:
  - resourceType: deployment
    resourceName: leeroy-web
    port: 8080
    localPort: 9000

Aqui estão descritas todas as etapas mencionadas acima. Além deste config, há um arquivo com configurações globais — ~/ .skaffold/config. Ele pode ser editado manualmente ou através da CLI — por exemplo, assim:

skaffold config set --global local-cluster true

Este comando definirá a variável global local-cluster como valor verdadeiro, após o que o Skaffold não tentará 'push' as imagens para um registro remoto. Se você estiver desenvolvendo localmente, pode usar este comando para armazenar as imagens localmente também.

Vamos voltar ao skaffold.yaml:

• Na etapa build indicamos que a imagem deve ser construída e armazenada localmente. Depois que a construção for iniciada pela primeira vez, veremos o seguinte:

  // т.к. Minikube создает кластер в отдельной виртуальной машине,
  // придется проникнуть внутрь, чтобы найти образы
  # minikube ssh
  $ docker images
  REPOSITORY                                TAG                                                                IMAGE ID            CREATED             SIZE 
  leeroy-app                                7d55a50803590b2ff62e47e6f240723451f3ef6f8c89aeb83b34e661aa287d2e   7d55a5080359        4 hours ago         13MB 
  leeroy-app                                v0.37.1-171-g0270a0c-dirty                                         7d55a5080359        4 hours ago         13MB
  leeroy-web                                5063bfb29d984db1ff70661f17d6efcc5537f2bbe6aa6907004ad1ab38879681   5063bfb29d98        5 hours ago         13.1MB
  leeroy-web                                v0.37.1-171-g0270a0c-dirty                                         5063bfb29d98        5 hours ago         13.1MB

  Como pode ser visto, o Skaffold tagueou as imagens automaticamente. A propósito, várias políticas de marcação são suportadas.

• Em seguida, no config, é especificado context: ./leeroy-app/, ou seja, o contexto no qual a imagem é construída.
• Durante a fase de deploy, determinamos que usaremos kubectl e uma máscara para os manifests necessários.
• PortForward: semelhante ao que costumamos fazer ao redirecionar portas com kubectl port-forward, fornecemos instruções ao Skaffold para chamar este comando. Neste caso, a porta local 9000 é redirecionada para 8080 no Deployment com o nome leeroy-web.

É hora de iniciar skaffold dev: o comando criará um "ciclo de feedback" contínuo, ou seja, não apenas compilará tudo e fará o deploy no cluster, mas também relatará o estado dos pods no momento, monitorará mudanças e atualizará o estado dos pods.

Aqui está o resultado da execução skaffold dev --port-forward na nova compilação:

Primeiro, vemos que o cache está sendo utilizado. Em seguida, o aplicativo é compilado, feito o deploy e as portas são redirecionadas. Como foi especificado --port-forward, o Skaffold redirecionou a porta para web, conforme solicitado, mas app ele redirecionou por conta própria (escolheu a mais próxima disponível). Depois disso, recebemos os primeiros logs dos aplicativos.

Vamos verificar se está funcionando?

~\/skaffold\/examples\/microservices # kubectl get po
NOME                          PRONTO   STATUS    REINÍCIOS   IDADE
leeroy-app-6998dfcc95-2nxvf   1\/1     Em Execução   0          103s
leeroy-web-69f7d47c9d-5ff77   1\/1     Em Execução   0          103s
~\/skaffold\/examples\/microservices # curl localhost:9000
leeroooooy app!!!

Modificamos o arquivo leeroy-app\/app.go — passa-se alguns segundos… e:

~\/skaffold\/examples\/microservices # kubectl get po
NOME                          PRONTO   STATUS    REINÍCIOS   IDADE
leeroy-app-ffd79d986-l6nwp    1\/1     Em Execução   0          11s
leeroy-web-69f7d47c9d-5ff77   1\/1     Em Execução   0          4m59s
~\/skaffold\/examples\/microservices # curl localhost:9000
leeroooooy Habr!!!

Neste processo, o próprio Skaffold exibiu no console a mesma coisa que antes, exceto por um detalhe: ele soltou apenas leeroy-app, e não tudo de uma vez.

Mais prática

Vale mencionar que ao criar um novo projeto, as configurações para Skaffold podem ser 'bootstrapadas' com o comando init, o que é muito conveniente. Além disso, é possível escrever várias configurações: realizar o desenvolvimento na configuração padrão e, em seguida, implantar no estágio com o comando run (o mesmo processo que dev, apenas não acompanha as alterações), utilizando outra configuração.

No katacoda, há manual um exemplo ainda mais simples. Lá, é oferecido um sandbox já pronto com Kubernetes, um aplicativo e Skaffold. Uma ótima opção se você estiver interessado em experimentar as noções básicas por conta própria.

Uma das possíveis utilizações do Skaffold é o desenvolvimento em um cluster remoto. Nem todos se sentem confortáveis em executar o Minikube em seu próprio hardware, depois fazer o rollout da aplicação e esperar que funcione adequadamente... Nesse caso, o Skaffold resolve muito bem o problema, como pode confirmar, por exemplo, os engenheiros do Reddit, sobre o que já falamos. reportou encontradas em nosso blog.

E em desta publicação da Weaveworks pode ser encontrado um exemplo de criação de pipeline para produção.

Conclusão

O Skaffold é uma ferramenta conveniente para a construção de pipelines destinados ao deployment de aplicações no Kubernetes e focados principalmente nas necessidades de desenvolvimento. É bastante simples criar um pipeline "curto" que atenda às necessidades básicas do desenvolvedor, mas se desejado, é possível organizar também processos mais elaborados. Como um dos exemplos práticos de aplicação do Skaffold em processos CI/CD é apresentado uma um projeto de teste com 10 microsserviços, utilizando as capacidades do Kubernetes, gRPC, Istio e OpenCensus Tracing.

O Skaffold já recebeu quase 8000 estrelas no GitHub, é desenvolvido pelo Google e faz parte do GoogleContainerTools — portanto, no momento, há todas as razões para acreditar que o projeto continuará a se desenvolver de forma sólida e duradoura.

P.S.

Confira também em nosso blog:

• «Ferramentas para desenvolvedores de aplicativos executados no Kubernetes»;
• «werf — nossa ferramenta para CI/CD no Kubernetes (visão geral e vídeo da apresentação)»;
• «Garden v0.10.0: Seu laptop não precisa de Kubernetes»;
• «Dicas & truques sobre Kubernetes: desenvolvimento local e Telepresence».

Fonte: habr.com