Hacker News Reader

Comment by weaksauce | Hacker News Reader

The short introduction on that tutorial is much better than that actual docker site and 10-15 min interactive tutorial on what docker actually is and what it can be used for. A note to other developers, it's a good idea to not use some language without first defining the word... Especially if it's an overloaded term.

View on HN

Agreed, it's a nice intro. I still think the hardest part is understanding how docker fits into the bigger picture. I think I've more or less figured it out on my own, but I struggled with e.g. do I want my source built in the image or mounted as a volume?

If you're loading the source from outside, aren't you losing the advantages of immutability of the Docker container? Suddenly the same image may have different behaviours depending on the state of the code outside.

That's why you want to use volumes for mutable data such as your source code repo - you isolate the changing parts and keep the containers static.

But if the source is mutable data, what isn't? Everything eventually mutates - dependencies have updates, configurations change, etc. Isn't the point of images that you "freeze" a static release that can be deployed everywhere?

It seems that by that point you've lost the advantage of using images; if parts of the system must be loaded outside of the container, it seems you might as well simply use a configuration manager to install the stuff and then run LXC/LXD containers instead of using images at all.

I know, I'm a little late to this party, but just in case anyone is still around... :)

For me, mounting my local app files as a volume is useful during development since it keeps the workflow fast. I don't have to rebuild the image every time I want to try the app out, I get to use the new code without delay.

If I were deploying as a container, I presume my build process would check the app out of git and build the image based on that fresh checkout. I'm just using Docker as a convenient way of simulating my production environment (dev'ing on Ubuntu 15.04, but deploying to Debian 7), and still be able to iterate rapidly.

Ah, fair enough, I was really thinking about shared, deployable images. I suppose this use case makes sense.

The introduction on this PDF is a good complement: https://d0.awsstatic.com/whitepapers/docker-on-aws.pdf

When I want to understand in a few lines some business or software, I normaly avoid their web site because it's usually just riddled with buz words and a sales funnel to force you to register or get some trial without even understanding what it is or how it costs.

For a good 2-3 sentences description I go on Wikipedia when available.

For some reason I found docker very unintuitive, even writing a simple build script was confusing. I agree, this book would have done a much better job of introduction than the docker site.

Out of interest, what did you find confusing/unintuitive? I'm writing a book on Docker so am interested in where the pain points are.

It was mostly how we wanted to use it at my company. It didn't seem clear whether docker should just set up the system (apt-get, pip install) or also checkout the code. To add to the complexity, we have a puppet script we run on the machine to install dependencies. I had no idea how Docker who supposed to fit into this pipeline. So basically, I didn't know what docker was supposed to be good at, i.e. do better than other tools.

Interesting.

You might be interested in my blog and book:

http://zwischenzugs.wordpress.com/

There are links through there to my book, where the first chapter is free to download, and may help. Let me know if you have any feedback.

What's the overloaded term you're talking about?

Yes, this is extremely helpful.

Reply on news.ycombinator.com