carbon

Carbon is a package manager for Kubernetes. It allows to operate with your application along with Kubernetes manifests as a holistic package.

With a Carbon package you are able to do:

• develop
• build
• assign version (Docker tags)
• distribute (via Docker registries)
• install to Kubernetes
• and many other maintenance operations

Carbon packages are based on Docker images and don't impose any additional requirements or restrictions. Thus you may use your favorite Docker registry in order to store, share and install it to your Kubernetes cluster.

If you want to try Carbon, please check this documentation page: Get started with Carbon

How Carbon works

Carbon package is a Docker image with additional metadata stored at the image labels. The most important part of the metadata are Kubernetes manifest templates, which are converted to Kubernetes manifests on the installation stage.

Usage of Docker labels allows us to avoid downloading the whole image for the installation. Carbon just reads a package metadata directly from a registry, builds a Kubernetes manifest based on the templates and applies this manifest to a Kubernetes cluster. Based on the manifest, Kubernetes downloads specified Docker images from a registry and launches Pods.

Content

• Carbon installation
• Available CLI operations
• Carbon config
• Structure of a Carbon package
• Package config
• Kubernetes manifest templates and variables
• Patches
• Docker image names and tags
• Hooks
• Building a Carbon package without an application code
• Building multiple packages from a shared codebase
• Installed package metadata
• Working with Minikube

TODO: code style

Limitations

• All resources of a package will be deployed to the same Kuberenetes namespace. If you need to deploy resources to different namespaces, we recommend splitting such package to different packages
• If a package has global resources (like ClusterRole or CustomResourceDefinition), it's your responsibility to avoid multiple installations of your package in different Namespaces, especially when you use cluster scope (it may be improved in the future).
• You are forced to build one and only one Docker image in the scope of a one Carbon package:
  • Even if you don't have any data but Kuberenet manifests, you must build a Docker image. For such cases we recommend using a scratch base image. More details can be found at Building a Carbon package without an application code
  • When you want to build two (or more) Docker images in the scope of a single Carbon package, you have two options: to build a single Docker image and run it with different commands, or to split your codebase into different Carbon packages.

Roadmap

• carbon init - create package Carbon configs for a new package
• carbon verify - verify Carbon package configuration before running carbon build
• carbon config-upgrade - upgrade a package config to the latest version
• version constraints and dependencies - provide a possibility to define dependencies among Carbon packages and to install a package only when all version constraints are met
• Remove resources from all namespaces when they are (re)moved with Cluster Carbon scope mode
• smooth migration between Cluster and Namespace Carbon scopes

Community

TODO

Contribution

While Carbon is an important tool for our engineering department, it isn't a major business goal. Thus we're going to add the features matters for us.

If you need any feature which isn't implemented yet, feel free to propose MR. In the extension of this tool, we count on the community.

Development environment

You will need:

• Any Unix system (Linux, OSX, FreeBSD). Some tests use Unix shell commands, thus they don't work at Windows
• Minikube
• Docker