This collection of yaml, ytt, and go code packages together the bits that make the CF API run in cf-for-k8s.

1. capi-k8s-release is best consumed as part of cf-for-k8s
2. Clone the cf-for-k8s repository: git clone https://github.com/cloudfoundry/cf-for-k8s.git
3. Follow the cf-for-k8s deploy documentation

click here to edit the diagram, save as capi-k8s-release.png to persist changes

In this repo:

• cf-api-controllers is a collection of kubebuilder controllers that synchronize the CF API and various k8s CRDs (Images, Builds, Routes, PeriodicSyncs, etc).
• registry-buddy is sidecar service to help ruby code communicate with container registries using go-containerregistry.
• nginx is a custom-built nginx container including the nginx upload module for managing resumable multipart package uploads.
• backup-metadata is a velero hook that collects metadata about resources currently stored in the CF API.

From elsewhere:

• cloud_controller_ng is a reference implementation of the the V3 CF API.
• eirini is an adapter that lets Cloudfoundry Processes and Tasks run on Kubernetes
• kpack is a collection of CRDs and Controllers for building container images from source using Cloud Native Buildpacks
• route controller & istio are used by cf-for-k8s to manage Routes to apps and the service mesh between CF components
• uaa is used to manage users and token verification
• cf is the eponymous CLI for interacting with the CF API. We support versions v7 and higher.

1. ./scripts/rollout.sh will take any local changes to capi-k8s-release, apply them to a local cf-for-k8s directory, and then deploy cf-for-k8s
2. ./scripts/build-and-rollout.sh will take local changes to cloud_controller_ng and the components in capi-k8s-release/src, build them with kbld, pack, and paketo's ruby and go buildpacks, and then deploy the new images to cf-for-k8s.

Environment variables can be used with either script to override default local source directories and remote image repositories.

capi-k8s-release currently uploads app source code to a blobstore, but then hands that off to kpack to build app images that are then placed in a registry. In order for this to work, you must configure the following values:

kpack:
  registry:
    hostname: # the hostname of the registry, used for authentication
    repository: # the destination of the build app images within the registry
    username: # basic auth registry username
    password: # basic auth registry password

dockerhub example:

kpack:
  registry:
    hostname: https://index.docker.io/v1/
    repository: cloudfoundry/capi
    username: <username>
    password: <password>

gcr example:

kpack:
  registry:
    hostname: gcr.io
    repository: gcr.io/cloudfoundry/capi
    username: <username>
    password: <password>