@jmmills "docker-compose scale worker=5"와 같은 컨테이너를 시작할 수 없으며 해당 서비스는 5로 시작합니까?

@aanm 예, 하지만 기능은 서비스 정의에서 기본으로 미러링되어야 한다고 생각합니다. 항상 실행해야 하는 최소한의 작업자 집합이 있고 이를 기본값으로 명확하게 선언하고 싶을 수도 있습니다.

@ @aanm docker-compose up 이 scale 매개변수를 고려해야 한다고 생각하십니까? 내가 볼 수있는 유일한 문제는 기본 Docker / Docker API 개념과 호환 되지 않지만 Docker Compose에 매우 특정한 매개 변수를 선언적 구성에 도입한다는 것입니다.

우리가 앞으로 이것을 하게 된다면; 다음과 같이 제안합니다.

#!yaml worker: build: rqworker $scale: 5 links: - redis command: rqworker -u tcp://redis

여기서 $<parameter> 는 Docker Compose 특정 항목을 나타냅니다.

우리는 scale 가 YAML에 속하는지 여부에 대해 왔다 갔다 했습니다. 이전에 추가하라는 PR이 있었습니다(#630). 나는 여전히 대부분의 사람들이 스케일 숫자를 설정에 넣으면 안 된다고 생각합니다. 왜냐하면 그렇게 하면 이식성이 떨어지기 때문입니다. 하지만 그렇게 하는 사용 사례를 이해합니다.

이제 우리는 extends Compose 파일을 보강하는 기본적인 방법을 얻었으므로(곧 더 나은 파일 - #1380, #758) https://github.com/docker/compose 에서 제기한 우려

일반적으로 시작하고 싶지 않은 테스트 관련 서비스에 대해 yml에 scale=0 를 설정하고 싶습니다. docker-compose run 또는 명시적 scale 를 사용하여 해당 서비스를 명시적으로 만들고 싶습니다.

@jamshid 나는 종종 환경을 설정하지만 기본적으로 실행되지 않는 정의를 원했습니다. 나는 docker run 를 통해 단위 테스트를 실행하는 기본 이미지(0/no-op 척도도 도움이 됨)를 생성하고 내 컨테이너 구성이 기본 이미지.

이와 같은 것은 개발 구성에 꽤 유용해 보입니다.

myproject:
    build: .
    command: nosetests
    scale: 0
    links:
       - redis
redis:
    image: redis
apiserver:
    image: myproject
    command: plackup
    links:
       - redis
workerserver:
    image: myproject
    command: rqworker
    links:
        - redis

@jamshid @jmmills 서비스당 YAML 파일의 enabled 매개변수/키는 어떻습니까? 서비스를 비활성화/활성화할 수 있습니까?

@prolog "규모" 매개변수가 두 가지 요구 사항을 모두 해결할 때 왜 그렇게 합니까?
실행 중인 프로세스/컨테이너를 클래스의 인스턴스로 상상하고 싶다면 instances 이름을 지정할 수도 있습니다.

@jmmills 현재 docker-compose 그대로 사용하지 않는 유스 케이스에 대한 _solution_을 찾으려고 합니다. 저는 scale=0 가 적절하지 않다고 생각하는 경향이 있으며 scale=X 가 Compose 자체의 일부여야 하는지에 대해 두 가지 생각이 있습니다.

내 생각에 규모(또는 사본 수)는 서비스 구성의 일부이므로 작성에 포함되어야 합니다.

scale=0 또는 disabled 키가 있는 것 같습니다.

:+1: 인스턴스에 대한 기본 scale 크기를 설정하는 기능이 있습니다. 그리고 저는 스케일이 입력되면 단순히 스케일을 0으로 설정하기 때문에 disabled 키가 필요하지 않다는 데 동의합니다.

+1

또한 또 다른 사용 사례: 컨테이너 수를 확장하고 싶지만 모든 서비스를 배경으로 하고 싶지 않거나 다른 터미널(또는 프로세스)로 건너뛰고 내 스케일 번호를 설정해야 하는 경우...
예:

$ docker-compose up && docker scale thing=4

up이 종료되지 않기 때문에 작동하지 않습니다.
그러나 내 구성 파일이 내 컨테이너의 크기를 설정하면 ...

$ docker-compose up

DWIM이 됩니다.

나는 이것을 정말로 좋아하는지 확신하지 못한다. 갑자기 up 는 두 가지 기능을 사용합니다.

• scale 매개변수가 없는 컨테이너를 불러옵니다.
• scale=0 가 있는 모든 컨테이너를 가져옵니다.

우리는 이제 "up" 명령을 실제로 남용하고 있습니다. "Scale"은 이제 다음 두 가지 작업을 수행한다는 점에서 새로운 의미를 갖습니다.

• 컨테이너 확장/축소
• ` scale=0 통해 컨테이너/서비스 비활성화

scale=0 가 있는 컨테이너를 불러오는 이유는 무엇입니까?
Build 는 scale=0 를 사용하여 이미지를 빌드하므로 기본 이미지 요구 사항을 용이하게 합니다.

제가 _틀릴 수도 있습니다_ 하지만 귀하의 마지막 댓글을 읽는 것은 일종의 암시였습니다. :)

자세히 설명하겠습니다.

base_thing:
    build: .
    scale: 0

thing:
    image: base_thing
    # scale: 1 implied by default

workers_for_thing:
    image: some_other_image
    scale: 4
    links:
      - thing

test_harness:
    image: base_thing
    command: nosetests --where=my_test_code_dir --all-modules
    scale: 0

이제 예상되는 동작: docker-compose build 는 "빌드"로 모든 컨테이너를 빌드하고(빌드 시 외부 이미지를 작성합니까? 기억나지 않습니까?) docker-compose up 는 양수 스케일(기본값은 1), docker-compose run test_harness 는 필요한 경우 "base_thing"을 빌드하고 내 하나의 명령을 실행합니다. 실제적 지식? :)

편집: docker-compose up 는 1 "thing" 및 4 "workers_for_thing"을 실행합니다.

괜찮 감사; 귀하의 예는 scale=0 의 의도에 대해 좀 더 이해하고 조금 더 명확합니다.

docker-compose up / run 이미지를 "끌어옵니다"라고 생각합니다.

테스트, 생산, qa 등을 위해 인스턴스 수(규모)를 나타내는 레시피를 생성해야 합니다.

scale=X 대해 +1 이것은 매우 도움이 될 것입니다.
구성 설명 및 예상 결과가 포함된 @jmmills 주석의 경우 +1입니다.

야! scale=x . 컨테이너 세트를 초기화하면 클러스터 구성을 설정할 때 잠재적인 경쟁 조건을 식별하는 데 확실히 도움이 됩니다.

+1 scale=x (포함 scale=0 초기에 비활성화 서비스에 docker-compose up )

scale=x 대해 +1

x 는 NaN입니다. 대신 -1 를 제안하겠습니다.

스케일 = x의 경우 +1.

+1

+1

+1로 중지하는 것은 어떻습니까?

+1'은 기능에 대한 관심 수준을 확인하는 데 유용합니다.

@shofetim 더 나은 방법을 알고 있습니다. 문제의 기능을 구현하고 풀 리퀘스트를 보내는 것입니다...

+1ing은 제안된 솔루션에 대한 사람들의 동의를 확인할 수 있는 좋은 방법이기도 합니다. github 전체에서 꽤 일반적인 동작입니다. 문제가 있는 경우 알림에서 구독 취소 버튼을 클릭하면 알림이 꺼집니다.

뭐, 이런 사람들인 것 같습니다. 작성 백로그에 비슷한 항목이 있습니다(그림에서 남음). 언젠가는 이에 대해 언급한 적이 있을 것입니다. 이따 저녁에 해봐야겠습니다.
저는 이번 주 대부분이 PuppetCon에 있으므로 해킹 시간을 가질 수 있기를 바랍니다. 이 글을 쓸 수 있는지 알아보겠습니다.

다음은 "scale=0" 사용 사례에 대한 해결 방법입니다.

app:
  build: .
  environment:
    - DATABASE_URL=postgres://user:password<strong i="6">@host</strong>:5432/dbname
  command: sleep 999999999999

app_web:
  extends:
    service: app
  ports:
    - "3000:3000"
  command:
    # intentionally blank to use Dockerfile's default RUN command

app_worker:
  extends:
    service: app
  command:
    rake jobs:work

@wkonkel 네, 과거에 비슷한 일을 한 적이 있습니다.

저는 현재 compose 코드베이스에 익숙해지기 위해 노력하고 있습니다. 모든 것이 compose에 대한 위치를 알게 되면 scale 구성 매개변수에 대한 PR을 해킹할 것입니다.
너무 어려울 것 같지는 않습니다. cli 인터페이스의 백엔드인 프로젝트에 scale 메서드가 있으므로 실제로 해야 할 일은 "스케일"을 추가하는 것입니다. 필드 스키마, 컨테이너 생성 후 호출하기 위해 존재하는지 확인하고... 0으로 설정된 경우 컨테이너를 실행하지 않는지 확인하십시오.

실제로 이것에 대한 아주 오래된 PR이 열려 있습니다: #630.

문제는 규모가 운영상의 문제이고 애플리케이션 정의의 일부가 아니므로 작성 파일과 실제로 맞지 않는다는 것입니다.

기본 스케일 수준에 대한 구성을 지원하면 좋겠지만 작성 파일이 적합한 위치가 아니라고 생각합니다.

scale: 0 는 이미 #1754로 해결되어야 합니다. "no-op" 컨테이너는 즉시 종료되는 명령(echo, true 등)을 가질 수 있습니다. scale: 0 를 원하는 경우는 일반적으로 데이터 볼륨 컨테이너 또는 "임시/관리 작업"의 두 가지 중 하나입니다.

볼륨에 새로운 API 엔드포인트가 추가되기 때문에 머지 않아 데이터 볼륨 컨테이너가 필요하지 않을 것이며 컨테이너 없이 볼륨을 정의할 수 있게 될 것입니다.

관리 작업은 #2051로 더 잘 처리됩니다. 핵심 docker-compose.yml admin.yml 을 확장하고 각각의 정의를 혼동하지 않고 관리 작업을 "핵심 구성"에 연결할 수 있도록

이 두 가지 변경 사항은 모두 현재 마스터 상태이며 1.5.0 릴리스(곧 모퉁이에 있음)에서 사용할 수 있습니다.

따라서 기본적으로 서비스를 > 1로 확장하려는 경우만 남습니다. 이미 이와 같은 것을 스크립팅하는 것은 매우 쉽지만 구성 파일에 넣을 수 있다는 것은 여전히 ​​좋은 일입니다. 나는 우리가 #745에서 별도의 설정에 대한 아이디어를 탐구할 것이라고 생각합니다. 이 새로운 구성은 애플리케이션 정의(프로젝트 이름, 기본 네트워크 이름, 기본 규모 등)의 일부가 아닌 것들을 위한 좋은 장소가 될 것이라고 생각합니다.

정중하게 저는 규모가 운영상의 문제일 뿐이라는 데 동의하지 않습니다. 응용 프로그램은 실행 중인 서비스의 최소 개수에 신경을 쓸 수 있습니다.
no-op 컨테이너의 경우 해당 컨테이너의 목적이 다른 컨테이너가 image 필드에 사용하는 기본 이미지를 빌드하도록 트리거하는 경우 실제로 컨테이너를 실행하는 것이 번거롭게 느껴집니다.

응용 프로그램은 실행 중인 서비스의 최소 개수에 신경을 쓸 수 있습니다.

이 경우의 예를 들어 주시겠습니까?

no-op 컨테이너에 관해서는 해당 컨테이너의 목적이 다른 컨테이너가 이미지 필드에 사용하는 기본 이미지를 빌드하도록 트리거하는 경우 실제로 컨테이너를 실행하는 것이 번거롭게 느껴집니다.

기본 이미지가 동일한 빌드의 일부여야 하는 이유가 있습니까? 내가 #1455에서 언급했듯이 compose는 기본적으로 "도커 빌드" 도구가 아닙니다. 목표는 런타임에 컨테이너 구성을 제공하는 것입니다. 가능한 모든 빌드 시나리오를 지원하려고 하면 작성 범위가 크게 늘어나고 컨테이너 작성에서 초점이 멀어집니다. 이미지 구축을 중심으로 설계된 도구조차도 이러한 요청을 모두 지원하기는 어려울 것입니다. 더 나은 방향은 작성 복잡성을 최대한 유지하고 사용자가 docker-compose build 대신 적절한 빌드 도구를 교체할 수 있도록 하는 것입니다.

내가 관심 있는 사용 사례는 scale=0입니다(아마도 abstract=true가 더 나은 설명자가 될 것입니다). 다른 명령 간에 이미지와 환경 변수를 공유하고 싶습니다. 특히 동일한 코드와 동일한 환경 변수를 사용하여 하나의 웹 서버를 실행하고 하나의 백그라운드 작업 서버를 실행하고 싶습니다.

@wkonkel 귀하의 예를 사용하면 이것이 효과가 있을까요?

app_web:
  build: .
  ports:
    - "3000:3000"
  environment:
    - DATABASE_URL=postgres://user:password<strong i="7">@host</strong>:5432/dbname

app_worker:
  extends:
    service: app_web
  command: rake jobs:work
  ports: []

당신은 어떤 조합으로 조작 추상적 인 서비스를 가지고하는 무역 command 에 무 조작 오버라이드없는 추상적에 대한 ports . 그 소리가 맞나요?

1988은 추상 서비스와 관련이 있습니다.

@dnephin 예, 제 경우에는 작동합니다.

사실, 나는 그것을 다시 가져옵니다 ... 방금 docker-compose-1.4.2로 시도했는데 "ports: []"가 부모를 무시하지 않으므로 app_worker가 "포트가 이미 할당되었습니다. ".

@dnephin 스레드에 더 나은 설명이 있지만 여기에서 설명하려고 합니다.

가장 먼저 떠오르는 것은 동일한 코드를 실행하는 별도의 컨테이너가 기본 애플리케이션 구성이 동시성을 위해 최소 수의 작업자를 원하는 상위->포크()->하위 풀 유형의 서비스처럼 모델링될 수 있는 작업 시스템입니다.

이에 대한 영감은 내 Python 패키지(작업자 코드)가 포함된 기본 이미지를 공유하지만 각 대기열에 대해 여러 인스턴스가 실행되는 다른 대기열에 연결된 RQ 작업자를 사용하는 앱에서 나왔습니다. 장기 실행 작업 때문에 최소 동시성 가용성은 애플리케이션의 요구 사항이었습니다.

나는 그냥 no-op 명령을 사용하는 것이 나머지 애플리케이션 스택과 동일한 방식으로 빌드된 공유 기본 이미지를 얻기 위한 리소스 낭비처럼 보인다고 생각합니다. 기본 이미지에 대해서만 while/sleep 루프가 발생합니다. 이는 멋진 해결 방법이지만 이를 수행하는 직관적인 방법은 아닌 것 같습니다. 말할 것도 없이 프로세스 트리에 런타임 기능이 없는 항목이 남습니다.

docker-compose가 이미지 빌드 관계를 코딩하는 도메인으로 실제로 교차하지 않는 경우 빌드 옵션이 없어져야 하고 기본 이미지를 빌드하기 위해 빌드 대상을 정의할 수 있도록 다른 빌드 정의 시스템을 만들어야 합니다. , 몇 가지 수정된 아티팩트/구성과 함께 해당 기반을 올바른 순서로 사용하는 다른 이미지는 무엇입니까?

아니면 제가 너무 독단적이어서 셸 스크립트에서 docker compose 명령을 래핑하여 규모로 서비스를 시작하고 모든 이미지 빌드를 종속성이 있는 make 대상으로 정의해야 합니다.

나는 그냥 no-op 명령을 사용하는 것이 나머지 애플리케이션 스택과 동일한 방식으로 빌드된 공유 기본 이미지를 얻기 위한 리소스 낭비처럼 보인다고 생각합니다.

#1754(다음 릴리스에서)를 사용하면 더 이상 필요하지 않습니다. 서비스가 종료될 수 있으며 나머지 서비스는 중지되지 않습니다. 따라서 베이스를 종료하고 걱정하지 않아도 됩니다.

@dnephin Cool, 그러면 기본/중간 컨테이너에 link 를 제공하여 먼저 빌드되도록 하시겠습니까?

@dnephin : docker compose up 해당하는 CI 러너가 있습니다. 내 테스트 환경이 여러 버전의 서비스(예: 규모)로 실행되기를 원합니다. 전체 구성 블록을 복사할 수는 있지만 이를 반복해야 합니다. 이 경우 "단순한 운영상의 문제"가 아니라 현재 작성 파일에 완전히 설명되어 있는 클러스터된 애플리케이션을 개발하는 동안 개발 환경에 필요한 것입니다. 현재로서는 대역 외 규모 구성이 있어야 하고 어떻게든 docker-compose scale 호출해야 할 것입니다. 하지만 이것은 이상적이지 않고 실패와 경주에 대한 추가 기회를 제공합니다.

프로덕션 사례에서는 최소한의 규모로 서비스에 별표를 표시할 수 있습니다. 예를 들어 한 클러스터에서 다른 클러스터로 마이그레이션하고 있으며 예제의 단순성을 위해 마이그레이션의 일부 어려운 부분을 복사 데이터로 유지하도록 합시다. 그리고 처음부터 일부 트래픽을 처리하기 시작해야 하므로 웹을 말할 수 있는 일부 서비스의 적어도 (n) 인스턴스를 docker-compose up으로 배포해야 합니다.

구성 파일의 서비스에서 규모를 조정하면 실제로 이를 처리할 수 있습니다. 사용 사례가 실제로 시작 지점에 하나가 아니라 실행 중인 일부 서비스 인스턴스가 적어도 (n)개 있어야 한다는 요구 사항을 노출하는 경우 사용성 사용 사례이기도 합니다.

내 관점에서 스케일은 실제로 토폴로지 및 구성의 정의 매개변수입니다.

@dnephin

이 경우의 예를 들어 주시겠습니까?

Consul, MariaDB Master-Master 또는 Swarm의 기타 분산 앱은 클러스터에 최소 3개의 노드가 있어야 안정적입니다. 구성 파일에서 사용할 수 있는 서비스 수에 대한 사용 사례가 분명히 있습니다. 왜 그렇게 반대하는지 이해가 되지 않습니다. 큰 :+1: 여기에서 나에게서.

나는 scale을 설정하는 방식에 반대하는 것이 아니라, compose 파일과 독립적으로 변하는 상태이기 때문에 그것이 compose 파일에 속한다고 생각하지 않는다.

구성 파일에 일부 규모 구성을 추가한다고 가정하는 이 예를 살펴보겠습니다.

1. 서비스에 대한 초기 척도를 3으로 설정했습니다.
2. docker-compose up -d 하면 서비스가 3으로 확장됩니다.
3. docker-compose scale service=4
4. docker-compose up -d 약간의 변경을 가하고 재배포합니다. 어떻게 됩니까? 다시 3으로 축소되나요? 이제 규모를 완전히 무시합니까?

이러한 시나리오 중 어느 것도 좋지 않거나 적절하지 않은 것처럼 들리며 이는 인스턴스 실패를 무시하는 사소한 예일 뿐입니다(이로 인해 더 복잡해짐).

그것이 작성 파일에 추가된다면 충돌하지 않도록 scale 명령을 제거하고 싶습니다.

귀하가 제공하는 예는 운영 요구 사항의 예입니다. 애플리케이션을 실행하기 위해 여러 마스터가 필요하지 않으며 서비스의 안정성(운영)을 위해 필요합니다. 그리고 scale db=x 를 사용하여 여전히 이를 수행할 수 있습니다.

@dnephin이 위에 제공한 예를 사용하여:

먼저 scale 명령도 순진한 명령이라고 생각합니다. 서비스를 확장 또는 축소할지 여부를 알 수 없기 때문에 얼마나 많은 서비스가 수행하는지 말함으로써 확장 또는 축소의 의도를 설명하는 두 개의 diff 명령이 있습니다. 각각 생성하거나 제거하는 것이 훨씬 좋습니다.

@dnephin 이 제기한 질문에 대한 대답은 수정 전만큼 많은 서비스/컨테이너가 실행될 것으로 예상한다는 것입니다.

Compose는 서비스/컨테이너를 모르거나 모니터링하지 못하는 상태 비저장 도구입니다. docker api를 사용하여 Ops가 문제가 있다고 생각하는 곳에서 오케스트레이션하도록 도와줍니다. 작성은 전체 오케스트레이션 서비스가 아닌 도움말 도구로 설계되었습니다. 이제 우리는 그 엔진이 필요합니다. 제대로 실행되는 엔진이 있고 프로비저닝할 시스템이 있으며 모든 클러스터를 클러스터에 결합할 무리가 있지만 구성할 수 있는 유연성을 제공하는 실제 오케스트레이션 서비스/도구가 누출되었습니다. 배포된 서비스/컨테이너를 관리하기 위해 k8과 같은 작업을 수행합니다. 지금은 compose가 그것과 많이 비슷하지만 이 프로젝트의 미래가 아니라면 더 큰 것으로 진화하는 것이 가장 좋은 방법은 공식 개발자와 유지 관리자가 이에 대해 이야기하여 다른 것을 알아낼 수 있을 것입니다. 할 수 있는 도구입니다.

개인적으로 Compose는 훌륭한 도구이고 우리 모두에게 잘 알려져 있기 때문에 진화하는 것이 더 나을 것이라고 생각합니다.

docker-compose > docker compose 를) 보게 되어 기쁩니다.
나머지 도구는 확실하지 않지만 이를 위해 엔진과 상태 저장 통합이 있으면 정말 좋을 것입니다. 조금 주제를 벗어난 댓글 죄송합니다.

scale 명령을 제거하고 scale 옵션으로 교체하자는 제안을 위해 #2496을 만들었습니다(위의 게시물에서). 이 제안에 대한 피드백은 훌륭할 것입니다.

#2496 compose가 있는 @dnephin 은 쉽게 확장 또는 축소할 수 있는 기능을 잃습니다. 우리는 compose 파일을 재구성한 다음 우리가 필요한 것이 하나의 인스턴스를 축소 또는 확장할 때 다시 compose up을 실행해야 합니다. 저는 이것이 꽤 좋다고 생각합니다. 복잡한.

다시 한 번 우리는 이 모든 시나리오가 compose가 상태 비저장 도구라는 점과 서비스의 상태와 어떤 지점에서 서비스의 수를 제어할 수 없다는 점에서 비롯되었다는 점을 놓치고 있습니다.

새 제안서에서 언급한 시나리오는 상태 전체 서비스/도구 new-compose로 쉽게 해결할 수 있습니다.

+1

+1

+1

@dnephin 다음을 수행하면 동작이 동일하지 않습니다.

$ docker-compose up -d && docker-compose scale node=4 && docker-compose up -d

작성이 내부적으로 확장성을 유지하는 방법에 대한 문제가 더 크지 않습니까?

즉, "응용 프로그램 작성"이 상태 비저장입니다. 유일한 상태는 1) 작성 파일 및 2) 엔진에서 관리하는 도커 컨테이너 레이블입니다.

작성 파일은 작성이 아닌 사람에 의해서만 편집됩니다. 동일한 주석, 순서 및 구조로 yaml을 작성하려고 하면 엉망이 될 것입니다. 그것은 pyyaml에서 지원하지 않으며 어쨌든 우리가 정말로 하고 싶은 것이 아닙니다.

도커 엔진은 규모를 인식하지 못하므로 해당 상태를 저장할 수 없습니다. 훨씬 더 큰 아키텍처 변경으로 가능하지만 이는 이 문제의 범위를 다소 벗어납니다.

현재 우리의 옵션은 기본적으로 명령줄 옵션으로 크기를 유지하거나 작성 파일로 옮기는 것입니다. 하지만 #2496에서 설명했듯이 둘 모두를 사용하는 것은 혼란스럽고 잘못된 동작으로 이어진다고 생각합니다.

up && scale && up 실제로 지금 옳은 일을 하고 있습니다. up 는 모든 컨테이너를 다시 생성하고 구성에 scale 값이 없기 때문에 원하는 scale이 무엇인지 혼동하지 않습니다. scale 명령에 의해 이미 설정되었고 컨테이너 레이블로 추적되었습니다.

@dnephin 나는 당신이 말하는 것에 동의한다고 생각합니다. [나는 이 가정이 틀릴 수도 있습니다] 당신이 정말로 질문하고 있는 것은 _if_ 구성 요소의 인스턴스 수가 실제로 서비스 구성(컨테이너의 그룹 다른 구성 요소 컨테이너 실행). 현재 cli와 구성 정의(yaml) 사이에 패리티가 부족하다는 경고와 함께 해당 문제를 해결하고 있다고 말하고 싶습니다.

규모가 구성의 문제가 아니라고 책임 범위가 결정되면 cli 옵션으로 규모를 제거해야 하거나(아마도 많은 사용자를 화나게 함), 규모가 서비스 구성의 문제라고 판단되는 경우 N+1이 필요한 클러스터링된 인스턴스를 설명하기 위해 최소 인스턴스의 추가 지원과 함께 cli와 yaml 사이에 패리티가 있어야 합니다.

@jmmills에 동의 특히 데이터 컨테이너 클러스터를 실행할 때 가용성과 복제가 함께 진행되는 경우 최소 scale 는 애플리케이션의 일부입니다. 적절한 확장이 없으면 작동하지 않을 수도 있습니다.

+1

+1

+1

현재 다음과 같이 선언해야 합니다.

셀레늄 크롬1:
...
셀레늄 크롬2:
...

그것은 좋은 것입니다:
셀레늄 크롬:
규모: 2

+1

@caioquirino가 말한 것과 정확히

docker-compose up 는 다른 작업 없이 작업 환경을 가져와야 합니다. 여러 노드가 필요한 서비스를 불러오는 유일한 방법은 @caioquirino가 언급한 패턴을 사용하는 것입니다. 여기에서 DRY 위반을 무시하면 어떤 '서비스'를 확장해야 하는지 명확하지 않기 때문에 scale 명령을 사용하여 다른 노드를 추가하려고 하면 패턴이 잘못된 냄새가 납니다.

yml 파일의 크기를 조정하면 이 문제가 해결됩니다.

큰 +1, 처음에 스케일이 0으로 설정된 서비스를 정의하는 데 이것을 사용하고 싶습니다.

의 라인을 따라 ...

consul_bootstrap:
  build: ./consul
consul_master:
  build: ./consul_master
  scale: 0

아이디어는 동일한 docker-compose.yml을 사용하고 개발 환경에서 프로덕션으로 원활하게 전환할 수 있다는 것입니다. consul_master 인스턴스는 자동으로 뗏목에 합류하고 docker-compose scale consul_master=3 를 수행하여 정족수를 설정합니다. 이것은 꽤 멋질 것입니다.

@dnephin에 응답하려면...

구성 파일에 일부 규모 구성을 추가한다고 가정하는 이 예를 살펴보겠습니다.

1. 서비스에 대한 초기 척도를 3으로 설정했습니다.
2. docker-compose up -d를 실행하면 서비스가 3으로 확장됩니다.
3. docker-compose scale service=4를 실행합니다.
4. docker-compose up -d를 사용하여 일부 변경하고 재배포합니다. 어떻게 됩니까? 다시 3으로 축소되나요? 이제 규모를 완전히 무시합니까?
5. 사랑해
6. 괜찮은
7. 나는 여전히 당신과 함께
8. 지속적인 업데이트를 받는 기존 배포에 대해 규모의 연속성을 유지할 수 있도록 기존 배포와 새 배포 간에 약간의 차이가 있어야 한다고 생각합니다. 개별 배포에는 DOCKER_HOST 환경 등이 각 구성 요소의 규모, 이미지 ID 및 재배포 기록과 함께 포함됩니다. 지속적인 배포 또는 블루 그린 배포와 같은 업스택 메커니즘에 연결하기에 좋은 장소가 될 수 있습니까? 저는 약간 더 생산 준비가 된 워크플로를 상상하고 있으므로 다른 DOCKER_HOST에 연결하고 docker-compose up -d 를 수행한 다음 후크를 제공하여 업스택 도구가 CI 및 블루/그린 롤아웃과 같은 것을 관리할 수 있도록 합니다. DOCKER_COMPOSE_ENV={"testing " || "생산" || "개발자"}?

"하드코딩된" scale IMHO, 3에게 말하면 3개의 컨테이너로 시작해야 합니다.

"scale" 매개변수와 "scale" 명령에 대한 많은 혼동은 YAML 매개변수를 "initial_scale" 또는 "default_scale"로 명명함으로써 완화될 것이라고 생각합니다. 그것은 어떤 종류의 재정의가 없는 경우에 사용될 값일 뿐이라는 것을 분명히 합니다. 또한 (적어도 IMHO) 이 "initial_scale" 매개변수는 docker-compose가 서비스를 처음으로 불러올 때만 참조되고 서비스의 일부 인스턴스가 이미 실행 중인 상태에서 docker-compose를 다시 실행할 때는 참조하지 않는 것이 합리적입니다.

"initial_scale"에 대해 +1, docker 자체에는 이러한 매개변수가 없기 때문에 이 매개변수를 작성 관련 매개변수로 명시적으로 설명합니다.

블로그 게시물 https://blog.docker.com/2016/02/video-containers-as-a-service-caas/ 에서 "48.56" 비디오에서 흥미로운 일이 발생합니다. 스택 생성 지점에서 실제로 실행할 컨테이너 인스턴스 수를 설정할 수 있습니다.따라서 이 아이디어는 도커 팀에 새로운 것이 아니므로 다음 작성 릴리스에 포함되기를 바랍니다.

+1

+1

수백만 개의 문제 및 요청 scale/initial_count 등 .. 아직 계획되지 않았습니다.

다른 좋은 프로젝트를 보는 것은 슬프지만 사람들은 핑계를 찾고 새롭고 중복된 문제를 만들고 문제를 닫고 작업을 "수행"할 뿐입니다.

+1

+1

+1

+1

중지하십시오!
+1을 추가하지 마십시오!
문제를 구독하십시오!

+1 ( @피에르 죄송합니다)

+1 매우 중요합니다( @pierrre , 죄송합니다)

동의하지만 "+1"에 대한 100000개의 알림을 받고 싶지 않습니다!

/me fork docker compose 및 코드베이스 학습을 시작합니다.

위의 많은 유효한 점을 보면 구성 파일에 default/inital scale 매개변수가 있고 scale cli 명령이 두 가지를 모두 처리하는 것처럼 보입니다. 초기 확장 옵션을 지원하는 사용 사례를 추가하려면 쿼럼이 X개의 노드로 구성되고 그렇지 않으면 작동하지 않아야 하는 클러스터된 서비스를 고려하십시오(예: 3 이상). docker-compose 의 요점은 그러한 시스템에 대해 완전히 포함된 설명자를 갖는 것입니다.

내 사용 사례는 다음과 같습니다.

중복을 줄이기 위해 몇 가지 공통 설정으로 서비스를 확장했습니다. 그러나 기본 서비스가 생성되고(명시적으로 서비스 이름을 지정하지 않고 실행할 때) 수동으로 종료합니다. 기본 서비스의 초기 척도가 0이 되기를 바랍니다.

나는 일반적으로 동의합니다. 내 생각에 이 문제와 연결된/관련 문제는 약간 다른 문제로 요약됩니다. up 및 scale 궁극적으로 동일한 명령이 되기를 원합니다.

그들은 때때로 이미:

• docker-compose up service
• docker-compose scale service=1 .

그리고 scale 가 up 가 하는 모든 cli 옵션(예: --force-recreate )을 노출하거나 up 가 카운팅에 대해 알고 있다면 기본적으로 그렇게 될 것입니다.

이 문제에서 제안하는 것처럼 "초기 척도" 지시문이 docker-compose.yml 되면 up 는 계산하는 법을 배워야 합니다. 어느 시점에서 up 는 계산 구문 docker-compose up service=10 (yaml에 정의된 스케일을 덮어쓸 수 있음)을 지원하지 않아야 합니까?

다른 명령의 도메인이 될 수 있는 "초기 스케일"과 "스케일" 사이에는 구별이 있습니다. 그러나 up 는 멱등성이고 반드시 상태를 변경하지 않고 반복적으로 실행되도록 설계되었기 때문에 이 구분이 엄격하다고 생각하지 않습니다. 대신 up scale 완전히 잡아먹는 것을 고려해야 한다고 생각합니다.

@mattgiles 동의합니다. 그게 #2496을 사용하려고 했던 부분이지만 service=count 가 up 추가될 수 있다고 생각하지 않았습니다. 상황을 처리할 수 있다고 생각합니다. 내가 볼 수있는 유일한 문제는 현재 up web 가 웹 서비스와 종속성 만 표시한다는 것을 의미한다는 것입니다. up web=3 시도하는 것은 계속해서 같은 것을 의미해야 합니다. 즉, 모든 것을 up 하고 스케일 카운트를 한 번에 무시할 수는 없지만 괜찮을 것입니다.

제안을 #2496에서 업데이트하겠습니다.

@dnephin 최근 제안을 놓쳤습니다. 엄청난!

fwiw, docker-compose up web=3 가 "웹" 서비스에 대한 세 개의 컨테이너와 모든 종속성을 불러오는 것이 완전히 직관적이라고 생각합니다... yaml에 정의된 비율로( scale 지시문). 그렇게 하면 명령줄에서 재정의하지 않는 한 작성 파일이 계속 제어됩니다.

up 의 후속 호출은 현재와 같이 계속해서 기존 컨테이너를 그대로 둘 수 있습니다. 현재 스케일이 yaml에 정의된 것보다 작은 경우에만 금지된 스케일과 일치하도록 카운트를 변경합니다. 정의된 척도가 없으면 척도 1을 계속 의미합니다.

--force-recreate 와 같은 항목은 yaml에 정의된 것보다 높으면 카운트를 그대로 두지만 여전히 다른 속성과 일치하도록 모든 컨테이너를 다시 생성해야 합니다.

docker-compose up web=2 등과 같은 것을 호출하여 현재 scale 할 수 있는 것처럼 컨테이너를 죽일 수 있다는 것도 의미가 있습니다.

+1

+1 ( @pierrre 를 귀찮게 하기

+1

스케일 = x의 경우 +1.

이와 관련하여 싱글톤을 설명하는 방법을 원합니다. scale=1

규모 옵션으로 모든 성공

+1

나는 upstream에서 이것에 대한 새로운 것을 보지 못했습니다. 개인적으로 패치를 해킹할 수 있는지 확인할 기회가 없었습니다.

감사 해요,
제이슨 밀스

• 모바일에서 보냈습니다.

2016년 8월 8일 오후 5시 19분에 lavvy [email protected]에서 다음과 같이 썼습니다.

규모 옵션으로 모든 성공

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하거나 GitHub에서 보거나 스레드를 음소거하세요.

+1

+1

+1

+1

+1 ( @pierrre를 다시 괴롭히기

+1

나는 사건을 다시 반복하고 싶다

규모=0
테스트, 디버그에 유용합니다. 일반적으로 불러오고 싶지 않지만 정의되기를 원하는 프로브 등의 서비스 - 일반적으로 파일의 다른 서비스 컨텍스트에서 사용되기 때문입니다.

규모=1
왜냐하면 나는 이것들 중 단 하나뿐인 - _ever_를 원하기 때문입니다. MariaDB 클러스터에서 특정 스토리지 엔진(예: Spider, ColumnStore 등)으로 구성된 단일 노드만 원하는 경우가 있습니다.

규모=n
예를 들어 항상 하나의 기본(구성 포함)과 두 개의 보조(기본 구성과 다른 구성)가 있는 MariaDB 클러스터와 같이 실행 중인 'n' 서비스가 필요하다는 것을 알고 있는 경우가 있기 때문입니다.

@alvinr에게 완벽한 의미가 있습니다. 기본값은 1이어야 합니다.

면책 조항: 저는 Marathon 또는 Mesosphere의 대표자가 아닙니다.

이것은 도커 지원 팀에서 1년 넘게 포기/미뤄온 상당히 간단한 기능 요청의 또 다른 예입니다. https://github.com/docker/docker/pull/12749 가 또 다른 예입니다. Kubernetes와 Marathon은 꽤 오랫동안 이러한 옵션을 가지고 있었고( "instances": marathon.json 파일의 3개) 심지어 Auto Scaling을 구현했습니다. 저를 도커 데이터 센터 및 떼에서 한동안 밀어낸 것은 도커 지원 그룹의 내키지 않음입니다.

Kontena에는 instances: 3 (https://www.kontena.io/docs/references/kontena-yml)도 있습니다.

이를 수행할 수 있는 또 다른 방법은 작성 파일 버전 2에 scale 섹션을 추가하는 것입니다.

서비스에서 사용되는 도커 전용 옵션과 혼합되지 않습니다.

예는 다음과 같습니다.

version: "2"

services:
  worker:
    image: something
    command: work

scale:
  worker: 2    

scale: 0 를 지정할 수 있는 기능은 하나의 돌로 두 마리의 새를 죽일 수 있습니다. 다른 하나는 https://github.com/docker/compose/issues/1896입니다.

이것은 아무 생각이없는 것처럼 보입니다.

3개 또는 4개의 nodejs 인스턴스로 nginx+nodejs+mongodb를 배포하고 싶습니다. 앱을 시작할 때마다.

명령줄 옵션이 있는 경우 yml 파일에 없는 이유는 무엇입니까?

docker-compose up scale nodejs=4

할것이다.

간단 해. 그들은 "다른 사람이 구축하고 우리가
지원하려고 합니다." 기본 도커 외에는 생성하지 않았습니다.
아무것. Compose는 그들이 소비한 다른 제품이었고 지금은
이를 지원/확장하는 방법을 모르기 때문에 마라톤 및
kubernetes는 swarm보다 더 유명합니다.

2016년 10월 16일 오후 9시 36분, "Michael Schwartz" [email protected]
썼다:

이것은 아무 생각이없는 것처럼 보입니다.

3개 또는 4개의 nodejs 인스턴스로 nginx+nodejs+mongodb를 배포하고 싶습니다. 모든
앱을 시작할 때.

명령줄 옵션이 있는 경우 yml 파일에 없는 이유는 무엇입니까?

docker-compose up scale nodejs=4

할것이다.

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

나는 솔직히 이것에 대해 _any_ 푸시백이 있다는 사실에 약간 놀랐습니다.

@westlakem MacOS용 Docker가 같은 운명을 겪지 않기를 바랍니다.

기능적 크기의 완전한 스택을 한 번에 불러오는 것이 좋을 것입니다. 현재 사용 사례에서 서비스 스택이 제대로 작동하려면 "workers=16"이 필요합니다.

이것은 끔찍합니다.

docker-compose up -d
docker-compose scale workers=16
docker-compose down
docker-compose up --abort-on-container-exit

다음과 같이 명확하게 대체될 수 있습니다.

docker-compose up --abort-on-container-exit --scale workers=16

편집: "Rancher"에는 구문과 같은 docker-compose가 있고 초기 확장 매개변수를 지원합니다. https://paypertrail.com/blog/tech/docker-rancher-and-laravel-easy-and-safe-scalability

해결 방법은 YAML 앵커 및 병합 기능을 사용하고 docker-compose 파일 내에서 서비스를 복제하는 것입니다.

services:
  toscale: &my_service
     ... # all paramteres
  # second instance
  toscale2: 
     << : *my_service
     ports:
       - 81:80 # override port if needed

등 ...

이것은 매우 유용할 것입니다!

존재하지 않는게 이상해...

내가 너무 게으르므로 중복 서비스를 만들어야 할 수도 있습니다.

이것은 이미 docker-compose v1에서 지원되는 작곡가 파일 v3 https://github.com/aanand/compose-file/blob/master/schema/data/config_schema_v3.0.json 작업에 있습니다. 10.0-rc1

그들의 "서비스" 오퍼링에는 매개변수가 내장되어 있습니다.
이 문제의 구독자는 개발 팀의 누구도 우리에게 다음 사실을 알려주지 않았습니다.
서비스 제품에 포함되어 있었고 누군가 RC 노트를 읽어야 했습니다.
모든 통찰력에 대한 1.10. 도커 담당자는 어디에 있습니까?

2017년 1월 6일(금) 오전 6시 30분, Yasmany Cubela Medina <
[email protected]>은 다음과 같이 썼습니다.

이것은 이미 작곡가 파일 v3 https://github.com/aanand/ 에서 작업 중입니다.
compose-file/blob/master/schema/data/config_schema_v3.0.json
이미 docker-compose v1.10.0-rc1에서 지원됩니다.

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

+1

+1

안녕하세요 관련 질문이 있습니다.
docker-compose up 이 내가 설정한 척도를 기억할 수 있는지 궁금했습니다.

예를 들어 docker-compose scale nodejs_web=4 다음 docker-compose down ,
그런 다음 docker-compose up 다시 시작하면 4 nodejs_web이 시작됩니다.

scale 명령이 숫자 4를 저장하는 위치를 알고 싶습니다.

docker-compose.yml은 다음과 같을 수 있습니다.

version: '2'
services:
  nodejs_web:
    image: node
    command: node

#2496에서 @dnephin 제안을 지지합니다.
이 기본 기능을 알려주세요.

새 버전의 Docker의 서비스는 '복제본' 기능을 제공합니다.

2017년 3월 20일 월요일 오후 3시 28분, alwaysatudent [email protected]
썼다:

#2496에서 @dnephin https://github.com/dnephin 제안을 지지합니다.
https://github.com/docker/compose/issues/2496
이 기본 기능을 알려주세요.

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

@westlakem - 그 기능은 떼를 위한 것입니다. 정기적인 서비스 확장을 위한 것이 아닙니다.

너무 많은 장점, 적은 단점. 이 문제에 무슨 문제가 있습니까?

https://github.com/docker/compose/issues/2496 에서 scale 명령을 완전히 제거하는 것에 대한 최신 제안이

작성 파일에 initial_scale: 3 옵션이 없는 이유 또는 이유를 정말 이해하지 못합니다( scale: 3 일 수 없는 이유를 이해합니다)

1.13.0에서 다시 구현되었습니다. 피드백과 인내심을 주신 모든 분들께 감사드립니다.

@shin- 폐쇄된 것으로 간주되는 이유는 무엇입니까? 모든 것이 자동화되고 버전 제어되는 대규모 앱을 관리할 때 이제 Docker를 실행하는 Ansible을 수정하여 실행할 서비스 인스턴스 수를 정의해야 합니다.

Ansible은 Docker가 실행될 수 있도록 모든 것을 설정해야 합니다. Docker는 앱에 필요한 서비스 인스턴스 수를 정의해야 합니다. 이제 서비스 인벤토리를 아는 것은 Docker의 책임이지만 Docker를 호출하는 Ansible의 책임은 회전할 컨테이너 수를 알 수 있도록 하는 것입니다.

@greenscar 죄송합니다. 문제가 무엇인지 정확히 모르겠습니다. 기능이 구현된 방식이 마음에 들지 않습니까? 그렇다면 어떤 방법으로 개선할 수 있습니까?

이것이 버전 3에 없는 이유는 무엇입니까? "deploy.replicas"와 "up"이 동일하지 않기 때문에 매우 혼란스럽습니다. 이 기능이 v3에서 누락되었다고 말할 수 있습니다.

@cgarciae deploy.replicas 는 scale 와 같은 용도로 사용됩니다. 당신이 보기에 그것들이 동등하지 않은 이유는 무엇입니까?

@shin- 떼를 만들고 싶지 않고 docker-compose up -d 만 사용하는 경우 docker compose는 "배포" 설정을 무시한다고 알려줍니다.

@cgarciae Swarm을 생성하지 않으려면 왜 v3 파일을 사용합니까?

docker를 사용하는 모든 사람은 scale 매개변수가 docker 2 또는 3 파일에서 작동할 것으로 예상합니다. 그렇지 않을 이유가 없으며 deploy.replicas의 기본값도 설정할 수 있습니다. deploy.replicas가 설정되면 Swarm의 규모를 재정의합니다. 모든 사람이 예상하는 것과는 별개로 이 그림의 문제점은 무엇입니까(물론 마음에 들지 않으면 docker-compose.yml에서 사용할 필요가 없습니다)?

누락된 scale 매개변수로 인해 서비스가 실패했습니다. 마지막으로 다시 배포한 이후로 이전처럼 확장하는 것을 잊었기 때문입니다.

이 문제도 치십시오. docker compose 구성 내에서 시작할 서비스 수를 지정할 방법이 없는 것 같습니까? docker compose 문서에 docker-compose와 작동하지 않는 것들에 대한 많은 문서가 있다는 것은 훨씬 더 혼란스럽습니다...

아 잠깐, 내 docker compose config를 version: "2.2" 로 변경하면 scale: 2 있지만 이후 버전으로 이동하려는 경우 더 이상 이를 수행할 수 있는 옵션이 없습니까?

좋아, 이 "버전" 문제는 실제로 버전이 이미 올라왔다는 의미가 아닙니다. https://github.com/docker/compose/issues/4693

2.2에 존재하지 않는 일부 구성이 필요하기 때문에 v3.6을 사용합니다. 로컬 개발을 위해 떼를 사용하지 않지만 docker-compose.overrides.yml의 일부 컨테이너에 scale=0을 설정하고 싶습니다. 그들 중 일부는 frontendbuild 컨테이너와 같은 빌드 프로세스를 위한 것이기 때문입니다. 이 컨테이너는 실행 중인 다른 컨테이너와 일부 볼륨을 공유하지만 docker-compose up에서 이러한 다른 컨테이너와 함께 시작하면 안 됩니다. 따라서 buildcontainer는 run 명령으로 실행됩니다. 예, docker-compose up을 호출할 때 --scale 매개변수를 설정할 수 있지만 구성에 직접 작성하는 것이 더 낫다고 생각합니다. :)

scale 매개변수에 감사드립니다. 누구나 Consul과 Vault의 HA 구성을 사용할 수 있도록 비프로덕션 docker-compose.yml 사용할 수 있었습니다. scale 매개변수를 사용하면 로컬 HA 구성을 쉽게 프로비저닝할 수 있습니다. https://github.com/samrocketman/docker-compose-ha-consul-vault-ui

이 경우 누군가가 HA 구성에서 Consul 및 Vault를 시도하고 Consul DNS를 사용하기 위한 용도로만 사용됩니다.

어떤 버전의 docker compose를 실행하고 있습니까? v3 이후로 이 기능은 삭제되었으므로(삭제로 인해 구현된 적이 없음) 무시됩니다. https://docs.docker.com/compose/reference/scale/ 참조

기능이 부족하여 v3 형식을 사용하지 않습니다. 사용하는 기능에 따라 가장 낮은 2.1 또는 2.2 형식을 사용하는 경향이 있습니다.

편집: v3 형식을 피하는 것은 아닙니다. 작성 파일을 작성하려고 할 때 일반적으로 사용하려는 항목이 누락되었습니다.

좋아, 나는 당신이 docker compose with swarm stack에 대해 이야기하는 것 같아요. 그래서 그런 것입니다. 시도한 적은 없지만 오케스트레이터와 다중 노드 없이 docker compose로 HA에 대해 이야기하는 것은 이상합니다. "poc" 또는 테스트 목적입니까? 어쨌든 나는이 맥락에서 시도한 적이 없다.

이 경우 HA는 단순히 영사 클러스터와 볼트 클러스터를 나타냅니다. 실험에 사용할 수 있는 개념 증명과 부트스트랩의 용이성을 제공하기 위한 것입니다. HA는 도커 HA 또는 다중 시스템 HA를 참조하지 않습니다. 실험하는 사람이 클러스터 컨테이너 중 하나를 종료하고 영사 및/또는 볼트 서비스가 영향을 받지 않음을 확인할 수 있다는 점에서 유일한 HA입니다.