Implement systemd unikernel manager

[craciunoiuc]

Feature request summary

This issue tracks the ability to set and manage Unikraft unikernels as individual systemd entries. Ultimately this would give users the ability to use unikernels as secure, persistent system services.

At a glance, creating and managing unikernels as systemd processes should be designed to be simple, making it an effective mechanism and alternative approach for system services. As such, a new flag --systemd should be provided to the following subcommands to enable managing and running via this interface:

• kraft run --systemd [...]
• kraft start --systemd [...]
• kraft stop --systemd [...]
• kraft rm --systemd [...]
• kraft ps --systemd [...]

In order to prevent large disruption to the individual subcommand codebases, (i.e. preventing having a large if opts.Systemd flag with a different line-of-execution), a simple wrapper around the machine API can be used to proxy all interface methods into relevant systemd service management actions.

In order to propagate such functionality, a new machine service implementation is required in kraftkit.sh/machine/platform/systemd which implements the MachineService interface:

kraftkit/api/machine/v1alpha1/machine.zip.go

Lines 149 to 162 in 71509c7

	// MachineService is the interface of available methods which can be performed
	// by an implementing machine platform driver.
	type MachineService interface {
	Create(context.Context, *Machine) (*Machine, error)
	Start(context.Context, *Machine) (*Machine, error)
	Pause(context.Context, *Machine) (*Machine, error)
	Stop(context.Context, *Machine) (*Machine, error)
	Update(context.Context, *Machine) (*Machine, error)
	Delete(context.Context, *Machine) (*Machine, error)
	Get(context.Context, *Machine) (*Machine, error)
	List(context.Context, *MachineList) (*MachineList, error)
	Watch(context.Context, *Machine) (chan *Machine, chan error, error)
	Logs(context.Context, *Machine) (chan string, chan error, error)
	}

To utilize the machine API via a controller, it should be a simple case of wrapping an existing controller, e.g.:

import (
  machineapi "kraftkit.sh/api/machine/v1alpha1"
  "kraftkit.sh/machine/platform/systemd"
)

var controller machineapi.MachineService

if opts.Systemd {
  controller, err = systemd.NewMachineV1alpha1ServiceSystemdWrapper(ctx, controller)
  if err != nil {
    // [...]
  }
}

The new method NewMachineV1alpha1ServiceSystemdWrapper will consume all interface methods and directly interface with systemd which can be accomplished with this existing Go module.

Warning

Installing systemd process should ultimately create an entry which invokes kraft itself and that not all interface methods are a simple 1-to-1 call of one another. This is because wrapper will pass through the machine API store twice and some verbs do not map directly to the machine API. Careful consideration should be practice when proxying commands. For example, the Create command should both create the systemd service entry and also initialize the unikernel. The Start method, however, could, only start the systemd service as this will invoke kraft which will actually start the unikernel.

Additional context

@MdSahil-oss wants to work on this.

[nderjung]

I have updated the issue text with more verbose information about this particular feature request.