In this chapter, we will explain the benefits of deploying an application via containers vs. the traditional method of using VMs while observing the benefits containers offer over the VMs for solving the same problem set. In a large-scale environment, such as is typical in an enterprise setting, with hundreds, if not thousands, of applications to be hosted and supported, the problem of deploying and managing those applications via VMs can be categorized into two main categories, namely: 1. Dependency hell: Of shared libraries, the OS, and application packages 2. Efficiency and cost control: Efficient use of compute resources Dependency Hell Anyone who has installed Microsoft runtime libraries on a Windows VM running multiple applications or had to upgrade a package system in Linux can tell you how complex this can be. Ever since computers made it into the business applications’ world, supporting real-world applications and problem solving, there has always been the problem of dependencies among the various components, both hardware and software, that comprise the application stack. The technical stack the application software is written on, for example, Java, has versions; this Java version is designed to run on top of a specified set of runtime libraries, which in turn run on top of an operating system; this specified operating system runs on top of a specified hardware device. Any changes and updates for security and feature enhancements must take into account the various interconnects, and when one breaks compatibility, we enter the dependency hell. © Shiva Subramanian 2023 S. Subramanian, Deploy Container Applications Using Kubernetes, This task of updating system components was even more complicated when IT systems were vertically scaled, where there was one underlying operating system and many applications that ran on top of it. Each application might come with its own runtime library requirements; an OS upgrade might not be compatible with the dependencies of some applications running on top, creating technical debt and operational complexity. Efficiency and Cost Control One way a system admin can alleviate the first problem is by creating a separate VM for each application, then scaling it, so the dependency of packages is reduced in complexity. Virtual machines, with each virtual machine running an individual application, were common in the days of virtualization. They still are. The major drawback of such solutions is they essentially waste a lot of resources and increase operational complexity of running large-scale systems. Imagine you are serving a static website that gets millions and millions of hits during peak hours. How do you quickly scale from 1 VM running a web server to 100 VMs running the same application? Even if you did, now you have to apply patches and maintain the web farm of 100 VMs. This decreases efficiency and increases the maintenance function as well as increases the overall cost of providing the solution. To illustrate the problem in finer detail and to allow us to compare solving the same problem using containers, let us first deploy a simple static website using a VM. The VM Way Task: Suppose the developers have developed a static website which they have asked you to host in your production environment. As a seasoned systems engineer or administrator, you know how to do this. Easy!, you say. I’ll create a VM, deploy a web server, and voilà! But what’s the fun in that? However, let us still deploy the static website the traditional way and the container way. This way, we will learn the similarities and differences between the two approaches. Thus 1) We will run a simple static website using virtual machine technology. 2) We will run the same simple static website using container technology. We will then build increasingly complex container applications as our journey progresses. Set up a static website using a virtual machine. Prerequisites Ubuntu 22.04 LTS Note There are several virtual machine technologies available, such as the cloud, ESXi host, VMware Workstation, Parallels, KVM, etc. Instructions for installing the Linux operating system will vary widely depending on the virtualization software in use; thus, we assume that the systems engineer/administrator is familiar with their workstation setup. The typical process involves the following: 1. Install the operating system. 2. Install the nginx (web server) application. 3. Deploy the application data (the web pages). 1. Install the operating system. In my case, I’ve installed a vanilla Ubuntu 22.04 LTS operating system, which we will be using. It is a typical virtual machine with 1 or 2vCPUs with 2GB of memory and ~10GB of HDD. The user shiva is an admin on the VM; since we will be installing many packages later on, ensure that the user you are using has admin rights on the VM via sudo, etc. The installed OS is Ubuntu 22.04 LTS as shown in Listing 1-1. We confirm the OS by running the following command: lsb_release -s -d Note The author has chosen to list plain command(s) only at the top of the listings and the executed output and results right below it, making it easy to differentiate between the command and the author’s illustrated outputs as shown in Listing 1-1. Listing 1-1. Version confirmation and output lsb_release -s -d shiva@wks01:~$ lsb_release -s -d Ubuntu 22.04 LTS 2. Install the nginx (web server) application. Now that the OS is ready, we need to install the nginx application; again, there are many ways to install the nginx application per nginx’s documentation website at packages.html – we can download the source code and compile it, or we can utilize the packages that are readily available for our operating system. In our case, we will install the package from the package repo. We first update our repos by running the command shown in Listing 1-2; depending on your location and the mirror closest to you, the output may slightly differ; as long as the repos are updated, we should be good. Listing 1-2. Package repo update and output sudo apt-get update shiva@wks01:~$ sudo apt-get update Hit:1 jammy InRelease Hit:2 jammy-updates InRelease Get:3 jammy-backports InRelease [99.8 kB] Get:4 jammy-security InRelease [110 kB] Fetched 210 kB in 0s (521 kB/s) Reading package lists... Done The package name for nginx is just nginx; thus, we will install nginx using the standard package manager command as shown in Listing 1-3. Note in the output section indicates the sections of the output snipped out of the listing to maintain brevity; it does not impact the concepts we are learning. Listing 1-3. Installing nginx and abbreviated output sudo apt-get install nginx -y shiva@wks01:~$ sudo apt-get install nginx -y Reading package lists... Done Building dependency tree... Done Reading state information... Done The following additional packages will be installed: fontconfig-config fonts-dejavu-core libdeflate0 libfontconfig1 libgd3 libjbig0 libjpeg-turbo8 libjpeg8 libnginx-mod-http-geoip2 libnginx-mod-httpimage-filter Setting up libnginx-mod-http-image-filter (1.18.0-6ubuntu14.4) ... Setting up nginx-core (1.18.0-6ubuntu14.4) ... * Upgrading binary nginx [ OK ] Setting up nginx (1.18.0-6ubuntu14.4) ... Processing triggers for ufw (0.36.1-4build1) ... Processing triggers for man-db (2.10.2-1) ... Processing triggers for libc-bin (2.35-0ubuntu3) ... Scanning processes... Scanning linux images... Running kernel seems to be up-to-date. No services need to be restarted. No containers need to be restarted. No user sessions are running outdated binaries. No VM guests are running outdated hypervisor (qemu) binaries on this host. Please note that your mileage may vary with respect to the output messages due to variations in installed editions of the operating system. Confirm the nginx process is running as shown in Listing 1-4. Listing 1-4. Confirming nginx is running ps -ef | grep [n]ginx shiva@wks01:~$ ps -ef | grep [n]ginx root 2125 1 0 03:23 ? 00:00:00 nginx: master process / usr/sbin/nginx -g daemon on; master_process on; www-data 2128 2125 0 03:23 ? 00:00:00 nginx: worker process This marks the end of step 2, which is installing the web server; now on to step 3. 3. Deploy the application data (the web pages). Luckily, nginx comes with its own default index.html; thus, we do not have to deploy anything special just to test the package. To test, we can use curl and confirm the web server is returning the web content as shown in Listing 1-5. Listing 1-5. Browsing to the nginx default website using the command line curl localhost shiva@wks01:~$ curl localhost Welcome to nginx!

Welcome to nginx!

If you see this page, the nginx web server is successfully installed and working. Further configuration is required.

For online documentation and support please refer to .

Thank you for using nginx.

We have successfully deployed our static website using a VM. The VM Way – Problem Summary From a time-to-deploy an application perspective, we have taken ~30 minutes to install the operating system and another ~5 minutes to update the package manager data and install the actual package. From a resource perspective, we have taken 2GB of memory and 10GB of HDD space. Suppose we have to scale this horizontally to ten VMs; that would have required 20GB of memory (10VM×2GB/VM) and 100GB (10VM×10GB/VM) of HDD space, which is an enormous amount of resources just for serving a static website. Along comes the system administration overhead of managing these VMs, patching, user management, IP addresses, and such. Is there a better way? Enter Containers Welcome to the wonderful world of containers. Containers solve both of the major problems associated with the VM way: 1. Dependency hell – no more Containers provide us a way to package an application and all its dependencies including the underlying operating system in an automated way, which can then be run on top of a container runtime and be scaled up or down horizontally quickly. Patching? No problem. Build a new image; deploy the new image; let the container management system (Kubernetes) take care of the rest. New app release? No problem. Build a new image; test; deploy the new image via Kubernetes. You get the idea. Self-contain the application and its runtime, build an image, deploy the image, and manage the image using K8S. Here, container is a generic term capturing the essence of the technology underpinning, which is to say the application and related dependency components are all self-contained and won’t impact the contents of another application in another container, like a physical container where the contents of one container cannot impact the contents of another container and the container as a whole can be lifted, shifted, and moved easily. Here, the term image refers to the binary format or artifact of the technology container. 2. Efficiency and cost control Unlike a traditional VM which contains a plethora of components to enable general-purpose application development, a container is purpose built and includes only the minimum needed OS components such as the kernel and necessary shared libraries to run the application process, no more, no less – meaning the container images are compact both at the disk image level as well as the memory footprint level. Just like how a hypervisor is capable of running many VMs, the container host (node) is capable of running as many container images as its CPU, memory, and disk would allow, except, instead of running full-blown VMs, containers run only the bare minimum processes needed for the application. FUN FACT: Google launches several billion containers per week.1 Expert advice: There are almost little or no technology controls that will prevent you from building a container with two applications running within the same container. Be aware, that’s bad design and breaks the basic tenant of a container. Don’t fear running each application in its own container as the resource required to run a container is very minimal; you will not be conserving any resources and will be reintroducing the dependency management complexity that got us here in the first place! Summary In this chapter, we learned about two of the major problems associated with deploying and managing an application and how containers promise to solve both the problems, enabling systems engineers to reduce complexity while increasing efficiency, scalability, and reliability of hosting applications via containers. In the next chapter, we will deploy a simple static application via container technology, realizing for ourselves how easy it is to deploy and manage applications deployed via containers.