Você finalmente se rendeu à mercê dos contêineres e descobriu que eles resolvem muitos problemas e têm muitas vantagens:
- Os contêineres são inabaláveis: SO, bibliotecas, pastas e aplicativos - como tudo isso é armazenado diretamente no contêiner, você tem 100% de certeza de que a imagem que foi testada no controle de qualidade sempre estará em produção. E funcionará exatamente da mesma maneira.
- Recipientes leves: um contêiner não desperdiça memória. Em vez de centenas de megabytes e gigabytes, um contêiner precisa apenas de memória para o processo principal.
- Os contêineres são rápidos: um contêiner é iniciado tão rápido quanto um processo normal do Linux. Não minutos, mas literalmente segundos.
No entanto, muitos ainda acreditam que os contêineres são máquinas virtuais e esquecem sua propriedade mais importante ...
Recipientes efêmeros
A descartabilidade é o motivo pelo qual você deve mudar sua abordagem de como lidar com contêineres.
E aqui está o que em nenhum caso deve ser feito para não perder as vantagens dos contêineres:1. Não há necessidade de armazenar dados dentro do contêiner. Durante o ciclo de vida, os contêineres podem ser suspensos, destruídos e substituídos. Se o aplicativo for executado em um contêiner, a versão 1.0 desse aplicativo deverá mudar facilmente para a versão 1.1 sem perda de dados e outros problemas. Portanto, se você deseja salvar dados, eles devem ser escritos nele. No entanto, você deve tomar cuidado para que os dois contêineres não gravem no mesmo local para não danificar os dados. Portanto, verifique se os aplicativos gravam corretamente os dados no armazenamento compartilhado.
2. Não há necessidade de dividir a entrega do aplicativo. Algumas pessoas pensam que um contêiner é a mesma máquina virtual. E a maioria deles acredita que os aplicativos devem ser implantados em contêineres existentes. De fato, isso também é possível, especialmente na fase de desenvolvimento, quando há depuração e implantação constantes. Mas eles devem inserir o CD-ROM de entrega contínua para transferência para o departamento de controle de qualidade ou produção apenas como parte de sua própria imagem. Lembre-se: os contêineres são inabaláveis.
3. Não há necessidade de criar imagens grandes. Uma imagem grande é mais difícil de distribuir. Portanto, a imagem deve incluir apenas os arquivos e bibliotecas realmente necessários para iniciar o processo de aplicação. Não há necessidade de instalar pacotes desnecessários ou executar atualizações (yum update), que criam uma nova camada na imagem e gravam muitos arquivos nela.
4. Não use recipientes de camada única. Para usar efetivamente sistemas de arquivos de várias camadas (vários níveis), sempre crie camadas separadas para o SO, para definição de nome de usuário, para configuração e, finalmente, para o próprio aplicativo. Portanto, será mais fácil recriar, manter e distribuir imagens.
5. Não há necessidade de criar imagens a partir de contêineres em execução. Em outras palavras, não use o comando docker commit para criar uma imagem, pois essas imagens não serão reproduzíveis. Em vez disso, sempre use um Dockerfile ou outras ferramentas S2I (fonte para imagem) que forneçam reprodutibilidade. Além disso, no Dockerfile, você pode rastrear facilmente as alterações se armazená-las no repositório de origem (git).
6. Não há necessidade de usar apenas a tag mais recente. Essa tag é algo como INSTANTÂNEO para usuários do Maven. Devido à natureza de várias camadas do sistema de arquivos do contêiner, as tags são muito úteis. No entanto, você pode esperar uma surpresa desagradável quando, por exemplo, após uma pausa de meses, decide coletar uma imagem e descobre subitamente que o aplicativo não é mais iniciado porque a camada pai (FROM no idioma do Dockerfile) foi substituída por uma nova versão que não oferece compatibilidade com versões anteriores. Ou porque a versão errada foi recuperada do cache de construção que você estava esperando. Além disso, a tag mais recente também deve ser evitada ao implantar contêineres na produção, pois você não poderá rastrear qual versão da imagem está sendo iniciada.
7. Não há necessidade de executar mais de um processo em um contêiner. Os contêineres são ideais para um único processo (daemon http daemon, servidor de aplicativos, DBMS). Caso contrário, você poderá encontrar todos os tipos de problemas, como cavar nos logs ou atualizar processos separadamente.
8. Não há necessidade de armazenar credenciais em uma imagem - use variáveis de ambiente para isso. Não prescreva logins e senhas na imagem. Em vez disso, use variáveis de ambiente para extrair dados relevantes de fontes externas ao contêiner. A imagem do Postgres é um ótimo exemplo de como fazer isso corretamente.
9. Não há necessidade de executar processos como root. “Por padrão, os contêineres do docker são executados como raiz. (...) No entanto, à medida que a tecnologia evolui, outras opções de inicialização padrão mais seguras podem aparecer. Sob as condições atuais, o requisito raiz pode ser considerado uma ameaça e pode não ser fornecido em todos os ambientes. Para especificar um usuário que não seja root, em nome do qual o contêiner será iniciado, a diretiva USER será usada ”(Trecho do Guidance for Docker Image Authors)
10. Não há necessidade de confiar em endereços IP. Cada contêiner possui seu próprio endereço IP interno, que pode mudar após o reinício do contêiner. Se o aplicativo ou microsserviço precisar se comunicar com outro contêiner, use variáveis de ambiente para transferir o nome do host desejado para o número da porta de um contêiner para outro.
Você se lembra? Agora você pode usá-lo com segurança. E dicas práticas para o uso de contêineres podem ser encontradas em nosso blog.