sugar for provisioning via container

coreos / butane

Butane translates human-readable Butane Configs into machine-readable Ignition Configs.

https://coreos.github.io/butane/

Apache License 2.0

249 stars 70 forks source link

sugar for provisioning via container #35

Open cgwalters opened 5 years ago

cgwalters commented 5 years ago

One thing I think would be interesting is sugar like this:

provisioncontainer: quay.io/myuser/setup@sha256:shashasha

This would expand into a systemd unit which ran podman under ConditionFirstBoot=yes something like this: podman run --rm quay.io/myuser/setup --privileged -v /:/host

And we could give some examples of using "first boot containers" like this that can do completely arbitrary things, say use an Ansible playbook pointing at the host, or use Ruby scripts - whatever.

This isn't hard to write manually but it's also not entirely obvious, and we'd be encouraging the pattern of containerization even for early boot.

ajeddeloh commented 5 years ago

I think it would be good to make this more general for launching containers in general, though that require adding something like runtime-args for things --volume and --privileged. Maybe something like:

containers:
 - image: `quay.io/example/example:v2`
   runtime: docker # docker | podman, podman default. docker adds the correct unit deps for docker.socket
   runtime-args: [ "--net=host" ]
   provisioning: true # adds `--privileged`, `-v /:host` to runtimeargs, ConditionFirstBoot=yes to the unit
   dropins:
     - <systemd drop ins for the unit>

This would cut down the boilerplate for units in general basically killing two birds with one stone

jlebon commented 4 years ago

This came up in the FCOS Hands-On Lab today. The podman generate systemd command already contains code for how to provision containers via systemd units. Would be great to leverage this. Some ideas that came up:

have fcct call out to podman: not great, embeds the assumption that podman is installed.
have a more generic "put the output of this command here" helper: user's responsibility to make sure they have podman installed when converting, full control over the podman flags, could be used with many other things as well, but less pleasant to use than declarative sugar.
have fcct generate a systemd generator which runs the podman command to create the systemd service: slightly contrived, though no local podman required and uses the podman of the target FCOS version.

bgilbert commented 4 years ago

Looking at the output of podman generate systemd, I'm not seeing anything sufficiently complex to be worth delegating to another tool. Any reason we shouldn't just generate the unit ourselves?

jlebon commented 2 years ago

Maybe instead of also implementing our own generators, we just support quadlet configs, e.g.:

containers:
  - name: minimal
    quadlet: |
      [Unit]
      Description=A minimal container

      [Container]
      Image=centos
      Exec=sleep 60

      [Service]
      Restart=always

which converts into a file at /etc/containers/systemd/minimal.container. (Obviously this implies https://github.com/coreos/fedora-coreos-tracker/issues/998.)