🥇डॉकर स्वॉर्म वापरून अनुप्रयोग उपयोजित करा

आम्ही ज्या ऑनलाइन व्हिडिओ सामग्री शिफारस प्रणालीवर काम करत आहोत ती एक बंद व्यावसायिक विकास आहे आणि तांत्रिकदृष्ट्या मालकी आणि मुक्त स्रोत घटकांचा एक बहु-घटक क्लस्टर आहे. हा लेख लिहिण्याचा उद्देश स्टेजिंग प्लॅटफॉर्मसाठी डॉकर स्वॉर्म क्लस्टरिंग सिस्टमच्या अंमलबजावणीचे वर्णन करणे हा आहे, मर्यादित वेळेच्या परिस्थितीत आमच्या प्रक्रियेच्या स्थापित कार्यप्रवाहात व्यत्यय न आणता. आपल्या लक्ष वेधण्यासाठी सादर केलेले वर्णन दोन भागात विभागले गेले आहे. पहिला भाग डॉकर स्वॉर्म वापरण्यापूर्वी CI/CD चे वर्णन करतो आणि दुसरा भाग ते लागू करण्याच्या प्रक्रियेचे वर्णन करतो. ज्यांना पहिला भाग वाचण्यात स्वारस्य नाही ते सुरक्षितपणे दुसऱ्या भागावर जाऊ शकतात.

भाग I

एकेकाळी, शक्य तितक्या लवकर CI/CD प्रक्रिया सेट करण्याची गरज होती. डॉकर न वापरण्याची एक अट होती तैनातीसाठी अनेक कारणांसाठी घटक विकसित केले जातात:

उत्पादनातील घटकांच्या अधिक विश्वासार्ह आणि स्थिर ऑपरेशनसाठी (म्हणजेच, व्हर्च्युअलायझेशन न वापरण्याची आवश्यकता)
आघाडीच्या विकसकांना डॉकरसोबत काम करायचे नव्हते (विचित्र, पण ते असेच होते)
R&D व्यवस्थापनाच्या वैचारिक कारणांसाठी

MVP साठी पायाभूत सुविधा, स्टॅक आणि अंदाजे प्रारंभिक आवश्यकता खालीलप्रमाणे होत्या:

Debian सह 4 Intel® X5650 सर्व्हर (विकासासाठी पूर्णपणे एक अधिक शक्तिशाली मशीन)
तुमच्या स्वतःच्या सानुकूल घटकांचा विकास C++, Python3 मध्ये केला जातो
वापरलेली मुख्य 3rdparty टूल्स: Kafka, Clickhouse, Airflow, Redis, Grafana, Postgresql, Mysql, …
डीबग आणि रिलीझसाठी स्वतंत्रपणे घटक तयार करण्यासाठी आणि चाचणी करण्यासाठी पाइपलाइन

कोणत्याही वातावरणात (CI/CD) सानुकूल घटक कसे उपयोजित केले जातील हे प्रारंभिक टप्प्यावर सोडवणे आवश्यक असलेल्या पहिल्या प्रश्नांपैकी एक आहे.

आम्ही तृतीय-पक्ष घटक पद्धतशीरपणे स्थापित करण्याचा आणि त्यांना पद्धतशीरपणे अद्यतनित करण्याचा निर्णय घेतला. C++ किंवा Python मध्‍ये विकसित केलेले सानुकूल अनुप्रयोग अनेक प्रकारे उपयोजित केले जाऊ शकतात. त्यापैकी, उदाहरणार्थ: सिस्टम पॅकेजेस तयार करणे, त्यांना एकत्रित केलेल्या प्रतिमांच्या भांडारात पाठवणे आणि सर्व्हरवर त्यांची त्यानंतरची स्थापना. आधीच अज्ञात कारणास्तव, दुसरी पद्धत निवडली गेली, ती म्हणजे: CI वापरून, ऍप्लिकेशन एक्झिक्युटेबल फाइल्स संकलित केल्या जातात, एक आभासी प्रकल्प वातावरण तयार केले जाते, requirements.txt वरून py मॉड्यूल स्थापित केले जातात आणि या सर्व कलाकृती कॉन्फिगरेशन, स्क्रिप्ट आणि सोबत पाठवल्या जातात. सर्व्हरवर सोबत असलेले ऍप्लिकेशन वातावरण. पुढे, प्रशासक अधिकारांशिवाय आभासी वापरकर्त्याकडून अनुप्रयोग लाँच केले जातात.

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 घटकांसाठी आभासी वातावरण तयार करते आणि ते रिमोट सर्व्हरवर कॉपी करते
ready_init.d.py — टेम्पलेटवर आधारित स्टार्ट-स्टॉप घटकांसाठी स्क्रिप्ट तयार करते
deploy.py — नवीन घटक तैनात आणि रीस्टार्ट करते

वेळ निघून गेली. स्टेजिंग स्टेजची जागा पूर्वउत्पादन आणि उत्पादनाने घेतली. उत्पादनासाठी समर्थन आणखी एका वितरणावर (CentOS) जोडले गेले आहे. आणखी 5 शक्तिशाली भौतिक सर्व्हर आणि डझनभर आभासी सर्व्हर जोडले गेले. आणि डेव्हलपर आणि परीक्षकांना त्यांच्या कार्यांची कमी-अधिक प्रमाणात कार्यरत स्थितीच्या जवळ असलेल्या वातावरणात चाचणी घेणे कठीण होत गेले. यावेळी हे स्पष्ट झाले की त्याच्याशिवाय करणे अशक्य आहे ...

भाग दुसरा

तर, आमचा क्लस्टर डॉकरफाईल्सने वर्णन केलेले नाही अशा दोन डझन वैयक्तिक घटकांची एक नेत्रदीपक प्रणाली आहे. तुम्ही ते फक्त सर्वसाधारणपणे विशिष्ट वातावरणात तैनात करण्यासाठी कॉन्फिगर करू शकता. प्री-रिलीझ चाचणीपूर्वी त्याची चाचणी घेण्यासाठी क्लस्टरला स्टेजिंग वातावरणात तैनात करणे हे आमचे कार्य आहे.

सैद्धांतिकदृष्ट्या, एकाच वेळी अनेक क्लस्टर्स कार्यरत असू शकतात: पूर्ण झालेल्या स्थितीत किंवा पूर्णत्वाच्या जवळ असलेली कार्ये. आमच्या विल्हेवाटीवर असलेल्या सर्व्हरची शक्ती आम्हाला प्रत्येक सर्व्हरवर अनेक क्लस्टर्स चालविण्यास अनुमती देते. प्रत्येक स्टेजिंग क्लस्टर वेगळे केले जाणे आवश्यक आहे (पोर्ट्स, डिरेक्टरी इ. मध्ये ओव्हरलॅप नसावे).

आमचा सर्वात मौल्यवान स्त्रोत हा आमचा वेळ आहे आणि आमच्याकडे ते जास्त नव्हते.

जलद सुरुवात करण्यासाठी, आम्ही डॉकर स्वॉर्म त्याच्या साधेपणामुळे आणि लवचिक आर्किटेक्चरमुळे निवडले. आम्ही केलेली पहिली गोष्ट म्हणजे रिमोट सर्व्हरवर व्यवस्थापक आणि अनेक नोड्स तयार करणे:

$ 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

पुढे, आम्ही CI कडील नोड्सच्या रिमोट मॅनेजमेंटच्या दृष्टीने Gitlab-CI आणि Swarm नोड्स कनेक्ट केले: प्रमाणपत्रे स्थापित करणे, गुप्त व्हेरिएबल्स सेट करणे आणि व्यवस्थापन सर्व्हरवर डॉकर सेवा देखील सेट करणे. हा एक लेख आमचा बराच वेळ वाचला.

पुढे, आम्ही .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) ज्यांना मॅन्युअल क्रिया आवश्यक आहे.

स्टॅकचे नाव शाखेच्या नावाशी जुळते आणि हे वेगळेपण पुरेसे असावे. स्टॅकमधील सेवांना अद्वितीय 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) जोडलेले आहेत आणि एकमेकांना प्रवेश करण्यायोग्य आहेत.

सिस्टम घटक (redis, mysql वर आधारित) सानुकूल घटकांच्या सामान्य पूलपासून वेगळे केले जातात (योजनांमध्ये, सानुकूल घटक देखील सेवा म्हणून विभागले जातात). आमच्या क्लस्टरची तैनाती अवस्था आमच्या एका मोठ्या कॉन्फिगर केलेल्या प्रतिमेमध्ये CMD हस्तांतरित केल्यासारखी दिसते आणि सर्वसाधारणपणे, भाग I मध्ये वर्णन केलेल्या तैनातीपेक्षा व्यावहारिकदृष्ट्या भिन्न नाही. मी फरकांवर जोर देईन:

git क्लोन... — उपयोजन (createconfig.py, install_venv.sh, इ.) करण्यासाठी आवश्यक फाइल्स मिळतात.
कर्ल... && अनझिप... - बिल्ड आर्टिफॅक्ट डाउनलोड आणि अनझिप करा (संकलित उपयुक्तता)

अद्याप अवर्णित समस्या फक्त एक आहे: वेब इंटरफेस असलेले घटक विकसकांच्या ब्राउझरमधून प्रवेश करण्यायोग्य नाहीत. आम्ही रिव्हर्स प्रॉक्सी वापरून ही समस्या सोडवतो, अशा प्रकारे:

.gitlab-ci.yml मध्ये, क्लस्टर स्टॅक तैनात केल्यानंतर, बॅलन्सर तैनात करण्यासाठी एक ओळ जोडा (जे, वचनबद्ध असताना, फक्त त्याचे कॉन्फिगरेशन अद्यतनित करते (टेम्प्लेटनुसार नवीन nginx कॉन्फिगरेशन फाइल्स तयार करते: /etc/nginx/conf.d) /${CI_COMMIT_REF_NAME}.conf) - कोड डॉकर-कंपोज-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; nginx वर url सेट करा:

10.50.173.106 staging_BRANCH-1831_cluster.dev
त्यामुळे, वेगळ्या स्टेजिंग क्लस्टरची तैनाती लागू करण्यात आली आहे आणि विकासक आता त्यांची कार्ये तपासण्यासाठी पुरेशा प्रमाणात त्यांना लॉन्च करू शकतात.

भविष्यातील योजना:

सेवा म्हणून आमचे घटक वेगळे करा
प्रत्येकासाठी एक डॉकरफाइल तयार करा
स्टॅकमध्ये कमी लोड केलेले नोड्स स्वयंचलितपणे शोधा
नाव टेम्पलेट वापरून नोड्स निर्दिष्ट करा (लेखातील आयडी वापरण्याऐवजी)
स्टॅक नष्ट झाल्याचे चेक जोडा
...

साठी विशेष धन्यवाद एक लेख.

स्त्रोत: www.habr.com

डॉकर स्वॉर्म वापरून अनुप्रयोग तैनात करा

भाग I

भाग दुसरा

एक टिप्पणी जोडा Отменить ответ