Continuous Integration &

Continuous Deployment
Module # 4
 Continuous Integration Fundamentals

• Waterfall- integration phase

• During this phase, the code changes made by individual developers or small teams were brought
together piecemeal and forged into a working product.
• This was hard work- involving the integration of months of conflicting changes.
• To anticipate the types of issues that would crop up, and even harder to fix them, as it could involve
reworking code that had been written weeks or months before.
• This painful process, fraught with risk and danger, often lead to significant delivery delays,
unplanned costs and, as a result, unhappy clients.
• Continuous Integration was born to address these issues.
 Continuous Integration Fundamentals

• Continuous Integration, involves a tool that monitors your version control system for changes.
• Whenever a change is detected, this tool automatically compiles and tests your application.
• If something goes wrong, the tool immediately notifies the developers so that they can fix the issue
immediately
• CI can also help you keep tabs on the health of your code base, automatically monitoring code
quality and code coverage metrics, and helping keep technical debt down and maintenance costs
low.
• The publicly-visible code quality metrics can also encourage developers to take pride in the quality
of their code and strive to improve it.
• Combined with automated end-to-end acceptance tests, CI can also act as a communication tool,
publishing a clear picture of the current state of development efforts.
• And it can simplify and accelerate delivery by helping you automate the deployment process, letting
you deploy the latest version of your application either automatically or as a one-click process.
 Continuous Integration Fundamentals

• Continuous Integration is about reducing risk by providing faster feedback.

• First and foremost, it is designed to help identify and fix integration and regression
issues faster, resulting in smoother, quicker delivery, and fewer bugs.
• By providing better visibility for both technical and non-technical team members
on the state of the project, Continuous Integration can open and facilitate
communication channels between team members and encourage collaborative
problem solving and process improvement.
• And, by automating the deployment process, Continuous Integration helps you get
your software into the hands of the testers and the end users faster, more reliably,
and with less efforts.
 Introduction to Jenkins
• Jenkins, originally called Hudson, is an open source Continuous Integration tool written in Java.
• Jenkins is an open source automation tool written in Java programming language that allows
continuous integration.
• Jenkins builds and tests our software projects which continuously making it easier for developers to
integrate changes to the project, and making it easier for users to obtain a fresh build.
• It also allows us to continuously deliver our software by integrating with a large number of testing
and deployment technologies.
• Jenkins offers a way to set up a CI/CD environment for almost any combination of languages and
source code repositories using pipelines, as well as automating other routine development tasks.
• With the help of Jenkins, organizations can speed up the software development process through
automation.
• Jenkins achieves CI with the help of plugins.
• Plugins is used to allow the integration of various DevOps stages.
• If you want to integrate a particular tool, you have to install the plugins for that tool.
• For example: Maven 2 Project, Git, HTML Publisher, Amazon EC2, etc.
Introduction to Jenkins
• For example: If any organization is developing a project, then Jenkins will
continuously test your project builds and show you the errors in early stages of
your development.
• Possible steps executed by Jenkins are for example:
• Perform a software build using a build system like Gradle or Maven Apache
• Execute a shell script
• Archive a build result
• Running software tests
Introduction to Jenkins
• Workflow:
 Continuous Integration with Jenkins
• Consider a scenario where the complete source code of the application was built and then deployed on
test server for testing. Developer teams have to wait till the complete software is developed for the test
results.
• There is a high prospect that the test results might show multiple bugs. It was tough for developers to
locate those bugs because they have to check the entire source code of the application.
• It slows the software delivery process.
• Continuous feedback pertaining to things like architectural or coding issues, build failures, test status and
file release uploads was missing due to which the quality of software can go down.
• The whole process was manual which increases the threat of frequent failure.
• It is obvious from the above stated problems that not only the software delivery process became slow but
the quality of software also went down. This leads to customer dissatisfaction.
• So to overcome such problem there was a need for a system to exist where developers can continuously
trigger a build and test for every change made in the source code.
• Jenkins is the most mature Continuous Integration tool available so let us see how Continuous
Integration with Jenkins overcame the above shortcomings.
Generic flow diagram of Continuous Integration with Jenkins
• First of all, a developer commits the code to the source
code repository. Meanwhile, the Jenkins checks the
repository at regular intervals for changes.
• Soon after a commit occurs, the Jenkins server finds the
changes that have occurred in the source code repository.
Jenkins will draw those changes and will start preparing a
new build.
• If the build fails, then the concerned team will be notified.
• If built is successful, then Jenkins server deploys the built
in the test server.
• After testing, Jenkins server generates a feedback and
then notifies the developers about the build and test
results.
• It will continue to verify the source code repository for
changes made in the source code and the whole process
keeps on repeating.
Advantages of Jenkins
• It is an open source tool.
• It is free of cost.
• It does not require additional installations or components.
• Easily configurable.
• It supports 1000 or more plugins to ease your work. If a plugin does not exist, you can write the
script for it and share with community.
• It is built in java and hence it is portable.
• It is platform independent. It is available for all platforms and different operating systems. Like OS
X, Windows or Linux.
• Easy support, since it open source and widely used.
• Jenkins also supports cloud based architecture so that we can deploy Jenkins in cloud based
platforms.
Jenkins Architecture

• Jenkins follows Master-Slave

architecture to manage distributed
builds. In this architecture, slave and
master communicate through TCP/IP
protocol.
• Jenkins architecture has two
components:
• Jenkins Master/Server
• Jenkins Slave/Node/Build Server
 Jenkins Master
• The main server of Jenkins is the Jenkins Master. It is a web dashboard which is nothing but
powered from a war file. By default it runs on 8080 port.
• With the help of Dashboard, we can configure the jobs/projects but the build takes place in
Nodes/Slave.
• By default one node (slave) is configured and running in Jenkins server. We can add more nodes
using IP address, username and password using the ssh, jnlp or webstart methods.
• The server's job or master's job is to handle:
• Scheduling build jobs.
• Dispatching builds to the nodes/slaves for the actual execution.
• Monitor the nodes/slaves (possibly taking them online and offline as required).
• Recording and presenting the build results.
• A Master/Server instance of Jenkins can also execute build jobs directly.
 Jenkins Slave

• Jenkins slave is used to execute the build jobs

dispatched by the master.
• We can configure a project to always run on a
particular slave machine, or particular type of slave
machine, or simple let the Jenkins to pick the next
available slave/node.
• As we know Jenkins is developed using Java is
platform independent thus Jenkins Master/Servers and
Slave/nodes can be configured in any servers
including Linux, Windows, and Mac.
How Jenkins Master and Slave Architecture works?

• The above image represents the following

functions:
• Jenkins checks the Git repository at periodic
intervals for any changes made in the source
code.
• Each builds requires a different testing
environment which is not possible for a single
Jenkins server.
• In order to perform testing in different
environments, Jenkins uses various Slaves as
shown in the diagram.
• Jenkins Master requests these Slaves to
perform testing and to generate test reports.
 Working of Jenkins Architecture
• This architecture works in following steps:

• The developer commits the changes in the source code repository

• The CI server of Jenkins then checks the repository and pulls the newly
changed code at regular intervals.

• The build server builds the pulled code into an executable file. Feedback is
sent to the developers in case of failure of the build.

• Jenkins deploys the build application on the test server. The developers are
alerted if it fails.

• If the tests are successful and the code is error-free, the tested application is
deployed on the production server.

• In some cases, files may have different code and require multiple builds and
the Jenkins server cannot handle multiple builds simultaneously for this, the
Master distributes the workload and allows us to run different builds on
different environments each called a Slave.
Continuous delivery (CD)

• Continuous delivery is a software development practice that uses automation to

speed the release of new code.
• It establishes a process through which a developer’s changes to an application can
be pushed to a code repository or container registry through automation.
• Continuous delivery (CD) is an approach for software delivery in which
development teams produce and test code in short but continuous cycles, usually
with high degrees of automation, to improve software quality.
• This process enables development teams to build, test and deploy software quickly
by encouraging more incremental updates, rather than spending a large portion of
time on a complete overhaul of a given product.
 CI/CD Pipeline
• There is not one standard continuous delivery pipeline. The common denominator between typical pipelines is the focus on subjects like automated builds, tests and staging deployments
into one continuous process. The following are general stages in a CI/CD process:

• Source. The first step in the pipeline is where developers write and commit the smallest distributable units of code. The code gets tested by reviews, unit tests and static analysis. Tests on
small amounts of code can be more efficient than end-to-end tests.

• Build. The source code is collected from the repository, linked to libraries, modules and dependencies, and compiled into an executable file. Tools log the process and denote errors to fix.

Some builds may employ scripts to translate the executable file into a packaged or deployable execution environment, such as a VM or a Docker container.

• Test. At this point, the code should be executable. It is tested at the subsystem level, including functional, performance and security tests. These ensure that the developed code meets the
quality standards of an end user and the specifications of the project. Integrated subsystems require UI and networks tests, and may still need other functional, performance and security

reviews. Automate these tests wherever possible. At this phase in the pipeline, the application components can be kept separate to form microservices or integrated together as one

complete system.

• Deploy. Finally, the software should be ready to be deployed into the production environment, but first, the code is manually checked one last time. Blue/green deployment is a common

method of deployment for continuous delivery, where two environments are configured identically -- one environment serves end users, while the other is ready for new code to deploy
and undergo testing, such as a load test to measure performance at a high capacity. When the released code is deemed ready, the environments switch traffic sources, and the new code

becomes available to users. Any issues discovered after the switch are rerouted back to the previous environment where the software team addresses the problem.
CI/CD pipeline
 Benefits of continuous delivery

• Simplicity. A development team spends less time preparing a code base for release and doesn't bundle
multiple individual changes together for a large release. Instead, developers continuously update and release
code in small increments.

• Faster debugging. Small releases reveal bugs in new code quickly. For example, if a bug is found in code
deployed into the production environment, developers can isolate the offending code to one of the last
incremental updates, fix the problem, test the code, redeploy it and receive new feedback.

• Faster development cycles. Continuous delivery enables faster application iterations, as it enables many
developers to collaborate on and create code at different times without harming other projects. If an iterative
process becomes unwieldy due to increasing project complexity, continuous delivery offers developers a way
to get back to smaller, more frequent releases that are more reliable, predictable and manageable.
Continuous Deployment
• Continuous Deployment (CD) is an aspect of the Continuous Delivery Pipeline that automates the migration of new functionality
from a staging environment to production, where it is made available for release.

• Continuous deployment (CD) is a software development approach in which code changes to an application are deployed into the
production environment automatically.

• Every time the codebase sees a change, it goes through a set of tests before goes to live, and an automatic check gate
authenticates the changes.

• Changes in the production environment are visible to developers in real-time because it is automated. This allows for quicker
response, allowing the team(s) to inspect and adjust in real-time.

• A feedback loop is included in the Continuous Deployment pipeline, which necessitates continuous monitoring of the process in
order to spot issues and take corrective action.

• The Business gains a competitive advantage by automating the entire process (from code contribution to go live) because
their Time to Market (TTM) is always shorter.
 Process of Continuous Deployment
• The continuous deployment pipeline is made up of a set of processes that take the code from development to
production.

• All of the steps are automated, and one step's output feeds into the next.

• Continuous monitoring ensures that the code is bug-free and meets the pre-approved quality check gates.

• The Four Activities of Continuous Deployment

• Deploy – the practices necessary to deploy a solution to a production environment

• Verify – the practices needed to ensure solution changes operate in production as intended before releasing
them to customers

• Monitor – the practices to monitor and report on any issues that may arise in production

• Respond – the practices to address any problems rapidly which may occur during deployment
 Step 1: Deploy
• When developers release a new piece of code to the production environment, the deployment process is triggered
automatically, and we refer to this as a "build."
• In continuous deployment, the entire process from code commit to final deployment is ideally a one-click
procedure.
Application Deployment Strategies Considerations:
• Minimum application downtime if any
• Manage and resolve incident with minimal impact on users
• Address failed deployments in a reliable effective way
• Minimize people and process errors to achieve predictable repeatable deployments
Deployment Patterns
• Recreate Deployment Patterns
• Rolling update Deployment Patterns
• Blue/green Deployment Patterns
• Canary Deployment Patterns
• A/B Deployment Patterns
• Shadow Deployment Patterns
Recreate Deployment Pattern
Recreate Deployment Pattern
• Key Benefits
• Simplicity
• Avoid backward compatibility challenges
• Considerations
• Downtime is not an issue
• if application is not Mission critical application
Rolling update deployment Pattern
Rolling update deployment Pattern
• Key Benefits
• No downtime
• Reduced deployment risk
• Considerations
• Slow rollback
• Backward Compatibility
Blue/green deployment pattern
Blue/green deployment pattern
• Key Benefits
• No downtime
• Instant rollback
• Environment separation
• Considerations
• Cost and operational overhead
• Backward Compatibility
• Cutover
Canary Deployment Pattern
Canary Deployment Pattern
• Key Benefits
• Zero downtime
• Ability to test live traffic
• Fast rollback
• Considerations
• Slow rollout
• Observability
• Backward compatibility
A/B Deployment Pattern
A/B Deployment Pattern
• Key Benefits
• Measure
• Target audience and Monitor
• Considerations
• Complex setup
• Validity of result
• Observability
Summary of Deployment Patterns
 Step 2: Verification
• In Continuous Deployment, it's critical to test the build/application before releasing it.
• Last-minute verifications frequently reveal flaws that were overlooked earlier in the process and must be
addressed right away to have the greatest impact.
• Various tests are carried out to ensure that the application performs as expected and that the production
environment is not contaminated.
• The verification process involves four practices:
• Test Automation – The ability to automate testing on a regular basis

• Production Testing – The ability to test solutions in production while they are still in a state of ‘darkness'

• Test Data Management – In order to ensure consistency in automatic testing, test data should be kept in
version control

• Testing Non-functional Requirements (NFRs) – Before a system is released, it must be thoroughly

tested for security, reliability, performance, maintainability, scalability, and usability
Step 3: Monitor
• Constant monitoring is a critical technique in the CD process for ensuring compliance and mitigating
potential risks.
• It aids in visualizing the performance of your application and any other parameter chosen by the
project leaders.
• Monitoring improves the consistency of claims and the responsiveness of teams.
• The monitoring process is aided by these four aspects:
• Full-stack Telemetry – The capacity to keep an eye on a system's entire stack for potential issues

• Visual Displays – Displaying automated measurements with tools

• Federated Monitoring – In the system, unified monitoring across applications gives a comprehensive view
of problems and performance

• User-behavior Tracking – Tracking the user's experience to collect qualitative and quantitative data and
analyze the interactions between the user and the application
 Step 4: Response and Recovery
• For business agility, the ability to respond is crucial.
• The Mean Time to Resolve (MTTR) is a metric that measures your team's preparedness to respond to and resolve issues.
• In agile software development, MTTR vs. MTTF is essential and decision-influencing indicators. When an issue or incident is detected,
immediate action should be taken because otherwise, business operations may be harmed or, worse, the brand value may be jeopardized.
The problem's root cause must be recognized and resolved.
• Five practices that can help your team be more responsive:

• Proactive Detection – A practice of proactively introducing flaws into a solution in order to detect prospective problems and scenarios
before they exist

• Collaboration between Team – A collaborative mentality across the Value Stream to identify and resolve issues as they emerge

• Session Reply – The capacity to replay end-user sessions in order to investigate occurrences and pinpoint issues

• Rollback and Fix Forward – The ability to easily rewind a solution to a previous environment, as well as to swiftly correct a problem
through the pipeline without having to rollback

• Immutable infrastructure – This concept suggests that teams never make uncontrolled changes to the production environment, but
rather manage infrastructure modifications through the Continuous Delivery pipeline
Benefits of Continuous Deployment
• Continuous Development and DevOps can result in lightning-fast releases, but it isn't the only benefit those
businesses are finding from CD adoption. Here are a few of the benefits of continuous deployment:
• Quick New Releases
The most important feature of continuous deployment is that it allows development teams to deliver new
releases into production as soon as feasible.
• Secure
Releases are less dangerous because they are thoroughly tested and all bugs are addressed prior to release.
• Rapid Feedback Loop with Customers
A shorter feedback loop with the consumer equals more frequent updates to your application. Developer
teams can examine the impact of a new modification on user behaviour or engagement using cutting-edge
monitoring tools and make adjustments as needed.
• Continuous Improvements
Customers can see continual improvements due to Continuous Deployment.
• Increases Workforce Productivity
Continuous deployment automates the majority of software development tasks. The developer does not need
to be concerned with the integration, deployment, or testing of the code.
Challenges in Continuous Deployment
• Resistance
Employees may find it difficult to transition from traditional methods to Continuous Deployment. Developers
are expected to enhance their knowledge of operations tasks, and Ops are expected to keep up with the pace
that the Devs and Business demand. The organization faces a problem as a result of its opposition.
• Structure
Some may believe that having more developers and larger teams would speed up software development.
Using larger teams, on the other hand, can stifle the transformation. Deployment cycles will be delayed by
larger teams with weak communication channels. This could cause issues with coordination, creativity, and
version control.
• Tools
Continuous Deployment is not a new process, yet it is. Both knowing too many and not understanding any
tools might be problematic. For a successful implementation, the teams must have sufficient knowledge of the
tools, their setups, and combinations. Finding and implementing the proper tool with the exact configurations
and combinations could be tricky.
• Architecture
Monolithic architecture is used by some organizations, which is a major hurdle to achieving Continuous
Deployment. It will be difficult to work on a feature without affecting others because the code and database of
monolithic systems are often intertwined. It's not always easy to recognize the impact until it's too late. It will
be difficult to change the architecture.
 Tools for Continuous Deployment
• DeployBot – Without the requirement for a full Continuous Integration system, it makes deployment
simple, fast, and easy.
• GitLab – It's made for Continuous Deployment, and it maintains projects using a user-friendly
interface.
• AWS CodeDeploy – A completely managed software deployment service for computing services
like AWS Lambda, Amazon EC2, AWS Fargate, and servers.
• Octopus Deploy – It's a tool for managing and automating code releases and deployments.
• Bamboo – This tools that assist in integrating and configuring automated builds, testing, and releases
into a single DevOps pipeline.
• Jenkins – It's an open-source automation server that lets developers build, test, and deploy
applications with confidence.
• TeamCity – This tool supports VE and runs on all operating systems, and it works with all known
testing frameworks and code QA tools.
 Docker Overview
• Docker is a software containerization platform, meaning
you can build your application, package them along with
their dependencies into a container and then these
containers can be easily shipped to run on other
machines.
• Docker is an open platform for developing, shipping, and
running applications.
• Docker enables you to separate your applications from
your infrastructure so you can deliver software quickly.
• With Docker, you can manage your infrastructure in the
same ways you manage your applications.
• Sysadmins need not worry about infrastructure as Docker
can easily scale up and scale down the number of systems.
• Docker comes into play at the deployment stage of the
software development cycle.
 Docker Overview
• For example:
• Lets consider a linux based application which has been written both in Ruby and Python. This application
requires a specific version of linux, Ruby and Python.
• In order to avoid any version conflicts on user’s end, a linux docker container can be created with the
required versions of Ruby and Python installed along with the application.
• Now the end users can use the application easily by running this container without worrying about the
dependencies or any version conflicts.
 Docker Overview
What is Virtualization?
• Virtualization is the technique of importing a Guest operating system on top
of a Host operating system.

• This technique was a revelation at the beginning because it allowed

developers to run multiple operating systems in different virtual machines all
running on the same host.

• This eliminated the need for extra hardware resource.

• The advantages of Virtual Machines or Virtualization are:

• Multiple operating systems can run on the same machine
• Maintenance and Recovery were easy in case of failure conditions
• Total cost of ownership was also less due to the reduced need
for infrastructure There is a host operating system on
• The disadvantages of Virtualization: which there are 3 guest operating
• Running multiple Virtual Machines leads to unstable performance systems running which is nothing but
• Hypervisors are not as efficient as the host operating system
the virtual machines.
• Boot up process is long and takes time
Docker vs Virtual Machines
• The virtual environment has a hypervisor layer, whereas Docker has a
Docker engine layer.
• There are additional layers of libraries within the virtual machine, each
of which compounds and creates very significant differences between a
Docker environment and a virtual machine environment.
• With a virtual machine, the memory usage is very high, whereas, in a
Docker environment, memory usage is very low.
• In terms of performance, when you start building out a virtual machine,
particularly when you have more than one virtual machine on a server,
the performance becomes poorer. With Docker, the performance is
always high because of the single Docker engine.
• In terms of portability, virtual machines just are not ideal. They’re still
dependent on the host operating system, and a lot of problems can
happen when you use virtual machines for portability. In contrast,
Docker was designed for portability. You can actually build solutions in
a Docker container, and the solution is guaranteed to work as you have
built it no matter where it’s hosted.
• The boot-up time for a virtual machine is fairly slow in comparison to
the boot-up time for a Docker environment, in which boot-up is almost
instantaneous.
Docker vs Virtual Machines
• One of the other challenges of using a virtual machine is that if
you have unused memory within the environment, you cannot
reallocate it. If you set up an environment that has 9 gigabytes
of memory, and 6 of those gigabytes are free, you cannot do
anything with that unused memory. With Docker, if you have
free memory, you can reallocate and reuse it across other
containers used within the Docker environment.
• Another challenge of virtual machines is that running multiples
of them in a single environment can lead to instability and
performance issues. Docker, on the other hand, is designed to
run multiple containers in the same environment—it actually
gets better with more containers run in that hosted single
Docker engine.
• Virtual machines have portability issues; the software can work
on one machine, but if you move that virtual machine to
another machine, suddenly some of the software won’t work,
because some dependencies will not be inherited correctly.
Docker is designed to be able to run across multiple
environments and to be deployed easily across systems.
• The boot-up time for a virtual machine is about a few minutes,
in contrast to the milliseconds it takes for a Docker
environment to boot up.
Containerization
• What is Containerization?
• Containerization is the technique of bringing virtualization to
the operating system level.
• While Virtualization brings abstraction to the hardware,
Containerization brings abstraction to the operating system.
Do note that Containerization is also a type of Virtualization.
Containerization is however more efficient because there is no
guest OS here and utilizes a host’s operating system, share
relevant libraries & resources as and when needed unlike
virtual machines. Application specific binaries and libraries of
containers run on the host kernel, which makes processing and
execution very fast. Even booting-up a container takes only a
fraction of a second. Because all the containers share, host
operating system and holds only the application related
binaries & libraries. They are lightweight and faster than
Virtual Machines.
• Advantages of Containerization over Virtualization: There is a host operating system which is
• Containers on the same OS kernel are lighter and smaller shared by all the containers. Containers
• Better resource utilization compared to VMs only contain application specific libraries
• Boot-up process is short and takes few seconds which are separate for each container
and they are faster and do not waste any
resources.
Important Terminologies in Docker
1. Docker Image
• It is a file, comprised of multiple layers, used to execute code in a Docker container.
• They are a set of instructions used to create docker containers.
2. Docker Container
• It is a runtime instance of an image.
• Allows developers to package applications with all parts needed such as libraries and other
dependencies.
3. Docker file
• It is a text document that contains necessary commands which on execution helps assemble a
Docker Image.
• Docker image is created using a Docker file.
Important Terminologies in Docker
4. Docker Engine
• The software that hosts the containers is named Docker Engine.
• Docker Engine is a client-server based application
• The docker engine has 3 main components:
• Server: It is responsible for creating and managing Docker images, containers, networks, and
volumes on the Docker. It is referred to as a daemon process.
• REST API: It specifies how the applications can interact with the Server and instructs it what
to do.
• Client: The Client is a docker command-line interface (CLI), that allows us to interact with
Docker using the docker commands.
• 5. Docker Hub
• Docker Hub is the official online repository where you can find other Docker Images that are
available for use.
• It makes it easy to find, manage, and share container images with others.
 Docker Architecture
• Docker architecture consists of:
• Docker client,
• Docker Daemon running on Docker Host,
• Docker Hub repository.
• Docker has client-server architecture in which the
client communicates with the Docker Daemon
running on the Docker Host using a combination of
REST APIs, Socket IO, and TCP.
• If we have to build the Docker image, then we use the
client to execute the build command to Docker
Daemon then Docker Daemon builds an image based
on given inputs and saves it into the Docker registry.
• If you don’t want to create an image, then just
execute the pull command from the client and then
Docker Daemon will pull the image from the Docker
Hub
• Finally, if we want to run the image then execute the
run command from the client which will create the
container.
Components of Docker
1. Docker Clients and Servers–
• Docker has a client-server architecture. The
Docker Daemon/Server consists of all
containers.
• The Docker Daemon/Server receives the
request from the Docker client through CLI or
REST APIs and thus processes the request
accordingly.
• Docker client and Daemon can be present on
the same host or different host.
Components of Docker
2. Docker Images–

• Docker images are used to build docker containers by using a read-only template.

• The foundation of every image is a base image eg. base images such as – ubuntu14.04 LTS, and Fedora 20.

• Base images can also be created from scratch and then required applications can be added to the base image by modifying it thus this process

of creating a new image is called “committing the change”.

3. Docker File–

• Dockerfile is a text file that contains a series of instructions on how to build your Docker image.

• This image contains all the project code and its dependencies.

• The same Docker image can be used to spin ‘n’ number of containers each with modification to the underlying image.

• The final image can be uploaded to Docker Hub and shared among various collaborators for testing and deployment.

• The set of commands that you need to use in your Docker File is FROM, CMD, ENTRYPOINT, VOLUME, ENV, and many more.
Components of Docker
4. Docker Registries–

• Docker Registry is a storage component for Docker images.

• We can store the images in either public/private repositories so that multiple users can collaborate in building the application.

• Docker Hub is Docker’s cloud repository. Docker Hub is called a public registry where everyone can pull available images and push
their images without creating an image from scratch.

5. Docker Containers–

• Docker Containers are runtime instances of Docker images.

• Containers contain the whole kit required for an application, so the application can be run in an isolated way.

• For eg.- Suppose there is an image of Ubuntu OS with NGINX SERVER when this image is run with the docker run command, then a
container will be created and NGINX SERVER will be running on Ubuntu OS.
 Anatomy of a Docker Image
• A Docker image is made up of a collection of files that bundle together all the essentials –
such as installations, application code, and dependencies – required to configure a fully
operational container environment.

• A Docker image can be created by using one of two methods:

• Interactive: By running a container from an existing Docker image, manually changing

that container environment through a series of live steps, and saving the resulting state as
a new image.

• Dockerfile: By constructing a plain-text file, known as a Dockerfile, which provides the

specifications for creating a Docker image.
 Anatomy of a Docker Image
• Image Layers
• Each of the files that make up a Docker image is known as a layer.
• These layers form a series of intermediate images, built one on top of the other in
stages, where each layer is dependent on the layer immediately below it.
• The hierarchy of your layers is key to efficient lifecycle management of your Docker
images.
• Thus, you should organize layers that change most often as high up the stack as
possible.
• This is because, when you make changes to a layer in your image, Docker not only
rebuilds that particular layer, but all layers built from it. Therefore, a change to a layer
at the top of a stack involves the least amount of computational work to rebuild the
entire image.
• Container Layer
• Each time Docker launches a container from an image, it adds a thin writable layer,
known as the container layer, which stores all changes to the container throughout its
runtime.
• As this layer is the only difference between a live operational container and the source
Docker image itself, any number of like-for-like containers can potentially share
access to the same underlying image while maintaining their own individual state.
 Anatomy of a Docker Image
• Parent Image
• In most cases, the first layer of a Docker image is known as the parent image.
• It’s the foundation upon which all other layers are built and provides the basic building blocks for your
container environments.
• You can find a wide variety of ready-made images for use as your parent image on the public container
registry Docker Hub.
• You can also find them on a small number of third-party services, such as the Google Container Registry.
Alternatively, you can use one of your own existing images as the basis for creating new ones.
• A typical parent image may be a stripped-down Linux distribution or come with a preinstalled service, such as
a database management system (DBMS) or a content management system (CMS).
• Base Image
• In simple terms, a base image is an empty first layer, which allows you to build your Docker images from
scratch.
• Base images give you full control over the contents of images, but are generally intended for more advanced
Docker users.
 Container Registries
• Container registries are catalogs of storage locations, known as repositories, where you can push and pull container images. The three main

registry types are:

• Docker Hub: Docker’s own, official image resource where you can access more than 100,000 container images shared by software vendors,
open-source projects, and Docker’s community of users. You can also use the service to host and manage your own private images.

• Third-party registry services: Fully managed offerings that serve as a central point of access to your own container images, providing a way to

store, manage, and secure them without the operational headache of running your own on-premises registry. Examples of third-party registry
offerings that support Docker images include Red Hat Quay, Amazon ECR, Azure Container Registry, Google Container Registry, and the JFrog

Container Registry.

• Self-hosted registries: A registry model favored by organizations that prefer to host container images on their own on-premises infrastructure –
typically due to security, compliance concerns or lower latency requirements. To run your own self-hosted registry, you’ll need to deploy a
registry server. Alternatively, you can set up your own private, remote, and virtual Docker registry.
Container Repositories

• Container repositories are the specific physical locations where your Docker images are actually
stored, whereby each repository comprises a collection of related images with the same name.
• Each of the images within a repository is referenced individually by a different tag and represents a
different version of fundamentally the same container deployment.
• For example, on Docker Hub, mysql is the name of the repository that contains different versions
of the Docker image for the popular, open-source DBMS, MySQL.
 How to Create a Docker Image
• Interactive Method

• Advantages: Quickest and simplest way to create Docker images. Ideal for testing, troubleshooting, determining dependencies, and validating processes.

• Disadvantages: Difficult lifecycle management, requiring error-prone manual reconfiguration of live interactive processes. Easier to create unoptimized images

with unnecessary layers.

• The following is a set of simplified steps to creating an image interactively:

• Install Docker and launch the Docker engine

• Open a terminal session

• Use the following Docker run command to start an interactive shell session with a container launched from the image specified by image_name:tag_name:

• $ docker run -it image_name:tag_name bash

• If you omit the tag name, then Docker automatically pulls the most recent image version, which is identified by the latest tag. If Docker cannot find the image locally

then it will pull what it needs to build the container from the appropriate repository on Docker Hub.

• In our example, we’ll launch a container environment based on the latest version of Ubuntu:

• $ docker run -it ubuntu bash

How to Create a Docker Image
• Now configure your container environment by, for example, installing all the frameworks, dependencies, libraries, updates, and application code you need. The
following simple example adds an NGINX server:
• # apt-get update && apt-get install -y nginx
• Next, you’ll need to know the name or ID of your running container instance.
• Open another Bash shell and type the following docker ps command to list active container processes:
• $ docker ps
• The sample output below shows our running container with the ID e61e8081866d and the name keen_gauss:
• CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
• e61e8081866d ubuntu “bash” 2 minutes ago Up 2 minutes keen_gauss
• This name is randomly generated by the Docker daemon. But you can also identify your container with something more meaningful by assigning your own name
using the – name operator in the Docker run command.
• Save your image using the Docker commit command, specifying either the ID or name of the container from you which want to create it:
• $ docker commit keen_gauss ubuntu_testbed
• In the example above, we supplied the name of our container and called the resulting image ubuntu_testbed.
• Now, use the Docker images command to see the image you’ve just created:
• $ docker images
• You should see your new image listed in the results.
• REPOSITORY TAG IMAGE ID CREATED SIZE
ubuntu latest 775349758637 5 minutes ago 64.2MB
• Finally, return to your interactive container shell and type exit to shut it down.
• # exit
 How to Create a Docker Image
• Dockerfile Method

• Advantages: Clean, compact and repeatable recipe-based images. Easier lifecycle management and easier integration into continuous
integration (CI) and continuous delivery (CD) processes. Clear self-documented record of steps taken to assemble the image.

• Disadvantages: More difficult for beginners and more time consuming to create from scratch.

• The Dockerfile approach is the method of choice for real-world, enterprise-grade container deployments. It’s a more systematic,
flexible, and efficient way to build Docker images and the key to compact, reliable, and secure container environments.

• In short, the Dockerfile method is a three-step process whereby you create the Dockerfile and add the commands you need to
assemble the image.

• The following table shows you those Dockerfile statements you’re most likely to use:
How to Create a Docker Image
The following table shows you those Dockerfile statements you’re most likely to use:

Command Purpose

FROM To specify the parent image.

WORKDIR To set the working directory for any commands that follow in the Dockerfile.

RUN To install any applications and packages required for your container.

COPY To copy over files or directories from a specific location.

ADD As COPY, but also able to handle remote URLs and unpack compressed files.

ENTRYPOINT Command that will always be executed when the container starts. If not specified, the default is /bin/sh -c

CMD Arguments passed to the entrypoint. If ENTRYPOINT is not set (defaults to /bin/sh -c), the CMD will be the commands the container executes.

EXPOSE To define which port through which to access your container application.

LABEL To add metadata to the image.

Advantages of Docker
• Docker has become popular nowadays because of the benefits provided by Docker containers. The main advantages of Docker are:

• Speed – The speed of Docker containers compared to a virtual machine is very fast. The time required to build a container is very
fast because they are tiny and lightweight. Development, testing, and deployment can be done faster as containers are small.
Containers can be pushed for testing once they have been built and then from there on to the production environment.

• Portability – The applications that are built inside docker containers are extremely portable. These portable applications can easily
be moved anywhere as a single element and their performance also remains the same.

• Scalability – Docker has the ability that it can be deployed on several physical servers, data servers, and cloud platforms. It can also
be run on every Linux machine. Containers can easily be moved from a cloud environment to a local host and from there back to the
cloud again at a fast pace.

• Density – Docker uses the resources that are available more efficiently because it does not use a hypervisor. This is the reason that
more containers can be run on a single host as compared to virtual machines. Docker Containers have higher performance because of
their high density and no overhead wastage of resources.