🥇 डकर स्वार्म प्रयोग गरेर अनुप्रयोगहरू प्रयोग गर्नुहोस्

हामीले काम गरिरहेका अनलाइन भिडियो सामग्री सिफारिस प्रणाली एक बन्द व्यावसायिक विकास हो र प्राविधिक रूपमा स्वामित्व र खुला स्रोत कम्पोनेन्टहरूको बहु-कम्पोनेन्ट क्लस्टर हो। यो लेख लेख्नुको उद्देश्य एक स्टेजिङ प्लेटफर्मको लागि डकर स्वार्म क्लस्टरिङ प्रणालीको कार्यान्वयनलाई वर्णन गर्नु हो, सीमित समयका सर्तहरूमा हाम्रा प्रक्रियाहरूको स्थापित कार्यप्रवाहमा बाधा नपर्ने। तपाईंको ध्यानाकर्षणको लागि प्रस्तुत कथालाई दुई भागमा विभाजन गरिएको छ। पहिलो भागले डकर स्वार्म प्रयोग गर्नु अघि CI/CD को वर्णन गर्दछ, र दोस्रो भागले यसलाई कार्यान्वयन गर्ने प्रक्रियाको वर्णन गर्दछ। पहिलो भाग पढ्न रुचि नभएकाहरू सुरक्षित रूपमा दोस्रो भागमा जान सक्छन्।

भाग I

एक पटक, त्यहाँ सकेसम्म चाँडो CI/CD प्रक्रिया सेट अप गर्न आवश्यक थियो। सर्तहरू मध्ये एक डकर प्रयोग नगर्नु थियो तैनाती को लागी कम्पोनेन्टहरू धेरै कारणहरूको लागि विकसित भइरहेका छन्:

उत्पादनमा कम्पोनेन्टहरूको थप भरपर्दो र स्थिर सञ्चालनको लागि (अर्थात, सारमा, भर्चुअलाइजेशन प्रयोग नगर्ने आवश्यकता)
प्रमुख विकासकर्ताहरू डकरसँग काम गर्न चाहँदैनन् (अनौठो, तर यो कस्तो थियो)
R&D व्यवस्थापनको वैचारिक कारणहरूका लागि

MVP को लागि पूर्वाधार, स्ट्याक र अनुमानित प्रारम्भिक आवश्यकताहरू निम्नानुसार थिए:

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

प्रारम्भिक चरणमा समाधान गर्न आवश्यक पर्ने पहिलो प्रश्नहरू मध्ये एउटा भनेको कुनै पनि वातावरण (CI/CD) मा कस्टम कम्पोनेन्टहरू कसरी प्रयोग गरिनेछ।

हामीले तेस्रो-पक्ष कम्पोनेन्टहरू प्रणालीगत रूपमा स्थापना गर्ने र तिनीहरूलाई प्रणालीगत रूपमा अद्यावधिक गर्ने निर्णय गर्यौं। C++ वा पाइथनमा विकसित गरिएका अनुकूलन अनुप्रयोगहरू धेरै तरिकामा प्रयोग गर्न सकिन्छ। तिनीहरू मध्ये, उदाहरणका लागि: प्रणाली प्याकेजहरू सिर्जना गर्दै, सङ्कलन गरिएका छविहरूको भण्डारमा पठाउने र सर्भरहरूमा तिनीहरूको पछिको स्थापना। पहिले नै अज्ञात कारणको लागि, अर्को विधि छनोट गरिएको थियो, अर्थात्: CI प्रयोग गरेर, अनुप्रयोग कार्यान्वयनयोग्य फाइलहरू कम्पाइल गरिन्छ, एक भर्चुअल परियोजना वातावरण सिर्जना गरिन्छ, आवश्यकताहरूबाट 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 शक्तिशाली भौतिक सर्भर र एक दर्जन भर्चुअल थपियो। र विकासकर्ताहरू र परीक्षकहरूलाई काम गर्ने अवस्थाको नजिकको वातावरणमा उनीहरूको कार्यहरू परीक्षण गर्न झन्झन् गाह्रो भयो। यस समयमा यो स्पष्ट भयो कि यो उहाँ बिना गर्न असम्भव थियो ...

भाग दोस्रो

त्यसोभए, हाम्रो क्लस्टर 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

अर्को, हामीले 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) - कोड 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 मा url सेट गर्नुहोस्:

10.50.173.106 staging_BRANCH-1831_cluster.dev
त्यसोभए, पृथक स्टेजिङ क्लस्टरहरूको तैनाती लागू गरिएको छ र विकासकर्ताहरूले अब तिनीहरूलाई उनीहरूको कार्यहरू परीक्षण गर्न पर्याप्त मात्रामा सुरू गर्न सक्छन्।

भावी योजनाहरु:

सेवाहरूको रूपमा हाम्रा कम्पोनेन्टहरू अलग गर्नुहोस्
प्रत्येकको लागि डकरफाइल सिर्जना गर्नुहोस्
स्ट्याकमा कम लोड नोडहरू स्वचालित रूपमा पत्ता लगाउनुहोस्
नाम टेम्प्लेट प्रयोग गरेर नोडहरू निर्दिष्ट गर्नुहोस् (लेखमा जस्तै आईडी प्रयोग गर्नुको सट्टा)
स्ट्याक नष्ट भएको जाँच थप्नुहोस्
...

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

स्रोत: www.habr.com

डकर स्वार्म प्रयोग गरेर अनुप्रयोगहरू प्रयोग गर्नुहोस्

भाग I

भाग दोस्रो

एक टिप्पणी थप्न Отменить ответ