EMAIL SUPPORT

dclessons@dclessons.com

LOCATION

US

Containerizing an APP

Containerizing an APP

Container & VM

Container & VM both run on host machine. In VM, a hypervisor runs on each host and then VM is created and on top of each VM suitable OS is installed and then application is hosted on it. So each VM will have operating system hosted. Once Host machine is powered on, it shares all of it RAM, CPU, Storage and NIC to VM working on it.

When we run an image, an instance of it is formed and we name it containers. From a single image, multiple containers can be build. Containers share OS/kernel of host on which they are running.

Container runs till the time the app they are executing. In container, Host machine has native OS which claims all of the host machine resources, on top of OS docker Daemon is installed On top of it containers are run and application is hosted on it, The Container engine takes all OS resources such as process tree, file system, and network stack and carved them in to secure isolated construct called containers.

Containers Self-healing restart Policies:

Whenever container are run, they must have some re-start policy so that docker automatically restart them after certain event or failure.

These re-start policies are applied per container and is configured along with docker-container run command. Following are re-start policies currently available with docker.

  • Always
  • Unless-stopped
  • On-failed

Always: it will always restart the stopped container unless it will explicitly stopped. Now another concept around is that a stopped container will be restarted when the Docker Daemon starts, meaning , a container is started with –restart always policy and is stopped with docker container stop command , at this point container is in exited state and now let’s restart the Docker daemon , the container will be automatically restarted and when daemon comes up.

Unless-stopped: container with –restart unless-stopped policy will not be restarted when daemon restart if the containers are in exited state.

On failure: This policy will start the container if and only if the container exits with non-zero exit code. It will also restart the container if Docker Daemon restart and even containers that were in stopped state.

All these restart policy to a service object as applied as below:

Version: “3.5 “
Services:
Myservice:

Restart policy:
Condition: always | unless-stopped | on-failure

Container Cleaning:

In order to clean everything on container present on docker host, run following command:

$ docker container rm $ (docker container ls –aq) –f

Use this command with caution because it will forcefully destroy all containers without giving up chance to clean up.

The above command we already know docker container rm deletes all container and passing (docker container ls –aq ) arguments to it , it passes all the container ID to main command and –f tag forces to delete all container present in docker .

Containerizing an APP:

Following are the process to containerizing an APP:

  • Start with application code
  • Create Dockerfile that describe your app, dependencies, and how to run it.
  • Put Dockerfile in to docker image build command
  • Docker will build the application in to docker image

Below is the overall steps:

How to containerize the single container APP:

Below are the procedure to containerize a single container app:


Comment

    You are will be the first.

LEAVE A COMMENT

Please login here to comment.