ਡੌਕਰ ਸਵਾਰਮ ਨਾਲ ਐਪਲੀਕੇਸ਼ਨਾਂ ਨੂੰ ਤੈਨਾਤ ਕਰੋ

ਔਨਲਾਈਨ ਵੀਡੀਓ ਸਮਗਰੀ ਸਿਫ਼ਾਰਿਸ਼ ਪ੍ਰਣਾਲੀ ਜਿਸ 'ਤੇ ਅਸੀਂ ਕੰਮ ਕਰ ਰਹੇ ਹਾਂ ਇੱਕ ਬੰਦ ਵਪਾਰਕ ਵਿਕਾਸ ਹੈ ਅਤੇ ਤਕਨੀਕੀ ਤੌਰ 'ਤੇ ਮਲਕੀਅਤ ਅਤੇ ਓਪਨ ਸੋਰਸ ਭਾਗਾਂ ਦਾ ਇੱਕ ਬਹੁ-ਕੰਪੋਨੈਂਟ ਕਲੱਸਟਰ ਹੈ। ਇਸ ਲੇਖ ਨੂੰ ਲਿਖਣ ਦਾ ਉਦੇਸ਼ ਇੱਕ ਸੀਮਤ ਸਮੇਂ ਵਿੱਚ ਸਾਡੀਆਂ ਪ੍ਰਕਿਰਿਆਵਾਂ ਦੇ ਸਥਾਪਿਤ ਵਰਕਫਲੋ ਵਿੱਚ ਵਿਘਨ ਪਾਏ ਬਿਨਾਂ ਇੱਕ ਸਟੇਜਿੰਗ ਸਾਈਟ ਲਈ ਡੌਕਰ ਸਵੈਰਮ ਕਲੱਸਟਰਿੰਗ ਸਿਸਟਮ ਨੂੰ ਲਾਗੂ ਕਰਨ ਦਾ ਵਰਣਨ ਕਰਨਾ ਹੈ। ਤੁਹਾਡੇ ਧਿਆਨ ਵਿੱਚ ਪੇਸ਼ ਕੀਤਾ ਗਿਆ ਬਿਰਤਾਂਤ ਦੋ ਹਿੱਸਿਆਂ ਵਿੱਚ ਵੰਡਿਆ ਗਿਆ ਹੈ। ਪਹਿਲਾ ਭਾਗ ਡੌਕਰ ਸਵੈਮ ਦੀ ਵਰਤੋਂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਸੀਆਈ / ਸੀਡੀ ਦਾ ਵਰਣਨ ਕਰਦਾ ਹੈ, ਅਤੇ ਦੂਜਾ ਇਸਦੇ ਲਾਗੂ ਕਰਨ ਦੀ ਪ੍ਰਕਿਰਿਆ ਦਾ ਵਰਣਨ ਕਰਦਾ ਹੈ। ਜਿਹੜੇ ਲੋਕ ਪਹਿਲੇ ਭਾਗ ਨੂੰ ਪੜ੍ਹਨ ਵਿੱਚ ਦਿਲਚਸਪੀ ਨਹੀਂ ਰੱਖਦੇ ਉਹ ਸੁਰੱਖਿਅਤ ਢੰਗ ਨਾਲ ਦੂਜੇ ਭਾਗ ਵਿੱਚ ਜਾ ਸਕਦੇ ਹਨ।

ਭਾਗ I

ਵਾਪਸ ਦੂਰ, ਦੂਰ ਦੇ ਸਾਲ ਵਿੱਚ, ਜਿੰਨੀ ਜਲਦੀ ਹੋ ਸਕੇ ਸੀਆਈ / ਸੀਡੀ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਸਥਾਪਤ ਕਰਨਾ ਜ਼ਰੂਰੀ ਸੀ. ਸ਼ਰਤਾਂ ਵਿੱਚੋਂ ਇੱਕ ਇਹ ਸੀ ਕਿ ਡੌਕਰ ਦੀ ਵਰਤੋਂ ਨਾ ਕੀਤੀ ਜਾਵੇ ਤਾਇਨਾਤੀ ਲਈ ਕਈ ਕਾਰਨਾਂ ਕਰਕੇ ਵਿਕਸਤ ਹਿੱਸੇ:

• ਉਤਪਾਦਨ ਵਿੱਚ ਭਾਗਾਂ ਦੇ ਵਧੇਰੇ ਭਰੋਸੇਮੰਦ ਅਤੇ ਸਥਿਰ ਸੰਚਾਲਨ ਲਈ (ਜੋ ਕਿ ਅਸਲ ਵਿੱਚ, ਵਰਚੁਅਲਾਈਜੇਸ਼ਨ ਦੀ ਵਰਤੋਂ ਨਾ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਹੈ)
• ਪ੍ਰਮੁੱਖ ਡਿਵੈਲਪਰ ਡੌਕਰ ਨਾਲ ਕੰਮ ਨਹੀਂ ਕਰਨਾ ਚਾਹੁੰਦੇ ਸਨ (ਅਜੀਬ, ਪਰ ਇਹ ਇਸ ਤਰ੍ਹਾਂ ਸੀ)
• ਖੋਜ ਅਤੇ ਵਿਕਾਸ ਪ੍ਰਬੰਧਨ ਦੇ ਵਿਚਾਰਧਾਰਕ ਵਿਚਾਰਾਂ ਦੇ ਅਨੁਸਾਰ

MVP ਲਈ ਬੁਨਿਆਦੀ ਢਾਂਚਾ, ਸਟੈਕ ਅਤੇ ਅੰਦਾਜ਼ਨ ਸ਼ੁਰੂਆਤੀ ਲੋੜਾਂ ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਪੇਸ਼ ਕੀਤਾ ਗਿਆ ਸੀ:

• ਡੇਬੀਅਨ ਦੇ ਨਾਲ 4 Intel® X5650 ਸਰਵਰ (ਇੱਕ ਹੋਰ ਸ਼ਕਤੀਸ਼ਾਲੀ ਮਸ਼ੀਨ ਪੂਰੀ ਤਰ੍ਹਾਂ ਵਿਕਸਤ ਹੈ)
• ਆਪਣੇ ਕਸਟਮ ਭਾਗਾਂ ਦਾ ਵਿਕਾਸ C++, Python3 ਵਿੱਚ ਕੀਤਾ ਜਾਂਦਾ ਹੈ
• ਮੁੱਖ 3rd ਪਾਰਟੀ ਟੂਲ ਵਰਤੇ ਗਏ: ਕਾਫਕਾ, ਕਲਿਕਹਾਊਸ, ਏਅਰਫਲੋ, ਰੇਡਿਸ, ਗ੍ਰਾਫਾਨਾ, ਪੋਸਟਗ੍ਰੇਸਕਿਲ, ਮਾਈਐਸਕਐਲ, ...
• ਡੀਬੱਗ ਅਤੇ ਰੀਲੀਜ਼ ਲਈ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਕੰਪੋਨੈਂਟ ਬਣਾਉਣ ਅਤੇ ਟੈਸਟ ਕਰਨ ਲਈ ਪਾਈਪਲਾਈਨਾਂ

ਸ਼ੁਰੂਆਤੀ ਪੜਾਅ 'ਤੇ ਸੰਬੋਧਿਤ ਕੀਤੇ ਜਾਣ ਵਾਲੇ ਪਹਿਲੇ ਸਵਾਲਾਂ ਵਿੱਚੋਂ ਇੱਕ ਇਹ ਹੈ ਕਿ ਕਿਸੇ ਵੀ ਵਾਤਾਵਰਣ (CI / CD) ਵਿੱਚ ਕਸਟਮ ਕੰਪੋਨੈਂਟਸ ਨੂੰ ਕਿਵੇਂ ਤਾਇਨਾਤ ਕੀਤਾ ਜਾਵੇਗਾ।

ਅਸੀਂ ਤੀਜੀ-ਧਿਰ ਦੇ ਭਾਗਾਂ ਨੂੰ ਪ੍ਰਣਾਲੀਗਤ ਤੌਰ 'ਤੇ ਸਥਾਪਤ ਕਰਨ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਪ੍ਰਣਾਲੀਗਤ ਤੌਰ 'ਤੇ ਅਪਡੇਟ ਕਰਨ ਦਾ ਫੈਸਲਾ ਕੀਤਾ ਹੈ। C++ ਜਾਂ Python ਵਿੱਚ ਵਿਕਸਤ ਕਸਟਮ ਐਪਲੀਕੇਸ਼ਨਾਂ ਨੂੰ ਕਈ ਤਰੀਕਿਆਂ ਨਾਲ ਤੈਨਾਤ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਉਹਨਾਂ ਵਿੱਚੋਂ, ਉਦਾਹਰਨ ਲਈ: ਸਿਸਟਮ ਪੈਕੇਜ ਬਣਾਉਣਾ, ਉਹਨਾਂ ਨੂੰ ਬਿਲਟ ਚਿੱਤਰਾਂ ਦੀ ਰਿਪੋਜ਼ਟਰੀ ਵਿੱਚ ਭੇਜਣਾ ਅਤੇ ਫਿਰ ਉਹਨਾਂ ਨੂੰ ਸਰਵਰਾਂ ਉੱਤੇ ਇੰਸਟਾਲ ਕਰਨਾ। ਕਿਸੇ ਅਣਜਾਣ ਕਾਰਨ ਕਰਕੇ, ਇੱਕ ਹੋਰ ਤਰੀਕਾ ਚੁਣਿਆ ਗਿਆ ਸੀ, ਅਰਥਾਤ: 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 - ਇੱਕ ਖਾਸ ਡਾਇਰੈਕਟਰੀ ਵਿੱਚ py ਭਾਗਾਂ ਲਈ ਇੱਕ ਵਰਚੁਅਲ ਵਾਤਾਵਰਣ ਬਣਾਉਂਦਾ ਹੈ ਅਤੇ ਇਸਨੂੰ ਰਿਮੋਟ ਸਰਵਰਾਂ ਤੇ ਨਕਲ ਕਰਦਾ ਹੈ
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 .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) ਪਾਈਪਲਾਈਨਾਂ ਵਿੱਚ ਸ਼ਾਮਲ ਕੀਤੇ ਗਏ ਹਨ, ਜਿਸ ਲਈ ਦਸਤੀ ਕਾਰਵਾਈ ਦੀ ਲੋੜ ਹੈ।

ਸਟੈਕ ਨਾਮ ਸ਼ਾਖਾ ਦੇ ਨਾਮ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ ਅਤੇ ਇਹ ਵਿਲੱਖਣਤਾ ਕਾਫ਼ੀ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ। ਸਟੈਕ ਵਿੱਚ ਸੇਵਾਵਾਂ ਵਿਲੱਖਣ ਆਈਪੀ ਪਤੇ, ਅਤੇ ਪੋਰਟਾਂ, ਡਾਇਰੈਕਟਰੀਆਂ, ਆਦਿ ਪ੍ਰਾਪਤ ਕਰਦੀਆਂ ਹਨ। ਅਲੱਗ ਕੀਤਾ ਜਾਵੇਗਾ, ਪਰ ਸਟੈਕ ਤੋਂ ਸਟੈਕ ਤੱਕ ਇੱਕੋ ਜਿਹਾ (ਕਿਉਂਕਿ ਸੰਰਚਨਾ ਫਾਈਲ ਸਾਰੇ ਸਟੈਕ ਲਈ ਇੱਕੋ ਜਿਹੀ ਹੈ) - ਜੋ ਅਸੀਂ ਚਾਹੁੰਦੇ ਸੀ। ਅਸੀਂ ਸਟੈਕ (ਕਲੱਸਟਰ) ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਤਾਇਨਾਤ ਕਰਦੇ ਹਾਂ ਡੌਕਰ-ਕੰਪੋਜ਼.ਆਈ.ਐਮ.ਐਲ., ਜੋ ਸਾਡੇ ਕਲੱਸਟਰ ਦਾ ਵਰਣਨ ਕਰਦਾ ਹੈ।

ਡੌਕਰ-ਕੰਪੋਜ਼.ਆਈ.ਐਮ.ਐਲ.

---
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 ਵਿੱਚ, ਕਲੱਸਟਰ ਸਟੈਕ ਨੂੰ ਤੈਨਾਤ ਕਰਨ ਤੋਂ ਬਾਅਦ, ਅਸੀਂ ਬੈਲੇਂਸਰ ਨੂੰ ਤੈਨਾਤ ਕਰਨ ਦੀ ਲਾਈਨ ਜੋੜਦੇ ਹਾਂ (ਜੋ, ਜਦੋਂ ਕਮਿਟ ਕਰਦਾ ਹੈ, ਤਾਂ ਸਿਰਫ ਇਸਦੀ ਸੰਰਚਨਾ ਨੂੰ ਅੱਪਡੇਟ ਕਰਦਾ ਹੈ (ਟੈਂਪਲੇਟ: /etc/nginx/conf ਦੇ ਅਨੁਸਾਰ ਨਵੀਂ nginx ਸੰਰਚਨਾ ਫਾਈਲਾਂ ਬਣਾਉਂਦਾ ਹੈ। 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