Module 4

Contents

 Container fundamentals
 Containers versus virtual machines
 Different container technologies
 Configuring a container engine
 Container virtual networking
 Container orchestration and clustering
 Images and containers
 Case study : Docker
Container fundamentals

 Containers are a form of operating system virtualization. A single

container might be used to run anything from a small microservice or
software process to a larger application. Inside a container are all the
necessary executables, binary code, libraries, and configuration files.
 A container is a standard unit of software that packages up code
and all its dependencies so the application runs quickly and
reliably from one computing environment to another. Available
for both Linux and Windows-based applications, containerized
software will always run the same, regardless of the infrastructure.
 Containers are executable units of software in which application code is packaged,
along with its libraries and dependencies, in common ways so that it can be run
anywhere, whether it be on desktop, traditional IT, or the cloud.
 To do this, containers take advantage of a form of operating system (OS)
virtualization in which features of the OS (in the case of the Linux kernel, namely
the namespaces and cgroups primitives) are leveraged to both isolate processes and
control the amount of CPU, memory, and disk that those processes have access to.
 Containers are small, fast, and portable because unlike a virtual machine,
containers do not need include a guest OS in every instance and can, instead,
simply leverage the features and resources of the host OS.
Containers vs. virtual machines (VMs)

 One way to better understand a container is to understand how it differs from a

traditional virtual machine (VM). In traditional virtualization—whether it be on-
premises or in the cloud—a hypervisor is leveraged to virtualize physical hardware.
Each VM then contains a guest OS, a virtual copy of the hardware that the OS
requires to run, along with an application and its associated libraries and
dependencies.
 Instead of virtualizing the underlying hardware, containers virtualize the operating
system (typically Linux) so each individual container contains only the application
and its libraries and dependencies. The absence of the guest OS is why containers
are so lightweight and, thus, fast and portable.
Benefits of containers
The primary advantage of containers, especially compared to a VM, is providing a
level of abstraction that makes them lightweight and portable.
 Lightweight: Containers share the machine OS kernel, eliminating the need for
a full OS instance per application and making container files small and easy on
resources. Their smaller size, especially compared to virtual machines, means
they can spin up quickly and better support cloud-native applications that scale
horizontally.
 Portable and platform independent: Containers carry all their dependencies
with them, meaning that software can be written once and then run without
needing to be re-configured across laptops, cloud, and on-premises computing
environments.
 Supports modern development and architecture: Due to a
combination of their deployment portability/consistency across
platforms and their small size, containers are an ideal fit for modern
development and application patterns—such as DevOps, serverless,
and microservices—that are built are regular code deployments in
small increments.
 Improves utilization: Like VMs before them, containers enable
developers and operators to improve CPU and memory utilization of
physical machines.
Use cases for containers
 Containers are becoming increasingly prominent, especially in cloud
environments. Many organizations are even considering containers as a
replacement of VMs as the general purpose compute platform for their
applications and workloads. But within that very broad scope, there are key
use cases where containers are especially relevant.
 Microservices: Containers are small and lightweight, which makes them a
good match for microservice architectures where applications are
constructed of many, loosely coupled and independently deployable
smaller services.
 DevOps: The combination of microservices as an architecture and
containers as a platform is a common foundation for many teams that
embrace DevOps as the way they build, ship and run software.
 Hybrid, multi-cloud: Because containers can run consistently
anywhere, across laptop, on-premises and cloud environments, they
are an ideal underlying architecture for hybrid cloud and multicloud
scenarios where organizations find themselves operating across a
mix of multiple public clouds in combination with their own data
center.
 Application modernizing and migration: One of the most common
approaches to application modernization starts by containerizing
them so that they can be migrated to the cloud.
Containerization

 Software needs to be designed and packaged differently in order to

take advantage of containers—a process commonly referred to as
containerization.
 When containerizing an application, the process includes packaging
an application with its relevant environment variables, configuration
files, libraries, and software dependencies. The result is a container
image that can then be run on a container platform.
Containers versus virtual machines
 Containers versus virtual machines
 Virtual machines and containers differ in several ways, but the
primary difference is that containers provide a way to virtualize an
OS so that multiple workloads can run on a single OS instance.
 With VMs, the hardware is being virtualized to run multiple OS
instances.
 Containers and VMs each have their uses–in fact, many deployments
of containers use VMs as the host operating system rather than
running directly on the hardware, especially when running containers
in the cloud.
Containers vs. virtual machines

Feature Virtual machine Container

Isolation Provides complete isolation from the Typically provides lightweight isolation
host operating system and other VMs. from the host and other containers, but
This is useful when a strong security doesn't provide as strong a security
boundary is critical, such as hosting apps boundary as a VM.
from competing companies on the same
server or cluster.

Operating system Runs a complete operating system Runs the user mode portion of an operating
including the kernel, thus requiring more system, and can be tailored to contain just
system resources (CPU, memory, and the needed services for your app, using
storage). fewer system resources.
Guest Runs just about any operating Runs on the same operating system
compatibility system inside the virtual machine. version as the host (Hyper-V
isolation enables you to run earlier
versions of the same OS in a
lightweight VM environment)

Deployment Deploy individual VMs by using Deploy individual containers by

Windows Admin Center or Hyper-V using Docker via command line;
Manager; deploy multiple VMs by deploy multiple containers by using
using PowerShell or System Center an orchestrator such as Azure
Virtual Machine Manager. Kubernetes Service.
Load balancing Virtual machine load balancing Containers themselves don't move;
moves running VMs to other instead an orchestrator can
servers in a failover cluster. automatically start or stop
containers on cluster nodes to
manage changes in load and
availability.

Fault tolerance VMs can fail over to another If a cluster node fails, any
server in a cluster, with the containers running on it are
VM's operating system rapidly recreated by the
restarting on the new server. orchestrator on another cluster
node.
Different container technologies

 Container runtimes
 Docker was the first major open-source container offering, and
quickly emerged as a de facto standard. Now Kubernetes is
evolving as the new standard for clusters and cluster management.
 Kubernetes initially supported Docker and rkt (or "rocket")
through custom code. But now, with the creation of the Container
Runtime Interface (CRI), you have many ways to store virtual
machines and at the same time communicate through that
interface.
What is clustering..??

 A computer cluster is a group of two or more computers, or nodes,

that run in parallel to achieve a common goal. This allows workloads
consisting of a high number of individual, parallelizable tasks to be
distributed among the nodes in the cluster. As a result, these tasks can
leverage the combined memory and processing power of each
computer to increase overall performance.
 Docker
 The first and still most popular container technology, Docker's open-
source containerization engine works with most of the products that
follow, as well as many open-source tools.
 Docker Enterprise
 This set of extensions not only adds features to Docker, but also
makes it possible for Docker (the company) to add commercial
support.
 CRI-O
 The first implementation of the Container Runtime Interface, CRI-O is
an incredibly lightweight, open-source reference implementation.
 rktlet
 The aforementioned rkt, redesigned and retooled to use the CRI as
rktlet, now has a set of supported tools and community to rival Docker.
 rkt is a container system developed by CoreOS as a light weight and
secure alternative to Docker. It is built based on an open container
standard known as “App Container” or “appc” specification.
 containerd
 A project of the Cloud Native Computing Foundation, containerd was an
early container format. More recently the developers of containerd built a
CRI plugin that lets Kubernetes run containerd in the same way it runs
rktlet or CRI-O.
 Microsoft Containers
 Positioned as an alternative to Linux, Microsoft Containers can support
Windows containers under very specific circumstances. They generally
run in a true virtual machine and not in a cluster manager like Kubernetes.
 Cluster management and deployment
 Cluster management tools manage workloads, including
moving instances from one virtual host to another based on
load, and allocate resources such as CPU and memory.
 Kubernetes
 While there is no standard for cluster management, the Kubernetes
open-source cluster manager, originally developed by Google, is far
and away the most popular. Supported by Amazon's AWS, Google's
Cloud Engine (GCE) and Microsoft's Azure Container service,
Kubernetes is relatively portable.
 Kubernetescan even run on a private cloud: OpenStack. Microsoft,
Amazon, and Google all provide container services that run
Kubernetes—with commercial support options available.
 Istio and Envoy
 Where Kubernetes provides load balancing and scalability, by default
it assumes that the same service will run the same version number
and that all services can talk to one another. Kubernetes does not
provide the tools to debug services that call services—sometimes
called "observability."
 Envoy and Istio are open-source service mesh technologies that
add a layer to provide security and observability. They can
encrypt traffic inside of the cluster while observing it. Developed by
Lyft, Envoy was the first service mesh for Kubernetes. Istio includes
Envoy, sits on top of it, and adds several plugins, dashboards, and
other features to extend it.
 Apache Mesos
 Apache Mesos is an open source cluster manager that handles
workloads in a distributed environment through dynamic resource
sharing and isolation. Mesos is suited for the deployment and
management of applications in large-scale clustered environments.
 Docker Swarm
 Docker swarm is a container orchestration tool, meaning that it
allows the user to manage multiple containers deployed across multiple
host machines. One of the key benefits associated with the operation of
a docker swarm is the high level of availability offered for
applications.
 Docker Datacenter
 More than just a commercial alternative to Kubernetes, Docker Datacenter is
designed as a drop-in replacement that lets you containerize your entire data
center, and it includes commercial support.
 Docker Datacenter (DDC) is the Containers as a Service (CaaS) platform
for enterprise IT and application teams. to build, ship and run, any
application anywhere.
 Of course, Docker Datacenter embraces and extends Docker's free, open-
source products: Docker and Swarm. The tool adds the load balancing and
scaling that Swarm is missing. And, of course, it works with Docker
Enterprise.
 Storage containers
 Containers are designed to be interchangeable, like currency. That
works exceptionally well for web services and microservices that
can scale on demand. Storage and databases, on the other hand, need
persistent locations to house data, or at least a standard interface
layer. Organizations that want to move to an all-container
infrastructure need storage, and companies now meet that demand.
 BlockBridge
 BlockBridge, the "elastic storage platform" company, offers storage as a
container using Docker, with support for Kubernetes, OpenStack, and
software-defined secure storage.
 EMC / libstorage
 The EMC / libstorage system offers a code library to provide container storage
that's free and open.
 Docker plugins for storage
 EMC, NetApp, and others have created plugins to support storage, which
Docker Inc. makes available for download.
 Configuring a container engine
 Although Docker containers are sandboxed, this doesn't prevent a stray rogue process
in one of the containers from hogging (take or use most or all of (something) in an
unfair or selfish way) the resources available to other containers, including the host.
 The practice of isolating a piece of software so that it can access only certain
resources, programs, and files within a computer system, so as to reduce the risk of
errors or malware affecting the rest of the system.] ⇒ Since Docker is expected to be
used in production, the possibility of one container stalling all others would be fatal.
 So, there are mechanisms to limit the number of resources that a container can take
ownership of.
 Constraining resources
⇒ It is imperative for any tool that promises sandboxing capabilities to provide a
mechanism to constrain resource allocation.
⇒ Docker provides mechanisms to limit the amount of CPU, memory and RAM that a
container can use when it is being started.
 Setting CPU share
⇒ The amount of CPU share a container takes up can be controlled using the -c
option in the docker run command: → $ docker run -c 10 -it ubuntu /bin/bash
⇒ The value, 10, is the relative priority given to this container with respect to other
containers. → By default, all containers get the same priority, and hence the same ratio
of CPU processing cycles, which you can check out by running.
⇒ However, you can give your own priority values when you run containers.
 Setting memory limit
⇒ Similarly, the amount of RAM that a container is allowed to consume
can also be limited while starting the container:
→ $ docker run -m <value><optional unit>
⇒ Here, unit can be b, k, m, or g, representing bytes, kilobytes,
megabytes, and gigabytes, respectively).
⇒ An example of a unit can be represented as follows:
→ $ docker run -m 1024m -dit ubuntu /bin/bash
→ This sets a memory limit of 1 GB for the container.
 Setting a storage limit on the virtual filesystem (Devicemapper)
⇒ Limiting disk usage can be a bit tricky. There is no direct way to limit the
amount of disk space a container can use. ⇒ The default storage driver, AUFS,
doesn't support disk quotas, at least not without hacks (the difficulty is because AUFS
does not have its own block device. )
→ The devicemapper driver is a Linux kernel framework used to map block
devices to higher-level virtual block devices.
⇒ The devicemapper driver creates a thin pool of storage blocks based on two
block devices (think of them as virtual disks), one for data and another for
metadata.
 Managing data in containers with volumes
→ Docker volumes are file systems mounted on Docker containers to preserve data
generated by the running container. The volumes are stored on the host, independent of
the container life cycle. This allows users to back up data and share file systems between
containers easily.
→ A volume is a directory that is separated from the container's root filesystem.
→ It is managed directly by the docker daemon (Docker Daemon: A persistent
background process that manages Docker images, containers, networks, and storage
volumes) and can be shared across containers.
→ A volume can also be used to mount a directory of the host system inside a container.
⇒ Creating a volume is easy. Just start a container with the -v option.
 Data-only container
⇒ A data-only container is a container that does nothing except exposing a
volume that other data-accessing containers can use.
⇒ Data-only containers are used to prevent volumes from being destroyed if
containers accessing the volume stop or crash due to an accident.
 Using volumes from another container
⇒ Once we start a container with a -v option, we have created a volume. We can
share the volumes created by a container with other containers using the --volumes-
from option.
→ Possible use cases of this option can be backing up databases,
processing logs, performing operations on user data, and so on.
 Configuring Docker to use a different storage driver
⇒ Before using a different storage driver, back up all your images with docker save and
stop the docker daemon.
⇒ Once you have backed up all your important images, remove /var/lib/docker. Once
you change the storage driver, you can restore the saved images.
→ We are now going to change our default storage driver, AUFS, to two
alternative storage drivers – devicemapper and btrfs.
 Configuring Docker’s network settings
⇒ Docker creates a separate network stack for each container and a virtual bridge
(docker0) to manage .
→ Network communication within the container, between the container and the
host, and between two containers.
⇒ There are a few network configurations that can be set as arguments to the docker run
command. They are as follows:
→ --dns: A DNS server is what resolves a URL, such as http://www.docker.io, to the
IP address of the server that is running the website.
→ --dns-search: This allows you to set DNS search servers.
 Configuring port forwarding between container and host
⇒ Containers can make connections to the outside world without any special
configurations, but the outside world is not allowed to peek into them. This is a
security measure and is fairly obvious, since the containers are all connected to
the host through a virtual bridge, thus effectively placing them in a virtual
network.
⇒ But what if you were running a service in a container that you wanted to
expose to the outside world? → Port forwarding is the easiest way to expose
services running in containers. It is always advisable to mention in the
Dockerfile of an image the ports that need to be exposed.
Dockerfile
yaml
CONTAINER ORCHESTRATION AND CLUSTERING

 Container Orchestration Engines (COE) are tools which help in managing many
containers running on multiple hosts.
 Introduction to COE
⇒ Containers provide users with an easy way to package and run their applications.
Packaging involves defining the library and tools that are necessary for a user's
application to run. These packages, once converted to images, can be used to create
and run containers.
⇒ These containers can be run anywhere, whether it's on developer laptops, QA
systems, or production machines, without any change in environment. Docker and
other container runtime tools provide the facility to manage the life cycle of such
containers.
 ⇒ Using these tools, users can build and manage images, run
containers, delete containers, and perform other container life cycle
operations. But these tools can only manage one container on a
single host. When we deploy our application on multiple containers
and multiple hosts, we need some kind of automation tool. This type
of automation is generally called orchestration.
 Orchestration tools provide a number of features, including:
→ Provisioning and managing hosts on which containers will run
→ Pulling the images from the repository and instantiating the containers
→ Managing the life cycle of containers
→ Scheduling containers on hosts based on the host's resource availability
→ Starting a new container when one dies
→ Scaling the containers to match the application's demand
→ Providing networking between containers so that they can access each other on
different hosts
→ Exposing these containers as services so that they can be accessed from
outside
→ Health monitoring of the containers
→ Upgrading the containers
 Generally, these kinds of orchestration tools provide declarative configuration in
YAML or JSON format. ⇒ These definitions carry all of the information related
to containers including image, networking, storage, scaling, and other things.
Orchestration tools use these definitions to apply the same setting to provide the
same environment every time.
 There are many container orchestration tools available, such as Docker Machine,
Docker Compose, Kuberenetes, Docker Swarm, and Apache Mesos.
The primary clustering and orchestration tools available are
Docker-Swarm, Kubernetes.
Docker Swarm
 We can use Docker Swarm to make Docker work across multiple nodes,
allowing them to share containers with each other. It's an environment where
you can have various Docker images running on the same host operating
system.

 Docker Swarm is an orchestration management tool that runs on Docker

applications. It helps end-users in creating and deploying a cluster of Docker
nodes.

 Each node of a Docker Swarm is a Docker daemon, and all Docker daemons
interact using the Docker API. Each container within the Swarm can be
deployed and accessed by nodes of the same cluster.
How Does Docker Swarm Work?
 In Swarm, containers are launched using services. A service is a group of
containers of the same image that enables the scaling of applications. Before you
can deploy a service in Docker Swarm, you must have at least one node
deployed.

 There are two types of nodes in Docker Swarm:

 Manager node: Maintains cluster management tasks

 Worker node: Receives and executes tasks from the manager node
How Does Docker Swarm Work?
 The manager node knows the status of the worker nodes in a cluster, and the
worker nodes accept tasks sent from the manager node.

 Every worker node has an agent that reports on the state of the node's tasks to
the manager. This way, the manager node can maintain the desired state of the
cluster.

 The worker nodes communicate with the manager node using API over HTTP.
In Docker Swarm, services can be deployed and accessed by any node of the
same cluster.
How Does Docker Swarm Work?
The following diagram represents the Docker Swarm architecture:
 Docker Swarm components
⇒ The following sections explain the various components in Docker Swarm.
 Node

⇒ Node is an instance of the Docker host participating in the Swarm cluster. There
can be one or multiple nodes in a single Swarm cluster deployment.
⇒ Nodes are categorized into Manager and Worker based on their roles in the
system.
 Manager node

⇒ The Swarm manager node manages the nodes in the cluster. It provides the API
to manage the nodes and containers across the cluster.
⇒ Manager nodes distribute units of work, also known as tasks, to worker nodes. If
there are multiple manager nodes, then they select a single leader to perform an
orchestration task.
 Worker node
⇒ The worker node receives and executes task distributed by manager nodes. By
default, every manager node is also a worker node, but they can be configured to run
manager tasks exclusively.
⇒ Worker nodes run agents and keep track of tasks running on them and reports them.
The worker node also notifies the manager node about the current state of assigned
tasks.
 Tasks
⇒ Task is the individual Docker container with a command to run inside the container.
⇒ The manager assigns the tasks to worker nodes. Tasks are the smallest unit of
scheduling in the cluster.
 Services
⇒ Service is the interface for a set of Docker containers or tasks running across the
Swarm cluster.
 Discovery service
⇒ The Discovery service stores cluster states and provides node and service
discoverability. (Service discovery is how applications and (micro)services locate each
other on a network.)
⇒ Swarm supports a pluggable backend architecture that supports etcd, Consul,
Zookeeper, static files, lists of IPs, and so on, as discovery services.
 Scheduler
⇒ The Swarm scheduler schedules the tasks on different nodes in the system.
⇒ Docker Swarm comes with many built-in scheduling strategies that gives users the
ability to guide container placement on nodes in order to maximize or minimize the task
distribution across the cluster.
⇒ The random strategy is also supported by Swarm. It chooses a random node to place
the task on.
Features of Docker Swarm
Some of the most essential features of Docker Swarm are:

 Decentralized access: Swarm makes it very easy for teams to access and
manage the environment
 High security: Any communication between the manager and client nodes
within the Swarm is highly secure
 Autoload balancing: There is autoload balancing within your environment, and
you can script that into how you write out and structure the Swarm environment
 High scalability: Load balancing converts the Swarm environment into a highly
scalable infrastructure
 Roll-back a task: Swarm allows you to roll back environments to previous safe
environments
Swarm Mode Key Concepts
Service and Tasks
 Docker containers are launched using services.
 Services can be deployed in two different ways - global and replicated.
Swarm Mode Key Concepts
 Global services are responsible for monitoring containers that want to run on a
Swarm node.

 In contrast, replicated services specify the number of identical tasks that a

developer requires on the host machine.

 A service is the definition of the tasks to execute on the manager or worker nodes.

 When you create a service, you specify which container image to use and which
commands to execute inside running containers.
Swarm Mode Key Concepts
 In the replicated services model, the swarm manager distributes a specific number
of replica tasks among the nodes based upon the scale you set in the desired state.
 For a replicated service, you specify the number of identical tasks you want to run.
For example, you decide to deploy an HTTP service with three replicas, each
serving the same content.
 For global services, the swarm runs one task for the service on every available node
in the cluster.
 A global service is a service that runs one task on every node. There is no pre-
specified number of tasks. Each time you add a node to the swarm, the orchestrator
creates a task and the scheduler assigns the task to the new node.
 Good candidates for global services are monitoring agents, an anti-virus scanners or
other types of containers that you want to run on every node in the swarm.
 Swarm mode
⇒ In version 1.12, Docker introduced the Swarm mode, built into its engine. To run a
cluster, the user needs to execute two commands on each Docker host:
⇒ To enter Swarm mode:
$ docker swarm init
⇒ To add a node to the cluster:
$ docker swarm join
⇒ Unlike Swarm, Swarm mode comes with service discovery, load balancing, security,
rolling updates and scaling, and so on, built into the Docker engine itself.
⇒ Swarm mode makes the management of the cluster easy since it does not require any
orchestration tools to create and manage the cluster.
 KUBERNETES
⇒ Kubernetes is a container orchestration engine created by Google, designed to
automate the deployment, scaling, and operating of containerized applications.

⇒ It is one of the fastest developing Computer Engineering because it provides a

reliable platform to build distributed applications on a massive scale.

⇒ Kubernetes automates your application, manages its life cycle, and maintains and
tracks resource allocation in a cluster of servers. It can run application containers on
physical or virtual machine clusters.

⇒ It provides a unified API to deploy web applications, databases, and batch jobs.
Features of Kubernetes

It comprises of a rich set of complex features:

→ Auto-scaling

→ Self-healing infrastructure

→ Configuration and updating of batch jobs

→ Service discovery and load balancing

→ Application lifecycle management

→ Quota management
Kubernetes architecture

 Kubernetes consists of the following

components from a top-level view:
→ External requests
→ Master node
→ Worker nodes
 ⇒The diagram shows the architecture of
Kubernetes: 
⇒ Some of the key components are depicted in the diagram.

 External request

⇒ Users interact with Kubernetes cluster through APIs; they explain

what their requirements are and what their application looks like, and
Kubernetes does all the hard work to manage their application.
 Master node
⇒ The master node provides the cluster's control plane. It acts like a controller in
the cluster.
⇒ Most of the major functionalities, such as scheduling, service discovery, load
balancing, responding to cluster events, and so on, are done by components
running on the master node only.
⇒ Now, let's take a look at the master components and their functionalities.
 kube-apiserver

⇒ It exposes the Kubernetes APIs. All of the internal and external requests
go through the API server. It verifies all of the incoming requests for
authenticity and the right level of access, and then forwards the requests to
targeted components in the cluster.
 etcd
⇒ etcd is used for storing all of the cluster state information by Kubernetes. etcd
is a critical component in Kubernetes. Kubernetes uses etcd to store all its data –
its configuration data, its state, and its metadata. Kubernetes is a distributed
system, so it needs a distributed data store like etcd. etcd lets any of the nodes in the
Kubernetes cluster read and write data.
 kube-controller-manager
⇒ There are multiple controllers in the Kubernetes cluster such as the node
controller, replication controller, endpoints controller, service account, and token
controllers. These controllers are run as background threads that handle routine tasks
in the cluster.
 kube-scheduler
⇒ It watches all of the newly created pods (A pod is the smallest execution unit in
Kubernetes.) and schedules them to run on a node if they aren't assigned to any node.
 Worker nodes
⇒ The worker nodes run the user's applications and services. There can be one or
more worker node in the cluster. You can add or remove nodes from the cluster to
achieve scalability in the cluster. Worker nodes also run multiple components to
manage applications.
 kubelet

⇒ It is command-line tool from the Kubernetes project to call Kubernetes APIs

in a simple way.
⇒ kubelet is the primary agent that lives on every worker node. It listens to the
kube apiserver for commands to perform.
⇒ Some of the functionalities of kubelet include mounting the pod's volume,
downloads the pod's secrets, running the pod's containers via Docker or
specified container runtime, and so on.
 kube-proxy

⇒ It enables the service abstraction for Kubernetes by maintaining

network rules on the host and performing connection forwarding.
 Pod

⇒ A pod is the smallest deployable unit of computing in Kubernetes. A pod is the

smallest execution unit in Kubernetes.
⇒ A pod is a group of one or more containers with shared storage or a shared
network, and a specification of how to run the containers.
⇒ Containers themselves are not assigned to hosts, whereas closely related containers
are always co-located and co scheduled together as pods and run in a shared context.
⇒ If a pod (or the node it executes on) fails, Kubernetes can automatically create a
new replica of that pod to continue operations.
⇒ Pods represent the processes running on a cluster. By limiting pods to a single
process, Kubernetes can report on the health of each process running in the cluster.
 Pod

⇒ Pods have:
a unique IP address (which allows them to communicate with each other)
 persistent storage volumes (as required)
 configuration information that determine how a container should run.
⇒ Although most pods contain a single container, many will have a few containers
that work closely together to execute a desired function.
 Concepts in Kubernetes
⇒ In the following sections, we will learn about the concepts of Kubernetes that
are used to represent your cluster.
 Replica sets and replication controllers
⇒ Replica sets are the next generation of replication controllers.
⇒ A Replica Set's purpose is to maintain a stable set of replica Pods running at any
given time. As such, it is often used to guarantee the availability of a specified
number of identical Pods.
⇒ A Replication Controller ensures that a specified number of pod replicas are
running at any one time. In other words, a Replication Controller makes sure that
a pod or a homogeneous set of pods is always up and available.
⇒ A pod is ephemeral and won't be rescheduled if the node it is running on goes
down. The replica set ensures that a specific number of pod instances (or replicas)
are running at any given time.
 Deployments
⇒ Deployment is high-level abstraction which creates replica sets and
pods. Replica sets maintain the desired number of pods in a running
state.
⇒ Deployment provides an easy way to upgrade, rollback, and scale up
or scale down pods by just changing the deployment specification.
 Secrets
⇒ Secrets are used to store sensitive information such as usernames,
passwords, OAuth tokens, certificates, and SSH keys.
⇒ It's safer and more flexible to store such sensitive information in
secrets rather than putting them in pod templates.
⇒ Pods can refer these secrets and use the information inside them.
 Labels and selectors
⇒ Labels are key value pairs that can be attached to objects, such as pods and even
nodes.
⇒ They are used to specify the identifying attributes of objects that are meaningful
and relevant to users. Labels can be attached to objects at creation time and added
or modified later.
⇒ They are used to organize and select subsets of objects. Some examples include
environment (development, testing, production, release), stable, pike, and so on.
⇒ Labels don't provide uniqueness. Using label selectors, a client or user can
identify and subsequently manage a group of objects. This is the core grouping
primitive of Kubernetes and it is used in many situations.
⇒ Kubernetes supports two kinds of selectors: equality-based and set-based.
→ Equality-based uses key value pairs to filter based on basic equality or
inequality, whereas set-based are a bit more powerful and allow for the
filtering of keys according to a set of values.
 Services
⇒ As pods are short-lived objects in Kubernetes, the IP address assigned to them
can't be relied upon to be stable for a long time. This makes the communication
between pods difficult. Hence, Kubernetes has introduced the concept of a
service.
⇒ A service is an abstraction on top of a number of pods and a policy by which to
access them, typically requiring the running of a proxy for other services to
communicate with it via a virtual IP address.
 Volumes
⇒ Volume provides persistent storage to pods or containers. If data is not persisted
on external storage, then once the container crashes, all of its files will be lost.
⇒ Volumes also make data sharing easy between multiple containers inside the pod.
Kubernetes supports many types of volumes, and pods can use any number of
volumes simultaneously.
IMAGES AND CONTAINERS
 A Docker image is a collection of all of the files that make up a
software application.
→ A Docker image is a file used to execute code in a Docker container.
Docker is used to create, run and deploy applications in containers. A
Docker image contains application code, libraries, tools, dependencies and
other files needed to make an application run.
→ When a user runs an image, it can become one or many instances of
a container.
→ Each change that is made to the original image is stored in a separate
layer. To be precise, any Docker image has to originate from a base image
according to the various requirements.
 A Docker container is a runtime instance of an image. From one image you
can create multiple containers (all running the sample application) on
multiple Docker platform.
 A container runs as a discrete process on the host machine. Because the
container runs without the need to boot up a guest operating system it is
lightweight and limits the resources (e.g. memory) which are needed to let it
run.
 A base image is the image that is used to create all of your container
images. Your base image can be an official Docker image, such as Centos, or
you can modify an official Docker image to suit your needs, or you can create
your own base image from scratch.
⇒ Additional modules can be attached to the base image for deriving the
various images that can exhibit the preferred behavior.
→ Each time you commit to a Docker image you are creating a new layer on
the Docker image, but the original image and each pre-existing layer
remains unchanged.
→ In other words, images are typically of the read-only type.
→ If they are empowered through the systematic attachment of newer
modules, then a fresh image will be created with a new name.
→ The Docker images are turning out to be a viable base for developing and
deploying the Docker containers.
A base image has been illustrated here. Debian is the base image,
and a variety of desired capabilities in the form of functional
modules can be incorporated on the base image for arriving at
multiple images:
⇒ Every image has a unique ID, The base images can be enhanced such that
they can create the parent images, which in turn can be used for creating the
child images.
⇒ As per the Docker home page, a Docker image has a read-only template.
⇒ Docker provides a simple way for building new images or of updating the
existing images. You can also download the Docker images that the other
people have already created.
⇒ The Docker images are the building components of the Docker containers.
⇒ In general, the base Docker image represents an operating system, and in the
case of Linux, the base image can be one of its distributions, such as Debian.
⇒ Each commit invariably makes a new image. This makes the number of
images go up steadily, and so managing them becomes a complicated
affair.
→ However, the storage space is not a big challenge because the
new image that is generated is only comprised of the newly added
modules.
 A Docker layer
⇒ Docker layer could represent either read-only images or read-
write images. However, the top layer of a container stack is always
the read-write (writable) layer, which hosts a Docker container.
 Docker Registry
⇒ A Docker Registry is a place where the Docker images can be stored in
order to be publicly found, accessed, and used by the worldwide
developers for quickly crafting fresh and composite applications without
any risks.
→ Using the Docker push command, you can dispatch your Docker
image to the Registry so that it is registered and deposited.
→ As a clarification, the registry is for registering the Docker images,
whereas the repository is for storing those registered Docker images in
a publicly discoverable and centralized place.
→ A Docker image is stored within a Repository in the Docker
Registry. Each Repository is unique for each user or account.
 Docker Repository
⇒ A Docker Repository is a namespace that is used for storing a Docker image.
For instance, if your app is named helloworld and your username or
namespace for the Registry is thedockerbook then, in the Docker
Repository, where this image would be stored in the Docker Registry would be
named thedockerbook/helloworld.
 Working with Docker images
⇒ As an example, we are starting a Docker container. It is standard practice
to start with the basic Hello World! application. In the following example,
we will echo Hello World! by using a busybox image, which we have
already downloaded, as shown here:
$ sudo docker run busybox echo "Hello World!"
 Output : "Hello World!"
In the example, the docker run subcommand has been used for creating a
container and for printing Hello World! by using the echo command.
⇒ Now, let us check the docker pull subcommand by adding the -a
option
$ sudo docker pull -a busybox
⇒ You can easily check the images that are available on the Docker host
by running the docker images subcommand, which comes in handy, and
it reveals more details with respect to :latest and the additional images
that are downloaded by running this command. Let us run this
command:
$ sudo docker images
⇒ You will get the list of images, as follows:
CREATED VIRTUAL SIZE
busybox ubuntu-14.04 f6169d24347d 3
months ago 5.609 MB
busybox ubuntu-12.04 492dad4279ba 3
months ago 5.455 MB
busybox buildroot-2014.02 4986bf8c1536 3
months ago 2.433 MB
busybox latest 4986bf8c1536 3
months ago 2.433 MB
busybox buildroot-2013.08.1 2aed48a4e41d 3
months ago 2.489 MB
⇒ Here is a list of the possible categories:
→ REPOSITORY: This is the name of the repository or image. In the preceding
example, the repository name is busybox.
→ TAG: This is the tag associated with the image, for example buildroot-2014.02,
ubuntu-14.04, latest. One or more tags can be associated with one image.
→ IMAGE ID: Every image is associated with a unique ID. The image ID is
represented by using a 64 Hex digit long random number.
▪ By default, the Docker images subcommand will only show 12 Hex digits.
→ CREATED: Indicates the time when the image was created.
→ VIRTUAL SIZE: Highlights the virtual size of the image.
⇒ In the preceding example, a single pull command with the -a option was
able to download five images, even though we had only specified one
image by the name of busybox.
→ This happened because each Docker image repository can have multiple
variants of the same image and the -a option downloads all the variants that
are associated with that image.
→ In the preceding example, the variants are tagged as buildroot-2013.08.1,
ubuntu-14.04, ubuntu-12.04, buildroot-2014.02 and latest.
⇒ By default, Docker always uses the image that is tagged as latest.
⇒ Each image variant can be directly identified by qualifying it with its tag.
DOCKER
⇒ 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.
→ By taking advantage of Docker’s methodologies for shipping,
testing, and deploying code quickly, you can significantly reduce the
delay between writing code and running it in production.
DOCKER
Docker is a tool used to automate the deployment of an application as a lightweight
container so that the application can work efficiently in different environments.
Docker container is a lightweight software package that consists of the dependencies
(code, frameworks, libraries, etc.) required to run an application.
THE DOCKER PLATFORM
⇒ Docker provides the ability to package and run an application in a loosely
isolated environment called a container.
⇒ The isolation and security allow you to run many containers simultaneously on
a given host.
⇒ Containers are lightweight and contain everything needed to run the
application, so you do not need to rely on what is currently installed on the host.
⇒ You can easily share containers while you work and be sure that everyone you
share with gets the same container that works in the same way.
⇒ Docker provides tooling and a platform to manage the lifecycle of your
containers:
→ Develop your application and its supporting components using
containers.
→ The container becomes the unit for distributing and testing your
application.
→ When you’re ready, deploy your application into your production
environment, as a container or an orchestrated service. This works the
same whether your production environment is a local data center, a
cloud provider, or a hybrid of the two.
WHAT CAN I USE DOCKER FOR?
Fast, consistent delivery of your applications
⇒ Docker streamlines the development lifecycle by allowing developers
to work in standardized environments using local containers which
provide – your applications and services.
→ Containers are great for continuous integration and continuous
delivery (CI/CD) workflows.
⇒ Consider the following example scenario:
→ Your developers write code locally and share their work with their
colleagues using Docker containers.
→ They use Docker to push their applications into a test environment and
execute automated and manual tests.
→ When developers find bugs, they can fix them in the development
environment and redeploy them to the test environment for testing and
validation.
→ When testing is complete, getting the fix to the customer is as simple as
pushing the updated image to the production environment.
Responsive deployment and scaling
⇒ Docker’s container-based platform allows for highly portable
workloads.
→ Docker containers can run on a developer’s local laptop, on
physical or virtual machines in a data center, on cloud providers, or in
a mixture of environments.
⇒ Docker’s portability and lightweight nature also make it easy to
dynamically manage workloads, scaling up or tearing down applications
and services – as business needs dictate, in near real time.
Running more workloads on the same hardware
⇒ Docker is lightweight and fast.
→ It provides a viable, cost-effective alternative to hypervisor-based
virtual machines, so you can use more of your compute capacity to
achieve your business goals.
⇒ Docker is perfect for high density environments and for small and
medium deployments where you need to do more with fewer resources.
 Docker objects
When you use Docker, You are creating and using Objects (images, containers,
networks, volumes, plugins, and other objects).

 The underlying technology

⇒ Docker is written in the Go programming language and takes advantage of several
features of the Linux kernel to deliver its functionality.
⇒ Docker uses a technology called namespaces to provide the isolated workspace
called the container.
→ When you run a container, Docker creates a set of namespaces for that
container.
→ These namespaces provide a layer of isolation.
→ Each aspect of a container runs in a separate namespace and its access is
limited to that namespace.
DOCKER ARCHITECTURE
⇒ Docker uses a client-server architecture.
⇒ The Docker client talks to the Docker daemon, which does the
heavy lifting of building, running, and distributing your Docker
containers.
⇒ The Docker client and daemon can run on the same system, or
you can connect a Docker client to a remote Docker daemon.
→ The Docker client and daemon communicate using a REST
API, over UNIX sockets or a network interface.
→ Another Docker client is Docker Compose, that lets you work
with applications consisting of a set of containers
DOCKER ARCHITECTURE
Docker Environment and Architecture
 There are five critical elements within a doctor Environment/Architecture:
1. Docker container
2. Docker daemon
3. Docker images
4. Docker client
5. Docker registry
 The Docker daemon
The Docker daemon (dockerd) listens for Docker API requests and manages
Docker objects such as images, containers, networks, and volumes. A daemon
can also communicate with other daemons to manage Docker services. The
docker daemon is the process that manages containers.
 Docker images
 An image is a read-only template with instructions for creating a Docker
container.
 The default docker images will show all top level images, their repository and
tags, and their size. Docker images have intermediate layers that increase
reusability, decrease disk usage, and speed up docker build by allowing each
step to be cached. These intermediate layers are not shown by default.
 The Docker container

A container is a runnable instance of an image.

You can create, start, stop, move, or delete a container using the Docker API or CLI.
You can connect a container to one or more networks, attach storage to it, or even
create a new image based on its current state.

By default, a container is relatively well isolated from other containers and its host
machine. You can control how isolated a container’s network, storage, or other
underlying subsystems are from other containers or from the host machine.
A container is defined by its image as well as any configuration options you
provide to it when you create or start it.
→ When a container is removed, any changes to its state that are not
stored in persistent storage will disappear.
A container is simply another process on your machine that has been isolated
from all other processes on the host machine. That isolation leverages kernel
namespaces and cgroups.
→ These features have been in Linux for a long time.
→ Docker has worked to make these capabilities approachable and easy to
use.
 The Docker client

The Docker client (docker) 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 dockerd, which carries them out. The docker command uses the Docker API. The
Docker client can communicate with more than one daemon.
 Docker registries

A Docker registry stores Docker images. Docker Hub is a public registry that
anyone can use, and Docker is configured to look for images on Docker Hub by
default. You can even run your own private registry.

 When you use the docker pull or docker run commands, the required images are
pulled from your configured registry. When you use the docker push command, your
image is pushed to your configured registry.
Example: docker run command

⇒ The following command runs an ubuntu container, attaches

interactively to your local command-line session, and runs /bin/bash
docker run –d –p 80:80 docker/getting-started
⇒ When you run this command, the following happens (assuming you
are using the default registry configuration):
1. If you do not have the ubuntu image locally, Docker pulls it from your configured
registry, as though you had run docker pull ubuntu manually.
2. Docker creates a new container, as though you had run a docker container create
command manually.
3. Docker allocates a read-write filesystem to the container, as its final layer. This
allows a running container to create or modify files and directories in its local
filesystem.
4. Docker creates a network interface to connect the container to the default network,
since you did not specify any networking options. This includes assigning an IP
address to the container. By default, containers can connect to external networks
using the host machine’s network connection.
5. Docker starts the container and executes /bin/bash. Because the container is
running interactively and attached to your terminal (due to the -i and -t
flags), you can provide input using your keyboard while the output is logged
to your terminal.
6. When you type exit to terminate the /bin/bash command, the container stops
but is not removed. You can start it again or remove it.
CONTAINER VIRTUAL NETWORKING
 A Docker container needs a host to run on. This can either be a physical machine or a
VM either On-premises or in the Cloud.
 The host has the Docker daemon and client running, as depicted in Figure which
enables you to interact with a Docker registry on the one hand (to pull/push Docker
images), and on the other hand, allows you to start, stop, and inspect containers.
 The relationship between a host and containers is 1:N. This means that one host
typically has several containers running on it.
 For example, Facebook reports that—depending on how beefy the machine is—it sees on
average some 10 to 40 containers per host running. And here’s another data point: at
Mesosphere, we found in various load tests on bare metal that not more than around 250
containers per host would be possible.
 No matter if you have a single-host deployment or use a cluster of machines,
you will almost always have to deal with networking:
 For most single-host deployments, the question boils down to data exchange
via a shared volume versus data exchange through networking (HTTP-based
or otherwise).
▪Although a Docker data volume is simple to use, it also introduces tight
coupling, meaning that it will be harder to turn a single-host deployment
into a multi-host deployment.
▪ Naturally, the upside of shared volumes is speed.
→ In multi-host deployments, you need to consider two aspects: how are
containers communicating within a host and how does the communication
paths look between different hosts.
▪ Both performance considerations and security aspects will likely influence
your design decisions.
▪ Multi-host deployments usually become necessary either when the capacity
of a single host is insufficient or when one wants to employ distributed
systems such as Apache Spark, HDFS, or Cassandra.
 Isolated inside the container from the host and all other containers are a full-
featured Linux environment with its own users, file system, processes, and network
stack. All applications inside the container are permitted to access or modify files or
resources available inside the container only.

 It is possible to run multiple containers at the same time, each with their own
installations and dependencies. Unlike virtual machines, containers share host
resources rather than fully simulating all hardware on the computer, making
containers smaller and faster than virtual machines and reducing overhead.
 A container network is a form of virtualization similar to virtual machines (VM) in
concept but with distinguishing differences. Primarily, the container method is a
form of operating system virtualization as compared to VMs, which are a form of
hardware virtualization.

 containers are a “running instance” of an image, ephemeral operating system

virtualization that spins up to perform some tasks then is deleted and forgotten.
Because of the ephemeral nature of containers, system users run many more
instances of containers than compared to virtual machines requiring a larger address
space.
⇒ Docker networking is the native container SDN (Software Defined
Networks) solution you have at your disposal when working with
Docker.
⇒ In a nutshell, there are four modes available for Docker networking:
bridge mode, host mode, container mode, or no networking.
Bridge Mode Networking
 In this mode the Docker daemon creates docker0, a virtual Ethernet
bridge that automatically forwards packets between any other network
interfaces that are attached to it.
 By default, the daemon then connects all containers on a host to this
internal network through creating a pair of peer interfaces, assigning
one of the peers to become the container’s eth0 interface and other peer
in the namespace of the host, as well as assigning an IP address/subnet
from the private IP range to the bridge.
Bridge Mode Networking
Bridge Mode Networking
Host Mode Networking
 This mode effectively disables network isolation of a Docker container.
 Because the container shares the networking namespace of the host, it is
directly exposed to the public network;
 The container has the same IP address as the host, namely 10.0.7.197.
 When using host mode networking, the container effectively inherits the
IP address from its host. This mode is faster than the bridge mode
(because there is no routing overhead), but it exposes the container
directly to the public network, with all its security implications.
Host Mode Networking
Host Mode Networking
Container Mode Networking

 In this mode, you tell Docker to reuse the networking namespace of

another container. In general, this mode is useful when you want to
provide custom network stacks. Indeed, this mode is also what
Kubernetes networking leverages.
Container Mode Networking
 The result is what we would have expected: the second container,
started with --net=container, has the same IP address as the first
container with the glorious auto-assigned name admiring_engelbart,
namely 172.17.0.3.
No Networking
 This mode puts the container inside of its own network stack but
doesn’t configure it. Effectively, this turns off networking and is useful
for two cases: either for containers that don’t need a network (such as
batch jobs writing to a disk volume) or if you want to set up your
custom networking.