5 ms·

Show HN: Meet Dockship

52 points by cedel2k1 13y ago

pbreit 13y ago
Need to include a one sentence description towards the top.
- cedel2k1 13y ago
  totally agree with you. i just added a tl;dr :-)
robbles 13y ago
Is "I wrote a PaaS on top of docker" the new "I wrote a new web framework"?
nl 13y ago
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.
retr0h 13y ago
NOde to CLI
davidbanham 13y ago
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 13y ago
  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!
chrissnell 13y ago
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-reusable-chef-cookbooks.html http://devopsanywhere.blogspot.com/2012/11/how-to-write-reus...
- shykes 13y ago
  > 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? Docker builds can be nested. That is, you can build a docker image on top of a docker image on top of a docker image, and so on. So, if you need to maintain a standardized base across several teams in your organization (which is a common requirement): * 1. Create a source repository for that standardized base with a Dockerfile and any other necessary content. * 2. Build that base and push it to a registry (public or private) * 3. Tell your developers to use that standardized base in their own Dockerfiles. You can repeat that step any number of times. Does this help?

52 points by cedel2k1 13y ago

pbreit 13y ago

Need to include a one sentence description towards the top.

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

robbles 13y ago

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

nl 13y ago

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.

retr0h 13y ago

NOde to CLI

davidbanham 13y ago

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 13y ago
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!

chrissnell 13y ago

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-reusable-chef-cookbooks.html http://devopsanywhere.blogspot.com/2012/11/how-to-write-reus...

shykes 13y ago
> 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? Docker builds can be nested. That is, you can build a docker image on top of a docker image on top of a docker image, and so on. So, if you need to maintain a standardized base across several teams in your organization (which is a common requirement): * 1. Create a source repository for that standardized base with a Dockerfile and any other necessary content. * 2. Build that base and push it to a registry (public or private) * 3. Tell your developers to use that standardized base in their own Dockerfiles. You can repeat that step any number of times. Does this help?