Como sair da complexidade do Kubernetes com Kamal

Quando escrevi uma postagem recente sobre Capistrano, não imaginei que precisaria mencioná-lo novamente, pois é uma relíquia da história inicial de implantação de aplicativos. O que eu não percebi é que Capistrano foi escrito por engenheiros que trabalham para a 37Signals, em seu produto principal, Basecamp. Esta é a empresa de David Heinemeier Hansson.

DHH (é bastante conhecido pelas suas iniciais) declarou que tinha deixado a nuvem no ano passado, por razões puramente económicas. Se você tiver a coragem de executar software em seus próprios racks gerenciados (como todo mundo tinha que fazer, antes da nuvem), isso claramente poderia ser mais barato do que usar, digamos, o Amazon AWS – especialmente se você tiver necessidades fixas. Obviamente, quando atraíam as pessoas para as suas plataformas, os fornecedores de nuvens pareciam uma proposta melhor do que quando os preços subiram mais tarde.

A abordagem altamente inovadora da Amazon às ofertas de serviços ainda pode ser um bom motivo para permanecer na nuvem. Além disso, cada organização precisa fazer as contas por si mesma – a nuvem não é a opção certa para muitos casos de uso. Mas é preciso dizer que, embora o hardware tenha ficado mais barato, o DHH é um tipo muito específico de líder tecnológico.

O restante deste post dá uma olhada no substituto de Capistrano, Kamal. É basicamente Capistrano para contêineres via Docker. É, se preferir, uma alternativa mais simples ao Kubernetes ou Docker Swarm. Kamal oferece “implantações com tempo de inatividade zero, reinicializações contínuas, ponte de ativos, compilações remotas e tudo mais que você precisa para implantar e gerenciar seu aplicativo da web em produção com Docker”. Então ele implanta coisas por meio de comandos ssh. Mas pretende ser o mais agnóstico possível em relação ao objetivo da implantação.

Atualização do Docker

Assim como uma rápida atualização de memória, o Docker usa Dockerfiles para construir imagens, e elas são executadas em contêineres — nos quais seu aplicativo ou parte dele é executado de forma isolada:

Construindo imagens do Docker

Aqui está um exemplo de Dockerfile:

# Use the official Ubuntu 18.04 as base 
FROM ubuntu:18.04 
# Install nginx and curl 
RUN apt-get update && 
apt-get upgrade -y && 
apt-get install -y nginx curl && 
rm -rf /var/lib/apt/lists/*

Portanto, este Dockerfile usa uma imagem base de uma versão conhecida do Ubuntu e, em seguida, executa as atualizações e atualizações do Ubuntu, antes de instalar o nginx e limpar.

Outra coisa que provavelmente precisaremos lembrar. Docker Hub é o repositório oficial para imagens de contêiner. Se eu fizer login em hub.docker.com, ainda poderei ver algumas de minhas imagens antigas – assim como os repositórios no GitHub.

Kamal (sim, outro nome de origem vagamente marítima) usa Ruby, que é a linguagem interna da 37Signals, e algo que ainda uso ocasionalmente. Mais explicitamente, um dos meus primeiros posts aqui foi sobre Sinatra — e você pode usar isso para ajudar a criar um ambiente Ruby.

Depois de iniciar o Warp no meu Mac, vou apenas verificar a versão do meu Ruby embutido:

Posso então instalar a gema Kamal:

> gem install kamal

E então comece:

Não temos nada para implantar, nem nenhum lugar para implantar, então vamos apenas ver como Kamal vê o mundo. Mas isso é da 37Signals, então você pode imaginá-los implantando um Trilhos aplicativo. Portanto, há referências a bancos de dados, balanceadores de carga, etc.

O implantar.yml detém os destinos das coisas, e o .env arquivo conterá “segredos” que provavelmente não verificaríamos no controle de origem. Então, é isso .env é adicionado pelo nome aos vários .ignorar arquivos.

Vejamos primeiro o arquivo de implantação criado. A hierarquia organizacional simples é fácil de ler neste modelo yaml, e verificaremos de que tipo de coisas ela precisa:

>cat config/deploy.yml 

# Name of your application. Used to uniquely configure containers. service: 
my-app 
# Name of the container image. 
image: user/my-app 

# Deploy to these servers. 
servers: 
 - 192.168.0.1 

# Credentials for your image host. 
registry: 
 # Specify the registry server, if you're not using Docker Hub 
 # server: registry.digitalocean.com / ghcr.io / ... username: 
 my-user 

 # Always use an access token rather than real password when possible. 
 password: 
  - KAMAL_REGISTRY_PASSWORD 

# Inject ENV variables into containers (secrets come from .env). 
# Remember to run `kamal env push` after making changes! 
# env: 
#  clear: 
#   DB_HOST: 192.168.0.2 
#  secret: 
#   - RAILS_MASTER_KEY

Assim você terá um destino para seus servidores e o nome da sua imagem a ser implantada. A imagem provavelmente vem do Docker Hub, que é o “host da imagem”, portanto suas credenciais precisam ser armazenadas. Observe que as variáveis ​​env são injetadas nos contêineres, de forma editável ou em texto não criptografado.

E um pouco mais abaixo no deploy.yml vemos mais seções de exemplo:

# Use accessory services (secrets come from .env).
# accessories:
#   db:
#     image: mysql:8.0
#     host: 192.168.0.2
#     port: 3306
#     env:
#       clear:
#         MYSQL_ROOT_HOST: '%'
#       secret:
#         - MYSQL_ROOT_PASSWORD
#     files:
#       - config/mysql/production.cnf:/etc/mysql/my.cnf
#       - db/production.sql:/docker-entrypoint-initdb.d/setup.sql
#     directories:
#       - data:/var/lib/mysql
#   redis:
#     image: redis:7.0
#     host: 192.168.0.2
#     port: 6379
#     directories:
#       - data:/data

O termo “serviço acessório” refere-se a serviços dependentes de longa duração, como bancos de dados. Eles definem diferentes imagens e hosts. Existem seções de configuração adicionais para o proxy reverso Traefik, por exemplo.

O .env file é onde você colocaria os “segredos” apropriados:

> cat .env

KAMAL_REGISTRY_PASSWORD=change-this
RAILS_MASTER_KEY=another-env

Esses arquivos podem ser usados ​​para fazer referência ao 1Password ou outros armazenamentos centralizados. O acima estaria faltando a senha MYSQL, se prosseguirmos com um banco de dados. Se você mexer com eles, eles precisam ser explicitamente “empurrados” para o sistema comkamal env push. Na verdade, estes seriam necessários antes da implantação. Em um ambiente DevOps, nem todo engenheiro deveria ter acesso ao arquivo, mas todos precisam saber como ele se encaixa.

Então usamos okamal setup para desligar o sistema. Como esperado, se eu fizer isso agora, serei imediatamente informado de que não há nada com que conversar:

Então, como Kamal procederia com todos os servidores especificados e disponíveis?

Após conectar-se aos servidores, ele instalaria o Docker e enrolaria, se necessário. Em seguida, efetuando login no registro de imagem, ele construiria a imagem localmente, antes de enviá-la para o registro. Dos servidores de destino, ele extrairia a imagem. Depois de enviar as variáveis ​​​​env, ele iniciaria um novo contêiner com a versão atual do aplicativo e interromperia o antigo.

Se você fizer uma alteração no aplicativo, após a configuração inicial kamal deploy atualizará seu sistema. Posteriormente, você pode usar kamal redeploy que irá ignorar coisas como login no registro e, portanto, será mais rápido. E isso define o fluxo de trabalho normal. Ao manter algumas imagens antigas de contêineres quentes, você também pode rapidamente kamal rollback com um destino de imagem válido. A partir daqui, os engenheiros de DevOps podem reconhecer os padrões familiares.

Ao fornecer esta ferramenta à comunidade, a 37Signals está sinalizando uma forma de sair fisicamente da nuvem, bem como um método para mudar facilmente de provedor. Eles também estão se afastando da relativa complexidade do Kubernetes. Ao considerar sua estratégia de computação, é bom saber que há um exemplo prático tanto da economia quanto dos métodos técnicos de saída para consultar, se essa for a sua direção de viagem.

A postagem Como sair da complexidade do Kubernetes com Kamal apareceu pela primeira vez no The New Stack.