ProHoster > بلاګ > اداره > د ډاکر سوارم په کارولو سره غوښتنلیکونه ځای په ځای کړئ

د ډاکر سوارم په کارولو سره غوښتنلیکونه ځای په ځای کړئ

د آنلاین ویډیو مینځپانګې سپارښتنې سیسټم چې موږ یې کار کوو یو تړل شوی سوداګریز پرمختګ دی او په تخنیکي ډول د ملکیت او خلاصې سرچینې اجزاو څو برخې کلستر دی. د دې مقالې لیکلو هدف د سټیجینګ پلیټ فارم لپاره د ډاکر سوارم کلسترینګ سیسټم پلي کول تشریح کول دي ، پرته لدې چې د محدود وخت شرایطو لاندې زموږ د پروسو رامینځته شوي کاري جریان ګډوډ کړي. ستاسو پام ته وړاندې شوی داستان په دوو برخو ویشل شوی دی. لومړۍ برخه د ډاکر سوارم کارولو دمخه CI/CD تشریح کوي ، او دویمه برخه یې د پلي کولو پروسه تشریح کوي. هغه څوک چې د لومړۍ برخې لوستلو سره علاقه نلري کولی شي په خوندي ډول دویمه برخه ته لاړ شي.

لومړۍ برخه

په یو وخت کې، اړتیا وه چې ژر تر ژره د CI/CD پروسې تنظیم کړئ. یو شرط دا و چې د ډاکر نه کار واخلئ د ګمارنې لپاره اجزا د ډیری دلایلو لپاره رامینځته کیږي:

  • په تولید کې د اجزاو د لا باوري او باثباته عملیاتو لپاره (د مثال په توګه ، د مجازی کولو نه کارولو اړتیا)
  • مخکښ پراختیا کونکي نه غوښتل د ډاکر سره کار وکړي (عجیب ، مګر دا څنګه و)
  • د R&D مدیریت ایډیالوژیکي دلیلونو لپاره

د MVP لپاره زیربنا، سټیک او نږدې ابتدايي اړتیاوې په لاندې ډول وې:

  • د Debian سره 4 Intel® X5650 سرورونه (یو بل پیاوړی ماشین په بشپړ ډول د پراختیا لپاره)
  • ستاسو د خپل دودیز اجزاوو پراختیا په C++، Python3 کې ترسره کیږي
  • د دریمې ډلې اصلي وسیلې کارول کیږي: کافکا، کلیک هاوس، ایر فلو، ریډیس، ګرافانا، پوسټګریسکیل، مای ایس کیو ایل، ...
  • د ډیبګ او خوشې کولو لپاره جلا جلا اجزاو جوړولو او ازموینې لپاره پایپ لاینونه

یو له لومړیو پوښتنو څخه چې اړتیا ورته په لومړي مرحله کې حل کیږي دا ده چې دودیز اجزا به په کوم چاپیریال کې ځای په ځای شي (CI/CD).

موږ پریکړه وکړه چې د دریمې ډلې برخې په سیسټمیک ډول نصب کړو او په سیسټمیک ډول یې تازه کړو. په C++ یا Python کې رامینځته شوي دودیز غوښتنلیکونه په څو لارو ځای په ځای کیدی شي. د دوی په مینځ کې ، د مثال په توګه: د سیسټم کڅوړې رامینځته کول ، د راټول شوي عکسونو ذخیره کولو ته لیږل او په سرورونو کې د دوی وروسته نصب کول. د دمخه نامعلوم دلیل لپاره ، بل میتود غوره شوی ، د بیلګې په توګه: د CI په کارولو سره ، د غوښتنلیک اجرا وړ فایلونه تالیف شوي ، د مجازی پروژې چاپیریال رامینځته کیږي ، د need.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

دا د یادونې وړ ده چې مجلس او ازموینه په خپل عکس کې ترسره کیږي ، چیرې چې د سیسټم ټول اړین کڅوړې دمخه نصب شوي او نور تنظیمات رامینځته شوي.

که څه هم په دندو کې د دې سکریپټونو څخه هر یو په خپله طریقه په زړه پورې دی، زه به یقینا د دوی په اړه خبرې ونه کړم؛ د دوی هر یو تشریح کول به د پام وړ وخت ونیسي او دا د مقالې موخه نه ده. اجازه راکړئ یوازې ستاسو پام دې حقیقت ته واړوم چې د پلي کولو مرحله د زنګ وهلو سکریپټونو ترتیب څخه جوړه ده:

  1. createconfig.py - د راتلونکو ګمارلو لپاره په مختلف چاپیریال کې د اجزاوو لپاره د ترتیباتو سره د Settings.ini فایل رامینځته کوي (مخکینۍ تولید، تولید، ازموینه، ...)
  2. install_venv.sh - په یوه ځانګړي لارښود کې د py اجزاو لپاره مجازی چاپیریال رامینځته کوي او لرې پرتو سرورونو ته یې کاپي کوي
  3. تیاری_init.d.py - د ټیمپلیټ پراساس د پیل سټاپ اجزاو لپاره سکریپټونه چمتو کوي
  4. 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

د پورتنۍ کوډ برخې څخه دا روښانه ده چې دوه تڼۍ په پایپ لاینونو کې اضافه شوي (د ډیپلای_سټینګ، سټاپ_سټینګ) چې لاسي عمل ته اړتیا لري.

د ډاکر سوارم په کارولو سره غوښتنلیکونه ځای په ځای کړئ
د سټیک نوم د څانګې نوم سره سمون لري او دا انفرادیت باید کافي وي. په سټیک کې خدمتونه ځانګړي IP پتې ترلاسه کوي ، او بندرونه ، لارښودونه او داسې نور. جلا به وي، مګر د سټیک څخه سټیک ته ورته (ځکه چې د ترتیب کولو فایل د ټولو سټیکونو لپاره ورته دی) - دا هغه څه دي چې موږ یې غوښتل. موږ د سټیک (کلستر) په کارولو سره ځای په ځای کوو ډاکر - 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) لخوا وصل شوي او یو بل ته د لاسرسي وړ دي.

د سیسټم برخې (د redis، mysql پر بنسټ) د ګمرک اجزاو عمومي حوض څخه جلا شوي (په پالنونو کې، دودیز برخې هم د خدماتو په توګه ویشل شوي). زموږ د کلستر د پلي کولو مرحله داسې ښکاري چې زموږ یو لوی ترتیب شوي عکس ته د CMD لیږدولو په څیر ښکاري او په عموم کې، په عملي توګه په لومړۍ برخه کې بیان شوي له ګمارلو څخه توپیر نلري. زه به په توپیرونو ټینګار وکړم:

  • git کلون... - موږ د پلي کولو ترسره کولو لپاره اړین فایلونه ترلاسه کوو (createconfig.py، install_venv.sh، etc.)
  • curl... && unzip... - د ساختماني اثارو ډاونلوډ او خلاص کړئ (تالیف شوي اسانتیاوې)

دلته یوازې یوه ناڅرګنده ستونزه شتون لري: هغه برخې چې ویب انٹرفیس لري د پراختیا کونکو براوزرونو څخه د لاسرسي وړ ندي. موږ دا ستونزه د ریورس پراکسي په کارولو سره حل کوو، پدې توګه:

په .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

نو، د جلا شوي سټیجینګ کلسترونو ګمارل پلي شوي او پراختیا کونکي اوس کولی شي دوی د دوی دندو ازموینې لپاره په کافي مقدار کې په لاره واچوي.

راتلونکي پلانونه:

  • زموږ برخې د خدماتو په توګه جلا کړئ
  • د هر یو لپاره ډاکر فایل جوړ کړئ
  • په سټیک کې په اتوماتيک ډول لږ بار شوي نوډونه کشف کړئ
  • د نوم ټیمپلیټ په کارولو سره نوډونه مشخص کړئ (د دې پرځای چې په مقاله کې د ID کارولو پرځای)
  • یو چک اضافه کړئ چې سټیک ویجاړ شوی
  • ...

لپاره ځانګړې مننه مقاله.

سرچینه: www.habr.com

Add a comment