Create a custom service
As described in the Service reference page, Epinio services are nothing but descriptions of Helm charts. An operator may add more services by simply creating a Custom Resource in the namespace where Epinio is installed.
As a starting point, you can check the services installed by default for Epinio:
$ kubectl get services.application.epinio.io -A
If Epinio is installed in a namespace called
epinio, the following command outputs the Service definition in
$ kubectl get services.application.epinio.io -n epinio mysql-dev -o yaml > service.yaml
or you can find the definition of the catalog services here.
Change the fields to point to the desired helm chart and apply the yaml with a command like:
$ kubectl apply -f service.yaml
If everything worked correctly, you can see your Service in the Epinio
$ epinio service catalog
Adding an Image to the service
The various consumers of the API (e.g. the web UI of Epinio) can show an icon when
listing the various available services. If you want to assign an image to your
custom service, make sure you add the
serviceIcon field in the Custom Resource
Generally, helm charts have an icon field defined which already provides such an
image. You can find the icon field with the
helm show command. E.g. for the
bitnami rabbitmq helm chart:
helm show chart https://charts.bitnami.com/bitnami/rabbitmq-9.0.5.tgz | yq .icon
Multiple Secret types
By default Epinio will look for Opaque secret types to label them as Configurations.
Sometimes this is not enough, so you can define different types with the
With this definition, Epinio will get all the
connection.crossplane.io/v1alpha1 secrets generated during the creation of this Service (any type of secret can be listed).
Services can be customized in two possible ways. The first, system settings, is for operators to configure the referenced chart so that it will actually work within the epinio environment. The second, user settings, declares the settings of the chart the user is allowed to tweak when deploying the service from the catalog.
Given that system settings are considered to be needed they have priority over user settings. In
other words, declaring a field used by the system settings as user-settable will in the end be a
operation. While the user can see that setting, and provide values, these values will be ignored in
favor of the system values.
The system settings are entered through the
spec.values field of the service declaration.
... text ...
The value of this field is text, albeit YAML formatted text.
As an example, the predefined development services coming with an Epinio installation use this to
extraDeploy field of the bitnami charts to inject supporting service accounts, roles,
bindings, and PVCs for the service to use.
User-settable configuration values
The user settings are declared through the
spec.settings field of the service declaration.
The example settings shown above are taking from the nginx service used in the epinio testsuite.
The syntax of the
settings map is the same as the
settings map used to customize app chart resources.
User-settable configuration values in the how to for
Creating Custom Application Helm Charts
Because of this the full specification is not repeated here.
There are semantic differences between the app chart and service declarations.
For app charts the keys are simple strings for the
userConfig map. They do not allow nesting.
For service charts the keys are proper paths into the set of fields exposed by the chart through its
values.yaml file. Nesting is expressed using dots (
.). As example see