CompTIA Linux+ Certification: Understanding Cloud and Virtualization Concepts

Objective 3.2: Given a scenario, perform basic container operations.
Objective 3.5: Summarize container, cloud, and orchestration concepts.

Key Topics:
Considering Cloud Services
Understanding Virtualization
Exploring Containers

Cloud technology has greatly changed the landscape of the computer world. Moving computer resources and applications into a shared network environment changes how many companies do business and provide services to customers. This guide introduces the main concepts of just what a cloud is and the role that Linux plays in cloud computing.

This guide starts out by defining what cloud computing is and what the different types of cloud computing environments are. Next is a discussion of how virtualization plays an important role in cloud computing and how that is implemented in Linux. Finally, you'll learn how containers fit into cloud computing and how they have changed the way developers do their jobs.

Considering Cloud Services
Before diving into how Linux participates in cloud computing, it's a good idea to define just what a cloud is and what type of resources it provides.

What Is Cloud Computing?
The first mention of the term cloud came in documentation for the original ARPAnet network environment in 1977, the precursor to the modern-day Internet. In that documentation, the cloud symbol was commonly used to represent the large network of interconnected servers geographically dispersed. However, in this environment each server was self-contained and self-sufficient; there was no distributed computing.

The term cloud computing is related to distributed computing. In distributed computing, resources are shared among two or more servers to accomplish a single task, such as run an application. This environment became the precursor to what we know today as cloud computing, popularized by companies such as Amazon Web Services (AWS), Google Cloud Platform, and Microsoft Azure.
 

With cloud computing, you can deliver computing resources across the Internet. Now customers can purchase both hardware and software resources as needed from cloud computing vendors. This includes servers, storage space, databases, networks, operating systems, and even individual applications.

The figure below demonstrates the three different methods for providing cloud computing services.

Figure: Cloud computing methods

As shown above, there are three primary methods for providing cloud computing environments:
 

Public: In public cloud computing environments, a third party provides all of the computing resources outside the organization. This pool of resources is usually shared between multiple organizations that also have access to the platform.
Private: In private cloud computing environments, each individual organization builds its own cloud computing resources to provide resources internally.
Hybrid: In hybrid cloud computing environments, computing resources are provided internally within the organization but also connected to an external public cloud to help supplement resources when needed.

What Are the Cloud Services?
Cloud computing environments can customize the level of resources provided to customers, depending on each customer's needs. The following sections describe the three most popular models for providing resource levels that you'll find from cloud computing vendors.

Infrastructure as a Service (IaaS)
In the infrastructure-as-a-service (IaaS) model, the cloud computing vendor provides low-level server resources to host applications for organizations.

These low-level resources include all of the physical components you'd need for a physical server, including CPU time, memory space, storage space, and network resources, as shown below:

Figure: The IaaS cloud model

The server resources provided may be on a single server, or they may be distributed among several servers. In a distributed environment, the servers may be co-located in a single facility, or they may be separated into multiple facilities located in separate cities. This helps provide for increased availability.

As shown above, in an IaaS model the customer supplies the operating system and any applications that it needs to run. Most IaaS environments support either the Linux or Windows operating system. The customer is responsible for any system administration work required for the operating system as well as any application administration. The cloud computing vendor takes responsibility for maintaining the physical infrastructure environment.

Platform as a Service (PaaS)
In the platform-as-a-service (PaaS) model, the cloud computing vendor provides the physical server environment as well as the operating system environment to the customer, as shown above.
With the PaaS model, the cloud computing vendor takes responsibility for the physical components as well as the operating system administration. It provides system administration support to ensure that the operating system is properly patched and updated to keep up with current releases and security features. This allows the customer to focus on developing the applications running within the PaaS environment.

Software as a Service (SaaS)
In the software-as-a-service (SaaS) model, the cloud computing vendor provides a complete application environment, such as a mail server, database server, or web server. The vendor provides the physical server environment, the operating system, and the application software necessary to perform the function. This is shown below:

Figure: The PaaS cloud model

Figure: The SaaS cloud model

Understanding Virtualization
The downside to cloud computing environments is that they're very computing intensive. A lot of computer power is required to run a cloud computing environment, and that can become costly.
The technology that made cloud computing possible is virtualization, and this is also what has made Linux a popular choice for cloud computing vendors. The following sections describe what virtualization is, the different types of virtualization available, and how to implement virtualization in a Linux environment.

Hypervisors
For organizations that run applications that support lots of clients, a standard performance model dictates that you should separate the different functions of an application onto separate servers, as shown below:

Figure: Separating application resources

As shown above, the web server, the application server, and the database server are located on separate servers. Customers only communicate with the front-end web server. The web server passes the connections to the application, which in turn communicates with the database server. From a performance standpoint, this model makes sense as you dedicate separate computing resources to each element. Also, from a security standpoint this helps compartmentalize access, making the job of any potential attackers a little more difficult.
However, with the increased capacity of servers, this model becomes somewhat inefficient. Dedicating an entire physical server to just running a web server, another physical server to just running the database server, and yet a third physical server to just running the application software doesn't utilize the full power of the servers and becomes costly.
This is where virtualization comes in. With virtualization, you can run multiple virtual smaller server environments on a single physical server.

The figure below demonstrates this concept.

Figure: Server virtualization concept

Each virtual server operates as a stand-alone server running on the physical server hardware. This is called a virtual machine (VM). None of the virtual servers interacts with each other, so they act just as if they were located on separate physical servers. However, there needs to be a way for each virtual server to share the physical resources on the server fairly so that they don't conflict with one another.

This is where the hypervisor comes into play. The hypervisor, also called a virtual machine monitor (VMM), acts as the traffic cop for the physical server resources shared between the virtual machines. It provides a virtual environment of CPU time, memory space, and storage space to each virtual machine running on the server. As far as each virtual machine is concerned, it has direct access to the server resources, and it has no idea that the hypervisor is in the middle controlling access to resources.

Since each virtual machine is a separate entity on the server, you can run different operating systems within the different virtual machines. This allows you to easily experiment with running applications in different operating systems, or just different versions of the same operating system—all without having to purchase additional servers.

Types of Hypervisors
There are two different methods for implementing hypervisors. The following sections discuss what they are and how they differ.

Type I Hypervisors
Type I hypervisors are commonly called bare-metal hypervisors. The hypervisor system runs directly on the server hardware, with no go-between. The hypervisor software interacts directly with the CPU, memory, and storage on the system, allocating them to each virtual machine as needed.

The figure below llustrates this setup.

Figure: Type I hypervisors

In the Linux world, two popular Type I hypervisor packages are used:
KVM: The Linux Kernel–based Virtual Machine (KVM) utilizes a standard Linux kernel along with a special hypervisor module, depending on the CPU used (Intel or AMD). Once installed, it can host any type of guest operating systems.
XEN: The XEN Project is an open source standard for hardware virtualization. Not only does it support Intel and AMD CPUs, but there's also a version for ARM CPUs. The XEN Project includes additional software besides the hypervisor software, such as an API stack for managing the hypervisor from a guest operating system.

Type II Hypervisors
Type II hypervisors are commonly called hosted hypervisors because they run on top of an existing operating system installation. The hypervisor software runs like any other application on the host operating system.

The figure below shows how a Type II hypervisor works.

Figure: Type II hypervisors

The Type II hypervisor software runs guest virtual machines as separate processes on the host operating system. The guest virtual machines support guest operating systems, which are completely separated from the host operating system. Thus, you can use a Linux host operating system and still run Windows or macOS guest operating systems.
The attraction of using a Type II hypervisor is that you can run it on an already installed operating system. You don't need to create a new server environment to run virtual machines. With the Type I hypervisors, you must dedicate a server to hosting virtual machines, whereas with a Type II hypervisor, your server can perform other functions while it hosts virtual machines.
There are many different popular Windows and macOS Type II hypervisors, such as VMware Workstation and QEMU, but for Linux the one commonly used is Oracle VirtualBox.

Hypervisor Templates
The virtual machines that you create to run in the hypervisor must be configured to determine the resources they need and how they interact with the hardware. You can save these configuration settings to template files so that you can easily duplicate a virtual machine environment either on the same hypervisor or on a separate hypervisor server.
The open source standard for virtual machine configurations is called the Open Virtualization Format (OVF). The OVF format creates a distribution package consisting of multiple files. The package uses a single XML configuration file to define the virtual machine hardware environment requirements. Along with that file are additional files that define the virtual machine requirements for network access, virtual drive requirements, and any operating system requirements.
The downside to OVF templates is that they are cumbersome to distribute. The solution to that is the Open Virtualization Appliance (OVA) format. The OVA template bundles all of the OVF files into a single tar archive file for easy distribution.

Exploring Containers
While utilizing virtual machines is a great way to spin up multiple servers in a server environment, they're still somewhat clunky for working with and distributing applications. There's no need to duplicate an entire operating system environment to distribute an application. The solution to this problem is containers. The following sections explore what containers are and how they are changing the way developers manage and distribute applications in the cloud environment.

What Are Containers?
Developing applications requires lots of files. The application runtime files are usually co-located in a single directory, but often additional library files are required for interfacing the application to databases, desktop management software, or built-in operating system functions. These files are usually located in various hard-to-find places scattered around the Linux virtual directory.
Because of all the ancillary files required to run an application, all too often an application will work just fine in development and then come crashing down when deployed to a production environment that doesn't accurately reproduce the development environment. In the Windows world, this is commonly referred to as DLL hell, as different applications overwrite common DLL library files, breaking other applications.

However, this isn't limited to the Windows world; it can also apply to the Linux world.
 

Containers are designed to solve this problem. A container gathers all of the files necessary to run an application—the runtime files, library files, database files, and any operating system–specific files. The container becomes self-sufficient for the application to run; everything the application needs is stored within the container.

If you run multiple applications on a server, you can install multiple containers. Each container is still a self-contained environment for each particular application, as shown below.

The application containers are portable. You can run the same container in any host environment and expect the same behavior for the application. This is ideal for application developers. The developer can develop the application container in one environment, copy it to a test environment, and then deploy the application container to a production environment, all without worrying about missing files.

Figure: Running an application in a container

By packaging and distributing an application as a container, the developer ensures that the application will work for customers the same way it worked in the development environment.
Since containers don't contain the entire operating system, they're more lightweight than a full virtual machine, making them easier to distribute. The following sections describe two of the most common container packaging systems used in Linux.

Note: “Embracing Best Security Practices” discussed the use of chroot jails as a method for separating applications running on a Linux system. The first containers utilized this same method to separate applications. Today's container packages use the chroot jail to separate applications but also incorporate advanced Linux features such as AppArmor and SELinux, kernel namespaces, control groups (cgroups), and additional kernel capabilities.

Container Software
Linux has been in the forefront of container development, making it a popular choice for developers.

Two main container packages are commonly used in Linux:
LXC: The LXC package was developed as an open source standard for creating containers. Each container in LXC is a little more involved than just a standard lightweight application container but not quite as heavy as a full virtual machine, placing it somewhere in the middle. LXC containers include their own bare-bones operating system that interfaces with the host system hardware directly, without requiring a host operating system to handle that part. Because the LXC containers contain their own mini–operating system, they are sometimes referred to as virtual machines, although that term isn't quite correct as the LXC containers still require a host operating system to operate.
Docker: The Docker package was developed by Docker Inc. and released as an open source project. Docker is extremely lightweight, allowing several containers to run on the same host Linux system. Docker uses a separate daemon that runs on the host Linux system that manages the Docker images installed. The daemon listens for requests from the individual containers as well as from a Docker command-line interface that allows you to control the container environments.

Container Templates
Just like virtual machines, containers allow you to create templates to easily duplicate container environments. The different types of Linux containers use different methods for distributing templates.
The LXC package uses a separate utility called LXD to manage containers. In recent versions, LXD has become so popular that it is now packaged itself as container software, although it still uses the LXC system images of the container.
Docker uses Docker container image files to store container configurations. The container image file is a read-only container image that can store and distribute application containers.

Working with Docker
The Docker container software package provides an easy platform to run OS containers in your Linux environment. However, because Docker shares the host OS kernel with the containers, you can only run Linux containers on a Linux Docker host.
You use the docker command-line tool to easily interact with the Docker system, starting, stopping, and interacting with containers.

The tablebelow shows the commands available for you to use with the docker command.
You can either build a new container image from a Docker configuration file or download a preconfigured container image directly from a container repository, where other admins have posted their containers. Docker itself maintains a container repository at http://hub.docker.com.

TABLE:  The docker utility commands

The following exercise walks you through the steps to install and use Docker on your Linux system to start hosting Linux containers.

EXERCISE: Working with Containers
Install the Docker software from your distribution's software repository (Read “Governing Software”). For Ubuntu, type the command sudo apt install docker. For Red Hat–based distributions, such as Rocky Linux, the command is sudo dnf install docker.

After installing the Docker software, you communicate with it by using the docker command. Check to make sure Docker is running by typing sudo docker ps at the command line:
$ sudo docker ps
Emulate Docker CLI using podman. Create /etc/containers/nodocker to quiet msg.
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES

The output shows that Docker is running and lists any containers that are currently running (currently none).

Retrieve the Docker customized container image for a generic Apache web server by typing the command sudo docker pull docker.io/library/httpd:latest. This causes Docker to query the Docker repository at http://hub.docker.com and retrieve the latest version of a customized Apache web server running on a generic Linux OS platform. If you need to use a specific version of Apache, you can specify it after the container image name, such as httpd:2.4.

Deploy the httpd container image to your Docker environment by typing sudo docker run -d -t -p 8088:80 --name myApache httpd. This command starts the container in background mode (the -d option), connects a terminal to the container (the -t option), exposes TCP 80 port on the container to port 8088 on the host (the -p option), and gives the container a simple name to use for the docker commands. It's important to remember that containers are self-contained, so to connect to a port on the container you must instruct Docker to expose the port to the host system.

When you run this command, Docker will display the ID assigned to the container.

Verify that the container is running by typing sudo docker ps.
$ sudo docker run -d -t -p 8088:80 --name myApache httpd
43ee094b028d7b3c9a168cf29284428b156624f8bfc3fcf5cbb5c644c56548cc
$ sudo docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
43ee094b028d docker.io/library/httpd:latest httpd-foreground 4 seconds ago Up 5 seconds ago 0.0.0.0:8088->80/tcp myApache

The output shows that indeed the httpd container is running and that it has exposed the TCP 80 port on the container to TCP port 8088 on the host system.
Connect to the Apache web server running in the container by opening the browser in your host Linux desktop and typing http://localhost:8088. You will see the generic “It works!” message produced by the Apache web server.
Open an interactive Bash shell in the running container by typing sudo docker exec -i -t myApache bash. This connects to the container named myApache as an interactive terminal (the -i and -t options) and runs the bash command-line command, producing a shell prompt.

You should see something like this:
$ sudo docker exec -it myApache bash
root@43ee094b028d:/usr/local/apache2#

The Bash shell command prompt indicates that you are logged into the container OS as the root user account and that it is in the /usr/local/apache2 directory. From there you can view and modify the Apache web server configuration files or create new web pages in the /usr/local/apache2/htdocs directory. To return to the host system command line, type exit.
root@43ee094b028d:/usr/local/apache2# exit
[rich@localhost ~]$

Stop the running container by typing sudo docker stop myApache. You can verify that the container has stopped by typing sudo docker ps.
Delete the container from your Docker system by typing sudo docker rm myApache.

If you don't want the httpd container image on your workstation anymore, type sudo docker rmi httpd.

Cloud computing provides an easy way to expand the computing resources for a company without having to purchase and administer your own hardware.

There are three levels of cloud computing that each provide different services. Infrastructure as a service (IaaS) provides hardware resources such as servers, storage, and network. Platform as a service (PaaS) provides development environments that consist of an operating system and any libraries required to develop, test, and deliver application software. Software as a service (SaaS)runs applications from the cloud servers across the Internet.

Cloud computing environments use virtualization to implement many servers without lots of physical hardware. With virtualization, one large server can host multiple smaller guest systems. The hypervisor software manages the resources allocated to each guest system and manages how those resources are used.

There are two types of hypervisor environments used.

Type I hypervisors interact directly with the system hardware. Guest systems receive system resources directly from the hypervisor software.

Type II hypervisors run on top of a host operating system. The host operating system interacts with the system hardware and provides resources to the Type II hypervisor, which in turn allocates the resources to the guest systems.

Containers are a different type of virtualization.

Containers provide a consistent runtime environment for a single application. When you deploy an application into a container, the application container is guaranteed to run the same way no matter what server it runs on. By deploying applications using containers, you're guaranteed the application will run the same way in the development, test, and production environments. Containers don't contain as much overhead as virtual machines, making them easier to distribute.

Important exam questions:

Describe the three primary methods of providing a cloud computing environment.
- Public clouds are hosted on servers owned and operated by a third party. The company doesn't own or operate any of the server hardware; it just utilizes space on those servers. Other companies can rent space in the same public cloud. Private clouds are hosted on servers located within the corporate network. All of the application files as well as data files reside within the corporate network. Hybrid clouds utilize private cloud servers but also interface them with public cloud servers. With the hybrid cloud, data could be located either externally in the public cloud or internally on the private cloud.

Explain the three types of cloud services.
- Infrastructure as a service (IaaS) provides hardware-level services to customers. This includes servers, storage space, and the network resources to connect them. Platform as a service (PaaS) provides on-demand environments for developing software. In the PaaS cloud service, the server hardware, operating system, and runtime libraries are all provided by the cloud service. Software as a service (SaaS) runs applications in the cloud environment, allowing customers to access those applications via the Internet.

Explain the two types of hypervisors.
- Type I hypervisors run directly on the system hardware. They act as a mediator between the hardware and the guest operating systems. Type I hypervisors allocate resources to each guest operating system, ensuring that each one gets enough. Type II hypervisors run on top of a host operating system. The host operating system interacts with the server hardware; the hypervisor software must go through the host operating system to access resources. Guest operating systems still only interact with the hypervisor software.

Describe how containers differ from virtual machines.
- Most container packages don't include a full operating system, but virtual machines do. Container packages only include the library files and application runtime files necessary to run a specific application. This makes the containers lightweight and easy to deploy.