SaltyVagrant8.2 Base server and operating system
The master server will be an x86 machine with 8GB RAM, 4 cores, and 250GB SSD1. Onto this hardware we will install the Debian operating system. At the time of writing the latest stable version of the Debian operating system is Debian-11 codenamed ‘Bullseye’.
The Vagrantfile for our base server will therefore look like this;
1# -*- mode: ruby -*- 2# vi: set ft=ruby : 3 4Vagrant.configure("2") do |config| 5 config.vm.box = "debian/bullseye64" 6 config.vm.box_version = "v11.20220912.1" 7 config.vm.provider "virtualbox" do |vb| 8 vb.memory=8192 9 vb.cpus=4 10 end 11end
Try it now. Create a new directory, move into that directory, create a new Vagrantfile and enter the content above2, save the file and then vagrant up. You should end up with a new VirtualBox server set up with the Debian operating system installed.
The keen-eyed amongst you will have noticed that there is no mention in this Vagrantfile of disk size. The Vagrant box will provide the initial system disk, changing this size of this disk involves more than a simple directive in the Vagrantfile. For now we will live with the disk provided and address this issue if the need arises.
Another key feature of this Vagrantfile is the config.vm.box_version line. This ‘locks’ our configuration to a specific version of the base box. This ensures that any configuration work we do after this is building on a known starting configuration. It also means that anyone using our Vagrantfile is sure to also deal with the correct starting point.
If we omit line 6 then Vagrant will use the latest debian/bullseye64 available on the Vagrant Cloud box catalogue. As we develop our initial solution this may be an option we want to use, but as soon as we are to share our configuration with others providing the version is important.
‘Locking’ our version like this is important for consistency later but has an associated downside. As our configuration ages this version of the Vagrant box becomes increasingly out of date with respect to the Debian releases. We can deal with these issues in a number of ways, among them the following.
- Review and update the ‘locked’ version of the box periodically.
- Build our own custom Vagrant box.
- Update the Vagrant VM as part of our subsequent configuration.
Each of these has pros and cons and we will consider each later. This ‘lock’ versus ‘free’ version issue will be a recurring one. For now we have a potentially more serious issue to deal with, the Vagrant box we rely upon is hosted on the Vagrant box catalogue hosted by HashiCorp and there is no guarantee that this box will remain available indefinitely. Worse, we have no control over that box’s availability, the Debian team or HashiCorp may choose to deprecate it. This raises a general issue; we should, so far as practicable, make copies of all resources we rely upon such that we can maintain direct control over them. For the box it would simply mean cloning the debian/bullseye64 box into our own Vagrant box catalogue and then using this local Vagrant box catalogue as our primary source. Since we do not currently have such a catalogue we should add this to our backlog.
It is also important to emphasise that our development and test configuration is based on a virtual machine configuration suitable for use with Vagrant on our desktop machine, it is not necessarily a precise match with the base configuration we will have on our target system. How should we deal with this? One obvious solution is to carefully control matters such that these differences are eliminated. Another, perhaps more pragmatic, approach for our purposes here is to test for the important features that we must have in our base configuration and to make our configuration appropriately adaptable. We will investigate these options as we proceed.
Part of the Vagrant specification for a box requires that an SSH server be provided to allow Vagrant to communicate with the VM to both provide access (via vagrant ssh) and for further configuration, to which we now turn our attention.
While Vagrant requires SSH access we will likely not install SSH access on the majority of our ‘real’ servers. So, one of the major discrepancies we have between our Vagrant development and test system, and our formal test and production system is the presence of SSH. We can minimize the impact of this discrepancy by severely limiting access to SSH. We will address this shortly.
Insecure by design
Vagrant boxes will generally not have much security by default (see §8.3). This is by design. Vagrant is intended primarily as a development tool and is not suitable for controlling or deploying production systems, consequently you will find that most generic Vagrant boxes, such as debian/bullseye64, are fairly ‘bare bones’, consisting of a largely default installation. However we want our local system to reflect our formal test and production environments as closely as practicable3. We will secure our servers as much as is practicable given the aforementioned Vagrant requirements.
1You might be thinking, “that’s a pretty weird specification for a server!” And you’re right. It just happens to be the specification of a spare machine I have lying around (recall, we’re working with what we have available.)
2You may need to reduce the assigned memory and cpu count, depending on your host machine’s specification.
3This is a game of diminishing returns. As our system grows there will come a point where replicating it for developers locally will be impractical, however we can reproduce the features essential to specific teams (although this requires a level of understanding of the system seldom found—but our mission is to foster this level of understanding, so let’s continue).