🥇 განათავსეთ აპლიკაციები Docker Swarm

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

I ნაწილი

ჯერ კიდევ შორეულ, შორეულ წელს, აუცილებელი იყო CI / CD პროცესის რაც შეიძლება სწრაფად დაყენება. ერთ-ერთი პირობა იყო Docker-ის არ გამოყენება განლაგებისთვის შემუშავებული კომპონენტები რამდენიმე მიზეზის გამო:

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

ინფრასტრუქტურა, დასტა და MVP-ის სავარაუდო საწყისი მოთხოვნები წარმოდგენილი იყო შემდეგნაირად:

4 Intel® X5650 სერვერი Debian-ით (კიდევ ერთი ძლიერი მანქანა სრულად არის განვითარებული)
საკუთარი პერსონალური კომპონენტების შემუშავება ხორციელდება C ++, Python3-ში
გამოყენებული ძირითადი მესამე მხარის ინსტრუმენტები: Kafka, Clickhouse, Airflow, Redis, Grafana, Postgresql, Mysql,…
მილსადენები კომპონენტების მშენებლობისა და ტესტირებისთვის ცალკე გამართვისა და გამოშვებისთვის

ერთ-ერთი პირველი კითხვა, რომელიც უნდა განიხილებოდეს საწყის ეტაპზე, არის ის, თუ როგორ განლაგდება საბაჟო კომპონენტები ნებისმიერ გარემოში (CI / CD).

ჩვენ გადავწყვიტეთ მესამე მხარის კომპონენტების სისტემურად დაყენება და მათი სისტემური განახლება. C++ ან Python-ში შემუშავებული პერსონალური აპლიკაციები შეიძლება განთავსდეს რამდენიმე გზით. მათ შორის, მაგალითად: სისტემური პაკეტების შექმნა, ჩაშენებული სურათების საცავში გაგზავნა და შემდეგ სერვერებზე ინსტალაცია. გაურკვეველი მიზეზის გამო, არჩეული იქნა სხვა მეთოდი, კერძოდ: CI-ს გამოყენებით, აპლიკაციის შესრულებადი ფაილების შედგენა, ვირტუალური პროექტის გარემოს შექმნა, py მოდულების ინსტალაცია დაინსტალირებულია მოთხოვნები.txt-დან და ყველა ეს არტეფაქტი იგზავნება კონფიგურებთან, სკრიპტებთან და სერვერების თანმხლები აპლიკაციის გარემო. შემდეგი, აპლიკაციები იხსნება როგორც ვირტუალური მომხმარებელი ადმინისტრატორის უფლებების გარეშე.

Gitlab-CI აირჩიეს CI/CD სისტემად. შედეგად მიღებული მილსადენი ასე გამოიყურებოდა:

სტრუქტურულად, gitlab-ci.yml ასე გამოიყურებოდა

---
variables:
  # минимальная версия ЦПУ на серверах, где разворачивается кластер
  CMAKE_CPUTYPE: "westmere"

  DEBIAN: "MYREGISTRY:5000/debian:latest"

before_script:
  - eval $(ssh-agent -s)
  - ssh-add <(echo "$SSH_PRIVATE_KEY")
  - mkdir -p ~/.ssh && echo -e "Host *ntStrictHostKeyChecking nonn" > ~/.ssh/config

stages:
  - build
  - testing
  - deploy

debug.debian:
  stage: build
  image: $DEBIAN
  script:
    - cd builds/release && ./build.sh
    paths:
      - bin/
      - builds/release/bin/
    when: always
release.debian:
  stage: build
  image: $DEBIAN
  script:
    - cd builds/release && ./build.sh
    paths:
      - bin/
      - builds/release/bin/
    when: always

## testing stage
tests.codestyle:
  stage: testing
  image: $DEBIAN
  dependencies:
    - release.debian
  script:
    - /bin/bash run_tests.sh -t codestyle -b "${CI_COMMIT_REF_NAME}_codestyle"
tests.debug.debian:
  stage: testing
  image: $DEBIAN
  dependencies:
    - debug.debian
  script:
    - /bin/bash run_tests.sh -e codestyle/test_pylint.py -b "${CI_COMMIT_REF_NAME}_debian_debug"
  artifacts:
    paths:
      - run_tests/username/
    when: always
    expire_in: 1 week
tests.release.debian:
  stage: testing
  image: $DEBIAN
  dependencies:
    - release.debian
  script:
    - /bin/bash run_tests.sh -e codestyle/test_pylint.py -b "${CI_COMMIT_REF_NAME}_debian_release"
  artifacts:
    paths:
      - run_tests/username/
    when: always
    expire_in: 1 week

## staging stage
deploy_staging:
  stage: deploy
  environment: staging
  image: $DEBIAN
  dependencies:
    - release.debian
  script:
    - cd scripts/deploy/ &&
        python3 createconfig.py -s $CI_ENVIRONMENT_NAME &&
        /bin/bash install_venv.sh -d -r ../../requirements.txt &&
        python3 prepare_init.d.py &&
        python3 deploy.py -s $CI_ENVIRONMENT_NAME
  when: manual

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

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

createconfig.py - ქმნის settings.ini ფაილს კომპონენტის პარამეტრებით სხვადასხვა გარემოში შემდგომი განთავსებისთვის (წინასწარი წარმოება, წარმოება, ტესტირება, ...)
install_venv.sh - ქმნის ვირტუალურ გარემოს py კომპონენტებისთვის კონკრეტულ დირექტორიაში და აკოპირებს მას დისტანციურ სერვერებზე
მომზადება_init.d.py — ამზადებს start-stop სკრიპტებს კომპონენტისთვის შაბლონზე დაყრდნობით
deploy.py - იშლება და განაახლებს ახალ კომპონენტებს

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

ნაწილი II

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

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

ჩვენი ყველაზე ძვირფასი რესურსი არის ჩვენი დრო და ბევრი არ გვქონდა.

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

$ docker node ls
ID                            HOSTNAME            STATUS              AVAILABILITY        MANAGER STATUS      ENGINE VERSION
kilqc94pi2upzvabttikrfr5d     nop-test-1     Ready               Active                                  19.03.2
jilwe56pl2zvabupryuosdj78     nop-test-2     Ready               Active                                  19.03.2
j5a4yz1kr2xke6b1ohoqlnbq5 *   nop-test-3     Ready               Active              Leader              19.03.2

შემდეგი, შექმენით ქსელი:


$ docker network create --driver overlay --subnet 10.10.10.0/24 nw_swarm

შემდეგი, ჩვენ დავაკავშირეთ Gitlab-CI და Swarm კვანძები CI-დან კვანძების დისტანციური მართვის თვალსაზრისით: სერთიფიკატების დაყენება, საიდუმლო ცვლადების დაყენება და Docker სერვისის დაყენება საკონტროლო სერვერზე. ეს ერთი სტატიის დაგვიზოგა ბევრი დრო.

შემდეგ დავამატეთ სტეკის შექმნისა და განადგურების სამუშაოები .gitlab-ci .yml-ს.

კიდევ რამდენიმე ვაკანსია დაემატა .gitlab-ci .yml

## staging stage
deploy_staging:
  stage: testing
  before_script:
    - echo "override global 'before_script'"
  image: "REGISTRY:5000/docker:latest"
  environment: staging
  dependencies: []
  variables:
    DOCKER_CERT_PATH: "/certs"
    DOCKER_HOST: tcp://10.50.173.107:2376
    DOCKER_TLS_VERIFY: 1
    CI_BIN_DEPENDENCIES_JOB: "release.centos.7"
  script:
    - mkdir -p $DOCKER_CERT_PATH
    - echo "$TLSCACERT" > $DOCKER_CERT_PATH/ca.pem
    - echo "$TLSCERT" > $DOCKER_CERT_PATH/cert.pem
    - echo "$TLSKEY" > $DOCKER_CERT_PATH/key.pem
    - docker stack deploy -c docker-compose.yml ${CI_ENVIRONMENT_NAME}_${CI_COMMIT_REF_NAME} --with-registry-auth
    - rm -rf $DOCKER_CERT_PATH
  when: manual

## stop staging stage
stop_staging:
  stage: testing
  before_script:
    - echo "override global 'before_script'"
  image: "REGISTRY:5000/docker:latest"
  environment: staging
  dependencies: []
  variables:
    DOCKER_CERT_PATH: "/certs"
    DOCKER_HOST: tcp://10.50.173.107:2376
    DOCKER_TLS_VERIFY: 1
  script:
    - mkdir -p $DOCKER_CERT_PATH
    - echo "$TLSCACERT" > $DOCKER_CERT_PATH/ca.pem
    - echo "$TLSCERT" > $DOCKER_CERT_PATH/cert.pem
    - echo "$TLSKEY" > $DOCKER_CERT_PATH/key.pem
    - docker stack rm ${CI_ENVIRONMENT_NAME}_${CI_COMMIT_REF_NAME}
    # TODO: need check that stopped
  when: manual

ზემოთ მოცემული კოდის ფრაგმენტიდან ხედავთ, რომ ორი ღილაკი (deploy_staging, stop_staging) დაემატა Pipelines-ს, რომლებიც საჭიროებენ ხელით მოქმედებას.

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

docker-compose.yml

---
version: '3'

services:
  userprop:
    image: redis:alpine
    deploy:
      replicas: 1
      placement:
        constraints: [node.id == kilqc94pi2upzvabttikrfr5d]
      restart_policy:
        condition: none
    networks:
      nw_swarm:
  celery_bcd:
    image: redis:alpine
    deploy:
      replicas: 1
      placement:
        constraints: [node.id == kilqc94pi2upzvabttikrfr5d]
      restart_policy:
        condition: none
    networks:
      nw_swarm:

  schedulerdb:
    image: mariadb:latest
    environment:
      MYSQL_ALLOW_EMPTY_PASSWORD: 'yes'
      MYSQL_DATABASE: schedulerdb
      MYSQL_USER: ****
      MYSQL_PASSWORD: ****
    command: ['--character-set-server=utf8mb4', '--collation-server=utf8mb4_unicode_ci', '--explicit_defaults_for_timestamp=1']
    deploy:
      replicas: 1
      placement:
        constraints: [node.id == kilqc94pi2upzvabttikrfr5d]
      restart_policy:
        condition: none
    networks:
      nw_swarm:

  celerydb:
    image: mariadb:latest
    environment:
      MYSQL_ALLOW_EMPTY_PASSWORD: 'yes'
      MYSQL_DATABASE: celerydb
      MYSQL_USER: ****
      MYSQL_PASSWORD: ****
    deploy:
      replicas: 1
      placement:
        constraints: [node.id == kilqc94pi2upzvabttikrfr5d]
      restart_policy:
        condition: none
    networks:
      nw_swarm:

  cluster:
    image: $CENTOS7
    environment:
      - CENTOS
      - CI_ENVIRONMENT_NAME
      - CI_API_V4_URL
      - CI_REPOSITORY_URL
      - CI_PROJECT_ID
      - CI_PROJECT_URL
      - CI_PROJECT_PATH
      - CI_PROJECT_NAME
      - CI_COMMIT_REF_NAME
      - CI_BIN_DEPENDENCIES_JOB
    command: >
      sudo -u myusername -H /bin/bash -c ". /etc/profile &&
        mkdir -p /storage1/$CI_COMMIT_REF_NAME/$CI_PROJECT_NAME &&
        cd /storage1/$CI_COMMIT_REF_NAME/$CI_PROJECT_NAME &&
            git clone -b $CI_COMMIT_REF_NAME $CI_REPOSITORY_URL . &&
            curl $CI_API_V4_URL/projects/$CI_PROJECT_ID/jobs/artifacts/$CI_COMMIT_REF_NAME/download?job=$CI_BIN_DEPENDENCIES_JOB -o artifacts.zip &&
            unzip artifacts.zip ;
        cd /storage1/$CI_COMMIT_REF_NAME/$CI_PROJECT_NAME/scripts/deploy/ &&
            python3 createconfig.py -s $CI_ENVIRONMENT_NAME &&
            /bin/bash install_venv.sh -d -r ../../requirements.txt &&
            python3 prepare_init.d.py &&
            python3 deploy.py -s $CI_ENVIRONMENT_NAME"
    deploy:
      replicas: 1
      placement:
        constraints: [node.id == kilqc94pi2upzvabttikrfr5d]
      restart_policy:
        condition: none
    tty: true
    stdin_open: true
    networks:
      nw_swarm:

networks:
  nw_swarm:
    external: true

აქ ხედავთ, რომ კომპონენტები დაკავშირებულია ერთი ქსელით (nw_swarm) და ხელმისაწვდომია ერთმანეთისთვის.

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

გიტის კლონი... - მიიღეთ განსათავსებლად საჭირო ფაილები (createconfig.py, install_venv.sh და ა.შ.)
დახვევა... && გახსნა... - ჩამოტვირთეთ და გახსენით build artifacts (შედგენილი უტილიტები)

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

.gitlab-ci.yml-ში, კლასტერული სტეკის განლაგების შემდეგ, ჩვენ ვამატებთ ბალანსერის განლაგების ხაზს (რომელიც ჩადენის დროს მხოლოდ განაახლებს მის კონფიგურაციას (ქმნის ახალ nginx კონფიგურაციის ფაილებს შაბლონის მიხედვით: /etc/nginx/conf. d/${CI_COMMIT_REF_NAME}.conf) - იხილეთ docker-compose-nginx.yml კოდი)

    - docker stack deploy -c docker-compose-nginx.yml ${CI_ENVIRONMENT_NAME} --with-registry-auth

docker-compose-nginx.yml

---
version: '3'

services:
  nginx:
    image: nginx:latest
    environment:
      CI_COMMIT_REF_NAME: ${CI_COMMIT_REF_NAME}
      NGINX_CONFIG: |-
            server {
                listen 8080;
                server_name staging_${CI_COMMIT_REF_NAME}_cluster.dev;

                location / {
                    proxy_pass http://staging_${CI_COMMIT_REF_NAME}_cluster:8080;
                }
            }
            server {
                listen 5555;
                server_name staging_${CI_COMMIT_REF_NAME}_cluster.dev;

                location / {
                    proxy_pass http://staging_${CI_COMMIT_REF_NAME}_cluster:5555;
                }
            }
    volumes:
      - /tmp/staging/nginx:/etc/nginx/conf.d
    command:
      /bin/bash -c "echo -e "$$NGINX_CONFIG" > /etc/nginx/conf.d/${CI_COMMIT_REF_NAME}.conf;
        nginx -g "daemon off;";
        /etc/init.d/nginx reload"
    ports:
      - 8080:8080
      - 5555:5555
      - 3000:3000
      - 443:443
      - 80:80
    deploy:
      replicas: 1
      placement:
        constraints: [node.id == kilqc94pi2upzvabttikrfr5d]
      restart_policy:
        condition: none
    networks:
      nw_swarm:

networks:
  nw_swarm:
    external: true

დეველოპერულ კომპიუტერებზე განაახლეთ /etc/hosts; დაწერეთ url nginx-ზე:

10.50.173.106 staging_BRANCH-1831_cluster.dev
ასე რომ, განხორციელდა იზოლირებული დადგმის კლასტერების განლაგება და დეველოპერებს ახლა შეუძლიათ მათი გაშვება ნებისმიერი რაოდენობით, რომელიც საკმარისია მათი ამოცანების შესამოწმებლად.

Მომავლის გეგმები:

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

განსაკუთრებული მადლობა მუხლი.

წყარო: www.habr.com

განათავსეთ აპლიკაციები Docker Swarm-ით

I ნაწილი

ნაწილი II

ახალი კომენტარის დამატება

განათავსეთ აპლიკაციები Docker Swarm-ით

I ნაწილი

ნაწილი II

ახალი კომენტარის დამატება პასუხის გასაუქმებლად

ახალი კომენტარის დამატება