You can look at how this book is organized from two perspectives.
The first one is based on the steps of the automated deployment pipeline. Each chapter takes you closer to the complete CD process. If you look at the names of the chapters, some of them are even named like the pipeline phases:
- The CI pipeline
- Automated acceptance testing
- Configuration management with Ansible
The rest of the chapters give the introduction, summary, or additional information complementary to the process.
There is also a second perspective to the content of this book. Each chapter describes one piece of the environment, which, in turn, is well prepared for the CD process. In other words, the book presents, step by step, technology by technology, how to build a complete system. To help you get the feeling of what we plan to build throughout the book, let's now have a look at how the system will evolve in each chapter.
Note
Don't worry if you don't understand the concepts and terminology at this point. We will be learning everything from scratch in the corresponding chapters.
In Chapter 2, Introducing Docker, we start from the center of our system and build a working application packaged as a Docker image. The output of this chapter is presented in the following diagram:
A dockerized application (web service) is run as a container on a Docker Host and is reachable as it would run directly on the host machine. That is possible thanks to port forwarding (port publishing in Docker's terminology).
In Chapter 3, Configuring Jenkins, we prepare the Jenkins environment. Thanks to the support of multiple agent (slave) nodes, it is able to handle the heavy concurrent load. The result is presented in the following diagram:
The Jenkins master accepts a build request, but execution is started at one of the Jenkins Slave (agent) machines. Such an approach provides horizontal scaling of the Jenkins environment.
In Chapter 4, Continuous Integration Pipeline, we'll show how to create the first phase of the CD pipeline, the commit stage. The output of this chapter is the system presented in the following diagram:
The application is a simple web service written in Java with the Spring Boot framework. Gradle is used as a build tool and GitHub as the source code repository. Every commit to GitHub automatically triggers the Jenkins build, which uses Gradle to compile Java code, run unit tests, and perform additional checks (code coverage, static code analysis, and so on). Once the Jenkins build is complete, a notification is sent to the developers.
After this chapter, you will be able to create a complete CI pipeline.
In Chapter 5, Automated Acceptance Testing, we'll finally merge the two technologies from the book title, Docker and Jenkins. This results in the system presented in the following diagram:
The additional elements in the diagram are related to the automated acceptance testing stage:
- Docker Registry: After the CI phase, the application is packaged first into a JAR file and then as a Docker image. That image is then pushed to the Docker Registry, which acts as storage for dockerized applications.
- Docker Host: Before performing the acceptance test suite, the application has to be started. Jenkins triggers a Docker Host machine to pull the dockerized application from the Docker Registry and starts it.
- Cucumber: After the application is started on the Docker Host, Jenkins runs a suite of acceptance tests written in the Cucumber framework.
InChapter 6,Clustering with Kubernetes, we replace a single Docker host with a Kubernetes cluster and a single standalone application with two dependent containerized applications. The output is the environment presented in the following diagram:
Kubernetes provides an abstraction layer for a set of Docker hosts and allows a simple communication between dependent applications. We no longer have to think about which exact machine our applications are deployed on. All we care about is the number of their instances.
InChapter 7,Configuration Management with Ansible, we create multiple environments using Ansible. The output is presented in the following diagram:
Ansible takes care of the environments and enables the deployment of the same applications on multiple machines. As a result, we have the mirrored environment for testing and for production.
In the last two chapters, that is, Chapter 8, Continuous Delivery Pipeline, and Chapter 9, Advanced Continuous Delivery, we deploy the application to the staging environment, run the acceptance testing suite, and finally release the application to the production environment, usually in many instances. The final improvement is the automatic management of the database schemas using Flyway migrations integrated into the delivery process. The final environment created in this book is presented in the following diagram:
I hope you are already excited by what we plan to build throughout this book. We will approach it step by step, explaining every detail and all the possible options in order to help you understand the procedures and tools. After reading this book, you will be able to introduce or improve the CD process in your projects.