Aurora Config

What is Aurora Config?

TLDR; Take me to the Configuration Reference!

Aurora Config is a custom file based configuration format developed by the Norwegian Tax Administration designed to be a concise representation of how applications are configured and deployed across environments and clusters in an OpenShift based infrastructure. Parts of the configuration format is generally reusable by anybody deploying to OpenShift, while other parts of it are designed to simplify integrations with specific third party components in our infrastructure.

The conciseness of the format is derived from a highly opinionated way of deploying applications to OpenShift, providing override options only when necessary.

Config files are written either as Json or Yaml.

Aurora Config is structured around a four level file structure with the top level being the most general and the bottom level, representing an application in a given environment, being the most specific - potentially overriding options set at higher levels. Each environment has its own folder with a separate file for each application in that environment, in addition to an about.yaml file describing the environment itself. The following table describes the different files;

For the applications App1 and App2, and the environments test and prod, a typical Aurora Config could then look like;

├── about.yaml     (Configuration for all applications in all environments)
├── about-alternative.yaml (Alternative global configuration)
├── App1.yaml      (General configuration for App1)
├── App2.yaml      (General configuration for App2)
├── prod           (A folder named prod, representing the environment prod)
│  ├── about.yaml  (Configuration for all applications in environment prod)
│  ├── App1.yaml   (Configuration for App1 in environment prod)
│  └── App2.yaml   (Configuration for App2 in environment prod)
└── test           (A folder named test, representing the environment test)
   ├── about.yaml  (Configuration for all applications in environment test)
   ├── about-alternative.yaml  (Alternative Configuration for all applications in environment test)
   ├── App1.yaml   (Configuration for App1 in environment test)
   └── App2.yaml   (Configuration for App2 in environment test)

For a given app file, it is possible to change the base and env file if you want to compose your configuration differently than the default. For instance, you may need to deploy the same application in the same environment with different name and configuration;

File named 'test/App1Beta.yaml'

baseFile: App1.yaml
envFile: about-alternative.yaml

In this scenario 'App1.yaml' would be used instead of 'App1Beta.yaml' (which does not exist) as the base file for the App1Beta in the environment test. The env file about-alternative will be used instead of the standard about file. Note that env files must start with the prefix about

For a given env file, it is possible to include another env file that is read right before you using the configuration.

In prod/about.yaml

includeEnvFile: test/about.yaml

In this scenario 'test/about.yaml' will be read right before 'prod/about.yaml'. This will make it possible to have an environment that is a template for other environments.

In App1.yaml

globalFile: about-alternative.yaml

In this scenario 'prod/App1.yaml' and 'test/App1.yaml' will inherit from 'about-alternative.yaml' at root level, replacing the default global file. This makes it possible to have alternative global configurations for particular applications.

In prod/about.yaml

globalFile: about-alternative.yaml

In this scenario 'prod/about.yaml' will inherit from 'about-alternative.yaml' at root level. This makes it possible to have alternative global configurations for entire environments.

DeploymentSpec and ApplicationId

When the Aurora Config is processed a new object is generated for each app file, representing the configuration collected from the global file, the base file for that application, the env file for the environment, and finally the app file itself. This object is called the DeploymentSpec for the given application. The identifier for a DeploymentSpec, called ApplicationId, is the combination of environment name and application name. From the example above we would get four DeploymentSpecs with the following ApplicationIds;

• prod/App1
• prod/App2
• test/App1
• test/App2

Configuration Reference

The following sections will describe the different configuration options that are available in each of the files. The examples will use the YAML format for the config files since it is terser and easier on the eyes than JSON.

Header

Some options are considered header options and are read in a separate step during the configuration parsing process. This allows us to set defaults and make available values in the header for variable substitution in the other configuration options. In order to include these into a field surround them with '@', for instance.

config/cluster : "@cluster@"

Which options are available for substitution is indicated in the following tables.

Substitutions should be used with care especially if they occur in a file that applies to multiple application instances, e.g. env files and base files.

Some configuration options can only be set in the global about file and the env file. These are typically options that are only relevant for configuring the environment, for instance environment name, permissions and env.ttl (time to live). Since environments have their own folder and the environment is configured in an own about-file, it is not allowed for an app-file to override any of the environment specific options. Options that can only be set in the global file or in an env file will be described in a section called "About files" and options that can also be set in the base files and app files will be describe in a section called "Application files".

About files

At least one of the groups in permissions/admin must have a user in it.

Application files

Notifications

Get notification messages when an application or environment/namespace has been deployed.

Mattermost

In order to use this feature one has to use the channelId, which is not the same as the channel name. The channelId can be retrieved by going to a channel, then hitting view info in the channel header. At the bottom of the dialog box you will find a greyed out channel id.

Email

Notifications can also be sent to mailing groups by configuring the email option in the notification field

Deployment Types

The configuration option type indicates the deployment type the application has. The value of this field affects what other configuration options are available for that application. The deployment type determines primarily how the objects that supports the application on OpenShift are generated, but it also affects the different types of integrations that are supported.

deploy

The deploy deployment type is used for deploying applications using the conventions from the Aurora Platform. You can read more about these conventions here: How we Develop and Build our Applications. This is the deployment type that will be most commonly used when deploying internally built applications. This will provide integrations with the rest of the NTAs infrastructure and generate the necessary objects to OpenShift to support the application.

development

The development deployment type is similar to the deploy deployment type but it will not deploy a prebuilt image from container registry. Instead an OpenShift ImageStream will be created that can be used to send images created from DeliveryBundles from your local development machine (see ao dev rollout).

This will usually significantly reduce the time needed to get code from a development machine running on OpenShift compared to, for instance, a CI/CD pipeline.

template

Supports deploying an application from a template available on the cluster. See Guidelines for developing templates.

localTemplate

Supports deploying an application from a template available in the AuroraConfig folder. See Guidelines for developing templates.

cronjob

Supports running a scheduled job as a CronJob resource on Kubernetes

job

Supports running a job as a Job resource on Kubernetes

Configuration for Deployment Types "deploy" and "development"

Example specification of an json env var

config:
  FOO: '{"BAR": "BAZ"}'

This will result in a json object with the key BAR and the value BAZ

For development flow the following configuration properties are available to specify how to build the image locally

The following baseImage are in use at NTA

Configuration specific for Deployment Type "localTemplate"

Configuration specific for Deployment Type "template"

Common configuration for Deployment Types "template" and "localTemplate"

Note that resources and replicas have no default values for templates. If they are set they will be applied if not the value in the template will be used.

Configuration for job and cronjobs

For jobs and cronjobs you have to create an application that terminates when it is done and point to it using the normal groupId/artifactId:version semantics

Aditional configuration for cronjobs

Supported integrations

Jobs and Cronjobs can have

• secrets
• databases
• STS tokens
• mounts
• logging
• prometheus metrics

Enable deployment on special nodes

Some deployments may require nodes with extended properties, such as larger available memory. For the deployment to be able to deploy on special nodes they must be configured with nodeProperties.

Note: using nodeProperties should be in agreement with operations.

Exposing an application via HTTP

The default behavior is that the application is only visible to other application in the same namespace using its service name.

By using routes and CNAME entries, the application can be exposed in a cluster-independent way both on-premise and to Azure resources.

In order to control routes into the application the following fields can be used.

If tls is used the host of the route cannot include the '.' key, since we do not support wildcard TLS cert.

Route annotations are usable for template types, but you need to create a Service with name after the NAME parameter yourself.

Managing Secrets

In order to provide sensitive data to an application (i.e. passwords that cannot be stored directly in the configuration block of the AuroraConfig) it is possible to access Vaults that has been created with the ao vault command (see internal link https://wiki.sits.no/pages/viewpage.action?pageId=143517331#AO(AuroraOpenShiftCLI)-AOVault). You can access the vaults in two different ways; as a mount or via the secretVault option.

If a Vault is accessed via the secretVault option and the vault contains a properties file the contents of that file will be made available as environment variables for the application. Example;

PASSWORD=s3cr3t
ENCRYPTION_KEY=8cdca234-9a3b-11e8-9eb6-529269fb1459

If you want to mount additional Vaults or access vault files directly this can be done with mounting it as a volume. See the next section for more details.

Note that it is possible to fetch multiple files from the same vault, the svName must be different for each one and you must set name to the same.

The old way of specifying secretVaults (detailed below is deprecated). There will be a migration feature soon. This configuration pattern only suppored a single vault/file.

It is possible to use substitutions in keys/keyMappings but it should be used with care and doublechecked.

Mounting volumes

The combination of type=PVC and exist=true is not supported by policy. We do not want normal java/web applications to use PVC mounts unnless strictly neccesary.

NTA webseal integration

Note: Webseal integration is being replaced by AzureAD integration. You should user either one or the other, even though they can both be used during the transition from Webseal to AzureAD.

Webseal is used for client traffic from within NTA to reach an application. Internal tax workers have roles that can be added to limit who can access the application

If you want to use webseal with a template type you need to create a Service with default ports named after the name parameter

NTA AzureAD integration

When migrating from webseal to AzureAD integration, first leave in the webseal configuration. After the azureAD integration is set up, you will receive a mail telling you to remove the webseal configuration. This will ensure that your application will be available during the transition.

AzureAD is used for client traffic from within NTA to reach an application. Internal tax workers have roles that must be added to limit who can access the application. Use ATS for authorization against data.

Example:

azure:
    azureAppFqdn: "<service>-<affiliation>-<env>.amutv.skead.no"
    groups:
    - "list"
    - "of"
    - "security_groups"
    jwtToStsConverter:
        enabled: true

Note: this feature is currently in beta testing and should only be used in cooporation with the platform team.

NTA STS integration

STS certificate: An SSL certificate with a given commonName is used to identify applications to secure traffic between them

For v1 of the STS service use:

For v2 use:

NTA Dbh integration

dbh is a service that enables an application to ask for credentials to a database schema.

If there is no schema the default behavior is to create one.

It is possible to change the default values for this process so that each application that wants a database can just use the database=true instruction

If you want to change the default configuration for one application you need to use the expanded syntax

To share a database schema between multiple applications then one application must be defined as the owner of the schema. The <name> must be the same in the configuration files, and for applications that do not own the schema applicationLabel must be set and match the name of the application owning the schema.

The database property configuration should not be put in global or env files. For databaseDefaults should be used for database configuration for a whole or multiple environments. configuration that should be the same for all applications in an environment should be set in databaseDefaults placed in a global or env file.

NTA S3 integration

To use the S3 integration, a bucket needs to exist before enabling s3 in auroraconfig. Refer to internal documentation to see how a new bucket is created.

The config field objectArea(specified below) has the following acceptable pattern: lowercase characters, numbers, hyphen(-) and period(.).

It could be wise to set some defaults in your base configuration files. The s3Defaults are as follows:

The simplified syntax is as follows:

For expanded syntax the following applies:

Registration of alerts

Application specific alerts can be automatically registered by adding the following configuration.

Some configuration values can be set with defaults, these values will be used unless an alert-configuration overrides it. alertsDefaults can be set in the base file if they should be used for all instances of an application across all environments, or in the env file if they should be used for all applications in that environment.

Logging configuration

To configure logging it is necessary to add the logging configuration block to the aurora config. If the configuration is not specified then the application(s) will log via Splunk Connect to a default index log-ocp-<env>.

Note: Log files are expected to reside under /u01/logs

Simple configuration

A minimal configuration specifying the log index can be added to the configuration.

logging: # configuration block
  index: myapp-index # splunk index where logs will be indexed

Separate indexes

It is possible to define separate splunk indexes for different types of logs. Logs that are not specified explicitly will be indexed to the index specified in logging.index.

Available defined log types:

To configure a specific, of the available log types, then logging.loggers.<logname> must be configured ( replace <logname> with one of the log type names).

logging:
  index: myapp-index # splunk index where log will be indexed
  loggers:
    stacktrace: myapp-stacktrace-index # splunk index where stacktraces will be indexed
    audit_text: aud-myapp-index # splunk index where audit_text logs will be indexed

Separate indexes with custom file pattern

We have support for specifying custom file patterns if you do not follow the default patterns. We strongly advice you to use the default loggers config if possible. We do not allow custom sourcetypes, we currently support [_json, access_combined, gc_log, log4j]. If you need support for another sourcetype you need to contact us. When you use custom logging, you take full ownership and responsibility of capturing logs with correct file pattern. If you specify custom logging you cannot have the config fields logging/index or logging/loggers. For custom logging you have to specify one logger that is named application, see example below.

Custom logging:

logging:
  custom:
    application:
      index: openshift
      sourcetype: log4j
      pattern: "*-custom-app.log"
    custom-access:
      index: openshift
      sourcetype: access_combined
      pattern: "*-custom-aud.log"

Additional output

In addition to sending logs to splunk, we also support sending log data to an HTTP collector. This happens in addition to the data being sent to splunk.

Custom logging with additionalOutput set:

logging:
  custom:
    application:
      index: "openshift"
      sourcetype: "log4j"
      pattern: "*-custom-app.log"
    access:
      index: "openshift"
      sourcetype: "access_combined"
      pattern: "*-custom-aud.log"
    vso:
      index: "logg-collector-openshift"
      sourcetype: "log4j"
      pattern: "collector.log"
      additionalOutput:
        vso-output:
          type: "http"
          secretVault: "collector-credentials"
          host: "logg-collector.skead"
          port: "80"
          path: "/v1/collect"

secretVaults:
  collector-credentials:
    name: collector-credentials

The secretVault must contain the CUSTOM_OUTPUT_USERNAME and CUSTOM_OUTPUT_PASSWORD properties used to authenticate with the collector service.

Note: The HTTP collector is not provided by us, and is something you develop yourself.

Configuring tail input plugin for fluentbit

Refer to fluentbit docs for tail input plugin to see definition of configuration parameters we refer to in table below.

Configurable fields

By default, descriptive fields will be added to the messages logged by the application. It is possible to toggle these fields on or off.

Add fluent-bit sidecar container for additional types

Fluent-bit is only supported for types: [deploy, development], however it is possible to opt-in for the types [localTemplate, template, job, cronJob]. You are not guaranteed that it will work for all types and your specific use case. You might have to configure custom logging if the logfiles do not conform to the normal filenames.

logging:
  index: "openshift"
  enableForAdditionalTypes:
    localTemplate: true
    template: true
    job: true
    cronjob: true

Disable fluent-bit sidecar logging

Setting logging.index to an empty value will prevent the application from running with a logging sidecar. This can be useful in situations where a fluent-bit sidecar is unwanted, for example a job that may hang if the pod starts with a fluent-bit container.

logging:
  index: ""

Topology

Support for organizing the OpenShift topology view is available with the topology configuration.

Notes:

• All fields are optional.
• partOf can only hold one value.
• For which values to use in connectsTo see the description for name in Application files.

The partOf property is only used for visual grouping of deployments, Each project decide themselves how to use the visual grouping, and there are no pre-defined values.

The runtime property is used to select a display icon. For example when topology/runtime=spring-boot is set, the topology view will show a spring-boot icon. Supported icons are listed in the logos array in the link below (it is not necessary to include the icon- part of the name):

• https://github.com/openshift/console/blob/master/frontend/public/components/catalog/catalog-item-icon.tsx
• Alternatively supported icons can be found by right-click on the topology view and Add to project -> Container image and check the Runtime icon dropdown list.

The connectsTo property indicate which applications the deployment connects to in one direction (sends requests to). The topology view can only visualize connections in the same namespace.

The topology configuration will add the following labels and annotations to the deployment

• topology/partOf adds the label app.kubernetes.io/part-of=<config-value> on all resources belonging to the deployment.
• topology/runtime adds the label app.kubernetes.io/runtime=<config-value> on all resources belonging to the deployment.
• topology/connectsTo adds the annotation app.openshift.io/connects-to=['config-value'] on the DeploymentConfig.

Configure Maskinporten

Note: If maskinporten feature is disabled with simplified configuration or maskinporten/enabled then it must be explicitly re-enabled.

Configure Vertical Pod Autoscaling (VPA)

The Vertical Pod Autoscaler (VPA) in Kubernetes automates resource limits and requests for pods. It adjusts requests based on actual usage, optimizing resource allocation. VPA downscales over-requesting pods and upscales under-requesting ones. It maintains specified limit/request ratios for containers. This dynamic autoscaling improves resource utilization and application performance.

Note: When using VPA, ensure that the pods have well-defined resource requests and limits in their initial configuration. These values act as guidelines for VPA to adjust the resource requests later. While VPA doesn't strictly follow these initial values, it uses them as starting points to iteratively adjust resource requests based on real usage patterns. During autoscaling, VPA ensures that the new resource requests set for a pod do not exceed the specified resource limits, respecting the upper boundaries defined in the initial pod configuration. As a side note, we highly recommend setting minimumAvailableReplicas to a value of 2 or higher to avoid service disruption during scaling.

Warning: This feature cannot be used in combination with HPA.

Configure Horizontal Pod Autoscaling (HPA)

Horizontal Pod Autoscaling (HPA) is a powerful feature that allows you to automatically adjust the number of pods in your deployments based on specific resource utilization or custom metrics. By dynamically scaling the number of pods up or down, HPA ensures that your applications can handle varying workloads effectively.

The primary purpose of HPA is to maintain a balance between resource availability and application performance. When your workload experiences increased demand, such as a spike in incoming requests or data processing, HPA will automatically increase the number of pods to meet the demand and distribute the workload across multiple instances.

Conversely, during periods of low demand, HPA can scale down the number of pods to conserve resources and reduce unnecessary costs. This autoscaling capability is particularly useful when you have fluctuating workloads or unpredictable usage patterns.

HPA can scale pods based on different metrics:

Resource Utilization Metrics: HPA can scale pods based on the actual CPU or memory utilization of the running pods. 
You can set a threshold for CPU or memory utilization, and when the observed utilization exceeds that threshold, 
HPA will initiate scaling actions.

Custom Metrics: In addition to resource metrics, HPA supports scaling based on custom metrics. These metrics can be 
specific to your application and may include things like the rate of incoming requests, response times, or any 
other custom metric that you define.

External Metrics: HPA can also scale based on external metrics obtained from sources outside of the Kubernetes 
cluster. For instance, if your workload depends on an external service that provides metrics relevant to scaling 
decisions, you can configure HPA to use these external metrics.

It's essential to configure resource requests and limits for your pods to ensure HPA can function correctly with resource utilization metrics. By providing these values, HPA can calculate the scaling ratio based on the actual resource usage and the requested resources.

Example of common use case

hpa:
  minReplicas: 2
  maxReplicas: 10
  metrics: 
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 50
  - type: Resource
    resource: 
      name: memory 
      target: 
        type: AverageValue
        averageValue: 500Mi

This configuration snippet defines two resource-based metrics for HorizontalPodAutoscaler:

CPU Metric: It uses CPU resource and sets a target utilization of 50%.
Memory Metric: It uses memory resource and sets a target average value of 500Mi (megabytes).

More advanced example

hpa:
  enabled: true
  minReplicas: '2'
  maxReplicas: '10'
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: AverageValue
        averageValue: 500m
  behavior:
    scaleDown:
      policies:
      - type: Pods
        value: 4
        periodSeconds: 60
      - type: Percent
        value: 10
        periodSeconds: 60
      selectPolicy: Min
      stabilizationWindowSeconds: 300
    scaleUp:
      policies:
      - type: Pods
        value: 5
        periodSeconds: 60
      - type: Percent
        value: 12
        periodSeconds: 60
      selectPolicy: Max
      stabilizationWindowSeconds: 0

This configuration defines the following settings for HorizontalPodAutoscaler (HPA):

Metrics: The HPA uses the CPU resource and sets a target average value of 500 milli-CPU (mCPU).

Behavior: The scaling behavior includes both scaleDown and scaleUp policies.

    Scale Down Policies: It applies two policies to scale down the number of replicas:
        The first policy will scale down with at most 4 pods if the CPU utilization is below target for 60 seconds
        The second policy will scale down with at most 10% of the current replicas if the CPU utilization is below target for 60 seconds
        SelectPolicy: Min, select the policy with the smallest change in replica count.

    Scale Up Policies: It applies two policies to scale up the number of replicas:
        The first policy will scale up with at most 5 pods if the CPU utilization is above target for 60 seconds
        The second policy will scale up with at most 10% of the current replicas if the CPU utilization is above target for 60 seconds
        SelectPolicy: Max, select the policy with the largest change in replicas count.

    Stabilization Window: When the metrics indicate that the target should be scaled down the algorithm looks into previously computed desired states, and uses the highest value from the specified interval. For scale-down the past 300 seconds will be considered, for
    scale-up there is no stabilization window, and the application is scaled-up immediately when the threshold is reached. 

Warning: This feature cannot be used in combination with the VPA feature.

Configure the trace collector(Grafana Agent)

We use the Grafana Agent to receive, process, and export telemetry data, eliminating the need for multiple agents/collectors. It supports open source observability data formats (e.g. OTEL http, OTEL grpc, Zipkin) and integrates with Grafana Enterprise Trace solution. Using a collector alongside services enables quick data offloading and additional handling like retries, batching, authentication, and data enrichment. By having collectors work in tandem with our services, we achieve swift data offloading, minimizing any impact on the services' performance.

The Aurora configuration supports two operation modes for telemetry data collection. The first mode involves using an agent collector as a DaemonSet running on each node, while the second mode deploys the agent collector alongside the service as a sidecar container. For the majority of our users, the first approach should be sufficient and straightforward.

Note: this feature is currently only supported for the deployment types deploy, development, cronjob and job. The configuration will not be used on other deployment types, but will not fail on validation if configured.

Example

trace: true

In this example, we will expose the following environment variables: OTLP_GRPC_TRACING_ENDPOINT, ZIPKIN_TRACING_ENDPOINT, and OTLP_HTTP_TRACING_ENDPOINT. These variables are used to point to the nearest node collector, in the format IP:port.

By setting these environment variables correctly, the telemetry data will be directed to the appropriate collectors, It's worth noting that certain frameworks, such as Spring Boot, may require an additional step. When using these frameworks, it is essential to include the appropriate protocol prefix, such as "http://" or "https://", in the specified endpoint URL.

The second approach with the sidecar container is tailored for more advanced users who require greater control over the configuration and data flow. With the sidecar approach, users can fine-tune and customize the telemetry data collection process to suit specific requirements and optimize performance.

Currently, our support includes memory requirement tuning, but we anticipate the addition of more advanced features, such as data enrichment, in the near future. This solution will continue to evolve over time, adapting to the needs of development teams as they require more sophisticated functionalities. For more information about the supported capabilities in the Grafana Agent, please follow this link https://grafana.com/docs/agent/latest/flow/reference/.

Example

trace:
  sidecar:
    enabled: true
    resources:
      requests:
        cpu: 100m
        memory: 100Mi
      limits:
        cpu: 200m
        memory: 200Mi

In this example, we expose the following environment variables: OTLP_GRPC_TRACING_ENDPOINT, ZIPKIN_TRACING_ENDPOINT, and OTLP_HTTP_TRACING_ENDPOINT. These variables are used to point to the sidecar collector, with the format localhost:port. Just like the first approach, this may also require adding the appropriate protocol prefix.

PodDisruptionBudget - configure minimum available number of pods for high availability

A PodDisruptionBudget limits the number of pods that can be down at the same time. AuroraConfig supports configuring the minimum number of available healthy pods, that must be available during service operations on the cluster, for example cluster draining and scaling. For more details about disruptions and Pod disruption budgets see https://kubernetes.io/docs/concepts/workloads/pods/disruptions/

In AuroraConfig support for PodDisruptionBudget is implemented for minimum available pods, a PodDisruptionBudget resource will be created in the namespace when using this functionality. To use PodDisruptionBudget replicas must be at least 2. If replicas is below 2 or the deployment is paused, then the PodDisruptionBudget resource will not be created but a warning will be displayed. It is not possible to configure minimum number of available pods to be equal to or above replicas.

Minimal example - will create a PodDisruptionBudget with minimum 1 available healthy pod

replicas: 2
podDisruptionBudget: true

Minimum available example - will create a PodDisruptionBudget with minimum 3 available healthy pods

replicas: 8
podDisruptionBudget:
    minAvailable: 3

Example configuration

Simple reference-application

Below is an example of how you could configure an instance of the reference application

about.yaml

schemaVersion: v1
affiliation: paas
permissions:
  admin: [PAAS_OPS, PAAS_DEV]
logging:
  index: paas-test

reference.yaml

groupId: no.skatteetaten.aurora.openshift
artifactId: openshift-reference-springboot-server
version: 1
type: deploy
replicas: 3
sts: true
route: true
database: true
config:
  FOO: BAR

dev/about.yaml

cluster: dev

dev/reference.yaml

config:
  FOO: BAZ

The complete config is then evaluated as

schemaVersion: v1
affiliation: paas
permissions:
  admin: [PAAS_OPS, PAAS_DEV]
logging:
  index: paas-test
groupId: no.skatteetaten.aurora.openshift
artifactId: openshift-reference-springboot-server
version: 1
type: deploy
replicas: 3
sts: true
route: true
database: true
config:
  FOO: BAZ
cluster: dev

Applying template with NTA integrations

about.yaml

schemaVersion: v1
affiliation: paas
permissions:
  admin: [PAAS_OPS, PAAS_DEV]
logging:
  index: paas-test

sample-atomhopper.yaml

type: template
template: aurora-atomhopper-1.0.0
databaseDefaults:
  flavor: POSTGRES_MANAGED
database: true
route: true
parameters:
  FEED_NAME: feed
  DB_NAME: atomhopper
  DOMAIN_NAME: localhost

dev/about.yaml

cluster: dev

dev/sample-atomhopper.yaml

empty file

The complete config is then evaluated as

schemaVersion: v1
affiliation: paas
permissions:
  admin: [PAAS_OPS, PAAS_DEV]
logging:
  index: paas-test
type: template
template: aurora-atomhopper-1.0.0
databaseDefaults:
  flavor: POSTGRES_MANAGED
database: true
route: true
parameters:
  FEED_NAME: feed
  DB_NAME: atomhopper
  DOMAIN_NAME: localhost

Example configuration for alerts

Single application utv/sample-app.yaml

baseFile: "sample-app.yaml"
---
alerts:
  failed-connections:
    enabled: true
    delay: "2"
    connections:
      - "aurora"
    expr: "failed_connections > 5"
    severity: "critical"
    summary: "Connections has failed over 5 times"
    description: "Instance has had over 5 connection failures"
  duplicate-entries:
    enabled: true
    delay: "5"
    connections:
      - "aurora"
    expr: "duplicate_entries > 10"
    severity: "warning"
    summary: "Duplicate entries has been registered over 10 times"
    Description: "Application has registered over 10 duplicates"

Default alert configuration with override sample-app.yaml

---
alertsDefaults:
  enabled: true
  delay: "5"
  connections:
    - "aurora"

utv/sample-app.yaml

baseFile: "sample-app.yaml"
---
alerts:
  failed-connections:
    delay: "1"
    expr: "failed_connections > 5"
    severity: "critical"
    summary: "Connections has failed over 5 times"
    description: "Instance has had over 5 connection failures"
  duplicate-entries:
    expr: "duplicate_entries > 10"
    severity: "warning"
    summary: "Duplicate entries has been registered over 10 times"
    Description: "Application has registered over 10 duplicates"

Guidelines for developing templates

When creating templates the following guidelines should be followed:

• include the following parameters VERSION, NAME and if appropriate REPLICAS. They will be populated from relevant AuroraConfig fields
• the following labels will be added to the template: app, affiliation, updatedBy
• if the template does not have a VERSION parameter it will not be upgradable from internal web tools
• Each container in the template will get additional ENV variables applied if NTA specific integrations are applied.