Кратко: обзорная статья-руководство, сравнивающая платформы для развертывания приложений в контейнерах. Мы рассмотрим возможности Docker и других похожих систем.
Немного истории, как все это началось
История
Первый известный способ изоляции приложений — это chroot. Соответствующий системный вызов изменяет корневую директорию, предоставляя программе, вызвавшей его, доступ только к файлам внутри этой директории. Однако, если программе внутри дать права суперпользователя, то она может "выбежать" из chroot и получить доступ к основной операционной системе. Также, помимо изменения корневой директории, не ограничиваются другие ресурсы (оперативная память, процессор) и доступ к сети.
Следующий подход — это запуск полноценной операционной системы внутри контейнера с использованием механизмов ядра операционной системы. В различных операционных системах этот метод называется по-разному, но суть остается неизменной — запуск нескольких независимых операционных систем, каждая из которых использует общее ядро с основной операционной системой. Это включает FreeBSD Jails, Solaris Zones, OpenVZ и LXC для Linux. Обеспечивается изоляция как по дисковому пространству, так и по другим ресурсам; в частности, каждый контейнер может иметь ограничения по процессорному времени, оперативной памяти и пропускной способности сети. По сравнению с chroot, выйти из контейнера сложнее, поскольку суперпользователь в контейнере имеет доступ только к внутренностям контейнера. Однако из-за необходимости поддерживать операционную систему внутри контейнера в актуальном состоянии и использовать устаревшие версии ядер (это касается Linux, в меньшей мере FreeBSD) существует вероятность "проталкивания" системы изоляции ядра и получения доступа к основной операционной системе.
Вместо стартиране на пълноценна операционна система в контейнер (с инициализационна система, пакетен мениджър и т.н.) можете директно да стартирате приложения. Важно е да се осигурят необходимите библиотеки и други файлове, за да имат приложенията такава възможност. Тази идея послужи за основа на контейнерната виртуализация на приложенията, най-известният представител на която е Docker. В сравнение с предишните системи, по-гъвкавите механизми за изолация в комбинация с вградената поддръжка на виртуални мрежи между контейнерите и проследяването на състоянието на приложението в контейнера дадоха възможност за изграждане на единна цялостна среда от множество физически сървъри за стартиране на контейнери — без нужда от ръчно управление на ресурсите.
Docker
Docker е най-известният софтуер за контейнеризация на приложения. Написан е на езика Go и използва вградените възможности на ядрото на Linux — cgroups, namespaces, capabilities и т.н., а също така файловите системи Aufs и други подобни за икономия на дисково пространство.
Източник: wikimedia
Архитектура
До версия 1.11 Docker работеше като единен сервис, който извършваше всички операции с контейнери: изтегляне на образи за контейнери, стартиране на контейнери, обработка на API заявки. Започвайки от версия 1.11, Docker бе разделен на няколко части, които си взаимодействат: containerd, за управление на целия жизнен цикъл на контейнерите (разделяне на дисково пространство, изтегляне на образи, работа с мрежата, стартиране, инсталиране и наблюдение на състоянието на контейнерите) и runC, среда за изпълнение на контейнери, основана на използването на cgroups и други функции на ядрото на Linux. Сервисът Docker остана, но сега той служи само за обработка на API заявки, които се предават на containerd.
Инсталиране и настройка
Моят любим начин за инсталиране на Docker е docker-machine, който освен директната инсталация и настройка на Docker на отдалечени сървъри (включително различни облаци), предлага възможност за работа с файлови системи на отдалечени сървъри и може да извършва стартиране на различни команди.
Въпреки това, от 2018 година проектът почти не се развива, затова инсталацията ще бъде извършена по стандартния начин за повечето дистрибуции на Linux — добавяне на хранилище и инсталиране на необходимите пакети.
Този метод се прилага и при автоматизирана инсталация, например с помощта на Ansible или други подобни системи, но в тази статия няма да го разглеждам.
Инсталацията ще се извърши на Centos 7. Като сървър ще използвам виртуална машина, за инсталацията е достатъчно да изпълня командите по-долу:
# 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.ioСлед инсталацията е необходимо да стартирате услугата и да я добавите в автозагрузката:
# systemctl enable docker
# systemctl start docker
# firewall-cmd --zone=public --add-port=2377/tcp --permanentДопълнително можете да създадете група docker, потребителите на която ще могат да работят с docker без sudo, да настроите логване, да активирате достъпа до API извън, не забравяйте да конфигурирате фаервола по-точно (забранено е всичко, което не е разрешено; в примерите по-горе и по-долу съм пропуснал това за улеснение и прегледност), но тук няма да задълбочавам.
Други възможности
Освен споменатата docker машина, съществува и docker registry, средство за съхранение на образи за контейнери, както и docker compose — средство за автоматизация на развързването на приложения в контейнери, като се използват YAML файлове за композиране и настройка на контейнери и други свързани елементи (например мрежи, постоянни файлови системи за съхранение на данни).
С негова помощ също така могат да се организират конвейери за CICD. Друга интересна възможност е работата в клъстерен режим, така нареченият swarm mode (до версия 1.12 беше известен като docker swarm), позволяващ да се съберат няколко сървъра в единна инфраструктура за стартиране на контейнери. Поддържа се виртуална мрежа над всички сървъри, наличен е вграден балансировач на натоварването, както и поддръжка на секрети за контейнери.
YAML файловете от docker compose с малки изменения могат да се използват за такива клъстери, напълно автоматизирайки обслужването на малки и средни клъстери за различни цели. За големи клъстери е предимно да се използва Kubernetes, тъй като разходите за обслужване на swarm mode могат да надминат тези с Kubernetes. Освен runC, като среда за изпълнение на контейнери може да се инсталира например
Работа с Docker
След инсталация и конфигурация, ще опитаме да съберем клъстер, в който ще разположим GitLab и Docker Registry за екипа на разработчиците. Като сървъри ще използвам три виртуални машини, на които допълнително ще разположа разпределена файлова система GlusterFS, която ще използвам като хранилище за docker volumes, например за стартиране на отказоустойчива версия на docker registry. Основните компоненти за стартиране: Docker Registry, Postgresql, Redis, GitLab с поддръжка на GitLab Runner върху Swarm. Postgresql ще стартираме с кластеризация. , затова за съхраняване на данните на Postgresql не трябва да се използва GlusterFS. Останалите критични данни ще се съхраняват на GlusterFS.
За разполагане на GlusterFS на всички сървъри (те се именуват node1, node2, node3) е необходимо да се инсталират пакети, да се разреши работата на firewall, да се създадат нужните каталози:
# 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/fstabСлед инсталацията работата по конфигурацията на GlusterFS трябва да продължи от един възел, например 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 dockerСлед това е нужно да се монтира полученият volume (командата трябва да се изпълни на всички сървъри):
# mount /srv/dockerКонфигурацията на swarm mode се извършва на един от сървърите, който ще бъде Leader; останалите трябва да се присъединят към клъстера, затова резултатът от изпълнението на командата на първия сървър трябва да се копира и изпълни и на останалите.
Първоначалната настройка на клъстера, командата стартирам на 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 managerКопираме резултата от втората команда, изпълняваме на node2 и node3:
# docker swarm join --token SWMTKN-x-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx-xxxxxxxxx xx.xx.xx.xx:2377
This node joined a swarm as a manager.На този етап предварителната настройка на сървърите е завършена, преминаваме към настройката на услугите, командите за изпълнение ще се стартират от node1, ако не е посочено друго.
Първо ще създадем мрежи за контейнерите:
# 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 gitlabСлед това отбелязваме сървърите, това е необходимо за свързването на някои услуги към сървърите:
# docker node update --label-add nodename=node1 node1
# docker node update --label-add nodename=node2 node2
# docker node update --label-add nodename=node3 node3След това създаваме каталози за съхранение на данните на etcd, KV-хранилище, необходимо за Traefik и Stolon. Подобно на Postgresql, това ще бъдат свързани контейнери на сървърите, затова тази команда изпълняваме на всички сървъри:
# mkdir -p /srv/etcdСлед това създаваме файл за конфигурация на etcd и го прилагаме:
00etcd.yml
версія: '3.7'
послуги:
etcd1:
зображення: quay.io/coreos/etcd:latest
ім'я хоста: etcd1
команда:
- 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
мережі:
- etcd
обсяги:
- etcd1vol:/data.etcd
розгортання:
копії: 1
розташування:
обмеження: [node.labels.nodename == node1]
etcd2:
зображення: quay.io/coreos/etcd:latest
ім'я хоста: etcd2
команда:
- 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
мережі:
- etcd
обсяги:
- etcd2vol:/data.etcd
розгортання:
копії: 1
розташування:
обмеження: [node.labels.nodename == node2]
etcd3:
зображення: quay.io/coreos/etcd:latest
ім'я хоста: etcd3
команда:
- 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
мережі:
- etcd
обсяги:
- etcd3vol:/data.etcd
розгортання:
копії: 1
розташування:
обмеження: [node.labels.nodename == node3]
обсяги:
etcd1vol:
драйвер: local
параметри_драйвера:
тип: none
o: bind
пристрій: "/srv/etcd"
etcd2vol:
драйвер: local
параметри_драйвера:
тип: none
o: bind
пристрій: "/srv/etcd"
etcd3vol:
драйвер: local
параметри_драйвера:
тип: none
o: bind
пристрій: "/srv/etcd"
мережі:
etcd:
зовнішня: true# docker stack deploy --compose-file 00etcd.yml etcdСлед известно време проверяваме, че etcd клъстера е стартирал:
# 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 healthyСъздаваме директории за Postgresql, командата се изпълнява на всички сървъри:
# mkdir -p /srv/pgsqlСлед това създаваме файл за конфигуриране на Postgresql:
01pgsql.yml
версия: '3.7'
услуги:
pgsentinel:
изображение: sorintlab/stolon:master-pg10
команда:
- 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
сети:
- etcd
- pgsql
развертывание:
реплики: 3
update_config:
parallelism: 1
delay: 30s
order: stop-first
failure_action: pause
pgkeeper1:
изображение: sorintlab/stolon:master-pg10
имя_узла: pgkeeper1
команда:
- 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
сети:
- etcd
- pgsql
окружение:
- PGDATA=/var/lib/postgresql/data
объемы:
- pgkeeper1:/var/lib/postgresql/data
секреты:
- pgsql
- pgsql_repl
развертывание:
реплики: 1
размещение:
ограничения: [node.labels.nodename == node1]
pgkeeper2:
изображение: sorintlab/stolon:master-pg10
имя_узла: pgkeeper2
команда:
- 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
сети:
- etcd
- pgsql
окружение:
- PGDATA=/var/lib/postgresql/data
объемы:
- pgkeeper2:/var/lib/postgresql/data
секреты:
- pgsql
- pgsql_repl
развертывание:
реплики: 1
размещение:
ограничения: [node.labels.nodename == node2]
pgkeeper3:
изображение: sorintlab/stolon:master-pg10
имя_узла: pgkeeper3
команда:
- 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
сети:
- etcd
- pgsql
окружение:
- PGDATA=/var/lib/postgresql/data
объемы:
- pgkeeper3:/var/lib/postgresql/data
секреты:
- pgsql
- pgsql_repl
развертывание:
реплики: 1
размещение:
ограничения: [node.labels.nodename == node3]
postgresql:
изображение: sorintlab/stolon:master-pg10
команда: 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
сети:
- etcd
- pgsql
развертывание:
реплики: 3
update_config:
parallelism: 1
delay: 30s
order: stop-first
failure_action: rollback
объемы:
pgkeeper1:
драйвер: local
драйвер_опции:
type: none
o: bind
device: "/srv/pgsql"
pgkeeper2:
драйвер: local
драйвер_опции:
type: none
o: bind
device: "/srv/pgsql"
pgkeeper3:
драйвер: local
драйвер_опции:
type: none
o: bind
device: "/srv/pgsql"
секреты:
pgsql:
файл: "/srv/docker/postgres"
pgsql_repl:
файл: "/srv/docker/replica"
сети:
etcd:
внешний: true
pgsql:
внешний: trueГенерираме секрети, прилагаме файла:
# </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 pgsqlСлед известно време (проверяваме изхода на командата docker service ls, какво показва, че всички услуги са стартирали) инициализираме кластера 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 initПроверяваме готовността на кластера 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
Настройваме traefik за отваряне на достъп до контейнерите отвън:
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 traefikСтартираме Redis Cluster, за целта създаваме каталог за съхранение на всички възли:
# 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 redisДобавяме Docker Registry:
06registry.yml
версия: '3.7'
сервисы:
реестр:
изображение: registry:2.6
сети:
- traefik
объемы:
- registry_data:/var/lib/registry
развертывание:
реплики: 1
размещение:
ограничения: [node.role == manager]
политика перезапуска:
условие: on-failure
метки:
- traefik.enable=true
- traefik.http.routers.registry.rule=Host(`registry.example.com`)
- traefik.http.services.registry.loadbalancer.server.port=5000
- traefik.docker.network=traefik
объемы:
registry_data:
драйвер: local
параметры_драйвера:
тип: none
o: bind
устройство: "/srv/docker/registry"
сети:
traefik:
внешняя: true# mkdir /srv/docker/registry
# docker stack deploy --compose-file 06registry.yml registryИ наконец — GitLab:
08gitlab-runner.yml
версия: '3.7'
сервисы:
gitlab:
изображение: gitlab/gitlab-ce:latest
сети:
- pgsql
- redis
- traefik
- gitlab
порты:
- 22222:22
среда:
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
объемы:
- gitlab_conf:/etc/gitlab
- gitlab_logs:/var/log/gitlab
- gitlab_data:/var/opt/gitlab
развертывание:
режим: replicated
реплики: 1
размещение:
ограничения:
- node.role == manager
метки:
- 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:
изображение: gitlab/gitlab-runner:latest
сети:
- gitlab
объемы:
- gitlab_runner_conf:/etc/gitlab
- /var/run/docker.sock:/var/run/docker.sock
развертывание:
режим: replicated
реплики: 1
размещение:
ограничения:
- node.role == manager
объемы:
gitlab_conf:
драйвер: local
параметры_драйвера:
тип: none
o: bind
устройство: "/srv/docker/gitlab/conf"
gitlab_logs:
драйвер: local
параметры_драйвера:
тип: none
o: bind
устройство: "/srv/docker/gitlab/logs"
gitlab_data:
драйвер: local
параметры_драйвера:
тип: none
o: bind
устройство: "/srv/docker/gitlab/data"
gitlab_runner_conf:
драйвер: local
параметры_драйвера:
тип: none
o: bind
устройство: "/srv/docker/gitlab/runner"
сети:
pgsql:
внешняя: true
redis:
внешняя: true
traefik:
внешняя: true
gitlab:
внешняя: 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Итоговое состояние кластера и сервисов:
# 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/tcpКакво още може да бъде подобрено? Обязательно настройте работата на контейнерите по https в Traefik, добавете tls криптиране за Postgresql и Redis. Но като цяло вече може да се предаде на разработчиците като PoC. Нека сега разгледаме алтернативите на Docker.
Podman
Друго доста известно engine за стартиране на контейнери, групирани по подове (pods, групи от контейнери, разгорнати заедно). За разлика от Docker, не изисква никаква услуга за стартиране на контейнери, цялата работа се извършва чрез библиотеката libpod. Също така е написан на Go и се нуждае от OCI-съвместим runtime за стартиране на контейнери, например runC.
Работата с Podman като цяло наподобява тази с Docker, до степен, че е възможно да се направи така (заявено от много опитващи, включително и автора на тази статия):
$ alias docker=podmanи може да продължите да работите. Като цяло ситуацията с Podman е доста интересна, тъй като ако ранните версии на Kubernetes работеха с Docker, то от около 2015 година, след стандартизацията на света на контейнерите (OCI — Open Container Initiative) и разделянето на Docker на containerd и runC, се развива алтернатива на Docker за стартиране в Kubernetes: CRI-O. В това отношение Podman е алтернатива на Docker, построена по принципите на Kubernetes, включително и по групирането на контейнери, но основната цел на проекта е да стартира контейнери в стил Docker без допълнителни услуги. Поради очевидни причини няма наличие на swarm mode, тъй като разработчиците ясно казват, че ако е необходим клъстер — вземете Kubernetes.
Инсталиране
За инсталиране в Centos 7 е достатъчно да активирате репозитория Extras, след което да инсталирате всичко с командата:
# yum -y install podmanДруги възможности
Podman може да генерира единици за systemd, решавайки така задачата за стартиране на контейнери след рестартиране на сървъра. Допълнително е заявена коректната работа на systemd като pid 1 в контейнера. За изграждане на контейнери се използва отделен инструмент buildah, има също и странични инструменти — аналози на docker-compose, които генерират включително конфигурационни файлове, съвместими с Kubernetes, така че преминаването от Podman на Kubernetes е улеснено колкото е възможно.
Работа с Podman
Тъй като няма swarm mode (предполага се преминаване на Kubernetes, ако е необходим клъстер) — ще събираме с отделни контейнери.
Инсталираме podman-compose:
# yum -y install python3-pip
# pip3 install podman-composeРезултантният конфигурационен файл за podman малко се различава, така например трябваше да преместим отделна секция volumes директно в секцията със услугите.
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 upРезултат от работата:
# 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_1Нека да видим какво ще генерира за systemd и kubernetes, за това трябва да знаем името или id на пода:
# 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.targetЗа съжаление, освен стартиране на контейнери, генерираният юнит за systemd не прави нищо друго (например, не почиства стари контейнери при рестартиране на такава услуга), така че тези неща ще трябва да се добавят ръчно.
По принцип, Podman е достатъчен, за да опитате какво представляват контейнерите, да пренесете стари конфигурации за docker-compose, след което да преминете към Kubernetes, ако е необходимо на клъстър, или да получите по-проста за работа алтернатива на Docker.
rkt
Проект приблизително преди половин година, тъй като беше купен от RedHat, затова няма да спирам на него в детайли. Като цяло, той оставяше доста добро впечатление, но в сравнение с Docker и особено с Podman изглеждаше като комбайн. Съществуваше също дистрибутив CoreOS, построен на основата на rkt (въпреки че първоначално имаха Docker), но и поддръжката му приключи след покупката от RedHat.
Plash
Още , авторът на който просто е искал да събира и стартира контейнери. Судя по документацията и кода — авторът не е следвал стандартите, а просто е решил да напише своя реализация, което в принципе и е направил.
Изводи
Ситуацията с наличието на Kubernetes е достатъчно интересна: от една страна, с Docker може да се събере клъстър (в режим swarm), с който дори може да се стартират продуктивни среди за клиенти, това е особено актуално за малки екипи (3-5 души), или при малко общо натоварване, или при липса на желание да се разбира в сложностите на настройката на Kubernetes, включително и за високи натоварвания.
Podman не осигурява пълна съвместимост, но има едно важно предимство — съвместимост с Kubernetes, включително и с допълнителни инструменти (buildah и други). Затова ще подхождам към избора на инструмент за работа така: за малки екипи или при ограничен бюджет — Docker (с възможен swarm mode), за разработка на личен localhost — Podman с приятели, а за останалите — Kubernetes.
Не съм сигурен, че ситуацията с Docker няма да се промени в бъдеще, те все пак са пионери и постепенно се стандартизират, но бъдещето на Podman, при всичките му недостатъци (работи само на Linux, няма клъстеризация, компилиране и други действия — чрез трети страни), е по-ясно, затова каня всички желаещи да обсъдят тези изводи в коментарите.
P.S. На 3 август стартираме „“, където може да научите повече за работата му. Ще разгледаме всичките му инструменти: от основните абстракции до параметрите на мрежата, нюансите на работа с различни ОС и програмни езици. Ще се запознаете с технологията и ще разберете къде и как най-добре да използвате Docker. Ще споделим също кейсове с best practice.
Цената на предварителната поръчка до излизането: 5000 р. С програмата „Видеокурс по Docker“ можете да се запознаете .
Източник: habr.com
