Iot Agent customizado

Para criar uma imagem do iotagent-xml:

1) tive que fazer o login no docker.io com o comando docker login docker.io
2) tive que criar um repositório privado no docker hub.
3) criação da imagem

4) fazer o push

Deploy da aplicação

Simulando a queda de um serviço na cloud:

Kubernets engine e cluster

Kubectl create

Simulando a queda de um POD, deletando-o:

deletando o POD que representa nosso banco, repare que a aplicação que representa o banco continua funcionando corretamente :

Kubernetes dashboard

Escalando os pods:

Criando objetos serviços:

Certificação Docker

https://success.docker.com/certification

validade de 2 anos. Depois disso tem que revalidar.

Kubernetes

Instalação do minikube: https://kubernetes.io/docs/tasks/tools/install-minikube/

Instalação do kubectl: https://kubernetes.io/docs/tasks/tools/install-kubectl/


Subindo o serviço:

aplicação:

Antes de criar um pod devemos deixar o minikube iniciado:

Criação de um pod:

Subindo a stack

cat > docker-compose.yml

copiar o conteúdo do arquivo para o docker-compose.yml acima.

docker stack deploy --compose-file docker-compose.yml vote


docker stack ls

docker service ls

repare que a coluna replicas ele demora um pouco para subir, por exemplo, replicas com 0/1 significa que de 1 zero subiu.

Os serviços demoram para serem executados.

Se eu quiser apagar é docker stack rm vote

Comunicação através do nome e não do ip

Service discovery

Iremos criar um serviço chamado serviço que roda o alpine (um linux leve), foi colocado a flag sleep 1d para que a máquina não caia.

Rede ingress

Serviços globais

Para apagar um serviço que já está em execução digitamos o seguinte comando:

docker service rm idDoServiço

//para pegar o id do serviço digite: docker service ls

Ou seja, com isso todos os nós (vms) terão uma réplica:

Serviços replicados

Readicionando um manager

Para um nó líder ser removido com o comando docker node rm vm1, por exemplo, temos que rebaixá-lo para um nó worker.

O comando (na vm2) docker node demote vm1 rebaixa o nó para worker.

Feito isso, digitamos o comando docker swarm join-token manager, copiamos e colamos o comando gerado na vm1 para deixá-la como manager.

Na vm2: docker service create -p 8080:3000 aluracursos/barbearia

docker service ls

Devemos executar um serviço dentro de um manager?

Para deixar novamente active: docker node update --availability active vm2

Executando tarefas somente nos workers: docker service update --constraint-add node.role==worker

Se uma tarefa já estiver rodando em uma manager devemos rodar o comando docker service update --constraint-add node.role==worker colocarOiddatarefa

Para  descobrir o id da tarefa digitar o comando docker service ls.

Eu posso parar um serviço que está rodando em uma vm para que esse serviço rode em outro worker. 

docker container rm idDoServiço --force

se eu voltar para a vm manager e digitar o comando docker service ps idDoServiço vemos que o serviço está executando em outra vm.

Criando mais managers

Criando mais 2 workers:

Tanto faz se eu for na vm2 ou vm3 e digitar o comando docker swarm join-token worker  porque conforme vemos na figura anterior elas também são managers. 

Caso o líder, que no caso é a vm1 caia, quem será escolhido como líder? Através do consenso.

Podemos simular uma queda da vm1 da seguinte forma:

docker swarm leave --force

O novo líder agora é a vm2: