joonas commented 6 months ago

Add wasmCloud recipe

This adds a new recipe for baking a wasmCloud sysext image.

How to use

Once the image is built, you can employ the following configuration ignition configuration (replacing <your-repository-goes-here> with the appropriate value) to consume it:

---
variant: flatcar
version: 1.0.0
storage:
  files:
    - path: /opt/extensions/wasmcloud/wasmcloud-0.82.0-x86-64.raw
      contents:
        source: https://github.com/<your-repository-goes-here>/sysext-bakery/releases/download/latest/wasmcloud-0.82.0-x86-64.raw
    - path: /etc/sysupdate.wasmcloud.d/wasmcloud.conf
      contents:
        source: https://github.com/<your-repository-goes-here>/sysext-bakery/releases/download/latest/wasmcloud.conf
  links:
    - target: /opt/extensions/wasmcloud/wasmcloud-0.82.0-x86-64.raw
      path: /etc/extensions/wasmcloud.raw
      hard: false
systemd:
  units:
    - name: systemd-sysupdate.timer
      enabled: true
    - name: systemd-sysupdate.service
      dropins:
        - name: wasmcloud.conf
          contents: |
            [Service]
            ExecStartPre=/usr/lib/systemd/systemd-sysupdate -C wasmcloud update
        - name: sysext.conf
          contents: |
            [Service]
            ExecStartPost=systemctl restart systemd-sysext

Testing done

I've set up a testing branch on top of this branch to customize things ever so slightly to allow me to test using the above configuration on my own by pushing a latest tag to kick off CI and create a new "latest" release.

Once I had a release ready to go, I ended up provisioning a DigitalOcean Droplet with Terraform loosely following Flatcar's docs to test the release.

When it was all said and done, I was able to successfully verify that the binaries and versions I would expect were indeed installed on the machine:

Flatcar Container Linux by Kinvolk stable 3815.2.1 for DigitalOcean
core@flatcar-demo-01 ~ $ /usr/bin/wasmcloud --version                                                                                                                                                                                                                       
wasmcloud 0.82.0                                                                                                                                                                                                              
core@flatcar-demo-01 ~ $ /usr/bin/nats-server --version                                                                                                                                                                                                                     
nats-server: v2.10.12
core@flatcar-demo-01 ~ $ /usr/bin/wasmcloud 
Error: failed to initialize host

Caused by:
    0: failed to establish NATS control server connection
    1: failed to connect to NATS
    2: IO error: Connection refused (os error 111)
core@flatcar-demo-01 ~ $ /usr/bin/nats-server                                                                                                                                                                                                                               
[1350] 2024/04/09 15:02:02.848630 [INF] Starting nats-server
[1350] 2024/04/09 15:02:02.856769 [INF]   Version:  2.10.12
[1350] 2024/04/09 15:02:02.856912 [INF]   Git:      [121169ea]
[1350] 2024/04/09 15:02:02.857020 [INF]   Name:     NCYLISGT6Z4R7E66WAAZU7LH5F7D6QJDIRH7J4CUWUXASXCAFPIM76QD
[1350] 2024/04/09 15:02:02.857103 [INF]   ID:       NCYLISGT6Z4R7E66WAAZU7LH5F7D6QJDIRH7J4CUWUXASXCAFPIM76QD
[1350] 2024/04/09 15:02:02.860211 [INF] Listening for client connections on 0.0.0.0:4222
[1350] 2024/04/09 15:02:02.860609 [INF] Server is ready
^C[1350] 2024/04/09 15:02:05.358731 [INF] Initiating Shutdown...
[1350] 2024/04/09 15:02:05.358864 [INF] Server Exiting..

[ ] Changelog entries added in the respective changelog/ directory (user-facing change, bug fix, security fix, update)
[ ] Inspected CI output for image differences: /boot and /usr size, packages, list files for any missing binaries, kernel modules, config files, kernel modules, etc.

Please note a couple more things:

This ships wasmCloud 0.82.0, which is currently the latest stable version. wasmCloud 1.0 release is imminent, but rather than block this work waiting on that, I figured I'd get this foundation in place, and make the update to bump to 1.0 once it's ready to go.
I wasn't sure if I should be adding the wasmCloud entries to release_build_versions.txt, please let me know if you'd prefer I back those changes out and focus these changes on just the recipe.

t-lo commented 5 months ago

Thank you for your contribution, @joonas !

I've tested the PR; first built the sysext

./create_wasmcloud_sysext.sh 0.82.0 wasmcloud-0.82.0

then started a fresh Flatcar qemu instance and provisioned the sysext (served from localhost). Butane config:

variant: flatcar
version: 1.0.0
storage:
  files:
    - path: /etc/extensions/wasmcloud-0.82.0.raw
      contents:
        source: http://172.16.0.99:8000/wasmcloud-0.82.0.raw

(172.16.0.99 was assigned to lo for testing).

Ran a simple web server in the backend to serve the wasmcloud sysext, and started Flatcar with the above config (transpiled to JSON):

python -m http.server &
./flatcar_production_qemu.sh -i wasmcloud.json -nographic
[...]
core@localhost ~ $ wasmcloud --version
wasmcloud 0.82.0

Looks good!

tormath1 commented 5 months ago

Thanks @joonas for the contribution. What do you think about shipping the NATS systemd unit: https://github.com/nats-io/nats-server/blob/main/util/nats-server.service in the Sysext image? The NATS server could be automatically started when the sysext image is merged (same as kubelet service for Kubernetes: https://github.com/flatcar/sysext-bakery/blob/403e75fdde7ae18e081230db0d016c74f4953d4b/create_kubernetes_sysext.sh#L90)

joonas commented 5 months ago

Thanks @joonas for the contribution. What do you think about shipping the NATS systemd unit: https://github.com/nats-io/nats-server/blob/main/util/nats-server.service in the Sysext image? The NATS server could be automatically started when the sysext image is merged (same as kubelet service for Kubernetes:

https://github.com/flatcar/sysext-bakery/blob/403e75fdde7ae18e081230db0d016c74f4953d4b/create_kubernetes_sysext.sh#L90

)

That sounds great, I'll take a look at including default configuration.

I had originally considered including unit files to start things out of the box, but I hesitated to include them since there is configuration you would likely want to pass in for the system to really be useful (consider the example of joining an existing cluster, for example).

That being said, as I understand it should be pretty easy to customize and even completely override pre-existing unit files and/or configuration such that the node could be configured to be part of a larger pre-existing deployment, so including a default set of configuration that would effectively make this a single-node wasmCloud deployment out of the box for the purposes of things like demos and local development/kicking the tires is a fine starting point.

I'm sure we can provide some docs with example butane/ignition configuration that'll override the defaults for including the provisioned node as part of an existing cluster setup.

joonas commented 5 months ago

Per @tormath1's suggestion I've added a systemd unit file for wasmcloud and nats-server, this sets a foundation that can be pretty easily extended to then connect the instance to an existing deployment with a configuration file and a couple of additional drop-ins.

For example:

---
variant: flatcar
version: 1.0.0
storage:
  files:
    - path: /opt/extensions/wasmcloud/wasmcloud-0.82.0-x86-64.raw
      contents:
        source: https://github.com/joonas/sysext-bakery/releases/download/latest/wasmcloud-0.82.0-x86-64.raw
    - path: /etc/sysupdate.wasmcloud.d/wasmcloud.conf
      contents:
        source: https://github.com/joonas/sysext-bakery/releases/download/latest/wasmcloud.conf
    - path: /etc/nats-server.conf
      contents:
        inline: |
          jetstream {
            domain: default
          }
          leafnodes {
              remotes = [
                  {
                      url: "tls://connect.cosmonic.sh"
                      credentials: "/etc/nats.creds"
                  }
              ]
          }
    - path: /etc/nats.creds
      contents:
        inline: |
          <redacted>
  links:
    - target: /opt/extensions/wasmcloud/wasmcloud-0.82.0-x86-64.raw
      path: /etc/extensions/wasmcloud.raw
      hard: false
systemd:
  units:
    - name: nats.service
      enabled: true
      dropins:
        - name: 10-environment-override.conf
          contents: |
            [Service]
            Environment=NATS_CONFIG=/etc/nats-server.conf
    - name: wasmcloud.service
      enabled: true
      dropins:
        - name: 10-environment-override.conf
          contents: |
            [Service]
            Environment=WASMCLOUD_LATTICE=<redacted>
    - name: systemd-sysupdate.timer
      enabled: true
    - name: systemd-sysupdate.service
      dropins:
        - name: wasmcloud.conf
          contents: |
            [Service]
            ExecStartPre=/usr/lib/systemd/systemd-sysupdate -C wasmcloud update
        - name: sysext.conf
          contents: |
            [Service]
            ExecStartPost=systemctl restart systemd-sysext

pothos commented 5 months ago

For example:

Can you add the noop.conf and then include this example in the README?

joonas commented 5 months ago

For example:

Can you add the noop.conf and then include this example in the README?

Sure can, are the changes in https://github.com/flatcar/sysext-bakery/pull/54/commits/157bbe25610ad71541e9e4a45d38510bb8ea3aa8 in line with what you were thinking?

joonas commented 5 months ago

Awesome, thanks for helping me get this over the finish line folks! 🎉

flatcar / sysext-bakery