Using validation policies with Skycap


Skycap allows you to specify validation policies for any of your Formations. These are essentially tests that Stencils within a Formation need to pass before they can be rendered and used for deploying to your cluster(s).

These policies are a powerful tool for enforcing standards and patterns in your application. For example policies can ensure that a standard sidecar container is deployed with every service, or that third party components (e.g. MySQL) don’t automatically upgrade and break your code.

Validation policies in Skycap are written in Copper DSL, a domain specific language we created to make validating Kubernetes configuration files easier and more reliable. (Copper is open-source, so you can use it regardless of whether you use Skycap or not.)

What you’ll need

Before you start, please check you have the following:

In this example we’re using the same simple "hello world" project that we used in our Getting Started guides.

Understanding Copper DSL rules

Copper’s DSL is focussed on doing two things:

  1. Fetching values from your configuration files (i.e. Stencils)
  2. Checking they are valid (according to the rules you have specified)

Copper DSL has extensive documentation that will help you write your own rules when you are more comfortable with the process.

We also have another guide to help you more easily test and debug your rules.

For now we’re just going to use a single simple example rule:

rule NoPort5000 ensure {
    fetch("$.spec.ports[?(@.port == 80)].targetPort").first == 5000

This rule tells Copper to check that none of the stencils specified should be using port 5000 as a targetPort and refuses to render the Formation if it finds a stencil that breaks this rule.

Creating a validation policy

In order to create a validation policy within any Formation:

  1. Open your Cloud 66 dashboard and click on the name of the application in question
  2. Click on Formations in the right-hand panel
  3. Click on the name of the Formation which you want to validate (in our case “Hello World”)
  4. Click the “Policies” tab at the top of the main panel
  5. Click on the green + and then give the new policy a name (NoPort5000 would be sensible)
  6. Paste our demo rule into the code area.
  7. Type kind: Service into the Selector field (we’ll explain more about this later)
  8. Add a commit message and click Save policy

Testing a validation policy

Validation policies are called each time you render a Formation. To test that our new NoPort5000 policy is working, we simply visit the Formation detail page and click Render Formation.

Since our Hello World Formation does use Port 5000 in the helloworld_service.yml our Render process will warn us about this issue when we try to download our stencils.

What’s next?