We’ve done it! Over the last 6 posts, we’ve reviewed in detail all the major
components of our simplified Infrastructure-as-Code (IaC) setup, and we’re
ready to pull it all together to spin up an Aegir3 instance.
With the pieces we have covered so far, we can run the following to get up the
point of actually installing Aegir:
pipenv shell # Activate venv
source d # Bootstrap Drumkit
make tools # Install Ansible and Galaxy dependencies
make infra # Run …
Initially our pure ansible infrastructure project consisted primarily of
Ansible playbooks, using includes and imports to segment out what was essentially one
long sequential process. We built up a set of plays that would go from nothing
through all of the support infrastructure and provisioning a Droplet, up to the
point of being ready to install application-level software, namely Aegir and
its dependencies.
At this point, we were able to pick up and dust off some
roles that we had
built over …
Ansible Playbooks are the heart of any project driven by this tool, and in our
example project
we are now ready to look at this core piece of the puzzle.
Essentially, when we think about the infrastructure resources needed to host a site
or application like Aegir, there are 3 main categories to think about:
Support infrastructure: VPCs and Firewalls, etc.
Hosts: usually VMs, sometimes clusters or “bare metal” servers
Applications: the software stack from operating system up through …
So far in this series, we’ve covered most of the foundational pieces of our pure ansible infrastructure
project.
We’ve got Drumkit installed, and configured our
dynamic inventory. The last piece we need is a
way to configure the fine-grained details of the Ansible playbooks and roles
we’ll be running. We also need a secure way to store variables with sensitive
data, in such a way that Ansible can access them as needed.
In any Infrastructure-as-Code project, there is a need to have visibility over
what’s actually live in the environment we’re managing. There’s also a need for
the Code part to have a manifest for what should exist. Any infrastructure
provisioning tool’s job is essentially to reconcile the difference between
these two things.
In a traditional Ansible setup, these two concepts would be represented by a
static
inventory
(typically a file named hosts). The inventory system …
Drumkit is one of my favourite tools that we use at
Consensus, because it serves to unify and simplify how we interact with our
project tooling. Drumkit itself is very simple, leveraging the venerable GNU make to create short, project-specific “targets” which are essentially a list of sub-commands to run.
Any time we have a complex command-line command to do something, and we need to run it regularly,
we add a Drumkit target for it and no longer have to remember the correct flags to …
In the first iteration of Consensus Enterprises’ internal infrastructure, we
built a well-provisioned, multi-environment architecture leveraging the
most Open services we could find (https://openstack.org). We built things as if
we were one of the larger-scale clients we tend to work with, who have
legitimate needs for more complex architectures.
We implemented a carefully crafted Infrastructure-as-Code (IaC) repository,
capable of switching between environments based on shell scripts to …