How to debug an Opsworks/Chef 11.10.4 cookbook locally on Linux (Debian9) using Centos Vagrant guest (Amazon Linux like)

Question

I searched for this for 3 weeks but didn't find any real answer.

The main goal is to save time to test dev Chef cookbooks locally before deploying on production on AWS.

All I found is some hints using Ubuntu with Vagrant :

Have anyone experienced to run kitchen locally with a Centos guest with a repository of Chef cookbooks with a JSON (Chef node configuration) as the node environment (like in opsworks) ?

My .kitchen.yml file and tree directory :

---
driver:
  # specifies the software that manages the machine. We're using the Vagrant Test Kitchen driver
  name: vagrant

provisioner:
  #  specifies how to run Chef. We use chef_zero because it enables you to mimic a Chef server environment on your local machine. This allows us to work with node attributes and other Chef server feature
  name: chef_zero
  environments_path: './env' # JSON file (node config) is not used !:  env/preprod.json
  client_rb:
    environment: preprod

verifier:
  # specifies which application to use when running automated tests. You'll learn more about automated testing in a future module.
  name: inspec

platforms:
  - name: centos-7

suites:
  - name: default
    run_list:
      # list of cookbooks
      - recipe[nginx::default]
    attributes:

Tree without of the repository content without all files, just dir names :

(minified)

├── foobar-cookbooks
│   ├── agent_version
│   ├── apache2
│   │   └── templates
│   │       ├── default
│   ├── foobar
│   │   ├── attributes
│   │   ├── definitions
│   │   ├── recipes
│   │   └── templates
│   │       └── default
│   ├── foobar_app_akeneo
│   │   ├── definitions
│   │   ├── metadata.rb
│   │   └── templates
│   │       └── default
│   ├── foobar_app_drupal
│   │   ├── attributes
│   │   ├── definitions
│   │   ├── metadata.rb
│   │   ├── recipes
│   │   └── templates
│   ├── foobar_app_joomla
│   │   ├── attributes
│   │   ├── definitions
│   │   ├── metadata.rb
│   │   └── recipes
│   ├── Config
│   ├── dependencies
│   │   ├── attributes
│   │   ├── libraries
│   │   ├── metadata.rb
│   │   ├── recipes
│   │   └── specs
│   ├── deploy
│   │   ├── attributes
│   │   ├── definitions
│   │   ├── libraries
│   │   ├── metadata.rb
│   │   ├── specs
│   │   └── templates
│   │       └── default
│   ├── ebs
│   │   ├── attributes
│   │   ├── files
│   │   │   └── default
│   │   ├── libraries
│   │   ├── metadata.rb
│   │   ├── recipes
│   │   ├── specs
│   │   └── templates
│   │       └── default
│   ├── gem_support
│   │   ├── libraries
│   │   ├── metadata.rb
│   │   ├── recipes
│   │   └── specs
│   ├── haproxy
│   │   ├── attributes
│   │   ├── metadata.rb
│   │   ├── README.rdoc
│   │   ├── recipes
│   │   ├── specs
│   │   └── templates
│   │       └── default
│   ├── LICENSE
│   ├── memcached
│   │   ├── attributes
│   │   ├── metadata.rb
│   │   ├── recipes
│   │   ├── specs
│   │   └── templates
│   │       └── default
│   ├── mod_php5_apache2
│   │   ├── attributes
│   │   ├── metadata.rb
│   │   ├── recipes
│   │   ├── specs
│   │   └── templates
│   │       └── default
│   ├── mysql
│   │   ├── attributes
│   │   ├── files
│   │   │   └── default
│   │   ├── metadata.rb
│   │   ├── recipes
│   │   ├── specs
│   │   └── templates
│   │       └── default
│   ├── nginx
│   │   ├── attributes
│   │   ├── definitions
│   │   ├── metadata.rb
│   │   ├── specs
│   │   └── templates
│   │       └── default
│   ├── opsworks_agent_monit
│   │   ├── attributes
│   │   ├── metadata.rb
│   │   ├── recipes
│   │   ├── specs
│   │   └── templates
│   │       ├── default
│   ├── opsworks_aws_flow_ruby
│   │   ├── attributes
│   │   ├── definitions
│   │   ├── metadata.rb
│   │   ├── recipes
│   │   └── templates
│   │       └── default
│   ├── opsworks_berkshelf
│   │   ├── attributes
│   │   ├── libraries
│   │   ├── metadata.rb
│   │   ├── providers
│   │   ├── recipes
│   │   └── resources
│   ├── opsworks_bundler
│   │   ├── attributes
│   │   ├── metadata.rb
│   │   ├── recipes
│   │   └── specs
│   ├── opsworks_cleanup
│   │   ├── attributes
│   │   ├── metadata.rb
│   │   ├── recipes
│   │   └── specs
│   ├── opsworks_commons
│   │   ├── attributes
│   │   ├── definitions
│   │   ├── libraries
│   │   ├── metadata.rb
│   │   ├── providers
│   │   ├── recipes
│   │   └── resources
│   ├── opsworks_custom_cookbooks
│   │   ├── attributes
│   │   ├── libraries
│   │   ├── metadata.rb
│   │   ├── recipes
│   │   └── specs
│   ├── opsworks_ecs
│   │   ├── attributes
│   │   ├── files
│   │   │   └── default
│   │   ├── libraries
│   │   ├── metadata.rb
│   │   ├── recipes
│   │   └── templates
│   │       └── default
│   ├── opsworks_ganglia
│   │   ├── attributes
│   │   ├── files
│   │   │   └── default
│   │   ├── metadata.rb
│   │   ├── recipes
│   │   ├── specs
│   │   └── templates
│   │       └── default
│   ├── opsworks_initial_setup
│   │   ├── attributes
│   │   ├── libraries
│   │   ├── metadata.rb
│   │   ├── recipes
│   │   ├── specs
│   │   └── templates
│   │       └── default
│   ├── opsworks_java
│   │   ├── attributes
│   │   ├── metadata.rb
│   │   ├── recipes
│   │   ├── specs
│   │   └── templates
│   │       ├── amazon
│   │       ├── default
│   ├── opsworks_nodejs
│   │   ├── attributes
│   │   ├── definitions
│   │   ├── libraries
│   │   ├── metadata.rb
│   │   ├── recipes
│   │   ├── specs
│   │   └── templates
│   │       └── default
│   ├── opsworks_rubygems
│   │   ├── attributes
│   │   ├── metadata.rb
│   │   ├── recipes
│   │   └── specs
│   ├── opsworks_shutdown
│   │   ├── metadata.rb
│   │   ├── recipes
│   │   └── specs
│   ├── opsworks_stack_state_sync
│   │   ├── metadata.rb
│   │   ├── recipes
│   │   └── templates
│   │       └── default
│   ├── packages
│   │   ├── attributes
│   │   ├── libraries
│   │   ├── metadata.rb
│   │   ├── recipes
│   │   └── specs
│   ├── passenger_apache2
│   │   ├── attributes
│   │   ├── definitions
│   │   ├── metadata.rb
│   │   ├── recipes
│   │   ├── specs
│   │   └── templates
│   │       └── default
│   ├── php
│   │   ├── attributes
│   │   │   └── default.rb
│   │   ├── recipes
│   │   ├── specs
│   │   └── templates
│   │       └── default
│   ├── Rakefile
│   ├── README.md
│   ├── ruby
│   │   ├── attributes
│   │   ├── metadata.rb
│   │   ├── recipes
│   │   └── specs
│   ├── scm_helper
│   ├── ssh_host_keys
│   ├── ssh_users
│   ├── test_suite
├── attributes
├── Berksfile
├── chefignore
├── definitions
├── env
├── layers.json
├── metadata.rb
├── recipes
├── spec
├── specs
├── test

I am not sure what do you want to achieve, (a) test Opsworks locally (on your development machine)?, before going to production. Or, (b) just run chef on standalone server? — Szymon, Sep 28 '18 at 04:58
I don't try to test directely on my desktop, but in a Vagrant Centos box guest — Gilles Quénot, Sep 28 '18 at 09:32
I will offer 250 reputation points to anyone providing a fully workable sample code — Gilles Quénot, Sep 30 '18 at 21:52
I am not sure how Opsworks interacts with Chef12+ (I do not have access to such environment anymore), but if you have a local copy of all the cookbooks, you can run them with [test-kitchen](https://learn.chef.io/modules/local-development/). Yes, it is "an overlay" on Vagrant, but the interface is simpler and easier to use with Chef. Sorry I cannot be more helpful. — Szymon, Oct 01 '18 at 05:57

score 1 · Answer 1 · answered Oct 05 '18 at 16:24

"Using Test Kitchen to Manage Test Environments Although you can test Chef code on your private server before launching it in a production environment, node that Chef will make changes to the configuration of the server when you run the code.

A smart way to go about testing Chef code during development is to set up a sandbox environment that closely resembles a production environment. This will give you a safe place to test your Chef recipes. Chef comes with Test Kitchen, which helps you create a sandbox environment for testing. Test Kitchen utilizes Vagrant and Virtual Box to get its job done.

Test Kitchen runs on Vagrant, and you create your sandbox environment on top of Test Kitchen. Test Kitchen is installed as part of the Chef Development Kit, and you need to install it separately if you’re using Chef Client.

In order to create a virtual environment using Test Kitchen, you use the kitchen create command:

$ kitchen create default-centos65

This example shows how to create a virtual environment running CentOs. This command downloads the Vagrant base box and configure and boot the VM instance. Test Kitchen will pull base boxes that Chef Software makes available on the Internet via VagrantCloud The CentOS instance created by the last command will set a up a barebones CentOS installation with just enough stuff to let Chef run.

You can login to the CentOS VM by doing this:

$ kitchen login default-centos65
Last login: Fri May 28 10:41:48 2016 
from 10.0.1.1

Welcome to your Packer-built virtual machine. Run all your test Chef code in this Test Kitchen supported sandbox environment.

Test Kitchen uses YAML file format for its configuration files. YAML files work with two types of data – key-value pairs and lists." - Alapati, S. (March 2018). Modern Linux Administration.

Sorry, but you can't just run `kitchen create default-centos65` without a complete `.kitchen.yml` file. Moreover, as explained before, I need to pass the JSON nodes object in environment. I expect a full working solution, there's already some tutorials on the web that describe the abstract use of `kitchen` like you does. Thanks trying to help. — Gilles Quénot, Oct 05 '18 at 17:43

How to debug an Opsworks/Chef 11.10.4 cookbook locally on Linux (Debian9) using Centos Vagrant guest (Amazon Linux like)

1 Answers1