Scribd
Upload
70 views

Testing Containers With Docker

This document provides an overview of containers and best practices for using containers for testing. It discusses what containers are, how they differ from virtual machines, and basic Docker terminology. It then demonstrates how to build a sample Nginx container using a Dockerfile and run the container. The document outlines steps for building a QA testing container image including necessary components like Ruby, gems, Selenium, and a browser. It also discusses running test suites within containers and potential approaches to running and reporting tests via a CLI tool within a containerized environment.

Uploaded by

Schuyler Ankele
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
70 views

Testing Containers With Docker

This document provides an overview of containers and best practices for using containers for testing. It discusses what containers are, how they differ from virtual machines, and basic Docker terminology. It then demonstrates how to build a sample Nginx container using a Dockerfile and run the container. The document outlines steps for building a QA testing container image including necessary components like Ruby, gems, Selenium, and a browser. It also discusses running test suites within containers and potential approaches to running and reporting tests via a CLI tool within a containerized environment.

Uploaded by

Schuyler Ankele
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 14

Testing Containers

with

Develop once, deploy anywhere


What are containers?
Containers are nothing new. In fact, the idea has been around
since the 1970’s. Unix v7 had the concept of a reassigned root
process with had its own child processes.

What containers are not:

… A virtual machine

Containers are intended to run processes in their most


isolated form sharing resources with a host machine.
Best Practices for Architecture with Containers
The KISS principle still applies,
but means Keep It Small Silly

Example: When building the first iteration of our base testing image the file size was 1.7GB, which is huge by
Docker standards. Selenium’s own testing image ships at 1.3 GB.

Alpine Linux is kind of the standard for building a container from scratch and it ships at just under 50MB.

Planning a build image is also known as


Checklist for the a QA Testing Container Image
containerizing an application.
● Ruby
● All the Gems the GTAF requires
● Selenium WebDriver
● And……. Oh yeah Chrome or Firefox
● That’s it right?
Basic Terminology in Docker
● Image - Is a container’s parent like Ubuntu, CentOS, Alpine Linux or Windows
● Base Image - Means that it is a minimal version to build an application environment on
○ Ex: ruby:2.6.1-alpine3.9 is Ruby’s official image running on Alpine Linux
● Tag - Is the version of the image. In most cases you can use ‘latest’ to get the most recent version
● Container - A built version of an image. Containers have persistent data until they are removed
● Host Machine - The computer that Docker is running on and shares resources with
● Entry Point - The default application that loads when logging into a container
○ Ex - Bash (In our usage it could be the Test Automation Framework itself)
● Port - An exposed port to the host machine
● Link - Is a virtual network between containers
● Image Registry - Is like a Git Repository for Docker images
○ Docker Hub is the official registry for Images
● Run - The command to execute applications inside of a container
● Dockerfile - A plain text file used to build images
○ Running docker build . will automatically assume the file is called Dockerfile
Let’s build some containers!
Prerequisite: Install Docker for MacOS, Linux or Windows

Let’s build a container with NGINX that hosts web page


Build command:
docker build -t some-content-nginx .
Run command:
docker run --name some-nginx -d -p 8080:80 some-content-nginx

Well that was easy right?


See if the container is still running:
docker ps - will show all running containers on a host
docker container ls -a - will show all containers running or not

Let’s remove that container we just built:


docker stop some-nginx - will stop the container
docker rm some-nginx - will remover the container

That’s cool and all, but what happened?


Command Breakdown - Image Build
Commands continued… - Container Build/Run
Looking at the Dockerfile contents
From the prebuilt image ‘nginx’ use latest.
Then , copy all the contents from the host into
‘/usr/share/nginx/html’

FROM debian:stable
RUN apt-get update && apt-get install -y --force-yes apache2
EXPOSE 80 443
VOLUME ["/var/www", "/var/log/apache2", "/etc/apache2"]
ENTRYPOINT ["/usr/sbin/apache2ctl", "-D", "FOREGROUND"]
What does the average Dockerfile look like?
Command to build our Docker Image
docker build -f /path/to/Dockerfile -t registry_name/image_name:version1.0.0 .

● You’ll notice that we are taking advantage of using the -f flag. This allows you to
specify a filename.

● The reason we need to do this is because Docker will only allow permissions to
copy files from the directory that the build is executed from.

● Because we need to copy in all of the Honda GTAF repositories we need to


execute this command from the parent folder of the test_automation repo.

● Something else you might notice is that we’re using the image registry
‘vidopsrig_registry’. This is a placeholder for now. We will need to consult with
Jeff Sutherland to determine whether or not we should post the image in the
group registry.

● For now, we can skip this step because we will be building new images frequently
until all development of automation is complete.
Running the container
● By default the image is currently set up to login to the Bash shell.

● Once you’re in the shell you can run commands like


rake ci:execute_all[/path/to/confg.xml]

● All of the test automation repo files are copied into the /home folder

● Moving forward I would use our command line tool so that is executes on startup.

● There is potential to have a container for each test suite that executes once you spin up
the container.

● Another consideration is reporting. Currently I have no way to consolidate the reports


from test execution.
Running a test suite: Step by step
Based on the previous steps

1. Run the container with


docker run -it --rm vidopsrig_registry/test_automation_image:version1.0.0

2. Navigate to the /home/test_automation/GTAF/Ruby-SelTestFw


3. Run the command to start the suite, like:
rake ci:execute_all[/home/dai_metrics/GTAF/Ruby-SelTestFw/conf/Auto.xml]

4. We’re running a headless container, yay!


5. When you exit the container it will be destroyed with CTRL+D
Conversely, you can leave a container running and exit with CTRL+P+Q
Running the CLI Tool
The preliminary tool is based on NodeJS
Caveat: You must have NodeJS installed to run the tool

To run the tool go to the cli_tool folder in test_automation/GTAF/Ruby-SelTestFW

Run: npm start

Paths to rake config files are inside testingSuiteIndex.js in JSON format


Resources

● Learn Docker Online


● Katacoda
● Docker’s Official Educational Material
● Play with Docker

You might also like