Docker Compose: 개발부터 생산까지

팟캐스트 대본의 번역은 수업 출시에 대비하여 준비되었습니다. "리눅스 관리자"

Docker Compose는 작업 환경을 만드는 데 놀라운 도구입니다.
애플리케이션에서 사용되는 스택에 대한 환경입니다. 이를 통해 다음을 정의할 수 있습니다.
귀하의 애플리케이션의 각 구성 요소는 명확하고 간단한 구문을 따릅니다. YAML-
파일.

의 출현으로 도커 컴포즈 v3 이러한 YAML 파일은 작업 시 프로덕션에서 직접 사용할 수 있습니다.
무리 도커 스웜.

하지만 이것은 동일한 docker-compose 파일을 사용할 수 있다는 것을 의미합니까?
개발 환경과 프로덕션 환경에서 모두 사용할 수 있나요? 아니면 같은 파일을 사용하세요.
스테이징이요? 음, 일반적으로는 그렇습니다. 하지만 이러한 기능을 사용하려면 다음이 필요합니다.

• 변수 보간: 일부 환경 변수 사용
  각 환경마다 변화하는 가치.
• 구성 재정의: 두 번째(또는 모든)를 정의하는 기능
  상대적으로 무언가를 변경할 또 다른 후속 docker-compose 파일
  먼저, docker compose가 두 파일을 병합합니다.

개발 파일과 프로덕션 파일의 차이점

개발 중에 코드 변경 사항을 체크인하고 싶을 가능성이 가장 높습니다.
실시간 모드. 이를 위해 소스 코드 볼륨은 일반적으로
애플리케이션의 런타임을 포함하는 컨테이너입니다. 하지만 프로덕션 환경의 경우
이 방법은 적합하지 않습니다.

생산에서는 여러 노드가 있는 클러스터가 있고 볼륨은 로컬입니다.
컨테이너(또는 서비스)가 실행 중인 노드를 기준으로 하므로
복잡한 작업 없이 소스 코드를 마운트할 수 있습니다.
코드 동기화, 신호 등

대신, 우리는 일반적으로 특정 버전의 코드를 사용하여 이미지를 만들고 싶어합니다.
적절한 태그로 표시하는 것이 일반적입니다(의미적 태그를 사용할 수 있음)
버전 관리 또는 귀하의 재량에 따른 다른 시스템).

구성 재정의

차이점을 고려하고 시나리오에 따라 종속성이 다를 수 있습니다.
개발과 운영에서는 서로 다른 구성 파일이 필요하다는 것이 분명합니다.

Docker Compose는 다양한 Compose 파일을 결합하는 것을 지원합니다.
최종 구성을 얻습니다. 작동 방식은 다음 예시에서 확인할 수 있습니다.

$ cat docker-compose.yml
version: "3.2"

services:
  whale:
    image: docker/whalesay
    command: ["cowsay", "hello!"]
$ docker-compose up
Creating network "composeconfigs_default" with the default driver
Starting composeconfigs_whale_1
Attaching to composeconfigs_whale_1
whale_1  |  ________
whale_1  | < hello! >
whale_1  |  --------
whale_1  |     
whale_1  |      
whale_1  |       
whale_1  |                     ##        .
whale_1  |               ## ## ##       ==
whale_1  |            ## ## ## ##      ===
whale_1  |        /""""""""""""""""___/ ===
whale_1  |   ~~~ {~~ ~~~~ ~~~ ~~~~ ~~ ~ /  ===- ~~~
whale_1  |        ______ o          __/
whale_1  |                     __/
whale_1  |           __________/
composeconfigs_whale_1 exited with code 0

앞서 언급했듯이 docker compose는 여러 compose를 결합하는 것을 지원합니다.
파일을 사용하면 두 번째 파일의 다양한 매개변수를 재정의할 수 있습니다. 예:

$ cat docker-compose.second.yml
version: "3.2"
services:
  whale:
    command: ["cowsay", "bye!"]

$ docker-compose -f docker-compose.yml -f docker-compose.second.yml up
Creating composeconfigs_whale_1
Attaching to composeconfigs_whale_1
whale_1  |  ______
whale_1  | < bye! >
whale_1  |  ------
whale_1  |     
whale_1  |      
whale_1  |       
whale_1  |                     ##        .
whale_1  |               ## ## ##       ==
whale_1  |            ## ## ## ##      ===
whale_1  |        /""""""""""""""""___/ ===
whale_1  |   ~~~ {~~ ~~~~ ~~~ ~~~~ ~~ ~ /  ===- ~~~
whale_1  |        ______ o          __/
whale_1  |                     __/
whale_1  |           __________/
composeconfigs_whale_1 exited with code 0

이 구문은 개발 중에 명령을 사용할 때 매우 편리하지 않습니다.
여러 번 해야 할 것입니다.

다행히도 docker compose는 자동으로 다음과 같은 특수 파일을 찾습니다.
docker-compose.override.yml 값을 재정의하려면 docker-compose.yml. 만약
두 번째 파일의 이름을 바꾸면 원래 명령만 사용했을 때와 동일한 결과를 얻을 수 있습니다.

$ mv docker-compose.second.yml docker-compose.override.yml
$ docker-compose up
Starting composeconfigs_whale_1
Attaching to composeconfigs_whale_1
whale_1  |  ______
whale_1  | < bye! >
whale_1  |  ------
whale_1  |     
whale_1  |      
whale_1  |       
whale_1  |                     ##        .
whale_1  |               ## ## ##       ==
whale_1  |            ## ## ## ##      ===
whale_1  |        /""""""""""""""""___/ ===
whale_1  |   ~~~ {~~ ~~~~ ~~~ ~~~~ ~~ ~ /  ===- ~~~
whale_1  |        ______ o          __/
whale_1  |                     __/
whale_1  |           __________/
composeconfigs_whale_1 exited with code 0

알겠습니다. 그러면 기억하기가 더 쉬워지겠네요.

변수의 보간

구성 파일 지원 보간
변수 기본값을 사용할 수 있습니다. 즉, 다음을 수행할 수 있습니다.

services:
  my-service:
    build:
      context: .
    image: private.registry.mine/my-stack/my-service:${MY_SERVICE_VERSION:-latest}
...

그리고 만약 당신이 그렇게 한다면 docker-compose 빌드(또는 푸시) 환경 변수 없이
내 서비스 버전, 값이 사용됩니다 최근, 하지만 설치하면
빌드 전 환경 변수의 값은 빌드 또는 푸시 중에 사용됩니다.
등록부에 개인 레지스트리 광산.

내 원칙

나에게 편리한 접근 방식이 여러분에게도 유용할 수 있습니다. 나는 다음 사항을 따릅니다.
간단한 규칙:

• 생산, 개발(또는 기타 환경)을 위한 모든 스택은 다음을 통해 정의됩니다.
  docker-compose 파일.
• 내 모든 환경을 포괄하는 데 필요한 구성 파일은 다음과 같습니다.
  중복을 피하세요.
• 모든 환경에서 작동하려면 간단한 명령 하나가 필요합니다.
• 주요 구성은 파일에 정의되어 있습니다. docker-compose.yml.
• 환경 변수는 이미지 태그나 기타를 정의하는 데 사용됩니다.
  환경마다 변경될 수 있는 변수(스테이징, 통합,
  생산).
• 생산 변수 값은 값으로 사용됩니다.
  기본적으로 이것은 프로덕션에서 스택을 실행할 경우 위험을 최소화합니다.
  환경 변수를 설정합니다.
• 프로덕션 환경에서 서비스를 시작하려면 다음 명령을 사용하세요. docker stack 배포 — docker-compose.yml —with-registry-auth my-stack-name 작성 파일.
• 작업 환경은 다음 명령을 사용하여 시작됩니다. 도커 - 위로 구성 dd.

간단한 예를 살펴보겠습니다.

# docker-compose.yml
...
services:
  my-service:
    build:
      context: .
    image: private.registry.mine/my-stack/my-service:${MY_SERVICE_VERSION:-latest}
    environment:
      API_ENDPOINT: ${API_ENDPOINT:-https://production.my-api.com}
...

И

# docker-compose.override.yml
...
services:
  my-service:
    ports: # This is needed for development!
      - 80:80
    environment:
      API_ENDPOINT: https://devel.my-api.com
    volumes:
      - ./:/project/src
...

나는 사용할 수 있습니다 docker-compose(docker-compose up)스택을 시작하려면
소스 코드가 마운트된 개발 모드 /프로젝트/소스.

프로덕션에서도 동일한 파일을 사용할 수 있습니다! 그리고 정확히
같은 파일 docker-compose.yml 스테이징을 위해. 이것을 배포하려면
제작을 위해서는 미리 정의된 태그로 이미지를 빌드하고 전송하기만 하면 됩니다.
CI 단계에서:

export MY_SERVICE_VERSION=1.2.3
docker-compose -f docker-compose.yml build
docker-compose -f docker-compose.yml push

운영 환경에서는 다음 명령을 사용하여 실행할 수 있습니다.

export MY_SERVICE_VERSION=1.2.3
docker stack deploy my-stack --compose-file docker-compose.yml --with-registry-auth

그리고 무대에서도 같은 것을 하고 싶다면 정의만 하면 됩니다.
스테이징 환경에서 작업하는 데 필요한 환경 변수:

export MY_SERVICE_VERSION=1.2.3
export API_ENDPOINT=http://staging.my-api.com
docker stack deploy my-stack --compose-file docker-compose.yml --with-registry-auth

우리는 두 개의 다른 docker-compose 파일을 사용하게 되었습니다.
구성 복제는 모든 환경에서 사용할 수 있습니다!

과정에 대해 자세히 알아보기 "리눅스 관리자"

출처 : habr.com