1. Networking
1.1. Docker Container Networking Model (CNM)
1.1.1. O Docker Container Networking Model é um conjunto de conceitos e práticas que descreve como os contêineres Docker se comunicam entre si e com o mundo exterior através de redes.
1.1.1.1. Componentes
1.1.1.1.1. Sandboxes
1.1.1.1.2. Endpoints
1.1.1.1.3. Network
1.1.1.2. Conceitos
1.1.1.2.1. Network Drivers
1.1.1.2.2. IPAM Driver
1.1.2. Tipos de redes
1.1.2.1. None
1.1.2.2. Macvlan Network
1.1.2.3. Overlay Network
1.1.2.3.1. Permite a comunicação do docker em hosts direferentes
1.1.2.3.2. É o padrão para conexao quando usado o docker swarm
1.1.2.3.3. Para configurar uma rede **overlay** basta passar a flag **--driver** na criação de uma rede
1.1.2.4. Host Network
1.1.2.4.1. Usa a rede do host diretamente
1.1.2.4.2. Não tem sandbox e acaba com o isolamento dos containers
1.1.2.4.3. Não pode ter mais de 1 container na mesma porta
1.1.2.4.4. Nesse cenario se criar 2 containers, 1 ngnx e 1 busy_box, e rodar o comando **docker exec busy_box curl localhost:80** é possivel recuparar a pagina do container do ngnx e se chamar o localhost:80 no host, ou seja, fora dos container, tbm é possivel ver a tela do ngnx, isso se dá devido a falta de isolamento nos container
1.1.2.5. Bridge Network
1.1.2.5.1. Permite a comunicação dos containers dentro do mesmo host
1.1.3. comandos
1.1.3.1. Add a rede "my-network" ao rodar uma img **docker run --network my-network nginx** Add uma rede depois de criar o container **docker connect my-network <container>** Desconectar uma rede **docker network disconnect my-network <container>** Add um alias a rede **docker connect --alias my-alias my-network **
1.1.3.2. **--network-alias** funciona como uma apelido para invez de usar o nome do container para referenciar uma conexao, podemos usar o alias
1.1.3.3. Cria uma nova rede com o driver default "bridge" **docker network create my-network** Para definir um driver diferente **docker network create --driver overlay my-network**
1.1.3.4. Para visualizar os logs do container **docker logs <container>**
1.1.3.5. A flag **--attachable** usada no momento da criação da rede, é util pra permitir que containers que ja estao rondando possam anexar essa rede a eles, por padrao a rede criada nao é anexada
1.1.4. Swarm
1.1.4.1. Esse comando publica a porta apenas nos host que tem uma tarefa/replica rodando **docker service create -p mode=host,published=8082,target=80 nginx** Ja esse comando publica para todos hosts mesmo sem tarefa/replica rodando **docker service create -p mode=ingress,published=8082,target=80 nginx**
1.1.5. DNS
1.1.5.1. Podemos configurar o"dns" no **/etc/docker/daemon.json**, para todo o host
1.1.5.2. Podemos configurar o"dns" com a **flag --dns** no docker run para apenas **um** conteiner
1.1.6. Mode
1.1.6.1. Host
1.1.6.1.1. No modo de rede host, o contêiner utiliza diretamente a interface de rede do host. Isso significa que o contêiner não possui sua própria pilha de rede separada e compartilha o mesmo espaço de rede do host. O contêiner pode acessar os serviços do host e vice-versa usando o endereço IP do host diretamente. O contêiner não precisa de uma tradução de porta, ou seja, todas as portas expostas no contêiner estão disponíveis diretamente no host. Este modo é útil quando você precisa de alto desempenho e quer que o contêiner tenha acesso direto à rede do host sem encapsulamento adicional.
1.1.6.2. Ingress
1.1.6.2.1. O modo de rede ingress é usado principalmente em ambientes de orquestração de contêineres, como Docker Swarm ou Kubernetes. Nesse modo, a comunicação entre contêineres ocorre através de uma rede virtual interna gerenciada pela plataforma de orquestração. Os contêineres externos acessam os serviços dentro da orquestração usando balanceamento de carga, roteamento ou outros mecanismos fornecidos pela plataforma. Esse modo permite que você adicione ou remova contêineres de forma dinâmica e transparente para a comunicação externa.
2. Storages e Volumes
2.1. Storage Drivers ou Graph Drivers
2.1.1. Overlay2
2.1.1.1. É o padrao para o Ubunto e CentOS
2.1.2. aufs
2.1.2.1. É padrão para versoes mais antigas do ubuntu
2.1.3. devicemapper
2.2. Storage Model
2.2.1. Descreve como os dados são persistidos
2.2.1.1. Filesystem Storage
2.2.1.1.1. usado pelo **auf ** e **overlay2**
2.2.1.1.2. Dados são salvos em forma de arquivo
2.2.1.1.3. uso eficiente de memoria
2.2.1.1.4. ineficiente em processo de escrita pesada
2.2.1.2. Block storage
2.2.1.2.1. persiste dados em BLOCOS
2.2.1.2.2. usado pelo devicemapper
2.2.1.2.3. eficiente para processo de escrita pesada
2.2.1.2.4. normalmente precisa de um dispositivo diferente para configurar o block storage
2.2.1.3. Object storage
2.2.1.3.1. Armazena os dados como se fosse uma solução da aws o S3
2.2.1.3.2. sua aplicação deve ser preparada para o uso dessa forma de armazenamento
2.3. Volumes
2.3.1. Os volumes são gerenciados pelo Docker e geralmente são armazenados em um local dentro do sistema de arquivos do Docker, como /var/lib/docker/volumes/ (em sistemas Linux). Os dados dos volumes não estão diretamente expostos no sistema de arquivos do host.
2.3.2. Os volumes são independentes do ciclo de vida dos contêineres. Eles persistem mesmo que nenhum contêiner esteja atualmente usando-os. Os volumes são projetados para serem compartilhados entre contêineres e persistirem além da vida útil do contêiner.
2.3.3. Os volumes são gerenciados pelo Docker. Eles podem ser criados, listados, inspecionados e removidos usando comandos Docker específicos. Além disso, os volumes podem ter propriedades adicionais, como serem criptografados ou suportarem plugins de armazenamento em bloco.
2.3.4. Embora os volumes possam ter um leve impacto no desempenho devido à camada de abstração adicional, eles oferecem recursos adicionais, como gerenciamento simplificado e integração com plug-ins de armazenamento em bloco.
2.3.5. Também funcionam em todas as plataformas suportadas pelo Docker e oferecem uma camada de abstração adicional que pode facilitar a portabilidade dos aplicativos.
2.4. Bind Mounts
2.4.1. Com bind mounts, os dados residem em uma localização específica no sistema de arquivos do host. Isso significa que você pode montar um diretório específico do host dentro do contêiner.
2.4.2. Os dados em um bind mount são diretamente mapeados para o sistema de arquivos do host. Isso significa que eles existem mesmo quando nenhum contêiner está usando-os.
2.4.3. Os bind mounts são configurados diretamente pelo usuário, especificando o caminho do host e o caminho do contêiner.
2.4.4. Geralmente, os bind mounts têm melhor desempenho do que os volumes, pois não há camada adicional de abstração entre o contêiner e os dados no sistema de arquivos do host.
2.4.5. Funcionam em todas as plataformas suportadas pelo Docker.
2.5. tmpfs
2.6. Remote Storage Drivers
2.7. Plugins de Storage
2.8. Drivers
2.8.1. Overlay2
2.8.2. AUFS
2.8.3. Device mapper
2.8.3.1. loop-lvm
2.8.3.1.1. É default
2.8.3.1.2. Pessima perfomace, usar só pra testes
2.8.3.1.3. Não precisa de dispositivos adicionais
2.8.3.1.4. sem necessidade de muitas configurações
2.8.3.2. direct-lvm
2.8.3.2.1. Boa perfomace, usar em produção
2.8.3.2.2. Precisa de um despositivo de armazenamento adicional
2.8.3.2.3. Armazena dados em varios dispositivos
3. Exame
3.1. When Docker Content Trust is enabled, unsigned images will not be allowed to run on the system.
3.2. We need a Docker Enterprise Edition (EE) license to scan images within our registry.
3.3. docker network create --opt encrypted --driver overlay my-net **This command will create an encrypted overlay network.**
3.4. To prevent overwriting images in a repository by pushing a different image with an existing tag. **you can mark the repository as immutable.**
3.5. Iniciar um cluster swarm **docker swarm init**
4. Docker EE
4.1. Proprietaria é Maratins
4.2. Necessario ter 3 instacias de servidores
4.2.1. Universal Control Plane - UCP - Manager
4.2.2. UCP - Worker
4.2.3. DTR - Docker Trusted Registry