add 'destroy' method - with appropriate warnings

[makeusabrew]

With an option to ignore implicit dependencies

[arahayrabedian]

Hi Guys, I was just evaluating decking for a project, unfortunately can't use it cos this destroy (and thus recreate) feature is missing, do you know of any workarounds? maybe I can clear some cache or images out so that create will create from the json every time?

My particular case is pretty basic and wanted to use this to deploy on a server using our project plus a dependency, the idea would be that our 'latest' tag would always be the latest version of our application, unfortunately the way things are now, we'd have to keep modifying the decking.json container name in order to get a rebuild to occur instead of it using an old container.

Dunno if this is how it's intended to be but please let me know what I can do to try to at least work with it as it currently is.

Thanks.

[stephenmelrose]

My understanding is that decking was originally created with dev and CI in mind. As you say, I'm not sure how it would work in production with relation to zero downtime updates. I believe (happy to be corrected) that @makeusabrew uses decking to build the images in CI, but launches them manually in production?

Even if we do this feature, it won't support zero downtime releases as you'd have to destroy the existing containers first and then create and start the new ones. You'd have to name the containers with a different alias to get them running at the same time and switch which ones you use via nginx or a load balancer. Might need to discuss this with @makeusabrew if he sees decking as a production tool as well.

For now though, you can use docker commands to manually remove each container,

docker rm -f container1.dev container2.dev container3.dev

Or if you are able to, you can use the following to remove all containers. Please note the emphasis on ALL, i.e. you probably wouldn't want to do this in production, especially if you're using data containers,

docker rm -f $(docker ps -a -q)

[arahayrabedian]

hmmm, that's fair enough, I'm still quite new to docker so I didn't see the issue with the namings, though it may be with careful management the system could keep track of aliases and the links between various running containers. (not saying it would be easy nor handle every user situation).

We're working with smartstack so don't need zero downtime per-se, but I was hoping to be able to spin up a parallel set of containers and then switch over to those, all triggered by jenkins.

Even if I alias them differently, the issue I'd have would be something like this:
(please note that the docker build itself is being done elsewhere in a traditional manner and being pushed to with the "latest" (and version specific) tags)

this json was spun up by hand with random names just to communicate an idea, if you swap out some vars you'll have what I'm trying to run at the moment:
{
  "containers": {
    "db-proxy": {
        "image": "<private-reg>:5000/db:proxy:latest",
        "port" : ["1234:1234"]
    },
    "application": {
      "image": "<private-reg>:5000/application:latest",
      "port" : ["80:80"],
      "dependencies": [
        "db-proxy:application-database_service"
      ]
    }
  },
  "clusters": {
    "one": ["db-proxy", "application"],
    "two": ["db-proxy", "application"]
  }
}

starting alternate clusters (blue-green deploy style, but not keeping the old around for very long) for each release should work assuming traffic direction is sorted, but, we end up with the issue that once 'db-proxy' and 'application' are created for the first time on the machine, they're never updated, even if the docker repository has new versions in the 'latest' tag that are pulled locally. i.e: doing: "decking create one; decking start one", then on the next release after the "latest" docker image has been pulled onto the machine locally, running "decking create two; decking start two", will (I speculate, I haven't actually tried it) cause an identical set of containers to cluster 'one' to launch since it's "already created".

Please don't get me wrong, until I hit this issue, I was absolutely blown away by the amount of scripting this would save me. We're trying to move to CD, but are PoC'ing things at the moment and I'm at the stage where decking would take me a long way, there are too many tools at the moment which focus on orchestrating an entire fleet of servers and docker containers across them, that's not what we're looking for right now and that's where decking fit in nicely.

My objective here would be not to have to fiddle with the decking.json file in between releases unless some config had actually changed. If that doesn't align with the project vision then that's perfectly fine, I'm just looking to see if i can make this last step with decking.

Thanks!

[arahayrabedian]

forgot to say, even if containers are aliased differently, I'd have to constantly fiddle with the aliases between releases in order to get fresh images, right?

edit:
possible Rube Goldberg solution: generate decking.json from a template and then run create, integrating the version number of the application in the alias so as to force create to work. Dunno how that would affect the other commands, especially that the clusters would constantly be changing, wouldn't be cluster 'one' 'two' but by version or something... I'm probably overthinking this solution.

[stephenmelrose]

If you don't mind destroying the old containers first and then creating the new ones after, then yes, this will work as and when it's implemented.

For me though, I'd do "blue-green" as you call it. The only way to do this with docker (nevermind decking) is to either use different aliases every time you create a new container, or not use them at all and leave it to docker to automatically name them.

I've not actually used docker in production yet, my thoughts on it are all theory based (hence deferring to @makeusabrew as I know he has), but this is what I had planned in my head. I'd do some Ansible scripting that,

• Got the container ID for the currently running container using a bit of docker ps and piping. Ansible's docker module might actually be able to do this for you.
• Fire up the new containers.
• Get the randomly assigned ports from these containers.
• Update whatever load balancer I'm using to use these ports. If nginx, it would be a config change then a reload.
• Stop old containers.

For that process, decking wouldn't work due to the specific alias names, hence rolling my own with Ansible.

[arahayrabedian]

original plan was to roll our own, had a quick look and came across decking earlier today :), anyway, I'll see what @makeusabrew says then think about this again tomorrow morning, unfortunately on a tight schedule but that's not anybody else's problem. Until then, it's time to get my mind off this for the day.

Thank you for your help. I'm considering tackling some of the decking issues when I have more experience with docker (give that weeks/months). Also have zero experience with nodejs but I think I can pick that up for these purposes.

[makeusabrew]

Hello both,

Interesting discussion here. A few things:

1. decking destroy <cluster> is absolutely on the roadmap, and soon; but probably not soon enough for your needs, @arahayrabedian.

2. The blue-green model is definitely the sanest way to deploy to production, and while @stephenmelrose is right that I use decking in build/test/ci and not production, it could be made to work in this scenario. Take a look at how decking names containers:

http://decking.io/#faq-names

This means that your initial assumptions @arahayrabedian are correct; as your example stands decking would reference the same container since it's quite legitimate to share containers across clusters. If you were to add two groups called one and two - which can be empty (I know, bit of a hack - will think of a better solution) then decking start one would look for application.one and db-proxy.one, and decking start two would look for *.two:

3. However, if you went down this route you'd have to avoid explicitly binding to a fixed port on the host as docker will complain when trying to start the second cluster (during the overlap when running both). You could use the group overrides (see http://decking.io/#format-groups) to specify a different fixed port, or as @stephenmelrose says could just let docker assign one for you and use docker inspect <container>, or decking status <cluster> to parse out the port you've been assigned (I'd use docker inspect since you get JSON back from it).

4. The reason decking shies away from trying to solve production issues is because they are so varied and complex I just couldn't see a sane way of trying to make a one-size-fits-all solution to them using decking. There are lots of intricacies about zero downtime, logging, process monitoring, persistent containers (e.g. DBs), data volumes etc that it just seemed like an area best left to other tools. Decking is all about speed and convenience but I'd trade some of that for reliability and control in production. Open all ears though!

[arahayrabedian]

I realise after writing this I've gotten a little off-topic from the issue, but don't know where else to continue:

gonna play around with a few options this morning, if it's not too complicated I'll go on with it.

Just wanted to comment on point 4: the main reason I picked decking to experiment with was that it precisely did not try to address these issues en masse. I treated it as merely a wrapper around the command line to simplify (eliminate) writing scripts, I see that that is not precisely the case and was caught off guard by the idempotency. The reason most of the other docker orchestration products wouldn't work for our purposes was that they don't fit in our infrastructure as it currently stands (which we are working towards changing). Almost everything on this list https://stackoverflow.com/questions/18285212/how-to-scale-docker-containers-in-production try to tackle too much at once and require too much change to be compatible with anything we currently have.

Once you start tackling those issues, it becomes difficult for anyone to integrate decking into their infrastructure as it will require that they bend/change their infrastructure. I believe the best way is to leave those issues to the user to tackle (or other tools as you say) but hand them enough control to be able to configure them (which to my knowledge, you do).

If all else fails, I think I'll write a basic commandline generator to at least make scripting easy. Either way, I look forward to seeing what happens with decking.

[makeusabrew]

Implemented; closing this old ticket. Keep an eye on #82 for release updates