Docker: dicas e truques na utilização de containers - Parte 3
Neste artigo dou continuidade à série que iniciei em Agosto/2019, com dicas e truques na utilização de containers Docker.
Caso não tenha ainda lido os 2 primeiros posts ou gostaria de revê-los acesse os mesmos no link a seguir:
Docker: dicas e truques na utilização de containers — Parte 1
Docker: dicas e truques na utilização de containers — Parte 2
E aproveito este espaço e o grande interesse por Docker também para um convite.
Tem interesse em conhecer mais sobre Docker? Que tal então fazer um curso completo, cobrindo desde fundamentos a diferentes possibilidades de uso de containers com tecnologias em alta no mercado? Adquira conhecimentos profundos sobre Docker, evolua e se diferencie no mercado, seja você um profissional DevOps, um Desenvolvedor ou um Arquiteto de Software!
Acompanhe o portal Docker Definitivo para ficar por dentro de novidades a serem anunciadas em breve!
Alpine Linux: imagens com o mínimo necessário e um menor tamanho
O uso e geração de imagens baseadas em Alpine Linux constitui uma opção extremamente interessante, já que esta distribuição conta com o mínimo necessário para uma aplicação/serviço executar. Como resultado temos a obtenção de imagens menores, o que agiliza bastante o download das mesmas e o processo de deployment de aplicações.
A seguir está um comparativo entre as imagens do runtime do ASP.NET Core 3.0 em sua versão normal e Alpine. Nota-se que a imagem Alpine é quase 100 MB menor:
E qual a diferença na prática entre estas 2 imagens? Vários componentes da imagem convencional não foram incluídos no build da versão Alpine: um bom exemplo disto é o Bash, utilitário de linha de comando útil para nos conectarmos a um container em execução (nem sempre isto será uma necessidade).
Criei inclusive recentemente uma aplicação ASP.NET Core 3.0 e disponibilizei a mesma como uma imagem Alpine (utilizando o runtime correspondente do ASP.NET Core) no Docker (renatogroffe/apicontagem-3–0-alpine). Como demonstra o próximo print a imagem em questão é relativamente, com apenas 105 MB:
O NGINX também constitui um ótimo exemplo de diferença significa entre o tamanho de uma imagem normal e sua versão Alpine (de 126 MB para 21.2 MB):
Configurando um container para reinicializar automaticamente
Ao empregar o parâmetro --restart always durante a criação de um container estaremos configurando o mesmo de forma que reinicie automaticamente, com isto acontecendo toda vez que o Docker for reinicializado (durante o reboot do sistema operacional ou, mesmo, de maneira forçada).
Ao criar um container como o indicado na listagem a seguir:
Podemos visualizar via Portainer que a política de reinicialização deste container foi configurada como Always (sempre reiniciar):
Atalhos utilizando o ID de um container
Além do nome completo de um container, podemos manipular um recurso deste tipo em linha de comando empregando seu ID ou parte desta identificação. É o que demonstrar os seguintes testes executados via PowerShell:
Azure Web App for Containers: deployment descomplicado de Web Apps containerizadas
O Azure Web App for Containers é um serviço que integra a plataforma de cloud computing da Microsoft e que possibilita o deployment de aplicações Web baseadas em containers Docker. Trata-se na verdade de uma variação do Azure App Service, a qual foi adaptada para o trabalho com Docker (criando um recurso do App Service também conseguimos configurar o uso de containers).
Importante destacar que este serviço conta com funcionalidades que viabilizam o deployment automatizado de projetos, suporta imagens Windows e Linux, vem com HTTPS habilitado por default, assim como permite escalar sem grandes dificuldades uma aplicação (através de múltiplos containers executando a mesma).
Na imagem a seguir temos o assistente para criação de um novo recurso do Web App for Containers no Portal do Azure:
Na próxima tela serão realizados os seguintes ajustes de configuração:
- Preencher um grupo de recursos em Resource Group;
- Em Name informar o nome do recurso, que servirá de base para a geração de um endereço de acesso à aplicação Web (tomando por base o domínio azurewebsites.net);
- Em Publish manter selecionada a opção Docker Image;
- Escolher a opção Linux em Operation System;
- Selecionar um dos data centers disponíveis em Region;
- Selecionar ou criar um novo Service Plan em Linux Plan;
- Temos ainda a opção de configurar aspectos como a memória alocada para execução da aplicação em Sku and size.
Avançando teremos a seção Docker, em que serão preenchidas as seguintes configurações:
- Em Options manter selecionada a alternativa Single Container;
- Em Image Source escolher Docker Hub;
- Em Access Type certificar-se de que está marcada a opção Public;
- Em Image and tag informar o valor renatogroffe/apicontagem-3–0-alpine:latest (trata-se de uma API REST criada com o ASP.NET Core 3.0 e na qual se empregou uma imagem Alpine durante o build).
Aparecerá finalmente um sumário; encerrar este procedimento acionando a opção Create:
Um aviso será então exibido indicando que o deployment teve sucesso:
Ao acessar o recurso constará a URL do mesmo (destacada em vermelho):
Um teste enviando uma requisição a esta aplicação (uma API REST) trará como resultado:
Utilizando variáveis de ambiente no Azure Web App for Containers
Variáveis de ambiente constituem um importante mecanismo voltado à configuração de containers Docker. Podemos preencher estas definições no Azure Web App for Containers navegando até a seção Configuration de um recurso desse tipo:
Para atribuir um valor a uma variável de ambiente acionar a opção New application setting em Application settings:
Preencher os campos Name e Value com o nome da variável e seu valor, respectivamente; confirmar este procedimento acionando o botão OK:
E finalmente concluir este ajuste clicando no botão Save:
Após alguns segundos os containers correspondentes à aplicação (até este momento somente um) serão regerados. É o que demonstra a próxima imagem, na qual o campo machineName contém o ID do container e em variavel está o valor preenchido via Portal do Azure:
Escalando horizontalmente uma aplicação no Azure Web App for Containers
O Azure Web App for Containers oferece tanto a possibilidade de escalar verticalmente uma aplicação (através de ajustes envolvendo alocação de mais memória e recursos de processamento), quanto horizontalmente (adicionando novas instâncias/containers de uma aplicação).
Quando optamos por escalar de maneira horizontal uma Web App temos a opção de realizar este procedimento de forma manual (selecionando um número de instâncias com um limite que dependerá das configurações do Service Plan ) ou com uma regra de autoscale (mediante o uso de algum tipo de métrica como uso de memória ou CPU).
Nesta seção demonstrarei como escalar de maneira horizontal a Web App apresentada nas seções anteriores. Acessarei para isto a opção Scale out (App Service plan):
Manter selecionada a opção Manual scale, aumentando o valor de Instance count para 3 em Override condition. Concluir este procedimento acionando o botão Save:
E quanto ao Load Balancer? No Web App for Containers (assim como no próprio Azure App Service) este mecanismo vem automaticamente configurado, simplificando em muito o processo de escalar uma aplicação.
Um teste de envio de requisições com o utilitário cURL via Bash + Cloud Shell no Portal do Azure:
Exibirá 3 containers recebendo e processando as solicitações HTTP enviadas à API REST de testes:
Para concluir este post deixo a gravação (que pode ser assistida gratuitamente) de uma live do Canal .NET detalhando na prática algumas das orientações aqui apresentadas, bem como diversas outras dicas: