Porter Buildtime Architecture
In Porter, “buildtime” refers to authoring and building a bundle. A bundle is defined by a manifest, porter.yaml, where you define:
- Parameters to customize the bundle.
- Credentials to authenticate to services and resources used by the bundle.
- Outputs generated by the bundle.
- Mixins used by the bundle. Mixins help you install and interact with tools in the bundle.
- Actions such as install, upgrade or uninstall. These contain the steps to execute when that bundle action is run.
Mixins must be installed to the same machine where the bundle is built.
So for example, if you want to use the kubernetes mixin in your bundle, first run
porter mixins install kubernetes.
Mixins are cached in your PORTER_HOME directory, and the kubernetes mixin can be found in ~/.porter/mixins/kubernetes after it is installed.
Porter does not support specifying which version of a mixin to use in a bundle yet.
You can follow the Mixins are Bundles proposal to keep track of that feature’s progress.
When the bundle author runs
porter build, Porter first generates a Dockerfile to create an image for the bundle (known as the invocation image or installer).
You can define your own custom Dockerfile to customize and optimize the image.
The Dockerfile contains the following: a base image (debian), additional customizations generated by the mixins, and a COPY statement to include the files contained in the bundle directory where the porter.yaml file is located.
A copy of the Porter runtime, the mixin runtimes and the porter.yaml file are copied into the bundle.
After the image is built, Porter then generates a CNAB-compliant bundle.json file that defines the bundle’s metadata.