Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

Add opt-in ordered replica startup with health-based readiness

オープン
  • 何か問題がありますか？
#14,232 コメント 6 件 リアクション 1 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
35/100
issue の種類
機能追加
明瞭さ
おおむね明確
活発さ
活発
技術スタック
docker, docker-compose
領域
devops, infrastructure

調査の方向性

まず関連する issue #5422、#8849、#14081 を確認し、次に Docker Compose における既存のレプリカの起動およびスケールアップの動作を追跡します。healthcheck、hook、失敗、後方互換性を含む opt-in 設定と readiness のセマンティクスを定義します。オプションを省略した場合の動作を変更せず、初期起動とスケールアップの処理が順序どおりに実行されれば完了です。

索引モデルが issue の本文から書いたものです。

説明

kind/feature
Description
Description

Docker Compose supports ordering between different services using depends_on and condition: service_healthy.

However, this ordering cannot be applied between replicas of the same service.

For example:

services:
  app:
    image: example/app
    deploy:
      replicas: 3
    healthcheck:
      test: ["CMD", "/app/healthcheck.sh"]
      interval: 5s
      timeout: 3s
      retries: 20

Compose starts all three replicas without waiting for one replica to become healthy before starting the next. Although container start API calls may be issued sequentially, application initialization occurs concurrently.

Desired behavior

I would like an opt-in mode that starts replicas in sequence and waits for each replica to become ready:

app-1 starts
  ↓
app-1 post_start hooks complete
  ↓
app-1 becomes healthy
  ↓
app-2 starts
  ↓
app-2 post_start hooks complete
  ↓
app-2 becomes healthy
  ↓
app-3 starts

This would provide behavior similar to chaining separately declared services:

services:
  app-0:
    image: example/app

  app-1:
    image: example/app
    depends_on:
      app-0:
        condition: service_healthy

  app-2:
    image: example/app
    depends_on:
      app-1:
        condition: service_healthy

That workaround loses the benefits of Compose replicas and requires manually duplicating each service.

Suggested configuration

The exact syntax is open for discussion. One possible configuration is:

services:
  app:
    image: example/app
    deploy:
      replicas: 3
      startup_config:
        order: sequential
        condition: service_healthy
        failure_action: pause

startup_config should be optional. When it is not provided, Docker Compose should preserve its existing replica startup behavior without requiring an explicit order: parallel setting.

This makes ordered, health-gated startup opt-in and maintains backward compatibility with existing Compose files.

Expected semantics

When ordered startup is enabled:

  1. Start the lowest-numbered missing replica.
  2. Run and complete its post_start hooks.
  3. Wait until its healthcheck reports healthy.
  4. Start the next replica.
  5. Stop the sequence if a replica exits, becomes unhealthy, a hook fails, or the readiness timeout is exceeded.
  6. Apply the same behavior during initial up and later scale-up operations.
  7. Leave the current behavior unchanged when the option is omitted.

A service using condition: service_healthy should require a healthcheck. A separate condition could support applications that only need the previous replica to be running.

Use case

This is useful for stateful or clustered applications where each member must register, join the cluster, initialize data, update shared configuration, or elect a leader before another member starts.

In our case, multiple replicas start concurrently and attempt to update the cluster configuration at the same time. Two clients can read the same available port before either client finishes writing its configuration. Both clients are then assigned the same port, resulting in a configuration mismatch error and preventing the cluster from starting correctly.

The expected sequence is:

app-1 starts
  ↓
app-1 updates the cluster configuration
  ↓
app-1 completes its post_start work and becomes healthy
  ↓
app-2 starts and receives the next available port
  ↓
app-2 becomes healthy
  ↓
app-3 starts
Environment
Docker Compose version
Docker Compose version v5.3.1
Docker version
Client: Docker Engine - Community
 Version:           29.6.2
 API version:       1.55
 Go version:        go1.26.5
 Git commit:        dfc4efb
 Built:             Thu Jul 16 16:12:21 2026
 OS/Arch:           linux/amd64
 Context:           default

Server: Docker Engine - Community
 Engine:
  Version:          29.6.2
  API version:      1.55 (minimum version 1.40)
  Go version:       go1.26.5
  Git commit:       3d80467
  Built:            Thu Jul 16 16:12:21 2026
  OS/Arch:           linux/amd64
  Experimental:     false
 containerd:
  Version:          v2.2.6
  GitCommit:        11ce9d5f3c68c941867e82890e93e815c1304f1b
 runc:
  Version:          1.3.6
  GitCommit:        v1.3.6-0-g491b69ba
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0
Related issues
  • #5422 — staggered container startup
  • #8849 — limiting startup parallelism
  • #14081 — start-phase plan engine and replica chains

Those discussions concern request ordering, startup parallelism, or internal planning. This request specifically adds a readiness barrier between replicas.

主要言語
Go
スター
38.3k
フォーク
5.8k
平均マージ
2日 17時間
マージ済み PR（30日）
47

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

docker/compose のほかの issue

docker/compose の issue をすべて見る

似ている issue

Go の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。