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 SCF 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 SCF from the latest public chart is as simple as:

$> make all

At the end of the process you will have SCF 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 scf-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 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 SCF install, you can push a sample app by

$> make sample

You can now delete your scf deployment by doing:

$> make scf-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 scf/kubecf, 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)!