Table of contents generated with markdown-toc
In the component repo (e.g. capi-k8s-release
, uaa
, cf-k8s-networking
, etc. ):
cf-for-k8s
to use that new image by updating the image reference(See a suggested local development workflow, below)
In cf-for-k8s
repo:
develop
and create a new branch
config/values.yml
), please also add those changes to the sample-cf-install-values.yml
filevendir
about the change by updating the ref:
in vendir.yml
to the new commit SHAvendir sync
cf-for-k8s
vendir.yml
, vendir.lock.yml
, and the template config changes from vendir sync
directory
flag, used in the development workflow)Deploy your instance of cf-for-k8s.
Configure the smoke test environment variables as suggested, below
export SYSTEM_DOMAIN=<your system domain>
export SMOKE_TEST_PASSWORD=<CF Admin password from `cf-values.yml`>
Run the smoke test suite
cd tests/smoke
export SMOKE_TEST_API_ENDPOINT=api.${SYSTEM_DOMAIN}
export SMOKE_TEST_USERNAME=admin
export SMOKE_TEST_APPS_DOMAIN=apps.${SYSTEM_DOMAIN}
export SMOKE_TEST_SKIP_SSL=true
ginkgo -v -r ./
In addition to the dependencies above, the workflow below requires these:
To simplify the component development workflow, we recommend repositories organize configuration thusly:
├── example-component
│ ├── config - K8s resources
│ │ ├── deployment.yml
│ │ └── values
│ │ ├── _default.yml - contains schema/defaults for all values used within config
│ │ └── images.yml - contains resolved image references (ideally in digest form)
│ └── build - configuration for the build of CF-for-K8s
│ └── kbld.yml
Note: a working example structure this way can be found at example-component.
Notes:
config/
(so that while invoking ytt
you always specify just that one directory.)config/
directory, gather data value file(s) into a sub-directory: e.g. config/values/
(so that while invoking vendir sync
you always specify just that one directory.)build
(so that all that’s in the config
directory are only the K8s resources being contributed to CF-for-K8s)These instructions assume that you are using the directory structure, above.
Create or claim a Kubernetes cluster. We expect these instructions to work for any distribution of Kubernetes, your mileage may vary (local or remote).
Checkout cf-for-k8s
develop and install it to your cluster.
Start a local Docker Daemon so that you can build (and push) local Docker images.
Here, we install minikube
for its Docker Daemon (and not necessarily as our target cluster).
minikube start
eval $(minikube docker-env)
docker login -u ...
Make changes to your component
Rebuild your component image and update any image references in your configuration.
Here, we use kbld
and generate a ytt data value file (i.e. config/values/images.yml
) with that resolved image reference:
cd ~/workspace/example-component
cat <(echo "#@data/values"; kbld -f build/kbld.yml --images-annotation=false) \
>config/values/images.yml
Note: ytt
merges data files in alphabetical order of the full pathname. So, config/values/_default.yml
is used first, THEN config/values/images.yml
(see k14s/ytt/ytt-data-values). Therefore, it is critical that whatever name you choose for the generated data file (here, images.yml
), it sorts after _default.yml
.
Note: see Sample kbld config, below for an example of a kbld
config.
Sync your local component configuration into the cf-for-k8s
repo.
Here, we use vendir’s --directory
feature to sync just the directory containing our component:
cd ~/workspace/cf-for-k8s
vendir sync \
--directory config/_ytt_lib/<path-to-component>=~/workspace/<path-to-component>
For example, sync’ing just CAPI would look like this:
cd ~/workspace/cf-for-k8s
vendir sync \
--directory config/_ytt_lib/github.com/cloudfoundry/capi-k8s-release=~/workspace/capi-k8s-release/
Re-deploy cf-for-k8s
with your updated component.
See kbld docs to configure your own kbld.yml
.
Assuming your ytt
template takes the data value at image.example
as the image reference…
images:
example: example-component-image
---
apiVersion: kbld.k14s.io/v1alpha1
kind: Sources
sources:
- image: example-component-image
path: .
---
apiVersion: kbld.k14s.io/v1alpha1
kind: ImageDestinations
destinations:
- image: example-component-image
newImage: docker.io/<your-dockerhub-username>/<your-docker-repo-name>
---
apiVersion: kbld.k14s.io/v1alpha1
kind: ImageKeys
keys:
- example
Where:
kbld
will rewrite the image reference.kbld
, itself.