diff --git a/content/u/blog/how-to-build-an-openstack-alternative-step-4-adding-a-database/contents.lr b/content/u/blog/how-to-build-an-openstack-alternative-step-4-adding-a-database/contents.lr index e7fb65c..3044ecd 100644 --- a/content/u/blog/how-to-build-an-openstack-alternative-step-4-adding-a-database/contents.lr +++ b/content/u/blog/how-to-build-an-openstack-alternative-step-4-adding-a-database/contents.lr @@ -6,7 +6,7 @@ author: ungleich virtualisation team --- twitter_handle: ungleich --- -_hidden: yes +_hidden: no --- _discoverable: yes --- @@ -16,16 +16,17 @@ Data begins to accumulate body: This time we describe how to -store information in a database. +store information in a database and why we selected etcd as the +primary database. The previous time we described [how to generate MAC -addresses(../how-to-build-an-openstack-alternative-step-3-automating-mac-addresses/), +addresses](../how-to-build-an-openstack-alternative-step-3-automating-mac-addresses/), a key element of uncloud. ## More Data -We know have a couple of running VMs, we want to remember which VMs +We now have a couple of running VMs, we want to remember which VMs are running and also add more information. Who owns a VM? And later also where is the VM running. @@ -36,7 +37,8 @@ The main reason for it is that we don't want to add a single point of failure into uncloud and we don't need guarantees provided by standard SQL. -An alternative we still consider to etcd is postgresql, which also +An alternative we still consider is postgresql. While it is not +inherently distributed (at all), it also supports storing JSON and has quite a sophisticated messaging system. ## Refactoring: phasing in a database diff --git a/content/u/blog/how-to-build-an-openstack-alternative-step-5-metadata-service/contents.lr b/content/u/blog/how-to-build-an-openstack-alternative-step-5-metadata-service/contents.lr new file mode 100644 index 0000000..73698ec --- /dev/null +++ b/content/u/blog/how-to-build-an-openstack-alternative-step-5-metadata-service/contents.lr @@ -0,0 +1,130 @@ +title: How to build an OpenStack alternative: Step 5, adding metadata +--- +pub_date: 2020-01-15 +--- +author: ungleich virtualisation team +--- +twitter_handle: ungleich +--- +_hidden: no +--- +_discoverable: yes +--- +abstract: +Let the VMs get information about themselves +--- +body: + +This time we describe how virtual machines can get information about +themselves like which ssh keys should have access to it. + +The previous time we +[added a data base to +uncloud](../how-to-build-an-openstack-alternative-step-4-adding-a-database/). + +## Motivation + +If we were to start VMs without a metadata service, all of the VMs +would be looking identical and would not be able to know, whom to +allow access to it. + +To customise a VM or to make it usable, we need to tell it who has +access to it and potentially inject even more information. + +## Metadata service: how others do it + +Enters the metadata service. OpenNebula solves this problem quite +nicely by attaching a virtual cdrom to the VMs. That cdrom contains +only one file, `context.sh`. This file contains information about + +* networking +* ssh keys + +OpenStack with cloud-init on the other side uses an HTTP based +service that is found on the address `http://169.254.169.254/`. + +Both schemes come with disadvantages that we don't want to replicate +in uncloud: + +In the opennebula case changing metadata information while the VM is +running requires to create a new CDROM and if that one is still +mounted, the VM might not get the up-to-date information. This is a +bit of a theorethical case, as the metadata is rarely re-used after +booting. + +However changing the information provided in the context.sh inside the +ISO always requires to generate a new ISO. While technical possible, +not very elegant. + +The OpenStack based approach has (from our point of view) a much +bigger problem: it relies on IPv4. VMs running on uncloud primarily +run IPv6 and should function without any IPv4 stack. + +The motivation for using the 169.254.0.0/16 network is clear: it works +without having an IP address management system in place. + +## Solving it the smart way + +So it seems like the general approach of OpenStack/cloud-init is +actually quite elegant, if it wasn't forcing IPv4. + +In the IPv6 world, we always have link local addresses in the +**fe80::/10** network. Should we just replace the OpenStack approach +with IPv6? + +We don't think so, it has the same argument in favor for IPv4 networks +that we have in favor for IPv6 networks. + +Instead, we suggest to add a simple change to the OpenStack approach: +Use http://metadata instead of using an IP address. + +## http://metadata + +So how should this work and why is this better than using +http://169.254.169.254/? + +Using a name, it doesn't matter whether the VM is on an IPv4 ore +IPv6 network. + +Using just the hostname, not an FQDN (i.e. metadata.example.com) makes +it portable. + +The name can be resolved via various methods: + +* uncloud: it will be delivered by DNS +* openstack: either via DNS (like uncloud) or if there is no IPAM, it + can be statically set in /etc/hosts + +In the DNS resolving case, this actually gets even more interesting, +because we can use the **DNS search path**. So while the client tries +to resolve the hostname **metadata**, the underlying resolver library +will also look for **metadata.example.com**, if example.com is in the +search path. + +## uncloud implementation + +In uncloud we have implemented a sample [metadata +service](https://code.ungleich.ch/uncloud/uncloud/tree/master/uncloud/metadata). + +However IPAM (i.e. router advertisements) and DNS servers are not part +of uncloud and can be used from the regular system infrastructure. + +In one of the next versions we plan to include helpers that allow you +to bootstrap IPAM and DNS easily. + + +## Status + +At this point uncloud can create VMs and the VMs can get the ssh keys +that should have access from the metadata service. + +With this latest add-on uncloud gets near the range of a usable +prototype. A lot of things will probably need to be refactored in the +future, but at the moment uncloud supports already: + +* creating VMs (using qemu) +* securing the VM network (using nftables) +* generating unique mac addresses (uncloud python code) +* storing information in a distributed database (using pytho-etcd3 and + etcd) +* providing basic metadata inforamtion (uncloud python code) diff --git a/content/u/blog/uncloud-next b/content/u/blog/uncloud-next index 97f8e1c..5611a04 100644 --- a/content/u/blog/uncloud-next +++ b/content/u/blog/uncloud-next @@ -1,6 +1,9 @@ -- step 4 = database! +x step 4 = database! +- image contextualisation +- dnsmasq - metadata - for getting keys +- user metadata - user authentication - otp or ldap or plain file - for registering keys