현지 고객을 위한 우리의 배치 전략(중국)

작년(2019년) 한 고객은 중국에서 제품 구독을 판매할 수 있는 우리의 전 순환 비즈니스 플랫폼을 운영할 수 있느냐고 물었다.이것은 듣기에 거대한 도전 같다.중국에서 몇몇 행사를 개최하는 것은 세계 다른 곳에서 개최하는 것처럼 그렇게 간단하지 않다.
본고에서, 나는 당신에게 우리가 어떻게 배치 파이프라인을 채택하여 고객의 내부 배치를 지원하는지 보여 드리겠습니다.나는 중국을 예로 들어 독특한 도전을 제기했다.그러나 아래의 글은 모든 유형의 인프라 시설에서 응용 프로그램의 내부 배치를 설정하는 데 사용할 수 있다.

중국이 왜?
중국 대륙에서 장사를 하는 것은 어떤 비중국 회사에도 완전히 폐쇄적이다.중국에서 장사를 하려면 특정 제품 유형의 국내 영업 허가증이 필요하고 방화 장성에 대응해야 한다.당신이 중국 대륙 밖에서 위탁 관리할 때, 만리장성 방화벽은 당신의 연결을 매우 느리게 하거나 사용할 수 없게 할 것이다.따라서 중국 대륙에서 현지 인프라 시설을 건설하는 것은 매우 관건적이다.
불행하게도 중국 대륙 서버에서 위탁 관리나 배치 응용 프로그램도 완전히 잠겨 있어 중국 시민과 회사만 접근할 수 있다.이것이 바로 우리가 직면한 것이다.
우리는 이미 아리운(Aliyun)의 고객 위탁 관리 계정에 플랫폼의 내부 환경을 구축했다.이렇게 하는 과정에서 기존의 배치 과정과 위탁 관리 도구가 여전히 유효하다는 것을 확보한다.

우리들의 방법
이것이 바로 우리가 최종적으로 채택한 배치 방법이다.다음은 모든 중요한 구성 요소의 상세한 설정과 설정을 설명할 것입니다.나는 또한 특정 설정 설정에 대한 예시와 세션을 제공할 것이다.
GitHub의 각 PR을 주요 지점으로 결합할 때는 다음 단계를 수행합니다.

CircleCI 테스트, 안전 검사, 의존 항목 스캔 등을 실행

Circleci는 성공적으로 구축된 토대에서 특수한 생산 Docker 이미지 구축을 시작했다.

Circleci는 새로운 생산Docker 이미지를 Docker Hub의 저장소에 업로드합니다.Docker 이미지에는 Git commit SHA 태그가 있습니다.

개발자는 로컬 환경에 로그인하고 Dokku's 용기 기반의 배치를 통해 이미지를 배치한다.Git commit SHA는 배치할 버전을 식별하는 데 사용됩니다.

Dokku는 일반적인 배치 절차, 응용 프로그램 재시작, 자산 컴파일링, 이전 등을 실행한다

새 버전 출시!

서버 및 데이터베이스 설정
배치 과정은 최종 서버나 데이터베이스 설정과 매우 독립적이다.용기 이미지를 실행하고 다양한 데이터베이스 서비스를 제공하는 것이 필요합니다.
다음은 우리가 중국Aliyun(아리운)에서 사용한 내용입니다.위젯은 Dokku plugins를 통해 다른 클라우드 인프라나 로컬 구성 요소로 쉽게 조정하거나 교체할 수 있습니다.

Aliyun Elastic Compute Service Ubuntu LTS 인스턴스가 있습니다.

Aliyun ApsaraDB RDS for PostgreSQL .

Aliyun ApsaraDB for Redis .

Terraform 및 Ansible 표준 서버 설정을 사용하여 구성 서버를 만듭니다.

Dokku 서버 호스팅 및 배포 플랫폼입니다.

보시다시피, 우리는 PostgreSQL과 Redis에 사용되는 아리운의 위탁 관리 서비스를 사용했습니다.그러나 데이터 센터 유형(가상) 서버의 내부 환경에 배치하려면 이 설정을 변경할 수 있습니다.
예를 들어, Dokku의 Redis 및 PostgreSQL 플러그인을 사용할 수 있습니다.이 플러그인들은 프로그램 용기에서 실행되는 같은 서버에서 Redis와 PostgreSQL을 실행할 수 있도록 합니다.또한 애플리케이션만 이러한 서비스에 액세스할 수 있으며 기본적으로 공용 인터넷을 통해 액세스할 수 없습니다.

Dokku는 컨테이너 기반 배포
비교적 간단한 내부 배치에 대해 우리는 매우 좋아한다Dokku.Dokku는 설치가 쉽고 응용 프로그램이 곧 실행될 수 있도록 잘 지원되었다.
Dokku는 접근 제어, 배치, 이전 절차, 버전, 확장, 웹 서버 위탁 관리 등을 배치합니다. 백업, 각종 데이터베이스, 기타 필요한 구성 요소를 위한 우수한 플러그인도 있습니다.각 Dokku가 관리하는 애플리케이션에 대해 ENV VAR을 구성하여 런타임 시 구성 설정과 데이터베이스 연결을 설정할 수 있습니다.
Dokku는 귀하의 소형 응용 프로그램 배치 플랫폼으로 귀하의 인프라 시설에서 실행되는 서비스입니다.Read here on how to deploy your app via Dokku .
Dokku를 사용하면 git push 배포 정책을 사용하여 응용 프로그램을 배포하거나 Docker 컨테이너를 배포할 수 있습니다.우선,git 전송 배치 방법을 사용합니다.나중에 Docker 컨테이너 기반 배포 방법으로 전환합니다.

"git Push"를 사용하지 않는 이유
git push 방법의 문제는 소프트웨어가 실행하는 로컬 서버마다 실행하는 응용 프로그램의 버전이 약간 다르다는 것이다.같은 제출에 근거해서라도git push-in Dokku가 각 서버의 각 배치에 새 컨테이너 이미지를 구축하기 때문입니다.따라서 관리되는 모든 내부 배치 환경의 응용 프로그램 이미지가 완전히 같은지 확인할 수 없습니다.
또한 각 서버의 배치마다 Docker 컨테이너 구축이 트리거됩니다.짧은 시간 내에 프로그램을 배치하는 데 많은 CPU가 사용될 수 있습니다.충분한 크기의 서버에 접근할 수 없다면, 생산 프로그램을 닫을 수도 있습니다.
중국에 있어git push 방법은 만리장성과 관련된 문제가 하나 더 있다.유럽에서 중국까지의 인터넷 연결은 매우 신뢰할 수 없거나 매우 느리다.때때로 한 번 제출을 배치하는 데 몇 시간이 걸릴 수도 있습니다. 왜냐하면 우리의 코드 라이브러리는 반드시 중국의 서버로 전송해야 하기 때문입니다.하지만 Dokku는 배포 과정에서 대량의 이미지와 의존 항목을 다운로드해야 한다.우리는 연결, 정지, 몇 시간 정지, 또는 시간 초과만 볼 수 있다.

Docker 이미지 기반 배포로 전환
따라서 git 기반 푸시 배치의 모든 문제점은 Dokku를 사용하여 Docker 이미지 기반 배치로 전환합니다.더 많은 설치 작업이 필요하지만 결국 배치 과정이 더욱 원활하고 빠르다.
Dokku 설명서how to use Docker images for your deployments를 참조하십시오.
전환하면 기본적으로 로컬 서버에서 다음 명령을 실행하는 것처럼 보입니다.

$ docker pull firmhouse/platform:<Commit SHA> 
$ docker tag firmhouse/platform:<Commit SHA> dokku/platform:<Commit SHA> 
$ dokku tags:deploy platform <Commit SHA>

Dokku에 새 버전 명령 배포

생산 부두의 이미지를 만들다.
Circleci는 우리의 테스트 세트를 실행하고 Docker 용기를 구축하는 첫 번째 CI입니다.그것은 때때로 우리의 응용 프로그램을 직접 배치할 수도 있다.
다음은 Circleci에서 Docker 이미지를 만들어 Docker Hub 계정으로 전송하는 방법에 대한 설정 세션입니다.

Circleci 구성은 이미지 구축 및 푸시
GoogleCircleci 작업 흐름에는 제품 이미지를 구축하고 이를 Docker Hub로 전송하는 특수한 구축 절차가 있습니다.
추가 보안을 위해, 우리는 모든 저장소에 단독 Docker Hub 사용자를 제공하여, 빈틈이 발생할 때Circleci의 접근 권한을 쉽게 취소할 수 있도록 합니다.
다음은 우리 동네의 관련 부분이다.yml 구성.이 파일들은 저희 프로그램 코드 라이브러리에 존재합니다.Circleci는 GitHub의 저장소로 전송될 때마다 자동으로 이 파일들을 가져옵니다.

version: 2
jobs:
  build:
    # Regular build steps. Redacted from this snipper.
  build_and_push_production_image:
    working_directory: ~/circleci-app
    docker:
      - image: circleci/ruby:2.5
    steps:
      - checkout
      - setup_remote_docker
      - run:
          name: Checkout on-premise branch
          command: git checkout master
      - run:
          name: Build Image
          command: docker build -t firmhouse/platform:$CIRCLE_SHA1 . -f Dockerfile-production
      - run:
          name: Tag latest
          command: docker tag firmhouse/platform:$CIRCLE_SHA1 firmhouse/platform:latest
      - run:
          name: Login to Docker Hub
          command: echo $DOCKER_PASSWORD | docker login -u $DOCKER_USER --password-stdin
      - run:
          name: Push commit-specific image to Hub
          command: docker push firmhouse/platform:$CIRCLE_SHA1
      - run:
          name: Push latest tag to Hub
          command: docker push firmhouse/platform:latest

workflows:
  version: 2
  main_flow:
    jobs:
      - build
      - build_and_push_production_image
        requires:
          - build

Circleci 구성의 세그먼트

프로덕션용 Dockerfile
저희 코드 라이브러리에는 생산에 배치할 이미지를 구축하는 데 사용되는 Dockerfile 제품이 있습니다.공식 지원 Ruby base images 및 Alpine을 기본 릴리스로 사용합니다.또한 최종 이미지에 개발/구축 의존 항목을 남기지 않도록 다단계 구축으로 설정되어 있습니다.
여기서는 일부 Ruby on Rails 고유의 섹션을 살펴보겠습니다.이것들은 꺼내거나 프레임에 필요한 내용으로 바꿀 수 있습니다.

FROM ruby:2.5.8-alpine AS build-env

ARG RAILS_ROOT=/app

RUN apk update \
  && apk upgrade \
  && apk add --update --no-cache \
  build-base curl-dev git postgresql-dev \
  yaml-dev zlib-dev nodejs yarn tzdata

ENV RAILS_ENV=production
ENV NODE_ENV=production
ENV BUNDLE_PATH=vendor/bundle
ENV BUNDLE_APP_CONFIG="$RAILS_ROOT/.bundle"
ENV BUNDLE_PATH__SYSTEM=false
ENV RAILS_SERVE_STATIC_FILES=true
ENV RAILS_LOG_TO_STDOUT=true
ENV APP_HOST=dispatch
ENV SMTP_DOMAIN=localhost
ENV SMTP_USERNAME=username
ENV SMTP_PASSWORD=password
ENV SMTP_ADDRESS=xxx
ENV SECRET_KEY_BASE=123
ENV BUNDLER_VERSION 2.0.2

WORKDIR $RAILS_ROOT

COPY Gemfile* package.json yarn.lock ./
COPY Gemfile Gemfile.lock $RAILS_ROOT/
RUN gem install bundler -v 2.0.2
RUN bundle config --global frozen 1 \
  && bundle install --without test:development:assets -j4 --retry 3 --path=vendor/bundle \
  && rm -rf vendor/bundle/ruby/2.5.0/cache/*.gem \
  && find vendor/bundle/ruby/2.5.0/gems -name "*.c" -delete \
  && find vendor/bundle/ruby/2.5.0/gems -name "*.o" -delete

RUN yarn install --production
COPY . .
RUN bin/rails assets:precompile

RUN rm -rf node_modules tmp/cache app/assets vendor/assets test

FROM ruby:2.5.8-alpine
ARG RAILS_ROOT=/app
ARG RUNTIME_PACKAGES="tzdata postgresql-client nodejs bash file imagemagick"

ENV RAILS_ENV=production
ENV BUNDLE_APP_CONFIG="$RAILS_ROOT/.bundle"
ENV RAILS_SERVE_STATIC_FILES=true
ENV RAILS_LOG_TO_STDOUT=true
ENV BUNDLER_VERSION 2.0.2

WORKDIR $RAILS_ROOT

RUN apk update \
  && apk upgrade \
  && apk add --update --no-cache $RUNTIME_PACKAGES
RUN gem install bundler -v 2.0.2

COPY --from=build-env $RAILS_ROOT $RAILS_ROOT
CMD ["bin/rails", "server"]

EMC Dockerfile 프로덕션

이미지를 호스팅하는 Docker Hub
우리는 현재 용기 이미지를 위탁 관리하기 위해 Docker Hub를 사용하고 있다.보안을 강화하기 위해 모든 응용 프로그램을 자체 Docker Hub 저장소에 배치합니다.각 저장소/애플리케이션에 대한 자격 증명을 Circleci에 저장할 수 있도록 사용자 계정을 추가로 만들었습니다.

상당히 괜찮은 내부 배치 메커니즘
우리에게 있어서 이것은 상당히 괜찮은 내부 배치 메커니즘이다.우리는 더 이상 많은 내부 설정을 하지 않는다. 왜냐하면 이것은 확실히 특수한 기업 고객의 수요이기 때문이다.
우리의 주요(유럽) 플랫폼은 Heroku에서 운영되고 그 모든 우수한 기능을 이용하여 우리의 플랫폼을 배치하고 확장한다.
그러나 본고에서 기술한 설정이 있어 고객이 필요로 한다면 우리는 어떠한 내부 환경도 쉽게 추가할 수 있다.컨테이너 이미지를 기반으로 하기 때문에 Kubernetes 그룹에서도 쉽게 신축 가능한 버전으로 만들 수 있습니다.
이 설정에 대한 질문에 대답해 주셔서 기쁩니다!