diff --git a/latest/index.html b/latest/index.html index 08efdde..75b5c02 100644 --- a/latest/index.html +++ b/latest/index.html @@ -541,7 +541,7 @@

Moon

Aerokube Software OÜ
version latest, -2024-08-12 +2024-08-13
Table of Contents
@@ -552,6 +552,7 @@

Moon

  • 1.2. Architecture @@ -1140,6 +1141,142 @@

    1.1.2

  • +
    +

    1.1.3. Recommendations on Working with Helm

    +
    +
    Helm values files
    +
    +

    As you could see above Helm chart is the recommended Moon installation way for both Kubernetes and Openshift. Our Helm chart comes with recommended defaults that will work out of the box in most cases. However, there are situations when you wish to install Moon with some advanced features already activated and to be able to easily reproduce the same installation later. For example, by default Moon does not record videos of browser sessions, and you may need this in your processes. Similarly, you may want to launch browsers in multiple namespaces or use additional trusted TLS certificates.

    +
    +
    +

    Although, all these features can be activated just by manually editing respective Moon objects (configuration object, browsers set, devices set) with kubectl edit command, such changes will be overwritten by Helm during the next deployment. Helm provides better way of having reproducible deployment configuration state - values files. It works like this:

    +
    +
    +
      +
    1. +

      Every Helm chart has default settings stored in values.yaml file and distributed with all the rest of chart files. For example, an up-to-date values.yaml file for Moon 2.x Helm chart is stored here. This file contains reasonable defaults.

      +
    2. +
    3. +

      If you need to change some defaults to custom values, you create a local values.yaml file containing only the values you wish to change. For example, in Moon Helm chart number of Moon replicas can be set using deployment.replicas field in values.yaml. You create a text values.yaml file like this:

      +
      +
      +
      deployment:
      +  replicas: 3
      +
      +
      +
      +

      Such file should be stored under your preferred version control system. This guarantees - you will never lose your custom deployment settings.

      +
      +
    4. +
    5. +

      To apply your custom settings while (re)deploying Moon - simply pass full path to your values.yaml file in Helm command:

      +
      +
      +
      $ helm upgrade --install -f path/to/values.yaml -n moon moon aerokube/moon2
      +
      +
      +
      +

      Overriding some parameter in values.yaml is equivalent but more useful than providing the same key as --set flag, e.g.:

      +
      +
      +
      +
      $ helm upgrade --install --set deployment.replicas=3 -n moon moon aerokube/moon2
      +
      +
      +
    6. +
    +
    +
    +
    +
    Configuring Moon Custom Resources
    +
    +

    Moon 2.x configuration is stored as native Kubernetes objects called custom resources:

    +
    +
    + +
    +
    +

    Our Helm chart contains a dedicated key in values.yaml corresponding to every such resource:

    +
    +
    +
    Moon custom resources can be also configured in values.yaml
    +
    +
    quota: # Stores a list of quotas
    +  quota1:
    +    # Quota1 specification
    +  quota2:
    +    # Quota2 specification
    +
    +configs: # Stores a list of configuration objects
    +  config1:
    +    # Config1 specification
    +  config2:
    +    # Config2 specification
    +
    +browsers: # Stores a list of browsers sets
    +  browsersset1:
    +    # Browsersset1 specification
    +  browsersset2:
    +    # Browsersset2 specification
    +
    +license: # Stores Moon license key (currently only one license key is supported in Helm chart)
    +
    +
    +
    +

    As you can see for all resources except licenses you can define multiple different instances: multiple configuration objects, multiple quota objects and multiple browsers sets. Every field you set in resource specification is converted as is to a Kubernetes custom resource. For example, consider the following browsers set in values.yaml:

    +
    +
    +
    An example browsers set definition in values.yaml
    +
    +
    browsers:
    +  my-browserset:
    +    selenium:
    +      firefox:
    +        repository: quay.io/browser/firefox
    +      chrome:
    +        repository: quay.io/browser/chrome
    +
    +
    +
    +

    When you apply Helm chart with the following definition in values.yaml, it will be automatically converted to browsers set Kubernetes resource like this:

    +
    +
    +
    An equivalent browsers set Kubernetes object
    +
    +
    apiVersion: moon.aerokube.com/v1
    +kind: BrowserSet
    +metadata:
    +  name: my-browserset
    +  namespace: moon # Your namespace name for Moon will be here
    +spec:
    +  selenium:
    +    firefox:
    +      repository: quay.io/browser/firefox
    +    chrome:
    +      repository: quay.io/browser/chrome
    +
    +
    +
    +

    If you create multiple entries in the list of browsers sets in values.yaml, then multiple Kubernetes resources will be created.

    +
    +
    +

    1.2. Architecture

    @@ -8736,7 +8873,7 @@