Sneak view into Docker for devs| Part-2

docker run -p 5000:5000 in28min/hello-world-python:0.0.1.RELEASE
  • We used to get a document from my development team describing the hardware, the specific version of the operating system, the specific version of the software, and the specific version of the application to deploy.
  • We used to manually follow the instructions — create a server, install an operating system on top of it, and install the right software, install Tomcat or whatever you’d need to run your application, and install the right language — Java or Python.
  • And after that is when we would download the application and deploy it, and very manually setting up the environment. We used to make a lot of mistakes.
  • With Docker, we don’t really need any details about the application that we would want to run.
  • We don’t really need to worry about what language the application is built with. Is it a Java application, or a python application or a Javascript application. We don’t really need to worry about which version of Java or which version of Python.
  • What were the frameworks which were used to build the application with. What is the software that is needed to run the application.
  • All that the developer needs to do, is to create something called Docker image, and you can run the image the same way, wherever Docker runtime is installed.
  • It does not matter if the image contains a java application, a python application, or a NodeJS application — you still run it the same way.
docker run -p 5000:5000 in28min/hello-world-java:0.0.1.RELEASE
  • Public docker Registry : https://hub.docker.com .From here, we can find docker-base-image for any of the repository. For ex → Image for Ubuntu, Mysql, NodeJS, Java, etc.
  • Private docker Registry : Amazon ECR. Here, we can store our own docker image files at AWS. Usually used in Enterprise eco-systems.
  • The first part over here is called a repository. So what we are seeing in here is a repository called hello-world-java.
  • Inside this repository, we would want a specific release 0.0.2.RELEASE. And if you scroll down and go to tags, you’d see that there is one tag which is present in here for 0.0.1-RELEASE.
  • A specific image contains everything that you would need to run your specific application. It contains the right software you’d need to run the application — for example the right version of Java.
  • It contains all the libraries that your application needs, and in addition to that, it might also contain any dependencies that your application might need to be able to run.
  • So the image is stored on Docker Hub (which is a public docker registry) and this specific repository for this particular image is : in28min/hello-world-java. And this specific tag of this specific image is 0.0.1.RELEASE.
docker run -p 5000:5000 in28min/hello-world-java:0.0.1.RELEASE
  • You can see above screenshot that, when we executed this command, it saying I am unable to find this image locally. So what is happening is, Docker is checking locally if this image is present — it is unable to find that image locally.
  • So what it’s doing — it’s actually connecting to Docker Hub. So it’s going to Docker Hub and pulling the image from this repository. So it pulls down the entire image from the Docker Hub to your local machine.
  • And once the images downloaded, Docker is running that specific image.
  • An image is something static on the repository. A Docker-Image is nothing but a set of bytes. This image is about 33 MB. When the image is downloaded onto your machine, even then, it’s just a set of bytes which are downloaded to your machine.
  • The running version of the image is called a container. When the image is running, It’s called a container.
  • So we containerised our Java application and our python application And you saw that we were able to launch them up very very easily. We did not need to worry about how to install Java, how to install Python, etc. All that we needed to do, was to create an image. Here, we were having the image pre-built.
  • Another thing to note here is that, the container that we spawned is tied with the terminal.
  • The image is actually downloaded from a public Docker registry called Docker Hub.
  • A Docker-Registry contains a number of repositories, and one of the repositories which is present in there is : hello-world-java. So in28min/hello-world-java is the name of the repository, and 0.0.1.RELEASE is a version of this specific repository.
  • A repository typically maps to a specific deployable unit, and you might have multiple versions of your deployable units — 0.0.1.RELEASE to 0.0.3.RELEASE.
  • This 0.0.1.RELEASE in here, is a tag which identifies which version of the application, which version of the deployable unit.
  • A running version of this image is called a container. The last thing which we have learned is the fact that we map the container port to a host port, so that, we can access the application which is running inside a container.
  • First thing to note here is that, a container name is also assigned to each containers running. So when we were running the command, we did not really assign any name for the container. So Docker assigned a default name to every container. So you can see that there was a name called admiring_banach, that was assigned to python based container and there is a name called pedantic_hamilton, that is assigned to the java based container.
  • The interesting thing is docker container ls, only shows the containers which are running at this particular point in time.
  • The first & top-most component that we have is : Docker-Client. It just sends that command out to the docker daemon.
  • Docker daemon is the one which is really responsible for execution of that specific command.
  • It is responsible for managing your containers.
  • For managing your local images.
  • It is mainly responsible for pulling the image from the image repository.
  • Create a number of Docker images on our local machine. The Docker demon is also responsible for pushing those images out to the image repository.
  • Docker-Client first sends the command to Docker-Daemon.
  • Then docker-daemon looks at the local images which are present, and the results are sent back. And that’s the results which we are showing in here.
  • The command that we executed, first executes on the docker client, and the docker client sends it out to the docker daemon.
  • Daemon then sees that, which all containers are running at this specific point in time and returns the same.
  • If we do “docker container ls -a” command, then daemon sends-out command and we get the list of containers which are in various kinds of statuses, including stop and running.
  • The “docker client” is sending the command out to the “docker daemon”.
  • The “docker daemon checks locally, if this image is available. So, it will do something like docker images, and it would check, if <reposit-name> is available locally ?
  • In case, seems the <reposit-name> is available locally, it does not go to the docker registry. So it will actually directly use the local image which is present.
  • However, if docker daemon identifies that the requested image is not present locally, then docker client would talk to the docker registry, which is the public Docker registry, and it would try and download that specific image, and it would try to run it.
  • Whenever we install Docker desktop, it means, we have installed docker client and docker daemon.
  • Whenever we send a command from the docker client, it’s executed by the daemon.
  • Whenever we try to run a container, docker checks the local images whether Is that specific image present locally? If it’s not present, what it does is, daemon starts talking to the image registry & gets the image down into our local images, and then starts it as a container.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store