Docker og alle, alle, alle

TL;DR: En oversiktsartikkel - en guide til å sammenligne miljøer for å kjøre applikasjoner i containere. Mulighetene til Docker og andre lignende systemer vil bli vurdert.

Docker og alle, alle, alle

En liten historie om hvor alt kom fra

Story

Den første velkjente måten å isolere en applikasjon på er chroot. Systemkallet med samme navn gir en endring til rotkatalogen - og gir dermed tilgang til programmet som kalte den, tilgang kun til filer i denne katalogen. Men hvis programmet får superbrukerrettigheter inne, kan det potensielt "rømme" fra chroot og få tilgang til hovedoperativsystemet. Dessuten, i tillegg til å endre rotkatalogen, er andre ressurser (RAM, prosessor), samt tilgang til nettverket, ikke begrenset.

Den neste måten er å starte et fullverdig operativsystem inne i beholderen, ved å bruke mekanismene til operativsystemkjernen. Denne metoden kalles forskjellig i forskjellige operativsystemer, men essensen er den samme - kjører flere uavhengige operativsystemer, som hver kjører på samme kjerne som kjører hovedoperativsystemet. Dette inkluderer FreeBSD Jails, Solaris Zones, OpenVZ og LXC for Linux. Isolering er gitt ikke bare for diskplass, men også for andre ressurser, spesielt kan hver container ha begrensninger på prosessortid, RAM, nettverksbåndbredde. Sammenlignet med chroot er det vanskeligere å forlate beholderen, siden superbrukeren i beholderen kun har tilgang til innsiden av beholderen, men på grunn av behovet for å holde operativsystemet inne i beholderen oppdatert og bruken av gammel kjerne versjoner (relevant for Linux, i mindre grad FreeBSD), er det en ikke-null sannsynlighet for å bryte gjennom kjerneisolasjonssystemet og få tilgang til hovedoperativsystemet.

I stedet for å starte et fullverdig operativsystem i en beholder (med et initialiseringssystem, en pakkebehandling, etc.), kan applikasjoner startes umiddelbart, det viktigste er å gi applikasjoner denne muligheten (tilstedeværelsen av nødvendige biblioteker og andre filer). Denne ideen fungerte som grunnlaget for containerisert applikasjonsvirtualisering, hvor den mest fremtredende og kjente representanten er Docker. Sammenlignet med tidligere systemer, resulterte mer fleksible isolasjonsmekanismer, sammen med innebygd støtte for virtuelle nettverk mellom containere og applikasjonstilstand inne i en container, i muligheten til å bygge et enkelt helhetlig miljø fra et stort antall fysiske servere for å kjøre containere - uten behovet for manuell ressursstyring.

Docker

Docker er den mest kjente programvaren for applikasjonscontainerisering. Skrevet på Go-språket bruker den de vanlige egenskapene til Linux-kjernen - cgroups, namespaces, capabilities, etc., samt Aufs-filsystemer og andre lignende for å spare diskplass.

Docker og alle, alle, alle
Kilde: wikimedia

arkitektur

Før versjon 1.11 jobbet Docker som en enkelt tjeneste som utførte alle operasjoner med containere: nedlasting av bilder for containere, lansering av containere, behandling av API-forespørsler. Siden versjon 1.11 har Docker blitt delt opp i flere deler som samhandler med hverandre: containerd, for å håndtere hele livssyklusen til containere (allokering av diskplass, nedlasting av bilder, nettverk, lansering, installasjon og overvåking av containernes tilstand) og runC , container kjøretider, basert på bruk av cgroups og andre funksjoner i Linux-kjernen. Selve docker-tjenesten gjenstår, men nå tjener den bare til å behandle API-forespørsler som sendes til containerd.

Docker og alle, alle, alle

Installasjon og konfigurasjon

Min favorittmåte å installere docker på er docker-machine, som i tillegg til å installere og konfigurere docker direkte på eksterne servere (inkludert ulike skyer), lar deg jobbe med filsystemene til eksterne servere, og kan også kjøre ulike kommandoer.

Siden 2018 har imidlertid prosjektet knapt vært utviklet, så vi vil installere det på vanlig måte for de fleste Linux-distribusjoner – ved å legge til et depot og installere de nødvendige pakkene.

Denne metoden brukes også for automatisert installasjon, for eksempel ved bruk av Ansible eller andre lignende systemer, men jeg vil ikke vurdere det i denne artikkelen.

Installasjonen vil bli utført på Centos 7, jeg vil bruke en virtuell maskin som server, for å installere, bare kjør kommandoene nedenfor:

# 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

Etter installasjonen må du starte tjenesten, sette den i autoload:

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

I tillegg kan du opprette en docker-gruppe, hvis brukere vil kunne jobbe med docker uten sudo, sette opp logging, aktivere tilgang til API fra utsiden, ikke glem å finjustere brannmuren (alt som ikke er tillatt er forbudt i eksemplene over og under - jeg har utelatt dette for enkelhets skyld og visualisering), men jeg skal ikke gå mer i detalj her.

Andre funksjoner

I tillegg til ovennevnte docker-maskin er det også et docker-register, et verktøy for lagring av bilder for containere, samt docker compose - et verktøy for å automatisere distribusjon av applikasjoner i containere, YAML-filer brukes til å bygge og konfigurere containere og andre relaterte ting (for eksempel nettverk, vedvarende filsystemer for lagring av data).

Den kan også brukes til å organisere rørledninger for CICD. En annen interessant funksjon er å jobbe i klyngemodus, den såkalte swarm-modusen (før versjon 1.12 var den kjent som docker swarm), som lar deg sette sammen en enkelt infrastruktur fra flere servere for å kjøre containere. Det er støtte for et virtuelt nettverk på toppen av alle servere, det er en innebygd load balancer, samt støtte for hemmeligheter for containere.

YAML-filene fra docker compose kan brukes til slike klynger med mindre modifikasjoner, og fullautomatiserer vedlikeholdet av små og mellomstore klynger for ulike formål. For store klynger er Kubernetes å foretrekke fordi vedlikeholdskostnadene for svermmodus kan oppveie Kubernetes. I tillegg til runC, som et utførelsesmiljø for containere, kan du installere f.eks Kata containere

Jobber med Docker

Etter installasjon og konfigurasjon vil vi prøve å bygge en klynge der vi vil distribuere GitLab og Docker Registry for utviklingsteamet. Som servere vil jeg bruke tre virtuelle maskiner, hvor jeg i tillegg vil distribuere den GlusterFS-distribuerte FS-en, jeg vil bruke den som en docker-volumlagring, for eksempel for å kjøre en feilsikker versjon av docker-registret. Nøkkelkomponenter å kjøre: Docker Registry, Postgresql, Redis, GitLab med støtte for GitLab Runner på toppen av Swarm. Postgresql vil bli lansert med klynging Stolon, så du trenger ikke bruke GlusterFS til å lagre Postgresql-data. Resten av de kritiske dataene vil bli lagret på GlusterFS.

For å distribuere GlusterFS på alle servere (de kalles node1, node2, node3), må du installere pakker, aktivere brannmuren, opprette de nødvendige katalogene:

# 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

Etter installasjonen må arbeidet med å konfigurere GlusterFS fortsette fra én node, for eksempel 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

Deretter må du montere det resulterende volumet (kommandoen må kjøres på alle servere):

# mount /srv/docker

Swarm-modus er konfigurert på en av serverne, som vil være Leader, resten må bli med i klyngen, så resultatet av å kjøre kommandoen på den første serveren må kopieres og utføres på resten.

Innledende klyngeoppsett, jeg kjører kommandoen på 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

Kopier resultatet av den andre kommandoen, kjør på node2 og node3:

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

Dette fullfører den foreløpige konfigurasjonen av serverne, la oss begynne å konfigurere tjenestene, kommandoene som skal utføres vil bli lansert fra node1, med mindre annet er spesifisert.

Først av alt, la oss lage nettverk for containere:

# 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

Så merker vi serverne, dette er nødvendig for å binde noen tjenester til serverne:

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

Deretter lager vi kataloger for lagring av etcd-data, KV-lagringen som Traefik og Stolon trenger. I likhet med Postgresql vil disse være containere bundet til servere, så vi utfører denne kommandoen på alle servere:

# mkdir -p /srv/etcd

Deretter oppretter du en fil for å konfigurere etcd og bruker 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

Etter en stund sjekker vi at etcd-klyngen har steget:

# 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

Opprett kataloger for Postgresql, utfør kommandoen på alle servere:

# mkdir -p /srv/pgsql

Deretter oppretter du en fil for å konfigurere 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 genererer hemmeligheter, bruk 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

En tid senere (se på resultatet av kommandoen docker service lsat alle tjenester har økt) initialiser Postgresql-klyngen:

# 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

Sjekke beredskapen til Postgresql-klyngen:

# 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 konfigurerer traefik for å åpne tilgang til containere fra utsiden:

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 starter Redis Cluster, for dette lager vi en lagringskatalog på alle 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

Legg til 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

Og til slutt - GitLab:

08gitlab-runner.yml

version: '3.7'

services:
  gitlab:
    image: gitlab/gitlab-ce:latest
    networks:
      - pgsql
      - redis
      - traefik
      - gitlab
    ports:
      - 22222:22
    environment:
      GITLAB_OMNIBUS_CONFIG: |
        postgresql['enable'] = false
        redis['enable'] = false
        gitlab_rails['registry_enabled'] = false
        gitlab_rails['db_username'] = "gitlab"
        gitlab_rails['db_password'] = "XXXXXXXXXXX"
        gitlab_rails['db_host'] = "postgresql"
        gitlab_rails['db_port'] = "5432"
        gitlab_rails['db_database'] = "gitlab"
        gitlab_rails['db_adapter'] = 'postgresql'
        gitlab_rails['db_encoding'] = 'utf8'
        gitlab_rails['redis_host'] = 'redis-master'
        gitlab_rails['redis_port'] = '6379'
        gitlab_rails['redis_password'] = 'xxxxxxxxxxx'
        gitlab_rails['smtp_enable'] = true
        gitlab_rails['smtp_address'] = "smtp.yandex.ru"
        gitlab_rails['smtp_port'] = 465
        gitlab_rails['smtp_user_name'] = "[email protected]"
        gitlab_rails['smtp_password'] = "xxxxxxxxx"
        gitlab_rails['smtp_domain'] = "example.com"
        gitlab_rails['gitlab_email_from'] = '[email protected]'
        gitlab_rails['smtp_authentication'] = "login"
        gitlab_rails['smtp_tls'] = true
        gitlab_rails['smtp_enable_starttls_auto'] = true
        gitlab_rails['smtp_openssl_verify_mode'] = 'peer'
        external_url 'http://gitlab.example.com/'
        gitlab_rails['gitlab_shell_ssh_port'] = 22222
    volumes:
      - gitlab_conf:/etc/gitlab
      - gitlab_logs:/var/log/gitlab
      - gitlab_data:/var/opt/gitlab
    deploy:
      mode: replicated
      replicas: 1
      placement:
        constraints:
        - node.role == manager
      labels:
        - traefik.enable=true
        - traefik.http.routers.gitlab.rule=Host(`gitlab.example.com`)
        - traefik.http.services.gitlab.loadbalancer.server.port=80
        - traefik.docker.network=traefik
  gitlab-runner:
    image: gitlab/gitlab-runner:latest
    networks:
      - gitlab
    volumes:
      - gitlab_runner_conf:/etc/gitlab
      - /var/run/docker.sock:/var/run/docker.sock
    deploy:
      mode: replicated
      replicas: 1
      placement:
        constraints:
        - node.role == manager

volumes:
  gitlab_conf:
    driver: local
    driver_opts:
      type: none
      o: bind
      device: "/srv/docker/gitlab/conf"
  gitlab_logs:
    driver: local
    driver_opts:
      type: none
      o: bind
      device: "/srv/docker/gitlab/logs"
  gitlab_data:
    driver: local
    driver_opts:
      type: none
      o: bind
      device: "/srv/docker/gitlab/data"
  gitlab_runner_conf:
    driver: local
    driver_opts:
      type: none
      o: bind
      device: "/srv/docker/gitlab/runner"

networks:
  pgsql:
    external: true
  redis:
    external: true
  traefik:
    external: true
  gitlab:
    external: true

# mkdir -p /srv/docker/gitlab/conf
# mkdir -p /srv/docker/gitlab/logs
# mkdir -p /srv/docker/gitlab/data
# mkdir -p /srv/docker/gitlab/runner
# docker stack deploy --compose-file 08gitlab-runner.yml gitlab

Den endelige tilstanden til klyngen og tjenestene:

# 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

Hva annet kan forbedres? Sørg for å konfigurere Traefik til å fungere med https-beholdere, legg til tls-kryptering for Postgresql og Redis. Men generelt kan du allerede gi det til utviklere som en PoC. La oss nå se på alternativer til Docker.

Podman

En annen ganske kjent motor for å kjøre containere gruppert etter pods (pods, grupper av containere utplassert sammen). I motsetning til Docker, krever det ingen tjeneste for å kjøre containere, alt arbeid gjøres gjennom libpod-biblioteket. Også skrevet i Go, trenger en OCI-kompatibel kjøretid for å kjøre containere som runC.

Docker og alle, alle, alle

Å jobbe med Podman ligner generelt på Docker, i den grad du kan gjøre det slik (hevdet av mange som har prøvd det, inkludert forfatteren av denne artikkelen):

$ alias docker=podman

og du kan fortsette å jobbe. Generelt er situasjonen med Podman veldig interessant, for hvis de tidlige versjonene av Kubernetes fungerte med Docker, så siden ca. 2015, etter å ha standardisert containerverdenen (OCI - Open Container Initiative) og splittet Docker i containerd og runC, et alternativ til Docker utvikles for å kjøre i Kubernetes: CRI-O. Podman i denne forbindelse er et alternativ til Docker, bygget på prinsippene til Kubernetes, inkludert containergruppering, men hovedmålet med prosjektet er å kjøre containere i Docker-stil uten tilleggstjenester. Av åpenbare grunner er det ingen svermmodus, siden utviklerne tydelig sier at hvis du trenger en klynge, ta Kubernetes.

Installasjon

For å installere på Centos 7, bare aktiver Extras-depotet, og installer deretter alt med kommandoen:

# yum -y install podman

Andre funksjoner

Podman kan generere enheter for systemd, og dermed løse problemet med å starte containere etter en omstart av serveren. I tillegg er systemd erklært å fungere korrekt som pid 1 i beholderen. For å bygge containere er det et eget buildah-verktøy, det finnes også tredjepartsverktøy - analoger av docker-compose, som også genererer Kubernetes-kompatible konfigurasjonsfiler, så overgangen fra Podman til Kubernetes er så enkel som mulig.

Jobber med Podman

Siden det ikke er noen svermmodus (det er ment å bytte til Kubernetes hvis en klynge er nødvendig), vil vi sette den sammen i separate beholdere.

Installer podman-compose:

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

Den resulterende konfigurasjonsfilen for podman er litt annerledes, da vi for eksempel måtte flytte en separat volumseksjon direkte til tjenesteseksjonen.

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 av arbeidet:

# 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

La oss se hva det vil generere for systemd og kubernetes, for dette må vi finne ut navnet eller ID-en til poden:

# 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

Dessverre, bortsett fra å kjøre containere, gjør den genererte enheten for systemd ingenting annet (for eksempel å rydde opp i gamle containere når en slik tjeneste startes på nytt), så du må legge til slike ting selv.

I prinsippet er Podman nok til å prøve hva containere er, overføre gamle konfigurasjoner for docker-compose, og deretter gå mot Kubernetes, om nødvendig, på en klynge, eller få et lettere å bruke alternativ til Docker.

rkt

Prosjekt gått til arkivet for omtrent et halvt år siden på grunn av at RedHat kjøpte den, så jeg vil ikke dvele mer detaljert på den. Generelt ga den et veldig godt inntrykk, men sammenlignet med Docker, og enda mer til Podman, ser det ut som en tresker. Det var også en CoreOS-distribusjon bygget på toppen av rkt (selv om de opprinnelig hadde Docker), men det ble også slutt etter RedHat-kjøpet.

Plass

en annen ett prosjekt, som forfatteren bare ønsket å bygge og kjøre containere. Etter dokumentasjonen og koden å dømme fulgte ikke forfatteren standardene, men bestemte seg ganske enkelt for å skrive sin egen implementering, noe han i prinsippet gjorde.

Funn

Situasjonen med Kubernetes er veldig interessant: på den ene siden, med Docker, kan du sette sammen en klynge (i svermmodus), som du til og med kan kjøre produksjonsmiljøer for klienter med, dette gjelder spesielt for små team (3-5 personer) ), eller med en liten total belastning , eller mangel på ønske om å forstå vanskelighetene ved å sette opp Kubernetes, inkludert for høy belastning.

Podman gir ikke full kompatibilitet, men den har en viktig fordel - kompatibilitet med Kubernetes, inkludert tilleggsverktøy (buildah og andre). Derfor vil jeg nærme meg valget av et verktøy for arbeid som følger: for små team, eller med et begrenset budsjett - Docker (med en mulig svermmodus), for å utvikle for meg selv på en personlig lokalvert - Podman-kamerater, og for alle andre - Kubernetes.

Jeg er ikke sikker på at situasjonen med Docker ikke vil endre seg i fremtiden, tross alt er de pionerer, og standardiserer også sakte trinn for trinn, men Podman, med alle dens mangler (fungerer bare på Linux, ingen klynging, montering og andre handlinger er tredjepartsbeslutninger) fremtiden er klarere, så jeg inviterer alle til å diskutere disse funnene i kommentarene.

PS 3. august lanserer vi "Docker videokurshvor du kan lære mer om arbeidet hans. Vi vil analysere alle verktøyene: fra grunnleggende abstraksjoner til nettverksparametere, nyanser av arbeid med ulike operativsystemer og programmeringsspråk. Du vil bli kjent med teknologien og forstå hvor og hvordan du best kan bruke Docker. Vi vil også dele eksempler på beste praksis.

Forhåndsbestillingskostnad før utgivelse: 5000 rubler. Programmet "Docker Video Course" finner du på kurssiden.

Kilde: www.habr.com

Legg til en kommentar