Running an application in a Docker container right now, and it works smoothly. However, I have some trouble understanding exactly what Docker does, what an image is, and what a container is
In: Technology
Docker provides a standard way to create, distribute, and run software. It’s a reliable way of providing compatibility because the standards are so strict; “it just works” because you’re simply not allowed to do the things that native software can do.
A Docker image is like a hard drive with an OS and applications installed on it. When you create a Docker image, it starts with an OS install (although this is typically done for you, so you don’t have to do it yourself). Then whatever applications are installed — but again, this is often done for you: if you just tell Docker you want a popular software package like Java, someone has already done the install so you can just use their install without doing it yourself.
So what’s inside your Docker image is not substantially different than what would be on your hard drive if you installed all that stuff manually.
When it comes time to run your Docker image, we call those containers. And we call them that because what’s going on inside of them is locked inside; Docker containers cannot access the host OS or software. It can’t even access your network or hard drive, unless you give it permissions to. Even then, the container only has the access you give it, so you can share one folder and it can’t see any of your other files.
Containerization is good for security (a virus in the container can’t escape the container and get into your machine), but also for stability. In a traditional software environment, software shares libraries and DLLs, so if something happens with a DLL or library (such as a patch or upgrade) can break a bunch of applications that were using them. With Docker, each container is completely independent with their own DLLs and libraries, so one container doing something crazy can’t affect the others.
One of the neat things, though, is layering the images. So if you have two containers that both use Java on Linux, you’ll just have one copy of Linux and one copy of Java that’s shared between containers — however, those layers are read-only. Any changes made in one container will not be seen by the other container, because each container has it’s own separate layer stacked on top of the read-only Linux and Java layers.
In Linux -and many other UNIX-like OSes- there is a tool called `chroot` that allows you to run an application using a given directory as if it were the `/` directory. For instance:
mkdir /tmp/blah
chroot /tmp/blah /bin/bash
This will run bash using `/tmp/blah` as the root directory. Obviously, this won’t work, because there is no `/bin/bash` under `/tmp/blah`. But we can make it work by populating `/tmp/blah` with a basic Linux filesystem:
/tmp/blah/bin
/tmp/blah/etc
/tmp/blah/lib
/tmp/blah/usr
/tmp/blah/proc
…
If you populate this directory with all the files that bash needs (the bash itself, libraries, configuration files, etc) the `chroot` command will work. Note that those files don’t have to be from your running distribution: you can run Arch in a chroot in Ubuntu, for instance. The only piece that will be shared is the kernel itself.
This has been used for many years to isolate an application from the rest of the system. The thing is, an application running in a chroot can’t access anything outside the chrooted directory. This is typically done in hosting services, where you buy part of a machine to host your web page.
This has an issue: an application can be isolated from other parts of the filesystem, but running `ps` or `w` will still show other processes and users. It turns out that `chroot` does not isolate your application entirely.
The Linux kernel has something called cgroups and namespaces which solve this. With them you can launch an application like `chroot` did but actually isolating it from other processes, users, and assigning it a subset of CPUs, memory, network, etc.
So, trying to answer the questions:
– Docker is a tool to launch applications in isolated environments.
– A docker image is a .tar.gz file that contains everything required by an application to run in a chroot. For instance, an image can contain a few files to run busybox, or an entire Debian distribution.
– A container is a process + its assigned resources in the cgroup + an image.
That’s terribly simplified but you get the idea 🙂
https://www.reddit.com/r/explainlikeimfive/search?q=docker&restrict_sr=1
Latest Answers