5 ms·

Using Docker with Github and Jenkins for repeatable deployments

96 points by jaboutboul 13y ago

keule 13y ago
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 13y ago
  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 13y ago
    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 13y ago
      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 13y ago
        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 13y ago
        > 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 13y ago
        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".
- nl 13y ago
  Docker's production ready. It's stable (in the sense that it doesn't crash) reliable software. People have been using it production for a long time, and really it's just a wrapper around Linux containers, which people have been using in production for even longer. Docker's not production ready. The APIs aren't locked down and the developers haven't said it is production ready yet. It may be possible to break out of the container (if you expect to use it like a VM) and people are still fighting over if you should "Dockerize" at the application, service or executable level.
ritonlajoie 13y ago
What is the go-to for windows application 'isolation' or 'sandboxing' ? I only know about sandboxie..Anythine else ?
- cheeseprocedure 13y ago
  Not sure if Cameyo meets all your needs, but it's worth a look: http://www.cameyo.com/ http://www.cameyo.com/
  - ritonlajoie 13y ago
    Thanks, will have a look !
- taspeotis 13y ago
  If you're serious about it you'd probably consider App-V [1]. [1] http://en.wikipedia.org/wiki/Microsoft_App-V http://en.wikipedia.org/wiki/Microsoft_App-V
sambabu9 13y ago
Is Docker going to disrupt Chef and Puppet? Is it ready for using in production environments especially RHEL
- i386 13y ago
  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-lifestyle/ http://theshipshow.com/2014/03/deciphering-the-docker-lifest...
  - d23 13y ago
    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 13y ago
      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?
michaelneale 13y ago
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+publish+Plugin https://wiki.jenkins-ci.org/display/JENKINS/Docker+build+pub...

96 points by jaboutboul 13y ago

keule 13y ago

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 13y ago
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 13y ago
  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 13y ago
    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 13y ago
      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 13y ago
        > 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 13y ago
        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".
nl 13y ago
Docker's production ready. It's stable (in the sense that it doesn't crash) reliable software. People have been using it production for a long time, and really it's just a wrapper around Linux containers, which people have been using in production for even longer. Docker's not production ready. The APIs aren't locked down and the developers haven't said it is production ready yet. It may be possible to break out of the container (if you expect to use it like a VM) and people are still fighting over if you should "Dockerize" at the application, service or executable level.

ritonlajoie 13y ago

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

cheeseprocedure 13y ago
Not sure if Cameyo meets all your needs, but it's worth a look: http://www.cameyo.com/ http://www.cameyo.com/
- ritonlajoie 13y ago
  Thanks, will have a look !
taspeotis 13y ago
If you're serious about it you'd probably consider App-V [1]. [1] http://en.wikipedia.org/wiki/Microsoft_App-V http://en.wikipedia.org/wiki/Microsoft_App-V

sambabu9 13y ago

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

i386 13y ago
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-lifestyle/ http://theshipshow.com/2014/03/deciphering-the-docker-lifest...
- d23 13y ago
  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 13y ago
    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?

michaelneale 13y ago

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+publish+Plugin https://wiki.jenkins-ci.org/display/JENKINS/Docker+build+pub...