Policies

Nirmata offers a rich set of policies that map applications to resources, and control how applications are placed and managed. This abstraction allows proper separation of application definitions from the infrastructure.

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

Policy Description
Resource Selection Controls which Host Groups and Placement types are used for Applications, Services, and Environments
Host Scaling Defines the conditions upon which hosts must be create or delete automatically
Environment Types Defines available environment types with optional image labels and update policies
Container Types Defines available container types with optional CPU and memory limits

Resource Selection

Resource selection rules select which Host Group(s) are used for placement as well has the type of placement to be used (sequential versus available memory). Rules are selected based on the container type associated with the Service being placed and the type of the Environment being created. If multiple rules match these two criteria, the following steps are applied to select a host:

  1. Rules are sorted by rank, in ascending order i.e. a lower number is considered the higher rank
  2. Host Groups from all rules with the same rank are treated as a pool, and the best Host is selected based on the placement type
  3. If no hosts are available in the highest rank, the next rank is processed

A Resource Selection rule can also specify a minimum. A minimum indicates how many instances of a Service must be placed in the Host Group before other Host Groups from the same rule, or other rules of the same rank, are used. This is useful for managing availability across regions. An AWS specific use case for the minimum is when spot instances are used, in which case you can specify a minimum count for rules that select Host Groups with on-demand, or dedicated instances, to gaurantee service availability when spot instances are not available.

There are are two types of placement supported:

Placement Description
Available Memory The host with the highest amount of memory is selected first.
Sequential The host with the smallest amount of memory is selected first

Sequential placement is used to minimize the number of hosts required to create environments. Available Memory placement is used to take full advantage of all the hosts available to the user.

The placement type is not strongly enforced as other placement criteria can take precedence. For instance, port collision avoidance and affinity rules may dictate to select a different host than the one selected based on the placement type.

Creating Resource Selection Rule

A default Resource Selection Rule, that matches all containers and all environment types is created in a new account. You can create additional rules at any time:

_images/resource-selection-rules.png _images/create-resource-selection-rule.png

Updating Resource Selection Rule

Once created, resource selection rules can be edited. The modified rule will only take effect when a new environment is created, or when new services instances are deployed in an existing environment.

Host Scaling

Host Scaling is one of the features you can use to optimize your cloud resources utilization. Host Scaling Rules can be defined to control when new Hosts must be created due to an increase of a Host Group utilization. A Host Scaling Rule also defines when empty hosts can be removed.

The Host Scaling features works with all the types of Cloud Providers except Other and AWS Auto Scaling Group & AWS Spot Instances. You can use the host auto-scaling feature on AWS when using a Launch Configuration.

Creating a Host Scaling Rule

The Host Scaling wizard has 3 sections. The first section is use to define the general parameters

_images/create-host-scaling-rule-general-setting.png

The first parameter is the Auto Scaling flag. You can decide to temporarily disable a specific rule by un-checking the Auto-Scaling flag. When the rule is disabled, none of its parameters apply anymore, not event the minimum number of hosts nor the maximum number of hosts.

The second parameter is the name of the rule.

The last parameter is the list of Host Groups to which this rule applies. You must specify at least one Host Group.

The next section of the wizard is used to specify when new hosts must be added the Host Group.

_images/create-host-scaling-rule-scale-up.png

The first parameter is the scale up Host Group utilization threshold. A new Host is added to the Host Group when the total memory allocated in a Host Group exceeds this threshold.

The second parameter is a cooldown period expressed in seconds. A new Host is added to the Host Group if the utilization threshold is exceeded for at least the time defined by this parameter. If you want to scale up your Host Group as soon as the utilization threshold is exceeded then set this parameter to zero. The cooldown period is used to avoid adding and removing Hosts within a short period of time when the utlization osiliates around the threshold.

The last parameter defines the maximum number of Hosts that can be part of a Host Group. Hosts in failed state or not connected are not taken into account.

The last section of the wizard is used to specify when Hosts must be removed from the Host Group.

_images/create-host-scaling-rule-scale-down.png

The first parameter is the scale down Host Group utilization threshold. An empty Host is removed from the Host Group when the percentage of memory allocated in the Host Group moves below this threshold. An empty host is a host with no managed containers. The scale down Host Group utilization threshold must be equal or less than the scale up Host Group utilization threshold.

The second parameter is a cooldown period expressed in seconds. An empty host is removed from the Host Group if the utilization stays below the utilization threshold for at least the time defined by this parameter.

The last parameter defines the minimum number of hosts that can be part of a Host Group. Hosts in failed state or not connected are not taken into account.

Environment Types

Environment types are used to categorize application environments. An environment type can represent a stage in a code delivery pipeline e.g. as ‘Development’, ‘QA’, and ‘Test’ or can even be used to categorize types of customers e.g. Bronze, Silver, Gold. You can define multiple environment types and then use these types in policies like Resource Selection and Scaling & Recovery.

In a new account, there are four predefined environment types that represent common stages in a code delivery pipeline:

  • Dev: developer sandboxes that can accept any image and promote to the Test environment type
  • Test: test / QA environments that only accept images tagged with the prefix TEST and promote to the Staging environment type
    • Staging: system test environments that only accept images tagged with the prefix STAGE and promote to the Staging environment type
    • Production: production environments that only accept images tagged with the prefix PROD
_images/environment-types-table.png

You can customize these types, or delete and define your own environment types.

The optional Accept Tag and Promote Tag fields control how container images are managed across environments. These fields work together with the Update Policy and the Environment’s Promote and Update actions to allow end-to-end automation of your DevOps processes.

Accept Tag

The optional Accept Tag controls which images are accepted into an environment of this type. If not specified, all images are accepted. If specified only images that are prefixed with the specified tag are accepted.

For example, the predefined Production environment type will only accept tags like PROD_latest or PROD_20150614_101231

Promote Tag

The optional Promote Tag controls how images are promoted out of an environment of this type. If not specified, the Promote action is disabled. If specified, the Promote action will generate image tags that are prefixed with this tag.

For example, when the Promote action is requested for a Service Instance in an environment of the predefined Staging environment type, two new images tags will be created for the Service’s image: PROD_latest or PROD_20150615_081054

Update Policy

The Update Policy manages how new images that are allowed for the environment are handled, to either result in an automated update or a user notification. The Update Policy works in conjunction with the Allow Tag defined for the environment type. If the Environment Type has an Allow Tag defined, only new images tagged as {TAG}_latest will be processed (where {TAG} is the user specified allow tag). If the Environment Type does not have an Allow Tag images with the latest tag will be processed.

If you enable auto-restarts, a rolling upgrade will be automatically performed when a new image that is allowed for the environment type, is detected. Otherwise a notification is shown on the Service Instances that require an upgrade.

The Quiet Period controls how many seconds to wait before the upgrade is started, and the Restart Interval controls how many seconds to wait between upgrades of Service Instances.

Access Control

You can configure access controls on an Environment Type. Access controls can be used to restrict environment access to a subset of users, and also control which users can create environments of a type. When new environments are created, they inherit the configured access controls from the environment type. If needed, you can also customize access controls in a deployed environment.

The access provided to a user can be of the following types:

  • Read Only Access: the user can view created environments and running services, but cannot modify environment settings or manage the services.
  • Read Write Access: the user can create new environments, view existing environments, modify environment settings, and manage services.

When access control is enabled, you must explicitly add rules for each user role (or individual user) that should be allowed access. Users who do not match the access control rules will not have any access i.e. they will not see the environment type, not be able to create new environments of that type, and also will not see any existing environments created from the environment type.

If both the user’s role and the user’s email are configured in the access control rules, the rule with the email will be used.

In the example below, users of type Administrator and Platform have read write access, and users of type DevOps have read only access.

_images/access-controls.png

Container Types

When defining the blueprint of an application, users must associate a container type to each service. For a new account, four container types are available:
  1. 4GB container type
  2. 2GB container type
  3. 1GB container type
  4. 512MB container type

Users can create as many container types as they want. Container Types can optionally specify memory limits and CPU shares.

_images/create-container-type.png

Container type are characterized by the following parameters:

Parameter Description
Name Logical name for this container type
Description Short description specifying the intent of this container type
CPU Shares Number of CPU shares required to run the associated service. Ranges from 1 to 10.
Memory Memory (MB) required to run the associated service.