🥇ນຳໃຊ້ແອັບດ້ວຍ Docker Swarm

ລະບົບການແນະນໍາເນື້ອຫາວິດີໂອອອນໄລນ໌ທີ່ພວກເຮົາກໍາລັງເຮັດວຽກແມ່ນການພັດທະນາການຄ້າປິດແລະທາງດ້ານວິຊາການເປັນກຸ່ມຫຼາຍອົງປະກອບຂອງອົງປະກອບທີ່ເປັນເຈົ້າຂອງແລະແຫຼ່ງເປີດ. ຈຸດປະສົງຂອງການຂຽນບົດນີ້ແມ່ນເພື່ອອະທິບາຍການປະຕິບັດລະບົບ docker swarm clustering ສໍາລັບສະຖານທີ່ staging ໂດຍບໍ່ມີການລົບກວນການເຮັດວຽກທີ່ສ້າງຕັ້ງຂຶ້ນຂອງຂະບວນການຂອງພວກເຮົາໃນເວລາຈໍາກັດ. ຄໍາບັນຍາຍທີ່ນໍາສະເຫນີໃຫ້ຄວາມສົນໃຈຂອງເຈົ້າແບ່ງອອກເປັນສອງສ່ວນ. ສ່ວນທໍາອິດອະທິບາຍ CI / CD ກ່ອນທີ່ຈະໃຊ້ docker swarm, ແລະສ່ວນທີສອງອະທິບາຍເຖິງຂະບວນການປະຕິບັດຂອງມັນ. ຜູ້ທີ່ບໍ່ສົນໃຈໃນການອ່ານພາກສ່ວນທໍາອິດໄດ້ຢ່າງປອດໄພສາມາດຍ້າຍໄປທີ່ສອງໄດ້ຢ່າງປອດໄພ.

ພາກທີ I

ກັບໄປໃນປີທີ່ຫ່າງໄກ, ຫ່າງໄກ, ມັນຈໍາເປັນຕ້ອງໄດ້ກໍານົດຂະບວນການ CI / CD ໄວເທົ່າທີ່ຈະໄວໄດ້. ຫນຶ່ງໃນເງື່ອນໄຂບໍ່ແມ່ນການໃຊ້ Docker ສໍາລັບການນໍາໃຊ້ ອົງປະກອບທີ່ພັດທະນາສໍາລັບເຫດຜົນຈໍານວນຫນຶ່ງ:

ສໍາລັບການດໍາເນີນງານທີ່ເຊື່ອຖືໄດ້ແລະຫມັ້ນຄົງຫຼາຍຂອງອົງປະກອບໃນການຜະລິດ (ນັ້ນແມ່ນ, ໃນຄວາມເປັນຈິງ, ຄວາມຕ້ອງການບໍ່ໃຫ້ໃຊ້ virtualization)
ຜູ້ພັດທະນາຊັ້ນນໍາບໍ່ຕ້ອງການເຮັດວຽກກັບ Docker (ແປກ, ແຕ່ວ່າມັນເປັນແນວໃດ)
ອີງຕາມການພິຈາລະນາອຸດົມການຂອງການຄຸ້ມຄອງ R&D

ໂຄງສ້າງພື້ນຖານ, stack ແລະຄວາມຕ້ອງການເບື້ອງຕົ້ນໂດຍປະມານສໍາລັບ MVP ໄດ້ຖືກນໍາສະເຫນີດັ່ງຕໍ່ໄປນີ້:

4 ເຊີບເວີ Intel® X5650 ກັບ Debian (ເຄື່ອງທີ່ມີປະສິດທິພາບອີກອັນໜຶ່ງແມ່ນໄດ້ຮັບການພັດທະນາຢ່າງເຕັມທີ່)
ການພັດທະນາອົງປະກອບທີ່ກໍາຫນົດເອງແມ່ນດໍາເນີນຢູ່ໃນ C ++, Python3
ເຄື່ອງມືພາກສ່ວນທີສາມຕົ້ນຕໍທີ່ໃຊ້: Kafka, Clickhouse, Airflow, Redis, Grafana, Postgresql, Mysql, …
ທໍ່ສໍາລັບການກໍ່ສ້າງແລະການທົດສອບອົງປະກອບແຍກຕ່າງຫາກສໍາລັບການ debug ແລະການປ່ອຍ

ຫນຶ່ງໃນຄໍາຖາມທໍາອິດທີ່ຕ້ອງໄດ້ຮັບການແກ້ໄຂໃນຂັ້ນຕອນເບື້ອງຕົ້ນແມ່ນວິທີການອົງປະກອບທີ່ກໍາຫນົດເອງຈະຖືກນໍາໄປໃຊ້ໃນສະພາບແວດລ້ອມໃດ (CI / CD).

ພວກເຮົາໄດ້ຕັດສິນໃຈທີ່ຈະຕິດຕັ້ງອົງປະກອບຂອງພາກສ່ວນທີສາມຢ່າງເປັນລະບົບແລະປັບປຸງໃຫ້ເຂົາເຈົ້າເປັນລະບົບ. ແອັບພລິເຄຊັນແບບກຳນົດເອງທີ່ພັດທະນາໃນ C++ ຫຼື Python ສາມາດຖືກນຳໃຊ້ໃນຫຼາຍວິທີ. ໃນບັນດາພວກເຂົາ, ສໍາລັບການຍົກຕົວຢ່າງ: ການສ້າງຊຸດລະບົບ, ສົ່ງພວກມັນໄປຫາບ່ອນເກັບມ້ຽນຂອງຮູບພາບທີ່ສ້າງຂຶ້ນແລະຫຼັງຈາກນັ້ນຕິດຕັ້ງມັນຢູ່ໃນເຄື່ອງແມ່ຂ່າຍ. ດ້ວຍເຫດຜົນທີ່ບໍ່ຮູ້ຈັກ, ວິທີການອື່ນໄດ້ຖືກເລືອກ, ຄື: ການນໍາໃຊ້ CI, ໄຟລ໌ທີ່ປະຕິບັດໄດ້ຂອງແອັບພລິເຄຊັນຖືກລວບລວມ, ສະພາບແວດລ້ອມໂຄງການ virtual ຖືກສ້າງຂື້ນ, ໂມດູນ py ຖືກຕິດຕັ້ງຈາກ requirement.txt, ແລະສິ່ງປອມທັງຫມົດເຫຼົ່ານີ້ຖືກສົ່ງພ້ອມກັບ configs, scripts ແລະ. ສະພາບແວດລ້ອມແອັບພລິເຄຊັນທີ່ມາພ້ອມກັບເຄື່ອງແມ່ຂ່າຍ. ຕໍ່ໄປ, ແອັບພລິເຄຊັນຖືກເປີດຕົວເປັນຜູ້ໃຊ້ virtual ໂດຍບໍ່ມີສິດຂອງຜູ້ເບິ່ງແຍງລະບົບ.

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

ມັນເປັນມູນຄ່າທີ່ສັງເກດວ່າການປະກອບແລະການທົດສອບແມ່ນດໍາເນີນຢູ່ໃນຮູບຂອງມັນເອງ, ບ່ອນທີ່ຊຸດລະບົບທີ່ຈໍາເປັນທັງຫມົດໄດ້ຖືກຕິດຕັ້ງແລ້ວແລະການຕັ້ງຄ່າອື່ນໆ.

ເຖິງແມ່ນວ່າແຕ່ລະສະຄິບເຫຼົ່ານີ້ໃນຫນ້າວຽກແມ່ນຫນ້າສົນໃຈໃນລັກສະນະຂອງຕົນເອງ, ແຕ່ແນ່ນອນວ່າຂ້ອຍຈະບໍ່ເວົ້າກ່ຽວກັບພວກມັນ. ຄໍາອະທິບາຍຂອງພວກມັນແຕ່ລະຄົນຈະໃຊ້ເວລາຫຼາຍແລະນີ້ບໍ່ແມ່ນຈຸດປະສົງຂອງບົດຄວາມ. ຂ້າພະເຈົ້າພຽງແຕ່ຈະດຶງດູດຄວາມສົນໃຈຂອງທ່ານຕໍ່ກັບຄວາມຈິງທີ່ວ່າຂັ້ນຕອນຂອງການຕິດຕັ້ງປະກອບດ້ວຍລໍາດັບຂອງ scripts ໂທຫາ:

createconfig.py - ສ້າງໄຟລ໌ settings.ini ທີ່ມີການຕັ້ງຄ່າອົງປະກອບໃນສະພາບແວດລ້ອມຕ່າງໆສໍາລັບການນໍາໃຊ້ຕໍ່ມາ (Preproduction, ການຜະລິດ, ການທົດສອບ, ... )
install_venv.sh - ສ້າງສະພາບແວດລ້ອມ virtual ສໍາລັບອົງປະກອບ py ໃນໄດເລກະທໍລີສະເພາະແລະຄັດລອກມັນໄປຫາເຄື່ອງແມ່ຂ່າຍຫ່າງໄກສອກຫຼີກ
ກະກຽມ_init.d.py — ກະກຽມສະຄຣິບເລີ່ມຕົ້ນ-ຢຸດສໍາລັບອົງປະກອບໂດຍອີງໃສ່ແມ່ແບບ
deploy.py - decomposes ແລະ restarts ອົງປະກອບໃຫມ່

ເວລາຜ່ານໄປ. ຂັ້ນຕອນຂອງຂັ້ນຕອນໄດ້ຖືກທົດແທນໂດຍການຜະລິດກ່ອນການຜະລິດແລະການຜະລິດ. ເພີ່ມການສະຫນັບສະຫນູນສໍາລັບຜະລິດຕະພັນໃນການແຈກຢາຍອື່ນ (CentOS). ໄດ້ເພີ່ມ 5 ເຊີບເວີທີ່ມີພະລັງ ແລະ ເຊີບເວີສະເໝືອນຫຼາຍສິບອັນ. ແລະມັນໄດ້ກາຍເປັນຄວາມຫຍຸ້ງຍາກຫຼາຍຂື້ນສໍາລັບນັກພັດທະນາແລະຜູ້ທົດສອບເພື່ອທົດສອບວຽກງານຂອງພວກເຂົາໃນສະພາບແວດລ້ອມທີ່ໃກ້ຊິດກັບລັດທີ່ເຮັດວຽກຫຼາຍຫຼືຫນ້ອຍ. ໃນເວລານີ້, ມັນໄດ້ກາຍເປັນທີ່ຊັດເຈນວ່າມັນເປັນໄປບໍ່ໄດ້ທີ່ຈະເຮັດໂດຍບໍ່ມີລາວ ...

ພາກທີ II

ດັ່ງນັ້ນ, ກຸ່ມຂອງພວກເຮົາແມ່ນລະບົບທີ່ຫນ້າປະທັບໃຈຂອງສອງອົງປະກອບແຍກຕ່າງຫາກທີ່ບໍ່ໄດ້ອະທິບາຍໂດຍ Dockerfiles. ທ່ານພຽງແຕ່ສາມາດ configure ມັນສໍາລັບ deployment ກັບສະພາບແວດລ້ອມສະເພາະໃດຫນຶ່ງໂດຍທົ່ວໄປ. ໜ້າທີ່ຂອງພວກເຮົາແມ່ນເພື່ອນຳໃຊ້ກຸ່ມເຂົ້າໃນສະພາບແວດລ້ອມຂັ້ນຕອນເພື່ອທົດສອບກ່ອນການອອກຈຳໜ່າຍກ່ອນ.

ໃນທາງທິດສະດີ, ສາມາດມີຫຼາຍກຸ່ມເຮັດວຽກພ້ອມໆກັນ: ຫຼາຍເທົ່າທີ່ມີວຽກງານຢູ່ໃນລັດສໍາເລັດຫຼືໃກ້ຈະສໍາເລັດ. ຄວາມສາມາດຂອງເຄື່ອງແມ່ຂ່າຍໃນການກໍາຈັດຂອງພວກເຮົາອະນຸຍາດໃຫ້ພວກເຮົາດໍາເນີນການຫຼາຍກຸ່ມໃນແຕ່ລະເຄື່ອງແມ່ຂ່າຍ. ແຕ່ລະກຸ່ມຂັ້ນຕອນຕ້ອງໂດດດ່ຽວ (ຕ້ອງບໍ່ມີຈຸດຕັດກັນໃນພອດ, ໄດເລກະທໍລີ, ແລະອື່ນໆ).

ຊັບພະຍາກອນທີ່ມີຄຸນຄ່າທີ່ສຸດຂອງພວກເຮົາແມ່ນເວລາຂອງພວກເຮົາ, ແລະພວກເຮົາບໍ່ມີມັນຫຼາຍ.

ສໍາລັບການເລີ່ມຕົ້ນໄວຂຶ້ນ, ພວກເຮົາເລືອກ Docker Swarm ເນື່ອງຈາກຄວາມງ່າຍດາຍແລະຄວາມຍືດຫຍຸ່ນຂອງສະຖາປັດຕະຍະກໍາ. ສິ່ງທໍາອິດທີ່ພວກເຮົາເຮັດແມ່ນສ້າງຜູ້ຈັດການແລະຫຼາຍ nodes ໃນເຄື່ອງແມ່ຂ່າຍຫ່າງໄກສອກຫຼີກ:

$ 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 ໃນເງື່ອນໄຂຂອງການຄວບຄຸມຫ່າງໄກສອກຫຼີກຂອງ nodes ຈາກ CI: ການຕິດຕັ້ງໃບຢັ້ງຢືນ, ການຕັ້ງຄ່າຕົວແປລັບ, ແລະການຕັ້ງຄ່າບໍລິການ Docker ໃນເຄື່ອງແມ່ຂ່າຍການຄວບຄຸມ. ອັນນີ້ ບົດຄວາມ ຊ່ວຍປະຢັດພວກເຮົາຫຼາຍເວລາ.

ຕໍ່ໄປ, ພວກເຮົາໄດ້ເພີ່ມວຽກການສ້າງ stack ແລະການທໍາລາຍກັບ .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, ຮຽກຮ້ອງໃຫ້ມີການປະຕິບັດຄູ່ມື.

ຊື່ stack ກົງກັບຊື່ສາຂາແລະຄວາມເປັນເອກະລັກນີ້ຄວນຈະພຽງພໍ. ການບໍລິການໃນ stack ໄດ້ຮັບທີ່ຢູ່ ip ທີ່ເປັນເອກະລັກ, ແລະພອດ, ໄດເລກະທໍລີ, ແລະອື່ນໆ. ຈະຖືກໂດດດ່ຽວ, ແຕ່ຄືກັນຈາກ stack ກັບ stack (ເພາະວ່າໄຟລ໌ການຕັ້ງຄ່າແມ່ນຄືກັນສໍາລັບ stacks ທັງຫມົດ) - ສິ່ງທີ່ພວກເຮົາຕ້ອງການ. ພວກເຮົາ deploy stack (cluster) ໂດຍໃຊ້ 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) ຖືກແຍກອອກຈາກສະນຸກເກີທົ່ວໄປຂອງອົງປະກອບທີ່ກໍາຫນົດເອງ (ໃນແຜນການແລະ custom ແມ່ນແບ່ງອອກເປັນບໍລິການ). ຂັ້ນຕອນການຕິດຕັ້ງຂອງກຸ່ມຂອງພວກເຮົາເບິ່ງຄືວ່າການຖ່າຍທອດ CMD ເຂົ້າໄປໃນຮູບພາບທີ່ມີການຕັ້ງຄ່າຂະຫນາດໃຫຍ່ອັນຫນຶ່ງຂອງພວກເຮົາແລະໂດຍທົ່ວໄປແລ້ວ, ການປະຕິບັດບໍ່ແຕກຕ່າງຈາກການປະຕິບັດທີ່ໄດ້ອະທິບາຍໄວ້ໃນພາກ I. ຂ້າພະເຈົ້າຈະເນັ້ນໃຫ້ເຫັນຄວາມແຕກຕ່າງ:

git clone... - ໄດ້ຮັບໄຟລ໌ທີ່ຈໍາເປັນເພື່ອນໍາໃຊ້ (createconfig.py, install_venv.sh, ແລະອື່ນໆ)
curl... && unzip... - ດາວນ໌ໂຫລດແລະ unzip ການກໍ່ສ້າງ artifacts (ອຸປະກອນການສັງລວມ)

ມີພຽງແຕ່ຫນຶ່ງບັນຫາທີ່ຍັງບໍ່ໄດ້ອະທິບາຍ: ອົງປະກອບທີ່ມີການໂຕ້ຕອບເວັບໄຊຕ໌ແມ່ນບໍ່ສາມາດເຂົ້າເຖິງໄດ້ຈາກຕົວທ່ອງເວັບຂອງນັກພັດທະນາ. ພວກເຮົາແກ້ໄຂບັນຫານີ້ໂດຍໃຊ້ reverse proxy, ດັ່ງນັ້ນ:

ໃນ .gitlab-ci.yml, ຫຼັງຈາກ deploy the cluster stack, we add line of deploy the balancer (ຊຶ່ງ, ເມື່ອ commits, ພຽງແຕ່ປັບປຸງການຕັ້ງຄ່າຂອງມັນ (ສ້າງໄຟລ໌ການຕັ້ງຄ່າ 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
ກວດພົບໂນດທີ່ໂຫຼດໜ້ອຍລົງໂດຍອັດຕະໂນມັດໃນ stack
ລະບຸ nodes ໂດຍຮູບແບບຊື່ (ແທນທີ່ຈະໃຊ້ id ໃນບົດຄວາມ)
ເພີ່ມການກວດສອບວ່າ stack ໄດ້ຖືກທໍາລາຍ
...

ຂອບໃຈພິເສດສຳລັບ ບົດຄວາມ.

ແຫຼ່ງຂໍ້ມູນ: www.habr.com

ນຳໃຊ້ແອັບພລິເຄຊັນກັບ Docker Swarm

ພາກທີ I

ພາກທີ II

ເພີ່ມຄວາມຄິດເຫັນ Отменитьответ