IaC: Infrastructure as Code
Over the past weeks, I have set up about fifty (50) FileMaker Servers on Linux EC2 instances – and destroyed every one of them only a few hours later.
The entire process takes about two (2) minutes of hands-on time, and everything is up and running in ten (10) minutes – including a new DNS entry, installing an SSL certificate, a separate drive for the operating system (OS), data, backups, as well as Zabbix monitoring.
How is that even possible?
Everything is scripted – it’s really more like programming than server management. Server provisioning, FileMaker Server installation, and everything else are defined in text files (YAML) that are managed in source control just like any other code. Every user can check out the latest version and run it – and voila! A new server is born.
RedHat Ansible is our automation platform of choice. It is free, open-source, extensively documented, and has a very active community. This post will not weigh the Pros and Cons of Ansible vs. Cloud Formation or other tools, but rather document how we are using it at Skeleton Key, so you can decide if you want to explore it for yourself. Ansible is developed by RedHat and the core version is available for free. Note: This version has no limits in terms of functionality but comes without a graphical user interface.
What really makes it such a powerful solution are the many modules both RedHat and the community develop and provide. Whether you want to call the AWS API to provision a server, configure a Linux server, run an FMSadmin command, or remotely manage a Windows machine with WinRM – it is all simple YAML task blocks in Ansible. The magic happens behind the scenes.
Individual “Tasks” execute a particular step: an SSH command on a different server, an API call to AWS, etc. Multiple tasks get compiled into a “Playbook”. Tasks are well documented and a Google search usually yields many results for terms like “Copy File Ansible”.
Getting started with infrastructure as code
To implement infrastructure as code, you need to get started with Ansible. Just simply:
- Install Ansible on your Development workstation.
- Create a basic “hosts” file.
- Test the connection.
- Create a Playbook.
- Run the Playbook.
Here’s the detailed play-by-play. Note: I’m doing this on my Mac laptop, so I’ll reference the Terminal app along the way.
1. Installation
All the details you’ll need to get the software installed can be found in the excellent Ansible documentation.
2. Create a basic “hosts” file.
Hosts are the computers ansible connects to, so before running the first Playbook, Ansible needs to know the target information.
- In the Terminal app, run “ansible –version” to reveal the config file location:
- Open the .ansible.cfg file in your favorite editor (note that the leading “dot” makes it a hidden file, which can be made visible in finder with the keyboard shortcut “command + shift + . ” ).
- Look for the value “inventory”, which will show the location of the “hosts” file
- Open the hosts file in a text editor
- Add a new line for your target server:
To break this File down:
- “[ServerGroup01]”: All servers listed under this header can be targeted with this name.
- “Test01”: The name of your target server. This can be anything you want.
- “[TARGET ADDRESS]”: The IP or domain name of the target server
- “[PATH TO PRIVATE KEY]”: The full path to the private key used to SSH to the target server, for example, “~/.ssh/myKeyFile.pem”
3. Test the connection.
Simply run this line in terminal
- “ansible SERVERNAME -m ping”, where “Servername” corresponds to the name of the target server (Test01) in step 2.
If everything is set up correctly, the server will respond with “pong”:
If an error occurs (or if you are curious) add a -v (or -vv or even -vvv) flag to run the command in verbose mode with more output detail:
- “ansible SERVERNAME -m ping -v”,
4. Create a playbook.
Create a new file called ping.yml and paste the text below and save the file in your home folder:
This is your first playbook. A playbook can hold any number of tasks that will be run in sequence, but for now, we want to simply test the setup.
5. Run the playbook.
With the new playbook saved, run this command in the Terminal app:
- “Ansible-playbook ~/ping.yml”
If everything is set up correctly, the output will look something like this:
Administrating your FileMaker Server
And now? Let’s see a list of our FileMaker Databases. By adding just a few lines to our Playbook we can begin to administer a FileMaker Server:
Replace USERNAME and PASSWORD with your FileMaker Server’s Admin Console credentials, save the file, and run the Playbook again. If everything goes as planned, the output will look like this:
But wait, there’s more!
Everything we do via SSH on a Linux server, via the AWS API or command-line interface (CLI), or any other scriptable service, can be fully written out as an Ansible Playbook.
As mentioned above, we have the provisioning process of all of our servers fully written out in Ansible Playbooks. This makes every server we set up 100% predictable, which means no accidental (human) omission of a step will require (a potentially long) troubleshooting effort. It also makes the execution very fast. Furthermore, all development and troubleshooting can be done during normal business hours, and before somebody urgently needs a new server on the weekend.
We have reduced our infrastructure and its maintenance to a few lines of code: Infrastructure as Code (IaC). This means a new test server can be up and running in minutes and disposed of a few hours later. When a client calls because their server failed, we can have them up and running in no time – without interrupting much of what we’re already doing.
Since Ansible uses standard protocols such as SSH and APIs to communicate with the target hosts, all it needs is the appropriate ports to be open. No other software needs to be installed on the hosts themselves. Ansible itself only needs to be installed on the controller, which can be a local development laptop or a dedicated server in the cloud. I use Ansible on my Mac for development and testing, and then move the finished Playbooks to a Linux instance on AWS which can run the code more efficiently in our environment.
Let us know how you would use Ansible!
