ಪ್ರೊಹೋಸ್ಟರ್ > Блог > ಆಡಳಿತ > ಡಾಕರ್ ಸಮೂಹದೊಂದಿಗೆ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ನಿಯೋಜಿಸಿ

ಡಾಕರ್ ಸಮೂಹದೊಂದಿಗೆ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ನಿಯೋಜಿಸಿ

ನಾವು ಕೆಲಸ ಮಾಡುತ್ತಿರುವ ಆನ್‌ಲೈನ್ ವೀಡಿಯೊ ವಿಷಯ ಶಿಫಾರಸು ವ್ಯವಸ್ಥೆಯು ಮುಚ್ಚಿದ ವಾಣಿಜ್ಯ ಅಭಿವೃದ್ಧಿಯಾಗಿದೆ ಮತ್ತು ತಾಂತ್ರಿಕವಾಗಿ ಸ್ವಾಮ್ಯದ ಮತ್ತು ಮುಕ್ತ ಮೂಲ ಘಟಕಗಳ ಬಹು-ಘಟಕ ಕ್ಲಸ್ಟರ್ ಆಗಿದೆ. ಈ ಲೇಖನವನ್ನು ಬರೆಯುವ ಉದ್ದೇಶವು ಸೀಮಿತ ಸಮಯದಲ್ಲಿ ನಮ್ಮ ಪ್ರಕ್ರಿಯೆಗಳ ಸ್ಥಾಪಿತ ಕೆಲಸದ ಹರಿವನ್ನು ಅಡ್ಡಿಪಡಿಸದೆಯೇ ಸ್ಟೇಜಿಂಗ್ ಸೈಟ್‌ಗಾಗಿ ಡಾಕರ್ ಸಮೂಹ ಕ್ಲಸ್ಟರಿಂಗ್ ಸಿಸ್ಟಮ್‌ನ ಅನುಷ್ಠಾನವನ್ನು ವಿವರಿಸುವುದು. ನಿಮ್ಮ ಗಮನಕ್ಕೆ ಪ್ರಸ್ತುತಪಡಿಸಿದ ನಿರೂಪಣೆಯನ್ನು ಎರಡು ಭಾಗಗಳಾಗಿ ವಿಂಗಡಿಸಲಾಗಿದೆ. ಮೊದಲ ಭಾಗವು ಡಾಕರ್ ಸಮೂಹವನ್ನು ಬಳಸುವ ಮೊದಲು CI / CD ಅನ್ನು ವಿವರಿಸುತ್ತದೆ ಮತ್ತು ಎರಡನೆಯದು ಅದರ ಅನುಷ್ಠಾನದ ಪ್ರಕ್ರಿಯೆಯನ್ನು ವಿವರಿಸುತ್ತದೆ. ಮೊದಲ ಭಾಗವನ್ನು ಓದಲು ಆಸಕ್ತಿಯಿಲ್ಲದವರು ಸುರಕ್ಷಿತವಾಗಿ ಎರಡನೆಯದಕ್ಕೆ ಹೋಗಬಹುದು.

ನಾನು

ದೂರದ, ದೂರದ ವರ್ಷದಲ್ಲಿ, ಸಾಧ್ಯವಾದಷ್ಟು ಬೇಗ CI / CD ಪ್ರಕ್ರಿಯೆಯನ್ನು ಹೊಂದಿಸುವುದು ಅಗತ್ಯವಾಗಿತ್ತು. ಡಾಕರ್ ಅನ್ನು ಬಳಸದಿರುವುದು ಒಂದು ಷರತ್ತು ನಿಯೋಜನೆಗಾಗಿ ಹಲವಾರು ಕಾರಣಗಳಿಗಾಗಿ ಘಟಕಗಳನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸಲಾಗಿದೆ:

  • ಉತ್ಪಾದನೆಯಲ್ಲಿನ ಘಟಕಗಳ ಹೆಚ್ಚು ವಿಶ್ವಾಸಾರ್ಹ ಮತ್ತು ಸ್ಥಿರ ಕಾರ್ಯಾಚರಣೆಗಾಗಿ (ಅಂದರೆ, ವಾಸ್ತವೀಕರಣವನ್ನು ಬಳಸದಿರುವ ಅವಶ್ಯಕತೆ)
  • ಪ್ರಮುಖ ಡೆವಲಪರ್‌ಗಳು ಡಾಕರ್‌ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಲು ಬಯಸುವುದಿಲ್ಲ (ವಿಚಿತ್ರ, ಆದರೆ ಅದು ಹೇಗೆ)
  • ಆರ್ & ಡಿ ನಿರ್ವಹಣೆಯ ಸೈದ್ಧಾಂತಿಕ ಪರಿಗಣನೆಗಳ ಪ್ರಕಾರ

MVP ಗಾಗಿ ಮೂಲಸೌಕರ್ಯ, ಸ್ಟಾಕ್ ಮತ್ತು ಅಂದಾಜು ಆರಂಭಿಕ ಅವಶ್ಯಕತೆಗಳನ್ನು ಈ ಕೆಳಗಿನಂತೆ ಪ್ರಸ್ತುತಪಡಿಸಲಾಗಿದೆ:

  • ಡೆಬಿಯನ್‌ನೊಂದಿಗೆ 4 Intel® X5650 ಸರ್ವರ್‌ಗಳು (ಇನ್ನೊಂದು ಶಕ್ತಿಶಾಲಿ ಯಂತ್ರವನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಅಭಿವೃದ್ಧಿಪಡಿಸಲಾಗಿದೆ)
  • ಸ್ವಂತ ಕಸ್ಟಮ್ ಘಟಕಗಳ ಅಭಿವೃದ್ಧಿಯನ್ನು C ++, Python3 ನಲ್ಲಿ ಕೈಗೊಳ್ಳಲಾಗುತ್ತದೆ
  • ಬಳಸಿದ ಮುಖ್ಯ 3ನೇ ವ್ಯಕ್ತಿಯ ಪರಿಕರಗಳು: ಕಾಫ್ಕಾ, ಕ್ಲಿಕ್‌ಹೌಸ್, ಏರ್‌ಫ್ಲೋ, ರೆಡಿಸ್, ಗ್ರಾಫನಾ, ಪೋಸ್ಟ್‌ಗ್ರೆಸ್ಕ್ಲ್, ಮೈಸ್ಕ್ಲ್, ...
  • ಡೀಬಗ್ ಮತ್ತು ಬಿಡುಗಡೆಗಾಗಿ ಪ್ರತ್ಯೇಕವಾಗಿ ಘಟಕಗಳನ್ನು ನಿರ್ಮಿಸಲು ಮತ್ತು ಪರೀಕ್ಷಿಸಲು ಪೈಪ್‌ಲೈನ್‌ಗಳು

ಯಾವುದೇ ಪರಿಸರದಲ್ಲಿ (CI / CD) ಕಸ್ಟಮ್ ಘಟಕಗಳನ್ನು ಹೇಗೆ ನಿಯೋಜಿಸಲಾಗುವುದು ಎಂಬುದು ಆರಂಭಿಕ ಹಂತದಲ್ಲಿ ತಿಳಿಸಬೇಕಾದ ಮೊದಲ ಪ್ರಶ್ನೆಗಳಲ್ಲಿ ಒಂದಾಗಿದೆ.

ನಾವು ಮೂರನೇ ವ್ಯಕ್ತಿಯ ಘಟಕಗಳನ್ನು ವ್ಯವಸ್ಥಿತವಾಗಿ ಸ್ಥಾಪಿಸಲು ಮತ್ತು ಅವುಗಳನ್ನು ವ್ಯವಸ್ಥಿತವಾಗಿ ನವೀಕರಿಸಲು ನಿರ್ಧರಿಸಿದ್ದೇವೆ. C++ ಅಥವಾ ಪೈಥಾನ್‌ನಲ್ಲಿ ಅಭಿವೃದ್ಧಿಪಡಿಸಲಾದ ಕಸ್ಟಮ್ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ಹಲವಾರು ರೀತಿಯಲ್ಲಿ ನಿಯೋಜಿಸಬಹುದು. ಅವುಗಳಲ್ಲಿ, ಉದಾಹರಣೆಗೆ: ಸಿಸ್ಟಮ್ ಪ್ಯಾಕೇಜುಗಳನ್ನು ರಚಿಸುವುದು, ಅವುಗಳನ್ನು ನಿರ್ಮಿಸಿದ ಚಿತ್ರಗಳ ರೆಪೊಸಿಟರಿಗೆ ಕಳುಹಿಸುವುದು ಮತ್ತು ನಂತರ ಅವುಗಳನ್ನು ಸರ್ವರ್ಗಳಲ್ಲಿ ಸ್ಥಾಪಿಸುವುದು. ಅಜ್ಞಾತ ಕಾರಣಕ್ಕಾಗಿ, ಇನ್ನೊಂದು ವಿಧಾನವನ್ನು ಆಯ್ಕೆಮಾಡಲಾಗಿದೆ, ಅವುಗಳೆಂದರೆ: CI ಅನ್ನು ಬಳಸಿ, ಅಪ್ಲಿಕೇಶನ್ ಕಾರ್ಯಗತಗೊಳಿಸಬಹುದಾದ ಫೈಲ್‌ಗಳನ್ನು ಕಂಪೈಲ್ ಮಾಡಲಾಗುತ್ತದೆ, ವರ್ಚುವಲ್ ಪ್ರಾಜೆಕ್ಟ್ ಪರಿಸರವನ್ನು ರಚಿಸಲಾಗಿದೆ, py ಮಾಡ್ಯೂಲ್‌ಗಳನ್ನು requirements.txt ನಿಂದ ಸ್ಥಾಪಿಸಲಾಗಿದೆ, ಮತ್ತು ಈ ಎಲ್ಲಾ ಕಲಾಕೃತಿಗಳನ್ನು ಸಂರಚನೆಗಳು, ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳು ಮತ್ತು ಜೊತೆಗೆ ಕಳುಹಿಸಲಾಗುತ್ತದೆ. ಸರ್ವರ್‌ಗಳಿಗೆ ಅಪ್ಲಿಕೇಶನ್ ಪರಿಸರದ ಜೊತೆಯಲ್ಲಿ. ಮುಂದೆ, ನಿರ್ವಾಹಕರ ಹಕ್ಕುಗಳಿಲ್ಲದೆ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ವರ್ಚುವಲ್ ಬಳಕೆದಾರರಾಗಿ ಪ್ರಾರಂಭಿಸಲಾಗುತ್ತದೆ.

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 - ನಿರ್ದಿಷ್ಟ ಡೈರೆಕ್ಟರಿಯಲ್ಲಿ ಪೈ ಘಟಕಗಳಿಗೆ ವರ್ಚುವಲ್ ಪರಿಸರವನ್ನು ರಚಿಸುತ್ತದೆ ಮತ್ತು ಅದನ್ನು ರಿಮೋಟ್ ಸರ್ವರ್‌ಗಳಿಗೆ ನಕಲಿಸುತ್ತದೆ
  3. ತಯಾರು_init.d.py — ಟೆಂಪ್ಲೇಟ್‌ನ ಆಧಾರದ ಮೇಲೆ ಘಟಕಕ್ಕಾಗಿ ಸ್ಟಾರ್ಟ್-ಸ್ಟಾಪ್ ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳನ್ನು ಸಿದ್ಧಪಡಿಸುತ್ತದೆ
  4. deploy.py - ಹೊಸ ಘಟಕಗಳನ್ನು ಕೊಳೆಯುತ್ತದೆ ಮತ್ತು ಮರುಪ್ರಾರಂಭಿಸುತ್ತದೆ

ಸಮಯ ಕಳೆಯಿತು. ಪ್ರೀಪ್ರೊಡಕ್ಷನ್ ಮತ್ತು ಉತ್ಪಾದನೆಯಿಂದ ವೇದಿಕೆಯ ಹಂತವನ್ನು ಬದಲಾಯಿಸಲಾಯಿತು. ಇನ್ನೂ ಒಂದು ವಿತರಣೆಯಲ್ಲಿ (CentOS) ಉತ್ಪನ್ನಕ್ಕೆ ಬೆಂಬಲವನ್ನು ಸೇರಿಸಲಾಗಿದೆ. 5 ಹೆಚ್ಚು ಶಕ್ತಿಯುತ ಭೌತಿಕ ಸರ್ವರ್‌ಗಳು ಮತ್ತು ಒಂದು ಡಜನ್ ವರ್ಚುವಲ್ ಅನ್ನು ಸೇರಿಸಲಾಗಿದೆ. ಮತ್ತು ಡೆವಲಪರ್‌ಗಳು ಮತ್ತು ಪರೀಕ್ಷಕರು ತಮ್ಮ ಕಾರ್ಯಗಳನ್ನು ಕೆಲಸ ಮಾಡುವ ಸ್ಥಿತಿಗೆ ಹೆಚ್ಚು ಅಥವಾ ಕಡಿಮೆ ಹತ್ತಿರವಿರುವ ಪರಿಸರದಲ್ಲಿ ಪರೀಕ್ಷಿಸಲು ಹೆಚ್ಚು ಕಷ್ಟಕರವಾಯಿತು. ಈ ಸಮಯದಲ್ಲಿ, ಅವನಿಲ್ಲದೆ ಮಾಡುವುದು ಅಸಾಧ್ಯವೆಂದು ಸ್ಪಷ್ಟವಾಯಿತು ...

ಭಾಗ II

ಡಾಕರ್ ಸಮೂಹದೊಂದಿಗೆ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ನಿಯೋಜಿಸಿ

ಆದ್ದರಿಂದ, ನಮ್ಮ ಕ್ಲಸ್ಟರ್ ಡಾಕರ್‌ಫೈಲ್ಸ್‌ನಿಂದ ವಿವರಿಸದ ಒಂದೆರಡು ಡಜನ್ ಪ್ರತ್ಯೇಕ ಘಟಕಗಳ ಅದ್ಭುತ ವ್ಯವಸ್ಥೆಯಾಗಿದೆ. ಸಾಮಾನ್ಯವಾಗಿ ನಿರ್ದಿಷ್ಟ ಪರಿಸರಕ್ಕೆ ನಿಯೋಜನೆಗಾಗಿ ಮಾತ್ರ ನೀವು ಅದನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಬಹುದು. ಪೂರ್ವ-ಬಿಡುಗಡೆ ಪರೀಕ್ಷೆಯ ಮೊದಲು ಅದನ್ನು ಪರೀಕ್ಷಿಸಲು ಕ್ಲಸ್ಟರ್ ಅನ್ನು ವೇದಿಕೆಯ ಪರಿಸರಕ್ಕೆ ನಿಯೋಜಿಸುವುದು ನಮ್ಮ ಕಾರ್ಯವಾಗಿದೆ.

ಸೈದ್ಧಾಂತಿಕವಾಗಿ, ಏಕಕಾಲದಲ್ಲಿ ಹಲವಾರು ಕ್ಲಸ್ಟರ್‌ಗಳು ಚಾಲನೆಯಲ್ಲಿರಬಹುದು: ಪೂರ್ಣಗೊಂಡ ಸ್ಥಿತಿಯಲ್ಲಿ ಅಥವಾ ಪೂರ್ಣಗೊಳ್ಳುವ ಸಮೀಪದಲ್ಲಿ ಕಾರ್ಯಗಳು ಇವೆ. ನಮ್ಮ ವಿಲೇವಾರಿಯಲ್ಲಿರುವ ಸರ್ವರ್‌ಗಳ ಸಾಮರ್ಥ್ಯಗಳು ಪ್ರತಿ ಸರ್ವರ್‌ನಲ್ಲಿ ಹಲವಾರು ಕ್ಲಸ್ಟರ್‌ಗಳನ್ನು ಚಲಾಯಿಸಲು ನಮಗೆ ಅನುಮತಿಸುತ್ತದೆ. ಪ್ರತಿಯೊಂದು ಸ್ಟೇಜಿಂಗ್ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಪ್ರತ್ಯೇಕಿಸಬೇಕು (ಬಂದರುಗಳು, ಡೈರೆಕ್ಟರಿಗಳು, ಇತ್ಯಾದಿಗಳಲ್ಲಿ ಯಾವುದೇ ಛೇದಕ ಇರಬಾರದು).

ನಮ್ಮ ಅತ್ಯಮೂಲ್ಯ ಸಂಪನ್ಮೂಲವೆಂದರೆ ನಮ್ಮ ಸಮಯ, ಮತ್ತು ನಮ್ಮಲ್ಲಿ ಹೆಚ್ಚು ಇರಲಿಲ್ಲ.

ವೇಗವಾದ ಆರಂಭಕ್ಕಾಗಿ, ಅದರ ಸರಳತೆ ಮತ್ತು ವಾಸ್ತುಶಿಲ್ಪದ ನಮ್ಯತೆಯಿಂದಾಗಿ ನಾವು ಡಾಕರ್ ಸಮೂಹವನ್ನು ಆಯ್ಕೆ ಮಾಡಿದ್ದೇವೆ. ನಾವು ಮಾಡಿದ ಮೊದಲ ಕೆಲಸವೆಂದರೆ ರಿಮೋಟ್ ಸರ್ವರ್‌ಗಳಲ್ಲಿ ಮ್ಯಾನೇಜರ್ ಮತ್ತು ಹಲವಾರು ನೋಡ್‌ಗಳನ್ನು ರಚಿಸುವುದು:

$ 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 ಮತ್ತು ಸ್ವಾರ್ಮ್ ನೋಡ್‌ಗಳನ್ನು ಸಂಪರ್ಕಿಸಿದ್ದೇವೆ: ಪ್ರಮಾಣಪತ್ರಗಳನ್ನು ಸ್ಥಾಪಿಸುವುದು, ರಹಸ್ಯ ವೇರಿಯೇಬಲ್‌ಗಳನ್ನು ಹೊಂದಿಸುವುದು ಮತ್ತು ನಿಯಂತ್ರಣ ಸರ್ವರ್‌ನಲ್ಲಿ ಡಾಕರ್ ಸೇವೆಯನ್ನು ಹೊಂದಿಸುವುದು. ಇದು ಒಂದು ಲೇಖನ ನಮಗೆ ಸಾಕಷ್ಟು ಸಮಯವನ್ನು ಉಳಿಸಿದೆ.

ಮುಂದೆ, ನಾವು .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

ಮೇಲಿನ ಕೋಡ್ ತುಣುಕಿನಿಂದ, ಹಸ್ತಚಾಲಿತ ಕ್ರಿಯೆಯ ಅಗತ್ಯವಿರುವ ಪೈಪ್‌ಲೈನ್‌ಗಳಿಗೆ ಎರಡು ಬಟನ್‌ಗಳನ್ನು (ಡಿಪ್ಲಾಯ್_ಸ್ಟೇಜಿಂಗ್, ಸ್ಟಾಪ್_ಸ್ಟೇಜಿಂಗ್) ಸೇರಿಸಲಾಗಿದೆ ಎಂದು ನೀವು ನೋಡಬಹುದು.

ಡಾಕರ್ ಸಮೂಹದೊಂದಿಗೆ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ನಿಯೋಜಿಸಿ
ಸ್ಟಾಕ್ ಹೆಸರು ಶಾಖೆಯ ಹೆಸರಿಗೆ ಹೊಂದಿಕೆಯಾಗುತ್ತದೆ ಮತ್ತು ಈ ಅನನ್ಯತೆಯು ಸಾಕಷ್ಟು ಇರಬೇಕು. ಸ್ಟಾಕ್‌ನಲ್ಲಿರುವ ಸೇವೆಗಳು ಅನನ್ಯ ಐಪಿ ವಿಳಾಸಗಳು ಮತ್ತು ಪೋರ್ಟ್‌ಗಳು, ಡೈರೆಕ್ಟರಿಗಳು ಇತ್ಯಾದಿಗಳನ್ನು ಸ್ವೀಕರಿಸುತ್ತವೆ. ಪ್ರತ್ಯೇಕಿಸಲಾಗುವುದು, ಆದರೆ ಸ್ಟಾಕ್‌ನಿಂದ ಸ್ಟಾಕ್‌ಗೆ ಒಂದೇ ಆಗಿರುತ್ತದೆ (ಏಕೆಂದರೆ ಎಲ್ಲಾ ಸ್ಟ್ಯಾಕ್‌ಗಳಿಗೆ ಕಾನ್ಫಿಗರೇಶನ್ ಫೈಲ್ ಒಂದೇ ಆಗಿರುತ್ತದೆ) - ನಮಗೆ ಬೇಕಾದುದನ್ನು. ನಾವು ಬಳಸಿಕೊಂಡು ಸ್ಟಾಕ್ (ಕ್ಲಸ್ಟರ್) ಅನ್ನು ನಿಯೋಜಿಸುತ್ತೇವೆ 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 ರಲ್ಲಿ ವಿವರಿಸಿದ ನಿಯೋಜನೆಯಿಂದ ಪ್ರಾಯೋಗಿಕವಾಗಿ ಭಿನ್ನವಾಗಿರುವುದಿಲ್ಲ. ನಾನು ವ್ಯತ್ಯಾಸಗಳನ್ನು ಹೈಲೈಟ್ ಮಾಡುತ್ತೇನೆ:

  • ಜಿಟ್ ಕ್ಲೋನ್... - ನಿಯೋಜಿಸಲು ಅಗತ್ಯವಿರುವ ಫೈಲ್‌ಗಳನ್ನು ಪಡೆಯಿರಿ (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

ಡಾಕರ್-ಕಂಪೋಸ್-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

ಅಭಿವೃದ್ಧಿ ಕಂಪ್ಯೂಟರ್‌ಗಳಲ್ಲಿ, ಅಪ್‌ಡೇಟ್ /ಇತ್ಯಾದಿ/ಹೋಸ್ಟ್‌ಗಳು; nginx ಗೆ url ಅನ್ನು ಸೂಚಿಸಿ:

10.50.173.106 staging_BRANCH-1831_cluster.dev

ಆದ್ದರಿಂದ, ಪ್ರತ್ಯೇಕವಾದ ಸ್ಟೇಜಿಂಗ್ ಕ್ಲಸ್ಟರ್‌ಗಳ ನಿಯೋಜನೆಯನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲಾಗಿದೆ ಮತ್ತು ಡೆವಲಪರ್‌ಗಳು ಈಗ ತಮ್ಮ ಕಾರ್ಯಗಳನ್ನು ಪರಿಶೀಲಿಸಲು ಸಾಕಷ್ಟು ಸಂಖ್ಯೆಯಲ್ಲಿ ಅವುಗಳನ್ನು ಚಲಾಯಿಸಬಹುದು.

ಭವಿಷ್ಯದ ಯೋಜನೆಗಳು:

  • ನಮ್ಮ ಘಟಕಗಳನ್ನು ಸೇವೆಗಳಾಗಿ ಪ್ರತ್ಯೇಕಿಸಿ
  • ಪ್ರತಿ ಡಾಕರ್‌ಫೈಲ್‌ಗಾಗಿ ಹೊಂದಿರಿ
  • ಸ್ಟಾಕ್‌ನಲ್ಲಿ ಕಡಿಮೆ ಲೋಡ್ ಮಾಡಲಾದ ನೋಡ್‌ಗಳನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಪತ್ತೆ ಮಾಡಿ
  • ಹೆಸರಿನ ಮಾದರಿಯ ಮೂಲಕ ನೋಡ್‌ಗಳನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸಿ (ಲೇಖನದಲ್ಲಿರುವಂತೆ ಐಡಿಯನ್ನು ಬಳಸುವ ಬದಲು)
  • ಸ್ಟಾಕ್ ನಾಶವಾಗಿದೆ ಎಂದು ಚೆಕ್ ಸೇರಿಸಿ
  • ...

ವಿಶೇಷ ಧನ್ಯವಾದಗಳು ಲೇಖನ.

ಮೂಲ: www.habr.com

ಕಾಮೆಂಟ್ ಅನ್ನು ಸೇರಿಸಿ