2 ms·

> The BOSH paradigm is: wait, why are you trying to automate the construction of pets? You want cattle. So it starts with a fixed OS base image and installs pac

> The BOSH paradigm is: wait, why are you trying to automate the construction of pets? You want cattle. So it starts with a fixed OS base image and installs packages in a fixed, non-negotiable way. At the low level, very inflexible. But it allows BOSH to focus on the business of installing, upgrading, repairing and reconfiguring distributed systems as single systems. The single distributed system is where BOSH starts, not where it was extended to. It's an important distinction. This is a problem compared to how we are reasoning about systems in the Docker world. You either use an orchestration tool - which doesnt care what the base system is, and only cares whether it is discoverable/alive/dead/etc - or you use a construction tool . The construction tool could be a Dockerfile .. which you massage in shape for the particular OS/config you have... or you use ansible/salt to "transform" the system. For example, k8s uses Salt for orchestration and Docker for construction. BOSH is a merger of both.. and is therefore extremely, extremely opinionated and incestuous. If I may overstep the limits of my intelligence - I would say, it is a product of times when Docker was not invented yet. It is also very hard to work with as a consequence. Just wanted to let you know that.

jacques_chester 10y ago
> If I may overstep the limits of my intelligence - I would say, it is a product of times when Docker was not invented yet. Well, it was, so that makes sense. I actually said ... a year ago now, I think? ... that tools like Puppet and Chef would morph from "discipline my pets" into straight up image builders. They're so much nicer than Dockerfiles -- the latter is severely constrained by the nature stackable filesystems. > It is also very hard to work with as a consequence. Just wanted to let you know that. Out of curiousity, where do you see the seams to cut it open?
- sandGorgon 10y ago
  I think Docker or runC is pretty much mandatory. Not because it is great tech or anything.. but because of https://hub.docker.com/explore/ https://hub.docker.com/explore/ So BOSH needs to work with my Dockerfile. That's the first step. Second, build a minimal cluster (1 node?) for me with my Dockerfile. All that the cluster is doing is restarting my application if it dies and helping me deploy. And let me scale out gradually from there. Keep BOSH if you want ;)
- lobster_johnson 10y ago
  > tools like Puppet and Chef would morph from "discipline my pets" into straight up image builders Maybe, but if you're running something like Kubernetes, which I genuinely think is the future, "images" stop having any sort of relevance to this problem space. If you've ever written a dockerfile, as I'm sure you have, you'll know that the recipes for individual applications' setup become so simple that problems that Puppet, Chef etc. exist to solve just melt away. Most of my dockerfiles are just a RUN line or two. A tool like Puppet, much of which is architected around the issue of mutable state, would just get in the way when your build is immutable. As for the host, containers don't care what kind of host environment they're being scheduled in, and so the recipes for building Kubernetes hosts also become a lot simpler.

jacques_chester 10y ago

> If I may overstep the limits of my intelligence - I would say, it is a product of times when Docker was not invented yet. Well, it was, so that makes sense. I actually said ... a year ago now, I think? ... that tools like Puppet and Chef would morph from "discipline my pets" into straight up image builders. They're so much nicer than Dockerfiles -- the latter is severely constrained by the nature stackable filesystems. > It is also very hard to work with as a consequence. Just wanted to let you know that. Out of curiousity, where do you see the seams to cut it open?

sandGorgon 10y ago
I think Docker or runC is pretty much mandatory. Not because it is great tech or anything.. but because of https://hub.docker.com/explore/ https://hub.docker.com/explore/ So BOSH needs to work with my Dockerfile. That's the first step. Second, build a minimal cluster (1 node?) for me with my Dockerfile. All that the cluster is doing is restarting my application if it dies and helping me deploy. And let me scale out gradually from there. Keep BOSH if you want ;)
lobster_johnson 10y ago
> tools like Puppet and Chef would morph from "discipline my pets" into straight up image builders Maybe, but if you're running something like Kubernetes, which I genuinely think is the future, "images" stop having any sort of relevance to this problem space. If you've ever written a dockerfile, as I'm sure you have, you'll know that the recipes for individual applications' setup become so simple that problems that Puppet, Chef etc. exist to solve just melt away. Most of my dockerfiles are just a RUN line or two. A tool like Puppet, much of which is architected around the issue of mutable state, would just get in the way when your build is immutable. As for the host, containers don't care what kind of host environment they're being scheduled in, and so the recipes for building Kubernetes hosts also become a lot simpler.