Compose: 이미지가 로컬에 있는 경우 docker-compose up은 최신 이미지를 풀다운하지 않습니다.

docker-compose pull && docker-compose up 가 비실용적인 이유가 있습니까?

나는 --pull 을 docker run 에 추가하는 문제에서 논의한 것과 대부분의 찬성/반대 포인트가 동일하다고 생각합니다. ux 및 일관성, 스크립팅/워크플로의 용이성, 무리 통합에 이르기까지 다양합니다(호기심에서 docker-compose pull 는 Swarm에서 무엇을 합니까?).
큰 문제는 아니지만 생각해 볼 문제라고 생각합니다. 다른 곳에서 이 기능을 원했던 동일한 유형의 사용자가 여기에서도 이 기능을 즐길 수 있습니다.

"docker-compose build"를 실행하려고 하는데 _--pull_을 사용하는 경우를 제외하고는 Dockerfile에서 참조하는 이미지를 새로 고치지 않습니다.

_up --build_를 사용하여 시작하는 동안 컨테이너를 빌드할 수도 있습니다. 그러나 최신 이미지는 가져오지 않습니다. "docker-compose up --build --pull"(또는 이와 유사한)과 같은 sth를 기대할 수 있습니까? 모든 빌드를 새로 고쳐야 하는 것은 아니므로 YML에 배치하는 것이 합리적일 수 있습니다(로컬 이미지 참조).

cli에 --pull을 추가하는 대신(또는 추가로) docker-compose 파일의 서비스 정의에 무언가를 추가하는 것은 어떻습니까?

version: '2'

services:

  postgres:
    image: postgres
    container_name: postgres
    pull: true
    ports:
     - '5432:5432'

이렇게 하면 내가 최신 상태에 신경 쓰지 않는 서비스가 있고 내가 하는 서비스가 있는 경우 docker-compose는 관심이 없는 이미지를 다운로드하는 데 시간을 낭비하지 않습니다.

Kubernetes의 프로덕션 클러스터에서 이 기능을 사용하기 때문에 이 기능을 찾아 왔습니다. 태그는 "imagePullPolicy"이며 "IfNotPresent", "Always" 또는 "Never"로 설정할 수 있습니다. 작성 환경과 비슷한 것이 좋을 것입니다.

우리의 경우 애플리케이션에 대한 최신 종속성이 업데이트되었는지 확인하기 위해 매일 기본 이미지를 다시 빌드해야 합니다. Docker가 동일한 태그로 최신 이미지를 가져오기 위해 작성하는 것은 좋은 기능입니다. 왜 안 돼 !

이것에 대한 소식이 있습니까?

안녕하세요,

이 문제에 대한 소식이 있습니까?

+1

+1

앞서 언급했듯이 docker-compose pull && docker-compose up 는 기능적으로 동일합니다. 다른 플래그를 추가할 이유가 없습니다.

git fetch && git merge origin/master 가 기능적으로 동일하기 때문에 git에 pull 가 없다고 상상해보십시오.

예를 들어 작성 파일에서 사용하는 이미지 중 일부가 캐시에 있는 경우 pull: true 태그를 추가하면 유용할 수 있습니다. docker-compose pull 작성 파일의 _all_ 이미지를 가져오며 이러한 이미지가 캐시에 있지만 저장소에는 없는 경우 해당 가져오기가 실패합니다.

+1

docker-compose pull && docker-compose up 가 비실용적이 되는 한 가지 시나리오는 여러 docker-compose 파일을 사용하는 경우입니다. docker-compose -f docker-compose.test.yml pull && docker-compose -f docker-compose.test.yml up 와 같은 명령으로 쉽게 끝낼 수 있습니다.

로컬에서 개발하고 원격에서 일부 이미지만 가져오고 싶은 시나리오가 있습니다. 현지에서 개발된 것(또는 그 이상)은 그대로 유지되어야 합니다. 이 경우 docker-compose up을 실행하기 전에 수동으로 이미지를 빌드/풀해야 합니다.
pull: true 가 유용할 것입니다.

@shin- 이에 대한 결정을 재고하는 것은 어떻습니까? 나는 그들에 대한 댓글과 반응이 충분히 자명해 보인다고 생각합니다.

아니, 난 괜찮아. 이것은 오픈 소스 프로젝트입니다. 기능을 추가할 때 우리가 취하는 보수적인 접근 방식에 동의하지 않는다면 포크할 수 있습니다.

docker-compose up 명령에 플래그를 추가하거나 구성에 매개변수를 추가하는 데 동의합니다. 개발 과정에서 자주 변경되는 추가 구성이 있는 기본 이미지를 사용합니다. 우리는 개발자가 디버그할 필요가 없는 것을 디버깅하지 않고 간단히 docker-compose up을 실행할 수 있는 완벽한 환경을 만들고 싶습니다.

동료가 내 pull 요청을 확인하고 빌드가 중단되었다고 말한 후에 실제로 이 스레드를 쳤습니다. 그리고 그 이유는 기본 이미지에 몇 개의 패키지가 누락되었지만 최종 Dockerfile에서 실행되었기 때문입니다. 그것은 좋은 기능이 될 것이지만 분명히 당신이 사용한 것은 아닙니다, @shin- .

새 버전에서 이 기능을 도입하면 기쁩니다.

@ shin- 내가 @blockloop으로 보여 주었다 생각 git 풀 옵션이 얼마나 편리 / 유용한 예. 솔직히 나는 그러한 것들을 위해 어떤 프로젝트도 포크할 필요가 없기를 바랍니다.

보수적인 접근 방식은 충분히 이해하지만 더 이상 선택 사항으로 간주되지 않는 것 같습니다. 아마도 다음 버전의 일부가 될 수 있습니까?

pull: IfNotPresent 이면 좋을 것입니다. 따라서 다음과 같은 폴백을 사용할 수 있습니다.
1) 로컬 이미지 사용
2) 로컬이 아닌 경우 끌어오기
3) 당길 수 없는 경우 빌드

@shin- 계속 && 방식이 잘리지 않는 이유를 물으시는데 제 이유는 이것입니다. 테스트용 "앱" 이미지에 사용합니다(Puppet PDK/Onceover). 작성 파일은 템플릿 리포지토리의 일부이므로 꼭두각시 개발자(실제로 운영하는 사람들)가 새 모듈을 만들어야 할 때 해당 리포지토리를 분기합니다. Jenkins는 해당 모듈 저장소에서 병합 유효성 검사를 위한 이미지를 실행합니다(내부적으로 작업에 대한 업데이트를 처리하는 jenkins 플러그인이 있습니다.) 이제 이것을 사용하는 사람들은 도커 전문가가 아니며 &&를 수행하도록 지시해야 하는 것은 추가입니다. 그들이 (아마도) 망칠 수 있는 단계. 왜 힘들고 어떤 불이익이 생길지 모르겠지만 이 추론은 추가할 가치가 있는 이유인 것 같습니다. 그것은 우리 개발자들이 더 적은 지시와 단계를 필요로 하는 것들을 보내는 데 도움이 됩니다..

짧은 것은 .... 게으름으로부터 보호하기 위해

여기에 더 나은 이유가 있습니다. && 는 동기식입니다. 그러나 docker-compose는 이 항목을 최적화하는 병렬 실행기를 크게 지원합니다. docker-compose up --pull --build 는 모든 이미지가 풀릴 때까지 기다렸다가 빌드를 시작하는 대신 이미지 빌드를 시작하고 풀링되는 즉시 실행할 수 있습니다.

@shin 은 드물게 업데이트되는 Dockerfile로 매우 드물게 자신을 위해 사용하고 있다고 가정합니다.
그러나 개발자가 사용할 Docker 이미지를 매일 업데이트하면 한 명의 개발자가 매일 수행해야 하는 이미지 가져오기를 잊어버리면 빠르게 개발 문제로 이어집니다(특히 docker에 익숙하지 않은 사람, 실제로 그것을 알고 기억하는 것은 그들의 일이 아닙니다). 재난 프로그램.
이 옵션을 docker-compose.yml에 추가하는 것이 큰 문제입니까?
내 말은, 그것은 다른 것을 변경하지 않고 단지 기능을 추가한다는 것입니다. ..

내가 docker-compose를 사용할 수 없고 레거시 docker run 명령으로 래퍼 스크립트를 작성해야 하는 이유가 바로 이것이지만 보기 흉합니다.

이 티켓이 폐쇄된 상황을 파악하는 중입니다. 누군가 자세히 설명해 주시겠습니까? 도움이 되셨다면 저는 --pull 플래그를 docker-compose up 있습니다.

여기에서 논의되는 두 가지 제안이 있다고 생각합니다.

1 - 이것을 명령줄 옵션으로 추가해야 합니까? 실제로 게시 된 문제.
2 - 이 옵션을 YML 파일에 추가해야 합니다.

@shin 이 실제로 이에 대해 언급하지 않았지만 나는 확실히 후자에 동의합니다. 동일한 주장으로 그것을 기각하는 것은 기능적으로 동일하다는 것은 일관성이 없습니다. YML 파일의 모든 것은 기능적으로 명령줄과 동일합니다.

전자에 대한 그의 요지는 알 수 있지만, 그 근거가 좀 너무 광범위하다고 생각합니다. 일련의 명령문을 && 로 연결하여 명령줄에서 거의 모든 작업을 수행할 수 있습니다. 분명히 합시다. 그것들은 하나가 아니라 두 개의 명령입니다. 기준은 다음과 같아야 합니다. 이에 대한 수요가 충분하여 두 단계가 아닌 한 단계로 수행할 수 있습니까? 충분히 자주 사용하면 연결된 명령의 수가 계속 증가하기 때문입니다. 요점은 스크립트를 작성할 때 가능한 한 간결하게 작성하기를 원한다는 것입니다.

@orodbhen 은 논쟁할 필요가 없습니다. 여기 아무도 우리 말을 듣지 않습니다.

플래그를 추가해야 하는 이유를 덧붙이자면... 지난 1년 정도 동안 나는 바로 이것에 대해 검색하다가 결국 여기까지 오게 되었고 이미 여러 의견에 찬성하여 엄지손가락을 치켜들었습니다. --pull 플래그입니다. 다음에도 이곳을 다시 찾게 될 것 같아요.

@shin-, 이 문제를 다시 열거나 잠그십시오. 거의 2년 동안 열려 있으며 지속적인 논평(지능적이고 재미있는), 수십 명의 참가자 및 수백 명의 투표를 받았습니다.
그러나 작성 팀은 이 기능을 추구하는 데 관심이 없는 것 같습니다. 따라서 다른 사람의 시간을 낭비하거나 그렇지 않은 경우 문제가 부활할 것이라는 잘못된 희망에 여지를 두지 맙시다.

욕설 사용은 자제해 주세요.

내가 원래 요청에 유용성이 있다고 생각 할 수 있지만,이 스레드에서 많은 사람들이 오픈 소스의 정신을 잊지 것 같다 : 그것은 당신에게 중요한, 당신은 포크와 당신의 마음의 콘텐츠를 자유롭게 변경할 수있는 것이 있다면. 나는 당신이 포크를 유지하고 싶지 않을 수도 있다는 것을 이해하지만, 유지 관리자가 기능을 구현하지 않을 것이라고 불평하는 것은 역효과를 낳습니다. 그것은 기능이 구현되는 방식이 아니며 유지 관리자가 당신을 덜 돕고 싶어하게 만들 것입니다.

특히 아무도 제품을 사용하기 위해 비용을 지불하지 않는 경우 기능에 대한 수요가 있는지 여부는 중요하지 않습니다. 모든 사람이 원하는 모든 기능을 기본 제품에 넣는 것보다 더 고려해야 할 사항이 있습니다. 이에 대한 @shin-의 답변을 존중해야 하며 이를 구현하지 않는 데에는 합당한 이유가 있다고 생각합니다.

@lig 논쟁할

필요에 따라 포크가 과도할 수 있습니다. 내 특별한 경우에는 Compose가 매우 기본적인 스크립트가 아닌 한 스크립팅에 적합하지 않다는 것을 알았습니다. Docker Python API와 내 YAML 파일을 사용하여 설정을 유지하는 것이 더 다양하고 더 간단합니다.

@bdharrington7 — 하지만 포크를 유지 관리하고 사용하는 모든 컴퓨터에 설치한 상태로 유지해야 합니다(거의 가능하지 않음). 주의 사항은 Docker Compose가 인기가 있다는 것입니다. 다른 사람들은 "누가 상관합니까?"

현실은 "오픈 소스입니다. 자신만의 포크를 만드세요"라는 댓글이 현실적이지 않다는 것입니다. 자체 포크를 유지 관리하고 메인 리포지토리의 최신 변경 사항으로 최신 상태를 유지하는 오버헤드로 인해 투자 가치가 거의 없습니다. 훨씬 더 나은 접근 방식은 유지 관리자에게 청원을 하고 기능이 왜 중요한지에 대한 적절한 이유를 제공하는 것입니다.

슬프게도 그것은 항상 약간의 불만족과 함께 이와 같은 문제를 야기할 것입니다. 여기에서 주된 문제는 이것이 왜 나쁜 생각인지에 대한 적절한 사례가 제시되지 않은 것 같다는 것입니다. 논쟁 거리

"우리는 이에 대한 @shin-의 답변을 존중해야 하며, 이를 구현하지 않는 데에는 합당한 이유가 있다고 믿습니다."

사람들을 만족시키지 못할 뿐입니다. 커뮤니티는 "좋은 이유"를 볼 필요가 있습니다.

요점은 주먹을 쥐고 구걸하는 경우가 거의 없다는 것입니다.
당신이 원하는 것을 얻을 때, 이 스레드에서 많은 일이 일어났습니다.
쓰레드에서도 좋은 사용 사례가 많이 나왔고,
그러나 실제로 소프트웨어 비용을 지불하지 않는 한
이에 대해 조치를 취하거나 이유를 제시하지 마십시오. 나는
@shin-과 회사에 여기에 의심의 이익을 주는 것뿐입니다.
2018년 3월 24일 토요일 오전 5시 39분 Greg Pakes [email protected]이 다음과 같이 썼습니다.

현실은 '오픈소스다, 나만의 포크를 만들어라'라는 댓글,
단지 현실적이지 못하다. 자신의 포크를 유지하는 오버헤드와
메인 리포지토리의 최신 변경 사항을 최신 상태로 유지
투자 가치가 거의 없습니다. 훨씬 더 나은 방법은 청원하는 것입니다
기능이 필요한 이유에 대한 적절한 이유를 제공합니다.
중요한.

슬프게도 항상 이와 같은 문제가 발생합니다.
불만. 여기에서 가장 중요한 문제는
이것이 왜 나쁜 생각인지에 대한 적절한 사례가 제시되었습니다. NS
인수 "우리는 이에 대한 @shin- http:///shin- 의 응답을 존중해야 합니다.
그리고 그것을 구현하지 않는 데에는 합당한 이유가 있다고 믿습니다."
사람들을 만족시킬 것입니다. 커뮤니티는 "좋은 이유"를 볼 필요가 있습니다.

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인
https://github.com/docker/compose/issues/3574#issuecomment-375805478 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AEV8Q9RseMxYS8KGyD9E2BK0pZv7OJpuks5thWt7gaJpZM4IyPQh
.

요점은 주먹을 휘두르고 구걸해도 원하는 것을 얻는 경우가 거의 없다는 것입니다.

이것은 사실이 아닙니다. 무료 작업을 요청하는 전략으로 그것을 용납하지는 않지만 실제로는 상당히 효과적입니다. 청원이 작동하는 방식과 "주먹을 두드리는" 사람들이 많을수록 중요한 사람들이 주의를 기울일 가능성이 높아집니다. 다시 말하지만, 나는 그것을 승인하지 않습니다

스레드에도 좋은 사용 사례가 많이 있습니다.

본질적으로 "대신 이 두 명령을 수행할 수 있습니다"로 요약되는 한 가지 경우를 볼 수 있습니다. 그러나 분명히 사람들은 그것을 원하지 않습니다. 따라서 그들을 참여시키고 그것이 왜 좋은 일인지 교육하십시오.

유지 관리자가 이에 대해 조치를 취하거나 이유를 제시할 의무가 없습니다.

나는 동의한다. 그러나 사람들이 그것에 대해 좌절할 것을 예상해야 합니다. 무시하는 태도입니다. 결국 여기 있는 모든 사람들은 같은 팀에 있습니다. 프로젝트를 유지 관리하는 사람들과 프로젝트 사용자는 모두 프로젝트가 성공하기를 바랍니다.

여기에서 정확히 어떤 제품이 무료인가요? docker-compose.exe를 사용하고 docker EE를 실행하면 실제로 제품에 대한 비용을 지불한다는 의미가 아닙니까?

IMHO --build 당겨야 합니다; 다른 플래그나 구성이 필요하지 않습니다. 가져오지 않으려면 이미지 버전을 지정하십시오.

@ET-CS: 이미지 버전은 태그일 뿐이며 여전히 다른 해시로 변경할 수 있습니다.

좋은 지적 @lifeofguenter 감사합니다. 이미지가 다른 해시로 변경되었는지 확인하고 해당 경우에도 가져올 수 있습니까?

그런 장면에서 저는 모든 환경(dev, prod)이 가능한 한 동일한 이미지를 가지기를 원한다고 생각합니다. 이제 프로덕션에서는 이전 해시를 사용하고 개발자는 새 해시를 사용하기 때문입니다.

--build 가) 모든 것을 최신 상태로 유지하기를 기대합니다.

좋은 사용 사례는 다음과 같습니다.

백엔드 서비스에서 새로운 기능을 개발할 때 새 이미지를 레지스트리로 가져오는 마이크로서비스 프로젝트용 CI를 구현했습니다. 프론트엔드 팀(도커에 대해 거의 알지 못함)은 로컬 시스템에서 전체 백엔드 스택을 불러올 수 있는 방법이 필요하며 가장 업데이트된 이미지에 의존합니다. 무언가가 고장난 경우에만 이미지를 가져오는 것을 기억할 것입니다.

이제 이것이 일어났습니다. 누군가 백엔드 이미지를 업데이트하는 것을 잊어버리고 이전 버전을 기반으로 전체 기능을 개발했기 때문에 전체 개발 스프린트가 실패했습니다. 프론트엔드 팀을 비난하지만 이 기능을 사용하면 이를 피할 수 있습니다(래퍼 스크립트를 사용하여 수행할 예정임).

@agnjunio 정말 불행하게 들리네요. 죄송합니다. 그러나 그 사람이 docker-compose pull 를 실행하는 것을 잊었다면 가상의 --pull 플래그를 사용하는 것을 잊었을 가능성이 얼마나 낮습니까?

@shin- 죄송합니다. 중요한 것을 언급하는 것을 잊었습니다. 제 경우의 해결책은 pull: always 태그를 yaml 내부, 아마도 image: 옵션 내부에 두는 것입니다.

https://github.com/docker/compose/issues/3574#issuecomment -382451356의 @ET-CS:

--build 가 모든 것을 최신 상태로 만들 것으로 기대합니다.

IMHO --빌드를 가져와야 합니다. 다른 플래그나 구성이 필요하지 않습니다. 가져오지 않으려면 이미지 버전을 지정하십시오.

depends_on 빌드의 결과인 FROM을 사용하는 빌드의 사용 사례를 차단하는 AFAIK.

version: "3.4"
services:
  some-base-image:
    image: our/base-image
    build:
      context: ./base
  # This Dockerfile has FROM our/base-image
  coolthing:
    depends_on:
    - some-base-image
    build:
      context: ./coolthing

저는 https://github.com/docker/compose/issues/3574#issuecomment -252861859 및 https://github.com/docker/compose/issues/3574#issuecomment -279460839에서 제안한 플래그를 찬성합니다.

@solsson
이 사용 사례에서 차단하는 이유 또는 차단하는 항목이 무엇인지 잘 모르겠습니다.
가능하다면 이에 대한 자세한 정보를 공유해 주십시오.

@shin- 여기서 차이점은 docker-compose up --help 실행하면 :latest 이미지를 사용하는 방법에 대한 설명을 받는 대신 요즘에는 문서나 Google에서 검색해야 한다는 것입니다. 이 스레드는 docker-compose up 가 내가 필요로 하는 작업을 수행하지 않는다는 것을 이해하기 위해 모든 주석을 읽어야 하므로 이제 두 개의 명령을 실행해야 합니다.

@agnjunio 정말 불행하게 들리네요. 죄송합니다. 그러나 사용자가 docker-compose pull을 실행하는 것을 잊었다면 가상의 --pull 플래그를 사용하는 것을 잊어버릴 가능성이 얼마나 줄어들었는지 잘 모르겠습니다.

다정하게

docker-compose를 사용하는 주요 이유 중 하나는 docker-compose.yaml 파일을 저장소에 배치하고 개발자가 저장소를 가져와 docker-compose up [service] 실행할 때 재현 가능한 출력을 갖는 기능입니다.

codegen 실행 및 JSON 스키마를 단일 파일로 역참조하는 도구 실행과 같은 작업을 수행하는 docker-compose 파일 내에서 여러 서비스를 사용합니다.
이러한 도구가 최신 상태인지 확인하는 것은 특히 모든 프로젝트에서 볼 수 있는 공통적인 중요한 문제를 해결하기 위해 codegen 이미지를 업데이트하는 경우 중요합니다.

배치 능력:

services:
  codegen:
    image: myimage:latest
    pull: Always

개발자가 앱을 시작하기 전에 최신 사용 가능한 이미지를 가져오기 위해 일련의 명령이나 스크립트를 실행하도록 상기시키기 위해 문서로 모든 단일 저장소를 보완할 필요 없이 개발자가 안정적으로 docker-compose up을 실행하고 예상 결과를 얻을 수 있는 기능을 유지합니다. .

"이 명령을 실행하여 이를 수행할 수 있는 기능이 이미 존재함"에 관한 것이 아니라 더 나은 사용자 경험입니다.

누군가 docker-compose rm --stop 를 추가하자고 제안했을 때 대답은 " docker-compose stop myapp && docker-compose rm myapp 무슨 문제가 있습니까? 또는 누군가 docker-compose down 의 구현을 요청했다면 docker-compose stop myapp && docker-compose rm -v myapp && docker-compose images -q myapp | xargs docker rmi ... 비실용적인 이유가 무엇인지 물었습니다.

이 스레드는 2년 전에 제기되었으며 여전히 docker-compose.yml에 플래그를 추가하는 것이 가장 좋은 방법이라고 생각했습니다. 제 경우에는 37개 정도의 서비스가 한 무리에 있는데, 그 중 4-5개 이미지를 업데이트하는 것은 쉽지 않습니다. 지금은 저장소에서 변경 사항을 모니터링하고 서비스가 업데이트된 경우 서비스를 다시 만들기 전에 특정 이미지에 대해 풀을 수행할 수 있는 셸을 만들었습니다.

여기서 또 다른 요점은 docker-compose up 에 --quiet-pull 옵션이 있다는 것입니다. up 에 pull이 포함되어 있는지 처음 확인하려고 했을 때, 나는 그것이 존재를 기반으로 한 것으로 가정했습니다. --quiet-pull 사용하지 않으면 장황한 pull이 발생합니다.

Docker Compose 유지 관리자에게 --pull 옵션이 있으면 별도의 명령을 실행할 필요 없이 더 나은 경험이 될 것이라고 확신시키려고 노력한 2년의 사람들. docker-compose 유지 관리자가 이 기능을 구현했다면 우선 모든 사람의 삶이 더 나아질 것입니다. 현재 유지 관리자가 커뮤니티 개선을 위해 이 기능을 추가하고 싶지 않다는 것이 분명한 것 같습니다.

아마도 우리는 docker-compose를 포크하고 스스로 업데이트해야 할 것입니다.

누군가가 PR을 제출한다면, 그것이 받아들여지면 기회가 될까요?
이것은 오픈 소스입니다. 나는 그것을 몇 가지 구현하기 위해 거의 조사했습니다.
나 자신. 나는 그것이 받아 들여질 수 있다고 가정합니다. 그렇지 않으면이 역할이 닫힙니다.
오른쪽?

나는이 같은 문제와 성가신 쓰레기, 여기에서 웅성 거리는 무리에 부딪쳤습니다. 이것은 무료 오픈 소스 소프트웨어입니다. 유지보수자에게 휴식을 주십시오. 나는 그들이 이것보다 훨씬 더 중요한 일을 하고 있다고 확신합니다. 누군가가 이것을 절실히 필요로한다면 PR을 열지 않겠습니까? 코드가 최소한의 위험으로 깨끗하다면 왜 수락하지 않는지 모르겠습니다.

논의에 이 요청을 구현하지 않을 타당한 이유가 없기 때문에 이 문제를 다시 열어야 합니다. 사람들은 닫힌 문제보다 _공개_ 문제에 대해 작업을 시작할 가능성이 더 큽니다.

이 "닫힌" 문제가 여전히 활성화되어 있다는 사실은 이 문제가 제대로 처리되지 않았음을 시사합니다.

불행히도 일부 GitHub 리포지토리의 문제 게시물에 대한 응답은 그다지 도움이 되지 않는 것으로 나타났습니다. 어조는 종종 간결하며 피드백이 환영받지 못한다는 것을 암시합니다.

일부는 여기에서 이것이 오픈 소스 프로젝트이며 (적어도 우리 대부분은) 고객에게 비용을 지불하지 않는다고 지적했습니다. 그러나 문제 보고서를 제출하는 것은 상당한 시간 투자를 의미하며, 문제 해결에 참여하는 경우에는 더욱 그렇습니다.

문제를 해결하는 데 시간을 할애하고 해결 방법을 찾은 사용자 또는 개발자는 이를 보고하는 데 추가 시간을 할애할지 여부를 결정할 것입니다. 유지 관리자의 수용할 수 없는 응답은 다음 번에는 귀찮게 하지 않기로 결정하는 결과를 낳을 수 있습니다.

소프트웨어는 "무료 맥주"라는 의미에서 실제로 "무료"가 아닙니다. 우리 모두가 더 나은 환경을 만들기 위해 참여하려고 노력하기 때문입니다. 소프트웨어를 테스트하고 피드백을 제공할 사람들을 확보하는 것은 귀중한 리소스입니다. 필요한 프로그래밍 기술을 가진 사람들은 기꺼이 코드를 제공할 의향이 있지만 시간을 들이기 전에 자신의 기여를 환영한다는 일종의 표시를 원합니다.

분명히, 단순히 문제에 대해 불평하고 수정을 요구하는 댓글은 유용하지 않지만 대다수는 그렇게 하지 않으며 "오픈 소스입니다. 그냥 포크하세요"와 같은 댓글도 똑같이 쓸모가 없습니다.

@shin- "--build"가 구현된 이유는 무엇입니까? docker-compose build && docker-compose up과 다른가요? --build(추가됨)와 --pull(중복된 것으로 간주됨) 간의 철학적 차이점을 이해하려고 합니다. 사고 과정을 이해하면 일이 어떻게 작동하는지 기억하는 데 도움이 될 수 있습니다. 그리고 문제가 열리면 기꺼이 PR을 제출하겠습니다. @everybodyelse... 정말 "오픈 소스 정신"이 마음에 들지 않으면 포크합니까? 나는 오픈소스의 정신이 "만약 당신이 무언가를 좋아하지 않는다면 당신이) 당신이 있는 곳이라면 요구사항에 기여하도록 돕고, b) 당신이 할 수 있다면 코드에 기여하도록 도와주는 것"이고 당신의 요구사항이 매우 중요할 때만 포크한다고 생각했습니다. 분명히 당신만이 혜택을 볼 수 있습니다. 즉, 공유할 때 가장 큰 혜택을 볼 수 있다고 생각했지만 여기서 교육을 받게 되어 기쁩니다.

2년 동안 주장하고 무시할 만한 타당한 이유와 이를 실제로 구현하기 위한 막대한 커뮤니티 지원을 제공한 후, 저는 @shin-이 원하지 않기 때문에 이 기능이 되지 않을 것이라고 말하고 싶습니다. 계속 주장할 이유가 없습니다.

한 가지 이유가 있습니다. 하나의 pull이 실패하고 그것을 하지 않을 타당한 이유가 없는 경우 docker는 이미지를 새로 고치지 않습니다.

docker compose에서 kubernetes 이미지 풀 정책을 찾고 있는데 "풀"을 사용할 수 있다면 좋을 것입니다.

@shin- 그만 유치해. 이 기능을 구현해야 하는 많은 이유가 언급되었습니다. 최소한 PR에 개방적이어야 합니다...

당신은 나와 동의하지 않을 수 있지만, 나는 당신이 ad hominems, @Wenzil에 의지하는 것에 실망했습니다. 우리 커뮤니티는 일반적으로 더 높은 수준을 유지합니다.

@shin- 저희 커뮤니티는 말씀하신 이유 때문에 대부분 같은 생각을 하고 있습니다. @Wenzil 은 솔직하게
내가 아는 많은 사람들은 귀찮게 하지 않고 docker-compose가 사용자에게 다가가도록 설득하는 것을 포기했습니다.

설명된 매우 타당한 이유에 대해 많은 사람들이 @shin-에 동의하지 않습니다. 최소한 이것은 서비스 선언이어야 합니다. bash 명령을 함께 묶는 것은 프로그래밍 방식 배포에 특히 좋은 솔루션이 아닙니다.

내가 아는 많은 사람들은 귀찮게 하지 않고 docker-compose가 사용자에게 다가가도록 설득하는 것을 포기했습니다.

이것. 그리고 그것은 단지 docker-compose가 아닙니다. Docker-stack, docker-machine 및 docker-cli는 모두 유사합니다.

https://github.com/docker/compose/issues/6316#issuecomment -438564025

이것이 계속 탈선하면서 잠금. https://github.com/docker/cli/pull/1498 의 운명에 따라 재평가 하겠습니다.

업데이트로 서비스 정의에 pull_policy 매개변수를 추가하는 방법을 내부적으로 검토하기로 결정했습니다. 우리는 여전히 옵션과 정확한 구문이 무엇인지 파악해야 하지만 이 스레드에서 표현된 요구 사항을 충족할 수 있기를 바랍니다.