Docker in Practice – A Guide for Engineers | Hacker News Reader

Docker in Practice – A Guide for Engineers

zwischenzugs.wordpress.com

90 pointszwischenzug22 comments

Do you plan to keep updating the electronic version of the book after the print version is published?

Since docker and its ecosystem are evolving so rapidly, I'd be hesitant to buy a book now due to the fear that much of the material would be outdated within a year.

Yes, we do. Much of what we're writing now we know will be outdated soon, so the structure is designed to be flexible.

It's planned to be a living text, just as Docker's a living technology.

How to run Docker in production:

http://blog.terminal.com/docker-without-containers-pulldocke...

When you run a docker container on terminal, we handle all of the networking and storage problems for you. In addition, we're the only place in the world that's offering live-migration of docker containers right now (metal to metal without downtime. We carry everything from the RAM state to the IP address automatically).

I'm really looking forward to this book. Question, how do you deal with users outside of Linux host regarding shared folders. I'm using boot2docker, but it's painfully slow if my code base is large(10kloc).

Are you doing a COPY to get it all in? Another thing you can try is to use a builder image, where you mount your source in as a volume (ie don't copy), and that build image makes a new Dockerfile+binary that you can build into a much smaller image for deploying.

I wrote a bit about this process here: http://gowithconfidence.tumblr.com/post/112715890281/vendori...

Take a look at https://github.com/codekitchen/dinghy

This is exactly what I'm looking for. Thanks. :)

I'm not sure I properly understand you, but we look at using sshfs for mounting local folders directly into the container.

It's a neat hack that bypasses a lot of setup with NFS or other shared folder tools, assuming you have an ssh setup in place. Needless to say, we used it at work.

I've been looking for an in depth guide to Docker. Thus looks perfect.

Thanks! Let us know what you want covered.

The one thing I've spent most time getting right with Docker is networking. It's so different from FreeBSD Jails.

I believe a guide with how to setup a dns container with a dns slave container and get other Docker containers to use the dns containers could be a good introduction to how Docker networking actually work.

Networking with Docker is a pretty hefty topic. One of the interesting things talked about in the book in this area is skydock[1], which provides automatic dns registration inside docker when you start your containers. We've found it very handy for simulating a network of real machines!

[1] https://github.com/crosbymichael/skydock

You may also like to look at Weave[1], which includes an open-source network for Docker and DNS service to find other containers.

[1]: http://weave.works/

Note: I work on Weave.

I work at a company whose main product is a small application using SOA of about 15 services. Managing these 15 services in development is getting to be a nightmare. I would love to know if docker is the right solution to manage these services. Spinning up 15 VMs on a MBP is not really feasible...

It sounds like a very apt use case, unless you need the VM representation for some reason. 15 separate services is no problem for Docker. Hundreds - if not thousands - are quite possible.

Tangent: Are there any good open source Docker books?

Not that I'm aware of, but docker.com's documentation is good. For more advanced stuff, I can also recommend the Digital Ocean docs on their community site: https://www.digitalocean.com/community/

Since when sysadmins are engineers?

Who drives the train? The engineer.

We've used "engineer" to refer to the person who operates a complex engine ever since Watt. The idea that engineers are planners and blueprint-drawers is more recent. I blame Kipling and the Canadians.

That was one of the significant discussions when planning the book: who is it aimed at? Both of us are devs by background, but in discussion it turned out we had been doing a lot of what was called "sysadmin" work as well.

We both ended up doing DevOps (whatever that is), and pitched the book at mostly DevOps, then dev, then sysadmin in that order. But we don't really believe Docker is limited to one group of engineers.

In a sense the semantics is irrelevant: if you're interested in software production and delivery then Docker is a tool you're going to want to know about.

All the developers started calling themselves "software engineers", and we wanted in on the fun too. ;-)

More seriously, I agree the term "engineer" is problematic.

https://en.wikipedia.org/wiki/Software_engineer#Use_of_the_t...

Useful link, thanks! I'd always used "engineer" as a more generic term for someone who "got things done" related to software. To do this you'd need to have done some form of programming, but perhaps not self-identify as such.

Reply on news.ycombinator.com