CI/CD 체인 생성 및 Docker를 사용한 작업 자동화

나는 90년대 후반에 첫 웹사이트를 만들었습니다. 그 당시에는 그것들을 작동 순서대로 설정하는 것이 매우 쉬웠습니다. 일부 공유 호스팅에는 Apache 서버가 있었습니다. 다음과 같이 작성하여 FTP를 통해 이 서버에 로그인할 수 있습니다. ftp://ftp.example.com. 그런 다음 이름과 비밀번호를 입력하고 파일을 서버에 업로드해야 했습니다. 다른 시대가 있었고 모든 것이 지금보다 더 간단했습니다.

그로부터 XNUMX년 동안 모든 것이 많이 바뀌었습니다. 웹사이트는 더욱 복잡해졌으며 프로덕션에 출시되기 전에 구성되어야 합니다. 하나의 서버가 로드 밸런서 뒤에서 실행되는 여러 서버가 되었고, 버전 제어 시스템의 사용이 일반화되었습니다.

내 개인 프로젝트에는 특별한 구성이 있었습니다. 그리고 단 한 가지 작업, 즉 브랜치에 코드를 작성하여 프로덕션 환경에 사이트를 배포하는 기능이 필요하다는 것을 알았습니다. master GitHub에서. 또한 소규모 웹 애플리케이션의 작동을 보장하기 위해 대규모 Kubernetes 클러스터를 관리하거나 Docker Swarm 기술을 사용하거나 포드, 에이전트 및 기타 모든 종류의 서버가 포함된 서버 집합을 유지하고 싶지 않다는 것을 알고 있었습니다. 복잡성. 업무를 최대한 쉽게 한다는 목표를 달성하기 위해서는 CI/CD에 익숙해져야 했습니다.

소규모 프로젝트(이 경우 Node.js 프로젝트)가 있고 저장소에 저장된 내용이 프로덕션에서 작동하는 내용과 정확히 일치하는지 확인하면서 이 프로젝트의 배포를 자동화하는 방법을 알고 싶다면 다음을 수행하세요. 당신이 이 기사에 관심이 있을 것 같아요.

전제 조건

이 글을 읽는 독자는 명령줄과 Bash 스크립트 작성에 대한 기본적인 이해가 있어야 합니다. 또한 그는 계정이 필요합니다 트래비스 CI и 도커 허브.

대상

이 글이 무조건 '튜토리얼'이라고 부를 수 있다고는 말하지 않겠다. 이 문서는 제가 배운 내용에 대해 이야기하고 하나의 자동화된 패스로 수행되는 코드를 테스트하고 프로덕션에 배포하는 데 적합한 프로세스를 설명하는 문서에 가깝습니다.

이것이 내 작업 흐름의 결과였습니다.

다음을 제외한 모든 저장소 분기에 게시된 코드의 경우 master, 다음 작업이 수행됩니다.

• Travis CI 기반 프로젝트 빌드가 시작됩니다.
• 모든 단위, 통합 및 엔드투엔드 테스트가 수행됩니다.

다음에 해당하는 코드에만 해당 master, 다음이 수행됩니다:

• 위에서 언급한 모든 것 외에도...
• 현재 코드, 설정 및 환경을 기반으로 Docker 이미지를 빌드합니다.
• Docker Hub에 이미지를 배포합니다.
• 프로덕션 서버에 연결합니다.
• Docker Hub에서 서버로 이미지 업로드.
• 현재 컨테이너를 중지하고 새 이미지를 기반으로 새 컨테이너를 시작합니다.

Docker, 이미지, 컨테이너에 대해 전혀 모르는 경우에도 걱정하지 마세요. 나는 그것에 대해 모두 말할 것입니다.

CI/CD란 무엇입니까?

약어 CI/CD는 "지속적인 통합/지속적인 배포"를 의미합니다.

▍지속적인 통합

지속적인 통합은 개발자가 프로젝트의 기본 소스 코드 저장소(일반적으로 분기)에 커밋하는 프로세스입니다. master). 동시에 자동화된 테스트를 통해 코드의 품질이 보장됩니다.

▍지속적 배포

지속적인 배포는 프로덕션 환경에 코드를 자주 자동으로 배포하는 것입니다. CI/CD 약어의 두 번째 부분은 때때로 "지속적인 전달"로 표기됩니다. 이는 기본적으로 "지속적 배포"와 동일하지만 "지속적 전달"은 프로젝트 배포 프로세스를 시작하기 전에 변경 사항을 수동으로 확인해야 함을 의미합니다.

시작하기

제가 이 모든 것을 배우는 데 사용한 앱은 다음과 같습니다. 필기 해. 이것은 제가 작업하고 있는 웹 프로젝트로, 메모용으로 설계되었습니다. 처음에는 하려고 했는데 잼스택-프로젝트가 제공하는 표준 호스팅 및 프로젝트 배포 기능을 활용하기 위해 서버 없이 프런트 엔드 애플리케이션을 사용하거나 네티 파이. 애플리케이션의 복잡성이 증가함에 따라 서버 부분을 만들어야 했으며, 이는 프로젝트의 자동화된 통합 및 자동화된 배포를 위한 나만의 전략을 수립해야 함을 의미했습니다.

내 경우 애플리케이션은 Node.js 환경에서 실행되는 Express 서버로, 단일 페이지 React 애플리케이션을 제공하고 안전한 서버 측 API를 지원합니다. 이 아키텍처는 다음에서 찾을 수 있는 전략을 따릅니다. 이 풀스택 인증 가이드.

와 상담했어요 другом자동화 전문가인 , 그에게 내가 원하는 대로 모든 것이 작동하도록 하려면 어떻게 해야 하는지 물었습니다. 그는 이 문서의 목표 섹션에 설명된 자동화된 작업 흐름이 어떤 모습이어야 하는지에 대한 아이디어를 나에게 제공했습니다. 이러한 목표를 갖는다는 것은 Docker를 사용하는 방법을 알아내야 한다는 것을 의미했습니다.

도커

Docker는 컨테이너화 기술 덕분에 Docker 플랫폼 자체가 다른 환경에서 실행되더라도 동일한 환경에서 애플리케이션을 쉽게 배포, 배포 및 실행할 수 있도록 하는 도구입니다. 먼저 Docker 명령줄 도구(CLI)를 사용해야 했습니다. 교수 Docker 설치 가이드는 매우 명확하고 이해하기 쉽다고 할 수는 없지만, 첫 번째 설치 단계를 수행하려면 Docker Desktop(Mac 또는 Windows용)을 다운로드해야 한다는 점을 알 수 있습니다.

Docker Hub는 거의 같습니다. GitHub의 git 저장소 또는 레지스트리의 경우 npm JavaScript 패키지의 경우. Docker 이미지를 위한 온라인 저장소입니다. Docker Desktop이 연결되는 곳입니다.

따라서 Docker를 시작하려면 다음 두 가지 작업을 수행해야 합니다.

• 세트 도커 데스크탑.
• 등록하다 도커 허브.

그런 다음 다음 명령을 실행하여 Docker 버전을 확인하여 Docker CLI가 작동하는지 확인할 수 있습니다.

docker -v

다음으로, 메시지가 표시되면 사용자 이름과 비밀번호를 입력하여 Docker Hub에 로그인하세요.

docker login

Docker를 사용하려면 이미지와 컨테이너의 개념을 이해해야 합니다.

▍이미지

이미지는 컨테이너 조립 지침이 포함된 청사진과 같습니다. 이는 애플리케이션의 파일 시스템 및 설정에 대한 변경 불가능한 스냅샷입니다. 개발자는 쉽게 이미지를 공유할 수 있습니다.

# Вывод сведений обо всех образах
docker images

이 명령은 다음 헤더가 포함된 테이블을 출력합니다.

REPOSITORY     TAG     IMAGE ID     CREATED     SIZE
---

다음으로 동일한 형식의 몇 가지 명령 예를 살펴보겠습니다. 먼저 주석이 포함된 명령이 있고 그 다음에는 출력할 수 있는 내용의 예가 있습니다.

▍컨테이너

컨테이너는 애플리케이션을 실행하는 데 필요한 모든 것을 포함하는 실행 가능한 패키지입니다. 이 접근 방식을 사용하는 애플리케이션은 인프라에 관계없이 격리된 환경과 동일한 환경에서 항상 동일하게 작동합니다. 요점은 동일한 이미지의 인스턴스가 다른 환경에서 시작된다는 것입니다.

# Перечисление всех контейнеров
docker ps -a
CONTAINER ID     IMAGE     COMMAND     CREATED     STATUS     PORTS     NAMES
---

▍태그

태그는 이미지의 특정 버전을 나타냅니다.

▍Docker 명령에 대한 빠른 참조

다음은 일반적으로 사용되는 Docker 명령의 개요입니다.

팀

문맥

Действие

도커 빌드

이미지

Dockerfile에서 이미지 빌드

도커 태그

이미지

이미지 태깅

도커 이미지

이미지

이미지 나열

도커 실행

컨테이너

이미지를 기반으로 컨테이너 실행

도커 푸시

이미지

레지스트리에 이미지 업로드

도커 풀

이미지

레지스트리에서 이미지 로드

도커 ps

컨테이너

컨테이너 나열

도커 시스템 정리

이미지/컨테이너

사용하지 않는 컨테이너 및 이미지 제거

▍도커파일

프로덕션 애플리케이션을 로컬에서 실행하는 방법을 알고 있습니다. 이미 만들어진 React 애플리케이션을 구축하도록 설계된 Webpack 구성이 있습니다. 다음으로 포트에서 Node.js 기반 서버를 시작하는 명령이 있습니다. 5000. 다음과 같습니다.

npm i         # установка зависимостей
npm run build # сборка React-приложения
npm run start # запуск Node-сервера

이 자료에 대한 예제 응용 프로그램이 없다는 점에 유의해야 합니다. 하지만 여기에서는 실험을 위해 간단한 Node 애플리케이션이면 충분합니다.

컨테이너를 사용하려면 Docker에 지침을 제공해야 합니다. 이는 다음이라는 파일을 통해 수행됩니다. Dockerfile, 프로젝트의 루트 디렉터리에 있습니다. 이 파일은 처음에는 이해하기 어려운 것 같습니다.

그러나 여기에 포함된 내용은 작업 환경 설정과 유사한 특수 명령을 사용하여 설명하는 것뿐입니다. 다음은 이러한 명령 중 일부입니다.

• FROM — 이 명령은 파일을 시작합니다. 컨테이너가 빌드되는 기본 이미지를 지정합니다.
• 복사 — 로컬 소스의 파일을 컨테이너로 복사합니다.
• 작업 디렉터리 — 다음 명령에 대한 작업 디렉터리를 설정합니다.
• 운영 - 명령을 실행합니다.
• 폭로하다 — 포트 설정.
• 진입 지점 — 실행할 명령을 나타냅니다.

Dockerfile 다음과 같이 보일 수 있습니다:

# Загрузить базовый образ
FROM node:12-alpine

# Скопировать файлы из текущей директории в директорию app/
COPY . app/

# Использовать app/ в роли рабочей директории
WORKDIR app/

# Установить зависимости (команда npm ci похожа npm i, но используется для автоматизированных сборок)
RUN npm ci --only-production

# Собрать клиентское React-приложение для продакшна
RUN npm run build

# Прослушивать указанный порт
EXPOSE 5000

# Запустить Node-сервер
ENTRYPOINT npm run start

선택한 기본 이미지에 따라 추가 종속성을 설치해야 할 수도 있습니다. 사실 일부 기본 이미지(예: Node Alpine Linux)는 가능한 한 컴팩트하게 만들기 위한 목적으로 생성됩니다. 결과적으로 귀하가 기대하는 일부 프로그램이 없을 수도 있습니다.

▍컨테이너 빌드, 태그 지정 및 실행

컨테이너의 현지 조립 및 출시는 당사가 완료한 후입니다. Dockerfile, 작업은 매우 간단합니다. 이미지를 Docker Hub에 푸시하기 전에 로컬에서 테스트해야 합니다.

▍조립

먼저 수집해야합니다 이미지, 이름 지정 및 선택적으로 태그 지정(태그가 지정되지 않은 경우 시스템이 자동으로 이미지에 태그를 할당함) latest).

# Сборка образа
docker build -t <image>:<tag> .

이 명령을 실행한 후 Docker가 이미지를 빌드하는 것을 볼 수 있습니다.

Sending build context to Docker daemon   2.88MB
Step 1/9 : FROM node:12-alpine
 ---> ...выполнение этапов сборки...
Successfully built 123456789123
Successfully tagged <image>:<tag>

빌드에는 몇 분이 걸릴 수 있습니다. 이는 종속성 수에 따라 다릅니다. 빌드가 완료되면 다음 명령을 실행할 수 있습니다. docker images 새 이미지에 대한 설명을 살펴보세요.

REPOSITORY          TAG               IMAGE ID            CREATED              SIZE
<image>             latest            123456789123        About a minute ago   x.xxGB

▍출시

이미지가 생성되었습니다. 이는 이를 기반으로 컨테이너를 실행할 수 있음을 의미합니다. 컨테이너에서 실행 중인 애플리케이션에 액세스할 수 있기를 원하기 때문입니다. localhost:5000, 나, 쌍의 왼쪽에 5000:5000 설치된 다음 명령에서 5000. 오른쪽에는 컨테이너 포트가 있습니다.

# Запуск с использованием локального порта 5000 и порта контейнера 5000
docker run -p 5000:5000 <image>:<tag>

이제 컨테이너가 생성되어 실행되었으므로 다음 명령을 사용할 수 있습니다. docker ps 이 컨테이너에 대한 정보를 보려면(또는 다음 명령을 사용할 수 있습니다.) docker ps -a, 실행 중인 컨테이너뿐만 아니라 모든 컨테이너에 대한 정보를 표시합니다).

CONTAINER ID        IMAGE               COMMAND                  CREATED              STATUS                      PORTS                    NAMES
987654321234        <image>             "/bin/sh -c 'npm run…"   6 seconds ago        Up 6 seconds                0.0.0.0:5000->5000/tcp   stoic_darwin

지금 주소로 가시면 localhost:5000 — 프로덕션 환경에서 실행 중인 애플리케이션의 페이지와 완전히 동일하게 보이는 실행 중인 애플리케이션의 페이지를 볼 수 있습니다.

▍태그 지정 및 게시

프로덕션 서버에서 생성된 이미지 중 하나를 사용하려면 Docker Hub에서 이 이미지를 다운로드할 수 있어야 합니다. 이는 먼저 Docker Hub에서 프로젝트에 대한 리포지토리를 생성해야 함을 의미합니다. 그러면 이미지를 보낼 수 있는 곳이 생깁니다. 이미지 이름이 Docker Hub 사용자 이름으로 시작되도록 이미지 이름을 바꿔야 합니다. 그 뒤에는 저장소 이름이 와야 합니다. 모든 태그는 이름 끝에 배치할 수 있습니다. 다음은 이 구성표를 사용하여 이미지 이름을 지정하는 예입니다.

이제 새 이름으로 이미지를 빌드하고 명령을 실행할 수 있습니다. docker push Docker Hub 저장소에 푸시합니다.

docker build -t <username>/<repository>:<tag> .
docker tag <username>/<repository>:<tag> <username>/<repository>:latest
docker push <username>/<repository>:<tag>

# На практике это может выглядеть, например, так:
docker build -t user/app:v1.0.0 .
docker tag user/app:v1.0.0 user/app:latest
docker push user/app:v1.0.0

모든 것이 순조롭게 진행되면 이미지는 Docker Hub에서 사용할 수 있으며 서버에 쉽게 업로드하거나 다른 개발자에게 전송할 수 있습니다.

다음 단계

이제 Docker 컨테이너 형태의 애플리케이션이 로컬에서 실행되고 있음을 확인했습니다. 컨테이너를 Docker Hub에 업로드했습니다. 이 모든 것은 우리가 이미 목표를 향해 매우 좋은 진전을 이루었음을 의미합니다. 이제 우리는 두 가지 질문을 더 해결해야 합니다.

• 코드 테스트 및 배포를 위한 CI 도구 설정
• 코드를 다운로드하고 실행할 수 있도록 프로덕션 서버를 설정합니다.

우리의 경우에는 트래비스 CI. 서버로서 - 디티갈오션.

여기서는 다른 서비스 조합을 사용할 수 있습니다. 예를 들어 Travis CI 대신 CircleCI 또는 Github Actions를 사용할 수 있습니다. 그리고 DigitalOcean 대신 AWS 또는 Linode가 있습니다.

우리는 Travis CI를 사용하기로 결정했고 이 서비스에는 이미 뭔가가 구성되어 있습니다. 따라서 이제 작업 준비 방법에 대해 간략하게 설명하겠습니다.

트래비스 CI

Travis CI는 코드를 테스트하고 배포하기 위한 도구입니다. 각 프로젝트는 고유하고 이로 인해 많은 이점을 얻지 못하기 때문에 Travis CI 설정의 복잡성에 대해 설명하고 싶지 않습니다. 하지만 Travis CI를 사용하기로 결정한 경우 시작하는 데 도움이 되는 기본 사항을 다루겠습니다. Travis CI, CircleCI, Jenkins 등을 선택하든 유사한 구성 방법이 모든 곳에서 사용됩니다.

Travis CI를 시작하려면 다음으로 이동하세요. 프로젝트 웹사이트 그리고 계정을 만드세요. 그런 다음 Travis CI를 GitHub 계정과 통합하세요. 시스템을 설정할 때 작업을 자동화하고 이에 대한 액세스를 활성화하려는 저장소를 지정해야 합니다. (저는 GitHub를 사용하지만 Travis CI가 BitBucket, GitLab 및 기타 유사한 서비스와 통합될 수 있다고 확신합니다.)

Travis CI가 시작될 때마다 서버가 시작되고 해당 리포지토리 브랜치 배포를 포함하여 구성 파일에 지정된 명령이 실행됩니다.

▍직업 생애주기

Travis CI 구성 파일이 호출되었습니다. .travis.yml 프로젝트 루트 디렉터리에 저장되며 이벤트 개념을 지원합니다. 라이프 사이클 작업. 이러한 이벤트는 발생 순서대로 나열됩니다.

• apt addons
• cache components
• before_install
• install
• before_script
• script
• before_cache
• after_success или after_failure
• before_deploy
• deploy
• after_deploy
• after_script

▍테스트

구성 파일에서 로컬 Travis CI 서버를 구성하겠습니다. 언어로 Node 12를 선택하고 Docker를 사용하는 데 필요한 종속성을 설치하도록 시스템에 지시했습니다.

에 나열된 모든 것 .travis.yml, 달리 지정하지 않는 한 모든 풀 요청이 저장소의 모든 분기에 이루어질 때 실행됩니다. 이는 저장소로 들어오는 모든 코드를 테스트할 수 있다는 점에서 유용한 기능입니다. 이를 통해 코드를 분기에 쓸 준비가 되었는지 알 수 있습니다. master, 프로젝트 빌드 프로세스가 중단되는지 여부. 이 전역 구성에서는 모든 것을 로컬에 설치하고 백그라운드에서 Webpack 개발 서버를 실행하고(이것이 내 워크플로의 기능임) 테스트를 실행합니다.

저장소에 테스트 적용 범위를 나타내는 배지를 표시하려면 다음을 수행하세요. 여기에 Jest, Travis CI 및 Coveralls를 사용하여 이 정보를 수집하고 표시하는 방법에 대한 간단한 지침을 찾을 수 있습니다.

그럼 파일 내용은 이렇습니다 .travis.yml:

# Установить язык
language: node_js

# Установить версию Node.js
node_js:
  - '12'

services:
  # Использовать командную строку Docker
  - docker

install:
  # Установить зависимости для тестов
  - npm ci

before_script:
  # Запустить сервер и клиент для тестов
  - npm run dev &

script:
  # Запустить тесты
  - npm run test

여기에서 저장소의 모든 브랜치와 풀 요청에 대해 수행되는 작업이 종료됩니다.

▍배포

모든 자동화된 테스트가 성공적으로 완료되었다는 가정을 바탕으로 선택적으로 코드를 프로덕션 서버에 배포할 수 있습니다. 우리는 브랜치의 코드에 대해서만 이 작업을 수행하고 싶기 때문에 master, 배포 설정에서 시스템에 적절한 지침을 제공합니다. 프로젝트에서 다음에 살펴볼 코드를 사용하기 전에 배포를 위해 호출되는 실제 스크립트가 있어야 한다는 점을 경고하고 싶습니다.

deploy:
  # Собрать Docker-контейнер и отправить его на Docker Hub
  provider: script
  script: bash deploy.sh
  on:
    branch: master

배포 스크립트는 다음 두 가지 문제를 해결합니다.

• CI 도구(이 경우 Travis CI)를 사용하여 이미지를 빌드하고 태그를 지정하고 Docker Hub로 보냅니다.
• 서버에 이미지를 로드하고 이전 컨테이너를 중지한 후 새 컨테이너를 시작합니다(이 경우 서버는 DigitalOcean 플랫폼에서 실행됩니다).

먼저 이미지를 빌드하고 태그를 지정하고 Docker Hub에 푸시하기 위한 자동 프로세스를 설정해야 합니다. 이미지에 고유한 태그를 할당하고 로그인을 자동화하기 위한 전략이 필요하다는 점을 제외하면 이는 이미 수동으로 수행한 작업과 매우 유사합니다. 태그 지정 전략, 로그인, SSH 키 인코딩, SSH 연결 설정과 같은 배포 스크립트의 일부 세부 사항에 어려움을 겪었습니다. 하지만 운 좋게도 내 남자친구는 다른 많은 것들과 마찬가지로 bash에도 능숙합니다. 그는 내가 이 대본을 작성하는 데 도움을 주었습니다.

따라서 스크립트의 첫 번째 부분은 이미지를 Docker Hub에 업로드하는 것입니다. 이것은 매우 쉽습니다. 내가 사용한 태그 지정 방식에는 git 해시와 git 태그(존재하는 경우)를 결합하는 것이 포함됩니다. 이렇게 하면 태그가 고유하게 되며 태그의 기반이 되는 어셈블리를 더 쉽게 식별할 수 있습니다. DOCKER_USERNAME и DOCKER_PASSWORD Travis CI 인터페이스를 사용하여 설정할 수 있는 사용자 환경 변수입니다. Travis CI는 민감한 데이터가 잘못된 사람의 손에 넘어가지 않도록 자동으로 처리합니다.

다음은 스크립트의 첫 번째 부분입니다. deploy.sh.

#!/bin/sh
set -e # Остановить скрипт при наличии ошибок

IMAGE="<username>/<repository>"                             # Образ Docker
GIT_VERSION=$(git describe --always --abbrev --tags --long) # Git-хэш и теги

# Сборка и тегирование образа
docker build -t ${IMAGE}:${GIT_VERSION} .
docker tag ${IMAGE}:${GIT_VERSION} ${IMAGE}:latest

# Вход в Docker Hub и выгрузка образа
echo "${DOCKER_PASSWORD}" | docker login -u "${DOCKER_USERNAME}" --password-stdin
docker push ${IMAGE}:${GIT_VERSION}

스크립트의 두 번째 부분은 사용 중인 호스트와 해당 호스트에 대한 연결이 어떻게 구성되어 있는지에 따라 전적으로 달라집니다. 제 경우에는 Digital Ocean을 사용하기 때문에 명령어를 이용하여 서버에 접속합니다. 독. AWS와 작업할 때 유틸리티가 사용됩니다. aws등

서버 설정은 특별히 어렵지 않았습니다. 그래서 기본 이미지를 기반으로 Droplet을 설정했습니다. 제가 선택한 시스템에는 Docker를 한 번 수동으로 설치하고 Docker를 한 번 수동으로 시작해야 한다는 점에 유의해야 합니다. 저는 Ubuntu 18.04를 사용하여 Docker를 설치했으므로 Ubuntu를 사용하여 동일한 작업을 수행하는 경우 다음을 따르시면 됩니다. 이 간단한 가이드.

여기서는 서비스에 대한 특정 명령에 대해 이야기하는 것이 아닙니다. 이 측면은 경우에 따라 크게 달라질 수 있기 때문입니다. 프로젝트가 배포될 서버에 SSH를 통해 연결한 후 수행할 일반적인 작업 계획을 제공하겠습니다.

• 현재 실행 중인 컨테이너를 찾아서 중지해야 합니다.
• 그런 다음 백그라운드에서 새 컨테이너를 시작해야 합니다.
• 서버의 로컬 포트를 다음으로 설정해야 합니다. 80 - 이렇게 하면 다음과 같은 주소로 사이트에 들어갈 수 있습니다. example.com, 다음과 같은 주소를 사용하는 대신 포트를 지정하지 않고 example.com:5000.
• 마지막으로 기존 컨테이너와 이미지를 모두 삭제해야 합니다.

다음은 스크립트의 연속입니다.

# Найти ID работающего контейнера
CONTAINER_ID=$(docker ps | grep takenote | cut -d" " -f1)

# Остановить старый контейнер, запустить новый, очистить систему
docker stop ${CONTAINER_ID}
docker run --restart unless-stopped -d -p 80:5000 ${IMAGE}:${GIT_VERSION}
docker system prune -a -f

주의해야 할 몇 가지 사항

Travis CI에서 SSH를 통해 서버에 연결하면 시스템이 사용자의 응답을 기다리기 때문에 설치를 계속하지 못하게 하는 경고가 표시될 수 있습니다.

The authenticity of host '<hostname> (<IP address>)' can't be established.
RSA key fingerprint is <key fingerprint>.
Are you sure you want to continue connecting (yes/no)?

문자열 키를 편리하고 안정적으로 사용할 수 있는 형식으로 저장하기 위해 base64로 인코딩할 수 있다는 것을 배웠습니다. 설치 단계에서 공개 키를 디코딩하여 파일에 쓸 수 있습니다. known_hosts 위의 오류를 없애기 위해.

echo <public key> | base64 # выводит <публичный ключ, закодированный в base64>

실제로 이 명령은 다음과 같습니다.

echo "123.45.67.89 ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAklOUpkDHrfHY17SbrmTIpNLTGK9Tjom/BWDSU
GPl+nafzlHDTYW7hdI4yZ5ew18JH4JW9jbhUFrviQzM7xlELEVf4h9lFX5QVkbPppSwg0cda3
Pbv7kOdJ/MTyBlWXFCR+HAo3FXRitBqxiX1nKhXpHAZsMciLq8V6RjsNAQwdsdMFvSlVK/7XA
t3FaoJoAsncM1Q9x5+3V0Ww68/eIFmb1zuUFljQJKprrX88XypNDvjYNby6vw/Pb0rwert/En
mZ+AW4OZPnTPI89ZPmVMLuayrD2cE86Z/il8b+gw3r3+1nKatmIkjn2so1d01QraTlMqVSsbx
NrRFi9wrf+M7Q== [email protected]" | base64

그리고 이것이 생성하는 내용은 다음과 같습니다. base64로 인코딩된 문자열입니다.

MTIzLjQ1LjY3Ljg5IHNzaC1yc2EgQUFBQUIzTnphQzF5YzJFQUFBQUJJd0FBQVFFQWtsT1Vwa0RIcmZIWTE3U2JybVRJcE5MVEdLOVRqb20vQldEU1UKR1BsK25hZnpsSERUWVc3aGRJNHlaNWV3MThKSDRKVzlqYmhVRnJ2aVF6TTd4bEVMRVZmNGg5bEZYNVFWa2JQcHBTd2cwY2RhMwpQYnY3a09kSi9NVHlCbFdYRkNSK0hBbzNGWFJpdEJxeGlYMW5LaFhwSEFac01jaUxxOFY2UmpzTkFRd2RzZE1GdlNsVksvN1hBCnQzRmFvSm9Bc25jTTFROXg1KzNWMFd3NjgvZUlGbWIxenVVRmxqUUpLcHJyWDg4WHlwTkR2allOYnk2dncvUGIwcndlcnQvRW4KbVorQVc0T1pQblRQSTg5WlBtVk1MdWF5ckQyY0U4NlovaWw4YitndzNyMysxbkthdG1Ja2puMnNvMWQwMVFyYVRsTXFWU3NieApOclJGaTl3cmYrTTdRPT0geW91QGV4YW1wbGUuY29tCg==

위에서 언급한 명령은 다음과 같습니다.

install:
  - echo < публичный ключ, закодированный в base64> | base64 -d >> $HOME/.ssh/known_hosts

서버에 액세스하려면 개인 키가 필요할 수 있으므로 연결을 설정할 때 개인 키와 동일한 접근 방식을 사용할 수 있습니다. 키로 작업할 때 Travis CI 환경 변수에 안전하게 저장되어 있고 어디에도 표시되지 않는지 확인하면 됩니다.

주목해야 할 또 다른 점은 전체 배포 스크립트를 한 줄로 실행해야 할 수도 있다는 것입니다. 예를 들어 다음과 같습니다. doctl. 이를 위해서는 추가적인 노력이 필요할 수 있습니다.

doctl compute ssh <droplet> --ssh-command "все команды будут здесь && здесь"

TLS/SSL 및 로드 밸런싱

위에서 언급한 모든 작업을 수행한 후 마지막으로 직면한 문제는 서버에 SSL이 없다는 것입니다. 저는 Node.js 서버를 사용하기 때문에 강제로 일 역방향 프록시 Nginx와 Let's Encrypt를 사용하려면 많은 부분을 수정해야 합니다.

저는 이 모든 SSL 구성을 수동으로 수행하고 싶지 않았기 때문에 로드 밸런서를 생성하고 해당 세부 정보를 DNS에 기록했습니다. 예를 들어 DigitalOcean의 경우 로드 밸런서에서 자동 갱신 자체 서명 인증서를 생성하는 것은 간단하고 무료이며 빠른 절차입니다. 이 접근 방식에는 필요한 경우 로드 밸런서 뒤에서 실행되는 여러 서버에 SSL을 매우 쉽게 설정할 수 있다는 추가 이점이 있습니다. 이를 통해 서버 자체는 SSL에 대해 전혀 "생각"하지 않고 동시에 평소와 같이 포트를 사용할 수 있습니다. 80. 따라서 로드 밸런서에서 SSL을 설정하는 것은 SSL을 설정하는 다른 방법보다 훨씬 쉽고 편리합니다.

이제 들어오는 연결을 허용하는 서버의 모든 포트를 닫을 수 있습니다. 80, 로드 밸런서 및 포트와 통신하는 데 사용됩니다. 22 SSH용. 결과적으로 이 두 포트 이외의 포트에서 서버에 직접 액세스하려는 시도는 실패합니다.

결과

이 자료에서 이야기한 모든 작업을 수행한 후에는 Docker 플랫폼이나 자동화된 CI/CD 체인 개념이 더 이상 저를 두렵게 하지 않았습니다. 코드가 프로덕션에 들어가기 전에 테스트되고 코드가 서버에 자동으로 배포되는 지속적인 통합 체인을 설정할 수 있었습니다. 이 모든 것은 나에게 여전히 비교적 새로운 일이며, 자동화된 작업 흐름을 개선하고 더 효율적으로 만들 수 있는 방법이 있다고 확신합니다. 따라서 이 문제에 대한 아이디어가 있으면 알려주시기 바랍니다. 나를 알다. 이 기사가 귀하의 노력에 도움이 되었기를 바랍니다. 이 책을 읽고 나면 내가 배운 것만큼 당신도 내가 이야기한 내용을 모두 이해하면서 배웠을 것이라고 믿고 싶습니다.

PS 우리의 시장 이미지가 있습니다 도커, 한 번의 클릭으로 설치할 수 있습니다. 컨테이너의 작동을 확인할 수 있습니다. VPS. 모든 신규 고객에게는 3일 동안 무료로 테스트가 제공됩니다.

독자 여러분! 프로젝트에 CI/CD 기술을 사용하시나요?

출처 : habr.com