Deploy an Application to a Environment

An Environment is a running instance of an Application. You can create multiple Environments from an Application, or from a version of an Application. Each Environment can contain all, or a subset of, the services defined in the Application and each Service can have one or more running instances, based on the scaling policies. Each Service instance is associated with a unique version of a Service.

When an Environment is created, the Application’s Scaling Policy, Routing Policies and its Gateway configuration are copied into the Environment. This allows you to change the Environment runtime policies, without modifying the application blueprint. Since the Environment has a copy of the information, only that Environment is impacted by changes.

To create a new Environment, provide a unique name, select an Environment Type, the Application and version. All other settings are optional.


The Environment Type and each Services’ Container Type are used to select the Host Group for placing Services.

While creating an Environment, you can optionally select which Services should be deployed, configure the environment dependencies, configure the Environment’s Scaling Policy, it’s Application Gateway Service, configure the Environment’s inter-service Routing Policy or create a Label Selector.

Label Selector

Service Instances are placed on hosts based on the Resource Selection Rules and the Service Affinity Rules that you have configured. You can further control on which host Service Instances are placed by using Labels and Label Selectors. You must first assign Labels to a Host or to a group of Hosts.


Labels are key/value pairs


When deploying an environment, you can define a Label Selector. Nirmata orchestration will only use the Hosts matching the Label Selector to run the placement algorithms.


The Label Selectors defined above indicates that the Customer and Catalog services must be placed on hosts configured with the Label storage-class=huge. The ratings service must be placed on hosts configured with the Label vm-type=public.

The following Label Operators are supported: . equals . not equals . in . not in . exists

When using the “in” or “not in” operators you can specify one or more values. When using the “exists” operator you don’t have to specify any label value.

Label Selectors can also be specified when adding a service to an already deployed environment.


Label Selectors can also be edited once the Environment is deployed:


Environment Dependencies

When deploying your environment, you can optionaly specify that your environment depends on other environments already deployed. To use this feature you need first to define the dependencies at the application level.

In the following example we a deploying the Staging Shopme environment which relies on the Staging MongoDB environment and the Staging Elasticsearch environment:


A Routing Policy is automatically added for each required environment. The Routing Policy default values are copied from the Application definition. Routing Policies can be edited once the environment is deployed.

Managing Services

Once the services are deployed, you can select an instance and view its logs, status, and also can stop, start, and delete the instance.


To launch multiple instances of the same service, you can edit the Environment’s Scaling Policy

Edit Scaling Policies

The Environment contains a Scaling Policy, that is copied from the Application, when the Environment is created. You can edit the Scaling Policy of an Environment to change the number of desired instances for a service:


Edit Gateway Routes

If the Nirmata Gateway Service is included in the Application blueprint, each Environment created from the Application will have one or more Gateway Service instances, and you can change the URL or DNS routes to manage traffic flows into the Environment:


Edit Routing Policies

Each Environment has one or more Routing Policies. You can edit the Routing Policy to manage traffic flows across service instances within the environment or across environments.

The Routing Policy defining the traffic flows within the environment is called ‘Internal’. The Routing Policies defining the traffic flows with the required environments are named using the name of the required environment. In the example below, the Shopme has 3 Routing Policies: . Internal: defines the traffic flows within the shopme environment . Staging-elasticsearch: Defines the traffic flows between Shopme and the Staging-elasticsearch environment . Staging-mongodb: Defines the traffic flows between Shopme and the Staging-mongodb environment:


To create a route, you can specify the from and to service names and versions and then can choose to allow or deny communication across those service instances.


Edit Update Policy

For each environment there is an update policy which allows you to control when service instances are upgraded. If Auto-Restart is enabled, service instances will be automatically restarted when a new image is available for that service. This will ensure that your services instances are always using the latest image. You can configure the restart interval and the quite period to mange the rolling upgrade. For automatic updates to work you will need Monitoring the Environment Routes or CI/CD Integration.


Deploy a new Version of a Service

You can add new versions of any Service, defined in the Application blueprint, to an Environment. This allows deploying and testing new features, and when used with the Gateway and Routing Policy enable powerful continuous delivery best practices such canary launches, and blue-green deployment.


If all versions of a Service have already been deployed, the dialog will show an error message and prompt you to use the Scaling Policy to manage the service instances.

Environment Access Controls

You can restrict access for an environment, to a role or a set of users. The Environment Access Control policy is inherited from the EnvironmentType. Once an environment is created, you can further customize the access control privileges for that environment, without impacting other environments.

For details on setting up access control, see Access Control.

Environment Update

You can update the entire environment in a single operation. You can speficied the new tag to apply to each of your services. The tags can be the same for all your services or they can be different. If you wish to update only a subset of your services, simply unselect these services. You can also specify what should happen if one of the service update fails:

  • Stop environment update: The system will stop the environment update at the firt failure.
  • Continue environment update: The system will try to update all you servvice even if errors occur.

Once an environment update is started you can monitor its progress.

_images/environment-update-monitor-1.png _images/environment-update-monitor-2.png

Monitoring an Environment

Nirmata collects and aggregates several statistic from each Service container. You can view these statistics (aggregated) at the Environment level, or for an individual Service instance:


To view statistics for an individual Service instance, simply click on the Service name in the table:


The Environment provides a logical view of an Application instance. You can also view physical host statistics, by drilling down to an individual host (select Host Groups -> <Cloud Provider> -> <Host>).


Monitoring the Environment Routes

When you deploy the Nirmata application gateway as part of your application, you can monitor the status of the routes you have configured.

The states associated to routes are:
  • Pending Data
  • Up
  • Down
  • Degraded

The route status is initially set to ‘Pending Data’ when the service is deployed. Once the first status report is received, the route status is set to either ‘Up’ or “Down’.

The application gateway starts monitoring the status of your services once they are in running state. In other words, the service health check must be succesful before the route status is evaluated.

A route status ‘Up’ indicates that the Nirmata application gateway is able to connect to your service using the route that you have configured.

A route status ‘Down’ indicates that the Nirmata application gateway is not able to connect to your service using the route that you have configured. There can be various reason why the route status is ‘Down’:

  • Networking issue between the instance running the application gateway and the instance running your service.
  • Security issue. The gateway is not authorized to communicate with your service.
  • The route is configuration is not correct.
  • Your service is not able to serve the configured route correctly.

A route status ‘Degraded’can be observed when a service is composed of multiple service instances. If at least one route to one of the service instances is ‘Down’ then the route status for the service is marked as ‘Degraded’. If all the route to all the service instance are ‘Down’ then the service route status is marked as ‘Down’.

Statistics are also provided to help you analyze the traffic patterns and errors within your application:

  • Error count
  • Total Connection count
  • Bytes in
  • Bytes out
  • Connection time
  • Response time

When a service is composed of multiple service instances, you can drill-down to the inspect the status of each route instance. in the following example the catalog service has 3 service instances. Two of the route instances are ‘Up’ and one is ‘Down’. As a result the overall service route status is ‘Degraded’.

For redunancy reason, it is common to have two application gateways deployed in the same environment.


In this situation, the route instance status panel displays the status of the route to each instance as seen for each gateway.


Docker Hub Integration

You can automate the update of your service instances deployed in an environment by setting up Nirmata as a web hook receiver in Docker Hub. To setup Nirmata as a web hook receiver in a repository, configure the below URL in Docker Hub:


You can find the tenant-id on the Settings->Account page in Nirmata web interface.

Once the web hook receiver is configured for a repository, Nirmata will receive a http POST request whenever the repository is updated. When Nirmata receives the POST request, all the environments that contain service instances using the image will be notified. To automatically update your services when an image is updated, you can enable the Update policy for your environment. When Update policy is enabled, Nirmata will perform a rolling upgrade of your services based on the Update policy settings


CI/CD Integration

You can also automate the update of your services instances deployed in an environment by integrating Nirmata with your build tools such as jenkins. To notify Nirmata, you can send a http POST request to the URL:


You can find the tenant-id on the Settings->Account page in Nirmata web interface.

In the http POST request, you need to include the following json:

  "owner": <reposotory owner>,
  "repository" : <repository name>,
  "user" : <user name>,
  "tag" : <image tag>

When the POST request is received, Nirmata will notify all the environments with service instances that are using this image. Automatic update will be performed if enabled in the Update policy. See Edit Update Policy for more details.