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 빌드(또는 푸시) 환경변수 없이
$MY_SERVICE_VERSION, 값이 사용됩니다 최근하지만 설정하면
빌드 전 환경 변수의 값은 빌드하거나 푸시할 때 사용됩니다.
등록부에 개인.레지스트리.광산.

나의 원칙

나에게 효과가 있는 접근 방식이 당신에게도 효과가 있을 수 있습니다. 나는 이것을 따른다
간단한 규칙:

• 프로덕션, 개발(또는 기타 환경)을 위한 모든 스택은 다음을 통해 정의됩니다.
  도커 작성 파일
• 가능한 한 모든 환경을 포괄하는 데 필요한 구성 파일
  중복을 피하세요.
• 각 환경에서 작업하려면 하나의 간단한 명령이 필요합니다.
• 기본 구성은 파일에 정의되어 있습니다. docker-compose.yml.
• 환경 변수는 이미지 태그 또는 기타를 정의하는 데 사용됩니다.
  환경마다 다를 수 있는 변수(스테이징, 통합,
  생산).
• 생산 변수의 값은 다음의 값으로 사용됩니다.
  기본적으로 이는 스택이 프로덕션 환경에서 시작될 때 위험을 최소화합니다.
  환경변수를 설정합니다.
• 프로덕션 환경에서 서비스를 시작하려면 다음 명령을 사용하십시오. 도커 스택 배포 - 작성 파일 docker-compose.yml -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 (도커-작성)스택을 실행하려면
소스 코드가 마운트된 개발 모드 /프로젝트/src.

프로덕션에서도 동일한 파일을 사용할 수 있습니다! 그리고 나는 확실히 사용할 수 있습니다
같은 파일 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