Muitas instruções da Internet descrevem um certo mínimo de ações e, como resultado, um mínimo de comandos e oportunidades.
Eu decidi fazer uma seleção de um pouco de recursos iluminados, recursos. O artigo não pretende ser único, ele me ajudará como um lembrete e talvez ajude alguns Padawans a iniciar sua jornada com docker-compondo.
Usando vários arquivos docker-compose.yml
Existem configurações complexas, nas quais há uma certa camada básica de contêineres, que, por exemplo, é sempre necessária. E geralmente acontece que pegamos da equipe vizinha \ outro projeto \ Internet e finalizamos de acordo com suas necessidades. Mas se houver vários comandos, a parte básica poderá ser movida para um repositório interno comum. E temos uma parte base idêntica para a maioria dos projetos, que também é versionada.
Vamos descrever um exemplo de um docker-compose-base.yml básico.
Suponha que esta seja uma imagem nginx personalizada com certificados, ajuste e métricas do say. E exportador para o prometheus:
version: '2' services: nginx: image: nginx nginx-exporter: image: nginx/nginx-prometheus-exporter
Agora descrevemos um exemplo do nosso aplicativo docker-compose-app.yml:
version: '2' services: backend: image: internal.local/super-app:0.1.2
Para começar, precisamos da equipe de sempre com uma diferença. Indicaremos 2 arquivos de composição do docker:
docker-compose up -d -f docker-compose-base.yml -f docker-compose-app.yml
E pronto, temos um conjunto de serviços, como se eles fossem descritos em um único arquivo de composição do docker!
Há também uma segunda opção para o uso de vários arquivos, através do uso da diretiva extends.
docker-compose-base.yml:
version: '2' services: nginx: image: nginx nginx-exporter: image: nginx/nginx-prometheus-exporter
docker-compose-app.yml:
version: '2' services: backend: image: internal.local/super-app:0.1.2 ### web: extends: # ( ) file: docker-compose-base.yml # service: nginx web-exporter: extends: file: docker-compose-base.yml service: nginx-exporter
Complemento do iSlava :
Você pode descrever todos os arquivos de composição em variáveis de ambiente e usar o docker-compose up -d sem especificar manualmente os arquivos:
COMPOSE_PATH_SEPARATOR=: COMPOSE_FILE=docker-compose-base.yml:docker-compose-app.yml
Qual opção escolher - você escolhe. Todos individualmente, eu só queria mostrar as opções =)
Herança na composição do docker
O exemplo a seguir requer a versão docker-compose > = 2.4
Também é uma característica bastante interessante, e de fato poucos são mencionados.
Essa funcionalidade nos permite descrever vários serviços do mesmo tipo no arquivo docker-compose, sem duplicar sua descrição, ou seja, herdar.
Por exemplo, temos um arquivo como este:
version: '2.4' services: backend: image: internal.local/super-app:0.1.2 ports: - 8080:8080 - 9090:9090 volumes: - ./conf/some.conf:/etc/app/some.conf:ro
E havia a necessidade de criar vários contêineres, mas com algumas diferenças, é claro que podemos "economizar" e mudar, mas podemos fazer isso:
version: '2.4' services: backend: &base-app # image: internal.local/super-app:0.1.2 ports: - 8080:8080 - 9090:9090 volumes: - ./conf/some.conf:/etc/app/some.conf:ro backend-2: <<: *base-app # ports: # - 8081:8080
Assim, temos a oportunidade de mudar em um só lugar, do que editar na descrição de cada contêiner.
Há outra opção para mover para a área raiz, por exemplo:
version: '2.4' services: x-backend: # "x-" , . &base-app image: internal.local/super-app:0.1.2 ports: - 8080:8080 - 9090:9090 volumes: - ./conf/some.conf:/etc/app/some.conf:ro backend: <<: *base-app # backend-2: <<: *base-app # ports: # - 8081:8080
Limites de recursos
A partir da versão 2.2, é possível usar limites de recursos para contêineres, de fato, da versão 2.1, mas ainda não há todos entregues =)
Há uma nuance! Na versão 3, esses recursos foram removidos! Já existe uma ênfase no enxame de estivadores.
O exemplo mais simples de limitação de recurso da CPU, MEM:
version: '2.2' services: backend: cpus: 1.5 # . cpuset: '0,3' # . mem_limit: 1gb # 1 memswap_limit: 2gb # SWAP . oom_kill_disable: true # , OOM Killer , . image: internal.local/super-app:0.1.2 ports: - 8080:8080 - 9090:9090 volumes: - ./conf/some.conf:/etc/app/some.conf:ro
Empacotando imagens em um arquivo
Infelizmente, nem sempre é possível enviar imagens no seu próprio registro ou no docker de nuvem. Às vezes, é necessário coletar imagens de um arquivo de composição do docker e enviar, por exemplo, um arquivo morto. Às vezes, as mãos fazem isso por um longo tempo, então eu esbocei um script simples, de repente alguém vem a calhar:
#!/bin/bash dc=${1} if [ ! -z ${dc} ] && [ -f ${dc} ]; then echo "Saving docker images from file ${dc}..." images=`grep image: ${dc} | awk '{print $2}'` docker save ${images} | gzip > docker-images.gz echo "Success!" else echo "ERROR! You must set path to docker-compose.yml as argument!" fi
Salvar no arquivo, diga docker-compose-images-save.sh
Nós damos o direito de executar:
chmod +x docker-compose-images-save.sh
Iniciamos e passamos o caminho para o arquivo docker-compose como um argumento:
./docker-compose-images-save.sh /home/some_user/docker-compose-app.yml
Na saída, chegamos à pasta de onde o arquivo de scripts com imagens foi chamado - docker-images.gz
De qualquer maneira, podemos enviar para um servidor remoto.
Agora, no servidor remoto, basta executar:
gzip -cd docker-images.gz | docker load
Todas as imagens serão carregadas no registro local, após o qual você pode executar com segurança aqui
docker-compose up -d , como todas as imagens estão no registro local na Internet, o docker não entrará nele.
Encaminhar IPv6
Em certas tarefas, o ipv6 pode ser extremamente útil, use pelo menos as nuances de que o Roskomnadzor passa todo o tráfego pelo ipv6 sem problemas, e o mesmo bot de telegrama funciona sem problemas.
Vou considerar uma situação em que o ipv6 não está na sua máquina, seja uma máquina virtual ou um servidor na Internet.
Verifique se o nível do sistema ipv6 está ativado:
sysctl net.ipv6.conf.all.disable_ipv6
O valor deve ser 0, caso contrário, altere:
sysctl -w net.ipv6.conf.all.disable_ipv6=0
Instalar miredo (este é um serviço com uma VPN embutida no servidor que nos fornecerá IPv6 público)
apt-get install miredo -y
Verifique se o serviço está sendo executado:
systemctl status miredo
Verificamos que recebemos o endereço ipv6:
ifconfig teredo
Escrevemos em /etc/docker/daemon.json
{ "ipv6": true, "fixed-cidr-v6": "2001:db8:1::/64" }
Reinicie a janela de encaixe:
systemctl restart docker
Bem, resta habilitar o NAT para o ipv6 para que os endereços internos de nosso contêiner possam alcançar o mundo externo por meio de nossa interface teredo:
ip6tables -t nat -A POSTROUTING -o teredo -j MASQUERADE
Elevamos o contêiner de docker de que precisamos e pode ser publicado via endereço ipv6.
O exemplo acima com sysctl e iptables funcionará até a reinicialização; se você precisar fazê-lo continuamente, verifique as instruções para sua distribuição; existem diferenças.
Espero que alguém que tenha fornecido as informações aqui seja útil.