Daniel de Repentigny and James Ma co-wrote this post.
A path to production is a way of codifying an application’s value stream map as it makes its way from a developer’s workstation to a production environment.
Although Kubernetes has a rich ecosystem of APIs and tools to do the work, managing the communication paths between these components can still be a big pain.
This is why we’ve created and open-sourced Cartographer, a tightly scoped tool that can choreograph events within the Kubernetes ecosystem. Instead of building an entirely new platform to hide this complexity and offer convenience, we are building on top of Kubernetes primitives to enable automation and encourage composability. You’ll find Cartographer on GitHub.
What is Cartographer?
Cartographer allows users to configure Kubernetes resources into reusable supply chains that can be used to define all of the stages that an Application Workload must go through to get to an environment. We call these stages the path to production.
Cartographer separates controls between two users—one who is responsible for defining a supply chain and who is known as an App Operator, and the application creator, called the Developer. These roles are not necessarily mutually exclusive, but they provide the ability to create separation concerns, which means developers can focus on writing code, and platform teams can focus on smoothing and securing their path to production.
To learn more, see these resources:
How does it work?
Cartographer allows users to define all of the steps that an application must go through to create an image and Kubernetes configuration. Users achieve this with the Supply Chain abstraction (spec reference).
The supply chain consists of components that are specified via templates. Each template acts as a wrapper for existing Kubernetes resources and allows them to be used with Cartographer. Cartographer supply chain templates include:
Source Template (spec reference)
Image Template (spec reference)
Config Template (spec reference)
Generic Template (spec reference)
Unlike many other existing Kubernetes-native workflow tools, Cartographer does not “run” any of the objects themselves. Instead, it monitors the execution of each component and templates the following component in the supply chain after a given component has completed execution and updated its status.
The supply chain may also be extended to include integrations to existing CI/CD pipelines by using the Pipeline Service (which is part of Cartographer Core). The Pipeline Service acts as a wrapper for existing CI and CD tooling (with support for Tekton, and with plans to support more providers in the future) and provides a declarative way for pipelines to be run inside of Cartographer.
While the supply chain is operator facing, Cartographer also provides an abstraction for developers called workloads (spec reference). Workloads allow developers to create application specifications, such as the location of their repository, environment variables, and service claims.
By design, supply chains can be reused by many workloads. This allows an operator to specify the steps in the path to production a single time, and for developers to specify their applications independently but for each to use the same path to production. The intent is that developers are able to focus on providing value for their users and can reach production quickly and easily, while providing peace of mind for app operators, who are ensured that each application has passed through the steps of the path to production that they’ve defined.
It’s only just begun
The team here is excited to share Cartographer with the community! We’re looking forward to having you try it out, use it, provide feedback, and to get involved if you’re interested. Whether it’s by automating the turning of source code into a running app, or integrating security scans into every application that’s deployed onto your platform, our hope is to help make Kubernetes app development and operations an absolute breeze. Get involved.
We want Cartographer to be a project that embraces input from the community as it begins to find its place within the Kubernetes ecosystem. From code contributions and documentation to sharing your usage in the field, there are many ways to get involved.