1.8 KiB
Concepts
Explain the following:
Contents
Deploy Path
The path to a service, starting with the cluster and environment: apps/staging/a/auth-app.
Path components may include:
- cluster
- env (
account) - target
- service (namespace)
- branch (
ref)
When locking a path, only the leaf path is locked, not parents.
When checking a path, each segment is checked recursively, so a lock at apps/staging will prevent all services
from being deployed into both the apps/staging/a and apps/staging/b clusters.
- cluster comes first because that is how we structure the git repositories (repo = cluster, branch = env)
- to lock multiple clusters in the same environment, run the command repeatedly with the same lock data
- to lock a specific branch, put it in the path:
apps/staging/a/auth-app/main
Ultimately, the deploy path's layout should follow the hierarchy of resources that you want to lock. One potential order, for a multi-cloud Kubernetes architecture, is:
- cloud
- account
- region
- network
- cluster
- namespace
- resource name
Such as aws/staging/us-east-1/apps/a/auth-app/api or gcp/production/us-east4-a/tools/gitlab/runner/ci.
Including the region in the path can be limiting, but also allows locking an entire provider-region in case of serious upstream incidents.
Exclusive and Partial Locks
Some locks allow certain types, some locks don't allow anything. Why is that?
Multi-Party Locks
Idea: make LockData.author an array, with commands to add/remove an author to an existing lock.
Why: there may be more than one person/team who needs to sign off on an incident before it is closed.