Compose: version3의 Depends_on

depends_on 은 (는) v3에 여전히 존재하지만 상태 검사 종속성 (결과적으로 확장 구문)은 이식되지 않습니다.

HTH

그러나 나는 docker-compose v3을 작성했으며 swarm에 배포하려고 시도하지만 컨테이너가 시작 해야하는 방식으로 시작되지 않기 때문에 dependent_on이 작동하지 않습니다.

docker-compose 또는 docker stack deploy 있습니까?

도커 스택 배포를 사용하고 있습니다.
7 대의 컴퓨터에 배포하려고합니다.

상태 확인 종속성과 같은 것을 달성하기 위해 docker-compose v3에서 동등한 것은 무엇입니까? v3에서 해당 기능을 삭제하려는 경우 기본적으로 사용하지 않아야합니다. 또는 적어도 이에 대한 마이그레이션 경로가 있어야합니다.

새로운 docker-compose v2.1에 도입 한 다음 v3 용으로 삭제하려는 의도는 무엇입니까? 현재 응용 프로그램에 대해 다른 작성 파일을 설정하고 있지만 다음 버전에서 삭제되는 기능을 사용하고 싶지 않아 사용이 새로운 도커 작성 파일 버전으로 업데이트되는 것을 방지하고 싶습니다.

현재로서는 새로운 depends_on 구문이 v3로 이식되지 않을 것이라고 가정해야합니다. 현재로서는 그렇게 할 계획이 없기 때문입니다.

많은 사람들이 원하는 답이 아니라는 것을 알고 있지만 최소한 명확성을 제공하는 데 도움이되기를 바랍니다.

계획에없는 이유를 물어볼 수 있습니까? 그렇게하는 것이 매우 유용 할 것이라고 생각합니다.

명확성을 제공하지만 설명하지는 않습니다. 이유를 자세히 설명해 주시겠습니까? 그리고 대안 (존재한다면)?
Depends_on은 컨테이너 내부에서 처리하는 것과는 반대로 서비스에 의존하는 정말 쉬운 방법을 제공합니다 (즉, 대기 스크립트로 타사 이미지를 래핑하고 유지해야 함을 의미 할 수 있음).

@ shin- 왜 2.1에서 구현 했습니까? 사람들이 그것을 사용하고 그것에 의존하게되면 그들은 결코 업그레이드 할 수 없을 것입니다. 존경하는 마음으로, 그것은 당신들 편에서 매우 가난한 계획처럼 보입니다.

그래서 v3의 지원 depends_on 구문은 무엇인가? https://docs.docker.com/compose/compose-file/#version -3은 depends_on을 언급하지 않으며 docker-compose v1.10을 사용하여 애플리케이션을 배포 할 때 v2 또는 v2.1 dependent_on 버전이 작동하지 않습니다. 나 v3 작성 파일 ...

안녕하세요.

계획에없는 이유를 물어볼 수 있습니까? 그렇게하는 것이 매우 유용 할 것이라고 생각합니다.

@hsmade

이유를 자세히 설명해 주시겠습니까? 그리고 대안 (존재한다면)?

https://github.com/docker/docker/issues/30404#issuecomment -274825244에서

depends_on 는 docker stack deploy 와 함께 사용하면 작동하지 않습니다. Swarm 모드 서비스는 실패 할 때 다시 시작되므로 시작을 지연 할 이유가 없습니다. 몇 번 실패하더라도 결국 회복 될 것입니다.

뿡뿡

그렇다면 v3에 대해 지원되는 dependent_on 구문은 무엇입니까?

docker-compose 를 사용하는 경우 v3에 지원되는 구문은 목록 구문입니다 (2.0에 사용되는 구문과 유사). docker stack deploy 경우 종속성이 적용되지 않습니다 (위의 근거 참조).

버전 3 형식은 외부 docker-compose 도구에서 통합 된 docker stack 솔루션으로 이동하는 첫 번째 단계입니다. 현재 구현에는 작업중인 단점이 있습니다. docker-compose 의 버전 3 형식 지원은 이러한 전환을 돕기위한 것입니다. fig / Compose가 처음 도입 된 이후 Docker에서 많은 것들이 변경되고 개선되었으며, 이는 의미가있는 많은 것들이 이제 쓸모 없게되었다는 것을 의미합니다. docker stack 는 새로운 개념을 사용하는 새로운 시작으로 volumes_from 에서 depends_on 까지 다루기 힘든 구문과 개념을 제거합니다.
이러한 변경 사항 중 일부에 대해 특별한 우려 사항이있는 경우 적극적으로 반복되는 docker / docker repo
아직 Docker 서비스 및 docker stack 로 전환 할 준비가되지 않은 경우 v2 형식을 계속 사용해도됩니다. 프로젝트가 미래의 어느 시점에서 일몰이 될 것이라고 가정하는 것이 합리적이지만 미리 발표 될 것입니다. 그 후에도 코드는 계속 사용 가능하고 오픈 소스로 유지됩니다.

감사. 이제 말이됩니다.

Swarm 모드 서비스는 실패 할 때 다시 시작되므로 시작을 지연 할 이유가 없습니다. 몇 번 실패하더라도 결국 회복 될 것입니다.

IMHO 이것은 좋은 접근 방식이 아닙니다. 모든 서비스가 의존하는 다른 서비스가 준비되지 않았 음을 제대로 감지 할 수있는 것은 아닙니다. 여러 번 시도한 다음 실패하므로 컨테이너가 나중에 죽을 수 있습니다. 우리는 여전히별로 좋지 않은 진입 점 래퍼 스크립트를 도입해야합니다. 건강 체크 의존성은 매우 좋았지 만 스웜 모드는 지원하지 않습니다.

Swarm 모드 서비스는 실패 할 때 다시 시작되므로 시작을 지연 할 이유가 없습니다. 몇 번 실패하더라도 결국 회복 될 것입니다.

안녕 모두들!
예를 들어 작업을 매우 빠르게 실행하고 완료하는 서비스가있는 경우 (설계에 따라 한 번만 실행되어야 함) 반복해서 다시 시작된다는 의미입니까?

@ Marvel77 기본적으로 예,하지만 deploy.restart_policy 섹션을 사용하여 해당 동작을 재정의 할 수 있습니다 : https://docs.docker.com/compose/compose-file/#restartpolicy

@ shin- 정말 감사합니다!

@mustafaakin 실제로 가장 좋은 방법은 (IMHO) 당신이 의존하는 서비스에 대한 내결함성 연결을 갖는 것입니다. 예를 들어 데이터베이스를 사용하는 경우 응답 할 때까지 시작을 지연 할 수 있습니다. 그러나 데이터베이스 재시작을 어떻게 처리합니까? 앱이이 문제를 복구 할 수 있어야하며 'depend_on'에도 의존 할 필요가 없습니다.
어떤 의미에서 사용 중단은 좋은 것입니다. 이러한 편의는 우리를 게으르게 만듭니다.

@hsmade 그러나 거의 모든 init (upstart, systemd)은 관계에 따라 다릅니다. 그래서 게으르다는 것이 아니라 말이되는 것입니다. SSHD 데몬은 네트워크 장치가 준비 될 때까지 시작되지 않습니다. 내가 가지고있는 모든 시스템을 제어 할 수 없습니다. 예, 내 시스템을 내결함성으로 만들 수 있습니다. 그러나 A가 B에 의존한다고 가정합니다. A는 초기화하는 데 시간이 걸리지 만 결정적이지 않습니다. 그렇다면 B에 다시 시작 정책을 어떻게 작성할 수 있습니까? 영원히 다시 시작 하시겠습니까? 당신이 그것을 원하지 않는다면?

이것은 Compose보다 더 큰 문제입니다. Compose는 그냥 시작합니다. Swarm이 그들을 운영하게 만드는 것이므로 Swarm이 건강 관계에 대한 이러한 의존성을 처리해야한다고 생각합니다.

@mustafaakin 컨테이너화 된 환경에서 실행중인 마이크로 서비스를 클래식 초기화 시스템과 비교할 수 없다고 생각합니다. 그것은 정말로 말이되지 않습니다. 마이크로 서비스의 아이디어는 자체 포함 된 최소 엔티티라는 것입니다. 그들은 API 등에 대한 매우 명확한 정의를 가지고 있습니다. 그들은 외부 세계의 어떤 지위도 가정해서는 안됩니다. 예, 데이터베이스가 필요하지만 아니요, 거기에 있다고 가정 할 수 없습니다. 내가 말했듯이, 시작에 대한 의존성이 있다는 것을 아는 것이 가장 적은 문제이며, 사라질 때 잘 처리하는 것이 더 중요하며 전자도 해결해야합니다.

그러나 다시, 이것들은 문제에 대한 나의 생각이며 나는 틀릴 수 있습니다.)

예, 마이크로 서비스에는 의미가 없지만 모든 것이 마이크로 서비스는 아닙니다. 저는 컨테이너에서 Hadoop을 실행합니다. Docker는 마이크로 서비스만을위한 것이 아닙니다. 내가 말했듯이, 내가 통제 할 수있는 환경에는 좋지만 내가 통제 할 수없는 것들에서는 서비스의 진입 점을 래핑해야합니다. healtcheck와 함께 dependent_on으로 해결되었습니다. Swarm에서도 사용하면 좋을 것 같습니다. 계속해서 다시 시작하는 것은 게으른 사람의 선택 일뿐입니다.

여러분,

"내결함성"과 "처음 초기화"에 대한 일종의 오해가 있다고 생각합니다.
접근 방식이 첫 번째 접근 방식에 대해 충분히 좋게 들리지만 후자는 진정한 고통이라는 데 동의하십시오.
나는 나 자신뿐만 아니라 일반적으로 서로에게 어느 정도 의존하기 때문에 일반적으로 특정 순서로 서비스를 시작해야한다고 생각합니다.

초기화 단계에서 계속해서 다시 시작하고 특정 시점에서 적절한 순서로 서비스가 시작될 때까지 기다리는 것은 악몽과도 같습니다. 더 나쁜 상황이 발생하면 시작 프로세스에 대한 "다운 타임"을 계획 할 수 없습니다. 더 나쁠뿐만 아니라 때로는 무언가를 변경해야하는 "유지 관리"시간이 있고 시스템이 실제로 시작하는 데 걸리는 시간을 아무도 예측할 수없는 경우가 있습니다. 다른 서비스가 계속해서 다시 시작되기 때문입니다. 다시 적절한 주문을 기다리고 있습니다.
나는 그것이 7 개의 컨테이너로 어떻게 될지보기 위해 노력했고 기다렸고 20 분 동안 _swarm_은 여전히 ​​그것을 알아 내지 못했고 전체 서비스는 여전히 다운되었습니다.
따라서 _ 초기 시작 _이 얼마나 오래 걸릴지 알 수 없기 때문에 전체 인프라를 복구하고 복원하는 데 얼마나 많은 시간이 소요 될지조차 말할 수 없습니다.
나에게 터무니없는 소리.

드물게 (완전히) 일어나야한다고하더라도 그런 예측 가능성 없이는 "프로덕션"에 들어갈 수 없다고 생각합니다.
하지만 그래도 여전히 발생한다면 바로 그 자리에있을 것이고 최대한 빨리 복원하라는 도전을 받게 될 것입니다. 그리고 바로 그 시점과 압력이 _ 시작하는 동안 컨테이너가 계속해서 다시 시작되기 때문에 컨테이너가 시작될 시간이 얼마나 될지 전혀 모릅니다 ._

@ozlatkov 이것은 실제로 여기가 아니라 도커 / 도커 문제 추적기에 게시되어야합니다.

@ shin- 감사합니다! 도커 / 도커 추적기로 옮겼습니다.

https://github.com/docker/docker/issues/31333

Docker 팀이 Docker Swarm이 사용된다고 가정하는 것이 정말 나쁘다고 생각합니다. Compose는 완전히 기능하는 독립 실행 형 도구입니다.

그러나 우리는 테스트 파이프 라인에서 Docker Compose를 많이 사용하고 있으며 이러한 기본적인 기능 제거 (실행 가능한 대안을 제공하지 않음)는 실제로 사용자에게 극적인 부정적인 영향을 미칩니다.

저는 현재 Compose 2.X에 영원히 머무르는 것을 포함하여 (이 기능에 크게 의존하기 때문에) 모든 종류의 해결 방법을 찾으려고 노력하는 팀원의 매우 추악한 PR을 검토하고 있습니다.

Docker는 많은 팀이 이미 의존하고있는 중요한 기능을 제거하여 더 어렵게 만드는 것이 아니라 우리가 목표를 달성하는 데 도움을주기위한 것입니다.

이 모든 것을 Docker Compose 3로 포팅하는 것을 다시 고려하십시오.

매우 감사.

100 번째 : 스웜 서비스를 사용하지 않으려는 경우 v3 형식을 사용할 이유가 없습니다.

팀이 compose를 독립형 개발 도구로 사용하는 사람들을 위해 2.X 형식을 지원하기로 약속하고 있다는 의미입니까?

정확히 제 질문입니다. Compose 팀은 v2 형식을 영원히 지원하기 위해 최선을 다하고 있습니까?

v2 형식이 언제든지 지원 중단 될 예정이면 Docker Compose에서 표준화 할 수 없습니다.

나는 이것이 모든 컨테이너를 init container 패턴으로 강제하고 도커 재시작 정책을 제거하며 시작 순서에 대한 해키 접근 방식을 만드는 것처럼 느낍니다. > = v3 of compose가 스택 및 애플리케이션 번들 생성에 집중하기 위해이 방향으로 이동한다고 가정해야합니까? 그리고 그것이 맞다면 도커 스택에서 시작 순서를 유지하는 방법을 알려주시겠습니까? wait-for-it.sh 또는 dockerize 접근 방식이 있습니까?

스택에 대한 docker-compose.yml의 선언적 대응은 무엇입니까?

안녕하세요, 도커 스택을 사용하고 도커 작성을 제거하려는 경우 가장 좋은 방법은 무엇입니까?

이것이 해결책 인 것 같지만 컨테이너를 초기화하기 위해 일종의 해키 스크립트를 사용하는 것은 좋은 습관처럼 들리지 않습니다. 그렇습니까?

감사.

@mustafaakin 비추천 해 주셔서 감사합니다! 매우 유용한 ❤️

@VinceOPS "모범 사례"에 대해 잘 모르겠지만 상태 검사와 restart: always 사용해 왔으므로 작동 할 때까지 순환합니다 ¯ \ _ (ツ) _ / ¯

@hutchic 그러나 위의 대화에서 언급했듯이 종료 날짜, 일종의 순환 실패시 재시작을 가질 수 없습니다.

Docker 팀이 버전 3에서이 기능을 제거하고 추가를 거부하는 이유는 무엇입니까?

@ tianhao-au는 https://github.com/moby/moby/issues/31333 (및 https://github.com/moby/moby/issues/31333#issuecomment-409143581)에서 토론을 참조하십시오.

작성을 위해 https://github.com/moby/moby/issues/31333#issuecomment -333265696에 제안을 남겼습니다 ( x-depends_on )

이 기능 변경은 말 그대로 더 이상 docker-compose를 사용하지 않는 이유입니다. 프로덕션에서 docker를 사용하고 dev 환경에서 로컬로 docker-compose를 사용하는 경우 이제 Docker 컨테이너가 프로덕션과 개발에서 근본적으로 다르게 동작하도록해야합니다. 프로덕션에서는 배포의 상태와 순서를 보장하기 위해 오케스트레이션 시스템에 의존합니다. 개발 영역에서는 docker-compose가 오케스트레이션을 수행했습니다. 이제 저는 시스템을 조율하기 위해 사물의 상태를 확인하기 위해 여러 스크립트를 작성하고 있습니다. 내가 그렇게 할 거라면 내 도커를 관리하고 그것을 끝내기 위해 golang을 작성하지 않는 이유는 무엇입니까? 조금 부끄러워서 떨어졌습니다. 내 2p 만

미래에 대비 한 최신 도커 작성 버전을 사용하려고 시도하고이 문제를 발견했습니다. 이거 슬프네.