12 ms·

They have focused relentlessly on making it easy to use for every day development. Solaris Zones, BSD Jails, and LXC were around first, but were (relatively) ar

by brianm 9y ago

They have focused relentlessly on making it easy to use for every day development. Solaris Zones, BSD Jails, and LXC were around first, but were (relatively) arcane and finicky, and no one ever looked at bringing them to non-linux (or non-bsd for jails) dev laptops. OTOH, Docker made a good (enough) implementation, and went for developers, developers, developers. They brought it to Mac, to Windows, they engaged a wide audience and mostly listened. Focusing on day to day development for users came with tradeoffs -- ops oriented features came much later, getting serious about security came later, etc. These are all important things... but less so than ease of use and adoption. The pattern is not new, the same thing happened with Rails -- the concepts in rails were not novel, the extreme ease of getting started and getting to useful really fast was the killer feature (to get it going). After it got a big ecosystem, it got the quality aspect (mostly by replacing itself with merb). The lesson: if you want wide adoption, build something good and reduce every barrier to adoption you encounter. The most important features are the ones getting in way of people using it, not the ones people using it are having. You'll need to solve them, but solve adoption first.

jitl 9y ago
Astute. I was trying to use jails for development in kinda a proto-Docker setup, where my apps each ran in their own BSD jail. I struggled to put the pieces together to set up the jails, share a “base jail” with ZFS, forward ports, etc. I had scripts for messing with my pf rules to add port forwards, other scripts to update/apply config inside a jail... it was more frustrating to automate creating and destroying “immutable” jails, than maintaining a pet per app I developed... until I messed up an environment, and just abandoned the project! I think we’ll see the same sort of thing happening with FaaS frameworks, or any of the layers building on top of Swarm/Kubernetes/Mesos.
- lilbobbytables 9y ago
  What do you mean, in reference to layers on kubernetes, mesos, etc?
- inferiorhuman 9y ago
  Really? I've found iocage to work very well and combined with Ansible's jail support creating new jails is pretty darn easy. In terms of networking I created another loopback interface and assign each jail its own IP at creation time. It's not particularly elegant but it simplifies ipfw rules. I've automated doing some updates with jenkins+ansiblee+git, but overall maintaining them is a bit tough because ansible's pkgng support is lacking.
  - cdancette 9y ago
    What you're describing is exactly the reason people use docker. No need to use ansible, or to manage interfaces if you don't want to, it just work out of the box, and you run just bash commands to configure it.
    - inferiorhuman 9y ago
      I'd argue no. Dockerfiles are riddled with gotchas and limitations. In this case using Anisble initally is more akin to using Packer to build an image. For ongoing maintenance it's because I maintain state in the jails. In terms of managing interfaces, iocage does that for you. The IP address has to be assigned manually, but that would be trivial to automate. A couple of IPFW rules work just fine to NAT the loopback aliases for a dynamic set of jails.
      - oblio 9y ago
        You sound like that comment on the Dropbox HN annoucement page: https://news.ycombinator.com/item?id=9224 https://news.ycombinator.com/item?id=9224 You've just added at least 2 more concepts to the thing you have to use: iocage and ansible. On top of the jails thing. That's the exact opposite of "easy to adopt". Especially since most people that use something like Docker already don't care or want to learn Docker, they just want the benefits of using containers.
        inferiorhuman 9y ago
        That's a bit like saying that Docker is one more thing on top of LXC that you have to learn. jails : iocage :: lxc : docker ansible : iocage :: packer : docker The workflow and terminology is somewhat different but that doesn't make it inherently more difficult to adopt. The "slick" DSL that Dockerfiles provide become quite limiting in short order especially as each line bloats the eventual Docker image quite significantly. Case in point, you can't set file ownership when you copy files into the image so that extra step adds that much more bloat.
- AgentME 9y ago
  Yeah, if you want to use jails or any container-type technology on your own to use for application deployments, then you have to write a ton of scripts for creating, managing, and destroying them. I'd rather use someone's pre-existing set of scripts for that. And I am. It's called Docker. To me, asking why people are using Docker instead of plain jails combined with a series of other technologies is like asking why people make buildings out of wooden planks instead of trees. The question seems a bit wrong, because Docker is just built on existing container technologies. And I'd rather save a few steps. Planks are the exact shape and size that I want to deal with when building an application anyway.
zbyte64 9y ago
Docker is easy enough that I can get the designers up and running with the app. Now my coworkers are excited for more projects to be set up this way. Other container solutions don't allow me to work as effectively with the team.
jypepin 9y ago
> making it easy to use for every day development Can you elaborate here? I've started using Docker for development recently (pretty much just to avoid local mySQL troubles in a Rails project) - we use a docker-compose file to start an official mySQL image and the local rails repo. Seemed easy enough, until I realized I have to restart my container every time my code changed. Then I had to integrate docker-sync, which is a great library but not official. I'm still surprised code sync is not included out of the box from Docker yet - am I missing something?
- drodgers 9y ago
  Yes. Volumes: https://docs.docker.com/engine/admin/volumes/volumes/ https://docs.docker.com/engine/admin/volumes/volumes/ Mount a directory from your local filesystem as a volume and file changes within that directory will appear immediately in the container.
  - fpoling 9y ago
    This even works when one uses docker build to compile things. Just have a shell script that after the build copies the compilation result to a local directory mounted as a volume in the docker container.
    - cdancette 9y ago
      Why not compile inside the volume already?
      - fpoling 9y ago
        This is what I have used before docker build started to support multiple images. That is, I had a shell script that run an image with a compiler that put the executable to a local directory. Then normal docker build would pickup the executable into the final image. But this does not take advantage of caching with docker build and made the infrastructure more complex. Dockerfile with multiple images addressed that nicely. Now single docker build command takes care about everything and generates production ready images. A shell script is only necessary during development to extract some files from the image to avoid restarting already running container.

by brianm 9y ago

jitl 9y ago

Astute. I was trying to use jails for development in kinda a proto-Docker setup, where my apps each ran in their own BSD jail. I struggled to put the pieces together to set up the jails, share a “base jail” with ZFS, forward ports, etc. I had scripts for messing with my pf rules to add port forwards, other scripts to update/apply config inside a jail... it was more frustrating to automate creating and destroying “immutable” jails, than maintaining a pet per app I developed... until I messed up an environment, and just abandoned the project! I think we’ll see the same sort of thing happening with FaaS frameworks, or any of the layers building on top of Swarm/Kubernetes/Mesos.

lilbobbytables 9y ago
What do you mean, in reference to layers on kubernetes, mesos, etc?
inferiorhuman 9y ago
Really? I've found iocage to work very well and combined with Ansible's jail support creating new jails is pretty darn easy. In terms of networking I created another loopback interface and assign each jail its own IP at creation time. It's not particularly elegant but it simplifies ipfw rules. I've automated doing some updates with jenkins+ansiblee+git, but overall maintaining them is a bit tough because ansible's pkgng support is lacking.
- cdancette 9y ago
  What you're describing is exactly the reason people use docker. No need to use ansible, or to manage interfaces if you don't want to, it just work out of the box, and you run just bash commands to configure it.
  - inferiorhuman 9y ago
    I'd argue no. Dockerfiles are riddled with gotchas and limitations. In this case using Anisble initally is more akin to using Packer to build an image. For ongoing maintenance it's because I maintain state in the jails. In terms of managing interfaces, iocage does that for you. The IP address has to be assigned manually, but that would be trivial to automate. A couple of IPFW rules work just fine to NAT the loopback aliases for a dynamic set of jails.
    - oblio 9y ago
      You sound like that comment on the Dropbox HN annoucement page: https://news.ycombinator.com/item?id=9224 https://news.ycombinator.com/item?id=9224 You've just added at least 2 more concepts to the thing you have to use: iocage and ansible. On top of the jails thing. That's the exact opposite of "easy to adopt". Especially since most people that use something like Docker already don't care or want to learn Docker, they just want the benefits of using containers.
      - inferiorhuman 9y ago
        That's a bit like saying that Docker is one more thing on top of LXC that you have to learn. jails : iocage :: lxc : docker ansible : iocage :: packer : docker The workflow and terminology is somewhat different but that doesn't make it inherently more difficult to adopt. The "slick" DSL that Dockerfiles provide become quite limiting in short order especially as each line bloats the eventual Docker image quite significantly. Case in point, you can't set file ownership when you copy files into the image so that extra step adds that much more bloat.
AgentME 9y ago
Yeah, if you want to use jails or any container-type technology on your own to use for application deployments, then you have to write a ton of scripts for creating, managing, and destroying them. I'd rather use someone's pre-existing set of scripts for that. And I am. It's called Docker. To me, asking why people are using Docker instead of plain jails combined with a series of other technologies is like asking why people make buildings out of wooden planks instead of trees. The question seems a bit wrong, because Docker is just built on existing container technologies. And I'd rather save a few steps. Planks are the exact shape and size that I want to deal with when building an application anyway.

zbyte64 9y ago

Docker is easy enough that I can get the designers up and running with the app. Now my coworkers are excited for more projects to be set up this way. Other container solutions don't allow me to work as effectively with the team.

jypepin 9y ago

> making it easy to use for every day development Can you elaborate here? I've started using Docker for development recently (pretty much just to avoid local mySQL troubles in a Rails project) - we use a docker-compose file to start an official mySQL image and the local rails repo. Seemed easy enough, until I realized I have to restart my container every time my code changed. Then I had to integrate docker-sync, which is a great library but not official. I'm still surprised code sync is not included out of the box from Docker yet - am I missing something?

drodgers 9y ago
Yes. Volumes: https://docs.docker.com/engine/admin/volumes/volumes/ https://docs.docker.com/engine/admin/volumes/volumes/ Mount a directory from your local filesystem as a volume and file changes within that directory will appear immediately in the container.
- fpoling 9y ago
  This even works when one uses docker build to compile things. Just have a shell script that after the build copies the compilation result to a local directory mounted as a volume in the docker container.
  - cdancette 9y ago
    Why not compile inside the volume already?
    - fpoling 9y ago
      This is what I have used before docker build started to support multiple images. That is, I had a shell script that run an image with a compiler that put the executable to a local directory. Then normal docker build would pickup the executable into the final image. But this does not take advantage of caching with docker build and made the infrastructure more complex. Dockerfile with multiple images addressed that nicely. Now single docker build command takes care about everything and generates production ready images. A shell script is only necessary during development to extract some files from the image to avoid restarting already running container.