Full exploration of Docker container Testing

Full exploration of Docker container Testing
GuideAfter building a Docker image and combining multiple containers into an application, we established a continuous delivery channel and learned how to incorporate the newly created image into the production or test environment, the new question comes-how do we test our own Docker container? There are various testing strategies, reflecting a variety of testing personalities: naive, lazy, worry-free, advanced idealistic, and perfectionist Virgo ...... So what type are you? Next we will analyze the advantages and disadvantages of their respective solutions one by one."Naive" SOLUTION

Most people use this as the default solution. It uses the CI server for task execution. In this solution, developers use Docker as the package manager, which is superior to jar/rpm/deb. The CI server compiles the application code and then performs tests (including units, services, and functions ). The build in Docker can be used to generate a new image. The generated image not only contains the "binary code" of the application, but also has the dependencies and configurations required for running.

However, to realize the portability of applications, we need to discard the portability capability of development and testing. In this case, we cannot re-establish the same development and testing environment outside of CI. To create such a new test environment, we need to set up test tools (correct versions and plug-ins), configure runtime and operating system settings, and obtain test scripts and test data of the same version.

To solve the above problems, we need to consider the following solutions.

Application & test container Solution

Now we try to create a single bundle, where the application "binary code" contains all necessary software packages and test tools (including the corresponding version) test Tool plug-ins, test scripts, and other test environment elements. However, this method also has significant drawbacks:
The image size increases linearly-this is because it contains test tools, necessary software packages, test scripts, and even test data.
The specific test configuration may cause pollution to the image runtime environment, or even introduce unnecessary dependencies (required for integration testing ).
We also need to consider how to process test results and record logs;

The following simplified Dockerfile describes how to export and where to export the solution.

FROM "":""WORKDIR ""# install packages required to run app and testsRUN apt-get update && apt-get install -y /" and " / # add app runtime and required packages" and " / # add testing tools and required packages&& rm -rf /var/lib/apt/lists/*# copy app filesCOPY app appCOPY run.sh run.sh# copy test scriptsCOPY tests tests# copy "main" test commandCOPY test.sh test.sh# ... EXPOSE, RUN, ADD ... for app and test environment# main app commandCMD [run.sh, ""]# it's not possible to have multiple CMD commands, but this is the "main" test command# CMD [/test.sh, ""]

There is no doubt that there should be better in-container testing solutions to choose from.

Test the sensor container Solution

Currently, Docker promises to Build an image, publish it to the registry, and Run it elsewhere using the simple operation "Build-> Ship-> Run. The correct and complete process of Test is Build-> Test-> Ship-> Run. Let's take a look at how the "test-friendly" syntax and extended Dockerfile can be created for Docker commands. In the ideal version, we should be able to see the guiding ideology that can be used for practice.

ONTEST [INSTRUCTION]

First, define a special ONTEST command, which is very similar to the existing ONBUILD command. The ONTEST command adds a trigger command to the image, which is automatically executed when the image is tested. Any build command can be registered as a trigger condition.

The ONTEST command can be identified by a new docker test command.

docker test [OPTIONS] IMAGE [COMMAND] [ARG...]

In fact, the syntax of the docker test command is very similar to that of the docker run Command. docker test will automatically generate a new "testable" image and execute all build operations, after the ONTEST command, define and execute ontest cmd (or ontest entrypoint ). If an error occurs during the test, the docker test command should return a piece of non-zero code. The test results should be written to the VOLUME automatically generated and directed to the/var/tests/results folder.

The modified Dockerfile contains the new ONTEST command.

FROM "":""WORKDIR ""# install packages required to run appRUN apt-get update && apt-get install -y /" and " / # add app runtime and required packages&& rm -rf /var/lib/apt/lists/*# install packages required to run testsONTEST RUN apt-get update && apt-get install -y /" and " / # add testing tools and required packages&& rm -rf /var/lib/apt/lists/*# copy app filesCOPY app appCOPY run.sh run.sh# copy test scriptsONTEST COPY tests tests# copy "main" test commandONTEST COPY test.sh test.sh# auto-generated volume for test results# ONTEST VOLUME "/var/tests/results"# ... EXPOSE, RUN, ADD ... for app and test environment# main app commandCMD [run.sh, ""]# main test commandONTEST CMD [/test.sh, ""]

How to Implement "test awareness container"

Docker has a very practical command like ONBUILD. This command allows us to trigger another build command on a successful build. The basic idea is to use the ONBUILD command while running the docker-test command.

Run the docker-test command as follows:

Docker-test searches for the ONBUILD command in the application Dockerfile and uses the initial Dockerfile to generate a temporary Dockerfile. test, and then run docker build-f Dockerfile. test [OPTIONS] PATH, which contains other OPTIONS supported by the docker build command:-test is automatically added to the tag option.
If the build is successful, run docker run-v. /tests/results:/var/tests/results [OPTIONS] IMAGE: TAG-test [COMMAND] [ARG...] remove Dockerfile. test File
So why not create a Dockerfile. test file that does not need to be used with the ONBUILD command?

This is because, in order to test the correct image (and tag), we need to ensure that FROM is always in the image of the test target: tag, but the solution mentioned above is still limited-it is not applicable to the "onbuild" image (that is, the image used to automatically build the application), such as Maven: onbuild.

Next we will look at a simple docker-test command implementation process. It emphasizes an important concept: the docker-test command should be able to process build and run Command Options and properly handle error conditions.

#!/bin/bashimage="app"tag="latest"echo "FROM ${image}:${tag}" > Dockerfile.test &&docker build -t "${image}:${tag}-test" -f Dockerfile.test . &&docker run -it --rm -v $(pwd)/tests/results:/var/tests/results "${image}:${tag}-test" &&rm Dockerfile.test

Let's focus on the most important part of attention.

Integrated test container Solution

Suppose we have an automated CI/CD channel. My applications are built by dozens or even hundreds of microservices, and each microservice is built and tested by CI, and then deployed to a certain environment (such as testing, segmentation or production environment ). Our CI tests various microservices separately-run unit and service tests (or API contract tests ). It is even possible to perform a micro-integration test-to run the test on a special subsystem, but this will bring about some new problems:

How can I complete the actual integration test or long-term running test (such as performance and stress test )? How can I implement an elastic test (for example, a 'chaotic monkey 'test )? How to implement security scanning? How do tests and scans that take a long time and run on the entire operating system be completed?

A special type of integration test container should exist. These containers will only contain test tools and test elements: test scripts, test data, test environment configuration, and so on. To simplify the arrangement and automation of such containers, we should define and follow certain conventions and use metadata labels (label commands in Dockerfile ).

Integration Test tag

Test. type-test type, which defines integration. It can belong to integration, performance, security, chaos, or any other text. This label indicates that it belongs to a set of integration test containers.

Test. results-VOLUME used to store test results. The default location is/var/tests/results.

Test. XXX-any other related metadata, using only the test. Extension name as the Tag Name

Integrated test container

An integrated test container is a conventional Docker container that does not contain any application logic and code. Its only purpose is to create a reusable and portable test process. We recommend that you include the following content in the integrated test container:

Test Tools-Phantom. js, Selenium, Chakram, Gatling ,... Test Tool runtime-Node. js, JVM, Python, Ruby ,... Test Management Configuration-environment variables, configuration files, boot scripts ,... Test-existing test data as compiled software packages or script files-any data file types used for testing: json, csv, txt, xml ,... Test start script-some "main" Start scripts used to run the test are only responsible for creating test. sh and starting the test tool.

The Integrated Test containers should run in an operating environment where all microservices are deployed. These containers can be deployed in the same way as other services. In the actual integration test, we must access multiple services to test whether the services can run normally in different environments. Incorporating integration testing into Application Service containers not only increases the container size, but also creates unnecessary dependencies between services. Therefore, we limit all dependencies to the integration test container.

From: https://linux.cn/article-7689-1.html

Address: http://linuxprobe.com/docker-test-probe.html