Announcing Lumogon

Breadcrumb

Editor's note: The Lumogon open source project is now unmaintained. The technology is part of Puppet Discovery, which lets you discover what's running in your hybrid infrastructure — from servers to VMs, cloud instances and containers.

Today I’m happy to announce the availability of Lumogon™, a tool for inspecting, reporting on, and analyzing what makes up your running containers. Lumogon generates reports that can be shared with others so everyone is operating on the same insights, including people involved in peer review processes and continuous delivery pipelines.

In the long run, we aim for Lumogon to become a standard way to report on container application metadata, from the operating system used to any system dependencies. The report information can be extended to support any information about applications, such as the commit and repository location for deployed application code.

The operational developer

It’s worth taking a moment to talk about the new operational responsibilities developers have been taking on. Developers are becoming increasingly responsible for deployment and ongoing operation of their applications, partly as a result of the new deployment models afforded by containers and schedulers.

The new wave of operational tooling empowers application developers with operational insights that were once solely the realm of IT operators. This trend isn’t going to slow any time soon.

At the same time, operations teams are facing some old challenges in these new technologies. Questions of security, compliance, audits, status accounting, and more haven’t gone away — but accessibility of the answers has. Increasingly, operators are adopting practices and methodologies that were once solely the realm of developers, which you can see in the trend towards modern software release engineering models of operation. Operations teams are moving to support the new deployment models by building processes and tooling that development teams need to build and operate their own applications.

Managing black boxes

Containers are essentially black boxes. That’s a benefit from an operational standpoint. Container runtimes and schedulers need to know only the inputs and outputs for a given container, along with its resource requirements. With that information, they can operate the container at any scale, without needing to know how the container works.

However, imagine you wanted to query the state of something inside a container — for example, the version of the SSL library installed, or the operating system or version. To do that, you would need a shell installed in the container, plus knowledge of the container runtime and the command that will get at the information. You'd also need to know which operating system is in the container — a piece of knowledge that is inside the black box.

This problem extends well beyond needing an inventory of the container's contents. Right now, there is an explosion in the number of tools used to manage the container ecosystem. All these other management or monitoring systems would benefit from information within the running container. But at this moment, there's no unified and discoverable interface available to access that information.

The scale problem

At scale, we run into a superset of these problems. The movement from physical servers to virtual machines increases the number of things to manage by a factor of 10. The introduction of containers in production again dramatically increases the number of things to manage. Now you need new tools to manage this large volume of short-lived containers.

If you're going to manage containers effectively in a production environment, you need to be able to answer some important questions. For example: How many of my images or containers have a particular Docker label? Which ones have AppArmor enabled? How many old versions of OpenSSL are deployed?

Today, all of this information is scattered in a variety of places (e.g., Dockerfile, CI/CD jobs, UATs, source control). You can't see any of this information in aggregate.

Lumogon

Lumogon aims to solve these problems. You run Lumogon on a host and attach it to the Docker runtime. It then inspects each running container’s namespace, collecting metadata for running containers and images, including installed packages, host information, labels and more. Over time, the range of metadata that Lumogon collects will be extended.

Because Lumogon inspects running containers by attaching to the Docker runtime, you can start using it without having to change the way you build and deploy containers today. You simply run it and learn. You can also have the Lumogon web service compile a formatted, shareable report.

Get it

We created Lumogon to help developers get the insights they need to operate container applications at scale. We're looking forward to hearing your feedback. Get started today, and please join us in the Slack channel. We're listening!

Kenaz Kwa is a senior product manager at Puppet.

Learn more

Get the insight you need to start managing your containerized applications at scale. Go to lumogon.com and get started today.