🥇डॉकर झुंड का उपयोग करके एप्लिकेशन परिनियोजित करें

जिस ऑनलाइन वीडियो सामग्री अनुशंसा प्रणाली पर हम काम कर रहे हैं वह एक बंद व्यावसायिक विकास है और तकनीकी रूप से मालिकाना और खुले स्रोत घटकों का एक बहु-घटक क्लस्टर है। इस लेख को लिखने का उद्देश्य सीमित समय की शर्तों के तहत हमारी प्रक्रियाओं के स्थापित वर्कफ़्लो को बाधित किए बिना, एक स्टेजिंग प्लेटफ़ॉर्म के लिए डॉकर झुंड क्लस्टरिंग सिस्टम के कार्यान्वयन का वर्णन करना है। आपके ध्यानार्थ प्रस्तुत कथा दो भागों में विभाजित है। पहला भाग डॉकर झुंड का उपयोग करने से पहले सीआई/सीडी का वर्णन करता है, और दूसरा भाग इसे लागू करने की प्रक्रिया का वर्णन करता है। जिन लोगों को पहला भाग पढ़ने में रुचि नहीं है वे सुरक्षित रूप से दूसरे भाग की ओर बढ़ सकते हैं।

भाग I

एक समय, जितनी जल्दी हो सके सीआई/सीडी प्रक्रिया स्थापित करने की आवश्यकता थी। शर्तों में से एक डॉकर का उपयोग नहीं करना था तैनाती के लिए कई कारणों से विकसित किए जा रहे घटक:

उत्पादन में घटकों के अधिक विश्वसनीय और स्थिर संचालन के लिए (अर्थात, संक्षेप में, वर्चुअलाइजेशन का उपयोग न करने की आवश्यकता)
प्रमुख डेवलपर्स डॉकर के साथ काम नहीं करना चाहते थे (अजीब बात है, लेकिन ऐसा ही था)
अनुसंधान एवं विकास प्रबंधन के वैचारिक कारणों से

एमवीपी के लिए बुनियादी ढाँचा, स्टैक और अनुमानित प्रारंभिक आवश्यकताएँ इस प्रकार थीं:

डेबियन के साथ 4 Intel® X5650 सर्वर (पूरी तरह से विकास के लिए एक और शक्तिशाली मशीन)
आपके स्वयं के कस्टम घटकों का विकास C++, Python3 में किया जाता है
प्रयुक्त मुख्य तृतीय पक्ष उपकरण: काफ्का, क्लिकहाउस, एयरफ्लो, रेडिस, ग्राफाना, पोस्टग्रेस्क्ल, माइस्क्ल,…
डिबग और रिलीज़ के लिए अलग-अलग घटकों के निर्माण और परीक्षण के लिए पाइपलाइन

प्रारंभिक चरण में हल किए जाने वाले पहले प्रश्नों में से एक यह है कि किसी भी वातावरण (सीआई/सीडी) में कस्टम घटकों को कैसे तैनात किया जाएगा।

हमने तृतीय-पक्ष घटकों को व्यवस्थित रूप से स्थापित करने और उन्हें व्यवस्थित रूप से अद्यतन करने का निर्णय लिया। C++ या Python में विकसित कस्टम एप्लिकेशन को कई तरीकों से तैनात किया जा सकता है। उनमें से, उदाहरण के लिए: सिस्टम पैकेज बनाना, उन्हें एकत्रित छवियों के भंडार में भेजना और सर्वर पर उनकी बाद की स्थापना। पहले से ही अज्ञात कारण से, एक और तरीका चुना गया था, अर्थात्: सीआई का उपयोग करके, एप्लिकेशन निष्पादन योग्य फ़ाइलों को संकलित किया जाता है, एक वर्चुअल प्रोजेक्ट वातावरण बनाया जाता है, require.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 - बाद की तैनाती (प्रीप्रोडक्शन, प्रोडक्शन, टेस्टिंग, ...) के लिए विभिन्न वातावरणों में घटकों के लिए सेटिंग्स के साथ एक सेटिंग्स.आईएनआई फ़ाइल बनाता है।
install_venv.sh - एक विशिष्ट निर्देशिका में py घटकों के लिए एक वर्चुअल वातावरण बनाता है और इसे दूरस्थ सर्वर पर कॉपी करता है
तैयार_init.d.py - टेम्पलेट के आधार पर स्टार्ट-स्टॉप घटकों के लिए स्क्रिप्ट तैयार करता है
Deploy.py - नए घटकों को तैनात और पुनः आरंभ करता है

वक्त निकल गया। मंचन चरण का स्थान प्रीप्रोडक्शन और प्रोडक्शन ने ले लिया। उत्पाद के लिए समर्थन एक और वितरण (CentOS) पर जोड़ा गया है। अन्य 5 शक्तिशाली भौतिक सर्वर और एक दर्जन वर्चुअल सर्वर जोड़े गए। और डेवलपर्स और परीक्षकों के लिए कामकाजी स्थिति के लगभग करीब के वातावरण में अपने कार्यों का परीक्षण करना कठिन हो गया। इस समय यह स्पष्ट हो गया कि उसके बिना ऐसा करना असंभव था...

भाग II

तो, हमारा क्लस्टर कुछ दर्जन अलग-अलग घटकों की एक शानदार प्रणाली है जिसका वर्णन Dockerfiles द्वारा नहीं किया गया है। आप इसे केवल सामान्य रूप से किसी विशिष्ट वातावरण में परिनियोजन के लिए कॉन्फ़िगर कर सकते हैं। हमारा कार्य क्लस्टर को प्री-रिलीज़ परीक्षण से पहले परीक्षण करने के लिए एक स्टेजिंग वातावरण में तैनात करना है।

सैद्धांतिक रूप से, एक साथ कई क्लस्टर काम कर सकते हैं: जितने कार्य पूर्ण स्थिति में हों या पूरा होने के करीब हों। हमारे पास उपलब्ध सर्वरों की शक्ति हमें प्रत्येक सर्वर पर कई क्लस्टर चलाने की अनुमति देती है। प्रत्येक स्टेजिंग क्लस्टर को अलग किया जाना चाहिए (पोर्ट, निर्देशिका आदि में कोई ओवरलैप नहीं होना चाहिए)।

हमारा सबसे मूल्यवान संसाधन हमारा समय है, और हमारे पास इसका ज़्यादा हिस्सा नहीं था।

तेज़ शुरुआत के लिए, हमने इसकी सादगी और लचीली वास्तुकला के कारण डॉकर स्वार्म को चुना। पहला काम जो हमने किया वह दूरस्थ सर्वर पर एक प्रबंधक और कई नोड बनाना था:

$ 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 .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

उपरोक्त कोड खंड से यह स्पष्ट है कि पाइपलाइनों (डिप्लॉय_स्टेजिंग, स्टॉप_स्टेजिंग) में दो बटन जोड़े गए हैं जिनके लिए मैन्युअल कार्रवाई की आवश्यकता होती है।

स्टैक का नाम शाखा के नाम से मेल खाता है और यह विशिष्टता पर्याप्त होनी चाहिए। स्टैक में सेवाएँ अद्वितीय आईपी पते, और पोर्ट, निर्देशिकाएँ आदि प्राप्त करती हैं। अलग किया जाएगा, लेकिन स्टैक से स्टैक तक समान (चूंकि कॉन्फ़िगरेशन फ़ाइल सभी स्टैक के लिए समान है) - यही हम चाहते थे। हम स्टैक (क्लस्टर) का उपयोग करके तैनात करते हैं डोकर-compose.yml, जो हमारे क्लस्टर का वर्णन करता है।

डोकर-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) से जुड़े हुए हैं और एक दूसरे तक पहुंच योग्य हैं।

सिस्टम घटकों (रेडिस, मायएसक्यूएल पर आधारित) को कस्टम घटकों के सामान्य पूल से अलग किया जाता है (योजनाओं में, कस्टम घटकों को सेवाओं के रूप में भी विभाजित किया जाता है)। हमारे क्लस्टर का परिनियोजन चरण सीएमडी को हमारी एक बड़ी कॉन्फ़िगर की गई छवि में स्थानांतरित करने जैसा दिखता है और सामान्य तौर पर, व्यावहारिक रूप से भाग I में वर्णित परिनियोजन से अलग नहीं है। मैं अंतरों पर जोर दूंगा:

गिट क्लोन... - हमें परिनियोजन करने के लिए आवश्यक फ़ाइलें मिलती हैं (createconfig.py, install_venv.sh, आदि)
कर्ल... && खोलना... - बिल्ड कलाकृतियों को डाउनलोड करें और अनज़िप करें (संकलित उपयोगिताएँ)

केवल एक ही समस्या है जिसका अभी तक वर्णन नहीं किया गया है: जिन घटकों में वेब इंटरफ़ेस है वे डेवलपर्स के ब्राउज़र से पहुंच योग्य नहीं हैं। हम इस समस्या को रिवर्स प्रॉक्सी का उपयोग करके हल करते हैं, इस प्रकार:

.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 अपडेट करें; यूआरएल को nginx पर सेट करें:

10.50.173.106 staging_BRANCH-1831_cluster.dev
इसलिए, पृथक स्टेजिंग क्लस्टरों की तैनाती लागू कर दी गई है और डेवलपर्स अब उन्हें अपने कार्यों का परीक्षण करने के लिए पर्याप्त मात्रा में लॉन्च कर सकते हैं।

भविष्य की योजनाएं:

हमारे घटकों को सेवाओं के रूप में अलग करें
प्रत्येक के लिए एक Dockerfile बनाएं
स्टैक में कम लोड किए गए नोड्स का स्वचालित रूप से पता लगाएं
नाम टेम्पलेट का उपयोग करके नोड्स निर्दिष्ट करें (लेख में आईडी का उपयोग करने के बजाय)
एक चेक जोड़ें कि स्टैक नष्ट हो गया है
...

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

स्रोत: www.habr.com

डॉकर झुंड का उपयोग करके एप्लिकेशन परिनियोजित करें

भाग I

भाग II

एक टिप्पणी जोड़ें उत्तर रद्द