When i run the following command
docker run mongo
It will download the mongo image and run it on container.
I am running Linux on VM.
My OS details are as follows:
NAME="CentOS Linux"
VERSION="7 (Core)"
In case I am using different OS /Mac Machine / Windows, how does docker determine which image to pull. As I understand there is a single image on docker hub for mongo or is it that we can specify a specific image to run based on our OS.
At least we need take care of downloading specific version of mongo when doing installation on our local machine (when not using containers).
How is this taken care of by dockers.
Thanks.
The OS that you are running is for the most part irrelevant when it comes to pulling a docker image. As long as you are running docker (and the versions of docker are a little different from windows to Mac to Linux) on your host, you can pull any image you want. You can pull the same mongo image are run it in any operating system.
The image hides the host operating system making it easy to build an image an deploy pretty much in any machine.
Having said that you may be getting confused because image makers many times use different OS to build their applications. A quick example is people building application using an Ubuntu image but switching to an alpine based image for deployment because that is so much smaller. However, both images will run pretty much anywhere.
Probably you are confused with terms OS and Architecture?
The OS does not really matter, because, as #camba1 mentioned, the Docker daemon handles all that stuff.
What matters, is architecture, because Linux can run on ARM, AMD64, etc.
So, the Docker daemon must know which image is good for current architecture.
Here is a good article regarding this question.
Related
This may seem like a silly question, but I am a beginner to containerization concept and I was wondering why the ubuntu image size(~80mb) from docker hub is very much lesser than its iso file(~1.8GB)
Container is an isolated space of your Kernel.
On ubuntu:18.04 docker image, it doesn't contain entire Kernel binaries.
It only has some libraries and executions with some configuration required to run ubuntu:18.04, it still uses your host's Kernel.
You can take a look at how does ubuntu:18.04 image created from Dockerfile from here.
I recommend you to search how Docker use cgroups and namepaces to create container.
Docker images contains only necessary minimum library and tools which is in fact needed to be an operating system running.For Ubuntu docker images, its does not have any GUI(which is not used in container or rarely used) and most tools are also not included.Its just a base operating system.Alpine images are too much smaller than the Ubuntu images.
I'm new to docker and I'm still trying to learn the conepts.
On my centos machine I created a test image that would include a C-compiled executable. Based on my understanding of docker my intention and my expectation was for the image to run on centos machines only. Here is my docker file:
FROM centos:7
WORKDIR /opt/MYAPPS
COPY my_hello .
CMD my_hello
The image builds and works fine on the centos machine I created.
Then I pushed this image to my repo and pulled it to another centos machine, and works correctly as well. So far so good.
As I mentioned I was expecting for this image to be limited to centos. In order to prove it I tried pulling it to other OSs, my ubuntu and my windows. To my surprise, it worked on both.
Obviously I'm missing something. Either I'm not grasping the concept of docker or I'm using the wrong "FROM" image.
As I mentioned I was expecting for this image to be limited to centos.
No: What you put in the image is merely what the dependencies for your executable to run, but in the end, everything resolves to system calls.
That means your image is limited by the kernel of the host machine, since the running process is doing system call to said kernel.
(As illustrated in "The Fascinating World of Linux System Calls")
As long as the kernel (here Linux, even on Windows, through HyperV) supports your system call, your program will run on those hosts.
See more at "How can Docker run distros with different kernels?".
I understand docker engine sits on top of docker host (which is OS) and docker engine pull docker/container images from docker hub (or any other repo). Docker engine interact with OS to configure and set up container out of image pulled as part of "Docker Run" command.
However I quite often also came across term "Docker Container". Is this some another tool and what is its role in entire architecture ? I know there is windows container or linux containers for respective docker host..but what is it Docker Container itself ? Is it something people use loosely to simply refer to container in general ?
In simple words, when you execute a docker image, it will spawn a docker container.
You can relate it to Java class(as docker image), and when we initialize a class it will create an object(docker container).
So docker container is an executable form of a docker image. You can have multiple Docker containers from a single docker image.
A docker container is an image that is an (think of it as a tarball, or archive) executable package that can stand on its own. The image has everything it needs to run such as software, runtimes, tools, libraries, etc. Check out Docker for more information.
Docker container are nothing but processes which are spawned using image as a source.
The processes are sandboxed(isolated) from other processes in terms of namespaces and controlled in terms of memory, cpu, etc. using control groups. Control groups and namespaces are Linux kernel features which help in creating a sandboxed environment to run processes in isolation.
Container is a name docker uses to indicate these sandboxed processes.
Some trivia - the concept sandboxing process is also present in FreeBSD and it is called Jails.
While the concept isn’t new in terms on core technology. Docker were innovative to imagine entire ecosystem in terms of containers and provide excellent tools on top of kernel features.
First of all you (generally) start with a Dockerfile which is a script where you setup the docker environment in which you are going to work (the OS, the extra packages etc). If you want is like the source code in typical programming languages.
Dockerfiles are built (with the command sudo docker build pathToDockerfile/ and the result is an image. It is basically a built (or compiled if you prefer) and executable version of the environment described in you Dockerfile.
Actually you can download docker images directly from dockerhub.
Continuing the simile it is like the compiled executable.
Now you can run the image assigning to it a name or setting different attributes. This is a container. Think for example to a server environment where you might need the same service to be instantiated the same time more than once.
Continuing again the simile this is like having the same executable program being launched many times at the same time.
How are Packer and Docker different? Which one is easier/quickest to provision/maintain and why? What is the pros and cons of having a dockerfile?
Docker is a system for building, distributing and running OCI images as containers. Containers can be run on Linux and Windows.
Packer is an automated build system to manage the creation of images for containers and virtual machines. It outputs an image that you can then take and run on the platform you require.
For v1.8 this includes - Alicloud ECS, Amazon EC2, Azure, CloudStack, DigitalOcean, Docker, Google Cloud, Hetzner, Hyper-V, Libvirt, LXC, LXD, 1&1, OpenStack, Oracle OCI, Parallels, ProfitBricks, Proxmox, QEMU, Scaleway, Triton, Vagrant, VirtualBox, VMware, Vultr
Docker's Dockerfile
Docker uses a Dockerfile to manage builds which has a specific set of instructions and rules about how you build a container.
Images are built in layers. Each FROM RUN ADD COPY commands modify the layers included in an OCI image. These layers can be cached which helps speed up builds. Each layer can also be addressed individually which helps with disk usage and download usage when multiple images share layers.
Dockerfiles have a bit of a learning curve, It's best to look at some of the official Docker images for practices to follow.
Packer's Docker builder
Packer does not require a Dockerfile to build a container image. The docker plugin has a HCL or JSON config file which start the image build from a specified base image (like FROM).
Packer then allows you to run standard system config tools called "Provisioners" on top of that image. Tools like Ansible, Chef, Salt, shell scripts etc.
This image will then be exported as a single layer, so you lose the layer caching/addressing benefits compared to a Dockerfile build.
Packer allows some modifications to the build container environment, like running as --privileged or mounting a volume at build time, that Docker builds will not allow.
Times you might want to use Packer are if you want to build images for multiple platforms and use the same setup. It also makes it easy to use existing build scripts if there is a provisioner for it.
Expanding on the Which one is easier/quickest to provision/maintain and why? What are the pros and cons of having a docker file?`
From personal experience learning and using both, I found: (YMMV)
docker configuration was easier to learn than packer
docker configuration was harder to coerce into doing what I wanted than packer
speed difference in creating the image was negligible, after development
docker was faster during development, because of the caching
the docker daemon consumed some system resources even when not using docker
there are a handful of processes running as the daemon
I did my development on Windows, though I was targeting LINUX servers for running the images.
That isn't an issue during development, except for a foible of running Docker on Windows.
The docker daemon reserves various TCP port ranges for itself
The ranges might change every time you reboot your system or restart the daemon
The only error message is to the effect: can't use that port! but not why it can't
BTW, The workaround is to:
turn off Hypervisor
reboot
reserve the public ports you want your host system to see
turn on hypervisor
reboot
Running packer on Windows, however, the issue I found is that the provisioner I wanted to use, ansible, doesn't run on Windows.
Sigh.
So I end up having to run packer on a LINUX system after all.
Just because I was feeling perverse, I wrote a Dockerfile so I could run both packer and ansible from my Windows station in a docker container using that image.
Docker builds images using a Dockerfile.
These can be run (Docker containers).
Packer also builds images. But you don't need a Dockerfile. And you get the option of using Provisioners such as Ansible which lets you create vastly more customisable images. It isn't used for running these images.
I am new to docker and i watched many videos and also studied articles. From there i came to know what exactly docker is.
But my question is -:
Lets suppose i have three docker image
First image of "Application 1" is created in window 7/8/10 environment
Second image of "Application 2" is created in CentOs .
Third docker of "Application 3" image is create in Linux.
so , can i run all these three images simultaneously in single environment(Window or CentOS or Linux) ?
Surely you can ! That's the advantage of docker . Docker runs images on any platform without worrying that what is inside image. So on centos you can run a ubuntu image and vice-versa.
You can run any Linux Docker container image created recently on any Docker host running Linux. There are exceptions around various kernel features which you might not have access to on an older kernel, though, for example. Windows apps do not run on Docker on Linux unless you are doing something like running them under Wine.
There is Windows specific containers which only runs on windows hosts, but if you are using the standard (none-windows-exclusive) images, they run the same on all hosts.
One of the core ideas with docker is that you should be able to run your service in the exact same environment (the container) on any system (the host). Which works pretty well (with the exception of the windows specific containers!).