aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorKatharina Fey <kookie@spacekookie.de>2019-09-09 10:05:38 +0100
committerKatharina Fey <kookie@spacekookie.de>2019-09-09 10:07:31 +0100
commit0d9c3299bc9db09cb69824f372794ee297953ced (patch)
tree7678eeb5688ab8f78ded3a780d0211ed8f3d5365
parentdfb3e28f0ff4df03b190969b07d7d4ffd32a0563 (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.md115
-rw-r--r--content/blog/xxx_no_google.md24
-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