TL;DR: um guia abrangente sobre a comparação de ambientes para a execução de aplicativos em contêineres. Serão abordadas as capacidades do Docker e de outros sistemas semelhantes.
Um pouco da história de onde tudo isso surgiu
Histórico
A primeira forma amplamente conhecida de isolamento de aplicativos é o chroot. A chamada de sistema homônima permite a mudança do diretório raiz — garantindo assim que o programa que a invocou tenha acesso apenas aos arquivos dentro desse diretório. No entanto, se o programa tiver permissões de superusuário, existe a possibilidade de que ele "escape" do chroot e acesse o sistema operacional principal. Além disso, a mudança do diretório raiz não limita outros recursos (memória, CPU), nem o acesso à rede.
A próxima abordagem é a execução de um sistema operacional completo dentro de um contêiner, utilizando mecanismos do núcleo do sistema operacional. Esse método é conhecido de diferentes maneiras em várias distribuições de sistema operacional, mas a essência é a mesma — executar múltiplos sistemas operacionais independentes, cada um funcionando com o mesmo núcleo que o sistema operacional principal. Isso inclui FreeBSD Jails, Solaris Zones, OpenVZ e LXC para Linux. O isolamento é garantido não apenas em termos de espaço em disco, mas também em recursos, uma vez que cada contêiner pode ter restrições em termos de tempo de CPU, memória e largura de banda da rede. Em comparação ao chroot, é mais difícil sair de um contêiner, já que o superusuário dentro dele só tem acesso aos componentes internos do contêiner, no entanto, devido à necessidade de manter o sistema operacional dentro do contêiner atualizado e ao uso de versões antigas de núcleos (o que é relevante para Linux, em menor grau para FreeBSD), existe uma possibilidade não nula de "fuga" do sistema de isolamento do núcleo e acesso ao sistema operacional principal.
Em vez de iniciar um sistema operacional completo em um contêiner (com sistema de inicialização, gerenciador de pacotes, etc.), é possível iniciar diretamente aplicativos, desde que se ofereça aos aplicativos a possibilidade de fazê-lo (como a presença das bibliotecas necessárias e outros arquivos). Essa ideia fundamentou a virtualização de contêineres de aplicativos, cujo representante mais notável e conhecido é o Docker. Em comparação com sistemas anteriores, mecanismos de isolamento mais flexíveis, juntamente com suporte embutido a redes virtuais entre contêineres e a monitorização do estado do aplicativo dentro do contêiner, resultaram na capacidade de construir um ambiente coeso a partir de muitos servidores físicos para executar contêineres — sem a necessidade de gerenciamento manual de recursos.
Docker
O Docker é o software mais conhecido para a conteinerização de aplicativos. Escrito na linguagem Go, utiliza recursos nativos do kernel do Linux — cgroups, namespaces, capabilities, etc., assim como sistemas de arquivos Aufs e outros semelhantes para economizar espaço em disco.
Fonte: wikimedia
Arquitetura
Até a versão 1.11, o Docker funcionava como um único serviço que realizava todas as operações com contêineres: download de imagens para contêineres, início de contêineres e processamento de solicitações via API. A partir da versão 1.11, o Docker foi dividido em várias partes interconectadas: containerd, para gerenciar todo o ciclo de vida dos contêineres (alocação de espaço em disco, download de imagens, gerenciamento de rede, execução, instalação e monitoramento do estado dos contêineres) e runC, um ambiente de execução de contêineres baseado em cgroups e outras funcionalidades do kernel Linux. O serviço docker em si permanece, mas agora serve apenas para o processamento de solicitações via API, que são traduzidas para o containerd.
Instalação e configuração
Minha maneira favorita de instalar o docker é usando o docker-machine, que, além da instalação e configuração do docker em servidores remotos (incluindo várias nuvens), permite trabalhar com sistemas de arquivos em servidores remotos, além de poder executar diversos comandos.
No entanto, desde 2018 o projeto quase não tem evoluído, por isso a instalação será feita de maneira padrão para a maioria das distribuições Linux — adicionando o repositório e instalando os pacotes necessários.
Este método também é utilizado na instalação automatizada, por exemplo, com Ansible ou sistemas semelhantes, mas neste artigo não vou abordá-lo.
A instalação será realizada no CentOS 7, e usarei uma máquina virtual como servidor; para a instalação, basta executar os comandos abaixo:
# yum install -y yum-utils
# yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo
# yum install docker-ce docker-ce-cli containerd.ioApós a instalação, é necessário iniciar o serviço e configurá-lo para iniciar automaticamente:
# systemctl enable docker
# systemctl start docker
# firewall-cmd --zone=public --add-port=2377/tcp --permanentAlém disso, é possível criar um grupo docker, cujos usuários poderão trabalhar com o docker sem sudo, configurar a gravação de logs, habilitar o acesso à API externamente, e não se esquecer de ajustar mais precisamente o firewall (tudo que não é permitido é bloqueado; nos exemplos acima e abaixo, omiti isso por simplicidade e clareza), mas aqui não vou me aprofundar mais.
Outras possibilidades
Além da ferramenta mencionada, existe o docker registry, que armazena imagens para contêineres, e o docker compose, que serve para automatizar a implantação de aplicações em contêineres, utilizando arquivos YAML para construir e configurar contêineres e outros itens relacionados (como redes e sistemas de arquivos persistentes para armazenamento de dados).
Com sua ajuda, também é possível organizar pipelines para CICD. Outra possibilidade interessante é a operação em modo de cluster, conhecido como swarm mode (até a versão 1.12 era chamado de docker swarm), que permite combinar vários servidores em uma única infraestrutura para execução de contêineres. Há suporte para uma rede virtual sobre todos os servidores, balanceador de carga integrado e suporte a segredos para contêineres.
Os arquivos YAML do docker compose, com pequenas alterações, podem ser usados para esses clusters, automatizando completamente a manutenção de pequenos e médios clusters para diferentes objetivos. Para clusters grandes, é preferível usar o Kubernetes, pois os custos de manutenção do swarm mode podem superar os do Kubernetes. Além do runC, como ambiente de execução de contêineres, também pode ser instalado por exemplo
Trabalho com Docker
Após a instalação e configuração, vamos tentar montar um cluster, onde implementaremos o GitLab e o Docker Registry para a equipe de desenvolvimento. Para os servidores, utilizarei três máquinas virtuais, nas quais também implementarei um sistema de arquivos distribuído GlusterFS, que usarei como armazenamento para volumes Docker, por exemplo, para executar uma versão tolerante a falhas do Docker Registry. Os componentes chave para a execução são: Docker Registry, Postgresql, Redis e GitLab com suporte ao GitLab Runner sobre o Swarm. O Postgresql será executado com clusterização. , por isso, o GlusterFS não deve ser utilizado para armazenamento de dados do Postgresql. Os outros dados críticos serão armazenados no GlusterFS.
Para implementar o GlusterFS em todos os servidores (que são chamados de node1, node2, node3), é necessário instalar os pacotes, permitir a operação do firewall e criar os diretórios necessários:
# yum -y install centos-release-gluster7
# yum -y install glusterfs-server
# systemctl enable glusterd
# systemctl start glusterd
# firewall-cmd --add-service=glusterfs --permanent
# firewall-cmd --reload
# mkdir -p /srv/gluster
# mkdir -p /srv/docker
# echo "$(hostname):/docker /srv/docker glusterfs defaults,_netdev 0 0" >> /etc/fstabApós a instalação, o trabalho de configuração do GlusterFS deve continuar a partir de um nó, por exemplo, node1:
# gluster peer probe node2
# gluster peer probe node3
# gluster volume create docker replica 3 node1:/srv/gluster node2:/srv/gluster node3:/srv/gluster force
# gluster volume start dockerEm seguida, é necessário montar o volume obtido (o comando deve ser executado em todos os servidores):
# mount /srv/dockerA configuração do modo swarm é feita em um dos servidores, que será o Leader; os outros devem se juntar ao cluster, então o resultado da execução do comando no primeiro servidor deve ser copiado e executado nos outros.
Configuração inicial do cluster, o comando é iniciado em node1:
# docker swarm init
Swarm initialized: current node (a5jpfrh5uvo7svzz1ajduokyq) is now a manager.
To add a worker to this swarm, run the following command:
docker swarm join --token SWMTKN-1-0c5mf7mvzc7o7vjk0wngno2dy70xs95tovfxbv4tqt9280toku-863hyosdlzvd76trfptd4xnzd xx.xx.xx.xx:2377
To add a manager to this swarm, run 'docker swarm join-token manager' and follow the instructions.
# docker swarm join-token managerCopiamos o resultado do segundo comando e executamos em node2 e node3:
# docker swarm join --token SWMTKN-x-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx-xxxxxxxxx xx.xx.xx.xx:2377
This node joined a swarm as a manager.Com isso, a configuração preliminar dos servidores está concluída, vamos iniciar a configuração dos serviços, os comandos a serem executados serão iniciados a partir de node1, a menos que indicado de outra forma.
Primeiro, vamos criar redes para os contêineres:
# docker network create --driver=overlay etcd
# docker network create --driver=overlay pgsql
# docker network create --driver=overlay redis
# docker network create --driver=overlay traefik
# docker network create --driver=overlay gitlabEm seguida, marcamos os servidores, isso é necessário para vincular alguns serviços aos servidores:
# docker node update --label-add nodename=node1 node1
# docker node update --label-add nodename=node2 node2
# docker node update --label-add nodename=node3 node3Em seguida, criamos diretórios para armazenar dados do etcd, um armazenamento de chave-valor, que é necessário para Traefik e Stolon. Assim como o Postgresql, serão contêineres vinculados aos servidores, então este comando deve ser executado em todos os servidores:
# mkdir -p /srv/etcdDepois, criamos um arquivo para a configuração do etcd e o aplicamos:
00etcd.yml
versão: '3.7'
serviços:
etcd1:
imagem: quay.io/coreos/etcd:latest
hostname: etcd1
comando:
- etcd
- --name=etcd1
- --data-dir=/data.etcd
- --advertise-client-urls=http://etcd1:2379
- --listen-client-urls=http://0.0.0.0:2379
- --initial-advertise-peer-urls=http://etcd1:2380
- --listen-peer-urls=http://0.0.0.0:2380
- --initial-cluster=etcd1=http://etcd1:2380,etcd2=http://etcd2:2380,etcd3=http://etcd3:2380
- --initial-cluster-state=new
- --initial-cluster-token=etcd-cluster
redes:
- etcd
volumes:
- etcd1vol:/data.etcd
deploy:
réplicas: 1
placement:
restrições: [node.labels.nodename == node1]
etcd2:
imagem: quay.io/coreos/etcd:latest
hostname: etcd2
comando:
- etcd
- --name=etcd2
- --data-dir=/data.etcd
- --advertise-client-urls=http://etcd2:2379
- --listen-client-urls=http://0.0.0.0:2379
- --initial-advertise-peer-urls=http://etcd2:2380
- --listen-peer-urls=http://0.0.0.0:2380
- --initial-cluster=etcd1=http://etcd1:2380,etcd2=http://etcd2:2380,etcd3=http://etcd3:2380
- --initial-cluster-state=new
- --initial-cluster-token=etcd-cluster
redes:
- etcd
volumes:
- etcd2vol:/data.etcd
deploy:
réplicas: 1
placement:
restrições: [node.labels.nodename == node2]
etcd3:
imagem: quay.io/coreos/etcd:latest
hostname: etcd3
comando:
- etcd
- --name=etcd3
- --data-dir=/data.etcd
- --advertise-client-urls=http://etcd3:2379
- --listen-client-urls=http://0.0.0.0:2379
- --initial-advertise-peer-urls=http://etcd3:2380
- --listen-peer-urls=http://0.0.0.0:2380
- --initial-cluster=etcd1=http://etcd1:2380,etcd2=http://etcd2:2380,etcd3=http://etcd3:2380
- --initial-cluster-state=new
- --initial-cluster-token=etcd-cluster
redes:
- etcd
volumes:
- etcd3vol:/data.etcd
deploy:
réplicas: 1
placement:
restrições: [node.labels.nodename == node3]
volumes:
etcd1vol:
driver: local
driver_opts:
type: none
o: bind
device: "/srv/etcd"
etcd2vol:
driver: local
driver_opts:
type: none
o: bind
device: "/srv/etcd"
etcd3vol:
driver: local
driver_opts:
type: none
o: bind
device: "/srv/etcd"
redes:
etcd:
externo: true# docker stack deploy --compose-file 00etcd.yml etcdApós algum tempo, verificamos se o cluster etcd foi iniciado:
# docker exec $(docker ps | awk '/etcd/ {print $1}') etcdctl member list
ade526d28b1f92f7: name=etcd1 peerURLs=http://etcd1:2380 clientURLs=http://etcd1:2379 isLeader=false
bd388e7810915853: name=etcd3 peerURLs=http://etcd3:2380 clientURLs=http://etcd3:2379 isLeader=false
d282ac2ce600c1ce: name=etcd2 peerURLs=http://etcd2:2380 clientURLs=http://etcd2:2379 isLeader=true
# docker exec $(docker ps | awk '/etcd/ {print $1}') etcdctl cluster-health
member ade526d28b1f92f7 is healthy: got healthy result from http://etcd1:2379
member bd388e7810915853 is healthy: got healthy result from http://etcd3:2379
member d282ac2ce600c1ce is healthy: got healthy result from http://etcd2:2379
cluster is healthyCriamos diretórios para o Postgresql, o comando é executado em todos os servidores:
# mkdir -p /srv/pgsqlEm seguida, criamos um arquivo para configurar o Postgresql:
01pgsql.yml
versão: '3.7'
serviços:
pgsentinel:
imagem: sorintlab/stolon:master-pg10
comando:
- gosu
- stolon
- stolon-sentinel
- --cluster-name=stolon-cluster
- --store-backend=etcdv3
- --store-endpoints=http://etcd1:2379,http://etcd2:2379,http://etcd3:2379
- --log-level=debug
redes:
- etcd
- pgsql
implantação:
réplicas: 3
configuração_de_atualização:
paralelismo: 1
atraso: 30s
ordem: stop-first
ação_em_falha: pause
pgkeeper1:
imagem: sorintlab/stolon:master-pg10
hostname: pgkeeper1
comando:
- gosu
- stolon
- stolon-keeper
- --pg-listen-address=pgkeeper1
- --pg-repl-username=replica
- --uid=pgkeeper1
- --pg-su-username=postgres
- --pg-su-passwordfile=/run/secrets/pgsql
- --pg-repl-passwordfile=/run/secrets/pgsql_repl
- --data-dir=/var/lib/postgresql/data
- --cluster-name=stolon-cluster
- --store-backend=etcdv3
- --store-endpoints=http://etcd1:2379,http://etcd2:2379,http://etcd3:2379
redes:
- etcd
- pgsql
ambiente:
- PGDATA=/var/lib/postgresql/data
volumes:
- pgkeeper1:/var/lib/postgresql/data
segredos:
- pgsql
- pgsql_repl
implantação:
réplicas: 1
colocação:
restrições: [node.labels.nodename == node1]
pgkeeper2:
imagem: sorintlab/stolon:master-pg10
hostname: pgkeeper2
comando:
- gosu
- stolon
- stolon-keeper
- --pg-listen-address=pgkeeper2
- --pg-repl-username=replica
- --uid=pgkeeper2
- --pg-su-username=postgres
- --pg-su-passwordfile=/run/secrets/pgsql
- --pg-repl-passwordfile=/run/secrets/pgsql_repl
- --data-dir=/var/lib/postgresql/data
- --cluster-name=stolon-cluster
- --store-backend=etcdv3
- --store-endpoints=http://etcd1:2379,http://etcd2:2379,http://etcd3:2379
redes:
- etcd
- pgsql
ambiente:
- PGDATA=/var/lib/postgresql/data
volumes:
- pgkeeper2:/var/lib/postgresql/data
segredos:
- pgsql
- pgsql_repl
implantação:
réplicas: 1
colocação:
restrições: [node.labels.nodename == node2]
pgkeeper3:
imagem: sorintlab/stolon:master-pg10
hostname: pgkeeper3
comando:
- gosu
- stolon
- stolon-keeper
- --pg-listen-address=pgkeeper3
- --pg-repl-username=replica
- --uid=pgkeeper3
- --pg-su-username=postgres
- --pg-su-passwordfile=/run/secrets/pgsql
- --pg-repl-passwordfile=/run/secrets/pgsql_repl
- --data-dir=/var/lib/postgresql/data
- --cluster-name=stolon-cluster
- --store-backend=etcdv3
- --store-endpoints=http://etcd1:2379,http://etcd2:2379,http://etcd3:2379
redes:
- etcd
- pgsql
ambiente:
- PGDATA=/var/lib/postgresql/data
volumes:
- pgkeeper3:/var/lib/postgresql/data
segredos:
- pgsql
- pgsql_repl
implantação:
réplicas: 1
colocação:
restrições: [node.labels.nodename == node3]
postgresql:
imagem: sorintlab/stolon:master-pg10
comando: gosu stolon stolon-proxy --listen-address 0.0.0.0 --cluster-name stolon-cluster --store-backend=etcdv3 --store-endpoints http://etcd1:2379,http://etcd2:2379,http://etcd3:2379
redes:
- etcd
- pgsql
implantação:
réplicas: 3
configuração_de_atualização:
paralelismo: 1
atraso: 30s
ordem: stop-first
ação_em_falha: rollback
volumes:
pgkeeper1:
driver: local
opções_do_driver:
type: none
o: bind
device: "/srv/pgsql"
pgkeeper2:
driver: local
opções_do_driver:
type: none
o: bind
device: "/srv/pgsql"
pgkeeper3:
driver: local
opções_do_driver:
type: none
o: bind
device: "/srv/pgsql"
segredos:
pgsql:
arquivo: "/srv/docker/postgres"
pgsql_repl:
arquivo: "/srv/docker/replica"
redes:
etcd:
externo: true
pgsql:
externo: trueGerando segredos, aplicamos o arquivo:
# </dev/urandom tr -dc 234567890qwertyuopasdfghjkzxcvbnmQWERTYUPASDFGHKLZXCVBNM | head -c $(((RANDOM%3)+15)) > /srv/docker/replica
# </dev/urandom tr -dc 234567890qwertyuopasdfghjkzxcvbnmQWERTYUPASDFGHKLZXCVBNM | head -c $(((RANDOM%3)+15)) > /srv/docker/postgres
# docker stack deploy --compose-file 01pgsql.yml pgsqlApós algum tempo (observamos a saída do comando docker service ls, que todos os serviços foram iniciados) inicializamos o cluster Postgresql:
# docker exec $(docker ps | awk '/pgkeeper/ {print $1}') stolonctl --cluster-name=stolon-cluster --store-backend=etcdv3 --store-endpoints=http://etcd1:2379,http://etcd2:2379,http://etcd3:2379 initVerificamos a prontidão do cluster Postgresql:
# docker exec $(docker ps | awk '/pgkeeper/ {print $1}') stolonctl --cluster-name=stolon-cluster --store-backend=etcdv3 --store-endpoints=http://etcd1:2379,http://etcd2:2379,http://etcd3:2379 status
=== Active sentinels ===
ID LEADER
26baa11d false
74e98768 false
a8cb002b true
=== Active proxies ===
ID
4d233826
9f562f3b
b0c79ff1
=== Keepers ===
UID HEALTHY PG LISTENADDRESS PG HEALTHY PG WANTEDGENERATION PG CURRENTGENERATION
pgkeeper1 true pgkeeper1:5432 true 2 2
pgkeeper2 true pgkeeper2:5432 true 2 2
pgkeeper3 true pgkeeper3:5432 true 3 3
=== Cluster Info ===
Master Keeper: pgkeeper3
===== Keepers/DB tree =====
pgkeeper3 (master)
├─pgkeeper2
└─pgkeeper1
Configuramos o traefik para abrir acesso aos contêineres externamente:
03traefik.yml
version: '3.7'
services:
traefik:
image: traefik:latest
command: >
--log.level=INFO
--providers.docker=true
--entryPoints.web.address=:80
--providers.providersThrottleDuration=2
--providers.docker.watch=true
--providers.docker.swarmMode=true
--providers.docker.swarmModeRefreshSeconds=15s
--providers.docker.exposedbydefault=false
--accessLog.bufferingSize=0
--api=true
--api.dashboard=true
--api.insecure=true
networks:
- traefik
ports:
- 80:80
volumes:
- /var/run/docker.sock:/var/run/docker.sock
deploy:
replicas: 3
placement:
constraints:
- node.role == manager
preferences:
- spread: node.id
labels:
- traefik.enable=true
- traefik.http.routers.traefik.rule=Host(`traefik.example.com`)
- traefik.http.services.traefik.loadbalancer.server.port=8080
- traefik.docker.network=traefik
networks:
traefik:
external: true# docker stack deploy --compose-file 03traefik.yml traefikIniciamos o Redis Cluster, para isso criamos em todos os nós um diretório para armazenamento:
# mkdir -p /srv/redis05redis.yml
version: '3.7'
services:
redis-master:
image: 'bitnami/redis:latest'
networks:
- redis
ports:
- '6379:6379'
environment:
- REDIS_REPLICATION_MODE=master
- REDIS_PASSWORD=xxxxxxxxxxx
deploy:
mode: global
restart_policy:
condition: any
volumes:
- 'redis:/opt/bitnami/redis/etc/'
redis-replica:
image: 'bitnami/redis:latest'
networks:
- redis
ports:
- '6379'
depends_on:
- redis-master
environment:
- REDIS_REPLICATION_MODE=slave
- REDIS_MASTER_HOST=redis-master
- REDIS_MASTER_PORT_NUMBER=6379
- REDIS_MASTER_PASSWORD=xxxxxxxxxxx
- REDIS_PASSWORD=xxxxxxxxxxx
deploy:
mode: replicated
replicas: 3
update_config:
parallelism: 1
delay: 10s
restart_policy:
condition: any
redis-sentinel:
image: 'bitnami/redis:latest'
networks:
- redis
ports:
- '16379'
depends_on:
- redis-master
- redis-replica
entrypoint: |
bash -c 'bash -s <<EOF
"/bin/bash" -c "cat < /opt/bitnami/redis/etc/sentinel.conf
port 16379
dir /tmp
sentinel monitor master-node redis-master 6379 2
sentinel down-after-milliseconds master-node 5000
sentinel parallel-syncs master-node 1
sentinel failover-timeout master-node 5000
sentinel auth-pass master-node xxxxxxxxxxx
sentinel announce-ip redis-sentinel
sentinel announce-port 16379
EOF"
"/bin/bash" -c "redis-sentinel /opt/bitnami/redis/etc/sentinel.conf"
EOF'
deploy:
mode: global
restart_policy:
condition: any
volumes:
redis:
driver: local
driver_opts:
type: 'none'
o: 'bind'
device: "/srv/redis"
networks:
redis:
external: true# docker stack deploy --compose-file 05redis.yml redisAdicionando o Docker Registry:
06registry.yml
versão: '3.7'
serviços:
registro:
imagem: registry:2.6
redes:
- traefik
volumes:
- registry_data:\/var\/lib\/registry
deploy:
réplicas: 1
colocação:
restrições: [node.role == manager]
política_de_reinício:
condição: on-failure
rótulos:
- traefik.enable=true
- traefik.http.routers.registry.rule=Host(`registry.exemplo.com`)
- traefik.http.services.registry.loadbalancer.server.port=5000
- traefik.docker.network=traefik
volumes:
registry_data:
driver: local
driver_opts:
type: none
o: bind
dispositivo: "\/srv\/docker\/registry"
redes:
traefik:
externo: true# mkdir /srv/docker/registry
# docker stack deploy --compose-file 06registry.yml registryE finalmente — GitLab:
08gitlab-runner.yml
versão: '3.7'
serviços:
gitlab:
imagem: gitlab\/gitlab-ce:latest
redes:
- pgsql
- redis
- traefik
- gitlab
portas:
- 22222:22
ambiente:
GITLAB_OMNIBUS_CONFIG: |
postgresql['enable'] = false
redis['enable'] = false
gitlab_rails['registry_enabled'] = false
gitlab_rails['db_username'] = "gitlab"
gitlab_rails['db_password'] = "XXXXXXXXXXX"
gitlab_rails['db_host'] = "postgresql"
gitlab_rails['db_port'] = "5432"
gitlab_rails['db_database'] = "gitlab"
gitlab_rails['db_adapter'] = 'postgresql'
gitlab_rails['db_encoding'] = 'utf8'
gitlab_rails['redis_host'] = 'redis-master'
gitlab_rails['redis_port'] = '6379'
gitlab_rails['redis_password'] = 'xxxxxxxxxxx'
gitlab_rails['smtp_enable'] = true
gitlab_rails['smtp_address'] = "smtp.yandex.ru"
gitlab_rails['smtp_port'] = 465
gitlab_rails['smtp_user_name'] = "noreply@exemplo.com"
gitlab_rails['smtp_password'] = "xxxxxxxxx"
gitlab_rails['smtp_domain'] = "exemplo.com"
gitlab_rails['gitlab_email_from'] = 'noreply@exemplo.com'
gitlab_rails['smtp_authentication'] = "login"
gitlab_rails['smtp_tls'] = true
gitlab_rails['smtp_enable_starttls_auto'] = true
gitlab_rails['smtp_openssl_verify_mode'] = 'peer'
external_url 'http:\/\/gitlab.exemplo.com\/'
gitlab_rails['gitlab_shell_ssh_port'] = 22222
volumes:
- gitlab_conf:\/etc\/gitlab
- gitlab_logs:\/var\/log\/gitlab
- gitlab_data:\/var\/opt\/gitlab
deploy:
modo: replicado
réplicas: 1
colocação:
restrições:
- node.role == manager
rótulos:
- traefik.enable=true
- traefik.http.routers.gitlab.rule=Host(`gitlab.exemplo.com`)
- traefik.http.services.gitlab.loadbalancer.server.port=80
- traefik.docker.network=traefik
gitlab-runner:
imagem: gitlab\/gitlab-runner:latest
redes:
- gitlab
volumes:
- gitlab_runner_conf:\/etc\/gitlab
- \/var\/run\/docker.sock:\/var\/run\/docker.sock
deploy:
modo: replicado
réplicas: 1
colocação:
restrições:
- node.role == manager
volumes:
gitlab_conf:
driver: local
driver_opts:
type: none
o: bind
dispositivo: "\/srv\/docker\/gitlab\/conf"
gitlab_logs:
driver: local
driver_opts:
type: none
o: bind
dispositivo: "\/srv\/docker\/gitlab\/logs"
gitlab_data:
driver: local
driver_opts:
type: none
o: bind
dispositivo: "\/srv\/docker\/gitlab\/data"
gitlab_runner_conf:
driver: local
driver_opts:
type: none
o: bind
dispositivo: "\/srv\/docker\/gitlab\/runner"
redes:
pgsql:
externo: true
redis:
externo: true
traefik:
externo: true
gitlab:
externo: true# mkdir -p /srv/docker/gitlab/conf
# mkdir -p /srv/docker/gitlab/logs
# mkdir -p /srv/docker/gitlab/data
# mkdir -p /srv/docker/gitlab/runner
# docker stack deploy --compose-file 08gitlab-runner.yml gitlabEstado final do cluster e serviços:
# docker service ls
ID NAME MODE REPLICAS IMAGE PORTS
lef9n3m92buq etcd_etcd1 replicated 1/1 quay.io/coreos/etcd:latest
ij6uyyo792x5 etcd_etcd2 replicated 1/1 quay.io/coreos/etcd:latest
fqttqpjgp6pp etcd_etcd3 replicated 1/1 quay.io/coreos/etcd:latest
hq5iyga28w33 gitlab_gitlab replicated 1/1 gitlab/gitlab-ce:latest *:22222->22/tcp
dt7s6vs0q4qc gitlab_gitlab-runner replicated 1/1 gitlab/gitlab-runner:latest
k7uoezno0h9n pgsql_pgkeeper1 replicated 1/1 sorintlab/stolon:master-pg10
cnrwul4r4nse pgsql_pgkeeper2 replicated 1/1 sorintlab/stolon:master-pg10
frflfnpty7tr pgsql_pgkeeper3 replicated 1/1 sorintlab/stolon:master-pg10
x7pqqchi52kq pgsql_pgsentinel replicated 3/3 sorintlab/stolon:master-pg10
mwu2wl8fti4r pgsql_postgresql replicated 3/3 sorintlab/stolon:master-pg10
9hkbe2vksbzb redis_redis-master global 3/3 bitnami/redis:latest *:6379->6379/tcp
l88zn8cla7dc redis_redis-replica replicated 3/3 bitnami/redis:latest *:30003->6379/tcp
1utp309xfmsy redis_redis-sentinel global 3/3 bitnami/redis:latest *:30002->16379/tcp
oteb824ylhyp registry_registry replicated 1/1 registry:2.6
qovrah8nzzu8 traefik_traefik replicated 3/3 traefik:latest *:80->80/tcp, *:443->443/tcpO que mais pode ser melhorado? É imprescindível configurar no Traefik o funcionamento dos containers via https, adicionar criptografia tls para Postgresql e Redis. Mas, em geral, já é possível entregar aos desenvolvedores como PoC. Agora, veremos as alternativas ao Docker.
Podman
Mais um engine bastante conhecido para rodar containers, agrupados em pods (pods, grupos de containers que são implantados em conjunto). Ao contrário do Docker, não requer qualquer serviço para iniciar os containers, toda a operação é feita através da biblioteca libpod. Também é escrito em Go, necessitando de um runtime compatível com OCI para executar os containers, como runC.
O trabalho com Podman é, em geral, semelhante ao do Docker, a ponto de ser possível fazer assim (afirmado por muitos que tentaram, inclusive pelo autor deste artigo):
$ alias docker=podmane você pode continuar trabalhando. No geral, a situação com o Podman é muito interessante, pois se as versões anteriores do Kubernetes trabalhavam com o Docker, a partir de 2015, após a padronização do mundo dos containers (OCI — Open Container Initiative) e a divisão do Docker em containerd e runC, uma alternativa ao Docker para execução no Kubernetes começou a se desenvolver: CRI-O. Neste aspecto, o Podman é uma alternativa ao Docker, construída com os princípios do Kubernetes, incluindo a agregação de containers, mas o principal objetivo da existência do projeto é executar containers ao estilo Docker sem serviços adicionais. Por razões óbvias, não há modo swarm disponível, já que os desenvolvedores afirmam claramente que, se for necessário um cluster, é preferível usar o Kubernetes.
Instalação
Para instalar no Centos 7, basta ativar o repositório Extras, após o que você pode instalar tudo com o comando:
# yum -y install podmanOutras possibilidades
O Podman pode gerar unidades para systemd, resolvendo assim a tarefa de iniciar containers após reiniciar o servidor. Além disso, é afirmada a operação correta do systemd como pid 1 dentro do container. Para construir containers, há uma ferramenta separada chamada buildah, e também há ferramentas de terceiros — análogas ao docker-compose, que geram arquivos de configuração compatíveis com o Kubernetes, facilitando a transição do Podman para o Kubernetes tanto quanto possível.
Trabalho com Podman
Uma vez que não há modo swarm (considera-se a migração para Kubernetes, se for necessário um cluster) — vamos coletar em containers separados.
Instalamos o podman-compose:
# yum -y install python3-pip
# pip3 install podman-composeO arquivo de configuração resultante para o podman é um pouco diferente, pois, por exemplo, foi necessário mover uma seção separada de volumes diretamente para a seção de serviços.
gitlab-podman.yml
versão: '3.7'
serviços:
gitlab:
imagem: gitlab/gitlab-ce:latest
hostname: gitlab.exemplo.com
reiniciar: a menos que parado
ambiente:
GITLAB_OMNIBUS_CONFIG: |
gitlab_rails['gitlab_shell_ssh_port'] = 22222
portas:
- "80:80"
- "22222:22"
volumes:
- /srv/podman/gitlab/conf:/etc/gitlab
- /srv/podman/gitlab/data:/var/opt/gitlab
- /srv/podman/gitlab/logs:/var/log/gitlab
redes:
- gitlab
gitlab-runner:
imagem: gitlab/gitlab-runner:alpine
reiniciar: a menos que parado
depende_de:
- gitlab
volumes:
- /srv/podman/gitlab/runner:/etc/gitlab-runner
- /var/run/docker.sock:/var/run/docker.sock
redes:
- gitlab
redes:
gitlab:# podman-compose -f gitlab-runner.yml -d upResultado da execução:
# podman ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
da53da946c01 docker.io/gitlab/gitlab-runner:alpine run --user=gitlab... About a minute ago Up About a minute ago 0.0.0.0:22222->22/tcp, 0.0.0.0:80->80/tcp root_gitlab-runner_1
781c0103c94a docker.io/gitlab/gitlab-ce:latest /assets/wrapper About a minute ago Up About a minute ago 0.0.0.0:22222->22/tcp, 0.0.0.0:80->80/tcp root_gitlab_1Vamos ver o que ele gera para systemd e kubernetes, para isso precisamos saber o nome ou ID do pod:
# podman pod ls
POD ID NAME STATUS CREATED # OF CONTAINERS INFRA ID
71fc2b2a5c63 root Running 11 minutes ago 3 db40ab8bf84bKubernetes:
# podman generate kube 71fc2b2a5c63
# Generation of Kubernetes YAML is still under development!
#
# Save the output of this file and use kubectl create -f to import
# it into Kubernetes.
#
# Created with podman-1.6.4
apiVersion: v1
kind: Pod
metadata:
creationTimestamp: "2020-07-29T19:22:40Z"
labels:
app: root
name: root
spec:
containers:
- command:
- /assets/wrapper
env:
- name: PATH
value: /opt/gitlab/embedded/bin:/opt/gitlab/bin:/assets:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
- name: TERM
value: xterm
- name: HOSTNAME
value: gitlab.example.com
- name: container
value: podman
- name: GITLAB_OMNIBUS_CONFIG
value: |
gitlab_rails['gitlab_shell_ssh_port'] = 22222
- name: LANG
value: C.UTF-8
image: docker.io/gitlab/gitlab-ce:latest
name: rootgitlab1
ports:
- containerPort: 22
hostPort: 22222
protocol: TCP
- containerPort: 80
hostPort: 80
protocol: TCP
resources: {}
securityContext:
allowPrivilegeEscalation: true
capabilities: {}
privileged: false
readOnlyRootFilesystem: false
volumeMounts:
- mountPath: /var/opt/gitlab
name: srv-podman-gitlab-data
- mountPath: /var/log/gitlab
name: srv-podman-gitlab-logs
- mountPath: /etc/gitlab
name: srv-podman-gitlab-conf
workingDir: /
- command:
- run
- --user=gitlab-runner
- --working-directory=/home/gitlab-runner
env:
- name: PATH
value: /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
- name: TERM
value: xterm
- name: HOSTNAME
- name: container
value: podman
image: docker.io/gitlab/gitlab-runner:alpine
name: rootgitlab-runner1
resources: {}
securityContext:
allowPrivilegeEscalation: true
capabilities: {}
privileged: false
readOnlyRootFilesystem: false
volumeMounts:
- mountPath: /etc/gitlab-runner
name: srv-podman-gitlab-runner
- mountPath: /var/run/docker.sock
name: var-run-docker.sock
workingDir: /
volumes:
- hostPath:
path: /srv/podman/gitlab/runner
type: Directory
name: srv-podman-gitlab-runner
- hostPath:
path: /var/run/docker.sock
type: File
name: var-run-docker.sock
- hostPath:
path: /srv/podman/gitlab/data
type: Directory
name: srv-podman-gitlab-data
- hostPath:
path: /srv/podman/gitlab/logs
type: Directory
name: srv-podman-gitlab-logs
- hostPath:
path: /srv/podman/gitlab/conf
type: Directory
name: srv-podman-gitlab-conf
status: {}Systemd:
# podman generate systemd 71fc2b2a5c63
# pod-71fc2b2a5c6346f0c1c86a2dc45dbe78fa192ea02aac001eb8347ccb8c043c26.service
# autogenerated by Podman 1.6.4
# Thu Jul 29 15:23:28 EDT 2020
[Unit]
Description=Podman pod-71fc2b2a5c6346f0c1c86a2dc45dbe78fa192ea02aac001eb8347ccb8c043c26.service
Documentation=man:podman-generate-systemd(1)
Requires=container-781c0103c94aaa113c17c58d05ddabf8df4bf39707b664abcf17ed2ceff467d3.service container-da53da946c01449f500aa5296d9ea6376f751948b17ca164df438b7df6607864.service
Before=container-781c0103c94aaa113c17c58d05ddabf8df4bf39707b664abcf17ed2ceff467d3.service container-da53da946c01449f500aa5296d9ea6376f751948b17ca164df438b7df6607864.service
[Service]
Restart=on-failure
ExecStart=/usr/bin/podman start db40ab8bf84bf35141159c26cb6e256b889c7a98c0418eee3c4aa683c14fccaa
ExecStop=/usr/bin/podman stop -t 10 db40ab8bf84bf35141159c26cb6e256b889c7a98c0418eee3c4aa683c14fccaa
KillMode=none
Type=forking
PIDFile=/var/run/containers/storage/overlay-containers/db40ab8bf84bf35141159c26cb6e256b889c7a98c0418eee3c4aa683c14fccaa/userdata/conmon.pid
[Install]
WantedBy=multi-user.target
# container-da53da946c01449f500aa5296d9ea6376f751948b17ca164df438b7df6607864.service
# autogenerated by Podman 1.6.4
# Thu Jul 29 15:23:28 EDT 2020
[Unit]
Description=Podman container-da53da946c01449f500aa5296d9ea6376f751948b17ca164df438b7df6607864.service
Documentation=man:podman-generate-systemd(1)
RefuseManualStart=yes
RefuseManualStop=yes
BindsTo=pod-71fc2b2a5c6346f0c1c86a2dc45dbe78fa192ea02aac001eb8347ccb8c043c26.service
After=pod-71fc2b2a5c6346f0c1c86a2dc45dbe78fa192ea02aac001eb8347ccb8c043c26.service
[Service]
Restart=on-failure
ExecStart=/usr/bin/podman start da53da946c01449f500aa5296d9ea6376f751948b17ca164df438b7df6607864
ExecStop=/usr/bin/podman stop -t 10 da53da946c01449f500aa5296d9ea6376f751948b17ca164df438b7df6607864
KillMode=none
Type=forking
PIDFile=/var/run/containers/storage/overlay-containers/da53da946c01449f500aa5296d9ea6376f751948b17ca164df438b7df6607864/userdata/conmon.pid
[Install]
WantedBy=multi-user.target
# container-781c0103c94aaa113c17c58d05ddabf8df4bf39707b664abcf17ed2ceff467d3.service
# autogenerated by Podman 1.6.4
# Thu Jul 29 15:23:28 EDT 2020
[Unit]
Description=Podman container-781c0103c94aaa113c17c58d05ddabf8df4bf39707b664abcf17ed2ceff467d3.service
Documentation=man:podman-generate-systemd(1)
RefuseManualStart=yes
RefuseManualStop=yes
BindsTo=pod-71fc2b2a5c6346f0c1c86a2dc45dbe78fa192ea02aac001eb8347ccb8c043c26.service
After=pod-71fc2b2a5c6346f0c1c86a2dc45dbe78fa192ea02aac001eb8347ccb8c043c26.service
[Service]
Restart=on-failure
ExecStart=/usr/bin/podman start 781c0103c94aaa113c17c58d05ddabf8df4bf39707b664abcf17ed2ceff467d3
ExecStop=/usr/bin/podman stop -t 10 781c0103c94aaa113c17c58d05ddabf8df4bf39707b664abcf17ed2ceff467d3
KillMode=none
Type=forking
PIDFile=/var/run/containers/storage/overlay-containers/781c0103c94aaa113c17c58d05ddabf8df4bf39707b664abcf17ed2ceff467d3/userdata/conmon.pid
[Install]
WantedBy=multi-user.targetInfelizmente, além de iniciar contêineres, a unidade gerada para systemd não faz mais nada (por exemplo, limpar contêineres antigos ao reiniciar esse serviço), então essas coisas terão que ser adicionadas manualmente.
Basicamente, o Podman é suficiente para experimentar o que são contêineres, transferir as configurações antigas para docker-compose, depois do que é possível migrar para Kubernetes, se for necessário para um cluster, ou obter uma alternativa mais simples ao Docker.
rkt
Projeto há cerca de seis meses, porque foi comprado pela RedHat, então não vou me aprofundar mais nele. No geral, deixava uma impressão bastante positiva, mas em comparação com Docker e, mais ainda, com Podman, parece um trator. Também existia uma distribuição CoreOS, construída com base em rkt (embora inicialmente tivesse Docker), porém seu suporte também terminou após a compra pela RedHat.
Plash
Mais , cujo autor queria apenas montar e executar contêineres. Segundo a documentação e o código — o autor não seguiu padrões, mas decidiu escrever sua própria implementação, e na verdade fez isso.
Como resultado, obtemos um serviço de "monitoramento como serviço", automatizado na linha de produção de integração contínua. O desenvolvedor ou testador precisa apenas definir a lista de métricas em um arquivo JSON, e tudo o mais acontece automaticamente. Obtemos um controle de qualidade transparente dos lançamentos: todas as notificações sobre desempenho, consumo de recursos ou regressões arquitetônicas.
A situação com a presença do Kubernetes é bastante interessante: por um lado, com Docker é possível montar um cluster (no modo swarm), com o qual é até possível executar ambientes produtivos para clientes, especialmente relevante para pequenas equipes (3-5 pessoas), ou com uma carga geral baixa, ou então se não houver desejo de entender os meandros da configuração do Kubernetes, incluindo para altas cargas.
O Podman não oferece compatibilidade total, mas tem uma vantagem importante — a compatibilidade com Kubernetes, incluindo ferramentas adicionais (buildah e outras). Portanto, levarei em consideração esta abordagem para escolher a ferramenta: para pequenas equipes ou orçamentos limitados — Docker (com possível modo swarm), para desenvolvimento pessoal no localhost — Podman com os colegas, e para todos os outros — Kubernetes.
Não tenho certeza se a situação com o Docker mudará no futuro, afinal, eles são os pioneiros, e estão, gradualmente, se padronizando. Porém, o futuro do Podman, apesar de suas desvantagens (funciona apenas no Linux, não tem clustering, e as ações de montagem e outras são feitas com soluções externas), parece mais claro. Por isso, convido todos os interessados a discutir essas conclusões nos comentários.
P.S. No dia 3 de agosto, lançamos "", onde você poderá saber mais sobre seu funcionamento. Vamos explorar todas as suas ferramentas: desde as abstrações principais até os parâmetros de rede, nuances de trabalho com diferentes sistemas operacionais e linguagens de programação. Você se familiarizará com a tecnologia e entenderá onde e como usar melhor o Docker. Também compartilharemos casos de melhores práticas.
O custo da pré-venda antes do lançamento: 5000 rublos. O programa do "Curso em Vídeo sobre Docker" pode ser consultado .
Fonte: habr.com
