An Environment is a logical grouping of applications to which you can apply policies and common configuration. You can run an application in several Environments. Typically environments are created for lifecycle phases in you delivery pipeline (e.g. dev-test, staging, production).
You can create several environments on the same Kubernetes cluster, and each environment is fully contained in a cluster.
To create a new Environment, provide a unique name, select the Kubernetes Cluster for this environment. You can also choose an Isolation Level for the environment.
After the Enviroment is created, you can optionally configure access controls, update policies, and other settings for your Environment by selecting the gears icon.
The Isolation Level of Namespace per Application will run each new instance of an application in a new namespace. Choose this level when you want to run multiple copies of the same application in an environment. The Isolation Level of Shared Namespace creates a single namespace for your environment, and all applications will run in the same namespace.
You can restrict access for an environment, to a role or a set of users. Once an environment is created, you can further customize the access control privileges for that environment, without impacting other environments.
The Environment Update Policy allows you to manage how changes in the Application definition are handled. You can choose to be notified of changes, or you can allow changes to be automatically applied to the applications in the environment.
Once an application is running, you can select it to get complete visibility and manage any of its components.
From the main application view you can drill-down into components, and even individual containers.
When an application is modified in the Catalog, Nirmata will propogate the changes to each running instance of the application. The changes will be processed based on the Update Policy of each environment. If the Update Policy is set to “View” a notification is shown when changes are available. You can then view the changes and decide to accept or reject them.
You can scale Pods for your Deployments or StatefulSets in a running Application. Simply select the scaling icon next to a component, or at the top right of the components table and set the desired replica counts.
Nirmata automatically tracks and correlates all user and system changes made to applications. You can view all activity for an application in the activity panel:
Nirmata collects and aggregates several statistic from each Pod and automatically aggregates them by components and applications. You can view these statistics (aggregated) at the application level, or for an individual resources:
Application Events & Tasks¶
Nirmata records all Kubernetes tasks performed (e.g. API calls) and also records events received from Kubernetes. This makes it very easy to troubleshoot application issues:
Using Nirmata, you can launch a remote shell into an application container without requiring complex VPN or host access. To launch a Cloud Shell navigate to the “Running Containers” panel and click “Launch Terminal”:
This action opens a new browser window with an embedded shell:
You can also stream a containers log (STDOUT and STDERR) output, by selecting the “View Logs” action:
Containers can exit due to lifecycle events or due to failures. In some cases, Pods may appear to be running but have had several container restarts. In addition to showing the Pod restart counts, Nirmata also gathers exited container logs and container details for easy troubleshooting.
If a resource controller has encountered container exits, there will be an indicator next to it showing the last container exit time.
You can drill-down on the resource to view the logs and container details: