Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add wasmCloud recipe #54

Merged
merged 4 commits into from
Apr 11, 2024
Merged

Add wasmCloud recipe #54

merged 4 commits into from
Apr 11, 2024

Conversation

joonas
Copy link
Contributor

@joonas joonas commented Apr 9, 2024

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:

  1. 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.
  2. 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
Copy link
Member

t-lo commented Apr 9, 2024

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!

Copy link
Member

@t-lo t-lo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, @pothos , @tormath1 do you think we can merge?

@tormath1
Copy link
Contributor

tormath1 commented Apr 9, 2024

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:

{ echo "[Unit]"; echo "Upholds=kubelet.service"; } > "${SYSEXTNAME}/usr/lib/systemd/system/multi-user.target.d/10-kubelet-service.conf"
)

@joonas
Copy link
Contributor Author

joonas commented Apr 9, 2024

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:

{ echo "[Unit]"; echo "Upholds=kubelet.service"; } > "${SYSEXTNAME}/usr/lib/systemd/system/multi-user.target.d/10-kubelet-service.conf"

)

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 joonas force-pushed the add-wasmcloud-support branch from f401413 to ec7a7ef Compare April 9, 2024 20:20
@joonas
Copy link
Contributor Author

joonas commented Apr 9, 2024

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

create_wasmcloud_sysext.sh Outdated Show resolved Hide resolved
create_wasmcloud_sysext.sh Outdated Show resolved Hide resolved
joonas and others added 2 commits April 9, 2024 21:24
@pothos
Copy link
Member

pothos commented Apr 10, 2024

For example:

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

@joonas
Copy link
Contributor Author

joonas commented Apr 10, 2024

For example:

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

Sure can, are the changes in 157bbe2 in line with what you were thinking?

README.md Outdated Show resolved Hide resolved
@joonas joonas force-pushed the add-wasmcloud-support branch from 157bbe2 to ef31043 Compare April 10, 2024 14:29
@pothos pothos merged commit c699a22 into flatcar:main Apr 11, 2024
@joonas
Copy link
Contributor Author

joonas commented Apr 11, 2024

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants