Cristiano dos Santos Diedrich
Cristiano dos Santos Diedrich, Operations Lead na Umbler

Containers #4: Boas práticas

Oi gente, tudo bem? Vamos ao quarto post da nossa série! Hoje vamos conversar um pouco sobre coisas que você deve e não deve fazer se quiser trabalhar com containers.

A gente já viu:

 

Certo?

Então, nada melhor do que fazer isso seguindo as melhores práticas do mercado, e é justamente isso que abordaremos a seguir 😉

Dockerfile

Você pode criar um Dockerfile da forma que quiser, afinal, ele é um descritivo de sua infraestrutura. Nele estão os passos a serem seguidos para criar o seu ambiente para atender a necessidade da sua aplicação. Um ponto muito importante nesse processo é que se você fizer de qualquer jeito, o build pode levar 5 segundos ou 40 minutos. Ou pior ainda, a imagem gerada pode ser tão grande quanto um host comum, o que é muito ruim, principalmente por ferir um dos princípios de se utilizar container, que é a portabilidade.

Então, observe os seguintes pontos:

  • Utilize o mínimo de instruções possíveis. Se precisar executar mais de um comando, crie um shell script que faça isso e chame-o em uma instrução RUN;
  • Em ordem, coloque sempre as instruções que nunca mudem no início do arquivo, isso fará com que seu build seja muito mais rápido;
  • Faça uso do multi-stage build sempre que possível;
  • Nunca faça update/upgrade, isso garante que você utilizará sempre a mesma imagem base para o build;

Imagem

Podemos chamar de imagem o artefato criado pelo processo de build do Docker, essa imagem deve ser independente e reutilizável, ou seja, eu posso pegar essa imagem e enviar para qualquer host e executá-la apenas com o comando docker run. Com isso, vamos as dicas quando falamos em imagens:

  • Sempre utilize um hub para suas imagens Docker, fazer com que ela esteja apenas nos nós é ruim, pois caso o host falhe, você não poderá reutilizar essa imagem. Então, sempre opte por ter um hub central, seja open source ou não.
  • Sempre que possível, utilize ferramentas para analisar a segurança das imagens que você utiliza.
  • Nunca salve dados sensíveis dentro da imagem, existem outras formas melhores para resolver isso, ok?

Container

Como já sabemos, container nada mais é do que um processo isolado, baseado em uma imagem construída para atender uma necessidade específica. Pois bem, existem algumas dezenas de dicas para essa “parte” do ambiente, vamos falar sobre as quais eu considero mais importantes. Bora:

  • Sempre que possível execute o container com um usuário restrito, apenas do Docker, para garantir o isolamento entre os containers e tudo mais. É melhor dificultar o caminho para quem está mal intencionado, certo? E para fazer isso é bem fácil: parâmetro -u no docker container create ou docker run 😉
  • Não salve nada dentro do container, utilize um volume para isso;
  • Opte sempre por utilizar um plugin de logs, isso facilita a administração do ambiente;
  • Não deixe sujeira. Utilize o docker system prune para remover aqueles containers que estão parados há tempos;
  • Limite, sempre que possível, a utilização de recursos de cada container;
  • Utilize um container para cada serviço, se tem MongoDB e Node.JS, por exemplo, utilize dois containers, e assim por diante;
  • Esteja preparado para perder o container. Essa talvez seja a dica não técnica mais importante, pois um container NÃO tem uma vida útil longa. Então, pense em como sobreviver no caso de um dos containers sumir 🙂

API

A parte mais interessante do Docker é a possibilidade de integração com outras ferramentas. Isso é possível graças ao API que ele disponibiliza para uso. Por ela é possível executar exatamente as mesmas coisas do que a CLI, visto que a CLI é apenas uma interface para a API. Tudo muito lindo, né? Mas, mesmo assim, vamos ver como melhorar isso:

  • Exponha somente se for realmente necessário. A API do Docker não possuí diversos recursos básicos de segurança, então exponha ela apenas em casos realmente necessários.
  • Opte sempre por um “proxy” para se comunicar com a API, dessa forma você pode prover alguns recursos, como certificado SSL e autenticação básica
  • Tenha cuidado com qual versão está utilizando, como os parâmetros podem mudar de versão para versão, não use a latest, opte sempre por especificar uma versão. Com isso você garante que suas chamadas retornarão o esperado.

Rede

Rede é mais um componente no ambiente todo que o Docker provê para você executar suas aplicações de forma isolada. Em ambiente de desenvolvimento o impacto é bem menor, mas se for pensar em utilizar Docker na produção, existem alguns pontos que você deve levar em consideração:

  • A bridge default do Docker permite que você crie até 1024 containers, esta é uma limitação do kernel do Linux e não do Docker. Caso você precise de mais, pense em utilizar o OpenvSwitch;
  • Para ter um melhor isolamento entre os containers, pense em utilizar uma rede do Docker para cada Stack. Por exemplo: uma rede para o ambiente de api e banco que ela utiliza, e outra rede para o site e outro banco.
  • Caso você deseje ter um cluster (usando Swarm, por exemplo), tente utilizar uma interface para o cluster e outra para acessos externos aos serviços;
  • Quando possível, utilize um serviço de IPAM externo para gerenciar melhor os recursos de IP dentro do host ou cluster.

Segurança

Olha que louco, não falaremos sobre segurança, mas isso é por um motivo óbvio. Em cada um dos itens, há algum ponto que fala sobre segurança, reforço isso pois segurança, independente do ambiente, tem que ser algo natural, e não algo externo a ser feito. Se, em cada ponto do ambiente for tratado segurança, no final das contas estaremos com o ambiente todo seguro. Lógica inegável, correto?

Existem muitos outros pontos que você pode estar com dúvidas, isso é natural e até mesmo esperado. Por isso, se você tem algo para contribuir não deixe de nos avisar, combinado?

Por ora, era isso, Abraço!

Cristiano dos Santos Diedrich
Cristiano dos Santos Diedrich, Operations Lead na Umbler