🥇פרוס אפליקציות עם Docker Swarm

מערכת המלצות תוכן הווידאו המקוונת עליה אנו עובדים היא פיתוח מסחרי סגור ומהווה טכנית אשכול מרובה רכיבים של רכיבים קנייניים וקוד פתוח. מטרת כתיבת מאמר זה היא לתאר את ההטמעה של מערכת האשכולות של docker swarm עבור אתר סטaging מבלי לשבש את זרימת העבודה המבוססת של התהליכים שלנו בזמן מוגבל. הנרטיב המובא לידיעתך מחולק לשני חלקים. החלק הראשון מתאר CI / CD לפני השימוש ב- Docker swarm, והשני מתאר את תהליך היישום שלו. מי שלא מעוניין לקרוא את החלק הראשון יכול לעבור בבטחה אל השני.

Часть אני

עוד בשנה הרחוקה, הרחוקה, היה צורך להגדיר את תהליך ה-CI/CD במהירות האפשרית. אחד התנאים היה לא להשתמש ב-Docker לפריסה פיתח רכיבים מכמה סיבות:

לפעולה אמינה ויציבה יותר של רכיבים ב-Production (כלומר, למעשה, הדרישה לא להשתמש בווירטואליזציה)
מפתחים מובילים לא רצו לעבוד עם Docker (מוזר, אבל ככה זה היה)
לפי השיקולים האידיאולוגיים של הנהלת המו"פ

תשתיות, ערימה ודרישות ראשוניות משוערות ל-MVP הוצגו כדלקמן:

4 שרתי Intel® X5650 עם Debian (מכונה אחת חזקה יותר פותחה במלואה)
פיתוח רכיבים מותאמים אישית משלו מתבצע ב-C++, Python3
כלי צד שלישי עיקריים בשימוש: Kafka, Clickhouse, Airflow, Redis, Grafana, Postgresql, Mysql, …
צינורות לבנייה ובדיקה של רכיבים בנפרד לצורך ניפוי ושחרור

אחת השאלות הראשונות שיש להתייחס אליהן בשלב הראשוני היא כיצד רכיבים מותאמים אישית ייפרסו בכל סביבה (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

ראוי לציין כי ההרכבה והבדיקה מתבצעת על תמונה משלה, שבה כל חבילות המערכת הדרושות כבר הותקנו ונעשו הגדרות אחרות.

אמנם כל אחד מהתסריטים הללו בעבודות מעניין בדרכו שלו, אבל כמובן שלא אדבר עליהם, התיאור של כל אחד מהם ייקח הרבה זמן וזו לא מטרת המאמר. אני רק אפנה את תשומת לבך לעובדה ששלב הפריסה מורכב מרצף של תסריטי קריאה:

createconfig.py - יוצר קובץ settings.ini עם הגדרות רכיבים בסביבות שונות לפריסה לאחר מכן (קדם ייצור, ייצור, בדיקה, ...)
install_venv.sh - יוצר סביבה וירטואלית עבור רכיבי py בספרייה ספציפית ומעתיק אותה לשרתים מרוחקים
prepare_init.d.py - מכין סקריפטים של התחלה-עצירה עבור הרכיב בהתבסס על התבנית
deploy.py - מפרק ומפעיל מחדש רכיבים חדשים

הזמן עבר. שלב הבימוי הוחלף בקדם ייצור והפקה. נוספה תמיכה במוצר בהפצה אחת נוספת (CentOS). נוספו עוד 5 שרתים פיזיים חזקים ותריסר וירטואליים. ומפתחים ובודקים נהיה יותר ויותר קשה לבדוק את המשימות שלהם בסביבה קרובה פחות או יותר למצב העבודה. בשלב זה התברר שאי אפשר בלעדיו...

חלק ב '

אז, האשכול שלנו הוא מערכת מרהיבה של כמה עשרות רכיבים נפרדים שאינם מתוארים על ידי Dockerfiles. אתה יכול להגדיר אותו רק לפריסה בסביבה ספציפית באופן כללי. המשימה שלנו היא לפרוס את האשכול לתוך סביבת בימוי כדי לבדוק אותו לפני בדיקות טרום-הפצה.

תיאורטית, יכולים להיות מספר אשכולות הפועלים בו-זמנית: כמה שיהיו משימות במצב הושלם או קרוב לסיום. היכולות של השרתים העומדים לרשותנו מאפשרות לנו להפעיל מספר אשכולות בכל שרת. יש לבודד כל מקבץ ביניים (אסור להיות צומת ביציאות, ספריות וכו').

המשאב היקר ביותר שלנו הוא הזמן שלנו, ולא היה לנו הרבה ממנו.

להתחלה מהירה יותר, בחרנו ב-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 מבחינת שליטה מרחוק על צמתים מ-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.ym, שמתאר את האשכול שלנו.

docker-compose.ym

---
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, לאחר פריסת מחסנית האשכולות, אנו מוסיפים את שורת הפריסה של ה-balancer (אשר, בעת commit, מעדכן רק את התצורה שלו (יוצר קבצי תצורה חדשים של 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; רשום כתובת אתר ל-nginx:

10.50.173.106 staging_BRANCH-1831_cluster.dev
לכן, הפריסה של אשכולות בימוי מבודדים יושמה ומפתחים יכולים כעת להפעיל אותם בכל מספר מספיק כדי לבדוק את המשימות שלהם.

תוכניות עתידיות:

הפרד את הרכיבים שלנו כשירותים
יש עבור כל Dockerfile
זיהוי אוטומטי של צמתים פחות טעונים בערימה
ציין צמתים לפי דפוס שמות (במקום להשתמש ב-id כמו במאמר)
הוסף סימון שהמחסנית נהרסה
...

תודה מיוחדת על מאמר.

מקור: www.habr.com

פרוס יישומים עם Docker Swarm

Часть אני

חלק ב '

הוספת תגובה ביטול תגובה