It’s alive! The DevOps 2.1 Toolkit: Docker Swarm Is Finished

The DevOps 2.1 Toolkit: Docker SwarmI published The DevOps 2.1 Toolkit: Docker Swarm on LeanPub early. I think that only around 20% was written when it went public. That allowed you to get early access to the material, and me to get your feedback. The result is fantastic. Many send me their notes, reported bugs, proposed suggestions for improvements, recommended tools and processes that should be explored, and so on.

It would be tempting to take the whole credit for the book but that would untrue. This book is the result of teamwork between the author (me) and many of the readers (you). It proves that lean publishing works and that we can apply agile principles when writing a book. There was no fixed scope and decisions were not made in advance. I would work on a chapter and deliver it when it’s finished (sprint). You would review it and send your notes and comments that would allow me to improve it (sprint review). We had a daily exchange of emails, chats, and Disqus messages (daily standups). We did short iterations that allowed us to learn from the mistakes and improve.

Dear readers, you made this book great!

One sticks from the crowd. Tim Condit provided help that was beyond anything I could expect. He sent me his suggestions, told me about bugs, and corrected my “Tarzan” English. If you started reading the book early (before it was finished), you might have been annoyed with some weird sentences that clearly showed that English is not my primary language. Tim fixed that. He forked the repository with the book, proofread it, and made a vast number of changes to all the chapters. There were days when I would wake up confident that I will make significant progress on a new chapter. That enthusiasm would last only until I check my emails and see that Tim made another round of pull requests. I had to spend hours reviewing the changes he made only to realize that they are all perfect. Tim, I owe you my eternal gratitude for helping me make this book excellent.

You can get a copy from (and the other worldwide sites) or LeanPub. It is also available as The DevOps Toolkit Series bundle.


12 thoughts on “It’s alive! The DevOps 2.1 Toolkit: Docker Swarm Is Finished

  1. Nick Collins

    Would I be able to take the project from 2.0 and update to what is discussed in 2.1 fairly quickly, or is it a whole new beast?

    (BTW, I absolutely love 2.0 and I will be buying 2.1 ASAP, great book!!!)

    1. Viktor Farcic Post author

      I’m glad you liked them.

      Now a few weeks of a rest from writing until a new inspiration comes. Any suggestions for the next topic? Wanna participate on the next book?

  2. Vadim

    Victor, you mentioned Nginx based proxy better due to possibility reload config without downtime but in 2.1 use HAProxy based solution. Why?

    1. Viktor Farcic Post author

      I am continuously switching from one to another. Both are really great and it’s hard for me to give a definite answer which one is better. What I liked about nginx is the ability to split configuration into multiple files. However, that reason is not important anymore (at least for me). I wrote the Docker Flow Proxy (builds on top of HAProxy) that handles all configuration changes by monitoring Swarm event through Docker API.

      The chances that HAProxy will loose a transaction on config reload are very small. With the old Swarm, that’s a risk I didn’t want to take since a cluster would be changing proxy configuration continuously. Any change to any service (change in the number of replicas, new release, and so on) would trigger reconfiguration. With the new Swarm introduced in Docker v1.12 changed that drastically. Docker networking is taking care of load balancing as well as service discovery. What that means is that a proxy should be reconfigured only when a new service is deployed. Change in replicas, new releases, and other actions performed with services do not change proxy configuration. To put it differently, while before Docker 1.12 we could be in a situation when proxy configs are changing every minute (on larger systems), with Docker 1.12+, it would change sporadically. How often do we develop a new service? Even huge companies do not deliver a new service more often than once a day. Most do not do it more often than once a month. So, the chances of a lost transaction due to config reload were very small in the past and now are almost non-existent.

      All that does not mean that HAProxy is better than nginx (nor that it’s worse). Both are great proxy solutions. In The DevOps 2.0 Toolkit, I was referring to differences that are not very important mostly because I had to choose one tool over the other. Choice of the proxy was probably the hardest choice I had to make in that book. All other choices were founded on much more important arguments.

      1. Vadim

        Thank you for the detailed answer.
        You mentioned that you are switching from haproxy to nginx, but i have not found documentation how to switch docker-flow-proxy to nginx based. May you please point me on that?

        1. Viktor Farcic Post author

          That must have been misunderstanding. I’m not switching Docker Flow Proxy from HAProxy to nginx. I might, one day, support both. However, for users that should not be important since they do not directly interact with the underlying proxy.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s