Nós reduzimos o tempo de implantação em múltiplos ambientes para 1/10 graças ao uso do Docker, e também economizamos 2 posições de operação e manutenção para uma equipe de 10 pessoas.

No mês passado, a nossa pequena equipe de SaaS de comércio eletrônico em Cingapura quase falhou – antes de uma grande promoção, atualizamos a função de sincronização de estoques para 3 sites no Sudeste Asiático. Os testes locais foram bem-sucedidos, mas assim que a atualização foi lançada no servidor cloud na Indonésia, surgiram problemas de falta de dependências. Dois servidores de backend e um técnico de operações passaram 18 horas tentando resolver o problema, o que atrasou o plano de realizar os testes de carga com 3 dias.

Primeiro, vamos entender o que é a implantação com Docker.

Em outras palavras, é como empacotar todo o código da sua aplicação, as bibliotecas de dependência, os arquivos de configuração e até mesmo os parâmetros do kernel do sistema operacional em um “image de container” padrão. O que funciona no seu ambiente local funciona da mesma forma em qualquer servidor que tenha o motor Docker instalado.20MB pode ser feito para uma única imagem, o tempo de inicialização não deve exceder 1 segundo.。

Nós utilizamos os rendimentos reais de 3 meses.

Primeiro, foi resolvido de forma definitiva o problema da inconsistência do ambiente. Antes, era necessário gastar bastante tempo para configurar diferentes versões do Node.js e drivers de banco de dados para cada site. Agora, com as imagens pré-compiladas sendo enviadas diretamente para o repositório de imagens, é possível baixar e iniciar os três sites com apenas um clique. O tempo de implantação caiu de uma média de 4 horas para 24 minutos, e não é mais necessário passar a noite toda atualizando as versões antes de grandes promoções.

Em segundo lugar, a taxa de utilização dos recursos do servidor aumentou exatamente para o dobro. Antes, cada site alugava um servidor cloud com 2 núcleos (4G) separadamente, e a taxa de utilização do CPU em tempos de inatividade era inferior a 10%. Agora, com o Docker, estamos reunindo as aplicações, caches e tarefas agendadas de todos os três sites em um único servidor com 4 núcleos (8G), e os recursos são exatamente suficientes.A economia mensal com os custos do servidor é de 620 dólares.Para uma pequena equipe com menos de 10 pessoas, isso não é um número pequeno.

Finalmente, a velocidade de expansão consegue acompanhar completamente o aumento súbito do tráfego. No ano passado, durante o Black Friday, levamos quase 2 horas para configurar os servidores temporariamente, mas este ano, 10 minutos antes do pico, já tínhamos ativado 12 cópias de containers que suportaram 3 vezes o tráfego normal, sem nenhum caso de tempo de resposta excedido para as solicitações.

Não se apresse em entrar no carro, nós já passamos por esses problemas para você.

O primeiro problema foi que a imagem criada era muito grande e pesada. No início, usávamos diretamente a imagem completa do Node.js oficial para empacotar os aplicativos, e uma única imagem do aplicativo tinha o tamanho de 1.2G, levando mais de 20 minutos para ser enviada para o repositório de imagens internacional. Mais tarde, mudamos para usar a imagem base Alpine, removendo todas as dependências desnecessárias, e o tamanho da imagem ficou apenas 90MB, o que aumentou a velocidade de transferência em mais de 10 vezes.

O segundo problema foi que os dados estavam armazenados em um container. No início, não prestamos atenção e salvamos as imagens dos produtos carregadas pelos usuários diretamente no diretório local do container. Depois que o container foi reiniciado, todas as imagens desapareceram, e levamos um dia para recuperá-las a partir do backup. Desde então, todos os dados persistentes são montados no diretório local do servidor ou no armazenamento em objetos (object storage), e nunca mais tivemos problemas.

O terceiro problema é a falta de restrições de recursos. Quando o sistema foi lançado inicialmente, não foram definidos limites para a CPU e a memória dos containers. Uma vez, um bug em uma tarefa agendada de um determinado site consumiu toda a CPU do servidor, fazendo com que os outros dois sites também falhassem. Mais tarde, limites de recursos foram estabelecidos para cada container, de modo que mesmo que um serviço tenha problemas, isso não afete o funcionamento geral do sistema.

Devo usar Docker ou não? Nosso critério de decisão é muito simples.

Caso de uso: Você precisa implantar o mesmo aplicativo em vários servidores, alternar frequentemente entre ambientes de desenvolvimento/teste/produção, e a equipe tem mais de 3 pessoas, cada uma com um ambiente de desenvolvimento diferente. Nesse caso, usar Docker apenas aumentará a eficiência.

Circunstâncias em que não se deve usar: Se você tem apenas um pequeno blog, o executa em um único servidor e atualiza o código apenas uma vez a cada seis meses, não há necessidade alguma de gastar tempo aprendendo sobre Docker. É mais prático usar o Baota ou realizar a implantação manual.

3 dicas específicas para quem está começando pela primeira vez

• As primeiras 3 vezes que você empacota uma imagem, procure diretamente pelos melhores modelos de práticas oficiais. Não escreva o Dockerfile por conta própria, isso pode evitar 80% dos problemas de excesso de tamanho da imagem e erros de permissões.
• No início, não é necessário usar ferramentas de gerenciamento complexas como o K8s; basta usar o Docker Compose para gerenciar até 3 serviços, o que é mais do que suficiente.
• Para o repositório de imagens, use os nós externos dos fornecedores de nuvem; não crie você mesmo. O tempo economizado será suficiente para desenvolver várias outras funcionalidades.

Respostas unificadas para problemas comuns

Pergunta: O Docker consome muito mais desempenho do servidor? Nós testamos e o consumo de desempenho é inferior a 5%, o que é completamente imperceptível para a grande maioria das equipes de pequeno e médio porte.

Pergunta: É possível migrar aplicativos antigos para Docker? Claro que sim! Temos um projeto PHP antigo que está em funcionamento há 3 anos, e levamos apenas 2 dias para criar o image e realizar a migração, o que foi muito mais rápido do que configurar o ambiente do zero.