diff options
author | Katharina Fey <kookie@spacekookie.de> | 2019-09-09 10:05:38 +0100 |
---|---|---|
committer | Katharina Fey <kookie@spacekookie.de> | 2019-09-09 10:07:31 +0100 |
commit | 0d9c3299bc9db09cb69824f372794ee297953ced (patch) | |
tree | 7678eeb5688ab8f78ded3a780d0211ed8f3d5365 | |
parent | dfb3e28f0ff4df03b190969b07d7d4ffd32a0563 (diff) |
content/blog: refactoring naming/numbering scheme
The idea here being that drafts are prefixed with `xxx_`, not knowing
when and in what order they will be released. This fixes the problem
where I start lots of articles, give them a number, then release them
in non-linear sequences and get confused down the line.
This commit _also_ releases the `nix-ocitools` article
-rw-r--r-- | content/blog/105_allocation.md (renamed from content/blog/106_allocation.md) | 0 | ||||
-rw-r--r-- | content/blog/106_encrypted_zfs.md (renamed from content/blog/107_encrypted_zfs.md) | 0 | ||||
-rw-r--r-- | content/blog/107_usable_gpg.md (renamed from content/blog/108_usable_gpg.md) | 0 | ||||
-rw-r--r-- | content/blog/108_public_inbox.md (renamed from content/blog/110_public_inbox.md) | 0 | ||||
-rw-r--r-- | content/blog/109_nix_ocitools.md | 115 | ||||
-rw-r--r-- | content/blog/xxx_no_google.md | 24 | ||||
-rw-r--r-- | content/blog/xxx_sieve.md (renamed from content/blog/105_sieve.md) | 0 |
7 files changed, 139 insertions, 0 deletions
diff --git a/content/blog/106_allocation.md b/content/blog/105_allocation.md index 4016718..4016718 100644 --- a/content/blog/106_allocation.md +++ b/content/blog/105_allocation.md diff --git a/content/blog/107_encrypted_zfs.md b/content/blog/106_encrypted_zfs.md index 7972466..7972466 100644 --- a/content/blog/107_encrypted_zfs.md +++ b/content/blog/106_encrypted_zfs.md diff --git a/content/blog/108_usable_gpg.md b/content/blog/107_usable_gpg.md index 350f352..350f352 100644 --- a/content/blog/108_usable_gpg.md +++ b/content/blog/107_usable_gpg.md diff --git a/content/blog/110_public_inbox.md b/content/blog/108_public_inbox.md index 88a5e1e..88a5e1e 100644 --- a/content/blog/110_public_inbox.md +++ b/content/blog/108_public_inbox.md diff --git a/content/blog/109_nix_ocitools.md b/content/blog/109_nix_ocitools.md new file mode 100644 index 0000000..c92c358 --- /dev/null +++ b/content/blog/109_nix_ocitools.md @@ -0,0 +1,115 @@ +Title: `ociTools` in NixOS +Category: Blog +Date: 2019-09-09 10:00 +Tags: /dev/diary, NixOS, Containers + +With the release of NixOS 19.09, I thought I wanted to blog about +something that I've been working on, that [recently][0] made it into +`master`, and thus this new stable channel. So I thought, why not blog +about it a bunch. + +[0]: https://github.com/NixOS/nixpkgs/pull/56411 + +## What are OCI tools? + +[Open Container Initiative][1] (or OCI) is a spec that standardised what +format containers should use. It is implemented by a bunch of runners, +such as `runc` (the Docker/ standard Kubernetes backend) and `railcar` +(more to that later) and outlines in exactly what format a containers +metadata and filesystem are to be stored, so to achieve the largest +possible reusability. + +[1]: https://www.opencontainers.org/ + +The spec is pretty [long][3] and in some places not very +great. There's even a [blog post][4] from Oracle, talking about how +implementing an OCI runner in Rust made them find bugs in the +specification. + +[3]: https://github.com/opencontainers/runtime-spec +[4]: https://blogs.oracle.com/developers/building-a-container-runtime-in-rust + +## What are `ociTools`? + +So now the question is, what does that have to do with +NixOS/`nixpkgs`. The answer is simple: I wanted to be able to +containerise single applications on my server, without requiring a +container daemon (such as docker) or relying on externally built +"Docker containers" from a registry. + +So, `ociTools.buildContainer` was recently merged into `nixpkgs` +`master`, allowing you to do exactly that. It's usage is farely +straight forward: + +```nix +with pkgs; ociTools.buildContainer { + args = [ + (writeShellScript "run.sh" '' + ${hello}/bin/hello -g "Hello from OCI container!" + '').outPath + ]; +} +``` + +The `args` parameter refers to a list of paths and arguments that are +handed to a container runner to run as init. In this case it's +creating a shell script with some commands in it, then getting the +output derivation path. + +There's other options available, such as the `os`, `arch` and +`readonly` flags (which aren't very interesting and have sane +defaults). Additionally to that there's `mounts`. + +Simply specify any bind-mount you wish to setup at container init in a +similar way you would describe your filesystem with `nix` already: + +```nix +with pkgs; ociTools.buildContainer { + args = [ + (writeShellScript "run.sh" '' + ${hello}/bin/hello -g "Hello from OCI container!" + '').outPath + ]; + mounts."/data" = { + source = "/var/lib/mydata"; + }; +} +``` + +## Railcar + ociTools + +So that's all nice and good. But what about actually running these +containers. Well, as I previously said I didn't want to have a +dependency on a management daemon such as `docker`. Instead, I also +added a module for the afromentioned `railcar` container runner +(Oracle please merge my PR, thank you). + +It wraps very cleanly around `ociTools` and generates `systemd` units +to start containers, restarting them if they crash. This way you can +express applications purely in `nix`, give them access to only the +things they need, and be sure that their configuration is in line with +the rest of your system rebuild. + +```nix +services.railcar = { + enable = true; + containers = { + "hello" = { + cmd = '' + ${pkgs.hello}/bin/hello -g "Hello railcar!" + ''; + }; + }; +}; +``` + +The metadata interface for `mounts`, etc is the same for `railcar` as +for `ociTools`. + +Anyway, I hope you enjoy. There is definitely things to improve, +especially considering the vastness of the OCI spec. Plus, at the +moment `ociTools` does require a bunch of manual setup work for an +application to function, if it, say, runs a webserver. It would be +cool if some NixOS modules could be re-used to make this configuration +easier. But I'm sure someone else is gonna have fun figuring that out +x) diff --git a/content/blog/xxx_no_google.md b/content/blog/xxx_no_google.md new file mode 100644 index 0000000..c7c0506 --- /dev/null +++ b/content/blog/xxx_no_google.md @@ -0,0 +1,24 @@ +Title: No, I won't work at Google +Category: Blog +Tags: ethics +Date: 2019-07-28 + +Once in a while (about every 6-9 months or so), I get an e-mail like this in my inbox: + +> Hi Katherina, +> +> Hope you are doing well. I'm a tech sourcer with Google working on the +> expansion of our Europe software engineering teams. I came across your +> linkedin and github profiles and I'm interested in finding more about your +> experience. Would you be open having a quick formal chat about our current +> teams and projects we have across Europe to see if there's anything that +> may interest you? + +I always send the same polite decline, wishing them a nice day. +And a few months later, someone else will e-mail me the exact same question. + + +I know that a few years ago, when Google first reached out to me to ask me +if I was interested in working for them, I was quite excited about the idea. +Since then a lot of things have changed, including my attitudes towards +big companies, and Google in particular. diff --git a/content/blog/105_sieve.md b/content/blog/xxx_sieve.md index 533ff72..533ff72 100644 --- a/content/blog/105_sieve.md +++ b/content/blog/xxx_sieve.md |