The DevOps 2.0 Toolkit: Automating the Continuous Deployment Pipeline with Containerized Microservices
This book is about different techniques that help us architect software in a better and more efficient way with microservices packed as immutable containers, tested and deployed continuously to servers that are automatically provisioned with configuration management tools. It's about fast, reliable and continuous deployments with zero-downtime and ability to roll-back. It's about scaling to any number of servers, design of self-healing systems capable of recuperation from both hardware and software failures and about centralized logging and monitoring of the cluster.In other words, this book envelops the whole microservices development and deployment lifecycle using some of the latest and greatest practices and tools. We'll use Docker, Kubernetes, Ansible, Ubuntu, Docker Swarm and Docker Compose, Consul, etcd, Registrator, confd, and so on. We'll go through many practices and even more tools. Finally, while there will be a lot of theory, this is a hands-on book. You won't be able to complete it by reading it in a metro on a way to work. You'll have to read this book while in front of the computer and get your hands dirty.
requirements. Our goal is to create an online shop. The complete plan is still not available, but we do know that selling books has priority. We should design services and a Web application in a way that it can easily be extended. We do not have the whole set of requirements in front of us, so we need to be prepared for the unknown. Besides books, we’ll be selling other types of goods, and there will be other kinds of functionality like a shopping cart, registration and login, and so on. Our job
containers existed long before its first release. Docker made it easy for us to use containers and is built on top of LXC. It made useful technology simple to use and built a very powerful ecosystem around it. Docker company quickly become the partner with almost all software industry leaders (Canonical, RedHat, Google, Microsoft, and so on) and managed to standardize containers. This partnership also brought containers to almost all operating systems. At the time of this writing, Windows Server
different tools) so we’ll move on to service registration. Service Registration Microservices tend to be very dynamic. They are created and destroyed, deployed to one server and then moved to another. They are always changing and evolving. Whenever there is any change in Service Discovery: The Key to Distributed Services 102 service properties, information about those changes needs to be stored in some database (we’ll call it service registry or simply registry). The logic behind service
⁸⁴https://github.com/vfarcic/ms-lifecycle/blob/master/ansible/roles/etcd/defaults/main.yml ⁸⁵https://github.com/vfarcic/ms-lifecycle/blob/master/ansible/etcd.yml ⁸⁶https://github.com/vfarcic/ms-lifecycle/blob/master/ansible/hosts/serv-disc Service Discovery: The Key to Distributed Services 1 2 113 [etcd] 10.100.194.20[1:3] In this example, you can a different way to define hosts. The second line is Ansible’s way of saying that all addresses between 10.100.194.201 and 10.100.194.203 should
to do. The gist of caching is that we set up the rules (for example, cache requests related to the products listing) and cache timeouts. From there on, the proxy service will send a request to the destination service only the first time and store the responses internally. From there on, as long as the request is the same, it will be served directly by the proxy without even sending the request to the service. That is, until the timeout is reached and the process is repeated. The are much more