base image . This means that you can take the functions of one application delivered as an image and build new functions on top of that image . Thus , you need to understand how to maintain the dependencies upon the derived image as well as the new functionality .
The assumption should be that you ’ re rarely starting an application from scratch , and those charged with container development are looking more and more at using OPC ( other people ’ s code ), which is much more productive . However , it does bring up challenges with the lifecycle of the container , considering that you ’ re not tracking many dependencies .
It ’ s a pretty clear problem that must be solved . If there is a step where developers find and leverage prebuilt container images , you need to figure out where you ’ re going to store them and from where you ’ re going to access them to simplify the job of tracking them .
You can leverage a private repository to store a copy of the base image you ’ re leveraging , as well as your extensions to the image . The advantage is that you retain an original copy of the image on which your customized version of that image is based . Moreover , you store the customized image back to the same private repository .
However , while this protects you from changes to the public image that you now depend upon — changes that could break your container-based application — you won ’ t enjoy the benefits of upgrades and bug fixes to the original image .
The answer is to use a container-aware configuration management system . While it is possible to adapt traditional tools to container image management , there are limitations . For now , the best practice is to work with your current configuration management provider to understand how existing toolsets can be best used to manage container-based applications . But in the next year or so , be prepared to look outside of your existing DevOps tools vendor pool for better tooling .
Container Testing
There are many approaches to testing containers . It ’ s important to remember , though , that automation of container testing is key , no matter what approach you leverage .
With containers , you can place test automation inside or outside . You ’ ll want to look for repeatable test environments , where you can run the same test using the same automated testing tools . This means that the testing is part of the continuous integration tooling , staging tooling , and deployment tooling . In this way , testing will be systemic , from the point a developer is ready to test to the time it goes into production .
With the inside-the-container approach to testing containers , the testing tools are a part of the image . Thus , they are automatically configured .
46 | THE DOPPLER | FALL 2017