summaryrefslogtreecommitdiff
path: root/static/src/_posts
diff options
context:
space:
mode:
Diffstat (limited to 'static/src/_posts')
-rw-r--r--static/src/_posts/2021-04-22-composing-processes-into-a-static-binary-with-nix.md1
-rw-r--r--static/src/_posts/2021-09-22-building-appimages-with-nix.md267
2 files changed, 268 insertions, 0 deletions
diff --git a/static/src/_posts/2021-04-22-composing-processes-into-a-static-binary-with-nix.md b/static/src/_posts/2021-04-22-composing-processes-into-a-static-binary-with-nix.md
index 885d56b..ebc0f7b 100644
--- a/static/src/_posts/2021-04-22-composing-processes-into-a-static-binary-with-nix.md
+++ b/static/src/_posts/2021-04-22-composing-processes-into-a-static-binary-with-nix.md
@@ -3,6 +3,7 @@ title: >-
Composing Processes Into a Static Binary With Nix
description: >-
Goodbye, docker-compose!
+tags: tech
---
It's pretty frequent that one wants to use a project that requires multiple
diff --git a/static/src/_posts/2021-09-22-building-appimages-with-nix.md b/static/src/_posts/2021-09-22-building-appimages-with-nix.md
new file mode 100644
index 0000000..956f912
--- /dev/null
+++ b/static/src/_posts/2021-09-22-building-appimages-with-nix.md
@@ -0,0 +1,267 @@
+---
+title: >-
+ Building AppImages with Nix
+description: >-
+ With some process trees thrown in there for fun.
+series: nebula
+tags: tech
+---
+
+It's been a bit since I've written an update on the cryptic nebula project,
+almost 5 months (since [this post][lastnix], which wasn't officially part of the
+blog series but whatever). Since then it's switched names to "cryptic-net", and
+that we would likely use [MinIO](https://min.io/) as our network storage
+service, but neither of those is the most interesting update.
+
+The project had been stalled because of a lack of a build system which could
+fulfill the following requirements:
+
+* Network configuration (static IP, VPN certificates) of individual hosts is
+ baked into the binary they run.
+
+* Binaries are completely static; no external dependencies need to exist on the
+ host in order to run them.
+
+* Each binary runs a composition of multiple sub-services, each being a separate
+ sub-process, and all of them having been configured to work together (with
+ some possible glue code on our side) to provide the features we want.
+
+* The builder itself should be deterministic; no matter where it runs it should
+ produce the same binary given the same input parameters.
+
+Lacking such a build system we're not able to distribute the program in a way
+which "just works"; it would require some kind of configuration, or some kind of
+runtime environment to be set up, both of which would be a pain for users. And
+lacking a definite build system makes it difficult to move forward on any other
+aspect of a project, as it's not clear what may need to be redone in the future
+when the build system is decided upon.
+
+## Why not nix-bundle?
+
+My usage of [nix-bundle][nix-bundle] in a [previous post][lastnix] was an
+attempt at fulfilling these requirements. Nix in general does very well in
+fulfilling all but the second requirement, and nix-bundle was supposed to
+fulfill even that by packaging a nix derivation into a static binary.
+
+And all of this it did! Except that the mechanism of nix-bundle is a bit odd.
+The process of a nix-bundle'd binary jails itself within a chroot, which it then
+uses to fake the `/nix/store` path which nix built binaries expect to exist.
+
+This might work in a lot of cases, but it did not work in ours. For one, [nebula
+can't create its network interface when run from inside
+nix-bundle's chroot][nix-bundle-issue]. For another, being run in a chroot means
+there's going to be strange restrictions on what our binary is able to do and
+not.
+
+## AppImage
+
+What we really needed was an [AppImage][appimage]. AppImages are static binaries
+which can bundle complex applications, even those which don't expect to be
+bundled into single binaries. In this way the end result is the same as
+nix-bundle, but the mechanism AppImage uses is different and places far fewer
+restrictions on what we can and can't do with our program.
+
+## Building Sub-Services Statically with Nix
+
+It's probably possible to use nix to generate an AppImage which has the
+`/nix/store` built into it, similar to what nix-bundle does, and therefore not
+worry about whether the binaries it's bundling are static or not. But if your
+services are written in sane languages it's not that difficult to build them
+statically and dodge the issue.
+
+For example, here is how you build a go binary statically:
+
+```
+{
+ buildGoModule,
+ fetchFromGitHub,
+}:
+ buildGoModule rec {
+ pname = "nebula";
+ version = "1.4.0";
+
+ src = fetchFromGitHub {
+ owner = "slackhq";
+ repo = pname;
+ rev = "v${version}";
+ sha256 = "lu2/rSB9cFD7VUiK+niuqCX9CI2x+k4Pi+U5yksETSU=";
+ };
+
+ vendorSha256 = "p1inJ9+NAb2d81cn+y+ofhxFz9ObUiLgj+9cACa6Jqg=";
+
+ doCheck = false;
+
+ subPackages = [ "cmd/nebula" "cmd/nebula-cert" ];
+
+ CGO_ENABLED=0;
+ tags = [ "netgo" ];
+ ldflags = [
+ "-X main.Build=${version}"
+ "-w"
+ "-extldflags=-static"
+ ];
+ };
+```
+
+And here's how to statically build a C binary:
+
+```
+{
+ stdenv,
+ glibcStatic, # e.g. pkgs.glibc.static
+}:
+ stdenv.mkDerivation rec {
+ pname = "dnsmasq";
+ version = "2.85";
+
+ src = builtins.fetchurl {
+ url = "https://www.thekelleys.org.uk/dnsmasq/${pname}-${version}.tar.xz";
+ sha256 = "sha256-rZjTgD32h+W5OAgPPSXGKP5ByHh1LQP7xhmXh/7jEvo=";
+ };
+
+ nativeBuildInputs = [ glibcStatic ];
+
+ makeFlags = [
+ "LDFLAGS=-static"
+ "DESTDIR="
+ "BINDIR=$(out)/bin"
+ "MANDIR=$(out)/man"
+ "LOCALEDIR=$(out)/share/locale"
+ ];
+ };
+```
+
+The derivations created by either of these expressions can be plugged right into
+the `pkgs.buildEnv` used to create the AppDir (see AppDir section below).
+
+## Process Manager
+
+An important piece of the puzzle for getting our nebula project into an AppImage
+was a process manager. We need something which can run multiple service
+processes simultaneously, restart processes which exit unexpectedly, gracefully
+handle shutting down all those processes, and coalesce the logs of all processes
+into a single stream.
+
+There are quite a few process managers out there which could fit the bill, but
+finding any which could be statically compiled ended up not being an easy task.
+In the end I decided to see how long it would take me to implement such a
+program in go, and hope it would be less time than it would take to get
+`circus`, a python program, bundled into the AppImage.
+
+2 hours later, [pmux][pmux] was born! Check it out. It's a go program so
+building it looks pretty similar to the nebula builder above, so I won't repeat
+it. However I will show the configuration we're using for it within the
+AppImage, to show how it ties all the processes together:
+
+```yaml
+processes:
+ - name: nebula
+ cmd: bin/nebula
+ args:
+ - "-config"
+ - etc/nebula/nebula.yml
+
+ - name: dnsmasq
+ cmd: bin/dnsmasq
+ args:
+ - "-d"
+ - "-C"
+ - ${dnsmasq}/etc/dnsmasq/dnsmasq.conf
+```
+
+## AppDir -> AppImage
+
+Generating an AppImage requires an AppDir. An AppDir is a directory which
+contains all files required by a program, rooted to the AppDir. For example, if
+the program expects a file to be at `/etc/some/conf`, then that file should be
+places in the AppDir at `<AppDir-path>/etc/some/conf`.
+
+[These docs](https://docs.appimage.org/packaging-guide/manual.html#ref-manual)
+were very helpful for me in figuring out how to construct the AppDir. I then
+used the `pkgs.buildEnv` utility to create an AppDir derivation containing
+everything the nebula project needs to run:
+
+```
+ appDir = pkgs.buildEnv {
+ name = "my-AppDir";
+ paths = [
+
+ # real directory containing non-built files, e.g. the pmux config
+ ./AppDir
+
+ # static binary derivations shown previously
+ nebula
+ dnsmasq
+ pmux
+ ];
+ };
+```
+
+Once the AppDir is built one needs to use `appimagetool` to turn it into an
+AppImage. There is an `appimagetool` build in the standard nixpkgs, but
+unfortunately it doesn't seem to actually work...
+
+Luckily nix-bundle is working on AppImage support, and includes a custom build
+of `appimagetool` which does work!
+
+```
+{
+ fetchFromGitHub,
+ callPackage,
+}: let
+ src = fetchFromGitHub {
+ owner = "matthewbauer";
+ repo = "nix-bundle";
+ rev = "223f4ffc4179aa318c34dc873a08cb00090db829";
+ sha256 = "0pqpx9vnjk9h24h9qlv4la76lh5ykljch6g487b26r1r2s9zg7kh";
+ };
+in
+ callPackage "${src}/appimagetool.nix" {}
+```
+
+Using `callPackage` on this expression will give you a functional `appimagetool`
+derivation. From there's it's a simple matter of writing a derivation which
+generates the AppImage from a created AppDir:
+
+```
+{
+ appDir,
+ appimagetool,
+}:
+ pkgs.stdenv.mkDerivation {
+ name = "program-name-AppImage";
+
+ src = appDir;
+ buildInputs = [ appimagetool ];
+ ARCH = "x86_64"; # required by appimagetool
+
+ builder = builtins.toFile "build.sh" ''
+ source $stdenv/setup
+ cp -rL "$src" buildAppDir
+ chmod +w buildAppDir -R
+ mkdir $out
+
+ # program-name needs to match the desktop file in the AppDir
+ appimagetool program-name "$out/program-name-bin"
+ '';
+ }
+```
+
+Running that derivation deterministically spits out a binary at
+`result/program-name-bin` which can be executed and run immediately, on any
+system using the same CPU architecture.
+
+## Fin
+
+I'm extremely hyped to now have the ability to generate binaries for our nebula
+project that people can _just run_, without them worrying about which
+sub-services that binary is running under-the-hood. From a usability perspective
+it's way nicer than having to tell people to "install docker" or "install nix",
+and from a dev perspective we have a really solid foundation on which to build a
+quite complex application.
+
+[lastnix]: {% post_url 2021-04-22-composing-processes-into-a-static-binary-with-nix %}
+[nix-bundle]: https://github.com/matthewbauer/nix-bundle
+[nix-bundle-issue]: https://github.com/matthewbauer/nix-bundle/issues/78
+[appimage]: https://appimage.org/
+[pmux]: https://github.com/cryptic-io/pmux