flatcar / sysext-bakery

Recipes for baking systemd-sysext images
Apache License 2.0
73 stars 39 forks source link

Bake K3S #53

Closed gcavalcante8808 closed 7 months ago

gcavalcante8808 commented 8 months ago

Bake K3S as a systemd sysext image.

This PR aims to bake K3S as a systemd sysext and also provide a systemd unit file to manage k3s.

How to use

[ describe what reviewers need to do in order to validate this PR ]

Testing done

[Describe the testing you have done before submitting this PR. Please include both the commands you issued as well as the output you got.]

pothos commented 8 months ago

Thanks! I made some suggestions but overall it's nice. If you also want to have it built in the releases of this repo, you can add it to release_build_versions.txt as k3s-v1.27.11+k3s1 (or whatever version we should use - ideally we add some logic to discover the latest version but we haven't done that yet for other extensions as well).

gcavalcante8808 commented 7 months ago

@pothos Great! Thanks for the updates on the PR and also thanks to accept!

kastl-ars commented 7 months ago

Sorry for the beginner's question, but why does it install to /usr/local/bin/k3s? Is it intended to be usable with the install script from k3s.io that will create the service files and such?

Or is this by principle, because /usr/bin/ should not be modified by sysexts in Flatcar?

pothos commented 7 months ago

/usr/bin/ is the normal place, it's up to the preference of the deployed software/the deployer, like sbin vs bin. In general one can say that /usr/local/ would be good to keep things separated but I don't think it makes a big difference (And might even be more confusing when two same binaries land on the system). With systemd-dissect --mtree one has a reliable way of seeing sysext contents.