Compose: 실행 후 명령 실행

Dockerfile의 단계 여야한다고 생각합니다.

FROM mongo:3.0.2
ADD data/mongodb/dumps/latest /data/mongodb/dumps/latest
RUN mongorestore -d database /data/mongodb/dumps/latest/database

이렇게하면 다시 빌드 할 때도 캐시됩니다.

감사합니다 @dnephin.
물론 Dockerfile을 만들어 이미지 대신 빌드에서 사용하거나 docker exec를 사용할 수 있습니다.
MongoDB는 예일 뿐이며 mysql 및 계정 생성 또는 rabbitmq 및 대기열 생성 등을 통해이 예를 가질 수 있습니다.

onrun 는 구성 오케스트레이션에 유연성을 허용하고 compose는 실행 목록을 읽고 각 항목에 대해 docker exec 를 만듭니다.

요점은 docker-compose.yml docker exec 에 Dockerfile 또는 컨테이너의 시작 스크립트에서 수행 할 수있을 때 명령을 넣을 필요가 없다는 것입니다. 둘 다 _not_ 때 컨테이너를 더 유용하게 만듭니다 Compose와 함께 실행됩니다.

또는 적절한 docker 및 docker-compose 명령을 실행하는 셸 스크립트 또는 Makefile을 사용하여 앱을 시작합니다.

이 기능은 둘 중 하나를 수행하는 것보다 중요한 가치를 추가하지 않는 한 Compose에 추가 할 가치가 없으며 귀하가 인용 한 사용 사례에는 적합하지 않을 것이라고 생각합니다.

따라서 내 도커를 관리하려면 Script 또는 Makefile을 사용하는 것이 좋습니다. 그래서 compose가 만들어진 이유
? 스크립트로 컨테이너를 관리하고 확장 할 수 있습니다 || dockerfile?

좋습니다.이 예제를 사용하여 CI 프로세스에서 내 애플리케이션 테스트 환경을 배포하는 데 사용했습니다.

rabbitmq:
    image: rabbitmq:3.5.1-management
    environment:
        RABBITMQ_NODENAME: rabbit
    hostname: rabbitmq
    domainname: domain.lan
    volumes:
        - /data/rabbitmq/db:/var/lib/rabbitmq
    ports:
        - "5672:5672" 
        - "15672:15672"
        - "25672:25672"
        - "4369:4369"

mongodb:
    image: mongo:3.0.2
    hostname: mongo
    domainname: domain.lan
    volumes:
        - /data/mongodb:/data
    ports:
        - "27017:27017" 

appmaster:
    image: appmaster
    hostname: master
    domainname: domain.lan
    environment:
        ...
    ports:
        - "80:80" 
        - "8080:8080"
    links:
        - mongodb
        - rabbitmq

celery:
    image: celery
    hostname: celery
    domainname: domain.lan
    environment:
        ...
    links:
        - rabbitmq

컨테이너가 시작된 후 mongodb를 프로비저닝하고 rabbitmq에서 대기열 및 계정을 관리해야합니다.

오늘 내가하는 일은 다음과 같은 스크립트입니다.

#!/bin/bash
PROJECT=appmaster
docker-compose -f appmaster.yml -p appmaster up -d
docker exec appmaster_rabbitmq_1 rabbitmqctl add_user user password
docker exec appmaster_rabbitmq_1 rabbitmqctl add_vhost rabbitmq.domain.lan
docker exec appmaster_rabbitmq_1 rabbitmqctl set_permissions -p rabbitmq.domain.lan password ".*" ".*" ".*"
docker exec appmaster_mongodb_1 mongodump --host mongo-prd.domain.lan --port 27017 --out /data/mongodb/dumps/latest
docker exec appmaster_mongodb_1 mongorestore -d database /data/mongodb/dumps/latest/database

onrun 명령으로 직접 docker-compose -f appmaster.yml -p appmaster up -d 만들 수 있습니다.
yml 파일이 더 읽기 쉬워집니다.

rabbitmq:
    ...
    onrun:
        - rabbitmqctl add_user user password
        - rabbitmqctl add_vhost rabbitmq.domain.lan
        - rabbitmqctl set_permissions -p rabbitmq.domain.lan password ".*" ".*" ".*"

mongodb:
    ...
    onrun:
        - mongodump --host mongo-prd.domain.lan --port 27017 --out /data/mongodb/dumps/latest
        - mongorestore -d database /data/mongodb/dumps/latest/database

이것은 다소 유용하고 사용 사례를 해결합니다.

: +1 :

docker-compose CD 파이프 라인의 일부로 게이트 테스트에 더 유용하게 사용할 수 있습니다.

: +1 :

이것은 # 877, # 1341, # 468 (및 기타 몇 가지)의 복제본입니다.

이를 지원하는 올바른 방법은 # 1510이며 원하는 이벤트에 도달했을 때 외부 도구가 작업을 수행 할 수 있도록하는 것입니다.

중복으로 닫기

이것은 매우 유용 할 것입니다. "오, bash 스크립트로이 작업을 수행 할 수 있습니다"라는 주장을 이해하지 못합니다. 물론 bash 스크립트로 할 수 있습니다. Docker-compose가하는 모든 작업을 bash 스크립트로 수행 할 수도 있습니다. 그러나 요점은 테스트 환경을 제어하는 ​​단일 YAML 파일이 있으며 간단한 docker-compose up 명령으로 실행할 수 있다는 것입니다.

쉘 스크립트 나 Makefile로 할 수있는 모든 작업을 수행하는 것은 Compose의 임무가 아닙니다. 유용성과 팽창 방지 사이의 균형을 맞추기 위해 어딘가에 선을 그려야합니다.

또한 Compose 파일의 중요한 속성 중 하나는 Mac, Linux 및 Windows 컴퓨터에서도 컴퓨터간에 이식이 가능하다는 것입니다. 사람들이 Compose 파일에 임의의 셸 명령을 넣을 수 있도록한다면 이식성이 훨씬 떨어질 것입니다.

@aanand 공정하게 docker exec 를 실행할 수 있다고해서 자동으로 x-plat 비 호환성을 의미하지는 않습니다.

사과-이 문제를 호스트 컴퓨터에서 명령을 실행하는 것으로 잘못 읽었습니다. 그래도 첫 번째 요점은 유효합니다.

@aanand의 요점을 이해합니다. 이미 docker-compose 는 command , expose 과 같이 일반 docker 엔진이 이미하는 것과 동일한 작업을 이미 많이 수행하므로 범위를 벗어난 것 같지는 않습니다 expose , ports , build 등. exec 기능을 추가하면 docker-compose 에 더 많은 기능을 추가하여 설정을위한 진정한 원 스톱 상점이됩니다. 개발 환경.

@aanand 많은 개발자 및 CI 파이프 라인의 주요 문제는 프로덕션 환경에 매우 가까운 데이터를 보유하는 것입니다. DB의 덤프처럼. 1 년 전에이 티켓을 만들었는데 도커에서 아무것도 작성하지 않았습니다.

따라서 일부 exec https://github.com/docker/compose/issues/1809#issuecomment -128073224를 실행하기 위해 Makefile 또는 Bashcript를 제안합니다.

내가 원래 제안한 것은 멱 등성을 유지하는 onrun (또는 oncreate)입니다. 처음 시작할 때 실행하십시오. 컨테이너가 중지되거나 일시 중지 된 경우 새 시작은 onrun (또는 oncreate)에서 실행되지 않습니다.

마지막으로 git 저장소에는 compose 파일, dockerfile 및 멱 등성 관리 기능이있는 makefile이 있습니다 (makefile이 상태 파일을 만들 수 있음). 천재!

command , expose 등과 exec 사이에는 큰 차이가 있습니다. 첫 번째 그룹은 컨테이너 옵션이고 exec 는 명령 / api 엔드 포인트입니다. 컨테이너 생성 기능에 대한 옵션이 아니라 별도의 기능입니다.

Compose (https://github.com/docker/compose/issues/1809#issuecomment-128059030)를 사용하여이 작업을 수행하는 몇 가지 방법이 이미 있습니다. onrun 이 (가) 이미 존재합니다. command 입니다.

데이터베이스에서 데이터를 덤프하거나로드하는 특정 문제와 관련하여 일반적으로 Makefile에서 수행되는 "워크 플로"또는 "빌드 자동화"유형의 작업입니다. 저는 컨테이너에서 모든 작업을 실행하는 dobi 라는 사용 사례를위한 도구를 프로토 타이핑했습니다. 또한 Compose와 매우 잘 통합됩니다. Makefile이 마음에 들지 않으면 사용해 보는 것이 좋습니다. 데이터베이스 초기화 /로드 사용 사례의 예를 작업 중입니다.

@dnephin onrun 은 멱 등성을 놓치기 때문에 단순한 command 가 아닙니다.

상상해 봅시다. 컨테이너 생성시 create 이며 다시는 exec가되지 않습니다 (덤프 및 복원).

exec:
    create:
        - echo baby
    destroy:
        - echo keny
    start:
        - echo start
    stop:
        - echo bye

더 많은 예가 필요한 경우 :

• 이 문제로 cmd 파일 생성 https://github.com/LarryEitel/phpdock/blob/master/dc.cmd-> juste compose up + exec
• 이 사람은 '흙손'을 사용하여 https://stackoverflow.com/questions/29303904/docker-compose-initialize-vs-run 을 해결합니다.

dobi 덕분에 작성을 향상시킬 도구를 만들어야하는 경우 작성이 나쁘고 더 강력한 도구를 사용하는 것이 좋습니다.

그러나 compose를 향상시키기 위해 도구를 만들어야하는 경우 compose는 좋지 않으며 더 강력한 도구를 사용하는 것이 좋습니다.

이는 "운영 체제를 향상시키기 위해 응용 프로그램이 필요한 경우 OS가 나쁩니다"라고 말하는 것과 같습니다. 어떤 도구도 모든 작업을 수행해서는 안됩니다. 유닉스 철학은 한 가지 일을하고 잘하는 것 입니다. 그것이 우리가 여기서하는 일입니다. Compose는 "애플리케이션 실행을위한 컨테이너 조정"을 수행합니다. 빌드 자동화 도구가 아닙니다.

이는 "운영 체제를 향상시키기 위해 응용 프로그램이 필요한 경우 OS가 나쁩니다"라고 말하는 것과 같습니다. 어떤 도구도 모든 작업을 수행해서는 안됩니다. 유닉스 철학은 한 가지를하고 잘하는 것입니다. 그것이 우리가 여기서하는 일입니다.

와우 최고의 악의에 도달했다고 생각합니다.

• 그렇다면 exec 가 코드와 cli 참조에있는 이유는 무엇입니까? https://docs.docker.com/compose/reference/exec/ ?
• 도 커가 유닉스 철학을 존중하지 않는 것이 오랜 시간이라고 생각합니다 https://coreos.com/blog/rocket

불행히도, 단순한 재사용 가능한 구성 요소는 일이 진행되는 방식이 아닙니다. 이제 Docker는 클라우드 서버를 시작하기위한 도구, 클러스터링을위한 시스템 및 다양한 기능 (이미지 빌드, 이미지 실행, 업로드, 다운로드, 결국에는 오버레이 네트워킹까지 포함)을 빌드하고 있으며, 모두 주로 서버에서 루트로 실행되는 하나의 모 놀리 식 바이너리로 컴파일됩니다. . 표준 컨테이너 선언문이 제거되었습니다. Docker 컨테이너에 대한 이야기를 중단하고 Docker 플랫폼에 대해 이야기를 시작해야합니다. 우리가 구상했던 단순한 구성 가능한 빌딩 블록이되지는 않습니다.

그래서 우리는 유닉스 철학을 유지하기 위해 도커 모 놀리 식 바이너리에 Go inside에서 쓴 "docker compose"를 결코 볼 수 없다는 것을 보장 할 수 있습니다. https://www.orchardup.com/blog/orchard-is-joining-docker

원래 목표를 계속하기 위해 Docker에 합류합니다. 무엇보다도 우리는 Fig를 사용하고 Fig의 가장 좋은 부분을 Docker 자체에 통합함으로써 Docker를 지금까지 본 최고의 개발 경험으로 만들기 위해 계속 노력할 것입니다.

간단히 말해서 compose를 사용하여 조명기를로드하는 것과 같은 작업을 수행 할 방법이 없습니다 ..? 깜짝 놀랐다 ..
공식적인 방법은 생산 컨테이너에 고정물 로딩을 추가하는 것입니까? 또는 내 compose 파일 주위에 쉘 스크립트를 작성하려면? 나중의 경우 이전처럼 'docker run'을 실행할 수도 있습니다.

@discordianfish , 만약 누군가가 CI / CD 엔지니어가 최소한 아주 기본적인 수준에서 라이프 사이클 이벤트와 오케스트레이션을 처리 할 수 ​​있어야한다는 사실을 깨달았다면 누가 docker / docker-compose가 로컬 개발 파이프 라인 및 테스트 인프라에서 벗어나 더 많은 프로덕션 환경에서 장소를 찾습니다. 스택에서 작업하는 사람이이 문제를 해결할 수 있기를 바랍니다.하지만 숨을 참지 않을 것입니다.

결국 빌드 시간에 수행해야하는 작업은 런타임에 필요한 작업과 다를 수 있으며 런타임에 필요한 작업은 배포 환경에 따라 다릅니다.

내 외부 스크립트가 컨테이너를 만들거나 시작할지 여부를 인식하도록 만드는 것은 일종의 성가신 작업입니다.

그리고 이것들은 수명주기 후크 + 명령 + 환경 변수가 도움이 될 수있는 것들입니다.

서비스 관리 프레임 워크 및 기타 오케스트레이션 도구에서 볼 수 있습니다. 왜 docker-compose에서 볼 수 없습니까?

https://github.com/dnephin/dobi에 관심이있을 수 있습니다.이 도구는 이러한 워크 플로를 위해 설계된 도구입니다.

@dnephin 은 도구로이 문제를 스팸하지 않습니다. 이전에 귀하의 의견을 보았고 대답은 동일합니다. Makefile / bash는 아마도 n 번째 "내 도구 향상 도커"보다 낫습니다.

건설적인 의견에 감사드립니다. 8 개월 전에이 스레드에서 이미 도비를 언급했다는 사실을 몰랐습니다.

Makefile / bash에 만족하신다면 좋습니다! 문제가 해결되어 다행입니다.

여기에이 주제와 관련된 댓글이 추가되었습니다. https://github.com/docker/compose/issues/1341#issuecomment -295300246

@dnephin , 내 의견을 적용 할 수 있습니다.

이 문제가 진화에 대한 약간의 불화로 인해 종결되어서 너무 슬프다 : 실망 :

Docker 구성의 가장 큰 가치는 표준화입니다.

그게 요점입니다. Docker Compose를 사용하지 않고 .sh 파일이나 작업을 수행하기 위해 "그냥"쓸 수 있다면 왜 Docker Compose가 존재합니까? : 혼란 :

@ shin-이 말했듯이 이것이 큰 일이라는 것을 이해할 수 있습니다.

안타깝게도 프로젝트의 해당 단계에서 지원하는 것은 너무 많은 부담입니다.

:심장:

하지만 "스크립트 만들기"라고 말할 수는 없습니다. "이봐, 너무 힘들어. 우리는 만들지 않을거야"라는 뜻입니다.

하기가 어렵다면 "당신의 아이디어가 흥미롭고 약간의 필요를 채워주지만, 정말 어렵고 우리는 지금 그것을 할 자원이 없습니다 ... 아마 당신은 그것을 개발하고 물어볼 수 있습니까? 풀 리퀘스트 "또는 그와 비슷한 것 : bulb :

# 1341에서는 docker-compose.yml 에서와 같이 일부 이벤트 (예 : 컨테이너 생성) 전후에 실행되는 nmp install 와 같은 docker-compose.yml 명령을 작성하는 방법을 "만"볼 수 있습니다 docker exec <container id> npm install 예를 들어

사용 사례

나는 사용자 정의 NodeJS 이미지를하고 난 실행하려면 npm install 으로, 그것에서 만든 용기에 docker-compose up --build .

내 문제는 응용 프로그램 코드가 컨테이너에 추가되지 않았으며 docker-compose.yml 정의 된 볼륨과 함께 탑재되어 있습니다.

custom-node:
    build: ../my_app-node/
    tty: true
    #command: bash -c "npm install && node"
    volumes:
     - /var/www/my_app:/usr/share/nginx/html/my_app

따라서 종속성을 확인하기 위해 애플리케이션 코드가 필요하기 때문에 Dockerfile에서 npm install 를 실행할 수 없습니다. 여기에 동작을 설명했습니다. http://stackoverflow.com/questions/43498098/what-is-the-order-of-events-in-docker-compose

npm install 를 실행하려면 해결 방법 인 command 문을 사용해야합니다.

command: bash -c "npm install && node"

정말 깨끗하지 않습니다 : 실망 : 그리고 Alpine 버전에서 실행할 수 없습니다 (Bash가 설치되어 있지 않습니다).

Docker Compose가 컨테이너, eG에서 exec 명령을 실행하는 방법을 제공 할 것이라고 생각했습니다.

custom-node:
    build: ../my_app-node/
    tty: true
    command: node
    volumes:
     - /var/www/my_app:/usr/share/nginx/html/my_app
    exec:
     - npm install

하지만 그렇지 않습니다. 정말 빠진 것 같습니다!

compose가 테스트 용으로 설계되었다고 생각했지만 아마도 틀렸을 것이며 로컬 개발 등을 위해 더 많은 것을 의도했습니다. 고아 컨테이너와 프로젝트 이름, 경로 및 소유권을 식별하는 데 사용되는 방법 사이의 불분명 한 관계와 같은 다른 거친 가장자리에 부딪 혔습니다. 같은 디렉토리 등에 여러 compose 파일이 있으면 어떻게됩니까? 그래서 모두 CI에 적합하지 않은 것 같습니다.
대신 kubelet을 독립 실행 형으로 실행하여 CI에서 프로덕션 k8 매니페스트를 재사용 할 계획입니다. 이것은 또한 많은 접착제가 필요하지만 적어도 이런 식으로 dev, test 및 prod에 대해 동일한 선언을 사용할 수 있습니다.

@ lucile-sticky는 알파인에서 sh -c 를 사용할 수 있습니다.

당신이 원하는 것은 docker-compose의 역할이 아닌 "빌드 자동화"인 것 같습니다. 도비 봤어 ?

두 가지 질문 :

• 이것이 Docker Compose의 역할이 아닌 이유는 무엇입니까?
• 핵심이 하나의 도구 만 사용하여 모두를 지배하는 것이라면 Docker Compose가 수행 할 수없는 작업을 완료하기 위해 다른 도구를 사용하는 이유는 무엇입니까?

이 기능은 매우 필요합니다!

@ lucile-sticky

이것이 Docker Compose의 역할이 아닌 이유는 무엇입니까?

Compose의 역할이 명확하게 정의되어 있고 이러한 기능을 포함하지 않기 때문입니다.

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

핵심이 하나의 도구 만 사용하여 모든 것을 지배하는 것이라면 Docker Compose가 수행 할 수없는 작업을 완료하기 위해 다른 도구를 사용하는 이유는 무엇입니까?

우리는 그들 모두를 지배하는 하나의 도구가되고 싶지 않습니다. 우리는 유닉스 철학을 따르고 "각 프로그램이 한 가지 일을 잘하도록 만든다. 새로운 작업을하려면 새로운 기능을 추가하여 기존 프로그램을 복잡하게 만들지 말고 새로 빌드하십시오."라고 믿습니다.
그 철학에 동의하지 않는 것은 괜찮지 만 Docker에서 소프트웨어를 개발하는 방법입니다.

저는 2015 년 8 월에이 문제를 작성합니다. 매년 누군가가 댓글을 추가하고 동일한 답변으로 동일한 질문을 반복하고 있습니다 (그리고 확실히 @dnephin 이 그의 도구에 대한 광고를 만드는 것을 볼 수 있습니다).

@정강이-

오케스트레이션 도구에서 "빌드"와 "프로비저닝"을 분리 할 수 ​​없습니다.

예를 들어 다음 중 하나를 알 수 있습니다.

• cloudformation : http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-init.html
• heat : https://docs.openstack.org/developer/heat/template_guide/software_deployment#configuring -with-scripts
• terraform : https://www.terraform.io/intro/getting-started/provision.html

서비스를 구성 할 때이를 프로비저닝해야합니다. 바람둥이를 배포하면 전쟁으로 프로비저닝해야하고, DB를 만들면 컨테이너가 어떻게 시작되어야하는지에 관계없이 데이터를 주입해야합니다 (이미지 유지 관리자가 관리하도록 함). Compose 사례에서 "프로 비 저너"의 주된 목적은 "컨테이너를 시작하는 항목"과 "컨테이너를 제공하는 항목"간의 오해를 방지하는 것입니다.

"Compose를 사용하면 Compose 파일을 사용 하여 응용 프로그램의 서비스를 그런 다음 단일 명령을 사용 하여 구성에서 모든 서비스를

유닉스 철학? 웃게 해주세요. 이 문제 https://github.com/docker/compose/issues/1809#issuecomment -237195021에서 한 것과 동일한 답변을 알려드립니다.
"moby"가 유닉스 철학에서 어떻게 발전 할 것인지 보자.

@shin docker-compose는 상상력의 확장으로 유닉스 철학을 고수하지 않습니다. docker-compose가 Unix 철학을 고수한다면 build, up, rm, start, stop 등 각각에 대한 개별 명령이있을 것이며 각각 일관되게 작동하는 사용 가능한 stdin, stdout 및 stderr을 가질 것입니다. System V, HP-UX, AIX, Solaris 및 Linux를 포함하여 20 년 이상의 경험을 가진 유닉스 시스템 관리자가 말합니다.

작성 개요로 돌아가 보겠습니다.

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

궁극적으로 docker-compose는 docker 이미지에서 생성 된 컨테이너를 기반으로 서비스 그룹을 관리하기위한 오케스트레이션 도구입니다. 주요 기능은 docker-compose.yml 파일에 정의 된 서비스를 '생성', '시작', '중지', '확장'및 '제거'하는 것입니다.

대부분의 서비스는 이러한 각 라이프 사이클 전환 동안 추가 명령을 실행해야합니다. 데이터베이스 클러스터를 확장하려면 종종 클러스터에서 멤버를 결합하거나 제거해야합니다. 웹 애플리케이션을 확장하려면 종종 구성원을 추가하거나 제거했음을로드 밸런서에 알려야합니다. 일부 편집증적인 시스템 관리자는 데이터베이스 로그를 강제로 비우고 데이터베이스를 종료 할 때 체크 포인트를 생성합니다.

대부분의 오케스트레이션 도구에는 상태 전환에 대한 조치가 필요합니다. AWS의 도구, Google의 도구, 감독, 요리사 등에서 찾을 수 있습니다.이 오케스트레이션 공간에있는 대부분의 항목에는 일종의 수명주기 후크가 있습니다.

나는 이것이 오케스트레이션 도구이고 상태 변화를 인식하고 있기 때문에 이것이 도커-컴 포즈의 영역에 확고하게 있다고 생각합니다. 이벤트 나 외부 스크립트가 사용 사례에 적합하지 않다고 생각합니다. 그들은 멱 등성이 아니며 이벤트를 따르기 위해 작성하는 '두 번째'서비스를 시작하는 것이 훨씬 더 어렵습니다. 후크가 컨테이너 내부 또는 컨테이너 외부에서 실행되는지 여부는 구현 세부 사항입니다.

하루가 끝나면 docker-compose 사용자가 표현하는 실제 요구가 있으며 @aanand , @dnephin , @ shin-은 그것을 무시하는 것 같습니다. 이것이 로드맵에 포함 된 것을 보는 것은 좋을 것입니다.

이러한 유형의 기능은 현재 테스트 및 프로덕션 프로덕션 배포에서 Docker 채택을 차단하고 있습니다. 나는 이것이 해고되기보다는 어떤 방식으로 해결되는 것을 정말로보고 싶다.

이것은 매우 유용 할 것이라고 생각합니다!

나에게 문제는 서비스 b를 실행하는 db 컨테이너 B에 의존하는 서비스 'a'를 실행하는 앱 컨테이너 A가있을 때입니다. 그런 다음 B가 설정되지 않으면 A 컨테이너가 실패합니다.
고유 한 Dockerfile을 다시 작성하는 대신 Docker 허브 이미지를 사용하는 것을 선호합니다. 그러나 이것은 A가 실패하고 컨테이너가 생성되지 않음을 의미합니다. 그렇지 않은 유일한 옵션은

1. B를 기본 이미지로 사용하고 고유 한 Dockerfile을 만듭니다.
2. A가 실패하고 스크립트에서 b를 구성하고 A를 다시 시작하십시오.

@ lucile-sticky와 똑같은 사용 사례를 사용했습니다.

@lekhnath 내 경우에, 나는 편집하여 그것을 해결 command 내에서 옵션 docker-compose.yml :

command: bash -c "npm install && node"

근데 너무 못 생겼어 TT

@ lucile-sticky 이것은 컨테이너의 Dockerfile 에 설정된 모든 명령을 무시한다는 점에 유의해야합니다. 내가 사용하여 사용자 정의 쉘 스크립트 설치하여이 문제를 해결했다 volumes 만드는 command 스크립트, 그리고 원본을 포함하여 나의 도커 작성 파일 실행에 CMD 로부터 Dockerfile .

이 문제가 종결 된 이유는 무엇입니까? _bash 스크립트 작성 _ 또는 _ 내가 작성한이 도구 사용 _은이 문제를 종결 할 유효한 이유가 아닙니다.

이것은 compose가 사용되는 많은 사용 사례에서 필요한 매우 유용하고 중요한 기능입니다.

@dnephin init 스크립트 실행이 컨테이너 기반 애플리케이션 배포 범위 밖에 있다고 생각하십니까? 결국 compose는 "Docker로 다중 컨테이너 응용 프로그램을 정의하고 실행"하는 것입니다.

당신이 여기에 그렇게하지 않았다면 누군가 도비를 보았습니다. :)

아무 일도 일어나지 않았다고 생각합니다. docker-compose 파일 내에서 @ ahmet2mir가 제공 한 예제와 같이 명령이 실행되어야하는시기를 기록 할 수있는 기능을보고 싶습니다.

이 기능이 구현되지 않은 것을보고 매우 슬픕니다.

이 기능을 구현하십시오. 컨테이너 초기화 후 파일을 복사해야하는 폴더가 생성되므로 Docker 구성 후 파일을 자동으로 설치해야합니다.
감사

이 기능이 아직 구현되지 않았다는 것이 놀랍습니다!

@dnephin은 매우 형편없는 형식입니다. 당신은 주로 자기 홍보로 보이는 기능에 대해 그렇게 많이 찾는 기능의 구현을 금지했으며 대화를 계속할 의사조차 없습니다.

죄송합니다. 좀 더 온화한 언어를 생각할 수 없었습니다.이 기능이 부족하여 다른 많은 개발자 및 팀과 마찬가지로 워크 플로에 일부가 추가되었으며이 문제를 해결하는 데 방해가되었습니다 ..

아, 그럼 unix-way 로합시다.
_Just_ (멀티 플렉스 후) docker-compose up stdin을 각 컨테이너의 CMD ?
그런 yaml 파일이

services:
  node:
    command: sh -

이 일을 할 것입니다 : cat provision.sh | docker-compose up
컨테이너는 exec uting을위한 것입니다. 명령을 전달하는 것보다 stdin을 더 잘 사용하는 것은 아닙니다.

대안은 다음과 같습니다.

services:
  node:
    localscript: provision.sh

프로비저닝 사용 사례의 99 %를 해결하는 약간의 쉘 중심이지만.

유효한 사용 사례가 있고 이에 대한 많은 찬성 투표가 있지만 ... 여전히 분명히 거부되었습니다. 여기에있는 다른 많은 사람들과 마찬가지로 저도 이것이 매우 유용하다는 것을 알게 될 것입니다.

기존 +의 큰 스택에 내 +1 추가

... 여기에 또 다른 +1!

이 기능에 대한 그러한 요청이 있으면 구현해야한다고 생각합니다. 우리의 목표를 달성하는 데 도움이되는 도구가 여기에 있으며 삶을 더 어렵게 만들지 않도록이를 성형해야합니다.
나는 누군가가 고수하는 철학을 이해하지만 어떤 종류의 "후크 명령"을 추가하는 것은 문제가되지 않아야합니다.

+1 +1

이 기능을 기다리는 동안 다음 스크립트를 사용하여 유사한 작업을 수행합니다.

docker-start.sh

#!/usr/bin/env bash

set -e
set -x

docker-compose up -d
sleep 5

# #Fix1: Fix "iptable service restart" error

echo 'Fix "iptable service restart" error'
echo 'https://github.com/moby/moby/issues/16137#issuecomment-160505686'

for container_id in $(docker ps --filter='ancestor=reduardo7/my-image' -q)
  do
    docker exec $container_id sh -c 'iptables-save > /etc/sysconfig/iptables'
  done

# End #Fix1

echo Done

@ reduardo7 그런 다음 docker-compose를 완전히 삭제하면 종속성이 하나 줄어 듭니다.

@omeid , 당신이 맞아요! 유사한 작업을 수행하는 해결 방법입니다. 죄송합니다!

@ reduardo7 사과 할 필요가 없습니다. 게시 한 내용이 일부 사람들에게 유용 할 것입니다.
나는 단지 원래의 문제가 여전히 유효하며 종결되어서는 안된다는 점을 지적했습니다. :)

@dnephin 의 스탠드를 이해합니다. 여기에 언급 된 기능은 충분히 다른 기능으로 대체 될 수 있습니다.

그러나 이러한 패턴이 자주 사용된다면 다른 사람들이 쉽게 사용할 수 있도록 가이드 (또는 일부 테스트)를 제시하는 것은 어떨까요?

이 패턴이 자주 사용될 수 있다는 데 동의하지 않는 것 같습니다.

@MaybeS 유일한 불일치는 @dnephin 이 docker-compose를 더 나은 제품으로 만드는 데 도움이되는 대신 그의 멍청한 도구가 홍보되는 것을 보는 것입니다.

@omeid 그렇습니다.

onrun 형식을 작성하는 방법을 원하는 오늘의 예

version: "3.3"
services:
  gitlab:
    image: 'gitlab/gitlab-ce:latest'
    restart: always
    hostname: 'gitlab'
    environment:
      GITLAB_OMNIBUS_CONFIG: |
        # NOTE: this URL needs to be right both for users, and for the runner to be able to resolve :() - as its the repo URL that is used for the ci-job, and the pull url for users.
        external_url 'http://gitlab:9090'
        gitlab_rails['gitlab_shell_ssh_port'] = 2224
    ports:
      - '9090:9090'
      - '2224:22'
  gitlab-runner:
    image: gitlab/gitlab-runner:latest
    volumes:
    - /var/run/docker.sock:/var/run/docker.sock

물론 주자는 등록되지 않았습니다. 그렇게하려면

1. gitlab의 데이터베이스에서 토큰을 가져옵니다.
2. 러너 컨테이너에서 레지스터 실행

따라서 docker-compose에서 다중 컨테이너 응용 프로그램의 배포를 정의하는 대신 보조 수단을 사용해야합니다.이 경우 ... 문서?

export GL_TOKEN=$(docker-compose exec -u gitlab-psql gitlab sh -c 'psql -h /var/opt/gitlab/postgresql/ -d gitlabhq_production -t -A -c "SELECT runners_registration_token FROM application_settings ORDER BY id DESC LIMIT 1"')
docker-compose exec gitlab-runner gitlab-runner register -n \
  --url http://gitlab:9090/ \
  --registration-token ${GL_TOKEN} \
  --executor docker \
  --description "Docker Runner" \
  --docker-image "docker:latest" \
  --docker-volumes /var/run/docker.sock:/var/run/docker.sock \
  --docker-network-mode  "network-based-on-dirname-ew_default"

음, 뭔가 해킹 할 수 있을지도 몰라 도커 소켓이있는 다른 컨테이너가 있고 docker exec's

내기해야 할 방법이 있습니다 ....

예를 들어 다음을 추가 할 수 있습니다.

  gitlab-initializer:
    image: docker/compose:1.18.0
    restart: "no"
    volumes:
    - /var/run/docker.sock:/var/run/docker.sock
    - ./gitlab-compose.yml:/docker-compose.yml
    entrypoint: bash
    command: -c "sleep 200 && export GL_TOKEN=$(docker-compose -p sima-austral-deployment exec -T -u gitlab-psql gitlab sh -c 'psql -h /var/opt/gitlab/postgresql/ -d gitlabhq_production -t -A -c \"SELECT runners_registration_token FROM application_settings ORDER BY id DESC LIMIT 1\"') && docker-compose exec gitlab-runner gitlab-runner register -n --url http://gitlab:9090/ --registration-token ${GL_TOKEN} --executor docker --description \"Docker Runner\" --docker-image \"docker:latest\" --docker-volumes /var/run/docker.sock:/var/run/docker.sock --docker-network-mode  \"simaaustraldeployment_default\""

내 작성 파일에-gitlab이 즉시 준비되지 않았기 때문에 일종의 루프 / 기다림이 필요하지만 sleep 200 로는 충분하지 않을 수 있습니다.

그래서-당신은 __can__ docker-compose.yml 에서 직접 이와 같은 패턴을 해킹합니다-하지만 개인적으로 저는 이것보다 더 깨끗한 지원을 원합니다 :)

@SvenDowideit onrun 이 (가) 이미 존재합니다. entrypoint 또는 cmd 입니다.

이 이미지의 진입 점 스크립트는 사용자에게 후크를 제공합니다. $GITLAB_POST_RECONFIGURE_SCRIPT 는 모든 설정이 완료된 후 실행할 스크립트의 경로로 설정할 수 있습니다 (이미지에서 /assets/wrapper 참조). env 변수를 psql + register를 수행하는 스크립트 경로로 설정하면 모든 설정이 완료됩니다.

이미지가이 후크를 제공하지 않더라도 이미지를 확장하면 상당히 쉽게 추가 할 수 있습니다.

gitlab이 바로 준비되지 않았기 때문에 일종의 루프 / 기다림이 필요하지만 sleep 200은 충분하지 않을 수 있습니다.

"exec-after-start"옵션을 사용하는 경우에도 필요합니다. 진입 점 스크립트는 실제로 후크를 제공하기 때문에 해당 솔루션에서는 필요하지 않을 것입니다.

아니요, 제가 보여주고있는 문제의 일부를 놓친 것 같습니다.

제 경우에는 하나가 아닌 두 컨테이너 모두에 대한 액세스가 필요합니다. 그래서 진입 점 / 명령은 이것을 제공하지 _ 않습니다 _.

GL_TOKEN 는 gitlab 컨테이너에서 가져온 다음 gitlab-runner 컨테이너에서 등록하는 데 사용됩니다.

그래서 제가하고있는 해킹은 docker/compose 이미지를 사용하여 세 번째 컨테이너를 추가하는 것입니다. 이것은 한 컨테이너의 config / entrypoint / settings를 수정할 수있는 것이 아니며, 완전히 (사소한) 예제입니다. 더 많은 것을 필요로하는 다중 컨테이너 조정.

나는 그것들을 좀 더 마법처럼 만들기 위해 작업하고 있습니다. 즉, 기본적으로 gitlab이 자체적으로 초기화하는 데 시간이 걸리기 때문에 내 초기화 컨테이너에 약간의 수면 루프가 있음을 의미합니다.

TBH, 저는 compose 파일 자체와 docker / compose 이미지를 사용하는 init-container에서 실행되는 스크립트를 사용하여 이러한 종류의 복잡성을 숨기는 올바른 방법이라고 느끼기 시작했습니다. 나를 밖으로, 그리고 그것은 단지 작동 할 것입니다 "이런 상황.

_IF_ 나는 도움이 될 이상한 구문 적 설탕을 고려해야했다. 아마도 나는 다음과 같은 것을 할 것이다.

gitlab-initializer:
    image: docker/compose:1.18.0
    restart: "no"
    volumes:
    - /var/run/docker.sock:/var/run/docker.sock
    - ./gitlab-compose.yml:/docker-compose.yml
    entrypoint: ['/bin/sh']
    command: ['/init-gitlab.sh']
    file:
      path: /init-gitlab.sh
      content: |
            for i in $(seq 1 10); do
                export GL_TOKEN=$(docker-compose -f gitlab-compose.yml -p sima-austral-deployment exec -T -u gitlab-psql gitlab sh -c 'psql -h /var/opt/gitlab/postgresql/ -d gitlabhq_production -t -A -c "SELECT runners_registration_token FROM application_settings ORDER BY id DESC LIMIT 1"')
                echo "$i: token($?) == $GL_TOKEN"
                ERR=$?

                if [[ "${#GL_TOKEN}" == "20" ]]; then
                    break
                fi
                sleep 10
            done
            echo "GOT IT: token($ERR) == $GL_TOKEN"

            for i in $(seq 1 10); do
                if  docker-compose -f gitlab-compose.yml  -p sima-austral-deployment exec -T gitlab-runner \
                    gitlab-runner register -n \
                    --url http://gitlab:9090/ \
                    --registration-token ${GL_TOKEN} \
                    --executor docker \
                    --description "Docker Runner" \
                    --docker-image "docker:latest" \
                    --docker-volumes '/var/run/docker.sock:/var/run/docker.sock' \
                    --docker-network-mode  "simaaustraldeployment_default" ; then
                        echo "YAY"
                        break
                fi
                sleep 10
            done

즉, cloud-init : http://cloudinit.readthedocs.io/en/latest/topics/examples.html#writing -out-arbitrary-files

그러나 그것에 관해서는-우리는 docker-compose-yml 내부에서 복잡한 다중 컨테이너를 조정하는 솔루션을 가지고 있습니다.

사전 정의 된 토큰을 설정할 수있는 경우 gitlab-runner 의 진입 점 스크립트에서 설정할 수 있습니다. 시간의 선두를 정할 방법이 없습니까?

@dnephin 당신이 대본을 언급하는 순간, 당신은 지나고 나서 약간의 족적을 벗어났습니다.

onrun 는 entrypoint 또는 cmd 와 동일하지 않습니다.

entrypoint / cmd 는 컨테이너 init / PID 1로 실행될 실행 파일을 구성하기위한 것입니다.

이 문제와 많은 관련 문제에서 언급 된 아이디어는 init scripts 에 대한 것인데, 이는 부팅의 맥락에서 init 와 다르며 응용 프로그램 초기화 스크립트에 관한 것입니다.

@dnephin 특정 컨테이너 세트의 문제를 해결하기보다는 일반적인 문제 세트에 초점을 맞춘 경우 더 유용 할 것입니다.

그러나 내가 본 것에서, 그것은 생성 된 비밀입니다. 그러나 실제로 이것은이 작은 플레이 시스템의 유일한 다중 컨테이너 조정 요구 사항이 아닙니다. 공개적으로 프로토 타입.

v1 이후 compose 파일에서 entrypoint 및 command 를 재정의 할 수 있었던 방법은 무엇입니까? -v1 / # entrypoint) 컨테이너가 작동 중일 때 명령을 실행하기위한 onrun 와 같은 지시문이 아직 없습니까?

TBH, 저는 onrun 이 그럴듯하다고 생각하지 않습니다. Docker, 또는 오케 스트레이터가 "컨테이너가 모두 작동했습니다"가 무엇을 의미하는지 알지 못합니다. 제 경우에 HEALTHCHECK는 실패합니다. 하나의 컨테이너에서 정보를 얻고 다른 컨테이너에서 다른 것들을 시작하는 데 사용하는 추가 "물건"입니다.

그리고 _if_ 맞아요, 이것은 기본적으로 멀티 컨테이너 시스템의 일부가 작업을 수행 할 수있을만큼 충분히 준비되었는지 감지하는 코드를 포함하는 연산자 컨테이너가 필요하다는 것을 의미합니다. 작업을 완료하고 종료하거나 심지어 모니터링하고 수정합니다.

그리고 이것은 코드가있는 도커 작성 컨테이너에 의해 (도커 작성에서) 가장 잘 해결되는 작업처럼 느껴집니다.

이 연산자를 도커 무리 스택을 처리 할 수있는 것으로 변환하는 방법을 가지고 놀 것입니다 (다른 프로젝트 요구 사항으로 인해).

컨테이너에 "이것은 운영자입니다. 마법 능력을 부여하십시오"라고 표시하는 것과 같은 것이 아니라면 docker-compose에 추가 할 수있는 구문 설탕이 많이 있는지 확신 할 수 없습니다.

개발자가 사용자의 말을 듣고 싶지 않다는 것이 분명해졌습니다 .. 다른 도구를 살펴 보겠습니다. docker-compose가 큰 고통입니다. docker-composer에서 빌드 도구입니다 ... 저는 SIMPLE 명령을 실행하여 활성 사용자에게 컨테이너 내부의 권한을 추가하는 방법을 검색하는 데 많은 시간을 보냈습니다.

docker-composer는 단순히 NOT DONE 상태가있는 것 같습니다.

나도 내 작성 파일에 onrun 이 될 것을 원합니다.

__BUT__, 컨테이너도 작성도 onrun 의미를 알 수있는 방법이 없습니다. 이것이 연산자 패턴이 존재하는 이유이며 https://github.com/docker/compose/issues/1809#issuecomment -362126930에서 예제를 만든 이유입니다.

오늘이 작업을 __is__ 가능합니다. 본질적으로 다른 서비스가 실제로 상호 작용할 준비가 될 때까지 기다리는 onrun 서비스를 추가 한 다음 (gitlab의 경우에는 상당한 시간이 걸립니다) 조정하기 위해해야 ​​할 일은 무엇이든.

그것으로 작동하지 않는 무언가가 있다면, 저희에게 알려주세요. 우리가 무언가를 알아낼 수 있는지 보겠습니다!

나도 작성 파일에서 실행될 무언가를 원합니다.

그러나 컨테이너도 구성도 onrun이 의미하는 바를 알 수있는 방법이 없습니다.

내가보기에 서비스 당 onrun 는 첫 번째 컨테이너 프로세스가 시작되는시기를 의미합니다. 대부분의 경우 컨테이너는 컨테이너를 실행하는 데 권장되는 방법이므로 어쨌든 하나의 프로세스 만 실행합니다.

크로스 플랫폼 지원 문제는 RUN이 Dockerfile에서 Linux 명령을 의미 할 필요가없는 것과 같은 방식으로 docker exec 통해 명령이 완전히 OS에 구애받지 않을 수 있으므로 이전에 해결되었습니다.
https://docs.microsoft.com/en-us/virtualization/windowscontainers/manage-docker/manage-windows-dockerfile

onrun 기능 대기 중

이 onrun 기능도 필요합니다.이 도구에 있다고 생각했습니다. 이 기능이 부족하기 때문에 이제 2 개의 스크립트를 유지해야합니다.

여러분,이 docker-compose 래퍼를 만들고이 onrun 기능을 허용하면 어떨까요? 너희들은 그것을 사용 하시겠습니까?

@wongjiahau 는 https://github.com/docker/compose/issues/1809#issuecomment -348497289

@ reduardo7 예, docker-composei 라는 스크립트와 onrun 속성을 포함하는 docker-composei.yml 로 래핑 할 생각이었습니다.
Btw, docker-composei 는 docker-compose improved 합니다.

실제 솔루션은 아마도 내부적으로 '앱 이미지'(아마도 도커를 사용)를 실행하고 관리하는 (bash 스크립트를 통해) '오케 스트레이터'이미지를 빌드하는 것입니다. 그렇지 않으면 "원하는 작업을 수행하기위한 것이 아닌"도구에 대해 더 많은 기능을 항상 요구할 것입니다.

따라서 Docker 내에서 Docker를 고려해야합니다.

이 제안 된 기능에 대한 지원을 추가하기 위해. onrun은 의미가 있지만 잠재적 인 유틸리티와 미래의 증거를 조금 확대하려면 누군가가 더 광범위한 'onevent'아키텍처를 살펴 봐야하며 그중 하나는 onrun입니다.

컨테이너가 컨테이너 당 하나의 서비스를 자체 포함해야하는 일반적인 방향을 고려할 때 컨테이너는 작동 상황 인식 측면에서 자체적으로 충분해야합니다. 작성 파일에서 나오는 것은 볼트 연결 스크립트가 아니라이를 정의하는 매체가되어야합니다. 당신이 자기 열광적 인 열광자가 아니라면 그것에 대해 논쟁하기는 어렵습니다.

제 경우에는 redis 컨테이너가 redis 서버가 시작된 후 lua 스크립트를로드합니다. 일반적인 비 컨테이너 환경에서는 시작 후 스크립트를 실행하도록 systemd됩니다. 시스템 아키텍처와 단순하고 일관성이 있습니다. 컨테이너가 실행할 컨텍스트를 설정하는 역할을 고려할 때 compose에 대해서도 유사한 원칙이 존재해야합니다.

메인테이너에 대한 일반적인 조언으로 개인적 선호가 아닌 입증 된 운영 원칙에 초점을 맞추십시오.

그래서 해결책은 (이 모든 스레드를 읽은 후) bash 스크립트를 사용하여 작업을 수행하는 것입니다.

thx dev는 당신의 물건을 사용하는 사람들의 말을 듣고 :)

간단한 제안 (예 : 온런 이벤트)과 싸우는 논쟁 및 반론이 포함 된 메시지의 양을 보면 Github Issues가 _owners_ (프로젝트 개발자)가 사용을 통해 자신의 자아와 현명함을 보여주는 곳으로 바뀌 었다는 첫 번째 솔직한 인상은 사용자의 지능적인 기여에 반대하는 그들의 지식과 기술적 인 아르곤.

제발, 오픈 소스를 진정으로 _open_합시다.

이 기능에 대한 업데이트가 있습니까? 무엇이 문제입니까?

@ v0lume 이 기사 전체에서 실제로 답변을 읽는 것을 귀찮게하지 않은 것 같습니다.

여전히 해결책이없는 것 같습니다 ... 그래도 해키 해결 방법을 공유하고 싶습니다.
docker-compose.yml에서 버전 "2.1"을 지정하면 상태 확인 테스트를 남용하여 시작될 때 이미지 내에서 추가 코드를 실행할 수 있습니다. 다음은 그 예입니다.

version: '2.1'
services:
    elasticsearch:
        image: docker.elastic.co/elasticsearch/elasticsearch:5.4.3
        healthcheck:
            test: |
                curl -X PUT elasticsearch:9200/scheduled_actions -H "ContentType: application/json" -d '{"settings":{"index":{"number_of_shards":'1',"number_of_replicas":'0'}}}' &&
                curl --silent --fail localhost:9200/_cat/health ||
                exit 1
            interval: 11s 
            timeout: 10s 
            retries: 3
        environment:
            - discovery.type=single-node
            - ES_JAVA_OPTS=-Xms1g -Xmx1g
            - xpack.security.enabled=false
    main:
        image: alpine
        depends_on:
            elasticsearch:
                condition: service_healthy

작성한 healthcheck-test 스크립트가 코드> = 1로 종료되면 여러 번 실행될 수 있습니다.
서비스의 상태 확인은 다른 서비스가 여기에 의존하고 예제에 표시된 것처럼 service_healthy 조건을 지정하는 경우에만 실행됩니다.

나는 @ T-vK 접근 방식을 좋아하고 이전에 성공적으로 사용했습니다. 하지만 다른 해킹을 공유하고 싶습니다.

# Run Docker container here

until echo | nc --send-only 127.0.0.1 <PORT_EXPOSED_BY_DOCKER>; do
  echo "Waiting for <YOUR_DOCKER> to start..."
  sleep 1
done

# Do your docker exec stuff here

+1
기능이 필요하고 이미 kubernetes와 같은 다른 도커 오케 스트레이터에 의해 구현 되었기 때문에 나는 이것에 전적으로 동의합니다. 이미 컨테이너에 대한 라이프 사이클 후크가 있으며 여기 에 문서화되어

하지만 Dockerfiles로 해결할 수없는 사용 사례를 제공하겠습니다.

런타임에 볼륨을 마운트하고 이전에 디렉토리의 정확한 이름을 몰라도 컨테이너에서 볼륨으로의 심볼릭 링크를 만들어야한다고 가정 해 보겠습니다. 배포하는 환경에 따라 dir 이름이 동적이라는 경우가 있었고 변수로 전달했습니다.

물론이 문제를 해결할 해결 방법을 찾았으며 둘 이상이 있습니다. 반면에 후크는 해킹하고 Dockerfile을 교체하지 않고도 동적으로 변경할 수있는 유연성과 더 나은 접근 방식을 제공합니다.

이 문제를 발견하게되어 기쁩니다. 나는 몇 년 동안 Docker와 Docker compose를 가지고 놀았습니다. 이제 진지하게 시스템 확장을 시작하는 도구로 사용하기를 원했습니다. 1 ~ 2 년에 한 번 확인 하겠지만 프로젝트 관리자의 태도에 따라 스크립트 나 다른 도구를 사용하면됩니다. 많은 시간을 투자하지 않아서 기쁩니다.

프로 팁 : 워크 플로를 이러한 유형의 도구로 이동하기 시작한 사람이 이미 여기에 설명 된 내용이 필요한 경우이를 구축하는 '이유'에 대해 다시 생각할 가치가 있습니다. 예, 당신은 성공했습니다.하지만 사람들이 애초에 그 것을 사용했기 때문에 당신은 아마도 그들에게 필요한 것을 줄 수있는 매우 개방적이었을 것입니다.

모두 제일 좋다.

이 기능이 구현되면 내가 원하는 것은 무엇이든 줄 수 있습니다 (내 여자 친구 제외). 나는 모든 우주에서 가장 행복한 사람이 될 것입니다 :)

이 제안 된 기능에 대한 지원을 추가하기 위해. onrun은 의미가 있지만 잠재적 인 유틸리티와 미래의 증거를 조금 확대하려면 누군가가 더 광범위한 'onevent'아키텍처를 살펴 봐야하며 그중 하나는 onrun입니다.

그것은 좋을 것입니다.

여기에 추가하려면 다음과 같이하십시오.

services:
    web:
        image: node:8-alpine
        depends_on:
            - db
    db:
        image: postgres:alpine
        onrun: "echo hi"

교차 이벤트 스크립트를 추가하는 것이 너무 많습니까?

    web:
        events:
            db_onrun: "connectAndMigrate.sh"

제 생각에 이것을 docker-compose에 추가하는 것은 compose 파일 및 compose 스택을 사용하는 귀하뿐만 아니라 팀의 다른 개발자에게도 간단합니다.

• 별도의 컨테이너 사용-모두가 컨테이너를 실행해야한다는 것을 알아야합니다.
• 커스텀 Dockerfile 작성-약 20 개의 서비스가 있으며 모든 서비스에 대해 Dockerfile을 재정 의하여 명령을 실행해야합니다.

예를 들어 신뢰할 수있는 인증서를 갖도록 모든 환경에 mkcert 를 설치하고 구성해야합니다. 스테이지 / 프로덕션에서 필요하지 않으므로 컨테이너 또는 Dockerfile의 일부가 아닙니다. 도구를 설치하는 적절한 접근 방법은 무엇이며 compose 파일을 사용하는 모든 사람은 뒤에서 무슨 일이 벌어지고 있는지 전혀 알지 못합니다.

다른 사용 사례 추가 :

워드 프레스 인스턴스가 필요했습니다. 내 docker-compose.yaml을 작성했습니다. docker-compose up – 죄송합니다! 플러그인 디렉터리의 파일 권한을 설정해야합니다 ... 다른 방법을 찾을 수 없습니다. 컨테이너가 실행 된 후 권한을 설정해야합니다. 호스트에서 일부 파일을 바인딩하고 있고 유일한 방법 인 것 같습니다. fs 권한을 수정하려면 컨테이너 내부에서 chown -Rf www-data.www-data /var/www/wp-content 을 수행합니다. 내 자신의 Dockerfile을 작성하고 빌드하십시오. 저에게는 어리석은 것 같습니다.

다행히도 위에 제공된 healthcheck 해킹을 통해이를 구현할 수있었습니다. 도커 볼륨에 대한 설정 권한 문제에 대해 웹에서 다른 페이지를 볼 수 있지만 제안 된 솔루션이 작동하지 않았습니다.

이 게이트 키퍼 @dnephin , @aanand , @ shin-이이를 위해 엄청난 열을 받고 있다는 것을 알게되어 기쁩니다. 전체 커뮤니티가 가능한 한 큰 소리로 비명을 지르고 핵심 개발자가 자리를 잡고 자리를 잡고 듣지 않을 때 정말 큰 소리를냅니다. 너무 일반적입니다. 좋아요의 수뿐만 아니라 이것이 필요하다고 답한 34 명의 사용자도 세어 보겠습니다.
01) sshishov
02) 페스 코바
03) sandor11
04) 웹 기반
05) v0lume
06) 웹 폴리스
07) 스컬 오네
08) usergoodvery
09) 웡자 하우
10) MFQ
11) 요세 프로
12) 배거 맨
13) daqSam
14) 오 메이드
15) 단테 바르바
16) 윌리 양
17) SharpEdgeMarshall
18) 분실 캐리어
19) 유령
20) 로드리고 로드리게스 코스타
21) 데이터 유형
22) 덱스 텀브
23) 레크 나스
24) 루실 끈적
25) rav84
26) 도프 리
27) 아멧 투 미르
28) montera82
29) Discordianfish
30) jasonrhaas
31) 페라리 스
32) 하이퍼 긱
33) 양산
34) 스툴 브

그리고 거절 한 번호는? 무려 3 :
01) 드네 핀
02) 아난드
03) 신-

음 ... 34 ~ 3 ...

@ rm-rf-etc 좋은 분석 ... @dnephin 또는 @aanand 가 더 이상 docker-compose 작업을한다고 생각하지 않습니다. 운이 좋으면 Docker는 스택을 위해 compose를 사용하지 않을 계획이며 여기에 불만을 제기 할 팀이 남아 있지 않으며 제품에 대한 향후 진행 상황을 다시보기 시작할 것입니다.

다른 사용 사례 추가 :

워드 프레스 인스턴스가 필요했습니다. 내 docker-compose.yaml을 작성했습니다. docker-compose up – 죄송합니다! 플러그인 디렉터리의 파일 권한을 설정해야합니다 ... 다른 방법을 찾을 수 없습니다. 컨테이너가 실행 된 후 권한을 설정해야합니다. 호스트에서 일부 파일을 바인딩하고 있고 유일한 방법 인 것 같습니다. fs 권한을 수정하려면 컨테이너 내부에서 chown -Rf www-data.www-data /var/www/wp-content 을 수행합니다.

이 경우 Compose 파일에서 user 속성 을

내 자신의 Dockerfile을 작성하고 빌드하십시오. 저에게는 어리석은 것 같습니다.

강한 의견을 내놓은 것 같습니다. 그러나 현실적으로 필요에 맞게 기본 이미지를 수정하기 위해 Dockerfile을 작성하는 것에 대해 "어리석은"것은 없습니다. 이것이 모든 기본 이미지의 원래 의도입니다.

다행히도 위에 제공된 healthcheck 해킹을 통해이를 구현할 수있었습니다. 도커 볼륨에 대한 설정 권한 문제에 대해 웹에서 다른 페이지를 볼 수 있지만 제안 된 솔루션이 작동하지 않았습니다.

이 게이트 키퍼 @dnephin , @aanand , @ shin-이이를 위해 엄청난 열을 받고 있다는 것을 알게되어 기쁩니다.

그래, 좋은 태도 친구. :디

@ rm-rf-etc 좋은 분석 ... @dnephin 또는 @aanand 가 더 이상 docker-compose 작업을한다고 생각하지 않습니다.

예, 이제 몇 년이 지났습니다. 오래된 문제에 대해 계속 핑할 필요가 없습니다.

운이 좋으면 Docker는 스택을 위해 compose를 사용하지 않을 계획이며 여기에 불만을 제기 할 팀이 남아 있지 않으며 제품에 대한 향후 진행 상황을 다시보기 시작할 것입니다.

🙄

@ shin-하지만 당신은 그 응답으로 그것을 핑했습니다.

최근 에이 문제가 다시 발생했으며 내 해결 방법 에서 볼 수 있듯이 수행 할 수 있지만 2.1을 지정하는 경우에만 작동합니다.

모든 것에 대해 고유 한 도커 이미지를 만들어야한다는 공식 입장이 나에게는 놀랍습니다.
나에게 이것은 문자 그대로 "어떤 프로그램에서 설정을 변경하려면 소스 코드를 수정하고 다시 컴파일해야합니다."라고 말하는 것과 같습니다.
새 서비스를 추가하거나 MongoDB 또는 MySQL Docker 이미지와 같은 ..의 새 버전으로 업그레이드 할 때마다 새 Dockerfile을 만들고 빌드 한 다음 잠재적으로 레지스트리에 푸시해야합니다.
이는 docker-compose.yml에서 image: mongo:3.0.2 를 image: mongo:3.0.3 로 변경할 수있는 방법에 비해 엄청난 시간과 리소스 낭비입니다.
나는 긴 빌드 시간에 대해 외치는 것이 아니라 잠재적으로 균등하지 않은 서비스의 매개 변수를 업데이트하거나 변경하는 것이 원할 때 Dockerfiles 및 docker build 로 귀찮게해야한다는 사실에 대해 외치고 있습니다. 기본 이미지로 사용됩니다.

그리고 모든 응용 프로그램이 한 가지 일만 수행해야한다는 주장도 정말 악취가납니다. 이것은 완전히 새로운 기능을 구현하는 것이 아니라 docker 통해 다른 매개 변수를 전달하는 것입니다. 또한 docker run , docker build , docker exec , docker pull 등이 모두 동일한 응용 프로그램의 일부인 이유에 대해서도 질문합니다. 논쟁이 지금은 위선적으로 들리지 않습니까?

@ shin-, 나는 당신의 링크를 따라 갔고 사용자 속성이 바인드 마운트 디렉토리의 소유자를 설정하는 것과 어떤 관련이 있는지 알지 못합니다. 포트와 관련된 것 같습니다.

Re : 태도 : 사람들이 저에게 동의하는 것 같으니 강력한 피드백으로 받아들이세요. 내가 이것을 표현하는 방식이 마음에 들지 않으면 미안하지만 사용자의 요구가 무시되는 것 같습니다. 그렇다면 다른 무엇을 기대하십니까?

나는 onrun과 같은 기능을 기대하며 여기에 왔습니다. compose를 사용하는 데 이틀 밖에 걸리지 않았고 이와 같은 도구가이 기능을 가지고 있어야하기 때문에 제안되었습니다.

내 도커 파일로 돌아가 기능에 대한 별도의 스크립트로 각각을 업데이트하는 것은 중복되는 것처럼 보입니다. 다른 컨테이너의 토큰을 이전에 내 dockerfile이 유연했던 환경 변수에 주입하고 싶을뿐입니다. 이제 간단한 목적을 위해 docker-composer.yml 및 솔루션과 밀접하게 연결됩니다.

젠장, 나는 "좋아, 우리는 이것이 멋지다는 것을 마침내 깨달았고 우리는 그것을 구현할 것이다"라는 답을 찾기 위해 전체 스레드를 읽었다. 이것이 앞으로 나아 가지 않은 것을보고 슬프다.
온런에 +1!

@fabiomolinar , 우리가 생산 무리에서 광범위하게 사용하는 한 가지 종류의 솔루션이 있지만 이벤트를 갖는 것만 큼 좋지는 않습니다.

다음 앵커를 사용합니다.

#### configure a service to run only a single instance until success
x-task: &task
  # for docker stack (not supported by compose)
  deploy:
    restart_policy:
      condition: on-failure
    replicas: 1
  # for compose (not supported by stack)
  restart: on-failure

성공할 때까지 작업을 반복합니다. 우리는 멱등 한 결과를 가진 마이그레이션 및 설정 작업을위한 컨테이너를 만들고 로컬 작성 및 스택에서 이와 같이 실행합니다.

작업에 의존하는 서비스는 구성 작업이 완료되지 않은 경우 다소 정상적으로 실패해야합니다. 대부분의 경우 최종 사용자에게 몇 가지 오류가 발생해도 괜찮다면 대부분의 환경에서 잘 작동하는 최종 일관성을 얻을 수 있습니다.

또한 서비스 컨테이너가 작업 완료 전후 상태 모두에서 작동 할 수 있다고 가정합니다. 데이터베이스 마이그레이션과 같은 사용 사례에서 종속 서비스는 마이그레이션 전 및 마이그레이션 후 스키마 모두에서 작동 할 수 있어야합니다. 분명히 개발 및 배포 조정에 대해 몇 가지 생각을해야하지만 이는 일반적인 사실입니다. 서비스의 롤링 업데이트 수행.

@fabiomolinar , 다음은 작성 서비스에서이 접근 방식을 사용하는 방법의 예입니다 ...

#### configure a service to run only a single instance until success
x-task: &task
  # for docker stack (not supported by compose)
  deploy:
    restart_policy:
      condition: on-failure
    replicas: 1
  # for compose (not supported by stack)
  restart: on-failure

#### configure a service to always restart
x-service: &service
  # for docker stack (not supported by compose)
  deploy:
    restart_policy:
      condition: any
  # for compose (not supported by stack)
  restart: always

services: 
  accounts: &accounts
    <<: *service
    image: internal/django
    ports:
      - "9000"
    networks:
      - service
    environment:
      DATABASE_URL: "postgres://postgres-master:5432/accounts"
      REDIS_URL: "hiredis://redis:6379/"

  accounts-migrate:
    <<: *accounts
    <<: *task
    command: ./manage.py migrate --noinput

@dopry를 지적 해 주셔서 감사합니다. 하지만 제 경우는 좀 더 간단했습니다. 서버를 실행하고 실행 한 후에야 몇 가지 배포 작업을 수행해야했습니다. 오늘 저는 단일 CMD 라인 내에서 소규모 프로세스 관리를 수행하는 방법을 찾았습니다. 서버 및 배포 프로세스가 각각 server 및 deploy 해보십시오. 그런 다음 다음을 사용했습니다.

CMD set -m; server $ deploy && fg server

위의 줄은 bash의 모니터 모드를 설정 한 다음 백그라운드에서 server 프로세스를 시작한 다음 deploy 프로세스를 실행하고 마지막으로 server 프로세스를 Docker 가 컨테이너를 죽이는 것을 피하기 위해 다시 포 그라운드를 만듭니다.

이에 대해 논의하는 동안 누구나 docker-compose up 실행시 컨테이너 또는 호스트에서 명령을 실행하는 방법에 대한 팁이 있습니다.

호스트에서 명령을 실행하면 보안 계층이 손상된다는 것을 이해하지만 컨테이너 시작 전이나 시작 중에 디렉터리를 rm 하고 싶습니다. 디렉토리는 호스트와 컨테이너 모두에서 액세스 할 수 있습니다. 나는 정의 도커 이미지를 만들거나 처음하는 스크립트 싶지 않아요 rm 다음 실행 docker-compose .

감사!

@fabiomolinar , 귀하가 제안한 접근 방식은 몇 가지 12 요소 앱 주체를 위반합니다. 인프라를 컨테이너화하는 경우 해당 인프라를 엄격하게 준수하는 것이 좋습니다.

• https://12factor.net/processes
• https://12factor.net/concurrency
• https://12factor.net/disposability
• https://12factor.net/admin-processes

접근 방식에서 발생할 수있는 몇 가지 문제

1. 느린 컨테이너 시작.
2. 컨테이너로 서비스를 확장 할 때 배포는 모든 인스턴스에 대해 한 번씩 실행되므로 잠재적으로 흥미로운 동시성 문제가 발생할 수 있습니다.
3. 관리 및 디버깅을 위해 '작업'및 서비스에서 로그를 정렬하기가 더 어렵습니다.

처음에는 내가 추천하는 접근 방식이 반 직관적이라는 것을 알았습니다. docker-compose, docker swarms 및 mesos / marathon 클러스터의 로컬 개발 환경에서 실제로 잘 작동했습니다. 또한 'onrun'부족을 효과적으로 해결했습니다.

내가 사용한 접근 방식은 실제로 매우 추합니다. 내 개발 환경을 실행하기 위해 잠시 사용했습니다. 그러나 서버가 가동되고 실행 된 후 시작점 스크립트와 at 명령을 사용하여 스크립트를 실행하도록 이미 변경했습니다. 이제 내 컨테이너가 PID 1로 올바른 프로세스로 실행되고 모든 신호에 올바르게 응답합니다.

우리는 여전히 이것이 필요합니다. 컨테이너를 성공적으로 시작한 후 여러 Makefile에서 만들지 않고 데이터베이스 롤업을 실행할 수있는 방법을 찾을 수 없습니다.

@ victor-perov는 롤업 작업을위한 다른 컨테이너를 만들고 별도의 서비스로 실행합니다.

다음은 데이터베이스 마이그레이션을 실행하는 태스크 서비스를 보여주는 프로젝트 중 하나의 일부 스 니펫입니다.

x-task: &task
  # run once deploy policy for tasks
  deploy:
    restart_policy: 
      condition: none
    replicas: 1

service:
  automata-auth-migrate:
    <<: *automata-auth
    <<: *task
    # without the sleep it can't lookup the host postgres.  maybe the command is ran before the network set is complete.
    command: sleep 5 && python /code/manage.py migrate --noinput

음, 이번이이 논의가 확장 된 4 년차입니다. onrun 가 필요한이 사용 사례에 +1을 추가하겠습니다. 추신 : 전체 실에 팝콘을 사야 했어요.

나도 onrun 또는 이에 상응하는 것 (포스트 런?)이 필수라고 생각합니다. 래퍼 스크립트를 추가하고 컨테이너에 docker exec를 수행하는 것은 단지 ... 추합니다.

IMO docker compose는 컨테이너 관리가 쉬울 수 있음을 사람들에게 확신시키는 훌륭한 컨테이너 오케스트레이션 MVP였습니다. 아마도 우리 커뮤니티는 프로덕션 준비 오케스트레이션 솔루션 (예 : kubernetes)이 확산됨에 따라 "유지 관리 모드"로 간주해야합니다. 컨테이너 종속성과 같은 고급 기능이 "컨테이너가 가동 된 후이 작업을 실행"과 같은 부재 기능과 결합 된 경우 개발 속도가 단순히 정체 상태에 있다는 이야기에 부합하는 것 같습니다. 적어도이 기능이 범위를 벗어난 것으로 간주되어야한다는 것은 분명하지 않습니다.

Dockerfile로 모든 것을 쉽게 할 수는 없습니다. 컨테이너에 자체 스크립트를 추가하고 싶다고 가정 해 보겠습니다.
예를 들어 mysql 컨테이너를 가져 와서 이벤트 발생시 API를 호출하는 간단한 스크립트를 추가해보십시오.
다음 중 하나를 수행 할 수 있습니다.

• mysql의 Dockerfile 를 변경하고 진입 점 앞에 컨테이너에 자체 스크립트를 추가합니다. 당신은 추가 할 수 없습니다 CMD 에 Dockerfile 가에 인수 될 것이기 때문에, ENTRYPOINT .
• 컨테이너를 실행 한 다음 스크립트를 실행중인 컨테이너에 복사하고 실행할 수 있습니다 [ docker cp , docker exec ].

그래서 Dockerfile을 변경하는 것만으로는 충분하지 않기 때문에 onrun 와 같은 기능이 유용하다고 생각합니다.

덤프, 왜 이것이 닫혀 있습니까? Cassandra와 같은 공식 도커 이미지를 사용하고 시작된 후 스키마를로드해야 할 때 상황을 고려하십시오.이를 위해 자체 bash 스크립트 솔루션을 구현해야합니다.

@somebi 는 compose가 닫힌 것 같습니다 ...

2 센트 만 : 현재 컨테이너를 시작할 때마다 Apache 모듈을 수동으로 활성화해야하기 때문에 여기에 왔습니다 (SSL은 기본적으로 Docker Hub wordpress 이미지에서 활성화되지 않음). 세상의 끝은 아니지만, 올라갈 때마다 몇 가지 명령을 실행하기를 바라고 있었기 때문에 강타하지 않고도 컨테이너를 원활하게 위아래로 가져갈 수 있습니다.

2 센트 만 : 현재 컨테이너를 시작할 때마다 Apache 모듈을 수동으로 활성화해야하기 때문에 여기에 왔습니다 (SSL은 기본적으로 Docker Hub wordpress 이미지에서 활성화되지 않음). 세상의 끝은 아니지만, 올라갈 때마다 몇 가지 명령을 실행하기를 바라고 있었기 때문에 강타하지 않고도 컨테이너를 원활하게 위아래로 가져갈 수 있습니다.

필요한 모듈이 활성화 된 wordpress 이미지를 기반으로 새 이미지를 빌드하면이 문제를 쉽게 해결할 수 있습니다. 그런 다음 대신 Dockerfile을 사용하십시오.

FROM wordpress:php7.1
RUN a2enmod ssl

또 다른 해결책은 워드 프레스 Dockerfile을 다운로드하고 그 안에 모듈 활성화를 추가하는 것입니다. 그런 다음 Docker 빌드를 사용하여 새 이미지를 생성하십시오. 예를 들어 이것은 PHP 7.1을 사용하는 wordpress 5.2 용 Dockerfile입니다.

워드 프레스 도커 파일

63 행에서 더 많은 모듈을 활성화하거나 ssl 생성을 실행할 수 있습니다.

이 모든 것은 우리가 여기서 논의하고 있다고 생각하는 경우가 아닙니다. 문제는 시작될 때와 같이 컨테이너 수명주기에서 동적 후크를 만드는 것입니다.

이것은 docker-compose에 좋은 추가가 될 것입니다!

이 스레드에있는 것과 같은 답변은 Kubernetes가 Docker (기술)가 생산하는 "모든" 돈을 유지하는 이유이며 누군가가 곧 Docker (회사)를 구매하고 커뮤니티 제안 / 요청을 환영하는 방식을 변경하기를 바라는 것은 나쁜 일이 아닙니다. / 분석 됨 ...

이 스레드에있는 답변과 같은 답변은 Kubernetes가 Docker (기술)가 생산하는 _ "모든"_을 유지하는 이유이며, 누군가가 곧 Docker (회사)를 구매하고 커뮤니티 제안 / 요청 방식을 변경하기를 바라는 것은 나쁜 일이 아닙니다. 환영 / 분석 ...

나는 모욕적 인 발언없이 비슷한 비평을 썼다. (그것은 유지 자들이 얼마나 많은 기술적 인 아르곤을 가지고 있는지 보여주는 것 외에 다른 이유없이 논쟁을 무시하는 _ 오픈 소스가 아닌 _ 오픈 소스 프로젝트의 라인을 따라 있었다.) , 메시지가 제거되었습니다.

이것은 어떤 종류의 오만한 사람들이 이것 뒤에 있는지 보여줍니다.

당신의 커뮤니티가 4 년 동안 무언가를 요구하고 당신 (Docker)이 눈을 감 으면 당신이 그들과 같은 방향을 바라보고 있지 않다는 것을 보여줍니다.

그리고 이제 도커는 포기하고 매진되었습니다.
그들은들을 수 없었기 때문에 ... 그들은졌습니다.

수치심-하지만 헤이 호.

이런 것이 존재하지 않는다는 것은 정말 부끄러운 일입니다. 상태 확인이 실패 할 때 발생할 수있는 onFailure 후크를 만들 수 있었으면 좋았을 것입니다.

즉

services:
  app:
    image: myapp:latest
    hooks:
      onFailure:
        - # Call a monitoring service (from the host machine) to tell it that the service is offline.

이것은 응용 프로그램이 소켓 / 포트에 바인딩되지 않는 경우에 유용합니다. 쿠 버네 티스는 아마도 갈 길일 것입니다. 그러나 이것은 매우 작은 환경에서 상당히 큰 인프라 변경이며 과잉입니다.

편집하다:
이 문제를 해결하기 위해 모니터링 기능을 "래핑"하기 위해 컨테이너의 진입 점을 업데이트했습니다. 즉

# /app/bin/run_with_monitor
#!/bin/bash
set -eE

updateMonitoringSystem() {
 # do something here... This is run from the container, though, unfortunately.
 if [[ $? -eq 1 ]]; then
  # Failed!
 else
  # All is good!
 fi
}

trap 'updateMonitoringSystem' EXIT

$@

# Dockerfile
....
CMD ["/app/bin/run_with_monitor", "./my-app"

그래도 이미지를 수정할 필요없이이 작업을 수행하는 것이 좋습니다.

: man_shrugging : 경쟁자 (Kubernetes)가 가지고있는이 기본 기능을 찾고 대신 쓰레기통 화재를 발견했습니다.

정말 부끄러운 일입니다. 이제 로컬에서 테스트하기 위해 별도의 도커 이미지를 유지해야합니다.

새해 복 많이 받으세요 : roll_eyes :

@LukeStonehm도 마찬가지입니다. 컨테이너가 세워진 후 하나의 명령을 수행해야하지만 대신 뜨거운 쓰레기로 처리되었습니다. 공식 이미지가 90 % 이상을 가져 오면 내 이미지와 도커 파일을 관리하고 싶지 않습니다.

상당량의 프로그램은 시작시 특정 서비스에 의존합니다. 예를 들어 MySQL 또는 MongoDB 데이터베이스입니다.

따라서 이러한 경우 docker-compose 를 사용하는 올바른 방법이 없습니다.

대신 사용자는 다음을 수행해야합니다.

• Dockerfiles 작성 방법 및 프로그래밍 배우기
• Docker images 빌드 방법 알아보기
• 원본 이미지에서 상속 된 Dockerfiles 를 만들고 컨테이너가 서로를 기다리도록 코드를 추가합니다.
• 기본 이미지의 보안 업데이트를 정기적으로 확인
• Dockerfiles 를 정기적으로 수정하여 업데이트를 적용하십시오.
• 정기적으로 구축 Docker images 것과 Dockerfiles

그리고 이것은 다음과 같은 이유로 짜증납니다.

• 다른 방법으로는 필요하지 않을 수도있는 것을 배우는 데 막대한 시간을 낭비합니다.
• 자신이 Docker images 만들고 저장하거나 업로드 / 다운로드 (풀링 / 푸시)하는 데 정기적으로 하드웨어 리소스를 낭비합니다.
• Dockerfiles , 빌드, 테스트, 수정 등에 정기적으로 시간을 낭비합니다.
• 무엇을하고 있는지 모르기 때문에 잠재적으로 이미지의 보안을 손상시킬 수 있습니다.
• 공식적으로 확인 / 서명 된 Docker images 만 실행할 수있는 기능을 잃습니다.

스타트 업 확인이 있었다면이 모든 것이 필요하지 않을 것이며 우리가 원하고 끝낼 때마다 image: mysql:8.0.18 를 image: mysql:8.0.19 간단히 변경할 수 있습니다!

현실적으로 이것은 현재 현실 세계에서 일어나고있는 일입니다.

• 사람들은 docker-compose 작업 할 수 있도록 자신 만의 Dockerfiles 만들어 변경합니다.
• 그들은 한 번 이미지를 만듭니다.
• 그리고 정기적으로 패치하지 마십시오
• 해커는 행복해

그리고 당신은 docker-compose 이 이미 거의 모든 것을하기 때문에 "한가지 일을해야한다"라고 말할 수 없습니다. depends_on 속성을 사용하여 종속성을 지정하는 것보다 더 중요한 것은 이미지 가져 오기 및 빌드를 포함합니다. 이것은 완전히 새로운 기능을 구현하는 것도 아닙니다. 이것은 다른 매개 변수를 docker 입니다.

@ binman-docker @crosbymichael @dmcgowan @ebriney @ehazlett @eunomie @guillaumerose @jeanlaurent @justincormack @lorenrh @manishtomar @olegburov @routelastresort @spencerhcheng @StefanScherer @thaJeztah @tonistiigi @ulyssessouza @aiordache @ chris-crone @aiordache
이 기능을 재고하거나 적어도 이에 대해 적절한 논의를합시다.

task service 기술은이 시점에서 저에게 꽤 잘 작동하지만 특이한 점이 있습니다. 마이그레이션 및 애플리케이션 초기화를 위해 compose 파일에 패턴을 광범위하게 적용했습니다. 그러나 성공적인 상태 확인 또는 성공적인 종료 / 작업 완료를 기다린 더 나은 'depends_on'이 많은 작업을 더 쉽고 안정적으로 만드는 데 동의합니다.

이것은 정말 도움이 될 것입니다.

Kubernetes가 postStart 수명주기를 통해이 기능을 가지고 있다는 점을 강조 할 가치가 있다고 생각합니다.

k8s! = 도커 작성. 잘못된 채널

명확하지 않아서 미안하지만 내 요점은 Kubernetes가 이것을 지원하고 Kubernetes와 Docker compose가 동일한 사용 사례 / 목적을 많이 가지고 있기 때문에 작성에 대한 논쟁이 될 것입니다. 잘 모르겠 으면 미안 해요.

좋은 소식!!

나는 docker가 우리를 들었다고 생각합니다 (이 문제와 다른 몇 가지). https://www.docker.com/blog/announcing-the-compose-specification/

커뮤니티 요구 사항을 충족하기 위해 사양에 대해 작업 해 봅시다. 이번 재개를 통해이 커뮤니티를 개방적이고 친근한 커뮤니티로 만들 수 있습니다.

좋은 소식!!

나는 docker가 우리를 들었다고 생각합니다 (이 문제와 다른 몇 가지). https://www.docker.com/blog/announcing-the-compose-specification/

커뮤니티 요구 사항을 충족하기 위해 사양에 대해 작업 해 봅시다. 이번 재개를 통해이 커뮤니티를 개방적이고 친근한 커뮤니티로 만들 수 있습니다.

이 변경 사항을 제안한 사람이 있습니까? 메일 링리스트는 아직 사용할 수 없으므로 차선책이 여기에 있다고 생각합니다 : https://github.com/compose-spec/compose-spec

이 문제를 설명하는 문제가 보이지 않지만 올바른 장소인지 확실하지 않습니다.

편집 : https://github.com/compose-spec/compose-spec/issues/84 에서 문제를 열었습니다

HEALTHCHECK 를 사용하여 다음 예제와 같은 다른 작업을 수행 할 수 있습니다.

암호

Dockerfile

FROM ubuntu

COPY healthcheck.sh /healthcheck.sh
RUN chmod a+x /healthcheck.sh

HEALTHCHECK --interval=5s CMD /healthcheck.sh

CMD bash -c 'set -x; set +e; while true; do cat /test.txt; sleep 3; done'

healthcheck.sh

#/usr/bin/env bash

set -e

FIRST_READY_STATUS_FLAG='/tmp/.FIRST_READY_STATUS_FLAG'

# Health check

echo 'Run command to validate the container status HERE'

# On success
if [ ! -f "${FIRST_READY_STATUS_FLAG}" ]; then
  # On first success...
  touch "${FIRST_READY_STATUS_FLAG}"

  # Run ON_RUN on first health check ok
  if [ ! -z "${DOCKER_ON_RUN}" ]; then
    eval "${DOCKER_ON_RUN}"
  fi
fi

1. _health check_를 실행하십시오.
   
   
   
   • 실패하면 종료 코드 1 스크립트를 종료합니다.
   
   
   • _health check_가 정상이면 스크립트가 계속됩니다.
   
   
2. 첫 번째 _health check OK_이고 DOCKER_ON_RUN 환경 변수가 있으면 실행합니다.

예

docker-compose.yml

version: "3.7"

services:
  test:
    build:
      context: .
    image: test/on-run
    environment:
      DOCKER_ON_RUN: echo x >> /test.txt

DOCKER_ON_RUN 환경 변수를 사용하여 실행 후 실행할 사용자 지정 명령을 전달할 수 있습니다.

실행 결과

docker-compose build
docker-compose up

산출:

Creating network "tmp_default" with the default driver
Creating tmp_test_1 ... done
Attaching to tmp_test_1
test_1  | + set +e
test_1  | + true
test_1  | + cat /test.txt
test_1  | cat: /test.txt: No such file or directory
test_1  | + sleep 3
test_1  | + true
test_1  | + cat /test.txt
test_1  | cat: /test.txt: No such file or directory
test_1  | + sleep 3
test_1  | + true
test_1  | + cat /test.txt
test_1  | x
test_1  | + sleep 3
test_1  | + true
test_1  | + cat /test.txt
test_1  | x
test_1  | + sleep 3
test_1  | + true
test_1  | + cat /test.txt
test_1  | x
test_1  | + sleep 3

• _health check_가 준비 될 때까지 cat: /test.txt: No such file or directory 오류를 볼 수 있습니다.
• 실행 후 /test.txt 내부에서 x 하나만 볼 수 있습니다.

이것이 누군가를 도울 수 있기를 바랍니다.

편집 1

_health check_가 필요하지 않은 경우 나머지 스크립트를 사용할 수 있습니다.

뿡 빵뀨
해결 방법에 감사드립니다.
사용자 생성 등과 같이 명령 1을 실행해야하는 경우 touch "${FIRST_READY_STATUS_FLAG}" 대한 볼륨을 마운트 할 수 있습니다.

이러한 솔루션 중 상당수는이 문제에 대한 유효한 해결 방법입니다. 예를 들어 진입 점 스크립트를 만들면 다음을 해결할 수도 있습니다.
ENTRYPOINT ["./entrypoint.sh"]

실제 서비스 또는 프로세스를 실행하기 전에 더 복잡한 논리가 포함됩니다.
컨테이너 라이프 사이클에 로직을 삽입 할 수 있지만 여전히 후크는 아닙니다.

• 만들기 전에
• 시작하기 전에
• 시작 후
• 파괴하기 전에
• 파괴 후에도
• 등 ...

위의 모든 것이 의미있는 것은 아니지만 이것이 포인트이기 때문에 사진을 찍었 으면합니다.
다음과 같은 지시문과 함께 docker-compose 포함될 수도 있습니다.

lifecycle:
    before_start: "./beforeStartHook.sh"
    after_destroy: "./afterDestroyHook.sh"

또는 심지어 그렇게 :

hooks:
    before_destroy: "./beforeDestroyHook.sh"
    before_create: "./fixFsRights.sh"

루트가 아닌 사용자로 컨테이너를 시작하기 때문에 후크 스크립트 또는 부트 스트랩 스크립트 접근 방식을 사용하여 루트 권한이 필요한 파일을 덮어 쓸 수 없습니다.

와, 기본 기능이지만 아직 구현되지 않았습니다.