‫Atualizações de serviço. Você provavelmente assumiu o tempo todo que há alguma maneira de atualizar seus
‫serviços, mesmo que ainda não estivemos focados nisso.
‫Vamos falar sobre isso porque as atualizações têm um monte de coisas acontecendo sob as capas. A funcionalidade de atualização do Swarm é centrada em torno
‫de um padrão de atualização contínua para suas réplicas. O que significa que se você tiver um serviço
‫com mais de uma réplica, e espero que você faça, ela irá rolar por padrão,
‫uma de cada vez, atualizando cada recipiente, substituindo-o pelas novas configurações que você está colocando
‫na atualização comando.
‫orquestradores impedem o tempo de inatividade nas atualizações, mas não vou dizer que isso evite o tempo de inatividade.
‫Muitas pessoas dirão que os
‫Eu vou dizer que isso limita o tempo de inatividade. Porque evitar o tempo de inatividade em qualquer sistema é o trabalho de teste.
‫Você realmente precisa começar a testar como você faz suas atualizações e determinando, isso afeta os meus usuários?
‫A atualização de um banco de dados afeta minha aplicação web? Provavelmente.
‫Cada aplicativo para o qual você possui um serviço vai atualizar e impactar as outras coisas em torno dele
‫de forma diferente.
‫Esse não é o trabalho de um orquestrador.
‫fácil.
‫Um orquestrador não pode determinar se este é um protocolo de banco de dados, e esse é um protocolo de aplicativo
‫REST que é
‫Então, essas vão ser coisas diferentes e complicadas com as quais você precisa lidar.
‫No caso de atualizações de serviço, se é apenas uma API REST ou um frontend da web que não está
‫fazendo nada extravagante como sockets web ou polling longo, se é algo muito simples assim ou um site estático,
‫você provavelmente terá uma atualização fácil e não será um problema. esses sempre serão um desafio,
‫Mas outros serviços, como bancos de dados ou armazenamento persistente ou qualquer coisa que exija uma conexão persistente. não importa o que você está tentando atualizar. Então, teste com antecedência e teste com freqüência.
‫Como eu disse antes, isso definitivamente irá substituir os contêineres na maioria das atualizações. rolar e mudar cada recipiente com um novo totalmente novo.
‫A menos que você esteja atualizando um rótulo ou
‫algum outro metadado com o serviço, ele irá
‫Apenas esteja preparado para isso. Tem muitas opções. Na verdade, o último que eu contei,
‫havia pelo menos 77 opções para o comando de atualização. Mas quase tudo o que você quer fazer pode
‫ser ajustado.
‫Muitas das opções no comando de atualização são, na verdade, criam opções que apenas possuem
‫um -rm e um -add no final deles. Porque se é uma opção que
‫pode ser usada para vários valores, digamos uma porta para publicar ou uma variável de ambiente, aqueles que você pode usar muitos deles.
‫Certo?
‫Então, você precisa informar o comando de atualização quais você está adicionando e quais você está removendo.
‫Vamos ver esses em um minuto.
‫Isso também inclui opções de reversão e verificação de integridade.
‫Você deve olhar para as opções para aqueles e ver se seus valores
‫padrão não são ideais para sua aplicação e testar configurações diferentes para ver se isso facilita a atualização para você e seu sistema.
‫Você também verá que temos opções de escala e reversão aqui que são seus próprios comandos agora.
‫deles um tipo de cidadão de primeira classe na linha de comando.
‫Eles costumavam ser opções que você precisava especificar com o "rollback" ou "escala",
‫mas tantas pessoas têm usado essas com tanta frequência que o Docker agora está fazendo
‫Eles podem estar adicionando mais do que no futuro.
‫Por fim, antes de chegar a alguns
‫exemplos, se você estiver fazendo pilhas, uma pilha empilhada na mesma pilha é uma atualização.
‫Na verdade, não existe uma opção separada para atualizações de pilha.
‫Você apenas faz uma pilha de implantação com o mesmo arquivo que foi editado.
‫Então, ele funcionará com os comandos de serviço e as redes e todas as outras coisas que faz. de se forem necessárias alterações, que sejam aplicadas.
‫Isso funcionará com eles para se certificar
‫Vejamos alguns exemplos rápidos e depois iremos à linha de comando.
‫Este é provavelmente o exemplo mais comum que você estará usando,
‫que é mudar a imagem de um serviço.
‫Toda vez que você atualiza seu aplicativo e você cria uma nova imagem, você terá que fazer um comando de atualização do serviço, com o nome da imagem e, em seguida,
‫o nome do serviço.
‫Então, neste caso, talvez eu tivesse minha aplicação com uma tag de 1. 2. 0.
‫E neste caso, agora estou aplicando um 1. 2. imagem diferente da que eu tenho executado no meu serviço, e iremos atualizá-los.
‫1 imagem, e o serviço
‫determinará, ah sim, essa é uma Neste próximo, estamos mostrando como você pode
‫fazer várias coisas ao mesmo tempo dentro de um único comando de atualização.
‫Você pode adicionar uma variável de ambiente com o env-add, e então você pode
‫remover uma porta com o publish -rm.
‫Poderíamos também adicionar e remover variáveis ​​de ambiente e publicar portas no mesmo comando de atualização,
‫tanto quanto desejemos. Sobre este último, isso
‫mostra como podemos usar esses novos comandos de escala e reversão em vários serviços ao mesmo tempo. usá-las no comando de atualização é que eles podem se candidatar a vários serviços.
‫Qual é uma das vantagens de
‫Neste caso, na verdade, vou mudar o número
‫de réplicas da web e dos serviços da API ao mesmo tempo.
‫Como eu disse há algum tempo, nas atualizações Swarm, você não possui um comando de implantação diferente.
‫É exatamente a mesma implantação da
‫plataforma docker, com o arquivo que você editou, e seu trabalho é trabalhar com todas as outras
‫partes da API para determinar se há alguma alteração necessária e, em seguida, rolar essas com uma atualização de serviço.
‫Tudo bem. Comecemos pela criação de um serviço para que possamos manipulá-lo com alguns comandos de atualização.
‫docker service create -p 8088 80 web de nome, e usaremos o Nginx, e
‫vamos especificar uma versão como sempre devemos na produção.
‫É bom, agora que nós realmente temos na última metade de 2017, a opção de desanexar com nosso serviço criamos e atualizamos comandos, podemos realmente
‫ver isso acontecer de forma síncrona em tempo real.
‫Então, isso será bom para os comandos de atualização para ver como as atualizações realmente são lançadas através da linha de comando.
‫Tudo bem. Agora, se fizermos um serviço docker, percebemos que nosso serviço
‫está funcionando e que tem 1 de 1 réplicas, então é bom ir.
‫Agora vamos escalar nosso serviço para que possamos ter algumas réplicas mais para trabalhar. Web = 5.
‫escala de serviço docker E você viu que um deles já estava
‫em execução, e os outros 4 tiveram que começar. Foi muito rápido no meu porque eu já tinha a imagem baixada, mas
‫a sua pode demorar alguns minutos enquanto eles estão no estado
‫pendente, pois os downloads de imagens nos outros nós.
‫Tudo bem.
‫Vamos fazer uma atualização contínua alterando a imagem desse Nginx.
‫Você verá aqui que escolhi uma imagem mais antiga.
‫Agora, Docker não se preocupa com o que a imagem realmente é.
‫Pode ser uma aplicação
‫completamente diferente para todos os cuidados. Sabe apenas que neste serviço, estou mudando para uma imagem diferente.
‫Lembre-se, por padrão, que vai passar por aqui uma por vez.
‫Ele primeiro irá removê-lo, crie um novo,
‫e então, quando esse for bom, e parece saudável, ele começará no próximo. No próximo exemplo, vamos
‫mudar a porta publicada.
‫Mas você não pode mudar uma porta.
‫Você realmente deve adicionar e removê-los ao mesmo tempo.
‫Então, neste caso, porque nós a publicamos pela
‫primeira vez com um 8088, precisamos fazer uma atualização de serviço do docker, publique o rm 8088. Não preciso especificar o valor. Eu só preciso especificar a chave. Então vamos
‫publicar o novo, 9090. Então, o valor, que neste caso é 80. Você verá que fará o mesmo processo de atualização
‫do que antes.
‫O último exemplo sobre o qual quero falar é uma espécie de dica. Porque muitas vezes você terá
‫um desafio com algo chamado reequilíbrio. Ou se você mudar o número de nós ou se você mover muitas coisas, se você tiver
‫muitos contêineres em seu enxame, pode achar que eles não estão realmente separados. são bastante claros em quantos contêineres estão sendo
‫executados e outros que têm muito.
‫Você tem talvez alguns nós que Se você tem muitas coisas mudando, Swarm não
‫vai mover as coisas para manter tudo equilibrado em termos da quantidade de recursos utilizados.
‫Mas, o que você pode fazer é que você pode forçar uma atualização de um serviço, mesmo sem alterar nada nesse serviço.
‫Então, ele irá reeditar tarefas, e nesse caso, ele escolherá os nós menos usados, que é uma forma de reequilíbrio.
‫Muitas vezes em um enxame menor quando eu mudo algo grande, ou adiciono um monte de nós,
‫de repente eu tenho um monte de servidores vazios sem fazer nada e preciso trabalhar com eles.
‫Então, o que vou fazer é levar um ou dois dos meus serviços, e vou fazer uma atualização do serviço docker -
‫forçar, e nesse caso, ele irá rolar e substituir completamente as tarefas.
‫Claro que ele usará o padrão de programação de busca de nós com
‫o menor número de contêineres e o menor número de recursos usados.
‫Esse é um truque para contornar uma quantidade desigual de trabalho em seus nós.
‫Lembre-se de limpar removendo o serviço que criamos nesta palestra.
‫