WIP

Author: deer-wmde

.envrc.bak

@@ -0,0 +1,16 @@
+export MINIKUBE_PROFILE=minikube-wbaas
+export MINIKUBE_MEMORY=max
+export MINIKUBE_CPUS=max
+export MINIKUBE_IN_STYLE=false
+
+export USER_MAIL="dena@dena.dena"
+export USER_PASS="123qwe"
+
+#export USER_WIKI_NAME="Local Test Wikiz"
+#export USER_WIKI_DOMAIN="local-test-wikiz.wbaas-local-test.de"
+#export USER_WIKI_ADMIN="Adminz"
+
+export CYPRESS_TEST_WIKI_PASSWORD="SuperSecureHackathonPassword!"
+export CYPRESS_TEST_WIKI_USERNAME="Admin"
+export CYPRESS_TEST_USER="deniz.erdogan@wikimedia.de"
+export CYPRESS_TEST_PASSWORD="W*=6+U4=xU{Hs.bJ3Px!"

.gitmodules

@@ -0,0 +1,3 @@
+[submodule "ssl-test"]
+	path = ssl-test
+	url = git@github.com:deer-wmde/ssl-test.git

bin/local/README.md

@@ -30,17 +30,17 @@ Creates a new wikibase with a local user account. The minikube tunnel needs to b
 
 It does this in two steps:
 1. Obtaining an auth token
-    - by `POST`ing to `http://api.wbaas.localhost/auth/login`
+    - by `POST`ing to `http://api.wbaas-local-test.de/auth/login`
 2. Requesting a new wikibase
-    - by `POST`ing to `http://api.wbaas.localhost/wiki/create`
+    - by `POST`ing to `http://api.wbaas-local-test.de/wiki/create`
 
 #### Default credentials
 You can use environment variables to overwrite the defaults:
 ```bash
 USER_MAIL="${USER_MAIL:-jane.doe@wikimedia.de}"
 USER_PASS="${USER_PASS:-wikiwikiwiki}"
 USER_WIKI_NAME="${USER_WIKI_NAME:-Local Test Wiki}"
-USER_WIKI_DOMAIN="${USER_WIKI_DOMAIN:-local-test-wiki.wbaas.localhost}"
+USER_WIKI_DOMAIN="${USER_WIKI_DOMAIN:-local-test-wiki.wbaas-local-test.de}"
 USER_WIKI_ADMIN="${USER_WIKI_ADMIN:-Admin}"
 ```
 

bin/local/README.md.bak

@@ -0,0 +1,72 @@
+# About this directory
+The purpose of the scripts in this directory is to improve and speed up the workflow with the local minikube setup. They are mostly quick and dirty hacks but serve the purpose.
+
+## Scripts
+### [`new-local-cluster.sh`](./new-local-cluster.sh)
+Deletes and tries to re-initiate the local minikube cluster in an unattended fashion (no user input/prompt approval required) by applying our opentofu and helmfile configuration. It can take like ~20 minutes to finish. All data inside the local cluster will be lost. Please report if your cluster is not in a useable state after running this script, so we can improve it.
+
+### [`create-local-user.sh`](./create-local-user.sh)
+Creates a local user account that can be used immediately. The minikube tunnel needs to be open for this to work (`make minikube-tunnel`).
+
+It does this in three steps:
+1. Creates an invite code
+    - by running `artisan wbs-invitation:create <code>`
+2. Registers a user account
+    - by using `curl` to `POST` form data to the API endpoint `/user/register`
+3. Manually sets the account to verified
+    - by flipping the `verified` field of the user in the database to 1
+        - via a PHP snippet executed with artisan tinker (dirty)
+
+#### Default credentials
+You can use environment variables to overwrite the defaults:
+```bash
+USER_CODE="${USER_CODE:-create-local-user}"
+USER_MAIL="${USER_MAIL:-jane.doe@wikimedia.de}"
+USER_PASS="${USER_PASS:-wikiwikiwiki}"
+```
+
+### [`create-local-wiki.sh`](./create-local-wiki.sh)
+Creates a new wikibase with a local user account. The minikube tunnel needs to be open for this to work (`make minikube-tunnel`).
+
+It does this in two steps:
+1. Obtaining an auth token
+    - by `POST`ing to `http://api.wbaas-local-test.de/auth/login`
+2. Requesting a new wikibase
+    - by `POST`ing to `http://api.wbaas-local-test.de/wiki/create`
+
+#### Default credentials
+You can use environment variables to overwrite the defaults:
+```bash
+USER_MAIL="${USER_MAIL:-jane.doe@wikimedia.de}"
+USER_PASS="${USER_PASS:-wikiwikiwiki}"
+USER_WIKI_NAME="${USER_WIKI_NAME:-Local Test Wiki}"
+USER_WIKI_DOMAIN="${USER_WIKI_DOMAIN:-local-test-wiki.wbaas-local-test.de}"
+USER_WIKI_ADMIN="${USER_WIKI_ADMIN:-Admin}"
+```
+
+## Adding new scripts
+### Fail safe
+All of these scripts should start with this failsafe snippet, to make sure they aren't doing anything at all when executed outside of the local minikube cluster context. If `kubectl` will be used in the script, it can be forced to use the local context with each call like this: `kubectl --context ${KUBE_CONTEXT}`.
+
+```bash
+#!/bin/bash
+
+### failsafe logic to exit in case we are not running in our local minikube context
+KUBE_CONTEXT=$(kubectl config current-context)
+
+echo "Current kube context: '${KUBE_CONTEXT}'"
+
+if [[ "${KUBE_CONTEXT}" != "minikube-wbaas" ]]; then
+    echo "Error: wrong kube context. Use this script only within 'minikube-wbaas'!"
+    exit 1
+fi
+#####################################################################################
+```
+
+### Dependency checking
+To test if certain CLI tools are available, you can check for them (and exit in case they aren't available) like this:
+```bash
+# Check if `jq` and `jo` are available
+[[ $(type -P "jq") ]] || { echo "error: 'jq' is not installed." 1>&2; exit 1; }
+[[ $(type -P "jo") ]] || { echo "error: 'jo' is not installed." 1>&2; exit 1; }
+```

bin/local/create-local-wiki.sh

@@ -19,17 +19,17 @@ fi
 USER_MAIL="${USER_MAIL:-jane.doe@wikimedia.de}"
 USER_PASS="${USER_PASS:-wikiwikiwiki}"
 USER_WIKI_NAME="${USER_WIKI_NAME:-Local Test Wiki}"
-USER_WIKI_DOMAIN="${USER_WIKI_DOMAIN:-local-test-wiki.wbaas.localhost}"
+USER_WIKI_DOMAIN="${USER_WIKI_DOMAIN:-local-test-wiki.wbaas-local-test.de}"
 USER_WIKI_ADMIN="${USER_WIKI_ADMIN:-Admin}"
 
-TEST_RESPONSE=$(curl -s http://api.wbaas.localhost/healthz)
+TEST_RESPONSE=$(curl -s http://api.wbaas-local-test.de/healthz)
 if [[ "${TEST_RESPONSE}" != "It's Alive" ]]; then
     echo "Error: local api is not available. Is the minikube tunnel open? ('make minikube-tunnel')"
     exit 2
 fi
 
 LOGIN_JSON_DATA=$(jo email="${USER_MAIL}" password="${USER_PASS}")
-LOGIN_RESPONSE=$(curl -s 'http://api.wbaas.localhost/auth/login' \
+LOGIN_RESPONSE=$(curl -s 'http://api.wbaas-local-test.de/auth/login' \
     -X POST \
     -H 'Content-Type: application/json' \
     -H 'Accept: application/json' \
@@ -39,7 +39,7 @@ LOGIN_TOKEN=$(echo "${LOGIN_RESPONSE}" | jq -r '.token')
 [[ -n "$LOGIN_TOKEN" ]] || { echo "error: login failed." 1>&2; exit 1; }
 
 CREATE_WIKI_JSON_DATA=$(jo domain="${USER_WIKI_DOMAIN}" sitename="${USER_WIKI_NAME}" username="${USER_WIKI_ADMIN}")
-CREATE_WIKI_RESPONSE=$(curl -s 'http://api.wbaas.localhost/wiki/create' \
+CREATE_WIKI_RESPONSE=$(curl -s 'http://api.wbaas-local-test.de/wiki/create' \
     -X POST \
     -H 'Content-Type: application/json' \
     -H 'Accept: application/json' \

bin/local/create-local-wiki.sh.bak

@@ -0,0 +1,49 @@
+#!/bin/bash
+
+### failsafe logic to exit in case we are not running in our local minikube context
+KUBE_CONTEXT=$(kubectl config current-context)
+
+echo "Current kube context: '${KUBE_CONTEXT}'"
+
+if [[ "${KUBE_CONTEXT}" != "minikube-wbaas" ]]; then
+    echo "Error: wrong kube context. Use this script only within 'minikube-wbaas'!"
+    exit 1
+fi
+#####################################################################################
+
+[[ $(type -P "jq") ]] || { echo "error: 'jq' is not installed." 1>&2; exit 1; }
+[[ $(type -P "jo") ]] || { echo "error: 'jo' is not installed." 1>&2; exit 1; }
+
+# This script should create a wiki for a user account on a local wbaas cluster with the credentials below. Do not use this in production! 
+
+USER_MAIL="${USER_MAIL:-jane.doe@wikimedia.de}"
+USER_PASS="${USER_PASS:-wikiwikiwiki}"
+USER_WIKI_NAME="${USER_WIKI_NAME:-Local Test Wiki}"
+USER_WIKI_DOMAIN="${USER_WIKI_DOMAIN:-local-test-wiki.wbaas-local-test.de}"
+USER_WIKI_ADMIN="${USER_WIKI_ADMIN:-Admin}"
+
+TEST_RESPONSE=$(curl -s http://api.wbaas-local-test.de/healthz)
+if [[ "${TEST_RESPONSE}" != "It's Alive" ]]; then
+    echo "Error: local api is not available. Is the minikube tunnel open? ('make minikube-tunnel')"
+    exit 2
+fi
+
+LOGIN_JSON_DATA=$(jo email="${USER_MAIL}" password="${USER_PASS}")
+LOGIN_RESPONSE=$(curl -s 'http://api.wbaas-local-test.de/auth/login' \
+    -X POST \
+    -H 'Content-Type: application/json' \
+    -H 'Accept: application/json' \
+    --data-raw "${LOGIN_JSON_DATA}")
+
+LOGIN_TOKEN=$(echo "${LOGIN_RESPONSE}" | jq -r '.token')
+[[ -n "$LOGIN_TOKEN" ]] || { echo "error: login failed." 1>&2; exit 1; }
+
+CREATE_WIKI_JSON_DATA=$(jo domain="${USER_WIKI_DOMAIN}" sitename="${USER_WIKI_NAME}" username="${USER_WIKI_ADMIN}")
+CREATE_WIKI_RESPONSE=$(curl -s 'http://api.wbaas-local-test.de/wiki/create' \
+    -X POST \
+    -H 'Content-Type: application/json' \
+    -H 'Accept: application/json' \
+    -H "Authorization: Bearer ${LOGIN_TOKEN}" \
+    --data-raw "${CREATE_WIKI_JSON_DATA}")
+
+echo "$CREATE_WIKI_RESPONSE"

doc/deployments/argocd.md

@@ -52,7 +52,7 @@ This GitHub workflow runs the script to check if the checked-in values files are
 1. Enable admin access by flipping `admin.enabled` to `true` in our values file (or manually in the ConfigMap `argocd-cm`)
     - this is enabled for local clusters by default
 2. Access the web interface and log in (username `admin`)
-    - a) local - http://argo.wbaas.localhost/
+    - a) local - http://argo.wbaas-local-test.de/
     - b) staging/production - https://localhost:8080/
       - Forward port `8080` of the deployment `argo-cd-base-argocd-server`
 

doc/deployments/argocd.md.bak

@@ -0,0 +1,61 @@
+# Argo CD
+## Overview
+### Deployment of Argo CD
+We deploy Argo CD via helmfile and the community helm charts: https://argoproj.github.io/argo-helm/
+- see [/k8s/helmfile/argo-cd.yaml](../../k8s/helmfile/argo-cd.yaml)
+
+It's basic configuration lives in the values files `argo-cd-base.values.yaml.gotmpl` for each environment.
+ - [production](../../k8s/helmfile/env/production/argo-cd-base.values.yaml.gotmpl)
+     - [staging](../../k8s/helmfile/env/staging/argo-cd-base.values.yaml.gotmpl)
+    - [local](../../k8s/helmfile/env/local/argo-cd-base.values.yaml.gotmpl)
+
+Currently this means each environment gets it's own instance of Argo CD, which in turn always deploys to the cluster it lives in. We may want to change this in the future, if this prevents us from using certain features or workflows.
+
+### Application configuration
+There are two more charts we use to configure our project & applications:
+- [argocd-config](../../charts/argocd-config/)
+  - gets deployed by helmfile
+  - defines the ["app-of-apps"](https://argo-cd.readthedocs.io/en/stable/operator-manual/cluster-bootstrapping/) `Application` 
+- [argocd-apps](../../charts/argocd-apps/)
+  - gets deployed by Argo CD
+  - defines the `Application` resources for our actual helm releases
+
+The values of the first chart get passed on to the second one, so we can infer which environment we are running in.
+
+### Values files
+After trying out different ways of templating our way through this, we currently settled with a script to generate plain yaml files:
+- the bash script: [/bin/generate/values](../../bin/generate-values)
+- the values files: [/k8s/argocd/](../../k8s/argocd/)
+
+These are generated by helmfile, which in turn reads the value files in [/k8s/helmfile/env/](../../k8s/helmfile/env/) like we are used to.
+
+#### [/bin/generate/values](../../bin/generate-values)
+```
+ $ ./bin/generate-values 
+error: missing environment
+
+usage: generate-values <environment> <release-name> [output-file-template]
+```
+The script can be run like `./bin/generate-values local ui` where `local` could be `staging` or `production` and `ui` any other helmfile release. The third parameter let's you define a different helmfile than `k8s/helmfile/helmfile.yaml`. This is needed for the CI script. Once we moved all components to Argo we could create a Makefile target that generates/updates all values files, for our convenience.
+
+#### CI - [check-generated-values.yml](../../.github/workflows/check-generated-values.yml)
+This GitHub workflow runs the script to check if the checked-in values files are actually up to date. It does this by iterating over each generated values file that is present in `k8s/argocd/` and runs `generate-values` to compare it against.
+
+### Self-Healing
+[Automatic Self-Healing](https://argo-cd.readthedocs.io/en/stable/user-guide/auto_sync/#automatic-self-healing) is currently disabled for the local environment. This way, we still can use skaffold to replace resources that get deployed by Argo CD. Otherwise Argo CD would immediately replace them again with the image that is configured in the values files.
+
+## Admin access
+> Caution! Admin access should only happen in rare circumstances (testing/diagnosing, for example)
+> as we want to maintain the configuration for everything in git.
+
+1. Reset the admin password by running `./bin/get-argocd-password`
+1. Enable admin access by flipping `admin.enabled` to `true` in our values file (or manually in the ConfigMap `argocd-cm`)
+    - this is enabled for local clusters by default
+2. Access the web interface and log in (username `admin`)
+    - a) local - http://argo.wbaas-local-test.de/
+    - b) staging/production - https://localhost:8080/
+      - Forward port `8080` of the deployment `argo-cd-base-argocd-server`
+
+        ```
+        make argo-port-forward
+        ```

doc/local-dev-env.md

@@ -178,15 +178,15 @@ minikube does not provision LoadBalancer service IP addresses as part of normal
 make minikube-tunnel
 ```
 
-You should now be able to access the ingress via http://www.wbaas.localhost. Most modern browsers will automatically resolve *.localhost to 127.0.0.1. If not, you'll need to edit your hosts file.
+You should now be able to access the ingress via http://www.wbaas-local-test.de. Most modern browsers will automatically resolve *.localhost to 127.0.0.1. If not, you'll need to edit your hosts file.
 
 More detailed information on the load balancer can be found in [minikube-load-balancer.md](minikube-load-balancer.md).
 
 ## Mailhog / Local emails
 
 For the local setup, [Mailhog](https://github.com/mailhog/MailHog) is used to capture outbound emails.
 
-You can view those emails by going to http://mailhog.wbaas.localhost/
+You can view those emails by going to http://mailhog.wbaas-local-test.de/
 
 ## Mediawiki debugging 
 ### logging
@@ -215,10 +215,10 @@ Xdebug can be enabled in your minikube cluster if you use mediawiki image with `
 - You can use Xdebug on your VSCode IDE by following these steps:
   * Follow this tutorial in the section "Debug PHP using Xdebug and VS Code" https://php.tutorials24x7.com/blog/how-to-debug-php-using-xdebug-and-visual-studio-code-on-ubuntu
 
-## Create an account on wbaas.localhost
+## Create an account on wbaas-local-test.de
 To use the local wbaas instance you have just setup, you will need to create an invitation code via the api which is needed when creating an account. Follow the [instructions](https://github.com/wbstack/api/blob/main/docs/invitation-codes.md) documented in the wbaas/api repo.
 
-After creating the invitation code, you can visit http://wbaas.localhost/create-account (or click the create account link in the login form) and create an account. All outbound email is captured by Mailhog ([see above](#mailhog--local-emails)) so you can use a made up email address (e.g. `test@example.com`). Verify your email address via the "Account Creation Notificaiton" email captured by Mailhog.
+After creating the invitation code, you can visit http://wbaas-local-test.de/create-account (or click the create account link in the login form) and create an account. All outbound email is captured by Mailhog ([see above](#mailhog--local-emails)) so you can use a made up email address (e.g. `test@example.com`). Verify your email address via the "Account Creation Notificaiton" email captured by Mailhog.
 
 ## [Optional] setup bash completion
 Here is how to get tab completion working for common commands
@@ -275,7 +275,7 @@ Error: plugin "diff" exited with error
 
 it is likely because `make diff-local` uses the `--skip-deps` option when executing `helmfile diff` which skips downloading chart dependencies. To force the fetching of dependencies run `make helmfile-deps` before `make diff-local`. 
 
-### **Why can't I access [wbaas.localhost](http://www.wbaas.localhost)?**
+### **Why can't I access [wbaas-local-test.de](http://www.wbaas-local-test.de)?**
 Here are a few things to try:
   - make sure minikube is running `make minikube-start`
   - make sure the minikube tunnel is running `make minikube-tunnel`