Moby: Compose v3/도커 스택 배포에서 '확장' 기능에 대한 지원 추가

docker compose file 2.1 버전까지 존재하므로 다시 가져오는 몇 가지 메모를 https://github.com/docker/compose/issues/4315#issuecomment -280617251 추가했습니다. Miss는 추상 서비스를 선언할 수 있는 것입니다(실행해서는 안 되지만 편의를 위해 서비스의 공통 속성을 그룹화하는 데 사용할 수 있음).

extends 작동 방식이 약간 스파르타적이라는 docker/compose#4315의 의견에 동의했습니다.

솔루션을 권장하지는 않지만 남용의 정도를 보여주기 위해 FWIW 작성 파일의 상단을 장식하는 규칙은 다음과 같습니다.

#
# Docker Compose configuration
#
# Due to lack of "expressivity" in Compose, we define our own couple of service
# "pseudo-types":
#
#   - image-only services (name: *-image)
#
#     The only goal of these is to build images. No other services build images.
#
#     These have entrypoint overridden to exit immediately.
#
#   - base services (name: *-base)
#
#     These contain common configuration and are intended to be extended.
#
#     Their command (not entrypoint, to keep the original one) is overridden to
#     exit immediately. Service must support a command to exit immediately.
#
#   - task services (name: *-task)
#
#     These are intended for running one-off commands.
#
#     Their default command is overridden to exit immediately. Service must
#     support a command to exit immediately.
#
#   - "real" services
#
#     These are actual services that stay up and running.
#
version: '2'
services:
  ...

나는 v2.1에서와 같이 확장이 좋은 선택이라고 생각합니다. Extends는 실제로 간단하고 이해할 수 있습니다. 이것은 각 환경에 대해 dev, prod 및 env 간에 약간의 읽기 쉬운 변환을 갖는 너무 좋은 관행입니다.

사실, 나는

• 기본 규칙을 나타내는 공통 docker-compose 파일
• dev docker는 그것을 확장하고 개발자를 위한 시설을 구성합니다.
• 스테이징 도커는 공통도 확장하고 이 환경을 위한 시설을 구성합니다.
• 프로덕션 도커는 이 환경, 특히 컨테이너 복제, 다시 시작에 대한 규칙 등을 위한 기능과 함께 공통 확장을 구성합니다.

이것은 작동합니다. 왜 우리가 이 티켓에서 완전한 재작성을 검색해야 하는지 이해하지 못하지만 더 흥미로운 기능을 유지해야 합니다. Extends는 다른 기술이 쉽게 해결할 수 없는 특별한 사용 사례의 좋은 부분입니다. 확장 가능성에 만족합니다.

v3.x 형식으로의 업그레이드도 차단합니다.

도커 컨테이너 정의를 인스턴스당 폴더 레이아웃으로 유지합니다. 여기서 각 폴더에는 컨테이너 인스턴스에 대한 환경 특성을 정의하는 docker-compose.yml 가 포함됩니다. 공통 항목(DRY)을 제외하기 위해 상위 폴더의 기본 서비스 정의를 사용하고 extend 합니다.

따라서 특정 컨테이너 인스턴스를 관리해야 할 때 올바른 폴더에 cd 만 있으면 추가 구성 없이 docker-compose 명령을 직접 실행할 수 있습니다(팀 구성원에게 필요한 -f 플래그 없음). 조회하거나 알아야 할 필요가 있으며 기본적으로 예상대로 작동합니다).

버전 3 작성 파일 사용이 차단되었습니다.

저는 services.yml 를 사용하여 서비스의 기본 레이아웃을 정의한 다음 개발 환경(대부분 볼륨 추가)을 위해 dev.services.yml 로 확장하지만 확장의 (DRY) 재사용성을 좋아합니다. 추가했습니다. 거래 차단기는 아니지만 필수 기능이 없는 한 버전 3으로 이동하는 것을 막을 수 있습니다.

나는 v2.1 '확장' 솔루션을 더 적절한 것으로 개선하는 것에 반대하지 않습니다. 추상 서비스와 같은 것은 사용하기에 더 안전하고 더 강력할 수 있습니다.

예를 들어 (추상적이기 때문에) 추상적인 기본 서비스가 호스트 부분을 정의하지 않고 서비스에 필요한 네트워크 또는 로컬 마운트 지점을 정의하는 추상 볼륨/마운트포인트/네트워크를 지원하는 것을 상상할 수 있습니다. 마운트/볼륨 및 네트워크의 호스트 부분을 호스트/스테이지 환경에 적절한 것으로 매핑합니다.

그것은 내가 아는 한 '확장'으로 지금 할 수 없는 일의 예이며 몇 가지 흥미로운 가능성을 열어줄 것입니다.

확장 기능을 제거하는 것은 전혀 도움이 되지 않았습니다. 매핑된 동일한 볼륨, 환경 변수 및 레이블 세트로 시작되는 많은 웹 서비스가 있습니다. 그들은 또한 동일한 건강 확인 정책을 가지고 있습니다. 그리고 포트는 말할 것도 없습니다. 여러 -f 옵션을 사용하여 작성 파일을 결합하는 것은 동일한 호스트에서 여러 프로젝트를 처리하는 경우 지루하고 오류가 발생하기 쉽습니다.

@shin- 이것은 3.2 스키마에서 다시 가져올까요?

extends 를 파일 형식으로 되돌리고 싶습니다. 저는 여러 프로젝트에서 추상 서비스를 더욱 구체화하는 데 사용하고 있습니다. 여러 -f 옵션이 거의 청구서에 맞는다는 것을 이해하지만 항상 작동하지는 않습니다. 예를 들어, 저는 추상 서비스의 이름을 현재 진행 중인 프로젝트의 컨텍스트에서 더 의미 있는 이름으로 변경하는 경우가 많습니다. 이것은 여러 -f 옵션에서 발생하는 재정의가 지원하지 않는 것입니다.

파일에서 추상 서비스를 "인스턴스화"하는 다른 방법인 한 정확한 extends 잃어도 상관 없습니다.

나는 공통 서비스 파일과 그것을 확장하는 많은 서비스가 있는 설정을 가지고 있으며 대부분 볼륨을 변경하므로 extends 기능에 의존하고 내 설정을 설명하는 다른 좋은 방법이 없다고 말하고 싶습니다.

--frustrated

+1
docker-compose 파일을 병합하라는 권장 사항 뒤에 있는 논리를 볼 수 있지만 여러 프로젝트에서 개발 서비스 토폴로지를 정의하는 코드를 복제하는 아이디어는 마음에 들지 않습니다. 개발자가 어떤 경우에 포함할 서비스를 기억할 필요가 없도록 쉘 스크립트와 함께 -f 해결 방법을 지금 사용할 것입니다.

구성 구조를 더 잘 분해할 수 있도록 여기에서 만족스러운 솔루션을 찾을 수 있기를 바랍니다!

내 사용 사례 목록의 맨 위에는 구성 관리 서비스를 DRYup하는 것입니다. v3.0이면 '확장'을 활용할 수 있을 거라고 생각했습니다. v2로 돌아가고 싶지 않습니다... 그리고 -f 프로세스 해결 방법을 사용해야 하는 특별한 경우를 원하지 않습니다.

야, 이거 작업 시작한 사람 있어? 추적할 PR을 찾을 수 없습니다. 여기에서도 우리를 위해 많은 것을 단순화할 것입니다(위에서 설명한 것과 매우 유사한 사용 사례).

버전 3이 고정되어 있고 공통 구성을 공유할 방법이 필요했기 때문에 여기에서 공유할 수 있는 작은 해결 방법을 해킹했습니다. 이 정보를 공유하세요 :))

repo에 readme가 있으므로 여기에서 자세히 설명하지 않겠습니다.
모두 즐거운 시간 되세요☮️

편집하다:

죄송합니다, 여기 링크가 있습니다 :D

+1

+1

+1

+1해주셔서 감사합니다 💃
그 동안, 10^3 요소만큼 작은 다른 docker noop 이미지를 찾았습니다(실제 noop이 어셈블리로 작성되기 때문에).

불행히도 해당 리포지토리에는 라이선스가 없습니다. 이미 페이스비에서 주인에게 글을 썼는데 아직 답장이 없다. 더 많은 사람들이 그에 대해 문의하면 라이선스를 추가할 수도 있습니다. :)

일부 확장 사용 사례(단일 파일 내)에 도움이 될 수 있는 것은 YAML 앵커에 대한 지원입니다. https://learnxinyminutes.com/docs/yaml/

JSON 스키마가 service must be a mapping, not a NoneType. 유효성 검사에 실패한 것으로 보입니다.

안녕하세요, @grayside , yaml 앵커는 적어도 저에게는 작동합니다. 내가 사용하는 방법은 위의 내 의견을 참조하십시오.

좋아, 하지만 눕 서비스를 사용하기에는 너무 슬프다 아니?

특히 env vars의 경우 해당 env vars가 처리하는 값의 종류는 무엇입니까? 비밀에 관한 것이라면 swarm secrets 기능(또는 다른 비밀 솔루션)을 사용하십시오. 설정에 관한 것이라면 대부분의 설정은 앱/서비스에 따라 다르며 서비스 간에 공유할 의도가 아닙니다.

서비스 간에 설정을 공유해야 하는 경우 대부분 동일한 컨테이너 이미지를 실행하지만 런타임 목적/작업(소비자, 생산자, http 작업자 등)이 다를 때입니다.

설정에 관한 것이라면 대부분의 설정은 앱/서비스에 따라 다르며 서비스 간에 공유할 의도가 아닙니다.

나는 동의하지 않는 경향이 있다. 현재 작업 중인 프로젝트에서 볼륨에 대해 다음과 같이 사용합니다.

# Volume paths
environment:
  - &volume_a        volume-a:/usr/share/my_project/volumes/volume-a
  - &volume_b        volume-b:/usr/share/my_project/volumes/volume-b
  - &volume_c        volume-c:/usr/share/my_project/volumes/volume-c
  - &volume_d        volume-d:/usr/share/my_project/volumes/volume-d

이제 다음과 같이 볼륨을 지정할 수 있습니다.

volumes:
  - volume-a:
  - volume-b:
  - volume-c:
  - volume-d:

services:
  some-service:
    image: some-image
    volumes:
      - *volume_a
      - *volume_b

  some-other-service:
    image: some-other-image
    volumes:
      - *volume_b
      - *volume_c

  some-third-service:
    image: yet-another-image
    volumes:
      - *volume_a
      - *volume_b
      - *volume_c
      - *volume_d

이렇게 하면 현재 있는 컨테이너에 대해 생각할 필요 없이 다른 볼륨을 더 쉽게 탐색할 수 있습니다. 임호, 이것은 docker-compose 설정을 보다 일관되고 사용 및 유지 관리하기 쉽게 만드는 한 가지 방법입니다.

예, @JanNash를 이해하지만 아래 예에서는 noop 서비스가 없습니까?

그러나 앵커는 많은 경우에 충분하지 않습니다.

제 경우에는 동일한 프로젝트에 대해 여러 환경을 지원하는 것이 포함됩니다. 여기에서 우리 프로젝트의 비계를 볼 수 있습니다.

개발할 때는 devel.yaml 를 사용하지만 프로덕션에서는 prod.yaml 합니다. test.yaml 있습니다. 모두 common.yaml 에서 상속하고 .env 파일에서 몇 가지 공통 변수를 가져옵니다.

각각 고유 한 특성이 있습니다.

• devel 환경은 개발 속도를 목표로 하므로 더 빠른 빌드를 생성하고 개발자 컴퓨터의 앱 코드로 볼륨을 마운트하고 앱을 외부 세계와 격리하는 일부 더미 서비스를 추가하는 빌드 인수를 사용합니다.
• prod는 대신 안정성을 목표로 하므로 모든 코드를 다운로드 및 컴파일하고 볼륨을 사용하는 대신 이미지 자체에 번들로 제공합니다. 빌드는 느리지만 더 안전합니다.
• test는 prod와 정확히 같은 것을 목표로 하지만 외부 서비스로부터 격리되어 외부 세계를 오염시키는 것을 방지합니다.

이 간단한 분리를 통해 매우 민첩하고 유연한 DevOps 파이프라인을 가질 수 있습니다. 여기에서 모든 사람은 사용 환경에 따라 약간의 조정만 하면 여러 단계에서 동일한 코드를 사용합니다.

파일 형식 v3을 작성하기 위해 이동하려고 했지만 extends 뿐만 아니라 .env 도 지원되지 않으므로 지금은 유지 관리의 악몽이 될 것입니다( .env 부족으로 인해 더 많이 Swarm과 DRY 중에서 결정할 때 지금은 DRY를 선택했지만 언젠가는 Swarm이 필요하고 두 기능이 다시 지원되는 날이 오기를 바랍니다... ☺️

... 또는 최소한 DRY-ful 솔루션에서 유효한 DRY-less 형식을 생성하는 방법이 있습니다. docker-compose bundle 라고 생각했는데 지금 당장은 폐기될 운명인 것 같습니다...

... 또는 우리는 모든 것을 만드는 다른 도구를 가지고 있습니다(저도 가능한 컨테이너를 주시하고 있습니다). 그러나 확실히 이것은 "수정"이 아닙니다.

https://github.com/moby/moby/issues/31101#issuecomment -301212524의 링크에는 YAML 앵커의 작업 예제와 함께 README가 포함되어 있습니다. 오늘 다시 확인하고 다시 시도하면 잘 작동합니다. 내가 다르게 무엇을하고 있는지 확실하지 않습니다.

@JanNash 👍

@Yajo 귀하의 말을 듣고 말했듯이 docker/moby/docker-compose(정확한 참조가 무엇이든)에서 제공하는 우수한 기본 제공 DRY 솔루션이 있으면 해결 방법이며 훨씬 더 좋을 것입니다. . 그것과 별개로 나는 docker compose가 꽤 만족스럽기 때문에 빨리 오길 바랍니다 👍

~ .env 지원을 놓치기 위해 해결 방법도 해킹했습니다. 서로 다른 환경(지금은 로컬 개발 및 소규모 개발 서버)에서 서로 다른 환경 변수 집합(예: 종속성 및 이미지 버전/태그)을 지원하기 위해 local.env 두 파일을 사용합니다 development.env 그리고 docker-compose <command> 내 명령을 실행하는 대신 이전에 해당 .env 파일을 내 셸에 소싱하거나 다음과 같이 실행합니다. (. local.env && docker-compose <command>) . 여전히 해킹이지만 지금은 이것에 매우 만족합니다.~

즐거운 시간 되세요 여러분 🚶

2배의 규모일 수도 있습니다. :D

@JanNash 기다려! .env 는 3 에서 더 이상 지원되지 않습니까?

저는 사실 잘 모르겠습니다. 댓글에서 그렇지 않다는 글을 읽었습니다.
저는 autoenv를 구현할 때 autoenv에 대해 몰랐기 때문에 주로 local.env 및 development.env 프로시저를 사용해 왔습니다. D
혼란을 드려 죄송합니다.

아, @Yajo 는 이 댓글 에서 누락된 .env 지원을
@Yajo 자세히 설명해 주시겠습니까?

아 미안, 내 잘못이야. 작동하지 않는 것이 아니라 이전과 같이 자동 감지되는 대신 env_file: .env 지정해야 합니다 . 원래 문제로 돌아가자.

extends 아무데나 떨어뜨리는 토론이 있습니까? 사용 사례를 제공하기 전에 이 기능이 꽤 많이 사용된 기능이라는 것을 잘 이해하고 있다고 생각하기 때문에 자세히 읽어보고 싶습니다.

안녕하세요, 한 가지 질문이 있습니다 - 언제? "확장" 지원이 v3에서 언제 다시 시작됩니까?

@JanNash 당신은 그보다 훨씬 작아

나는 지금 Swarm에서 확장을 사용할 수 없다는 것을 알았습니다.
동일한 게시 포트와 1개의 추가 환경 변수가 있는 서비스의 하나의 컨테이너로 동일한 서비스를 시작하는 방법에 대한 아이디어가 있습니까?

스웜 스택 배포에서 확장 지원을 위해 +1

안녕하세요,
여러 git 리포지토리(각각 docker-compose 파일이 있음)에 분산된 마이크로서비스 애플리케이션을 실행하고 있습니다.
배포는 각 서비스를 확장하는 하나의 "루트" docker-compose 파일에 의해 진행됩니다. 우리에게 이 extends 기능은 스택 배포에 실제로 필요합니다.
따라서 Swarm 스택 배포에서 지원을 확장하려면 +1도 필요합니다.
감사 해요.

임시 솔루션으로 YAML 단순 상속( &default , <<: *default )을 사용할 수 있습니다.

version: '3'
services:
  worker: &default
    build: .
    command: bundle exec rake jobs:work
    env_file:
      - .env
    volumes:
      - .:/app
    depends_on:
      - db
      - redis
    links:
      - db:postgres
  web:
    <<: *default
    command: bundle exec puma -C config/puma.rb -p 3000
    ports:
      - "3000:3000"
  spring:
    <<: *default
    command: bundle exec spring server

물론 extends 기능이 더 좋습니다.

다른 파일을 확장하면 어떻습니까?

Yaml에는 파일 확장 기능이 없습니다.

Docker 기여자의 이 기능에 대한 업데이트가 있습니까? 재도입 예정인가요? 그렇지 않다면 비슷한 계획이 있습니까? 아니라면 왜..?

@quolpr, 나는 당신의 "YAML의 간단한 상속"코드가 대체하지 않습니다 두려워 extends 대부분의 경우 "프로토 타입"이후 (즉, &default )는 항상 같은 도커 작성에 의해 해석됩니다 worker 라는 서비스입니다. 따라서 a) 잘 정의되어야 하는 서비스, b) 원하지 않는 서비스.

어쨌든 흥미로운 기능임에는 틀림없습니다.

@laugimethods YAML 참조를 사용할 수도 있습니다.

version: '3'
services:
  spring:
    build: ./app
    command: /bin/sh -c "bundle exec spring server"
    volumes: &default_volumes
      - ./app:/app:delegated
      - bundle:/bundle:nocopy
  worker:
    build: ./app
    command: bundle exec sidekiq -v -C config/sidekiq.yml
    volumes: *default_volumes

( &default_volumes 및 *default_volumes )

그런데 왜 extends 기능이 제거되었는지 정말 이해가 되지 않습니다 🤔

참고로, 누락된 "확장" 기능을 대체하기 위해 이제 .yaml 파일의 합성/병합을 사용하고 있습니다.
https://github.com/Logimethods/smart-meter/blob/master/README.md#docker -compose

extends 작품은 간단하고 성숙합니다. 누군가 extends 를 안티 패턴으로 보는 경우 사용하지 마십시오. 그러나 잘라내지 마십시오.

extends 를 사용하지 않고 의도한 접근 방식에 대한 명확한 설명을 요청할 수 있습니까? 특히 Git 하위 모듈에 포함된 파일에서 상속하여 애플리케이션 간 네트워킹 배선 등을 처리하는 메타 프로젝트의 정의를 허용할 때 광범위하게 사용합니다. 여러 docker-compose.yml 파일을 지정할 수 있다는 것을 잘 알고 있지만 재정의하면 extends 사용하여 소스 제어에 연결할 수 있는 대신 명령줄에서 상호 연결을 지정해야 합니까? 아니면 v3의 어딘가에서 새로운 기능을 놓쳤습니까?

여러 프로젝트에서 extends 를 많이 사용하여 다른 환경과 다른 호스트에 대한 공통 서비스 속성 세트를 상속합니다(읽기: extends 를 사용하여 다른 파일에서 상속함).

extends 키워드 제거를 읽고 데이지 체인 -f docker compose 파일을 필요로 하지 않는 대체물을 찾으려고 시도한 후 extends 를 제거한 이유가 무엇인지 매우 궁금합니다.

links 및 volume-from 의 문제를 이해하지만 기본 yml 파일에서 사용을 자제하는 것이 가장 좋은 방법인 것 같습니다.

차를 뒤집는 데 익숙해졌다는 이유만으로 차의 바퀴를 제거하는 것은 _어쩌면_ 불가능할 것입니다. 그렇죠?

추신: noop 및 anchors는 흥미롭게 보이지만 가장 단순한 프로젝트에 불필요한 복잡성을 추가합니다...

아주 간단한 예를 들면 다음과 같습니다.

common/common.yml

services:
  web:
    image: alpine:3.6
    build: .
    environment:
      DOMAIN:
      PREFIX:

dev/docker-compose.yml

services:
  web:
    extends: ../common/common.yml
    service: web
  ports:
    - "8080:8080"

prod/docker-compose.yml

services:
  web:
    extends: ../common/common.yml
    service: web
  image: the-prod-image:latest-release
  ports:
    - "80:80"
    - "80:443"
  environment:
    NEW_RELIC_KEY:

extends 없이 DRY 원칙을 유지하는 방법

현재 이 때문에 버전 2.1에서 업그레이드할 이유가 없습니다.

@teodorescuserban ,

데이지 체이닝 -f 도커 작성 파일

그게 뭐가 문제야? docker-compose를 호출하기 위해 짧은 별칭을 사용하여 고유한 스크립트를 만들 수 있습니다.

다음 구조를 사용하십시오.

공통/공통.yml

services:
  web:
    image: alpine:3.6
    build: .
    environment:
      DOMAIN:
      PREFIX:

dev/docker-compose.yml

services:
  web:
    ports:
      - "8080:8080"

prod/docker-compose.yml

services:
  web:
    image: the-prod-image:latest-release
    ports:
      - "80:80"
      - "80:443"
    environment:
      NEW_RELIC_KEY:

명령

docker-compose -f common/common.yml -f dev/docker-compose.yml -p myproject up --build

docker-compose -f common/common.yml -f prod/docker-compose.yml -p myproject up --build

그 기능을 몰랐습니다. CLI를 💩로 만들지만 작동할 수 있습니다.

그것이 extends 대한 공식적인 대체 가 된다면 더 쉽게 할 수 있는 방법이 있어야 한다고 생각합니다.

예를 들어:

docker-compose.yml

version: "3"  # or whatever
extend:
  - ./common/common.yml
  - ./dev/docker-compose.yml
services: # Not required now
  # etc.

이렇게 하면 필요한 모든 작업을 수행하는 단일 docker-compose.yml 파일을 가리킬 수 있습니다.

유용한 대안은 COMPOSE_FILE 환경 변수에서 여러 작성 파일을 지원하는 것입니다.

@야조

유용한 대안은 COMPOSE_FILE 환경 변수에서 여러 작성 파일을 지원하는 것입니다.

https://docs.docker.com/compose/reference/envvars/#compose_file에서 :

이 변수는 경로 구분 기호로 구분된 여러 Compose 파일을 지원합니다(Linux 및 macOS에서 경로 구분 기호는 : , Windows에서는 ; ). 예: COMPOSE_FILE=docker-compose.yml:docker-compose.prod.yml . 경로 구분자는 COMPOSE_PATH_SEPARATOR 사용하여 사용자 정의할 수도 있습니다.

@dermeister0 https://github.com/ImmobilienScout24/yamlreader 와 같은 도구를 사용하여 해당 파일을 영구적으로 병합할 수도

> yamlreader common/common.yml prod/docker-compose.yml > docker-compose-prod.yml
> docker-compose -f docker-compose-prod.yml -p myproject up --build

> cat docker-compose-prod.yml
services:
    web:
        build: .
        environment:
            DOMAIN: null
            NEW_RELIC_KEY: null
            PREFIX: null
        image: the-prod-image:latest-release
        ports:
        - 80:80
        - 80:443

@dermeister0 제안 extends 사용하면 데이지 체인 방식을 정확히 알아야 할 필요가 없습니다. 나 자신을 위해 그렇게 할 수는 있지만 이 솔루션을 사랑하는 개발자에게 적용할 수는 없습니다.

그러나 COMPOSE_FILE env 변수에 여러 값이 포함될 수 있다는 것을 알지 못했습니다. @gsong 감사합니다! 그것은 굉장하고 그것을 사용할 수 있습니다 ( .env 파일에서 정의합니다). 여기에는 한 가지 문제가 있습니다. 기본/공통 파일에는 필요하지 않은 서비스가 있을 수도 있습니다.

데이터베이스와 웹 컨테이너를 정의하는 플랫 공통 파일을 예로 들어 보겠습니다. 스테이징에서는 모두 함께 뭉쳐지기를 원하지만 프로덕션에서는 db 및 웹용으로 별도의 호스트를 원할 것입니다.

또한 기본적으로 docker-compose.override.yml이 로드됩니다.

https://docs.docker.com/compose/extents/#understanding -multiple-compose-files

버전 3.3에서 이 접근 방식을 사용합니다.

• docker-compose.yml 에 일반적인 구성 옵션과 서비스를 넣습니다.
• 특정 개발 구성 및 서비스(예: xdebug)에 docker-compose.override.yml 를 사용하십시오.
• 특정 스테이징 구성 옵션에 docker-compose.staging.yml 를 사용합니다.

참고: 프로덕션 환경에서는 Docker를 실행하지 않습니다.

이 접근 방식을 사용하면 docker-compose build 사용하여 로컬에서 쉽게 빌드할 수 있으며 스테이징에 배포할 때 다음을 사용합니다.

docker-compose -f docker-compose.staging.yml -f docker-compose.yml build

Apache를 사용하고 있으며 개발 및 준비를 위한 별도의 가상 호스트 파일이 없습니다. 나는 다른 파일을 갖는 것을 피하기 위해 꽤 많은 시간을 보냈습니다. 결국 유효한 유일한 접근 방식은 <IfDefine> 및 환경 변수(yml 파일의 환경 섹션에서 설정)를 사용하여 예를 들어 ssl 구성을 포함하는 것입니다. 그리고 TLD와 도메인 접두사를 사용하므로 www.example.local http://www.example.local/ :8080 및 www.staging.example.com http://www.staging.example.com 과 같은 것을 가질 수 있습니다

경로는 모두 친척이므로 컨테이너는 모든 환경에서 작동합니다.

내 2센트

-필리포

제 경우에는 이전에 다음과 같이 사용했습니다.

• common.yml
• devel.yml -> common.yml 확장
• prod.yml -> common.yml 확장
• docker-compose.yml -> 로컬, 자식 무시, 원하는 환경(devel 또는 prod)에 대한 심볼릭 링크.

제가 몰랐던 https://github.com/moby/moby/issues/31101#issuecomment -329482917 과 https://github.com/moby/moby/issues/31101#issuecomment -329512231 덕분에, 이제 다른 스키마를 사용하여 v3으로 이동할 수 있습니다.

• docker-compose.yml -> 이전에 common.yml이었던 것
• devel.yml -> docker-compose.yml 재정의
• prod.yml -> docker-compose.yml 재정의
• docker-compose.override.yml -> 로컬, 자식 무시, 원하는 환경(개발 또는 생산)에 대한 심볼릭 링크.

또한 env 변수를 사용하여 필요한 모든 해킹을 수행할 수 있으므로 제 경우에는 문제가 해결되었습니다. 감사 해요! 🎉 (죄송합니다. 불만을 제기하기 전에 새 문서를 제대로 읽었어야 했습니다).

추신: 그래도 extends 는 되돌려 받을 수 있는 좋은 일이지만 적어도 우리에게는 공정한 대안이 있습니다. 😊

@shin- 먼저 extends 기능이 3.0 누락된 것을 보고 매우 실망했지만 YAML 앵커(예: https://github.com/JanNash/docker-noop)는 충분한 교체 이상.

유일한 것은 위의 예와 같이 docker-compose.yml 파일의 유효한 섹션에 앵커를 넣어야 한다는 것입니다.

(최상위) templates 속성 또는 GitLab과 같은 숨겨진 키를 가져와 앵커를 정의하는 방식을 보다 유연하게 할 수 있습니까?

@schmunk42 는 https://github.com/docker/cli/pull/452를 살펴보십시오.

docker-compose.override.yml을 사용할 때의 문제는 포함해야 하는 재정의 유형과 재정의 계층이 하나만 있다고 가정한다는 것입니다.

제 경우에는 모든 로컬 개발에 공통적인 특정 동작을 원하지만 개발자가 Windows, OSX 또는 Linux를 실행하는 경우 미묘하게 달라야 할 수도 있습니다. docker-compose v3 컨텍스트에서 이를 관리 가능하게 유지하기 위해 Linux 사용자가 스테이징 환경과 동일한 동작으로 작동하도록 했습니다. 이는 작동하지만 다른 개발자와 약간 차이가 있음을 의미합니다.

저는 로컬 개발에 -f 를 사용하는 것을 피합니다. 왜냐하면 사람의 실수에 매우 취약하고 너무 많은 일에 대해 토글로 의존하면 문제가 발생하기 때문입니다. 하나의 파일을 선택하는 것이 합리적으로 보이지만 여러 개를 선택하는 것은 신중하게 부과하지 않는 것입니다.

참고로, 위에서 언급한 x- 해킹하고 .env 프로젝트 파일의 COMPOSE_FILE 변수를 사용하여 docker-compose 파일을 데이지 체인으로 연결하면 docker- compose.override.yml은 내가 지금까지 만난 모든 사용 사례를 해결해야 합니다.

yml 앵커도 가까운 장래에 사용하려고 하는 멋진 것입니다.

x- 해킹 아름다움에 매우 만족하지 않지만 나는 그것으로 살 수 있습니다.

입력해 주셔서 감사합니다!

extends 로 인해 가슴 앓이가 많이 발생하고 v3로의 이동을 차단하거나 해킹에 의존하는 것 같습니다. 나는 몇 가지 공통 사항(예: 업데이트 정책)을 전달할 수 있는 "템플릿"(또는 추상) 서비스를 정의하는 기능을 좋아합니다.

저는 extends 로 도커 작성 파일을 사전 처리하고 확장이 해결된 깨끗한 v3 파일을 뱉을 수 있는 간단한 golang 필터 유틸리티를 작업 중입니다.
해결-작성 도커 스택 배포 -c docker-compose.yaml
(또는 docker-compose up)

이것은 최소한 일부 사용 사례에서 작동합니까 / 왜 문제가 있습니까?

@pnickolov 그것은 나를 위해

나는 가능한 모든 것을 수행하는 것처럼 보이지만 당신과 같은 스크립트가 더 바람직 할 것 인 것처럼 보이는 가능한 컨테이너 (나는 개인적으로 사용하지만 아직 직장에서는 사용하지 않음)를 찾고 있습니다.

extends: 키를 재귀적으로 처리할 수 있는 한 저는 기쁠 것입니다!

알겠습니다 extends 대한 대안을 찾은 것 같습니다 ... 👍

문제는 Moby의 프로젝트 관리가 호환성 유지를 핵심 요소로 고려하지 않는 것 같다는 사실입니다. 전방 호환성은 특히 프로덕션에 배포된 대규모 응용 프로그램의 광범위한 채택에 필수적입니다. extends 와 같은 핵심 기능이 유지된다는 보장이 없는 경우 Docker Swarm/Docker EE를 어떻게 추진할 수 있습니까? 👎
좋은 평판은 얻기는 어렵고 잃기는 쉽다...

개인적으로 저는 v2 구문에서 extends 에 의해 처리되는 작업을 수행하기 위해 사용자 정의 스크립트나 가능과 같은 더 큰 솔루션보다는 네이티브 YAML 기능에 의존하는 것을 선호합니다. 이전에 비슷한 문제가 있었고 여러 .yml 파일 등을 사용하는 것과 같은 솔루션이 있기 전에 자체 변환기를 작성하기 시작했습니다. (https://github.com/schmunk42/yii2-yaml-converter-command) - 그러나 그렇지 않았습니다. 실행 가능한 솔루션.

버전 관리 정책과 함께 수행되는 경우 기능을 사용하지 않는 것도 괜찮습니다. 오래된 물건을 영원히 가지고 다닐 수는 없습니다. 비록 이것이 우리 측에서 약간의 작업을 의미하더라도.

@schmunk42 기능을 중단하는 것은 좋지만 다음과 같은 경우에만 가능합니다.

• 제거된 기능은 더 이상 실제로 사용되지 않거나 진화를 방해하는 요소입니다.
• 사전에 발표된다.
• 마이그레이션 경로가 즉시 제공됩니다.

불행히도 (내 책에서) 이러한 요구 사항 중 어느 것도 extends 의 사용 중단에 적용되지 않습니다 ...

@laugimethods v3 를 사용해야 하는 이유는 무엇입니까?

@schmunk42 Swarm 때문에:

최신 권장 버전인 버전 3.x는 Compose와 Docker 엔진의 스웜 모드 간에 상호 호환되도록 설계되었습니다. 이것은 버전: '3' 또는 버전: '3.1' 등으로 지정되며 YAML 루트의 항목입니다.

docker stack deploy 명령은 버전 "3.0" 이상의 모든 Compose 파일을 지원합니다.

Btw, 내 의견은 extends 뿐만 아니라 앞으로 발생할 수 있는 (고통스러운) 사용 중단과 관련이 있습니다...

예, 우리는 스웜 모드 때문에 동일한 문제에 직면하고 있습니다.

나는 처음에 왜 docker CLI가 이제 --composer-file 입력을 사용할 수 있는지 물었습니다. 그러나 docker/swarm 대한 학습에서 (자체 관리) 스웜에서 스택을 실행하는 것은 꽤 복잡한 일처럼 보이며 이것이 엔진으로 옮겨진 데에는 몇 가지 합당한 이유가 있습니다.

여기에서 내 발견 사항 중 일부를 언급하자면 ... v2 에서 v3.4 것은 결코 쉬운 일이 아닙니다.

내 문제 중 일부:

• volumes_from 와 같은 다른 지원되지 않는 옵션이 있습니다. 어쨌든 제거하기를 원했기 때문에 우회하기가 쉽습니다.
• .env 파일(예: docker-compose )은 Docker CLI에 영향을 주지 않습니다.
• 여러 작성 파일( docker stack deploy -c docker-compose.yml -c docker-compose.override.yml doro )을 지정하면 제대로 작동하지 않는 것 같고 오류는 없지만 올바르게 병합되지 않은 것처럼 보입니다. 하지만 docker-compose config 같은 명령도 확인하지 않습니다.
• v3.4 구문을 지원하는 docker-compose 대한 "설치하기 쉬운"(시험판) 바이너리가 없습니다. 도커 엣지처럼
• 외부 네트워크는 --scope swarm 로 생성해야 합니다.

참조: @핸드코드

최신 빌드 사용

• 도커 17.09.0-ce
• 도커 작성 1.17.0dev

이제 _extend_ 및 _noop_ 사용을 대체하기 위해 이 구성 파이프라인을 사용하고 있습니다.
물건을 조금 더 건조하게 유지
이것이 누군가를 돕기를 바랍니다.

base.yml (공유 정의, 유효한 yaml 문서이므로 _docker-compose config_를 사용하여 병합 가능)

version: '3.4'
networks:
  net_back:
    external: true

base-inject.yml (공유 앵커 정의, 불행히도 다른 yaml 파일에서 앵커를 참조할 수 없기 때문에 base.yml에 추가할 수 없습니다. 대신 foo.yml 에 텍스트로 주입됩니다. 이 작업을 수행하는 이상적인 방법은 아닙니다)

x-logging: &logging
  driver: json-file
  options:
    max-size: "50m"
    max-file: "2"

foo.yml (일반 스택 정의, base.yml의 객체 참조, base-inject.yml의 앵커 및 foo-dev.yml 에서 재정의된 객체)

version: '3.4'
[[base-inject]]
services:
  foo:
    image: ${DOCKER_REGISTRY}/foo:${IMAGE_VERSION}
    volumes:
      - type: volume
        source: "volfoo"
        target: "/foo"
    networks:
     - net_back
    logging:
      <<: *logging

foo-dev.yml (환경 스택

version: '3.4'
services:
  foo:
    ports:
      - "8080:80"
volumes:
  volfoo:
    name: '{{index .Service.Labels "com.docker.stack.namespace"}}_volfoo_{{.Task.Slot}}'
    driver: local

그런 다음 배포 명령:

docker stack rm stack_foo && echo "waiting..." && sleep 3 &&
  cat foo.yml | sed -e '/base-inject/ {' -e 'r base-inject.yml' -e 'd' -e '}' > ./foo-temp1.yml &&
  export $(sed '/^#/d' ./dev.env | xargs) &&
  docker-compose -f base.yml -f ./foo-temp1.yml -f foo-dev.yml config > ./foo-temp2.yml
  docker stack deploy --with-registry-auth --prune --compose-file ./foo-temp2.yml stack_foo

1. 오래된 스택 제거
2. 제거 가능한 스택이 전파될 때까지 기다립니다.
3. 앵커를 일반 정의에 삽입하고 tmp 파일에 저장
4. 파일에서 환경 파일 변수 읽기+설정
5. docker-compose를 사용하여 세 파일을 함께 병합하십시오.
6. 병합된 파일 배포

3개 이상의 파일 작성에서 extends 를 갈망하는 사람들을 위해 baclin 라는 도구를 사용했습니다. baclin 이러한 지시문을 선형화하여 모든 extends 지시문을 내용으로 재귀적으로 대체합니다. 이것은 알파 소프트웨어이며, 현재 Swarm 모드 및 스택 배포를 지원하는 코드를 작성 중이므로 코드는 내 기계의 일부입니다. baclin 초기 버전의 플랫폼 바이너리는 여기에서 사용할 수 여기에서 의견이나 문제를 보고

이것은 정말 혼란 스럽습니다!
최신 docker 릴리스( v17.09 ) 및 v17.06 릴리스 문서에 대한 문서 를

$ head -n1 docker-compose.yml
version: '3'

하지만 compose up 수익

ERROR: The Compose file './docker-compose.yml' is invalid because:
Unsupported config option for services.admin_application: 'extends'

extends 키워드를 사용할 때.
또한 compose changelog 에서 extends 제거에 대한 정보를 찾을 수 없습니다.

이제 그것은 무엇입니까?!
이와 같은 중요한 정보는 github 문제에서 찾거나 숨겨져 있으면 안 됩니다.

$ docker --version
Docker version 17.09.0-ce, build afdb6d4

$ docker-compose --version
docker-compose version 1.16.1, build 6d1ac21

@jottr , 문서 참조 :

extends 키워드는 Compose 파일 버전 2.1까지의 이전 Compose 파일 형식에서 지원되지만(v1의 extends 및 v2의 extends 참조) Compose 버전 3.x에서는 지원되지 않습니다.

그래서 당신이 사용하려는 경우 extends 사용하면 최대 충실 할 필요가 version: '2.1' .

내 잘못이야. 여전히 빨간색 사용 중단 경고 기호와 함께 문서 상단에 있어야 합니다.

내 잘못이야. 여전히 빨간색 사용 중단 경고 기호와 함께 문서 상단에 있어야 합니다.

@jottr Github을 사용하여 이에 대한 별도의 문제를 만들거나 PR을 만들 수도 있습니다. 방금 문제를 생성했습니다. https://github.com/docker/docker.github.io/issues/5340

제 경우에는 다음과 같이 docker-compose-override.yml 있습니다.
yaml version: "3.4" services: common: extra_hosts: - "host1:172.28.5.1" - "host2172.28.5.2" - "host3:172.28.5.3" networks: default: external: name: "common-network"
그리고 네트워크와 extra_hosts를 공유해야 하는 몇 가지 다른 docker-compose.yml 파일이 있습니다. 확장 기능 없이 이것을 사용하는 방법은 무엇입니까?

yaml version: "3.4" services: mongo: image: "mongo" container_name: "mongo" hostname: "mongo" volumes: - "/opt/docker/mongo/default.conf:/usr/local/etc/mongo/mongod.conf" - /opt/data/mongo:/data/db" ports: - "27017:27017" command: "mongod --config /usr/local/etc/mongo/mongod.conf" networks: default: ipv4_address: "172.28.5.4"
docker-compose가 yaml 앵커와 다른 파일 간의 참조를 지원한다면 좋을 것입니다. 파일을 병합한 후 앵커 및 참조를 적용할 수 있습니다.
예를 들어:
yaml version: "3.4" services: common: &common extra_hosts: ... networks: ...
yaml version: "3.4" services: mongo: <<: *common image: "mongo" container_name: "mongo" ...
결과는 다음과 같아야 합니다.
yaml version: "3.4" services: mongo: image: "mongo" container_name: "mongo" extra_hosts: // EXTRA HOSTS HERE networks: ...

@sandro-csimas: https://docs.docker.com/compose/compose-file/#extension -fields에서 가능합니다.
@shin- 이 티켓을 닫을 수 있나요?

@rdxmb 저는 그렇게 생각하지 않습니다. 내가 볼 수 있듯이 다른 docker-compose 파일에서 확장할 수 없습니다.

이것이 https://github.com/docker/compose/issues 의 문제라고 생각하는 것이 맞습니까?

일부 디버깅:

# cat docker-compose.yml 
version: "3.4"
services:
  foo-not-bar:
    << : *common
  foo-bar:
    << : *common
    environment:
      - FOO=BAR 

x-common-definitions-for-all-our-services:
  &common
    image: phusion/baseimage
    environment:
      - FOO=NOTBARBYDEFAULT

이것은 작업 중입니다
docker stack deploy -c docker-compose.yml test

docker-compose를 사용할 때:

# docker-compose up 
ERROR: yaml.composer.ComposerError: found undefined alias 'common'
  in "./docker-compose.yml", line 4, column 10

yml 파일을 다음으로 변경:

version: "3.4"

x-common-definitions-for-all-our-services:
  &common
    image: phusion/baseimage
    environment:
      - FOO=NOTBARBYDEFAULT

services:
  foo-not-bar:
    << : *common
  foo-bar:
    << : *common
    environment:
      - FOO=BAR

docker-compose에서도 작동합니다.

따라서 이것이 여러 파일에서도 작동해야 한다고 생각했는데 그렇지 않습니다.

# docker-compose -f compose-services.yml -f compose-default.yml config > docker-compose.yml
ERROR: yaml.composer.ComposerError: found undefined alias 'common'
  in "./compose-services.yml", line 5, column 10
t# docker-compose -f compose-default.yml -f compose-services.yml config > docker-compose.yml
ERROR: yaml.composer.ComposerError: found undefined alias 'common'
  in "./compose-services.yml", line 5, column 10

# cat compose-services.yml 
version: "3.4"

services:
  foo-not-bar:
    << : *common
  foo-bar:
    << : *common
    environment:
      - FOO=BAR 

# cat compose-default.yml 
x-common-definitions-for-all-our-services:
  &common
    image: phusion/baseimage
    environment:
      - FOO=NOTBARBYDEFAULT

그러나 물론 cat 사용하면 이를 병합할 수 있습니다.

# cat compose-default.yml compose-services.yml > docker-compose.yml && docker-compose up -d
WARNING: The Docker Engine you're using is running in swarm mode.

Compose does not use swarm mode to deploy services to multiple nodes in a swarm. All containers will be scheduled on the current node.

To deploy your application across the swarm, use `docker stack deploy`.

Creating network "test_default" with the default driver
Creating test_foo-bar_1 ... 
Creating test_foo-not-bar_1 ... 
Creating test_foo-bar_1
Creating test_foo-bar_1 ... done

다음 버전으로 xenial에서 실행:

# docker --version
Docker version 17.11.0-ce, build 1caf76c
# docker-compose --version
docker-compose version 1.17.0, build ac53b73

@rdxmb , 감사합니다!
따라서 "cat" 명령을 사용하여 작성 파일을 병합하고 최종 파일을 실행해야 합니다.

나는 또한 이것을 하기 위해 docker-compose config 를 사용합니다. 환경별 설정의 예:

이것은 CI 파이프라인에 의해 실행됩니다: docker-compose -f docker-compose.yml -f docker-compose.override.prod.yml config > docker-compose.prod.yml 그런 다음 docker stack deploy -c .\docker-compose.prod.yml my-stack

이를 위해 투표하십시오. extends는 v3에 매우 유용합니다.

v2에서 많이 사용했는데 정말 유용합니다!
+1

v3에서 extends 지원을 보고 싶습니다. 내 docker-compose.yml 파일을 많이 건조하는 데 도움이 됩니다.

이 문제가 제기된 지 거의 1년이 되었고 많은 사람들이 이 기능을 필요로 한다는 것은 분명합니다. 그러나 Docker 개발자가 이 요청에 대한 응답을 전혀 읽지 않았으며 릴리스 전에 docker-compose v3에 포함되지 않은 이유에 대한 설명도 읽지 않았습니다.

새로운 기술을 믿는 고객을 위해 기능을 유지하거나 통신조차 할 수 없다면 소프트웨어의 슬픈 상태입니다.

상황에 대한 한 가지 가능한 해석(및 아마도 현재 스레드의 요약)은 다음과 같습니다.

• YAML 앵커/참조와 3.4의 확장 필드 는 거의 동일합니다.
• 다중 파일이 작동하도록 만들 수 있습니다. 이 스레드에서 간단한 cat 및 고급 접근 방식 을 참조하십시오. 간단한 접근 방식 주석은 끝을 향해 여러 파일을 로드하는 docker-compose의 문제를 보여줍니다(누가 이에 대한 문제를 생성했습니까?). 그것이 docker-compose에서 수정되면 파일 병합이 전혀 필요하지 않을 것입니다. 따라서 다중 파일 지원을 원하는 사람들은 @rdxmb가 제안한 대로 docker/compose/issues 에서 계속되어야 합니다.
• extends 다시 가져오는 것이 고려되었으며( GitHub 프로젝트 이벤트 참조, Docker 팀의 좋은 투명성, 감사합니다!) 결과를 "전략적으로 더 중요한 다른 많은 것들이 있습니다"라고 해석할 수 있지만 여전히 extends 대한 pull 요청을 작성합니다.

나에게 그것은 완벽하게 이해할 수 있는 관점이다.

@aCandidMind 동의했습니다.

IMHO, @aCandidMind가 언급한 접근 방식이 작동하더라도 extends 제공하는 더 간단하고 깔끔한 메커니즘에 복잡성을 추가합니다.
나일 수도 있지만 적당히 복잡한 확장 구성을 확장 필드로 옮기면 읽고 유지하기가 훨씬 더 어려워집니다.
많은 댓글과 게시물을 읽은 후에도 확장 기능이 삭제된 이유와 이러한 기능 저하의 이점이 무엇인지 여전히 명확하지 않습니다.

약간의 bash 마술로 가능합니다. 테스트 저장소를 만들어 직접 시도해 볼 수 있습니다.

stack deploy 명령을 다음과 같이 구성하면 됩니다.

docker stack deploy --compose-file=<(docker-compose -f docker/prod.yml -f docker/dev.yml config) <stackname>

@tylerbuchea - 그 bash 마술의 유일한 단점은 WARNING: Some services (<service-name(s)>) use the '<key>' key, which will be ignored. Compose does not support '<key>' configuration 얻을 수 있다는 것입니다. 이로 인해 혼란이 발생할 수 있습니다. 하지만 작동합니다 👍

@dnmgns 네 말이 맞아! 지적해주셔서 감사합니다. @joaocc가 말했듯이 기본 지원을 능가하는 것은 없지만 위에서 언급한 솔루션은 bash 이외의 종속성이 없다는 점에서 내가 찾을 수 있는 최고의 솔루션입니다.

@tylerbuchea 더러운 방법 중 하나는 stderr을 /dev/null로 리디렉션하는 것입니다. :)
docker stack deploy --compose-file=<(docker-compose -f docker/prod.yml -f docker/dev.yml config 2> /dev/null) <stackname>

부끄럽지 않아요 😄

extend 대한 이러한 혼란에 대해 문서가 더 명확해야 한다고 생각합니다.
extend 대한 설명은 사용자를 업그레이드 방법 문서로 리디렉션하고 업그레이드 방법 문서는 추가 정보를 위해 extend 대한 설명을 다시 가리킵니다. 이것은 충분히 도움이 되지 않습니다. 사용자로서 이 전체 문제를 처리하는 방법, 내가 가진 옵션 및 고려해야 할 사항에 대한 도움을 기대합니다. v3에서 extend 를 제거하기로 한 결정 뒤에는 분명한 아이디어가 있었습니다.

보다:
https://docs.docker.com/compose/extents/#extending -서비스
https://docs.docker.com/compose/compose-file/compose-versioning/#upgrading

@tylerbuchea 훌륭한 원 라이너 bash 기반 솔루션과 관련하여,
슬프게도 일부 고급 Docker 스택 기능을 지원하지 않습니다.

WARNING: Some services (web) use the 'deploy' key, which will be ignored. Compose does not support 'deploy' configuration - use `docker stack deploy` to deploy to a swarm.
WARNING: Some services (web) use the 'configs' key, which will be ignored. Compose does not support 'configs' configuration - use `docker stack deploy` to deploy to a swarm.

https://github.com/docker/cli/pull/569 가 병합되기 때문에 18.03부터 docker stack deploy 여러 작성 파일을 하나로 병합하는 것을 지원합니다. 그것은 완전히 대체하지 않습니다 extends composefile 형식 v2에서 키를 그러나 희망이 방법이 더 사용 사례를 다루고 👼

내 자신의 해결 방법은 yq 를 사용하는 것이었습니다(Bash를 사용하는 경우 단일 라이너로 결합할 수 있음).

yq merge --overwrite docker-stack.yml docker-stack.preprod.yml > merged-docker-stack.yml
docker stack deploy -c merged-docker-stack.yml preprod

@Lucas-C 그들은 출력에 deploy 및 config 키가 계속 포함된다는 경고일 뿐입니다. docker-compose -f docker/prod.yml -f docker/dev.yml config 를 실행하면 이를 확인할 수 있습니다.

파일 작성 v3.4 이상용입니다. 교차 yaml 참조(부분)를 지원합니다. 이 zsh alias/perl 스크립트로 완료했습니다.

alias regen=$'perl -MFile::Slurp=read_file -MYAML=Load,Dump -MHash::Merge::Simple=merge -E \'
  local $YAML::QuoteNumericStrings = 1;
  $n=read_file("/data/docker-compose.yml");
  $s=Dump(merge(map{Load($n.read_file($_))}@ARGV));
  local $/ = undef;
  $s =~ s/\\bno\\b/"no"/g;
  say $s;
  \' $(find /data -mindepth 2 -maxdepth 4 -name docker-compose.yml) >! /data/x-docker-compose.yml'
regen
export COMPOSE_FILE=/data/x-docker-compose.yml

1. 공통 부분으로 /data/docker-compose.yml을 읽습니다.
2. 모든 docker compose를 재귀적으로 찾습니다. (예를 들어 이 프로젝트에는 약 40개의 서로 다른 컨테이너/docker-compose.yml 파일이 있습니다)
3. 각 docker-compose.yml 앞에 /data/docker-compose.yml 내용을 추가합니다.
4. 병합
5. /data/x-docker-compose.yml에 결과 저장

장점 : perl은 일반적인 도구이며 모든 perl 모듈도 빠르게 생성됩니다.
단점 : 해킹은 싫지만 DRY 외에는 방법이 없다. 최종 docker-compose는 약 900줄입니다. 처음부터 하나의 파일로 지원하기를 원하십니까? python docker-compose로 래핑된 바이너리 도커를 펄 핵으로 래핑하는 것은 부끄러운 일입니다.

어떻게 확장과 같은 기능을 제거할 수 있습니까? 핵심 기능인 것 같습니다.

사용 docker-compose config 표준 입력 옵션에 파이프 docker stack deploy -c - 나를 위해 문제를 해결했다 :

docker-compose -f docker-compose.yml \
               -f docker-compose.extended.yml \
               config \
| docker stack deploy -c - my-stack

나는 이것을 시도하지 않았지만 docker stack deploy 문서에서 이것을 발견했습니다.

구성이 여러 Compose 파일로 분할된 경우(예: 기본 구성 및 환경별 재정의) 여러 --compose-file 플래그를 제공할 수 있습니다.

이것을 예로 들면:

docker stack deploy --compose-file docker-compose.yml -f docker-compose.prod.yml vossibility

https://docs.docker.com/engine/reference/commandline/stack_deploy/#compose - 파일

extends 제거에 대한 근거가 어딘가에 문서화되어 있습니까? 공식 문서(예: https://docs.docker.com/compose/extens/#extending -services)에 설명되어 있지 않은 것 같습니다.
사용자가 근거를 이해할 수 있다면 사용자는 제거에 대응하는 방법에 대한 더 나은 아이디어를 개발할 수 있습니다. 감사 해요.

@shaun-blake 여러 작성 파일을 사용하게 되었습니다. 사람들이 사용하는 접근 방식인 것 같습니다. 상속이라기보다는 혼합에 가깝습니다. 빌드하거나 실행할 때 올바른 환경 yaml 템플릿을 docker-compose.override.yml에 복사합니다.

다중 docker 작성 파일(예: base.yml , local.yml , prod.yml )은 서비스가 다른 파일의 YAML 앵커를 사용하도록 허용하지 않으므로 여러 yml 파일 간에 팩터링된 서비스 정의를 정의할 수 없습니다. .
참고 :이 문제는 대부분의 댓글을 달았 13입니다 https://github.com/moby/moby/issues?q=is%3Aissue+is%3Aopen+sort%3Acomments-desc 가장 좋아 3 일.

사용자가 근거를 이해할 수 있다면 사용자는 제거에 대응하는 방법에 대한 더 나은 아이디어를 개발할 수 있습니다. 감사 해요.

처음에 extends 를 제거한 근거에 대한 문서에 +1...

거의 1년 반이 지난 후에도 여전히 _연장_하지 않습니다. Cmon, devs, u는 대안을 제공하지 않고 sth를 제거하지 않습니다.

그들은 구성이라는 대안을 제공합니다. 스레드에서 내 대답을 읽으십시오.

-필리포

2018년 7월 30일 09:41에 Xiaohui Liu [email protected]이 다음과 같이 썼습니다.

거의 1년 반이 지난 후에도 여전히 연장되지 않습니다. Cmon, devs, u는 대안을 제공하지 않고 sth를 제거하지 않습니다.

—
당신이 댓글을 달았기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하거나 GitHub https://github.com/moby/moby/issues/31101#issuecomment-408790200 에서 확인하거나 https://github.com/notifications/unsubscribe-auth/AAS_0AOynjpfVnVo4ZqciMbmjBmkcTQ 스레드를 음소거

@dedalozzo , "쓰레드에서" == ?

여기 내 의견을 참조하십시오.

https://github.com/moby/moby/issues/31101#issuecomment -329527600 https://github.com/moby/moby/issues/31101#issuecomment-329527600

기본적으로 컨테이너의 구성을 재정의하거나 변경하려면 .yml 파일 체인을 사용해야 합니다.

"여러 Compose 파일 지정"을 읽으십시오.

여러 -f 구성 파일을 제공할 수 있습니다. 여러 파일을 제공하면 Compose가 파일을 단일 구성으로 결합합니다. Compose는 파일을 제공한 순서대로 구성을 빌드합니다. 후속 파일은 선행 파일을 무시하고 추가합니다.

https://docs.docker.com/compose/reference/overview/ https://docs.docker.com/compose/reference/overview/

이 접근 방식은 상속보다 합성을 사용하여 다소간 동일한 결과를 얻습니다.

2018년 7월 30일 15:23에 Serban Teodorescu [email protected]이 다음과 같이 썼습니다.

@dedalozzo https://github.com/dedalozzo , "스레드에서" == ?

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 회신하거나 GitHub https://github.com/moby/moby/issues/31101#issuecomment-408880809 또는 스레드 https://github.com/notifications/unsubscribe-auth/AAS_0FZO30NplqHRid_Id8VBOJW7nk5MDaks를 음소거합니다.

우리가 결합하면 동일한 확장성을 다시 얻을 수 없습니까?
yaml 확장 필드 (2.1+/3.4+ 작성)
x- 필드가 다른 파일 을

따라서 루트 include 목록이 로드할 파일을 지정하도록 허용할 수 있습니다.
x-include 넣고 표준 YAML 앵커 및 병합을 통해 즉시 사용할 수 있습니다.

# /docker-compose.yml
version: '2.1'

volumes:
  nginx_file_sockets:
    external: false
    driver: local

services:
  reverse_proxy:
    extends:
      file: reverse_proxy/docker-compose.yml
      service: proxy
    restart: 'always'
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - nginx_file_sockets:/sockets/nginx

  reverse_proxy_test:
    extends:
      file: reverse_proxy/docker-compose.yml
      service: proxy
    restart: 'always'
    ports:
      - "8080:80"
      - "8443:443"
    volumes:
      - nginx_file_sockets:/sockets/nginx

  web:
    extends:
      file: webservice/docker-compose.yml
      service: app
    restart: 'always'
    environment:
      ENVIRONMENT: 'production'
      DB_USER: ${WEB1_DB_USER}
      DB_PASSWORD: ${WEB1_DB_PASS}
    volumes:
      - nginx_file_sockets:/sockets/nginx

  web_staging:
    extends:
      file: webservice/docker-compose.yml
      service: app
    restart: 'no'
    environment:
      ENVIRONMENT: 'staging'
      DB_USER: ${WEB1_DB_USER}
      DB_PASSWORD: ${WEB1_DB_PASS}
    volumes:
      - nginx_file_sockets:/sockets/nginx

# /proxy/docker-compose.yml
version: '2.1'
services:
  proxy:
    build: ./
    volumes:
      - /certs:/certs:ro

# /webservice/docker-compose.yml
version: '2.1'
services:
  app:
    build:
      context: ./folder
      args:
        LINUX_VERSION: 20.s
        LINUX_FLAVOR: dash
    environment:
      - "ES_JAVA_OPTS=-Xms512m -Xmx512m"
      - bootstrap.memory_lock=true
    ulimits:
      memlock:
        soft: -1
        hard: -1

# /proxy/docker-compose.yml
version: '3.9'
services:
  proxy:
    &proxy
    build: ./
    volumes:
      - /certs:/certs:ro

# /webservice/docker-compose.yml
version: '3.9'
services:
  app:
    &app
    build:
      context: ./folder
      args:
        LINUX_VERSION: 20.s
        LINUX_FLAVOR: dash
    environment:
      - "ES_JAVA_OPTS=-Xms512m -Xmx512m"
      - bootstrap.memory_lock=true
    ulimits:
      memlock:
        soft: -1
        hard: -1

# /docker-compose.yml
version: '3.9'
include:
  - /proxy/docker-compose.yml
  - /webservice/docker-compose.yml

volumes:
  nginx_file_sockets:
    external: false
    driver: local

services:
  reverse_proxy:
    << : *proxy
    restart: 'always'
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - nginx_file_sockets:/sockets/nginx

  reverse_proxy_test:
    restart: 'always'
    << : *proxy
    ports:
      - "8080:80"
      - "8443:443"
    volumes:
      - nginx_file_sockets:/sockets/nginx

  web:
    << : *app
    restart: 'always'
    environment:
      ENVIRONMENT: 'production'
      DB_USER: ${WEB1_DB_USER}
      DB_PASSWORD: ${WEB1_DB_PASS}
    volumes:
      - nginx_file_sockets:/sockets/nginx

  web_staging:
    restart: 'no'
    extends:
      file: web1/docker-compose.yml
      service: app
    environment:
      ENVIRONMENT: 'staging'
      DB_USER: ${WEB1_DB_USER}
      DB_PASSWORD: ${WEB1_DB_PASS}
    volumes:
      - nginx_file_sockets:/sockets/nginx

@@ /proxy/docker-compose.yml @@
-version: '2.1'
+version: '3.9'
 services:
   proxy:
+    &proxy
     build: ./
     volumes:
       - /certs:/certs:ro
 ```

 ```diff
 @@ /webservice/docker-compose.yml @@
-version: '2.1'
+version: '3.9'
 services:
   app:
+    &app
     build:
       context: ./folder
       args:
         LINUX_VERSION: 20.s
         LINUX_FLAVOR: dash
     environment:
       - "ES_JAVA_OPTS=-Xms512m -Xmx512m"
       - bootstrap.memory_lock=true
     ulimits:
       memlock:
         soft: -1
         hard: -1
 ```

 ```diff
 @@ /docker-compose.yml @@
-version: '2.1'
+version: '3.9'
+include:
+  - /proxy/docker-compose.yml
+  - /webservice/docker-compose.yml

 volumes:
   nginx_file_sockets:
     external: false
     driver: local

 services:
   reverse_proxy:
-    extends:
-      file: reverse_proxy/docker-compose.yml
-      service: proxy
+    << : *proxy
     restart: 'always'
     ports:
       - "80:80"
       - "443:443"
     volumes:
       - nginx_file_sockets:/sockets/nginx

   reverse_proxy_test:
-    extends:
-      file: reverse_proxy/docker-compose.yml
-      service: proxy
+    << : *proxy
     restart: 'no'
     ports:
       - "8080:80"
       - "8443:443"
     volumes:
       - nginx_file_sockets:/sockets/nginx

   web:
-    extends:
-      file: webservice/docker-compose.yml
-      service: app
+    << : *app
     restart: 'always'
     environment:
       ENVIRONMENT: 'production'
       DB_USER: ${WEB1_DB_USER}
       DB_PASSWORD: ${WEB1_DB_PASS}
     volumes:
       - nginx_file_sockets:/sockets/nginx

   web_staging:
-    extends:
-      file: webservice/docker-compose.yml
-      service: app
+    << : *app
     restart: 'no'
     environment:
       ENVIRONMENT: 'staging'
       DB_USER: ${WEB1_DB_USER}
       DB_PASSWORD: ${WEB1_DB_PASS}
     volumes:
       - nginx_file_sockets:/sockets/nginx
 ```
<hr>
Resulting in the final version, which should be already yaml parsable:

```yml
# /docker-compose.yml
version: '3.9'
#include:
#  - /proxy/docker-compose.yml
#  - /webservice/docker-compose.yml
x-include:
  /proxy/docker-compose.yml:
    version: '3.9'
    services:
      proxy:
        &proxy
        build: ./
        volumes:
          - /certs:/certs:ro
  /webservice/docker-compose.yml:
    version: '3.9'
    services:
      app:
        &app
        build:
          context: ./folder
          args:
            LINUX_VERSION: 20.s
            LINUX_FLAVOR: dash
        environment:
          - "ES_JAVA_OPTS=-Xms512m -Xmx512m"
          - bootstrap.memory_lock=true
        ulimits:
          memlock:
            soft: -1
            hard: -1

volumes:
  nginx_file_sockets:
    external: false
    driver: local

services:
  reverse_proxy:
    << : *proxy
    restart: 'always'
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - nginx_file_sockets:/sockets/nginx

  reverse_proxy_test:
    << : *proxy
    restart: 'no'
    ports:
      - "8080:80"
      - "8443:443"
    volumes:
      - nginx_file_sockets:/sockets/nginx

  web:
    << : *app
    restart: 'always'
    environment:
      ENVIRONMENT: 'production'
      DB_USER: ${WEB1_DB_USER}
      DB_PASSWORD: ${WEB1_DB_PASS}
    volumes:
      - nginx_file_sockets:/sockets/nginx

  web_staging:
    << : *app
    restart: 'no'
    environment:
      ENVIRONMENT: 'staging'
      DB_USER: ${WEB1_DB_USER}
      DB_PASSWORD: ${WEB1_DB_PASS}
    volumes:
      - nginx_file_sockets:/sockets/nginx

AFAIK는 동일한 파일에서 반복되는 부분을 피하기 위해 laguage 사양 자체에 내장된 YAML 기능입니다. 다른 파일을 사용할 때는 기본적으로 불가능합니다.

해당 기능을 YAML 사양 자체에 제안해야 합니다.

이 토론은 다음과 같이 소실됩니다.

• docker-compose -f file.yml 가 docker-compose -f file.yml -f file_extension.yml 보다 훨씬 더 나은 이유는 무엇입니까?
• 또는: 명령 수준에서 연결 _vs_ 파일 수준에서 연결.

명령줄에서 작업할 때만 불편이 눈에 띄게 됩니다. 우리는 잠시 그것을 인정해야 합니다. 다른 모든 것은 어쨌든 스크립팅 가능합니다.

그 다음 실제 인수의 경우 docker-compose up service 보다 더 의미가 docker-compose -f service.yml up :에서 (일명 명령 행에) 지역 개발에 필요한 모든 것을 정의 docker-compose.override.yml .

주어진 의미론은 매우 깨끗하고 잘 생각했습니다. service.yml _명령줄 사용_을 채택하는 것은 아마도 UX를 낮추는 것을 의미할 것입니다. 이에 대한 또 다른 주장이 있습니다. 첫눈에 docker-compose.yml 가 무엇인지는 분명하지만 service.yml 는 무엇이든 될 수 있습니다. 실제로는 무엇이든 될 수 있습니다.

면책 조항: 도발적인 의견. :wink: 가능한 모든 사용 사례를 고려하지 않았습니다...

이 긴 토론 후에 그것이 성공할지 여부는 확실하지 않습니다. IMHO, extends는 멋지고 최소한 신중하게 사용되지 않으며 단순히 삭제하는 대신 논의되어야 합니다.

우리가 할 수 있는 한 가지는 v2 대 v3에 대한 문서화 스토리를 개선하는 것이라고 생각합니다. 많은 사람들이 v3 가 v2를

v2: docker-compose cli 전용입니다. 단일 기계와 엔진에 초점을 맞춘 개발 워크플로. CI 빌드/테스트 워크플로에도 좋습니다. 이 버전 분기는 v17.12에서 2017년 12월에 최신 기능을 받았습니다.

v3: 다중 노드 개념이 있는 Swarm/Kube 스택에 이상적이며 대부분의 docker-compose cli 기능에 대한 지원을 유지합니다.

당신이 떼 또는 도커 엔터프라이즈는 Kubernetes 스택을 사용하지 않는 경우, 사용 v3으로 이유가 없다. v2.4를 사용하면 extends,Depends_on, extension필드, 상태 확인이 있는 depends_on

v3는 단일 엔진 docker-compose cli 세계의 기능을 다중 노드 클러스터 세계와 병합하기 위해 만들어졌습니다. 모든 v2 기능(예:Depends_on)이 클러스터에서 의미가 있는 것은 아닙니다. 다른 기능(예: 확장)은 v3에 포함되지 않았습니다. v3 이전에는 모든 코드가 docker-compose Python에 있었고 v3.0이 Swarm을 지원하려면 docker cli Go에서 이를 다시 작성해야 했기 때문일 수 있습니다. 이제 그들은 아직 존재하지 않는 Swarm 스택 API를 만들기 위해 엔진 데몬에 다시 작성하고 있습니다.

이 문제를 처음 접하는 분들을 위해 3.0 릴리스 이후 다양한 구성, 템플릿 및 팀 워크플로 문제를 해결하기 위해 진행한 많은 작업에 유의하십시오.

• 이 기사에서 간략하게 설명하는 3가지 기능(env vars, 템플릿 및 구성 범위)
• 재정의 파일, docker-compose config 및 .env 파일
• docker-app 실험적 템플릿 및 패키징 cli. 이것 좀 봐
• 향후 docker-compose GUI(DockerCon 2018 기조 연설의 티저)

https://docs.docker.com/compose/extents/#extending -services의 문서는 extends 키워드가 v3에서 제거 되었다는 사실을 빨간색으로 강조해야 합니다. 이는 단지 _note_보다 더 중요하기 때문입니다.
더 이상 작동하지 않는 이유에 대해 문서를 마이그레이션하고 훑어본 다음 여기에서 끝내기 전에 몇 가지 닫힌 문제를 따랐고 원래 문서로 돌아가서 문구를 확인했습니다.

extends 키워드는 Compose 파일 버전 2.1까지의 이전 Compose 파일 형식에서 지원되지만(v1의 extends 및 v2의 extends 참조) Compose 버전 3.x에서는 지원되지 않습니다.

다음과 같이 바꿀 수 있습니다.

extends 키워드는 Compose 버전 3.x에서 제거되었지만 Compose 파일 버전 2.1까지의 이전 Compose 파일 형식에서 계속 지원됩니다(v1의 extends 및 v2의 extends 참조).

작은 차이지만 문서를 훑어볼 때 간과하기 쉬운 차이입니다.

@krisrp 홍보 시작했습니다

@BretFisher 감사

v2를 "version: docker-cli"로, v3을 "version: swarm/kube"로 변경할 계획이 있습니까?
대부분의 다른 버전 관리 체계에서 v3가 v2를 대체하는 방식을 고려하면 이러한 방식으로 구분하는 것이 더 합리적입니다. 현재 둘 다 유지되고 분기되고 있으므로 내가 착각하지 않는 한 둘 다 잠시 동안있을 것 같습니다.

@krisrp 반대로 메이저 버전 번호를 알리기 위함입니다.

@ cpuguy83 나는 달리 암시하지 않았습니다. 더 명확하거나 명시적이지 못한 점에 대해 사과드립니다.
IIRC Gnome 2 & 3도 몇 년 전에 각각의 독립적인 포크가 유지되었을 때 이러한 혼란을 겪었습니다.

나는 버전 관리(나쁜 말장난)의 의미론에 대해 논의하기 위해 이 스레드를 탈선시키고 싶지 않으므로 그대로 두겠습니다. v2 vs v3에 대한 문서 개선에 대한 @BretFisher 의 지난 주 게시물은 저와 다른 사람들에게 도움이 되었을 것입니다.

@shin- @cpuguy83 1년이 지난 후 이 문제를 보면 버전 3에 다시 추가하지 않는 이유가 _무엇입니까?

"다르게 할 수 있습니다"(하지만 실제 더 나은 솔루션은 제공되지 않음) 외에는 이에 대해 많은 것을 찾을 수 없었습니다.
기술적인 제한이 있습니까? 아니면 pull 요청이 부족합니까?

결국, 내 compose 2.1 파일은 여전히 ​​잘 실행되고 있습니다.

이뿐만 아니라 변경 로그에 "제거되었습니다. 자세한 내용은 '업그레이드 방법'을 참조하세요."라고 표시됩니다. 저는 "업그레이드 방법"을 보고 업그레이드 방법에 대한 세부 정보를 보고 "자세한 내용은 '서비스 확장'을 참조하십시오"라고 말합니다. "서비스 확장"으로 이동하여 마침내 내 파일을 확장할 수 있는 방법을 알게 되지만 "이 항목이 제거되었습니다. 자세한 내용은 변경 로그를 참조하십시오"라고만 표시됩니다.

이 시점에서 이것은 문서 작성자가 하고 있는 잔인한 농담처럼 보입니다.

궁극적으로 "스택" 형식은 여기에서 제어되지 않으며 Docker CLI의 일부입니다.

개인적으로 v3에서 제외된 이유를 모르겠습니다... 또한 실제로 추가하려고 하는 사람을 본 적이 없는 것 같습니다.
이것을 docker/cli에서 가져오는 것이 가장 좋습니다... 기능이 있는 것처럼 작동하는 높은 수준의 문서 변경이 있는 PR일 수도 있으므로 논의할 수 있고 설계가 승인되면 구현을 추가할 수 있습니다. .

기본적으로 누군가가 원하면 PR을 합니다. 거부되는 경우에 대비하여 많은 시간을 낭비하지 않도록 하기 위해 문서 변경을 제안합니다... 다시 한 번 왜 v3에서 생략되었는지 확실하지 않기 때문입니다.

같은 상기와. docker-compose를 다시 사용하기 전에 이 문제가 해결될 때까지 기다리세요.

+1 이 문제를 해결하십시오. 확장 기반 작성 파일이 있고 그 때문에 떼에 작성을 사용할 수 없습니다.

확장 기능의 경우 +1

이것에 대한 소식이 있습니까?

그래도 기다리고 있어

여기도 마찬가지입니다. 아직 기다리고 있습니다.

모든 업데이트?

왜 꺼냈는지에 대한 이유가 있었나요?

2019년 8월 5일 월요일, 11:10 Jaykishan, [email protected]이 다음과 같이 썼습니다.

모든 업데이트?

—
당신이 댓글을 달았기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/moby/moby/issues/31101?email_source=notifications&email_token=ABOE6GA4CXY6ESMZMTDSFGDQC74CZA5CNFSM4DANZGS2YY3PNVWWK3TUL52HS4DFVEXG43VMXHJKTNMV
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/ABOE6GCEFFJ3SOLDWRWX2IDQC74CZANCNFSM4DANZGSQ
.

모든 업데이트?

그래서.. 거의 3년..
그러나 나는 그것이 착륙하기를 여전히 희망합니다 :D

다시 오지 않을 경우 확장할 수 있는 일종의 대안이 필요합니다. 추상 서비스를 허용하지 않는 이유는 무엇입니까? 파일 형식은 단순하고 모든 서비스 선언은 하나의 파일에 있습니다. & 를 통해 노드에 대한 별칭을 추가하는 yaml의 기능과 함께 추상 서비스를 사용할 수 있으며 <<: 연산자를 통해 해당 별칭을 재사용할 수 있습니다.

왜 3년!! 아무도 신경 쓰지 않는 일에 집중하고 있는 것 같습니다.

이것에 대한 어떤 업데이트?

이것은 한심한 일입니다. Terraform은 구성을 사용합니다. 그래서 가능합니다. 왜 compose가 이 좋은 디자인 관행을 따를 수 없습니까?
Terraform 모듈 구성
Terraform 모범 사례

"한심한", 좋은.

@Cristian-Malinescu 계속해서 구현하십시오.
이것은 무료 및 오픈 소스 소프트웨어입니다.

이 채팅에서 다른 모든 사람들처럼 불평하는 대신.
그것은 여기에 어떤 가치도 추가하지 않습니다.
여러 번 말했듯이 지금까지 아무도 이것을 구현하고 싶지 않았습니다.
그래서 다른 사람이 k를 수정해야 하는 문제일 뿐입니다. 감사합니다.

@luckydonald @Cristian-Malinescu를 쉽고/수동적이며 공격적인 답변으로 밀어

스레드를 훑어보고 지원되는 YAML 기능을 활용하는 것이 언급되었습니다.

이 예가 도움 했습니다 .

@nomasprime 찾아 주셔서 감사합니다! 나는 내 프로젝트를 위해 v2와 v3 사이에서 결정하고 있었고 이것은 이 스레드의 큰 딜레마를 해결했습니다. 이러한 대체 솔루션이 서비스 확장 기능에 대한 공식 문서 에 언급되지 않은 것에

문서 페이지의 오른쪽 탐색 모음에 있는 Request docs changes 링크를 사용할 수 있는 좋은 기회인 것 같습니다.

@nomasprime 예, 그 아이디어는 이전에 이 스레드에 있었습니다.

그것이 다른 yml 파일에 대한 파일 로딩 메커니즘과 결합될 수 있다면, 그것이 모든 이전 depends 기능을 갖는 데 실제로 필요한 전부입니다.

위 참조, 예: https://github.com/moby/moby/issues/31101#issuecomment -413323610

아주 _읽을 수 있는_ 것은 아니지만 적어도 _가능한_ 것입니다.

@nomasprime 찾아 주셔서 감사합니다! 나는 내 프로젝트를 위해 v2와 v3 사이에서 결정하고 있었고 이것은 이 스레드의 큰 딜레마를 해결했습니다.

@arseniybanayev 매체에 대한 기사는 v3에 대해서만 설명하지만 v2의 최신 버전은 docker-compose 하고 swarm 사용하지 않기 때문에 v2(더 구체적으로 2.4)를 선택합니다(v3은 컨테이너 메모리 제한 과 같은 v2의 일부 기능을 지원하지 않습니다).

v3는 컨테이너 메모리 제한과 같은 v2의 일부 기능을 지원하지 않습니다.

v3는 메모리 제한을 지원하지만 필드는 deploy -> resources -> limits https://docs.docker.com/compose/compose-file/#resources 아래에 있습니다.

@thaJeztah 내 말은, docker-compose 에 대한 것입니다(이전 의견에서 언급한 프로젝트에서 swarm을 사용하지 않기 때문에). IIRC 배포는 스웜 전용입니다.

Swarm과 Local에 대해 별도의 구성을 만드는 것이 합리적입니까? 이 둘은 서로 충돌하는 것 같습니다. 당연히 Docker는 Swarm 사용량이 증가하기를 원하지만 많은 사람들이 로컬 개발용으로만 compose를 사용합니다.

저는 ECS, k8s 또는 GAE를 사용하여 프로덕션 환경에서 Swarm을 사용하고 컨테이너를 실행한 적이 없습니다.

대부분의 옵션은 swarm/kubernetes 서비스와 compose를 통해 배포된 컨테이너 모두에 대해 번역 가능/사용 가능해야 합니다. memory 한도가 docker-compose 적용되지 않는 이유를 확인해야 합니다.

여전히 확장 기능이 없지만 주요 사용 사례에서는 COMPOSE_FILE 환경을 통해 여러 도커 작성 파일로 전환했습니다. 나는 주로 다른 암호 또는 구성을 사용하여 dev 및 prod에 동일한 기본 docker-compose.yml을 사용하는 데 사용합니다.

예시:

• 개발자: export COMPOSE_FILE= docker-compose.yml` # 기본값
• 제품: export COMPOSE_FILE= docker-compose. yml:docker-compose.prod.yml ` # 두 yaml 파일을 모두 사용

docker-compose.prod.yml 에서 env 변수를 prod 암호로 덮어씁니다.

이 설정은 간단하며 docker-compose 명령에 항상 "-f"를 여러 개 추가할 필요가 없습니다. 개발자 컴퓨터와 서버에서 COMPOSE_FILE env var를 다르게 설정하고 git은 docker-compose.prod.yml 파일을 무시하기만 하면 됩니다.

아직 기다리고 있습니다 :)

나는 이것을 확장하는 방법으로 사용했습니다.

docker-compose \
  -f ./docker/base.yml \
  -f ./docker/extended.yml \
  up

그러나 파일에서 확장하면 추가 bash 스크립트가 필요하지 않습니다.

나는 또한 이것을 사용하여 bash 스크립트에서 동적으로 확장했습니다.

extended_docker_compose="
  version: '3.5'
  services:
    my-service:
      restart: always
"

echo "$extended_docker_compose" | docker-compose \
  -f ./docker/base.yml \
  -f /dev/stdin \
  up

@dave-dm 그것들은 평범한 오래된 재정의입니다!

나는 이것이 확장에 대한 잠재적인 유효한 사용 사례라고 생각합니다.

https://github.com/NerdsvilleCEO/devtools/blob/master/doctl/docker-compose.yml#L10

서비스 환경에 사용하는 docker-compose 래퍼가 있습니다. https://github.com/nowakowskir/docker-compose-wrapper

편집: 또 다른 가능한 사용 사례는 누군가가 LAMP/LEMP 스택을 가지고 있고 wordpress와 같은 특정 서비스와 함께 사용하기 위해 해당 서비스를 확장하려는 것입니다.

docker compose 대안을 탐색하는 동안 여전히 2017년부터 기다리고 있습니다.

@nomasprime 예, 그 아이디어는 이전에 이 스레드에 있었습니다.

그것이 다른 yml 파일에 대한 파일 로딩 메커니즘과 결합될 수 있다면, 그것이 모든 이전 depends 기능을 갖는 데 실제로 필요한 전부입니다.

위 참조, 예: #31101(댓글)

아주 _읽을 수 있는_ 것은 아니지만 적어도 _가능한_ 것입니다.

@luckydonald 지적해 주셔서 감사합니다. 이상하게 도 내장된 YAML 포함 기능 이 없는 것은 확실히 많은 문제를 해결할 것입니다.

타사 솔루션을 구현하는 것은 꽤 쉬울 것 같지만 왜 이것이 v3로 제공되지 않는지 잘 모르겠습니다 🤷‍♂

많은 분들이 이 기능을 원하신다는 사실을 살짝 알려드립니다 :)

v3 btw로 이식하지 않는 이유는 무엇입니까?

잊어버렸는데 뺏긴 진짜 이유가 있나요?

2020년 5월 6일 수요일 23:14 Julien Marechal, [email protected]에서 다음과 같이 썼습니다.

많은 분들이 이 기능을 원하신다는 사실을 살짝 알려드립니다 :)

—
당신이 댓글을 달았기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/moby/moby/issues/31101#issuecomment-624919070 또는
구독 취소
https://github.com/notifications/unsubscribe-auth/ABOE6GGDIVGATP734YJA4UTRQHOLJANCNFSM4DANZGSQ
.

yaml 앵커가 이 사용 사례를 처리하는 방식은 extend 비해 약간 불편합니다. 제 생각에 이 힘은 주로 요소의 재귀적 병합에서 비롯되었습니다. 앵커를 사용하면 75% 정도 얻을 수 있습니다. yaml을 재귀적으로 병합하지 않습니다. 모든 병합은 최상위 수준에서 발생합니다. 고정된 서비스 템플릿을 참조한 다음 environment 블록을 재정의하면 병합되는 대신 고정된 서비스의 환경 블록을 덮어쓰게 됩니다. extend 키워드의 동작을 일치시키려면 사전의 재귀 트리 아래로 모든 사전을 고정하고 참조해야 합니다.

예:

# anchors for the service, environment, deploy, and deploy.placement blocks
# you'll need an anchor for every dict that you want to merge into
x-common-app: &common-app
  image: app:1.0
  environment: &common-app-environment
    common_option: a
    overwrite_option: b
  deploy: &common-app-deploy
    max-replicas-per-host: 3
    placement: &common-app-deploy-placement
      constraints:
        - 'node.labels.app_host==true'

services:
  myapp: << *common-app
    environment: << *common-app-environment
      foo: bar
      baz: xyzzy
      overwrite_option: quz
    deploy: << *common-app-deploy
      replicas: 15
      placement: << *common-app-deploy-placement
        preferences:
          - spread: node.labels.region

# The above yields the following:
services:
  myapp:
    image: app:1.0
    environment:
      common_option: a
      overwrite_option: quz
      foo: bar
      baz: xyzzy
    deploy:
      replicas: 15
      max-replicas-per-host: 3
      placement:
        constraints:
          - 'node.labels.app_host==true'
        preferences:
          - spread: node.labels.region

이 예제에서는 그렇게 성가시게 보이지 않을 수 있지만 하나의 확장 블록에서 여러(10개 이상) 서비스를 템플릿화하는 경우 성가시고 덜 읽기 쉽습니다.

내 마음 속에서 이상적인 시나리오는 YAML 앵커 접근 방식의 조합과입니다 extend 접근 방식은 - 허용 extend 최고 수준에서만 보내고 x- 로, 접두사 확장 필드 블록 더 똑똑한 병합 특성.

우리 조직에서는 yaml 앵커가 구문적으로 약간 엉성하다는 것을 발견하여 기본적으로 외부 파이썬 스크립트에서 extend 기능을 다시 구현했습니다. 그것은 우리에게 효과적이지만 무언가를 처리해야 하는 절름발이 방법입니다. 마찬가지로 우리는 v3/Swarm 스택에 대한 depends_on 제거를 처리하기 위해 자체 외부 도구를 만들어야 했습니다.

최근에 gitlab CI YAML을 많이 했습니다. 읽기 쉽고 관리 가능한 템플릿과 최종 구성을 달성하는 데 아주 좋은 다음과 같은 기능이 있습니다.

• 다른 YAML 파일을 포함 할 수 있습니다(템플릿에 적합).
• 확장 할 수
• 실제 물건으로 간주되지 않도록 "숨길" 수도 있습니다. 작성 형식에서는 x- 이고 gitlab CI에서는 초기 . 입니다.

이것은 이러한 파일을 견딜 수 있게 하는 정확한 기능 세트입니다.

도커 문서에서 이 문제에 도달했습니다. 제 경우에는 docker-compose 설정을 템플릿화하고 싶었고 '해결 방법'으로 위의 조언을 따라 기존 템플릿 프로그램을 찾기로 결정했습니다. 이 실제 기능 요청에 대한 논의와 상관없이 여기에서 찾은 내용을 조금 더 자세히 설명하겠습니다. 그러나 관련된 사람들은 YAML 기반 템플릿 시스템을 사용하여 이 기능을 docker-compose 자체에 통합하는 것보다 작성 파일을 생성하는 것이 캡슐화 및 작업에 적합한 도구 선택 측면에서 더 적절할 수 있습니다.

어떤 맥락에서 저는 Let's Encrypt 및 여러 애플리케이션 컨테이너와 함께 기본 역 프록시를 사용하고 있습니다(지금은 Nextcloud, 저를 위한 것, 친구를 위한 별도의 컨테이너). 매우 유사한 설정에 대해 키 입력으로 실수와 중복을 피합니다. 다음 패키지는 내가 시도한 것입니다.

• ytt
• 달
• 큐
• 제이슨넷

ytt는 매우 포괄적인 것으로 보이며 기본적으로 YAML을 사용하는 유일한 옵션입니다. 강력하고 작업에 적합한 도구로 보였고 Python의 상위 집합인 Starlark를 사용하여 YAML 파일 내부에서 직접 처리를 수행합니다. 그러나 얼마 지나지 않아 템플릿은 매우 지저분해졌으며 코드 조각과 YAML 조각이 흩어지고 사전 및 배열 및 YAML 조각과 같은 Python 데이터 유형이 혼합되었습니다. 문자열과 같은 태그를 출력하는 HTML 템플릿 엔진)은 결국 너무 많은 오류와 너무 지저분한 파일을 초래했습니다. Dhall은 또한 매우 포괄적인 것으로 보이며 다양한 형식으로 출력할 수 있는 고유한 모국어를 사용합니다. 템플릿 시스템보다 메타프로그래밍 언어처럼 보이지만 구문이 기능적이고 매우 엄격하게 형식화되어 있다는 점을 감안할 때 구조화되지 않은 YAML용 간단한 템플릿의 가치보다 빠르게 더 복잡해졌습니다. JSON과 Haskell을 혼합한 것처럼 보이지만 언어에 필요한 작업을 수행하는 데 너무 많은 생각이 필요했습니다.

흥미롭게도 Dhall과 ytt 모두에서 어려웠던 점은 매개변수화된 필드 이름을 사용하는 것이었습니다. 그렇지 않으면 둘 다 충분히 잘 작동했을 것입니다. 그러나 내 인스턴스의 이름이 서비스 이름과 볼륨 이름에 나타나도록 해야 합니다. 이것은 다소 추악했습니다. 해시의 값에 대한 인수를 사용하는 것은 쉽지만 키 이름에 이러한 인수를 사용하는 것은 지저분하거나 깔끔하게 수행하는 방법을 찾을 수 없었고 Dhall은 형식 안전성을 적용했으며 이는 단순히 그 개념에 어긋납니다. Jsonnet을 사용하면 식을 대괄호 안에 넣는 것처럼 간단했습니다.

CUE와 Jsonnet은 둘 다 JSON 지향이지만 변환기를 통해 실행하는 것은 전혀 어렵지 않으며 Dhall과 마찬가지로 CUE는 강력한 기능이 많이 있으며 Jsonnet의 단점에서 태어났습니다. , 그것은 이미 과도하다는 것이 분명해졌습니다. 아마도 제대로 배우는 데 시간이 훨씬 더 걸리면 더 나은 옵션이 될 것입니다. 하지만 CUE는 단순한 템플릿 작업보다 유효성 검사와 스키마에 더 중점을 두는 것 같아서 빠르게 Jsonnet으로 이동하여 작업을 매우 빠르게 완료했습니다.

마지막으로, 이 모든 작업을 완료한 후에야 이 도구를 Liquid 태그 또는 유사한 HTML 템플릿의 단순성과 비교하면서 실제로 처음부터 Liquid를 사용했을 수 있음을 깨달았습니다. 저는 Jekyll 사이트의 컨텍스트에서만 사용했기 때문에 독립 실행형 패키지를 얻을 수 없었지만 기본 루핑 및 목록, 표현식을 제자리 텍스트로 바로 평가할 수 있는 기능을 사용하면 아마도 이렇게 했을 것입니다. 작업에 있어서도 훨씬 좋았습니다. Jsonify는 JSON에 대해 더 우수할 수 있지만 Liquid는 순수한 YAML에서 작동할 수 있으므로 파일을 다시 읽기 쉽게 됩니다.

+1 docker-compose는 이 티켓이 많은 수의 테스트 환경을 k8로 마이그레이션하는 것을 지원하기 위해 만들어졌기 때문에 직장에서 구현한 맞춤형 솔루션에 대한 영감 중 하나였습니다. 나는 종소리와 휘파람을 피하기 위해 매우 조심했지만 유사한 기능을 꽤 빨리 정당화했습니다. 철학적 토론(구성 대 상속 등)은 상식에서 벗어난 것처럼 보입니다. 분명히 docker-compose를 계속 사용할 수 있는 사람들이 필요합니다.

+1:+1:

dev / test / ci 환경에서 이 기능을 많이 사용했는데 ./config/{dev,test,ci}/compose.yaml 의 하위 디렉토리 경로에 있는 작성 파일에서 확장할 수 있었습니다. COMPOSE_ENV=dev 가 있는 .env 가 있지만 개발자가 재정의할 수 있으며 분명히 ci 에서 재정의할 수 있습니다.

나는 그 기능을 더 이상 사용하지 않고 비슷한 것을 할 수 있는 것으로 대체하지 않는 것에 충격을 받았습니다. 어쩌면 우리가 jinja2를 사용하고 우리가 원하는 것을 하도록 허용할 수도 있습니다. Docker-Compose가 덜 건조하기를 바랍니다. :'(

extends 는 v1.27(https://github.com/docker/compose/pull/7588)부터 docker-compose 지원되는 것 같습니다.

이 기능을 많이 사용하는 한 가지 사용 사례는 도커 이미지를 코드로 버전화하는 것입니다. 내 docker dev 및 prod 작성 파일은 모두 기본 서비스만 나열되고 태그가 지정된 서비스 이미지 버전이 있는 docker-images.yml에서 확장됩니다.

v3에서 이에 대한 쉬운 해결 방법을 찾지 못했습니다.