DR: Um guia geral para comparar estruturas para execução de aplicativos em contêineres. As capacidades do Docker e de outros sistemas similares serão consideradas.
Um pouco da história de onde tudo veio
história
O primeiro método conhecido para isolar um aplicativo é o chroot. A chamada do sistema com o mesmo nome garante que o diretório raiz seja alterado - garantindo assim que o programa que o chamou tenha acesso apenas aos arquivos desse diretório. Mas se um programa receber privilégios de root internamente, ele poderá “escapar” do chroot e obter acesso ao sistema operacional principal. Além de alterar o diretório raiz, outros recursos (RAM, processador), bem como o acesso à rede, não são limitados.
O próximo método é lançar um sistema operacional completo dentro de um contêiner, usando os mecanismos do kernel do sistema operacional. Este método é chamado de forma diferente em diferentes sistemas operacionais, mas a essência é a mesma - iniciar vários sistemas operacionais independentes, cada um executando o mesmo kernel no qual o sistema operacional principal é executado. Isso inclui FreeBSD Jails, Solaris Zones, OpenVZ e LXC para Linux. O isolamento é garantido não apenas pelo espaço em disco, mas também por outros recursos; em particular, cada contêiner pode ter limitações de tempo de processador, RAM e largura de banda da rede. Comparado ao chroot, sair do container é mais difícil, pois o superusuário no container tem acesso apenas ao conteúdo do container, porém, devido à necessidade de manter o sistema operacional dentro do container atualizado e ao uso de versões mais antigas de kernels (relevante para Linux, em menor grau FreeBSD), há uma probabilidade diferente de zero de “romper” o sistema de isolamento do kernel e obter acesso ao sistema operacional principal.
Em vez de lançar um sistema operacional completo em um contêiner (com um sistema de inicialização, gerenciador de pacotes, etc.), você pode iniciar aplicativos imediatamente, o principal é fornecer aos aplicativos essa oportunidade (a presença das bibliotecas necessárias e outros arquivos). Essa ideia serviu de base para a virtualização de aplicativos em contêineres, cujo representante mais proeminente e conhecido é o Docker. Em comparação com sistemas anteriores, mecanismos de isolamento mais flexíveis, juntamente com suporte integrado para redes virtuais entre contêineres e rastreamento do estado do aplicativo dentro do contêiner, resultaram na capacidade de construir um ambiente único e coerente a partir de um grande número de servidores físicos para execução de contêineres - sem a necessidade de gerenciamento manual de recursos.
Estivador
Docker é o software de conteinerização de aplicativos mais famoso. Escrito na linguagem Go, ele usa os recursos padrão do kernel Linux - cgroups, namespaces, capacidades, etc., bem como sistemas de arquivos Aufs e outros semelhantes para economizar espaço em disco.
Fonte: wikimedia
Arquitetura
Antes da versão 1.11, o Docker funcionava como um serviço único que realizava todas as operações com containers: download de imagens para containers, lançamento de containers, processamento de solicitações de API. A partir da versão 1.11, o Docker foi dividido em diversas partes que interagem entre si: containerd, para processamento de todo o ciclo de vida dos containers (alocação de espaço em disco, download de imagens, trabalho com a rede, lançamento, instalação e monitoramento do estado dos containers) e runC, o ambiente de execução de contêineres, baseado no uso de cgroups e outros recursos do kernel Linux. O serviço docker em si permanece, mas agora serve apenas para processar solicitações de API traduzidas para containerd.
Instalação e configuração
Minha forma preferida de instalar o docker é o docker-machine, que, além de instalar e configurar diretamente o docker em servidores remotos (incluindo diversas nuvens), possibilita trabalhar com sistemas de arquivos de servidores remotos e também pode executar diversos comandos.
Porém, desde 2018, o projeto quase não foi desenvolvido, por isso iremos instalá-lo da forma padrão para a maioria das distribuições Linux - adicionando um repositório e instalando os pacotes necessários.
Este método também é usado para instalação automatizada, por exemplo, usando Ansible ou outros sistemas similares, mas não o considerarei neste artigo.
A instalação será realizada no Centos 7, utilizarei uma máquina virtual como servidor, para instalar 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, você precisa iniciar o serviço e colocá-lo na inicialização:
# systemctl enable docker
# systemctl start docker
# firewall-cmd --zone=public --add-port=2377/tcp --permanentAlém disso, você pode criar um grupo docker, cujos usuários poderão trabalhar com o docker sem sudo, configurar o log, habilitar o acesso à API de fora e não se esquecer de configurar o firewall com mais precisão (tudo que não é permitido é proibido nos exemplos acima e abaixo - omiti isso por questão de simplicidade e clareza), mas não entrarei em mais detalhes aqui.
Outras características
Além da máquina docker mencionada acima, há também o docker Registry, uma ferramenta para armazenar imagens para contêineres, bem como o docker compose, uma ferramenta para automatizar a implantação de aplicativos em contêineres, arquivos YAML são usados para construir e configurar contêineres e outras coisas relacionadas (por exemplo, redes, sistemas de arquivos persistentes para armazenamento de dados).
Também pode ser usado para organizar transportadores para CICD. Outro recurso interessante é trabalhar em modo cluster, o chamado modo swarm (antes da versão 1.12 era conhecido como docker swarm), que permite montar uma única infraestrutura a partir de vários servidores para execução de containers. Há suporte para uma rede virtual em todos os servidores, há um balanceador de carga integrado, bem como suporte para segredos para contêineres.
Arquivos YAML do docker compose, com pequenas modificações, podem ser usados para tais clusters, automatizando completamente a manutenção de clusters de pequeno e médio porte para diversos fins. Para clusters grandes, o Kubernetes é preferível porque os custos de manutenção do modo swarm podem exceder os do Kubernetes. Além do runC, você pode instalar, por exemplo, como ambiente de execução do contêiner
Trabalhando com Docker
Após a instalação e configuração, tentaremos montar um cluster no qual implantaremos o GitLab e o Docker Registry para a equipe de desenvolvimento. Usarei três máquinas virtuais como servidores, nas quais implantarei adicionalmente o FS GlusterFS distribuído; usarei-o como armazenamento de volumes docker, por exemplo, para executar uma versão tolerante a falhas do registro do docker. Componentes principais para execução: Docker Registry, Postgresql, Redis, GitLab com suporte para GitLab Runner em cima do Swarm. Lançaremos o Postgresql com clustering , então você não precisa usar o GlusterFS para armazenar dados do Postgresql. Os dados críticos restantes serão armazenados no GlusterFS.
Para implantar o GlusterFS em todos os servidores (eles são chamados de node1, node2, node3), você precisa instalar pacotes, habilitar o 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 dockerEntão você precisa montar o volume resultante (o comando deve ser executado em todos os servidores):
# mount /srv/dockerO modo swarm está configurado em um dos servidores, que será o Líder, os demais deverão ingressar no cluster, portanto o resultado da execução do comando no primeiro servidor precisará ser copiado e executado nos demais.
Configuração inicial do cluster, executo o comando no 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 o executamos no node2 e node3:
# docker swarm join --token SWMTKN-x-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx-xxxxxxxxx xx.xx.xx.xx:2377
This node joined a swarm as a manager.Neste ponto, a configuração preliminar dos servidores está concluída, vamos proceder à configuração dos serviços; os comandos a serem executados serão lançados a partir do nó1, salvo indicação em contrário.
Primeiro de tudo, vamos criar redes para containers:
# 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 gitlabA seguir 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 node3A seguir, criamos diretórios para armazenar dados etcd, armazenamento KV, que é necessário para Traefik e Stolon. Semelhante ao Postgresql, estes serão contêineres vinculados a servidores, então executamos este comando em todos os servidores:
# mkdir -p /srv/etcdA seguir, crie um arquivo para configurar o etcd e use-o:
00etcd.yml
version: '3.7'
services:
etcd1:
image: quay.io/coreos/etcd:latest
hostname: etcd1
command:
- 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
networks:
- etcd
volumes:
- etcd1vol:/data.etcd
deploy:
replicas: 1
placement:
constraints: [node.labels.nodename == node1]
etcd2:
image: quay.io/coreos/etcd:latest
hostname: etcd2
command:
- 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
networks:
- etcd
volumes:
- etcd2vol:/data.etcd
deploy:
replicas: 1
placement:
constraints: [node.labels.nodename == node2]
etcd3:
image: quay.io/coreos/etcd:latest
hostname: etcd3
command:
- 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
networks:
- etcd
volumes:
- etcd3vol:/data.etcd
deploy:
replicas: 1
placement:
constraints: [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"
networks:
etcd:
external: true# docker stack deploy --compose-file 00etcd.yml etcdDepois de algum tempo, verificamos se o cluster etcd está ativo:
# 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 Postgresql, executamos o comando em todos os servidores:
# mkdir -p /srv/pgsqlA seguir, crie um arquivo para configurar o Postgresql:
01pgsql.yml
version: '3.7'
services:
pgsentinel:
image: sorintlab/stolon:master-pg10
command:
- 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
networks:
- etcd
- pgsql
deploy:
replicas: 3
update_config:
parallelism: 1
delay: 30s
order: stop-first
failure_action: pause
pgkeeper1:
image: sorintlab/stolon:master-pg10
hostname: pgkeeper1
command:
- 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
networks:
- etcd
- pgsql
environment:
- PGDATA=/var/lib/postgresql/data
volumes:
- pgkeeper1:/var/lib/postgresql/data
secrets:
- pgsql
- pgsql_repl
deploy:
replicas: 1
placement:
constraints: [node.labels.nodename == node1]
pgkeeper2:
image: sorintlab/stolon:master-pg10
hostname: pgkeeper2
command:
- 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
networks:
- etcd
- pgsql
environment:
- PGDATA=/var/lib/postgresql/data
volumes:
- pgkeeper2:/var/lib/postgresql/data
secrets:
- pgsql
- pgsql_repl
deploy:
replicas: 1
placement:
constraints: [node.labels.nodename == node2]
pgkeeper3:
image: sorintlab/stolon:master-pg10
hostname: pgkeeper3
command:
- 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
networks:
- etcd
- pgsql
environment:
- PGDATA=/var/lib/postgresql/data
volumes:
- pgkeeper3:/var/lib/postgresql/data
secrets:
- pgsql
- pgsql_repl
deploy:
replicas: 1
placement:
constraints: [node.labels.nodename == node3]
postgresql:
image: sorintlab/stolon:master-pg10
command: 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
networks:
- etcd
- pgsql
deploy:
replicas: 3
update_config:
parallelism: 1
delay: 30s
order: stop-first
failure_action: rollback
volumes:
pgkeeper1:
driver: local
driver_opts:
type: none
o: bind
device: "/srv/pgsql"
pgkeeper2:
driver: local
driver_opts:
type: none
o: bind
device: "/srv/pgsql"
pgkeeper3:
driver: local
driver_opts:
type: none
o: bind
device: "/srv/pgsql"
secrets:
pgsql:
file: "/srv/docker/postgres"
pgsql_repl:
file: "/srv/docker/replica"
networks:
etcd:
external: true
pgsql:
external: trueGeramos segredos e usamos 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 pgsqlDepois de algum tempo (veja a saída do comando serviço docker lsque todos os serviços estão ativos) 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 initVerificando 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 o acesso aos contêineres de fora:
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 traefikLançamos o Redis Cluster, para isso criamos um diretório de armazenamento em todos os nós:
# 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 <<EOF > /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 redisAdicionar registro Docker:
06registry.yml
version: '3.7'
services:
registry:
image: registry:2.6
networks:
- traefik
volumes:
- registry_data:/var/lib/registry
deploy:
replicas: 1
placement:
constraints: [node.role == manager]
restart_policy:
condition: on-failure
labels:
- traefik.enable=true
- traefik.http.routers.registry.rule=Host(`registry.example.com`)
- traefik.http.services.registry.loadbalancer.server.port=5000
- traefik.docker.network=traefik
volumes:
registry_data:
driver: local
driver_opts:
type: none
o: bind
device: "/srv/docker/registry"
networks:
traefik:
external: true# mkdir /srv/docker/registry
# docker stack deploy --compose-file 06registry.yml registryE finalmente - GitLab:
08gitlab-runner.yml
version: '3.7'
services:
gitlab:
image: gitlab/gitlab-ce:latest
networks:
- pgsql
- redis
- traefik
- gitlab
ports:
- 22222:22
environment:
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'] = "[email protected]"
gitlab_rails['smtp_password'] = "xxxxxxxxx"
gitlab_rails['smtp_domain'] = "example.com"
gitlab_rails['gitlab_email_from'] = '[email protected]'
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.example.com/'
gitlab_rails['gitlab_shell_ssh_port'] = 22222
volumes:
- gitlab_conf:/etc/gitlab
- gitlab_logs:/var/log/gitlab
- gitlab_data:/var/opt/gitlab
deploy:
mode: replicated
replicas: 1
placement:
constraints:
- node.role == manager
labels:
- traefik.enable=true
- traefik.http.routers.gitlab.rule=Host(`gitlab.example.com`)
- traefik.http.services.gitlab.loadbalancer.server.port=80
- traefik.docker.network=traefik
gitlab-runner:
image: gitlab/gitlab-runner:latest
networks:
- gitlab
volumes:
- gitlab_runner_conf:/etc/gitlab
- /var/run/docker.sock:/var/run/docker.sock
deploy:
mode: replicated
replicas: 1
placement:
constraints:
- node.role == manager
volumes:
gitlab_conf:
driver: local
driver_opts:
type: none
o: bind
device: "/srv/docker/gitlab/conf"
gitlab_logs:
driver: local
driver_opts:
type: none
o: bind
device: "/srv/docker/gitlab/logs"
gitlab_data:
driver: local
driver_opts:
type: none
o: bind
device: "/srv/docker/gitlab/data"
gitlab_runner_conf:
driver: local
driver_opts:
type: none
o: bind
device: "/srv/docker/gitlab/runner"
networks:
pgsql:
external: true
redis:
external: true
traefik:
external: true
gitlab:
external: 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 gitlabO estado final do cluster e dos 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? Certifique-se de configurar o Traefik para executar contêineres em https, adicionar criptografia tls para Postgresql e Redis. Mas, em geral, já pode ser dado aos desenvolvedores como PoC. Vejamos agora alternativas ao Docker.
Podman
Outro mecanismo bastante conhecido para executar contêineres agrupados por pods (pods, grupos de contêineres implantados juntos). Ao contrário do Docker, ele não requer nenhum serviço para executar contêineres; todo o trabalho é feito através da biblioteca libpod. Também escrito em Go, requer um tempo de execução compatível com OCI para executar contêineres, como runC.
Trabalhar com o Podman geralmente lembra o do Docker, a tal ponto que você pode fazer assim (como afirmado por muitos que tentaram, incluindo o autor deste artigo):
$ alias docker=podmane você pode continuar trabalhando. Em geral, a situação com o Podman é muito interessante, pois se as primeiras versões do Kubernetes funcionavam com Docker, então por volta 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 rodar em Kubernetes vem sendo desenvolvida: CRI-O. Nesse sentido, o Podman é uma alternativa ao Docker, construído sobre os princípios do Kubernetes, incluindo o agrupamento de contêineres, mas o objetivo principal do projeto é lançar contêineres no estilo Docker sem serviços adicionais. Por razões óbvias, não existe modo swarm, já que os desenvolvedores dizem claramente que se você precisar de um cluster, use o Kubernetes.
Instalação
Para instalar no Centos 7, basta ativar o repositório Extras, e depois instalar tudo com o comando:
# yum -y install podmanOutras características
Podman pode gerar unidades para systemd, resolvendo assim o problema de inicialização de contêineres após a reinicialização do servidor. Além disso, declara-se que o systemd funciona corretamente como pid 1 no contêiner. Existe uma ferramenta buildah separada para construir contêineres, também existem ferramentas de terceiros - análogos do docker-compose, que também geram arquivos de configuração compatíveis com Kubernetes, para que a transição do Podman para o Kubernetes seja simplificada tanto quanto possível.
Trabalhando com Podman
Como não há modo swarm (devemos mudar para Kubernetes se um cluster for necessário), iremos coletá-lo em contêineres separados.
Instale o podman-compose:
# yum -y install python3-pip
# pip3 install podman-composeO arquivo de configuração resultante para podman é um pouco diferente, então, por exemplo, tivemos que mover uma seção de volumes separada diretamente para a seção com serviços.
gitlab-podman.yml
version: '3.7'
services:
gitlab:
image: gitlab/gitlab-ce:latest
hostname: gitlab.example.com
restart: unless-stopped
environment:
GITLAB_OMNIBUS_CONFIG: |
gitlab_rails['gitlab_shell_ssh_port'] = 22222
ports:
- "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
networks:
- gitlab
gitlab-runner:
image: gitlab/gitlab-runner:alpine
restart: unless-stopped
depends_on:
- gitlab
volumes:
- /srv/podman/gitlab/runner:/etc/gitlab-runner
- /var/run/docker.sock:/var/run/docker.sock
networks:
- gitlab
networks:
gitlab:# podman-compose -f gitlab-runner.yml -d upResultado:
# 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 descobrir 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: {}Sistema:
# 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 o systemd não faz mais nada (por exemplo, limpar contêineres antigos quando esse serviço é reiniciado), então você mesmo terá que escrever essas coisas.
Em princípio, Podman é suficiente para testar o que são contêineres, transferir configurações antigas para docker-compose e depois passar para o Kubernetes, se precisar de um cluster, ou obter uma alternativa mais fácil de usar ao Docker.
rkt
Projeto cerca de seis meses atrás devido ao fato de que a RedHat o comprou, então não vou me alongar sobre isso com mais detalhes. No geral, deixou uma impressão muito boa, mas comparado ao Docker e principalmente ao Podman, parece uma combinação. Havia também uma distribuição CoreOS construída sobre o rkt (embora originalmente tivessem Docker), mas isso também terminou em suporte após a compra do RedHat.
Flash
mais , cujo autor queria apenas construir e executar contêineres. A julgar pela documentação e pelo código, o autor não seguiu os padrões, simplesmente decidiu escrever sua própria implementação, o que, em princípio, ele fez.
Descobertas
A situação com o Kubernetes é muito interessante: por um lado, com o Docker você pode construir um cluster (em modo swarm), com o qual você pode até executar ambientes de produto para clientes, isto é especialmente verdadeiro para equipes pequenas (3-5 pessoas) , ou com uma carga geral pequena, ou falta de desejo de entender os meandros da configuração do Kubernetes, inclusive para cargas altas.
O Podman não oferece compatibilidade total, mas tem uma vantagem importante: compatibilidade com Kubernetes, incluindo ferramentas adicionais (buildah e outras). Portanto, abordarei a escolha de uma ferramenta para trabalhar da seguinte forma: para equipes pequenas, ou com orçamento limitado - Docker (com possível modo swarm), para desenvolvimento para mim em um localhost pessoal - camaradas Podman, e para todos os outros - Kubernetes.
Não tenho certeza se a situação com o Docker não mudará no futuro, afinal eles são pioneiros, e também estão sendo gradativamente padronizados passo a passo, mas Podman, apesar de todas as suas deficiências (funciona apenas em Linux, sem clustering, montagem e outras ações são soluções de terceiros) o futuro é mais claro, por isso convido a todos a discutir essas descobertas nos comentários.
PS No dia 3 de agosto lançamos “", onde você poderá conhecer mais sobre seu trabalho. Analisaremos todas as suas ferramentas: desde abstrações básicas até parâmetros de rede, nuances de trabalhar com diversos 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.
Preço da encomenda antes do lançamento: RUB 5000. Você pode visualizar o programa Docker Video Course .
Fonte: habr.com