The purpose of this solution is to go over the Docker basics which explain containers, images, how they work, where to find them, the architecture (client, daemon), the difference between Docker and VMs, and we will see Docker and an image and see some commands.

1. Dockers and Containers
The purpose of this solution is to go over the Docker basics which explain
containers, images, how they work, where to find them, the architecture (client,
daemon), the difference between Docker and VMs, and we will see Docker and an
image and see some commands.
 Sourabh Saxena

2. Containers
To understand Docker you have to start at containers.
Container technology has been around since the days of the
mainframe, but it has resurged in the last couple of years due
to the increase in virtualization and the rise of microservice
architecture.
 A container is created from a container image. Images are tarballs
with a JSON configuration file attached.
 A Docker container image includes everything needed to run an
application: code, runtime, system libraries, etc.
 When using containers, there is a single operating system installed on
the physical hardware which each container makes use of. Illustrated
in the diagram above we have two containers (app 1 and app 2)
sitting atop the Docker engine. Note that the containers themselves
are not a complete operating system, the complete system is within
the host OS.

3.  The container only contains the application and the required binaries and libraries
that support that particular application. Why? So the app runs quickly and reliably
from one computing environment to another.
 Container images become containers at runtime. The runtime is software that
executes the container, which means telling the kernel to assign resource limits,
create isolation layers (for processes, networking, and filesystems), and so on.
Basically the runtime describes the configuration, execution environment, and
lifecycle of a container.
 The story of container runtimes has had many twists and turns and makes for exciting
reading which we aren’t going to cover in any great detail save to say the names you
may have heard to help you connect the dots.
 Rkt is a container runtime created by CoreOs (part of RedHat and now IBM)
 CRI-O another runtime was built by some RedHat folks to make an even
simpler runtime to Rkt; and that would only do what Kubernetes needed
 Along the same time Docker updated its runtime Containerd which was
donated to the CNCF in 2018
 And finally we have the OCI (Open Container Initiative) which is NOT a runtime (or
our Oracle Cloud Infrastructure also known as OCI) but the organization created to
manage define and standardize runtimes. You may ask, why so many runtimes? Well,
since its inception Docker has been known as a big project doing too many things,
and the other players just wanted a simple, standardized runtime.

4. Images
As you can see from the picture above, an image is a collection of read-
only files and some metadata that include executable code (system
libraries, system tools and other platforms settings a software program
needs to run) so it can run an isolated process.
These images are made of layers that are conceptually stacked on one
another with each layer being able to add, change or remove files. A
storage driver handles the details about the way these layers interact with
each other.
A container is a running instance of an image. You can have many
running containers of the same image. To make changes to introduce
more functionality, fix bugs or otherwise change the image, you create a
new container from that image and make changes to the files presented
from the base image of that container on the read-write layer (container
layer) of your new container.

5. For increased automation, the set of layers can be described by the user in a Dockerfile, and these
are assembled into the image. A Dockerfile is a series of commands or operations that define how to
build an image. The image is built up of read-only layers, with each instruction in the Dockerfile
resulting in a new read-only layer based on the previous layer. The resulting image is also read-only.
Let's look at a Dockerfile briefly.
FROM ubuntu:15.04
COPY . /app
RUN make /app
CMD python /app/app.py
This Dockerfile contains four commands, each of which creates a layer.
 The FROM statement starts by creating a layer from the ubuntu:15.04 image.
 The COPY command adds some files from your Docker client’s current directory.
 The RUN command builds your application.
 Finally, the last layer specifies what command to run within the container.

6. Note: That "ubuntu" image in the Dockerfile above is a public image from Docker Hub and 15.04 is a
tag which describes the version. The use of layers, images, and copy-on-write means there is a strong
emphasis on building generic images that can be reused and shared (like the ubuntu image above)
to optimize disk storage. Once you have a running container, avoid making additional configuration
changes to it, which includes upgrades and patches. Instead, make the necessary changes in the
Dockerfile and/or configuration scripts, rebuild the image, then run a new container based on the
updated image.
A slightly advanced topic is that when you are trying to make containers that are stateless, anything
important that shouldn't be thrown away when the container is dropped and run again should be
held in persistent storage, not in the container itself.

7. Get Images
 Now that you know what they are, you're probably wondering where to find them. Many
software vendors create publicly available images of their products.
 The way they make them available is through a Container Registry such as Docker Hub or Docker
Store.
 How is Docker Store different from Docker Hub? Docker Hub contains community content -
these are images that have been created by entities that are not vetted or curated; anyone can
push new images to the community, and there are no guarantees around the quality or
compatibility of this content. For official Oracle images go to the Docker Store.

8. Docker Architecture
Now that we have covered containers and images, let's have a
look at Docker.

9.  Docker as a whole is composed of many different tools, but when most people talk about
installing and using Docker, it’s about the Docker daemon and Docker CLI.
 Look at the image above. The image on the left is the Docker client. The Docker client makes the
calls to the Docker daemon to pull an image, create a container, delete a container, attach a
network, remove storage (you get the picture) - all these actions are from the Docker client which
uses the exposed Docker API to connect with the Docker daemon. The client could be installed on
your laptop running Windows, MacOS or a server running Linux.
 The next picture in the middle is the Docker daemon. The Docker daemon runs on a “host” server,
and this can be bare metal or a VM. The host is just the server that happens to be running the
Docker daemon. The client and daemon do not need to be on the same box. The daemon is
doing all the work that the client asks it to do.

10.  On the right, you have Docker containers (remember containers are lightweight
operating systems that have the required binaries and libraries, created out of
multiple images, to support our application. You can deploy every application you
can think of in any language be it Java, Python, Perl (I mean, you could), and you
don’t need to stop there. Under particular conditions you could deploy
a database.

11. Let's look at the daemon (the bit in
the middle in the picture below) in
closer detail.
The Docker daemon (green circle of the picture) listens for the
Docker API requests and manages Docker objects such as
images, containers, networks, and volumes. The daemon itself
exposes a REST API where a number of different tools can talk to
the daemon. Docker client - is the primary way that many
Docker users interact with Docker. When you use commands
such as docker run the client sends these commands to the
daemon which then carries them out. The picture below
illustrates this.

12. What’s the Difference from VMs?
Let's have a look at this diagram below.

13.  With virtualization, You have three layers: Infrastructure, Host Operating System, and the
Hypervisor with each virtual machine containing a copy of the OS and all the required
binaries and libraries to run the application (this can get pretty big, pretty fast).
 With containers, the Docker engine replaces the hypervisor and shares the host OS
among the containerized applications who themselves only have the required binaries
and libraries needed to run the applications (this greatly improves CPU utilization).
 So which is best? Containers are the answer in some situations while VMs are the answer
in others, and, in some cases, both should be deployed at the same time. It's about
understanding when and where each type of deployment is best for your organization.

14. Container Pros
 They deliver immutable infrastructure and solve the age-old “works on my machine”
problem.
 Once containerized, applications can be deployed on any infrastructure – on virtual
machines, on bare metal, and various public clouds running different hypervisors
 The improved CPU utilization within a VM means an organization can reduce the
number of virtual machines needed to operate their environment and increase the
number of applications that can run on a server
Container Cons
 Builds and deployments are slow and unpredictable
 Most standard Docker containers, meaning those running on a basic community or
commercial Docker Engine on Linux, are not isolated from each other like VMs

15. My First Docker
 First remove older version of Docker (if any )
yum remove docker docker-common docker-selinux docker-
engine-selinux

16. Next install needed packages -
yum install -y yum-utils device-mapper-persistent-data lvm2

17.  Configure the docker-ce repo –
yum-config-manager --add-repo
https://download.docker.com/linux/centos/docker-ce.repo

18.  Install docker-ce -
sudo yum install docker-ce

21.  systemctl start docker

22.  docker info

23.  docker –version

24.  How to test your docker installation
 Docker images are pulled from docker cloud/hub such as docker.io or registry.access.redhat.com
and so on. Type the following command to verify that your installation working:
# docker run hello-world

25.  Docker images

26. DOCKER CONFIGS
 By default, docker store containers and images in /var/lib/docker by default:
ls -al /var/lib/docker

27. Thanks !!