ഡോക്കർ സ്വാം ഉപയോഗിച്ച് ആപ്ലിക്കേഷനുകൾ വിന്യസിക്കുക

ഞങ്ങൾ പ്രവർത്തിക്കുന്ന ഓൺലൈൻ വീഡിയോ ഉള്ളടക്ക ശുപാർശ സംവിധാനം ഒരു അടഞ്ഞ വാണിജ്യ വികസനമാണ്, സാങ്കേതികമായി കുത്തക, ഓപ്പൺ സോഴ്‌സ് ഘടകങ്ങളുടെ ഒരു മൾട്ടി-ഘടക ക്ലസ്റ്ററാണ്. ഈ ലേഖനം എഴുതുന്നതിന്റെ ഉദ്ദേശ്യം, പരിമിതമായ സമയ സാഹചര്യങ്ങളിൽ ഞങ്ങളുടെ പ്രക്രിയകളുടെ സ്ഥാപിത വർക്ക്ഫ്ലോയെ തടസ്സപ്പെടുത്താതെ, ഒരു സ്റ്റേജിംഗ് പ്ലാറ്റ്‌ഫോമിനായി ഡോക്കർ സ്വാം ക്ലസ്റ്ററിംഗ് സിസ്റ്റം നടപ്പിലാക്കുന്നത് വിവരിക്കുക എന്നതാണ്. നിങ്ങളുടെ ശ്രദ്ധയിൽപ്പെടുത്തിയ ആഖ്യാനം രണ്ട് ഭാഗങ്ങളായി തിരിച്ചിരിക്കുന്നു. ഡോക്കർ സ്വോം ഉപയോഗിക്കുന്നതിന് മുമ്പ് ആദ്യ ഭാഗം CI/CD വിവരിക്കുന്നു, രണ്ടാം ഭാഗം അത് നടപ്പിലാക്കുന്ന പ്രക്രിയ വിവരിക്കുന്നു. ആദ്യഭാഗം വായിക്കാൻ താല്പര്യമില്ലാത്തവർക്ക് സുരക്ഷിതമായി രണ്ടാമത്തേതിലേക്ക് കടക്കാം.

ചാസ്റ്റ് ഐ

ഒരു കാലത്ത്, കഴിയുന്നത്ര വേഗത്തിൽ ഒരു CI/CD പ്രോസസ്സ് സജ്ജീകരിക്കേണ്ടതിന്റെ ആവശ്യകത ഉണ്ടായിരുന്നു. ഡോക്കർ ഉപയോഗിക്കരുത് എന്നതായിരുന്നു ഒരു നിബന്ധന വിന്യാസത്തിനായി ഘടകങ്ങൾ പല കാരണങ്ങളാൽ വികസിപ്പിച്ചെടുക്കുന്നു:

• ഉൽ‌പാദനത്തിലെ ഘടകങ്ങളുടെ കൂടുതൽ വിശ്വസനീയവും സുസ്ഥിരവുമായ പ്രവർത്തനത്തിന് (അതായത്, സാരാംശത്തിൽ, വിർച്ച്വലൈസേഷൻ ഉപയോഗിക്കേണ്ടതില്ല എന്ന ആവശ്യകത)
• മുൻനിര ഡവലപ്പർമാർ ഡോക്കറുമായി പ്രവർത്തിക്കാൻ ആഗ്രഹിച്ചില്ല (വിചിത്രം, പക്ഷേ അങ്ങനെയായിരുന്നു)
• ആർ ആൻഡ് ഡി മാനേജ്‌മെന്റിന്റെ പ്രത്യയശാസ്ത്രപരമായ കാരണങ്ങളാൽ

MVP-യുടെ അടിസ്ഥാന സൗകര്യങ്ങളും സ്റ്റാക്കും ഏകദേശ പ്രാരംഭ ആവശ്യകതകളും ഇനിപ്പറയുന്നവയാണ്:

• 4 Debian ഉള്ള Intel® X5650 സെർവറുകൾ (വികസനത്തിനായി പൂർണ്ണമായും ഒരു ശക്തമായ യന്ത്രം)
• നിങ്ങളുടെ സ്വന്തം ഇഷ്‌ടാനുസൃത ഘടകങ്ങളുടെ വികസനം C++, Python3-ൽ നടപ്പിലാക്കുന്നു
• ഉപയോഗിച്ച പ്രധാന മൂന്നാം കക്ഷി ടൂളുകൾ: കാഫ്ക, ക്ലിക്ക്ഹൗസ്, എയർഫ്ലോ, റെഡിസ്, ഗ്രാഫാന, പോസ്റ്റ്ഗ്രെസ്‌ക്എൽ, മൈസ്‌ക്യുഎൽ, …
• ഡീബഗ് ചെയ്യുന്നതിനും റിലീസ് ചെയ്യുന്നതിനുമായി പ്രത്യേകം ഘടകങ്ങൾ നിർമ്മിക്കുന്നതിനും പരിശോധിക്കുന്നതിനുമുള്ള പൈപ്പ് ലൈനുകൾ

പ്രാരംഭ ഘട്ടത്തിൽ പരിഹരിക്കേണ്ട ആദ്യത്തെ ചോദ്യങ്ങളിലൊന്ന്, ഏത് പരിതസ്ഥിതിയിലും (CI/CD) ഇഷ്‌ടാനുസൃത ഘടകങ്ങൾ എങ്ങനെ വിന്യസിക്കും എന്നതാണ്.

മൂന്നാം കക്ഷി ഘടകങ്ങൾ വ്യവസ്ഥാപിതമായി ഇൻസ്റ്റാൾ ചെയ്യാനും വ്യവസ്ഥാപിതമായി അപ്ഡേറ്റ് ചെയ്യാനും ഞങ്ങൾ തീരുമാനിച്ചു. C++ അല്ലെങ്കിൽ Python-ൽ വികസിപ്പിച്ച ഇഷ്‌ടാനുസൃത ആപ്ലിക്കേഷനുകൾ പല തരത്തിൽ വിന്യസിക്കാൻ കഴിയും. അവയിൽ, ഉദാഹരണത്തിന്: സിസ്റ്റം പാക്കേജുകൾ സൃഷ്ടിക്കുക, ശേഖരിച്ച ചിത്രങ്ങളുടെ ശേഖരത്തിലേക്ക് അയയ്ക്കുക, സെർവറുകളിൽ അവയുടെ തുടർന്നുള്ള ഇൻസ്റ്റാളേഷൻ. ഇതിനകം അജ്ഞാതമായ ഒരു കാരണത്താൽ, മറ്റൊരു രീതി തിരഞ്ഞെടുത്തു, അതായത്: CI ഉപയോഗിച്ച്, ആപ്ലിക്കേഷൻ എക്സിക്യൂട്ടബിൾ ഫയലുകൾ കംപൈൽ ചെയ്യുന്നു, ഒരു വെർച്വൽ പ്രോജക്റ്റ് എൻവയോൺമെന്റ് സൃഷ്ടിക്കപ്പെടുന്നു, ആവശ്യകതകൾ.txt-ൽ നിന്നുള്ള py മൊഡ്യൂളുകൾ ഇൻസ്റ്റാൾ ചെയ്തു, കൂടാതെ ഈ ആർട്ടിഫാക്റ്റുകളെല്ലാം കോൺഫിഗറുകൾ, സ്ക്രിപ്റ്റുകൾ എന്നിവയ്‌ക്കൊപ്പം അയയ്‌ക്കുന്നു. സെർവറുകളിലേക്കുള്ള ആപ്ലിക്കേഷൻ പരിതസ്ഥിതി. അടുത്തതായി, അഡ്മിനിസ്ട്രേറ്റർ അവകാശങ്ങളില്ലാതെ ഒരു വെർച്വൽ ഉപയോക്താവിൽ നിന്ന് ആപ്ലിക്കേഷനുകൾ സമാരംഭിക്കുന്നു.

CI/CD സിസ്റ്റമായി Gitlab-CI തിരഞ്ഞെടുത്തു. തത്ഫലമായുണ്ടാകുന്ന പൈപ്പ്ലൈൻ ഇതുപോലെ കാണപ്പെടുന്നു:

ഘടനാപരമായി, 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. ready_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, 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

മാനുവൽ പ്രവർത്തനം ആവശ്യമുള്ള പൈപ്പ് ലൈനുകളിൽ (ഡിപ്ലോയ്_സ്റ്റേജിംഗ്, സ്റ്റോപ്പ്_സ്റ്റേജിംഗ്) രണ്ട് ബട്ടണുകൾ ചേർത്തിട്ടുണ്ടെന്ന് മുകളിലെ കോഡ് ശകലത്തിൽ നിന്ന് വ്യക്തമാണ്.

സ്റ്റാക്ക് നാമം ബ്രാഞ്ചിന്റെ പേരുമായി പൊരുത്തപ്പെടുന്നു, ഈ പ്രത്യേകത മതിയാകും. സ്റ്റാക്കിലെ സേവനങ്ങൾക്ക് അദ്വിതീയ ഐപി വിലാസങ്ങളും പോർട്ടുകളും ഡയറക്‌ടറികളും മറ്റും ലഭിക്കും. ഒറ്റപ്പെട്ടതായിരിക്കും, എന്നാൽ സ്റ്റാക്ക് മുതൽ സ്റ്റാക്ക് വരെ ഒരേപോലെയാണ് (എല്ലാ സ്റ്റാക്കുകൾക്കും കോൺഫിഗറേഷൻ ഫയൽ ഒരുപോലെയാണ്) - അതാണ് ഞങ്ങൾ ആഗ്രഹിച്ചത്. ഞങ്ങൾ സ്റ്റാക്ക് (ക്ലസ്റ്റർ) ഉപയോഗിച്ച് വിന്യസിക്കുന്നു 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

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

അതിനാൽ, ഒറ്റപ്പെട്ട സ്റ്റേജിംഗ് ക്ലസ്റ്ററുകളുടെ വിന്യാസം നടപ്പിലാക്കി, ഡവലപ്പർമാർക്ക് അവരുടെ ടാസ്‌ക്കുകൾ പരിശോധിക്കുന്നതിന് ആവശ്യമായ ഏത് അളവിലും ഇപ്പോൾ അവ സമാരംഭിക്കാനാകും.

ഭാവി പരിപാടികള്:

• ഞങ്ങളുടെ ഘടകങ്ങളെ സേവനങ്ങളായി വേർതിരിക്കുക
• ഓരോന്നിനും ഒരു ഡോക്കർഫയൽ സൃഷ്ടിക്കുക
• സ്റ്റാക്കിൽ ലോഡ് കുറഞ്ഞ നോഡുകൾ സ്വയമേവ കണ്ടെത്തുക
• ഒരു നെയിം ടെംപ്ലേറ്റ് ഉപയോഗിച്ച് നോഡുകൾ വ്യക്തമാക്കുക (ലേഖനത്തിലെ പോലെ ഐഡി ഉപയോഗിക്കുന്നതിന് പകരം)
• സ്റ്റാക്ക് നശിച്ചുവെന്ന് ഒരു ചെക്ക് ചേർക്കുക
• പങ്ക് € |

പ്രത്യേകം നന്ദി ഒരു ലേഖനം.

അവലംബം: www.habr.com