Compose: yaml 구성에`copy` 추가

여기서 copy 의 의미는 무엇입니까? 우리는 호스트에서 파일을 복사 docker-compose 사용하여 새로 실행 용기에에서 실행됩니다 docker cp ?

AFAIK에는 _no_ 현재이 작업을 수행하는 방법이 있습니다.

보다:

```#! bash
$ docker cp -h

사용법 : docker cp [OPTIONS] CONTAINER : PATH HOSTDIR |-

컨테이너의 PATH에서 호스트의 HOSTDIR로 파일 / 폴더 복사
명령을 실행합니다. '-'를 사용하여 데이터를 STDOUT에 tar 파일로 씁니다.

--help = false 인쇄 사용법
```

여기서 복사의 의미는 무엇입니까? docker cp를 사용하여 docker-compose가 실행되는 호스트에서 새로 실행되는 컨테이너로 파일을 복사합니까?

예

AFAIK 현재이 작업을 수행하는 방법은 없습니다.

docker cp 명령이이를 수행 할 수 없음을 확인했습니다. 그러나 호스트 측의 컨테이너 데이터에 액세스하여 여전히 가능합니다 (내가 못 생겼습니다)

http://stackoverflow.com/a/24805696/210090

예, 저는 우리가 이것을 전혀 옹호하지 않을 것입니다. 이것은 Docker에 대한 많은 것들과 가정을 깨뜨릴 것입니다. 이것은 또한 사용되는 기본 스토리지 드라이버에 크게 의존합니다. Docker는 불가지론 적입니다. 나는 우리가 귀하의 문제에 대한 다른 해결책을 _해야한다고 생각합니다. :)

이제 docker-1.8이 docker cp 를 통해 컨테이너에 복사를 지원하고 swarm-0.4.0-rc2가 docker cp 대한 지원을 추가 했으므로 작성 수준에서이 문제를 다시 검토하는 것이 좋습니다. 다음은 사용 사례입니다 (현재 _almost_ 프로덕션에서 실제로 수행하는 작업을 반영 함).

CI 빌드 이미지 태그로 많은 컨테이너를 언급하는 docker-compose.yml 파일 (즉, 프로덕션에서 build: 을 사용하지 않습니다. 지금은 가능할 수도 있지만 이전 릴리스에서는 swarm과 잘 어울리지 않았습니다) 예를 들어 배치 환경과 정확히 일치하는 정적 하둡 구성 파일이 모두 필요합니다. 현재 docker-compose.yml이있는 디렉토리를 떼의 _each_ target docker-machine의 정확한 경로에 수동으로 동기화해야합니다. 그런 다음 volume: 줄 스택을 추가합니다.

docker cp 를 지원하면 시스템 배포 방법에서 사용자 지정 구성 파일 동기화를 제거하고 구성 변경 사항이 삽입되는시기를 더 잘 제어 할 수 있습니다 ( volume: 줄에 언급 된 파일을 변경하는 모든 사람이 영향을 미치기 때문에 이전에 배포 된 모든 컨테이너 (그리고 내부 구현이 언급 한 구성을 다시 읽을 때마다, 아마도 다음 컨테이너가 다시 시작될 때만, 아마도 컨테이너 내부의 다양한 도구가 시작될 때; 예상치 못한 일 수 있음) 및 미래 (예상 됨).

OTOH, (위에서 간략히 언급했듯이) 아마도 build: 사용해야합니다. 여기서 단점은 배포 컨테이너 유형별로 추가 Dockerfile을 작성해야한다는 것입니다. 하나는 CI 빌드 이미지 용이고 다른 하나는 정적 구성 파일 인젝터 용입니다. copy: 의 최근 변경 사항으로 뒷받침되는 작성시 docker cp 는 이러한 모든 중복을 방지 할 수있게 해줍니다.

볼륨을 사용하는 것이 더 나은 방법 인 것 같습니다. 호스트 볼륨 일 필요는 없으며 데이터 볼륨 컨테이너와 함께 작동해야합니다.

Bedies docker-machine 은 (는) docker-machine scp 가지고 있습니다. 어쨌든 기계의 준비로 할 수 있습니다. 그런 다음 docker 또는 docker-compose 같은 일반적인 방법으로 호스트 볼륨을 수행 할 수 있습니다.

"여전히 볼륨을 사용하는 것이 더 나은 방법 인 것 같습니다. 호스트 볼륨 일 필요는 없으며 데이터 볼륨 컨테이너와 함께 작동해야합니다."
나는 표적이 무리 일 때 그것이 어떻게 최선인지 보지 못합니다. AFAICS는 가능한 모든 스웜 노드에 데이터 볼륨 컨테이너가 있어야한다고 표현할 방법이 없습니다.

어쨌든 다른 컨테이너 ala 스케줄링 전략과 마찬가지로 swarm 자체를 통해 매우 노드에 데이터 볼륨 컨테이너를 배포 할 수 없습니까?

"Bedies docker-machine은 어쨌든 당신이 기계의 준비로 할 수있는 docker-machine scp를 가지고 있습니다. 그러면 당신은 docker 또는 docker-compose와 같은 일반적인 방법으로 호스트 볼륨을 할 수 있습니다."
나는 현재 이것을하고있다. 고통 스럽습니다. 배포를 관리하는 사람들은 구성 파일을 이동하는 것을 잊습니다. docker-compose yml에서 지원되는 경우 컨테이너가 수동 단계없이 다시 생성 될 때마다 발생합니다.

"어쨌든 다른 컨테이너 알라 스케줄링 전략에서 할 수있는 것처럼 스웜 자체를 통해 매우 노드에 데이터 볼륨 컨테이너를 배포 할 수 없습니까?"
아마도 우리는 할 수 있지만 스케일링에 비추어 볼 수 없다는 것을 인정합니다.

"어쨌든 다른 컨테이너 알라 스케줄링 전략에서 할 수있는 것처럼 스웜 자체를 통해 매우 노드에 데이터 볼륨 컨테이너를 배포 할 수 없습니까?"
흠, 내 떼가 10 노드 크기라는 것을 안다면; 주어진 도커 엔진 노드에서 중복이 허용되지 않는 정책으로 데이터 볼륨 컨테이너를 크기 10으로 확장 할 수 있습니까? 문제는 (내가 놓친 것이 아니라면) 예를 들어 해당 데이터 볼륨을 참조해야하는 컨테이너가 인덱스가 일치하는 컨테이너에서 --volume- 할 방법이 없다는 것입니다. 여러분, 저는이 문제를 2 개월 동안보고 있습니다. 내가 할 수있는 최선은 docker-machine scp 를 사용하는 스크립트를 만드는 것입니다. 그러나 구성 파일을 편집 한 후 docker-compose up 이전에는 수동 단계입니다. 또한 docker-compose.yml의 루트로 떼의 대상 컴퓨터에 정확한 경로를 작성할 수 있어야합니다 (즉, 주요 해킹 냄새가납니다).

아마도 공장 에서 나의 노력이 도커 머신을 회전시키고 사용할 준비가 된 "올바른"데이터로 클러스터를 구성하는이 프로세스를 자동화하는 데 도움이 될 수 있습니까? (_ 아직 초기 개발 단계이며 단일 setp_0에서 docker-machine 및 docker-compose 을 (를) 결합하는 데 사용하고 있습니다.

copy 는 서비스 구성의 일부가 아닌 작업이므로 작성 파일에 속하지 않습니다.

Docker 1.9는 새 볼륨 API를 추가하고 있으며 볼륨 드라이버는 이미 있습니다. 볼륨은이를 지원하는 올바른 방법입니다. 주변에 파일을 복사하려고하지 않습니다.

제안 해 주셔서 감사합니다! 하지만 지금은 이것이 작곡 디자인과 맞지 않는다고 생각합니다.

복사는 서비스 구성의 일부가 아닌 작업이므로 작성 파일에 속하지 않습니다.

구성 파일 만 복사하려면 어떻게해야합니까? (도커 떼로, 그래서 volume_from이 작동하지 않습니다)

나는 정확히 동일한 상황을 가지고 있으며 사용자 정의 mysql, nginx, haproxy 등 구성 파일을 복사하고 싶습니다. 클러스터가 프로덕션에 있으며 하나의 복사 명령을 사용하여 로컬에서 원격으로 구성을 복사하는 대신

매번 이미지를 사용하고, 빌드하고, 가져와야하지만, 아무것도 필요하지 않으며 복사 명령만으로도 많은 배포 및 개발 시간을 절약 할 수 있습니다.

이것은 더 많은 사람들이 쉽게 스크립팅 할 수없는 문제가 없다는 사실에 매우 놀랍습니다. 도커에 대해 잘못 생각하고 있습니까? 이제 내 솔루션은 ansible을 사용하여 구성 파일을 호스트로 복사 한 다음 호스트에서 필요한 컨테이너로 볼륨 마운트하는 것입니다.

같은 문제에 부딪 혔습니다. N 개의 다른 서비스에 Dockerfile을 재사용하고 있으며 자체 COPY 명령으로 N 개의 다른 Dockerfile을 생성하거나 그에 대한 볼륨을 생성하고 싶지 않습니다.

Btw 나는 현재 수십 줄의 sed 명령을 실행하여 해결하고 있습니다-http: //unix.stackexchange.com/questions/112023/how-can-i-replace-a-string-in-a-files

최적의 솔루션은 아니지만 docker-compose가 파일 복사를 지원하지 않는다는 점을 고려하여 작동합니다.

Btw 마운트 및 복사는 물론 가능하지만 자동화 docker-compose 제안에 위배됩니다. 수동으로 모든 것을 수행하고 싶다면 docker-compose를 사용하지 않겠습니까?

Docker를 더 많이 파고 들수록이 도구의 많은 부분이 "hello world"에 좋은 것 같습니다. 단일 머신 유형 유스 케이스에서 "이와 같은 쉘 명령으로이 멋진 것을 얼마나 빨리 회전시킬 수 있는지보세요" (도커 구성 포함). 그 이상으로 넘어 가면 상황이 매우 복잡해지기 시작하고 IMO가 약간 떨어져서 기존 프로비저닝 도구가 적절하게 사용되면 하루를 절약 할 수 있습니다.

도커 이미지를 시작하려면 반드시 존재해야하는 시스템 별 볼륨, 파일 및 템플릿 구성 파일 이있을 때 Ansible을 사용하여 멱 등성 방식으로 시스템을 설정하는 것이 매우 쉽습니다. 그런 다음 마지막에 Ansible을 사용하여 docker-compse를 호출하거나 구문이 Docker가 몇 가지 추가 된 보너스 기능으로 구성하는 것과 거의 똑같은 Ansible docker 모듈을 사용할 수 있습니다.

하루가 끝나면 위의 접근 방식을 사용하면 모든 것을 스크립팅하고 멱등하며 가장 중요한 소스 제어에 체크인 할 수 있습니다.

@dnephin 위의 일부 사람들은 CP가 구성의 일부인 사용 사례를 제안했습니다. CP는 구성이 아닌 작업에만 사용된다는 가정을 다시 검토하는 것이 합리적

간단한 예는 컨테이너를 만들고 올바른 위치에 구성을 복사하고 구성이 복사 된 후 컨테이너를 시작하는 것입니다.

이를 통해 실제 구성을 포함하지 않고 컨테이너가 시작될 때만 구성을 배포하는 이미지를 만들 수 있습니다.

확실히 매우 도움이 될 것입니다. 지금 데이터베이스 백엔드로 postgres 이미지를 사용하고 있으며 /docker-entrypoint-initdb.d 폴더의 스크립트를 업데이트하기 위해 다시 빌드하고 싶지 않습니다.

여기에서 제안 된 옵션을 좋아하는 사람이 없기 때문에 기능이 구현되거나 사람들이 좋아하는 실행 가능한 솔루션이 발견 될 때까지이 문제를 다시 열어 보지 않겠습니까?

@ctindel이 언급

문제를 재개 한 경우 +1

열기도 +1합니다.

다시 열려면 +1.

다시 열려면 +1.

다시 열려면 +1.

다시 열려면 +1.

다시 열려면 +1.

다시 열려면 +1.

읽기 전용 볼륨의 문제점은 무엇입니까?

myservice:
    image: foo/bar
    volume:
        - src:dest:ro

@michaelarnauts 는 이것을 참조

👍 다시 열기

다시 열려면 +1.

다시 열려면 +1.

다시 열려면 +1

다시 열려면 +1

다시 열려면 +1

다시 열려면 +1

다시 열려면 +1

다시 열려면 +1

Compose에서 사본을 허용하는 이유는 다음과 같습니다.

수많은 컨테이너에서 실행되는 애플리케이션이 있습니다. 논쟁을 위해 모두 Apache를 실행한다고 규정합시다. 그들은 모두 "/ var / www / partX"와 같은 것을 가리키는 DocumentRoot 정의를 가지고 있습니다. Dockerfile은 Apache 구성의 내용에 대해 아무것도 모르고 Compose는 / var / www / partX에 대한 볼륨 참조를 정의합니다. 컨테이너 내용을 수정하지 않고도 코드를 디버깅하고 수정할 수 있기 때문에 개발에 적합합니다.

문제는 내가 배포하고 싶을 때입니다. Docker의 주요 매력 중 하나는 자체 우주인 컨테이너를 배포 할 수 있다는 것입니다. 컨테이너에있는 모든 것을 가져 오려면 파일을 복사해야합니다. 즉, 개발에 사용하는 것과 별도의 Dockerfile 및 Compose 정의가 있어야합니다. 대규모 프로젝트에서는 두 세트의 정의 파일을 유지해야하므로 오류 가능성이 더 커집니다.

내가 선호하는 것은 단일 Dockerfile 세트를 유지하고 Compose 파일에서 오케스트레이션을 수행하는 것입니다. Compose는 / var / www / partX를 공유 볼륨으로 설정할 것인지 또는 파일을 컨테이너에 복사 할 것인지 정의하는 곳입니다.

공유 볼륨으로 배포하는 것은 웜처럼 보입니다. 공유 볼륨에 의존하는 프로덕션에서 기존 버전을 업데이트하는 경우 유지 관리 기간을 설정하거나 공유 볼륨의 버전 관리 체계를 마련하지 않고는 해당 공유 볼륨을 업데이트 할 수 없습니다. 컨테이너를 외부 파일과 밀접하게 결합하고 있으며 이러한 유형의 복잡성을 도입하는 경우 Docker 사용의 이점 중 일부를 무효화합니다.

조건부로 파일을 복사하기 위해 Dockerfile 정의에 대한 변경 사항을 스크립트로 작성할 수있는 것처럼 보이지만 Docker 유니버스에서 모든 Docker 논리를 처리하는 것이 더 "논리적"인 것처럼 보이며 Compose는이를 수행하는 논리적 장소처럼 보입니다.

다시 열려면 +1.

+1. Dockerfile 대신 docker-compose.yml 파일에 구성 파일을 복사하는 것이 매우 유용합니다.

+1. 서비스에 대한 구성 파일을 제공하려고 시도했습니다. 읽기 전용 볼륨은 옵션처럼 보이지만 오히려 복사합니다.

단순히 볼륨을 마운트하면 트릭을 수행 할 수 있습니다.

version: '2'
services:
  foobar:
    image: 'postgres:9.6-alpine'
    volumes:
      - './docker/schemas/foobar:/docker-entrypoint-initdb.d'

@raszi-예 , 마운트 된 구성은 우리가 지금 갈 방향입니다. Docker에 대해 정말 마음에 들었던 점 중 하나는 외부 종속성 (예 : 연결된 구성)에 대한 걱정없이 통합 테스트를 실행할 수있는 자체 포함 된 컨테이너 개념이었습니다. 블루 / 그린 또는 A / B 배포를 수행하고 있고 다른 버전의 컨테이너에서 사용하는 구성에 차이가 있으면 상황이 약간 취약해질 수 있습니다. 각 환경의 공유 볼륨에서 구성 파일의 버전을 관리하는 등의 작업을 수행하여이 문제를 해결할 수 있지만 그럴 수있는 것보다 더 복잡하거나 깨지기 쉬운 것 같습니다.

"Docker 컨테이너는 코드, 런타임, 시스템 도구, 시스템 라이브러리 (서버에 설치할 수있는 모든 것) 를 포함하는 완전한 파일 시스템에 소프트웨어를 래핑합니다. 이는 소프트웨어가 항상 동일하게 실행되도록 보장합니다. 환경의. " 나에게 이상적으로는 구성이 포함됩니다. Compose는 일종의 "빌드 / 컴파일 및 실행"을 수행합니다. 여기있는 우리 중 일부는 Compose가 "빌드 / 컴파일, 링크 및 실행"을 수행 할 수 있기를 바랍니다. 그것이 오늘날 작동하는 방식이 아니며 그 길을가는 것에 대한 열정이 부족하다는 것을 이해할 수 있지만, 이건 포럼입니다. 물어 보는 것도 아프지 않습니다.)

동의합니다.이 기능이 있으면 좋을 것 같습니다. 다른 사람들을 돕기 위해 내 솔루션을 게시했습니다.

다시 열려면 +1.

+1

다시 열거 나 볼륨이없는 다른 솔루션의 경우 +1.

현재 컨테이너의 기본 앱을 실행하기 전에 구성 파일로 구문 분석하기 위해 docker-compose.yml 및 j2의 환경 변수를 docker-entrypoint.sh에서 사용하고 있습니다. 나를 위해 작동하지만 사용자 지정 이미지이며 이미 사용 가능한 전체 이미지로 즉시 사용할 수 없습니다.

+1

+1

+1

+1

+1

+1

+1

+1

+1

다시 열려면 +1

환경 변수를 기반으로 한 구성 대신 각 컨테이너에 대해 다른 yaml 파일을 가질 가능성을 추가하려면

+1 매우 필요한 기능

+1, 기능이있어서 기쁩니다!

+1

+1

+1

+1

+1 재개. 북마크 됨

+1 이것은 매우 필요한 기능입니다.

공유 볼륨을 계층으로 표시 할 수있는 방법이있어서 볼륨은 RO로 남아 있지만 맨 위에있는 계층에 쓰기가 적용되면 copy 지시문 없이도 행복하게 살 것입니다. 예를 들어 추출 된 빌드 아티팩트를 공유하고 싶지만 서비스는 해당 디렉토리 (로그 또는 PID 파일 등)에 기록합니다.

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1 매우 유용한 기능이므로 다시 열기

https://github.com/jwilder/dockerize 의 템플릿 기능이 도움이 될 수 있습니다.

+1

+1

+1

+1

+1

문제를 다시 열려면 +1

+1

Docker 비밀을 사용합니다.이 예제에서는 비밀이 nginx 이미지와 함께 사용되어 서버 인증서 및 구성 파일을 복사합니다.
https://docs.docker.com/engine/swarm/secrets/#intermediate -example-use-secrets-with-a-nginx-service

그건 좋은 지적이야. 솔직히 우리는 이미 비밀을 가지고 있기 때문에 비밀은 어떤면에서 당신이 복사 할 특정 유형의 파일이기 때문에 우리는 복사본을 가져야합니다. 즉, 구성 파일에 필요하지 않은보다 신중하게 프로비저닝 된 것입니다.

포함하려는 모든 구성 파일에 대해 호스트 마운트 볼륨을 능가합니다.

앞서 말했듯이 :

...
볼륨 :
-./nginx/default.conf:/etc/nginx/conf.d/default. conf : ro
-./nginx/nginx.conf:/etc/nginx/nginx. conf : ro
...

복사가 더 좋은 이유는 a) 호스트가 실제로 별도의 시스템 인 스웜 환경에서 모든 시스템의 동일한 위치에 정확히 동일한 파일을 가질 필요는 없습니다. b) 복사는 compose가있는 폴더로 제한 할 수도 있지만 호스트 마운트에는 절대 경로가 필요합니다. c) Docker의 요점은 포함 된 응용 프로그램이 호스트에 침입하는 위치의 수를 최소화 하는 것입니다. 읽기 전용으로 구성된 경우에도 호스트 마운트는 호스트에 파일을 보유 하고 보존 할 책임을 생성합니다. 이 간단한 문제를 해결하기 위해 호스트 마운트를 사용할 필요는 없습니다.

복사는 docker build 프로세스와 유사하게 모델링 될 수 있다고 생각합니다. 여기서 Dockerfile 는 일반적으로 빌드 컨텍스트로 보내는 데 필요한 모든 파일과 함께 git 저장소로 제공됩니다. Dockerfile 은 (는) 올바르게 심볼릭 링크 된 경우에도 디렉토리 구조 외부에 존재하는 것을 보낼 수 없습니다. src 는 docker-compose.yml 의 디렉토리 (및 그 아래에있는 것)로 제한되는 compose와 비슷한 것을 가질 수 있습니다. 기본적으로 워크 플로는 docker-compose 가 컨테이너를 만든 다음 모든 src:dst 쌍에 대해 현재 디렉터리에서 src 를 찾아 시작되지 않은 컨테이너에 복사합니다. 그런 다음 컨테이너를 시작하십시오.

현재 호스트 마운트를 피하려면 Dockerfiles 을 추가하고 conf 파일을 수정 된 이미지로 빌드하여 수행 할 수 있지만 새 이미지에 태그를 다시 지정하거나 사용자를 강제하는 작업이 포함되므로 과도하게 느껴집니다. 더 바람직한 (IMO) image 속성 대신 docker-compose build 속성을 사용합니다. 서비스 정의에서 이미 build 속성을 사용하고 있고 이런 방식으로 작업을 수행하려는 경우 compose에만 속해야하는 고도로 독단적 인 구성 파일을 사용하여 독립적 인 이미지 빌더를 오염시켜야합니다. 및 배포 프로세스.

도커 작성 복사 기능의 경우 +1

+1

+1

+1

사본은 +1.

도커 작성 복사 기능의 경우 +1. 위에서 찬성하는 주장이 설득력이 있다고 생각합니다.

사본에 +1

사본은 +1.

내 POV에 있지만. 편리 할 수 ​​있지만 제어 할 수 없거나 많은 사용자에게 남용 될 수 있으며 볼륨을 쓸모 없게 만들 수도 있습니다. 특히 swarm을 위해 컨테이너에 파일을 넣을 필요가 있다면 구성 또는 비밀을 사용할 수 있습니다. 그러나 정적 폴더를 nginx 컨테이너에 넣는 것과 같은 경우에는 Dockerfile에서 다단계 빌드를 사용하여 목표를 달성하기 전에 많은 프로세스가 필요한 컨테이너에 정적 폴더를 넣어야합니다. 그래서 복사 옵션을 추가하면

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

다시 열려면 +1

+1

다시 열려면 +1

컨테이너 (또는 자체)가 특정 상태 작업에 도달 한 후 볼륨에서 작동하는 기능이 아닐까요?
읽기 전용과 같은 플래그 일 수 있지만 대신 복사 전용입니다! 그런 다음 컨테이너 내부에서 동기화 상태에 도달 한 후 링크를 ​​제거하는 기능이 추가 된 일반 볼륨 작업 파이프 라인 / 구문을 갖게됩니다.

다시 열려면 +1. 볼륨 마운트는 항상 옵션이 아닙니다. 이것이 제가 오늘 여기에 게시하는 이유입니다. 볼륨 탑재가 금지 된 고유 한 시나리오로 인해 파일을 복사하기 위해 많은 수의 컨테이너를 직접 수정해야합니다.

+!

+1

도커 작성 복사 기능의 경우 +1

+1

+1

나는 이것이 무의미하다고 생각하기 시작했습니다. Docker는 Docker를 구축 한 특정 사용 사례 주변에만 기능을 추가합니다. 이것은 사용 사례 외부의 기능 중 하나이므로 추가하지 않을 것입니다.

+1

@stuaxo 많은 사람들이 풋건을 요구하고

이 경우, 실행하기 위해 서비스에 필요한 파일은 빌드에 구워 지거나 (Dockerfile에 선언 됨) 볼륨을 통해 사용 가능하게 만들거나 ( docker stack / Swarm 모드의 경우) config로 존재해야합니다. 또는 비밀 개체. 런타임에 잠재적으로 여러 대상으로 파일을 복사하는 것은 느리고 오류가 발생하기 쉬우 며 실패하지 않습니다.

건배, 그게 심술 궂은 경우 사과드립니다.
"서비스 실행"이라고 말하면 웹 서비스와 같이 오래 실행되는 것을 의미한다고 생각합니다. Docker는이를 잘 다루었습니다.

Dockers 계층화 및 캐싱은 다른 작업에 편리합니다.

이전 WordPress 블로그를 docker에 넣었지만 때로는 몇 분 동안 만 실행하여 데이터를 내보내거나 게시물이 어떻게 보이는지 확인할 수 있습니다.

이것은 Docker compose를 사용하여 MySQL과 Apache를 분리하는 데 약간의 작업이 필요했지만 모두가 함께 스무딩되는 곳은 상관 없습니다.

Dockers 캐싱은 Cairo와 같은 데스크톱 라이브러리를 만드는 실험을 할 때 재미 있습니다. 내가하려고했던 대부분의 작업은 세부 사항을 잊었지만 서비스 실행과 관련된 것보다 건물의 무언가 측면에 더 가깝습니다.

+1 docker-compose 사본을 추가해야합니다. 구성 파일의 흐름과 컨테이너 업데이트가 훨씬 쉬워집니다.

docker cp 및 docker config 사용

2018 년 3 월 2 일 금요일 21:19 James Hahn [email protected] 은 다음과 같이 썼습니다.

+1 docker-compose 사본을 추가해야합니다. 훨씬 더 쉬운 흐름을 허용합니다.
구성 파일 및 컨테이너 업데이트.

—
댓글을 달았 기 때문에 수신 한 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/docker/compose/issues/1664#issuecomment-370055493 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/ABOv-q5VO9n9HDvBP6YJ1BCePz5tGu-pks5tabdrgaJpZM4FTTPg
.

>

James Mills / prologic

E : [email protected]
W : prologic.shortcircuit.net.au

docker-compose 사본의 경우 +1. 아이디어는 여기에 설명 된대로 파일에 대해 복사 전용 을 갖는

+1

+1

이 경우, 서비스 실행에 필요한 파일은 빌드에 구워지고 (Dockerfile에 선언 됨), 볼륨을 통해 사용 가능하게 만들거나, (도커 스택 / Swarm 모드의 경우) 구성 또는 비밀 객체로 존재해야합니다. 런타임에 잠재적으로 여러 대상으로 파일을 복사하는 것은 느리고 오류가 발생하기 쉬우 며 실패하지 않습니다.

많은 경우를 제외하고는 단일 구성 파일을 업데이트하는 것뿐입니다.이 경우 표준 공식 이미지의 자체 이미지를 굽는 것은 좋지 않으며 추후에 많은 기술 부채가 쌓이고 볼륨이 과잉 X10이며 그렇지 않습니다. 기본 위치에있는 단일 파일이 아닌 전체 폴더를 처리해야하는 문제는 말할 것도없고 파일이 계속 동기화되기를 원하거나 필요로하며 구성 설정을 가져 오는 것이 아니라 시스템 파일 을 업데이트해야합니다.

나는 당신의 우려를 이해합니다. 그러나 모든 사람들에게 그들의 필요가 실제가 아니라고 말하는 것만으로도 당신의 프로젝트와 그것을 사용하고 당신의 작업을 지원하기를 원하는 커뮤니티에서 사람들을 멀어지게 할뿐입니다. 우리는 여기에서 여러분과 함께 작동하는 해결책을 찾고 싶지만 여러분이 말하고 싶은 것은 우리가 필요하다고 생각하는 것이 필요하지 않다는 것입니다.

와우, 아직 안됐다 니 믿을 수가 없네요. 이 기본 기능은 지금까지 도커 작성에있을 것이라고 생각했습니다. 오, OSS 프로젝트의 아름다움 ...

docker-compose --force-recreate --rebuild 해결하면 새 파일이 변경된 경우 (또는 그렇게 보이는 경우) 복사합니다. 이상적이지는 않지만 작동합니다.

+1

+1

+1

+1

+1 이것은 나를 미치게 만드는 낮은 키입니다. 하나의 구성 파일에 대해서만 볼륨을 마운트해야하는 것은 어리석은 것 같습니다.

+1

docker compose with volume을 사용하여 컨테이너에 파일을 추가하는 방법이 있습니다. 이제 Compose 문서에 configs 설정이 있으므로 단일 파일도 추가 할 수 있습니다.

https://docs.docker.com/compose/compose-file/#configs

그러나 사람들이 원하는 것은 호스트의 파일을 컨테이너의 디렉터리로 병합하는 방법이며, 복사본이 작동 할 것으로 예상하는 방식 인 overwrite if exists 를 선호합니다.

compose 파일의 volumes 구성에 nocopy 옵션이 있다는 것이 이상합니다.

https://docs.docker.com/compose/compose-file/#volumes

volumes:
  - type: volume
  source: mydata
  target: /data
  volume:
    nocopy: true

다음과 같이 설명됩니다.
volume: configure additional volume options
nocopy: flag to disable copying of data from a container when a volume is created

그래서 정확히 원하는 것을 비활성화합니까?

내가 원하는 사용 사례는 개발 용 웹 애플리케이션입니다. 이미지에 기본 웹 사이트를 포함하여 웹 사이트를 제공하는 데 필요한 모든 것이 포함되기를 원하지만 파일을 포함하는 것 외에 다른 구성 (키)없이 웹 사이트의 현재 작업 상태로 해당 파일을 병합 / 덮어 쓸 수있는 옵션이 있습니다. 호스트의 올바른 위치. 컨테이너에 복사 할 때 임시 파일 인 파일입니다. 네트워크 공유에 없음을 의미합니다.

이점을 얻을 수있는 프레임 워크의 예는 Laravel과 같습니다. 다른 구성 (볼륨, 네트워크 공유 등)없이 Laravel 스플래시 페이지를 제공 할 수있는 이미지를 만들었지 만 compose 파일은 호스트에서 컨테이너의 Laravel 루트로 파일을 복사하도록 작성되어 있습니다. 덮어 씁니다.

이를 위해 네트워크 공유를 사용하는 것은 임시 환경에 대한 추가 유지입니다 (개발이 항상 일정하지는 않음). Laravel과 같은 프레임 워크와 함께 볼륨 마운트를 사용하려면 해당 볼륨에 앱을 빌드해야합니다. 즉, 호스트에 PHP 및 작곡가를 설치하거나 앱이 생성 될 호스트에서 위치를 공유해야합니다. 둘 다 더 많은 유지 보수를 생성합니다.

편집하다:

테스트 후 볼륨을 마운트하면 해당 위치의 이미지에 있던 파일이 볼륨의 원래 내용보다 우선하여 영구 볼륨에 복사되는 것 같습니다. 덮어 쓰지 않음을 의미합니다.

실제로 이것이 원하는 결과에 대한 해결책이라고 생각합니다.

이봐, 여러분, 참고로, "+1"코멘트를 추가하는 것보다이 이슈에 대한 최고 메시지에 엄지 손가락으로 반응하는 것이 좋습니다. 이슈는받은 반응 수에 따라 분류 될 수 있기 때문입니다.

+1

+1 Docker 팀, 귀하의 커뮤니티를 고려하십시오.

@ shin- 지금 문제는 볼륨 기능으로 인해 외부 볼륨의 단일 구성 파일을 컨테이너에 연결할 수 없다는 것입니다.

nginx 구성 파일을 /etc/something/whatever.conf 에 연결하고 해당 폴더에있는 다른 모든 항목을 제거한다고 가정합니다. 단일 파일에 대해 명명 된 볼륨을 생성 할 수 없으며 (moby / moby # 30310 참조) 단일 파일을 포함하는 디렉토리 볼륨을 생성 한 다음 해당 특정 파일을 컨테이너에 마운트 할 수도 없습니다 (moby / moby # 참조). 32582).

남은 유일한 옵션은 구성 파일로 실제 Docker 호스트의 고정 위치를 오염시킨 다음 마운트를 바인드하는 것입니다. 물론 Docker 호스트 사이를 이동하거나 Docker와 함께 작업하려는 경우이 작업은 산산조각이납니다. 파일 시스템 액세스 권한이없는 호스트 (예 : 온라인 CI) 또는 병렬로 여러 스택을 실행하는 경우도 있습니다.

여기에서 뭔가를 포기해야합니다. Docker의 볼륨 기능을 변경하여 실제로 스택에 구성 파일을 삽입하는 데 사용할 수 있도록하거나 copy 와 같은 것을 사용하여 작성시이를 해결해야합니다

FWIW 저는 더 이상 Compose 메인테이너가 아니지만 Dockerfile을 사용하여 빌드시 구성 파일을 삽입하는 것이 가장 좋은 사용 사례 인 것 같습니다.

@ shin- 불행히도 구성 파일은 빌드 시점에 알려지지 않았으며 이미지는 배포 할 위치와 구성을 알기 훨씬 전에 CI 서버에서 준비됩니다.

저는 @masaeedu를 사용 하고 있습니다. compose 기능을 크리핑으로부터 유지하여이 기능을 추가하고 싶지 않다는 개념적 이상을 이해합니다. 그러나 실생활에서이 기능의 손실은 compose없이 사용할 수있는 상황을 크게 줄입니다.

A) 문제의 컨테이너를 세우기 위해 일종의 끔찍한 스크립트 작업을 함께 뭉쳐야합니다 (구성하는 것은 표준화를 돕고 우리가 할 필요가 없도록하기위한 것입니다).

B) 모든 구성을 처리하는 다른 도구를 추가해야합니다 (실행 가능하지만 실제로 특정 .conf 및 .env를 각 컨테이너에 복사해야하는 중소 규모 프로젝트에 엄청난 양의 오버 헤드를 추가합니다. 이미지 빌드시 수행하고 싶지 않습니다. 즉, 소프트웨어에 구성 파일이있는 대신 모든 옵션을 C ++에 하드 코딩해야하며 유지 관리해야 할 추가 이미지가 수십 개가 필요하다고 말하는 것과 동일합니다.

C) 사소한 구성 변경이 필요할 때마다 필요한 소프트웨어의 모든 가능한 구성에 대해 별도의 이미지를 유지해야합니다 ./ 실제 환경에서는 둘 다 작동하지 않습니다. 또한 프로덕션 소프트웨어에 필요한 강력한 QA 및 테스트 파이프 라인을 갖지 못하게합니다.