Qual é o recurso mais importante de qualquer aplicativo baseado na web? São muitos, mas para mim alta disponibilidade é o mais importante. É isso que o Docker Swarm nos ajuda a alcançar! Ajuda na alta disponibilidade do aplicativo.
No meu blog anterior , Expliquei como o Docker Compose funciona. Este blog no Docker Swarm é uma continuação do anterior e aqui os benefícios de usar o Docker Swarm para contêiner qualquer aplicativo de vários contêineres foram explicados.
No caso deste blog, é apenas um aplicativo Angular que será acoplado ao Docker Swarm.
Nota : O método para armazenar o aplicativo MEAN Stack é o mesmo.
Então, o que é Docker Swarm?
Docker Swarm é uma técnica para criar e manter um cluster de Docker Engines . Os motores Docker podem ser hospedados em nós diferentes, e esses nós que estão em locais remotos formam um Grupo quando conectado no modo Swarm.
Por que usar o Docker Swarm?
Pelas razões já mencionadas! Conquistando alta disponibilidade sem nenhum tempo de inatividade é uma prioridade para todos os provedores de serviços. A alta disponibilidade impressionará seus clientes? Bem, eles não ficarão impressionados se enfrentarem o tempo de inatividade. Isso é um acéfalo.
Outros benefícios do Docker Swarm
Como muitos outros serviços, o Docker Swarm faz balanceamento de carga para nós. Portanto, não há necessidade de os engenheiros de DevOps encaminharem solicitações de processamento para outros nós quando um falhar. O gerenciador do cluster executará automaticamente o balanceamento de carga para nós.
Acesso descentralizado é outro benefício. O que isso significa? Isso significa que todos os nós podem ser acessados facilmente a partir do gerenciador. O gerenciador também avisará os nós regularmente e manterá um controle de sua integridade / status para lidar com o tempo de inatividade. No entanto, os nós não podem acessar ou rastrear os serviços em execução em outros nós / gerenciadores.
Você pode verificar o não. de contêineres em execução em um nó, aumento de escala o não. de recipientes ou diminuir gradativamente o não. com base em nosso requisito, apenas executando um único comando.
Mesmo depois que um aplicativo foi implantado, podemos emitir atualizações contínuas e certifique-se de que a CI (Integração Contínua) seja alcançada. As atualizações contínuas são emitidas para um nó após o outro, garantindo assim que não haja tempo de inatividade e que a carga seja distribuída entre outros nós no cluster.
Então, o que vem a seguir? Para fazer o óbvio. Comece a usar o Docker Swarm se você já trabalhou no Docker ou se sua organização deseja colocar em contêiner um serviço da web confiável.
Nota : Os motores Docker são instalados em hosts / servidores independentes ou em várias VMs em um host.
Introdução ao modo Swarm
O Docker Swarm é iniciado pelo gerenciador, ou deixe-me colocar desta forma, a instância que inicia o cluster Swarm se torna o gerenciador. O comando para iniciar o cluster é:
$ docker swarm init --advertise-addr endereço IP
Aqui, o sinalizador ‘–advertise-addr’ é usado para anunciar-se a outros nós que desejam ingressar no cluster. O endereço IP do gerente precisa ser especificado junto com o sinalizador. Abaixo está o exemplo de captura de tela.
Quando o cluster Swarm é iniciado, um token é gerado na extremidade do gerenciador. Este token precisa ser usado por outros nós para se juntar ao cluster swarm.
Como é isso exatamente? Copie todo o token gerado no mecanismo docker do gerenciador, cole-o no mecanismo docker do nó e execute-o. A parte destacada da imagem acima é um token. Quando o token é executado em um nó de trabalho, ele se parece com a captura de tela abaixo.
diferença entre final finalmente e finalizar em java
Qualquer nó que ingresse no cluster pode ser promovido posteriormente a gerenciador. Caso você queira que um docker engine se junte a um gerenciador, execute o comando abaixo no final do gerenciador:
gerenciador de token de junção $ docker swarm
Posteriormente, se quiser que o token de um nó se junte ao cluster, execute o comando abaixo:
nó de token de junção $ docker swarm
Vá em frente e execute o token em cada nó que você deseja, para ingressar no cluster. Quando tudo isso estiver feito, você pode executar um comando docker node list para verificar quantos nós se juntaram ao cluster junto com seu status. O comando é:
$ docker node ls
A captura de tela está abaixo:
Criação de uma imagem Docker para aplicativo angular
Se tudo estiver bem, então podemos iniciar nosso serviço Swarm, desde que a imagem do Docker seja construída. A imagem Docker pode ser construída a partir do Dockerfile. O Dockerfile usado para construir os aplicativos está abaixo:
DO nó: 6 RUN mkdir -p / usr / src / app WORKDIR / usr / src / app COPY package.json / usr / src / app RUN npm cache clean RUN npm install COPY. / usr / src / app EXPOSE 4200 CMD ['npm', 'iniciar']
O Dockerfile é usado para executar um conjunto de comandos juntos para construir uma imagem Docker personalizada a partir de uma imagem base. Como você pode ver, a imagem base que usei é ‘Nó: 6’. NodeJS é a imagem I do Docker Hub marcada com a versão 6.
Em seguida, estou criando um novo diretório Docker dentro do contêiner e tornando-o o diretório de trabalho dentro do meu contêiner.
Estou copiando o arquivo ‘package.json’ da minha máquina local para o diretório de trabalho do contêiner. Em seguida, estou especificando os comandos ‘RUN npm cache clean’ e ‘RUN npm install’. npm install comando baixa a versão das dependências mencionadas no arquivo package.json.
Em seguida, estou copiando todos os códigos do projeto da máquina local para o contêiner, expondo a porta número 4200 para acessar o aplicativo Angular no navegador e, por fim, estou especificando o comando npm start que coloca o aplicativo em contêiner.
Agora, para criar a imagem Docker com base neste Dockerfile, execute o comando abaixo:
$ docker build -t angular-image.
Nota: As imagens do Docker precisam ser construídas em todos os nós do cluster. Sem ele, os contêineres não podem ser girados em outros motores Docker.
Iniciando o serviço Docker Swarm
Dado que nossa imagem do Docker é construída, podemos girar um contêiner a partir dessa imagem. Mas faremos algo melhor: criar um serviço Docker Swarm a partir dele. O comando para criar um serviço swarm é:
$ docker service create --name 'Angular-App-Container' -p 4200: 4200 imagem angular
Aqui, o sinalizador 'nome' é usado para dar um nome ao meu serviço e o sinalizador 'p' é usado para expor a porta do contêiner à porta do host. No arquivo package.json, especifiquei a porta do contêiner na qual o aplicativo Angular deve ser hospedado. E o 4200 neste comando ajuda a mapear a porta 4200 do contêiner para a porta 4200 do host. ‘Imagem-angular’ é o nome da imagem que eu construí anteriormente.
Lembrar : Quando criamos um serviço, ele pode ser hospedado em qualquer docker engine no cluster. O gerente do enxame decidirá onde ele será hospedado. Mas, não importa em qual nó está hospedado, o aplicativo pode ser acessado em localhost: 4200 de qualquer um dos nós conectados no cluster.
Como isso é possível? Porque o Swarm expõe internamente os números das portas para serem acessíveis por todos os outros nós do cluster. Isso significa que porta não. 4200 em qualquer nó / gerenciador no cluster renderizaria o aplicativo Angular.
O que agora? O contêiner está ativo?
Você pode verificar se o serviço está em contêiner executando o comando docker service list. Porém, pode demorar um minuto para o contêiner ser implantado. Abaixo está o comando:
$ docker service ls
Este comando listará todos os serviços gerenciados pelo cluster Swarm. Em nosso caso, ele deve exibir um contêiner ativo. Veja a captura de tela abaixo para referência.
Aqui, 'REPLICAS = 1/1' indica que há um único 'serviço' desse contêiner, no cluster. E “MODE = replicated” indica que o serviço é replicado em todos os nós do cluster.
Agora, para identificar em qual nó / gerenciador o aplicativo está hospedado, podemos executar o comando docker service ps seguido do nome do contêiner. O comando é:
$ docker service ps Angular-App-Container
A captura de tela para o mesmo está abaixo.
Isso menciona detalhes sobre o nó no qual o aplicativo está hospedado junto com o comando usado para iniciar o serviço.
O comando 'docker ps' esclarece os detalhes sobre o contêiner ativo. O comando é:
$ docker ps
Veja a captura de tela abaixo para referência.
Porém, este comando só funcionará no gerenciador de cluster e no nó onde o serviço está realmente hospedado.
Para verificar quantos nós estão em execução, execute o comando node list. O comando é:
$ docker node ls
Para verificar os contêineres em execução em um determinado host, execute o comando node ps. O comando é:
$ docker node ps
Se você se lembra, mencionei anteriormente que o serviço está sendo executado em MODO replicado. Isso significa que o serviço é replicado em todos os nós dos clusters. Você acha que existe uma alternativa?
Absolutamente! Existe algo chamado Global MODE. Neste modo, há um serviço deste contêiner em execução em cada / gerenciador no cluster. Lembre-se de parar o serviço / contêiner atual antes de girar outro conjunto de contêineres.
O comando para isso é:
$ docker service rm Angular-App-Container
O comando para girar o contêiner no modo Global é:
$ docker service create --name 'Angular-App-Container' -p 4200: 4200 --mode global angular-image
Isso criaria 3 serviços nos 3 nós em nosso cluster. Você pode verificar isso executando o comando docker service list. A imagem disso está abaixo.
Quando o comando docker service ps for executado, você verá algo assim:
Como você pode ver, ele diz que o modo é replicado e as réplicas desse container são 3. Agora vem a melhor parte deste blog.
Para ter 2 réplicas dos serviços em execução entre os três contêineres, podemos usar o sinalizador replicas. Observe o comando abaixo:
$ docker service create --name 'Angular-App-Container' -p 4200: 4200 --replicas = 2 imagem angular
Você notará que esses 2 serviços têm balanceamento de carga entre os três nós do cluster. Execute o comando docker service process para verificar em quais nós os contêineres estão ativos. Veja a captura de tela abaixo para referência. Os contêineres estão ativos em um nó gerenciador e um nó trabalhador.
No nó Worker, você pode verificar se o contêiner está em execução executando o comando ‘docker ps’.
Docker Swarm para alta disponibilidade
Agora, para realmente verificar se há alta disponibilidade em nosso cluster, precisamos experimentar um cenário em que um dos nós fica inativo e outros nós do cluster compensam isso. Podemos criar esse cenário parando manualmente o contêiner de um dos nós usando este comando:
$ docker stop Angular-App-Container
Execute o comando acima no nó: Worker-1 onde o contêiner está sendo executado.No gerenciador, execute o comando:
$ docker service ps Angular-App-Container
Agora você notará que o contêiner está em execução no nó: Worker-2 e Manager. No entanto, ele foi desligado do nó: Worker-1. O mesmo é visível na imagem abaixo.
É assim Docker de alta disponibilidade é alcançado. EuApesar de o contêiner estar inativo no Worker-1, o aplicativo pode ser renderizado na porta número 4200 nesse nó do trabalhador. Isso ocorre porque ele está internamente conectado a outros nós no cluster e é capaz de renderizar o aplicativo no navegador.
Alta disponibilidade após expansão dos serviços
Seja no modo replicado ou no modo global, podemos aumentar o número de serviços em execução em nosso cluster. E mesmo após o escalonamento, seremos capazes de manter a alta disponibilidade. Incrível, não é?
como encontrar palíndromo em java
Mas, voltando ao nosso ponto, vamos ver como é fácil aumentar o número de serviços em nosso cluster. Supondo que tenhamos 2 ou 3 réplicas em nosso cluster, vamos aumentar os serviços para 5 apenas executando um único comando. O comando é:
$ docker service scale Angular-App-Container = 5
A imagem disso está abaixo.
Ao executar o comando docker service list, você pode notar que o número de réplicas agora é 5. E ao executar o comando docker service ps junto com o nome do serviço, você pode ver como os 5 serviços têm balanceamento de carga e são distribuídos nos 3 nós . Os comandos são:
$ docker service ls $ docker service ps Angular-App-Container
E, finalmente, em uma configuração Docker Swarm, se você não quiser que seu gerente participe dos procedimentos e o mantenha ocupado apenas para gerenciar os processos, podemos drenar o gerente de hospedar qualquer aplicativo. Porque é assim que funciona no mundo, não é? Os gerentes são apenas para gerenciar outros trabalhadores. De qualquer forma, o comando para fazer isso é:
$ docker node update --availability dreno Manager-1
Você pode verificar se o gerenciador agora está participando do cluster executando o comando docker node list e o comando docker service ps:
$ docker node ls $ docker service ps Angular-App-Container
Agora você pode notar que os serviços do contêiner foram divididos entre os nós de trabalho e o nó do gerenciador na verdade foi esvaziado de contêiner de qualquer serviço. A imagem está abaixo.
Então, isso encerra este blog no Docker Swarm. Espero que este blog tenha explicado como é importante implementar o modo Swarm para obter alta disponibilidade. Fique ligado para mais blogs nesta série de tutoriais do Docker.
Você também pode assistir ao vídeo abaixo para entender como funciona o Docker Swarm. Todos os conceitos explicados acima foram abordados no vídeo.
Docker Swarm para alta disponibilidade | Tutorial do Docker | Tutorial DevOps
Agora que você aprendeu sobre o Docker, verifique o pela Edureka, uma empresa de aprendizagem online confiável com uma rede de mais de 250.000 alunos satisfeitos espalhados por todo o mundo. Este curso de Treinamento de Certificação Edureka Docker ajuda os alunos a ganhar experiência na implementação e domínio do Docker.
Tem alguma questão para nós? Mencione isso na seção de comentários e entraremos em contato com você.