Tag Archives: Docker Swarm

Kubernetes Pods, ReplicaSets, And Services Compared To Docker Swarm Stacks

Starting from this article, we’ll compare each Kubernetes feature with Docker Swarm equivalents. That way, Swarm users can have a smoother transition into Kubernetes or, depending on their goals, choose to stick with Swarm.

Please bear in mind that the comparisons will be made only for a specific set of features. You will not (yet) be able to conclude whether Kubernetes is better or worse than Docker Swarm. You’ll need to grasp both products in their entirety to make an educated decision. The comparisons like those that follow are useful only as a base for more detailed examinations of the two products.

For now, we’ll limit the comparison scope to Pods, ReplicaSets, and Services on the one hand, and Docker Service stacks, on the other.
Continue reading

Advertisements

Blueprint Of A Self-Sufficient Docker Cluster

The article that follows is an extract from the last chapter of The DevOps 2.2 Toolkit: Self-Sufficient Docker Clusters book. It provides a good summary into the processes and tools we explored in the quest to build a self-sufficient cluster that can (mostly) operate without humans.

We split the tasks that a self-sufficient system should perform into those related to services and those oriented towards infrastructure. Even though some of the tools are used in both groups, the division between the two allowed us to keep a clean separation between infrastructure and services running on top of it.
Continue reading

Auto-Scaling Docker Swarm Services Using Instrumented Metrics

If you prefer reading, please visit Auto-Scaling Docker Swarm Services Using Instrumented Metrics tutorial from Docker Flow Monitor documentation. Otherwise, feel free to watch the video that follows.

The DevOps 2.2 Toolkit: Self-Sufficient Docker Clusters

The article you just read is the summary of the progress we made in The DevOps 2.2 Toolkit: Self-Healing Docker Clusters. You can find the hands-on exercises that build the system in the book.

If you liked this article, you might be interested in The DevOps 2.2 Toolkit: Self-Sufficient Docker Clusters book. The book goes beyond Docker and schedulers and tries to explore ways for building self-adaptive and self-healing Docker clusters. If you are a Docker user and want to explore advanced techniques for creating clusters and managing services, this book might be just what you’re looking for.

Please get a copy from Amazon, LeanPub, or look for it through your favorite book seller.

Give the book a try and let me know what you think.

Building A Self-Sufficient Docker Cluster

A self-sufficient system is a system capable of healing and adaptation. Healing means that the cluster will always be in the designed state. As an example, if a replica of a service goes down, the system needs to bring it back up again. Adaptation, on the other hand, is about modifications of the desired state so that the system can deal with changed conditions. A simple example would be increased traffic. When it happens, services need to be scaled up. When healing and adaptation are automated, we get self-healing and self-adaptation. Together, they both a self-sufficient system that can operate without human intervention.

How does a self-sufficient system look? What are its principal parts? Who are the actors?
Continue reading

The DevOps Toolkit Series Continues: 2.2 Is Born

The third installment in The DevOps Toolkit Series is public! Even though, while I’m writing this post, only 20% of The DevOps 2.2 Toolkit: Self-Healing Clusters is finished, I hope you’ll pick it up and send me your feedback. I need your help in setting the direction of the book. I need you to help me shape it into something great. I need you to help me make this book a community effort.

Please get it from leanpub.com/the-devops-2-2-toolkit. I’m waiting for your feedback.

What follows is the preface to The DevOps 2.2 Toolkit: Self-Healing Clusters book.
Continue reading

Managing Secrets In Docker Swarm Clusters

Docker 1.13 introduced a set of features that allow us to centrally manage secrets and pass them only to services that need them. They provide a much-needed mechanism to provide information that should be hidden from anyone except designated services.

A secret (at least from Docker’s point of view) is a blog of data. A typical use case would be a certificate, SSH private keys, passwords, and so on. Secrets should stay secret meaning that they should not be stored unencrypted or transmitted over a network.
Continue reading