Overview

ESP Environment Background/Facts

• ESP clusters are designed to be immutable and throwaway
• The certs on a cluster expire after 90 days
• You can have more than one cluster backing a site (KA, TDC, etc)
• A separate repo holds the training portal and workshop definitions and it is not publicly accessible
• Manual access to the cluster is unique for each cluster and also tied to people's personal accounts
• There is no concept of environment in the design, so the version of a workshop cannot be different for example between production and staging.
• The training-portal.yaml is only one per cluster

Design Assumptions

TrainingPortal

The training portal YAML is global to the cluster contains from this perspective only a list of the workshops hosted on that cluster. A training portal in a course repo does not map into this. Realistically the frequency of a change or addition to the training portal yaml is very infrequent, usually when a course is created. In fact the workshop IDs for all the labs/workshops in a course can even be pre-populated in the training portal to reduce churn on the file.

Essentially the training portal YAML is never modified manually outside of the internal ESP GTIX infrastructure repo.

Workshop

The workshop artifact has the potential to change a little more frequently, but mostly during local development and not as much once in production or during testing. Therefore this again has an update frequency int he internal ESP GTIX infrastructure repo that is low. However there is one very important line in the workshop file that needs to change between environments... The image of the files server that runs the html hosted lab instructions.

            - name: files
              image: ${REGISTRY_HOST}/template-replaceme:${IMAGE_TAG}

Since this has to be the same across environments, the safest thing to do is default it to a prod or similar tag. That way when a new production cluster is deployed it is guaranteed to have the correct version of the lab running.

Approach

The overall approach works towards the following:

• Favors an approach where production has zero to low risk of accidentally having an outage or incorrect version
• Leverages that the frequency of which training portal and workshop definition additions/changes and are low volume compared to lab instruction changes.
• Accepts that non-prod environments may temporarily for a brief period may be out of sync with what version is desired of workshops

GitHub Action workflows

Release Created

Tag Release Image

Deploy to Environment ${X}

from backlog.