TL;DR: articolo riassuntivo-guida sul confronto tra ambienti per l'esecuzione di applicazioni in container. Verranno esaminate le possibilità di Docker e di altri sistemi simili.
Un po' di storia, da dove tutto è iniziato
Storia
Il primo metodo noto per isolare un'app è chroot. La chiamata di sistema omonima garantisce il cambiamento della directory radice, fornendo così accesso al programma che la invoca solo ai file all'interno di questa directory. Tuttavia, se al programma vengono concessi i diritti di superutente, può potenzialmente "uscire" da chroot e ottenere accesso al sistema operativo principale. Inoltre, oltre a cambiare la directory radice, non ci sono limitazioni su altre risorse (memoria, CPU), così come sull'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 operazioni, questo metodo ha nomi diversi, ma il concetto è lo stesso: eseguire più sistemi operativi indipendenti, ognuno dei quali opera con lo stesso kernel del sistema operativo di base. Questo include FreeBSD Jails, Solaris Zones, OpenVZ e LXC per Linux. Viene fornita un'isolamento non solo per lo spazio disco, ma anche per altre risorse; in particolare, ogni container può avere limiti sul tempo di CPU, memoria RAM, e larghezza di banda della rete. Rispetto a chroot, è più difficile uscire da un container, poiché il superutente all'interno ha accesso solo all'interno del container. Tuttavia, a causa della necessità di mantenere il sistema operativo all'interno del container aggiornato e dell'uso di versioni obsolete dei kernel (valido per Linux, in misura minore per FreeBSD), esiste una probabilità non nulla di "sfondare" il sistema di isolamento del kernel e ottenere accesso al sistema operativo principale.
Invece di eseguire un sistema operativo completo nel container (con sistema di iniziazione, gestore di pacchetti, ecc.), è possibile eseguire direttamente le applicazioni, a patto di fornire alle applicazioni questa possibilità (disponibilità delle librerie necessarie e altri file). Questa idea ha dato origine alla virtualizzazione delle applicazioni nei container, il rappresentante più noto e luminoso del quale è Docker. Rispetto ai sistemi precedenti, meccanismi di isolamento più flessibili insieme al supporto integrato per reti virtuali tra contenitori e al monitoraggio dello stato dell'applicazione all'interno del container hanno reso possibile la costruzione di un ambiente coeso su un gran numero di server fisici per l'esecuzione di container, senza la necessità di gestione manuale delle risorse.
Docker
Docker è il software più noto per la containerizzazione delle applicazioni. Scritto in Go, utilizza le funzionalità native del kernel Linux - cgroups, namespaces, capabilities, ecc. - e filesystem come Aufs e altri simili per ottimizzare lo spazio su disco.
Fonte: wikimedia
Architettura
Fino alla versione 1.11 Docker funzionava come un unico servizio, gestendo tutte le operazioni sui container: scaricamento delle immagini per i container, avvio dei container, gestione delle richieste API. A partire dalla versione 1.11, Docker è stato suddiviso in più parti che interagiscono tra loro: containerd, per gestire l'intero ciclo di vita dei container (allocazione dello spazio su disco, scaricamento delle immagini, gestione della rete, avvio, installazione e monitoraggio dello stato dei container), e runC, l'ambiente di esecuzione dei container che utilizza cgroups e altre funzionalità del kernel Linux. Il servizio docker è rimasto, ma ora serve solo per gestire le richieste API che vengono tradotte in containerd.
Installazione e configurazione
Il mio modo preferito per installare docker è docker-machine, che oltre all'installazione e configurazione di docker su server remoti (inclusi vari cloud) offre l'opzione di lavorare con i filesystem dei server remoti e può eseguire vari comandi.
Tuttavia, dal 2018, il progetto è quasi fermo, quindi procederemo con l'installazione nel modo standard per la maggior parte delle distribuzioni Linux: aggiungendo il repository e installando i pacchetti necessari.
Questo metodo è anche utilizzato per installazioni automatizzate, ad esempio con Ansible o altri sistemi simili, ma in questo articolo non lo esaminerò.
L'installazione sarà effettuata su Centos 7, utilizzerò una macchina virtuale come server, per installare è sufficiente eseguire i comandi seguenti:
# 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 --permanentIn aggiunta, si può creare un gruppo docker, i cui utenti potranno lavorare con docker senza sudo, configurare il logging, abilitare l'accesso API esterno e non dimenticare di configurare più precisamente il firewall (tutto ciò che non è permesso è vietato; negli esempi sopra e sotto ho omesso questo dettaglio per semplicità e chiarezza), ma non mi soffermerò ulteriormente su questo.
Altre funzionalità
Oltre alla docker machine menzionata, esiste anche il docker registry, uno strumento per la conservazione delle immagini dei container, e docker compose — uno strumento per automatizzare il dispiegamento delle applicazioni nei container, utilizzando file YAML per assemblare e configurare i container e altre cose correlate (come reti, sistemi di file permanenti per la conservazione dei dati).
Con esso è anche possibile organizzare pipeline per CICD. Un'altra interessante possibilità è il funzionamento in modalità cluster, nota come swarm mode (fino alla versione 1.12 era conosciuta come docker swarm), che consente di unire più server in un'unica infrastruttura per eseguire container. C'è supporto per una rete virtuale su tutti i server, la presenza di un bilanciatore di carico integrato e supporto per segreti per i container.
I file YAML di docker compose, con piccole modifiche, possono essere utilizzati per tali cluster, automatizzando completamente la gestione di piccoli e medi cluster per vari scopi. Per cluster più grandi è preferibile utilizzare Kubernetes, poiché i costi di gestione della modalità swarm possono superare quelli di Kubernetes. Oltre a runC, è possibile installare ad esempio
Lavoro con Docker
Dopo aver installato e configurato, proviamo a costruire un cluster in cui dispiegheremo GitLab e Docker Registry per il team di sviluppo. Utilizzerò tre macchine virtuali come server, sulle quali installerò anche un filesystem distribuito GlusterFS, che userò come archiviazione per i volumi docker, ad esempio per eseguire una versione altamente disponibile del docker registry. I componenti chiave per l'avvio sono: Docker Registry, PostgreSQL, Redis, GitLab con supporto per GitLab Runner sopra Swarm. Eseguiremo PostgreSQL con clustering , quindi per la conservazione dei dati di PostgreSQL non è necessario utilizzare GlusterFS. Gli altri dati critici saranno conservati su GlusterFS.
Per dispiegare GlusterFS su tutti i server (che si chiamano node1, node2, node3) è necessario installare i pacchetti, consentire il funzionamento del firewall, 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 essere continuata 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 dockerPoi è necessario 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, gli altri dovranno unirsi al cluster, quindi il risultato dell'esecuzione del comando sul primo server deve essere copiato ed eseguito sugli altri.
Configurazione iniziale del cluster, eseguo il comando di avvio 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 managerCopia il risultato del secondo comando, esegui 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, passiamo alla configurazione dei servizi, i comandi da eseguire saranno avviati da node1, se non indicato diversamente.
Per prima cosa, creiamo 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 gitlabPoi etichettiamo i server, questo è necessario per legare 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 node3Successivamente, creiamo directory per la conservazione dei dati etcd, uno storage KV, necessario per Traefik e Stolon. Analogamente a PostgreSQL, questi saranno container legati 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 in funzione:
# 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, eseguendo il comando su tutti i server:
# mkdir -p /srv/pgsqlSuccessivamente, creiamo un file per configurare 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 i segreti, applicando 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 siano stati avviati), inizializziamo 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 initVerifichiamo la disponibilità 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
Configuriamo traefik per aprire l'accesso ai container 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 Redis Cluster, per questo creiamo una directory per lo storage su tutti i nodi:
# 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 Docker Registry:
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? Configurare in Traefik il funzionamento dei container tramite https, aggiungere la crittografia tls per Postgresql e Redis. Ma nel complesso è già possibile darlo agli sviluppatori come PoC. Vediamo ora le alternative a Docker.
Podman
Un altro engine abbastanza conosciuto per l'esecuzione di container, raggruppati in pod (pods, gruppi di container distribuiti insieme). A differenza di Docker, non richiede alcun servizio per avviare i container, tutto il lavoro viene eseguito tramite la libreria libpod. È stato anch'esso scritto in Go e richiede un runtime compatibile con OCI per eseguire i container, come runC.
Lavorare con Podman è simile a farlo con Docker, tanto da poter fare così (come riportato da molti che lo hanno provato, incluso l'autore di questo articolo):
$ alias docker=podmane si può continuare a lavorare. In generale, la situazione con Podman è molto interessante, poiché se le prime versioni di Kubernetes funzionavano con Docker, a partire dal 2015, dopo la standardizzazione del 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. In questo senso, Podman è un'alternativa a Docker, progettata secondo i principi di Kubernetes, incluse le funzionalità di raggruppamento dei container, ma l'obiettivo principale del progetto è l'esecuzione di container in stile Docker senza servizi aggiuntivi. Per ragioni comprensibili, non esiste la modalità swarm, poiché gli sviluppatori chiariscono che se è necessario un cluster, allora si deve usare Kubernetes.
Installazione
Per l'installazione su CentOS 7, è sufficiente attivare il repository Extras e poi installare tutto con il comando:
# yum -y install podmanAltre funzionalità
Podman può generare unità per systemd, risolvendo così il problema dell'avvio dei container dopo il riavvio del server. Inoltre, è dichiarato che systemd funziona correttamente come pid 1 all'interno di un container. Per la costruzione dei container esiste uno strumento separato, buildah, e ci sono anche strumenti di terze parti — analoghi di docker-compose, che generano anche file di configurazione compatibili con Kubernetes, quindi la transizione da Podman a Kubernetes è semplificata il più possibile.
Lavorare con Podman
Poiché non esiste la modalità swarm (si prevede un passaggio a Kubernetes, se è necessario un cluster) — assembleremo con contenitori 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 genererà per systemd e kubernetes; per farlo, dobbiamo 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.targetSfortunatamente, oltre all'avvio dei container, l'unità generata per systemd non fa altro (ad esempio, non pulisce i vecchi container al riavvio di un tale servizio), quindi tali operazioni dovranno essere aggiunte manualmente.
In linea di principio, Podman è sufficiente per provare cosa sono i container, trasferire vecchie configurazioni per docker-compose e poi passare a Kubernetes se è necessario un cluster, oppure ottenere un'alternativa più semplice a Docker.
rkt
Progetto circa sei mesi fa, poiché è stato acquistato da RedHat, quindi non mi fermerò ad approfondire. In generale, ha lasciato un'impressione piuttosto buona, ma rispetto a Docker e ancor di più a Podman appare come un aggeggio. C'era anche una distribuzione CoreOS, basata su rkt (anche se avevano originariamente Docker), ma il suo supporto è terminato dopo l'acquisto da parte di RedHat.
Plash
Altro , il cui autore voleva semplicemente costruire e avviare container. Da quanto si evince dalla documentazione e dal codice, l'autore non ha seguito gli standard, ma ha semplicemente deciso di scrivere una propria implementazione, e in effetti l'ha fatto.
Conclusioni
La situazione con Kubernetes è piuttosto interessante: da un lato, con Docker è possibile creare un cluster (in modalità swarm), con il quale è anche possibile avviare ambienti di produzione per i clienti, cosa particolarmente rilevante per piccoli team (3-5 persone), o in caso di carichi complessivi contenuti, o in assenza di voglia di gestire i dettagli della configurazione di Kubernetes, inclusa anche la gestione di carichi elevati.
Podman non offre piena compatibilità, ma ha un importante vantaggio — la compatibilità con Kubernetes, incluse anche le strumenti aggiuntivi (buildah e altro). Pertanto, per la scelta dello strumento di lavoro adotterò il seguente approccio: per piccoli team o con budget limitato — Docker (con possibile modalità swarm), per lo sviluppo personale su localhost — Podman con collaboratori, e per tutti gli altri — Kubernetes.
Non sono sicuro che la situazione con Docker non cambierà in futuro; dopotutto, sono pionieri e stanno gradualmente standardizzando, ma con Podman, nonostante tutte le sue lacune (funziona solo su Linux, non ha clustering, costruzione e altre operazioni — soluzioni di terze parti), il futuro è più chiaro, quindi invito tutti gli interessati a discutere queste conclusioni nei commenti.
P.S. Il 3 agosto lanciamo "», dove potrai scoprire di più sul suo funzionamento. Esamineremo tutti i suoi strumenti: dalle astrazioni di base alle impostazioni di rete, le sottigliezze del lavoro con diversi sistemi operativi e linguaggi di programmazione. Imparerai la tecnologia e capirai dove e come utilizzare al meglio Docker. Condivideremo anche casi di best practice.
Costo del preordine prima del rilascio: 5000 r. È possibile consultare il programma del «Corso Videocorso su Docker» .
Fonte: habr.com
