

Show HN: Meet Dockship - cedel2k1
http://braindump.ghost.io/meet-dockship/

======
chrissnell
First off, don't take my comments the wrong way. Good on you for this work to
fill in something that's missing from the whole Docker deployment process. I
love Show HN's and there's always something for everyone to learn here.

If I'm understanding your project correctly, what you've done is create a way
to deploy some git-managed code into a Docker container. It's a good idea but
I think you are attacking the problem from too high up the stack. The real
problem, as I see it, exists one level down: in the Dockerfile and the Docker
image. We need deeper control of the environment than a Dockerfile and your
app deployer provides. The popular approach is for developers to create their
Dockerfile that builds their platform and instantiate a container from this.
The problem is that this works great for a small startup with a couple of devs
but falls short for larger companies who want to layer configurations on top
of one another, applying and enforcing rules across those configurations. Let
me explain:

Where I work, we have lots of servers running lots of apps. The apps
themselves are managed by various developers but we have standard things that
we do across those servers, like install our monitoring agent, applying
patches, configuring performance tweaks, etc. The problem with running Docker
in this environment is maintaining these things in a centralized manner. Sure,
we could create a bunch of Docker images that contain all of our organization
standardizations but how do we maintain these? Without Docker, we use Chef and
Gangnam-style[1] cookbooks but Chef is not lightweight at all and it's a total
pain in the ass for junior guys to learn.

What I think we need is a system of building Docker images that allows dev &
ops teams to collaborate and layer different configurations and applications
on top of one another in a structured way. It sounds like Chef, but this
imaginary application evaluates the "cookbooks" and produces Docker images and
Dockerfiles, not bootstrapped servers.

Perhaps Chef will evolve and people will adopt it for deploying Docker.
Perhaps someone will write the next-gen Dev/Ops configuration management tool
and it will be built around Docker. Perhaps this is already out there and I'm
just not aware of it.

[1] [http://devopsanywhere.blogspot.com/2012/11/how-to-write-
reus...](http://devopsanywhere.blogspot.com/2012/11/how-to-write-reusable-
chef-cookbooks.html)

~~~
mitchellh
Dockerfiles can build off of other Dockerfiles (the FROM) directive. What
you'd want to do in this situation is probably build a base Docker image that
apps build off of, with this base Docker image containing your "standard
things."

If you have a lot of Chef, you can get this up and running pretty quickly by
using Packer ([http://www.packer.io](http://www.packer.io)). Packer can build
Docker images using Chef to provision them. The next version of Packer
(already in git) can tag and push those images to a registry, too, if you
want. You probably do, if you want downstream to use Dockerfiles.

Using Packer for the creation of the containers has helped a lot of
organizations we work with use Docker while maintaining existing workflows and
tools that their employees are trained to use well and that they're happy
with. Its a good balance, and easy to replace things with Dockerfiles if you
feel the need.

In terms of "allowing dev & ops to layer", the way this looks is you separate
what layers you need: clearly you need a base layer (OS), then you want a
standard layer (monitoring agents and so on), then maybe you want a stack-
specific layer (rails vs node vs whatever), then finally maybe you want devs
to be able to put in their application.

Dockerfiles are great and concise for apps (put files here, start by running
this command, etc.). Chef/Puppet are great for pretty much the rest of the
stack upwards. Packer comes into play there.

It is just an option, at the end of the day, but it can provide a smoother
adoption process without having to disrupt too much.

~~~
shykes
> _Dockerfiles are great and concise for apps (put files here, start by
> running this command, etc.). Chef /Puppet are great for pretty much the rest
> of the stack upwards. Packer comes into play there._

You really don't need packer to use Chef in a docker build. Just install Chef
as part of your build, add your cookbooks, and run chef with the arguments of
your choice. That's 3 extra lines in your Dockerfile. As a bonus, you get to
manage the exact build and version of chef to use, using the exact same syntax
and toolbox as for the rest of your software stack. At the end day, chef is
just that - software. Why make it a hardcoded special case?

See for example this blog post: [http://tech.paulcz.net/2013/09/creating-
immutable-servers-wi...](http://tech.paulcz.net/2013/09/creating-immutable-
servers-with-chef-and-docker-dot-io.html)

~~~
mitchellh
That's very true, although there is usually quite a lot more to configuring
Chef, I can see that it can be done without too much complication using
Dockerfiles. I apologize for not mentioning this.

I prefer Chef (or some other provisioners) as a special case because it is a
common case. It is just software, but if all your servers (or a majority) are
configured using Chef, its nice to have an abstraction to make this easy. The
same argument could've been said for Vagrant early on, probably: I could've
just supported shell scripts, because shell scripts could install Chef, then
run Chef.

Perhaps so, but having the "just set this one to handful of options and you
get Chef for free" functionality was a big win for both Vagrant and Chef
adoption (as well as other provisioners, I'm just using Chef as an example
here).

Likewise, I'm finding that having Docker as a special case in Packer/Vagrant
is doing the same: it is educating more people about Docker with a low barrier
and bringing more people into an ecosystem I like (VMs, containerization,
immutability, or any mix there-in).

I'm super excited about where Docker is headed, and glad containers are
finally reaching a point where they're friendlier for laypeople (as in... not
super experienced Linux sysadmins) can use them. :)

------
robbles
Is "I wrote a PaaS on top of docker" the new "I wrote a new web framework"?

------
davidbanham
I wrote something very much like fleet, only maintained and without the crazy
RPC stuff.

I've got a branch started to integrate Docker into it. Want to join forces?

[http://github.com/davidbanham/field-
marshal](http://github.com/davidbanham/field-marshal)

~~~
shykes
If either of you wants to come hang on #docker and #docker-dev (freenode),
we'll be happy to help you out with the integration!

------
nl
Interesting.

Is there anything that ties this specifically to node apps?

I find one thing Docker is very useful for is cases where you have diverse
platforms to deploy.

------
pbreit
Need to include a one sentence description towards the top.

~~~
cedel2k1
totally agree with you. i just added a tl;dr :-)

------
retr0h
NOde to CLI

