This is a guest posting by Michael Solomon PhD CISSP PMP CISM
Virtualized container use in software application development and deployment is increasing across nearly all industry verticals. Containers provide advantages of virtualization without draining computing resources. When used in the testing process, containers can be helpful — or they can be a breeding ground for obstacles.
Let’s learn about the advantages and some of the pitfalls of using containers to test your software and computing components.
for QA and Development Teams
How Containers Work
In simple terms, a container is a lightweight virtual machine (VM). But while a VM is a complete self-contained copy of an operating system, a container only includes resources that need to be isolated, and it shares the rest with the full operating system. Resources that a container shares with the operating system running on your computer include the kernel and many binaries and libraries. Sharing items that don’t need to be local and writable greatly reduces the resource requirements of each container.
One way to use containers is to use a popular container platform, such as Docker or rkt (pronounced “rocket”), to launch containers based on the operating system your computer runs. You can have multiple containers running simultaneously. And since containers share many parts of the underlying operating system, you can almost always run more containers on a computer than you could VMs.
You aren’t limited to just the operating system your computer runs. You can run containers that use any one of many different operating systems that you aren’t running on your computer. Each container needs a base operating system, so you can normally run a VM with a complete copy of the desired operating system, such as a specific Linux distribution, and then launch multiple containers that use the Linux VM as their base. As with native operating system sharing, the containers share many of the resources of the base VM.
The small footprint of containers means that you can create and launch multiple images simultaneously. You also can afford to store multiple container images without eating up as much disk space as VMs — most containers are megabytes in size, while VMs are often gigabytes in size. That much smaller size means you can create, store and transfer containers easier and faster than traditional VMs.
Containers make it easy to create an image of a running operating system, a VM or another container. You can generally create a new container in under a minute. This easy and fast creation means you can take a snapshot of a system and then run that container on another computer. That’s like copying a computer and then running it somewhere else.
Testing with Containers
Containers can provide great opportunities to address software testing challenges. In many cases, software development organizations maintain separate development, testing and production servers. That strategy provides separation and autonomy for each function, but it can lead to growing differences among environments. Any data or configuration changes in one environment increase the gaps between others. Unless you aggressively duplicate all changes to other environments, your development, testing and production systems become increasingly unlike one another.
Containers provide the ability to create copies of running environments and then run those environments on other computers. For instance, you could create a container of production and then run it on your own laptop. As a software tester, that can provide a way to test software using production data and configuration. By reducing the differences between a simulated test environment and what users are interacting with in production, you can carry out more realistic functional tests.
Whether you create containers from currently running systems or from carefully configured base images, you can run tests in controlled environments that are easy to reset to a known state. If you want to run a suite of tests again, or even terminate tests and start over, you don’t have to rebuild containers and their configurations from scratch; you just throw one away and spin up another one. You can quickly stop the current container and create another container from a base image or running system. In very short order, you’re up and running with a fresh image.
The ease of creating and spinning up containers, as well as the ability to run containers on other computers, makes container-based testing more agile and responsive than using traditional separate computers. While some may argue that you can achieve similar results with VMs, it comes at a higher performance and storage cost. Containers are small and fast, and they make switching among various images quick and easy.
Some development organizations use containers in the entire software development lifecycle. Instead of just using containers for testing, you can develop application components to run in purpose-built containers. Application component containers only need to support a specific subset of an application to provide a small number of services. These containers make it even easier to spin up a specific container to test, and then deploy a part of a complete application. In such environments, a full application is a collection of containers that work together to provide a range of application services.
Join 34,000 subscribers and receive carefully researched and popular article on software testing and QA. Top resources on becoming a better tester, learning new tools and building a team.
Leveraging Containers in Software Testing
It may seem that the benefits of quickly making a copy of a production system for container-based testing are too good to pass up. After all, you’ll be testing new software using the latest data and configuration — that seems to be the best way to ensure that your tests are as close to reality as possible. But while there are many benefits, there are also some potential obstacles to relying on containers for exhaustive software testing.
In many cases, the underlying operating system and hardware differ from the true production environment. While it is true that the container will accurately mirror the configuration at the time you created the container from the live system, there still will likely be differences. One of the biggest differences is in physical hardware. If your testers carry out tests on their laptops, the performance will be different from the same software running on a server configured for hundreds of users. Even if you’re only carrying out functional testing, performance can affect all aspects of how software works. Testing on slower hardware still impacts your results, even in container environments.
Another obstacle to universal container-based testing is its impact on data security. Copying a running production system is convenient, but it can be risky. Many standards and regulations, such as PCI DSS and GDPR, place restrictions on how you can use production data. It is desirable to test software with real data, but copying that data to a test platform could move it to a less secure environment. For instance, if you test application software on a laptop, would copying a container that contains production data to that laptop violate any regulation? That is a question you’ll need to answer before moving containers around.
In most cases, testing platforms aren’t as secure as production environments. There are many reasons for this, but most reasons boil down to money. Production systems are often exposed to users and perhaps even the Internet. Those systems have security controls in place to protect them, but implementing, maintaining and periodically assessing security controls requires effort and costs money. Traditional testing servers often reside on internal servers. Their distance from the organization’s perimeter usually means that they have fewer security controls.
But what about testers who use their own laptops for testing? Containers make it easy to spin up a production environment copy on a laptop. If the laptop always stays physically and logically inside the organization, that may be OK. However, having potentially private customer data on a laptop in a coffee shop probably isn’t OK at all. Security controls are generally built around primary data and application locations. If you move that data or those programs, as you will when creating container copies, you have to take security into consideration.
Containers open lots of new possibilities for testing and deploying software. But each possibility has a cost associated with it. Still, in spite of the potential obstacles, containers are more of a friend to testing than an enemy to be feared.
Article written by Michael Solomon PhD CISSP PMP CISM, Professor of Information Systems Security and Information Technology at University of the Cumberlands.
Cross-Technology | Cross-Device | Cross-Platform
