TL;DR: una guida panoramica per confrontare i framework per l'esecuzione di applicazioni in contenitori. Verranno prese in considerazione le capacità di Docker e di altri sistemi simili.
Un po' di storia da dove tutto ha avuto origine
storia
Il primo metodo noto per isolare un'applicazione è chroot. La chiamata di sistema con lo stesso nome garantisce che la directory root venga modificata, garantendo così che il programma che l'ha chiamata abbia accesso solo ai file all'interno di quella directory. Ma se a un programma vengono concessi internamente i privilegi di root, può potenzialmente “sfuggire” al chroot e ottenere l’accesso al sistema operativo principale. Inoltre, oltre alla modifica della directory principale, non sono limitate altre risorse (RAM, processore) e l'accesso alla rete.
Il metodo successivo consiste nel lanciare un sistema operativo completo all'interno di un contenitore, utilizzando i meccanismi del kernel del sistema operativo. Questo metodo viene chiamato in modo diverso a seconda dei diversi sistemi operativi, ma l'essenza è la stessa: avviare diversi sistemi operativi indipendenti, ognuno dei quali esegue lo stesso kernel su cui gira il sistema operativo principale. Questi includono Jail di FreeBSD, Solaris Zones, OpenVZ e LXC per Linux. L'isolamento è assicurato non solo dallo spazio su disco, ma anche da altre risorse; in particolare ogni contenitore può avere limitazioni sul tempo del processore, sulla RAM e sulla larghezza di banda della rete. Rispetto al chroot, lasciare il contenitore è più difficile, poiché il superutente nel contenitore ha accesso solo al contenuto del contenitore, tuttavia, a causa della necessità di mantenere aggiornato il sistema operativo all'interno del contenitore e dell'utilizzo di versioni precedenti dei kernel (rilevante per Linux, in misura minore per FreeBSD), c'è una probabilità diversa da zero di "sfondare" il sistema di isolamento del kernel e ottenere l'accesso al sistema operativo principale.
Invece di avviare un sistema operativo completo in un contenitore (con un sistema di inizializzazione, un gestore di pacchetti, ecc.), puoi avviare immediatamente le applicazioni, l'importante è fornire alle applicazioni tale opportunità (la presenza delle librerie necessarie e altri file). Questa idea è servita come base per la virtualizzazione delle applicazioni containerizzate, il cui rappresentante più importante e conosciuto è Docker. Rispetto ai sistemi precedenti, meccanismi di isolamento più flessibili, abbinati al supporto integrato per le reti virtuali tra contenitori e al monitoraggio dello stato dell'applicazione all'interno del contenitore, hanno consentito di creare un unico ambiente coerente da un gran numero di server fisici per l'esecuzione dei contenitori. senza la necessità di gestire manualmente le risorse.
docker
Docker è il più famoso software di containerizzazione delle applicazioni. Scritto nel linguaggio Go, utilizza le funzionalità standard del kernel Linux: cgroup, spazi dei nomi, funzionalità, ecc., nonché file system Aufs e altri simili per risparmiare spazio su disco.
Fonte: wikimedia
Architettura
Prima della versione 1.11, Docker funzionava come un unico servizio che eseguiva tutte le operazioni con i contenitori: download di immagini per contenitori, avvio di contenitori, elaborazione di richieste API. A partire dalla versione 1.11, Docker è stato suddiviso in più parti che interagiscono tra loro: containerd, per l'elaborazione dell'intero ciclo di vita dei contenitori (allocazione dello spazio su disco, download delle immagini, lavoro con la rete, avvio, installazione e monitoraggio dello stato dei contenitori) e runC, l'ambiente di esecuzione del contenitore, basato sull'uso di cgroup e altre funzionalità del kernel Linux. Il servizio docker stesso rimane, ma ora serve solo per elaborare le richieste API tradotte in containerd.
Installazione e configurazione
Il mio modo preferito per installare docker è docker-machine, che, oltre a installare e configurare direttamente docker su server remoti (inclusi vari cloud), consente di lavorare con file system di server remoti e può anche eseguire vari comandi.
Tuttavia, dal 2018, il progetto è stato appena sviluppato, quindi lo installeremo nel modo standard per la maggior parte delle distribuzioni Linux, aggiungendo un repository e installando i pacchetti necessari.
Questo metodo viene utilizzato anche per installazioni automatizzate, ad esempio utilizzando Ansible o altri sistemi simili, ma non lo prenderò in considerazione in questo articolo.
L'installazione verrà effettuata su Centos 7, utilizzerò una macchina virtuale come server, per installare basterà 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 metterlo in startup:
# systemctl enable docker
# systemctl start docker
# firewall-cmd --zone=public --add-port=2377/tcp --permanentInoltre, puoi creare un gruppo docker, i cui utenti potranno lavorare con docker senza sudo, impostare il logging, abilitare l'accesso all'API dall'esterno e non dimenticare di configurare il firewall in modo più preciso (tutto ciò che non è consentito è proibito negli esempi sopra e sotto - l'ho omesso per semplicità e chiarezza), ma non entrerò qui nei dettagli.
Altre caratteristiche
Oltre alla suddetta macchina docker, esiste anche il registro docker, uno strumento per archiviare immagini per contenitori, nonché docker compose, uno strumento per automatizzare la distribuzione di applicazioni in contenitori, i file YAML vengono utilizzati per creare e configurare contenitori e altre cose correlate (ad esempio reti, file system persistenti per l'archiviazione dei dati).
Può anche essere utilizzato per organizzare i trasportatori per CICD. Un'altra caratteristica interessante è il funzionamento in modalità cluster, la cosiddetta modalità swarm (prima della versione 1.12 era conosciuta come docker swarm), che consente di assemblare un'unica infrastruttura da più server per l'esecuzione dei container. C'è il supporto per una rete virtuale sopra tutti i server, c'è un bilanciatore del carico integrato, nonché il supporto per i segreti per i contenitori.
I file YAML di docker compose, con piccole modifiche, possono essere utilizzati per tali cluster, automatizzando completamente la manutenzione di cluster di piccole e medie dimensioni per vari scopi. Per i cluster di grandi dimensioni, Kubernetes è preferibile perché i costi di manutenzione della modalità swarm possono superare quelli di Kubernetes. Oltre a runC è possibile installarlo, ad esempio, come ambiente di esecuzione del contenitore
Lavorare con Docker
Dopo l'installazione e la configurazione, proveremo ad assemblare un cluster in cui distribuiremo GitLab e Docker Registry per il team di sviluppo. Utilizzerò tre macchine virtuali come server, sulle quali distribuirò inoltre l'FS distribuito GlusterFS; lo utilizzerò come storage di volumi docker, ad esempio, per eseguire una versione tollerante agli errori del registro docker. Componenti chiave da eseguire: Docker Registry, Postgresql, Redis, GitLab con supporto per GitLab Runner su Swarm. Lanceremo Postgresql con il clustering , quindi non è necessario utilizzare GlusterFS per archiviare i dati Postgresql. I restanti dati critici verranno archiviati su GlusterFS.
Per distribuire GlusterFS su tutti i server (sono chiamati nodo1, nodo2, nodo3), è 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, il lavoro sulla configurazione di GlusterFS deve essere continuato da un nodo, ad esempio nodo1:
# 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 dockerQuindi è necessario montare il volume risultante (il comando deve essere eseguito su tutti i server):
# mount /srv/dockerLa modalità sciame è configurata su uno dei server, che sarà il Leader, gli altri dovranno unirsi al cluster, quindi il risultato dell'esecuzione del comando sul primo server dovrà essere copiato ed eseguito sugli altri.
Configurazione 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 e lo 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, completata la configurazione preliminare dei server, procediamo al settaggio dei servizi; i comandi da eseguire verranno lanciati dal nodo1, se non diversamente specificato.
Prima di tutto creiamo reti per contenitori:
# 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 gitlabQuindi 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 node3Successivamente, creiamo directory per l'archiviazione dei dati etcd, archiviazione KV, necessaria per Traefik e Stolon. Similmente a Postgresql, questi saranno contenitori legati ai server, quindi eseguiamo questo comando su tutti i server:
# mkdir -p /srv/etcdSuccessivamente, crea un file per configurare etcd e usalo:
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' di tempo, controlliamo 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 directory per Postgresql, eseguiamo il comando su tutti i server:
# mkdir -p /srv/pgsqlSuccessivamente, crea 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 segreti e utilizziamo 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' di tempo (vedi l'output del comando servizio docker lsche tutti i servizi siano attivi) 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 initVerifica della 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 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 traefikLanciamo Redis Cluster, per fare questo creiamo una directory di 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 <<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 redisAggiungi registro Docker:
06registro.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'] = "[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 gitlabLo stato 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/tcpCos'altro può essere migliorato? Assicurati di configurare Traefik per eseguire contenitori su https, aggiungi la crittografia tls per Postgresql e Redis. Ma in generale può già essere fornito agli sviluppatori come PoC. Diamo ora un'occhiata alle alternative a Docker.
Podman
Un altro motore abbastanza noto per l'esecuzione di contenitori raggruppati per pod (pod, gruppi di contenitori distribuiti insieme). A differenza di Docker, non richiede alcun servizio per eseguire i contenitori; tutto il lavoro viene svolto tramite la libreria libpod. Scritto anch'esso in Go, richiede un runtime compatibile con OCI per eseguire contenitori, come runC.
Lavorare con Podman in genere ricorda quello con Docker, al punto che puoi farlo in questo modo (come affermato da molti che l'hanno provato, compreso l'autore di questo articolo):
$ alias docker=podmane puoi continuare a lavorare. In generale, la situazione con Podman è molto interessante, perché se le prime versioni di Kubernetes funzionavano con Docker, poi intorno al 2015, dopo la standardizzazione del mondo dei container (OCI - Open Container Initiative) e la divisione di Docker in containerd e runC, è stata sviluppata un'alternativa a Docker per l'esecuzione in Kubernetes: CRI-O. Podman a questo proposito è un'alternativa a Docker, costruita sui principi di Kubernetes, incluso il raggruppamento di contenitori, ma lo scopo principale del progetto è lanciare contenitori in stile Docker senza servizi aggiuntivi. Per ovvi motivi, non esiste la modalità sciame, poiché gli sviluppatori dicono chiaramente che se hai bisogno di un cluster, prendi Kubernetes.
Installazione
Per installare su Centos 7 basta attivare la repository Extras, e poi installare il tutto con il comando:
# yum -y install podmanAltre caratteristiche
Podman può generare unità per systemd, risolvendo così il problema dell'avvio dei contenitori dopo il riavvio del server. Inoltre, systemd viene dichiarato per funzionare correttamente come pid 1 nel contenitore. Esiste uno strumento buildah separato per la creazione di contenitori, 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à sciame (dovremmo passare a Kubernetes se è necessario un cluster), lo raccoglieremo in contenitori separati.
Installa podman-compose:
# yum -y install python3-pip
# pip3 install podman-composeIl file di configurazione risultante per podman è leggermente diverso, quindi ad esempio abbiamo dovuto spostare una sezione separata dei volumi direttamente nella sezione con i 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:
# 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 dobbiamo scoprire 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 db40ab8bf84bKuberneti:
# 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: {}Sistemad:
# 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, a parte l'avvio dei contenitori, l'unità generata per systemd non fa nient'altro (ad esempio, ripulire i vecchi contenitori quando tale servizio viene riavviato), quindi dovrai scrivere queste cose da solo.
In linea di principio, Podman è sufficiente per provare cosa sono i contenitori, trasferire le vecchie configurazioni per docker-compose e poi spostarsi verso Kubernetes, se è necessario un cluster, o ottenere un'alternativa più semplice da usare a Docker.
RKT
Progetto circa sei mesi fa a causa del fatto che RedHat lo ha acquistato, quindi non mi soffermerò su questo in modo più dettagliato. Nel complesso ha lasciato un'ottima impressione, ma rispetto a Docker e soprattutto a Podman sembra una mietitrebbia. C'era anche una distribuzione CoreOS costruita su rkt (sebbene originariamente avessero Docker), ma anche questa finì con il supporto dopo l'acquisto di RedHat.
Sbatti
Di più , il cui autore voleva semplicemente creare ed eseguire contenitori. A giudicare dalla documentazione e dal codice, l'autore non ha seguito gli standard, ma ha semplicemente deciso di scrivere la propria implementazione, cosa che, in linea di principio, ha fatto.
risultati
La situazione con Kubernetes è molto interessante: da un lato con Docker puoi costruire un cluster (in modalità swarm), con il quale puoi anche eseguire ambienti di prodotto per i clienti, questo vale soprattutto per i piccoli team (3-5 persone) , o con un carico complessivo ridotto o con la mancanza di desiderio di comprendere le complessità della configurazione di Kubernetes, anche per carichi elevati.
Podman non fornisce la piena compatibilità, ma presenta un vantaggio importante: la compatibilità con Kubernetes, inclusi strumenti aggiuntivi (buildah e altri). Pertanto, affronterò la scelta di uno strumento di lavoro come segue: per piccoli team o con un budget limitato - Docker (con una possibile modalità sciame), per lo sviluppo per me stesso su un localhost personale - compagni Podman e per tutti gli altri - Kubernetes.
Non sono sicuro che la situazione con Docker non cambierà in futuro, dopo tutto, sono pionieri e vengono anche gradualmente standardizzati passo dopo passo, ma Podman, nonostante tutti i suoi difetti (funziona solo su Linux, senza clustering, montaggio e altre azioni sono soluzioni di terze parti) il futuro è più chiaro, quindi invito tutti a discutere questi risultati nei commenti.
PS Il 3 agosto lanciamo”", dove potrai conoscere meglio il suo lavoro. Analizzeremo tutti i suoi strumenti: dalle astrazioni di base ai parametri di rete, le sfumature del lavoro con vari sistemi operativi e linguaggi di programmazione. Acquisirai familiarità con la tecnologia e capirai dove e come utilizzare al meglio Docker. Condivideremo anche casi di migliori pratiche.
Prezzo del preordine prima del rilascio: RUB 5000. È possibile visualizzare il programma del videocorso Docker .
Fonte: habr.com