From the course: DevOps Foundations: Containers
What are containers?
From the course: DevOps Foundations: Containers
What are containers?
- [Instructor] You've no doubt heard a lot about containers recently. They seem to be one of the hottest new technologies around, but what exactly our containers and how do they fit into your DevOps ecosystem? Containers allow you to keep your application code contained by wrapping it together with the tools and supporting libraries it needs. The idea itself is not particularly new. Some of the predecessors are things like a virtual machine where an entire server, including the hardware is emulated. Or for something much more lightweight. There are virtual environments and CH routes, which don't emulate any part of the system, but configure the code to ignore anything in the file system. Except the current directory and its sub-directories. To better understand what exactly containers are, it might help to look at the non-containerized way of packaging software. It's very common to ship an application that depends on some external libraries. These external libraries are the pieces of code that are common between different applications. They don't need to be included in every single application because they're basically just doing the same thing. This offers a couple of benefits. One is that if there's a bug in the code that's shared between the different applications, it only has to be fixed in one place. And the individual software developers won't need to release updates. Splitting out the packages also causes the applications to use up less space on disk. Those reasons both make a lot of sense if you're shipping packaged software that's going to be purchased by a consumer on a store shelf. Or if you're dealing with very limited disk space. These days, neither of those problems are much of a concern. In fact, you'll even see some non-containerized applications shipped as a single file these days with all the external dependencies compiled right in. The other major difference between containers and traditional applications is how they are run on them system. If you look at the taskbar on your computer, you've probably got a couple of things running right now. Those are all running side by side within the same operating system. Those applications share some resources. For example, they can write files to the same folder on disk. And there are ways that they can interact with each other via other parts of the operating system itself. Containers on the other hand act much more like a fully independent system. They provide a way for individual applications to act as if they're the only thing running on the system. That's really the core feature of containers. They provide a way of isolating one application from another. Both in packaged dependencies that are bundled along with the application, but also in how the application itself interacts with the larger operating system.