Building A Self-Sufficient Docker Cluster

1 Reply

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 Four Quadrants of A Dynamic And Self-Sufficient System

Leave a reply

Any system that intends to be fully automated and self-sufficient must be capable of self-healing and self-adaptation. As a minimum, it needs to be able to monitor itself and perform certain actions both on service and infrastructure levels.

Two axes can represent the set of actions a system might execute. One group of actions be represented through the differences between infrastructure and services. The other axis can be explained by the type of activities, with self-healing on one end, and self-adaptation on the other.
Continue reading →

The DevOps Toolkit Series Continues: 2.2 Is Born

1 Reply

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 →

Automating Jenkins Docker Setup

8 Replies

Jenkins is, by far, the most used CI/CD tool in the market. That comes as no surprise since it’s been around for a while, it has one of the biggest open source communities, it has enterprise version for those who need it, and it is straightforward to extend it to suit (almost) anyone’s needs.

Products that dominate the market for years tend to be stable and very feature rich. Jenkins is no exception. However, with age come some downsides as well. In the case of Jenkins, automation setup is one of the things that has a lot to be desired. If you need Jenkins to serve as an orchestrator of your automation and tasks, you’ll find it to be effortless to use. But, if you need to automate Jenkins itself, you’ll realize that it is not as smooth as you’d expect from modern tools. Never the less, Jenkins setup can be automated, and we’ll go through one possible solution.
Continue reading →

Zombies Are Muttering “Agile”, “DevOps”, “Containers”, “Big Data”, and “Microservices”

Leave a reply

DevOps is the word of the year. Everyone speaks about it, and many are hoping to apply it, even though most are confused what it truly means.

Inquiring about DevOps does not seem to help. If you speak with a software vendor, he’ll tell you that all you need to become DevOps ninja is to purchase his product. Puppet, Chef, Ansible, Docker, Terraform, Packer, Jenkins, Nexus, Git… Every software vendor seems to have a DevOps sticker attached to his product. You’ll notice those stickers being right next to “we make Docker easy” and “we convert your architecture into microservices.”
Continue reading →

The Ten Commandments Of Continuous Delivery

10 Replies

The Ten Commandments Of Continuous Delivery

Everyone wants to implement continuous delivery. After all, the benefits are too big to be ignored. Increase the speed of delivery, increase the quality, decrease the costs, free people to dedicate time on what brings value, and so on and so forth. Those improvements are like music to any decision maker. Especially if that person has a business background. If a tech geek can articulate the benefits continuous delivery brings to the table, when he asks a business representative for a budget, the response is almost always “Yes! Do it.”

A continuous delivery project will start. Tests will be written. Builds will be scripted. Deployments will be automated. Everything will be tied into an automated pipeline and triggered on every commit. Everyone will enter a state of nirvana as soon as all that is done. There will be a huge inauguration party with a vice president having the honor to be the first one to press the button that will deploy the first release to production. Isn’t that a glorious plan everyone should be proud of?
Continue reading →

Managing Secrets In Docker Swarm Clusters

8 Replies

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 →