🥇ដាក់ពង្រាយកម្មវិធីជាមួយ Docker Swarm

ប្រព័ន្ធណែនាំមាតិកាវីដេអូអនឡាញដែលយើងកំពុងធ្វើការគឺជាការអភិវឌ្ឍន៍ពាណិជ្ជកម្មបិទជិត ហើយតាមបច្ចេកទេសជាចង្កោមពហុផ្នែកនៃសមាសធាតុកម្មសិទ្ធិ និងប្រភពបើកចំហ។ គោលបំណងនៃការសរសេរអត្ថបទនេះគឺដើម្បីពិពណ៌នាអំពីការអនុវត្តប្រព័ន្ធ docker swarm clustering សម្រាប់គេហទំព័រដំណាក់កាលមួយដោយមិនរំខានដល់ដំណើរការការងារដែលបានបង្កើតឡើងនៃដំណើរការរបស់យើងក្នុងរយៈពេលកំណត់មួយ។ រឿងដែលបង្ហាញដល់ការចាប់អារម្មណ៍របស់អ្នកត្រូវបានបែងចែកជាពីរផ្នែក។ ផ្នែកទីមួយពិពណ៌នាអំពី CI/CD មុនពេលប្រើ docker swarm ហើយផ្នែកទីពីរពិពណ៌នាអំពីដំណើរការនៃការអនុវត្តរបស់វា។ អ្នកដែលមិនចាប់អារម្មណ៍នឹងការអានផ្នែកទីមួយអាចបន្តទៅវគ្គទីពីរដោយសុវត្ថិភាព។

ផ្នែកទី ១

ត្រលប់មកឆ្នាំដ៏សែនឆ្ងាយ ចាំបាច់ត្រូវរៀបចំដំណើរការ CI/CD ឱ្យបានលឿនតាមដែលអាចធ្វើទៅបាន។ លក្ខខណ្ឌមួយគឺមិនត្រូវប្រើ Docker ទេ។ សម្រាប់ការដាក់ពង្រាយ សមាសធាតុដែលបានបង្កើតឡើងសម្រាប់ហេតុផលជាច្រើន:

សម្រាប់ប្រតិបត្តិការដែលអាចទុកចិត្តបាន និងស្ថិរភាពនៃសមាសភាគនៅក្នុងផលិតកម្ម (នោះជាការពិត តម្រូវការមិនប្រើនិម្មិត)
អ្នកអភិវឌ្ឍន៍ឈានមុខគេមិនចង់ធ្វើការជាមួយ Docker ទេ (ចម្លែក ប៉ុន្តែនោះជារបៀបដែលវាកើតឡើង)
នេះបើយោងតាមការពិចារណាមនោគមវិជ្ជានៃការគ្រប់គ្រង R&D

ហេដ្ឋារចនាសម្ព័ន្ធ ជង់ និងតម្រូវការដំបូងប្រហាក់ប្រហែលសម្រាប់ MVP ត្រូវបានបង្ហាញដូចខាងក្រោម៖

ម៉ាស៊ីនមេ Intel® X4 ចំនួន 5650 ជាមួយ Debian (ម៉ាស៊ីនដ៏មានឥទ្ធិពលមួយត្រូវបានអភិវឌ្ឍយ៉ាងពេញលេញ)
ការអភិវឌ្ឍន៍សមាសធាតុផ្ទាល់ខ្លួនត្រូវបានអនុវត្តនៅក្នុង C ++, Python3
ឧបករណ៍ភាគីទី 3 សំខាន់ៗដែលប្រើ៖ Kafka, Clickhouse, Airflow, Redis, Grafana, Postgresql, Mysql, …
បំពង់សម្រាប់សាងសង់ និងសាកល្បងសមាសធាតុដាច់ដោយឡែកសម្រាប់បំបាត់កំហុស និងការបញ្ចេញ

សំណួរមួយក្នុងចំណោមសំណួរដំបូងដែលចាំបាច់ត្រូវដោះស្រាយនៅដំណាក់កាលដំបូងគឺថាតើសមាសធាតុផ្ទាល់ខ្លួននឹងត្រូវដាក់ពង្រាយក្នុងបរិយាកាសបែបណា (CI/CD)។

យើងបានសម្រេចចិត្តដំឡើងសមាសភាគភាគីទីបីជាប្រព័ន្ធ និងធ្វើបច្ចុប្បន្នភាពពួកវាជាប្រព័ន្ធ។ កម្មវិធីផ្ទាល់ខ្លួនដែលត្រូវបានបង្កើតឡើងនៅក្នុង C ++ ឬ Python អាចត្រូវបានដាក់ឱ្យប្រើប្រាស់តាមវិធីជាច្រើន។ ឧទាហរណ៍ក្នុងចំនោមពួកគេ៖ បង្កើតកញ្ចប់ប្រព័ន្ធ បញ្ជូនវាទៅឃ្លាំងនៃរូបភាពដែលបានបង្កើត ហើយបន្ទាប់មកដំឡើងពួកវានៅលើម៉ាស៊ីនមេ។ សម្រាប់ហេតុផលដែលមិនស្គាល់ វិធីសាស្ត្រមួយផ្សេងទៀតត្រូវបានជ្រើសរើសគឺ៖ ដោយប្រើ CI ឯកសារដែលអាចប្រតិបត្តិបានរបស់កម្មវិធីត្រូវបានចងក្រង បរិយាកាសគម្រោងនិម្មិតត្រូវបានបង្កើត ម៉ូឌុល py ត្រូវបានដំឡើងពី requirement.txt ហើយវត្ថុបុរាណទាំងអស់នេះត្រូវបានផ្ញើរួមជាមួយ configs, scripts និង អមជាមួយបរិយាកាសកម្មវិធីទៅកាន់ម៉ាស៊ីនមេ។ បន្ទាប់មក កម្មវិធីត្រូវបានបើកដំណើរការជាអ្នកប្រើនិម្មិតដោយគ្មានសិទ្ធិអ្នកគ្រប់គ្រង។

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

វាគួរឱ្យកត់សម្គាល់ថាការជួបប្រជុំគ្នានិងការធ្វើតេស្តត្រូវបានអនុវត្តនៅលើរូបភាពរបស់វាផ្ទាល់ដែលកញ្ចប់ប្រព័ន្ធចាំបាច់ទាំងអស់ត្រូវបានដំឡើងរួចហើយនិងការកំណត់ផ្សេងទៀតត្រូវបានធ្វើឡើង។

ទោះបីជាស្គ្រីបទាំងនេះនៅក្នុងការងារនីមួយៗគួរឱ្យចាប់អារម្មណ៍តាមរបៀបរបស់វាក៏ដោយ ប៉ុន្តែជាការពិតណាស់ខ្ញុំនឹងមិននិយាយអំពីពួកវាទេ។ ការពិពណ៌នាអំពីពួកវានីមួយៗនឹងចំណាយពេលច្រើន ហើយនេះមិនមែនជាគោលបំណងនៃអត្ថបទនោះទេ។ ខ្ញុំនឹងទាក់ទាញការយកចិត្តទុកដាក់របស់អ្នកចំពោះការពិតដែលថាដំណាក់កាលដាក់ពង្រាយមានលំដាប់នៃការហៅស្គ្រីប៖

បង្កើតconfig.py - បង្កើតឯកសារ settings.ini ជាមួយនឹងការកំណត់សមាសធាតុនៅក្នុងបរិស្ថានផ្សេងៗសម្រាប់ការដាក់ពង្រាយជាបន្តបន្ទាប់ (ការផលិត ការផលិត ការធ្វើតេស្ត ... )
install_venv.sh - បង្កើតបរិយាកាសនិម្មិតសម្រាប់សមាសធាតុ py នៅក្នុងថតជាក់លាក់មួយ ហើយចម្លងវាទៅម៉ាស៊ីនមេពីចម្ងាយ
រៀបចំ_init.d.py — រៀបចំស្គ្រីប start-stop សម្រាប់សមាសភាគដោយផ្អែកលើគំរូ
deploy.py - បំបែក និងចាប់ផ្តើមសមាសធាតុថ្មី។

ពេលវេលាបានកន្លងផុតទៅ។ ដំណាក់កាលដំណាក់កាលត្រូវបានជំនួសដោយការផលិត និងការផលិតជាមុន។ បានបន្ថែមការគាំទ្រសម្រាប់ផលិតផលនៅលើការចែកចាយមួយបន្ថែមទៀត (CentOS) ។ បានបន្ថែមម៉ាស៊ីនមេដែលមានថាមពលខ្លាំងជាង 5 និងម៉ាស៊ីននិម្មិតចំនួនដប់។ ហើយវាកាន់តែពិបាកសម្រាប់អ្នកអភិវឌ្ឍន៍ និងអ្នកសាកល្បងដើម្បីសាកល្បងកិច្ចការរបស់ពួកគេនៅក្នុងបរិយាកាសជិត ឬតិចជាងនេះទៅនឹងស្ថានភាពការងារ។ នៅពេលនេះវាច្បាស់ណាស់ថាវាមិនអាចទៅរួចទេក្នុងការធ្វើដោយគ្មានគាត់ ...

ផ្នែកទី II

ដូច្នេះ ចង្កោមរបស់យើងគឺជាប្រព័ន្ធដ៏អស្ចារ្យនៃសមាសធាតុដាច់ដោយឡែកពីគ្នាជាច្រើនដែលមិនត្រូវបានពិពណ៌នាដោយ Dockerfiles ។ អ្នកអាចកំណត់រចនាសម្ព័ន្ធវាសម្រាប់ការដាក់ពង្រាយទៅបរិយាកាសជាក់លាក់ជាទូទៅប៉ុណ្ណោះ។ ភារកិច្ចរបស់យើងគឺដើម្បីដាក់ពង្រាយចង្កោមទៅក្នុងបរិយាកាសដំណាក់កាលដើម្បីសាកល្បងវាមុនពេលការសាកល្បងមុនការចេញផ្សាយ។

តាមទ្រឹស្តី អាចមានចង្កោមជាច្រើនដែលកំពុងដំណើរការក្នុងពេលដំណាលគ្នា៖ ដូចជាមានកិច្ចការជាច្រើននៅក្នុងស្ថានភាពដែលបានបញ្ចប់ ឬជិតដល់ការបញ្ចប់។ សមត្ថភាពរបស់ servers ក្នុងការចោលរបស់យើងអនុញ្ញាតឱ្យយើងដំណើរការ clusters ជាច្រើននៅលើ server នីមួយៗ។ ចង្កោមដំណាក់កាលនីមួយៗត្រូវតែដាច់ឆ្ងាយពីគ្នា (មិនត្រូវមានចំនុចប្រសព្វនៅក្នុងច្រក ថត។ល។)។

ធនធានដ៏មានតម្លៃបំផុតរបស់យើងគឺពេលវេលារបស់យើង ហើយយើងមិនមានវាច្រើនទេ។

សម្រាប់ការចាប់ផ្តើមលឿនជាងមុន យើងបានជ្រើសរើស 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 nodes ក្នុងលក្ខខណ្ឌនៃការបញ្ជាពីចម្ងាយនៃថ្នាំងពី 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) ហើយមានសម្រាប់គ្នាទៅវិញទៅមក។

សមាសភាគប្រព័ន្ធ (ផ្អែកលើ redis, mysql) ត្រូវបានបំបែកចេញពីក្រុមទូទៅនៃសមាសភាគផ្ទាល់ខ្លួន (នៅក្នុងគម្រោង និងផ្នែកផ្ទាល់ខ្លួនត្រូវបានបែងចែកជាសេវាកម្ម)។ ដំណាក់កាលនៃការដាក់ពង្រាយនៃចង្កោមរបស់យើងមើលទៅដូចជាការបញ្ជូន CMD ទៅក្នុងរូបភាពដែលបានកំណត់រចនាសម្ព័ន្ធធំមួយរបស់យើង ហើយជាទូទៅ ការអនុវត្តជាក់ស្តែងមិនខុសគ្នាពីការដាក់ពង្រាយដែលបានពិពណ៌នានៅក្នុងផ្នែកទី XNUMX នោះទេ។ ខ្ញុំនឹងគូសបញ្ជាក់ពីភាពខុសគ្នា៖

git ក្លូន... - ទទួលបានឯកសារដែលត្រូវការដើម្បីដាក់ពង្រាយ (createconfig.py, install_venv.sh ។ល។)
curl... && ពន្លា... - ទាញយកនិងពន្លាវត្ថុបុរាណបង្កើត (ឧបករណ៍ប្រើប្រាស់ដែលបានចងក្រង)

មានបញ្ហាតែមួយគត់ដែលមិនទាន់បានពិពណ៌នា៖ សមាសធាតុដែលមានចំណុចប្រទាក់គេហទំព័រមិនអាចចូលប្រើបានពីកម្មវិធីរុករករបស់អ្នកអភិវឌ្ឍន៍។ យើងដោះស្រាយបញ្ហានេះដោយប្រើប្រូកស៊ីបញ្ច្រាសដូច្នេះ៖

នៅក្នុង .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 នីមួយៗ
រកឃើញថ្នាំងដែលផ្ទុកតិចដោយស្វ័យប្រវត្តិនៅក្នុងជង់
បញ្ជាក់ថ្នាំងតាមលំនាំឈ្មោះ (ជាជាងប្រើលេខសម្គាល់ដូចក្នុងអត្ថបទ)
បន្ថែមការត្រួតពិនិត្យថាជង់ត្រូវបានបំផ្លាញ
...

សូមអរគុណជាពិសេសសម្រាប់ អត្ថបទ.

ប្រភព: www.habr.com

ដាក់ពង្រាយកម្មវិធីជាមួយ Docker Swarm

ផ្នែកទី ១

ផ្នែកទី II

បន្ថែមមតិយោបល់ ответОтменить