Understand the idea of “packaging” code to some degree, but why would this process need to be done? What is being resused and changing in the process to require scalability and efficiency that is described with the benefits of dockerization? It’s just not registering. Thanks.
In: Technology
Your computer has many different things installed including libraries, programs, drivers, etc. The exact nature of what you have installed is going to be different than that of everyone else, and slight discrepancies can cause something to work properly on one machine and not on another. Docker images basically pretend to be a fresh slate; what’s installed on your computer doesn’t interact with what is in the docker image for the most part. It doesn’t matter what device you are using it on, it should behave the same way on any device. The Dockerfile describes how to create that environment.
At the core, Docker acts like anything within the container is in its own separate operating system, but it’s much more efficient than emulating a full operating system.
Docker containers create a separate, virtual environment for program or processes all running on the same server. They contain all of the information and dependencies for those programs inside the container itself. This can be advantageous for several reasons:
– If you are running multiple programs that use the same dependencies, you can ensure there are no conflicts (e.g. two programs require two different versions of the dependency
– If one container updates the dependency, you can be sure it doesn’t break other programs that use the same dependency.
– If there is a critical error in a container and it crashes, the host system will be unaffected.
– You can easily limit access to host files and resources
– You can spin down, make changes, and spin up containers without affecting other programs running on the server.
I’m sure there are other benefits, but that is what I can think of off the top of my head.
Many of these benefits are also available using virtual machines, but containers have the advantage of being far less resource intensive.
There is classical virtualization, where you can get a reliable and reproducible copy of your environment by emulating hardware and running its own operating system. This works but has significant overhead because realistically you don’t need 10 different operating systems with 10 virtualized hardware devices to run 10 different apps on physical/virtual machine
Docker and its alternatives utilize the tools Linux gives you by cleanly separating your application from others, including various resources such as CPU, memory, disks, filesystems etc. while still providing the underlying operation system functionality without running multiple operation systems in parallel.
With that, you can create images – a filesystem which is just enough (best case scenario) to run your application and nothing more and run your apps as if that filesystem was a root filesystem.
Moreover, with tricks such as image layering you can even run 10 different apps while taking up barely more space than if you were to run one app, because best case scenario your apps shares 99% percent of system libraries and only differ by an actual application.
So essentially, docker IS lightweight virtualization, not in a technical sense, but from an intention endpoint.
Old school ‘virtualization’ virtualizes hardware for use by a virtual machine. A container virtualizes the operating system. So, necessarily, the container must run the same OS as the host. This technology has been around for a long time in some form or another, Docker is just one iteration. One thing to keep in mind, you don’t usually run a whole OS in a container, so it is probably better to say the container must be *compatible* with the host’s operating system.
Say I have an application that requires a certain version of Java, I could spin up an entire virtual machine running the desired OS and all of its little stuff and then I could install the correct version of java and then install the application. Or, I could ‘containerize’ the application by creating a container with the correct version of Java and the code that runs the application. That is a lot more lightweight, when the developer updates the app, I just destroy the existing container and put in the new one. Linux admins will recognize this idea as very similar to the idea of a chroot jail – another method of isolating processes.
The benefits are a little more mixed than a lot of people will admit to, I run a major application on Kubernetes (an orchestration platform, the underlying containerization is the dockerd runtime) and I am regularly surprised by what it *can’t* do. Performance monitoring is a joke, collecting logs is a massive PITA, it doesn’t (out of the box) do dynamic load balancing, etc. At the end of the day you are still running some developer’s crappy code but with an added layer of abstraction that is super difficult to explain to people.
In addition to what everyone else is saying, I think another strength that Docker has is it’s scripting language for actually creating the images. This makes it way easier to understand what steps are being taken to construct the image, and makes it possible to review changes to the image in code review.
Docker is essentially a fancy version of a virtual machine – it takes the basics of “run a miniature computer session on my computer” and adds in features like automatic software installation and platform standardization.
So with Docker, you can essentially roll out an ad hoc installation of some software with a click or two, instead of having to manage any details. And you can roll out as many as you need.
The same code could run on my machine but not yours (different OS and softwares could cause this).
With the introduction of cloud computing, most code would need to be run on random machines. How could we prevent this problem? Make the machine create “virtual machine” inside of it that simulate same OS and softwares, then instruct them how to run the code. This way it guarantees that it works on any machine on any clouds hence scalability.
This is the simplest explanation I could come up for ELI5
Latest Answers