사용 사례는 무엇입니까? 내가 본 대부분의 권장 사용법은 반 패턴이었습니다.

제공된 링크를 클릭하면 많은 사용 사례 중 일부를 볼 수 있습니다. 보시다시피 많은 구독자가 "반 패턴"이 아닌 정말 유용한 기능으로 간주합니다.

ooops, 이제 더 이상 코멘트가 없기 때문에 문제 # 2105에 "무언가"가 발생했습니다.
아마도 잘못된 링크를 제공했을 것입니다 ...

따라서 일부 구성 / 초기화 파일을 컨테이너에 복사하는 것이 정말 유용합니다. 예를 들어 db 컨테이너의 경우 일부 * .sql 항목, apache / nginx 컨테이너의 경우 일부 html / js / css 콘텐츠 또는 Java 컨테이너의 경우 jar 파일이 있습니다. 이렇게하면 볼륨을 마운트하는 경우처럼 구성된 시스템에서만 "전역 적으로"사용 가능 / 실행 가능하게됩니다. 주로 이것은 호스트 로컬 및 컨테이너 포함 파일의 일부 조합입니다. 사실 어떤 컨테이너도 구성이나 초기화없이 쓸모없는 것으로 간주 될 수 있습니다.

이것은 올바른 링크입니다 : https://github.com/docker/compose/issues/1664

+1

이렇게하면 볼륨을 마운트하는 경우처럼 구성된 시스템에서만 "전역 적으로"사용 가능 / 실행 가능하게됩니다.

이것의 문제점은 컨테이너가 다시 생성 될 때마다 작업을 반복해야하기 때문에 매우 근시안적이라는 것입니다 (따라서 "반 패턴"이라는 용어). 확장 성이 매우 낮다는 사실은 말할 것도 없습니다 (컨테이너가 10 개? 20? 100?).

문제에 대한 실제 해결책은 빌드 (Dockerfile)에 필요한 파일을 포함하고 업데이트가 필요할 때 다시 빌드하는 것입니다.

물론 모든 "공유 된"콘텐츠를 컨테이너에 포함하여 구성하면 컨테이너를 10 ~ 100 개 확장하는 것이 훨씬 쉬울 것입니다. 필요한 것은 저장소에서 가져 와서 노드 별 구성 만 마운트 (예,이 경우 마운트)하는 것입니다. 또한 각 노드에서 docker-compose를 실행할 필요가 없습니다.
물론 build : & Dockerfile과 함께 docker-compose를 사용할 수 있습니다.하지만 상황이 조금 더 복잡해지고 docker-compose의 yaml 구성이 훨씬 더 "우아함"입니다. : o)

나는 사본이 (적어도 재정의로서) 유용 할 수있는 문제에 봉착했습니다. 저는 주로 Mac에서 개발하므로 컨테이너에서 루트로 실행되고 마운트 된 볼륨으로 내보내는 명령에 문제가 거의 발생하지 않습니다. 그러나 최근 CentO에서 동일한 워크 플로를 사용하면 루트 사용자가 소유 한 파일이 마운트 된 볼륨을 통해 호스트에 추가되기 때문에 상당한 고통이 발생했습니다. 이 경우 호스트 파일을 마운트하는 대신 컨테이너에 복사 할 수 있기를 바랍니다.

관련 문제 : # 1532

최신 정보

내 경우에는 Dockerfile에서 COPY를 사용하고 볼륨 마운트를 사용하는 여러 개의 docker-compose 파일을 사용할 수 있다고 생각합니다.

사용 사례 :
컨테이너 내부의 읽기 전용 파일 시스템의 디렉토리를 사용하고 싶습니다. 응용 프로그램은 해당 디렉토리에 새 파일을 생성하지만 파일 시스템이 읽기 전용이기 때문에 오류가 발생합니다.

파일 시스템이 읽기 전용이기 때문에 rw 볼륨을 사용할 수 없습니다.
효과가 같기 때문에 볼륨을 사용할 수 없습니다.

컨테이너가 실행될 때만 지속되는 쓰기를 만드는 것은 멋질 것입니다. 래퍼 (https://stackoverflow.com/questions/36362233/can-a-dockerfile-extend-another-one)를 COPY 파일로만 만들 수 있지만 volume 과 비슷하게 작성하면됩니다.

사용 사례 : .gitlab-ci.yml에서 여러 도커 컨테이너를 동시에 시작하여 git 저장소의 디렉토리에 작성해야합니다.

컨테이너 내부의 프로세스가 실패하거나 컨테이너가 자체적으로 정리되기 전에 ci 작업이 취소되면 권한 부족으로 인해 gitlab-runner에서 나머지 파일을 삭제할 수 없습니다. 이제 컨테이너 내의 파일을 볼륨에서 다른 디렉토리로 복사 할 수 있지만, 그것은 반 패턴이 될 것입니다.

volumes: - ./folder_on_host/ :/folder_in_container/ 가요?
내 compose 파일에서 이런 방식으로 호스트에서 컨테이너 (COPY와 동일)로 파일을 복사 할 수 있습니다.

@harpratap 당신이 옳지 만, 단점은 / folder_in_container가 존재하지 않거나 비어 있어야하며 그렇지 않으면 덮어

COPY 기능이 있으면 +1. 우리의 사용 사례는 로컬 개발 환경을 신속하게 구축하고 개발 설정을위한 구성에서 복사하는 것입니다.

COPY에 +1. 이것은 정말 유용한 기능이 될 것입니다.

사용 사례 : swarm 모드에서 mysql 이미지를 사용하는 서비스가 있습니다. MySQL에서 실행할 수 있도록 /docker-entrypoint-initdb.d/에 초기화 스크립트를 복사해야합니다.

mysql 위에 이미지를 생성 할 수 있지만 파일을 복사하여 사용하거나 mysql에 연결합니다.
떼에서 작업하고 수동으로 스크립트를 실행하면 내 의견으로는 불필요합니다.

복사 / 추가에 +1,

사용 사례 :
Fluentd는 런타임 동안 구성 파일을 컨테이너로 이동해야합니다. 이러한 구성 파일은 Jenkins Engine에 의해 런타임에 생성되며 Docker에 COPY / ADD가 없으면 단순히 실패합니다.

COPY에 +1

Docker-compose 디렉터리 아래의 각 하위 디렉터리에 Dockerfile이있는 여러 도커 머신에서 공유 구성 파일이 있다고 가정합니다. 공유 구성을 각 이미지에 어떻게 복사합니까? COPY failed: Forbidden path outside the build context 없이 Dockerfile 컨텍스트에서 ../ 심볼릭 링크를 할 수 없습니다.

이 경우 docker-compose 빌드를 실행할 때 docker 빌드 단계를 실행하기 전에 docker-compose 컨텍스트에서 구성 파일을 복사하고 싶습니다.

물론 누군가가 깨끗한 해결 방법을 제안 할 수 있다면 기쁩니다.

기능이 있으면 좋겠네요 !!

+1만으로 댓글을 달지 마세요. 모두의 시간 낭비입니다. 제공 할 추가 정보가 있으면 그렇게하십시오. 그렇지 않으면 원래 문제에 좋아요를 추가하세요.

_ 어떤 경우에는 _ 결국 _ 문제를 일으킬 수 있기 때문에 반 패턴이라고 독단적으로 주장하는 용도는 무엇입니까? 추가 폴더와 파일을 만든 다음 추가 할 파일을 이동하는 대신 기존 파일에 한 줄을 추가 할 수 있으므로 확실히 유용합니다. 이 무의미하고 관료적 인 작은 파일 생성은 진정한 반 패턴으로, 사용자가 도커 작성 파일을 간단하고 유지 관리하기 쉽게 만들지 못하게합니다.

사용자가 Docker로 유해한 일을하고 싶다면, 당신이 무엇을하든 상관없이 방법을 찾을 것입니다. 누군가가 언젠가 오용 할 수 있다는 이유만으로 합법적 인 기능을 추가하는 것을 거부하는 것은 어리석은 일입니다.

저는 당신이하는 일이 실제로이 경우에 대해 올바른 방법이라고 생각합니다.

여기서 제기 된 문제는 mongo.conf 파일이 하나의 docker-compose 파일에 의해 조정되는 세 개의 docker 이미지간에 공유되었다고 가정하는 것과 비슷합니다. 각 Docker 빌드 하위 디렉토리에서 동일한 지 어떻게 확인합니까?

예를 들어 심볼릭 링크를 사용하는 경우 docker는 파일이 빌드 환경의 외부에 있다고 불평합니다. 예를 들어 docker 빌드는 해당 디렉토리 외부의 수정이 빌드를 변경할 수 있으므로 재현성이 부족합니다.

따라서 이것을 조정하는 유일한 방법은 파일 복사를 사용하는 것입니다. 현재 docker-compose를 실행하기 전에 Makefile 또는 셸 스크립트와 관련이 있으므로 이것이 docker-compose가 할 수있는 기능인지 여부를 논의하는 아이디어처럼 보였습니다. 확실히 일반적인 사용 사례이기 때문입니다.

당신이 제기하는 문제는 로컬 파일 수정의 런타임 (시작 시간) 주입에 관한 것 같습니다.

나는 당신이하는 일에서 실제로 괜찮다고 생각합니다. 당신이 위에서 말한 것은 그것이 어떻게 이루어 졌는지입니다. 도커 이미지는 항상 구성 디렉토리가 어디에 있는지와 같은 질문에 답하기 위해 환경 변수를 허용하도록 구성 될 수 있으며, 해당 구성 디렉토리는 런타임에 볼륨을 사용하여 "주입"될 수 있지만, 이는 도커 이미지의 설계에 달려 있습니다. 환경 변수 및 볼륨 매핑 (도 커가 런타임 구성 수정으로 지원하는 기능입니다.)

귀하의 의견을 잘못 해석하지 않았기를 바라며 제 답변이 도움이 되었기를 바랍니다.

@jpz- 어떻게 든 내 원래 댓글을 삭제했습니다

내 원래 의견은 다음과 같습니다.

내 사용 사례는 /etc/mongod.conf 와 같은 구성 파일을 복사하기 위해 사용자 지정 이미지를 만들 필요없이 mongo 를 사용하여 서비스를 선언하려는 것입니다.

업데이트 : 나는 volumes . 1 ~ 2 년 전-나쁜 경험으로 이걸 시도했다고 생각했는데 ... 괜찮아 보인다.

COPY에 +1

나는 이것에 대한 간단한 요점을 만들었습니다. docker compose 서비스의 이름이 phpfpm 라고 가정하지만 원하는대로 변경할 수 있습니다. 자유롭게 수정하십시오.
https://gist.github.com/markoshust/15efb29aa5eebf8adae402af18b2e674

안녕하세요, 이번 호의 진행 상황을 알고 싶습니다. 이제 docker-toolbox와 함께 Windows 10 home을 사용하고 있습니다. 마운트 파일을 컨테이너에 볼륨으로 묶으려고 할 때 대부분 오류가 발생합니다. docker-compose에 COPY 기능이 있으면 좋을 것입니다.

COPY / ADD는 확실히 환영받는 기능이 될 것입니다.

사용 사례 : Dev 목적으로 Docker에서 Graylog 인스턴스 실행. 입력을 자동으로 시작하려면 JSON 사양을 / usr / share / graylog / data / contentpacks에 넣어야합니다.
COPY / ADD 기능을 사용하면 YML에서 한 줄로 쉽게 처리 할 수 ​​있습니다.

지금 작동하게하려면 (2018 년 10 월 16 일) 볼륨을 해당 지점에 마운트하고 해당 폴더의 원본 콘텐츠를 영구 볼륨에 복사해야합니다. 조용하고 불편합니다.

나는 그것으로부터 이익을 얻을 것입니다. 데이터베이스 시드를 컨테이너로 가져 오는 도구 세트가 있으며 해당 파일을 기반으로 devtools 데이터베이스 가져 오기 프로그램을 실행합니다. 할 필요가 없습니다.

docker cp "${seed_file}" $(docker-compose ps -q devtools):/tmp/seed_file

내 씨앗을 가져올 수 있습니다. 그리고 아니요, 고정 스키마로 개발자 이미지를 컴파일하지 않을 것입니다. 이것은 최소한 웹 개발 패턴에 위배됩니다. 컨테이너는 데이터가 아닌 앱 이식성을위한 것이어야합니다.

다음을 수행하는 것이 더 합리적입니다.

docker-compose cp "${seed_file}" devtools:/tmp/seed_file

대체로 기본적으로 똑같은 일을하는 것은 속기 일 뿐이지 만, 물건을 섞는 것보다 docker-compose 어디에서나 활용하는 것이 더 좋습니다 ...

1) 이것은 # 3593의 중복 인 것 같습니다
2) @shin에 동의합니다. 정교한 사용 사례가 안티 패턴을 따르고 있다는 것입니다.
3) 그러나 Docker의 cp 명령을 마무리하는 것은 의미가 있습니다.

@funkyfuture 이러한 사용 사례가 반 패턴을 따른다고 생각되면 그렇지 않은 솔루션을 제안하십시오.

k8s와 같은 "데이터 섹션"은 어떻습니까?
예를 들면 :

services:
  service1:
    image: image.name
    data:
      filename1.ini: |
        [foo]
        var1=val1
        [bar]
        var2=val2
      filename2.yml: |
        foo:
          bar: val1

또는 동일하지만 volumes: 섹션

volumes:
  service_config:
    data:
      filename1.ini: |
        [foo]
        var1=val1
        [bar]
        var2=val2

services:
  service1:
    image: image.name
    volumes:
      - service_config:/service/config

@정강이-

이것의 문제점은 컨테이너가 다시 생성 될 때마다 작업을 반복해야하기 때문에 매우 근시안적이라는 것입니다 (따라서 "반 패턴"이라는 용어). 확장 성이 매우 낮다는 사실은 말할 것도 없습니다 (컨테이너가 10 개? 20? 100?).

여기서 실제 문제는 일부 사람들이 실제 사용 사례 시나리오에 대한 제한된 비전과 충돌하기 때문에 요청 된 기능을 너무 빨리 디스커버리한다는 것입니다.

여기에서 방금 dockerhub에서 가져온 컨테이너로 구성 파일을 복사하는 방법을 찾고 있습니다. 원래 Dockerfile에 대한 액세스 권한이 없으며이 기능을 사용하는 것이 매우 편리 할 것입니다 (위에 다른 레이어를 빌드하는 대신 작동하지만 불편합니다. 변경시 다시 빌드하고 싶지 않습니다).

사용 사례 :

통합 테스트 환경에서 데이터베이스를 실행하고 컨테이너가 시작될 때 각 반복에서 데이터를 재설정하기를 원합니다. 사용자 지정 이미지에 데이터를 포함하는 것은 작동하지만 호스트의 데이터를 재설정해야하기 때문에 볼륨을 탑재하는 것이 번거 롭습니다.

우리는 데이터를 독립적으로 유지하며 표준 데이터베이스 이미지를 사용하는 것이 가장 편리합니다. 실행을 시작하기 전에 데이터를 복사합니다. 현재 이것은 docker-compose로는 불가능한 것 같습니다.

유스 케이스를 염두에두고 있습니다. 일반 Apache 서버와 같은 기성 이미지에서 내 이미지를 기반으로하고 싶습니다. 이미지 생성 중에 HTML을 복사하고 싶습니다. 이렇게하면 언제든지 기본 이미지를 업데이트 할 수 있으며 복사 지시문은 내 콘텐츠가 새 이미지에 포함되도록합니다.

BTW 저는 현재 docker-compose.yaml에서 dockerfiles 및 빌드 지시문을 사용하여이를 수행합니다. 도커 파일이 필요하지 않으면 좋을 것입니다.

@tvedtorama-

사용 사례 :

통합 테스트 환경에서 데이터베이스를 실행하고 컨테이너가 시작될 때 각 반복에서 데이터를 재설정하기를 원합니다. 사용자 지정 이미지에 데이터를 포함하는 것은 작동하지만 호스트의 데이터를 재설정해야하기 때문에 볼륨을 탑재하는 것이 번거 롭습니다.

우리는 데이터를 독립적으로 유지하며 표준 데이터베이스 이미지를 사용하는 것이 가장 편리합니다. 실행을 시작하기 전에 데이터를 복사합니다. 현재 이것은 docker-compose로는 불가능한 것 같습니다.

이 문제는 런타임이 아닌 이미지 빌드 시간에 파일을 복사하려는 욕구에 대해 설명합니다. 그 장점을 논의하기 위해 별도의 티켓을 올리는 것이 좋습니다. 이 논의를 혼동하여 런타임 파일 주입에 대해 논의 할 수 있습니다.

@ c0ze-

k8s와 같은 "데이터 섹션"은 어떻습니까?
예를 들면 :

...

나는 그 구성이하는 일에 완전히 적응하지 못했지만 예, 그것이 해결책이 될 것 같습니다. 기본적으로 비밀이있을 때 (예 : 데이터베이스에 대한 로그인 사용자 이름 / 비밀번호 / 포트가 무엇인지) 코드를 작성하지 않고 도커 이미지 (클라이언트 및 서버)에 어떻게 삽입합니까?

kubernetes 데이터 섹션과 같은 것이 작동 할 수 있습니다. 단일 소스 소스이기 때문입니다. 그렇지 않으면 여러 도커 이미지에서 동일한 비밀이 여러 번 유지되는 것을 알 수 있습니다.

또한 이것이 실제로 채택 할 가치가있는 좋은 아이디어인지 아닌지에 대한 대화를 진행하는 데 도움이되는 선행 기술이 있습니다.

저에게있어이 모든 것은 컨테이너간에 불변 구성 파일을 공유하기를 원했고, 외부에서 docker-compose를 스크립팅하고 단일 진실 소스의 구성을 각각의 docker-compose 폴더 아래의 Docker 폴더. 물론 저는 Docker에 대한 불변성 인수를 얻습니다 (예 : Dockerfile 디렉토리는 이미지를 빌드하는 방법을 완전하고 완전하게 설명합니다). 따라서 자동화를 요청하여 해당 디렉토리에 항목을 복사하도록 요청하는 것은 이러한 원칙에 비추어 약간 날아가는 것처럼 보입니다.

토론은 docker-compose가 얼마나 방해가 되는가? 이것이 그러한 자동화를 정당화하기에 충분히 일반적인 사용 사례입니까? 그렇지 않은 경우, 우리는 늦게 (예 : 런타임에) 외부로부터 비밀을 주입하는 책임을 환경 변수 전달 메커니즘에 부담하는 것처럼 보입니다. 여기에서 내 요점이 충분히 일관성이 있기를 바랍니다.

이것은 나에게 큰 의미가 없지만 사용 사례에 대해 논의 할 가치가 있다고 생각합니다.

나에게 매우 유용 할 것입니다. 직장에서 바이러스 소프트웨어는 Windows 10이 컨테이너와 볼륨을 공유하는 기능을 차단합니다. 그것은 거대한 조직이며 다른 대륙에 설정된 정책으로 인해 변경하도록 유도하는 것은 시작하지 않습니다.

안녕하세요, 제 사용 사례 : 저는 오픈 소스 Prometheus docker-compose 설정을 사용하고 있습니다 (저장소는 다른 사람들이 유지 관리함). 컨테이너에 마운트 된 구성이 있습니다. 문제 : 구성을 제대로 마운트 할 수 없기 때문에 원격 컴퓨터 (aws docker-machine 또는 CI / CD runner 내부)에서 docker-compose를 수행 할 수 없습니다. 이 경우 복사 / 삽입하고 싶습니다. RW 데이터의 경우 볼륨이 있습니다. RO-?

초기 데이터를 설정할 수있는 RO 볼륨을 갖는 것이 다른 옵션입니다.

현재 솔루션 : ssh를 통해 docker 호스트에 연결하고, 저장소를 복제 / 업데이트하고 docker-compose up을 실행합니다. 이것은 수동 케이스에서 작동하지만 자동화에는 고통 스럽습니다.

+1

유스 케이스 : 데이터베이스를 실행하는 개발 도커 머신이 있으며이를 설정할 때마다 최신 데이터베이스 덤프를 설치해야합니다. 이는 효과적으로 다음을 의미합니다.

1. extern에서 데이터베이스 도커 이미지를 가져옵니다.
2. 실행중인 이미지에 ZIP을 복사하고 압축을 풉니 다.
3. 볼륨 내에서 db-restore를 실행합니다.
4. db 덤프를 삭제합니다.

이제 큰 문제는 해당 데이터베이스의 덤프 버전이 다양하기 때문에 2 단계는 개발자마다 항상 달라진다는 것입니다. 따라서 가장 쉬운 방법은 각 개발자가 특정 덤프 위치 / 버전이 포함 된 자체 작성 파일을 가지고있는 경우입니다. Docker가 작성하는 동안 특정 파일 위치로 이미지를 조립하도록 한 다음 다른 버전이 필요할 때 즉석에서 변경할 수도 있습니다.

내 사용 사례는 간단합니다. 볼륨을 원하지도 않고 내 이미지를 롤링하고 싶지도 않습니다. 구성 파일을 만든 후 시작하기 전에 컨테이너에 간단한 방어용 복사본을 저장하고 싶습니다.

이것이 여전히 문제입니까?
매우 긴 설정 파일이있는 django 애플리케이션이 있습니다. 나에게는 도커 이미지를 만들고 단일 구성 파일을 각 컨테이너에 복사하는 것이 더 쉬울 것입니다.
ENV로 모든 설정을 전달하는 것은 나에게 반 패턴입니다. 많은 코드가 필요하고 유지 관리가 어렵고 단일 복사 명령으로 해결할 수 있습니다.

나는 # 6643을 열었고 그것이 어떻게 안티 패턴으로 간주되는지에 대한 피드백을 원합니다. 특히, 수많은 구성 파일을 즉시 추가 / 수정해야하는 환경에서.

@정강이-

이것의 문제점은 컨테이너가 다시 생성 될 때마다 작업을 반복해야하기 때문에 매우 근시안적이라는 것입니다 (따라서 "반 패턴"이라는 용어). 확장 성이 매우 낮다는 사실은 말할 것도 없습니다 (컨테이너가 10 개? 20? 100?).

여러 컨테이너에서 docker-compose exec 는 어떻게 작동합니까?

    --index=index     index of the container if there are multiple
                      instances of a service [default: 1]

cp 동일한 동작을 시도해야하지 않습니까?

IMHO exec 는 cp 만큼 임시적입니다. 하지만 저는 항상 "개발"명령이라고 생각합니다. 개발 환경은 일시적이어야합니다. 그렇지 않습니까?

이 기능을 요청하여이 문제를 너무 빨리 고쳐서 근시안적이라고 여기는 많은 개발자에 대한 의견을 보지 못했습니다. 나는 이것이 약간 거칠고 겸손하다고 생각합니다. 수년간의 개발에서 배운 것이 하나 있다면 다음과 같습니다.

소프트웨어가하는 일이 아니라 사용자가하는 일이 중요합니다.

분명히, 나는 당신이 일이 미쳐가는 것을 막는 역할이 있다는 것을 이해하지만 누군가가 당신의 비전에 따라 도구를 잘못 사용하기 때문에 모든 사람이 그렇게 시작하고 모든 지옥이 풀릴 것입니다.

여기에서 본 모든 특수한 경우는 대부분 매우 적절합니다. 그리고 이러한 특수한 경우의 대부분은 프로덕션 시스템에서 발생해서는 안되며 발생하지 않을 것입니다. 예를 들어 제가 얼마 전에 설명한 제 경우와 같이 개발 환경을 사용자 지정하고 사용할 수없는 컨테이너에서 특수 파일을 실행하는 경우입니다. 볼륨 매핑. 대부분의 예는 스키마, 데이터 또는 구성 파일을 굽고 싶지 않고 볼륨 매핑을 사용할 수 없다고 분명히 말하고 있으므로 "근시"라는 용어를 사용하는 것만 큼 불편한 이유를 알 수 없습니다.

그런 말을 할 때는 신중하게 말해야한다고 생각합니다 ...

1. 나는 내가 말하거나 쓸 수있는 것에 대한 강의가 정말로 필요하지 않습니다. "근시안적"이 당신을 불쾌하게해서 미안합니다. 이러한 것들이 설계 상 Dockerfile에 속한다고 말하는 것은 여전히 ​​정확합니다.
2. 나는 더 이상 관리자가 아닙니다. 내가 더 이상 제어 할 수없는 일에 대해 @ -ing을 중지하십시오.

1. 나는 여기서 내가 crazycodr 편이라고 말해야한다 ... 유용하고 실제적이고 현실적인 대안을주지 않고 완벽하게 유효한 실제 사용 사례를 "반 패턴"으로 무시하는 것은 개발자에게 비우호적이며 솔직히 약간 무례한 일이다.
2. 메인테이너이든 아니든, github의 토론 부분에 참여했다면 기본적으로 댓글에 댓글을다는 사람들과 함께 살아야합니다. 그것이 작동하는 방식입니다. 받아 들여...

다시 가져 오자. 여기에 정직한 기술적 인 질문이 있습니다. 도커 스택에는 "configs"옵션이 있습니다. 이것은 기본 도커 기능이지만 컨테이너가 아닌 서비스 용입니다. 서비스 수준이 아닌 컨테이너 수준에서 작동하는 것과 같은 것을 얻을 수있는 가능성은 무엇입니까? Docker 스택은 구성 프로비저닝을 어떻게 구현합니까? 해당 구현을 docker-compose를 위해 복제 할 수 있습니까?

여기에 언급 된 사용 사례의 절반 이상이 구성에 관한 것이므로 가려운 부분 만 긁어도 많은 사람들이 만족할 것입니다.

또 다른 간단한 사용 사례는 Google의 도메인 유효성 검사와 같은 것입니다. 워드 프레스 이미지를 사용하는 경우 Google에서 확인할 파일을 추가 할 수 없습니다. 그렇게하려면 완전히 새로운 이미지를 만들어야합니다.

또한 사물이 "반 패턴"이라는 말은 거의 말이되지 않으며 엘리트주의의 냄새가납니다.

편집 : yikes, 더 읽기, 그가 더 이상 관리자가 아닌 신에게 감사합니다

따라서 작은 구성 파일을 미리 빌드 된 이미지 (예 : nginx 또는 mariadb )에 복사하려면 이제 내 이미지 빌드 설정을 관리하고 복제해야한다고 말씀하셨습니다. 사용 된 디스크 공간 (원본 이미지 및 구성된 이미지)?

이것은 기능이어야합니다.

사용 된 디스크 공간 복제

Docker를 사용할 때가 아닙니다.

나는 그가 말한 것 중에서 가장 사소한 것 중 하나를 고르는 방법을 좋아합니다. 이것은 기능이어야합니다. 이 문제는 일반적인 사용 사례이기 때문에도 커가 성장함에 따라 사람들이 여기에 왔기 때문에 성장하고 성장할 것이며 사람들은 상식으로 인해 존재한다고 기대할 것입니다.

나는 그가 말한 것 중에서 가장 사소한 것 중 하나를 고르는 방법을 좋아합니다.

유효하지 않은 인수는 이와 같이 기록되어야합니다.

저는 여기서 "반 패턴"주장이 특정 비즈니스 전략 ( @washtubs 포인트 참조)에서 유효 할 수 있다고 생각합니다. 우리는이 전략에 동의하지 않을 수 있지만 인신 공격을 정당화하지 않습니다. 결국 docker-compose 대한 대안을 구현할 수있는 것은 docker-py 대한 @ shin-의 과거 노력입니다.

어떤 "반 패턴"주장? 논쟁이 없습니다. 그것은 뒤에 논리가없는 "아니오, 안티 패턴이기 때문에", 그저 그것을 뒷받침하지 않고 말하는 것입니다. 사람들이 최악의 시나리오를 머릿속으로 생각하고, 시나리오가 반 패턴이라고 결정한 다음, 이른바 반 패턴 시나리오에 대해 글을 쓰지도 않고 모든 것을 기각하는 것과 같습니다.

그것은 단지 엘리트주의입니다. 여기에 추가하지 않은 이유가 얼마나 우스꽝 스러운지에 대한 많은 의견이 있으며 모두 무시됩니다.

상식과 논리는 당신의 감정이나 엘리트주의에 관심이 없습니다. 또는 당신이 만든 안티 패턴.

예, @robclancy , 시민 FFS로 유지하십시오. 나는이 기능을 원하지만, 당신이 할 모든 것이 관리자에게 똥을 말하는 것이라면, reddit을 사용하십시오. @funkyfuture 의 이전 수정이 완전히 보장됩니다.

결국 docker-compose의 대안을 구현할 수있는 docker-py에 대한 @ shin-의 과거 노력입니다.

나는 분명히 당신이 제안하는 것이라면, 특히 그러한 미세한 향상을 위해 docker-compose의 포크를 원하지 않습니다. 이것이 일어날 수있는 유일한 다른 방법이며 커뮤니티에 좋지 않을 것입니다.

누군가 PR을 제출하면 실제로 고려됩니까? 아니면 도커 작곡 팀이 받아들이지 않겠다고 단호하게 결정한 것입니까? 도커 스택 구성 과 호환되는 구성 섹션을 추가하는 과정에서 고려할 사항이 있습니까?

이것은 레일을 벗어났습니다 ... 설명이없는 '반 패턴'은 '반 패턴'을 반박 할 수없는 매우 광범위한 정의로 바꿉니다. '안티 패턴'이 어느쪽에 있는지 명확한 방향도 없습니다. docker 또는 docker-compose.

반 패턴 응답에 대한 명확한 정의는 환상적이고 많은 평가를받을 것입니다.

커뮤니티는 계속 성장할 것이므로 설정된 정의가 존재해야합니다.

Docker compose 스택에서 실행되는 젠킨스 파이프 라인에서 생성 된 아티팩트를 복사하는 데 사용하고 싶습니다. 그런 다음 컨테이너 이름은 임의 일 수 있으므로 docker cp 사용할 수 없습니다.

오늘 나는 사용해야합니다

docker cp $(docker-compose -f docker-compose.development.ci.yml ps -q test):/app/tests_output ./tests_output

volumes: - ./folder_on_host/ :/folder_in_container/ 가요?
내 compose 파일에서 이런 방식으로 호스트에서 컨테이너 (COPY와 동일)로 파일을 복사 할 수 있습니다.

저도 똑같이하려고합니다. csv 파일이있는 폴더가 있으며 logstash에 제공하고 싶습니다.
어떻게 할 수 있습니까? 또는 컨테이너의 어느 폴더?
현재 나는 이것을 가지고 있습니다.
./path/to/storage:/usr/share/logstash/ 데이터 : ro

어떤 제안이라도 도움이 될 것입니다.

@ shin-이 티켓은 이제 1.5 년이되었습니다. 160 명의 사람들이 당신이 틀렸다고 말할 때-아마 그렇습니다.

이것이 구현되어야한다고 확신하기 위해 또 무엇이 필요합니까?

고객의 말을 듣지 않는 @isapir 는 곧 사업을 중단하는 경향이 있습니다. 그래서 가까운 장래에 생산 준비가 된 도커 대안을 보게 될 것 같습니다.

@ shin-이 티켓은 이제 1.5 년이되었습니다. 160 명의 사람들이 당신이 틀렸다고 말할 때-아마 그렇습니다.

😆 🤣 💯 🥇 😲 😮

또한,

나는 더 이상 관리자가 아닙니다. 내가 더 이상 제어 할 수없는 일에 대해 @ -ing을 중지하십시오.

@sfuerte 이미 Docker-Compose를 대체 한 Kubernetes라는 작은 프로젝트가 있습니다. 사용자 피드백에 대한 태도가 더 긍정적 이었 더라면 그런 일이 일어 났을까요?

그들의 유행어에 대응하려면 유행어가 필요합니다. 그들이 처리 할 수있는 전부입니다.

이 기능은 완전히 pro-pattern 입니다. 그렇게해야합니다. 차이점은 내가 어리석은 일을 만들었음에도 불구하고이 문제에는 분명히 일반적인 사용 사례 인 방식으로 이것의 장점을 보여주는 많은 의견이 있다는 것입니다. 그리고 anti-pattern 의 단일 인스턴스가 없습니다.

@ shin- 현실에 근거없이이 헛소리 반 패턴 쓰레기를 시작했기 때문에 이것에 태그가 붙습니다. 그러니 당신이 일으킨 것에 대해 울지 마세요.

k 재밌다

내 경우는 다음과 같습니다.

• "개발"중에 소스 코드를 "볼륨"으로 빌드하여 개발 중에 자동으로 업데이트되도록하고 싶습니다.
• 앱이 출시 될 준비가되어 있고 "배포"해야 할 때 볼륨 대신 복사 된 파일을 복사하고 싶습니다.

이 문제를 해결하는 가장 쉬운 방법은 dev 용 compose 파일 1 개와 프로덕션 용 compose 파일 1 개를 갖는 것입니다.

여기서 문제는 도커 파일에 "볼륨"을 지정할 수 있지만 도커 파일에 "복사"를 지정할 수 없다는 것입니다.

저와 같은 경우가 있습니까? 내가 뭔가 빠졌나요?

@ shin- 이것은 안티 패턴입니까? 이 문제를 어떻게 해결 하시겠습니까?

@hems , 완벽한 세상에서는 애플리케이션이 독립형 도커 이미지로 배포되기를 원합니다. 따라서 애플리케이션을 작성하는 경우 배포하려는 소스 코드가 Dockerfile 일부 여야하므로 이미지에 전체 애플리케이션이 포함됩니다. 따라서 Dockerfile 에 소스를 / var / www에 넣으려면

COPY my-app-src /var/www

소스는 특정 환경이 아니므로 Docker 이미지에 속합니다. 쉬운.

우리 대부분은 기존 이미지가 특정 도커 구성 구성에서 잘 작동하도록 컨테이너에 환경 별 구성 파일을 포함하려고합니다. 그리고 우리는 작은 파일을위한 볼륨을 만들거나 새 이미지를 롤링하지 않고도이를 수행 할 수 있기를 원합니다.

docker-compose 팀의 누군가가 이것을 진지하고 공정하게 살펴보고 최종 판결을 내릴 수 있습니까? 이 문제는 영원히 열려 있습니다. 결과는 중요하지만 개인적으로 알림 수신에 지쳤습니다.

COPY my-app-src /var/www

그게 제가 말하는 것입니다. 개발 과정에서 도커 구성 파일을 사용하여 VOLUMES를 이미지에 마운트하고 프로덕션 빌드 중에 파일을 이미지에 복사하고 싶습니다. 그러므로 볼륨을 복사하고 마운트 할 수 있어야한다고 생각합니다. docker-compose 파일을 사용하므로 dev 용 compose 파일 1 개와 프로덕션 빌드 용 파일 1 개를 가질 수 있습니다.

저는 Compose를 유지 관리하는 팀에서 일하고 있으며이 토론에 참여하게되어 기쁩니다. 시작하기 위해 Dockerfiles 및 Compose 파일의 책임을 확인하는 방법을 간략하게 설명하겠습니다.

Dockerfile은 이미지를 빌드하기위한 레시피이며 서비스 작동에 필요한 모든 바이너리 / 기타 파일을 추가해야합니다. 여기에는 몇 가지 예외가 있습니다 : 비밀 (예 : 자격 증명), 구성 (예 : 구성 파일) 및 애플리케이션 상태 데이터 (예 : 데이터베이스 데이터). 비밀 및 구성은 읽기 전용입니다.

작성 파일은 서비스 세트가 배치되고 상호 작용하는 방법을 설명하는 데 사용됩니다. Compose 형식은 단일 엔진 (예 : docker-compose )뿐만 아니라 Swarm 및 Kubernetes와 같은 오케스트레이션 된 환경에도 사용됩니다. Compose 형식의 목표는 애플리케이션을 쉽게 작성하고 로컬에서 테스트 한 다음 변경 사항이 거의 또는 전혀없이 조정 된 환경에 배포하는 것입니다. 이 목표는 각 환경이 볼륨 및 데이터 스토리지를 처리하는 방법과 같은 근본적인 차이로 인해 형식에서 변경할 수있는 사항을 제한합니다.

이와 같이 Dockerfile 및 Compose 파일의 책임을 줄이면 각 컨테이너 이미지 (Dockerfile)의 내용, 서비스가 배포되고 상호 작용하는 방식 (Compose 파일)과 같은 우려 사항을 잘 구분할 수 있습니다.

이제 이미지에 저장하는 항목에 대한 각 예외를 살펴 보겠습니다. 비밀의 경우, 도난 당할 수 있고 시간이 지남에 따라 변경 될 수 있으므로 이미지로 구워지는 것을 원하지 않습니다. 이를 해결하기 위해 Docker Secrets 가 사용됩니다. 이는 배포하는 환경에 따라 약간 다르게 작동하지만 기본적으로 런타임시 컨테이너의 tmpfs 디렉토리에 읽기 전용으로 마운트되는 파일에 자격 증명을 저장할 수 있다는 생각입니다. 이 디렉토리는 항상 /run/secrets/ 이고 파일은 비밀의 이름이됩니다. 보안 비밀은 Swarm, 엔진 만 ( docker-compose ) 및 Kubernetes에서 지원됩니다.

구성 파일 또는 부트 스트랩 데이터의 경우 Docker Configs가 있습니다. 이것들은 비밀과 비슷하게 작동하지만 어디에나 장착 할 수 있습니다. Swarm 및 Kubernetes에서는 지원되지만 docker-compose 에서는 지원되지 않습니다. 이에 대한 지원을 추가해야하며이 문제에 나열된 일부 사용 사례에 도움이 될 것이라고 생각합니다.

마지막으로 외부에 저장해야하는 애플리케이션 상태 데이터가 있습니다. 이 문제와 관련이 없으므로 이에 대해서는 다루지 않겠습니다.

그 프레임으로 몇 가지 질문에 답할 수 있습니다.

• 작성 형식에 copy 필드를 추가합니까? 아니요, 오케스트레이션 된 환경에서는 말이되지 않기 때문에 그렇게 할 것이라고 생각하지 않습니다.
• docker-compose 에 configs 지원을 추가합니까? 네, 그래야한다고 생각합니다.
• docker-compose cp 하시겠습니까? 아직 확실하지 않을 수도 있습니다. 본질적으로 docker container cp 의 별칭입니다.

따라서 여기에서 사용할 수있는 몇 가지 도구가 있습니다.

• 대상을 사용하여 이미지에 조건부로 파일을 추가 할 수있는 다단계 빌드 입니다.
• 런타임에 자격 증명을 서비스에 전달할 수있는 비밀입니다.
• 런타임에 구성 정보를 서비스에 전달할 수있는 구성입니다.

나는 그 도구들이이 스레드에서 제기 된 모든 문제를 해결한다고 생각한다.

이 실은 꽤 뜨겁습니다. 각 GitHub 핸들 뒤에는 실제 살아있는 사람이 있으며 그들은 아마도 최선을 다하려고 노력하고 있다는 것을 기억하십시오 (좌절감이 나타나더라도). 우리는 모두 Compose에 열정적이며 프로젝트가 계속 번창하기를 바랍니다.

docker-compose cp 하시겠습니까? 아직 확실하지 않을 수도 있습니다.

docker-compose exec 와 같은 유용한 편리함을 찾을 수 있습니다.

@ chris-crone 놀라운 응답, 감사합니다!

모든 사람을 대변하지는 않지만 configs 지원이 여기에 대한 대부분의 관심을 충족 시킨다는 인상을받습니다. 이것에 대한 이슈가 열릴까요?

그리고 몇 가지 대안을 제공해 주셔서 감사합니다. 지금까지 다단계 빌드에 대해 몰랐습니다.

configs 지원이 여기에 대한 대부분의 관심을 충족 시킨다는 인상을 받았습니다.

나는 여기의 대다수가 Swarm을 사용하지 않는다고 생각하고 config 기능이 필요하다고 생각하기 때문에 이것을 의심합니다.

예, 현재 Swarm이 필요하지만 @ chris-crone의 의견에서 ...

이들은 Swarm 및 Kubernetes에서 지원되지만 docker-compose에서는 지원되지 않습니다. 이에 대한 지원을 추가해야하며이 문제에 나열된 일부 사용 사례에 도움이 될 것이라고 생각합니다.

... 나는 이것이 docker-compose에서 구현 될 수 있다는 것을 읽고 있습니다 (sans Swarm)

Compose 형식의 목표는 애플리케이션을 쉽게 작성하고 로컬에서 테스트 한 다음 변경 사항이 거의 또는 전혀없이 조정 된 환경에 배포하는 것입니다.

복잡한 앱에는 즉석에서 조정해야하는 구성 파일이 상당히 많을 수 있습니다. 지금 가장 효율적인 (시간 및 비용 현명한) 방법은 볼륨 키를 채우는 것입니다 (정확한 사람이 여러 구성을 테스트하는 동안 다른 이미지를 만들지 않기 때문입니다. 개발 시간에).

Swarm 및 config는 나열된 여러 사용 사례에 실제로 응답하지 않습니다. compose가 이미 docker에서 할 수있는 작업을 수행하고 있기 때문에 "분리 우려"도 적용 할 수 없지만 단순화합니다. 래퍼는 분리가 아닙니다 ... 우리는 당신에게 조금 더 확장하라고 요청하는 것입니다 ...

https://github.com/docker/compose/issues/6643

그것으로 해키를 얻으십시오 .. 새 키 아래의 모든 파일이 단일 볼륨에 동적으로 연결되고 각각의 내부 경로에 매핑되는 볼륨 기능을 확장하십시오.

여기에 완벽하게 유효한 두 가지 시나리오가 있다고 생각합니다. 하나는
개발 환경. 사람들은 소스로 유연한 환경을 만듭니다.
이미지에 코드가 탑재되었습니다. 소스 코드는 개발에 따라 진화합니다.
이미지를 지속적으로 재 구축 할 수 없거나 낭비합니다.
엄청난 시간. 그게 내 시나리오이고 나는 이것이
시나리오는 다른 많은 사람들에게 적용됩니다.

두 번째는 소스 코드를 굽는 프로덕션 이미지에 관한 것입니다.
(컴파일되지 않은 스크립트로 작업하는 경우) 이미지에 (및
그런 다음 다시, 나는 그렇지 않았습니다, 나는 여전히 그것을 내 옆에 장착하고있었습니다) 또는 당신은
응용 프로그램을 컴파일하고 최종 이미지에 복사합니다. 그 시점에서
응용 프로그램은 매우 이식성이 있습니다.

나는 모두가 그것을 이해한다고 생각합니다! 문제는 도커 작성을 수행하는 것입니다.
dev는 시간을 들여 사례를 읽고 필요 사항을 이해 했습니까? 있습니다
이론상 여기에는 안티 패턴이 없습니다. 필요하고 원하는 개발자 만
존경받습니다.

우리는 docker, docker-compose 및 모든 생태계를 좋아합니다.
그것을 좋아하고 우리가 그것을 사용하기 때문에 당신은 직업이 있습니다 (적어도 당신 중 일부는
그것을 위해).

내가 지난 몇 년 동안 배운 것을 여기로 가져오고
다음이 있으며이 시나리오에 매우 잘 적용됩니다.

중요한 것은 소프트웨어가하는 일이 아니라 사용자가하는 일입니다.
중요한 그것으로

건배와 행복한 연속성!
ᐧ

2019 년 6 월 6 일 목요일 10:55에 jadon1979 [email protected]이 작성했습니다.

작성 형식의 목표는 응용 프로그램을 쉽게 작성할 수 있도록하는 것입니다.
로컬에서 테스트 한 후 다음을 사용하여 오케스트레이션 된 환경에 배포합니다.
거의 또는 전혀 변경되지 않습니다.

복잡한 앱에서는 필요한 구성 파일이 상당히 많을 수 있습니다.
즉석 조정. 현재 가장 효율적인 (시간 및 비용 현명한) 방법
그렇게하는 것은 볼륨 키를 채우는 것입니다 (정상적인 사람이
여러 구성을 테스트하면서 다른 이미지를 만들려면 ..
그들은 개발 시간에 돈을 쓰는 것을 좋아하는 상사가 있습니다).

Swarm 및 config는 실제로 몇 가지 사용 사례에 응답하지 않습니다.
나열됩니다. 이미 작성하여 "관심의 분리"도 적용되지 않음
도커에서 할 수있는 작업을 수행하지만 단순화합니다. 래퍼는 아닙니다
분리 ... 우리는 당신이 그것을 조금 더 확장하라고 요청하는 것입니다 ...

6643 https://github.com/docker/compose/issues/6643

그것으로 해키를 얻으십시오 .. 아래의 모든 파일이 볼륨 기능을 확장
새 키는 단일 볼륨에 동적으로 연결되고
각각의 내부 경로 ...

—
댓글을 달았 기 때문에 수신 한 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/docker/compose/issues/5523?email_source=notifications&email_token=ABBR3OMQH62242SM4QN5Y7TPZEQP7A5CNFSM4EKAVONKYY3PNVWWK3TUL52HS4DFVREXG43VMVBWPZGODW2995ZLOPWSZGODMVXHJKTissue ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/ABBR3OMOZFZ47L6ITHPF2TDPZEQP7ANCNFSM4EKAVONA
.

ROOT.war 이 아닌 .war에서 내 앱을 실행하기 위해 docker Tomcat 환경을 가동하고 싶습니다. 이렇게하려면 Tomcat의 webapps 디렉터리에 복사하고 현재 바인딩 된 포트 8005/9에서 실행되도록 ROOT로 이름을 변경해야합니다. '불법 액세스'에 대한 오류가있는 포트의 리 바인딩 문제로 인해 다른 모든 작업이 실패합니다. 이들은 임시 테스트 빌드이므로 Dockerfile에 들어갈 수 없습니다. 이것이 내가 docker-compose 에서 원하는 이유입니다.

뿡뿡

나는 내가 모든 사람을 대변하지는 않는다는 것을 알고 있지만 구성 지원이 여기에 대한 대부분의 관심을 충족 시킨다는 인상을받습니다. 이것에 대한 이슈가 열릴까요?

이 문제에 대해 아직 문제가없는 경우 하나를 만들어 여기에 연결하십시오. 개인 팀 추적기에 뭔가를 추가했습니다.

트윗 담아 가기

... 나는 이것이 docker-compose에서 구현 될 수 있다는 것을 읽고 있습니다 (sans Swarm)

우리는 이미 기초적인 비밀 지원을 가지고 있으며 유사한 방식으로 구성을 구현할 수 있습니다.

확실히 누락 된 기능입니다. 유일한 "반 패턴"은 dockerfile의 진입 점 스크립트를 변경하거나 마운팅 파일을 컨테이너에 바인딩하는 등 다른 방법으로 수행하기 어렵다는 사실을 해결해야하는 경우입니다.

원하는 것은 한 번, 가급적이면 공식적으로 빌드되고 사용 시점, 즉 docker-compose에서 사용 사례에 맞게 구성 할 수있는 컨테이너입니다.

도커 사람들이 깨닫지 못하는 한 "Dockerfile"이 전체 도커 개념에서 가장 큰 반 패턴이라는 것을 알 수 있습니다. 특히 모든 것이 완전히 읽을 수없고 관리 할 수 ​​없기 때문입니다. 도커와 관련된 누군가가 "반 패턴"이라는 단어를 그들이 아는 것처럼 버릴 때 정말 나를 웃게 만듭니다!

Dockerfile은 실제로 빌드 스크립트를 사용하거나 실제로 패키지 관리자 또는 make와 같은 빌드 용으로 설계된 것을 사용하는 경우 사용할 수있는 정상적인 디버깅 및 정리를 방지합니다.

나 자신을 위해 모든 사용 사례에 동일한 DockerFile을 사용합니다 (패턴으로 만듭니다!). 다른 용도로 DockerFile을 변경하고 실제로는 안티 패턴이라고 제안합니다.

그리고 "구성 지원"이 전혀 필요하지 않은 곳에 구조를 부과하지 않습니다.

근본적인 문제는 마운트를 / etc / nginx라고 말하도록 바인드하면 구성을 조정하는 스크립트를 실행할 수 있도록 rw 여야한다는 것입니다 (일명 envsubst). 그런 다음 입력 구성을 변경합니다 (불변 상태로 유지해야 함) ... 컨테이너가 구성 전체를 작성하는 것보다 훨씬 더 많은 반 패턴을 얻지 못하므로 다시 생성 할 때 파일을 컨테이너에 복사하는 옵션이 필요합니다. 해결책.

즉, 컨테이너에서는 바인드 마운트 디렉토리 rw이지만 호스트에서는 ro입니다. 이걸 허용하면 정말 당신을 죽일까요?

확실히 누락 된 기능입니다. 유일한 "반 패턴"은 dockerfile의 진입 점 스크립트를 변경하거나 마운팅 파일을 컨테이너에 바인딩하는 등 다른 방법으로 수행하기 어렵다는 사실을 해결해야하는 경우입니다.

원하는 것은 한 번, 가급적이면 공식적으로 빌드되고 사용 시점, 즉 docker-compose에서 사용 사례에 맞게 구성 할 수있는 컨테이너입니다.

도커 사람들이 깨닫지 못하는 한 "Dockerfile"이 전체 도커 개념에서 가장 큰 반 패턴이라는 것을 알 수 있습니다. 특히 모든 것이 완전히 읽을 수없고 관리 할 수 ​​없기 때문입니다. 도커와 관련된 누군가가 "반 패턴"이라는 단어를 그들이 아는 것처럼 버릴 때 정말 나를 웃게 만듭니다!

Dockerfile은 실제로 빌드 스크립트를 사용하거나 실제로 패키지 관리자 또는 make와 같은 빌드 용으로 설계된 것을 사용하는 경우 사용할 수있는 정상적인 디버깅 및 정리를 방지합니다.

나 자신을 위해 모든 사용 사례에 동일한 DockerFile을 사용합니다 (패턴으로 만듭니다!). 다른 용도로 DockerFile을 변경하고 실제로는 안티 패턴이라고 제안합니다.

그리고 "구성 지원"이 전혀 필요하지 않은 곳에 구조를 부과하지 않습니다.

근본적인 문제는 마운트를 / etc / nginx라고 말하도록 바인드하면 구성을 조정하는 스크립트를 실행할 수 있도록 rw 여야한다는 것입니다 (일명 envsubst). 그런 다음 입력 구성을 변경합니다 (불변 상태로 유지해야 함) ... 컨테이너가 구성 전체를 작성하는 것보다 훨씬 더 많은 반 패턴을 얻지 못하므로 다시 생성 할 때 파일을 컨테이너에 복사하는 옵션이 필요합니다. 해결책.

즉, 컨테이너에서는 바인드 마운트 디렉토리 rw이지만 호스트에서는 ro입니다. 이걸 허용하면 정말 당신을 죽일까요?

이 같은:

```

파일을 덮어 쓰면

디렉토리가 대상의 내용을 덮어 쓰거나 추가하면

원본의 내용으로 원래 대상 구조를 유지

소스 : 파일 : p ermission : 소유자 : 그룹

svc :
부:
- './source/filename:/path/ filename : ro : www-data'
- './source/dir:/path/ dir : ro : www-data'

# 또는
svc :
부:
-출처 : './source/file'
목적지 : '/ destination'
허가 : ro
소유자 : 소유자
그룹 : 그룹
-출처 : './source/directory'
목적지 : '/ destination'
허가 : ro
소유자 : 소유자
그룹 : 그룹 ''`

사용 사례 : 애플리케이션의 docker-compose 파일이 포함 된 조정되지 않은 컨테이너 솔루션이 있습니다. Git-repository 내부의 SSL 인증서 등을 VM으로 가져옵니다. 그런 다음 서비스를 가동하고 예를 들어 SSL 인증서, 구성 파일 등을 컨테이너의 볼륨으로 이동하려고합니다. 이것은 현재 COPY 명령이있는 Dockerfile이 없으면 불가능합니다. 복제 된 git repo 내부의 파일을 엉망으로 만들고 싶지 않습니다. 애플리케이션이 파일을 변경하면 매번 저장소를 정리해야합니다.

@MartinMajewski 그런 다음 인증서가있는 디렉터리를 볼륨으로 마운트 하고 응용 프로그램 구성에서 지정할 수 있습니다.

사용 사례 (및 방법에 대한 질문) :
postgres 이미지에 시작시 단일 환경 변수를 설정할 수 있습니다 : POSTGRES_PASSWORD . Docker Secret을 통해 설정하고 싶습니다. 내가해야 할 일은 첨부 된 Secret을 실행중인 컨테이너의 env var로 내보내는 내 자신의 entrypoint.sh 를 넣는 것입니다. 이 진입 점을 시작시 컨테이너에 추가해야합니다. 2 줄 Dockerbuild 없이는 할 수 없습니다. 하나의 단일 파일을 복사 할 수 없습니다.

PS postgres 가 그 예입니다. _FILE env vars를 지원하지 않는다고 가정합니다.

내부 추적 문제 https://docker.atlassian.net/browse/COMPOSE-89

사용 사례 : Karaf
프로젝트를 빌드 할 때마다 다시 빌드하고 싶지 않은 karaf 기본 이미지를 사용하여 앱을 빠르게 배포하고 모든 빌드에 대해 컨테이너를 다시 빌드 할 수 있기를 원합니다. 그러나 컨테이너를 시작할 때 _features.xml_ 및 _jar_을 deploy 디렉터리에 복사해야합니다.

지금까지 내 솔루션은 karaf 이미지를 또 다른 Dockerfile (overlayfs에 의존하여 결국 오버레이가 부족하여 이미지를 수동으로 삭제해야 함) 및 avast / gradle-docker-compose-plugin에서 기본 이미지로 사용하는 것이 었습니다. init 명령은 반드시 환경 변수로 전달할 수 있지만 features.xml의 내용은 전달할 수 없습니다. 컨테이너의 특정 위치에 파일로 저장해야합니다. 지금은 볼륨 바인드 마운트 만 사용하면됩니다. 원격 시스템의 해당 볼륨에 항목을 가져 오려면 어떻게합니까? 내 빌드 스크립트에 더 많은 로직이 필요합니다 (예 : org.hidetake.groovy.ssh, 비밀 암호 / 키 로직으로 빌드 스크립트를 복잡하게 함). docker-compose cp를 사용할 수있는 경우 필요한 복사 명령을 docker-compose.yml에 추가 할 수 있습니다. avast / gradle-docker-compose-plugin은 컨테이너를 빌드하고 추가 원격 파일 시스템 액세스 논리없이 내 빌드 출력의 파일을 컨테이너로 직접 복사하는 작업을 처리합니다.

이 Dockerfile은 스크립트의 docker-compose.yml 빌드 부분에 추가됩니다. 무엇이든간에 이것은 반 패턴입니다. 왜냐하면 각 빌드와 함께 업스트림 도커 이미지에 오버레이를 추가하기 때문입니다 (이미지를 수동으로 삭제해야 할 때까지 빌드 속도가 훨씬 느려질 때까지).

FROM myregistry:443/docker/image/karaf-el7:latest

COPY karafinitcommands /usr/local/karaf/etc/

COPY features.xml \
     *.jar \
     /usr/local/karaf/deploy/

docker cp가 런타임 복사에 잘 작동하지만 docker-compose에는 동등한 메커니즘이 없다는 것이 실망 스럽습니다.

아이디어는 로컬 디렉토리를 / usr / local / karaf / deploy에 마운트하고 거기에 파일을 놓는 것이라고 생각했습니다. 나는 이것을 유지하기 위해 이미지를 다시 빌드하거나 도커 파일을 사용할 것으로 기대하지 않습니다.

아이디어는 로컬 디렉토리를 / usr / local / karaf / deploy에 마운트하고 거기에 파일을 놓는 것이라고 생각했습니다. 나는 이것을 유지하기 위해 이미지를 다시 빌드하거나 도커 파일을 사용할 것으로 기대하지 않습니다.

확실히 그렇게 할 수 있습니다. 다시 읽고 이것이 순전히 편리한 문제라는 것을 주목하십시오. 컨테이너는 gradle 빌드로 다시 빌드됩니다. 다음 논리 단계는 다음과 같습니다. 새 빌드 파일을 / usr / local / karaf / deploy에 마운트 된 "로컬 디렉토리"로 어떻게 이동합니까? 제 경우에는 "로컬 디렉토리"가 더 정확하게는 호스트가 원격 호스트 인 "호스트 디렉토리"입니다. 따라서 파일을 가져오고 이전 파일을 교체하고 추가 파일을 제거하기 위해 rsync 또는 다른 것을 빌드 스크립트에 추가해야합니다. docker-compose cp를 사용할 수 있다면 불필요합니다. 기존의 도커 클라이언트를 포트 포워딩을 통해 설정 한 도커 데몬 연결에 활용할 수 있습니다.

Docker 볼륨은 각 빌드에서 제거 할 수 있습니다. 마운트 볼륨을 바인드 할 수 없습니다. 비어있는 경우에만 다시 채워

다시 말하지만, docker cp를 사용하여 런타임 환경으로 복사 할 수 있습니다. 그것은 실망스러운 부분입니다.

아, 나도 내 설정에 익숙해 져. http://github.com/keithy/groan을 사용하여 비트와 조각을 원격 서버에 자체 배포하는 bash 스크립트를 사용한 다음 docker를 호출합니다.

사용 사례 : Google 클라우드 빌드 및 빌드 아티팩트

아티팩트 필요 : 웹 클라이언트 (자동 생성)는 graphql 바인딩에 반응합니다. 클라이언트 컴파일에 필요한 파일을 생성하려면 서버를 실행해야합니다. 클라이언트 이미지에는 서버 주소가 주어지면 바인딩을 만드는 도구가 있습니다. 따라서 배경에서 서버 이미지를 시작하고 이제 서버를 가리키는 클라이언트 컨테이너를 실행해야합니다. 이제 생성 된 파일을 컨테이너에서 "작업 공간"호스트 디렉토리로 가져 오는 방법은 무엇입니까? Docker 컨테이너의 마운트 된 디렉토리에 이미 있으므로 마운트 디렉토리가 허용되지 않습니다. docker-compose cp 을 (를) 할 수 있으면 컨테이너 ID를 가져 오는 추가 고통스러운 단계를 완화 할 수 있습니다.

$(docker-compose ps -q SERVICE) 에 의존하여 올바른 컨테이너를 대상으로하면 이러한 컨테이너 중심 작업에 일반 Docker CLI를 사용할 수 있습니다. 새로운 명령을 도입하면 명령을 요청하는 소수의 사용 사례가 더 간단 해지지 만 필수는 아닙니다. compose와 docker CLI 사이에 더 많은 코드 중복을 방지하려면이 문제를 해결해야한다고 생각합니다.

Docker 데몬 compose가 사용중인 버전으로 인해 compose와 일반 docker 간의 빌드 캐시가 다른 공개 된 문제가 있습니다. 즉, CI 환경에서 캐시를 중단하지 않으려면 pure compose를 사용해야합니다 (https : // github .com / docker / compose / issues / 883) 따라서 이러한 문제가 해결 될 때까지 일반 docker 명령과 compose 명령을 혼합하면 캐시가 손상됩니다. compose config는 모든 종류의 구워진 config를 지정하므로 일반 docker 명령으로 중복 구성을 수동으로 지정할 필요가 없습니다.

$(docker-compose ps -q SERVICE) 에 의존하여 올바른 컨테이너를 대상으로하면 이러한 컨테이너 중심 작업에 일반 Docker CLI를 사용할 수 있습니다. 새로운 명령을 도입하면 명령을 요청하는 소수의 사용 사례가 더 간단 해지지 만 필수는 아닙니다. compose와 docker CLI 사이에 더 많은 코드 중복을 방지하려면이 문제를 해결해야한다고 생각합니다.

이러한 시나리오는 매우 일반적이고 수정, 이미지 빌드, 다시 수정, 이미지 빌드 등이 docker-compose를 통해 이러한 작업을 처리 할 수있는 시간 싱크 구절이기 때문에 "언급 된 사용 사례"보다 훨씬 더 깊습니다. "당신은 docker cli에서 할 수 있으므로 거기에서 할 수 있습니다"라는 주장은 docker-compose에 추가 된 수많은 다른 것들을 거의 무효화합니다.

이 문제는 거의 1 년 동안 공개되었으며이 문제 외에 다른 많은 논의가 있습니다. 실제로 해결되지 않는 한 닫히면 안됩니다.

@dionjwa # 883은 docker-compose가 docker CLI와 정렬되어야하므로 (여전히 관련이있는 경우) 실제로 조사해야합니다.

@ jadon1979 이 기능 요청을 차단하려는 것이 아닙니다. 1 년 이상 전에 열렸으며 핵심 관리자 중 누구도 새 명령을 도입 할만큼 중요하다고 생각하지 않았으며 기여자도 PR을 제안하지 않았습니다. 그것.
이 기능 요청에 대한 피드백과 "더 나은 방법"을 제공하기위한 개발 노력의 부족에 따라 쉽게 별칭을 지정할 수있는 docker-compose 및 docker cli의 조합을 사용하는 제안 된 해결 방법을 말합니다. 사용하기 쉽게 유지하는 환경은 합리적인 해결 방법입니다.
이제 누군가가 PR을 열어 새로운 cp 명령을 제공하면 기꺼이 검토하겠습니다.

모든 사용 사례가
안티 패턴. 그리고 며칠마다 새로운 사용 사례가 게시되지만
안티 패턴.

2019 년 11 월 18 일 월요일 오후 5:31 Nicolas De loof [email protected]
썼다 :

@dionjwa https://github.com/dionjwa # 883
https://github.com/docker/compose/issues/883 정말 필요합니다
docker-compose가 정렬되어야하므로 (여전히 관련이있는 경우) 조사
도커 CLI.

@ jadon1979 https://github.com/jadon1979 나는 이것을 차단하려고하지 않습니다
기능 요청, 방금 열렸던 지 1 년이 넘었고
핵심 유지 관리자 중 누구도
새로운 명령을 도입했지만, 기여자는 PR을 제안하지도 않았습니다.
이 기능 요청에 대한 피드백에 따르면
그리고 "더 나은 방법"을 제공하기위한 개발 노력의 부족, 제안 된
docker-compose 및 docker cli의 조합을 사용하는 해결 방법입니다.
사용하기 쉽게 유지하기 위해 환경에서 쉽게 별칭을 사용할 수 있습니다.
합리적인 해결 방법.
이제 누군가가 새로운 cp 명령을 제공하기 위해 PR을 열면 기꺼이
그것을 검토하십시오.

—
당신이 언급 되었기 때문에 이것을 받고 있습니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/docker/compose/issues/5523?email_source=notifications&email_token=AAGRIF2NS64IYANNVTGFTULQUL3TZA5CNFSM4EKAVONKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5W2ZLO
또는 구독 취소
https://github.com/notifications/unsubscribe-auth/AAGRIFY7CULCUS3TDDTTHZLQUL3TZANCNFSM4EKAVONA
.

내 사용 사례는 컨테이너로 복사하는 것이 아니라 실행 후 컨테이너에서 복사하는 것입니다. 이 작업 은 틀림없이 저하 된 기능을 생성하는 투박한 해결 방법을 사용 하여 CLI에서 수행 할 수 있습니다. 아래에 자세한 내용이 있습니다.

저는 DevOps 엔지니어이며 베어 메탈 빌드 에이전트의 종속성 지옥의 대안으로 컨테이너에 크게 의존합니다. 내 CI 시스템이 리포지토리를 테스트 할 때 동일한 리포지토리 내의 Dockerfile에서 빌드하고 모든 검사 ( bundle exec rspec , npm test 등)를 _ 컨테이너 내부에서 실행합니다 _. 문서 또는 테스트 결과와 같이 생성 된 빌드 아티팩트가있는 경우 docker cp 를 사용하여 컨테이너에서 복사하기 만하면됩니다.

통합 테스트의 경우 docker-compose 를 사용하여 테스트를 실행하는 컨테이너에 서비스 종속성 (예 : 데이터베이스 서버)을 제공하기 시작했습니다. 안타깝게도 "docker CLI 해결 방법"은이 경우 파일을 복사하는 데 유용하지 않습니다.

이 구성 고려 : docker-compose-minimal.yml

version: "3"
services:
  artifact-generator:
    image: busybox

컨테이너를 만들고, 해당 컨테이너에서 명령을 실행하고, 컨테이너 ID를 얻은 다음 docker cp 사용하여 파일을 추출해 보겠습니다.

$ # Prepare the images and (stopped) containers.  In this case there is only one.
$ docker-compose --file docker-compose-minimal.yml up --no-start
Creating network "docker-compose-cp-test_default" with the default driver
Creating docker-compose-cp-test_artifact-generator_1 ... done
$ # Determine the ID of the container we will want to extract the file from
$ docker-compose --file docker-compose-minimal.yml ps -q artifact-generator
050753da4b0a4007d2bd3514a3b56a08235921880a2274dd6fa0ee1ed315ff88
$ # Generate the artifact in the container
$ docker-compose --file docker-compose-minimal.yml run artifact-generator touch hello.txt
$ # Check that container ID again, just to be sure
$ docker-compose --file docker-compose-minimal.yml ps -q artifact-generator
050753da4b0a4007d2bd3514a3b56a08235921880a2274dd6fa0ee1ed315ff88
$ # OK, that looks like the only answer we're going to get.  Can we use that to copy files?
$ docker cp $(docker-compose --file docker-compose-minimal.yml ps -q artifact-generator):hello.txt ./hello-artifact.txt
Error: No such container:path: 050753da4b0a4007d2bd3514a3b56a08235921880a2274dd6fa0ee1ed315ff88:hello.txt
$ # Nope.  Let's take a look at why this is
$ docker container ls -a
CONTAINER ID        IMAGE                        COMMAND                   CREATED              STATUS                          PORTS               NAMES
9e2cb5d38ba0        busybox                      "touch hello.txt"         About a minute ago   Exited (0) About a minute ago                       docker-compose-cp-test_artifact-generator_run_dd548ee686eb
050753da4b0a        busybox                      "sh"                      2 minutes ago        Created                                             docker-compose-cp-test_artifact-generator_1

보시다시피 docker-compose ps 실제로 업데이트 된 컨테이너 ID를 알지 못합니다. 이것은 불행한 일입니다. run_dd548ee686eb 이 내가 실행 한 docker-compose run 와 어떻게 든 관련이 있다는 것을 알 수있는 방법이 있다면 그렇게 나쁘지 않을 것입니다. 그러나 그것을 달성 할 방법은 없습니다.

이 해결 방법에는 --name 를 실행 명령에 추가하는 간단한 해결 방법이 있습니다.

$ docker-compose --file docker-compose-minimal.yml run --name blarg artifact-generator touch hello.txt
$ docker cp blarg:hello.txt ./hello-artifact.txt
$ ls 
docker-compose-minimal.yml  hello-artifact.txt

성공! ... 좀

여기서 문제는 여러 빌드를 병렬로 실행하는 경우 --name 전역 적으로 고유하게 만드는 문제를 해결해야한다는 것입니다. 그렇지 않으면 최상의 경우에는 시끄러운 충돌이 발생하고 최악의 경우 손상된 결과 (오류는 없지만 잘못된 파일이 추출 됨)가 발생합니다. 따라서 Docker가 이미 만든 것을 사용하는 대신 컨테이너 ID 생성을 다시 만들어야하기 때문에 이것은 투박합니다.

최소한 docker-compose run 명령의 결과 인 컨테이너의 ID를 알 수있는 방법이 필요합니다.

뿡뿡

$ (docker-compose ps -q SERVICE)를 사용하여 올바른 컨테이너를 대상으로하면 이러한 컨테이너 중심 작업에 일반 docker cli를 사용할 수 있습니다.

False, 이전 주석의 데모를 참조하십시오.

우리는 여기에서 수년간 새로운 사용 사례를 가질 것입니다. 잠깐만 새로운 안티
패턴 ...

2019 년 12 월 13 일 금요일 11:40 Ian, [email protected] 작성 :

@ndeloof https://github.com/ndeloof

$ (docker-compose ps -q SERVICE)에 의존하여 올바른 컨테이너를 대상으로 지정
컨테이너 중심의 일반 도커 CLI를 사용할 수 있습니다.
작업.

False, 이전 주석의 데모를 참조하십시오.

—
당신이 언급 되었기 때문에 이것을 받고 있습니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/docker/compose/issues/5523?email_source=notifications&email_token=AAGRIF2NFPTKY3QKRIXQ5RTQYONHLA5CNFSM4EKAVONKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNEGMVXHJKJKTDN5WW2ZLO026 ,
또는 구독 취소
https://github.com/notifications/unsubscribe-auth/AAGRIF3S4UHF5NG3VKYXJB3QYONHLANCNFSM4EKAVONA
.

관리자에게 연락하기 위해 누구를 언급 할 수 있습니까? 이 문제는 그들이 우리와 대화를 시작할 때까지 의미가 없습니다. "현재 소프트웨어 아키텍처로 인해 수행 할 수없는 작업"일 수도 있습니다. 그러나 그러한 문제를 비활성 상태로 두는 것은 Docker와 같은 인기있는 솔루션에서보고 싶은 것이 아닙니다.

배포는 bazel을 사용하여 Docker 이미지를 빌드하고 Docker 레지스트리에 업로드 한 다음 upload 스탠자와 함께 Terraform docker_container 리소스를 사용하여 구성 파일을 컨테이너에 복사합니다. Terraform 대신 docker-compose를 사용하려면이 배포 프로세스를 마이그레이션해야합니다. docker-compose가 컨테이너 별 구성에 대한 기능을 제공하지 않는다는 사실에 놀랐습니다.

이 호는 2 년 동안 공개되었습니다. 이것이 Kubernetes가 인기에서 Docker를 앞지르는 이유입니까? Kubernetes는 구성 및 비밀 기능을 제공합니다. Docker 팀, 최소한 구성 기능을 추가하십시오.

tbf docker-compose는 k8s와 정확히 비교할 수 없으며 프로덕션 용도로 권장되지 않습니다. 개발 및 빠른 테스트를위한 것입니다. docker swarm은 k8s와 비교할 수 있으며 매우 단순하지만 구성 및 비밀과 같은 기능이 있습니다.

개발만을위한 것이라면이 문제가 더 많은 이유입니다.
작동해야합니다. 엉뚱한 "반 패턴"규칙은
중요합니다 (정상적인 사용이 풍부하기 때문에
안티 패턴과 닮지 않은 경우).

2020 년 3 월 3 일 화요일 오후 12:56 David Milum [email protected]
썼다 :

tbf docker-compose는 k8s와 정확히 비교할 수 없으며 권장하지 않습니다.
생산 용. 개발 및 빠른 테스트를위한 것입니다. 도커
swarm은 k8s와 비교할 수있는 것입니다.
단순하지만 구성 및 비밀과 같은 기능이 있습니다.

—
당신이 언급 되었기 때문에 이것을 받고 있습니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/docker/compose/issues/5523?email_source=notifications&email_token=AAGRIFZTKGRWMZZ5H6DG3FDRFUSEJA5CNFSM4EKAVONKYY3PNVWWK3TUL52HS4DFVREXG43VMVORPWSZ5W594W2ZLOBW63LNMVXHJKissue ,
또는 구독 취소
https://github.com/notifications/unsubscribe-auth/AAGRIF4NTQQSR2QQWPJT6PLRFUSEJANCNFSM4EKAVONA
.

또 다른 "반 패턴":

로컬 개발 중에는 컨테이너 오케스트레이션에 docker-compose 를 사용하고 프로덕션에는 k8을 사용합니다.

Docker의 조언 에 따라 서비스 시작 / 종료 순서를 관리하기 위해 wait-for-it.sh 스크립트를 구현했습니다.

이 파일 하나에 대해 각 서비스에 볼륨을 마운트하지 않으려면 각 서비스의 Dockerfile이 포함 된 디렉토리에 스크립트 사본이 필요합니다.

대신 docker-compose 가 로컬에서 실행될 때 각 컨테이너에 복사되는 wait-for-it 스크립트의 단일 복사본을 최상위 디렉터리에 유지하고 싶습니다. 이는 내 서비스의 Dockerfile 오염시키는 이러한 우려를 원하지 않는다는 의미입니다.

에머슨은 한때 이렇게 썼습니다. "어리석은 일관성은 작은 정치가와 철학자와 신자들이 숭배하는 작은 마음의 홉 고블린입니다."

아마도 사용자의 말을 들어야 할 때입니다 ...

@Phylodome 은 컨테이너 상태 확인과 docker-compose depends_on 없습니까? 이것이 내가 건강한 컨테이너 시작 종속성을 보장하는 방법입니다.

내 이해는 wait-for-it.sh 은 (는) 정말 해킹이라는 것입니다. 서비스 자체가오고가는 종속성에 탄력적이어야하기 때문입니다. 스타트 업은 그저 개별적인 경우입니다.

@ianfixes "귀하의 서비스"는 docker-compose 서비스 자체를 의미

"귀하의 서비스"는 docker-compose 서비스 자체를 의미합니까, 아니면 docker-compose를 사용하는 당사가 작성한 서비스에서와 같이 "당사의"서비스를 의미합니까?

개발자로서 구축하는 서비스는 탄력적이어야합니다. 이것은 다음 문서에 따른 것입니다 : https://docs.docker.com/compose/startup-order/

데이터베이스 (예 :)가 준비 될 때까지 기다리는 문제는 실제로 분산 시스템의 훨씬 더 큰 문제의 하위 집합에 불과합니다. 프로덕션에서 데이터베이스를 사용할 수 없게되거나 언제든지 호스트를 이동할 수 있습니다. 애플리케이션은 이러한 유형의 오류에 대해 탄력적이어야합니다.

이를 처리하려면 실패 후 데이터베이스에 대한 연결을 다시 설정하도록 애플리케이션을 설계하십시오. 애플리케이션이 연결을 재 시도하면 결국 데이터베이스에 연결할 수 있습니다.

가장 좋은 해결책은 시작할 때와 어떤 이유로 든 연결이 끊어 질 때마다 애플리케이션 코드에서이 검사를 수행하는 것입니다. 그러나이 수준의 복원력이 필요하지 않은 경우 래퍼 스크립트로 문제를 해결할 수 있습니다.

그리고 다양한 대기 스크립트를 언급합니다.

나는 여러 가지를 할 수 있습니다. 그러나 이것은 단지 로컬 개발을위한 것이고, k8s에서 프로덕션 서비스 검사를 처리하기위한 다른 전략이 있기 때문에, 나는 왜 내가 선호 할 것입니다. (예 : Webpack의 개발 서버를 통해 UI 개발을 수행하기위한 볼륨 마운트 문제).

어쨌든, 사용자의 재량에 맡겨야하는 기능이 될이 기능에 대한 긴 사용 사례 목록에서 또 하나 일뿐입니다.

저를 향한 분노를 듣고 있으며 귀하의 접근 방식에 대한 원치 않는 "조언"을 듣는 것이 왜 실망 스러운지 이해합니다. 하지만 어떻게 사과해야할지 모르겠습니다. 나는 당신이 "Docker의 자신의 조언"이라고 부르는 URL의 텍스트를 인용했는데, 이것은 _ 명시 적으로 _ 대기 스크립트가 "문제를 해결하는"방법이라는 것을 말합니다. 그만한 가치에 대해서는 어쨌든 미안합니다.

분노가 들리지 않습니다. 당신은 꽤 명백한 기능이되어야하는 것을 인터넷 검색을하다가 100 개의 댓글 스레드를 우연히 발견 한 누군가의 분노한 어조를 들었을 때, 일련의 메인테이너들이 지속적으로 후원하고 완전히 유효한 기능에 대한 커뮤니티의 탄원을 거부했습니다.

나는 여기에서 나의 경험을 공유하지 않았다. 나는 사과를 원했다. Docker 사용자가 compose 사용할 때 추가적인 유연성을 원한다는 증거를 긴 목록에 추가하기 위해 간단히 공유했습니다.

물론 다른 도구와 마찬가지로 이러한 유연성은 남용 가능성과 함께 제공됩니다. 그러나 사용자가이 기능을 추가하기 만하면 훨씬 더 쉽게 해결할 수있는 특정 사용 사례를 해결하기위한 해결 방법을 찾아야하는 경우에도 동일한 잠재력이 존재합니다.

또한 사용자를 변명스럽게 가스 라이팅하는 것은 나쁜 모습입니다.

나는이 프로젝트의 관리자도 아니고 기여자도 아니며 혼란을 드려 죄송합니다. 제가 제공 할 수있는 작은 도움이 원치 않고 도움이되지 않는다고 생각한 것 같습니다. 시간을 낭비하게되어 죄송합니다.

분산 응용 프로그램의 일부인 Go 컨테이너에이 기능이 필요합니다. .env 파일이 Go 애플리케이션의 루트에 포함되어야하므로 별도의 .env 을 만들어야합니다. 그러나이 기능이 있으면 내 최상위 .env 파일을 가지고 빌드 할 때 Go 컨테이너에 복사합니다. 추적해야 할 항목이 적다는 것을 의미합니다.

내 해결 방법은 Go 컨테이너의 Dockerfile 를 통해이 파일을 만들거나 해당 컨테이너에 대해 .env 파일을 만드는 것입니다. 그러나 여전히 새 환경 변수를 추가 할 때마다 두 곳에서 업데이트해야합니다. 여기에 좋은 사용 사례. 또는 셸 스크립트를 사용하여 cp 파일을 대신 사용할 수 있습니다.

COPY 기능에 대한 +1

우리는 이미 쿠 버네 티스에서 사이드카로 이것을 달성했으며 많은 사용 사례가 있습니다. 이것은 안티 패턴이 아니라 도커 구성을 유지하는 기능 중 하나 일뿐입니다.

뭔가 빠졌을지도 모르지만 5 분 동안 앱을 빌드 할 때마다 빌드 폴더가 "유동적"이며 불일치로 인해 앱이 시작되지 않습니다.
컨테이너에 빌드 폴더를 _copy_하는 것을 선호하므로 컨테이너를 시작할 때 내부 폴더를 대신합니다. 이런 식으로 앱은 컨테이너를 중지 / 시작할 때 1 초 정도만 오프라인 상태가됩니다.

docker 이미 지원하는 경우 어떻게 안티 패턴입니까? docker-compose 도커의 유용성을 따라 간다는 것은 이해가 될 것입니다. 그렇게하지 않는 것은 그 자체로 안티 패턴입니다.

이것의 문제점은 컨테이너가 다시 생성 될 때마다 작업을 반복해야하기 때문에 매우 근시안적이라는 것입니다 (따라서 "반 패턴"이라는 용어). 확장 성이 매우 낮다는 사실은 말할 것도 없습니다 (컨테이너가 10 개? 20? 100?).

그것은 개발자에게 달려 있다고 생각합니다. 단일 로컬 구성 파일을 복사하는 것만으로도 오버 헤드가 적습니다. 칼을 비난하지 마십시오.

PS 내 사용 사례; Dockerfile이없는 프로젝트의 Nginx 컨테이너에 구성을 추가하고 싶습니다.

더 이상 아는 사람.
새 프로젝트를 설정해야했고
도구, Lando는 이것보다 훨씬 낫습니다. 내가 사용했으면 좋겠어
빨리.
더 빠르고, 이해하기 쉬우 며, 즉시 사용할 수있는 지원 및
하향적 (예 :) 유지 관리자 / 기여자가 없습니다.

귀하의 의견 에 대해 @ chris-crone ...

구성 파일 또는 부트 스트랩 데이터의 경우 Docker Config가 있습니다. 이것들은 비밀과 비슷하게 작동하지만 어디에나 장착 할 수 있습니다. 이들은 Swarm 및 Kubernetes에서 지원되지만 docker-compose에서는 지원되지 않습니다. 이에 대한 지원을 추가해야하며이 문제에 나열된 일부 사용 사례에 도움이 될 것이라고 생각합니다.

docker-compose가 swarm 구성과 패리티에 대한 구성 지원을 구현하는 데 관심이 있습니까?

이것에 대한 티켓이 있다면 (또는 괜찮은 티켓을 만들어야하는 경우), 그 티켓을 구독하고이 쓰레기통에서 구독을 취소하고 싶습니다. 개인적으로 나는 이것을 닫고 그것에 연결하지만 그것은 나뿐입니다.

@harpratap 당신이 옳지 만, 단점은 / folder_in_container가 존재하지 않거나 비어 있어야하며 그렇지 않으면 덮어

COPY 기능이 있으면 +1. 우리의 사용 사례는 로컬 개발 환경을 신속하게 구축하고 개발 설정을위한 구성에서 복사하는 것입니다.

바로 그거죠. 우리는 모두 같은 방식으로 확장하지 않습니다. 우리 회사는 SALT를 사용하여 다양한 앱에 필요한 .conf 파일을 빌드합니다. 하나의 빌드-기본 사항-그런 다음 Docker- 구성하여 고유 한 부분 (MAC 주소, IP, 포트, 라이센스, 모듈 등)을 기반으로 개별 인스턴스를 생성합니다. 명령 줄에서 수행 할 수 있지만 훨씬 쉽고 간단합니다. docker-compose에서 오류가 발생하기 쉽습니다.

유스 케이스가 있습니다. SSL을 설정해야하는 테스트 빌드가 있습니다. 인증서는 docker-compose의 서비스에 의해 생성됩니다 ... 그런 다음 해당 인증서를 클라이언트 컨테이너에 추가합니다 ... 마운트하면 기존 인증서가 손실되고 Docker 빌드에 넣을 수 없습니다. 아직 존재하지 않습니다.

결과적으로 2 개의 docker-compose-1을 실행하여 서비스를 시작하여 인증서를 생성하고 다른 하나를 실행하여 서비스를 빌드하고 테스트를 실행해야합니다. 어질러 놓은.

여기에서 많은 문제를 보았습니다. 사용자가 기능에 대한 많은 사용 사례를 제안했지만 유지 관리자가 생각하는 것, 안티 패턴이거나 사람들이 사용하지 않거나 다른 이야기를 사용하지 않기 때문에 격추되었습니다. .

한 사람에게는 반 패턴처럼 보일지 모르지만이 기능을 요청하는 1000 명의 사람들은 그렇지 않다고 생각하는 사람들도들을 필요가 있다고 확신합니다. 기능 개발에 도움이 필요하면 많은 분들이 도움을 줄 수있을 것 같습니다.

내 사용 사례 : 구성 외에도 5 개의 Rails 애플리케이션 컨테이너 (Debian)에 설치해야하는 라이브러리 (RPM)가 있습니다. Ruby / Rails 버전이 다르므로 동일한 기본 이미지를 사용할 수 없으므로 파일을 단일 위치에 저장하고 빌드 할 때 컨테이너에 복사 할 수 있어야합니다. 1.5GB의 데이터를 다운로드하고 싶지 않습니다. 구축하는 동안.

안녕하세요.

내 사용 사례 : 구성 외에도 5 개의 Rails 애플리케이션 컨테이너 (Debian)에 설치해야하는 라이브러리 (RPM)가 있습니다. Ruby / Rails 버전이 다르므로 동일한 기본 이미지를 사용할 수 없으므로 파일을 단일 위치에 저장하고 빌드 할 때 컨테이너에 복사 할 수 있어야합니다. 1.5GB의 데이터를 다운로드하고 싶지 않습니다. 구축하는 동안.

이를 위해 다단계 빌드 를 살펴 보셨습니까? 더 강력한 솔루션이 될 것이라고 생각합니다.

다단계 빌드를 사용하면 여러 이미지에 동일한 Dockerfile을 사용할 수 있습니다. 이를 통해 요소를 인수 화하고 각 이미지에 필요한 비트 만 포함 할 수 있습니다.

하나의 좋은 예는 Docker Compose를 빌드하는 데 사용하는 것 입니다. 이것은 Debian 또는 Alpine을 사용하여 빌드되지만 공통 코드를 고려할 수 있습니다.

설정에서 docker-compose를 사용하여 약 12 ​​개의 시뮬레이터를 늘립니다. 시뮬레이터는 그렇지 않으면 동일하지만 각 대상에 대해 하나의 init 파일이 다르며이 파일은 시작시 사용됩니다 (서버가 실행 중일 때 삭제됨). 하나의 파일이 다르다고해서 거의 동일한 이미지를 12 개 정도 만들어야한다고 정말로 제안하고 있습니까? IMO는 말이되지 않습니다.

docker를 사용하면 --copy-service 플래그를 사용하여이를 수행 할 수 있습니다. docker-compose와 함께 사용할 수있는 대안이 있습니까?

안녕하세요 @megaeater ,

docker-compose를 사용하여 약 12 ​​개의 시뮬레이터를 늘립니다. 시뮬레이터는 그렇지 않으면 동일하지만 각 대상에 대해 하나의 init 파일이 다르며이 파일은 시작시 사용됩니다 (서버가 실행 중일 때 삭제됨).

이것은 흥미로운 사용 사례입니다. 몇 가지 질문 : 이러한 시뮬레이터 (또는 그 일부)가 프로덕션 환경에서 실행됩니까 (예 : 개발자의 컴퓨터 나 CI가 아님)? 코드가 열려있는 경우 (또는 유사한 시스템이있는 경우) 제가 살펴볼 수 있도록 저를 링크 해 주시겠습니까?

바인드 마운트 대신 사본이나 이러한 파일에 대한 볼륨을 원하는 이유를 아는 것도 흥미로울 것입니다.

하나의 파일이 다르다고해서 거의 동일한 이미지를 12 개 정도 만들어야한다고 정말로 제안하고 있습니까? IMO는 말이되지 않습니다.

이미지는 정확히 이러한 이유로 레이어 기반입니다. 모든 이미지는 다른 파일을 포함하는 레이어를 제외하고 동일한 레이어를 참조합니다.

컨테이너 생성 복사와 같은 문제는 동일한 코드를 사용하여 프로덕션 환경에서 실행하기 어렵게 만드는 것입니다 (예 : 주요 논리 재 작성 필요). 패턴이 오케스트레이션 된 환경에서 깨지기 쉬우거나 불가능하기 때문입니다.

이것은 Compose에서 이와 같은 것을 구현해서는 안된다는 의미가 아닙니다. 변경으로 인해 사용자가 프로덕션에서 로컬로 작동하는 것을 재사용 할 수 없게되는 경우, 우리는 일시 중지하고 동일한 목표를 달성하는 더 강력한 방법이 있는지 확인하는 것을 좋아합니다.

@ chris-crone 댓글 주셔서 감사합니다

우리는 프로덕션에서 docker를 실행하지 않고 개발 목적으로 만 사용합니다. 볼륨 사용의 문제 (올바르게 이해하는 경우)는 시뮬레이터 (타사)에 시작시 파일을 삭제하는이 시작 스크립트가 있다는 것입니다. 삭제에 실패하면 스크립트 실행이 중지되므로 rw로 마운트해야합니다. 그리고 파일 삭제가 허용되면 원본이 삭제되지 않도록 이러한 파일을 제공하기위한 임시 디렉토리를 생성하는 메커니즘이 필요합니다. 그래서 우리는 docker-compose 위에 컴포지션을 높이기 위해 일종의 외부 스크립트가 필요합니다.

@ chris-crone 링크 주셔서 감사합니다. 제가 살펴보고 그것이 우리에게 효과가 있는지 볼게요 👍

안녕하세요 @ chris-crone 저는 Multi Stage 빌드를 사용해 보았고 라이브러리 / 구성을 한 위치에만 유지하고 주변에 복사하는 데 도움이되었지만 이제는 .dockerignore 가 어디에서든 무시되는 문제가 있습니다. 배치합니다.

새로운 DOCKER_BUILDKIT 옵션과 함께 Docker를 사용할 때 작동하지만 docker-compose를 사용할 때는 작동하지 않고 COMPOSE_DOCKER_CLI_BUILD=1 DOCKER_BUILDKIT=1 docker-compose build 시도했지만 여전히 작동하지 않습니다. 어떤 아이디어?

이 문제를 우연히 발견했을 때 compose에서 .dockerignore 를 찾을 위치를 지정하는 옵션이 있는지 궁금합니다. https://github.com/docker/compose/issues/6022 다시, 닫혔습니다. coz 1 기여자는 이것이 유용하지 않다고 생각합니다.

솔직히 말하면 꽤 답답 해요 !!

이는 MacOS에서 매우 중요합니다. 개발주기를 최대한 프로덕션에 가깝게 만드는 것이 가장 중요하기 때문입니다. 적절한 Continuous Delivery 관행을위한 것입니다. 예를 들어 컨테이너를 빌드 한 다음 현재 작업중인 소프트웨어의 새 버전을 컨테이너에 바인딩하여 빌드주기 시간을 절약합니다. 안타깝게도 바인드 마운트는 비용이 매우 많이 들고 3 ~ 5 배 느립니다.

예를 들어, tomcat의 시작 시간은 컨테이너에있는 내 앱의 경우 약 3 초입니다. ~ / .bash_history의 바인드 마운트를 추가하면 4 초입니다. 내 앱의 바인드 마운트를 추가하면 일반적으로 약 18-20 초입니다. Linux에서 바인드 마운트 성능은 로컬 파일 시스템과 비슷하지만 MacOS에서는 그렇지 않습니다. 하루에 100 번으로 확장하면 중요합니다.

여기에는 처음으로 앱에 액세스 할 때 계속되는 속도 저하가 포함되지 않습니다. 코드 파일이 캐시 될 때까지. 나에게 그것은 작은 구절을 다른 것으로 변경하기 위해 모 놀리 식 오라클 DB에 연결하는 인터넷 지연을 포함하여 3 분을 의미하며 여전히 괜찮아 보이는지 확인합니다. 젠장 covid-19, 롤.

이상적으로는 docker-compose를 다시 실행하고 실행중인 컨테이너에서 내 앱을 "업데이트"하고 tomcat에 다시로드하도록 요청할 수 있기를 바랍니다. tomcat 관리자를 사용하여 변경 사항을 업로드 할 수 있지만 관리되는 컨테이너를 사용하지 않는 백엔드 앱도 있으므로 다른 솔루션을 사용해야합니다.

docker-compose가 프로덕션 배포뿐만 아니라 개발에도 적합하다면 좋을 것입니다.

이 사용 사례는 토론과 관련이 있습니다 : https://github.com/docker/compose/issues/3593#issuecomment -637634435

@ chris-crone

안녕하세요.

내 사용 사례 : 구성 외에도 5 개의 Rails 애플리케이션 컨테이너 (Debian)에 설치해야하는 라이브러리 (RPM)가 있습니다. Ruby / Rails 버전이 다르므로 동일한 기본 이미지를 사용할 수 없으므로 파일을 단일 위치에 저장하고 빌드 할 때 컨테이너에 복사 할 수 있어야합니다. 1.5GB의 데이터를 다운로드하고 싶지 않습니다. 구축하는 동안.

이를 위해 다단계 빌드 를 살펴 보셨습니까? 더 강력한 솔루션이 될 것이라고 생각합니다.

다단계 빌드를 사용하면 여러 이미지에 동일한 Dockerfile을 사용할 수 있습니다. 이를 통해 요소를 인수 화하고 각 이미지에 필요한 비트 만 포함 할 수 있습니다.

하나의 좋은 예는 Docker Compose를 빌드하는 데 사용하는 것 입니다. 이것은 Debian 또는 Alpine을 사용하여 빌드되지만 공통 코드를 고려할 수 있습니다.

다단계 빌드는 멋지지만 고유 한 문제로 어려움을 겪습니다. 하나는 동일한 컨텍스트 내에서 모든 단계를 실행해야하므로 항상 가능하지는 않습니다. 또한, 지금까지의 내가 아는 한, 당신은 쉽게 사용할 수 COPY --from 다른 Dockerfile에 정의와 내장 이미지 docker-compose build (난 당신이 구축하고 수동으로 태그를 지정하여이를 수행 할 수 가정).

COPY 자체는 빌드 컨텍스트에서만 가져올 수 있다는 점에서 매우 제한적입니다. docker cp 는 이미지와 컨테이너간에 복사 할 수 없다는 점을 제외하고는 어디에서나 복사 할 수 있습니다 ( COPY --from 와 비슷 함).

내 사용 사례는 약간 다릅니다 (읽기 전용 구성 파일 복사와는 별개로 로컬 볼륨 마운트는 다른 컴퓨터에 배포 할 때 가장 좋은 생각이 아닙니다). 지금하고있는 작업은 반 패턴이라고 말할 수 있습니다. . 빌드시 컴파일되고 축소 된 JS + HTML + 자산 번들 (작은 각도 앱을 생각해보십시오)을 생성하는 잠재적으로 여러 다른 이미지와 이들 모두를 제공하는 단일 nginx 서버 (플러그인으로 인해 사용자 지정 이미지에서 빌드 됨)가 있습니다.

현재 내가해야 할 일은 시작시 "빌드"이미지에서 "배포"패키지를 복사하는 것입니다. 이상적으로는 컨테이너 생성 또는 빌드에서 수행해야하지만 후자는 "modded nginx"위에 다른 이미지를 생성해야합니다.

다음 프로젝트 레이아웃을 이미지화합니다 (하위 프로젝트는 별도의 저장소에 있으며 서로에 대해 알지 못할 수 있음).

app1/
  src/
    ...
  Dockerfile
app2/
  src/
    ...
  Dockerfile
app3/
  src/
    ...
  Dockerfile
nginx/
  ...
  Dockerfile
docker-compose.yml

각 app{1,2,3}/Dockerfile 파일에는 /usr/src/app/dist 앱을 빌드하는 대상 / 단계 build 가 포함되어 있습니다. nginx/Dockerfile 에는 하나의 단계 만 있으며 nginx/nginx 와 유사한 이미지를 빌드하지만 모든 필수 플러그인 (구성 없음)이 있습니다.

docker-compose.yml :

version: '3.8'
services:
  app1-build:
    build:
      context: app1/
      target: build
    image: app1-build
    entrypoint: ["/bin/sh", "-c"]
    command:
      - |
        rm -vfr /dist-volume/app1 \
        && cp -vr /usr/src/app/dist /dist-volume/app1 \
        && echo "Publishing successful"
    volumes:
      - 'dist:/dist-volume'

  app2-build:
    build:
      context: app2/
      target: build
    image: app2-build
    entrypoint: ["/bin/sh", "-c"]
    command:
      - |
        rm -vfr /dist-volume/app3 \
        && cp -vr /usr/src/app/dist /dist-volume/app3 \
        && echo "Publishing successful"
    volumes:
      - 'dist:/dist-volume'

  #... same thing for app3-build

  nginx:
    build:
      context: nginx/
    image: my-nginx
    volumes:
      - 'dist:/var/www'
      - # ... (config files etc)

volumes:
  dist:

이제 이것은 분명히 이상적이지 않으며 각 앱 빌드 이미지가 불필요하게 실행되고 빠르게 완료되고 배포 된 이미지가 공유 볼륨에 상주합니다 (저는 이것이 성능에 부정적인 영향을 미친다고 가정하지만 아직 확인할 수 없습니다). copy 또는 copy_from 가 docker-compose 옵션 인 경우 다음과 같이 작성할 수 있습니다.

version: '3.8'
services:
  # assuming the images have default entrypoint and cmd combination that immediately returns with success.
  app1-build:
    build:
      context: app1/
      target: build
    image: app1-build

  #... same thing for app2-build app3-build

  nginx:
    build:
      context: nginx/
    image: my-nginx
    copy:
      - from: app1-build  # as image or service, both have their pros and cons, service would mean an image associated with this service
         source: /usr/src/app/dist
         destination: /var/www/app1
      - from: app2-build
         source: /usr/src/app/dist
         destination: /var/www/app2
      - from: app3-build
         source: /usr/src/app/dist
         destination: /var/www/app3
    volumes:
      - # ... (config files etc)

내 사용 사례가 빌드 단계 또는 시작 단계에 없습니다. 컨테이너 또는 서비스의 모든 컨테이너 내부에서 생성 된 파일을 가져 오는데, 이러한 컨테이너는 원격 Docker 엔진에서 실행됩니다. 지금까지 docker-compose ps -qa <service> | xargs -i docker cp {}:<there> <here> 와 같은 일을하고 있습니다. 내 스크립트에서 독특하게 도커 작성을 고수 할 수 있기를 바랍니다.

@ chris-crone

바인드 마운트 대신 사본이나 이러한 파일에 대한 볼륨을 원하는 이유를 아는 것도 흥미로울 것입니다.

자기 편모를 즐기십니까? 그렇다면 MacOS에서 바인드 마운트를 사용하여 애플리케이션을 실행하는 것이 좋습니다. 🤣 자세한 내용은 이전 게시물을 참조하십시오.

이것은 Compose에서 이와 같은 것을 구현해서는 안된다는 의미가 아닙니다. 변경으로 인해 사용자가 프로덕션에서 로컬로 작동하는 것을 재사용 할 수 없게되는 경우, 우리는 일시 중지하고 동일한 목표를 달성하는 더 강력한 방법이 있는지 확인하는 것을 좋아합니다.

@ chris-crone 너무 자주 사람들이 구성 및 데이터를 일시적으로 관리하지 않는 것과 같이 도커에 대한 안티 패턴을 구현하기 때문에 이것이 대단한 감정이라고 생각합니다.

어떻게 든 우리가 docker와 Apple이 결합 마운트의 성능 문제를 해결하기 위해 함께 일할 수 있는지 궁금합니다. 적어도 나에게는 docker compose cp 옵션이 더 이상 필요하지 않을 것입니다. 왜냐하면 개발을 위해 bind 마운트를 사용할 것이기 때문입니다. 바인드 마운트를 사용하는 것은 너무 고통 스럽지만 지금 당장은. Linux를 사용하는 가상 머신으로 전환 할 수 있습니다. 내 Mac은 바이트 만 발생합니다.

헉헉

우리는 프로덕션에서 docker를 실행하지 않고 개발 목적으로 만 사용합니다. 볼륨 사용의 문제 (올바르게 이해하는 경우)는 시뮬레이터 (타사)에 시작시 파일을 삭제하는이 시작 스크립트가 있다는 것입니다. 삭제에 실패하면 스크립트 실행이 중지되므로 rw로 마운트해야합니다. 그리고 파일 삭제가 허용되면 원본이 삭제되지 않도록 이러한 파일을 제공하기위한 임시 디렉토리를 생성하는 메커니즘이 필요합니다. 그래서 우리는 docker-compose 위에 컴포지션을 높이기 위해 일종의 외부 스크립트가 필요합니다.

흠 .. 시뮬레이터 공급 업체에 문의 할 수 있다면이 문제를 해결하는 가장 좋은 방법이라고 생각합니다. 필요에 따라 파일을 이동하는 시뮬레이터의 진입 점 스크립트를 사용하여이 문제를 해결할 수 있습니다. 이것은 지저분해질 것입니다.

안녕하세요.

라이브러리 / 구성을 한 위치에만 유지하고 주변에 복사하는 데 도움이되었지만 지금은 어디에 두든 .dockerignore 이 무시되는 문제가 있습니다.
새로운 DOCKER_BUILDKIT 옵션과 함께 Docker를 사용할 때 작동하지만 docker-compose를 사용할 때는 작동하지 않고 COMPOSE_DOCKER_CLI_BUILD=1 DOCKER_BUILDKIT=1 docker-compose build 시도했지만 여전히 작동하지 않습니다. 어떤 아이디어?

기쁜 다단계 빌드가 도움이되었습니다! 어떤 버전의 Docker 및 docker-compose를 사용하고 있습니까? 나는 최신 버전으로 시도하고 문제가 여전히 있는지 확인합니다. .dockerignore 파일을 존중해야합니다.

@Marandil , docker build 가 문제인 프로젝트 구조 (예 : 디렉토리 구조)를 처리하지 않는 것 같습니다. docker buildx bake (https://github.com/docker/buildx)와 같은 것을 사용하여이 사용 사례를 해결할 수 있습니다. buildx가 작업 중이므로 아직 매우 안정적이지는 않지만 타격을 입은 일부 문제를 해결하는 것을 목표로합니다.

@itscaro , 입력 해 주셔서 감사합니다! 컨테이너에서 무언가를 생성하기 위해 내부적으로하는 일은 docker build 를 사용하여 FROM scratch 이미지에서 결과를 출력하는 것입니다. 이것은 단일 컨테이너의 출력이 필요한 경우에만 작동합니다.

@TrentonAdams 우리는 Docker Desktop의 파일 시스템 성능을 개선하기 위해 노력해 왔지만 까다 롭습니다. 근본적인 문제는 VM 경계를 통과하는 것입니다. 파일 공유 비트가 최근에 다시 작성되었으며 (환경 설정에서 "파일 공유에 gRPC FUSE 사용"토글을 사용하여 새로운 환경을 활성화 할 수 있음) 이것은 사람들이보고있는 높은 CPU 사용량 문제 중 일부를 해결할 것입니다. 여기 와 여기 에 성능 조정에 대한 문서가

@ chris-crone

@Marandil , docker build 이 문제인 프로젝트 구조 (예 : 디렉토리 구조)를 처리하지 않는 것 같습니다. docker buildx bake (https://github.com/docker/buildx)와 같은 것을 사용하여이 사용 사례를 해결할 수 있습니다. buildx가 작업 중이므로 아직 매우 안정적이지는 않지만 타격을 입은 일부 문제를 해결하는 것을 목표로합니다.

감사합니다. docker buildx bake 살펴 보겠습니다. 유망 해 보이지만 이에 대한 좋은 참조 나 문서를 찾을 수 없었고 docs.docker.com의 페이지는 다소 노출되어 있지 않습니다 (https://docs.docker.com/engine/reference/commandline/buildx_bake 참조). /). 지금까지 몇 가지 예제를 참조하는 https://twitter.com/tonistiigi/status/1290379204194758657을 찾았습니다 (https://github.com/tonistiigi/fsutil/blob/master/docker-bake.hcl, https : // github .com / tonistiigi / binfmt / blob / master / docker-bake.hcl), 좋은 출발점이 될 수 있지만 좋은 참조는 아닙니다.

@TrentonAdams 우리는 Docker Desktop의 파일 시스템 성능을 개선하기 위해 노력해 왔지만 까다 롭습니다. 근본적인 문제는 VM 경계를 통과하는 것입니다. 파일 공유 비트가 최근에 다시 작성되었으며 (환경 설정에서 "파일 공유에 gRPC FUSE 사용"토글을 사용하여 새로운 환경을 활성화 할 수 있음) 이것은 사람들이보고있는 높은 CPU 사용량 문제 중 일부를 해결할 것입니다. 여기와 여기에 성능 조정에 대한 문서가 있습니다.

@ chris-crone 지옥 예, 정말 감사합니다! 새로운 옵션으로 3 ~ 4 초의 개선이 있으며 "캐시 됨"을 사용하면 컨테이너 외부에서 실행하는 것과 동일한 성능을 얻을 수 있으므로 이것은 저에게 엄청납니다. 나는 우리 앱의 시작 시간이 2800ms만큼 낮아서 더 이상 11-18 초가 아닙니다. 예! 캐시 된 것 외에는 다른 것이 필요하지 않습니다. 어쨌든 매번 컨테이너를 다시 생성하기 때문입니다.

@ chris-crone MacOS에서 성능 조정 및 피드백을 지원하기 위해 성능 관련 자료를 게시해야하는 장소가 있습니까? 바인드 마운트로 새로 시작된 컨테이너가 cached 사용하지 않을 때 왜 느린 지 궁금합니다. 동기화 상태 인 경우 시작시 모든 파일을 확인하는 이상한 일이있을 것입니다. 심지어 새 파일 일 때도 마찬가지입니까?

사용 사례 : 컨테이너를 실행하고 파일을 수정합니다 (특히 Keycloak은 환경 변수 등을 기반으로 구성 파일을 수정합니다). 수정 결과를 확인하고 컨테이너 스크립트를 수정하면서 시간 경과에 따른 진행 상황을 추적 할 수 있도록 로컬 디스크에 해당 파일의 사본이 필요합니다. 현재는 docker cp 사용할 수 있도록 매번 새 컨테이너 ID를 찾아야합니다.

사용 사례 :
도커에서 개발.
내 잠금 파일을 호스트 컴퓨터로 다시 전파해야합니다. 그렇지 않으면 컨테이너가 프로젝트 폴더를 마운트 할 때 덮어 쓰게됩니다.

사용 사례 : 비밀 키가 포함 된 파일을 복사해야합니다. 컨테이너 내부에서 실행되는 앱은 해당 파일을 메모리로 읽고 디스크에서 삭제합니다.

사용 사례 : 도커 컨테이너에서 C ++ 단위 테스트를 실행하고 있습니다. 실행할 때마다 기존 이미지에 코드를 복사하기 만하면됩니다.

1) 별도의 dockerfile COPY 로이 작업을 수행하면 코드가 새롭고 불필요한 이미지에 기록되며 다음 실행에서 최신 코드로 새 이미지를 생성하도록 해당 이미지를 삭제해야합니다.

2) docker-compose volumes yaml config 로이 작업을 수행하면 Docker가 소스 코드 를 root:root (내 IDE가 다시 쪼개 질 때까지 편집하지 못하도록 완전히 죽입니다!)

@ shin- 컨테이너에서 단위 테스트를 실행하여 안티 패턴을 따르고 있습니까? 이 문제를 해결할 수있는 비-반 패턴 방식은 무엇입니까?

.... 나는 가장 고통스럽지 않기 때문에 1 번을 고수하고있다. 그러나 나는 복사 구성을 지원하는 docker-compose가 정말 멋진 향상이라고 생각합니다! 적어도이 워크 플로우에는!

@soulseekah 작성시 비밀을 사용하는 것이 더 나은 사용 사례가 아닌가요?

저에게 적합한 해결 방법을 찾았습니다.

1. 다음을 사용하여 Dockerfile 만들기
   COPY a_filename .
2. Dockerfile을 사용하여 이미지 빌드
   docker build -t myproject:1.0 .
3. 방금 만든 이미지를 사용하도록 docker-compose를 편집하십시오.

version: "3.7"
services:
  app:
    image: myproject:1.0
    ports:
      - 3000:3000
    networks:
       - mynetwork
       - internal
    environment:
      MYSQL_HOST: mysql
      MYSQL_USER: root
      MYSQL_PASSWORD: not_so_secret_password # don't do this 
      # https://diogomonica.com/2017/03/27/why-you-shouldnt-use-env-variables-for-secret-data/
      MYSQL_DB: appdb
    deploy:
      resources:
        limits:
          cpus: '0.75'
          memory: 100M

완벽한 해결 방법은 아니지만 내 사용 사례에서 작동합니다.

@soulseekah 작성시 비밀을 사용하는 것이 더 나은 사용 사례가 아닌가요?

불행히도 내가 마지막으로 시도했을 때 떼가 필요합니다.

@soulseekah 작성시 비밀을 사용하는 것이 더 나은 사용 사례가 아닌가요?

불행히도 내가 마지막으로 시도했을 때 떼가 필요합니다.

@soulseekah 어쩌면 내가 사용하는 해결 방법을 사용할 수 있습니까?

@ChristophorusReyhan 그 해결 방법의 문제는 @zoombinis 주석에 표시됩니다.

별도의 dockerfile COPY로이 작업을 수행하면 코드가 새롭고 불필요한 이미지에 기록되며 다음 실행에서 최신 코드로 새 이미지를 생성하도록 해당 이미지를 삭제해야합니다.

작동하는 솔루션이지만 원치 않는 유지 관리로 이어질 수 있습니다. 예를 들어 원치 않는 이미지를 정리하려면 _ 관심있는 이미지를 보존하면서 _ :

docker-compose up && docker-compose down --rmi local

하지만 관심있는 모든 이미지 에 맞춤 태그가 있고 테스트 / 더미 이미지에는