Docker Swarm으로 애플리케이션 배포

우리가 작업하고 있는 온라인 비디오 콘텐츠 추천 시스템은 폐쇄형 상용 개발이며 기술적으로 독점 및 오픈 소스 구성 요소의 다중 구성 요소 클러스터입니다. 이 기사를 작성하는 목적은 제한된 시간 내에 프로세스의 확립된 워크플로우를 방해하지 않고 스테이징 사이트에 대한 docker swarm 클러스터링 시스템의 구현을 설명하는 것입니다. 귀하의 관심을 끌기 위해 제시된 내러티브는 두 부분으로 나뉩니다. 첫 번째 부분은 docker swarm을 사용하기 전에 CI/CD를 설명하고 두 번째 부분은 구현 과정을 설명합니다. 첫 번째 부분을 읽는 데 관심이 없는 사람들은 안전하게 두 번째 부분으로 넘어갈 수 있습니다.

제 1 부

멀고 먼 해에 CI / CD 프로세스를 최대한 빨리 설정해야했습니다. 조건 중 하나는 Docker를 사용하지 않는 것이었습니다. 배치를 위해 다음과 같은 몇 가지 이유로 구성 요소를 개발했습니다.

• 프로덕션에서 구성 요소의 보다 안정적이고 안정적인 작동을 위해(즉, 가상화를 사용하지 않는 요구 사항)
• 선도적인 개발자들은 Docker로 작업하기를 원하지 않았습니다(이상하지만 그랬습니다).
• R&D 관리의 이데올로기적 고려에 따라

MVP에 대한 인프라, 스택 및 대략적인 초기 요구 사항은 다음과 같이 제시되었습니다.

• Debian이 탑재된 Intel® X4 서버 5650대(강력한 머신 한 대 더 개발 완료)
• 자체 커스텀 컴포넌트 개발은 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

필요한 모든 시스템 패키지가 이미 설치되고 기타 설정이 완료된 자체 이미지에서 조립 및 테스트가 수행된다는 점은 주목할 가치가 있습니다.

작업의 각 스크립트는 나름대로 흥미롭지 만 물론 이야기하지는 않겠습니다 각각에 대한 설명은 많은 시간이 걸리며 이것이 기사의 목적이 아닙니다. 배포 단계가 일련의 호출 스크립트로 구성된다는 사실에만 주의를 기울이겠습니다.

1. createconfig.py - 후속 배포를 위해 다양한 환경에서 구성 요소 설정이 포함된 settings.ini 파일 생성(사전 프로덕션, 프로덕션, 테스트 등)
2. install_venv.sh - 특정 디렉터리에 py 구성 요소에 대한 가상 환경을 생성하고 원격 서버에 복사
3. 준비_초기화.d.py — 템플릿을 기반으로 구성 요소에 대한 시작-중지 스크립트를 준비합니다.
4. 배포.py - 새로운 구성 요소를 분해하고 다시 시작합니다.

시간이 지났습니다. 스테이징 단계는 프리프로덕션과 프로덕션으로 대체되었습니다. 하나 이상의 배포(CentOS)에서 제품에 대한 지원을 추가했습니다. 5개의 더 강력한 물리적 서버와 XNUMX개의 가상 서버를 추가했습니다. 그리고 개발자와 테스터가 작업 상태에 어느 정도 가까운 환경에서 작업을 테스트하는 것이 점점 더 어려워졌습니다. 이때 그 없이는 불가능하다는 것이 분명해졌습니다 ...

2 부

따라서 우리 클러스터는 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

다음으로 CI에서 노드 원격 제어 측면에서 Gitlab-CI 및 Swarm 노드를 연결했습니다. 인증서 설치, 비밀 변수 설정 및 제어 서버에서 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)이 파이프라인에 추가되어 수동 작업이 필요한 것을 볼 수 있습니다.

스택 이름은 분기 이름과 일치하며 이 고유성으로 충분해야 합니다. 스택의 서비스는 고유한 IP 주소, 포트, 디렉터리 등을 받습니다. 격리되지만 스택마다 동일합니다(구성 파일이 모든 스택에 대해 동일하기 때문에) - 우리가 원하는 것입니다. 다음을 사용하여 스택(클러스터)을 배포합니다. 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를 하나의 큰 구성된 이미지에 전달하는 것처럼 보이며 일반적으로 XNUMX부에서 설명한 배포와 실질적으로 다르지 않습니다. 차이점을 강조하겠습니다.

• 자식 복제... - 배포에 필요한 파일 가져오기(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

개발 컴퓨터에서 /etc/hosts를 업데이트합니다. nginx에 URL을 지정하십시오.

10.50.173.106 staging_BRANCH-1831_cluster.dev

따라서 격리된 스테이징 클러스터의 배포가 구현되었으며 개발자는 이제 작업을 확인하기에 충분한 수만큼 클러스터를 실행할 수 있습니다.

향후 계획:

• 구성 요소를 서비스로 분리
• Dockerfile마다 있음
• 스택에서 부하가 적은 노드를 자동으로 감지
• 이름 패턴으로 노드 지정(기사에서와 같이 id를 사용하는 대신)
• 스택이 파괴되었는지 확인 추가
• ...

특별한 감사 статью.

출처 : habr.com