DEV Community: Yash Hegde

🚀Navigating the Microservices Universe with Layer5: A Beginner's Guide

Yash Hegde — Fri, 20 Jan 2023 07:06:21 +0000

Microservices architecture has become the norm for building and operating modern applications. However, managing communication between these small, independent services can be daunting. This is where a service mesh like Layer5 comes in - it provides a configurable infrastructure layer that sits between the application code and the underlying network infrastructure. In this beginner's guide, we'll explore how Layer5 can help navigate the microservices universe and make communication between services more flexible, reliable, and fast.

What is a Service Mesh?

A service mesh is an infrastructure layer that sits between the application code and the underlying network infrastructure. It helps manage communication between microservices in a distributed system and provides features such as traffic management, service discovery, load balancing, and security. These features are crucial for building and operating microservices-based applications and can make communication between services more flexible, reliable, and fast.

How does it work?

A service mesh works by inserting a proxy, called a sidecar proxy, into each service instance. These sidecar proxies handle all the communication between service instances and the service mesh control plane. The control plane is responsible for configuring the behavior of the sidecar proxies and provides features such as traffic management, service discovery, load balancing, and security.

🚦 "Traffic Management in a Microservices World with Layer5"

One of the key features of a service mesh like Layer5 is traffic management. It allows for precise control over how traffic flows between different service instances. This can be used for things like canary releases, A/B testing, and blue-green deployments. With Layer5, it is possible to route traffic to different versions of a service, or to different instances based on various criteria such as user identity or geographic location.

🔍 "Discovering the Power of Service Discovery with Layer5"

Service discovery is another important feature of a service mesh like Layer5. In a microservices-based application, new instances of a service can come and go dynamically. Layer5 can automatically discover these new instances and update the routing information accordingly. This allows for automatic scaling of services and failover in the case of an instance failure.

🔒 "Securing Microservices Communication with Layer5"

Security is also a crucial aspect of a service mesh like Layer5. It provides features such as mutual TLS and role-based access control to secure communication between service instances and control access to services based on the identity of the caller.

💻 "Getting Started with Layer5"

To use Layer5, you'll need to deploy the Layer5 control plane in your cluster and configure the sidecar proxies to communicate with it.

Deploy the Layer5 control plane: You can deploy the Layer5 control plane using Kubernetes manifests or Helm charts.
Configure the sidecar proxies: Once the control plane is deployed, you'll need to configure the sidecar proxies in your services to communicate with them. This can typically be done by adding a few lines of configuration to your service's code.
Configure traffic management: You can use Layer5's traffic management features to control how traffic flows between different service instances. This can be done using the Layer5 control plane's APIs or the Layer5 CLI.
Configure service discovery: Layer5 can automatically discover new instances of a service and update the routing information accordingly. You can configure this feature using the Layer5 control plane's APIs or the Layer5 CLI.
Configure security: Layer5 provides features such as mutual TLS and role-based access control to secure communication between service instances and control access to services based on the identity of the caller. You can configure these features using the Layer5 control plane's APIs or the Layer5 CLI.

In conclusion, a service mesh like Layer5 is a powerful tool for managing communication between microservices in a distributed system. With its traffic management, service discovery, load balancing, and security features, it makes communication between services more flexible, reliable, and fast. By following this tutorial, you would now have got a brief overview of how to use Layer5 to manage communication between your microservices.

Outro:

There’s no better way to test-drive Layer5 than by diving in and playing with it. The purpose of the blog is to create awareness about a service mesh like Layer5. To learn further it is recommended to go through the official documentations of Layer5.

Have fun!
Feel free to connect with me on
LinkedIn
Twitter
Github

Continuous deployment: The ArgoCD way

Yash Hegde — Tue, 18 Oct 2022 07:28:58 +0000

If you have used GitHub for creating a pull-request, you might have come across this:

Have you ever wondered what these “checks” actually mean? And how the project actually implements these tests? Whether you know or don’t know the answer to this question, delve into this article and get a glimpse of ArgoCD’s world :)

So, what is ArgoCD?

As the name suggests, ArgoCD is a continuous delivery tool. And to understand how it works, let’s first look into how continuous delivery is implemented in most projects using common tools like Jenkins, Gitlab, etc (since Jenkins and Gitlab are also CD tools, one question would arise in your mind,” is ArgoCD a replacement of these established CD tools?”. So, let’s try to answer this question as well).

An example of a continuous deployment workflow without ArgoCD:

Let’s say we have a microservices application running in a Kubernetes cluster. Now, when you make some changes to your application, like adding a new feature or some bug fix, the CI tool like Jenkins will carry out the tests, and when tests are passed, Docker will create a new image and push it to the Docker depository.

But how does this new image get deployed to the Kubernetes cluster?
This is done by updating the application’s deployment YAML file with the new image tag(this will be done using Jenkins), and then it should be applied to Kubernetes using tools like Kubectl.

Following is an example:

However, there are some challenges to this approach:

You need to set up tools like Kubectl, and Helm to access the Kubernetes cluster and execute changes on the build automation tools like Jenkins, which in turn means you need to configure these tools on Jenkins.
You need to configure access to Kubernetes for these tools(when using cloud platforms like AWS, some more configuration will be required). Apart from being a tiring configuration process, this also becomes a security challenge as you have to share your cluster credentials with external services and tools.
Once Jenkins has changed the config file for applying the changes to the cluster, it bears no responsibility for checking whether your changes were deployed successfully or not in the cluster. This can only be found by only following test steps.

2018: ArgoCD arrives

ArgoCD was created for improving the CD part of your application building and deployment process. It was purpose-made for Kubernetes and is based on Gitops principles.

So how does ArgoCD make the process more efficient?
ArgoCD does this by using the pull workflow. It is a part of the k8s cluster, and instead of pushing the manifest changes, it pulls the changes and applies them to the cluster.

Thus, the workflow can be listed as follows:

1)deploy ArgoCD in k8s cluster
2)configure ArgoCD to track the git repository
3)ArgoCD monitors for any changes and applies them automatically
So, when a developer applies some changes to the application source code, the CI pipeline tool like Jenkins will first test the changes, build the image, push the image to the docker repository and finally update the k8s manifest file.

_A POINT TO BE NOTED: _

It is considered best practice to separate the git repository for application source code and configuration code ie k8s manifest files. The benefit of doing this is that the application configuration file can not only be the deployment file but also configmap, secret, ingress, etc, and everything else the application needs to run in the cluster. And these manifest files can change completely independent of the application’s source code. And when you update, say, a service YAML file for the application, which is just the application configuration and not a part of the code, you don’t want to run the whole CI pipeline for the application when the app source code hasn’t even changed. Also, you don’t want to have complex logic in the pipeline to decide what actually changed.

So now, Jenkins will update the manifest file in a separate git repo where the k8s manifest files exist. And as soon as the configuration files for the repo change, ArgoCD will start tracking changes as we had initially configured it to monitor changes in the cluster, and it will pull and apply the changes in the cluster automatically.

ArgoCD supports k8s YAML files, helm charts, Kustomize files, and all other template files that generate k8s manifests. The repo which is tracked by ArgoCD is sometimes also known as the Gitops repository.

Thus, when the configuration files get changed by either Jenkins or by DevOps engineers, all of these changes will be tracked and applied in the cluster by ArgoCD. As a result, we have separate CI and CD, where the CI is completely owned by developers and configured on Jenkins for example, and the CD pipeline is owned by operations/ DevOps teams and configured using ArgoCD.

Benefits of using ArgoCD (answering the question, “Why ArgoCD?”)

a) Git as a single source of truth:

Since the whole k8s configuration is defined as code in the git repo, the config files don’t have to be manually applied from local laptops using helm or kubectl, as everyone will have the same interface for updating the cluster.

What happens if someone updates the cluster manually?

One point to be noted here is that ArgoCD tracks the changes in the config file repo, as well as in the whole cluster. It continuously tracks and compares the actual state of the cluster with the desired state. So, when someone manually does some changes, the actual state will be different from that defined in the configuration file, and thus ArgoCD will sync the changes, overwriting the manual change. Thus, this guarantees that the k8s manifests in git remain the single source of truth.

But let’s say we do need a way to quickly manually update the cluster. In that case, we can configure ArgoCD to not sync manual cluster changes automatically, and send an alert in such a case.

Also, the benefit of using git is that we can track all the changes made, as opposed to untraceable changes made directly to the cluster by using kubectl or helm, etc. This also provides better team collaboration.
b) easy rollback:
since git tracks all the changes, so we can easily revert back to a previous commit if the new git commit causes a failure in the application. This is especially useful when we have thousands of clusters that point to the same git repository. Thus, we don’t have to manually update all the clusters
but just changing the configuration file will do the work for us.

c) Cluster disaster recovery:
Let’s say we have a cluster in a region A. and for some reason, the cluster completely crashes. So, using the configuration file, we can create a new cluster easily, thus recreating the exact state as the previous one.

d) k8s access control with git and ArgoCD:
Since all team members should not have access to make changes to the config repo, especially in a production environment, we configure access rules in the git repositories.

Thus, using permissions, all team members can propose changes to the cluster, but only a handful of senior engineers can approve and merge those requests. In this way, we can manage cluster access indirectly via git, without having to create ClusterRole and user resources in Kubernetes.

Also, we need to only give access to the git repo and not the whole cluster. We also don’t need to give external cluster access to non-human users like Jenkins etc as we have ArgoCD inside the cluster which will apply those changes. Thus, no cluster credentials outside of K8s, resulting in better management of the security of our cluster.
e) ArgoCD as k8s extension:

ArgoCD uses existing k8s functionalities:
eg1) using etcd to store data
eg2)using k8s controllers for monitoring and comparing actual and desired states.

The major benefit is that we get visibility in the cluster as we can get real-time updates of the application state.

Now that we have learned about ArgoCD, let’s try to learn how we configure it in our project:

For doing this, we have to follow the following steps:
1)deploy ArgoCD into the k8s cluster
2)configure ArgoCD with k8s native YAML file:

The main component of ArgoCD is “application”, and we can define this application CRD (custom resource definition) in a k8s native YAML file.

While defining, we have to mention which git repository is to be synced with which k8s cluster.

How do we work with Multiple clusters using ArgoCD?

Since the same ArgoCD instance is able to sync a fleet of k8s clusters, we need to configure and manage ArgoCD only once.

Finally, is ArgoCD a replacement for other ci/cd tools?

Not really as we still need a CI pipeline to test and build app code changes. ArgoCD, as the name suggests is for the CD pipeline, along with its other functionalities.

But there are many alternatives for ArgoCD as well like fluxCD, Jenkinsx etc, to name a few. Each has its own functionality, which can be discussed in some other article :)

Outro:

There’s no better way to test-driveArgoCD than by diving in and playing with it. The purpose of the blog is to create awareness about CD pipeline tools like ArgoCD. To learn further it is recommended to go through ArgoCD’s Github and blogs

Have fun!

Feel free to connect with me on LinkedIn,Twitter
And GitHub

YAML: A short and crisp tutorial

Yash Hegde — Sat, 20 Aug 2022 19:15:35 +0000

Before going into the details of YAML, what do you think YAML could be? One of the guesses by some of my friends was “You Ate My Lunch”. Jokes apart, let’s get started with the article.

Previously, YAML’s full form was “Yet Another Markup Language”. But now, it is “YAML Ain’t Markup Language”. By the way, what is a Markup language?
One of the common examples of a markup language is HTML. But why is it a markup language?

A markup language provides a structure to the page. Like, in HTML, you can give a definite structure to the page by providing, say, a header, under that header you can provide lists, and under the lists, you provide paragraphs and so on.

One question you would have in your mind is, “why YAML ain’t a markup language?”. First of all, YAML isn’t a programming language. It is a data format, used to exchange data, similar to XML and JSON data types. So, it is used to store information related to some configurations. Or simply put, you can’t write commands using YAML, you can only store data (this storing of data in files is known as data serialization).

Ok, so what are Data serialization and Deserialization?

Let’s take a hypothetical scenario:

Let’s say, the police department of Mumbai has a list of all the most wanted criminals in Mumbai. One of the criminals is say, Abdul. The news comes out that Abdul has escaped Mumbai. The cops suspect that he might have run to Delhi, and thus they want to provide all details related to Abdul to the Delhi Police. Let’s take that our police use web apps and machine learning models to transfer data to each other, predict a crime’s outcomes, or guess where the criminal might have gone.

So, the problem at hand is, that data from the Mumbai police needs to be sent to a web app and further it needs to be sent to a machine learning model for carrying out the mission. So how is this data transfer done? Say, you have a file containing the data, how will you convert the file into a web app readable file and a machine learning model readable file? This process of file conversion is known as data serialization.

So, the process of converting data objects in complex data structures into streams of data to provide it to some devices is known as data serialization. The opposite of this is known as data deserialization.

The files that store this object is known as data serialization file, and the language used is known as data serialization language. Examples of data serialization languages include YAML, JSON, and XML. This file can now be shared anywhere easily, with no conversion at every step required.

An example-the Kubernetes way:

Imagine you have made an app and you want to deploy it on ten servers. For that, you have to provide data to Kubernetes about your file so that it can create pods in the servers according to your data. This data is given to Kubernetes by creating what is known as Kubernetes configuration files. These files are written in YAML.

What are the benefits of YAML?

Some of the benefits include:

Simple and easy to read
Has a strict syntax, indentation is important
Easily convertible to JSON, YAML, etc
Most languages use YAML
More powerful when representing complex data.
Various tools like parsers can be used using YAML

Background done, now let’s get started with some YAML coding:

Some things to keep in mind:

-Extension for YAML files: .yaml or .yml.
-Note: YAML is case-sensitive. So “small” and “Small” are two different things.
-strictly following spaces and block style is important.

to separate different types of documents (like lists, key-value pairs, etc), put “---” at the end of each document. -for ending a document, put “…” at the end of the document.

As mentioned earlier, JSON, XML, and YAML are quite similar in function. And you might have to convert code from JSON/XML to YAML and vice versa or any combination of the three. Here’s a cool which might come in handy to you for code conversion: Online YAML Tool .

A sample code:

# storing key value pairs(these are called maps):
"apple" : "red fruit"
2: "my roll number"
---
# lists 
- apple
- mango
- banana
- Apple
---
cities :
- wekm
- wekdw
- wedo
... #for ending the doc

#for storing lists in a single line:
cities: [wefwf,efe,efqeq2]
---

#for key value pairs in a single line:

{apple : "red fruit" , roll number : 58} 
---

Datatypes in YAML- The basics:

-everything after “:” is known as variable

name: Yash #here Yash is a variable

Variables can be of many types like string, integer, etc :

String:

#string variables:
name: Yash #here Yash is a variable
address: "avgfwge"
gender: 'male'

Note1: strings can be represented using no quotes/single quotes (‘ ‘ )/double quotes (“ ”)

Note2: say want to write multiple paragraphs/multiple lines of string. For that, you need to use “|” to preserve the format of your paragraph.

Example:

para: |
 the output
 will be in
 multiple lines.

Note3: if your input is in multiple lines and you want to store it in a single line in the key, use “> “

Example:

input: >
 this will
 be in
 a single line.

Integer:

#Integer data type:
number: 5461

Float:

#Float data type:
percentage: 96.4

Boolean:

#Boolean:
booleanValue: No # or you can also write n/N/false/False/FALSE
#or
BooleanValue: Yes # or you can also write y/Y/true/True/TRUE

### Specifying the datatypes:

Format:
key: !!datatype value

Example:

#specifying the data type
number: !!int 1
hexa: !!int 0x45
floatingnumber: !!float 5464.168
infinity: !!float .inf
not a number: .nan
string: !!str this is a string
something: !!null Null #or null NULL ~
~: when your key is null
date: !!timestamp 2022-08-20
date with time: 2022-08-20T17:13:43.10 +5:30 # 17:13:43.10 is the UTC time by default, hence add 5:30 for IST
if no time zone: 2022-08-20T17:13:43.10
exponential number: 54851.648E161

Now that we have learned the basic datatypes, let’s level up and learn some advanced ones:

#sequence data type:
cities: [wefwf,efe,efqeq2] #can also be written as:
---
Cities: !!seq
 - efwef
 - wefwe
---
#sparse sequence: when some variable of the sequence is empty
 sparse sequence:
  -wfwf
  -wefwef
  -wefweefw
  - 
  -wefwewefwef   
---
#nested sequence:

- 
 -one
 -two
 -three
-
 -somthing
 -somthingmore
 -somethingonemore
---
#for maps, use !!map

#nested maps:
name: Yash
role:
 age: 58
 job: student

#this can also be represented as:
Name: Yash
Role: { age: 58, job: student}

#note: in the older version of Yakey-value pairs could have multiple values, but it’s not allowed:
#pairs example: !!pairs
# -nickname: Rahul
# -nickname: Raj
#the opposite of this is set datatype

#Dictionary datatype:
people: !!omap 
 - Sahil:
     name: Sahil P
     age: 54
     height: 468
 - Supra: 
     name: Supra P
     age: 57
     height: 548
#Anchor tags: used for avoiding repetition . example:
roles: &role
 role1: student
 role2: software engineer

 #say 3 people have the same roles as above. so instead of writing the same code again 3 times, we can use " <<: *role "" :

person1:
 name: yash 
 <<: *role

person2:
 name: supra
 <<: *role

person3:
 name: sahil 
 <<: *role

#say sahil has changed his role from software engineer to electronics engineer. we need to update that in code. for that we can do :

#person3:
# name: sahil
# <<: *role
# role2: electronics engineer
#writing role2 below <<: *role will override the data for role2

Some handy tools to install:
(Suggestion: Watch tutorials on Youtube on how to use this tools effectively. For setup and installation, follow the blogs attached below)

Datree

Monokle

Lens

Do check out Tutorialspoint for more info on YAML.

Outro:

There’s no better way to test-drive YAML than by diving in and playing with it. The purpose of the blog is to create awareness about YAML. To learn further it is recommended to go through YAML's blog and GitHub.
Have fun!
Feel free to connect with me on
LinkedIn
Twitter
GitHub

I would recommend you to go through this article as well for gaining more perspectives on this topic!

All code can be found on : YAML Code
Enjoy!

Understanding Containers: Docker

Yash Hegde — Mon, 01 Aug 2022 06:50:00 +0000

Many companies are running their applications and stuff. But where are these apps run? The answer is servers. Some companies have their servers while some borrow from big providers (like cloud providers).

Initially, only one application could be run on one server. As one might guess, there were some problems with this approach. Firstly, this increased the load on a single server since the load increased as the number of people using that app increased. Secondly, only one app could be run, thus, to run multiple apps, companies had to add multiple servers, thus significantly increasing the costs.

Enter Virtual Machines

Virtual machines solved this problem. The concept of the virtual machine was invented by IBM as a method of time-sharing extremely expensive mainframe hardware. In simple terms, virtual machines help us to run multiple apps on the same server. But the problem with virtual machines is that they require their own operating systems, and operating systems require RAM, CPU, etc. So, say we want to run a virtual machine on our computer. For doing this, we will have to dual boot our computer, that is, install another operating system (e.g., ubuntu) on another part of our hard disk. Other flaws include reduced speed, need for dedicated storage, need for dedicated CPU and RAM allocation, and installation of dependencies management for each virtual machine. Thus, virtual machines are better than one-app-one-server, but still not perfect.

Could containers be a better solution?

Won’t it be great if we could run multiple instances of applications on the same operating system? That’s where containers come into the picture. Docker (by Docker Inc.) made containers popular with Linux containers. Before docker, big companies like Google were already using containers in a way. Not just that, there were many other initiatives like containers as well, but just weren’t popular (In 2015, an organization named Open Container Initiative (OCI) was put in place for the express purpose of creating open industry standards around container formats and runtimes).

So, what are containers?

Containers are just like virtual machines but don’t require multiple operating systems.

The analogy for understanding containers is:

Say you have built a website. Now you want feedback, hence you share the website files with your friend. You must have encountered this situation where your friend is not able to run the website due to version incompatibility or similar reasons. Thus, to avoid this situation, you do this:

Thus, you will have to share all the files (for example, including dependencies) with your friend for him to be able to run the website on his system.

This is what is called a container. Now your friend can run your website on his system without any errors!

Virtual Machine vs Containers: Extended

In the above image for Virtual machine vs container, you can see a term called a hypervisor. The hypervisor is used to create multiple machines on a host operating system and it manages virtual machines. These virtual machines have their operating system and every operating system will be dedicated some amount of hardware, resources, and CPU. On the other hand, you have only one operating system in containers, along with a container engine (container engine consists of the parts covered in the Docker architecture section). Thus, you run multiple apps on the same operating system using the container engine. The container helps the apps to run in an isolated environment (that is, an app running in a container will not know what is happening outside that container). This in turn also ensures security. Docker (by Docker, Inc) is a container tool that helps us to create, manage & scale containers.

Next, how do you get docker on your system?

Just follow the steps below:

go to https://docs.docker.com/ -downloads and install section -select docker desktop for mac/ windows/Linux according to your operating system. easy-peasy!

Installation is done, but what setup is required to run docker on your system?

A container runs on your host operating system (that is host kernel). Thus, when a windows app is containerized, it will not run on a Linux-based kernel and vice versa. A windows-based container will require a windows kernel, similarly for Linux based container. Docker desktop can be run in two modes: 1) run on windows containers and 2) run on Linux containers.

For the Windows system, you need to install the docker desktop and windows subsystem for Linux (WSL).

For the Mac system, just installing the Docker desktop will work.

Wait, wait, wait! First, understand what Docker is in technical terms: Docker Architecture

Docker consists of three parts:
a) Docker runtime b) Docker engine c) Orchestration
Its architecture is as follows:

Let’s have a look at these terms individually:

a) docker runtime:
It helps us to start and stop a container. It is of two types:
i)low-level-runtime, known as runC:
It works with the operating system and helps to start and stop the containers
ii)high-level-runtime, known as containerd:
-it is a CNCF project
-manages runc and containers
-connecting to the internet and pulling the images into containers:
Pulling the images means bringing data from the internet to the containers. Thus, containerd helps in making the interaction between containers and the internet.

b) docker engine:
Used to interact with the docker. Docker daemon is used.
Daemon works with the docker runtime and executes the commands.

Explanation of diagram:

Example:
Docker CLI is used to write docker commands

On CLI:
Docker run ubuntu

The CLI passes this message to the docker daemon via the RestAPI. The daemon interacts with the docker runtime and instructs it to run ubuntu in the container.

c) Orchestration:
Examples:
Let’s say there are 100 containers for an application. All containers contain version 1 of the application. And now, a new version of the application is made. Thus, to update the containers, we can either update containers manually or update them all at once. Updating all at once is one of the functions of orchestration engines. Examples include docker swarm, and Kubernetes.

How will you share your files with your friend using containers?

A Docker file is what you need.

A Docker file is a set of instructions. It contains the required operating system files and the dependencies required to run the application.

When we run the docker file, we get a Docker image. When the image is run, we get the container. When we have an app that we want to containerize, we first have to write a docker file. This file will be converted to an image that can be shared with other systems. Images are immutable. Once built, the files making up an image do not change. Images can be stored locally or in remote locations like https://hub.docker.com/. A single image can be used to create multiple containers. Images are built in layers. Each layer is an immutable file but is a collection of files and directories. The last layer can be used to write out data. Each layer has an ID, calculated via an SHA 256 hash of the layer contents. Thus, if the layer contents change, the SHA 256 hash changes as well. Note: The Image ID listed by docker commands (that is ‘docker images’) is the first 12 characters of the hash. These hash values are referred to by ‘tag’ names.

Some hands-on examples of Docker commands:

a)Listing hash values of docker images:

$ docker images -q --no-trunc
sha256:3556258649b2ef23a41812be17377d32f568ed9f45150a26466d2ea26d926c32
sha256:9f38484d220fa527b1fb19747638497179500a1bed8bf0498eb788229229e6e1
sha256:fce289e99eb9bca977dae136fbe2a82b6b7d4c372474c9235adc1741675f587e

Note the first 12 characters of the hash values given above.

$ docker images
REPOSITORY   TAG     IMAGE ID        
ubuntu       18.04   3556258649b2   
centos       latest  9f38484d220f    
hello-world  latest  fce289e99eb9

Now notice the IMAGE ID above. The first 12 characters of the hash values are equal to the IMAGE ID.
A point to note:
Two containers may share the same images. Thus, when we try to run the new container, CLI will show that it is pulling images from the container which already had that image. This in turn makes the process fast by not downloading the same files again. Common images are identified by the image ID.

b)Pulling an image from the Docker registry:

$ docker images
REPOSITORY      TAG      IMAGE ID     CREATED      SIZE
$ docker pull ubuntu:18.04
18.04: Pulling from library/ubuntu
7413c47ba209: Pull complete
0fe7e7cbb2e8: Pull complete
1d425c982345: Pull complete
344da5c95cec: Pull complete
Digest:sha256:c303f19cfe9ee92badbbbd7567bc1ca47789f79303ddcef56f77687d4744cd7a
Status: Downloaded newer image for ubuntu:18.04
$ docker images
REPOSITORY     TAG        IMAGE ID          CREATED         SIZE
ubuntu         18.04      3556258649b2      9 days ago      64.2MB

c)Running image to create a container:

$ docker run -it ubuntu:18.04
root@4183618bcf17:/# ls
bin boot dev etc home lib lib64 media mnt opt proc root run sbin srv sys tmp usr var
root@4183618bcf17:/# exit
exit

d)creating your own docker image:
Create a file named ‘Dockerfile’
By default on building, docker searches for ‘Dockerfile’ $ docker build -t myimage:1.0 .
During the building of the image, the commands in the RUN section of Dockerfile will get executed. $ docker run ImageID
The commands in the CMD section of Dockerfile will get executed when you create a container out of the image.

Dockerfile example:

Dockerfile example:
FROM ubuntu
MAINTAINER Yash <yash@gmail.com>
RUN apt-get update
CMD [“echo”, “Hello World”]

e) some basic image-related commands:

$ docker pull ubuntu:18.04 (18.04 is tag/version)
$ docker images (Lists Docker Images)
$ docker run image (creates a container out of an image)
$ docker rmi image (deletes a Docker Image if no container is using it)
$ docker rmi $(docker images -q) (deletes all Docker images)

f) listing containers:

$ docker ps -a
CONTAINER ID   IMAGE          COMMAND       CREATED         STATUS
4183618bcf17   ubuntu:18.04   “/bin/bash”   4 minutes ago   Exited

A simplified explanation of Docker’s working:

Let’s say, you type
~ docker run hello-world
On your CLI (command line interface):
This means that you want to run the image hello world in your containers.

What happens inside is this message will be passed to the docker daemon via the restAPIs. Docker daemon will now check whether your system has an image of hello world in it. If it does not, it will download the hello-world image from the docker registry. The Docker registry is where Docker images are stored. Docker Hub is a public registry that anyone can use. When you pull an image, Docker by default looks for it in the public registry and saves the image on your local system on DOCKER_HOST. You can also store images on your local machine or push them to the public registry.

If your system has those images, it will directly run them.

Docker hub

Fun fact: You can now run Mongo DB/ MySQL etc without even installing it on your computer.

Just run the container!

Outro:

There’s no better way to test-drive Docker than by diving in and playing with it. The purpose of the blog is to create awareness about containers. To learn further it is recommended to go through Docker’s Github and blogs.

Have fun!
Feel free to connect with me on LinkedIn