Docker

Docker brief introduction:

Docker is a container management service. The keywords of docker are develop, ship and run anywhere. The whole idea of docker is for developers to easily develop applications, ship them into containers which can then be deployed anywhere.

Features of docker

1. Docker has the ability to reduce the size of development by providing a smaller footprint of the operating system via containers.

2. With containers, it becomes easier for teams across different units, such as development, qa and operations to work seamlessly across applications.

3. You can deploy docker containers anywhere, on any physical and virtual machines and even on the cloud.

4. Since docker containers are pretty lightweight, they are very easily scalable.

Docker terminology

Image:

a package with all the dependencies and information needed to create a container. An image includes all the dependencies (such as frameworks) plus deployment and execution configuration to be used by a container runtime. Usually, an image derives from multiple base images that are layers stacked on top of each other to form the containers filesystem. An image is immutable once it has been created.

Container:

an instance of a docker image. A container represents the execution of a single application, process, or service. It consists of the contents of a docker image, an execution environment, and a standard set of instructions. When scaling a service, you create multiple instances of a container from the same image. Or a batch job can create multiple containers from the same image, passing different parameters to each instance.

Tag:

a mark or label you can apply to images so that different images or versions of the same image (depending on the version number or the target environment) can be identified.

Repository (repo):

a collection of related docker images, labeled with a tag that indicates the image version. Some repos contain multiple variants of a specific image, such as an image containing sdks (heavier), an image containing only runtimes (lighter), etc. Those variants can be marked with tags. A single repo can contain platform variants, such as a linux image and a windows image.

Registry:

a service that provides access to repositories. The default registry for most public images is docker hub (owned by docker as an organization). A registry usually contains repositories from multiple teams. Companies often have private registries to store and manage images theyve created. Azure container registry is another example.

Docker hub:

a public registry to upload images and work with them. Docker hub provides docker image hosting, public or private registries, build triggers and web hooks, and integration with github and bitbucket.

Cluster:

a collection of docker hosts exposed as if it were a single virtual docker host, so that the application can scale to multiple instances of the services spread across multiple hosts within the cluster. Docker clusters can be created with docker swarm, mesosphere dc/os, kubernetes, and azure service fabric. (if you use docker swarm for managing a cluster, you typically refer to the cluster as a swarm instead of a cluster. )

dockerfile:

a text file that contains instructions for how to build a docker image.

Docker containers vs. Virtual machines

docker container can be created/destroyed very quickly as compare to the virtual machines.

Docker containers are light weight is compare to the virtual machines. Being lightweight more containers can run at same time on a host.

Docker container make use of resources very efficiently. In case of virtual machines capacity is need to be reserved (compute + storage ), whereas this is not needed is case of docker containers .

Virtual machines can be migrated across servers when they are running , but docker need to stopped before migration as there is no hypervisor layer.

How to install docker

step 1. Download static binaries

download the static binary archive. Go to https: //download. Docker. Com/linux/static/stable/ (or change stable to edge or test), choose your hardware platform, and download the . Tgz file relating to the version of docker ce you want to install.

Step 2: extract the archive using the tar utility. The dockerd and docker binaries are extracted.

$ tar -xzvf /path/to/<file>. Tar. Gz

move the binaries to a directory on your executable path, such as /usr/bin/. If you skip this step, you must provide the path to the executable when you invoke docker or dockerd commands.

Step 3: $ sudo dockerd &

if you need to start the daemon with additional options, modify the above command accordingly or create and edit the file /etc/docker/daemon. Json to add the custom configuration options.

Step 4: verify that docker is installed correctly by running the hello-world image.

$ sudo docker run hello-world

this command downloads a test image and runs it in a container. When the container runs, it prints an informational message and exits.

Add registry

sudo docker run -d -p 5000:5000 --restart=always --name irlcent7cmd02 registry:2

install rancher

sudo docker run -d --restart=unless-stopped -p 80:80 -p 443:443 rancher/rancher

NOTE : Before installing rancher make sure to clean any instance of existing rancher file and folders

no previous rancher containers and files should be present in the node where you plan to install rancher. Follow the below steps to remove rancher if present: $ docker ps -a | awk '{ print $1, $2 }' | grep rancher | awk '{print $1 }' | xargs -i {} docker rm -f {} $ rm -rf /var/lib/etcd /etc/kubernetes/ssl /etc/cni /opt/cni /var/lib/cni /var/run/calico /etc/kubernetes/. Tmp/ /var/lib/rancher/state ~/. Kube/config

add hosts entry into ur windows machine to access the rancher ui

https: //server-ip

add a cluster with all the permission (etcd, worker)

copy the command from rancher ui generated during cluster addition and run it on the vm which must be added as cluster. It can be run on multiple vm for multi node cluster

cluster take 5-10 mins to be active

kubectl is a command line to monitor and run command against kubernetes clusters. Either you can use kubectl interface provided by rancher in ui or download the kubectl in your node to monitor the kubernetes cluster and services.

1. Download kubectl on the node where required. 

$curl -lo "https: //storage. Googleapis. Com/kubernetes-release/release/$(curl -s https: //storage. Googleapis. Com/kubernetes-release/release/stable. Txt)/bin/linux/amd64/kubectl"

2. Give it proper permission $ chmod +x . /kubectl

3. Move it to /usr/local/bin/kubectl $ sudo mv . /kubectl /usr/local/bin/kubectl (if it doesnt work move it to /usr/bin)

4. Copy kubeconfig file from ui to by clicking on cluster->kubeconfig file

5. Create ~/. Kube/config file (if not present) and paste the kubeconfig file details copied from the ui to ~/. Kube/config file.

6. Run the following command to check if kubectl is properly installed or not. $ kubectl cluster-info or $ kubectl version

2. How to create docker images

docker commit <containername> <imagename>

ex: docker commit test4. Informatica. Com manoj/newrhel7: latest

3. How to publish docker images

3.1. Create user account on -https: //hub. Docker. Com/

3.2. Login from putty where docker image is taken and enter user/pass

ex :

docker login

username: ldmqa01

password: ldmqa@01

then execute command

docker push test/newrhel7: latest

4. Important command in docker

check the docker version

docker version

check detailed docker information

docker info

search docker images on internet

docker search centos

download docker image

docker pull centos: centos7

to display the list of locally available images, type:

docker images

to test your new image, type

docker run centos: centos7 /bin/ping opera. Com -c 5

list docker containers

docker ps -a

checking docker networking

docker network ls

docker network inspect [network name]

check resource consumption by running container#

docker stats

setting resource limits for a docker container

docker run -it -c 256 -m 300m centos: centos7 /bin/bash

1. Create container in docker

docker run -d -ti -p 1123:22 -p --privileged --hostname=test1 --name test1 -e "container=docker" -v /sys/fs/cgroup: /sys/fs/cgroup -v /etc/ntpd. Conf: /etc/ntpd. Conf ldmteam/rhel7 /usr/sbin/init

docker run -d -ti -p 1123:22 -p --privileged --hostname=$agentcontainername --name $agentcontainername -e "container=docker" -v /sys/fs/cgroup: /sys/fs/cgroup -v /etc/ntpd. Conf: /etc/ntpd. Conf $imagename /usr/sbin/init

2. Start container

docker exec -it <containername> /bin/bash

docker exec -it manojtest1 /bin/bash

3. List docker images

docker images : <lists images>

4. List containers

docker ps -a : <lists container>

5. Stop container

docker stop <docker container id/name>

6. Remove container

docker rm <docker container id/<name>

7. Stop all running containers

docker stop $(docker ps -a -q)

8. Delete all existing containers

docker rm $(docker ps -a -q)

9. Delete all existing images

docker rmi $(docker images -q -a)

Read More

Quartz : Trigger Listeners and Jobs

In the context of quartz scheduler, a listener is an interface that you can implement to receive notifications about various events that occur during the scheduling and execution of jobs and triggers. Listeners provide a way to monitor and react to specific events within the quartz scheduler framework. There are several types of listeners available in quartz, such as job listeners, trigger listeners, and scheduler listeners.

Here's an overview of each type of listener and how to use them in java:

Job listener:

Joblistener interface is used to receive notifications related to job execution.

You can implement the joblistener interface to define custom behavior when jobs are about to be executed, have been executed, or were not executed.

The main methods in the joblistener interface are:

1. jobtobeexecuted(jobexecutioncontext context): called before a job's execute method is invoked.

2. Jobwasexecuted(jobexecutioncontext context, jobexecutionexception jobexception): called after a job has been executed.

3. Jobexecutionvetoed(jobexecutioncontext context): called if a trigger has vetoed the execution of a job (e. G. , misfire handling).

Trigger listener:

triggerlistener interface is used to receive notifications related to trigger events.

You can implement the triggerlistener interface to customize the behavior when triggers are about to be fired, have been fired, or misfired (i. E. , not fired as scheduled).

The main methods in the triggerlistener interface are:

triggerfired(trigger trigger, jobexecutioncontext context): called when a trigger has fired.

Triggermisfired(trigger trigger): called when a trigger has misfired (e. G. , skipped or delayed).

Triggercomplete(trigger trigger, jobexecutioncontext context, trigger. Completedexecutioninstruction triggerinstructioncode): called when a trigger has completed its firing.

Scheduler listener:

schedulerlistener interface is used to receive notifications related to the scheduler lifecycle and its events.

You can implement the schedulerlistener interface to perform actions when the scheduler is started, paused, resumed, or shut down.

The main methods in the schedulerlistener interface are:

schedulerstarted(): called when the scheduler has been started.

Schedulerpaused(): called when the scheduler has been paused.

Schedulerresumed(): called when the scheduler has been resumed after being paused.

Schedulershutdown(): called when the scheduler is shutting down.

To use these listeners in your java application with quartz scheduler:

implement the desired listener interface(s) by creating a class that provides the required behavior for each listener method.

Register the listener(s) with the scheduler:

Java

scheduler scheduler = // obtain the scheduler instance

joblistener joblistener = new yourjoblistener(); // replace yourjoblistener with your implementation

scheduler. Getlistenermanager(). Addjoblistener(joblistener);

triggerlistener triggerlistener = new yourtriggerlistener(); // replace yourtriggerlistener with your implementation

scheduler. Getlistenermanager(). Addtriggerlistener(triggerlistener);

now, whenever the corresponding events occur, your listener's methods will be invoked automatically by the quartz scheduler.

By using listeners in quartz, you can easily customize the behavior of your scheduled jobs and triggers, monitor their execution, and perform actions based on various events in the scheduler's lifecycle.

Read More