First steps

ATTENTION If you are running catapult locally, be sure to have met the Local requirements.

Clone this repository locally:

$> git clone https://github.com/SUSE/catapult && cd catapult

We will spawn a deployment of KubeCF locally, by spawning also a local Kubernetes cluster with docker: by default catapult uses kind. When you create a new cluster, a new directory build<clustername>/ (in our case buildkind) will be created inside, after the kubernetes cluster is up and ready.

Deploying KubeCF from the latest public chart is as simple as:

$> make all

At the end of the process you will have KubeCF installed inside the build folder, with everything you need to interact with the deployment. Now we can log into CloudFoundry to be able to cf push:

$> make kubecf-login

If you want to interact with your k8s cluster manually (e.g. running kubectl commands) or perform more cf functions, you can cd buildkind, or source ./buildkind/.envrc or source the envrc, which contains the env vars needed for kubectl, helm, cfcli etc:

$> pushd buildkind
$> source .envrc
$> kubectl get pods …

Your kubeconfig will be in buildkind/kubeconfig. You can also install direnv (and configure it by adding an eval "$(direnv hook zsh)" or the like to your shell config), and the .envrc will get loaded automatically when you enter the build dir, and unloaded when you exit, instead of needing to source the .envrc.

To try out your KubeCF install, you can push a sample app by

$> make sample

You can now delete your KubeCF deployment by doing:

$> make kubecf-clean

Or the full kind deployment by:

$> make clean

Apart from kind, you can use other k8s backends with the BACKEND variable:

$> BACKEND=gke make all
or
$> BACKEND=caasp4os make all

These deployments will by default end in a folder called build<backend>, eg buildgke. We can always customize the folder name by using the CLUSTER_NAME variable, which also allows us to have several clusters deployed:

$> BACKEND=kind CLUSTER_NAME=my-kind make all
$> cd buildmy-kind; cf apps

Each build folder contains a bin/ folder, with clients downloaded to target your specific k8s cluster (kubectl, cf-cli, helm) and utilities needed by catapult make targets. Each build folder contains artifacts needed for deploying kubecf/scf, and artifacts created by the deployment.

Now that we have tried a local deployment, check out in the wiki how it can be used to drive deployments on remote backends as well (e.g. CaaSP)!