テーマ: deployment
-
デプロイ済みのイメージを削除することなくコンテナレジストリを小さく保つには、どのイメージ保持ルールがよいか
未解決の問い: レジストリは、どのマニフェストからも参照されなくなったblobだけをガベージコレクションし、ライフサイクルポリシーは経過時間・件数・タグパターンによってイメージを期限切れにする。無制限な増大も、イメージが消えていたことによるロールバックの失敗も起こさずに、チームが何年も運用してきたルールの組み合わせはどのようなものか。
-
Welche Rollout-Strategie funktioniert auf einem einzelnen Host mit Docker Compose und Reverse Proxy?
Offene Frage: Rollierend, Blue-Green und Canary sind für Orchestratoren beschrieben; viele kleine Dienste laufen aber auf einem Host mit Docker Compose hinter Traefik, nginx oder Caddy. Welche Nachbildung – zweiter Container mit umgeschalteter Proxy-Regel, gewichtete Verteilung, start-first – haben Teams über Monate betrieben, was hat sie gebrochen, und ab welcher Grösse lohnt sich der Orchestrator?
-
Tags and releases: lightweight versus annotated tags and how they travel
A lightweight tag is only a name for a commit; an annotated tag is an object with tagger, date, message and optional signature, which is why git describe ignores lightweight tags by default and why releases should use annotated or signed tags; tags are not pushed with branches unless --follow-tags or --tags is used, and a published tag should never be moved.
-
グレースフルシャットダウン:サービスでの SIGTERM の処理
コンテナーランタイムは SIGTERM を送り、猶予期間を待ってから SIGKILL を送る。サービスは新しい処理の受け付けを止め、実行中の処理を完了するか引き渡し、接続を閉じて期間内に終了する必要がある。シグナルを無視すると、デプロイのたびにサービス中断が起きる。
-
Design rollback before rollout
Write a recovery decision tree before deployment, distinguishing reversible configuration changes from data migrations that need compensation.
-
Datenbankänderungen ohne Ausfall: Expand und Contract
Ein Schema in drei einzeln auslieferbaren Schritten ändern: erweitern (neue Spalte oder Tabelle anlegen, alte behalten), migrieren (doppelt schreiben und in Häppchen nachfüllen), zusammenziehen (Altes entfernen, sobald aller Code das Neue nutzt); lange Sperren vermeiden, indem keine Tabelle in einem Statement umgeschrieben wird und lock_timeout jede Wartezeit begrenzt.
-
Canary behavior changes before rollout
Expose a bounded cohort to a new behavior, compare it with a baseline and stop using predeclared failure conditions.
-
Read-only maintenance mode: serving reads while writes are paused
For storage moves, failovers and long migrations, a service can keep serving reads and refuse writes with a clear message instead of going dark; PostgreSQL's default_transaction_read_only makes new transactions read-only at the database as a backstop, and HTTP 503 with Retry-After tells clients when to try again. The mode needs one switch, a user-facing message and a rehearsal.
-
Rolling, blue-green and canary deployments compared
Rolling updates replace instances gradually within surge and unavailability bounds; blue-green runs the full new stack beside the old and switches traffic at once; canary sends a small share of real traffic to the new version and promotes on evidence. The choice depends on capacity, rollback speed and whether two versions may serve at the same time.
-
サービスのチェックリストとしての十二要素アプリ
十二要素は、デプロイ可能なサービスの規約を説明する。一つのコードベース、宣言された依存関係、環境内の設定、接続されたリソースとしてのバックエンドサービス、ビルド・リリース・実行の厳格な分離、ステートレスなプロセス、イベントストリームとしてのログである。
-
Managing secrets outside the repository
Credentials belong in protected configuration injected at runtime, never in source control, images or logs; rotate them on a schedule and on suspicion, and give each service its own.
-
1つのビルドを環境間で昇格させる:構成の昇格と開発・本番の一致
成果物を1回だけビルドし、不変の識別子を付け、環境固有の構成だけを変えながら、その同じ成果物をテスト、ステージング、本番へ昇格させます。バックエンドサービスと接続構成を環境間で似せ、ある段階の成功が次を予測できるようにします。
-
Schema migrations run with a short lock_timeout and automatic retry cause fewer deploy-time incidents than migrations without one
Hypothesis: because most ALTER TABLE forms take an ACCESS EXCLUSIVE lock that queues behind any long transaction while blocking every later query, migrations executed with a lock_timeout of a few seconds and a bounded retry loop produce fewer and shorter deploy-time outages than the same migrations run with the default unlimited wait, at the cost of a few migrations that need a manual rerun.
-
Rolling out a service worker safely: scope, versioned caches, the waiting worker and a kill switch
A service worker that caches HTML can pin users to old code after a deploy. Register it with an explicit scope, fetch the script fresh on every update check, version caches per build and delete old ones on activate, choose per-resource strategies, decide how the waiting worker takes over, and ship a tested kill switch before the first release.
-
Which pre-deployment checks have actually stopped a bad release in the last year, and which have never fired?
Open question: pipelines accumulate gates (tests, scans, smoke checks, canary analysis, manual approvals, rollout deadlines), and the Kubernetes documentation notes that a stalled Deployment is only reported, not rolled back; which gates have a record of stopping a bad release, which never fired, and which fired only falsely?
-
機能トグル:種類、寿命、後片付け
トグルはデプロイとリリースを切り離すが、一つ一つがコードの分岐になる。目的(リリース、実験、運用、権限)で分類し、それぞれに担当者と削除日を設ける。
-
Zero-downtime schema changes with expand and contract
Change a schema in three deployable steps: expand (add the new column or table, keep the old), migrate (dual-write and backfill in batches), contract (remove the old after all code uses the new); avoid long locks by not rewriting tables in one statement.
-
小さく再現可能なコンテナーイメージを作る
ベースイメージをダイジェストで固定し、ロックファイルからハッシュを検証してインストールし、実行時に必要なものだけをコピーする。root 以外のユーザーで実行し、ヘルスチェックを追加し、レイヤーやビルド引数にシークレットを含めない。
-
コンテナイメージのタグとダイジェスト:可変の名前と内容アドレス
タグは人が読めるポインターで、いつでも別のマニフェストへ移せる。ダイジェストはマニフェストのバイト列のハッシュであり、永久に正確に1つのイメージを識別する。ビルドとテストにはタグ、デプロイと固定にはダイジェストを使い、すべてのリリースノートにダイジェストを記録する。
-
Running a service under systemd
A unit file declares how a service starts, restarts and is confined; use Type, Restart=on-failure, resource limits and sandboxing directives, and read logs with journalctl instead of writing your own daemonisation.
機械可読: JSON