‫Tudo bem.
‫Onde quer que você esteja executando o Docker, nós realmente podemos criar um enxame de um único nó para nossos próprios
‫fins de teste.
‫Da maneira que eu posso dizer se o Swarm está ligado ou não, eu só posso fazer uma informação do docker e você notará
‫Swarm inactive.
‫Então, sabemos que Swarm não foi ativado aqui. Novamente, por padrão, o Docker não habilita
‫nenhum dos recursos Swarm.
‫Posso executar um injetor docker init para inicializar. Isso levou cerca de meio segundo e terminamos.
‫O que temos agora é um enxame de um único nó com todos os recursos e funcionalidades que
‫saímos da caixa.
‫Então, essa foi provavelmente a demonstração mais curta de todo esse curso.
‫Quero dizer, o que aconteceu? Nós digitamos um comando e mágica. Na verdade, não era mágica.
‫Foram muitas das coisas muito rápidas e eficientes na programação Go do Docker, mas, essencialmente, logo na caixa,
‫faz um
‫monte de PKI e coisas de segurança. Ele cria um certificado raiz para o enxame que ele usará para
‫estabelecer certificados de confiança e assinatura para todos os nós e todos os gerentes. porque é um gerente versus um trabalhador.
‫Ele criará um certificado especial para este primeiro nó gerenciador
‫Em seguida, ele cria esses tokens que podemos realmente usar em outros nós para se juntar a este enxame.
‫Em seguida, um monte de outras coisas no fundo onde ele permite a API Swarm e cria algo chamado base
‫de dados do Consórcio Raft, sobre o qual falaremos mais tarde em uma parte de produção do curso.
‫Para que você saiba, a Raft é um protocolo que realmente garante consistência em vários nós, e é
‫ideal para usar na Nuvem, onde não podemos garantir que qualquer coisa esteja disponível para
‫qualquer momento.
‫Ele cria esse banco de dados no disco. primeiro gerenciador, e realmente o criptografa.
‫Ele armazena a configuração do enxame, e esse
‫Supondo que você esteja na versão 1. 13 ou mais recente. Então, aguardará outros nós antes de começar
‫a replicar o banco de dados para eles.
‫Novamente, todo esse tráfego que faria uma vez que criarmos outros nós seja criptografado.
‫Um dos principais componentes do Swarm que o diferenciou quando surgiu pela primeira vez foi que
‫não precisávamos de um sistema de armazenamento de valores adicionais ou de alguma arquitetura de banco de dados para ser o gerenciamento
‫de configuração do backend do nosso enxame.
‫que você geralmente precisa redundante, que irá armazenar todas as informações sobre seu sistema de orquestração e automação.
‫Se você já esteve em torno da indústria por anos ou décadas, mesmo esse conceito normalmente é o config db,
‫que é esse sistema de banco de dados separado Swarm realmente construiu isso diretamente
‫no Docker diretamente no daemon e lide com ele.
‫Nós nunca precisamos fazer nada. Não há senhas para se preocupar. Não há serviços especiais
‫para iniciar ou algo assim. Se eu quiser adicionar um trabalhador ao
‫Então, de volta à linha de comando. enxame, eu realmente preciso cortar e
‫Você notará aqui que fala. colar isso nos outros servidores que eu adicionei. Mais tarde, na verdade, vamos construir um enxame
‫de vários nós, mas, por enquanto, nós apenas vamos manter isso em um único nó. Vamos dar uma olhada em alguns dos comandos que vão sair dela.
‫A primeira coisa é que podemos fazer nó docker ls. Nesse caso, estamos apenas vendo o único nó
‫gerenciador que criamos.
‫Você notará que é marcado como líder, e só pode haver um líder por vez entre todos os gerentes.
‫Novamente, uma vez que só conseguimos um, então, obviamente, é o líder. Podemos
‫ver ajuda para ver outras opções que temos aqui. Realmente, os comandos dos nós usados ​​para trazer seus servidores dentro e fora do enxame, ou promovê-los de trabalhadores
‫para gerentes, ou rebaixá-los de gerentes de volta aos trabalhadores.
‫Se você voltar o comando do swarm do
‫dockers por um pouco, notaremos que ele realmente é um escopo muito limitado para o comando.
‫Realmente é apenas para inicializar, juntar-se ou sair.
‫O novo comando de desbloqueio, no qual podemos falar em uma palestra posterior.
‫Por enquanto, vamos nos concentrar no novo e emocionante comando do serviço Docker.
‫Novamente, o serviço em um enxame substitui o Docker.
‫Eu não sei de fato, mas eu realmente acho que isso foi centrado em torno
‫da idéia de que não queríamos quebrar a funcionalidade de execução do Docker existente, mas
‫a execução do Docker sempre foi construída desde o início como uma única solução host.
‫Toda a idéia era se concentrar em contêineres locais no sistema que está falando. começamos a falar sobre um cluster, não nos importamos tanto com os nós individuais.
‫Considerando que, quando
‫Na verdade, nós provavelmente não os nomeamos. Nós os tratamos como gado, se você já ouviu
‫falar sobre a analogia de animais de estimação versus gado, onde eles são apenas um número.
‫Na verdade, não fazemos individualmente a cada nó e criamos um contêiner individual.
‫Realmente, apenas lançamos requisitos no enxame sob a
‫forma de serviços e, em seguida, orquestrará como é preciso colocar
‫tudo isso, quais nós precisam ser, e nós só sabemos que está de volta. O serviço docker cria é como nós
‫damos alguns novos pedidos. Vamos fazer algo realmente simples.
‫Vamos apenas fazer com que ele comece a imagem alpina. Então, vamos ter a imagem Alpine
‫apenas usar ping para bater 8. 8. 8. 8, que é realmente um servidor DNS do
‫Google, mas nós realmente queremos dar algo para fazer enquanto investigamos o que acontece.
‫Então você verá como o docker executar, ele custam uma ID, só que essa não é a identificação do contêiner. Essa é realmente
‫a ID do serviço.
‫Você verá que agora temos um serviço listado. Assim como no nosso comando de encaminhamento do
‫docker, já que não o
‫nomeamos, ele deu um nome aleatório. Podemos ver que na verdade já está girando.
‫Um de um. Quando você está olhando
‫para os serviços, você sempre vai ver esse número com um / no meio. Isso representa o da esquerda e quantos estão em execução.
‫E aquele à direita é o número de quais você especificou para que ele seja executado.
‫O objetivo do orquestrador é fazer com que esses números correspondam, seja lá o que for necessário.
‫Mas isso novamente não nos mostra o recipiente real.
‫Isso realmente está nos mostrando uma lista de nossos serviços, para que possamos detalhar um pouco mais.
‫Fazemos um serviço de docker ps, e depois damos
‫o nome ou o ID do serviço, e isso nos mostrará as tarefas ou contêineres para este serviço. com cenários de vários servidores, talvez precisemos saber em qual servidor ele está funcionando.
‫Você verá que é semelhante ao comando dock ls do docker, mas na verdade já possui esse
‫componente de nó, porque quando você está lidando Você notará que ele realmente
‫deu um nome de um incremento no nome do serviço.
‫Se voltarmos para o comando docker container ls, isso ainda funciona.
‫Neste caso, a orquestração do Swarm está realmente adicionando
‫algumas informações aos nomes e às imagens reais que estão sendo executadas. Abrangeremos algumas dessas diferenças sutis mais tarde também.
‫Por enquanto, vamos realmente tomar esse serviço e ampliá-lo. Para isso, usamos a atualização do serviço docker e, em seguida, o nome do nosso serviço, ou o ID
‫neste caso, vou fazer o ID. atributo sobre o serviço.
‫E eu quero mudar um
‫Neste caso, eu quero mudar o número de réplicas.
‫Então, se fizermos um serviço docker ls novamente, agora vemos três das três. Se fizermos um
‫ps de serviço docker, na verdade, agora veremos três tarefas. Você notará que dois foram apenas criados segundos atrás.
‫Se estivéssemos rápidos o suficiente, e se estivéssemos implantando algo grande o suficiente, poderíamos realmente executar
‫o serviço e ver nos mostrar zero de três. Um de tres.
‫Isso aumentará quando as coisas forem iniciadas. Acontece que a Alpine já estava nesta máquina, em termos de sua imagem, e não demorou muito
‫para iniciar um comando de ping.
‫Nós simplesmente não poderíamos ser tão rápidos.
‫O que é interessante sobre esse comando de atualização é que
‫você pode imaginar a diferença entre o comando
‫de execução do Docker que você pode usar em um único desenvolvedor ou servidor de teste
‫ou em sua máquina local e as preocupações de produção sempre mantendo algo disponível o máximo possível.
‫Esse é um dos objetivos de design do Swarm. Esse comando que ainda não usamos ainda é o comando
‫de atualização do Docker. Esse foi um comando para o Docker executou
‫recipientes que nos permitiram atualizar certas variáveis ​​em nosso contêiner em execução sem ter que matá-lo e reiniciá-lo.
‫Quase todas essas opções estão relacionadas a limitar e controlar o uso de recursos para esse recipiente.
‫Porque essa é uma das coisas típicas que você vê quando você está executando um
‫aplicativo de longo prazo é que você precisa mudar seus recursos talvez porque os bancos de dados ficaram maiores e precisam de mais RAM.
‫Ou talvez você tenha um processo fora de controle que está consumindo CPU demais e você precisa restringi-lo.
‫Se fizermos uma ajuda no comando de atualização do serviço docker, você verá que temos muitas outras opções.
‫Como o objetivo de um serviço Swarm é que ele
‫é capaz de substituir os contêineres e atualizar as mudanças no serviço sem tirar a totalidade da coisa.
‫derrubar um a cada vez para fazer uma mudança e fazer uma atualização contínua, que é o padrão verde azul sobre o qual falamos.
‫Se você tivesse um serviço com três recipientes nele, você poderia É por isso que vemos muitas outras
‫opções aqui porque podemos alterar essas opções que podem exigir um reinício do recipiente, mas o
‫enxame assegurará de forma inteligente que a
‫maneira como os atualizamos está em um padrão que garante uma disponibilidade consistente.
‫Então, de volta à nossa lista de contêiner docker, é muito rápido. Você perceberá que nós temos esses três agora, e se eu entrasse e, como um rogue, Digamos que ganhei o primeiro e
‫fiz um container rm do docker, Tudo bem.
‫e eu especifiquei um desses recipientes, e eu forcei isso. apenas tire isso. Agora eu faço um serviço docker, e você vê como isso mostra dois dos três?
‫e eu realmente tirei um recipiente para correr, ele vai identificar isso e vai lançar um novo em segundos para substituir aquele que desceu.
‫Porque eu fui atrás das costas de
‫Swarm
‫Então, se eu fiz um serviço de docker ps em gelado, você verá que ele realmente mostra o histórico da
‫primeira tarefa aqui na lista é que ele teve um que falhou e ele começou um novo 24 segundos atrás.
‫Esta é uma das responsabilidades de um sistema de orquestração de
‫contêiner
‫é certificar-se de que os serviços que você especificou estão sempre em execução, e se eles falharem, ele se recupera dessa falha. Qual é a maneira diferente da corrida do docker, certo? A corrida do docker nunca
‫criaria um recipiente.
‫Então, é por isso que sempre que fazemos qualquer um desses comandos de serviço do Docker, na verdade não
‫estamos falando diretamente de uma ação, como criar um recipiente.
‫Estamos realmente contando um sistema de orquestração, por favor, coloque este trabalho em sua fila.
‫Quando você conseguir chegar, execute as ações no enxame que eu perguntei aqui. Essa
‫é uma grande diferença.
‫É sutil na linha de comando, mas é uma grande diferença porque significa que há possibilidades de reversão.
‫Há uma mitigação de falhas e muita inteligência incorporada a isso.
‫realmente quis remover todos esses recipientes, eu teria que remover o serviço.
‫Nesse caso, se eu Eu teria que fazer o serviço docker rm.
‫E depois o gelado.
‫Se fizermos um serviço docker, não vemos nada. Se fizermos um container docker,
‫veremos três recipientes.
‫Ah, vamos lá.
‫Isso mostra exatamente o que a automação está acontecendo no backend.
‫Pudemos mostrar rapidamente que excluímos o serviço, mas o sistema de
‫orquestração não passou por todos os processos de limpeza do serviço e da tarefa por trás disso. de execução do Docker que tivemos no início deste curso.
‫Esses conceitos devem ser bastante
‫fáceis de entender, porque eles realmente estão se expandindo nos conceitos
‫Em seguida, vamos construir um enxame de vários nós e começar a dimensionar nossos contêineres.
‫