Schema Compiler

Pligos heavily relies on yaml configurations. In order to compile one set of configurations into different contexts (for example CI,dev,prod) pligos comes with it's own simple schema language to describe the context. The idea is to create a single helm starter that supports a big set of your services. Services than differ only in their templating input, or the {values.yaml,dependencies.yaml} files. Have a look at the examples in the examples/ directory for a more comprehensive use-case.

Pligos supports the following basic types: string, numeric, bool, object. Example:

# schema.yaml
context:
  pullPolicy: string
  useTLS: bool
  applicationConfig: object
  podInstances: numeric

# pligos/example/values.yaml -- this is your actual service configuration, define this for all your services individually
contexts:
  dev:
    pullPolicy: Always
    useTLS: true
    applicationConfig:
      fixture:
        user: "John Doe"
        balance: "10$"
    podInstances: 1

# helmcharts/example/values.yaml -- this file will be generated by pligos
pullPolicy: "Always"
useTLS: true
applicationConfig:
  fixture:
    user: "John Doe"
    balance: "10$"
podInstances: 1

As mentioned above pligos allows defining different contexts (dev, prod, ...). Each context needs to be set under the contexts property in the service configuration. The contexts can be applied to different schema definitions.

# dev/schema.yaml -- the schema definition for the dev context
context:
  environment: string
  srcPath: string

# prod/schema.yaml -- the schema definition for the prod context
context:
  environment: string

# pligos/example/values.yaml
contexts:
  dev:
    environment: dev
    srcPath: /home/johndoe/src/
  prod:
    environment: prod

# helmcharts/dev/values.yaml
environment: dev
srcPath: /home/johndoe/src/

# helmcharts/prod/values.yaml
environment: prod

However the true power of pligos comes through custom types, which can be instantiated and composed in the service configuration.

# schema.yaml
route:
  port: string

container:
  route: route

context:
  container: container

# pligos/example/values.yaml
route:
 - name: http
   port: 80

container:
 - name: gowebservice
   route: http

contexts:
  dev:
    container: gowebservice

# helmcharts/example/values.yaml
container:
  route:
    port: 80

Notice that in the service configuration the instances are referenced by their name. name is a special property in pligos which is used for referencering configuration instances (such as the gowebservice container) and mapped types. More to mapped types later.

Additionally the language supports the meta types repeated, mapped, embedded and embedded mapped which can be applied to any custom, or basic types. Let's start with an example for repeated instances.

# schema.yaml
container:
  name: string
  command: repeated string

context:
  container: repeated container

# pligos/example/values.yaml
container:
 - name: nginx
   command: ["nginx"]
 - name: php
   command: ["php-fpm"]

contexts:
  dev:
    container: ["nginx", "php"]

# helmcharts/examples/values.yaml
container:
 - name: nginx
   command:
    - nginx
 - name: php
   command:
    - php-fpm

Repeated allows specifying a list of any type. In the example we have a list of container, as well as a property command which is a list of string. Next, beside lists, pligos also allows you to define maps.

# schema.yaml
route:
  name: string
  port: string
  containerPort: string

context:
  routes: mapped route

# pligos/example/values.yaml
route:
 - name: http
   port: 80
   containerPort: 8080

contexts:
  dev:
    routes: ["http"]

# helmcharts/example/values.yaml
routes:
  http:
    port: 80
    containerPort: 8080

Notice that, although the configuration defines an array of routes, pligos yields a map, as shown in the the output. Maps can be created using the mapped meta type.

Up until this point all custom types appeared under some key in the output. However, this is not always the desired behavior. In order to embed the types' properties into the parent embedded types can be used.

# schema.yaml
rawValues:
  values: embedded object

context:
  rawValues: embedded rawValues

# pligos/example/values.yaml
rawValues:
 - name: devenvironment
   values:
     mysql:
       user: testuser
       password: asdf

contexts:
  dev:
    rawValues: devenvironment

# helmcharts/example/values.yaml
mysql:
  user: testuser
  password: asdf

Similarly the instance can be embedded using any arbitrary key using embedded mapped types.

# schema.yaml
dependency:
  port: string
  hostname: string

context:
  dependencies: embedded mapped dependency

# pligos/example/values.yaml
dependency:
 - name: mysql
   port: 3306
   hostname: mysql

contexts:
  dev:
    dependencies: ["mysql"]

# helmcharts/example/values.yaml
mysql:
  port: 3306
  hostname: mysql

Just as with mapped types, the name property is used to embedd the type instance into the parent.