<commit_before># Overview

## Status

__UNDER CONSTRUCTION__ _Not yet working fully_

As of April 24, 2014:

* The vagrant version works fine. (but doesn't really do anything)
* The docker version "succeeds" but doesn' leave a running container
    * The chef-client run on my workstation completes without error,
    * Creates the image / container
    * Runs the chef-client on the container and succeeds.
    * __BUT__ the container then exits and is no longer available

So I'm trying to figure out how to get the container to stay up and
act like a vm.

## Chef-Repo for testing chef-metal cluster

This is a base chef repo with an app cookbook `myapp` for trying out
chef-metal and various chef-metal provisioners. It primiarily will be
using a real Chef Server and not chef-server mainly because that is my
use case and is not yet well documented.

This first experiment is trying to use Docker containers to act like
lightweight VMs so we can simulate a cluster of servers on a laptop.
This is not the "docker way" but it solves and immediate need until we
can figure out how to fully utilize docker for compositing services
into servers.

# Prerequeistes / Assumptions

These are the environment I developed under. YMMV if you don't use the
same. Probably not all hard and fast but variation increases
uncertainty.

* Ruby 2.1.1 via rvm
* Bundler installs all the gems in an rvm gemset
    * This repo sets a gemset and ruby version use `.ruby-*` files in
      the root of the repo
    * Chef 11.12+ installed as gems by bundler
    * Chef-metal and the provisioneres are installed by bundler
    * Berkshelf 3.1.1
* A real Chef Server

# Set things up

## Have a Chef Server

Have some kind of Chef Server running that you can add users,
cookbooks, nodes, clients etc. to . It can be Hosted/Private
Enterprise Chef or Open Source Chef Server. These examples were tested
with Open Source Chef Server.

## Set up this repo to your workstation

We're assuming a Mac. Should work elsewhere but I haven't tested it.

### Clone the repo

```
git clone https://github.com/rberger/chef-metal-playground
```

This includes an app cookbook in my_cookbooks. Berkshelf will use this
directory to get cookbooks that are specific to the playground and
then get the rest of the cookbooks from the community site or other
sites as specified in the Berksfile.

### Bundle install

```
bundle install
```

### Berkshelf install

This will pull in any cookbooks and the `berks vendor cookbooks` will
copy the cookbooks into the cookbooks directory

```
berks install
berks vendor cookbooks
```

### Set up your .chef directory in this repo

The existing .chef/knife.rb is set up with the following assumptions.
Feel free to change for your environment:

* Your chef-server chef-validator and user pem will be in
  `~/.chef/#{HOSTNAME}/  
    (This insures that your creds don't end up in your git repo)
* You need to change the chef_server_url to match your chef servers
  FQDN or ip address
* It trys to figure out the username and orgname if appropriate


## Set up to run chef-client on your workstation

## Install Docker

* http://docs.docker.io/installation/mac/


## Create an admin client on your chef server

As far as I can tell, if you are running Open Source Chef Server, you
need to have a client on your chef server that has admin credentials
since the chef-client run on your workstation will need permission to
create, modify and destroy nodes and other data on the chef-server.

If you were running Enterprise Chef Server you can have finer control
of the permissions for the chef-client you run on your workstation.

Make sure you save the private key that gets generated when you create
the new client on your chef server. You can name it what you want but
you eill have to put that name into the `/etc/chef/client.rb` we are
going to create below.

Our example client will be named `rberger_cymek`. Make sure you say it
has `admin` power when you create it. 

## Set up your `/etc/chef`

We're going to be running `chef-client` on your workstation, not to
manage your workstation but to bring up the target instances. If you
do use chef for managing your workstation (i.e. if there already
exists an `/etc/chef` directory on your workstation) you should not
follow these instructions or back up your /etc/chef.

There are ways to not depend on /etc/chef (like merge it into knife.rb
and pass that to the chef-client run with the `-c` flag) for this but
I didn't want to add that complexitity right now<commit_msg>Tweak readme<commit_after># Overview

## Status

__UNDER CONSTRUCTION__ _Not yet working fully_

As of April 24, 2014:

* The vagrant version works fine. (but doesn't really do anything)
* The docker version "succeeds" but doesn' leave a running container
    * The chef-client run on my workstation completes without error,
    * Creates the image / container
    * Runs the chef-client on the container and succeeds.
    * __BUT__ the container then exits and is no longer available

So I'm trying to figure out how to get the container to stay up and
act like a vm.

## Chef-Repo for testing chef-metal cluster

This is a base chef repo with an app cookbook `myapp` for trying out
chef-metal and various chef-metal provisioners. It primiarily will be
using a real Chef Server and not chef-server mainly because that is my
use case and is not yet well documented.

This first experiment is trying to use Docker containers to act like
lightweight VMs so we can simulate a cluster of servers on a laptop.
This is not the "docker way" but it solves and immediate need until we
can figure out how to fully utilize docker for compositing services
into servers.

# Prerequeistes / Assumptions

These are the environment I developed under. YMMV if you don't use the
same. Probably not all hard and fast but variation increases
uncertainty.

* Ruby 2.1.1 via rvm
* Bundler installs all the gems in an rvm gemset
    * This repo sets a gemset and ruby version use `.ruby-*` files in
      the root of the repo
    * Chef 11.12+ installed as gems by bundler
    * Chef-metal and the provisioneres are installed by bundler
    * Berkshelf 3.1.1
* A real Chef Server

# Set things up

## Have a Chef Server

Have some kind of Chef Server running that you can add users,
cookbooks, nodes, clients etc. to . It can be Hosted/Private
Enterprise Chef or Open Source Chef Server. These examples were tested
with Open Source Chef Server.

## Set up this repo to your workstation

We're assuming a Mac. Should work elsewhere but I haven't tested it.

### Clone the repo

```
git clone https://github.com/rberger/chef-metal-playground
```

This includes an app cookbook in my_cookbooks. Berkshelf will use this
directory to get cookbooks that are specific to the playground and
then get the rest of the cookbooks from the community site or other
sites as specified in the Berksfile.

### Bundle install

```
bundle install
```

### Berkshelf install

This will pull in any cookbooks and the `berks vendor cookbooks` will
copy the cookbooks into the cookbooks directory

```
berks install
berks vendor cookbooks
```

### Set up your .chef directory in this repo

The existing .chef/knife.rb is set up with the following assumptions.
Feel free to change for your environment:

* Your chef-server chef-validator and user pem will be in
  `~/.chef/#{HOSTNAME}/  
    (This insures that your creds don't end up in your git repo)
* You need to change the chef_server_url to match your chef servers
  FQDN or ip address
* It trys to figure out the username and orgname if appropriate


## Set up to run chef-client on your workstation

## Install Docker

* http://docs.docker.io/installation/mac/
* export DOCKER_HOST=tcp://localhost:4243

## Create an admin client on your chef server

As far as I can tell, if you are running Open Source Chef Server, you
need to have a client on your chef server that has admin credentials
since the chef-client run on your workstation will need permission to
create, modify and destroy nodes and other data on the chef-server.

If you were running Enterprise Chef Server you can have finer control
of the permissions for the chef-client you run on your workstation.

Make sure you save the private key that gets generated when you create
the new client on your chef server. You can name it what you want but
you eill have to put that name into the `/etc/chef/client.rb` we are
going to create below.

Our example client will be named `rberger_cymek`. Make sure you say it
has `admin` power when you create it. 

## Set up your `/etc/chef`

We're going to be running `chef-client` on your workstation, not to
manage your workstation but to bring up the target instances. If you
do use chef for managing your workstation (i.e. if there already
exists an `/etc/chef` directory on your workstation) you should not
follow these instructions or back up your /etc/chef.

There are ways to not depend on /etc/chef (like merge it into knife.rb
and pass that to the chef-client run with the `-c` flag) for this but
I didn't want to add that complexitity right now
{'fraction_non_alphanumeric': 0.04928492849284929, 'fraction_numerical': 0.0039603960396039604, 'mean_word_length': 3.8151483050847457, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 2, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '583838', 'n_tokens_mistral': 2582, 'n_tokens_neox': 2444, 'n_words': 1446}