დოკერი და ყველა, ყველა, ყველა

TL;DR: მიმოხილვის სახელმძღვანელო კონტეინერებში აპლიკაციების გაშვების ჩარჩოების შედარების შესახებ. განხილული იქნება Docker-ის და სხვა მსგავსი სისტემების შესაძლებლობები.

პატარა ისტორია იმის შესახებ, თუ საიდან მოვიდა ეს ყველაფერი

Story

პირველი ცნობილი მეთოდი აპლიკაციის იზოლირებისთვის არის chroot. ამავე სახელწოდების სისტემური ზარი უზრუნველყოფს root დირექტორიას შეცვლას - რითაც უზრუნველყოფს, რომ პროგრამას, რომელმაც მას დაურეკა, აქვს წვდომა მხოლოდ ამ დირექტორიაში არსებულ ფაილებზე. მაგრამ თუ პროგრამას შიდა პრივილეგიები მიენიჭება, მას შეუძლია „გაექცეს“ chroot-ს და მოიპოვოს წვდომა მთავარ ოპერაციულ სისტემაზე. ასევე, გარდა root დირექტორიას შეცვლისა, სხვა რესურსები (RAM, პროცესორი), ისევე როგორც ქსელის წვდომა შეზღუდული არ არის.

შემდეგი მეთოდი არის სრულფასოვანი ოპერაციული სისტემის გაშვება კონტეინერში, ოპერაციული სისტემის ბირთვის მექანიზმების გამოყენებით. ამ მეთოდს სხვადასხვა ოპერაციულ სისტემაში სხვანაირად უწოდებენ, მაგრამ არსი იგივეა - რამდენიმე დამოუკიდებელი ოპერაციული სისტემის გაშვება, რომელთაგან თითოეული მუშაობს იმავე ბირთვზე, რომელზეც მუშაობს მთავარი ოპერაციული სისტემა. მათ შორისაა FreeBSD Jails, Solaris Zones, OpenVZ და LXC for Linux. იზოლაცია უზრუნველყოფილია არა მხოლოდ დისკის სივრცით, არამედ სხვა რესურსებითაც; კერძოდ, თითოეულ კონტეინერს შეიძლება ჰქონდეს შეზღუდვები პროცესორის დროს, ოპერატიული მეხსიერებასა და ქსელის გამტარუნარიანობაზე. chroot-თან შედარებით, კონტეინერის დატოვება უფრო რთულია, რადგან კონტეინერში მყოფ სუპერმომხმარებელს აქვს წვდომა მხოლოდ კონტეინერის შიგთავსზე, თუმცა, კონტეინერის შიგნით ოპერაციული სისტემის განახლების აუცილებლობისა და ძველი ვერსიების გამოყენების გამო. ბირთვების (შესაბამისია Linux-ისთვის, ნაკლებად FreeBSD-სთვის), არსებობს ბირთვის იზოლაციის სისტემის „გარღვევის“ და მთავარ ოპერაციულ სისტემაზე წვდომის ალბათობა.

სრულფასოვანი ოპერაციული სისტემის კონტეინერში გაშვების ნაცვლად (ინიციალიზაციის სისტემით, პაკეტის მენეჯერით და ა. და სხვა ფაილები). ეს იდეა საფუძვლად დაედო კონტეინერიზებული აპლიკაციების ვირტუალიზაციას, რომლის ყველაზე ცნობილი და ცნობილი წარმომადგენელია Docker. წინა სისტემებთან შედარებით, უფრო მოქნილი იზოლაციის მექანიზმები, კონტეინერებს შორის ვირტუალური ქსელების ჩაშენებული მხარდაჭერა და განაცხადის მდგომარეობის თვალყურის დევნება კონტეინერში, განაპირობა კონტეინერების გაშვებისთვის დიდი რაოდენობით ფიზიკური სერვერებიდან ერთი თანმიმდევრული გარემოს აგების შესაძლებლობა - რესურსების ხელით მართვის საჭიროების გარეშე.

docker

Docker არის ყველაზე ცნობილი აპლიკაციის კონტეინერიზაციის პროგრამა. Go ენაზე დაწერილი, ის იყენებს Linux-ის ბირთვის სტანდარტულ მახასიათებლებს - cgroups, სახელთა სივრცეებს, შესაძლებლობებს და ა.შ., ასევე Aufs ფაილურ სისტემებს და სხვა მსგავსებს დისკზე სივრცის დაზოგვის მიზნით.

წყარო: ვიკიმედია

არქიტექტურა

1.11 ვერსიამდე Docker მუშაობდა როგორც ერთიანი სერვისი, რომელიც ახორციელებდა ყველა ოპერაციას კონტეინერებით: კონტეინერებისთვის სურათების ჩამოტვირთვა, კონტეინერების გაშვება, API მოთხოვნების დამუშავება. 1.11 ვერსიით დაწყებული Docker დაიყო რამდენიმე ნაწილად, რომლებიც ურთიერთქმედებენ ერთმანეთთან: კონტეინერი, კონტეინერების მთელი სასიცოცხლო ციკლის დასამუშავებლად (დისკზე სივრცის გამოყოფა, სურათების ჩამოტვირთვა, ქსელთან მუშაობა, გაშვება, ინსტალაცია და კონტეინერების მდგომარეობის მონიტორინგი) და runC, კონტეინერის შესრულების გარემო, რომელიც დაფუძნებულია cgroup-ების გამოყენებაზე და Linux-ის ბირთვის სხვა ფუნქციებზე. თავად დოკერის სერვისი რჩება, მაგრამ ახლა ის მხოლოდ კონტეინერში გადათარგმნილი API მოთხოვნების დამუშავებას ემსახურება.

ინსტალაცია და კონფიგურაცია

დოკერის ინსტალაციის ჩემი საყვარელი გზაა დოკერ-მანქანა, რომელიც დისტანციურ სერვერებზე (სხვადასხვა ღრუბლების ჩათვლით) დოკერის უშუალო ინსტალაციისა და კონფიგურაციის გარდა, შესაძლებელს ხდის დისტანციური სერვერების ფაილურ სისტემებთან მუშაობას და ასევე შეუძლია სხვადასხვა ბრძანებების გაშვება.

თუმცა, 2018 წლიდან პროექტი თითქმის არ განვითარებულა, ამიტომ ჩვენ დავაინსტალირებთ მას სტანდარტული გზით Linux-ის დისტრიბუციების უმეტესობისთვის - დავამატებთ საცავს და დავაინსტალირებთ საჭირო პაკეტებს.

ეს მეთოდი ასევე გამოიყენება ავტომატური ინსტალაციისთვის, მაგალითად Ansible ან სხვა მსგავსი სისტემების გამოყენებით, მაგრამ მე არ განვიხილავ მას ამ სტატიაში.

ინსტალაცია განხორციელდება Centos 7-ზე, სერვერად გამოვიყენებ ვირტუალურ მანქანას, ინსტალაციისთვის უბრალოდ გაუშვით ქვემოთ მოცემული ბრძანებები:

# yum install -y yum-utils
# yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo
# yum install docker-ce docker-ce-cli containerd.io

ინსტალაციის შემდეგ, თქვენ უნდა დაიწყოთ სერვისი და ჩართოთ იგი გაშვებაში:

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

გარდა ამისა, შეგიძლიათ შექმნათ დოკერ ჯგუფი, რომლის მომხმარებლებს შეეძლებათ იმუშაონ დოკერთან sudo-ს გარეშე, დააყენონ ჟურნალი, ჩართონ წვდომა API-ზე გარედან და არ დაგავიწყდეთ firewall-ის უფრო ზუსტად კონფიგურაცია (ყველაფერი, რაც დაუშვებელია აკრძალულია ზემოთ და ქვემოთ მოცემულ მაგალითებში - მე ეს გამოვტოვე სიმარტივისა და სიცხადისთვის), მაგრამ აქ უფრო დეტალურად არ შევალ.

სხვა მახასიათებლები

ზემოაღნიშნული დოკერის აპარატის გარდა, ასევე არსებობს დოკერის რეესტრი, ხელსაწყო კონტეინერებისთვის სურათების შესანახად, ასევე დოკერ კომპოსი, ინსტრუმენტი კონტეინერებში აპლიკაციების განლაგების ავტომატიზაციისთვის, YAML ფაილები გამოიყენება კონტეინერების შესაქმნელად და კონფიგურაციისთვის. და სხვა დაკავშირებული რამ (მაგალითად, ქსელები, მუდმივი ფაილური სისტემები მონაცემთა შენახვისთვის).

ის ასევე შეიძლება გამოყენებულ იქნას CICD-სთვის კონვეიერების მოსაწყობად. კიდევ ერთი საინტერესო მახასიათებელია კლასტერულ რეჟიმში მუშაობა, ეგრეთ წოდებული swarm mode (1.12 ვერსიამდე იგი ცნობილი იყო როგორც docker swarm), რომელიც საშუალებას გაძლევთ შეკრიბოთ ერთი ინფრასტრუქტურა რამდენიმე სერვერიდან კონტეინერების გასაშვებად. ყველა სერვერის თავზე არის ვირტუალური ქსელის მხარდაჭერა, არის ჩაშენებული დატვირთვის ბალანსერი, ასევე კონტეინერების საიდუმლოების მხარდაჭერა.

YAML ფაილები docker compose-დან, მცირე ცვლილებებით, შეიძლება გამოყენებულ იქნას ასეთი კლასტერებისთვის, რაც მთლიანად ავტომატიზირებს მცირე და საშუალო ზომის კლასტერების შენარჩუნებას სხვადასხვა მიზნებისთვის. დიდი კლასტერებისთვის სასურველია Kubernetes, რადგან Swarm რეჟიმის შენარჩუნების ხარჯები შეიძლება აღემატებოდეს Kubernetes-ს. გარდა runC-ისა, შეგიძლიათ დააინსტალიროთ, მაგალითად, როგორც კონტეინერის შესრულების გარემო კატას კონტეინერები

Docker-თან მუშაობა

ინსტალაციისა და კონფიგურაციის შემდეგ, ჩვენ შევეცდებით შევკრიბოთ კლასტერი, რომელშიც განვათავსებთ GitLab-ს და Docker Registry-ს განვითარების გუნდისთვის. სერვერად გამოვიყენებ სამ ვირტუალურ მანქანას, რომლებზეც დამატებით განვათავსებ განაწილებულ FS GlusterFS-ს; გამოვიყენებ მას დოკერის ტომების შესანახად, მაგალითად, დოკერის რეესტრის შეცდომის ტოლერანტული ვერსიის გასაშვებად. გასაშვები ძირითადი კომპონენტები: Docker Registry, Postgresql, Redis, GitLab GitLab Runner-ის მხარდაჭერით Swarm-ის თავზე. ჩვენ გავუშვით Postgresql კლასტერინგით სტოლონი, ასე რომ თქვენ არ გჭირდებათ GlusterFS-ის გამოყენება Postgresql მონაცემების შესანახად. დარჩენილი კრიტიკული მონაცემები შეინახება GlusterFS-ზე.

GlusterFS-ის განსათავსებლად ყველა სერვერზე (მათ უწოდებენ node1, node2, node3), თქვენ უნდა დააინსტალიროთ პაკეტები, ჩართოთ firewall და შექმნათ საჭირო დირექტორიები:

# yum -y install centos-release-gluster7
# yum -y install glusterfs-server
# systemctl enable glusterd
# systemctl start glusterd
# firewall-cmd --add-service=glusterfs --permanent
# firewall-cmd --reload
# mkdir -p /srv/gluster
# mkdir -p /srv/docker
# echo "$(hostname):/docker /srv/docker glusterfs defaults,_netdev 0 0" >> /etc/fstab

ინსტალაციის შემდეგ, GlusterFS-ის კონფიგურაციაზე მუშაობა უნდა გაგრძელდეს ერთი კვანძიდან, მაგალითად, node1:

# gluster peer probe node2
# gluster peer probe node3
# gluster volume create docker replica 3 node1:/srv/gluster node2:/srv/gluster node3:/srv/gluster force
# gluster volume start docker

შემდეგ თქვენ უნდა დაამონტაჟოთ მიღებული მოცულობა (ბრძანება უნდა შესრულდეს ყველა სერვერზე):

# mount /srv/docker

Swarm რეჟიმი დაკონფიგურირებულია ერთ-ერთ სერვერზე, რომელიც იქნება Leader, დანარჩენს მოუწევს შეუერთდეს კლასტერს, ამიტომ პირველ სერვერზე ბრძანების შესრულების შედეგი საჭირო იქნება კოპირება და სხვებზე შესრულება.

კლასტერის საწყისი დაყენება, მე ვასრულებ ბრძანებას node1-ზე:

# docker swarm init
Swarm initialized: current node (a5jpfrh5uvo7svzz1ajduokyq) is now a manager.

To add a worker to this swarm, run the following command:

    docker swarm join --token SWMTKN-1-0c5mf7mvzc7o7vjk0wngno2dy70xs95tovfxbv4tqt9280toku-863hyosdlzvd76trfptd4xnzd xx.xx.xx.xx:2377

To add a manager to this swarm, run 'docker swarm join-token manager' and follow the instructions.
# docker swarm join-token manager

ჩვენ ვაკოპირებთ მეორე ბრძანების შედეგს და ვასრულებთ მას node2-ზე და node3-ზე:

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

ამ ეტაპზე სერვერების წინასწარი კონფიგურაცია დასრულებულია, მოდით გადავიდეთ სერვისების დაყენებაზე; შესასრულებელი ბრძანებები ამოქმედდება node1-დან, თუ სხვა რამ არ არის მითითებული.

უპირველეს ყოვლისა, მოდით შევქმნათ ქსელები კონტეინერებისთვის:

# docker network create --driver=overlay etcd
# docker network create --driver=overlay pgsql
# docker network create --driver=overlay redis
# docker network create --driver=overlay traefik
# docker network create --driver=overlay gitlab

შემდეგ ჩვენ აღვნიშნავთ სერვერებს, ეს აუცილებელია სერვერებთან ზოგიერთი სერვისის დასაკავშირებლად:

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

შემდეგი, ჩვენ ვქმნით დირექტორიებს etcd მონაცემების შესანახად, KV შენახვისთვის, რომელიც საჭიროა Traefik-ისთვის და Stolon-ისთვის. Postgresql-ის მსგავსად, ეს იქნება სერვერებზე მიბმული კონტეინერები, ამიტომ ჩვენ ვასრულებთ ამ ბრძანებას ყველა სერვერზე:

# mkdir -p /srv/etcd

შემდეგი, შექმენით ფაილი etcd-ის კონფიგურაციისთვის და გამოიყენეთ იგი:

00etcd.yml

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

გარკვეული პერიოდის შემდეგ, ჩვენ ვამოწმებთ, რომ etcd კლასტერი არის:

# docker exec $(docker ps | awk '/etcd/ {print $1}')  etcdctl member list
ade526d28b1f92f7: name=etcd1 peerURLs=http://etcd1:2380 clientURLs=http://etcd1:2379 isLeader=false
bd388e7810915853: name=etcd3 peerURLs=http://etcd3:2380 clientURLs=http://etcd3:2379 isLeader=false
d282ac2ce600c1ce: name=etcd2 peerURLs=http://etcd2:2380 clientURLs=http://etcd2:2379 isLeader=true
# docker exec $(docker ps | awk '/etcd/ {print $1}')  etcdctl cluster-health
member ade526d28b1f92f7 is healthy: got healthy result from http://etcd1:2379
member bd388e7810915853 is healthy: got healthy result from http://etcd3:2379
member d282ac2ce600c1ce is healthy: got healthy result from http://etcd2:2379
cluster is healthy

ჩვენ ვქმნით დირექტორიებს Postgresql-სთვის, ვასრულებთ ბრძანებას ყველა სერვერზე:

# mkdir -p /srv/pgsql

შემდეგი, შექმენით ფაილი Postgresql-ის კონფიგურაციისთვის:

01pgsql.yml

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

ჩვენ ვქმნით საიდუმლოებებს და ვიყენებთ ფაილს:

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

გარკვეული პერიოდის შემდეგ (იხილეთ ბრძანების გამოსავალი დოკერის სერვისი lsრომ ყველა სერვისი მუშაობს) ჩვენ ვაყენებთ Postgresql კლასტერს:

# docker exec $(docker ps | awk '/pgkeeper/ {print $1}') stolonctl --cluster-name=stolon-cluster --store-backend=etcdv3 --store-endpoints=http://etcd1:2379,http://etcd2:2379,http://etcd3:2379 init

Postgresql კლასტერის მზადყოფნის შემოწმება:

# docker exec $(docker ps | awk '/pgkeeper/ {print $1}') stolonctl --cluster-name=stolon-cluster --store-backend=etcdv3 --store-endpoints=http://etcd1:2379,http://etcd2:2379,http://etcd3:2379 status
=== Active sentinels ===

ID      LEADER
26baa11d    false
74e98768    false
a8cb002b    true

=== Active proxies ===

ID
4d233826
9f562f3b
b0c79ff1

=== Keepers ===

UID     HEALTHY PG LISTENADDRESS    PG HEALTHY  PG WANTEDGENERATION PG CURRENTGENERATION
pgkeeper1   true    pgkeeper1:5432         true     2           2
pgkeeper2   true    pgkeeper2:5432          true            2                   2
pgkeeper3   true    pgkeeper3:5432          true            3                   3

=== Cluster Info ===

Master Keeper: pgkeeper3

===== Keepers/DB tree =====

pgkeeper3 (master)
├─pgkeeper2
└─pgkeeper1

ჩვენ ვაკონფიგურირებთ traefik კონტეინერებზე წვდომის გასახსნელად გარედან:

03traefik.yml

version: '3.7'

services:
  traefik:
    image: traefik:latest
    command: >
      --log.level=INFO
      --providers.docker=true
      --entryPoints.web.address=:80
      --providers.providersThrottleDuration=2
      --providers.docker.watch=true
      --providers.docker.swarmMode=true
      --providers.docker.swarmModeRefreshSeconds=15s
      --providers.docker.exposedbydefault=false
      --accessLog.bufferingSize=0
      --api=true
      --api.dashboard=true
      --api.insecure=true
    networks:
      - traefik
    ports:
      - 80:80
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
    deploy:
      replicas: 3
      placement:
        constraints:
          - node.role == manager
        preferences:
          - spread: node.id
      labels:
        - traefik.enable=true
        - traefik.http.routers.traefik.rule=Host(`traefik.example.com`)
        - traefik.http.services.traefik.loadbalancer.server.port=8080
        - traefik.docker.network=traefik

networks:
  traefik:
    external: true

# docker stack deploy --compose-file 03traefik.yml traefik

ჩვენ გავუშვით Redis Cluster, ამისათვის ჩვენ ვქმნით შენახვის დირექტორიას ყველა კვანძზე:

# mkdir -p /srv/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

დოკერის რეესტრის დამატება:

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

და ბოლოს - 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

კლასტერის და სერვისების საბოლოო მდგომარეობა:

# 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

კიდევ რა შეიძლება გაუმჯობესდეს? დარწმუნდით, რომ დააკონფიგურირეთ Traefik კონტეინერების გასაშვებად https-ზე, დაამატეთ tls დაშიფვრა Postgresql და Redis-ისთვის. მაგრამ ზოგადად, ის უკვე შეიძლება მიეცეს დეველოპერებს, როგორც PoC. მოდით ახლა გადავხედოთ Docker-ის ალტერნატივებს.

პოდმანი

კიდევ ერთი საკმაოდ ცნობილი ძრავა კონტეინერების გაშვებისთვის, რომლებიც დაჯგუფებულია ღობეების მიხედვით (pods, კონტეინერების ჯგუფები ერთად განლაგებული). დოკერისგან განსხვავებით, კონტეინერების გასაშვებად არ საჭიროებს რაიმე სერვისს; ყველა სამუშაო კეთდება libpod ბიბლიოთეკის მეშვეობით. ასევე Go-ში დაწერილი, მოითხოვს OCI-თავსებადი გაშვების დროს კონტეინერების გასაშვებად, როგორიცაა runC.

პოდმანთან მუშაობა ზოგადად დოკერს მოგვაგონებს, იმ დონემდე, რომ ამის გაკეთება შეგიძლიათ ასე (როგორც ბევრმა სცადა, მათ შორის ამ სტატიის ავტორის ჩათვლით):

$ alias docker=podman

და შეგიძლიათ გააგრძელოთ მუშაობა. ზოგადად, პოდმანთან სიტუაცია ძალიან საინტერესოა, რადგან თუ Kubernetes-ის ადრეული ვერსიები მუშაობდა Docker-თან, მაშინ დაახლოებით 2015 წელს, კონტეინერების სამყაროს სტანდარტიზაციის შემდეგ (OCI - Open Container Initiative) და Docker-ის დაყოფა კონტეინერად და runC-ად, შეიქმნა Docker-ის ალტერნატივა Kubernetes-ში გასაშვებად: CRI-O. Podman ამ მხრივ არის Docker-ის ალტერნატივა, რომელიც აგებულია Kubernetes-ის პრინციპებზე, კონტეინერების დაჯგუფების ჩათვლით, მაგრამ პროექტის მთავარი მიზანია Docker-ის სტილის კონტეინერების გაშვება დამატებითი სერვისების გარეშე. გასაგები მიზეზების გამო, არ არსებობს სვარმის რეჟიმი, რადგან დეველოპერები ნათლად ამბობენ, რომ თუ კლასტერი გჭირდებათ, აიღეთ Kubernetes.

დაყენების

Centos 7-ზე ინსტალაციისთვის, უბრალოდ გაააქტიურეთ Extras საცავი და შემდეგ დააინსტალირეთ ყველაფერი ბრძანებით:

# yum -y install podman

სხვა მახასიათებლები

Podman-ს შეუძლია სისტემად ერთეულების გენერირება, რითაც გადაჭრის კონტეინერების დაწყების პრობლემას სერვერის გადატვირთვის შემდეგ. გარდა ამისა, systemd გამოცხადებულია, რომ მუშაობს სწორად, როგორც pid 1 კონტეინერში. არსებობს ცალკე buildah ინსტრუმენტი კონტეინერების ასაშენებლად, ასევე არის მესამე მხარის ინსტრუმენტები - docker-compose-ის ანალოგები, რომლებიც ასევე წარმოქმნიან Kubernetes-თან თავსებად კონფიგურაციის ფაილებს, ამიტომ Podman-დან Kubernetes-ზე გადასვლა მაქსიმალურად გამარტივებულია.

Podman-თან მუშაობა

იმის გამო, რომ არ არის Swarm რეჟიმი (ჩვენ უნდა გადავიდეთ Kubernetes-ზე, თუ კლასტერი საჭიროა), ჩვენ მას ცალკე კონტეინერებში ვაგროვებთ.

დააინსტალირეთ podman-compose:

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

შედეგად მიღებული კონფიგურაციის ფაილი პოდმენისთვის ოდნავ განსხვავებულია, ასე რომ, მაგალითად, ჩვენ მოგვიწია ცალკეული ტომების განყოფილების გადატანა პირდაპირ სერვისების განყოფილებაში.

gitlab-podman.yml

version: '3.7'

services:
  gitlab:
    image: gitlab/gitlab-ce:latest
    hostname: gitlab.example.com
    restart: unless-stopped
    environment:
      GITLAB_OMNIBUS_CONFIG: |
        gitlab_rails['gitlab_shell_ssh_port'] = 22222
    ports:
      - "80:80"
      - "22222:22"
    volumes:
      - /srv/podman/gitlab/conf:/etc/gitlab
      - /srv/podman/gitlab/data:/var/opt/gitlab
      - /srv/podman/gitlab/logs:/var/log/gitlab
    networks:
      - gitlab

  gitlab-runner:
    image: gitlab/gitlab-runner:alpine
    restart: unless-stopped
    depends_on:
      - gitlab
    volumes:
      - /srv/podman/gitlab/runner:/etc/gitlab-runner
      - /var/run/docker.sock:/var/run/docker.sock
    networks:
      - gitlab

networks:
  gitlab:

# podman-compose -f gitlab-runner.yml -d up

შედეგი:

# podman ps
CONTAINER ID  IMAGE                                  COMMAND               CREATED             STATUS                 PORTS                                      NAMES
da53da946c01  docker.io/gitlab/gitlab-runner:alpine  run --user=gitlab...  About a minute ago  Up About a minute ago  0.0.0.0:22222->22/tcp, 0.0.0.0:80->80/tcp  root_gitlab-runner_1
781c0103c94a  docker.io/gitlab/gitlab-ce:latest      /assets/wrapper       About a minute ago  Up About a minute ago  0.0.0.0:22222->22/tcp, 0.0.0.0:80->80/tcp  root_gitlab_1

ვნახოთ, რას წარმოქმნის ის systemd-ისთვის და kubernetes-ისთვის, ამისათვის ჩვენ უნდა გავარკვიოთ pod-ის სახელი ან id:

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

კუბერნეტები:

# 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: {}

სისტემური:

# podman generate systemd 71fc2b2a5c63
# pod-71fc2b2a5c6346f0c1c86a2dc45dbe78fa192ea02aac001eb8347ccb8c043c26.service
# autogenerated by Podman 1.6.4
# Thu Jul 29 15:23:28 EDT 2020

[Unit]
Description=Podman pod-71fc2b2a5c6346f0c1c86a2dc45dbe78fa192ea02aac001eb8347ccb8c043c26.service
Documentation=man:podman-generate-systemd(1)
Requires=container-781c0103c94aaa113c17c58d05ddabf8df4bf39707b664abcf17ed2ceff467d3.service container-da53da946c01449f500aa5296d9ea6376f751948b17ca164df438b7df6607864.service
Before=container-781c0103c94aaa113c17c58d05ddabf8df4bf39707b664abcf17ed2ceff467d3.service container-da53da946c01449f500aa5296d9ea6376f751948b17ca164df438b7df6607864.service

[Service]
Restart=on-failure
ExecStart=/usr/bin/podman start db40ab8bf84bf35141159c26cb6e256b889c7a98c0418eee3c4aa683c14fccaa
ExecStop=/usr/bin/podman stop -t 10 db40ab8bf84bf35141159c26cb6e256b889c7a98c0418eee3c4aa683c14fccaa
KillMode=none
Type=forking
PIDFile=/var/run/containers/storage/overlay-containers/db40ab8bf84bf35141159c26cb6e256b889c7a98c0418eee3c4aa683c14fccaa/userdata/conmon.pid

[Install]
WantedBy=multi-user.target
# container-da53da946c01449f500aa5296d9ea6376f751948b17ca164df438b7df6607864.service
# autogenerated by Podman 1.6.4
# Thu Jul 29 15:23:28 EDT 2020

[Unit]
Description=Podman container-da53da946c01449f500aa5296d9ea6376f751948b17ca164df438b7df6607864.service
Documentation=man:podman-generate-systemd(1)
RefuseManualStart=yes
RefuseManualStop=yes
BindsTo=pod-71fc2b2a5c6346f0c1c86a2dc45dbe78fa192ea02aac001eb8347ccb8c043c26.service
After=pod-71fc2b2a5c6346f0c1c86a2dc45dbe78fa192ea02aac001eb8347ccb8c043c26.service

[Service]
Restart=on-failure
ExecStart=/usr/bin/podman start da53da946c01449f500aa5296d9ea6376f751948b17ca164df438b7df6607864
ExecStop=/usr/bin/podman stop -t 10 da53da946c01449f500aa5296d9ea6376f751948b17ca164df438b7df6607864
KillMode=none
Type=forking
PIDFile=/var/run/containers/storage/overlay-containers/da53da946c01449f500aa5296d9ea6376f751948b17ca164df438b7df6607864/userdata/conmon.pid

[Install]
WantedBy=multi-user.target
# container-781c0103c94aaa113c17c58d05ddabf8df4bf39707b664abcf17ed2ceff467d3.service
# autogenerated by Podman 1.6.4
# Thu Jul 29 15:23:28 EDT 2020

[Unit]
Description=Podman container-781c0103c94aaa113c17c58d05ddabf8df4bf39707b664abcf17ed2ceff467d3.service
Documentation=man:podman-generate-systemd(1)
RefuseManualStart=yes
RefuseManualStop=yes
BindsTo=pod-71fc2b2a5c6346f0c1c86a2dc45dbe78fa192ea02aac001eb8347ccb8c043c26.service
After=pod-71fc2b2a5c6346f0c1c86a2dc45dbe78fa192ea02aac001eb8347ccb8c043c26.service

[Service]
Restart=on-failure
ExecStart=/usr/bin/podman start 781c0103c94aaa113c17c58d05ddabf8df4bf39707b664abcf17ed2ceff467d3
ExecStop=/usr/bin/podman stop -t 10 781c0103c94aaa113c17c58d05ddabf8df4bf39707b664abcf17ed2ceff467d3
KillMode=none
Type=forking
PIDFile=/var/run/containers/storage/overlay-containers/781c0103c94aaa113c17c58d05ddabf8df4bf39707b664abcf17ed2ceff467d3/userdata/conmon.pid

[Install]
WantedBy=multi-user.target

სამწუხაროდ, კონტეინერების გაშვების გარდა, systemd-ისთვის გენერირებული განყოფილება სხვას არაფერს აკეთებს (მაგალითად, ძველი კონტეინერების გაწმენდა ასეთი სერვისის გადატვირთვისას), ასე რომ თქვენ თვითონ მოგიწევთ ასეთი რაღაცების დაწერა.

პრინციპში, Podman საკმარისია სცადოთ რა არის კონტეინერები, გადაიტანოთ ძველი კონფიგურაციები docker-compose-ისთვის და შემდეგ გადავიდეთ Kubernetes-ისკენ, თუ გჭირდებათ კლასტერი, ან მიიღოთ უფრო ადვილად გამოსაყენებელი ალტერნატივა Docker-ისთვის.

რქტ

პროექტი არქივში შევიდა დაახლოებით ექვსი თვის წინ იმის გამო, რომ RedHat-მა ის იყიდა, ამიტომ უფრო დეტალურად არ ვისაუბრებ. მთლიანობაში, ძალიან კარგი შთაბეჭდილება დატოვა, მაგრამ დოკერთან და განსაკუთრებით პოდმანთან შედარებით, კომბაინს ჰგავს. ასევე იყო CoreOS დისტრიბუცია აგებული rkt-ის თავზე (თუმცა მათ თავდაპირველად ჰქონდათ Docker), მაგრამ ეს ასევე დასრულდა მხარდაჭერით RedHat-ის შეძენის შემდეგ.

პლაშ

სხვა ერთი პროექტი, რომლის ავტორს მხოლოდ კონტეინერების აგება და გაშვება სურდა. დოკუმენტაციისა და კოდის მიხედვით თუ ვიმსჯელებთ, ავტორი არ იცავდა სტანდარტებს, უბრალოდ გადაწყვიტა დაეწერა საკუთარი იმპლემენტაცია, რაც, პრინციპში, გააკეთა.

დასკვნები

Kubernetes-თან სიტუაცია ძალიან საინტერესოა: ერთის მხრივ, Docker-ით შეგიძლიათ შექმნათ კლასტერი (swarm რეჟიმში), რომლითაც შეგიძლიათ პროდუქტის გარემოც კი გაუშვათ კლიენტებისთვის, ეს განსაკუთრებით ეხება მცირე გუნდებს (3-5 ადამიანი) , ან მცირე საერთო დატვირთვით, ან კუბერნეტების დაყენების სირთულეების გაგების სურვილის ნაკლებობით, მათ შორის მაღალი დატვირთვისთვის.

Podman არ იძლევა სრულ თავსებადობას, მაგრამ მას აქვს ერთი მნიშვნელოვანი უპირატესობა - თავსებადობა Kubernetes-თან, დამატებითი ხელსაწყოების ჩათვლით (buildah და სხვა). ამიტომ, სამუშაოსთვის ხელსაწყოს არჩევას შემდეგნაირად მივუდგები: მცირე გუნდებისთვის, ან შეზღუდული ბიუჯეტით - Docker (შესაძლო swarm რეჟიმით), პირად ლოკალურ მასპინძელზე საკუთარი თავის განვითარებისთვის - Podman ამხანაგები და ყველა დანარჩენისთვის. - კუბერნეტები.

დარწმუნებული არ ვარ, რომ Docker-თან სიტუაცია არ შეიცვლება მომავალში, ბოლოს და ბოლოს, ისინი არიან პიონერები და ასევე თანდათანობით სტანდარტიზდებიან ეტაპობრივად, მაგრამ Podman, ყველა მისი ნაკლოვანების მიუხედავად (მუშაობს მხოლოდ Linux-ზე, კლასტერიზაციის გარეშე, ასამბლეა და სხვა ქმედებები მესამე მხარის გადაწყვეტილებებია) მომავალი უფრო ნათელია, ამიტომ ყველას ვპატიჟებ განიხილონ ეს დასკვნები კომენტარებში.

PS 3 აგვისტოს ჩვენ ვიწყებთ "დოკერის ვიდეო კურსი“, სადაც შეგიძლიათ გაიგოთ მეტი მისი შემოქმედების შესახებ. ჩვენ გავაანალიზებთ მის ყველა ხელსაწყოს: ძირითადი აბსტრაქციებიდან ქსელის პარამეტრებამდე, სხვადასხვა ოპერაციულ სისტემასთან და პროგრამირების ენებთან მუშაობის ნიუანსებამდე. თქვენ გაეცნობით ტექნოლოგიას და გაიგებთ სად და როგორ საუკეთესოდ გამოიყენოთ Docker. ასევე გაგიზიარებთ საუკეთესო პრაქტიკის შემთხვევებს.

წინასწარი შეკვეთის ფასი გამოშვებამდე: 5000 რუბლი. შეგიძლიათ ნახოთ Docker Video Course პროგრამა კურსის გვერდზე.

წყარო: www.habr.com