Skip to content

Instantly share code, notes, and snippets.

View mozafrank's full-sized avatar

Adam Frank mozafrank

View GitHub Profile

Testing a Mozlenium/Synthetics style check locally

Lets assume you have a check you want to run in mozlenium called my-check.js.

  1. git clone https://github.com/mozilla-it/mozlenium
  2. cd mozlenium/checkers/mozlenium
  3. npm i
  4. echo 'async function runner($browser, $driver, $secure) {' > check.js
  5. cat my-check.js >> check.js
  6. echo -e "}\nmodule.exports = runner;" >> check.js

How Mozlenium Works

Tl;dr

Check CRD (k8s) -> Event Stream -> mozlenium Check threads, one thread for each Check -> check threads create k8s jobs to run the check -> check thread polls the job, scrapes status, state, logs, deletes the job, sends state, status, logs to Check CRD

Too long, DID read

  1. When Mozlenium starts the Controller creates all the necessary threads and q ueues.
@mozafrank
mozafrank / ExternalSecrets.md
Last active November 12, 2020 18:07
External Secrets in GCP

A Guide to ExternalSecrets

Google Cloud (GCP)

Example Secret:

apiVersion: kubernetes-client.io/v1
kind: ExternalSecret
metadata:
  name: my-k8s-secret

How to Flux

How Flux Works

  1. You've got a config repo where you keep your HelmReleases for a given cluster. Flux polls this periodically for manifest changes (based on the git-path you specify) and applies them.

  2. developer adds annotations to HelmRelease to tell flux to watch their upstream docker images.

  3. developer merges code to main in app-specific repo

  4. CI tool builds, tags and pushes image

  5. Flux detects the changed image because of the annotation on the HelmRelease file, triggers an upgrade