Docker och allt, allt, allt

TL;DR: En översiktsguide för att jämföra ramverk för att köra applikationer i behållare. Förmågan hos Docker och andra liknande system kommer att övervägas.

En liten historia om var allt kom ifrån

Story

Den första välkända metoden för att isolera en applikation är chroot. Systemanropet med samma namn säkerställer att rotkatalogen ändras - vilket säkerställer att programmet som anropade den endast har tillgång till filer i den katalogen. Men om ett program ges root-privilegier internt, kan det potentiellt "rymma" chroot och få tillgång till huvudoperativsystemet. Förutom att ändra rotkatalogen är andra resurser (RAM, processor), såväl som nätverksåtkomst, inte begränsade.

Nästa metod är att köra ett fullfjädrat operativsystem inuti en container, med hjälp av operativsystemets kärnmekanismer. Denna metod har olika namn i olika operativsystem, men kärnan är densamma: att köra flera oberoende operativsystem, där vart och ett kör samma kärna som huvudoperativsystemet. Detta inkluderar FreeBSD Jails, Solaris Zones, OpenVZ och LXC för... LinuxIsolering sker inte bara av diskutrymme, utan även av andra resurser; i synnerhet kan varje container ha begränsningar för CPU-tid, RAM och nätverksbandbredd. Jämfört med chroot är det svårare att avsluta en container, eftersom superanvändaren i containern endast har åtkomst till containerns interna komponenter. Men på grund av behovet av att hålla operativsystemet inuti containern uppdaterat och användningen av äldre kärnversioner (relevant för Linux, i mindre utsträckning FreeBSD) finns det en sannolikhet som inte är noll att "bryta igenom" kärnans isoleringssystem och få tillgång till det huvudsakliga operativsystemet.

Istället för att starta ett fullfjädrat operativsystem i en behållare (med ett initieringssystem, pakethanterare, etc.), kan du starta applikationer omedelbart, det viktigaste är att ge applikationerna en sådan möjlighet (närvaron av nödvändiga bibliotek och andra filer). Denna idé fungerade som grunden för containeriserad applikationsvirtualisering, vars mest framstående och välkända representant är Docker. Jämfört med tidigare system har mer flexibla isoleringsmekanismer, i kombination med inbyggt stöd för virtuella nätverk mellan behållare och applikationstillståndsspårning inom behållaren, resulterat i möjligheten att bygga en enda sammanhängande miljö från ett stort antal fysiska servrar för att köra behållare - utan behov av manuell resurshantering.

Hamnarbetare

Docker är den mest välkända programvaran för applikationscontainrarisering. Den är skriven i Go-språket och använder inbyggda kärnfunktioner. Linux — cgroups, namnrymder, funktioner etc., såväl som Aufs-filsystem och andra liknande för att spara diskutrymme.

Källa: wikimedia

Arkitektur

Före version 1.11 fungerade Docker som en enda tjänst som hanterade alla containeroperationer: nedladdning av containeravbildningar, start av containrar och hantering av API-förfrågningar. Från och med version 1.11 delades Docker upp i flera interagerande delar: containerd, som hanterar hela containerns livscykel (diskallokering, nedladdning av avbildningar, nätverk, start, installation och övervakning av containerstatus), och runC, en containerkörningsmiljö baserad på cgroups och andra kärnfunktioner. LinuxSjälva Docker-tjänsten finns kvar, men nu tjänar den bara till att bearbeta API-förfrågningar som skickas till containerd.

Installation och konfiguration

Mitt favoritsätt att installera docker är docker-machine, som förutom att direkt installera och konfigurera docker på fjärrservrar (inklusive olika moln), gör det möjligt att arbeta med filsystem på fjärrservrar och även kan köra olika kommandon.

Sedan 2018 har dock projektet knappt utvecklats, så vi kommer att installera det med standardmetoden för de flesta distributioner. Linux metod - genom att lägga till ett arkiv och installera nödvändiga paket.

Denna metod används också för automatiserad installation, till exempel med Ansible eller andra liknande system, men jag kommer inte att överväga det i den här artikeln.

Installationen kommer att utföras den Centos 7, Jag kommer att använda en virtuell maskin som server, för installation räcker det att köra kommandona nedan:

# 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

Efter installationen måste du starta tjänsten och sätta den i start:

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

Dessutom kan du skapa en dockargrupp, vars användare kommer att kunna arbeta med docker utan sudo, ställa in loggning, aktivera åtkomst till API från utsidan och glöm inte att konfigurera brandväggen mer exakt (allt som inte är tillåtet är förbjudet i exemplen ovan och nedan - jag har utelämnat detta för enkelhetens skull och tydlighetens skull), men jag ska inte gå in mer i detalj här.

Andra funktioner

Utöver den ovan nämnda dockningsmaskinen finns även docker registry, ett verktyg för att lagra bilder för containrar, samt docker compose, ett verktyg för att automatisera distributionen av applikationer i containrar, YAML-filer används för att bygga och konfigurera containrar och andra relaterade saker (till exempel nätverk, beständiga filsystem för lagring av data).

Den kan också användas för att organisera transportband för CICD. En annan intressant funktion är att arbeta i klusterläge, det så kallade svärmläget (före version 1.12 var det känt som docker swarm), som låter dig montera en enda infrastruktur från flera servrar för att köra containrar. Det finns stöd för ett virtuellt nätverk ovanpå alla servrar, det finns en inbyggd lastbalanserare, samt stöd för hemligheter för containrar.

YAML-filer från docker compose, med mindre ändringar, kan användas för sådana kluster, vilket helt automatiserar underhållet av små och medelstora kluster för olika ändamål. För stora kluster är Kubernetes att föredra eftersom underhållskostnaderna för svärmläge kan överstiga Kubernetes. Förutom runC kan du till exempel installera som containerexekveringsmiljön Kata behållare

Jobbar med Docker

Efter installation och konfiguration kommer vi att försöka sätta ihop ett kluster där vi kommer att distribuera GitLab och Docker Registry för utvecklingsteamet. Jag kommer att använda tre virtuella maskiner som servrar, på vilka jag dessutom kommer att distribuera den distribuerade FS GlusterFS; Jag kommer att använda den som en docker-volymlagring, till exempel för att köra en feltolerant version av docker-registret. Nyckelkomponenter att köra: Docker Registry, Postgresql, Redis, GitLab med stöd för GitLab Runner ovanpå Swarm. Vi kommer att lansera Postgresql med klustring Stolon, så du behöver inte använda GlusterFS för att lagra Postgresql-data. Återstående kritiska data kommer att lagras på GlusterFS.

För att distribuera GlusterFS på alla servrar (de kallas node1, node2, node3), måste du installera paket, aktivera brandväggen och skapa de nödvändiga katalogerna:

# 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

Efter installationen måste arbetet med att konfigurera GlusterFS fortsätta från en nod, till exempel nod1:

# 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

Sedan måste du montera den resulterande volymen (kommandot måste köras på alla servrar):

# mount /srv/docker

Svärmläget är konfigurerat på en av servrarna, som kommer att vara ledaren, resten måste gå med i klustret, så resultatet av att utföra kommandot på den första servern måste kopieras och köras på de andra.

Initial klusterinstallation, jag kör kommandot på nod1:

# 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

Vi kopierar resultatet av det andra kommandot och kör det på nod2 och nod3:

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

Vid denna tidpunkt är den preliminära konfigurationen av servrarna klar, låt oss fortsätta med att ställa in tjänsterna; kommandona som ska köras kommer att startas från nod1, om inte annat anges.

Först och främst, låt oss skapa nätverk för behållare:

# 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

Sedan markerar vi servrarna, detta är nödvändigt för att binda vissa tjänster till servrarna:

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

Därefter skapar vi kataloger för lagring av etcd-data, KV-lagring, som behövs för Traefik och Stolon. I likhet med Postgresql kommer dessa att vara behållare knutna till servrar, så vi kör det här kommandot på alla servrar:

# mkdir -p /srv/etcd

Skapa sedan en fil för att konfigurera etcd och använd den:

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

Efter en tid kontrollerar vi att etcd-klustret är uppe:

# 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

Vi skapar kataloger för Postgresql, kör kommandot på alla servrar:

# mkdir -p /srv/pgsql

Skapa sedan en fil för att konfigurera 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: true

Vi genererar hemligheter och använder filen:

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

Efter en tid (se resultatet av kommandot hamnartjänst lsatt alla tjänster är uppe) initierar vi Postgresql-klustret:

# 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

Kontrollera beredskapen för Postgresql-klustret:

# 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

Vi konfigurerar traefik för att öppna åtkomst till containrar från utsidan:

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

Vi lanserar Redis Cluster, för att göra detta skapar vi en lagringskatalog på alla noder:

# 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 <<EOF > /opt/bitnami/redis/etc/sentinel.conf
      port 16379
      dir /tmp
      sentinel monitor master-node redis-master 6379 2
      sentinel down-after-milliseconds master-node 5000
      sentinel parallel-syncs master-node 1
      sentinel failover-timeout master-node 5000
      sentinel auth-pass master-node xxxxxxxxxxx
      sentinel announce-ip redis-sentinel
      sentinel announce-port 16379
      EOF"
      "/bin/bash" -c "redis-sentinel /opt/bitnami/redis/etc/sentinel.conf"
      EOF'
    deploy:
      mode: global
      restart_policy:
        condition: any

volumes:
  redis:
    driver: local
    driver_opts:
      type: 'none'
      o: 'bind'
      device: "/srv/redis"

networks:
  redis:
    external: true

# docker stack deploy --compose-file 05redis.yml redis

Lägg till Docker Registry:

06registry.yml

version: '3.7'

services:
  registry:
    image: registry:2.6
    networks:
      - traefik
    volumes:
      - registry_data:/var/lib/registry
    deploy:
      replicas: 1
      placement:
        constraints: [node.role == manager]
      restart_policy:
        condition: on-failure
      labels:
        - traefik.enable=true
        - traefik.http.routers.registry.rule=Host(`registry.example.com`)
        - traefik.http.services.registry.loadbalancer.server.port=5000
        - traefik.docker.network=traefik

volumes:
  registry_data:
    driver: local
    driver_opts:
      type: none
      o: bind
      device: "/srv/docker/registry"

networks:
  traefik:
    external: true

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

Och slutligen - 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

Det slutliga tillståndet för klustret och tjänsterna:

# 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

Vad mer kan förbättras? Se till att konfigurera Traefik för att köra behållare över https, lägg till tls-kryptering för Postgresql och Redis. Men i allmänhet kan det redan ges till utvecklare som en PoC. Låt oss nu titta på alternativ till Docker.

poddman

En annan ganska välkänd motor för att köra containrar grupperade efter pods (pods, grupper av containrar utplacerade tillsammans). Till skillnad från Docker kräver det ingen tjänst för att köra behållare; allt arbete görs genom libpod-biblioteket. Även skrivet i Go, kräver en OCI-kompatibel körtid för att köra behållare, som runC.

Att arbeta med Podman påminner i allmänhet om det för Docker, till den grad att du kan göra det så här (som sagt av många som har provat det, inklusive författaren till den här artikeln):

$ alias docker=podman

och du kan fortsätta arbeta. I allmänhet är situationen med Podman mycket intressant, för om tidiga versioner av Kubernetes fungerade med Docker, så runt 2015, efter standardiseringen av containervärlden (OCI - Open Container Initiative) och uppdelningen av Docker i containerd och runC, ett alternativ till Docker för körning i Kubernetes har utvecklats: CRI-O. Podman i detta avseende är ett alternativ till Docker, byggt på principerna för Kubernetes, inklusive gruppering av containrar, men huvudsyftet med projektet är att lansera Docker-liknande containrar utan ytterligare tjänster. Av uppenbara skäl finns det inget svärmläge, eftersom utvecklarna tydligt säger att om du behöver ett kluster, ta Kubernetes.

Installation

För installation i Centos 7, aktivera bara Extras-förrådet och installera sedan allt med kommandot:

# yum -y install podman

Andra funktioner

Podman kan generera enheter för systemd och därmed lösa problemet med att starta behållare efter en omstart av servern. Dessutom deklareras systemd att fungera korrekt som pid 1 i behållaren. Det finns ett separat buildah-verktyg för att bygga containrar, det finns också tredjepartsverktyg - analoger till docker-compose, som också genererar konfigurationsfiler som är kompatibla med Kubernetes, så övergången från Podman till Kubernetes förenklas så mycket som möjligt.

Jobbar med Podman

Eftersom det inte finns något svärmläge (vi ska byta till Kubernetes om ett kluster behövs) samlar vi det i separata behållare.

Installera podman-compose:

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

Den resulterande konfigurationsfilen för podman är något annorlunda, så till exempel var vi tvungna att flytta en separat volymsektion direkt till sektionen med tjänster.

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

Resultat:

# 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

Låt oss se vad det genererar för systemd och kubernetes, för detta måste vi ta reda på poddens namn eller 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

Tyvärr, förutom att starta behållare, gör den genererade enheten för systemd inget annat (t.ex. städar upp gamla behållare när en sådan tjänst startas om), så du måste skriva sådana saker själv.

I princip räcker det med Podman för att prova vad containrar är, överföra gamla konfigurationer för docker-compose och sedan gå mot Kubernetes, om du behöver ett kluster, eller skaffa ett mer lättanvänt alternativ till Docker.

RKT

Projekt gick in i arkivet för ungefär sex månader sedan på grund av att RedHat köpte den, så jag kommer inte att uppehålla mig mer i detalj. Sammantaget lämnade den ett mycket gott intryck, men jämfört med Docker och speciellt Podman ser det ut som en skördetröska. Det fanns också en CoreOS-distribution byggd ovanpå rkt (även om de ursprungligen hade Docker), men även detta slutade i support efter RedHat-köpet.

Plask

annan ett projekt, vars författare bara ville bygga och driva containrar. Att döma av dokumentationen och koden följde författaren inte standarderna, utan bestämde sig helt enkelt för att skriva sin egen implementering, vilket han i princip gjorde.

Resultat

Situationen med Kubernetes är mycket intressant: å ena sidan, med Docker kan du bygga ett kluster (i svärmläge), med vilket du till och med kan köra produktmiljöer för kunder, detta gäller särskilt för små team (3-5 personer) , eller med en liten total belastning, eller brist på lust att förstå krångligheterna med att ställa in Kubernetes, inklusive för höga belastningar.

Podman ger inte full kompatibilitet, men det har en viktig fördel - kompatibilitet med Kubernetes, inklusive ytterligare verktyg (buildah och andra). Därför kommer jag att närma mig valet av ett verktyg för arbete enligt följande: för små team, eller med en begränsad budget - Docker (med ett möjligt svärmläge), för att utveckla för mig själv på en personlig lokal värd - Podman-kamrater och för alla andra - Kubernetes.

Jag är inte säker på att situationen med Docker inte kommer att förändras i framtiden, de är trots allt pionjärer, och steg för steg standardiseras de gradvis, men Podman, trots alla sina brister (arbetar bara på Linux, ingen klustring, montering och andra åtgärder utförs av tredjepartslösningar) är framtiden tydligare, så jag uppmanar alla att diskutera dessa resultat i kommentarerna.

PS Den 3 augusti lanserar vi "Docker videokurs", där du kan lära dig mer om hans arbete. Vi kommer att analysera alla dess verktyg: från grundläggande abstraktioner till nätverksparametrar, nyanser av att arbeta med olika operativsystem och programmeringsspråk. Du kommer att bli bekant med tekniken och förstå var och hur du bäst använder Docker. Vi kommer också att dela bästa praxis.

Förbeställningspris före release: 5000 XNUMX RUB. Du kan se Docker Video Course-programmet på kurssidan.

Källa: will.com