A Google divulgou como open source uma implementação de exemplo (baseada em Kubernetes) sobre como automatizar a geração de imagens customizadas para o Google Compute Engine utilizando Jenkins e Packer. Sendo o objetivo principal do trabalho, demonstrar como adicionar a geração de imagem no pipeline de builds para entrega contínua, e produzir artefatos que podem fornecer maior confiabilidade e reduzir a velocidade da inicialização da máquina virtual (VM).
O blog da Google Cloud Platform sugere que muitas aplicações publicáveis na nuvem requerem provisionamento de uma instância de máquina virtual personalizada. Exemplos desse tipo de provisionamento incluem: a configuração do sistema operacional, a instalação de pacotes de linguagens e a manipulação dos arquivos de logs para a instância.
Existem várias abordagens para provisionamento, incluindo o método tradicional de se conectar a cada VM via SSH e executar comandos arbitrários. O processo de se conectar e executar os comandos é propenso a erros (muitas vezes criando servidores 'snowflake').
A outra abordagem é conhecida como 'automated sysadmin', que utiliza ferramentas de provisionamento tais como Puppet, Chef ou Ansible para configuração durante o processo de inicialização da VM. Esse processo com as ferramentas de provisionamento podem resultar em um tempo de instalação demorado ou ser afetado pela disponibilidade do repositório que hospeda os pacotes a serem instalados no momento que a máquina estiver sendo inicializada.
Uma alternativa para reduzir tempo de inicialização de provisionamento da instância é criar uma imagem base customizada da VM, utilizando uma ferramenta como o Packer. Portanto, uma única vez é realizado o provisionamento de uma instância, que é basicamente um 'snapshot' criado para inicializar um número arbitrário de VMs quando necessário. O processo evita a necessidade de provisionar uma instância durante a inicialização da VM, também pode aumentar a confiabilidade e reduzir o tempo de inicialização, como mostrado na imagem a seguir:
Diferente da imagem base, a imagem imutável tem todo software necessário incluído na imagem. Quando a instância ou container é iniciado a partir da imagem, não há nenhum pacote para realizar download ou softwares para instalar. Esse processo consiste de cada versão do seu software, construir uma imagem com tudo que é necessário para rodar a aplicação.
A equipe da Google Cloud Platform também lançou um artigo técnico e uma implementação de referência de código aberto que descreve em detalhes como automatizar a construção de imagens usando tecnologias como: Jenkins, Packer e Kubernetes. Esta implementação de referência pode ser utilizada como um modelo para construir continuamente imagens para o GCE ou aplicações baseadas em Docker. As imagens são construídas no projeto, e em seguida podem ser compartilhadas com outros projetos dentro de uma organização. O blog da Google Cloud Platform sugere que o processo automatizado de geração de imagem seja integrado como um passo na ferramenta de integração contínua (IC).
A InfoQ.com conversou com Evan Brown, arquiteto de soluções da Google Cloud Platform, e fez diversas perguntas sobre a construção automatizada de imagens descrita no artigo técnico e sobre implementação de referência.
InfoQ.com: Foi fornecido um projeto com pipeline de integração contínua de código completamente aberto para container/cloud, em comparação com outros fornecedores de soluções para SaaS. Qual sua opinião sobre isso?
Brown: Tínhamos dois objetivos em mente quando criamos a solução. Primeiro: o tema da construção de imagens customizadas tem estado presente assim como o tema da nuvem. E nesta solução, queríamos abordar imagens customizadas - especialmente imagens imutáveis - nesse momento que containers são bem populares, e VMs ainda são importantes. Como podemos ajudar nossos clientes a fazer este processo de automatização da criação de imagens imutáveis, sendo útil para ambos Google Compute Engine e containers Docker?; Segundo: fazer mais do que um material filosófico sobre como esta aplicação deveria ser, ao invés disso, proporcionar uma implementação funcional, com código aberto para que os clientes pudessem utilizar e compreender os conceitos.
InfoQ.com: A implementação de referência está utilizando ferramentas de código aberto como Jenkins e Hashicorp's Packer. Foi uma decisão consciente para acelerar este trabalho, em vez de desenvolver alguma coisa proprietária?
Brown: Utilizar o Jenkins e Packer na implementação foi uma decisão consciente. Na verdade, um pouco de trabalho braçal foi feito meses atrás com uma contribuição da Google para Packer, como também através da contribuição da Google em vários plugins de código aberto para Jenkins. Contribuimos para projetos que os clientes utilizam e adoram, e é empolgante usar esses projetos para tratar o problema da automação de imagens imutáveis que é novo.
InfoQ.com: O pipeline atualmente só oferece implantação para Kubernetes - há interesse em apoiar outras plataformas que funcionam no Google Cloud Platform, como o framework Mesos?
Brown: A implementação de referência no GitHub é projetada para ser executada sobre Kubernetes e a Engine do Google Container, mas as três imagens Docker (nginx-ssl, jenkins-gcp-leader e jenkins-packer-agent) que permitem o a funcionalidade principal podem ser executadas sempre que é iniciar o Docker, incluindo o Mesos. Escolhemos Container Engine porque daria um cluster Kubernetes em cerca de 3 minutos e deixa parar ainda mais rápido. Isso significa que um cliente pode pegar e usar esse exemplo, e derrubar todas as máquina para subir novamente em menos de meia hora. E no dia seguinte eles podem ajustar algumas coisas para adequar o ambiente, levantar o cluster novamente e experimentar um pouco mais.
Além disso, uma parte do projeto foi construido para ser executado em Kubernetes. Existem três camadas - o proxy nginx que provê o TLS, o Jenkins na interface de usuário e os agentes de build do Jenkins - que são facilmente representados como containers Docker e o Kubernetes apenas tornou simples realizar a publicação e gerenciá-los. Além disso, há uma grande quantidade trabalho interessante feito pelo Carlos Sanchez no plugin de Kubernetes para Jenkins.
InfoQ.com: Se algum leitor do InfoQ desejar contribuir para este projeto, qual é a melhor maneira de se envolver?
Brown: Uma contribuição pode ser algum código ou até mesmo melhorias na documentação - então realize o fork do repositório no GitHub e envie um pull request. Outras contribuições valiosas são registro de bugs encontrados ou pedidos de funcionalidade - estamos rastreando as issues no GitHub. E também é possível me contactar via Twitter, @evandbrown, se sua contribuição ou comentário couber em 140 caracteres.
InfoQ.com: Muito obrigado pelo seu tempo. Há mais alguma coisa que gostaria de compartilhar com os leitores da InfoQ?
Brown: Obrigado pelas perguntas! Tenho que enfatizar para os leitores que esta solução e implementação que publicamos foi uma junção de incríveis projetos de código aberto, incluindo Packer, Jenkins, Kubernetes, Docker e outros ótimos plugins do Jenkins (Plugin Swarm, Google Storage Plugin, Google Source Plugin, Google Metadata Plugin e Google OAuth Plugin). Se tiver alguma ideia para melhorar, ou apenas está procurando contribuir com códigos ou documentação, esses são ótimos projetos para se começar.
Mais informações sobre a implementação de referência para automatização de imagens da Google podem ser encontrada no blog Google Cloud Platform, ou no repositório do projeto de referência armazenado no Github.