faasd
faasd copied to clipboard
Support for Flatcar Linux
Expected Behaviour
faasd install
does whatever it was trying to do without error
Current Behaviour
# faasd install
2020/04/05 00:27:02 Writing to: "/var/lib/faasd/secrets/basic-auth-password"
2020/04/05 00:27:02 Writing to: "/var/lib/faasd/secrets/basic-auth-user"
Error: unable to stat /usr/local/bin/faasd, install this binary before continuing
Possible Solution
Instead of hard-coding the path, do the golang equivalent of the_file="$(cd $(dirname "$0") && pwd)/$(basename "$0")"
is
Steps to Reproduce (for bugs)
-
vagrant install vagrant-ignition
-
copy the
Vagrantfile
below into the current directory -
vagrant up
- observe the
faasd install
error
# Vagrantfile
Vagrant.configure("2") do |config|
config.vm.box = "flatcar-stable"
config.vm.box_url = "https://stable.release.flatcar-linux.net/amd64-usr/current/flatcar_production_vagrant_virtualbox.json"
config.vm.network "private_network", ip: "192.168.33.100"
config.ignition.enabled = true
$script = <<'SCRIPT'
set -ex
curl -fSLs "https://github.com/openfaas/faasd/releases/download/0.8.1/faasd" --output "./faasd" && chmod a+x "./faasd"
touch resolv.conf
touch prometheus.yml
./faasd install
SCRIPT
config.vm.provision :shell, inline: $script
end
Context
I was just interested in running faasd
to see what it was like, and our fleet of machines is already running containerd
on Flatcar
Your Environment
-
OS and architecture:
-
Versions:
$ uname -a
Linux localhost 4.19.107-flatcar #1 SMP Thu Mar 26 19:48:36 -00 2020 x86_64 Intel(R) Core(TM) i7 CPU M 620 @ 2.67GHz GenuineIntel GNU/Linux
$ cat /etc/os-release
NAME="Flatcar Container Linux by Kinvolk"
ID=flatcar
ID_LIKE=coreos
VERSION=2345.3.1
VERSION_ID=2345.3.1
BUILD_ID=2020-03-26-2026
PRETTY_NAME="Flatcar Container Linux by Kinvolk 2345.3.1 (Rhyolite)"
ANSI_COLOR="38;5;75"
HOME_URL="https://flatcar-linux.org/"
BUG_REPORT_URL="https://issues.flatcar-linux.org"
FLATCAR_BOARD="amd64-usr"
/set title: Support for Flatcar Linux
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
/usr is read-only in Flatcar Container Linux (like CoreOS): https://docs.flatcar-linux.org/os/sdk-disk-partitions/
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?
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.
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?
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 :-)
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
@mdaniel are you still interested in helping with this? @vbatts do you have any opinions on a solution?
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.
Which paths are the offending ones?
I'd like to see: a list of possible solutions, and one preferred solution.
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
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/
@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.