Nowadays infrastructure as code became a de facto! IaC is used intensively in the tech world everyday! And since IaC is just a "code" at the end, so it also needs to be tested to make sure everything is working as expected and ready to be applied with confidence!
There are few tools for testing configuration management and infrastructure code in the market, so let's take a look on 2 of them that I used recently, KitchenCI and Molecule.
KitchenCI is one of main players! Even it's maintained by Chef and written in Ruby, but it actually works with all other configuration management tools like Ansible, SaltStack, and Puppet! It also works with many providers like AWS, Docker, or Vagrant. It's mature to do sophisticated tests against infrastructure code! It even supports many verifiers like InSpec and Serverspec to make sure everything is in place! What it's nice about KitchenCI that it's abstract and can work with any CM tool, but if you don't like Ruby ecosystem, maybe you will not like it too much!
Here is part of the .kitchen.yml file (you can check the project for more details):
--- driver: name: docker use_sudo: false privileged: true platforms: - name: ubuntu-16.04 driver_config: run_command: /sbin/init provisioner: name: salt_solo formula: flume state_top: base: '*': - flume suites: - name: default provisioner: pillars-from-files: flume.sls: pillar.example pillars: top.sls: base: '*': - flume
Molecule the newcomer! (not really, it's almost 2 years old now!) it has a different style/mindset and it's just for Ansible! But since Ansible itself has its own style (in compare to other CM tools) so Molecule could make sense! Molecule has a nice style where uses Ansible itself to setup the tests! It also supports many verifiers like Serverspec and Testinfra (where you can use pytest!), so it's pure Python!
I found it nice to try Molecule when I wrote Yourls Ansible Role (Yourls is a shortening app written in PHP).
Here is part of the molecule.yml file (you can check the project for more details):
--- driver: name: docker lint: name: yamllint platforms: - name: centos-yourls-latest image: centos:7 provisioner: name: ansible env: ANSIBLE_HASH_BEHAVIOUR: merge lint: name: ansible-lint options: x: ANSIBLE0016 playbooks: converge: ../../tests/test.yml inventory: host_vars: centos-yourls-latest: yourls: version: latestNote: Make sure to use the syntax for latest version, because there is a major change between v1 and v2. ---
That was a quick preview and you can find more details on each projects page. At the end, maybe testing infrastructure code not necessary for all cases, but it has some use-cases where it totally makes scene! And you have two nice options to do that! So keep automating! :-)