New release includes a ‘Dockerfile lock’ feature and inclusion of Scancode data in default reports
Tern is a VMware-originated open source container inspection tool. Since Tern’s last release, new features and command line options have been added as a part of Tern 2.0.0, which is now generally available from PyPI. You can also clone the latest changes from GitHub.
One of the most anticipated features in this release is the addition of a new capability we call “Dockerfile lock”. The Dockerfile lock feature is designed to help users create more reproducible Docker images from their Dockerfiles. Why is this necessary? Dockerfiles are used to automate the assembly and creation of Docker container images. While useful, Dockerfiles are not inherently reproducible the way one might think. This is because Dockerfiles are not declarative of what ultimately gets included in the end product container.
Take for example the case where you want to build a container on top of a Debian base image. To do this, you might include this line in your Dockerfile:
FROM debian:latest. While this FROM line will indeed build a container image based on the latest debian base OS tag, there is no guarantee that the
latest base OS will remain the same in the future. The
debian:latest base OS with digest abc in January might become
debian:latest base OS with digest xyz a few months later. When the base digest changes, it is likely because packages (and their respective versions) which make up the base image have changed. This means that if you were to build a container image in January from your Dockerfile and then build a container image from the same Dockerfile a few months later, the contents of your container would likely be different. This is especially true if you install packages for your container in subsequent lines of your Dockerfile.
Dockerfiles present unique challenges for building reproducible container images. Tern’s new Dockerfile lock feature addresses some of these issues. When provided a Dockerfile, Tern creates a locked Dockerfile in which the base image is pinned to a digest and the packages installed for each subsequent layer are pinned to their versions, if they are known. Tern will also expand
ENV variables and try to find information about git repositories that may be
ADDed within the Dockerfile provided. An example of what can be expected is below.
For more information about this feature, check out Tern’s README on GitHub.
The second headlining feature included in Tern’s 2.0.0 release is the ability to map Scancode’s data into Tern’s data model. Scancode-toolkit is a license scanning tool that finds licenses in source code and binaries. This new feature allows file level licenses found in Scancode’s data collection to be reported in Tern’s default report format when running with the
--extend CLI option. Ultimately, this makes it easier to read and consume Scancode output information. This change builds upon the functionality added as a part of Tern’s 1.0.0 release to extend the use other filesystem analysis tools. For more information about how to utilize Tern and Scancode together, see the Scancode documentation on Tern’s GitHub page.
Other notable additions to this release include:
- Remove the
-l, --loggingCLI option and make logging the default behavior.
- Allow user to set the working directory on the command line.
- Expand test coverage.
- Enable tox to run unit tests.
- Use dockerfile-parse to parse Dockerfiles instead of manual parsing.
- Update documentation.
For a more detailed summary of bugfixes and enhancements, see the Release Notes.
While we are excited about the new features Tern has to offer, Tern is still in alpha development mode as a project. If you experience any issues while experimenting with or using Tern, please don’t hesitate to open a bug. If you have any other questions or would like to get in contact with the maintainers, you can reach out to email@example.com.
Future work for Tern is focused on adding support for language package managers and adding support for multistage Docker builds. On an administrative note, Tern will move GitHub organizations from VMware to its own organization, tern-tools under the ACT umbrella org. This move coincides with the Linux Foundation’s announcement that founding member commitments had been made for the Automated Compliance Tooling (ACT) workgroup, of which Tern belongs.
We would like to thank the six community contributors that helped with the delivery of this release, five of them first time contributors. This speaks to Tern’s organic growth as a project and developer community.