내가 뭘 잘못하고 있는지 모르겠지만 docker-compose up먼저 시스템에서 오래된 컨테이너를 완전히 제거하지 않으면 레지스트리에서 최신 이미지를 사용할 수 없습니다 . docker-compose pull이 최신 이미지를 가져 왔음에도 compose가 이전에 시작된 이미지를 사용하는 것처럼 보입니다.
항상 새로운 이미지에서 컨테이너를 다시 생성하기 위해 docker-compose를 얻는 방법을 살펴 보았습니다 . 내 문제와 비슷해 보이지만 프로덕션 서버에서 사용할 수있는 솔루션을 찾고 있기 때문에 제공된 솔루션 중 어느 것도 나를 위해 작동하지 않으며 시작하기 전에 모든 컨테이너를 제거하고 싶지 않습니다. 다시 (가능한 데이터 손실?). 변경된 이미지의 새 버전을 감지하고 가져 와서 해당 새 이미지로 서비스를 다시 시작하기 위해서만 작성하고 싶습니다.
나는 이것을 위해 간단한 테스트 프로젝트를 만들었는데, 유일한 목표는 각각의 새로운 빌드에서 증가 할 버전 nr을 얻는 것입니다. 생성 된 nginx 서버로 이동하면 버전 nr이 표시됩니다 (로컬에서 예상대로 작동 함).
docker 버전 : 1.11.2 docker-compose 버전 : 1.7.1 OS : docker-toolbox를 사용하여 CentOS 7 및 OS X 10.10에서 테스트되었습니다.
내 docker-compose.yml :
version: '2'
services:
application:
image: ourprivate.docker.reg:5000/ourcompany/buildchaintest:0.1.8-dev
volumes:
- /var/www/html
tty: true
nginx:
build: nginx
ports:
- "80:80"
volumes_from:
- application
volumes:
- ./logs/nginx/:/var/log/nginx
php:
container_name: buildchaintest_php_1
build: php-fpm
expose:
- "9000"
volumes_from:
- application
volumes:
- ./logs/php-fpm/:/var/www/logs
젠킨스 서버에서 다음을 실행하여 이미지를 빌드하고 태그를 지정합니다.
cd $WORKSPACE && PROJECT_VERSION=$(cat VERSION)-dev
/usr/local/bin/docker-compose rm -f
/usr/local/bin/docker-compose build
docker tag ourprivate.docker.reg:5000/ourcompany/buildchaintest ourprivate.docker.reg:5000/ourcompany/buildchaintest:$PROJECT_VERSION
docker push ourprivate.docker.reg:5000/ourcompany/buildchaintest
빌드가 완료되고 버전 nr이 충돌 할 때마다 저장소에서 새 버전 태그를 얻었 기 때문에 이것은 예상대로 작동하는 것 같습니다.
내가 지금 달리면
docker-compose pull && docker-compose -f docker-compose.yml up -d
내 컴퓨터의 폴더에서 콘텐츠가 docker-compose.yml 및 nginx 및 php 서비스를 빌드하는 데 필요한 Dockerfiles 인 경우, 내가 얻은 출력은 레지스트리에 태그가 지정된 최신 버전 번호가 아니거나 표시됩니다. docker-compose.yml (0.1.8)에 있지만 그 이전 버전은 0.1.7입니다. 그러나 pull 명령의 출력은 이미지의 새 버전을 가져 왔음을 나타냅니다.
Pulling application (ourprivate.docker.reg:5000/ourcompany/buildchaintest:latest)...
latest: Pulling from ourcompany/buildchaintest
Digest: sha256:8f7a06203005ff932799fe89e7756cd21719cccb9099b7898af2399414bfe62a
Status: Downloaded newer image for docker.locotech.fi:5000/locotech/buildchaintest:0.1.8-dev
내가 달리면
docker-compose stop && docker-compose rm -f
그런 다음 docker-compose up명령 을 실행하면 예상대로 화면에 새 버전이 표시됩니다.
이것은 도커 작성의 의도 된 동작입니까? 즉 , 프로덕션 서버에서도 다시 docker-compose rm -f실행하기 전에 항상 a 를 수행 up해야합니까? 아니면 여기서 곡물에 대해 뭔가를하고 있는데 이것이 작동하지 않는 이유입니까?
목표는 빌드 프로세스가 docker-compose.yml에 필요한 이미지의 태그가 지정된 버전을 빌드하고 생성하고,이를 개인 레지스트리로 푸시 한 다음 “release to production-step”에서 단순히 docker-compose를 복사하도록하는 것입니다. yml을 프로덕션 서버에 추가하고 프로덕션 docker-compose pull && docker-compose -f docker-compose.yml up -d에서 새 이미지를 시작 하려면 a 를 실행하십시오 . 누구든지 이것에 대한 팁이 있거나 이러한 종류의 설정에 대한 모범 사례 자습서를 가리킬 수 있다면 많은 도움이 될 것입니다.
답변
:latest레지스트리 (예 : 도커 허브)에서 태그에 최신 버전을 사용하고 있는지 확인 하려면 최신 태그도 다시 가져와야합니다. 변경된 경우 diff가 다운로드되어 docker-compose up다시 시작됩니다 .
그래서 이것이 갈 길입니다.
docker-compose stop
docker-compose rm -f
docker-compose pull
docker-compose up -d
나는 이것을 Docker-compose를 시작하고 이미지가 최신 상태로 유지되도록 실행하는 이미지에 붙였습니다 .https : //hub.docker.com/r/stephanlindauer/docker-compose-updater/
답변
최신 이미지를 얻으려면 docker-compose build –pull을 사용하십시오.
나는 실제로 3 in 1 인 아래 명령을 사용합니다.
docker-compose down && docker-compose build --pull && docker-compose up -d
이 명령은 서비스를 중지하고 최신 이미지를 가져온 다음 서비스를 시작합니다.
답변
이 질문을 끝내기 위해 효과가 있었던 것처럼 보이는 것이 실제로 실행 중입니다.
docker-compose stop
docker-compose rm -f
docker-compose -f docker-compose.yml up -d
즉, up다시 실행하기 전에 컨테이너를 제거 하십시오.
이렇게 할 때 명심해야 할 점은 rm -f.을 실행하면 데이터 볼륨 컨테이너도 제거된다는 것 입니다. 제거 할 각 컨테이너를 명시 적으로 지정하는 것을 방지하려면 다음을 수행하십시오.
docker-compose rm -f application nginx php
내 질문에서 말했듯이 이것이 올바른 프로세스인지 모르겠습니다. 그러나 이것은 우리의 사용 사례에서 작동하는 것처럼 보이므로 더 나은 솔루션을 찾을 때까지이 솔루션을 사용할 것입니다.
답변
나는 이것이 우리의 7-8 도커 프로덕션 시스템에서 발생하는 것을 보았습니다. 프로덕션에서 저에게 도움이 된 또 다른 솔루션은
docker-compose down
docker-compose up -d
이것은 컨테이너를 제거하고 최신 이미지에서 새 컨테이너를 만드는 ‘구성’하는 것처럼 보입니다.
이것은 아직 각 변경된 컨테이너 당 down + up에 대한 나의 꿈을 해결하지 못하지만 (연속적으로, 다운 타임 감소), 컨테이너를 업데이트하기 위해 강제로 작동합니다.
답변
down이 문제를 해결하는 옵션
내 작성 파일을 실행합니다.
docker-compose -f docker/docker-compose.yml up -d
그런 다음 모두 삭제 down --rmi all
docker-compose -f docker/docker-compose.yml down --rmi all
Stops containers and removes containers, networks, volumes, and images
created by `up`.
By default, the only things removed are:
- Containers for services defined in the Compose file
- Networks defined in the `networks` section of the Compose file
- The default network, if one is used
Networks and volumes defined as `external` are never removed.
Usage: down [options]
Options:
--rmi type Remove images. Type must be one of:
'all': Remove all images used by any service.
'local': Remove only images that don't have a custom tag
set by the `image` field.
-v, --volumes Remove named volumes declared in the `volumes` section
of the Compose file and anonymous volumes
attached to containers.
--remove-orphans Remove containers for services not defined in the
Compose file
답변
나는이 문제로 반나절을 보냈다. 그 이유는 볼륨이 녹음 된 위치를 확인하기 때문입니다.
볼륨 :-api-data : / src / patterns
하지만 사실은 여기에 우리가 변경 한 코드가있었습니다. 그러나 도커를 업데이트 할 때 코드는 변경되지 않았습니다.
따라서 다른 사람의 코드를 확인하고 어떤 이유로 업데이트하지 않는 경우이를 확인하십시오.
따라서 일반적으로이 접근 방식은 다음과 같이 작동합니다.
docker-compose down
도커 작성 빌드
도커 구성 -d
답변
‘up’ 명령에 대한 docker-compose 문서 는 마지막 ‘up’이 수행 된 이후 이미지가 변경되면 컨테이너를 업데이트한다고 명확하게 명시합니다.
서비스에 대한 기존 컨테이너가 있고 컨테이너 생성 후 서비스의 구성 또는 이미지가 변경된 경우 docker-compose up 은 컨테이너를 중지하고 다시 생성 (마운트 된 볼륨 유지)하여 변경 사항을 선택합니다.
따라서 ‘중지’, ‘풀’, ‘업’을 차례로 사용하면 이미지가 업데이트 된 컨테이너를 제외하고 실행중인 컨테이너의 볼륨 손실 문제를 방지 할 수 있습니다.
현재이 프로세스를 실험 중이며 곧이 의견에 결과를 포함 할 것입니다.
