Proponho ler a transcrição do relatório de Alexander Sigachev da Inventos "Processo de desenvolvimento e teste com Docker + Gitlab CI"
Quem está começando a implementar o processo de desenvolvimento e teste baseado em Docker + Gitlab CI costuma fazer perguntas básicas. Por onde começar? Como organizar? Como testar?
Este relatório é bom porque fala de forma estruturada sobre o processo de desenvolvimento e teste usando Docker e Gitlab CI. O relatório em si é de 2017. Acho que com esse relatório você pode aprender o básico, a metodologia, a ideia, a experiência de uso.
Quem se importa, por favor, debaixo do gato.
Meu nome é Alexander Sigachev. Trabalho na Inventos. Vou contar sobre minha experiência com o uso do Docker e como estamos implementando gradativamente nos projetos da empresa.
Tópico da apresentação: Processo de desenvolvimento usando Docker e Gitlab CI.
Esta é minha segunda palestra sobre Docker. Na época do primeiro relatório, usávamos apenas o Docker in Development em máquinas de desenvolvedores. O número de funcionários que usavam o Docker era de cerca de 2 a 3 pessoas. Aos poucos, foi ganhando experiência e avançamos um pouco mais. Link para o nosso .
O que terá neste relatório? Compartilharemos nossa experiência sobre qual rake coletamos, quais problemas resolvemos. Nem em todos os lugares era bonito, mas permitia seguir em frente.
Nosso lema é: atracar tudo o que pudermos colocar em nossas mãos.
Que problemas estamos resolvendo?
Quando há várias equipes em uma empresa, o programador é um recurso compartilhado. Há estágios em que um programador é retirado de um projeto e dado por algum tempo para outro projeto.
Para que o programador entenda rapidamente, ele precisa baixar o código-fonte do projeto e lançar o ambiente o mais rápido possível, o que lhe permitirá avançar ainda mais resolvendo os problemas deste projeto.
Normalmente, se você começar do zero, haverá pouca documentação no projeto. Informações sobre como configurar estão disponíveis apenas para veteranos. Os funcionários montam seu local de trabalho por conta própria em um ou dois dias. Para acelerar isso, usamos o Docker.
O próximo motivo é a padronização das configurações no Desenvolvimento. Na minha experiência, os desenvolvedores sempre tomam a iniciativa. Em cada quinto caso, um domínio personalizado é inserido, por exemplo, vasya.dev. Sentado ao lado dele está seu vizinho Petya, cujo domínio é petya.dev. Eles desenvolvem um site ou algum componente do sistema usando esse nome de domínio.
Quando o sistema cresce e esses nomes de domínio começam a entrar em configurações, surge um conflito no ambiente de desenvolvimento e o caminho do site é reescrito.
O mesmo acontece com as configurações do banco de dados. Alguém não se preocupa com segurança e trabalha com uma senha de root vazia. No estágio de instalação, o MySQL pediu uma senha a alguém e a senha acabou sendo 123. Muitas vezes acontece que a configuração do banco de dados muda constantemente dependendo do commit do desenvolvedor. Alguém corrigiu, alguém não corrigiu a configuração. Houve truques quando fizemos algum tipo de configuração de teste em .gitignore e cada desenvolvedor teve que instalar o banco de dados. Isso dificultou o início. É necessário, entre outras coisas, lembrar sobre o banco de dados. O banco de dados deve ser inicializado, uma senha deve ser inserida, um usuário deve ser registrado, uma tabela deve ser criada e assim por diante.
Outro problema são as diferentes versões das bibliotecas. Muitas vezes acontece que um desenvolvedor trabalha com projetos diferentes. Existe um projeto de Legado que começou há cinco anos (de 2017 - nota do editor). No momento do lançamento, começamos com o MySQL 5.5. Existem também projetos modernos onde tentamos implementar versões mais modernas do MySQL, por exemplo, 5.7 ou mais antigas (em 2017 - nota do ed.)
Quem trabalha com MySQL sabe que essas bibliotecas trazem consigo dependências. É bastante problemático executar 2 bases juntas. Pelo menos, clientes antigos são problemáticos para se conectar ao novo banco de dados. Isso, por sua vez, cria vários problemas.
O próximo problema é quando um desenvolvedor trabalha em uma máquina local, ele usa recursos locais, arquivos locais, RAM local. Toda a interação no momento do desenvolvimento de uma solução para os problemas é realizada no âmbito do fato de funcionar em uma máquina. Um exemplo é quando temos servidores backend em Produção 3, e o desenvolvedor salva os arquivos no diretório raiz e de lá o nginx pega os arquivos para responder a requisição. Quando esse código entra em produção, verifica-se que o arquivo está presente em um dos 3 servidores.
A direção dos microsserviços está se desenvolvendo agora. Quando dividimos nossos grandes aplicativos em alguns pequenos componentes que interagem entre si. Isso permite selecionar tecnologias para uma pilha específica de tarefas. Ele também permite que você compartilhe trabalho e responsabilidades entre os desenvolvedores.
Desenvolvedor Frondend, desenvolvendo em JS, quase não tem influência no Backend. O desenvolvedor backend, por sua vez, desenvolve, no nosso caso, Ruby on Rails e não interfere no Frondend. A interação é realizada usando a API.
Como bônus, com a ajuda do Docker, conseguimos reciclar recursos no Staging. Cada projeto, por suas especificidades, exigiu determinadas configurações. Fisicamente, era necessário alocar um servidor virtual e configurá-los separadamente ou compartilhar algum tipo de ambiente variável e os projetos poderiam, dependendo da versão das bibliotecas, influenciar uns aos outros.
Ferramentas. O que usamos?
- Docker em si. O Dockerfile descreve as dependências de um único aplicativo.
- Docker-compose é um pacote que reúne alguns de nossos aplicativos Docker.
- Usamos o GitLab para armazenar o código-fonte.
- Usamos o GitLab-CI para integração do sistema.
O relatório é composto por duas partes.
A primeira parte falará sobre como o Docker foi executado nas máquinas dos desenvolvedores.
A segunda parte falará sobre como interagir com o GitLab, como executamos testes e como implementamos o Staging.
Docker é uma tecnologia que permite (usando uma abordagem declarativa) descrever os componentes necessários. Este é um exemplo de Dockerfile. Aqui declaramos que estamos herdando da imagem oficial do Ruby:2.3.0 Docker. Ele contém o Ruby versão 2.3 instalado. Instalamos as bibliotecas de compilação necessárias e o NodeJS. Descrevemos que criamos um diretório /app. Defina o diretório do aplicativo como o diretório de trabalho. Nesse diretório, colocamos o Gemfile e o Gemfile.lock mínimos necessários. Em seguida, construímos os projetos que instalam essa imagem de dependência. Indicamos que o container estará pronto para escutar na porta externa 3000. O último comando é o comando que inicia diretamente nossa aplicação. Se executarmos o comando de início do projeto, o aplicativo tentará executar e executar o comando especificado.
Este é um exemplo mínimo de um arquivo docker-compose. Neste caso, mostramos que existe uma conexão entre dois contêineres. Isso ocorre diretamente no serviço de banco de dados e no serviço da web. Nossos aplicativos da Web, na maioria dos casos, requerem algum tipo de banco de dados como back-end para armazenar dados. Como estamos usando MySQL, o exemplo é com MySQL - mas nada nos impede de usar algum outro banco de dados (PostgreSQL, Redis).
Tiramos da fonte oficial do hub Docker a imagem do MySQL 5.7.14 sem alterações. Coletamos a imagem responsável por nosso aplicativo da Web no diretório atual. Ele coleta uma imagem para nós durante o primeiro lançamento. Em seguida, executa o comando que estamos executando aqui. Se voltarmos, veremos que o comando de lançamento via Puma foi definido. Puma é um serviço escrito em Ruby. No segundo caso, substituímos. Este comando pode ser arbitrário dependendo de nossas necessidades ou tarefas.
Também descrevemos que precisamos encaminhar uma porta em nossa máquina host do desenvolvedor de 3000 para 3000 na porta do contêiner. Isso é feito automaticamente usando o iptables e seu mecanismo, que é incorporado diretamente no Docker.
O desenvolvedor também pode, como antes, acessar qualquer endereço IP disponível, por exemplo, 127.0.0.1 é o endereço IP local ou externo da máquina.
A última linha diz que o container web depende do container db. Quando chamamos o início do contêiner da web, o docker-compose iniciará primeiro o banco de dados para nós. Já no início do banco de dados (na verdade, após o lançamento do contêiner! Isso não garante a prontidão do banco de dados) será iniciado o aplicativo, nosso back-end.
Isso evita erros quando o banco de dados não é carregado e economiza recursos quando paramos o contêiner do banco de dados, liberando recursos para outros projetos.
O que nos dá o uso de dockerização de banco de dados no projeto. Corrigimos a versão do MySQL para todos os desenvolvedores. Isso evita alguns erros que podem ocorrer quando as versões divergem, quando a sintaxe, a configuração e as configurações padrão mudam. Isso permite que você especifique um nome de host comum para o banco de dados, login e senha. Estamos nos afastando do zoológico de nomes e conflitos nos arquivos de configuração que tínhamos anteriormente.
Temos a oportunidade de usar uma configuração mais ideal para o ambiente de desenvolvimento, que será diferente do padrão. O MySQL é configurado para máquinas fracas por padrão e seu desempenho imediato é muito ruim.
O Docker permite que você use o interpretador Python, Ruby, NodeJS, PHP da versão desejada. Nós nos livramos da necessidade de usar algum tipo de gerenciador de versões. Anteriormente, Ruby usava um pacote rpm que permitia alterar a versão dependendo do projeto. Ele também permite, graças ao contêiner do Docker, migrar o código sem problemas e verificá-lo junto com as dependências. Não temos problemas para entender a versão do interpretador e do código. Para atualizar a versão, baixe o container antigo e suba o novo container. Se algo der errado, podemos abaixar o novo contêiner, levantar o antigo.
Depois de construir a imagem, os contêineres em Desenvolvimento e Produção serão os mesmos. Isto é especialmente verdadeiro para grandes instalações.
No Frontend utilizamos JavaScipt e NodeJS.
Agora temos o último projeto em ReacJS. O desenvolvedor executou tudo no contêiner e desenvolveu usando hot-reload.
Em seguida, a tarefa de montagem JavaScipt é iniciada e o código compilado em estática é fornecido por meio de recursos de salvamento do nginx.
Aqui eu dei o esquema do nosso último projeto.
Quais tarefas foram resolvidas? Tínhamos a necessidade de construir um sistema com o qual os dispositivos móveis interagissem. Eles recebem dados. Uma possibilidade é enviar notificações push para este dispositivo.
O que temos feito para isso?
Dividimos na aplicação componentes como: a parte admin em JS, o backend, que funciona através da interface REST em Ruby on Rails. O back-end interage com o banco de dados. O resultado gerado é entregue ao cliente. O painel de administração interage com o back-end e o banco de dados por meio da interface REST.
Também precisávamos enviar notificações push. Antes disso, tínhamos um projeto que implementava um mecanismo responsável por enviar notificações para plataformas móveis.
Desenvolvemos o seguinte esquema: um operador do navegador interage com o painel de administração, o painel de administração interage com o back-end, a tarefa é enviar notificações push.
As notificações push interagem com outro componente que é implementado no NodeJS.
As filas são construídas e, em seguida, as notificações são enviadas de acordo com seu mecanismo.
Dois bancos de dados são desenhados aqui. No momento, com a ajuda do Docker, usamos 2 bancos de dados independentes que não estão relacionados entre si de forma alguma. Além disso, eles têm uma rede virtual comum e os dados físicos são armazenados em diferentes diretórios na máquina do desenvolvedor.
O mesmo, mas em números. É aqui que a reutilização de código é importante.
Se antes falamos sobre a reutilização de código na forma de bibliotecas, neste exemplo, nosso serviço que responde a notificações push é reutilizado como um servidor completo. Ele fornece uma API. E nosso novo empreendimento já interage com ele.
Naquela época, estávamos usando a versão 4 do NodeJS. Agora (em 2017 - nota ed.) em desenvolvimentos recentes, usamos a versão 7 do NodeJS. Não há problema em novos componentes envolverem novas versões de bibliotecas.
Se necessário, você pode refatorar e aumentar a versão NodeJS do serviço de notificação por push.
E se pudermos manter a compatibilidade da API, será possível substituí-la por outros projetos que foram usados anteriormente.
O que você precisa para adicionar o Docker? Adicionamos um Dockerfile ao nosso repositório, que descreve as dependências necessárias. Neste exemplo, os componentes são divididos logicamente. Este é o conjunto mínimo de um desenvolvedor de back-end.
Ao criar um novo projeto, criamos um Dockerfile, descrevemos o ecossistema desejado (Python, Ruby, NodeJS). No docker-compose, ele descreve a dependência necessária - o banco de dados. Descrevemos que precisamos de um banco de dados de tal e tal versão, armazenar dados ali e ali.
Usamos um terceiro contêiner separado com nginx para servir estático. É possível fazer upload de fotos. O backend os coloca em um volume pré-preparado, que também é montado em um contêiner com nginx, que fornece a estática.
Para armazenar a configuração nginx, mysql, adicionamos uma pasta Docker na qual armazenamos as configurações necessárias. Quando um desenvolvedor faz um git clone de um repositório em sua máquina, ele já tem um projeto pronto para desenvolvimento local. Não há dúvida de qual porta ou quais configurações aplicar.
Em seguida, temos vários componentes: admin, inform-API, notificações push.
Para começar tudo isso, criamos outro repositório, que chamamos de dockerized-app. No momento usamos vários repositórios antes de cada componente. Eles são apenas logicamente diferentes - no GitLab parece uma pasta, mas na máquina do desenvolvedor, uma pasta para um projeto específico. Um nível abaixo estão os componentes que serão combinados.
Este é um exemplo apenas do conteúdo de dockerized-app. Também trazemos aqui o diretório Docker, no qual preenchemos as configurações necessárias para as interações de todos os componentes. Existe um README.md que descreve brevemente como executar o projeto.
Aqui aplicamos dois arquivos docker-compose. Isso é feito para poder executar em etapas. Quando um desenvolvedor trabalha com o núcleo, ele não precisa de notificações push, ele simplesmente inicia um arquivo docker-compose e, consequentemente, o recurso é salvo.
Se houver necessidade de integração com notificações por push, docker-compose.yaml e docker-compose-push.yaml serão iniciados.
Como docker-compose.yaml e docker-compose-push.yaml estão em uma pasta, uma única rede virtual é criada automaticamente.
Descrição dos componentes. Este é um arquivo mais avançado que é responsável pela coleção de componentes. O que é notável aqui? Aqui apresentamos o componente balanceador.
Esta é uma imagem do Docker pronta que executa o nginx e um aplicativo que escuta no soquete do Docker. Dinâmico, conforme os contêineres são ativados e desativados, ele regenera a configuração do nginx. Distribuímos o manuseio de componentes por nomes de domínio de terceiro nível.
Para o ambiente de Desenvolvimento, utilizamos o domínio .dev - api.informer.dev. Aplicativos com domínio .dev estão disponíveis na máquina local do desenvolvedor.
Além disso, as configurações são transferidas para cada projeto e todos os projetos são iniciados juntos ao mesmo tempo.
Graficamente, verifica-se que o cliente é nosso navegador ou alguma ferramenta com a qual fazemos solicitações ao balanceador.
O balanceador de nome de domínio determina qual contêiner contatar.
Pode ser nginx, que dá ao administrador JS. Isso pode ser nginx, que fornece a API, ou arquivos estáticos, que são fornecidos ao nginx na forma de uploads de imagens.
O diagrama mostra que os containers estão conectados por uma rede virtual e escondidos atrás de um proxy.
Na máquina do desenvolvedor você pode acessar o container sabendo o IP, mas a princípio não usamos isso. Praticamente não há necessidade de acesso direto.
Qual exemplo observar para dockerize seu aplicativo? Na minha opinião, um bom exemplo é a imagem oficial do docker para o MySQL.
É bastante desafiador. Existem muitas versões. Mas sua funcionalidade permite cobrir muitas necessidades que possam surgir no processo de desenvolvimento. Se você gastar tempo e descobrir como tudo interage, acho que não terá problemas na auto-implementação.
Hub.docker.com geralmente contém links para github.com, que contém dados brutos diretamente dos quais você mesmo pode criar a imagem.
Além disso, neste repositório, há um script docker-endpoint.sh, que é responsável pela inicialização inicial e pelo processamento posterior do lançamento do aplicativo.
Também neste exemplo, há a possibilidade de configurar usando variáveis de ambiente. Ao definir uma variável de ambiente ao executar um único contêiner ou por meio do docker-compose, podemos dizer que precisamos definir uma senha vazia para o docker fazer root no MySQL ou o que quisermos.
Existe uma opção para criar uma senha aleatória. Dizemos que precisamos de um usuário, precisamos definir uma senha para o usuário e precisamos criar um banco de dados.
Em nossos projetos, unificamos um pouco o Dockerfile, responsável pela inicialização. Lá nós o corrigimos para nossas necessidades para torná-lo apenas uma extensão dos direitos do usuário que o aplicativo usa. Isso nos permitiu simplesmente criar um banco de dados a partir do console do aplicativo posteriormente. Os aplicativos Ruby possuem um comando para criar, modificar e excluir bancos de dados.
Este é um exemplo de como uma versão específica do MySQL se parece no github.com. Você pode abrir o Dockerfile e ver como está indo a instalação lá.
docker-endpoint.sh é o script responsável pelo ponto de entrada. Durante a inicialização inicial, algumas etapas de preparação são necessárias e todas essas ações são executadas apenas no script de inicialização.
Passamos para a segunda parte.
Para armazenar os códigos-fonte, mudamos para o gitlab. Este é um sistema bastante poderoso que possui uma interface visual.
Um dos componentes do Gitlab é o Gitlab CI. Ele permite que você descreva uma sequência de comandos que serão usados posteriormente para organizar um sistema de entrega de código ou executar testes automáticos.
Gitlab CI 2 palestra - relatório do clube Ruby Russia - bastante detalhado e talvez lhe interesse.
Agora veremos o que é necessário para ativar o Gitlab CI. Para iniciar o Gitlab CI, basta colocar o arquivo .gitlab-ci.yml na raiz do projeto.
Aqui descrevemos que queremos executar uma sequência de estados como um teste, implantar.
Executamos scripts que chamam diretamente docker-compose para construir nosso aplicativo. Este é apenas um exemplo de back-end.
Em seguida, dizemos que é necessário fazer migrations para alterar o banco de dados e fazer testes.
Se os scripts forem executados corretamente e não retornarem um código de erro, o sistema seguirá para o segundo estágio da implantação.
O estágio de implantação está atualmente implementado para preparo. Não organizamos uma reinicialização com tempo de inatividade zero.
Extinguimos à força todos os contêineres e, em seguida, levantamos todos os contêineres novamente, coletados no primeiro estágio durante o teste.
Já executamos para a variável de ambiente atual as migrações de banco de dados que foram escritas pelos desenvolvedores.
Há uma observação de que isso se aplica apenas à ramificação master.
Ao alterar outras ramificações não é executado.
É possível organizar rollouts por filiais.
Para organizar ainda mais, precisamos instalar o Gitlab Runner.
Este utilitário é escrito em Golang. É um único arquivo, como é comum no mundo Golang, que não requer nenhuma dependência.
Na inicialização, registramos o Gitlab Runner.
Obtemos a chave na interface da web do Gitlab.
Em seguida, chamamos o comando de inicialização na linha de comando.
Configure o Gitlab Runner interativamente (Shell, Docker, VirtualBox, SSH)
O código no Gitlab Runner será executado em cada confirmação, dependendo da configuração do .gitlab-ci.yml.
Como fica visualmente no Gitlab na interface da web. Depois de conectarmos o GItlab CI, temos um sinalizador que mostra o estado da compilação no momento.
Vemos que um commit foi feito há 4 minutos, que passou em todos os testes e não causou nenhum problema.
Podemos dar uma olhada mais de perto nas construções. Aqui vemos que dois estados já passaram. Testando o status e o status da implantação na preparação.
Se clicarmos em uma compilação específica, haverá uma saída do console dos comandos que foram executados no processo de acordo com .gitlab-ci.yml.
É assim que nosso histórico de produtos se parece. Vemos que houve tentativas bem-sucedidas. Quando os testes são enviados, ele não avança para a próxima etapa e o código de preparação não é atualizado.
Quais tarefas resolvemos na preparação quando implementamos o docker? Nosso sistema é composto por componentes e tivemos a necessidade de reiniciar, apenas parte dos componentes que foram atualizados no repositório, e não todo o sistema.
Para fazer isso, tivemos que esmagar tudo em pastas separadas.
Depois que fizemos isso, tivemos um problema com o fato de que o Docker-compose cria seu próprio espaço de rede para cada pai e não vê os componentes do vizinho.
Para contornar, criamos a rede no Docker manualmente. Foi escrito no Docker-compose que você usa essa rede para este projeto.
Assim, cada componente que começa com esta malha vê componentes em outras partes do sistema.
O próximo problema é dividir a preparação em vários projetos.
Pois para que tudo isso fique bonito e o mais próximo possível da produção, é bom utilizar a porta 80 ou 443, que é utilizada em toda WEB.
Como resolvemos isso? Atribuímos um Gitlab Runner a todos os principais projetos.
O Gitlab permite que você execute vários Gitlab Runners distribuídos, que simplesmente realizarão todas as tarefas de maneira caótica e as executarão.
Para não termos casa, limitamos o grupo de nossos projetos a um Gitlab Runner, que lida sem problemas com nossos volumes.
Movemos o nginx-proxy para um script de inicialização separado e adicionamos grades para todos os projetos nele.
Nosso projeto tem uma grade e o balanceador tem várias grades por nomes de projeto. Ele pode fazer proxy ainda mais por nomes de domínio.
Nossas solicitações passam pelo domínio na porta 80 e são resolvidas em um grupo de contêineres que atende a esse domínio.
Que outros problemas havia? Isso é o que todos os contêineres executam como root por padrão. Isso é raiz diferente do host raiz do sistema.
No entanto, se você entrar no contêiner, ele será root e o arquivo que criamos neste contêiner obtém direitos de root.
Se o desenvolvedor entrou no container e fez alguns comandos lá que geram arquivos, depois saiu do container, então ele tem um arquivo em seu diretório de trabalho ao qual ele não tem acesso.
Como pode ser resolvido? Você pode adicionar usuários que estarão no container.
Que problemas surgiram quando adicionamos o usuário?
Ao criar um usuário, geralmente não temos o mesmo ID de grupo (UID) e ID de usuário (GID).
Para resolver esse problema no container, utilizamos usuários com ID 1000.
No nosso caso, isso coincidiu com o fato de quase todos os desenvolvedores usarem o sistema operacional Ubuntu. E no Ubuntu, o primeiro usuário tem um ID de 1000.
Temos planos?
Leia a documentação do Docker. O projeto está se desenvolvendo ativamente, a documentação está mudando. Os dados recebidos há dois ou três meses já estão lentamente ficando desatualizados.
Alguns dos problemas que resolvemos possivelmente já foram resolvidos por meios padrão.
Então eu quero ir mais longe para ir direto para a orquestração.
Um exemplo é o mecanismo interno do Docker chamado Docker Swarm, que vem pronto para uso. Eu quero rodar algo em produção baseado na tecnologia Docker Swarm.
A geração de contêineres torna inconveniente trabalhar com logs. Agora os logs estão isolados. Eles estão espalhados em contêineres. Uma das tarefas é facilitar o acesso aos logs por meio da interface da web.
Fonte: habr.com