Skip to main content

Test Kitchen - `kitchen.ec2.yml` File

Aaron LippoldAbout 2 min

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:

  1. Create: Test Kitchen uses the driver to create an instance of the platform.
  2. 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.
  3. 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.
  4. 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.