How do we reduce duplication of installation steps? about faasd HOT 8 CLOSED

I've created a first bash script to install faasd: https://gist.github.com/jsiebens/d623dee59da35f5f28c03b49f057a772
Tested on latest Raspois, Ubuntu 16/18/20, Debian 10 and CentOS 7/8

For Debian 10, I had to use containerd 1.3.7
On CentOS 8, the script is working, but I'm having some troubles with running faasd.

arm64 is not yet supported, because a version of containerd is not yet available for that platform.

from faasd.

A centralized bash script could already be a step forward. Installing containerd will be the most interesting part, because it is not available for every architecture (like armhf, arm64)

When I was working on the images, I was thinking about a similar tool like inletsctl or k3sup, a lightweight binary to install faasd.

Something else I noticed when creating the images: although one can simply download the faasd binary, you still have to clone the git repository to get some files, like the docker-compose.yml file. Is it an option to bundle all those files, together with the binary, in e.g. a zip artifact?

from faasd.

Having a platform-agnostic way to install faasd would be great, and I don't see any better way than a bash script at this point. That would be a great way to improve the installation experience.

I also agree with @jsiebens regarding the installation steps. Would be better if one can get all needed files without cloning the git repo.

Something else crossed my mind, we always need to keep updating the installation docs(or cloud-config templates) to fetch the latest version of faasd, would it possible to use a single link that always points to the latest faasd release? 🤔

from faasd.

@LucasRoesler has already done some work on embedding the config assets -> #78

from faasd.

It seems reasonable that faasd should know how to completely install itself.

Perhaps we can create a "staging" folder where all of the components need to install faasd are put. Then faasd can embed static assets and generate into this folder. Additionally, it can also have the download urls for the confirmed working dependencies, which it can also download into that folder. The user can then modify or update any of the files/binaries in that folder and then faasd can install them to the the correct location. Something like

faasd generate/init
faasd install

or if someone just wants the default, e.g. for a demo, install can call generate automatically (if the folder is empty/doesn't exist), so just

faasd install

If you want more flexibility, you could allow some of the values (for example, the containerd version) via env variables of flags to the generate/init command

from faasd.

Thanks @mehyedes and @jsiebens for the comments

Having a platform-agnostic way to install faasd would be great, and I don't see any better way than a bash script at this point. That would be a great way to improve the installation experience.

I'd agree that bash is portable enough to be used, and faasd can only really be installed on Linux anyway. The other option is to have the faasd binary do some of the bootstrap itself, I think @LucasRoesler hinted at that.

I also agree with @jsiebens regarding the installation steps. Would be better if one can get all needed files without cloning the git repo.

You can fetch files without cloning a repo, we already do that for the containerd.service, you can also specify a tag, like we do there.

https://github.com/openfaas/faasd/blob/master/cloud-config.txt#L13

Something else crossed my mind, we always need to keep updating the installation docs(or cloud-config templates) to fetch the latest version of faasd, would it possible to use a single link that always points to the latest faasd release? 🤔

I agree that a deliberate choice needs to be made to update the cloud-init / terraform file, but the answer may be removing duplication, instead of always using the latest version available. We all know that using the :latest tag with Docker is an anti-pattern, so why would we do that with the faasd installation?

@jsiebens

A centralized bash script could already be a step forward. Installing containerd will be the most interesting part, because it is not available for every architecture (like armhf, arm64)

containerd needs to be built from source, and there is a script to do that, or the binaries that I've made available can be used.

With bash it's easy to determine the architecture and then to pull in binaries from one location, or another, but that's harder to do with cloudinit steps.

https://github.com/alexellis/containerd-armhf/

Is it an option to bundle all those files, together with the binary, in e.g. a zip artifact?

It would be reasonable for the various files to be distributed in an archive along with the faasd binary. Moving from faasd to faasd.tar.gz, another approach is the idea of embedding resources within the binary.

I think that the path of least resistance would be to start with a shell script. The script should install everything we need, and if we think it's useful, also set up Caddy through some sort of if statement / selector. It also seems like having a pre-generated password vs. dynamic is a requirement of the way we're using terraform now.

Any remaining tasks that are only needed for the terraform bootstrap, could remain in a separate cloud-init file.

from faasd.

Here's a corresponding armhf binary for containerd v1.3.5 https://github.com/alexellis/containerd-armhf/releases/tag/v1.3.5

from faasd.

Sorry I missed this. How about Caddy as a parameter override?

from faasd.