

Using Docker with Github and Jenkins for repeatable deployments - jaboutboul
http://blog.buddycloud.com/post/80771409167/using-docker-with-github-and-jenkins-for-repeatable?utm_source=Docker+News&utm_campaign=a4320fc137-Docker_0_5_0_7_18_2013&utm_medium=email&utm_term=0_c0995b6e8f-a4320fc137-235720153

======
sambabu9
Is Docker going to disrupt Chef and Puppet? Is it ready for using in
production environments especially RHEL

~~~
i386
I was recently on a podcast panel that discussed if Docker was a replacement
or complement to Puppet/Chef.

[http://theshipshow.com/2014/03/deciphering-the-docker-
lifest...](http://theshipshow.com/2014/03/deciphering-the-docker-lifestyle/)

~~~
d23
I've seen Puppet Fabric Chef Vagrant and Docker pop up in popularity over the
last couple of years, but I've never really been clear on what the use cases
are for each. It'd be a nice to see an easily digestible comparison somewhere.

~~~
btgeekboy
Puppet and Chef do basically the same things: they let you define how a server
should be configured, and the respective applications make changes to the
server so that they converge upon that definition.

Fabric is a "library and command-line tool for streamlining the use of SSH for
application deployment or systems administration tasks." In other words, it's
shell scripting in Python that makes it easy for the author to switch contexts
between local and remote commands, or run a series of tasks. It makes no
attempt to converge to a known state like Puppet or Chef; it simply runs what
you tell it to.

Vagrant is a bit different; it connects to VirtualBox or VMware to give you
disposable VM for use as a development environment. So, if your application is
deployed on Debian configured a certain way, someone on your team can make a
Vagrantfile that tells your local computer to fire up a Debian VM and
configure it a certain way that is similar to how it is in production. (That
configuration might actually be done by Puppet or Chef - Vagrant just builds
the VM and fires it off.) It prevents various cross-platform issues from being
an issue during development, aka "it works on my machine!" syndrome.

Finally, Docker is a way to run a super lightweight container, like a VM, but
taking advantage of various Linux kernel capabilities, preventing you from
needing the overhead of yet another OS. Your Docker images might have a full
VMs worth of content for libraries and such, but they'll not need to actually
run as an OS. (Only the libraries needed for your app will be loaded.)

With the exception of Puppet and Chef (which are directly competing products),
all are very different tools that can be used simultaneously at various parts
of the product lifecycle. Does this help clear things up a bit?

~~~
sambabu9
So are you saying we can use docker to create VMs which means it is competing
with Vagrant and Openstack. If we use docker to deploy containers(war, mysql)
then it is competing with Chef and Puppet. I am still confused what is the
best use of docker. Do people really use docker to create VMs I doubt this

------
michaelneale
Related: using Jenkins+Docker in a similar fashion myself I extracted most of
what I do into a Jenkins plugin for publishing images (I was an early user of
the private docker repos): [https://wiki.jenkins-
ci.org/display/JENKINS/Docker+build+pub...](https://wiki.jenkins-
ci.org/display/JENKINS/Docker+build+publish+Plugin)

------
keule
Though I like automated deployment flows and docker, the author should have
stated that docker itself claims to be not production ready in the current 0.9
version. I am a true fan of bleeding-edge technology, but when it comes to
production I would like to see a more conservative approach.

~~~
derefr
Whether something is or is not "production-ready" is subjective. Different
projects can handle different levels of (un)reliability; "production-ready"
really just means "not a significant contributor to your service's downtime,
relative to the quality of your own code."

A more useful-and-objective piece of information, I think, would be the
average/maximum number-of-nines of reliablity reported by current users of the
project. Then you could just look at your own project's current reliability,
and allow yourself to depend on anything more reliable than you are.

~~~
keule
Oh I am not disagreeing with you on that one. Definitely a subjective matter.
Just the statement about "production-readyness" of docker comes from the
docker developers themselves.

~~~
derefr
Humility is often a problem with software developers, though. Some software is
still versioned 0.X after ten years of development, releases, adoption and
usage. I would take any developer's claim that their software _isn 't_
production-ready with a grain of salt, and test it for your use-case for
yourself.

They are probably correct-enough in that you shouldn't be using Docker in
production at Google/Amazon/Facebook/wherever. It's not yet nine-nines
reliable. But Docker _is_ probably more reliable than your startup's MVP, and
you shouldn't let "not production-ready" scare you away from developing and
shipping your new project using Docker.

~~~
keule
Yes. I did use systems in the past that had questionable versioning, milestone
releases a.s.o. and they proved to be just fine. Docker on the other hand is
not just a third-party library in your project.

Docker is a container, and I therefore apply the same set of standards that my
linux distribution/kernel should fullfill.

~~~
derefr
> Docker on the other hand is not just a third-party library in your project.
> Docker is a container

What's the difference, exactly? In either case, a failure in the code
composing the third-party component can, at worst, cause an instance of your
application to crash and corrupt state, preventing instances on that machine
from coming back up.

But as long as you've got immutable deployments[1] set up, when all else
fails, you can just destroy the server (hosting the containers) hosting your
app instances, and deploy it afresh, which should be automated to the point
that it only takes a few minutes.

[1] [http://chadfowler.com/blog/2013/06/23/immutable-
deployments/](http://chadfowler.com/blog/2013/06/23/immutable-deployments/)

~~~
bjt
When talking about whether something like Docker is production-ready, the "at
worst" can be a lot worse than that, particularly where security is concerned.
Months back they found that Docker's API wasn't sufficiently locked down, for
example, and could be accessed by an untrusted process. So they changed that
and locked it down.

I don't see anything unreasonable about waiting to use a package until the
devs themselves say it's "production ready".

------
ritonlajoie
What is the go-to for windows application 'isolation' or 'sandboxing' ? I only
know about sandboxie..Anythine else ?

~~~
cheeseprocedure
Not sure if Cameyo meets all your needs, but it's worth a look:

[http://www.cameyo.com/](http://www.cameyo.com/)

~~~
ritonlajoie
Thanks, will have a look !

