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

Leave a 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

4 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

7 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 →

Blue-Green Deployments With Docker Services Running Inside a Swarm Cluster

9 Replies

I am continuously getting questions about blue-green releases inside a Docker Swarm cluster. Viktor, in your The DevOps 2.0 Toolkit book you told us to use blue-green deployment. How do we do it with services running inside a Swarm cluster? My answer is usually something along the following lines. With the old Swarm, blue-green releases were easier than rolling updates (neither were supported out of the box). Now we got rolling updates. Use them! The reaction to that is often that we still want blue-green releases.

This post is my brainstorming on this subject. I did not write it as a result of some deep thinking. There is no great wisdom in it. I just wrote what was passing through my mind while I was trying to answer another one of the emails containing blue-green deployment questions. What follows might not make much sense. Don’t be harsh on me.
Continue reading →