This new blog series (in short: TIL) is supposed to cover topics in software development, learnings from working in software companies, tooling, but also private matters (family, baby, hobbys). No idea where I’m heading with it, though 😉
I would like to start with the reason for creating TIL.
nginx replaces Apache, introducing Ansible
The setup on my server got too complicated, especially with Apache configs that I’ve been maintaining since Apache 2.0.x was installed. From experience at my company, I know that nginx is much easier and concise in its configuration.
Around 2011, I created Site Deploy, a UI for deploying web sites to web servers via SSH. The set of supported web site types was limited (the ones I used, e.g. Django, Play!, static files), as were the supported servers (Apache, nginx, lighttpd).
Only in 2015, while working on an automated test environment setup for my company, I learned about Ansible, and that my software was basically the same invention to a small extent, just earlier and created for private purposes. Site Deploy has similar concepts like hosts, variable resolution, SSH connection, but never became as elegant as Ansible.
My previous setup was manual configuration of virtual hosts of Apache, plus configuration files automatically created by Site Deploy per site. This was all replaced by an Ansible-based setup, which makes it easier to
-
Run tasks and updates from one place
-
Create a test environment. I’m using a VM with the same OS as my real server, plus a suffix
.testdomainso that I only have to add e.g.<IP of test VM> andidog.de.testdomainto/etc/hosts. -
Test repeatability (and idempotency) of the tasks. I tried checked mode, which only performs a dry run, but it’s much harder to maintain playbooks that are compatible with it. Having a test machine (or VM) is a much better idea. Seeing things fail (even if on a test system) makes you a better developer / devop / sysadmin.
-
Get the same setup every time, therefore having a full configuration backup in one place, without the need to backup anything from the server (except for live data like databases).
-
Reuse, reuse, reuse. Ansible roles are one way to apply the same changes multiple times, e.g. creating a web site configuration. Another way is to use nginx/Apache’s include operation to add common configuration directives to other configs.
-
Readability and ability to share playbooks/roles with others.
Ansible is definitely the way to go for me. It’s available as package on *nix systems (not on Windows) and principally only needs Python installed on the to-be-configured server. It works by syncing modules to the server and running them there, with the inputs you provide. Read their introduction article to get a grasp of the concepts - the learning curve is gentle and you will quickly get good results.
Other than my server, I am also maintaining my home server - a Raspberry Pi with a hard drive, exposed through dynamic DNS on the Internet so that I can, for example, access my music from work. At least that’s the theory. In reality, my neighborhood only gets DSL 6000 speed with horrible upload rate which makes my remote MP3 listening experience very hickupy… Back to topic: I’ve even used Ansible to setup/restore my work laptop before.
Conclusion: Ansible is the simplest, most readable and, in my opinion, architecturally best (e.g. no server-side component, only Python required) way to set up your private server or other machine. Learning it should be really quick, while mastering takes the usual time. Even if the tool is one of the industry standards among its rivals Chef, Puppet, etc., it’s hard to find (consistent) best practices. The sharing portal Ansible Galaxy has playbooks/roles of mixed quality, which I haven’t checked out very much, and software maintainers typically don’t provide direct Ansible support in their upstream project (for instance, wouldn’t that be nice for nginx?!). However there are books on it already (I’ve read a bit of an Ansible: Up and Running excerpt a while ago, looks promising), and meetup groups around the world (for me: Munich group). The company behind the open source project also seems to be quite good at communicating and documenting everything, while keeping a good balance between making money and maintaining the open source part. Their developers and evangelists whom I’ve met on the meetups ranged from very competent to brilliant, so the future looks bright on this project.