CF API Kyma Module is providing a CF API to run on top of Kyma, using the open source Korifi project Once installed, one could use the cf cli to connect and deploy workloads.
| Property | Optional | Default | Description |
|---|---|---|---|
| RootNamespace | Optional | cf |
Root namespace for CF resources |
| ContainerRegistrySecret | Optional | dockerregistry-config-external |
Container registry secret used to push application images. It has to be of type docker-registry |
| ContainerRepositoryPrefix | Optional | <registryURL>/ |
The prefix of the container repository where package and droplet images will be pushed. More details here |
| BuilderRepository | Optional | <registryURL>/cfapi/kpack-builder |
Container image repository to store the kpack ClusterBuilder image. More details here |
| UAA | Optional | The subaccount UAA | UAA URL to be used for authentication |
| CFAdmins | Optional | Kyma cluster admins | List of users, which will become CF administrators. A user is expected in format sap.ids:<sap email> example sap.ids:[email protected] |
| UseSelfSignedCertificates | Optional | false |
Use self signed certificates for CF API and workloads. |
| GatewayType | Optional | contour |
The underlying gateway api implementation. Accepted values: contour, istio |
Used for application source and droplet images. If not configured, the CFAPI module would use the registry provided by the docker registry module, or issue an error if not enabled.
Used to authenticate the user when running cf commands, such as cf push. If not configured, the CFAPI module would default to the BTP subaccount UAA instance
In the Kyma dashboard:
- Enable the
docker-registrymodule - Make sure external access is enabled
In the Kyma dashboard:
- Enable the
cfapimodule. - Once ready the CF url is set on its status.
cf login --sso -a <cfapi-url>Use CF cli to deploy applications as on a normal CF. The buildpacks used are native community buildpacks.
The CFAPI module installs a service broker that allows users consume BTP managed services in their applications. To view available services, run
cf service-access
By default the services are not enabled. To enable a service (for example xsuaa), run
cf enable-service-access xsuaa -p application
The service above is now available in the marketplace:
cf marketplace
Getting all service offerings from marketplace in org org / space space
offering plans description broker
xsuaa application Manage application authorizations and trust to identity providers. BTP
See the documentation on how to create a service instance and bind applications to instances.
The cfapi module uses contour as a default gateway api implementation since kyma managed istio does not support the gateway api out of the box. To use istio do the following:
In the Kyma dashboard:
- set the module release channel to
exprimental - set
spec.experimental.pilot.enableAlphaGatewayAPItotrueon the default Istio resource - set
spec.gatewayTypetoistioon the default CFAPI resource
The cf api module uses the kyma docker registry as container registry. To use a custom container registry (such as dockerhub) do the following:
- Create a container registry secret in the
cfapi-systemnamespace, e.g.dockerhub-secret:
kubectl create secret -n cfapi-system docker-registry dockerhub-secret \
--docker-server="https://index.docker.io/v1/" \
--docker-username="<dockerhub-username>" \
--docker-password="<dockerhub-password>"
On the default CFAPI resource:
- Set
spec.containerRegistrySecrettodockerhub-secret - Set
spec.containerRepositoryPrefixtoindex.docker.io/<organization>/ - Set
spec.builderRepositorytoindex.docker.io/<organization>/kpack-builder
Referer to Korifi documentation on configuring containerRepositoryPrefix and builderRepository
See the Contributing Rules.
See the Code of Conduct document.
See the license file.