SIP

Learn how to interact with the SIP as ISG supporter or OIV, both called operators.

Concepts

We introduce two concepts: Applications and Deployments. All interaction with an SIP cluster is through sipctl and the VCS. Some day all this will be done via the Gatekeeper web UI.

Application

An SIP application bundles a gitlab repository with a branch and commit hash, a docker image and the configuration from sip.yml. All application definitions go to the *-apps namespace of your organisation (e.g. amiv-apps). Applications are not runnable by themselves. 

SIP cares about stability of applications. It can happen frequently that the commit hash of the application changes in order to automatically install updates. Those updates have to maintain backward compatibility. If an incompatible change is to be released, this is done by creating a new application from the existing one and changing the branch and commit hash of the release to the new version.

Deployment

An application can be deployed into a namespace which creates an SIP deployment (something different from a Kubernetes Deployment if you know this). The SIP infrastructure will then automatically instantiate Kubernetes resources to finally start the application's container.

While the application can change arbitrarily, often and is mostly under the control of the developers of the application, deployments are controlled by the OIVs. They choose whether they want to automatically follow all updates of the application (auto-update) or stay on a fixed commit hash until the OIV triggers a manual update.

Gatekeeper

This is the planned GUI frontend application for all interactions with SIP for an operator. Here you will be able to manage your applications and deployments. It talks directly with the SIP API and does not interact with the cluster directly.

sipctl

This is a command-line tool to interact with SIP. It is meant to support the same tasks as Gatekeeper.

Installation

Download the tool and make sure it is executable in your shell.

Put the following content into ~/.config/vseth/sipctl/config.yml

$ mkdir -p ~/.config/vseth/sipctl/
endpoints:
- domain: api.vseth-k8s-redzone.vseth.ethz.ch:443
  registry: eu.gcr.io/aerial-reef-202214

If you know what our Greenzone is and you need to interact with it, use this config. Don't merge the two files, sipctl only supports a single endpoint.

endpoints:
- domain: api.k8s-eth.vseth.ethz.ch:443
  registry: eu.gcr.io/aerial-reef-202214

sip-api

Both gatekeeper and sipctl interact with an application inside the kubernetes cluster called the sip-api. It transforms user requests into kubernetes resources of deployments, applications and other internal resources. It runs as container inside kubernetes.


Tools

sipctl

See above

kubectl

The primary tool to interact with a kubernetes cluster. To maintain your cluster, better get used it. You can view the cluster status, including all resources of Kubernetes and SIP. You can access logs and metrics of containers. You can add and delete all kubernetes resources with it.

To get access to a cluster, put the corresponding kubeconfig into ~/.kube/config

Redzone Cluster: Install the google cloud SDK on your machine and follow the instructions here

Greenzone Cluster: Copy the kubeconfig from root@k8s-eth.vseth.ethz.ch:/etc/rancher/k3s/k3s.yaml to your machine. Then replace the string "localhost" with "k8s-eth.vseth.ethz.ch" in the kubeconfig.

helm

A template engine to apply kubernetes manifests automatically. We use it for cluster-level management tasks, see the charts repo.

repo-manager

repo-manager-cli

groupmanager