Comment by brianm | Hacker News Reader

Comment by brianm | Hacker News Reader

Parent Full thread

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.

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.

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.

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.

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.

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.

You sound like that comment on the Dropbox HN annoucement page: 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.

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.

> 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.

I think you could solve that problem easily with multi-stage Dockerfiles.

   FROM alpine:latest
   COPY . /app
   RUN chown/chmod
   FROM alpine:latest
   COPY --from=0 /app /app

That looks suspiciously like an additional layer beyond the copy step to me (either that or a terrifically non-intuitive syntax).

You only learn about docker...

Regarding your later edit about bloat, well, it seems most people don't really care about that.

You only learn about iocage… (although even with Docker you should have at least a little knowledge of how things work under the hood for when things invariably break).

I was curious about iocage, is it this thing? https://github.com/iocage/iocage

It's FreeBSD only, why are we even having this discussion? :)

Take a look at the post I originally replied to. It was commenting on docker versus the alternatives.

What do you mean, in reference to layers on kubernetes, mesos, etc?

> 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?

Yes. 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.

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.

Why not compile inside the volume already?

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.

my understanding is that volumes are more for persisting data on your host's filesystem, right?

I'm talking more about having code you write automatically sync'ed inside the container - do volumes offer that?

Yes, just mount your /../../../Projects/MyProject onto /mnt/MyProject in the docker container and you'll have your current project files there all the time.

omg this sounds awesome, will try, thanks a lot!

Just a heads up to save you time down the road:

Docker works well for small deployments and extremely large deployment, it is extremely mismatched in bringing your average three tier app into medium size cluster because swarm doesn’t do routing well for that and because the underlying assumption is that each service is perfectly identical across each node - so even having a cluster id to ddcide who’s master in a nosql development is extra weird.

As others have already mentioned shared volumes, here's a commented little command-line demo of the principle:

https://github.com/DHager/docker-php-library-demo

It should be easy enough achieve the same results with your docker-compose configuration.

Code reload in a container has always been pretty painful. I don’t use Docker for the application I’m developing on, relying on virtualenv (in your case RVM) to keep a clean, stable, and contained environment. I use Docker for the dependencies (which is a huge boon) and when I’m done developing, I package the app into a Docker container so I can easily distribute it.

Why is code reload painful? Just mount a volume from the code you're editing in the host.

If you’re using Docker on Windows, bind mount propagation isn’t a thing. Adding a new file (or maybe a folder) on the host machine means you have to restart docker.

This is especially bad in node development when you are trying to work on your npm dependencies.

Are you sure your information is up to date? 'Cause I'm pretty sure that's not an issue anymore.

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.

Reply on news.ycombinator.com