I completely associate with what you said about using Docker as an educational tool. I have my projects littered around, and half of them might not even run anymore. Might be good to build a tar and archive them somewhere.
I think the level of detail you have worked fine for the writing style, my comment is somewhat nitpicky. Your statement is generally true, if they use the dockerfile they posted then it's extremely likely to work for you too.
It was mostly a clarification for people reading that the dockerfile doesn't guarantee repeatable builds.
This looks like the font file you're using lacks some rendering hints (all points that touch the median line should be annotated as such, it looks like they aren't).
Another version of the same font or the same font from another source may work. Webfont sites often try to tweak the hinting tables, they're trying to make the fonts look better but it breaks stuff all the time.
Docker is a pretty modern piece of tech, that has very little wrong with it, and seems to work exactly as designed. So you are kind of shoe horning the reference...
I'm a pretty smart person; I've poured over the Docker documentation, run through the interactive tutorial twice now, and I still don't have a great sense of 1) what it really is for, 2) how to really use it, or 3) how to handle slightly-non trivial use cases.
For #3, reading through a few examples online of how to get MySQL or Redis up and running in a container... honestly makes my head hurt. And those represent just one or two parts of the system I'm thinking could some day run on Docker - I don't have the time or patience right now to figure out how to get Nginx, Node.js, Redis, MySQL, RabbitMQ, and a few other things here or there - stitched together into a dockerfile.
If I had to make a guess at what the "bad parts" of Docker are, it's that it's complex and not all that understandable - yet. Maybe there aren't that many things that are technically wrong with it, but at this point, it's pretty painful to wrap one's mind around (IMO), and at least I personally think thats a "bad" part.
Docker feels like one of those things that is going to be indispensable and incredibly useful in a year or two. I'm certainly keeping my eye on it, but I'm staying away from the diving board for now.
I have never used Puppet/Chef,so can't speak for them, but part of the reason why sandboxing in Docker isn't overkill is that it uses a layered file system that shares as much as can be shared; so, although the containers are isolated in user space, they still share the same base. This is one of the reasons for its high performance
Not sure I understand what you are saying. I know that Docker uses AUFS. I'm not saying sandboxing in Docker is overkill. I'm saying that using separate containers for application dependencies rather than running them all in the same container is often making things more complicated than necessary.
Obviously some people have good reasons to use links, like they need to run lots of databases on different servers or something. But for most installations that don't need to scale to serve millions of people, putting all of the application dependencies in one container makes a lot more sense.
Oh! It seems I misunderstood your comment. My apologies. Yes, it makes sense to use one container for all the dependencies pertaining to an application. However, if you are running multiple applications on the same server, you can sandbox them by running them in different containers.
I've settled on running 5 or 6 containers rather than one big one with 5 or 6 processes because:
I can host some containers on other physical hosts - I don't need to keep thinking (what if I fill up the biggest droplet on Digital Ocean) - If one of the services dies or needed kicking - 5/6 of the stack is unaffected - Orchestration is really only a matter of network endpoints getting written to environment variables - not too taxing
Running everything is one container also has it's advantages - like being able to push the whole stack as one image.