‫Uma das grandes promessas de contêineres é que podemos facilmente implementar nossos aplicativos como se fossemos um serviço de plataforma, você
‫sabe, como Heroku ou algo assim. Nós podemos fazer isso no hardware de qualquer pessoa, seja no
‫nosso hardware, é um provedor de nuvem, seja ele virtual ou físico. Com o Docker, nossos aplicativos podem ser os mesmos,
‫sejam eles Amazon, Azure, DigitalOcean, Linode, Rackspace, Google Cloud ou o que for. Sem todos esses recursos da plataforma, como
‫podemos implementar e manter facilmente nossas dúzias, ou centenas, ou mesmo milhares de
‫contêineres em vários servidores ou instâncias? Ou nós ou gotículas ou o que quer que seja.
‫Isso traz alguns problemas realmente novos que anteriormente não eram problemas para organizações pequenas.
‫se estendem a milhares e milhares de nós, e dezenas de milhares de nós, e eles têm muitos engenheiros.
‫Todos sabemos sobre a Netflix e grandes organizações como essa que
‫Mas, se você tem apenas um par de pessoas em sua equipe, ou se você é apenas um desenvolvedor solo, como você leva
‫seus contêineres e os dimensiona e lida com todo o ciclo de vida? Desde a sua implantação, iniciá-los,
‫reiniciá-los, recriá-los, excluí-los e atualizá-los e tudo isso.
‫Começamos a fazer perguntas sobre como exatamente Docker faz isso ou faz mesmo isso mesmo?
‫Algumas das perguntas que nos perguntamos são coisas como, como escalamos? Como escalamos? Como garantir que
‫nossos recipientes sejam reiniciados se falharem?
‫Como substituímos esses contêineres quando realmente temos uma atualização para eles? tira servidores do pool para trazer novos.
‫O que é chamado de "green green green" hoje em dia, o que significa que você
‫tem zero tempo de inatividade e você Você acaba sempre com alguma coisa disponível para
‫que você nunca esteja realmente abaixado quando você atualizar. Como sabemos se nós temos dúzias de nós ou mesmo apenas
‫três nós onde iniciamos esses contêineres? Qual nó é o nosso contêiner? Como conversamos entre esses diferentes
‫nós ou servidores com nossa rede dentro dos contêineres?
‫Quando se trata de segurança, como podemos ter certeza de que nossos contêineres estão funcionando somente nas
‫máquinas que pretendemos que elas sejam executadas?
‫armazenamos as informações privadas que precisamos para nossos contêineres, como segredos ou senhas?
‫Agora que estamos movendo as coisas e implantando-as dinamicamente, como
‫Então, isso nos leva a uma grande evolução no escopo do que a Docker tenta resolver.
‫Quando as pessoas falam comigo e acham que o Docker é apenas um tempo de execução de
‫contêiner, é quando eu realmente apenas mencione Swarm Mode, que é uma nova característica em 2016 que reúne anos de compreensão
‫das necessidades dos contêineres e como realmente executá-los ao vivo em produção.
‫realmente uma solução de cluster de servidor que reúne diferentes sistemas operacionais ou hosts, ou nós, ou o
‫que quer que você
‫queira chamá-los, em uma única unidade gerenciável que você pode orquestrar o ciclo de vida de seus contêineres.
‫Portanto, no seu núcleo, o Swarm é Apenas para ser claro, na verdade não estamos falando sobre o Swarm,
‫que chamarei de Swarm Classic, que foi um componente adicional para o Docker antes de 1. 12 saiu. Era realmente um recipiente que funcionaria dentro do
‫Docker, que realmente acabou de levar
‫seus comandos de execução do Docker e os repetiu para múltiplos servidores.
‫Isso resolveu alguns problemas, mas não era realmente na escala que precisávamos para resolver verdadeiramente 80% dos casos para
‫saber como você vai executar seus contêineres.
‫2016, o Docker anunciou
‫o Swarm Kit, que era um conjunto de bibliotecas ou um kit de ferramentas relacionado a um conjunto de novos recursos Swarm.
‫No verão de 2016, no dockercon
‫Então eles ficaram presos no servidor Docker. Ao longo deste curso, você realmente possui os
‫recursos disponíveis na CLI e no seu servidor.
‫Agora, finalmente conseguimos mergulhar neles.
‫Em janeiro de 2017, 1. 13 saíram e, claro, porque o Swarm
‫Mode era novo em 2016, eles continuarão a melhorar nos próximos anos.
‫Em janeiro, eles adicionaram recursos adicionais chamados Stacks and Secrets, bem como outros bônus
‫sobre os quais falaremos mais tarde. É importante notar que Swarm não está habilitado na caixa.
‫Na verdade, na sua máquina, você não poderia usar esses comandos listados aqui agora. Isso realmente lhe dará um
‫erro porque Swarm deve ser habilitado.
‫Esse era um dos objetivos de design, segundo o qual nenhum dos códigos Swarm
‫afetaria o daemon do Docker existente e que todas as ferramentas e sistemas existentes que já
‫dependiam do Docker ou talvez tivessem sua própria orquestração no Docker continue a funcionar e não seja
‫interferido
‫com o Swarm sendo agora uma parte do Docker. essas caixas azuis que você vê no topo são o que chamamos
‫de Nó de Gerenciador, e eles realmente possuem um banco de dados localmente conhecido como o banco de dados Raft.
‫Alguns conceitos realmente básicos antes de começar a mergulhar, é que
‫Ele armazena sua configuração e dá-lhes toda a informação que eles precisam ter para ser a autoridade
‫dentro de um enxame.
‫Então, o que temos aqui são três gerentes diferentes que foram todos adicionados ao enxame
‫e todos eles mantêm uma cópia desse banco de dados e criptografam seu tráfego para garantir a integridade e garantem a confiança
‫de que eles são capazes de gerenciar esse enxame com segurança .
‫Abaixo no verde, nós realmente temos notas de trabalho. Agora você pode ver no conceito de
‫Swarm, agora temos gerentes e trabalhadores.
‫Cada uma delas seria uma máquina virtual, ou um host físico, executando alguma distribuição do
‫servidor Linux ou Windows.
‫Isso está mostrando como eles realmente estão se comunicando sobre o que chamamos de Plano de Controle, que
‫é como as ordens são enviadas ao redor do enxame, participando de ações. Em uma visão um pouco mais complicada, temos este banco
‫de dados de consenso Raft que mencionei, que é replicado novamente entre todos os nós.
‫Eles emitem ordens para os trabalhadores.
‫Os próprios gerentes também podem ser trabalhadores. Claro, você pode rebaixar e promover trabalhadores
‫e gerentes nas duas funções diferentes.
‫Quando você pensa em um gerente, geralmente pensa em um trabalhador com permissões para controlar o enxame.
‫Novamente, os únicos requisitos para cada um desses servidores são que eles estão
‫executando o mesmo Docker que você já está usando agora. Com este conceito de enxame, e esses gerentes, agora temos novos conceitos
‫de como são nossos recipientes.
‫Então, com o comando de execução do Docker, nós realmente poderíamos realmente implantar um contêiner.
‫Apenas criaria um recipiente.
‫Foi sempre em qualquer máquina com a qual a CLI Docker estava falando.
‫Essa é geralmente a sua máquina local, ou talvez um servidor em que estiver conectado. sobre como dimensionar ou ampliar.
‫O comando Docker Run não tinha conceitos
‫Então precisávamos de novos comandos para lidar com isso.
‫É aí que vem o comando do serviço Docker. Em um enxame, ele substitui o
‫comando de execução do Docker e nos permite adicionar recursos extras ao nosso contêiner quando o
‫executamos, como réplicas para nos dizer quantos desses deseja executar.
‫Essas são conhecidas como tarefas.
‫Um único serviço pode ter várias tarefas e cada uma dessas tarefas iniciará um contêiner.
‫serviço docker criando para girar um serviço Nginx usando a imagem Nginx como já fiz várias vezes antes.
‫Nesse exemplo, criamos um serviço usando o
‫Mas dissemos que gostaríamos de três réplicas.
‫Então, ele usará os nós do gerente para decidir onde no enxame para colocá-los. Por padrão, ele tenta
‫espalhá-los.
‫Cada nó obteria sua própria cópia do contêiner Nginx até as três réplicas que
‫dissemos que precisávamos.
‫Esta é uma compreensão rápida e básica de como os gerentes trabalham e o que eles estão fazendo em segundo plano.
‫Todos esses recursos são novos.
‫Não é simplesmente assumir o seu comando e executá-lo em uma API, como se houvesse experiência com um comando
‫de execução do Docker.
‫Na verdade, há uma API de Swarm totalmente nova que possui muitos serviços de fundo, como o agendador e o despachador,
‫e o alocador e orquestrador, que ajudam a tomar decisões em torno do que os trabalhadores
‫deveriam estar executando em qualquer momento.
‫Assim, os trabalhadores estão constantemente reportando aos gerentes e pedindo novos trabalhos.
‫Os gerentes estão constantemente distribuindo novos trabalhos e avaliando o que você lhes disse para fazer contra o
‫que eles realmente estão fazendo.
‫Então, se houver alguma reconciliação, eles farão essas mudanças, como talvez você tenha dito
‫para girar mais três tarefas de repetição nesse serviço.
‫Então, o orquestrador perceberá isso e depois emitirá ordens para os trabalhadores e assim por diante.
‫Com este modo de enxame, nós realmente conseguimos um conjunto de recursos repleto de recursos fora da caixa que nos permitem usar
‫as habilidades existentes do Docker que temos para implementar nossos contêineres na Internet de forma confiável
‫e resolver muitos problemas que teríamos uma vez que iremos
‫à produção.