Documentation
¶
Overview ¶
Package containerboot decides which miren binary a container install runs. The image's own binary never changes while the container exists, which makes it the right place to decide and the wrong thing to serve from: upgrades land in the data volume's release directory, and that is what has to run. The image binary stays as the known-good fallback.
Index ¶
Constants ¶
const DefaultMaxBootAttempts = 3
DefaultMaxBootAttempts is how many boots an upgraded build gets before container-boot decides it is crash looping and rolls back.
const DefaultReleaseDir = "/var/lib/miren/release"
DefaultReleaseDir is where the image bakes the release bundle and where the data volume, mounted over it, keeps it from then on.
const RollbackFrom = "container-boot"
RollbackFrom is what container-boot writes as the operation's RollbackFrom: it is not an instance, and no instance will ever match it, which is the point. The executor in the rolled-back build sees a name that is not its own and knows the restart already happened.
Variables ¶
var ErrWatchedOperationGone = errors.New("watched operation is not in the ledger")
ErrWatchedOperationGone is returned when the operation the watchdog was started for is not in the ledger.
Functions ¶
This section is empty.
Types ¶
type Boot ¶
type Boot struct {
ReleaseDir string
// ImageBinary is the miren shipped in the image, normally the one
// running this code.
ImageBinary string
// LifecycleDir is the operation ledger; empty skips the upgrade guard.
LifecycleDir string
// MaxBootAttempts is how many boots an upgraded build gets; 0 means
// DefaultMaxBootAttempts.
MaxBootAttempts int
Log *slog.Logger
}
func (Boot) GuardUpgrade ¶
func (b Boot) GuardUpgrade(ctx context.Context) *serverlifecycle.Operation
GuardUpgrade is the part of rollback only container-boot can do. The executor inside an upgraded build rolls it back when it fails to get ready, but a build that crashes before the executor runs never gets that far; from the outside it is a container restarting over and over. Each boot of the new build is counted on the operation, and once it has had its chances the previous binary goes back and the operation is handed to the executor in that build as a rollback whose restart already happened.
A ledger that cannot be read is logged and the boot goes on: the server's own data-restore step fails closed on the same ledger, so nothing is lost by not deciding here.
The returned operation, when not nil, is the upgrade this boot is the new build's attempt at, for a Watchdog to keep an eye on.
func (Boot) Prepare ¶
Prepare makes the release directory ready to boot from and returns the binary to exec. The volume's binary is the one to run except when the image changed underneath it: docker seeds a volume once, on creation, so a `container install` with a newer (or older) image against an existing volume would otherwise keep running whatever the volume had. A changed image reseeds the binary, as the install used to do implicitly by running the image's copy.
type Watchdog ¶
type Watchdog struct {
Boot
OperationID string
// ServerPID is the process to end on rollback, container-boot's own
// PID, which the exec keeps.
ServerPID int
// Timeout is how long the build gets; 0 means the operation's own ready
// timeout, or the executor's default.
Timeout time.Duration
Interval time.Duration
// Kill ends the server; nil means the signal sequence in killServer.
Kill func(pid int) error
}
Watchdog is the one observer of an upgraded build that hangs before the executor inside it can run. A build that crashes is caught by the boot guard's attempt count, and one that boots far enough to run the executor is caught by that executor's own ready deadline; a hang in between has nothing watching it, since the boot graph has no overall timeout. Under systemd the executor is an external process probing the health endpoint against a deadline, and this is that deadline for a container.
container-boot starts one beside the server for each boot of the new build. It watches the ledger, not the server: the operation leaving the phases that mean "the new build is coming up" is the executor having taken over, whatever the outcome. Past the deadline with the operation still there, it rolls back the same way the boot guard does and ends the server so the restart policy brings the previous build up.
Source Files