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 your AWS credentials, environment variables, and settings that you should have configured as described in the Environment Setup Guide section.

Example kitchen.ec2.yml File

---
platforms:
  - name: rhel-9

driver:
  name: ec2
  subnet_id: "<%= ENV['SAF_PIPELINE_SUBNET'] %>"
  security_group_ids:
    - "<%= ENV['SAF_PIPELINE_SG'] %>"
  metadata_options:
    http_tokens: required
    http_put_response_hop_limit: 1
    instance_metadata_tags: enabled
  instance_type: t2.small
  associate_public_ip: true
  interface: public
  skip_cost_warning: true
  privileged: true
  instance_initiated_shutdown_behavior: terminate

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
  requirements_collection_path: spec/ansible/roles/requirements.yml
  ansible_extra_flags: <%= ENV['ANSIBLE_EXTRA_FLAGS'] %>

suites:
  - name: vanilla
    provisioner:
      playbook: spec/ansible/roles/ansible-role-rhel-vanilla.yml
    driver:
      tags:
        Name: Vanilla-<%= ENV['USER'] %>
        CreatedBy: test-kitchen

  - name: hardened
    provisioner:
      playbook: spec/ansible/roles/ansible-role-rhel-hardened.yml
    driver:
      tags:
        Name: Hardened-<%= ENV['USER'] %>
        CreatedBy: test-kitchen

lifecycle:
  pre_converge:
    - remote: |
        # echo "+++ Refreshing DNF package cache +++"
        # sudo dnf -y clean all
        echo ""
        echo "+++ Updating DNF Packages +++"
        sudo dnf -y update --nogpgcheck --nobest
        echo ""
        echo "+++ Installing needed packages for workflow and utility +++\n\n"
        sudo dnf -y install --nogpgcheck bc bind-utils redhat-lsb-core vim git wget gcc openssl-devel libffi-devel bzip2-devel
        echo ""
        echo "+++ Installing Python 3.9 and Ansible +++\n\n"
        export PATH=/usr/local/bin:$PATH
        sudo dnf -y install python3-pip
        sudo python3 -m pip install ansible jmespath
        echo ""
        echo "+++ Updating the ec2-user to keep sudo working after hardening phase +++\n\n"
        sudo chage -d $(( $( date +%s ) / 86400 )) ec2-user
        echo ""
        echo "+++ updating ec2-user sudo config for hardening phase +++\n\n"
        sudo chmod 600 /etc/sudoers && sudo sed -i'' "/ec2-user/d" /etc/sudoers && sudo chmod 400 /etc/sudoers
        sudo dnf -y install git
        echo "+++ add cinc-auditor for local shell +++\n\n"
        curl -L https://omnitruck.cinc.sh/install.sh | sudo bash -s -- -P cinc-auditor

transport:
  name: ssh
  #https://github.com/neillturner/kitchen-ansible/issues/295
  max_ssh_sessions: 2

Breakdown of the kitchen.ec2.yml file

platforms:
  - name: rhel-9

This section defines the platforms on which your tests will run. In this case, it's Red Hat Enterprise Linux 9.

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 (t2.small), 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) and the paths to the roles and requirements files.

suites:
  - name: vanilla
  ...

This section configures the test suites, which are the various configurations that are being tested. Here, we outline how to spin up our vanilla and hardened containers. Each suite contains various options such as one to specify the path to the playbook that the provisioner should use.

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.