Por que Capistrano foi usurpado pelo Docker e depois pelo Kubernetes

Enquanto ouvia Cory Doctorow, muito apreciado defensor da propriedade intelectual e dos direitos digitais, lendo um pouco de seu novo livro, ouvi-o mencionar um lugar na Califórnia chamado Capistrano. Mas é claro que me lembrei do Capistrano, uma ferramenta de automação de servidor remoto popular no início de 2010 – era efetivamente uma ferramenta pré-contêineres e pré-Kubernetes.

Às vezes estou interessado no que aconteceu com a tecnologia comumente usada que perdeu popularidade com o tempo. É claro que Capistrano não está realmente morto – mesmo que eu esteja usando o pretérito para descrevê-lo. As ferramentas de código aberto nunca morrem de verdade, elas apenas se tornam subestimadas (e possivelmente colocadas no sótão). Lembro-me de usar o Capistrano como ferramenta de automação de servidor remoto há pouco mais de uma década. Usando SSH, seguiria um script para permitir que você implantasse suas atualizações nos servidores de destino. Uma atualização pode ser um novo arquivo executável, talvez algum código, talvez alguma configuração, talvez algumas alterações no banco de dados. Ótimo, mas por que olhar para um sistema que não é mais usado regularmente?

Em primeiro lugar, para compreender as tendências, é útil olhar para exemplos passados. Também ajuda observar o ponto em que algo diminuiu em popularidade, ao mesmo tempo em que verificamos se não perdemos nada ao longo do caminho. A tecnologia atual é apenas um pontinho na linha do tempo e é muito mais fácil prever o que vai acontecer se você olhar para trás ocasionalmente. Se você tiver que trabalhar em uma implantação em um novo site, é bom ter um conjunto de ferramentas além das suas favoritas. Talvez você até precise usar o Capistrano em uma pilha antiga. Então, vamos avaliar a antiguidade, para ver quanto ela pode valer.

Ambientes

Capistrano entendeu os três ambientes básicos nos quais você trabalharia: normalmente Produção, encenação e desenvolvimento. Um ambiente de desenvolvimento é provavelmente um laptop; um ambiente de teste é provavelmente algum tipo de servidor em nuvem que o controle de qualidade pode acessar. Usando essas definições, Capistrano poderia atuar em máquinas específicas.

Tarefas e Funções

O comando básico dentro do Capistrano era o tarefa. Eles foram executados em diferentes estágios de uma implantação. Mas para filtrá-los, você usou papéis para descrever com qual parte do sistema você estava trabalhando:

role :app, "my-app-server.com"
role :web, "my-static-server.com"
role :db, "my-db-server.com"

Isso representa o servidor de aplicativos (aquilo que gera conteúdo dinâmico), as páginas da web ou servidor da web e o banco de dados como partes separadas. É claro que você pode criar suas próprias definições.

Alternativamente, você poderia se concentrar mais na separação ambiental, com funções operando abaixo. Para uma descrição da produção, podemos definir o seguinte:

# config/deploy/production.rb

server "11.22.333.444", user: "ubuntu", roles: %w{app db web}

O padrão implantar A tarefa tinha várias subtarefas representando os estágios de implantação:

• implantar: começando Inicie uma implantação, certifique-se de que os pré-requisitos estejam definidos
• implantar: atualizandoAtualizar servidor(es) com uma nova versão
• implantar:publicaçãoPublique o novo lançamento
• implantar: finalizandoConclua a implantação, comece a limpar
• implantar: fazer upload Copie os arquivos para a versão implantada atualmente. Isso é útil para atualizar arquivos
  aos poucos
• implantar: reversão Leve tudo de volta

Aqui está um exemplo de uma tarefa de implantação personalizada. Este código semelhante ao Ruby usa as funções para filtrar a tarefa, bem como o estágio de implantação. Neste caso, podemos atualizar o estilo.css arquivo antes de terminarmos:

namespace :deploy do
   after :finishing, :upload do
     on roles(:web) do
       path = "web/assets"
       upload! "themes/assets/style.css", "#{path}"
     end
     on roles(:db) do
       # Migrate database
     end
   end
 end

Para acionar isso na linha de comando, você pode usar o seguinte após a instalação do Capistrano:

cap production deploy

Há um fluxo de implantação padrão, bem como um fluxo de reversão correspondente. Aqui está uma visão mais detalhada de como isso poderia acontecer:

deploy
  deploy:starting
    (before)
      deploy:ensure_stage
      deploy:set_shared_assets
    deploy:check
  deploy:started
  deploy:updating
    git:create_release
    deploy:symlink:shared
  deploy:updated
    (before)
      deploy:bundle
    (after)
      deploy:migrate
      deploy:compile_assets
      deploy:normalize_assets
  deploy:publishing
    deploy:symlink:release
  deploy:published
  deploy:finishing
    deploy:cleanup
  deploy:finished
    deploy:log_revision

Você pode ver os ganchos — “iniciado”, “atualizado”, “publicado” e “concluído” – que correspondem às ações “iniciar”, “publicar”, etc. Eles são usados ​​para conectar tarefas personalizadas ao fluxo com antes e depois cláusulas como vimos acima.

Observe que após a publicação, um link simbólico ‘atual’ apontando para a versão mais recente é criado ou atualizado. Se a implantação falhar em qualquer etapa, o link simbólico atual ainda aponta para a versão antiga.

Então o que aconteceu?

O modelo “execute isto e depois execute aquilo” nem sempre foi uma boa maneira de prever como seria o seu sistema após as implantações. Ferramentas como o Chef eram melhores no tratamento de sistemas extensos, porque começavam com um modelo e diziam “tornar esta configuração verdadeira”. Chef trabalhou em termos de convergência e idempotência. Foram adicionados bits ausentes, mas depois disso, a reaplicação das mesmas etapas não mudou nada. Conseqüentemente, múltiplas execuções da mesma ação não causaram efeitos colaterais ao estado.

A flexibilidade do Capistrano permitiria que desenvolvedores menos experientes construíssem torres Jenga com implantações funcionais, mas instáveis.

Por outro lado, uma única imagem Docker permitiu o controle sistemático do sistema operacional, pacotes, bibliotecas e código. Também permitiu que um laptop e um servidor em nuvem fossem tratados de forma semelhante – assim como locais para montar contêineres.

E, finalmente, o Kubernetes administrou clusters sem se preocupar com lentidão e tempos limite. Ter uma infraestrutura totalmente transparente, com capacidade de obter listas de serviços e configurações exatas necessárias para executar todos os aspectos, facilitou muito a vida das equipes de DevOps. Em vez de alterar serviços já em execução, seria possível criar novos contêineres e encerrar os antigos.

Um outro ponto crítico do Capistrano do ponto de vista moderno é que ele é construído a partir de Ruby. A linguagem Ruby está injustamente ligada à popularidade do Ruby On Rails; e isso caiu em desuso com a ascensão do Node.js e do JavaScript. No geral, outras linguagens e tendências de linguagem a ultrapassaram em popularidade: Python se tornou a linguagem de script preferida, por exemplo. As tarefas mostradas acima usam uma DSL que é efetivamente a ferramenta de construção Ruby Rake.

Alguma coisa foi perdida? Possivelmente. Ter um conjunto de tarefas personalizadas para fazer mudanças rápidas incentiva uma abordagem hacker, mas também permitido para mudanças temporárias menores baseadas em eventos. “Faça essa mudança acontecer” em vez de “Eu sempre quero que o servidor fique assim”.

Talvez seja melhor dizer que ferramentas como o Capistrano apareceram como um ponto de referência na jornada de implantação para qualquer equipe, antes que uma visão mais ampla fosse necessária. Mas mesmo sendo uma relíquia empoeirada, o Capistrano continua sendo uma excelente ferramenta modular para automatizar a implantação e manutenção de aplicações web.

Quanto a Capistrano, o lugar na Califórnia? Receio que más notícias.

A postagem Por que Capistrano foi usurpado pelo Docker e depois pelo Kubernetes apareceu pela primeira vez no The New Stack.