Changes to decking.js being ignored until you remove the container

[philcal]

I realise this issue is a combination of #4 and #40 but add it here for the benefit of anyone looking for a fast solution without digging through the long discussions on those issues.

I've just spent 4 hours trying to determine why changes to the "env" for a container were being ignored. I wanted to run a simple mysql container...

"containers": {
    "mysql": "mysql"
    ...

and after running decking create dev I realised I was missing a necessary environment variable.

"containers": {
    "mysql": {
            "image": "mysql",
            "env": ["MYSQL_ROOT_PASSWORD=xyz"]
    },
    ...

This change and others I made to the container config were completely ignored.

After running the create command without errors, my expectation was that my containers would match my decking.json file. I got the message already exists - running in case of dependents, but otherwise no indication of what operations were being performed.

After forking the code and inserting debug, I realised that the container's run parameters are only defined as the container is initially created in Docker, which only happens the first time the decking create command is run. Of course once I realised that it was a simple matter to delete the container and run the command again.

My concern is that there was no indication in the project page, or in the output of the commands, that decking.json is a use-once config. Once I knew what the problem was, I was able to find the solution confirmed down within issue #40. Decking does a great job of the set up and tear down lifecycle, except when you change the config. For this, you need to delete everything by hand, and start from scratch, which diminishes the overall Decking experience.

I am quite familiar with Docker, and understand (and agree) that Decking commands should mirror those of Docker. However this is something of a trap, and tweaking parameters like this during development to get a container running should not be considered aberrant behaviour.

In order to keep command semantics as they are, but help others avoid my experience, may I suggest the following:

1. Change the message mentioned above to Container already exists (config will not be updated)
2. As per issue add 'destroy' method - with appropriate warnings #4, it would be great to have a way to easily destroy existing containers without doing docker ps -a and cutting and pasting ids to a docker rm command.
3. Maybe a sentence or two to describe this issue on the home page.
4. A debug option to display the underlying docker commands would make solving a problem like this much easier.

In every other way I think Decking is great, and that's why I persisted in working through this problem.
Cheers and thanks.