Lior Kesos July 19, 2022
01:05:25 PM
Lior Kesos Lior KesosThis is the second part of our Open Cloud Adventures Series. You can view the previous part ‘Open Cloud Adventures: Introduction’ to get a general idea of what a cloud is and what we aim to do.
Make sure to check out the official documentation if you have questions that are not answered in this post. Keep in mind that the documentation is version specific. So make sure you know the version of MAAS you’ve installed and look closely at the documentation to see the URL matches. Oftentimes you can modify the URL with the correct version of MAAS so that it takes you to the documentation for your version.
We are using this guide as a general guideline for getting our cloud up and running.
MAAS (Metal as a Service) is thus named, mainly for its ability to manage and provision physical nodes. Despite the focus on this ability, MAAS handles virtual nodes just fine.
MAAS fulfills the following tasks among others:
After conducting some research we learned that MAAS is comprised of two essential components: MAAS region controller and MAAS rack controller.
Some of the main jobs of a MAAS region controller are to provide DNS and to serve the web interface of MAAS to users and the web API of MAAS to Cloud Deployers such as Juju.
A region controller consists of:
A region controller can be thought of as being responsible for a data centre, or a single region.
MAAS rack controllers on the other hand are responsible for detecting new nodes via PXE boot requests within a Layer 2 network (Broadcast Domain) and providing boot images to those new nodes through the commissioning process.
A rack controller provides:
Basically, one or more Rack Controllers act as an agents for a specific network on behalf of the Region Controller in that region and users and Cloud Deployers access nodes on the Rack Controller managed networks through the Region Controller because that’s where the API is.
For a more in depth explanation of how MAAS works, check out the official documentation.
Because of MAAS’s modular structure, it is possible to install a Rack Controller on each network gateway and connect them all to the Region Controller for a region.
However, since we are only trying to understand how MAAS works, we installed the Region Controller and Rack Controller on the same machine.
In order to install our MAAS test environment, we required the following:
As we looked for hardware to install our Cloud Provider on, we discovered 6 working NUCs left over from a training workshop. These are small computers designed for basic workstations and definitely not designed for a full deployment of a cloud. Nevertheless, they are neat little computers with adequate resources for a test installation.
We knew that we would require at least one private network for MAAS to operate properly, so we went out and bought a simple 8-port switch to be used in our experiments.
First, we allocated one physical node to become our MAAS host and installed Ubuntu 16.04 on it.
Since MAAS detects PXE (network) boot requests on the subnet it controls and PXE requires DHCP (which can optionally run on the MAAS host), we needed to first define a network in a separated broadcast domain without any other DHCP servers running on it, so as not to cause a DHCP conflict.
Since our router (like most modern routers) runs a DHCP server by default and we did not want the headache of configuring our existing DHCP to work with MAAS, we simply created a new subnet on a network interface that is completely isolated from our router subnet (on a different broadcast domain)
This is not a problem, since MAAS can be configured to handle DHCP all by itself and it can also handle DNS.
When we were finished, we added the following lines:
/etc/network/interfaces
# designate one wired connection to become the gateway for a private network for nodes to live on.
auto eth0
iface eth0 inet static#the ip of this MAAS node which serves as the network gateway
address 10.222.0.1# details of the MAAS private network
network 10.222.0.0
netmask 255.255.255.0
broadcast 10.222.0.255 # rules to allow traffic to the internet
post-up /sbin/iptables -t nat -A POSTROUTING -o wlan0 -j MASQUERADE
post-up /sbin/iptables -A FORWARD -i eth0 -o wlan0 -j ACCEPT
post-up /sbin/iptables -A FORWARD -i wlan0 -o eth0 -j ACCEPT
post-down /sbin/iptables -t nat -D POSTROUTING -o wlan0 -j MASQUERADE
post-down /sbin/iptables -D FORWARD -i eth0 -o wlan0 -j ACCEPT
post-down /sbin/iptables -D FORWARD -i wlan0 -o eth0 -j ACCEPT
Note the lines on the bottom which automatically configure iptables on ifup and ifdown. These lines need not be here, and we could configure iptables to load rules automatically in whichever way we want.
eth0: is our Wired interface which is connected directly to a switch and has no connection directly to the Internet default gateway.
wlan0: is our connection interface, through which we connect to the internet.
10.222.0.0/24This is the network we chose to be our arbitrary subnet. But you can choose whichever subnet that you want.
We logged in to the node that we allocated and configured in the previous step and installed MAAS by following these steps:
sudo apt-add-repository -yu ppa:maas/stableSince we are installing both maas-rack-controller and maas-region-controller on the same machine, we install the maas meta-package which automatically installs them both.
sudo apt-get updatesudo apt-get install maas
Once the installation is completed, we made sure that MAAS is installed onto the correct IP, by visiting that ip in our browser: ie: https://10.222.0.1/MAAS
To be sure that MAAS was configured to use the right IP we reconfigured it.
First we reconfigure the Rack Controller which contains the API endpoint to which requests to MAAS are sent.
sudo dpkg-reconfigure maas-rack-controller
ie: http://10.222.0.1:5240/MAAS
Then we reconfigure the Region Controller
sudo dpkg-reconfigure maas-region-controller
ie: 10.222.0.1
MAAS uses self-signed certificates by default, so we get a warning about HTTPS when we attempt to use HTTPS. In this case, since we trust our installation, we simply click the links to continue until we get to the login screen.
Then we follow the instructions on the page to set up a MAAS user.
We accepted most of MAAS defaults. Except we chose to download both 16.04 and 14.04 images for Ubuntu, since we know that both will be used later by our Cloud Deployer.
Additionally, in the DNS Setup section, we chose 8.8.8.8 as our external DNS.
Now that we have MAAS up and running, we need to get it to recognize new nodes on our network. For this we require 2 steps:
MAAS automatically detects all of our subnets, but we must give it more information about our private subnet before MAAS can successfully provide DHCP.
We navigate to http://10.222.0.1/MAAS/#/networks?by=fabric to view the currently detected subnets.
Then we click on the Subnet CIDR of our Cloud Subnet “10.222.0.0/24”. This brings us to the subnet configuration page. Here we define more information about our subnet for the benefit of DHCP.
We set both the ‘Gateway IP’ and ‘DNS’ to our current subnet IP address ‘10.222.0.1’. The reason why we do this is that even though our own default gateway is the IP of our external Subnet, we want DHCP to tell everyone else in our private subnet that we are their default Gateway and DNS server.
Finally, to Enable DHCP and get our Cloud Provider up and running, we must return to the Subnet page http://maas/MAAS/#/networks?by=fabric.
Here instead of selecting the subnet CIDR ‘10.222.0.0/24’ we click the VLAN name to the left of the CIDR. Since we have not tagged our VLAN, our VLAN is called ‘untagged’. So we click the link ‘untagged’ to the left of our subnet CIDR ‘10.222.0.0/24’.
This brings us to the management page for our VLAN. We then click the “Take Action” Dropdown in the upper right-hand corner and choose “Enable DHCP”.
We accepted the defaults and restarted our server.
After we configured networking, we found that we still had a problem resolving addresses using our MAAS Provided DNS. Upon further inspection of /etc/resolv.conf, we found that our DNS server was not being added automatically, and any attempts to edit it manually were futile, as the resolvconf service simply overwrote the file.
However, upon further inspection, we discovered that NetworkManager was managing our resolv.conf. So we disabled it by editing /etc/NetworkManager/NetworkManager.conf and replacing the line dns=dnsmasq with dns=none and restarted the NetworkManager service with service NetworkManager restart.
Unfortunately though, at this point, nobody was managing DNS, and manually editing resolv.conf still achieved nothing. But then we discovered that we could edit the file /etc/resolvconf/resolv.conf.d/base to include our list of DNS Servers (up to 3)
# DNS servers are defined here# Private DNS Server preferably with traffic forward # to a public server like google 8.8.8.8 nameserver 10.222.0.1# First Public DNS (ie google 8.8.8.8) nameserver 8.8.8.8# Second Public DNS (ie google 8.8.4.4) nameserver 8.8.4.4
After we saved the file, we restarted the resolvconf service viasudo service resolvconf restart , and voila! resolvconf now automagically included our DNS servers into /etc/resolv.conf. DNS was now locally being handled by MAAS.
Check out our next post where we discuss our experience with setting up servers to boot from the network (PXE Boot) so that MAAS will recognize them and where to go from there.
Also, feel free to explore on your own or check out the MAAS official documentation (keep an eye on the version number).