Policies

Nirmata offers a rich set of policies that can be used to decouple environment specific information from application definition. This allows your application to be more portable across clusters and across cloud providers.

Here is a summary of the available policies. Each one of these is described in more detail in the sections below.

Policy Description
Config Maps Used to provide environment specific configuration for your applications
Secrets Used to provide environment specific secrets for your applications
Patch Policies Used to override properties in the application configuration based on the environment
Cluster Policies Used to create new Kubernetes Clusters

Config Maps

Config Map policies is used to provide environment specific configuration for your applications. For example, if you have an application that uses a proxy such as nginx and you want to enforce specific configuration in different environments, e.g. Development vs Production, you can use the Config Map policy to provide the configuration instead of creating and managing different application manifests. This makes your application manifests more portable.

Creating a Config Map Polcy

To create a config map policy, you need to provide:

  • Rank: Specifies the order in which this policy is processed
  • Name: Name of the policy
  • Application Selector: Selects the application to which this policy will be applied
  • Data: Configuration key/value pairs that should be added to your application.

Secrets

Secrets policies is used to provide environment specific secrets for your applications. For example, if you have an application that uses a database and you want to enable different secrets in different environments, e.g. Development vs Production, you can use the Config Map policy to provide the secrets instead of creating and managing different application manifests. This makes your application manifests more portable.

Creating a Secret Polcy

To create a secret policy, you need to provide:

  • Rank: Specifies the order in which this policy is processed
  • Name: Name of the policy
  • Application Selector: Selects the application to which this policy will be applied
  • Data: Secret key/value pairs that should be added to your application.

Patch Policy

A patch policy allows you to override settings in your Kubernetes Resource manifests for a selected namespace. For example, if you want to use specific loadbalancer settings for certain applications you can configure a patch policy for the Service Resource to add annotations for Load Balancer settings.

To create a patch policy, you need to provide:

  • Name: Name of the policy
  • Resource Type: Kubernetes resource type
  • Namespace Selector: Selects the namespace to which this policy will be applied
  • Patch Operations: The operation that should be performed on the selected resource

To add a patch operation, you need to provide:

  • Path: The path for the property in the Kubernetes resource (e.g. /metadata/annotations/service.beta.kubernetes.io/aws-load-balancer-connection-idle-timeout)
  • Operation: The operation that needs to be performed. Possible operations are: add, replace, remove
  • Value Type: The type of the value. Possible types are: text, number, json string
  • Value: The actual value to apply

Cluster Policy

A cluster policy is used to define the configuration of your cluster. For details of how to create a cluster policy, go to (see Cluster Policies.).