Visualizing DockerCompose

Continuing on my story line of documenting with code, I have found a neat way to visualize docker-compose files.

Using this docker-compose file…

I generate this image

The red dashed line indicates a dependency mapping. In this case, the grafana and chronograf services are depending on the influxdb service.

This is the code base.

krogebry/awsmap

But why?

Isn’t docker-compose mainly designed for developing applications? Shouldn’t we be using something like kube in production?

Absolutely. However, there is a use case where this can be handy. The use case is basically around IoT devices. In this case, heavy IoT where we have a ton of data flowing through multiple services on a single piece of hardware.

What I want to do is allow my developers 3 things:

1. Develop things on their local machines with all of the components available.
2. Emulate the operating environment in the cloud on a single EC2 host.
3. Push the manifest to a single hardware appliance using an ISO.

Docker-compose is an easy fit for item #1, but #2 and #3 are going to be built with packer. #2 uses the amazon-ebs builder, and #3 uses the virtualbox-iso builder, both use roughly the same shell scripts to provision the OS.

The AMI is tied together with some Terraform to create an ASG and some basic IAM/SecurityGroups which allow developers to create workspaces for testing. We can also expand on this idea for CI/CD things.

CI/CD

Once we have the ground work laid out for this, we can start putting the builders together. At the very end of the packer run for either of the build profiles, we run docker-compose to pull the images down to the image:

docker-compose start

When the ISO or AMI is spun up, it should automatically start the various required docker containers, giving us our operating platform.

Along with building the ISO’s, I’m thinking about having the pipeline automatically generate the image of the layout, giving us all of the visual data for a given build.

That gives us a visual graph for a given deployment:

• Ports
• Dependancies
• Services
• Volumes
• Networks ( eventually :) )