Search form

Using Lumogon to inspect your containers

Breadcrumb

In a post last week, we introduced Lumogon, a tool for inspecting, reporting on, and analyzing your containers. We wanted to provide more examples of it being used to solve real problems, as well as ways you can build on Lumogon to solve even more problems.

To recap, running Lumogon against a specific container outputs information about the contents and metadata of that container.

That much data is more useful to machines than people however, so let’s use this low-level tool to answer some specific questions. It would be possible in the future to build a higher-level, more problem-focused user interface to Lumogon data, but for the moment we’ll show examples using the excellent JQ.

Looking at a containers labels

Let’s look at a simple example to begin with. Let’s view the labels for a specific container:

That’s not hugely interesting; you could do the same with docker inspect -f "{{json .Config.Labels }}". So let’s do something more interesting that’s not available from the native tools.

A handy alias

Packaging up Lumogon as a Docker container has a number of advantages, but the verbose command to run the above examples can get old quickly. Luckily you can just create an alias in your shell of choice to skip that.

The above means you can just run all of the examples in this post with lumogon rather than the full incantation. We’ll use this for the next set of example. We may release native packages for Lumogon at a later date.

Listing packages installed in a container

Many containers are using Linux distributions as the user space for their containers, which means they include a list of packages and their specific versions. Lumogon collects that information (currently from the dpkg, RPM and apk package managers) and makes it available to us. For instance:

Here we start to see some of the value of Lumogon — it’s a single tool that can query information about your container from the outside (like labels that come from the Docker API) and the inside (like installed packages or the user space operating system details), without knowing anything beforehand about the container in question.

One more example before we move on. Let’s grab the version of bash installed in this specific container:

Information about more than one container

All the examples so far have shown us how Lumogon gathers data about individual containers. Let’s expand that and collect information from all of the containers running on this host. To make this more interesting, we’ll then filter that information, and produce a list showing the container names and the version of bash installed via either RPM or dpkg.

Note that this is much more powerful than simply relying on the parent image for this information. We’re inspecting the file system itself, rather than relying on usefully named images.

Consider this: How you would do that without Lumogon? Invariably, It’s a multi-step process which requires intimate implementation knowledge. With Lumogon, we want to set that information free, so we can build tools to quickly to answer questions and solve real user problems.

What about images?

The current tooling focuses on scanning containers, but you may want to scan an image instead. This would make a nice extension to Lumogon, but in the meantime it’s a useful example of how easy it is to build slightly higher-level tools on top of the existing implementation. Here’s an image-scanning tool in just a few lines of bash.

Save this as scan-image.sh and make it executable. This will allow you to run the following and to produce output for the contents of the image.

./scan-image.sh ocaml/opam

Testing

Given the ability to generate a data structure from a container or image, a handy use case for Lumogon is introducing tests to the image build process, or building a constant-compliance test suite for production monitoring purposes. The following is more a demonstration of how simple this is when building on top of Lumogon, rather than a full example. Depending on user feedback, and the interest in the open source community, this would be a great area to explore and expand upon.

Using less than 20 lines of Python, we can create a framework to write tests like the one that follows. Because Lumogon uses data as a first-class interface, it’s simple to imagine writing similar tests in other languages or testing frameworks, too.

These tests could be used in a CI pipeline to verify that metadata was being set correctly, or that certain packages were installed, or that known-vulnerable packages (across multiple different package managers or operating systems) were not present, or that all images were using the corporate-standard operating system.

Next steps

The above presents just some of what’s possible today with Lumogon. As more capabilities are added, we’ll be able to expose even more data. And more data means more interesting user interfaces and the potential for other higher-level tools like testing. Please let us know any ideas you might have in the comments below, and on the dedicated Slack channel. And if you fancy jumping in and trying to implement something, please head over to the Lumogon GitHub repository.