commit 3568728baca823b59d6c49a9dd43ea222ea215a9
parent 95ae9fdbed45b7fe56c6f095c0d9f45ba0b167c5
Author: Paco Esteban <paco@e1e0.net>
Date: Fri, 5 Jun 2020 17:44:38 +0200
update "manage k8s from openbsd" article
we now have kubectl in ports
Diffstat:
2 files changed, 150 insertions(+), 3 deletions(-)
diff --git a/src/easy-dns-zone-management-accross-providers.md b/src/easy-dns-zone-management-accross-providers.md
@@ -0,0 +1,142 @@
+# Easy DNS zone management across providers
+2020-05-31
+
+For personal projects and at work I have to manage some DNS zones. They are
+not that many, but I would say that if they are more than 2 or 3, or if the
+management interface is not _extremely_ easy and comfortable, a way to automate
+this process as much as possible is really beneficial.
+
+There are many alternatives out there, like Github's [Octodns][1] or
+StackExchange's [dnscontrol][2]. I personally use the latter.
+
+Using tools like these bring a couple of benefits. For one, you can have your
+DNS zones under version control. Ok, you can do that too with BIND zone files.
+But it's more difficult to do that if you use one of the _"cloud providers"_ as
+I do at work. Another benefit is that you can wire this with your CI platform
+of choice. Again, BIND zones are pretty good at this too. Rsync + reload and
+you're set. This is the magic of *the Unix way*. Problem is that one cannot
+always choose what one works with, but I digress.
+
+Dnscontrol is both a [DSL][3] and a cli tool that interprets that and takes the
+appropriate actions to ensure that your zones are a reflection of what you have
+on disk. Be that API calls to your fancy provider or interactions with
+ISC-BIND to update the zones on the fly.
+
+It's written in Go, so good for your fancy container life and supports a fairly
+comprehensive list of providers.
+
+It also has the ability to export your current zones to dnscontrol's DSL, so
+migration is easy.
+
+And finally, it can be used to issue LetsEncrypt certificates.
+
+The main problem for me is that the configuration file is JavaScript (or
+something pretty similar). Yes, I facepalmed too.
+
+But, a part from that, is really simple to use and pretty fast.
+
+I personally only tested it against `GANDI` and Amazon's `R53`, but I assume it
+works the same way for other providers. There's a fairly good documentation on
+their website.
+
+What I put here are some notes on a basic setup. The installation process can
+take many paths depending on what you want. So take a look at their
+documentation. There's a port for OpenBSD, so that's what I used.
+
+Create a folder that will contain all your zone info and credentials to access
+your providers. Remember to ignore the credentials file in your version
+control system of choice.
+
+The credentials file is called `creds.js` by default, but can be anything.
+You'll have to pass some info to the cli if you do not use the default. It
+looks like this:
+
+```
+{
+ "gandi": {
+ "apikey": "super-secret-api-key"
+ },
+ "r53": {
+ "KeyId": "super-secret-key-id",
+ "SecretKey": "super-secret-secret-key"
+ }
+}
+```
+
+The main file, which describes your zones, it's called `dnsconfig.js` by
+default and looks like this:
+
+```
+// Providers:
+
+var REG_NONE = NewRegistrar('none', 'NONE'); // No registrar.
+var GANDI = NewDnsProvider("gandi", "GANDI_V5"); // Gandi.
+
+// Domains:
+
+D("example.com", REG_NONE, DnsProvider(GANDI),
+ A('@', '100.100.100.100', TTL(86400)),
+ AAAA('@', '2000:abc:dead:beef::1', TTL(86400)),
+ CAA('@', 'issue', 'letsencrypt.org'),
+ MX('@', 10, 'mail01.example.com.'),
+ TXT('@', 'v=spf1 a mx ~all'),
+ SRV('_xmpp-client._tcp', 5, 0, 5222, 'example.com.', TTL(86400)),
+ SRV('_xmpp-server._tcp', 5, 0, 5269, 'example.com.', TTL(86400)),
+ A('main', '100.100.100.200', TTL(86400)),
+ CNAME('foo', 'example.com.', TTL(600)),
+ CNAME('bar', 'main.example.com.', TTL(600))
+);
+```
+
+As you can see, first there's the provider definition. The `REG_NONE` line is
+there to define an "empty registrar". I do this because my zones are already
+registered with my providers, but you could create the zone and register it
+automatically if all your config is correct.
+
+In fact, the only required parameters to the `D` function are the `fqdn` and
+the registrar.
+
+Each domain has its `D` function that defines it. I usually organize it like
+you see on the example. With the 1st line containing the `fqdn`, registrar and
+dns provider, and then one line per DNS record. That makes a lot of sense for
+visually clean diffs later on. But you can use whatever you want as long as
+you respect the syntax.
+
+There's a complete description list of the DSL functions and modifiers at the
+[language reference][4] section of their website.
+
+Once you have your zones defined, execute `dnscontrol preview`. I would
+recommend to set the records as you have them if the zone already exists (more
+on this later). In that case the output should be similar to this:
+
+```
+******************** Domain: example.com
+----- Getting nameservers from: gandi
+----- DNS Provider: gandi...0 corrections
+----- Registrar: none...0 corrections
+```
+
+When you have changes it may look similar to this:
+
+```
+******************** Domain: example.com
+----- Getting nameservers from: gandi
+----- DNS Provider: gandi...2 corrections
+#1: CREATE CNAME blah.example.com foo.duckdns.org. ttl=600
+#2: MODIFY CNAME bar.example.com: (main.example.com. ttl=600) -> (abc.duckdns.org. ttl=600)
+----- Registrar: none...0 corrections
+```
+
+To actually apply the changes, execute `dnscontrol push`
+
+You can specify the location of the credentials file and the zones file using
+`--creds file` and `--config file`. Check the command help for more
+information.
+
+_Have any comments ? Send an email to the [comments address][999]._
+
+[1]: https://github.com/github/octodns
+[2]: https://stackexchange.github.io/dnscontrol/
+[3]: https://en.wikipedia.org/wiki/Domain-specific_language
+[4]: https://stackexchange.github.io/dnscontrol/js
+[999]: mailto:comments@e1e0.net?Subject=Easy%20DNS%20zone%20management%20across%20providers
diff --git a/src/manage-k8s-from-openbsd.md b/src/manage-k8s-from-openbsd.md
@@ -5,6 +5,9 @@ _This should work with OpenBSD `6.7`. I write this while the source tree is
locked for release, so even if I use `-current` this is as close as `-current`
gets to `-release`_
+_Update 2020-06-05: we now have [a port for kubectl][6]. So, at least in
+`-current` things get a bit easier._
+
## Intro
Some of us have to suffer the pain of the trendy tech and the buzzwords even
@@ -72,9 +75,10 @@ Later on you can change projects with:
## kubectl
-There's no port for `kubectl` (yet, if you want to step in, I promise to test
-it, give feedback and maybe even commit it !), but it can be compiled and
-installed manually.
+There's no port for `kubectl` ~~(yet, if you want to step in, I promise to test
+it, give feedback and maybe even commit it !),~~ on `6.7` but it can be compiled and
+installed manually. We have [a port now on -current][6] thanks to
+Karlis Mikelsons and _@kn_.
I assume that you have a Go environment working.
@@ -176,4 +180,5 @@ _Have any comments ? Send an email to the [comments address][999]._
[3]: https://github.com/bitnami-labs/sealed-secrets
[4]: https://cloud.google.com/sdk/docs/quickstart-linux#initialize_the_sdk
[5]: https://kustomize.io
+[6]: https://marc.info/?l=openbsd-ports-cvs&m=159136413409093&w=2
[999]: mailto:comments@e1e0.net?Subject=Manage%20Kubernetes%20from%20OpenBSD
