Hi, I pretty much agree with all of your points. But there are some ways of working around the "documentation/build" part of Docker images. It is actually possible to have a pom-only documentation for a Docker Image. With the right Plugins you have the same as the Docker file. Though I regard such solutions only feasible for testing to make sure Continous Integration with more than one Container works. Otherwise I'd rather stick to Pax Exam with Karaf as Integration test.
regards, Achim 2015-04-13 16:54 GMT+02:00 Ed Welch <e...@edjusted.com>: > Hi David, > > There are kind of 2 threads in parallel covering a little bit of the same > info, and I just talked a little about the big question/issue we have in > the other thread: > http://karaf.922171.n3.nabble.com/Karaf-and-Docker-td4039514.html > > I'll kind of give the brief overview of that here. We have some difficult > to answer questions regarding ownership of the linux distro that exists > within the docker container. Our linux team owns the VM that runs docker, > but then do they have to learn docker in order to handle software updates > to the docker container? Or does this fall on the dev group to now > maintain? > > So with that question in mind, I found it easier to work within a linux VM > owned by our linux ops team, and Ansible was the software I chose to > provide automation around deployments. > > I would also point out though, the physical overhead of deployments is > smaller, and depending on your network, faster. Docker images will be > large, telling karaf to install a feature is going to be smaller. Also, we > don't update karaf/java very often, so the app server is deployed pretty > infrequently. (depending on your network, size may be a moot point) > > I also like the approach I have taken because everything is explicitly > defined and in source control. The karaf config files are in source > control, the application and its current version is as well. I could > technically use ansible to deploy my setup into a docker container and then > ship that container. > > I'm not opposed to docker, just a little more skeptical than my peers. My > fear is they will build images on their local machine with poor > documentation, nothing tracked in source control, bash it together and make > it work then ship that off to production, where docker really facilitates > making that easy. Which I think is seen as a positive in many peoples > minds, I am a little more skeptical. > > However, at this point I don't have a lot of docker experience, and I am > trying to find some time to explore it. > > I appreciate the question, it's important to me that I'm being open > minded, especially because I haven't used docker extensively. > > TLDR; If you can figure out who "owns" docker containers and maintains > them in your organization, and you can also enforce some good practices > around documentation and source control of container configurations so that > future maintenance and troubleshooting is made easier, and you don't mind > paying the 300+MB per deploy penalty, docker may be great for you! :) > > Ed -- Apache Member Apache Karaf <http://karaf.apache.org/> Committer & PMC OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer & Project Lead blog <http://notizblog.nierbeck.de/> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS> Software Architect / Project Manager / Scrum Master
