TL;DR : un article-guide comparant les environnements de déploiement des applications dans des conteneurs. Les capacités de Docker et d'autres systÚmes similaires seront examinées.
Un peu d'histoire, d'oĂč tout cela vient
Historique
La premiĂšre mĂ©thode bien connue d'isolation des applications est chroot. L'appel systĂšme du mĂȘme nom permet de changer le rĂ©pertoire racine â assurant ainsi Ă la programme qui l'appelle l'accĂšs uniquement aux fichiers Ă l'intĂ©rieur de ce rĂ©pertoire. Cependant, si l'on accorde des droits de superutilisateur au programme Ă l'intĂ©rieur, il peut potentiellement « s'Ă©chapper » de chroot et accĂ©der au systĂšme d'exploitation principal. De plus, en dehors du changement de rĂ©pertoire racine, d'autres ressources (mĂ©moire vive, processeur) ne sont pas limitĂ©es, tout comme l'accĂšs au rĂ©seau.
La mĂ©thode suivante consiste Ă exĂ©cuter un systĂšme d'exploitation complet Ă l'intĂ©rieur d'un conteneur, grĂące aux mĂ©canismes du noyau du systĂšme d'exploitation. Dans diffĂ©rents systĂšmes d'exploitation, cette mĂ©thode est appelĂ©e diffĂ©remment, mais le principe est le mĂȘme â exĂ©cuter plusieurs systĂšmes d'exploitation indĂ©pendants, chacun fonctionnant avec le mĂȘme noyau que le systĂšme d'exploitation principal. Cela inclut FreeBSD Jails, Solaris Zones, OpenVZ et LXC pour Linux. L'isolation est assurĂ©e non seulement par l'espace disque, mais aussi par d'autres ressources, en particulier chaque conteneur peut avoir des limites sur le temps processeur, la mĂ©moire vive, et la bande passante rĂ©seau. ComparĂ© Ă chroot, il est plus difficile de sortir d'un conteneur, car le superutilisateur dans le conteneur n'a accĂšs qu'Ă l'environnement interne du conteneur, cependant, en raison de la nĂ©cessitĂ© de maintenir le systĂšme d'exploitation Ă jour Ă l'intĂ©rieur du conteneur et de l'utilisation d'anciennes versions de noyau (surtout pour Linux, dans une moindre mesure pour FreeBSD), il existe une probabilitĂ© non nulle de « briser » le systĂšme d'isolation du noyau et d'accĂ©der au systĂšme d'exploitation principal.
Au lieu de lancer un systĂšme d'exploitation complet dans un conteneur (avec systĂšme d'initialisation, gestionnaire de paquets, etc.), il est possible de dĂ©marrer directement des applications, Ă condition de leur permettre de le faire (disponibilitĂ© des bibliothĂšques nĂ©cessaires et autres fichiers). Cette idĂ©e a servi de base Ă la virtualisation des applications par conteneurs, dont le reprĂ©sentant le plus emblĂ©matique et connu est Docker. ComparĂ© aux systĂšmes prĂ©cĂ©dents, des mĂ©canismes d'isolement plus flexibles, associĂ©s au support intĂ©grĂ© des rĂ©seaux virtuels entre les conteneurs et Ă la surveillance de l'Ă©tat des applications Ă l'intĂ©rieur des conteneurs, ont permis de crĂ©er un environnement unique et cohĂ©rent Ă partir d'un grand nombre de serveurs physiques pour exĂ©cuter des conteneurs â sans nĂ©cessitĂ© de gestion manuelle des ressources.
Docker
Docker est le logiciel de conteneurisation d'applications le plus connu. Ăcrit en Go, il utilise les capacitĂ©s natives du noyau Linux â cgroups, namespaces, capabilities, etc. â ainsi que les systĂšmes de fichiers Aufs et autres similaires pour Ă©conomiser de l'espace disque.
Source : wikimedia
Architecture
Avant la version 1.11, Docker fonctionnait comme un service unique, gĂ©rant toutes les opĂ©rations avec les conteneurs : tĂ©lĂ©chargement d'images pour les conteneurs, lancement de conteneurs, traitement des requĂȘtes API. Ă partir de la version 1.11, Docker a Ă©tĂ© divisĂ© en plusieurs parties interagissant entre elles : containerd, pour gĂ©rer tout le cycle de vie des conteneurs (allocation d'espace disque, tĂ©lĂ©chargement d'images, gestion du rĂ©seau, dĂ©marrage, installation et surveillance de l'Ă©tat des conteneurs) et runC, l'environnement d'exĂ©cution des conteneurs, basĂ© sur l'utilisation de cgroups et d'autres fonctionnalitĂ©s du noyau Linux. Le service docker lui-mĂȘme subsiste, mais il ne sert dĂ©sormais qu'Ă traiter les requĂȘtes API, qui sont transmises Ă containerd.
Installation et configuration
Ma méthode préférée pour installer docker est docker-machine, qui, en plus de l'installation et de la configuration de docker sur des serveurs distants (y compris divers clouds), permet de travailler avec les systÚmes de fichiers des serveurs distants, et peut également exécuter diverses commandes.
Cependant, depuis 2018, le projet a peu Ă©voluĂ©, c'est pourquoi nous allons procĂ©der Ă l'installation de maniĂšre standard pour la plupart des distributions Linux â en ajoutant le dĂ©pĂŽt et en installant les paquets nĂ©cessaires.
Cette méthode est également utilisée lors de l'installation automatisée, par exemple avec Ansible ou d'autres systÚmes similaires, mais je ne l'examinerai pas dans cet article.
L'installation se fera sur CentOS 7, et j'utiliserai une machine virtuelle comme serveur. Pour l'installation, il suffit d'exécuter les commandes ci-dessous :
# 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.ioAprĂšs l'installation, il faut dĂ©marrer le service et lâajouter au dĂ©marrage automatique :
# systemctl enable docker
# systemctl start docker
# firewall-cmd --zone=public --add-port=2377/tcp --permanentEn outre, vous pouvez créer un groupe docker, dont les utilisateurs pourront travailler avec docker sans sudo, configurer la journalisation, activer l'accÚs à l'API depuis l'extérieur, et ne pas oublier de configurer plus précisément le pare-feu (tout ce qui n'est pas autorisé est interdit, comme je l'ai omis pour simplifier et rendre cela plus clair dans les exemples ci-dessus et ci-dessous), mais je ne vais pas m'attarder sur ce point.
Autres possibilités
En plus de la docker machine mentionnĂ©e ci-dessus, il y a aussi le docker registry, un outil pour stocker des images de conteneurs, ainsi que docker compose â un outil pour automatiser le dĂ©ploiement d'applications dans des conteneurs, utilisant des fichiers YAML pour assembler et configurer des conteneurs et d'autres Ă©lĂ©ments connexes (par exemple, des rĂ©seaux, des systĂšmes de fichiers persistants pour le stockage des donnĂ©es).
Avec cela, il est également possible d'organiser des pipelines pour le CICD. Une autre fonctionnalité intéressante est le mode cluster, appelé swarm mode (avant la version 1.12, connu sous le nom de docker swarm), qui permet de créer une infrastructure unique pour exécuter des conteneurs à partir de plusieurs serveurs. Il offre un support pour un réseau virtuel à travers tous les serveurs, un équilibreur de charge intégré, ainsi qu'un support pour les secrets des conteneurs.
Les fichiers YAML de docker compose, avec quelques modifications mineures, peuvent ĂȘtre utilisĂ©s pour ces clusters, automatisant complĂštement la gestion de petits et moyens clusters pour divers objectifs. Pour les grands clusters, il est prĂ©fĂ©rable d'utiliser Kubernetes, car les coĂ»ts d'entretien du swarm mode peuvent dĂ©passer ceux de Kubernetes. En plus de runC, comme environnement d'exĂ©cution des conteneurs, vous pouvez installer par exemple
Travail avec Docker
AprÚs l'installation et la configuration, essayons de créer un cluster sur lequel nous déploierons GitLab et Docker Registry pour l'équipe de développeurs. Comme serveurs, j'utiliserai trois machines virtuelles, sur lesquelles je déploierai également un systÚme de fichiers distribué GlusterFS, que j'utiliserai comme stockage pour les volumes Docker, par exemple pour exécuter une version tolérante aux pannes de Docker Registry. Les composants clés pour le lancement sont: Docker Registry, Postgresql, Redis, et GitLab avec support GitLab Runner sur Swarm. Nous lancerons Postgresql avec clustering. , donc pour le stockage des données de Postgresql, nous ne devons pas utiliser GlusterFS. Les autres données critiques seront stockées sur GlusterFS.
Pour déployer GlusterFS sur tous les serveurs (nommés node1, node2, node3), il est nécessaire d'installer les paquets, d'autoriser le fonctionnement du pare-feu et de créer les répertoires nécessaires:
# 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/fstabAprĂšs l'installation, le travail de configuration de GlusterFS doit se poursuivre depuis un nĆud, par exemple 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 dockerEnsuite, il faut monter le volume obtenu (la commande doit ĂȘtre exĂ©cutĂ©e sur tous les serveurs):
# mount /srv/dockerLa configuration du mode swarm se fait sur l'un des serveurs, qui sera le Leader, les autres devront rejoindre le cluster, donc il faudra copier le résultat de la commande exécutée sur le premier serveur et l'exécuter sur les autres.
Configuration initiale du cluster, je lance la commande sur 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 managerNous copions le résultat de la deuxiÚme commande, que nous exécutons sur node2 et node3:
# docker swarm join --token SWMTKN-x-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx-xxxxxxxxx xx.xx.xx.xx:2377
This node joined a swarm as a manager.à ce stade, la configuration préliminaire des serveurs est terminée, nous passons à la configuration des services, les commandes à exécuter seront lancées à partir de node1, sauf indication contraire.
Tout d'abord, créons des réseaux pour les conteneurs:
# 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 gitlabEnsuite, marquons les serveurs, cela est nécessaire pour lier certains services aux serveurs:
# docker node update --label-add nodename=node1 node1
# docker node update --label-add nodename=node2 node2
# docker node update --label-add nodename=node3 node3Ensuite, nous créons des répertoires pour stocker les données etcd, un stockage KV nécessaire pour Traefik et Stolon. Comme pour Postgresql, ce seront des conteneurs liés aux serveurs, donc nous exécutons cette commande sur tous les serveurs:
# mkdir -p /srv/etcdEnsuite, nous créons un fichier pour la configuration d'etcd et l'appliquons:
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 etcdAprÚs un certain temps, vérifions que le cluster etcd est opérationnel :
# 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 healthyCréons des répertoires pour Postgresql, la commande sera exécutée sur tous les serveurs :
# mkdir -p /srv/pgsqlEnsuite, créons le fichier de configuration pour 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: trueGénérons des secrets, appliquons le fichier :
# </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 pgsqlAprÚs un certain temps (vérifiez la sortie de la commande docker service ls, en s'assurant que tous les services sont en cours d'exécution) nous initialisons le 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 initVérifions la disponibilité du 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
Configurons traefik pour ouvrir l'accÚs aux conteneurs depuis l'extérieur :
03traefik.yml
version: '3.7'
services:
traefik:
image: traefik:latest
command: >
--log.level=INFO
--providers.docker=true
--entryPoints.web.address=:80
--providers.providersThrottleDuration=2
--providers.docker.watch=true
--providers.docker.swarmMode=true
--providers.docker.swarmModeRefreshSeconds=15s
--providers.docker.exposedbydefault=false
--accessLog.bufferingSize=0
--api=true
--api.dashboard=true
--api.insecure=true
networks:
- traefik
ports:
- 80:80
volumes:
- /var/run/docker.sock:/var/run/docker.sock
deploy:
replicas: 3
placement:
constraints:
- node.role == manager
preferences:
- spread: node.id
labels:
- traefik.enable=true
- traefik.http.routers.traefik.rule=Host(`traefik.example.com`)
- traefik.http.services.traefik.loadbalancer.server.port=8080
- traefik.docker.network=traefik
networks:
traefik:
external: true# docker stack deploy --compose-file 03traefik.yml traefikLançons le cluster Redis, pour cela, crĂ©ons un rĂ©pertoire de stockage sur tous les nĆuds :
# 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 redisAjoutons le registre 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 registryEt enfin â 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 gitlabĂtat final du cluster et des services :
# 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/tcpQuelles autres amĂ©liorations peuvent ĂȘtre apportĂ©es ? Assurez-vous de configurer Traefik pour le fonctionnement des conteneurs via https, d'ajouter le chiffrement tls pour Postgresql et Redis. Mais dans l'ensemble, il est dĂ©jĂ possible de le transmettre aux dĂ©veloppeurs en tant que PoC. Voyons maintenant les alternatives Ă Docker.
Podman
Un autre moteur assez connu pour exécuter des conteneurs, regroupés par pods (pods, groupes de conteneurs déployés ensemble). Contrairement à Docker, il ne nécessite pas de service pour exécuter des conteneurs, tout le travail se fait via la bibliothÚque libpod. Il est également écrit en Go et nécessite un runtime compatible OCI pour exécuter des conteneurs, comme runC.
Le travail avec Podman ressemble globalement à celui de Docker, au point qu'il est possible de faire comme ceci (selon beaucoup de ceux qui ont essayé, y compris l'auteur de cet article) :
$ alias docker=podmanet vous pouvez continuer Ă travailler. Globalement, la situation avec Podman est trĂšs intĂ©ressante, car si les premiĂšres versions de Kubernetes fonctionnaient avec Docker, depuis 2015, aprĂšs la normalisation du monde des conteneurs (OCI â Open Container Initiative) et la sĂ©paration de Docker en containerd et runC, une alternative Ă Docker pour l'exĂ©cution dans Kubernetes est en dĂ©veloppement : CRI-O. Podman, dans ce sens, est une alternative Ă Docker construite sur les principes de Kubernetes, y compris le regroupement des conteneurs, mais l'objectif principal de l'existence du projet est d'exĂ©cuter des conteneurs dans le style de Docker sans services supplĂ©mentaires. Pour des raisons Ă©videntes, il n'existe pas de mode swarm, car les dĂ©veloppeurs disent clairement que si vous avez besoin d'un cluster, prenez Kubernetes.
Installation
Pour l'installation sur Centos 7, il suffit d'activer le dépÎt Extras, puis d'installer tout avec la commande :
# yum -y install podmanAutres possibilités
Podman peut gĂ©nĂ©rer des unitĂ©s pour systemd, rĂ©solvant ainsi le problĂšme du lancement de conteneurs aprĂšs le redĂ©marrage du serveur. De plus, une bonne fonctionnalitĂ© de systemd en tant que pid 1 dans le conteneur a Ă©tĂ© annoncĂ©e. Un outil distinct, buildah, est utilisĂ© pour la construction des conteneurs, et il existe Ă©galement des outils tiers â des analogues de docker-compose, gĂ©nĂ©rant Ă©galement des fichiers de configuration compatibles avec Kubernetes, facilitant ainsi la transition de Podman vers Kubernetes autant que possible.
Travailler avec Podman
Comme il n'y a pas de mode swarm (il est prĂ©vu de passer Ă Kubernetes si un cluster est nĂ©cessaire) â nous allons assembler des conteneurs individuels.
Nous installons podman-compose :
# yum -y install python3-pip
# pip3 install podman-composeLe fichier de configuration résultant pour podman est légÚrement différent, par exemple il a fallu déplacer une section distincte des volumes directement dans la section des services.
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 upRĂ©sultat du travail :
# 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_1Voyons ce qu'il générera pour systemd et Kubernetes, pour cela nous devons connaßtre le nom ou l'ID du 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.targetMalheureusement, Ă part le dĂ©marrage des conteneurs, l'unitĂ© gĂ©nĂ©rĂ©e pour systemd ne fait rien d'autre (par exemple, elle ne nettoie pas les anciens conteneurs lors du redĂ©marrage d'un tel service), donc ces choses devront ĂȘtre ajoutĂ©es manuellement.
En gros, Podman est suffisant pour essayer ce que sont les conteneurs, transférer d'anciennes configurations pour docker-compose, aprÚs quoi il est possible de passer à Kubernetes, si nécessaire pour un cluster, ou d'obtenir une alternative plus simple à Docker.
rkt
Projet il y a environ six mois, parce que RedHat l'a achetĂ©, donc je ne vais pas m'attarder dessus. Globalement, il laissait une impression plutĂŽt bonne, mais comparĂ© Ă Docker et encore plus Ă Podman, il semble ĂȘtre un outil plus complexe. Il y avait aussi une distribution CoreOS, basĂ©e sur rkt (bien qu'ils aient commencĂ© avec Docker), mais son support a Ă©galement pris fin aprĂšs l'acquisition par RedHat.
Plash
Autre , dont l'auteur voulait simplement assembler et exécuter des conteneurs. D'aprÚs la documentation et le code, l'auteur n'a pas suivi les normes, mais a simplement décidé de créer sa propre implémentation, ce qu'il a effectivement fait.
Conclusions
La situation avec Kubernetes est assez intĂ©ressante : d'un cĂŽtĂ©, avec Docker, on peut crĂ©er un cluster (en mode swarm), qui peut mĂȘme exĂ©cuter des environnements de production pour des clients, ce qui est particuliĂšrement pertinent pour de petites Ă©quipes (3-5 personnes), ou lorsque la charge gĂ©nĂ©rale est faible, ou encore en absence de dĂ©sir de se plonger dans les subtilitĂ©s de la configuration de Kubernetes, y compris pour de fortes charges.
Podman n'assure pas une compatibilitĂ© totale, mais il a un avantage majeur : la compatibilitĂ© avec Kubernetes, y compris pour les outils supplĂ©mentaires (buildah et autres). Par consĂ©quent, ma sĂ©lection d'outil sera la suivante : pour les petites Ă©quipes ou avec un budget limitĂ© â Docker (avec le mode swarm possible), pour un dĂ©veloppement personnel sur un localhost â Podman avec des collĂšgues, et pour tout le reste â Kubernetes.
Je ne suis pas sĂ»r que la situation avec Docker ne change pas Ă l'avenir, car ils sont les pionniers, et commencent Ă ĂȘtre standardisĂ©s petit Ă petit. Cependant, malgrĂ© tous ses inconvĂ©nients (fonctionne uniquement sur Linux, pas de clustering, la construction et d'autres actions nĂ©cessitant des solutions tierces), l'avenir de Podman semble plus clair. J'invite donc tous ceux qui le souhaitent Ă discuter de ces conclusions dans les commentaires.
P.S. Le 3 aoĂ»t, nous lançons «», oĂč vous pourrez en savoir plus sur son fonctionnement. Nous examinerons tous ses outils : des abstractions de base aux paramĂštres rĂ©seau, les particularitĂ©s de travail avec diffĂ©rents systĂšmes d'exploitation et langages de programmation. Vous vous familiariserez avec la technologie et comprendrez oĂč et comment mieux utiliser Docker. Nous partagerons Ă©galement des cas de best practices.
Le coût de la précommande avant la sortie : 5000 roubles. Vous pouvez consulter le programme « Vidéo Cours sur Docker » .
Source : habr.com
