TL;DR: articolo di panoramica-guida sul confronto degli ambienti per l'esecuzione di applicazioni in container. Verranno esaminate le funzionalità di Docker e di altri sistemi simili.
Un po' di storia, da dove è tutto iniziato
Storia
Il primo metodo noto per l'isolamento delle applicazioni è chroot. La chiamata di sistema omonima modifica la directory radice, consentendo così al programma che la invoca di accedere solo ai file all'interno di questa directory. Tuttavia, se al programma all'interno vengono dati i diritti di superutente, può potenzialmente "fuggire" da chroot e ottenere accesso al sistema operativo principale. Inoltre, oltre a cambiare la directory radice, non ci sono limitazioni su altre risorse (memoria RAM, CPU) e l'accesso alla rete.
Il metodo successivo è l'esecuzione di un sistema operativo completo all'interno di un container, grazie ai meccanismi del kernel del sistema operativo. In diverse sisteme operativi, questo metodo ha nomi diversi, ma il concetto è lo stesso: eseguire più sistemi operativi indipendenti, ognuno dei quali utilizza lo stesso kernel di quello del sistema operativo principale. Questo include FreeBSD Jails, Solaris Zones, OpenVZ e LXC per Linux. Viene fornita un'isolamento non solo nello spazio su disco, ma anche su altre risorse; ad esempio, ogni container può avere limitazioni sul tempo di CPU, sulla memoria RAM e sulla larghezza di banda di rete. Rispetto a chroot, è più difficile uscire da un container, poiché l'utente super nel container ha accesso solo al contenuto del container. Tuttavia, a causa della necessità di mantenere il sistema operativo all'interno del container aggiornato e dell'uso di versioni obsolete del kernel (cosa vale per Linux, in misura minore per FreeBSD), esiste una possibilità non trascurabile di "bucare" il sistema di isolamento del kernel e ottenere accesso al sistema operativo principale.
Invece di avviare un sistema operativo completo all'interno di un contenitore (con sistema di inizializzazione, gestore di pacchetti, ecc.), è possibile eseguire direttamente le applicazioni, l'importante è fornire alle applicazioni tale possibilità (presenza delle librerie necessarie e di altri file). Questa idea è stata alla base della virtualizzazione delle applicazioni in contenitori, il rappresentante più noto e riconosciuto di questo è Docker. Rispetto ai sistemi precedenti, meccanismi di isolamento più flessibili, insieme al supporto integrato delle reti virtuali tra i contenitori e al monitoraggio dello stato dell'applicazione all'interno del contenitore, hanno reso possibile la creazione di un ambiente coeso da un grande numero di server fisici per eseguire contenitori - senza la necessità di gestione manuale delle risorse.
Docker
Docker è il software di containerizzazione delle applicazioni più conosciuto. Scritto in linguaggio Go, utilizza le funzionalità native del kernel Linux: cgroups, namespaces, capabilities, ecc., nonché filesystem come Aufs e altri simili per ottimizzare lo spazio su disco.
Fonte: wikimedia
Architettura
Fino alla versione 1.11, Docker operava come un unico servizio che gestiva tutte le operazioni sui contenitori: scaricamento delle immagini per i contenitori, avvio dei contenitori, gestione delle richieste API. Dalla versione 1.11, Docker è stato suddiviso in più parti che interagiscono tra loro: containerd, per gestire l'intero ciclo di vita dei contenitori (allocazione dello spazio su disco, scaricamento delle immagini, gestione della rete, avvio, installazione e monitoraggio dello stato dei contenitori) e runC, un ambiente di esecuzione dei contenitori basato sull'uso dei cgroups e di altre funzionalità del kernel Linux. Il servizio docker è rimasto, ma ora serve solo a gestire le richieste API inviate a containerd.
Installazione e configurazione
Il mio modo preferito di installare Docker è docker-machine, che oltre a installare e configurare direttamente Docker sui server remoti (inclusi vari cloud) permette di lavorare con i filesystem dei server remoti e può eseguire vari comandi.
Tuttavia, dal 2018 il progetto è quasi inattivo, quindi procederemo all'installazione nel modo standard per la maggior parte delle distribuzioni Linux: aggiungendo il repository e installando i pacchetti necessari.
Questo metodo può essere applicato anche durante l'installazione automatizzata, ad esempio utilizzando Ansible o altri sistemi simili, ma in questo articolo non lo tratterò.
L'installazione sarà eseguita su Centos 7, userò una macchina virtuale come server; per installare, è sufficiente eseguire i comandi qui sotto:
# 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.ioDopo l'installazione, è necessario avviare il servizio e impostarlo per l'avvio automatico:
# systemctl enable docker
# systemctl start docker
# firewall-cmd --zone=public --add-port=2377/tcp --permanentInoltre, è possibile creare un gruppo docker, i cui utenti potranno lavorare con docker senza sudo, configurare la registrazione, abilitare l'accesso all'API dall'esterno, ricordando di configurare più precisamente il firewall (tutto ciò che non è esplicitamente consentito è vietato; negli esempi sopra e sotto, ho omesso questo per semplicità e chiarezza), ma qui non mi soffermerò ulteriormente.
Altre possibilità
Oltre alla già citata docker machine, ci sono anche docker registry, uno strumento per la memorizzazione delle immagini dei container, e docker compose — uno strumento per automatizzare il deployment delle applicazioni nei container, utilizzando file YAML per costruire e configurare i container e altri elementi correlati (ad esempio reti, sistemi di file persistenti per memorizzare i dati).
Inoltre, con esso è possibile organizzare pipeline per CICD. Un'altra interessante funzionalità è il funzionamento in modalità cluster, conosciuta come swarm mode (prima della versione 1.12 era nota come docker swarm), che consente di unire più server in un'unica infrastruttura per l'esecuzione di container. È supportata una rete virtuale su tutti i server, è presente un bilanciatore di carico integrato e inoltre è supportata la gestione dei segreti per i container.
I file YAML di docker compose, con alcune piccole modifiche, possono essere utilizzati per tali cluster, automatizzando completamente la gestione di piccoli e medi cluster per vari scopi. Per cluster di grandi dimensioni, è preferibile utilizzare Kubernetes, poiché i costi di gestione della modalità swarm possono superare quelli di Kubernetes. Oltre a runC come ambiente di esecuzione dei container, si può installare ad esempio
Funzionalità con Docker
Dopo l'installazione e la configurazione, proveremo a creare un cluster, in cui implementeremo GitLab e Docker Registry per il team di sviluppo. Come server utilizzerò tre macchine virtuali, su cui installerò anche un file system distribuito GlusterFS, che utilizzerò come storage per i volumi Docker, ad esempio per eseguire una versione a prova di errore di Docker Registry. I componenti chiave per l'avvio: Docker Registry, Postgresql, Redis, GitLab con supporto per GitLab Runner su Swarm. Avvieremo Postgresql con clustering. , pertanto non è necessario utilizzare GlusterFS per l'archiviazione dei dati di Postgresql. Gli altri dati critici saranno memorizzati su GlusterFS.
Per installare GlusterFS su tutti i server (che si chiamano node1, node2, node3), è necessario installare i pacchetti, abilitare il firewall e creare le directory necessarie:
# 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/fstabDopo l'installazione, la configurazione di GlusterFS deve continuare da un nodo, ad esempio 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 dockerDopodiché bisogna montare il volume ottenuto (il comando deve essere eseguito su tutti i server):
# mount /srv/dockerLa configurazione della modalità swarm viene effettuata su uno dei server, che sarà il Leader, mentre gli altri dovranno unirsi al cluster, quindi il risultato dell'esecuzione del comando sul primo server dovrà essere copiato ed eseguito sugli altri.
Impostazione iniziale del cluster, eseguo il comando su 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 managerCopiamo il risultato del secondo comando, eseguiamo su node2 e node3:
# docker swarm join --token SWMTKN-x-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx-xxxxxxxxx xx.xx.xx.xx:2377
This node joined a swarm as a manager.A questo punto, la configurazione preliminare dei server è terminata, procediamo con la configurazione dei servizi, i comandi per l'esecuzione saranno avviati da node1, a meno che non venga specificato diversamente.
Per prima cosa creiamo le reti per i container:
# 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 gitlabSuccessivamente contrassegniamo i server, questo è necessario per associare alcuni servizi ai server:
# docker node update --label-add nodename=node1 node1
# docker node update --label-add nodename=node2 node2
# docker node update --label-add nodename=node3 node3Poi creiamo le directory per l'archiviazione dei dati etcd, un'archiviazione KV necessaria per Traefik e Stolon. Analogamente a Postgresql, saranno container associati ai server, quindi eseguiamo questo comando su tutti i server:
# mkdir -p /srv/etcdPoi creiamo un file per la configurazione di etcd e lo applichiamo:
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 etcdDopo un po' verifichiamo che il cluster etcd sia attivo:
# 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 healthyCreiamo le directory per Postgresql, eseguiamo il comando su tutti i server:
# mkdir -p /srv/pgsqlSuccessivamente creiamo un file per la configurazione di 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: trueGeneriamo segreti, applichiamo il file:
# </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 pgsqlDopo un po' (controlliamo l'output del comando docker service ls, che tutti i servizi sono stati avviati) iniziamo il 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 initControlliamo la prontezza del 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
Configurando traefik per aprire l'accesso ai contenitori dall'esterno:
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 traefikAvviamo il cluster Redis, per questo creiamo su tutti i nodi una directory di archiviazione:
# 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 redisAggiungiamo il 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 infine — 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'] = "noreply@example.com"
gitlab_rails['smtp_password'] = "xxxxxxxxx"
gitlab_rails['smtp_domain'] = "example.com"
gitlab_rails['gitlab_email_from'] = 'noreply@example.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.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 gitlabStato finale del cluster e dei servizi:
# 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/tcpCosa si può migliorare ulteriormente? Assicurati di configurare in Traefik il funzionamento dei container su https, aggiungere la crittografia tls per Postgresql e Redis. Ma in generale, è già possibile passarlo agli sviluppatori come PoC. Ora vediamo le alternative a Docker.
Podman
Un altro motore abbastanza noto per l'esecuzione di container, raggruppati in pod (pods, gruppi di container distribuiti insieme). A differenza di Docker, non richiede alcun servizio per eseguire i container, tutto il lavoro avviene tramite la libreria libpod. È scritto anch'esso in Go e necessita di un runtime compatibile con OCI per eseguire i container, ad esempio runC.
Lavorare con Podman ricorda in gran parte il lavoro con Docker, fino al punto che puoi fare così (come dichiarato da molti che l'hanno provato, incluso l'autore di questo articolo):
$ alias docker=podmane puoi continuare a lavorare. In generale, la situazione con Podman è piuttosto interessante, poiché se le versioni precedenti di Kubernetes lavoravano con Docker, da circa il 2015, dopo la standardizzazione nel mondo dei container (OCI — Open Container Initiative) e la separazione di Docker in containerd e runC, si è sviluppata un'alternativa a Docker per l'esecuzione su Kubernetes: CRI-O. Podman, in tal senso, è un'alternativa a Docker, costruita secondo i principi di Kubernetes, incluso il raggruppamento dei container, ma l'obiettivo principale dell'esistenza del progetto è l'esecuzione dei container in stile Docker senza servizi aggiuntivi. Per motivi comprensibili, non esiste la modalità swarm, poiché gli sviluppatori affermano chiaramente che se è necessario un cluster, si deve utilizzare Kubernetes.
Installazione
Per installarlo su Centos 7 è sufficiente attivare il repository Extras, dopo di che installa tutto con il comando:
# yum -y install podmanAltre possibilità
Podman può generare unità per systemd, risolvendo così il problema di avviare i container dopo il riavvio del server. È inoltre dichiarato che systemd funziona correttamente come pid 1 all'interno del container. Per costruire container è disponibile uno strumento separato chiamato buildah; ci sono anche strumenti di terze parti — analoghi di docker-compose, che generano anche file di configurazione compatibili con Kubernetes, rendendo così la transizione da Podman a Kubernetes il più semplice possibile.
Lavorare con Podman
Poiché non esiste la modalità swarm (si prevede di passare a Kubernetes, se è necessario un cluster) — costruiremo usando container separati.
Installa podman-compose:
# yum -y install python3-pip
# pip3 install podman-composeIl file di configurazione risultante per podman è leggermente diverso; ad esempio, è stato necessario spostare una sezione separata volumes direttamente nella sezione dei servizi.
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 upRisultato del lavoro:
# 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_1Vediamo cosa genera per systemd e kubernetes, per questo è necessario conoscere il nome o l'ID del 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.targetPurtroppo, oltre ad avviare i contenitori, l'unità generata per systemd non fa altro (ad esempio, non pulisce i vecchi contenitori al riavvio di un tale servizio), quindi dovrai aggiungere queste cose manualmente.
In linea di massima, Podman è sufficiente per provare cosa sono i contenitori, trasferire le vecchie configurazioni per docker-compose, dopo di che si può passare a Kubernetes, se necessario su un cluster, oppure ottenere un'alternativa più semplice a Docker.
rkt
Progetto circa sei mesi fa, dopo l'acquisizione da parte di RedHat, quindi non mi soffermerò ulteriormente su di esso. In generale, ha lasciato un'impressione piuttosto buona, ma rispetto a Docker, e tantomeno a Podman, appare come un frullatore. Esisteva anche una distribuzione CoreOS, basata su rkt (anche se inizialmente avevano Docker), ma anche il suo supporto è cessato dopo l'acquisto da parte di RedHat.
Plash
Altro , il cui autore voleva semplicemente costruire e avviare contenitori. A giudicare dalla documentazione e dal codice, l'autore non ha seguito gli standard, ma ha semplicemente deciso di scrivere la propria implementazione, e in effetti ci è riuscito.
Conclusioni
La situazione con Kubernetes è piuttosto interessante: da un lato con Docker è possibile costruire un cluster (in modalità swarm), con il quale è anche possibile avviare ambienti di produzione per i clienti, il che è particolarmente rilevante per piccoli team (3-5 persone), o con un carico complessivo ridotto, oppure in assenza di desiderio di scoprire le complessità della configurazione di Kubernetes, incluse le elevate cariche.
Podman non garantisce una compatibilità totale, ma ha un importante vantaggio: la compatibilità con Kubernetes, inclusi strumenti aggiuntivi (buildah e altri). Pertanto, per la scelta dello strumento con cui lavorare procederò in questo modo: per piccoli team o con budget limitato — Docker (con possibile swarm mode), per sviluppo personale su localhost — Podman e per tutti gli altri — Kubernetes.
Non sono sicuro che la situazione con Docker non cambi in futuro; del resto, sono pionieri e stanno lentamente standardizzando, ma Podman, nonostante tutti i suoi difetti (funziona solo su Linux, assenza di clustering, build e altre operazioni — soluzioni esterne), ha un futuro più chiaro. Pertanto, invito tutti coloro che sono interessati a discutere queste conclusioni nei commenti.
P.S. 3 agosto lanciamo “”, dove sarà possibile apprendere di più sul suo funzionamento. Analizzeremo tutti i suoi strumenti: dalle astrazioni di base alle opzioni di rete, ai dettagli sul funzionamento con vari sistemi operativi e linguaggi di programmazione. Scoprirete la tecnologia e capirete dove e come utilizzare al meglio Docker. Condivideremo inoltre casi di best practice.
Il costo del preordine fino al rilascio: 5000 r. È possibile consultare il programma del “Corso Video su Docker” .
Fonte: habr.com
