24. Tips, Tricks, and Troubleshooting

Aaron LippoldJanuary 5, 2024About 2 min

Tips, Tricks, and Troubleshooting

Test Kitchen

Test Kitchen stores the current host details of your provisioned test targets in the .kitchen/ directory. Here, you'll find a yml file containing your target's hostname, ip address, host details, and login credentials, which could be an ssh pem key or another type of credential.

.kitchen
├── .kitchen/hardened-container.yml
├── .kitchen/hardened-rhel-8.pem
├── .kitchen/hardened-rhel-8.yml
├── .kitchen/logs
├── .kitchen/vanilla-container.yml
├── .kitchen/vanilla-rhel-8.pem
├── .kitchen/vanilla-rhel-8.yml
└── .kitchen/vanilla-ubi8.yml

Restoring Access to a Halted or Restarted Test Target

If your test target reboots or updates its network information, you don't need to execute bundle exec kitchen destroy. Instead, update the corresponding .kitchen/#{suite}-#{target}.yml file with the updated information. This will ensure that your kitchen login, kitchen validate, and other kitchen commands function correctly, as they'll be connecting to the correct location instead of using outdated data.

AWS Console and EC2 Oddities

Since we're using the free-tier for our AWS testing resources instead of a dedicated host, your test targets might shut down or reboot in the background if you stop interacting with them, halt them, put them in a stop state, or leave them unattended overnight. To regain access, edit the .kitchen/#{suite}-#{target}.yml file. As mentioned above, there's no need to recreate your testing targets if you can simply point Test Kitchen to the correct IP address.

Auto-generated, sensitive files

Since the .kitchen/ directory is automatically generated by Test Kitchen, you need to be careful not to accidentally mess up its internal workings when editing it by hand as suggested above. Additionally, be sure not to place this directory underneath version control since you could unintentionally leak sensitive information such as your ip addresses and credentials!

InSpec / Ruby

Using `pry` and `pry-byebug` for Debugging Controls

When developing InSpec controls, it's beneficial to use the kitchen-test suite, the INSPEC_CONTROL environment variable, and pry or pry-byebug. This combination allows you to quickly debug, update, and experiment with your fixes in the context of the InSpec code, without having to run the full test suite.

pry and pry-byebug are powerful tools for debugging Ruby code, including InSpec controls. Here's how you can use them:

First, add require 'pry' or require 'pry-byebug' at the top of your control file.
Then, insert binding.pry at the point in your code where you want to start debugging.
When you run your tests, execution will stop at the binding.pry line, and you can inspect variables, step through the code, and more.

Linter

Remember to remove or comment out the binding.pry lines when you're done debugging or you won't have a good 'linting' down the road.

Streamlining Your Testing with `inspec shell`

The inspec shell command allows you to test your full control update on your test target directly. To do this, you'll need to retrieve the IP address and SSH PEM key for your target instance from the Test Kitchen .kitchen directory. For more details on this, refer to the Locating Test Target Login Details section.

Once you have your IP address and SSH PEM key (for AWS target instances), or the container ID (for Docker test instances), you can use the following commands:

For AWS test targets: bundle exec inspec shell -i #{pem-key} -t ssh://ec2-user@#{ipaddress} --sudo
For Docker test instances: bundle exec inspec shell -t docker://#{container-id}

The kitchen login command provides an easy way to review and modify your test target. This tool is particularly useful for introducing test cases, exploring corner cases, and validating both positive and negative test scenarios.