Docker un visi, visi, visi

TL;DR: salīdzinoša raksta ceļvedis par lietojumprogrammu izpildes vidi konteineros. Tiks apskatītas Docker un citu līdzīgu sistēmu iespējas.

Docker un visi, visi, visi

Mazliet vēstures, no kurienes viss radies

Vēsture

Pirmais vispārzināmais veids, kā izolēt lietojumprogrammu, ir chroot. Viena no sistēmas izsaukuma funkcijām nodrošina saknes mapes maiņu, līdz ar to dodot programmatūrai, kas to izsauc, piekļuvi tikai failiem šajā mapē. Taču, ja programmā iekšienē piešķir superlietotāja tiesības, potenciāli tā var "izbēgt" no chroot un iegūt piekļuvi pamatsistēmai. Turklāt, mainot saknes mapi, nav ierobežoti citi resursi (operatīvā atmiņa, procesors), kā arī piekļuve tīklam.

Nākamais veids ir pilnvērtīgas operētājsistēmas palaišana konteinerā, pateicoties operētājsistēmas kodola mehānismiem. Atšķirīgās operētājsistēmās šo metodi sauc dažādi, bet būtība ir viena un tā pati — vairāku neatkarīgu operētājsistēmu palaišana, kuras katra darbojas ar to pašu kodolu, uz kura darbojas arī pamatsistēma. Šajā kategorijā ietilpst FreeBSD Jails, Solaris Zones, OpenVZ un LXC Linux. Tiek nodrošināta izolācija ne tikai diska vietā, bet arī citiem resursiem, jo īpaši katram konteineram var būt ierobežojumi procesora laikā, operatīvajā atmiņā, tīkla joslas platumā. Salīdzinājumā ar chroot, izeja no konteinera ir grūtāka, jo superlietotājs konteinerā ir piekļuves tikai konteineram, taču, ņemot vērā nepieciešamību uzturēt operētājsistēmu konteinerā aktuālā stāvoklī un izmantot vecākas kodola versijas (aktualitāte Linux, mazāk FreeBSD), pastāv riskantā iespēja "izlauzties" cauri kodola izolācijas sistēmai un iegūt piekļuvi pamatsistēmai.

Sistēmas palaišanas vietā pilnvērtīgā operētājsistēmā konteinerā (ar inicializācijas sistēmu, pakotņu pārvaldnieku utt.) var nekavējoties palaist lietojumprogrammas; galvenais ir nodrošināt lietojumprogrammām šādas iespējas (nepieciešamo bibliotēku un citu failu klātbūtni). Šī ideja kalpoja par pamatu lietojumprogrammu konteinerizācijas virtualizācijai, visizteiksmīgākais un vispazīstamākais pārstāvis kurai ir Docker. Salīdzinājumā ar iepriekšējām sistēmām elastīgāki izolācijas mehānismi kopā ar iebūvētu atbalstu virtuālajām tīklām starp konteineriem un lietojumprogrammu stāvokļa uzraudzību konteinerā deva iespēju izveidot vienotu vidi no daudziem fiziskiem serveriem konteineru palaišanai — bez nepieciešamības manuāli pārvaldīt resursus.

Docker

Docker ir visvairāk pazīstamā programmatūra lietojumprogrammu konteinerizācijai. Tā ir uzrakstīta Go valodā, izmanto Linux kodola dabiskās iespējas — cgroups, namespaces, capabilities utt., kā arī failu sistēmas Aufs un citas līdzīgas, lai ekonomētu diska vietu.

Docker un visi, visi, visi
Avots: wikimedia

Arhitektūra

Līdz versijai 1.11 Docker darbojās kā vienots pakalpojums, kas veica visas operācijas ar konteineriem: attēlu lejupielāde konteineriem, konteineru palaišana, API pieprasījumu apstrāde. Sākot ar versiju 1.11 Docker tika sadalīts vairākās daļās, kas savstarpēji mijiedarbojas: containerd, kas apstrādā visu konteineru dzīves ciklu (disku vietas piešķiršana, attēlu lejupielāde, tīkla darbība, palaišana, uzstādīšana un konteineru stāvokļa uzraudzība) un runC, konteineru izpildes vide, kas balstīta uz cgroups izmantošanu un citām Linux kodola iespējām. Pašreizējais docker pakalpojums palika, taču tagad tas kalpo tikai API pieprasījumu apstrādei, ko translē uz containerd.

Docker un visi, visi, visi

Uzstādīšana un konfigurācija

Mans iecienītākais veids, kā instalēt docker, ir docker-machine, kas, izņemot tiešu docker instalēšanu un iestatīšanu attālinātiem serveriem (ieskaitot dažādas mākoņu platformas), ļauj strādāt ar attālināto serveru failu sistēmām un arī var izpildīt dažādas komandas.

Tomēr kopš 2018. gada projekts praktiski neattīstās, tāpēc instalāciju veiksim, izmantojot standarta metodi, kas ir izplatīta lielākajā daļā Linux distribūciju — pievienojot repozitoriju un instalējot nepieciešamās paketes.

Šī metode tiek izmantota arī automatizētā uzstādē, piemēram, izmantojot Ansible vai citus līdzīgus rīkus, taču šajā rakstā es to neapskatīšu.

Uzstādīšana tiks veikta uz Centos 7, kā serveri es izmantos virtuālo mašīnu. Lai veiktu uzstādīšanu, pietiek izpildīt zemāk norādītās komandas:

# 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

Pēc uzstādīšanas nepieciešams palaist pakalpojumu un pievienot to automātiskajā ielādē:

# systemctl enable docker
# systemctl start docker
# firewall-cmd --zone=public --add-port=2377/tcp --permanent

Papildu var izveidot docker grupu, kuras lietotāji varēs strādāt ar docker bez sudo, konfigurēt žurnālu, iespļaut piekļuvi API no ārpuses, un neaizmirsti precīzāk konfigurēt ugunsmūri (visa piekļuve ir aizliegta, ja nav atļauta, piemēros augstāk un zemāk - es to izlēmu atstāt vienkāršības un skaidrības dēļ), taču par to es šeit vairāk neapstāšos.

Citas iespējas

Papildus iepriekš minētajai docker machine ir arī docker registry, līdzeklis attēlu uzglabāšanai konteineriem, kā arī docker compose — līdzeklis, lai automatizētu lietojumprogrammu izvietošanu konteineros. Tika izmantoti YAML faili, lai veidotu un konfigurētu konteinerus un citas saistītās lietas (piemēram, tīkli, pastāvīgas failu sistēmas datu glabāšanai).

Arī ar tā palīdzību iespējams organizēt CICD cauruļvadus. Vēl viena interesanta iespēja ir darbība klastera režīmā, saucamā swarm mode (līdz 1.12 versijai pazīstams kā docker swarm), kas ļauj izveidot no vairākiem serveriem vienotu infrastruktūru konteineru palaišanai. Ir virtuālās tīkla atbalsts visiem serveriem, kā arī iebūvēts slodzes līdzsvarotājs un atbalsts slepeniem datiem konteineriem.

Docker compose YAML faili ar nelielām izmaiņām var tikt izmantoti šādiem klasteriem, pilnībā automatizējot mazo un vidējo klasteru apkalpošanu dažādiem mērķiem. Lieliem klasteriem priekšroka dodama Kubernetes, jo uzturēšanas izmaksas swarm mode var pārsniegt Kubernetes izmaksas. Papildus runC kā konteineru izpildes vidi var uzstādīt piemēram Kata containers

Darbs ar Docker

Pēc uzstādīšanas un konfigurēšanas izmēģināsim izveidot klasteri, kurā uzstādīsim GitLab un Docker Registry izstrādātāju komandai. Kā serverus es izmantošu trīs virtuālās mašīnas, uz kurām papildus uzstādīšu izplatīto failu sistēmu GlusterFS, ko izmantosim kā docker volumes krātuvi, piemēram, lai palaistu augstas pieejamības versiju docker registry. Galvenās sastāvdaļas palaišanai: Docker Registry, Postgresql, Redis, GitLab ar GitLab Runner atbalstu virs Swarm. Postgresql mēs palaidīsim ar klasterizāciju. Stolon, tāpēc Postgresql datu glabāšanai nav nepieciešams izmantot GlusterFS. Pārējie kritiskie dati tiks glabāti uz GlusterFS.

Lai uzstādītu GlusterFS visos serveros (tie tiek dēvēti par node1, node2, node3), nepieciešams uzstādīt pakotnes, atļaut ugunsmūra darbību, izveidot nepieciešamās direktorijas:

# 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

Pēc uzstādīšanas darbs ar GlusterFS konfigurēšanu jāturpina no viena mezgla, piemēram, 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

Pēc tam jānokopē iegūtais volume (komanda jāizpilda visos serveros):

# mount /srv/docker

Swarm mode konfigurēšana tiek veikta vienā no serveriem, kas būs līderis, pārējiem jāpieņem klasteris, tāpēc komandas izpildes rezultātu pirmajā serverī jākopē un jāizpilda pārējiem.

Sākotnējā klastera konfigurācija, komandu izpildīšu uz 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

Kopējam otrās komandas rezultātu, izpildām uz node2 un node3:

# docker swarm join --token SWMTKN-x-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx-xxxxxxxxx xx.xx.xx.xx:2377
This node joined a swarm as a manager.

Uz to šo serveru priekšizvēlēšanās ir pabeigta, uzsākam pakalpojumu konfigurēšanu, komandas tiks izpildītas no node1, ja nav norādīts citādi.

Vispirms izveidosim tīklus konteineriem:

# 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

Pēc tam marķējam serverus, tas ir nepieciešams, lai piesaistītu dažus pakalpojumus serveriem:

# docker node update --label-add nodename=node1 node1
# docker node update --label-add nodename=node2 node2
# docker node update --label-add nodename=node3 node3

Tālāk izveidojam direktorijas datu glabāšanai etcd, KV glabātavai, kas nepieciešama Traefik un Stolon. Līdzīgi kā Postgresql, tas būs piesaistīts serveriem konteineriem, tāpēc šo komandu izpildām visos serveros:

# mkdir -p /srv/etcd

Tālāk izveidojam failu etcd konfigurēšanai un to piemērojam:

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 etcd

Pēc kāda laika pārbaudām, vai etcd klasteris ir uzcelts:

# 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

Izveidojam direktorijus PostgreSQL, komandu izpildām visos serveros:

# mkdir -p /srv/pgsql

Tālāk izveidojam failu PostgreSQL iestatīšanai:

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: true

Ģenerējam noslēpumus, izmantojam failu:

# </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

Pēc kāda laika (pārbaudām komandas izpildi docker service ls, kas augšupceļ visus servisus) inicializējam Postgresql klasteri:

# 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

Pārbaudām Postgresql klastera gatavību:

# 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

Konfigurējam traefik, lai atvērtu piekļuvi konteineriem no ārpuses:

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

Palaižam Redis klasteri, tam visos mezglos izveidojam glabāšanas katalogu:

# mkdir -p /srv/redis

05redis.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

Pievienojam Docker reģistru:

06registry.yml

versija: '3.7'

pakalpojumi:
  reģistrs:
    attēls: registry:2.6
    tīkli:
      - traefik
    apjomi:
      - registry_data: /var/lib/registry
    izvietošana:
      replika: 1
      izvietojums:
        ierobežojumi: [node.role == manager]
      atkārtotas palaišanas politika:
        nosacījums: on-failure
      etiķetes:
        - traefik.enable=true
        - traefik.http.routers.registry.rule=Host(`registry.example.com`)
        - traefik.http.services.registry.loadbalancer.server.port=5000
        - traefik.docker.network=traefik

apjomi:
  registry_data:
    vadītājs: local
    vadītāja opcijas:
      tips: none
      o: bind
      ierīce: "/srv/docker/registry"

tīkli:
  traefik:
    ārējais: true

# mkdir /srv/docker/registry
# docker stack deploy --compose-file 06registry.yml registry

Un visbeidzot — GitLab:

08gitlab-runner.yml

versija: '3.7'

pakalpojumi:
  gitlab:
    attēls: gitlab/gitlab-ce:latest
    tīkli:
      - pgsql
      - redis
      - traefik
      - gitlab
    porti:
      - 22222:22
    vide:
      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
    apjomi:
      - gitlab_conf:/etc/gitlab
      - gitlab_logs:/var/log/gitlab
      - gitlab_data:/var/opt/gitlab
    izvietošana:
      režīms: replika
      replika: 1
      izvietojums:
        ierobežojumi:
        - node.role == manager
      etiķetes:
        - 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:
    attēls: gitlab/gitlab-runner:latest
    tīkli:
      - gitlab
    apjomi:
      - gitlab_runner_conf:/etc/gitlab
      - /var/run/docker.sock:/var/run/docker.sock
    izvietošana:
      režīms: replika
      replika: 1
      izvietojums:
        ierobežojumi:
        - node.role == manager

apjomi:
  gitlab_conf:
    vadītājs: local
    vadītāja opcijas:
      tips: none
      o: bind
      ierīce: "/srv/docker/gitlab/conf"
  gitlab_logs:
    vadītājs: local
    vadītāja opcijas:
      tips: none
      o: bind
      ierīce: "/srv/docker/gitlab/logs"
  gitlab_data:
    vadītājs: local
    vadītāja opcijas:
      tips: none
      o: bind
      ierīce: "/srv/docker/gitlab/data"
  gitlab_runner_conf:
    vadītājs: local
    vadītāja opcijas:
      tips: none
      o: bind
      ierīce: "/srv/docker/gitlab/runner"

tīkli:
  pgsql:
    ārējais: true
  redis:
    ārējais: true
  traefik:
    ārējais: true
  gitlab:
    ārējais: 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

Beigu stāvoklis klasterim un pakalpojumiem:

# 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

Ko vēl var uzlabot? Noteikti ir jāiestata Traefik darbu konteineriem pa https, jāpapildina ar tls šifrēšanu Postgresql un Redis. Bet kopumā jau var nodot izstrādātājiem kā PoC. Apskatīsim tagad alternatīvas Docker.

Podman

Vēl viens pietiekami pazīstams engine konteineru palaišanai, kas grupēti podos (pods, grupas konteineru, kas izvērsti kopā). Atšķirībā no Docker, tas neprasa nekādu servisu konteineru palaišanai, visa darbība notiek caur bibliotēku libpod. Tāpat tas ir uzrakstīts Go valodā un prasa OCI saderīgu runtime konteineru palaišanai, piemēram, runC.

Docker un visi, visi, visi

Darbs ar Podman kopumā līdzinās darbam ar Docker, pat līdz tam, ka var izdarīt šādi (daudzu izmēģinātāju, arī šī raksta autora, apgalvojumos):

$ alias docker=podman

un var turpināt strādāt. Kopumā situācija ar Podman ir ļoti interesanta, jo, ja agrākās Kubernetes versijas darbojās ar Docker, tad aptuveni no 2015. gada, pēc konteineru pasaules standartizācijas (OCI — Open Container Initiative) un Docker sadalīšanas uz containerd un runC, attīstās Docker alternatīva Kubernetes palaišanai: CRI-O. Podman šajā ziņā ir Docker alternatīva, kas būvēta uz Kubernetes principiem, tostarp arī konteineru grupēšanas, bet galvenā projekta eksistēšanas mērķis ir konteineru palaišana Docker stilā bez papildu servisiem. Saprotamu iemeslu dēļ nav pieejama swarm mode, jo izstrādātāji skaidri norāda, ka ja nepieciešams klasteris — jāņem Kubernetes.

Uzstādīšana

Lai instalētu Centos 7, pietiek aktivizēt Extras repozitoriju, pēc tam instalējiet ar komandu:

# yum -y install podman

Citas iespējas

Podman var ģenerēt unit failus systemd, tādējādi risinot konteineru palaišanas uzdevumu pēc servera restartēšanas. Papildus ir norādīta pareiza systemd darbība kā pid 1 konteinerā. Kodešanai konteineriem ir atsevišķs instruments buildah, ir arī trešo pušu rīki — analoģiski docker-compose, kas ģenerē konfigurācijas failus, kas ir saderīgi ar Kubernetes, tādējādi pāreja no Podman uz Kubernetes ir atvieglota cik vien iespējams.

Darbs ar Podman

Tā kā nav swarm mode (tiek paredzēta pāreja uz Kubernetes, ja nepieciešams klasteris) — veidosim atsevišķus konteinerus.

Uzstādam podman-compose:

# yum -y install python3-pip
# pip3 install podman-compose

Rezultātā iegūtais konfigurācijas fails podman nedaudz atšķiras, piemēram, bija nepieciešams pārvietot atsevišķu volumes sadaļu tieši uz servisu sadaļu.

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

Izpildes rezultāts:

# 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

Apskatīsim, ko tas ģenerēs systemd un kubernetes, tam vajadzētu uzzināt poda vārdu vai ID:

# podman pod ls
POD ID         NAME   STATUS    CREATED          # OF CONTAINERS   INFRA ID
71fc2b2a5c63   root   Running   11 minutes ago   3                 db40ab8bf84b

Kubernetes:

# 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

Diemžēl, izņemot konteineru palaišanu, ģenerētais vienums systemd neizpilda nekādas citas darbības (piemēram, veco konteineru tīrīšanu šāda pakalpojuma restartēšanas gadījumā), tāpēc šādas lietas būs jāpapildina pašam.

Principā, Podman ir pietiekams, lai izmēģinātu, kas ir konteineri, pārvietotu vecās konfigurācijas uz docker-compose, pēc tam pārietu uz Kubernetes, ja nepieciešams, uz klasteri, vai iegūtu vienkāršāku alternatīvu Docker.

rkt

Projekts ir arhīvā apmēram pirms sešiem mēnešiem, jo to iegādājās RedHat, tāpēc es neapstāsosies pie tā sīkāk. Kopumā tam bija diezgan laba iespaida, tomēr salīdzinājumā ar Docker un it īpaši ar Podman tas izskatās kā kombains. Pastāvēja arī CoreOS izplatījums, kas tika veidots uz rkt pamata (kaut gan sākotnēji viņiem bija Docker), tomēr tā atbalsts arī beidzās pēc RedHat iegādes.

Plash

Vairāk ir viens projekts, kura autors vienkārši vēlējās savākt un palaižu konteinerus. Spriežot pēc dokumentācijas un koda — autors nesekoja standartiem, bet vienkārši nolēma uzrakstīt savu implementāciju, ko viņš faktiski arī izdarīja.

Secinājumi

Situācija, ja ir Kubernetes, izveidojas ļoti interesanta: no vienas puses, ar Docker var izveidot klasteri (swarm režīmā), ar kuru pat var palaist produktu vidi klientiem, tas ir īpaši aktuāli mazām komandām (3-5 cilvēki), vai arī pie nelielas kopējās slodzes, vai arī trūkstošas vēlmes saprast Kubernetes iestatīšanas nianses, tostarp augstām slodzēm.

Podman nodrošina pilnīgu saderību, bet tam ir viens svarīgs ieguvums — saderība ar Kubernetes, tostarp arī papildus rīkiem (buildah un citi). Tādēļ rīka izvēlē es pieeju šādi: maziem komandām vai ierobežota budžeta gadījumā — Docker (ar iespēju izmantot swarm režīmu), personīgai attīstībai uz localhost — Podman ar kolēģiem, bet visiem pārējiem — Kubernetes.

Es neesmu pārliecināts, ka situācija ar Docker nākotnē nemainīsies, noteikti viņi ir pionieri un, soli pa solim, tiek standartizēti, bet Podman ar visiem tā trūkumiem (darbojas tikai uz Linux, nav klasterizācijas, būvēšana un citi procesi — ar trešo pušu risinājumiem) nākotne ir skaidrāka, tāpēc aicinu visus, kuri vēlas, apspriest šos secinājumus komentāros.

P.S. 3. augustā uzsākam “Video kurss par Docker”, kur varēsiet uzzināt vairāk par tā darbību. Mēs izskatīsim visus tā rīkus: no pamata abstrakcijām līdz tīkla iestatījumiem, dažādu OS un programmēšanas valodu darbības niansēm. Jūs iepazīsities ar tehnoloģiju un sapratīsiet, kur un kā vislabāk izmantot Docker. Tāpat dalīsimies ar labākajām praksēm.

Iegādes cena pirms relīzes: 5000 RUD. Ar “Docker video kursa” programmu var iepazīties kursu lapā.

Avots: habr.com

Iegādājieties uzticamu tīmekļa hostingu ar DDoS aizsardzību, VPS VDS serveriem 🔥 Iegādājieties uzticamu tīmekļa hostingu ar DDoS aizsardzību, VPS VDS serveriem | ProHoster