Porter Runtime Architecture
In Porter, “runtime” refers generally to the execution of a bundle. The “Porter runtime” specifically refers to the embedded copy of the porter-runtime binary that is inside every single Porter bundle, located at /cnab/app/porter-runtime.
Below is an outline of what happens when a bundle is executed:
- Porter identifies all parameters and credentials, resolving parameter and credentials sets against the host environment and any configured secret stores.
- Porter runs a container using the bundle’s invocation image, injecting the parameters and credentials as files and/or environment variables.
- The entrypoint of the container is the Porter runtime. It parses the porter.yaml file embedded in the bundle, and executes the steps defined for the current action (such as install or upgrade).
- For each step, Porter calls the corresponding mixins which are also embedded in the bundle.
- The mixin performs an action, most commonly translating the yaml snippet for the step into a call to a development tool. For example, the helm3 mixin handles calling out to the helm CLI.
- When the bundle is complete, Porter records the result of the run, and persists any outputs generated by the bundle.
When a bundle is executed by Porter, the console output generated by the Porter runtime is directed to STDERR. Console output generated by the mixins may be sent to either STDOUT or STDERR depending on the behavior of the tool that the mixin calls.
For example, a bash script that uses “echo” will have its output sent to STDOUT. Other mixins may send some output to STDOUT and some to STDERR depending on the message severity.
If you want to exclude Porter’s runtime console output, do not pass the –debug flag to the corresponding porter command, such as porter install or porter upgrade. When a bundle is run in “debug mode”, Porter will print additional output about how the bundle and mixins were run to STDERR.