Kubernetes – Iniciando com services

Olá pessoal como foi mencionado nesse post https://www.mundodocker.com.br/iniciando-com-pods/  há algumas semanas atrás, vamos dar continuidade a nossa série sobre Kubernetes, na primeira etapa mostramos como realizar a instalação, configuração e como poderíamos iniciar nossos primeiros Pods(containers) e hoje vamos demonstrar como podemos abstrair os nossos Pods e trabalhar diretamente com Services.

Pods é o menor objeto que pode ser criado no Kubernetes, eles são processos mortais  sendo executados em um cluster. Eles nascem e morrem porém não são ressuscitados.  Quem pode fazer o papel de ficar criando e destruindo os Pods dinamicamente é o Replication Controller que é um objeto do Kubernetes que faz com que sempre existam x Pods dentro de um Cluster.

Cada Pod ao ser criado recebe um endereço IP, porém ao ser destruído e recriado esse endereço IP é alterado. Então se temos um conjunto de Pods chamados de Backend que dependem de acesso de um outro conjuntos de Pods por exemplo Frontend como o conjunto de Frontend pode saber quais os componentes do Backend?

É nesse caso que usamos services, que é uma abstração que define um conjunto de Pods e sua politica de acesso, geralmente esse conjunto de Pods é identificado através de um Label Selector. Como exemplo de uso de um service podemos dizer que temos 3 Pods de MongoDB nos quais temos um Frontend que realiza o acesso, com a criação de um service o Frontend não vai precisar associar a aplicação aos Pods e sim ao service então os Pods podem ser recriados a qualquer instante que o Frontend continuará funcionando devido ao service realizar toda a parte de gerenciamento dos Pods abstraindo isso para o Frontend.

Agora vamos poder visualizar qual seria uma construção básica do meu service, nesse caso estamos usando como exemplo um conjunto de Pods que espoem a porta 8500 e que possuem como Selector “MeuApp” :

kind: Service
apiVersion: v1
metadata:
name: meu-service
spec:
selector:
app: MeuApp
ports:
- protocol: TCP
port: 80
targetPort: 8500

Com Kubernetes é possivel querer expor o serviço a um IP externo para acesso de alguma aplicação ou algum cliente, então para esse caso existe “ServiceTypes” onde é possivel especificar o tipo de serviço desejado, por padrão o criado é o ClusterIP que faz com que o serviço seja exposto com um IP do cluster, tornando o acessível apenas através do cluster. Existem outros 3 tipos de serviços:

– NodePort: Expõe o serviço em cada IP do Nó em uma porta estática (o NodePort). Um serviço ClusterIP, ao qual o serviço NodePort encaminhará, é automaticamente criado. Você poderá entrar em contato com o serviço NodePort, de fora do cluster, solicitando : .

– LoadBalancer: Expõe o serviço externamente usando o balanceador de carga de um provedor de nuvem. Os serviços NodePort e ClusterIP, aos quais o balanceador de carga externo encaminhará, são criados automaticamente.

– ExternalName: Mapeia o serviço para o conteúdo do campo externalName (por exemplo, foo.bar.example.com), retornando um registro CNAME com seu valor. Nenhum proxy de qualquer tipo é criado. Isso requer a versão 1.7 ou superior do kube-dns.

Caso você escolha o Type NodePort o Kubernetes irá definir por padrão uma porta entre (30000-32767) para expor em cada nó de proxy do Kubernetes. Caso você deseje especificar um número de porta é possivel utilizar a propriedade nodeport para escolher uma porta fixa, porem deve se ter cuidado para não colocar mais serviços na mesma porta, o que acarretará em um erro na hora de subir o serviço.

Então hoje podemos entender um pouco mais de como funciona o componente “Service” dentro do Kubernetes e nos próximos capítulos vamos trabalhar mais a questão prática com o deploy de algumas aplicações.

 

Obrigado e uma ótima semana a todos 😀

 

Iniciando com Pods

Olá pessoal,

Hoje quero fugir um pouco do tema “Docker” e quero mostrar para vocês um pouco mais de “Kubernetes”. Em dois posts anteriores mostrei como era complicada a instalação e configuração do Kubernetes caso não quizesse usar AWS ou Google Cloud. Com a comunidade sempre mostrando o quanto a instalação do Kubernetes era sempre trabalhosa, a partir da versão 1.4 foi criado o utilitario “kubeadm” que é utilizado para realizar a instalação de um cluster de Kubernetes de maneira rápida e fácil possibilitando assim uma maneira fácil de instalação e assim aderiando mais pessoas utilizando a ferramenta.

 

Passo 1 – Vamos iniciar agora a instalação do Kubernetes em alguns passos simples e depois vamos realizar algumas operações básicas para que você possa conhecer mais sobre essa ferramenta tão poderosa.

apt-get update && apt-get install -y apt-transport-https
curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | apt-key add -
cat < /etc/apt/sources.list.d/kubernetes.list
deb http://apt.kubernetes.io/ kubernetes-xenial main
EOF

 
apt-get update
# Install docker if you don't have it already.
apt-get install -y docker.io
apt-get install -y kubelet kubeadm kubectl kubernetes-cni

Passo 2 – Parecido com a sintaxe do comando para iniciar um cluster com o “docker swarm” com o comando abaixo vamos estar iniciando o cluster com Kubernetes. Caso tenha 2 placas de redes em seu servidor você poderá especificar qual deseja utilizar com --api-advertise-addresses <ip-address> passando como parâmetro para o comando kubeadm init

Na saída do comando será possível visualizar, no final a instrução para você adicionar um outro nó ao seu cluster, para isso basta você repetir o passo 1 em seu outro nó e colar a saída do comando acima onde mostra:

kubeadm join --token=<token> <master-ip>

Após realizar os passos acima você estará com seu cluster de kubernetes quase pronto, porém ainda para que você possa fazer funcionar o seu cluster perfeitamente, você ainda precisa que seja instalado um plugin de rede para que o cluster de Kubernetes esteja a funcionar 100% para isso basta você executar:

kubectl apply -f https://git.io/weave-kube

Nesse caso o plugin escolhido foi o do Weave. Agora pronto estamos com nosso cluster de Kubernetes no ar e podemos começar a realizar as operações básicas em um cluster. Para isso vamos iniciar trabalhando com Pods.

Se você não sabe ainda os principais componentes do Docker, então você pode acompanhar um outro post nosso que fala sobre isso aqui. Então vamos por a mão na massa:

Com o comando kubectl é possivel fazer todas as operações que precisamos que sejam feitas em caso de lidarmos com containers. Então para listarmos os Pods que temos criados podemos executar o comando:

kubectl get pods 

Isso irá trazer os pods que foram criados no Namespace default. Namespaces são clusters virtuais dentro de um cluster físico, então eu posso ter dezenas de Namespaces em 1 cluster de kubernetes e em cada Namespace ter diversos Pods nos quais possuem total isolamento entre eles. Com namespace então eu posso limitar recursos como: CPU, Memória, Disco e Rede. Para que eu liste todos os Pods criados em todos os namespaces basta eu executar:

kubectl get pods --all-namespaces 

Para criar um Pod com uma imagem do Node.Js por exemplo você utiliza:

kubectl run --image=ghost --port=2368

Estou utilizando a porta 2368, pois é a que está com o EXPOSE no Dockerfile. Também é possivel criar 1 Pod com n container no caso você deve utilizar o parâmetro --replicas

kubectl run node --image=ghost --replicas=5 --port=2368

Nesse caso será criado os cinco containers no Docker porém apenas 1 Pod estará visivel no Kubernetes. Agora para que possamos acessar a nossa aplicação através do Browser devemos expor a porta 2368 para alguma porta do Host, o mesmo conceito do Docker, porém sintaticamente de uma forma diferente. Para isso utilizamos o comando:

kubectl expose deployment node --target-port=2368 --type=LoadBalancer

Com o comando acima estamos dizendo para o Kubernetes pegar alguma porta livre no host e redirecionar o tráfego para a porta 2368 dentro do container e que o tipo de envio seja um LoadBalancer entre as replicas que eu mandei criar, então no caso das 5 réplicas que foram criadas acima, cada requisição será enviada para uma replica diferente da outra.


Mais para frente entraremos mais a fundo no Kubernetes, mas agora quando executamos o comando kubectl expose o Kubernetes criou um service de forma abstrata, podemos agora de forma resumida dizer que um service tem o papel de Habilitar um endpoint para que o usuário consiga acessar a aplicação". Então se você executar o comando:

kubectl get services

Você irá ver algo parecido com isso:


NAME         CLUSTER-IP       EXTERNAL-IP   PORT(S)          AGE
node         10.100.162.143        2368:31529/TCP   10s

Então a porta para que possamos acessar nossa aplicação será a porta 31529


Conforme criamos os primeiros posts sobre como criar containers, imagens e coisas mais simples com Docker, começaremos a fazer também com o Kubernetes, então vamos evoluir cada vez mais o conteúdo para que possa ser útil tanto para as pessoas que estão pensando em começar a usar, como também as que estão usando a um certo tempo.


Obrigado e fique ligado, pois em breve estaremos lançando novidades para os nossos leitores que estão se cadastrando em nossas Newsletter.

Grande abraço!

Docker Compose v3

Olá pessoal, tudo bem?

 

Conforme falamos em um post anterior o Docker lançou uma nova versão a 1.13 e nessa nova versão tivemos diversas melhorias e com a entrada dessa nossa versão também tivemos a criação de uma nova versão no Docker Compose que é a v3. Essa nova versão é totalmente compatível com o Docker Swarm que hoje é nativo na mesma engine no Docker, então agora com Docker Compose podemos gerenciar nossos serviços através do Docker Swarm.

Agora com a V3 existe opção chamada deploy que é responsável por realizar as implantações e execução de serviços. Dentro dessa opção temos as seguintes funções:

  • Mode
    • Onde é possível escolher a opção “Global” (Um container por nó de swarm) ou “Replicated” (Onde posso escolher a quantidade de réplicas que estarão distribuídas entre os nós). O padrão é replicated.
    • Replicas
      • replicas: x
    • Global
  • Placement
    • Especifica restrições de posicionamento são elas:
      • node.id = idworker
      • node.hostname = nomeworker
      • node.role = manager ou worker
      • node.lables = nome
      • engine.labels = Sistema Operacional ou Driver
  • Update_config
    • Configura como devem ser as opções de atualizações dos serviços.
    • Parallelism: 5 #O Numero de containers que vão ser atualizados em paralelo.
    • delay: 10s #O tempo entre cada grupo de containers será atualizado
    • failure_action: pause ou continue #O que irá acontecer se a atualização falhar. O padrão é pause.
    • monitor: 0s # Duração após cada atualização para monitorar a falha. O padrão é 0s.
    • max_failure_ratio: #Taxa de falha para atualizar.
  • resources
    • Configura a restrição de recursos
      • limits:
        • cpus: ‘0.5’ # 0.5 representa 50% de um núcleo, porem pode ser 1 ou 1.5 ou 2….
        • memory: ‘512M’ #apenas especificar o prefixo M, G, K….
  • Restart_policy
    • Configura como reiniciar os containers quando eles derem exit.
      • condity: none on-failure any #Por padrão é any
      • delay: 0s #Tempo entre as tentativas de reiniciar o containers #Por padrão é 0s
      • max_attempts: 0 #Quantas vezes irá tentar subir o container antes de desistir #Por padrão é nunca desistir.
      • window: 0s #Quanto tempo demora para decidir se um reinicio foi bem sucedido  #Por padrão é imediatamente,

 

Alem dessas opções, com a entrada da V3 foram descontinuadas as seguintes opções do Docker Compose: volume_driver, volumes_from, cpu_shares, cpu_quota, cpuset, mem_limit, memswap_limit

Agora vamos demonstrar um exemplo de como ficaria o docker-compose.yml com essas opções que mostramos acima.

version: "3"
services:

  redis:
    image: redis
    ports:
      - "6379"
    deploy:
      placement:
        constraints: [node.role == manager]
  nginx:
    image: nginx
    ports:
      - 80:80
    depends_on:
      - redis
    deploy:
      mode: replicated
      replicas: 2
      placement:
        constraints: [node.role == manager]
      resources:
        limits:
          memory: 512M
      restart_policy:
        condition: on-failure
        delay: 10s

Executando o comando docker deploy --compose-file docker-compose.yml nomedastack criamos a stack mencionada acima em nossa estrutura. Após executar esse comando é possível dar um docker stack ls e você poderá ver que a sua stack foi criada, com o nome da sua stack você pode executar o docker stack services nomedastack e poderá ver os serviços criados e qual o seu status.

Então ta pessoal, por hoje era isso, espero que tenham gostado e qualquer dúvida é só deixar um comentário que estaremos felizes em lhe ajudar, nos ajude divulgando o blog obrigado!

 

Docker – Device mapper

Olá pessoal,

No primeiro post da série falamos sobre AUFS e hoje vamos falar um pouco sobre Device Mapper.

Origem

No começo o Docker era suportado apenas em distribuições Ubuntu, Debian e usavam AUFS para o seu armazenamento. Depois de algum tempo o Docker começou a se popularizar e as pessoas começaram a querer utilizar Docker com RedHat, porêm o AUFS era suportado apenas em sistemas (Debian,Ubuntu).

Então os engenheiros da Redhat baseados no código do AUFS decidiram desenvolver uma tecnologia própria de armazenamento baseado no já existente “Device mapper”. Então os engenheiros da RedHat colaboraram com o “Docker inc” para contribuir com um novo driver de armazenamento para containers. Então o Docker foi reprojetado para fazer a conexão automática com o dispositivo de armazenamento baseado em Device Mapper.

Layers

O Device Mapper armazena cada imagem e container em seu disco virtual, esses discos virtuais são dispositivos do tipo Copy-on-Write no nível de bloco e não a nível de arquivo. Isso significa que ao invés do Device Mapper copiar todo um arquivo para o seu dispositivo, ele vai copiando por blocos o que o torna muito rápido comparado ao AUFS. No processo de criação de uma imagem com o Device Mapper é criado um pool e em cima desse pool é criado um dispositivo base que é a partir dele que as imagens são construídas, a partir dai temos as imagens base do Docker que a cada modificação vão criando camadas de snapshots a cima da camada anterior. Conforme a imagem abaixo:

https://docs.docker.com/engine/userguide/storagedriver/images/two_dm_container.jpg

Read

Quando um container deseja ler algum arquivo que está nas camadas anteriores o Device Mapper cria um ponteiro na camada do container referenciando a camada da imagem onde possui esses dados colocando transferindo esse bloco para a memória do container.

Write

Quando o Docker faz uma alteração no arquivo utilizando Device Mapper esse arquivo é copiado apenas o que sera modificado cada bloco de modificação copiado é de no máximo 64KB. Por exemplo na escrita de um arquivo de 40KB de novos dados para o container o Device Mapper aloca um único bloco de 64KB para o container, caso a escrita seja de um arquivo maior que 64KB então o Device Mapper aloca mais blocos para realizar essa gravação.

O Device Mapper já é padrão nas em algumas distribuições do linux como:

  • RedHat/Centos/Fedora
  • Ubuntu 12.04 e 14.04
  • Debian

Docker e Device Mapper

O Device Mapper atribui novos blocos para um container por meio de uma operação chamada “Allocate-on-Demand”, isso significa que cada vez que uma aplicação for gravar em algum lugar novo dentro do container, um ou mais blocos vazios dependendo do tamanho de gravação terão que ser localizados a partir do pool mapeado para esse container. Como os blocos são de 64KB então muitas gravações pequenas podem sofrer com problemas de performance, pois acaba causando lentidões nas operações. Com isso aplicações que gravam arquivos pequenos sequencialmente podem ter performance piores com Device Mapper do que com AUFS.

Legal né? Se gostou nos ajude divulgando o blog.

Grande abraço!

 

Docker – AUFS

Olá pessoal,

AUFS foi o primeiro controlador de armazenamento em uso com Docker, como beneficio tem uma história longa com Docker. É muito estável, tem grandes implementações no mundo real e possui forte apoio da comunidade, o AUFS possui diversas características que acabam o tornando uma boa escolha para uso com Docker. Entre elas estão:

  • Tempo de inicialização do container rápido
  • Uso eficiente de armazenamento
  • Uso eficiente de memória

Apesar de ter uma ampla capacidade de caracteristicas com Docker, algumas distribuições não possuem suporte ao AUFS, pois ele não está incluído na linha principal do Kernel Linux, no caso do RHEL não é suporte AUFS.

Os tópicos seguintes demonstram algumas características do AUFS e como ele se relaciona com o Docker:

 

Layers de Imagens:

AUFS é um sistema de unificação de arquivos, isso quer dizer que ele leva vários diretórios em um único host linux, colocando um sobre o outro e fornece uma visão unificada desses arquivos para conseguir isso o AUFS usa uma união de montagem.

O AUFS driver de storage do Docker implementa Layers de imagens utilizando usando a união do sistema montado. Abaixo podemos ver um exemplo de Layers, onde para o cliente é apresentado a união de todas elas:

 

layer1

 

Utilizando arquivos:

O Docker utiliza a tecnologia de “AUFS CoW”  para conseguir compartilhar a imagem e minimizar o uso de disco. Como o AUFS trabalha em nível de arquivos então todos os dados são copiados por inteiros para a camada superior mesmo que modificando uma pequena parte do arquivo, isso faz com que dependendo do tamanho de arquivo que será copiado acabe penalizando um pouco o desempenho do container, pois um arquivo muito grande demorará algum tempo para que seja copiado. Ou também a imagem possui uma grande quantidade de camadas e o arquivo que você deseja utilizar está na primeira camada da imagem.

A ordem de procura é de cima para baixo, então caso seja a primeira vez que o usuário irá utilizar aquele arquivo, então o Docker vai procurar esse arquivo nas suas camadas abaixo e copiar todo o seu conteúdo para a camada gravável do container. Porém o arquivo só é copiado na primeira vez, após isso o esse arquivo já está na ultima camada então todas as demais operações são rápidas.

Deletando arquivos:

O driver do AUFS exclui um arquivo de dentro do container colocando um arquivo whiteout na camada gravável do container. O arquivo whiteout obscurece a existência do arquivo nas camadas inferiores de imagem:

 

 

layers2

 

 

Você pode adicionar o driver AUFS no seu daemon docker editando o arquivo de conf do docker e adicionando:

DOCKER_OPTS="--storage-driver=aufs"
systemctl restart docker

 

Então ta pessoal esse é nosso primeiro post dessa série que vai mostrar para vocês os drivers de armazenamento nativos do Docker.

 

Docker Run – Avançado

Olá pessoal,

Hoje vamos falar um pouco mais sobre as opções que talvez muitas pessoas não conhecem sobre o Docker run e que podem ajudar você diariamente a subir suas aplicações com mais segurança e também com mais praticidade. A ideia por trás desse post não é mostrar como criar um container, mas sim quais as opções novas e que podemos utilizar em nosso dia a dia.

PID settings (–pid)

Por padrão todos os containers possuem o PID namespace habilitado. O Namespace PID remove o ponto de vista dos processos do sistema e permite ids de processos para ser utilizado. Em alguns casos você pode querer rodar alguma ferramenta de depuração em seu container para que ele consiga visualizar os processos do seu host, então basta iniciar o container com a opção de –pid ativado:

docker run -it --rm --pid=host imagem

É possível também utilizar o –pid para depurar as informações de outro container, para isso vamos iniciar a execução de um container com mongoDB e depois um container para realizar a depuração

docker run --name mongo -d mongodb 
docker run --it --pid=container:mongo imagem

–dns

Por padrão os containers irão compartilhar os mesmos servidores de DNS que estão sendo utilizados em seu host, então na hora de criação de cada container você pode utilizar o parâmetro –dns=”8.8.8.8″ por exemplo.

–add-host

O docker ja cria dentro de cada container em /etc/hosts o arquivo com algumas configurações de rede, como:

172.17.0.2 02ed3f564f1b
127.0.0.1 localhost
fe00::0 ip6-localnet

Porem é possivel na hora da criação do container você adicionar mais uma entrada dentro do arquivo de hosts para isso basta colocar a opção –add-host em seu “docker run”

 docker run -it --add-host entrada:ip -d centos

–security-opt

Nas versões mais recentes do Docker é possível você limitar para que os comandos que exigem privilégios dentro do Docker não sejam mais executado, como: su ou sudo para isso basta executar:

docker run --security-opt no-new-privileges -d centos

–restart

Utilizando essa opção é possível realizar a reinicialização de containers a partir de determinados evento, são esses: on-failure, always, unless-stopped.

  • On-failure: Reinicia somente se o status de saída do container por diferente de 0, é possível limitar o numero de tentativas de reinicialização. O docker irá esperar 100ms na primeira vez que tentar reiniciar o container, caso vá para segunda vez então irá esperar 200ms e depois 400ms e assim dependendo do número de tentativas.
 docker run --restart=on-failure:3 centos
  • Always: Sempre reinicie o container independentemente do status de saída. Na reinicialização do servidor, o container irá subir automaticamente após o serviço do docker ser startado.
 docker run --restart=always centos
  • Unless-Stopped: Inicialize o container independentemente do status de saída, porem na reinicialização do servidor ou do serviço do Docker o container não irá subir automaticamente;
 docker run --restart=unless-stopped centos

O status de saída exibido pelo Docker no docker run pode ser visto utilizando a seguinte opção:

 docker run redis; echo $?

Existem alguns números já conhecidos, 125 (Problema com o docker daemon), 126 (Comando não pode ser invocado), 127 (Comando não pode ser encontrado).

–isolation

Essa opção é útil quando você executar Docker no Windows essa opção define qual tecnologia ira ser usada para o isolamento do container, no caso do linux é default e no Windows temos: process e Hyper-v.

docker run -d --isolation process busybox top

–device

Um dia poderá aparecer a necessidade para que você anexe um disco a seu container, então com essa opção você pode anexar diretamente um disco a seu container:

docker run --device=/dev/sdb:/dev/xvdc -d centos

–rm

Por padrão quando você cria um container sem passar a opção de “–rm” quando esse container acaba parando por algum motivo, ele não é removido do Docker e também nem o seu volume. Porem caso você deseja que remova o container você poderá passar o parâmetro na hora da criação do container.

docker run -it -v /home/container:/home --rm -d centos

Nesse modo de criação de container, quando o container por algum motivo parar o docker irá excluir-lo e também apagar o volume junto. Para que NÃO APAGUE O VOLUME você deve criar um volume com a opção de docker volume create.... e na hora da criação desse container passar o nome do volume.

docker run -it --rm -v volume:/home -d centos

Então ta pessoal, por hoje era isso, espero que tenham gostado, em breve faremos posts mais focados no baixo nível do Docker para que você possa saber como todas as opções funcionam e como utiliza-las. Já sabe, nos ajude divulgando o blog 😉

Troubleshooting e dicas de Docker

Olá pessoal,

Já faz mais de 1 ano que criamos esse blog e hoje resolvemos fazer um post referente a como solucionar algumas dificuldades e problemas que tivemos no começo, visto que trabalhamos a mais de 2 anos já com Docker, tivemos muitos problemas que queremos demonstrar para vocês.

Instalando a versão mais recente

A maioria das pessoas que acabam por usar Ubuntu, Centos, RedHat ou qualquer outra distribuição utiliza seus próprios comandos para realizar a instalação do Docker, com yum ou apt-get. Mas a forma de utilizar as versões mais recentes são essas:

Versão oficial para se utilizar em produção:

curl -sSL https://get.docker.com/ | sh

Versão que se encontra ainda em fase de testes:

curl -fsSL https://test.docker.com/ | sh

Versão alpha que está em constante desenvolvimento:

curl -fsSL https://experimental.docker.com/ | sh

 Como remover todos os containers parados:

docker rm $(docker ps -a -q)

 Sincronizar o relógio do host com o container:

Isso é um dos principais problemas que as pessoas acabam encontrando as vezes.

Para Centos (Na hora de criar o container mapeia o diretório do host com o do container)

docker run -v /etc/localtime:/etc/localtime:ro centos date

Para Ubuntu (Na hora da criar o container passa como variável o timezone(tz)

docker run -e "TZ=America/Salvador" ubuntu date

 Comunicação entre containers:

Por padrão no Docker a comunicação entre os containers na mesma rede é liberado através de IP interno. Mas caso você queira que os containers não se comuniquem diretamente basta mudar na hora da criação da rede colocar icc=false.

docker network create -o com.docker.network.bridge.enable_icc=false rede_isolada

Montando volumes com services:

Quando criamos um container simples com docker run, existe a opção do -v onde podemos passar como parâmetro o nosso volume, porém com a implementação do services no Docker 1.12 ficou um pouco mais complicado na hora de passar um volume para o serviço:

Como você pode ver na opção “type” temos o “bind” que seria um diretório em nosso host:

docker service create --mount type=bind,source=/diretoriohost,target=/diretoriocontainer imagem

E também temos a opção volume que é passado o volume que é criado com “docker volume create…..

docker service create --mount type=volume,source=meuvolume,target=/diretoriocontainer imagem

 Docker commit e volume:

O comando “docker commit” gera uma imagem do nosso container, porém ele NÃO vai armazenar os dados do volume que estão atrelados a aquele container. Então o docker commit não irá servir de backup para os seus dados que estão no volume.

Não rode containers com –privileged

Com a opção de –privileged o container consegue facilmente acessar diversas áreas do seu host na qual podem ser cruciais caso alguém ache alguma brecha de segurança em sua aplicação.

Um processo para cada container.

Não instale pacotes desnecessários em seus containers, se você quer ter um container para apache, só instale o apache nele. Quer ter o PHP também? então suba outro container.

Cuidado com as regras de IPTABLES

Como o Docker trabalha com toda a sua parte de redes através de iptables, é bem provável que se você fizer alguma manutenção em seu firewall e editar alguma regra errada, toda a sua estrutura de Docker pode parar de funcionar por algum problema.

Coloque o diretório do docker em outro disco:

O docker utiliza o caminho “/var/lib/docker” para colocar todos os seus arquivos de instalação e também toda a sua estrutura de containers, volumes e mais outros recursos que ele utiliza. Então não deixe esse diretório no mesmo disco do seu SO.

Gostaram do post? Deixe seu feedback e novamente, nos ajudem divulgando o blog.

Grande abraço!