What are containers? Containers are packages of software that contains everything that is required to run a service (web server, email, SQL Database, DHCP server, DNS Server or custom code). Containers contain all the needed libraries, binary code, executables and configuration files that are required to run the service. A container does not contain an image of an OS. As a container does not contain an OS image this makes them more lightweight and portable. Also, within a container you can specific versions of software that your code requires. You can provide this container image to another party and you can guarantee that it will work.
Containers are just another way to virtualize that does not require as many resources and are easier to configure/deploy that an entire VM.
Containers have been around since the late 1970s! The first idea of containers started with Unix V7 in 1979 with the chroot system call. The next major implementation of containers came with FreeBSD in 2000. FreeBSD implemented something called jails and this created a clear separation between services that might be run on a single FreeBSD server. Jails provided the ability to assign an IP address to each system and configuration. Along the way there has been other container implementation that required patching the kernel or never had a stable release (Linux VServer, Solaris Containers, Open VZ). Containers continued to progress for the next several years, but in 2013 Docker was released. When Docker was released this revolutionized container technology and container usage exploded.
Containers help us to solve the problem of moving software from one computing environment to another. Think about a developer writing code to run a server. This developer tests the code on their computer and it works. The developer now wants to test the code an a test server to make sure that it also works on that computing environment. Without containers the developer might have to install libraries or other software to get it to work. This could be a simple task, but the developers software might require a specific version of a library and that could cause them a headache if it is not easily able to be installed/configured on the test system. A more concrete example is the developer wrote their code using Python 2.7, but on the test system it only has Python 3 installed. This creates a problem and containers can solve it! The developer could create a container that says to use Python 2.7, copy their code to the container and start the container on the test environment without having to change the test environment's configuration.
You might be thinking well, why not just create a VM on a type 1 hypervisor that has Python 2.7 installed. This would also solve the problem. Yes, you are correct. It would solve the problem, but you would have to create an entire VM, install an OS and the size of the VM could take up gigabytes of disk space. Creating a VM would also take a few hours to complete. Creating and deploying the code within a container can be done extremely quick and also the disk space would be under 100 megabytes in size. Another benefit the developer would notice is that starting up a VM can take several minutes (think of your computer starting up, it takes time). With a container it is almost instantly run once you launch it.
We will learn how to create containers and deploy them in the next module. I hope this has piqued your interest to learn about containers!