Running options

See make help and make help-all for a comprehensive list.

The make targets can be executed separated, but some of them depend on others having been run beforehand (eg: make scf needs a preexisting k8s cluster, obtained for example with make k8s).

Using kind

Create a k8s cluster with kind

$> make k8s

The kubeconfig will be available under buildkind/kubeconfig.

Start an already existing kind cluster

$> make start

Stop an already running kind cluster

$> make stop

Cleaning up

$> make clean

Or if the kind cluster was started but the build dir was lost:

$> make force-clean

To recover a kind kubeconfig from a previous deployment:

$> make recover

Using other k8s backends

Eg: BACKEND=caasp4os make k8s or BACKEND=gke make k8s. See the different BACKEND options, and their pages in the wiki.

Upgrading a deployment

You might want to tweak the values file after a deployment, to experiment e.g. different env variables or upgrade from another chart. You can do:

$> SCF_CHART="xxx" DEFAULT_STACK=cflinuxfs3 make scf-chart scf-gen-config scf-upgrade

Overriding a default stack

You can specify a default stack with DEFAULT_STACK. e.g. to set a different default with an already existing deployment. You can just do:

$> DEFAULT_STACK=cflinuxfs3 make scf-gen-config scf-upgrade

Login in

Once the deployment of SCF succeeded, you can also manually login to your cluster if needed:

$> make scf-login; cd buildfolder; cf apps

Cluster terminal

If you want to open up a terminal inside a pod running in the cluster, you can do:

$> [..] make module-extra-terminal

Overriding scf-config-values

One way to let override Catapult generated config file, is to specify the CONFIG_OVERRIDE parameter:

export CONFIG_OVERRIDE=$(cat <<EOF
sizing:
  HA: true
EOF
)