Support for Flatcar Linux about faasd

[ahrkrak]

/usr is read-only in Flatcar Container Linux (like CoreOS):
https://docs.flatcar-linux.org/os/sdk-disk-partitions/

[mdaniel]

Thanks for everyone weighing in; while the mount --bind trick side-steps that one specific issue, it surfaces the next hard-coded path, which would be weirder to bind-mount away[1]:

2020/04/05 19:01:04 Writing to: "/var/lib/faasd/secrets/basic-auth-password"
2020/04/05 19:01:04 Writing to: "/var/lib/faasd/secrets/basic-auth-user"
Error: open /lib/systemd/system/faasd-provider.service: read-only file system

I do appreciate that command-line flags or config files may go against the ethos of "download binary, get faasd" but their flexibility allows the software to work in a lot more situations

I just wanted to report back; I guess for now I'll just hack on the source to fix all the hard-coded paths until it starts to work, and then decide if I've made too much of a mess to PR it :-)

1 = AIUI, customer-provided systemd units should go into /etc/systemd/system or /run/systemd/system likely for this very reason

[alexellis]

/set title: Support for Flatcar Linux

[alexellis]

Hi @mdaniel thank you for your interest.

You'll have to bring me up to speed here, as I don't use that specific distro. What path is used for Flatcar Linux and what would prevent you from creating /usr/local/bin on your Flatcar VM?

Alex

[alexellis]

How would people normally run processes or install software? Does it only run containers, or is there somewhere on the filesystem that's fair game?

[invidian]

Given that this is Container Linux, the recommended way of running things on Flatcar is to use containers. Can faasd be run from e.g. Docker?

An alternative would be, to store the binary in /opt, which is usually used for 3rd party software (the directory does not exist on default installation IIRC).

Then, if path in faasd is hardcoded, one can do a bind mount as a workaround too:

sudo mkdir /opt/bin
sudo mount --bind /opt/bin /usr/local/bin

This can also be automated with Ignition.

[alexellis]

We could accept a PR to install to a specific location. What other issues do you envisage? Perhaps try the bind mount and see if that's enough?

[rata]

If only a binary is needed, I guess no other issues.

opt/bin is on the PATH by default (need to mkdir -p /opt/bin, though). If you can install binaries to any specified location in the PATH, that should work. The bind-mount too, if you can't change the location or prefer that for some reason.

Don't hesitate to write us if you find any other issues :-)

[alexellis]

@mdaniel are you still interested in helping with this? @vbatts do you have any opinions on a solution?

[alexellis]

1 = AIUI, customer-provided systemd units should go into /etc/systemd/system or /run/systemd/system likely for this very reason

Happy to take a PR for that specific change, along with changes to the rest of the repo/terraform and bash.

[alexellis]

Which paths are the offending ones?

I'd like to see: a list of possible solutions, and one preferred solution.

[vbatts]

writing to systemd units to /etc/systemd/system should be a fallback here.
And while I thing the /usr/local/bin bind mount is ugly, it would be nicer to just fallback to /opt/bin

Other options could be overly mounts, but that feels like a one-off, like the bind mounting.
Here's a cloud-init that lays out a unit file to do an overlay https://gist.github.com/vbatts/705c2542df39495319c8601c01b658e8#file-cloud-config-yaml-L17

[alexellis]

What is the ideal way we should deploy a binary and have some state when using Flatcar @vbatts? K3s will be similar in that it has an /etc/ folder and a /var/lib/ folder and a binary in /usr/local/bin/

[rata]

@alexellis sorry for the late response. Not sure I understand your question, var/lib/ and /opt/bin/ can be used for those things. But that was mentioned and I guess you are asking because that doesn't work? If you need more stuff, usually a container is the way to go.