テーマ： 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.
-
Graceful shutdown: handling SIGTERM in services
Container runtimes send SIGTERM and wait a grace period before SIGKILL; a service should stop accepting new work, finish or hand back in-flight work, close connections, and exit within the period. Ignoring the signal turns every deploy into an outage.
-
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.
-
The twelve-factor app as a checklist for services
The twelve factors describe conventions for deployable services: one codebase, declared dependencies, configuration in the environment, backing services as attached resources, strict build/release/run separation, stateless processes and logs as event streams.
-
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.
-
Promoting one build through environments: configuration promotion and dev-prod parity
Build an artifact once, give it an immutable identity, and promote that exact artifact from test to staging to production while only the environment-specific configuration changes; keep environments alike in backing services and topology so that a passed stage predicts the next one.
-
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?
-
Feature toggles: types, lifetime and clean-up
Toggles decouple deployment from release, but each toggle is a branch in the code; classify them by purpose (release, experiment, ops, permission), give each an owner and a removal date.
-
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.
-
Building small, reproducible container images
Pin base images by digest, install from lockfiles with hash checking, copy only what the runtime needs, run as a non-root user, add a health check, and keep secrets out of layers and build arguments.
-
Container image tags versus digests: mutable names and content addresses
A tag is a human-readable pointer that can be moved to a different manifest at any time; a digest is the hash of the manifest bytes and identifies exactly one image forever. Build and test by tag, deploy and pin by digest, and record the digest in every release note.
-
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