Skip to content

Gatekeeper provision and update namespaces

Mat Appelman requested to merge mat/provisioner into main

This MR closes out the integrated auth work.

Please check this branch our locally and follow the instructions below to test Opstrace on your local machine.

Summary of Changes

  • Builds upon the work done in !1595 (merged)
  • Extends Gatekeeper with additional paths for provisioning/enabling observability in a GitLab namespace
  • Fixes a few reconciliation issues
  • Updates our quickstart and adds new documentation for how to get started with sending and exploring traces

Quickstart Guide

Git pull and checkout this branch.

Step 0: Setup

Open a terminal and verify you have the following:

  • Kind for setting up a local Kubernetes cluster.
  • For sending dummy data to Opstrace, you'll need Docker and Docker Compose
  • Kubectl for interacting with Opstrace
kind --version
docker --version
docker-compose --version
kubectl version

Now we need to create a local kind cluster. In the root of this repo:

make kind

Step 1: Install Opstrace

Now deploy the scheduler:

make deploy

Create a GitLab Application so we can use it for authentication. In the GitLab instance you'd like to connect Opstrace to, create an OAuth Application. This application can be a user owned, group owned or instance-wide application. In production, we create an instance-wide application and select "trusted" so that users are explicitly authorized without the consent screen. Here is an example of how to configure the application. Be sure to select the API scope and to enter http://localhost/v1/auth/callback as the redirect URI:

create-gitlab-application

Create the cluster definition:

cat <<EOF > Cluster.yaml
apiVersion: opstrace.com/v1alpha1
kind: Cluster
metadata:
  name: dev-cluster
spec:
  target: kind
  dns:
    acmeEmail: ""
    dns01Challenge: {}
    externalDNSProvider: {}
  gitlab:
    groupAllowedAccess: '*'
    groupAllowedSystemAccess: "6543"
    instanceUrl: https://gitlab.com
    oauthClientId: <YOUR CLIENT ID FROM YOUR GITLAB APPLICATION>
    oauthClientSecret: <YOUR CLIENT SECRET FROM YOUR GITLAB APPLICATION>

EOF

Replace <YOUR CLIENT ID FROM YOUR GITLAB APPLICATION> and <YOUR CLIENT SECRET FROM YOUR GITLAB APPLICATION> with the values from your GitLab application that you just created.

kubectl apply -f Cluster.yaml

Wait for the cluster to be ready:

kubectl wait --for=condition=ready cluster/dev-cluster --timeout=600s

Once the above command exits, the cluster is ready.

Step 2: Enable Observability on a GitLab namespace you own

Navigate to a namespace you own in the connected GitLab instance, and copy the Group ID below the group name, for example:

copy-group-id

Now open your browser to http://localhost/-/{GroupID}. In the above group, we'd open http://localhost/-/14485840

Follow the on screen instructions to enable observability for the namespace. This can take a couple of minutes if it's the first time observability has been enabled for the root level namespace (GitLab.org) in the above example. There are many optimizations we can make to reduce this provisioning time.

Once your namespace has been enabled and is ready, the page will automatically direct you to the GitLab Observability UI.

Step 3: Generating and Sending Traces using OpenTelemetry

This docker compose can be used to generate traces and send them to an opstrace namespace.

Navigate to your namespace in Opstrace and create an API Key.

create-token

Copy the created Key:

key

Install a small tool to help us workaround an issue of the OTLP exporter trying to send data to the loopback interface.

go install github.com/axetroy/forward-cli@latest

Start the reverse proxy with any port of your choosing.

forward --port=4000 http://localhost:80

You should get output like the following:

forward --port=4000 http://localhost:80
2022/05/19 12:13:06 Proxy 'http://192.168.1.47:4000' to 'http://localhost:80'

Copy the address of the forwarder (http://192.168.1.47:4000 in the example above).

Take the key and the namespace which the key was created in and let's start the docker services that will generate and send traces to this namespace:

cd test/tracing

OPSTRACE_ADDRESS=http://192.168.1.47:4000 \
NAMESPACE=13490748 \
NAMESPACE_TOKEN=eyJrIjoiTTdqekNOV0JIOHpvMjRsRFlXb1MxcVVaNHNCZFVucmMiLCJuIjoiZGVtbyIsImlkIjoxMzQ5MDc0OH0= \
docker-compose up

Open http://localhost:8080 and click some buttons. This will create traces and they will be sent to your opstrace namespace.

Navigate to the datasources tab in the UI for your namespace and create a new Jaeger datasource (this is yet to be automated).

datasources-tab

Click Add datasource and then select Jaeger.

In the URL field of the datasource configuration, add jaeger-{namespace}.{namespace}.svc.cluster.local:16686 where namespace is the value of the NAMESPACE environment variable set above (the namespace ID for which this maps to in GitLab). Click Save and Test.

jaeger-datasource

Navigate to the explore view in your namespace and select Jaeger as the datasource. You should see traces which you can select and view.

traces

Step 4: Clean up

To tear down your locally running instance of Opstrace, run:

make destroy
Edited by Mat Appelman

Merge request reports