Os recipientes do docker devem ser tratados como gado, não animais de estimação. Isso significa que sua criação, configuração, gerenciamento e descarte devem ser automatizados de cima para baixo. Não criamos e configuramos recipientes individuais. Em vez disso, escalamos horizontalmente, girando mais recipientes.

Escala horizontal refere -se a aumentar mais computadores, eu.E, VMs, recipientes ou servidores físicos para acomodar qualquer aumento nas demandas. Isso contrasta com a escala 'verticalmente', que geralmente se refere à substituição de uma máquina mais lenta (com memória e armazenamento menor) por um rápido 'maior' um.

Com o escalonamento de contêineres de ambos os tipos, tornou -se muito dinâmico. Você pode definir cotas para aplicativos específicos, definindo a quantidade de CPU, memória ou armazenamento que eles podem ter acesso. Esta cota pode ser alterada para aumentar ou diminuir conforme necessário. Da mesma forma, você pode escalar horizontalmente, aumentando mais recipientes que acomodarão um aumento na demanda e, posteriormente, destruindo o excesso de contêineres que você criou. Se você estiver usando serviços hospedados em nuvem que o cobra por hora (ou minuto), isso pode reduzir substancialmente suas contas de hospedagem.

Neste artigo, focaremos apenas em escala horizontal, que não é tão dinâmica quanto a descrição acima, mas é um bom ponto de partida para alguém aprender o básico. Então vamos começar.

Escala através da CLI do Docker-Compose

Quando você inicia sua pilha de aplicativos, passando seu arquivo de composição para a CLI Docker-Compose você pode usar a bandeira -escala Para especificar a escalabilidade de qualquer serviço específico especificado lá.

Por exemplo, para o meu arquivo do Docker-Compose:

Versão: "3"
Serviços:
rede:
Imagem: "Nginx: mais recente"
Portas:
- "80-85: 80"
$ Docker -Compõe Up -d -Web em escala = 5

Aqui, o serviço é chamado de Web na declaração da YML, mas pode ser qualquer componente individual de sua implantação, eu.E, front-end da web, banco de dados, daemon de monitoramento, etc. A sintaxe geral exige que você escolha um dos elementos na seção de serviços de nível superior. Também dependendo do seu serviço, você pode ter que modificar outras partes do script. Por exemplo, a gama 80-85 de portas host são dadas para acomodar 5 instâncias de contêineres Nginx, todos ouvindo em sua porta interna 80, mas o host ouve portas que variam de 80-85 e redireciona o tráfego de cada porta exclusiva para uma das das Instâncias Nginx.

Para ver qual contêiner obtém qual número da porta você pode usar o comando:

$ docker ps -a
Comando de imagem de identificação de contêiner criado
d02e19d1b688 nginx: mais recente "nginx -g 'daemon de…" cerca de um minuto atrás
34B4DD74352D NGINX: mais recente "nginx -g 'daemon de…" cerca de um minuto atrás
98549c0f3dcf nginx: mais recente "nginx -g 'daemon de…" cerca de um minuto atrás
Nomes de portas de status
Até um minuto 0.0.0.0: 83-> 80/tcp Project_web_1
Até um minuto 0.0.0.0: 82-> 80/TCP Project_Web_3
Até um minuto 0.0.0.0: 81-> 80/tcp Project_web_2
..

Para dimensionar mais de um serviço, você precisa mencioná -los individualmente com o sinalizador de escala e o parâmetro de número para garantir que o número desejado de instâncias sejam criadas. Por exemplo, se você tiver dois serviços diferentes, precisa fazer algo assim:

$ Docker -Compõe Up -D -SERVIÇO DE ESCALA1 = 5 -SERVIÇO DE ESCALA2 = 6

Esta é a única maneira de fazer isso, já que você não pode executar o comando do Docker -Compose Up -escala duas vezes para cada serviço. Fazer isso escalaria o serviço anterior de volta a um único contêiner.

Mais tarde, veremos como você pode definir o valor da escala para uma determinada imagem, de dentro do Docker-Compose.yml. Caso haja uma opção de escala definida no arquivo, o equivalente da CLI para a opção de escala substituirá o valor no arquivo.

Escala

Esta opção foi adicionada na versão 2 do arquivo Docker-Compose.2 e pode ser tecnicamente usado, embora eu não recomendo usá -lo. É mencionado aqui por uma questão de completude.

Para o meu Docker-Compose.Arquivo YML:

versão 2.2 "
Serviços:
rede:
Imagem: "Nginx: mais recente"
Portas:
- "80-85: 80"
Escala: 3

Esta é uma opção perfeitamente válida. Embora funcione para o Docker Engine 1.13.0 e acima.

Use réplicas na produção

Em vez de usar o comando de escala ou o valor de escala desatualizado em seu arquivo de composição, você deve usar a variável de réplica. Este é um número inteiro simples associado a um determinado serviço e funciona praticamente da mesma maneira que a variável de escala. A diferença crucial é que o Swarm Docker é explicitamente destinado ao sistema distribuído.

Isso significa que você pode implantar seu aplicativo em vários nós ou servidores físicos em várias regiões diferentes e vários data centers diferentes. Isso permite que você realmente se beneficie da multiplicidade de instâncias de serviço que estão em execução.

Ele permite dimensionar seu aplicativo para cima e para baixo modificando uma única variável, além disso, oferece maior resiliência contra o tempo de inatividade. Se um data center estiver inativo ou um link de rede falhar, os usuários ainda poderão acessar o aplicativo porque outra instância está sendo executada em outro lugar. Se você espalhar sua implantação de aplicativos em várias regiões geográficas, e.G, UE, EUA e Ásia -Pacífico, reduzirá a latência para os usuários que tentam acessar seu aplicativo da referida região.

Conclusão

Enquanto a escala do Docker-Compose é útil para pequenos ambientes, como um único host do Docker em produção. Também é muito útil para desenvolvedores que executam o Docker em sua estação de trabalho. Pode ajudá -los a testar como o aplicativo será dimensionado na produção e em diferentes circunstâncias. Usando o comando de escala circunha o incômodo de configurar um novo swarm do Docker.

Se você tem uma instância do Swarm Docker em execução, fique à vontade para brincar com réplicas. Aqui está a documentação sobre esse assunto,