Compose: 기본적으로 시작되지 않는 서비스 정의

옵션 1의 경우 +1

실제로 컴포지션의 일부가 아니지만 연결 / 첨부해야하는 서비스를 추가하는 것은 잘못된 디자인 선택이라고 생각합니다. 어떤 형태의 include 구문을 허용하여 해결할 수있는 몇 가지 다른 사용 사례가 있습니다. 단일 기능으로 여러 문제를 해결하는 것은 항상 좋습니다.

이러한 문제 중 일부 (데이터 전용 컨테이너를 다루는 문제, # 942, @ cpuguy83의 마지막 주석)는 실제로 # 1754에 의해 이미 수정되었으므로 더 이상 문제로 간주 할 필요가 없다고 생각합니다 (1.5 이후 ).

우리는 Magento 확장을 개발합니다. 이를 위해서는 LAMP 스택에서 웹 스토어를 실행하는 간단한 방법이 필요합니다. Compose를 사용하면 쉽게 할 수 있습니다. 그러나 우리는 또한 phpunit, 다양한 정적 분석 도구, 문서 작성기 등을 실행하려고합니다. 사실 대부분의 "서비스"는 docker-compose run --rm phplint 와 같은 명령 일뿐입니다. 이상적으로는 다음과 같은 규정되지 않은 명령

docker-compose up -d

장기 실행 서비스 (실제 _services_ 그대로) 만 시작하고 phpunit과 같은 다른 효과를 불필요하게 트리거하지 않습니다. (웹 서비스가 시작되기 전에 Selenium 테스트를 실행하는 것과 같이 순서가 잘못된 것을 트리거하지 않는 것도 중요합니다.)

우리가 정말로하려는 것은 프로덕션 서비스를 실행하는 것이 아니라 개발자로부터 환경 관리의 고통을 없애는 것입니다. @dnephin 의 의견이 Compose가 향하고있는 방향을 대표하는지 여부는 모르겠지만 Compose가 Fig가 시작된 틈새 시장에 서비스를 제공 할 계획인지 여부는 저에게 모호해 보입니다. 옵션 1은 개발자가 Fig가 의도 한대로 이것을 사용하는 데 필요한 사용 편의성을 지원하지 않는다고 생각합니다.) Compose가 여러 책임을 갖고 싶지 않은지 완전히 이해하지만 누군가가 명확하게 알려줄 수 있기를 바랍니다. 빠르고 고립 된 개발 환경을 위해이 제품을 사용하는 우리가 다른 방향으로 나아가 야한다면.

@kojiromike , (1) 사용 사례에 적합하지 않은 것은 무엇입니까? 명령 의미론 ( docker-compose run --rm phplint 대 docker-compose --file phplint.yml up )에 관한 것입니까?

docker-compose up -d 는 phplint를 '시작'하려고하고 docker-compose ps 는 phplint 'service'가 다운되었음을보고합니다. 실제로는 서비스 컨테이너가 아니라 도구 컨테이너이므로 업 / 다운 개념이 없어야합니다. 도구 컨테이너가 도커 (분명히 '서비스'가 아닌 redis-cli와 같은 것을 실행하는 방법)에 의해 수용된다는 것이 제 이해 였고, 개발에 더 많이 사용하는 동안에도 프로덕션을위한 장소가 있다고 생각합니다. awk 가 프로덕션 머신이나 컨테이너에 설치되어있는 이유와 같이 연결이있는 컨테이너를 통해 실행하여 예측 가능한 동작을 가져 오는 것은 어떻습니까?

: +1 : 실행중인 단위 테스트를 캡슐화하기 위해 다른 서비스와 함께 tests 컨테이너를 만들고 싶습니다. 내 "해결 방법"은 명령을 "/ bin / true"로 설정하고 CLI에 지정된 단위 테스트 명령으로 컨테이너를 실행하는 것입니다. up 시간에 시작할 컨테이너를 지정할 수 있으면 좋을 것입니다!

(btw, 주위에 좋은 일, 여러분)

cc @jameydeorio

@ryneeverett 의미론은 그것의 일부입니다. 자체 문서화 및 검색 가능성의 문제입니다. 현재 개발자에게 docker-compose run --rm foo bar 라고 알려줍니다. 쉘 함수 나 별칭을 만들도록 초대하지만 프로젝트에 대한 표준 별칭 / rcfile을 유지하지 않습니다. (컨테이너 외부의 항목을 표준화하고 싶지 않습니다. Docker _to_ standardize를 사용하고 싶습니다.) 일부 명령에 대해 새 파일을 추가하면 중요한 계층이 생성됩니다. docker-compose.yml 파일은 중요한 경우 "기본"파일이됩니다. 그리고 "기타"파일은 덜 중요해집니다.

다른 하나는 서비스 간의 관계를 유지하는 것이 더 힘들어진다는 것입니다. 기본적으로 실행되지 않는 항목이 있다고해서 장기 실행 서비스에서 link 또는 volume 를 사용하지 않는다는 의미는 아닙니다. extends 은 실제로 서비스를 "명령"(일회성 서비스)에 연결하는 데 필요한 모든 기능을 제공하지 않습니다. 그렇게하더라도 여러 개의 yaml 파일을 사용해야한다면 extends 를 사용해야하는데 그렇지 않으면 필요하지 않을 것입니다.

extends는 서비스를 "명령"(일회성 서비스)에 연결하는 데 필요한 모든 기능을 실제로 제공하지는 않습니다. 그렇더라도 여러 yaml 파일을 사용해야한다면 필요하지 않은 확장을 사용해야합니다.

@kojiromike 내가 의심했던 것입니다. 개선 된 extends 지원 + 단일 docker-compose.yml 내에서 하위 명령 ( extends 과 기능적으로 동일 함)을 수행하는 방법에 만족하는지 궁금합니다. 그러나 아마도 후자는 (4)와 동일합니다.

2) 기본적으로 시작되지 않도록 서비스에 옵션 추가

나는 옵션 2에 투표한다. 예를 들어 start: false 지시어와 같은 것. 장점은 여러 compose.yml 파일이나 추가 구성 파일이 필요하지 않다는 것입니다. 하나의 compose.yml 만 읽으면 전체 앱 스택의 느낌을 얻을 수 있습니다.

https://github.com/docker/compose/issues/1987#issuecomment -139632238에 대해 제안 된 솔루션이이를 처리 할 것이라고 생각합니다. "admin"서비스는 별도의 구성으로 정의 할 수 있으며 구성에 대해 관리자 명령을 실행해야하는 경우 -f 할 수 있습니다.

@dnephin # 1987 (comment) 의 솔루션은 _does_ "admin services"를 처리하지만 "data only container"는 처리하지 않습니다 _ 맞습니까? 여전히 command: /bin/true 해결 방법을 사용해야합니다.

compose가 볼륨을 다시 생성 된 컨테이너로 교체하는 작업을 처리하므로 compose가있는 데이터 전용 컨테이너가 필요하지 않습니다.

@ cpuguy83 다음 예제에서는 데이터 컨테이너가 실제로 필요하지 않지만 볼륨을 변경하려면 지정된 한

nginx:
  image: nginx:1.9
  volumes_from:
  - data

php:
  image: php:5.6-fpm
  volumes_from:
  - data

data:
  image: debian:jessie
  volumes:
  - ./:/app

그러나 나는 이것이 코너 케이스이며 추가 구문을 추가하는 것은 아마도 가치가 없다는 데 동의합니다. 제안 된 솔루션이이 경우를 처리하지 못한다는 것입니다.

사실, 데이터 볼륨에는 여전히 일부 명령이 필요하므로 해당 명령을 지원하려면 최소 이미지를 사용해야합니다.

앞으로 나올 새 볼륨 API에 대해 완전히 최신 상태는 아니지만 더 나은 방식으로 데이터 볼륨을 처리 할 수 ​​있도록 volumes: 섹션을 추가하여 구성 할 수 있기를 바랍니다. (그들을 위해 컨테이너를 요구하는 대신).

이것이 반드시 올바른 선택이되는 것은 아니지만 학습 곡선 / 이해의 용이성을 고려해야한다고 생각합니다.

나는 (2)가 이해하기 가장 쉽다고 생각합니다. 나는 이것을 확인할 방법이 없지만, 내 직감에 따르면 우리가 여기서 해결하려는 문제에 직면하는 docker-compose 의 모든 옵션에 대해 친밀하지 않은 대부분의 사람들은 다음과 같이 말합니다. " docker-compose up 실행할 때 해당 컨테이너를 _ 시작하지 않음 _ 상태로 만들 수있는 방법이 있었으면 좋겠습니다."그리고 start: false 및 bam이 표시됩니다. 완료되고 행복합니다.

그들은 "이 문제를 해결하기 위해 어색한 링크 스토리가있는 두 번째 파일을 만들 수있는 방법이 있었다면 ..."이라고 말하지 않습니다. (https://github.com/docker/compose/issues/ 1987 # issuecomment-139632238은 "어색한 연결 이야기"를 도와줍니다.

(4)는 다소 모호했지만, 이와 같은 대본과 일회성에 대한 전용 방법이이 "이치에 맞는"법안에 부합합니다.

오늘 저는 정확히 (2) 찾고 있었지만 가장 선호하지 않는 솔루션 인 두 번째 YML 파일로 끝났습니다. 내 사용 사례 :

두 개의 컨테이너가 있으며 모두 동일한 mongo 컨테이너에 연결됩니다. 저는 제 자신과 팀에게 mongo 데이터베이스에 고정물을로드 할 수있는 기능을 제공하고 싶습니다.이를 수행하는 가장 쉬운 방법은 mongo 컨테이너를 다른 이름 fixtures 하는 것입니다. mongo에 연결 한 다음 mongorestore --host mongo --port 27017 --drop /dump 합니다. 우리는 항상 조명기를로드하고 싶지 않기 때문에 start: false 와 함께 사용하는 것이 자연스럽게 느껴졌지만 fixtures 및 mongo 컨테이너에 대해 별도의 YML 파일을 갖게되었습니다.

잘 작동하지만 start: false 는 훨씬 더 깨끗한 IMO입니다. 이 소위 픽스처 컨테이너의 순열이 10 개 이상이면 예 start: false 는 나쁜 생각이고 (1) 합니다.

docker-compose up -d 명령으로 일부 서비스를 실행하지 않아야하는 compose 파일을 만들기 만하면됩니다. 나에게는 옵션 (2)가 내 문제에 대한 최상의 솔루션이 될 것입니다.

나는 이것도 만났다. 어떤 것이 최선의 해결책이라고 생각하는지 잘 모르겠지만, 저에게는 구도의 일부로 활용되는 이미지를 구축 할 수있는 능력이 필요하다는 것입니다. 임시 컨테이너 용이지만 필요할 때 컨테이너를 실행할 수 있도록 이미지를 사용할 준비가되어 있어야합니다.

안녕하세요! 여기에 같은 문제, 좋은 그룹화 문제가있어 다행입니다.

제 경우에는 서비스가있는 두 개의 컨테이너와 함께 작동하는 파이썬 스택이 있습니다. 모든 것이 잘 작동하지만 방금 스택에서 케이스를 찾았습니다. 저는 bower로 정적 종속성을 관리하고 있으며 컨테이너 내부에서 bower 명령을 실행하고 싶습니다. 이것은 우리가 잠시 실행하는 스크립트 일뿐입니다.

우리가 가지고있는 작성 구조 내에서이 스크립트를 실행하면 좋을 것입니다. 나는 다음과 같은 이미지를 얻었다.
docker-compose run node bower install

그래서 저는 4 번째 중 2 번째 옵션을 좋아합니다. 서비스가 시작되지 않고 필요하지 않습니다 .P

합의가 있다면 "재시작"과 같은 풀 요청을 보내려고 할 수 있습니다.
시작 : 항상
아마도 ... 몰라.

옵션 2에 대한 또 다른 투표.

옵션 2도 선호합니다. 새로운 Docker 데이터 컨테이너는 docker-compose 파일에 지정할 수 있지만 사용하기 위해 실행 중일 필요는 없습니다.

나도 옵션 2

옵션 2가 좋을 것입니다.

옵션 2의 경우 +1

옵션 2의 경우 +1. 여러 파일을 유지하고 이름을 입력하는 것은 시간 낭비 일뿐입니다. 하나의 부울 플래그가 모두를 지배합니다. :맥주:

옵션 4의 경우 +1,
두 번째로 좋아하는 것을 선택해야한다면 선택 2입니다.

내가 둘 다 +1 할 수 있다면 최선의 선택은 2,4라는 사실은 사실입니다.

2 명 투표

2와 4 모두 가지고 있으면 좋습니다.
2에 +1

작업에 대한 새로운 개념을 도입 할 필요는 없다고 생각합니다. 이것들은 제 생각에 아주 잘 읽고 많은 수정없이 가능합니다.

// 'task' being a service that manages all my tasks, probably with some custom entrypoint script
docker-compose run task tests

// 'tests' being a service specifically for testing with the default command set to run my tests
docker-compose run tests

별도의 compose 파일이있는 현재 "솔루션"은 제 생각에는 실제로 솔루션이 아닙니다. @xaka가 말했듯이 아무도이 모든 것을 입력하고 싶지 않습니다.

docker-compose -f default-file.yml -f additional-tasks-file.yml  run task myTask

당신이 될 겁니다 것은입니다 ./run-task 전에 모든 상용구 추가 스크립트 myTask 당신을 위해. 그러나 이제 다중 컨테이너 앱에 다른 진입 점과 인터페이스를 추가했습니다. 개발자는 docker-compose.yml 를보고 다음과 같이 생각합니다. _ "좋아요, 작성 앱입니다.이 작업을 처리하는 방법을 알고 있습니다!"_ 이제 그들에게 말해야합니다. _ "좋습니다. docker-compose 관리 할 수 ​​있습니다.

start: false / up: false / some-additional-flag-to-a-service: false 는 구현하기 가장 간단 할 수도 있지만 가장 명확하고 이해하기 쉬운 것일 수도 있습니다. 그리고 그것은 사용성을 크게 향상시킬 것입니다.

@sherter가 말한 것. : arrow_up :

: +1 : 그것을 위해. 별도의 dockerfile은 특히 네트워크가 관련된 경우 큰 고통입니다.

start: true|false 접근 방식은 너무 제한적입니다. 일부 서비스는 테스트에 사용되고 다른 일부는 관리자 용으로, 나머지는 정상 작동 용으로 사용되는 경우 어떻게됩니까?

서비스에 그룹화 개념을 추가하는 것을 선호합니다.

    myservice:
       group: `admin`

group 속성이 정의되지 않은 경우 default 로 간주됩니다.
이렇게하면 docker-compose up -g admin -d 사용하여 기본 및 관리 서비스를 시작할 수 있습니다.

더 나은 방법은 groups 를 배열로 만드는 것입니다.

그룹 클래스의 서비스를 만드는 것은 강력한 기능인 것처럼 보이지만이 문제에 접하는 것처럼 보입니다.

docker-compose 버전 2 에서 모든 컨테이너는 services: 최상위 항목 내에 선언됩니다.
스크립트를 실행하기 위해 start: never 로 서비스를 선언하는 것은 잘못된 것 같습니다.
따라서 새로운 형식을 고려할 때 _services_, _volumes_ 및 _networks_와 별도로 추가 최상위 항목을 선언해야하지 않습니까?

내 제안 :

• 새로운 scripts: , transients: (또는 더 나은 이름을 생각 해보세요) 최상위 항목을 v2에 추가합니다.
• 과도 내부에서 어떤 서비스와 마찬가지로 컨테이너를 정의 할 수 있습니다.
• 유일한 차이점은 일시적인 용도로만 사용되기 때문에 _ 기본적으로 시작되지 않는다는 것입니다.

예:

version: "2"

services:
  web:
    image: myapp
    networks:
      - front
      - back
    volumes:
      - /usr/src/app/
  redis:
    image: redis
    volumes:
      - redis-data:/var/lib/redis
    networks:
      - back

scripts:
  bower:
    image: my_image_with_bower
    volumes_from: web
    working_dir: /usr/src/app/static
    command: "bower"
// maybe would be great to place something like "bower $@"
// to define where you want the cli arguments to be placed, by default at the end.

volumes:
  redis-data:
    driver: flocker

networks:
  front:
    driver: overlay
  back:
    driver: overlay

그리고 다음을 실행할 수 있습니다.

docker-compose script bower <EXTRA_CMD_ARGUMENTS |  default nothing>

docker-compose script bower install

우려 사항 :

• 시작 관리를 위해 다른 최상위 항목을 만드는 것이 OverPowered처럼 들리지만, 새 형식이 최상위 수준에서 동작을 선언한다는 사실에서 파생되었습니다.
• 나는 이것이 추가 될 수있는 추가적인 유연성 (및 문제)을 상상하려고 노력하고있다.

마지막으로, _groups 기능 _에서 멋지게 들리지만 그 정도의 그룹화가 있다면 각각에 대해 docker-compose 파일을 만드는 데 문제가 없습니다. 아마도 당신이 원하는 기능은 docker-compose file inheritance 일 것입니다.

PD : @bfirsh 가 마음에 들면 "가능한 제안"에 추가 할 수 있습니다.

두 번째로 이것은 임박한 새로운 형식 선언 서비스로 인해 네 번째 제안 의 개편입니다.

옵션 2에 대한 투표 : 가장 명확하고 읽기 쉬우 며 새로운 개념을 배울 필요가 없습니다.
기본적으로 시작되지 않는 서비스를 원합니다.

disabled: true 와 같은 것은 어떻습니까?

@ cpuguy83 run 에서도 전체 서비스가 비활성화 되었음을 의미하는 것 같습니다. 혼란 스러울 것입니다.

@qcho 흠, 이제 1.6부터 Docker에 익숙해 졌으므로 당신과 @gittycat 의 접근 방식을 정말 좋아합니다. 나는 (푸른 하늘) 인터페이스를 다음과 같이 묘사합니다.

groups: # if no groups, all services are in the "default" group by…default
    - foo
    - bar
services:
  foo:
    image: imagine
    groups: foo
  bar:
    image: energy
    groups: bar
  baz:
    image: money
    # no groups, so "default"
   quux:
    image: word
    groups:
      - bar
      - default

한편 껍데기에…

docker-compose up -d # Up all services in default group, so 'baz' and quux
docker-compose up -d --groups foo # Up all services in the foo group
docker-compose up -d --groups foo,default # You get the idea
docker-compose run --rm bar somecommand # We never started 'bar', so it can be a one-off command

이와 같은 접근 방식은 대단하고이 티켓의 필요성을 없앨 수 있지만 범위를 벗어납니다.

@kojiromike 나는 그렇게 생각하지 않는다. 이것이 init 시스템이 자동으로 시작되지 않아야하는 서비스를 참조하는 방법입니다.

또한 간단하며 모든 "혼란"은 문서로 해결할 수 있습니다.
또한 서비스 시작 개념과는 전혀 관련이없는이 그룹화보다 훨씬 덜 혼란 스럽습니다.

@ cpuguy83 나는 "서비스"의 의미가 정확히 처음에 혼란스러운 것이라고 생각합니다. 나는 그룹화가 범위 크립이라는 것에 동의합니다. 그런 의미에서 나는 "서비스"와 "서비스가 아닌 것"을 명확히 구분하는 옵션 4 / @qcho 의 접근 방식을 선호합니다.

그것이 요점입니다. 왜 서비스를 실행하지 않을 컨테이너를 "service ... disabled"범주에 넣어야합니다. 누군가 만든 못생긴 패치처럼 들리며 직관적이지 않습니다.

형식의 "버전 2"가이 문제를 고려했을 것입니다. 예를 들어 다른 사양은

version: 3?
containers:
  webserver:
    ...
  database:
    ...
  cache:
    ...
  some_script_container:

services: (they are groups):
  production:
    webserver:
      ...
    database:
      ...
    cache:
      ...
  development:
    webserver:
      ... DEFINE SOME CUSTOM DEV STUFF ABOVE basic container definition
    database:
      ...
    cache:
      ...     

이제 그룹 정의와 함께 적절한 서비스가 제공됩니다. 생산 또는 개발 서비스 그룹을 시작할 수 있습니다. 또는 some_script_container에서 스크립트를 실행하십시오. 어떤 서비스에도 정의되어 있지 않기 때문에 아무도 시작되지 않습니다.

@qcho 는 서비스의 정의에 따라 다르지만, 어떤 경우에도 가끔 실행해야하는 질문을 던지고, 실행 여부는 사람 만이 결정할 수 있습니다.

따라서 compose가 job 객체와 같은 것을 채택한다고 가정 해 보겠습니다.

1. 작업은 한 번만 실행됩니다.
2. 서비스 후 작업 시작
3. 일자리가 종료 될 것으로 예상됩니다
4. ???

이제 compose는 작업에 대한 일부 지역 상태를 유지해야하는데 현재는 전혀 수행하지 않습니다.

그렇기 때문에 간단한 auto-up: false 또는 autorun: false 것이이를 처리하는 가장 쉽고 덜 오싹한 (범위 별) 방법입니다.

@ cpuguy83 나는 당신이 내가 말하는 것을 더 복잡한 것으로 확장하고 있다고 생각합니다. 작업이나 워크 플로에 대해 알고있는 도커 작성을 의도하지 않습니다. 이를 위해 외부 스크립트를 만들 수 있습니다. 내가 의도 한 것은 docker-compose가 애플리케이션을 실행할 전체 스택을 정의해야한다는 것입니다.

나는 스크립트를 만들고 당신이 말하는 상태를 유지한다고 상상할 수 있습니다. 서비스가 시작되기 전에 스크립트를 호출해도됩니다. 내가 상상하지 못하는 것은 내가 가져와야 할 볼륨을 확인해야하거나 그것에 적용되는 스크립트를 실행하기 위해 알 수없는 컨테이너에서 추출해야하는 구성을 확인해야하기 때문에 작곡가 파일을 파싱하는 것입니다. 그래서 저는 docker-compose가 그 컨테이너를 제공해야한다고 생각합니다. 스크립트를 실행하고 상태를 유지하는 것이 내 문제입니다.

사람들이 왜 계속 그렇게 말하는지 모르겠어

services:
  my-script-container:
    auto-up:false

다음보다 간단합니다.

scripts/containers/transients/you_name_it:
  my-script-container:

동일한 수준의 복잡성입니다. 그러나 의미 상 덜 해키.

한 스레드에 대한 아이디어를 얻으려면 # 2803을 참조하십시오.

사용 사례 : 구성 요소가 많은 프로젝트와 사용자가 무엇을 선택하고 설치할지 선택했지만 compose 파일이 모두 설치합니다.

제안 : docker.compose에 정의 된 이미지를 제외하기 위해 docker-cmpose.overrider.yml에 넣는 옵션을 추가합니다.

즉

일부 이미지 :
제외 : 예

동작은 docker-compose.yml의 해당 항목을 무시하는 것입니다.

팀의 생각을 알려 주시면 변경에 관심이있을 것입니다.

# 2에 대한 투표도 오늘이 필요에 부딪 혔습니다.

@jimzucker 의 제안도 작동하지만, 명시 적으로 호출하지 않는 한이 '서비스'가 실행되지 않는다는 것을 즉시 단서를 제공하기 위해 기본 .yaml 파일에 "start : false"가 표시되는 것이 좋습니다. 그렇지 않으면 사용자 (또는 제 경우에는 도커 작성 파일을 전달한 최종 사용자 / 개발자)가 재정의 파일을 찾는 것을 기억해야합니다.

+1 for 2. compose의 일부로 docker 이미지를 빌드해야하지만 서비스로 실행되지 않는 상황이 있습니다. 다른 서비스 (도커 양말이 내부에 마운트되어 있음)는 이미지에서 컨테이너를 자주 실행합니다.

+1은 2이고 "자동 실행"또는 "자동 실행"은 +1입니다.

그리고 서비스 그룹의 경우 (@gittycat에서 설명 함)는 환경 변수 ala "auto-up : $ {ADMIN}"을 통해 처리 할 수 ​​없습니까?

또한 docker-compose.yml 서비스가 간단한 docker-compose up 자동 시작되지 않고 명시 적으로 만 시작되도록 표시하는 실제 사용 사례도 있습니다.

해결책 1)은 지금 가능한 한 가지 방법이지만 docker-compose up 호출하고 파일을 분할하거나 복제해야하는 대신 하나 이상의 yml 파일을 지정해야하기 때문에 너무 번거 롭습니다.

나는 해결책 2와 같은 것을보고 싶기 때문에) (다른 많은 사람들도 그렇듯이) 나는 # 3047에서 이것에 대한 개념 증명을 구현하여 실행 가능한지 확인하기 위해 약간 놀 수 있습니다. 해결책.

옵션 2의 경우 +1

옵션 2의 경우 +1

옵션 2의 경우 +1

옵션 2와 4 모두 +1

옵션 2 및 4의 경우 +1

옵션 4의 경우 +1. 일부 구성은 스크립트에 허용되지 않아야합니다 (예 : 다시 시작 : 항상).

옵션 2를 사용하면 다음과 같은 이상한 경우가 발생할 수 있습니다.

service:
  run_tests:
    build: ./tests/
    restart: always
    auto-start: "false"

그게 무슨 뜻일까요?

@mathroc : 의미 : "

@niko 아 맞다, 게시하기 전에 조금 더 생각해야합니다 ...

옵션 2의 "투표"를 +1로 변경

옵션 2에 +1, 여러 프로젝트에서 필요했습니다.

@bfirsh @dnephin 핑 :
이 문제에 대한 업데이트를 제공 할 수 있습니까? 여기에있는 대부분의 의견이 옵션 2를 선호하기 때문에 현재 이와 같은 (또는 옵션 3/4) 구현 계획이 있습니까?
풀 리퀘스트 (# 3047)를 다듬고 병합을 고려한다면 테스트와 문서로 완성 할 수 있습니다.

감사합니다.

옵션 2의 경우 +1

옵션 2의 경우 +1

옵션 2의 경우 +1

옵션 1이 작동 할 수 있다고 생각하지만 다음의 장황함을 줄이는 더 나은 방법이 필요합니다.

docker-compose -f docker-compose.yml -f docker-compose.tests.yml up

아마도 단순화 / 증강 플래그를 추가 할 수 있을까요? docker-compose --augment tests up 및 docker-compose.yml 의 변형 인 경우 자동으로 해결-그렇지 않으면 사용자가 명시 적이어야합니다.

하지만 suites 및 commands 같은 새로운 최상위 키워드 아이디어가 마음에 듭니다.

다음 구성은 다음을 허용합니다.

docker-compose run -s application
docker-compose run -c cache-clear

suites:
    application:
        services:
            - database
            - memcached
            - application
    tests:
        extends: application
        services:
            - application

commands:
    cache-clear:
        service: application
        workdir: /var/www
        command/entrypoint: php app/console ca:cl

코드에서 이미 "일회성"서비스라는 개념이 있음을 알 수 있습니다 (IMHO는 docker-compose run 가 호출 될 때만 사용됨).
다시 사용할 수 있습니까?
컨테이너에 com.docker.compose.oneoff=True 라벨을 지정하면 시작하려고할까요?

그렇지 않으면 옵션 2에 투표합니다.

나는 이것을 우연히 만났으므로 여기에 두 가지 사용 사례가 있습니다.

1. "전역"환경 변수 : 여기에서 제안하는 접근 방식은 extends 를 사용하는 것입니다.이 방법은 괜찮습니다 ...하지만 이제는 확장 할 대상에 대해 image 를 정의해야합니다. , scratch 도 사용할 수 없습니다 (따라서 https://hub.docker.com/r/tianon/true/로 끝남).
2. "확장"서비스 : 기본적으로 하나의 MongoDB 인스턴스가 있지만 일부 테스트의 경우 두 번째 비활성 인스턴스를 정의하고 싶습니다.이 인스턴스는 해당 테스트를 위해 가져올 수 있습니다. 다른 파일에서 extends 를 사용하는 것은 실행 가능한 아이디어처럼 보입니다 (여전히 docker / docker-compose 및 관련 모범 사례에 대해 배우고 있음).

옵션 2의 경우 +1

옵션 2의 경우 +1

옵션 2의 경우 +1
단순한 변화 인 것 같습니다 ...

+1 옵션 2,

공통 환경 및 구성 집합을 공유하는 여러 컨테이너의 사용 사례에서는 확장 할 기본 컨테이너를 빌드하지만 실제로 컨테이너를 시작하지 않는 것이 좋습니다.

auto-start:true|false

지난 9 월부터 rocker-compose 라는 멋진 솔루션이 있으므로 다음을 실행하는 것이 좋습니다. _always_ | _once_ | _못_. 나는 또한 상태를 좋아한다 : _running_ | _ran_ | _created_도 마찬가지입니다.

이 기능을 위해 별도의 프로젝트를 사용하는 팬이 아니기 때문에 이것이 구현 될 때까지 tianon / true 프로젝트에서 True asm 코드 명령을 훔쳤습니다.

나는 또한 처음에는 옵션 2가 가장 좋을 것이라고 생각했지만 이제는 너무 제한적일 것이라고 생각하기 시작했고 추가 한 직후에는 한 번 실행 작업에 대한 필요성이 나타납니다. 실제로 저는 다음과 같은 사용 사례가 필요한 프로젝트를 진행하고 있습니다.

• 스택 내에서 초기 배포시 한 번 실행되는 컨테이너를 정의하고 향후 실행은 외부에서만 (예 : 일정 / 이벤트, API 호출 등을 통해) 트리거되어 기본 서비스 컨테이너의 상태를 초기화 / 업데이트 할 수 있기를 원합니다. 동일한 스택 내 (예 : DB 데이터 / 스키마, 데이터 볼륨 채우기 등)
• 스택 내에서 유틸리티 / 관리 작업 (예 : 상태 / 데이터 검사 등) 및 일정에 따라 트리거되는 프로세스 (예 : 백업)를 캡슐화하는 데 사용할 수 있도록 외부에서만 트리거되는 컨테이너를 정의 할 수 있기를 원합니다. 외부 이벤트 (예 : S3 버킷 변경시 프로세스 트리거)

제 경우에는 유틸리티 / 관리자 작업 중 일부가 파괴적 일 수 있고 사용하기 만하면되기 때문에 state: created (ran 0 회)와 state: ran (ran> = 1 회)를 구분하는 것이 중요합니다. 서비스 마이그레이션과 같은 특정 상황에서.

내가 지금은 락커-컴 포즈 또는 옵션 4에서와 같이 최상위 수준 _task_ 또는 _job_ 개체 + 종속성을 표현하는 기능과 같이 state: running | ran | created 쪽으로 더 기울고 있다는 점을 감안할 때 서비스가 이전 / 이후에 작업을 실행하도록 트리거 할 수 있습니다. .

이것이 내 사용 사례에 중요하다는 것을 언급하고 싶습니다. Docker-compose를 사용하여 테스트 환경을 만들고 테스트 스위트를 실행합니다. 모든 컨테이너를 한 번에 시작할 때의 문제는 테스트 스위트를 실행하기 전에 서비스 컨테이너 (예 : 데이터베이스 또는 셀러리 작업자)를 쉽게 초기화 할 수 없다는 것입니다.

다음과 같은 작업을 수행 할 수있는 것이 좋습니다.

$ docker-compose --file="docker-compose-testing.yml" up -d --exclude=tests
$ sleep 5
$ docker-compose --file="docker-compose-testing.yml" run --rm tests

초기화가 발생했는지 확인하기 위해 sleep 5 보다 더 정교한 것을 작성할 수 있지만 예제 스 니펫에는 필요하지 않습니다.

cli 플래그에 대한 옵션을 읽지 않았습니다. 따라서 옵션 목록에 --exclude 플래그를 추가 할 것을 제안합니다. --exclude 플래그는 up 명령에 지정된 컨테이너를 시작하지 않도록 지시합니다. --exclude 플래그는 필요에 따라 여러 컨테이너를 시작에서 제외 할 수 있도록 구문 분석됩니다.

: +1 :

옵션 2가 적합한 솔루션이 될 수있는 또 다른 사용 사례를 고려하여 기존 애플리케이션 내에서 새로운 하위 서비스를 반복합니다. 프로젝트에 참여하는 대부분의 개발자는 아직 새로운 서비스가 필요하지 않으며, 작업을 방해하는 문제로 인해 문제가 발생하는 것을 원하지는 않지만 장기간 동안 트리 외부 분기를 유지하지 않는 것이 좋습니다. 시각.

별도의 "docker-compose-experimental.yml"파일은 작동 할 수 있지만 해당 구성 요소에 대한 작업에 대한 모든 문서는 구성 요소가 아직 실험적인 동안 한 방향으로 작성되어야하며 표준 집합의 일부가되면 수정해야 함을 의미합니다. 서비스.

옵션 2에 +1

옵션 2의 경우 +1

옵션 2의 경우 +1

옵션 2의 경우 +1

옵션 2의 경우 +1

@acran 나는 당신이 이것을 앞으로 나아가는 견인력을 얻을 수 있는지 확인하기 위해 풀 요청을 제출하는 것을보고 싶습니다. 아마도 # 3047에서 갈등을 제거하기 위해 리베이스하면이 문제에주의를 기울이는 방법을 모르겠습니다.

@jimzucker 글쎄 # 3047은 이미 풀 리퀘스트이고 나는 여전히 개발자들의 코멘트를 기다리고있다. : disappointed :

위의 내 의견을 참조하십시오. PR을 병합 할 가치가있게 만들려면 여전히 관련 문서 및 테스트 케이스를 업데이트해야합니다. 그러나 나는이 접근법이 업스트림에 의해 통합되는 것으로 간주 될 것이라는 것을 알지 못한 채 그 작업을 수행하지 않을 것입니다. 그렇지 않으면 이것에 대한 나의 노력이 무의미 할 수 있습니다 ...

+1 옵션 2

@acran , 관련 문서 및 테스트 사례를 업데이트하는 데 도움을 드리고자합니다. 괜찮습니까?

+1 옵션 2

아니면 Kubernetes에서와 같이 일종의 Job을 정의 할 수 있습니까?

옵션 2의 경우 +1

여러 서비스가 포함 된 docker-compose가 있으며 그중 하나 (데이터베이스)는 프로덕션 환경이 아닌 개발 환경에서 시작되어야합니다. 따라서 두 개의 docker-compose 파일을 유지해야합니다. 옵션 2는 정확히 우리가 찾고있는 것입니다!

: +1 : 옵션 2의 경우

+1 옵션 2

@acran 저는 피드백을 받기 위해 올바른 프로세스 / 채널을 찾기 위해 SF의 일부 연결부에 연락하여 앞으로 나아갈 수 있도록 계속 지켜봐주십시오.)

👍 옵션 2

옵션 2의 경우 +1

+1 옵션 2

+1 옵션 2

또한 나는 옵션 2에 투표합니다

또 다른 아이디어 : 이제 최상위 networks 및 volumes 가 있으므로 images 옵션도 추가 할 수 있습니다. 이는 애플리케이션이 작동하려면 이러한 이미지를 가져 오거나 빌드해야한다는 Compose에 대한 힌트가 될 수 있지만 docker-compose up 를 수행 할 때는 실행되지 않습니다.

이것은 내 머리 꼭대기에서 두 가지 사용 사례에서 작동합니다.

1) 여기서 일반적인 문제는 일종의 관리 명령을 실행하려는 경우입니다. docker-compose run 은 서비스가 존재하지 않는 경우 실행중인 이미지로 대체 될 수 있습니다.
2) Docker 이미지를 실행하지만 항상 실행되지 않는 이와 같은 앱 .

/ cc @dnephin @aanand @ shin-

Docker-compose 파일에서 단기 컨테이너에 필요한 모든 옵션 (예 : 볼륨 / 마운트 포인트, 네트워크, 링크, 이름 등)을 구성 할 수 있다는 점을 제외하면 컨테이너를 실행해야 할 때마다 계속 추가해야합니다.

2016 년 9 월 13 일 오전 3:58:41 CDT에 Ben Firshman [email protected] 은 다음과 같이 썼습니다.

또 다른 아이디어 : 이제 최상위 수준 networks 및 volumes 가 있으므로
images 옵션도 추가하십시오. 이것은 Compose에 대한 힌트가 될 것입니다.
응용 프로그램이 작동하려면 이미지를 가져 오거나 빌드해야하지만
docker-compose up 할 때 실행되지 않습니다.

이것은 내 머리 꼭대기에서 두 가지 사용 사례에서 작동합니다.

1) 여기에서 어떤 종류의 관리를 원하는 일반적인 문제
실행할 명령. docker-compose run 은 (는) 실행중인 이미지로 대체 될 수 있습니다.
서비스가 존재하지 않는 경우.
2) 같은 앱이 실행하는
Docker 이미지이지만 항상 실행되지는 않습니다.

/ cc @dnephin @aanand @ shin-

댓글을 달았 기 때문에 수신 한 것입니다.
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/docker/compose/issues/1896#issuecomment -246618909

내 Android 기기에서 K-9 Mail을 사용하여 보냈습니다. 간결함을 용서해주십시오.

나는 이것 에 대해 docker-compose up foo 만 설정하고 빌드 및 종료를 수행하는 것이 가장 좋습니다.

여기에서 더 많은 이해를 얻으려는 시도 : 옵션 2)는 더 일반적인 " docker-compose.yml 에서 initial_scale 값을 원합니다"의 특수한 경우입니까? (# 1661, # 2496 et. al. 참조)

@ankon 전혀 아닙니다.

images [섹션] 추가

@bfirsh 이것은 내가 https://github.com/dnephin/dobi로 취한 방향으로 움직이기 시작합니다

1. networks 및 volumes 는 실제로 직접 작동하지 않으며 컨테이너에서 필요에 따라 생성됩니다. 이미지를 자체 섹션으로 분할하는 것은 현재의 동작을 변경하지 않고 Compose 구성을 더 복잡하게 만들뿐입니다. 이미지 만 빌드하려면 docker-compose build .
2. 이 문제에서 확인 된 문제를 실제로 해결한다고 생각하지 않습니다. 사람들은 이미지뿐만 아니라 컨테이너를 원합니다.

작성 파일에서 스케일링 제약 조건을 선언하는 것에 대한 # 2496의 스레드와 토론을 다시 읽으면서 옵션 2보다 옵션 4 (즉, 새로운 최상위 섹션)를 선호합니다.

특히 utilities 와 같은 섹션 이름이 적합 할 것입니다. 일반적으로 필요하지 않은 구성 요소이지만 필요할 때 연결되는 다른 구성 요소를 미리 구성해야합니다. 사람들이 적절한 docker run 주문을 직접 만들도록합니다.

이 접근 방식은 일회성 관리 명령뿐만 아니라 pgweb 및 Celery Flower와 같은 보조 디버깅 및 내부 검사 서비스도 포함합니다 (개발 중에 실행하는 데 매우 편리하지만 일반적으로 추가 보안으로 인해 프로덕션 환경에서는 원하지 않을 것입니다). 그들이 생성하는 위협 표면 영역).

이러한 새로운 "서비스가 아님"의 의미를 정의하는 것도 훨씬 쉬워집니다. docker-compose build 과 같은 정규화되지 않은 명령을 제외하고는 services 와 _ 정확히 _ 동일합니다 (해당 형식에 대한 모든 향후 변경 포함). docker-compose build , docker-compose pull 및 docker-compose up 는 완전히 무시합니다. "서비스"가 아닌 "유틸리티"에 나열된 구성 요소를 처리하려면 구체적으로 이름을 지정해야합니다. 아마도이 될 수 --all 현재와 비슷한 옵션, docker-compose rm ). 그러나 이름으로 이러한 유틸리티와 상호 작용하는 CLI는 일반 서비스와 상호 작용하는 CLI와 동일하며 (추가 유틸리티 구성 파일을 지정해야하는 현상 유지와는 달리) docker-compose는 이름 충돌을 방지합니다. 서비스와 유틸리티 정의 사이.

# 2496의 확장 제안은 잠재적으로이 동작을 얻기 위해 (ab) 사용될 수 있지만 제대로 설계된 기능이 아닌 해결 방법처럼 느껴집니다.

나는 그 디자인, @ncoghlan을 좋아한다.

utilities 대신 .services 이름을 지정하는 것은 어떻습니까? 이것은 당연히 services 및 .services 가 정확히 동일한 의미를 사용한다는 것을 전달합니다. 유일한 차이점은 .services 가 기본적으로 실행되지 않는다는 것입니다. 기본적으로 표시되지 않는 파일 이름과 매우 유사합니다. 단점은 둘 사이의 차이가 약간 미묘하다는 것입니다.

@ncoghlan 이 거기에 대해 이야기하는 기본 아이디어가

1. _all_ unqualified 명령이 기본적으로 이러한 유틸리티를 무시해야한다는 데 동의하지 마십시오. 제 생각에는 컨테이너를 실행하는 명령을 제외한 모든 명령이 정상적으로 실행되어야합니다. (기본적으로 up 및 start .)
2. @dsem 의 코멘트에 관해서는 '.services'보다 '유틸리티'의 의미가 더 좋습니다. 나는 unixy 숨겨진 파일 추론을 이해하지만 이러한 것들은 단순히 숨겨진 서비스가 아니라 서비스 도우미입니다.

@bfirsh @ncoghlan 나는 완전히 @dnephin에 동의 :

이 문제에서 확인 된 문제를 실제로 해결한다고 생각하지 않습니다. 사람들은 이미지뿐만 아니라 컨테이너를 원합니다.

내가 원하는 워크 플로우에 필요한 것은 바로 여기에있는 대부분의 사람들에게 단순한 서비스입니다. 일반 서비스처럼 정의되고 일반 서비스처럼 시작 / 중지됩니다.
_only_ 차이점은 기본적으로 간단한 docker-compose up 의해 자동으로 시작되지 않고 명시 적으로 지정 (또는 종속성으로 끌어온 경우) 할 때만 시작된다는 것입니다.

따라서 새로운 최상위 섹션이나 이러한 일회성 컨테이너에 대한 완전히 새로운 개념이 필요하지는 않지만 선택적 서비스 구성 매개 변수 만 있습니다.
나는 이것을 개념 증명으로 내 pull request # 3047에서 구현했습니다. 아주 작은 변화이지만 내 사용 사례를 완전히 만족시킬 것입니다. 그래서 내가 할 수있는 일이 더 있으면 이것을 병합하기 위해 알려주세요 (=

이것을 테스트하려는 사람을 위해 컨테이너에서 docker-compose를 빌드하고 실행하는 명령은 다음과 같습니다.

# download and build
git clone [email protected]:acran/compose.git -b auto_up
cd compose
docker build -t docker-compose .

# create an example docker-compose.yml
cat > docker-compose.yml <<EOF
version: "2"
services:
  foo:
    image: busybox
    auto_up: false
    command: echo foo
  bar:
    image: busybox
    auto_up: false
    command: echo bar
    depends_on:
      - foo
  baz:
    image: busybox
    command: echo baz
EOF

# start all default services only, i.e. baz
docker run --rm -v /var/run/docker.sock:/var/run/docker.sock -ti -v $(pwd):$(pwd) -w $(pwd) docker-compose up

# start service foo only
docker run --rm -v /var/run/docker.sock:/var/run/docker.sock -ti -v $(pwd):$(pwd) -w $(pwd) docker-compose up foo

# start service bar, foo is pulled in as a dependeny
docker run --rm -v /var/run/docker.sock:/var/run/docker.sock -ti -v $(pwd):$(pwd) -w $(pwd) docker-compose up bar

# clean up all services, i.e. foo, bar and baz
docker run --rm -v /var/run/docker.sock:/var/run/docker.sock -ti -v $(pwd):$(pwd) -w $(pwd) docker-compose down

@acran , 관련 문서 및 테스트 사례를 업데이트하는 데 도움을 드리고자합니다. 괜찮습니까?

@ dattran-vn01 물론, 나는 행복 할 것입니다 : 스마일 :

귀하의 예제에서 @acran 은 현재 Compose와 다른 동작을 갖는 유일한 명령이며 해당 동작은 up baz 사용하여 수행 할 수 있습니다.
여러 Compose 파일을 사용하여 동일한 작업을 수행 할 수도 있습니다.

다른 기본 서비스 목록에서 일부 명령이 작동하는 것은 매우 혼란스러워 보이며이 기능이 마음에 들지 않는 이유 중 하나였습니다.

귀하의 예제에서 @acran 은 현재 Compose와 다른 동작을 갖는 유일한 명령이며 해당 동작은 up baz를 사용하여 수행 할 수 있습니다.
여러 Compose 파일을 사용하여 동일한 작업을 수행 할 수도 있습니다.

@dnephin 예, 정확히 알고 있습니다.이 예에서는 가장 쉬운 방법이 될 것입니다.
그러나 이것을 10 개의 서비스와 단 하나의 일회성 서비스 ( "init"또는 "backup"/ "dump"와 같은)로 상상해보십시오.이 경우 하나의 단일 서비스를 제외하고 명령 줄에 모든 서비스를 나열해야합니다. docker-compose up service1 service2 ... service10 와 같은 서비스 해제 (아래 참조). 특히 모든 서비스를 기억하고 docker-compose.yml 변경 사항을 수동으로 추적해야합니다.

또한 여러 YAML 파일을 사용할 수있는 가능성에 대해 알고 있습니다 . 위의 첫 번째 주석을 참조하십시오. 명령 줄에서 모든 서비스를 명시 적으로 제공하는 것뿐만 아니라 여기에 언급 된 대부분의 사용 사례를 다루고 있습니다. 그러나 그것은 사용하는 해결 방법처럼 느껴집니다.

문제를 시각화하는 또 다른 예 docker-compose.yml :

version: "2"
services:
  init:
    image: busybox
    auto_up: false
    command: echo "I do one-time initializing"
  service1:
    image: busybox
    command: echo "I'm service #1"
  service2:
    image: busybox
    command: echo "I'm service #2"
  service3:
    image: busybox
    command: echo "I'm service #3"
  service4:
    image: busybox
    command: echo "I'm service #4"
  service5:
    image: busybox
    command: echo "I'm service #5"
  service6:
    image: busybox
    command: echo "I'm service #6"
  service7:
    image: busybox
    command: echo "I'm service #7"
  service8:
    image: busybox
    command: echo "I'm service #8"
  service9:
    image: busybox
    command: echo "I'm service #9"
  service10:
    image: busybox
    command: echo "I'm service #10"

간단한 docker-compose up _with_ auto_up 속성은 init 서비스를 제외한 모든 서비스에서 시작됩니다. 없이 동일하게하려면 10 개의 서비스로 훨씬 더 긴 명령을 입력하거나 YAML 파일을 분할하고 여러 파일을 지정해야합니다.

따라서 여기에서 요청한 기능은 완전히 새로운 기능이 아니라 편리함과 cli에서 입력을 줄이는 것입니다.

"여러 구성 파일 사용"옵션 (실제로 현재 사용 가능한 가장 좋은 옵션)과 관련하여 사용성 문제는 실제로 다음과 같이 보인다는 것입니다.

$ docker-compose up one-shot-command
ERROR: No such service: one-shot-command
$ docker-compose up -f docker-compose.yml -f docker-compose-utils.yml one-shot-command
# Actually goes & does the requested thing

그러면 불일치가 프로젝트 문서 및 자동화의 _all_을 감염시킵니다. _two_ compose 파일을 유틸리티 명령을 실행하려는 모든 사람이 사용할 수 있는지 확인하고 유틸리티 파일의 명령에 대해 전체 호출이 제공되었는지 확인해야합니다. 또는 서비스가 "항상 실행"에서 "명시 적으로 요청 된 경우에만 실행"으로 강등 된 경우 구성 파일 이름을 제공하지 않는 호출을 찾아서 추가해야합니다.

이것이 모두 _doable_입니다. 작성 파일에서 "내가 명시 적으로 요청할 때만 실행하고 기본적으로 실행하지 마십시오"라고 말할 수있는 것에 비해 짜증이납니다.

누군가 저에게 이렇게 말했습니다. _ "여러 똑똑한 사람들이 어떤 접근 방식이 최선인지 결정할 수 없다면, 보통 둘 다 나쁘지 않습니다. 최악은 아무것도하지 않는 것입니다."_

이 카드는 이것의 대표적인 예처럼 보입니다 :)

이제 docker가 장기 실행 명령에 대해 기본적으로 서비스 개념을 지원한다는 점을 감안할 때 가장 좋은 방법은 다시 시작 정책을 제외하고는 허용되지 않는 서비스와 동일한 기능을 허용하는 명령이라는 새 섹션을 추가하는 것입니다.

내 설정에서 인프라 (nginx, 데이터베이스, 웹 서버, 메시지 대기열 ...)를 실행하는 데 필요한 docker-compose에 서비스가 있습니다. 또한 디버깅 이유 (예 : 데이터베이스 웹 GUI)에만 필요한 추가 서비스를 정의했습니다.

"디버깅"서비스가 자동으로 시작되지 않도록하고 싶지만 추가하고 싶다면 간단한 docker-compose up -d database-gui 만 있으면됩니다.

또한 : 가끔 마음이 바뀌고 이러한 서비스 중 하나가 항상 시작되기를 원합니다 ... => 옵션 2) 해당 플래그 하나만 변경할 수 있습니다.

=> 옵션 2에 투표하십시오. 간단하고 여기에있는 모든 사람의 요구 사항을 충족하는 것 같기 때문입니다. 다른 모든 솔루션은 저에게 과도한 엔지니어링처럼 느껴집니다. 실제적인 필요가 아닌 드물거나 상상 만하는 사용 사례를 기반으로 구성에 복잡성을 추가합니다.

내 +1을 추가하려면 여기에 있습니다. Django 앱에서 실행 중이며 Docker에서 실행할 때 셸 또는 테스트를 실행하거나 마이그레이션 명령을 실행하는 컨테이너가 있으면 좋을 것입니다. 하지만 앱을 시작할 때마다이 중 어떤 것도 실행하고 싶지 않습니다. 여러 구성 파일을 사용하면 작동하지만, 입력, 스크립팅 또는 마일 길이의 명령 줄 별칭 지정이 필요합니다. 내가 compose를 전혀 사용하지 않으려면 컨테이너를 셸 스크립트 (또는 python 스크립트 ... 컨테이너 구성을 저장하기 위해 통합 YAML 파일 추가 ... 잠깐 ...) 내 컨테이너에서 데이터베이스 마이그레이션을 실행하기 위해 docker-compose -f common.yml -f dev.yml -f local.yml -f commands.yml up migrate 과 같은 작업을 수행하고 싶지 않습니다. 대안은 /bin/true 를 명령으로 사용하고 docker-compose -f common.yml -f dev.yml -f local.yml up commands 'python3 manage.py migrate' 와 같은 작업을 수행하는 것입니다. 따라서 구성 어딘가에 한 번의 명령을 저장하면 매우 유용 할 것입니다. 옵션 2, 3 및 4 중 하나가 저에게 효과적입니다.

이 스레드의 피드백을 기반으로 부분적으로 작업해온 도구 인 dobi를 살펴볼 것을 제안하고 싶습니다.

compose는 "환경"을 형성하는 장기 실행 서비스를 시작하도록 설계되었습니다.
dobi는 순차 프로젝트 빌드 작업에 중점을 둡니다.

찾고있는 것 (셸 실행, 단위 테스트 실행, 마이그레이션 실행)은 모두 프로젝트 작업이므로 dobi 모델에 훨씬 더 적합합니다.

dobi와 compose는 함께 잘 작동하므로 compose 리소스를 사용하여 dobi에서 compose를 시작할 수 있습니다.

compose=dev-environment:
  files: [docker-compose.yml, local.yml]
  project: 'theprojectname'

다음을 사용하여 실행할 수 있습니다.

dobi dev-environment

여기에 작성 통합 및 db 마이그레이션 실행의 예가 있습니다. https://github.com/dnephin/dobi/tree/master/examples/init-db-with-rails

여러 워크 플로의 예 (테스트 실행, 대화 형 셸 시작, 최소 이미지 릴리스 및 빌드 포함)가 여기에 있습니다. http://dnephin.github.io/dobi/examples.html

2에 +1). 우리의 관점에서는 일회성 명령과 같은 흔하지 않은 사용 사례를 생각하고 논의 할 필요가 없지만, 생성되어 사용할 준비가되어 있지만 필요할 때 필요할 때 시작할 수있는 실제 서비스를 원합니다 (기본적으로는 사용하지 않음). 자원).

"흔하지 않은 사용 사례"? 데이터베이스 마이그레이션을 실행합니까? 단위 테스트를 실행합니까? 보푸라기를 실행합니까? 웹팩?

예, 나는 달리지 만 컨테이너 내부에서 달성하고 제어 할 수 있습니다. 그러나 나는 당신의 견해 나 요구를 훼손하고 싶지 않습니다.이 토론을 불꽃으로 만들지 마십시오. docker compose에 대한 우리의 요구 사항이 반드시 충돌하는 것은 아닙니다.

mysql 컨테이너에서 데이터베이스를 지우고 다운로드 한 덤프에서 스키마를 다시로드하는 스크립트에 대한 docker-compose 컨테이너를 만드는 방법을 찾으려고이 스레드를 발견했습니다. 매우 길고 파괴적인 프로세스이므로 서비스를 불러올 때마다 실행되는 것을 원하지는 않지만 자체 dockerfile을 사용하여 구성된 컨테이너 집합 내에서 실행해야합니다.

작업, 명령 등 무엇이든 부르지 만 나는 그것 없이는 좀 SOL입니다.

나는 다른 것을 찾고있는 것을 우연히 발견했고, 단지 사용 사례를 만들고 싶었다. 우리는 우리 개발자들이 그들의 서비스에서 어떤 데이터를 백업해야 하는지를 가장 잘 정의 할 수 있다는 것을 발견했다. docker-compose.yml 파일이 손에 있고 이름이 지정된 볼륨이 사용 되었기 때문에 백업 전략을 정의하는 데 사용하기로 결정했습니다. 다음은 우리가 사용하던 이전 docker-compose.yml의 요약 된 예입니다.

version: '2'
services:
  gitlab:
    image: gitlab/gitlab-ce:latest
    restart: always
    ports:
      - "5555:5555"
    volumes:
      - gitlab_config:/etc/gitlab
      - gitlab_logs:/var/log/gitlab
      - gitlab_data:/var/opt/gitlab
      - certificates:/etc/gitlab/ssl
      - registry_data:/var/opt/gitlab/gitlab-rails/shared/registry
  gitlab-runner:
    image: gitlab/gitlab-runner:latest
    restart: always
    volumes:
      - certificates:/etc/gitlab-runner/certs
      - /var/run/docker.sock:/var/run/docker.sock
volumes:
    gitlab_config:
      driver: local
    gitlab_logs:
      driver: local
    gitlab_data:
      driver: local
    certificates:
      driver: local
    registry_data:
      driver: local

볼륨 데이터를 백업 할 수 있으려면 busybox 컨테이너를 사용하여 필요한 데이터를 타르하기로 결정했지만 유연해야하고 개발자가 백업하려는 볼륨 만 수행해야합니다. 마지막으로 모든 볼륨을 개별적으로 백업 할 수 있어야합니다. 이를 위해 모든 docker-compose.yml에 3 개의 서비스를 추가했습니다.

  boot:
    image: busybox
    depends_on:
      - gitlab
      - gitlab-runner

  backup:
    image: busybox
    volumes:
      - gitlab_config:/data/gitlab_config
      - gitlab_data:/data/gitlab_data
      - registry_data:/data/gitlab_data
      - /backups/latest:/backup
    command: find . -type d -maxdepth 1 -mindepth 1 -exec tar cvf /backup/{}.tar {}  \;
    working_dir: /backup

  restore:
    image: busybox
    volumes:
      - gitlab_config:/data/gitlab_config
      - gitlab_data:/data/gitlab_data
      - registry_data:/data/gitlab_data
      - /backups/latest:/backup
    command: find . -type f -iname "*.tar" -maxdepth 1 -mindepth 1 -exec tar xvf {} \;
    working_dir: /backup

백업 및 복원 서비스는 볼륨을 사용하여 구성하기 만하면됩니다. 나머지는 명령으로 수행됩니다. 백업 또는 복원 할 볼륨을 선택할 수 있도록 약간의 구성을 추가 할 계획이지만 지금은 모든 작업을 수행합니다.이 두 서비스가 모든 docker-compose에서 시작되는 것을 원하지 않기 때문에 up 명령을 사용하려면 원하는 모든 서비스를 지정해야했습니다. 지루할 수 있습니다 ... 그래서 boot라는 더미 서비스를 추가했습니다. 실행해야하는 모든 서비스에 따라 다릅니다. 도커 구성.

여기에는 작은 해킹으로 가득 차 있지만 docker-compose up backup 를 쉽게 실행하여 호스트의 / backups / latest에 백업을 저장하고 거기에서 버전 관리 / 정리 논리를 실행할 수 있습니다.

비슷한 것을 달성하려는 사람에게 도움이되기를 바랍니다.하지만 결국 docker-compose에게 두 서비스를 부팅하지 말라고 말할 수 있기 때문에 세 번째 서비스가 필요하지 않고 docker-compose가 복잡해집니다. 명령.

개발 중에는 현재 4 개의 docker-compose 파일이 있습니다.

• docker-compose.yml : redis, MySQL, php-fpm, Laravel 큐 프로세서, nginx, Solr 등 앱을 완전히 운영하는 데 필요한 핵심 서비스를 정의합니다.
• docker-compose-utils.yml : 일반적으로 위의 서비스와 함께 실행되는 gulp, npm, artisan (Laravel), composer, redis-cli와 같은 개발 작업을 실행하는 데 필요한 유틸리티 서비스를 정의합니다.
• 위의 서비스에 대한 환경과 볼륨을 정의하기위한 2 개의 추가 도커 구성 파일

이 설정은 Docker 외부에서 개발 환경에 대한 최소한의 종속성이 있기 때문에 잘 작동합니다. 단점은 간단한 유틸리티를 실행하는 데 필요한 모든 .yml 파일을 지정하는 데 필요한 다루기 힘든 명령 줄입니다.

우리는 macOS, Windows 및 Linux에서 개발합니다. 또한 많은 개발 작업에는 일종의 매개 변수화 (예 : DB 마이그레이션 생성, 자체 인수를 사용하여 composer / artisan / npm 명령 실행)가 필요하므로 schmich/runx 를 제로 설치 교차로 생성했습니다. 플랫폼 태스크 러너를 사용하여 공통 개발 태스크를 묶습니다.

예를 들어 runx migrate : make create_some_table 을 사용하여 docker-compose -f docker-compose.yml -f docker-compose-utils.yml -f docker-compose-dev.yml -f docker-compose-utils-dev.yml run --rm artisan migrate:make create_some_table 를 효과적으로 실행하거나 runx npm older 를 사용하여 오래된 JS 종속성을 볼 수 있습니다.

위에서 언급 한 dobi 사용하지 않았지만 runx 은 (는) Docker 환경에 덜 적합하지만 정신적으로 비슷하게 느껴집니다. 궁극적으로 필자는 서비스 자체와 개발에 필요한 유틸리티 스크립트를 제외하고 모든 곳에서 종속성을 피하고 싶습니다.

어떤 소식이라도? 이 기능이 있으면 정말 좋을 것 같아요! 실행해야 할 서비스를 지정할 수있는 default 와 같은 최상위 구성의 솔루션에 투표합니다.
boot 더미 서비스는 좋지만 프로세스를 포 그라운드에 두는 것을 선호하므로이 작업을 마치면 터미널을 닫아 모든 것을 중단 할 수 있습니다. 기본적으로 출력을 첨부하는 것도 좋으며 더미 서비스에서는 발생하지 않습니다.

noboby가 .env 파일을 사용하여 사용 사례에 대해 주석을 달았으므로 다음은 내 것입니다.

4 개의 compose 파일이 있습니다 : docker-compose.yml, docker-compose.local.yml, docker-compose.prod.yml 및 docker-compose.ci.yml. 각 환경마다 다른 .env가 있습니다.

CI .env:
COMPOSE_PROJECT_NAME=foo
COMPOSE_FILE=docker-compose.yml:docker-compose.ci.yml
WEB_PORT=8081
...

Test/dev/etc .env:
COMPOSE_PROJECT_NAME=foo
COMPOSE_FILE=docker-compose.yml:docker-compose.local.yml
WEB_PORT=80
...

등등...

사용자 및 / 또는 스크립트는 환경이 이미 개별적으로 구성되어 있으므로 사용할 작성 파일에 대해 걱정할 필요가 없습니다.

하지만 결국 실행할 유지 관리 인스턴스가 있습니다. 기본 docker-compose.yml 내에서 구성 할 수 없으며 한 가지 해결책은 docker-compose.worker.yml을 만들고 변경되는 3 개의 "-f"옵션으로 명령 줄을 실행하는 것입니다. 각 환경에. 사용 가능한 옵션이되기 쉬운 오류입니다.

내가 찾은 해결책은 "worker"디렉토리를 만들고 거기에 yml 파일을 넣고 상위 .env 파일을이 디렉토리에 연결하고 빈 docker-compose. [ci | local | prod] .yml 파일을 만드는 것입니다 (그렇지 않으면 COMPOSE_FILE 변수 값 변경).

이것은 잘 작동하지만 최적이 아닙니다. OP의 다른 솔루션은 엉망이되지 않고 이것을 해결할 것입니다.

여기에있는 논의, 많은 예제 사용 사례 및 열린이 문제에 대해 자주 중복되는 문제가 있다는 사실은 "기본적으로 시작되지 않는 서비스 정의"에 대한 가능성에 대한 많은 사용자의 실제 요구가 있음을 분명히 보여줍니다. ".

따라서 저는 여기서 논의를 _if_ 더 많이 구현해야하는 경우에서 _ 어떻게 구현해야 하는지를 _로 옮기고 싶습니다. 우리 모두 동의 할 수 있을까요 ?

_how_에 관련하여이 얻을 수있는 @bfirsh는 오프닝 코멘트에 몇 가지 옵션을 나열 :

1) 사용자에게 별도의 Compose 파일 사용 권장

이 사용 사례에 현재 사용 가능한 유일한 솔루션입니다. 그러나 위에서 언급했듯이 긴 명령 줄을 수동으로 입력하고 실행할 명령에 포함 할 Compose 파일을 기억해야하기 때문에이 경우에는 더 많은 해결 방법이 있습니다.
물론 CI 설정 또는 프로덕션에 대한 자동화 된 배포에서는 명령 줄을 한 번만 정의하면되고 수동으로 입력 할 수 없으므로 이는 문제가되지 않습니다. 따라서 이것은 오로지 Compose 자체의 주요 사용 사례 중 하나 인 docker-compose 매뉴얼 에 따라 자동화되지 않은 환경, 즉 개발에서의 편의에 관한 것입니다.

이러한 기능은 개발자가 프로젝트를 시작할 수있는 편리한 방법을 제공합니다. Compose는 여러 페이지의 "개발자 시작 안내서"를 단일 컴퓨터에서 읽을 수있는 Compose 파일과 몇 가지 명령으로 줄일 수 있습니다.

로컬 설정을 초기화하기 위해 docker-compose -f docker-compose.yml -f docker-compose-utils.yml run init 와 같은 것을 입력해야하는 것은 _ 편리함 _이 아니라 _ ​​여러 페이지의 "개발자 시작 가이드"_에서 찾을 수있는 것과 비슷합니다.

여기에서 옵션 1b)를 고려하십시오.

사용자가 별도의 Compose 파일을 사용하기 위해 래퍼 스크립트 / 도구를 사용하도록 권장합니다.

이를 위해 추가 도구 및 종속성을 가져와야한다면 왜 처음에 docker-compose 를 사용합니까? docker-compose 는 모든 작업은 이론적으로 사용자 지정 셸 스크립트와 기본 docker 클라이언트로 직접 수행 할 수도 있습니다.
표준화 된 사용자 인터페이스에서 docker-compose 의 주요 이점을 확인합니다 (프로젝트를 복제하고 여기에서 docker-compose.yml docker-compose up 를 확인하고 시작하려면

2) 기본적으로 시작되지 않도록 서비스에 옵션 추가
3) 기본 서비스 정의를위한 최상위 구성 옵션 추가

이 두 옵션은 기본적으로 동일합니다. 하나의 compose 파일에서 기본적으로 시작되어야하는 서비스를 정의
대부분의 경우 단일 작성 파일에 "일회성 서비스"보다 기본 서비스가 더 많다는 점을 고려하면 다른 모든 서비스를 화이트리스트에 추가하고 기본 서비스가 가져올 때마다 화이트리스트를 업데이트해야하는 것보다 한 서비스를 블랙리스트에 추가하는 것이 더 쉽습니다. 추가 또는 제거. 또한 옵션 2)를 사용하면 여러 작성 파일을 병합하는 것이 더 쉬울 것입니다.

4) 서비스와 같은 개념을 추가하되 일회성 명령 ( "스크립트", "작업"등)을위한 것입니다.

옵션 4)는 옵션 2) 또는 3)의 전문 화일 뿐이라고 생각합니다. 위의 대부분의 예에서 원하는 일회성 컨테이너는 기본적으로 다른 서비스와 마찬가지로 정의되고 일반 서비스처럼 더 많거나 적은 작업을 수행하지 않습니다. 기본적으로 시작되지 않습니다. (또는 "서비스"에 대한 중요한 차이점을 놓쳤습니까?).

그래서 제 생각에는 옵션 2)가 여기에서 가장 좋은 선택입니다. 왜냐하면 최소한의 변경이 필요하지만 동시에 여기에 언급 된 대부분의 (또는 전부?) 사용 사례를 만족시킬만큼 유연하고 동시에 사용하기 매우 편리하기 때문입니다.
그럼에도 불구하고 옵션 3) 또는 4)와 같은 항목이 업스트림으로 병합되는 것을 보게되어 기쁩니다. 그래서 여기에서 1 년 넘게 논의한 후, 언제 또는 일어날 지에 대한 일정이 있습니까 ??

나는 옵션 2가 아마도 가장 덜 침습적이라는 데 동의합니다. 옵션 4가 제공 할 수있는 유일한 기능은 기존 컨테이너에서 명령을 실행하는 기능입니다 (도커 실행 메커니즘 사용). 예를 들어 내가 원하는 것이 데이터베이스 마이그레이션이나 단위 테스트를 실행하는 것뿐이라면 내 앱을 실행하는 컨테이너가 이미 있으면 별도의 전체 컨테이너를 만들 이유가 없을 수 있습니다. 즉, 컨테이너는 가볍고 옵션 2에 완벽하게 만족할 것입니다.

@MadWombat 옵션 4에 대해서도 같은 느낌이

@mathroc 저는 docker exec를 사용하여 옵션 4를 언급했습니다. @acran 이 옵션 2와 4 사이에 중요한 차이점이 있는지 물었 기 때문입니다. 목적을 위해 다른 유사한 컨테이너를 가져 오는 대신 기존 컨테이너. 일부 서비스 또는 기존 컨테이너에서 이미 사용중인 다른 제한된 리소스에 대한 제한된 영구 연결이있는 시나리오가있을 수 있지만 하나는 생각할 수 없습니다.

옵션 4가 제공 할 수있는 유일한 기능은 기존 컨테이너에서 명령을 실행하는 기능입니다 (도커 실행 메커니즘 사용).

이는 서비스와 다른 새로운 최상위 개념을 도입하는 것을 정당화하고 요구하는 새로운 사용 사례입니다. 그러나 이미 존재하는 서비스 컨테이너 내에서 docker exec 를 통해 명령을 실행할 필요가없는 한 기존 서비스 개념만으로도 충분합니다.

그러나 목적을 위해 다른 유사한 컨테이너를 가져 오는 대신 기존 컨테이너에서 명령을 실행하려는 실제 사용 사례를 생각 해낼 수는 없습니다.

내가 생각할 수있는 가장 가까운 경우는 컨테이너 내의 구성 파일을 변경하고 애플리케이션에 의해 다시로드를 트리거하는 것과 같은 것입니다. # 4096의 @mathroc 예제 사용 :

version: "2"
services:
  my_service:
    image: my/service
shortcuts:
  start-debugging:
    service: my_service
    command: echo "debug=true" > /etc/myapp/conf.d/debug.conf && mydaemon --reload-config
  stop-debugging:
    service: my_service
    command: echo "debug=false" > /etc/myapp/conf.d/debug.conf && mydaemon --reload-config

이 문제와 관련이 있지만 # 4096에는 자체 유스 케이스가 있으며 옵션 4)를 가장 잘 이동할 수 있습니까?

1 년이 넘는 시간이 지났고 우리는 더 이상 결정을 내리지 못하는 것 같습니다. @bfirsh 는 스타일을 선택하고 함께 가야합니다.

+1

+1하면 매우 유용한 기능이 될 것입니다.

그리고 auto-start: false 또는 enabled: false 와 같은 옵션 2에 대한 또 다른 +1.

내 사용 사례는 서비스를 확장하는 것입니다. depends_on 설정된 서비스는 확장 할 수 없으므로 서비스 템플릿을 정의한 다음 여기에서 여러 서비스를 확장하는 것이 좋습니다. 분명히 템플릿은 빌드해야하지만 자동으로 실행해서는 안됩니다.

나만의 솔루션을 만들었고 무료로 사용할 수 있습니다.
아직 베타 버전입니다. :)

https://github.com/jonathanborges/picles-docker

여기에 많은 훌륭한 옵션이 있습니다. 기능에 대한 필요성은 현실입니다.

옵션 2가 분명히 더 인기가 있습니다.

1-> 4
2-> 52
3-> 3
4-> 10

옵션 2에 대한 또 다른 👍

초기 진입 점이나 단순히 반환하는 명령을 사용하여 "도구"서비스에서이 작업을 상당히 쉽게 처리 할 수 ​​있습니다. 그런 다음이 서비스를 대체 명령으로 실행하여 원하는 작업을 수행합니다 (예 : 테스트 또는 데이터 시드). 예

docker-compuse up -d
docker-compose run tools tests

예, 도구 서비스는 docker-compose ps 에서 "중지됨"으로 표시됩니다. 이것이 받아 들일 수 없다면 https://github.com/docker/compose/pull/2051 의 다중 파일 옵션이 작동합니다. 예

docker-compose -f docker-compose.yml -f docker-compose-tools.yml up -d
docker-compose -f docker-compose-tools.yml logs -f tools

많은 오케스트레이션 도우미가 이러한 요구를 위해 작성되고있는 것처럼 보이지만 나는 그 중 하나에 대해서도 작업을하고 있습니다. :).

개인적으로 저는 충분한 해결 방법이 있다고 생각합니다 (위의 두 가지, 진입 점 / 컨테이너로 창의력을 발휘하고 / 또는 셸 별칭 / 도우미와 함께 다중 파일 접근 방식 사용). 작성은 간단하게 유지할 수 있습니다.

@briceburg 는 위 의 논의를 참조하십시오. 여기서 문제는 다른 방법으로 수행 할 수없는 누락 된 기능에 관한 것이 아닙니다. 여기 사람들이 달성하고자하는 거의 모든 것에 대한 해결 방법이 있습니다. 그러나 그들은 docker-compose의 일반적인 사용 사례 대신 해결 방법과 더러운 해킹입니다.

편의성에 관한 것입니다. cli에 직접 docker-compose -f docker-compose.yml -f docker-compose-tools.yml up 를 입력하지 않아도되며, docker-compose run tools tests 인지 docker-compose run utils tests 인지 기억할 필요가 없습니다. _ 여러 페이지로 구성된 "개발자 시작 안내서"_ 대신 개발자를위한 통합되고 간단한 인터페이스가 있습니다.

이 문제에 _any_ 피드백을 제공하시기 바랍니다 수 : 다시, @dnephin, @bfirsh을 CCing? docker-compose 에 대한 향후 로드맵에서 이와 같은 내용을 볼 수 있다는 희망이 있습니까?

간단한 환경의 경우 @briceburg 는 해결 방법이 허용 될 수 있지만 때로는 그렇지 않습니다. 내 설정을보십시오.

rancher<strong i="7">@rancher</strong>:~/servers/sgi/docker$ ls -l 
total 64
-rwxrwxr-x 1 rancher rancher  303 Dec  8 20:05 cleanup.sh
drwxrwxr-x 3 rancher rancher 4096 Dec 16 15:26 conf
drwxrwxrwx 4 rancher rancher 4096 Dec 15 20:03 data
-rw-rw-r-- 1 rancher rancher   94 Dec 14 19:40 docker-compose.amt.yml
-rw-rw-r-- 1 rancher rancher  295 Dec  8 20:05 docker-compose.auth.yml
-rw-rw-r-- 1 rancher rancher  332 Dec  8 20:05 docker-compose.ci.yml
-rw-rw-r-- 1 rancher rancher  112 Dec  8 20:05 docker-compose.dbext.yml
-rw-rw-r-- 1 rancher rancher  347 Dec 14 19:40 docker-compose.dbint.yml
-rw-rw-r-- 1 rancher rancher  688 Dec 15 16:31 docker-compose.full.yml
-rw-rw-r-- 1 rancher rancher   81 Dec  8 20:05 docker-compose.local.yml
-rw-rw-r-- 1 rancher rancher  288 Dec 15 16:31 docker-compose.yml
-rwxrwxr-x 1 rancher rancher  721 Dec 14 19:40 redeploy.sh
-rwxrwxr-x 1 rancher rancher  861 Dec  8 20:05 setup.sh
-rwxrwxr-x 1 rancher rancher   66 Dec  8 20:05 shutdown.sh
-rwxrwxr-x 1 rancher rancher  269 Dec 14 19:40 startup.sh
drwxrwxr-x 2 rancher rancher 4096 Dec 14 19:40 worker

'기본적으로 시작하지 않음'컨테이너를 구성하는 worker 디렉터리에있는 파일 외에 8 개의 compose 파일 (여러 조합으로 사용)이 있습니다. worker 디렉터리 (부모에 연결된 .env 파일과 부모의 .env COMPOSE_FILE 변수를 준수하기 위해 비어있는 compose 파일 포함)는 제 해결 방법이지만, 이에 대한 해결책이 있으면 제 삶이 훨씬 쉬워 질 것입니다. 이 문제.

@vipseixas 파일 목록에서이 솔루션의 온전함을 측정하는 것은 어렵습니다. 예, 서비스를 자동 시작하지 않는 기능이 있다는 데 동의합니다. 자동 시작을 선호하지 _ 않는 _ 서비스에 대해 아무것도하지 않는 기본 진입 점 / 명령을 사용하는 것이 좋습니다. 예를 들어 컨테이너는 기본적으로 단순히 종료되며 후속 docker-compose 실행을 통해 대체 명령으로 해당 서비스를 실행합니다.

대부분의 경우 테스트를 실행하기 전에 종속 서비스 / 컨테이너에 대한 상태 검사가 통과하는지 확인하고 싶을 것입니다. 예를 들어, 이러한 테스트가 실행되기 전에 jenkins가 작동 중이고 실행 중입니다 (: 8080 등의 연결 허용). 과거에는 이것을 위해 dockerize를 사용했습니다.

내가 은색 총알을 제안한다면 환경 변수 (예 : DOCKER_COMPOSE_PROFILE = "tests")를 통해 작성 프로필을 설정하고 서비스가 프로필에 종속되도록 허용하는 것입니다. 여기서 모든 서비스는 기본적으로 "기본값"으로 설정됩니다. "프로필 또는 무엇이든. 또한 다른 서비스에 의존하는 서비스도 해당 서비스의 HEALTHCHECK에 _ 종속 _되도록 할 것입니다. 그래서 뭔가

app:
  image: myapp:v1

tests:
  image: myapp:tests
  dependencies:
    - profile: "tests"
    - service: "app"
      healthcheck: true

# run the things
docker-compose up -d

# test the things
DOCKER_COMPOSE_PROFILE="tests" docker-compose up -d
DOCKER_COMPOSE_PROFILE="tests" docker-compose logs -f

옵션 2의 경우 +1.

여기 많은 사람들이 흥미로운 새로운 기능을 제안했지만 여기서 문제의 핵심은 무엇입니까? 가능한 한 간단하게 유지하기 위해 투표합니다.

현재 상태에서 우리는 docker-compose.yml의 모든 서비스가 docker-compose up 에서 가져올 것이라고 가정합니다. 우리는 모두 자체 커스텀 부트 스트랩 스크립트, 메이크 파일, 빌드 도구 등으로 작업하고 있으며 다행히도 도커 구성 및 도커 모두 주방 싱크가 '업'되면 개별 컨테이너 관리를위한 광범위한 API를 노출합니다.

제가이 논의를하게 된 유일한 필요는 제가 정의한 서비스 중 하나가 어떤 이유로 든 기본적으로 '업'하려는 것이 아님을 지정하는 것입니다.

우리 모두를 위해 "완성"할 수있는 가장 간단한 기능은 무엇입니까? 서비스가 autostart: false 지정할 수있는 docker-compose.yml 사양 ( @bfirsh 원래 아이디어 2 번)에 대한 작은 업데이트입니다.

나는 "그냥 우리를 위해 뭔가를 해줘, 감사합니다."에 투표합니다. 우리는 투표합니다. 이제 최소한 하나의 답변이 필요합니다. 4 하나님!

우리 모두를 위해 "완성"할 수있는 가장 간단한 기능은 무엇입니까? 서비스가 autostart : false를 지정할 수있는 docker-compose.yml 사양 ( @bfirsh 원래 아이디어 번호 2)에 대한 작은 업데이트입니다.

다른 대안보다 훨씬 좋습니다. :)

너무 간단합니다.
scale: 0
https://github.com/docker/compose/issues/1661

@ drew-r 뭐?

@ jonathanborges1542 docker-compose scale servname=2 입니다. docker-compose.yml 파일에는 이에 상응하는 항목이 없습니다.

@ drew-r scale: 0 현재 docker 데몬에게 SIGTERM / SIGKILL을 서비스의 모든 컨테이너로 보내도록 지시합니다. 이렇게하면 아직 작업을 완료하지 않은 경우에도 유지 관리 작업이 종료됩니다. 이것이 예상되는 동작입니다. 이것을 변경하는 것은 지금 당장 명확한 행동을 과부하시키는 나쁜 경우가 될 것입니다.

@gittycat 이해합니다.하지만 여기서 원하는 것은 "docker-compose up"을 입력하는 것입니다. 그러면 모든 것이 준비됩니다. 그런 경우에는 작동하지 않습니다.

나는 1 년 넘게이 주제를 따라왔다 (대부분의 포스트는 도커쪽에있다).
나는 "서비스", "볼륨"및 "네트워크"와 함께 사는 새로운 최상위 "직업"이 최선의 선택이라고 믿습니다. 위 OP 목록의 옵션 4입니다.
Docker 리포지토리에 대한 제안이기도합니다.
https://github.com/docker/docker/issues/23880

@briceburg

파일 목록에서이 솔루션의 온 전성을 측정하기는 어렵습니다.

의도는 내가 많은 파일 조합을 가지고 있고 여러 개의 "-f"옵션을 사용하는 것이 수동으로 수행하기에는 너무 오류가 발생하기 쉽다는 것을 보여주기위한 것이 었습니다.

자동 시작을 원하지 않는 서비스에 대해 아무것도 수행하지 않는 기본 진입 점 / 명령을 사용하는 것이 좋습니다.

때로는 파멸에서 벗어날 수 없습니다. 그러나 나는 내 해결책을 선호한다. 나는 결코 "구성"되지 않을 다른 디렉토리를 사용하므로 내 환경을 오염시키는 쓸데없는 중지 된 컨테이너가 없을 것이다. 그래서 부모 ".env"에 연결된 ".env"가있는 작업자 디렉터리가 있습니다.

내가 은색 총알을 제안한다면 환경 변수 (예 : DOCKER_COMPOSE_PROFILE = "tests")를 통해 작성 프로필을 설정할 수 있습니다.

그것이 최선의 해결책이 될 것입니다. 하지만 저는 개발자들이 복잡성을 증가시키는 경향이 없다고 생각합니다.

동일한 docker-compose.yml에서 기본 이미지를 "확장"하고 두 번째 이미지 만 시작하려고합니다. 현재 한 단계에서는 수행 할 수 없습니다. 옵션 2를 사용하면 가능하지만 기본 이미지 생성이 완료되는 "빌드 단계"및 "실행 단계"를 갖는 것이 더 좋고 깔끔한 방법 일 수 있습니다. 지금은 하나가 아닌 2 개의 명령을 실행해야합니다.

+1 @ drew-r # 1661

이 문제는 어느 시점에서 구현 될 것인가 아니면 단지 개발자가하고 싶지 않은 일인가? 커뮤니티가 다른 솔루션을 찾을 수 있도록 알아두면 좋을 것입니다.

그건 그렇고 나는 옵션 2에 투표합니다.

감사합니다

옵션 2의 경우 +1.
그래도 명시 적 종속성을 존중할까요 ... links 등?

docker-compose up [service] 로 가져올 서비스를 지정하는 경우 해당 서비스 이외의 서비스를 시작하고 싶은 경우는 드뭅니다.

옵션 2에 대한 또 다른 투표입니다. @acran 이 생성하기에 충분히 친절하다는 PR (https://github.com/docker/compose/pull/3047)도 있으므로 작성 개발자의 노력은 상당히 적어야합니다. 검토 만하면되고 (매우 짧고 간단합니다) 코드를 작성하지 않아도됩니다.

작성 개발자가이 작업을 원하지 않는 경우 한 번에 한 번만 언급 한 다음 티켓을 닫고 댓글을 막기 위해 잠 가야합니다.

@msabramo compose는 기본적으로 도커 엔진 수준에서 결정된 것에 의해

요청은 Docker 엔진 저장소 https://github.com/docker/docker/issues/23880 에서 추적됩니다.
그것이 결정 / 작업이 시작되는 곳입니다.

이 문제를 종결 할 것을 제안합니다.

@gittycat compose는 엔진에게 서비스를 시작하도록 지시할지 여부를 선택할 수 있습니다. 이것은 여전히 ​​매우 유효한 요청입니다.

나는 프로덕션에서 도커를 포기하고 많은 문제가 있습니다. 그런 다음 방랑자로 이동합니다.

2에 대한 또 다른 투표

2와 4에 대한 또 다른 투표.

사용 사례를 지적하기 위해 일부 서비스에는 순환 종속성, 구성 파일 생성, 기타 여러 가능성 중에서 테스트 스위트 실행이 필요합니다. Docker에서 분리하거나 다른 도구를 사용할 수 있지만 프로젝트 설정에 불필요한 복잡성이 추가됩니다.

설정 및 / 또는 테스트를위한 간단한 명령 만 있으면 상황이 훨씬 더 깔끔해집니다.

2에 대한 또 다른 투표!

이 스레드를 읽었지만 새 게시물 (https://github.com/docker/compose/issues/4650)을 작성하기로 결정했으며,이 게시물은 닫히고 여기에서 참조되었습니다. 제가 말하고 싶었던 요점은이 스레드의 대부분의 논의는 실행중인 컨테이너를 비활성화하는 플래그에 관한 것이지만 제 사용 사례는 컨테이너 생성이라는 세 번째 상태입니다.

컨테이너가 실행되는 것을 방지 할뿐만 아니라 처음에는 컨테이너를 만들 수 없도록하고 싶습니다 (사용 사례에서는이를 수행하는 사용자 중심 프로세스가 있습니다).

@ekkis 나는 그것이 어떻게

문제에 대해 자세히 설명해 주시겠습니까?

@frnco , 더 자세히 알고 싶은 내용을 이해하지 못했습니다. 컨테이너를 만들지 않고 이미지를 빌드하려는 경우가 있습니다. 내 것이 그러한 경우입니다. 다른 이미지와 함께 특정 이미지를 만들고 싶지만이 특정 이미지는 내가 작성한 프로세스에서 사용될 것입니다. build-only 대한 플래그를 만들고 빌드하는 데 두 개의 별도 프로세스를 갖고 싶지 않습니다.

@ekkis 나는 당신이 찾고있는 것과 관련이있는 # 963을 살펴볼 것을 제안합니다.

옵션 2의 경우 +1

옵션 2의 경우 +1

옵션 2의 경우 +1

옵션 2의 경우 +1

옵션 2의 경우 +1

옵션 2의 경우 +1

: +1 :이 기능에 대한 예상치에 대한 질문이있는 옵션 # 2의 경우? 가장 좋은 해결 방법은 무엇입니까? 다음과 같은 모든 서비스를 나열해야한다고 상상할 수 있습니다.

docker-compose up service1 service2 service3

... 기본적으로 시작하고 싶지 않은 항목은 생략합니다.

오픈 소스 커뮤니티에서 많이 요청 된이 기능을 기여할 수있는 방법이 있습니까?

옵션 2의 경우 +1.
'스테이지'를 지정하는 방법이 좋습니다. 서비스가 프로덕션에서만 실행됩니다.

옵션 2의 경우 +1.

옵션 2에 투표

up 명령 필터링이 완벽합니다 – docker-compose up service1 service3

: +1 : 옵션 2 및 4 용

이 시점에서 분명한 옵션 2는 사용자가 원하는 것입니다. 이를 실현하기위한 다음 단계는 무엇입니까?

옵션 2의 +1을 위해이 기능이 이미 존재하기를 바라면서이 문제가 발생했습니다.

옵션 2에 +1

... 옵션 2에 대해 하나 더 +1

옵션 2의 경우 +1

옵션 2의 경우 +1 :-)

옵션 2 및 4의 경우 +1

안녕하세요,
+1 옵션 2

IMHO, 옵션은 마이크로 서비스 또는 육각형 아키텍처를 기반으로하는 애플리케이션이있는 경우 로컬 환경에서 매우 유용합니다. 개발자로서 가장 가까운 작업에 필요한 요소 만 실행할 수 있습니다.

옵션 2는 대부분의 사용자가 원하는 것입니다. 이것에 관한 결정이 아직 내려 지거나 개발이 시작되어 다른 곳에서 추적되고 있습니까?

몇 달 안에 대학을 마치고 더 많은 시간을 가지면이 기능을 혼자서 구현하는 것이 훨씬 빠를 것이라고 생각합니다. 2 년 동안 엄청난 양의 투표와 요청이 있었으며 앞으로도 한 걸음 더 나아가 자체 구현이 향후 5 년 동안 해결책이 될 것 같습니다 (해당 기능이 공식적으로 구현 될 때까지).

물론 옵션 2의 경우 +1000

+1 옵션 2

옵션 2에 투표하면 차이가 있습니까? '그럴 것 같지 않습니다.

여기에있는 댓글은 최근 무섭게되었고 새로운 피드백이 실제로 나타나지 않았기 때문에이 스레드를 잠그는 것이 좋습니다. 여기서 교류 할 때는 예의 바르게 행동하십시오.

이것은 이 문제에 메인테이너 팀의 현재, 공식 입장이다. 편의 옵션으로이 기능을 추가 할 것인지 비슷한 기능을 추가 할 것인지는 아직 고려 중이지만 강조된 이유와 이에 더 적합한 다른 도구가 존재하기 때문에 우선 순위가 아닙니다.

@ shin- 우리가 이것을 잠그기 전에 커뮤니티가 개발 의지인지 명확하게 알 수 있으므로 핵심 팀이 팀의 표준을 충족하면 병합 할 수 있습니까? 스레드에는이를 완료하려는 구현 및 커뮤니티 구성원이 있으며, 투자 낭비가 아니라는 확인을 찾고있었습니다. 피드백을받을 수 있다면 스레드를 추적하여이를 클로저로 이동할 수 있는지 확인합니다.

@jimzucker 아니오-여기서 문제는 구현이 아니기 때문입니다. 이 기본 구현은 일반 개발자에게 반나절이 걸립니다. 여기서 우리가 염려하는 것은 근본적인 디자인 문제입니다.

1. 서비스 란? 설계 상 서비스는 애플리케이션을 형성하기 위해 다른 서비스와 상호 작용하는 명확하게 정의 된 장기 실행 프로세스입니다. 이것이 Compose가 작동하는 기본 가정이며 우리가 구현하는 모든 기능은 아니지만 대부분의 설계를 안내합니다.
2. 이 정의에 따르면 "기본적으로 시작되지 않는 서비스"는 실제로 서비스가 아닙니다 [1]. 이는 컨테이너에서 실행되고 응용 프로그램의 일부가 아니라 응용 프로그램에서 작동 하는 미리 정의 된 작업에
3. 따라서 서비스라고 부르는 것은 잘못된 것입니다 (기본적으로 설계 상). 이 시점에서 Compose 파일에 새로운 유형의 정의를 만드는 것을 고려해야합니다 (간결성을 위해 "작업"이라고 부르겠습니다. 여기서 정확한 용어는 중요하지 않습니다).
4. 태스크는 본질적으로 단기 실행 프로세스이므로 서비스와 비교하여 다른 옵션 세트를 사용합니다. 예를 들어 작업이 포트를 노출 할 필요가 없다는 것을 직감 할 수 있습니다 [2]. 반면에 서비스에 대부분 무의미한 CID 파일 과 같은 옵션은 작업에 정말 유용 할 수 있습니다.
5. 이제 대부분의 프로젝트에서 작업에는 종속성 체인이있는 경향이 있습니다 (이것이 기존의 컨테이너가 아닌 세계에서는 Makefile이있는 이유입니다). 따라서 최소한 병렬 처리가있는 종속성 체인의 기본 구현이 있어야하며이를 알 수 있어야합니다. 항상 10 분 소요 하나 JAR 빌드 작업은 정말 다시 실행해야합니다.
6. 그런 다음 일부 서비스는 실제로 시작하기 전에 실행 된 작업에 의존하여 종속성을 계산하고 처리하는 방법에 또 다른 수준의 복잡성을 추가합니다.
7. 그리고 일부 작업은 실행하기 위해 몇 가지 서비스가 필요합니다 (예 : 데이터베이스 마이그레이션).

이 시점에서 이것은 범위 및 복잡성 측면에서 cmake 와 일치하거나 능가하는 완전히 새로운 코드가되었습니다. 이것이 우리가 이것을 오랫동안 구현하는 것을 거부 한 이유입니다. 부분적으로 이것은 Compose가 수행하도록 설계된 것이 아니기 때문입니다. 또한 [3] 단순히이 기능을 구현하거나 유지할 시간이나 리소스가 없기 때문입니다. 사람들에게 진정으로 유용한 사람이되어야합니다.

바라건대 이것은 상황을 좀 더 명확하게합니다. 나는 사람들이이 스레드에 대한 응답 (또는 응답의 부족)에 대해 화가 나고 실망한 것을 알고 있으며 이것이 어떤 식 으로든 그것을 완화시킬 것이라고 확신하지는 않지만 거기에 있습니다.

[1] 어떤 사람들은 "선택적 서비스"를 원한다고 언급하지만,이 글에서 언급 한 가장 일반적인 사용 사례는 아닙니다. 내가 말할 수있는 한 대부분의 사람들은 "작업"기능을 원합니다.
[2] 누군가가 포트를 노출해야하는 작업의 예와 모순 될 것이라고 확신합니다. 이는 각 세트에 적용 할 수있는 옵션을 결정하는 작업이 사소하지 않다는 것을 보여줄뿐입니다.
[3] 그리고이 시점에서 저는 "나"를 의미합니다. 제가 현재 docker-compose 을 적극적으로 작업하는 유일한 관리자이기 때문입니다.

@ shin- 나는 요점을 본다. 내가 추구하는 것은 각주에있는 "선택적 서비스"이며 작업의 개념이 아닌 사용 사례입니다. 내가 옹호하려는 스레드의 일부이기 때문에 그 지점을 어떻게 진행할 수 있는지에 대해 어떻게 든 동의 할 수 있습니까? 이 스레드에 찬성하여 닫힌 경로에 대한 내 티켓. 우리가 그것을 '과제'로 명확하게 정의한 요점과 분리 할 수 ​​있다면 우리는 약간의 진전을 이룰 수 있습니다. 사람들이 내 읽기에서 옵션 2에 대해 +1을 수행하는 것은 선택적 서비스에 대한 것입니다. 토론을 위해 오프라인으로 전환 한 후 포럼으로 돌아갈 수 있습니다. 저는 [email protected]입니다.

@ shin- 당신의 요점 # 2가 잘못되었습니다. 서비스는 실행 여부에 관계없이 서비스입니다. 종속성을 사용할 수 없을 때 종속 서비스가 동작을 수정하는 수많은 사용 사례가 있습니다. 따라서 응용 프로그램 계층에서 모든 "서비스"를 항상 사용할 수 있도록 요구해서는 안됩니다.

가장 전통적인 용어로 생각한다면, 웹 서버는 "서비스"라고 생각하십시오. 그러나 주어진 호스트에서 기본적으로 시작되지 않도록 종료하거나 구성 할 수 있지만 아무도 서비스 이외의 다른 것으로 간주하지 않습니다.

이 기능을 요청하는 많은 분들이 작업 실행이 아닌 옵션 서비스를 원하시는 것 같습니다. 예를 들어, Docker 컨테이너로 실행되는 마이크로 서비스 집합이 있고 모든 마이크로 서비스를 전체 서비스로 배포하는 경우 언젠가는 요구 사항이 변경되고 모든 서버에서 모든 컨테이너를 실행할 필요가 없습니다. 필수가 아닌 컨테이너에 포함 된 특정 기능이 필요하지 않습니다.

또한 이것은 개발 환경을위한 좋은 기능이라고 생각합니다. 특정 컨테이너의 버그를 수정하는 경우 모든 컨테이너를 시작할 필요가 없습니다.

정확하게, 간단한 부울 필드를 사용하여 .env 파일에서 서비스를 쉽게 활성화 / 비활성화하고 yaml 파일 편집을 피할 수 있습니다.

@ekkis 나는 당신이 내결함성과 분배 성을 다소 혼란스럽게 생각한다고 생각합니다. 또한 주제에 대한 내 각주를 참조하십시오. 여기서 일부 사용 사례가 존재한다는 것을 인정합니다.

모두 : 일부 서비스가 귀하의 애플리케이션에 선택 사항 인 경우 이미 현재 기능으로이를 처리 할 수 ​​있습니다. 이렇게하는 데 권장되는 방법은 -f 플래그를 사용하여 포함하거나 제외 할 수있는 별도의 작성 파일을 만드는 것입니다. 그들은이 옵션을 추가하는 것에 대해 그다지 설득력이없는 주장이 아닙니다.

@ shin- 시간을내어이 대화를 나눠 주셔서 감사합니다. 여러 개의 yml 파일을 제안함에 따라 여러 가지 방법이 있다는 데 동의합니다. 여러 개의 yml 파일을 제안하면 서비스 목록을 전달할 수도 있지만 이는 편리하지 않으며 사용자 오류로 인해 운영 위험을 초래합니다. 특히 상용 제품의 경우 하나의 compose 파일을 배포하고 기본적으로 원하는 공통 동작을 얻고 고급 옵션에 대한 지침을 제공하려고합니다. 하나의 파일은 dev, CI / CD 및 배포 모두에 대해이 모든 것을 훨씬 깔끔하게 만듭니다. 기본값이있는 ENV 변수의 추가는 우리에게 큰 도움이되었고 많은 yml 파일이 필요하지 않게되었습니다. 이것은 배포를 설명하는 단일 파일을 관리하는 한 단계 더 나아가게 될 것입니다.

핵심 팀이이 LMK에 대한 기여를 기꺼이 수용 할 수있는 형식이 있습니까?

@shin , 나는 내결함성 또는 분배 가능성에 대해 언급하지 않았습니다. 나는 단지 "서비스"의 정의, 즉 서비스 실행 여부가 정의에 내재되어 있지 않다는 점을 지적했습니다.

@ shin- 나는 @ekkis에 강력하게 동의합니다 : 시작되지 않음 _ 기본적 으로

예 : mysql DB를 사용하여 애플리케이션을 개발할 때 일반적으로 추가 _service_ phpmyadmin 정의합니다. 이것은 진정한 서비스입니다 : 다른 서비스에 의존하는 장기 실행, 노출 된 포트.
하지만이 서비스를 _ 기본적으로 _ 시작하지 않고 _ 요청시 _ / 개발 중에 만 시작하고 싶지 않습니다.
현재 저는이 서비스를 추가 docker-compose.yml 넣고 위에서 제안한대로 docker-compose 두 파일을 모두 제공하여 시작함으로써이를 인식합니다.

그렇습니다.이를 달성 할 수있는 방법이 이미 있습니다. 서비스를 여러 파일로 분할하거나 단순히 docker-compose 이외의 도구를 사용하면됩니다. 그러나 위에서 이미 썼 듯이 :이 문제는 완전히 새로운 기능이나 새로운 개념 (예 : _tasks_)에 관한 것이 아니라 특히 개발 환경 에서의 편리 성에 관한 것 입니다.
docker-compose -f docker-compose.yml -f docker-compose-tools.yml up 를 입력하는 것은 편리하지 않으므로 docker-compose 는 자체 약속을 제공하지 않습니다.

이러한 기능은 개발자 가 프로젝트를 시작할 수있는 편리한 방법 을 제공합니다. Compose는 여러 페이지의 "개발자 시작 안내서" 를 단일 컴퓨터에서 읽을 수있는 Compose 파일 과 몇 가지 명령으로 줄일 수

어떤 서비스를 시작할지 또는 어떤 yml 파일을 어떤 환경에서 사용할 것인지는 일반적으로 _ 여러 페이지 "개발자 시작 안내서"_에서 찾을 수 있습니다.

그래서 제 생각에 @jimzucker 가 여기에

내 PoC 가 "선택적 서비스"를 위해 필요한 코드 변경을 보여

@ shin- 사용자에게 서비스를 선택 사항으로 표시 할 수있는 가능성을 제공하는 데 동의하지 않습니까? 그러나 여전히 서비스 인 경우 큰 도움이 될 것입니까?
"_services_를 선택 사항 / 기본적으로 시작되지 않음으로 표시"로 축소하면이 문제 / 이에 대한 풀 요청이 수락되고 병합됩니까?

@shin , 위의 @acran 의 요점에 추가하기 위해 특정 서비스 를 이름을 사용 하는 다른 서비스에 의해 실행되기 때문에 docker-compose를 사용하여 특정 서비스를 빌드하고 싶을 수 있습니다. 내가 "up"할 때마다 project_app_1 , project_otherapp_1 등의 "서비스"를 얻게된다는 점을 고려하십시오. 이들은 데이터베이스의 정보를 사용하여 실행해야하기 때문에 의미가 없습니다 (이를 시작하는 마스터 서비스가 있습니다). . 그래서 나는 항상 그들을 죽여야합니다. 그래서 나에게는 NO_RUN 또는 BUILD_ONLY 플래그가 완전히 의미가 있습니다. 이것은 편리 할 것이다

@acran

사용자에게 서비스를 선택 사항으로 표시 할 수있는 가능성을 제공하는 데 동의하지 않으시겠습니까?하지만 여전히 서비스입니다.

나는 그것이 얼마나 도움이 될지에 동의하지 않는다 – 나는 "매우"가 과장된 것이라고 생각한다. 귀하의 예에서, 선택적으로 포함될 수있는 docker-compose.phpmyadmin.yml 를 갖는 것은 환경 변수를 설정하거나 기본 파일 내에서 서비스 정의를 수정하는 것보다 더 이상 부담 스럽거나 복잡하지 않습니다 (지침 "개발자 가이드"측면에서).
나는 또한 개발자들에게 꼭 필요하지 않을 때 "풋건" 을주는 것의 상충 관계를 고려하고 있습니다.

"서비스를 옵션으로 표시 / 기본적으로 시작되지 않음"으로 축소하면이 문제 / 이에 대한 풀 요청이 수락되고 병합됩니까?

위의 내용을 참조하십시오.이 기능을 사용할 수있게되면 사람들은 의도 된 목적 이외의 용도로 사용하기 시작하고이를 지원하는 새로운 기능 세트를 구현할 것으로 기대합니다. 또한 cc @jimzucker ; 나는 현재이 시나리오가 전개되는 것을 막을 수있는 구현을 생각할 수 없다. 가능하다면이 문제는 오래 전에 종결되었을 것입니다.

@ekkis 이러한 서비스를 직접 시작하지 않으려는 경우 별도의 파일에 격리하는 것이 정확히 문제가되는 이유는 무엇입니까? 나는 이것이 왜 여기에서 그렇게 중단되는지에 대해 정말로 혼란 스럽습니다.

@shin docker-compose.yml 을 사용하여 서비스를 빌드 할 수 있다면 빌드 프로세스를 중앙 집중화하는 데 가장 유용한 도구입니다. 실제로 서비스를 실행하기 전에 (조건부로) 구축하고 싶을 수 있다는 사실이 상당히 의미가 있으며, 그 기능에 박수를 보냅니다.

따라서 docker-compose 파일도 my makefile 입니다. 하지만 내가 무언가를 만들었다 고해서 실행하고 싶다는 의미는 아닙니다. docker-compose가 서비스를 실행하고 이름을 발명하고 적절한 매개 변수 / 환경 변수 등없이 실행 한다고 가정 하는 것은 의미가 없습니다.

솔직히이 간단한 패치에 대한 반대가 무엇인지 잘 모르겠습니다. 그것은 나에게 매우 유용 할 것입니다

이전 게시물 에서 팀의 공식 입장이 Compose 파일을 Makefile로 사용해서는 안되는 이유를 분명히 지적했습니다. 우리가 이것에 대해 틀렸다고 믿고 여전히 그렇게하고 싶다면, 그것은 당신의 특권이지만, 우리가 그것을 지원하기 위해 기능을 추가하도록 주장하는 것은 약간 터무니없는 일입니다.

@정강이-

귀하의 예에서, 선택적으로 포함될 수있는 docker-compose.phpmyadmin.yml을 갖는 것은 환경 변수를 설정하거나 기본 파일 내에서 서비스 정의를 수정하는 것보다 더 이상 부담 스럽거나 복잡하지 않습니다 (지침 "개발자 가이드"측면에서).

사실 저는 아직 여기에 환경 변수를 포함시키는 것에 대해 생각하지 않았습니다. 내가 원하는 "선택적 서비스"가 마침내 허용하는 워크 플로우는 다음과 같습니다.

• 새 프로젝트를 복사 / 복제합니다.
• 여기에 (단일) docker-compose.yml 파일이있는 것을 알았습니다. 따라서 제가해야 할 일은 docker-compose up 를 실행하는 것뿐입니다. 그러면 응용 프로그램이 빌드되고 실행됩니다.
• 이제 개발 목적으로 선택적 서비스 중 하나를 시작하려고합니다 (예 : 추가 디버깅, phpMyAdmin). 내가해야 할 일은 docker-compose up phpmyadmin 입니다.

저에게는 여러 개의 docker-compose.yml 파일을 사용하는 것보다 _ 훨씬 _ 편리하며, 여기에있는 대부분의 다른 사람들도 알고 있습니다. 여기에서 "선택적 서비스"를 갖는 이점은

• 개발자가 여러 파일 사이에 아무것도 복제 할 필요가 없거나 어떤 파일에 어떤 정의를 넣을지 신중하게 고려할 필요가 없지만 서비스에 하나의 부울 플래그 ( auto_up: false ) 만 설정하면됩니다.
• 사용자가 어떤 서비스에 어떤 파일을 포함해야하는지 알거나 기억할 필요가없는 경우 : 실행해야합니까?
  
  
  
  • docker-compose -f docker-compose.phpmyadmin.yml up
  
  
  • docker-compose -f docker-compose.yml -f docker-compose.phpmyadmin.yml up 또는
  
  
  • docker-compose -f docker-compose.phpmyadmin.yml -f docker-compose.yml up ?
  
  
• 대신 사용자가 알아야 할 유일한 것은 phpmyadmin 라는 서비스가 있고 사용자가이를 시작하는 방법을 즉시 알고 있다는 것입니다.

위의 내용을 참조하십시오.이 기능을 사용할 수있게되면 사람들은 의도 한 목적 이외의 용도로 사용하기 시작하고이를 지원하기위한 새로운 기능 세트를 구현할 것으로 기대합니다.

오해하지 마십시오. 여기에서 귀하의 우려 사항을 이해할뿐만 아니라 이에 동의합니다. 기능이 의도하지 않았더라도 원하는 워크 플로에 맞게이 기능 또는 기타 (!) 기능을 구부리는 사용자가 항상있을 것입니다. 그렇게 사용되었습니다.
그러나 "태스크"의 기능이 누락 된 "옵션 서비스"에 대한 요청에 대해 _ 그런 다음 _ 쉽게 서비스가 태스크가 아니며 태스크를 먼저 새로운 개념으로 도입해야하므로 아직 지원되지 않는다고 주장 할 수 있습니다. 즉, 서비스를 선택 사항으로 표시하는 것 이상의 것은 작업 개념 (예 : 옵션 4)을 향한 단계이며 그 사이에 명확한 구분이 있습니다.

_service_를 선택 사항으로 표시하는 기능으로 우리는 여전히 그 컷의 오른쪽에 있습니다. "이 기능 자체는 구현하기에 너무 복잡하지는 않지만 사용자가 잘못 사용하도록 유혹 할 수 있습니다."현재이 기능에 반대하는 유일한 실제 (유효하지만!) 주장은이를 구현하지 않는 이유로서 상당히 불만족 스럽습니다. 올바른 방법으로 사용하면서 많은 편리함을 얻을 수있는 사용자.

나는 내 풀 리퀘스트 # 3047을 현재 마스터로 리베이스하고 이것을 받아들이 기 위해 필요한 폴리싱을 할 것입니다. 제발 알려주세요;)

내 사용 사례는 모든 이미지를 도커 허브 또는 부두로 푸시하지 않으며 자체 레지스트리도 없으며 서비스를 기본적으로 실행되지 않음으로 표시 할 수 있다는 것은 시작되지 않는 docker-compose.yml 정의 된 기본 이미지가 있고이를 사용하거나 빌드하는 다른 컨테이너가 있습니다.

이 단일 기능에만이 기능을 구현하는 docker-compose 포크를 사용하고 싶습니다.

@ shin- 우리 모두가 당신의 요점을 이해하고 공감한다고 생각하지만, "오용 될 수있다"는 것은 분명한-많은 실행 가능한 사용 사례에 대한 좋은 주장이라고 생각하지 않습니다. 물론 오용 될 것입니다. 이것이 바로 소프트웨어와 새로운 아이디어가 성장하는 방식입니다. 기술을 완전히 사용하지 않는 것입니다. 지난 25 년 동안 제공된 모든 기술을 오용하지 않았다면 웹은 오늘날의 웹이 아닐 것입니다.

어쨌든.
당신에 따르면-단순화-서비스와 작업의 차이는 수명입니다. 이치에 맞습니다. 저는 여러분이 그것들을 두 가지 다른 개념으로보고 그것이 잠재적 인 웜 캔이라고 느끼는 것을 이해합니다. 그러나이 구분은 문서에서 명확히 설명되지 않습니다. 도 커가 시간적 프로세스를 회전시키는 데 사용되지 않는다는 점도 지적되지 않았습니다.
내 말은 도커 팀이 이것에 대해 강한 입장을 가지고 있다면 처음부터 명확하게해야한다는 것입니다.
또한. 작업 또는 서비스, 분명히 겹치는 부분이 있습니다. 그리고 서비스를 선택 사항으로 표시하는 것은 확실히 작업 측에 고유 한 것이 아닙니다.
실용적인 관점에서 저는 @acran에 확실히 동의합니다. 단일 docker-compose 파일을 갖는 것이 훨씬 더 나은 DX이고 많은 것을 단순화하며 여러 개의 docker-compose 파일을 갖는 것보다 오류가 적습니다.

Hehe, 저는 우리가 "브라우저"가 이미지를 표시하도록 허용하기 위해 로비 할 때 있었던 격렬한 토론을 기억합니다. 반대자들의 주요 주장은 하이퍼 텍스트 전송 프로토콜이라는 것입니다.
옛날 방귀를 연상시키는 구약에 대해 죄송합니다.

@ shin- docker-compose가 메이크 파일로 사용되지 않아야한다면 메이크 파일 기능을 제공하지 않아야합니다. 내 프로젝트를 빌드 할 수 있다면 (bravo!) makefile이 아니라는 입장을 취하는 것은 우스꽝 스럽습니다.

@ shin- 봐, 당신은 당신의 이유가 아무리 비합리적이거나 기능이 얼마나 유용한 지에 관계없이 원하지 않는 기능을 구현할 필요가 없습니다. 그것은 단지 그것을 사용하는 우리들에게 도구를 덜 유용하게 만드는 것입니다. 우리는 사용자이고 사용 사례를 알고 있으며 도구는 사용 사례를 충족하는 것만 큼 유용하고 가치가 있습니다.

이것은 나에게 사소한 자극 일뿐입니다. _ 내 서비스를 시작할 때마다 _ 타당한 이유없이 생성되는 많은 것들을 수동으로 죽여야합니다. 다른 사람들에게는 장애가 될 수 있으며 자극의 정도는 다양합니다.

나는 공식적인 입장이 우리가 필요로하는 것에 과잉 일지라도 도비를 사용해야한다는 것을 이해합니다. 그러나 그 공식적인 입장은 유용한 PR을 받아들이기를 꺼리는 근거를 설명하지 않습니다. docker-compose에 대한 수요가 너무 크거나 마이그레이션하기에 충분한 겹침이있을 때 여전히 dobi를 사용할 수 있습니다. 그러나 이것은 우리 삶을 훨씬 더 좋게 만들 아주 작은 변화입니다.

그리고 부수적으로, 나는 "무소 적"이 아니지만 더 이상의 논의를 막기 위해 스레드를 잠그는 것은 단순히 비민주적이고 권위주의적일 것입니다. 오픈 소스는 개방의 원칙에 기반을두고 있으며,이 프로젝트가 검열과 독재 적 전술을 사용하여 관리되는 것을 보면 안타깝습니다.

@rysiekpl 이것은 우리가 다른 방식으로 해결하고자하는 문제입니다. https://github.com/docker/cli/pull/452를 참조

@creynders 나는 그것이 약간의 잘못된 특성이라고 생각합니다. 아무도 선택적 서비스가 존재해서는 안된다고 말하지 않습니다 (사실 내가 지적했듯이 별도의 파일을 사용하여 선언하는 방법이 있습니다). 이것은 <img> 태그를 명시 적으로 닫지 않는 것이 유효한지 그리고 특정 브라우저가이를 지원해야하는지 여부에 대한 논쟁과 더 비슷합니다.

또한 귀하의 요점은 다음과 같습니다.

그러나이 구분은 문서에서 명확히 설명되지 않습니다. 도 커가 시간적 프로세스를 회전시키는 데 사용되지 않는다는 점도 지적되지 않았습니다.

이것은 실제로 https://docs.docker.com/compose/overview/ 페이지의 첫 번째 단락입니다 (강조 표시) :

Compose는 다중 컨테이너 Docker 애플리케이션을 정의하고 실행하기위한 도구입니다. Compose에서는 Compose 파일을 사용하여 애플리케이션의 서비스를 구성합니다. 그런 다음 단일 명령 을 사용하여 구성에서 모든 서비스를 만들고 시작합니다.

@ekkis Compose가 실제로 프로젝트에 도움이 돼서 정말 기쁩니다! 나는이 모든 것에 성실하지 않기를 바란다. 그것이 당신이 소프트웨어를 사용하고 싶은 방식이라면 절대적으로 괜찮다. 그러나 내가 말하는 것은 그 방향으로 더 나아가면 아마도 장기적으로 더 악화 될 것이라는 것입니다. 우리 모두는 너무 많은 일을 시도하는 응용 프로그램에 어떤 일이 발생하는지 알고 있습니다 (Emacs가 그것을 제거했다고 생각하지만 : stuck_out_tongue :)

나는 내가 "권위주의 자"라고 생각하지 않지만, 내 자신을 제대로 표현하지 않았을 수도 있습니다. 내 의도는 사람들이 상호 작용에서 예의 바르고 긍정적 인 태도를 유지하도록 장려하는 것이 었습니다. 스레드는 여전히 잠금 해제되어 있으며 사람들이 비열하거나 무례한 것을 자제하는 한 계속됩니다.

구성에서 모든 서비스를 만들고 시작합니다.

그리고 우리의 주장은 "만들기 및 / 또는 시작"을 읽어야한다고 생각하지만, AND에 암시 적이므로 OR를 표시 할 필요가없는 언어에 공평합니다. 즉, 서비스를 생성하고 시작할 수 있다는 것은 사실이지만 둘 다 수행해야한다는 의미는 없습니다.

우리 모두는 너무 많은 일을 시도하는 애플리케이션이 어떻게되는지 알고 있습니다.

예, 도메인의 경계를 관리하고 있다는 점에 감사드립니다.

나는 내가 "권위적"이라고 생각하지 않는다

저는 오픈 소스 운동을 좋아합니다. 우리는 불일치를 가질 수 있지만 여전히 함께 있습니다. 비트 코인 커뮤니티 내의 전쟁은 끔찍했고 저는 여전히 그것 때문에 긴장하고있는 것 같습니다. 예의를 지켜 주셔서 감사합니다.

이별 생각으로 https://github.com/docker/compose/issues/4650 이 스레드의 요청과 동일하지 않지만 (닫을 때 표시 한대로) 내 사용을 수용하는 재검토를 요청합니다. 예를 들어 여기서 논의되는 플래그는 바이너리가 아니라 트리 너리입니다.

여러 파일을 정의하는 아이디어가 정말 마음에 듭니다. 그러나 원본을 포함하여 -f 가 여러 개인 파일을 모두 포함하는 것은 총 과잉 인 것 같습니다.

실제로 저에게 맞는 더 실용적인 방법이 있습니다 (아래 PS 참조) : 실행하고 싶지 않은 모든 서비스를 docker-compose.override.yml 넣으십시오. 그리고 정상적인 시작에는 docker compose -f docker-compose.yml up 를 사용합니다 (이는 일회성 명령입니다). 모든 연속 호출에서 재정의가 소싱됩니다.

전반적으로 이것은 모두 매우 직관적이지 않고 약간 불만족 스럽습니다. 추가 추가 :

• 서비스 비활성화 옵션은 특히 더 복잡한 재정의에 적합합니다.

• -f 옵션은 최소한이지만 그다지 직관적이지 않습니다. 추가 재정의를 추가하는 또 다른 -F <name> 옵션은 매우 환영 할 것입니다 (예 : docker-compose..yml. 대안은모든 .yml 파일이 소싱되는 디렉토리로 : 심볼릭 링크와 함께 이것은 /etc/apache/sites.available -> /etc/apache/sites.enabled 와 유사하게 강력합니다.

다른 한편으로 : 누구나이 동작을 에뮬레이트하기 위해 쉘에 simpe 래퍼 스크립트 (함수)를 제공 할 수 있습니다.

추신 : 내 사용 사례는 디버거를 서비스로 정의하는 것입니다. 분명히이 서비스는 항상 필요한 것은 아니지만 제대로 작동하려면 링크 (보안상의 이유로)가 필요합니다.

옵션 2가 좋은 또 다른 사용 사례 :

같은 프로젝트에서 일하는 팀이 있다고 가정 해 보겠습니다. 일부는 AWS 관리 형 서비스에 액세스 할 수 있지만 일부는 해당 리소스를 로컬 컨테이너로 실행해야합니다. 따라서 내 워크 플로에 따라 _always_ 또는 _never_ compose constellation에 Redis 및 MySQL 컨테이너가 필요합니다.

이 사용 사례에서는 여러 compose 파일을 관리하는 것이 어리 석다고 단호하게 말할 것입니다. 겹치는 정도는 코믹합니다. 여러 파일을 유지하는 것은 풋건입니다. 동기화되지 않고 혼란을 야기 할 것입니다. 솔직히 누군가가 _any_ 사용 사례에 대해이 옵션을 진지하게 받아 들였다는 사실에 약간 충격을 받았습니다.

큰 구성 블록을 주석으로 처리하지 않고 서비스를 빠르게 활성화 및 비활성화 할 수 있다는 것은 그 자체로 훌륭합니다. 그러나 언젠가 compose가 변수를 구성에 삽입하는 기능을 갖게되면이 기능은 자동으로 기하 급수적으로 더 강력 해집니다. 그때까지는 _ 단순히 _ 유용합니다.

@campadrenalin에 완전히 동의합니다.

내가 이해하는대로이 전체 토론은 기본적으로 옵션 2를 구현해야하는 아주 좋은 이유를 제공하는 많은 사람들과 개발자가 거부하는 이유입니다. 누군가 가설 적으로이 기능의 존재를 잘못 해석하고 다른 관련없는 기능을 요청할 수 있기 때문입니다. .

OT :

그러나 언젠가 compose가 변수를 구성에 삽입하는 기능을 갖게되면이 기능은 자동으로 기하 급수적으로 더 강력 해집니다.

이 기능을 오랫동안 사용할 수 없었습니까? https://docs.docker.com/compose/compose-file/#variable -substitution을 참조 .env 파일 (예 : 소스 코드 위치, 포트 매핑 등)을 사용하여 Compose 개발 환경의 사용자 정의를 허용하는 데 사용하고 있습니다. compose 파일 버전 2.1부터 쉘 스타일 변수 기본값 ( ${VARIABLE:-default} / ${VARIABLE-default )가 지원됩니다.

내가 이해하는대로이 전체 토론은 기본적으로 옵션 2를 구현해야하는 아주 좋은 이유를 제공하는 많은 사람들과 개발자가 거부하는 이유입니다. 누군가 가설 적으로이 기능의 존재를 잘못 해석하고 다른 관련없는 기능을 요청할 수 있기 때문입니다. .

나는 이것이 약간 거칠지 만 본질적으로 유효하다고 생각합니다. @rysiekpl의 아주 좋은 요약입니다.
그래서 @ shin-, 우리는이 문제에 대한 결정에 더 가까워 졌습니까? 그냥 닫을 지 아니면 옵션 2에 대한 PR을 구현 / 수락할까요?

나는 당신의 우려를 완전히보고 이해합니다. 그러나 이것은 다소 작은 변화이지만 많은 사람들에게 훨씬 더 편리한 워크 플로우에 대해 훨씬 더 많은 가능성을 제공하기 때문에 누군가 잠재적으로 이것을 남용 할 위험보다 이점이 더 크다는 것을 봅니다.

어쨌든 docker-compose는 장기간에 걸쳐 Docker 스택을 선호하는 것처럼 보이므로 가능한 한 빨리 모든 사람이 새로운 v3 형식과 docker stack 도구로 이동하는 것이 좋습니다.

스웜 (노드 1 개 포함)에서 스택을 사용하여 다음을 지정할 수 있습니다.

        deploy:
            mode: replicated
            replicas: 0

복제본이 전혀 없으면 서비스가 실행되지 않습니다.

envsubst와 같은 환경 변수 대체를 적용하려면 해당 yml을 생성하기 위해 다른 도구가 필요합니다.

그런 다음 yml에서 자리 표시자를 사용할 수 있습니다.

        deploy:
            mode: replicated
            replicas: ${R}

그리고 다음과 같이 처리하십시오.

export R=0
docker stack deploy stack1 --compose-file=<(envsubst <docker-compose.yml) 

따라서 docker-compose 가 장기적으로 더 이상 사용되지 않는 경우 이미 존재 하는 docker-compose 이 dodo의 길을 가고 있다면, "누군가 이상한 기능을 요청할 것"이 어떻게 진짜 문제일까요?

docker-compose는 장기간에 걸쳐 docker stack을 선호하는 것으로 보입니다.

따라서 docker-compose가 장기적으로 사용되지 않을 경우

잠깐, 와트? docker-compose 은 (는) 무리 관리자가 거의 필요하지 않은 개발 워크 플로의 많은 사람들에게 핵심입니다. 이와 관련하여 Docker의 공식 성명을 알려 주시겠습니까?

나는 이것을 잘못 읽고 있을지 모르지만, 도커 떼와 도커 스택이 도커 클라우드 서비스와 밀접하게 결합 된 것처럼 들린다. 독립형 오프라인 시스템에서 이러한 항목을 구성 할 수 있습니까?

독립형 오프라인 시스템에서 구성 할 수 있습니까?

예, 오프라인에서 사용할 수 있습니다.

나에게는 docker-swarm의 스택이 결국 docker-compose 기능의 상위 집합이 될 것 같습니다. 설명자 파일이 이미 매우 유사하다고 생각합니다. 바라건대,이 전환이 너무 어렵지 않을 것입니다. 내가 볼 수있는 가장 큰 골칫거리는 떼를 스택과 별도로 관리하는 것입니다. 두 개 이상의 노드에서 구성된 애플리케이션을 실행하는 데 관심이 없기 때문에 더 많은 오버 헤드가 발생합니다.

아니면 내가 모든 걸 오해하고 있을지도 ...?

옵션 2에 +1!
그리고 나는도 커가 스웜 스택에 유리하게 구성되는 것이 커뮤니티에 큰 단점이 될 것이라고 생각합니다. Docker compose는 매우 간단하고 사용하기 쉽습니다 !!

@tberne 동의합니다. docker-compose는 간단하고 간단합니다. 우리는 그것을 유지하기 위해 투표해야합니다

헤, 얼마나 광범위한 토론입니까! 이 의견에 많은 관심을 기울이지 마십시오. 단지 2 센트입니다.

처음에는 enabled 플래그를 추가하기로 다수의 의견에 동의했습니다.
그런 다음 그룹 별 분기 정의에 대한 제안을보고이를 좋은 아이디어로 간주했습니다.
그런 다음 Dobi에 대해 읽고 사용해 보았고 지금 내 프로젝트에서 사용할 수 없는지 확인하고 계속 읽었습니다.
그런 다음 나는 일부 반론에도 동의했지만 @ shin-의 주장을 읽고 충분히 좋다고 생각했습니다.

내 현재 솔루션은 일부 docker-compose yamls를 만들고 docker-compose를 수동으로 실행하지 않도록 일부 bash 래핑 스크립트를 작성하는 것입니다.

예를 들어 웹 사이트를 실행하는 컨테이너를 실행하는 방법입니다 ( ./docker/scripts/up 스크립트).

#!/usr/bin/env bash

def_opts="-d"

cd "$(dirname "$0")"/../

# A separate bash file with functions like: get_args, add_hosts...
. ./functions.sh

docker-compose -p ${PROJECT} up ${def_opts} $(get_args "options services" "$@") && \

# Adding host to /etc/hosts
add_hosts "$HOSTS" web && \
add_hosts "$HOSTS_MAIL" mail

옵션 2 또는 3에 큰 +1.

옵션 2 또는 3의 경우 +1.

또한 제안 된 "그룹"개념이 흥미롭게 들립니다!

옵션 2의 경우 +1

_ +1 on option x 가 너무 많아서 원래 명세서도 찾을 수 없습니다. 대신 게시물 아래의 반응 버튼을 사용하세요 ._

새로운 아이디어를 추가하려면 :

기본 배율 을 0 설정할 수 없습니까?

web:
  image: busybox:latest
  command: echo 'scaled'
  scale: 0

사람들이 몇 년을 기다렸 기 때문에 옵션 2를 수행해야합니다 (대신 시작하지 않을 수도 있습니다). 그런 다음 도구가 너무 제한적이기 때문에 docker-compose를 자신의 구성 관리자로 래핑합니다. 하고있다. 2 년 안에 누군가는 자신의 더 강력한 도커 구성을 만들 수도 있습니다. 이 문제는 많은 시간 동안 공개되었습니다.

장기적으로 진정한 옵션 그룹화를 고려해야합니다. 일부는 빌드에만 관련이 있고 일부는 실행에만 관련이 있고 일부는 상호 적입니다 (적어도 실행을 위해 중첩 레이어를 원하거나 분리하고 빌드 섹션을 갖고 문제가 해결됨). 현재는 구성에 많은 문제가 있지만 버전 5에서 모든 것을 리메이크하는 것 뿐이지 만 그 때 올바르게 가져 오는 것입니다 (주로 사용을 매핑하려고하기보다는 기술 수준 도메인에서 실제를 나타냄으로써 기반 도메인 또는 지나치게 단순한 대신 올바른 목표 위에 해당 목표에 대한 구성 계층을 생성하십시오. 반대로 수행 할 수 없습니다.) 나는 그 상황 때문에 빠른 수정이 정당하다고 생각합니다.

옵션 2 또는 4의 경우 +1

현재이 기능을 추가 할 계획이 없다면, 그러한 서비스 (또는 작업)를 컴포지션에서 실행하는 방법이 docker-compose의 문서로 작성되기를 바랍니다.

이것은 오래된 스레드이며 docker-compose 가 start_에서 실행되지 않는 _services에 대해 신경 쓰지 않는다는 데 동의합니다.

하지만 일반적으로 test 서비스도 추가하므로 다음 작업을 수행했습니다.

1. 서비스의 entrypoint 을 재정의합니다.

2. 새로운 entrypoint 에서 사용 가능한 tty 가 있는지 확인합니다 ( docker-compose run 는 기본적으로 --tty 를 사용하고 up 는 사용하지 않음).

   # Check if there is a tty
   if [ ! -t 1 ] ; then
     echo "No tty available."
     exit 0
   fi
   

   docker-compose run 로 예상대로 실행되는 동안 tty (예 : docker-compose up ) 실행하면 항상 서비스가 종료됩니다.

@paulodiovani 솔루션 이라기보다 해킹처럼 보입니다.

기능 요청에 +1.
아무것도하지 않는 명령을 갖는 것과 같은 해킹은 컨테이너가 실행되지 않더라도 여전히 빌드되고 초기화되어야 함을 의미합니다.

제공된 인수를 기반으로 적절한 docker-compose 명령을 호출하는 간단한 bash 스크립트를 제공하여 프로젝트에서이 문제를 해결했습니다.

이제 ./docker-compose.sh -e testing up 를 수행하면 결과는 docker-compose -f docker-compose.yml -f docker-compose.testing.yml up 한 것과 동일합니다.
./docker-compose.sh up 를하면 예상대로 일반 docker-compose up 얻습니다.

따라서 내 -e ${environment} 옵션 ( --env 의 약자)은 기본적으로 -f docker-compose.yml -f docker.compose.${environment}.yml 의 별칭입니다. 결과적으로 docker-compose.yml 는 기본 / 기본 작성 파일이되고 docker-compose.testing.yml 와 같은 파일은 확장명이됩니다.

이것은 정상적인 기본값을 적용하여 docker-compose 명령에 어떤 파일을 어떤 순서로 포함할지 모르는 사용자의 @acran 문제를 다소 해결합니다. 일부는 더 복잡한 compose 파일 조합을 사용할 수 있기 때문에 매우 강력한 솔루션은 아니지만 docker-compose 비슷한 작업을 수행 할 수 있어야한다고 생각합니다. 대부분의 docker-compose 파일을 시작하는 가능성이 docker-compose. 와 끝 .yml 왜 난 항상 같은 긴 명령 (교체 아웃 입력해야합니까, 어쨌든 docker-compose -f docker-compose.yml -f docker-compose.testing.yml up ) 테스트 환경에 대해 하나의 추가 서비스 만 필요한 경우?

envsubst가 필요 없으며 docker-compose config가 환경 변수를 수행 한 다음 docker 스택이 stdin에서 가져옵니다.

docker-compose config | docker stack deploy --prune --compose-file -

docker-compose .env 대체도 사용하겠습니다.

@kogli 여기서 문제는 옵션을 선택하는 것이라고 생각합니다. 모두 장단점이 있습니다. 예전에 내가 말했듯이:

모든 솔루션은 일부 사용 사례에서 더 좋을 것이고 다른 경우에는 더 나쁘거나 쓸모 없을 것입니다. 무언가가 구현되면 영원히 관리하기 때문에 시간을내는 것이 현명하다고 생각합니다.

@ shin- 나는 당신이 물어볼 사람이라고 생각합니다 : 이것을 고려하는 것이 합리적입니까? 팀의 현재 위치, 디자인이 얼마나 어려운지, 그리고 거기에있는 많은 도구를 고려할 때 사람들에게 이것이 일어나지 않을 것이라고 말하는 것이 더 쉬울까요? 여기에 언급 한 모든 사람이 아니라면 대부분의 사람들은이를 처리 할 방법을 찾았습니다.

이것을 닫는 것은 꽤 좋은 것 같고, 중요한 일에 집중할 수 있으며, 아무도 풀 리퀘스트를해야하는지, 그리고 이러한 모든 요구를 동시에 충족하는 방법을 궁금해하지 않습니다. 그들은 그냥 다른 것을 만들어서 다른 사람들을 돕기 위해 게시 할 수도 있습니다.

기록을 위해 : 내 솔루션은 완벽하지 않았지만 종속성을 설치하고 많은 것을 수정하고 프로젝트를 실행하는 데 걸린 2 일보다 훨씬 낫습니다 (그리고 이미 Docker를 사용했습니다). Docker 및 Docker Compose를 유일한 종속성으로 사용하는 단 3 개의 명령. 네, 제가 원하는 것보다 더 많은 코드가있었습니다. 예, 명령을 실행하는 엉뚱한 순서가 있습니다. 그리고 네, 명심해야 할 것이 조금 더 있습니다. 위키 페이지에서이를 다루었습니다. Preety good, 내가 그렇게 말하면 Docker Compose가 그 일을 했음을 의미 합니다 .

요점은 범위를 벗어난 경우 계속 논의하는 데 시간 낭비입니다. 많은 사람들이 무엇을 해야할지 결정하기 전에 여기에 멈추고 이에 대해 질문하고 의견을 제시합니다. 이것이 닫히면 그들은 더 빨리 다른 것을 찾거나 만들 것입니다. 그리고 당신은 아기를 돌볼 스레드를 하나 덜 얻습니다.

편집 : 좋은 방법을 생각했습니다. PR을 수락 할 명확한 기준이없고 핵심 팀에 PR에 관여하거나 가까운 장래에 검토 할 계획이없는 경우 " 문제 ", 그냥 아이디어.

문제 목록을 복잡하게 만들 이유가 없다고 생각합니다. 여기에있는 많은 아이디어가 좋다고 생각하지만, 좋든 나쁘 든 다른 곳에 속한다고 생각합니다. 거의 3 년이 지나면 언젠가 상황이 바뀔 때 언제든지이 문제를 다시 열거 나 새로운 문제를 열 ​​수 있습니다.

이 기능은 정말 간단하기 때문에 구현하는 데 하루 정도 걸립니다. 그러나 2 년 간의 논의 후에도 여전히 아무것도 없습니다. 슬퍼.

@rubycut 그렇습니다. 소위 "상위 원칙"이 유용성과 사용자

@rubycut 토크는 저렴합니다. 코드를 보여주세요. 할 수 있으면 PR을 보내고 할 수 없으면보고하고 기다리십시오.

@wangwenpei 농담 해? 우선, 당신은이 프로젝트의 관리자가 아닙니다. 메인테이너가이 아이디어를 받아들이고 "help wanted"태그를 붙이면 누군가 풀 리퀘스트에 기여할 수있을 것입니다. 그러나 그들은 관심이 없다고 말했습니다. 따라서 수락되지 않으면 왜 귀찮게 요청을 끌어 당길 것입니다.

참고로 "코드"는 이미 있습니다. # 3047

@wangwenpei 음 , # 3047, 풀 요청이 있습니다 ...
2 년 넘게 이에 대한 피드백을 받기를 기다리고 있습니다. 최근에 문을 닫았습니다

https://github.com/docker/compose/issues/1896#issuecomment -322285976에 강조 표시된 이유 때문에

https://github.com/docker/compose/issues/1896#issuecomment -322285976에 제공된 인수가 풀 요청과 어떤 식 으로든 관련이 없기 때문에 솔직히 말하면 화가납니다.

1. 서비스 란? 설계 상 서비스는 애플리케이션을 형성하기 위해 다른 서비스와 상호 작용하는 명확하게 정의 된 장기 실행 프로세스입니다. 이것이 Compose가 작동하는 기본 가정이며 우리가 구현하는 모든 기능은 아니지만 대부분의 설계를 안내합니다.
2. 이 정의에 따르면 "기본적으로 시작되지 않는 서비스"는 실제로 서비스가 아닙니다 [1]. 이는 컨테이너에서 실행되고 응용 프로그램의 일부가 아니라 응용 프로그램에서 작동하는 미리 정의 된 작업에 가깝습니다.

By that definition, a "service that is not started by default" is not really a service 주장이 사실이라고 생각하지 않습니다. 기본적으로 시작되지 않는 서비스는 기본적으로 시작되지 않는 서비스 일뿐입니다. 기본적으로 시작되는지 여부는 서비스가 오래 실행되는지 여부, 응용 프로그램의 일부인지 여부에 대해 아무 말도하지 않으며 기본적으로 시작되지 않는다는 의미 일뿐입니다.

그리고 그것은 또한 풀 리퀘스트의 변경이하는 일이기도합니다 : 서비스가 기본적으로 시작될 것인지 여부를 표시하는 기능을 추가하십시오.
이를 위해 작업과 같은 새로운 개념을 도입 할 필요가 없습니다. 사실 https://github.com/docker/compose/issues/1896#issuecomment -322285976의 다른 모든 인수는 2의 거짓 전제를 따르므로 아무 것도 시도하지 않는 풀 요청에는 적용되지 않습니다. 그밖에.

완전성을 위해 :

[1] 어떤 사람들은 "선택적 서비스"를 원한다고 언급하지만,이 글에서 언급 한 가장 일반적인 사용 사례는 아닙니다. 내가 말할 수있는 한 대부분의 사람들은 "작업"기능을 원합니다.

예, 일회성 작업의 예가 있었지만 정의에 따라 _real_ 서비스에 대한
이것을 사용하여 일회성 작업을 _also_ 실행할 수 있다는 점은 이에 대한 유효한 주장으로 받아 들일 수 없습니다. 오래 실행되지 않고 포트를 노출하지 않고 완전히 유효한 docker-compose.yml 에서 애플리케이션의 필수 부분이 아닌 _service_를 정의하는 것이 이미 가능합니다.

사실 이것은 또한 제안 된 해결 방법 중 하나입니다! _tasks_를 별도의 docker-compose.yml 로 분할하십시오.
언급 된 다른 해결 방법은 자신의 집에서 만든 (플랫폼에 따라 다름) 스크립트를 사용하는 것입니다.이 스크립트는 docker-compose의 자칭 목적에 완전히 모순됩니다 . 위의 내 의견을 참조하거나 단순히 다른 도구로 전환하는 것입니다. 현재 도구 체인에서 쉽게 구현할 수있는이 작은 기능을 편리하게 얻기 위해 잘 작동하는 도구 체인입니다 (도커 작성).

옵션 2의 가장 기본적인 구현에 대해 제기 된 유일한 실제 주장-즉, docker-compose 에 기본적으로 특정 서비스를 시작하지 않도록 지시하는 _some way_, 그리고 그 이상, 새로운 개념이나 기타 사항 없음- be_somehow_ _some_ 사용자에 의해 오용 될 수 있습니다.
그러나이 주장은 이에 대한 수요와 여기에 제기 된 합법적 인 사용 사례에 비해 상당히 약합니다.

@정강이-

뿐만 아니라 [3] 사람들에게 진정으로 유용한 기능이되기 위해 필요한 기능을 구현하거나 유지할 시간이나 자원이 없기 때문입니다.
[3] 그리고이 시점에서 저는 "I"를 의미합니다. 제가 현재 docker-compose에 대해 적극적으로 작업하고있는 유일한 관리자이기 때문입니다.

한편으로는 활성 유지 관리자가 한 명 뿐이고 다른 한편으로는 풀 리퀘스트를 무시하고 다른 개발자가 프로젝트에 참여할 수있는 기회를 낭비하는 것은 내가 이해할 수있는 일이 아닙니다.
# 3047에 제공된 코드 변경은 이미 _ [많은] 사람들에게 정말 유용 할 기능을 _do_ 구현하고 있습니다 _-아마도 _all_ of _their_ 사용 사례를 가진 사람들은 _all_ 아닐 수도 있지만 대부분의 사람들은 여기에 있습니다.

모든 추가 요구 사항-완전히 새로운 개념, 새로운 종속성 관리, 최대 cmake 와 같은 복잡성을 도입해야 함-단순히 잘못된 전제를 따르십시오!

나는 이와 같은 기능을 찾고 있었기 때문에 며칠 전에이 문제를 접했습니다.

불행히도 구현되지 않았기 때문에 내가 수집 할 수 있었던 것에서 공식적으로 지원되는 대안은 여러 yaml 파일을 사용하는 것입니다.

글쎄, 기본적으로 실행되지 않는 서비스에 대해 하나의 추가 설정을 포함하는 모든 서비스에 대해 하나의 yaml 파일을 사용하는 것과 비교할 때 기본적으로 실행되지 않는 서비스에 대해 여러 개의 yaml 파일을 사용하는 아이디어를 발견했습니다.

그래서 여기 내 +1이 있습니다.