348
physical hardware, regardless of hypervisor type, there
will be a limit to how many
VMs you can run on it because of this, and performance will never be
quite as good
as a non-VM situation.
Containers seek to avoid this “weight” issue in favor of something lighter on
resources so that physical server resources can be used more efficiently and shared
between more deployed apps, thereby allowing a server to do more.
In contrast to a VM, a container performs operating-system-level virtualization. This
is achieved by abstracting what’s known as “user space,” that is, where your applications
run. There is no emulation occurring with containers. Instead, they actually
share kernel
space with the host OS. But a container looks like a VM in most other regards in that
they represent an isolated user space where your applications can run. In this way, you
can
have many containers running, all with their own user space but sharing the kernel
resources of the host operating system. This is a far more efficient approach than VMs
and allows for many more containers to run on a given host system.
A key point about containers is that they allow you to package up not only your
application but also its runtime environment. Yes, that means things like a JDK for a Java
application and JavaScript libraries for a Node app, but it also means the underlying
operating system environment. When you create a container,
you start from a blueprint
known as an image. The image almost always begins with an operating system and then
has stuff added to it, building up to the final image. So, if you want to package up your
Node application, you will also, in a container, package up a version of, say,
Linux that it
will run on.
Containers function as if they were the sole OS on the hardware. Anything running
in them is unaware that they are on a shared system, just like a VM, but it’s still just a
process running on a host system, not a fully emulated computer and OS on top of it, and
it’s not going through a hypervisor like a VM is.
A container relates to an image in that the image is the blueprint,
and a container
is an instance of the image. You can think of it like a class-object relationship: classes
are essentially the blueprint that is used to build instances of that class that we then call
objects.
This yields what is perhaps the most significant benefit of containers: a consistent
runtime environment without the overhead of a VM. The host operating system mostly
doesn’t matter (with some caveats concerning cross-platform containers, vis-à-vis
Windows containers on Linux hosts and vice versa). Only what’s in the container
matters, and only what’s in the container will impact the functioning of the app(s) in
Chapter 12 Bringing the Dev Ship into harBor: DoCker
349
that container. You can change the host operating system and know that what’s in the
container will still be the same environment you originally build and so everything will
work as it always has, no fear of breakage due to the host change.
Another benefit of containers
is that they start fast, almost instantly in most cases,
which makes them easy to scale. If you have an application running in a container
and the load on it starts getting too heavy, it’s relatively quick and easy (assuming your
application code allows for this) to spin up more containers with instances of your app
running to share the load.
Container capabilities have been built into Linux for many years, but it only began to
gain traction with the introduction of something that made dealing with the technology
much easier: Docker.
Do'stlaringiz bilan baham: