Test Kitchen - `kitchen.ec2.yml` File
Understanding the kitchen.ec2.yml
File
The kitchen.ec2.yml
file is instrumental in setting up our testing targets within the AWS environment. It outlines the configuration details for these targets, including their VPC assignments and the specific settings for each VPC.
This file leverages the AWS CLI and AWS Credentials
configured as described in the previous Required Software section.
Alternatively, if you've set up AWS Environment Variables, the file will use those for AWS interactions.
Example kitchen.ec2.yml
file
---
platforms:
- name: rhel-8
driver:
name: ec2
metadata_options:
http_tokens: required
http_put_response_hop_limit: 1
instance_metadata_tags: enabled
instance_type: m5.large
associate_public_ip: true
interface: public
skip_cost_warning: true
privileged: true
tags:
CreatedBy: test-kitchen
provisioner:
name: ansible_playbook
hosts: all
require_chef_for_busser: false
require_ruby_for_busser: false
ansible_binary_path: /usr/local/bin
require_pip3: true
ansible_verbose: true
roles_path: spec/ansible/roles
galaxy_ignore_certs: true
requirements_path: spec/ansible/roles/requirements.yml
ansible_extra_flags: <%= ENV['ANSIBLE_EXTRA_FLAGS'] %>
lifecycle:
pre_converge:
- remote: |
echo "NOTICE - Installing needed packages"
sudo dnf -y clean all
sudo dnf -y install --nogpgcheck bc bind-utils redhat-lsb-core vim
echo "updating system packages"
sudo dnf -y update --nogpgcheck --nobest
sudo dnf -y distro-sync
echo "NOTICE - Updating the ec2-user to keep sudo working"
sudo chage -d $(( $( date +%s ) / 86400 )) ec2-user
echo "NOTICE - updating ec2-user sudo config"
sudo chmod 600 /etc/sudoers && sudo sed -i'' "/ec2-user/d" /etc/sudoers && sudo chmod 400 /etc/sudoers
transport:
name: ssh
max_ssh_sessions: 2
Breakdown of the kitchen.ec2.yml
file
platforms:
- name: rhel-8
This section defines the platforms on which your tests will run. In this case, it's Red Hat Enterprise Linux 8.
driver:
name: ec2
...
This section configures the driver, which is responsible for creating and managing the instances. Here, it's set to use Amazon EC2 instances. The various options configure the EC2 instances, such as instance type (m5.large
), whether to associate a public IP address (associate_public_ip: true
), and various metadata options.
provisioner:
name: ansible_playbook
...
This section configures the provisioner, which is the tool that brings your system to the desired state. Here, it's using Ansible playbooks. The various options configure how Ansible is run, such as the path to the Ansible binary (ansible_binary_path: /usr/local/bin
), whether to require pip3 (require_pip3: true
), and the path to the roles and requirements files.
lifecycle:
pre_converge:
- remote: |
...
This section defines lifecycle hooks, which are commands that run at certain points in the Test Kitchen run. Here, it's running a series of commands before the converge phase (i.e., before applying the infrastructure code). These commands install necessary packages, update system packages, and update the ec2-user
configuration.
transport:
name: ssh
max_ssh_sessions: 2
This section configures the transport, which is the method Test Kitchen uses to communicate with the instance. Here, it's using SSH and allowing a maximum of 2 SSH sessions.
The workflow of Test Kitchen involves the following steps:
- Create: Test Kitchen uses the driver to create an instance of the platform.
- Converge: Test Kitchen uses the provisioner to apply the infrastructure code to the instance. Before this phase, it runs the commands defined in the
pre_converge
lifecycle hook. - Verify: Test Kitchen checks if the instance is in the desired state. This is not shown in your file, but it would be configured in the
verifier
section. - Destroy: Test Kitchen uses the driver to destroy the instance after testing. This is not shown in your file, but it would be configured in the
driver
section.
The transport
is used in all these steps to communicate with the instance.