integration of compose-like container groups

[brainchild0]

Although only recently having entered the containers space, I have come to understand the importance of Container Structure Test.

Docker and other developers of container infrastructure emphasize the value of building custom containers for testing general software, even software not generally targeted for containers, but few emphasize the importance of validating a container image before publishing it to external consumers.

The Docker interface is not natively friendly to the workflow of reusing an image for repeated cycles of container creation and destruction, and therefore, management of these processes is an important source of value from this project.

Automation in container testing seems to entail two critical aspects. One, as just explained, is management of the life cycle of a container and automatic processes occurring within the lifetime. The other is management of groups of containers, of heterogeneous source images, related to each other by sharing of otherwise isolated resources, such as network connectivity. Docker Compose seeks to achieve the latter objective.

In the case of robust container testing, I have come to understand, the needed for both of these automation features being integrated into a single, cogent workflow.

To make possible a truly robust test suite, a framework should allow a test suite to include specifications of any number of systems of heterogeneous containers, each such system being created and destroyed any number of times, under various specific constraints or performing various specific tasks, That is, a test suite in general should encapsulate multiple Compose-like definitions, and should handle the entire life cycle of all components from each definition.

It suggest it would be quite worthwhile for Container Structure Tests to move in such an ambitious direction.