Using the Cloudify Manager

Get the latest docs.

You are looking at documentation for an older release. Not what you want? Use the version selector on the top banner or click here.

Packaging a Blueprint

A blueprint can contain multiple files. These files can reside under a single directory with subdirectories or in an archive. Although the Cloudify CLI can manage the archiving process for you during upload, you might want to create archives prior to uploading the blueprint, so that you can keep them in a fileserver, upload them via the Cloudify Web UI, or send them to others. There are two methods for uploading a blueprint:

Uploading a Blueprint

Before you can deploy a blueprint, you must upload the blueprint to the Cloudify Manager. You can upload a blueprint using the CLI. You users can also upload using the Cloudify Console. Either use a blueprint that you have written or download an example blueprint to upload. Uploading a Blueprint using the Cloudify Console You can upload a pre-packaged blueprint archive through the Cloudify Console in tar, tar.gz, tar.bz, or zip formats.

Creating a Deployment

In order for Cloudify to deploy your application, it reads the uploaded blueprint YAML (the logical representation) and manifests a model called a deployment. A deployment is a “technical” drilled-down representation of your application. For example, if a blueprint describes a single server node that is defined to deploy multiple instances, the deployment will comprise the instances themselves, together with their unique identifiers. Creating a deployment does not actually create any resources, it simply generates a “physical” representation of your application from a “logical” (blueprint) representation and stores it in the database.

Configuring Multi-Tenancy

Multi-tenancy is a Cloudify Premium-edition feature that enables you to create multiple independent logical groups of resources as isolated environments on a single Cloudify Manager. A tenant is a logical entity that contains a group of Cloudify resources such as blueprints, deployments, executions, plugins and secrets. Using multi-tenancy is useful when you want to limit access to a specific set of data to a defined set of users. With the multi-tenant ability, you can create tenants and divide your Cloudify resources between them.

Executing Workflows

After you have created a deployment, you must execute the process that will implement your application’s actual manifestation in your selected environment. This process is achieved using the install workflow, which is the default workflow provided by Cloudify for deploying your application. You can create workflows for different types of actions such as deploying code, changing the infrastructure state, and even for overriding the default Install Workflow. Executing a Workflow via the CLI To execute a workflow run the following command.

Resource Visibility

The visibility of the resource defines who can see the resource. It can have one of the following values: private - The resource is visible to the user that created the resource, the tenant’s managers and the system’s admins. Only these users can see or use this resource. tenant - The resource is visible to all users in the current tenant. (Default value) global - The resource is visible to all users in all tenants across the manager.

Updating a Deployment

With Cloudify, you can update a deployment. For example, if you have a sizable, complex deployment of webservers and databases, and you need to add a new type of database that must be connected to some of the existing webservers, you would update your deployment. Updating a deployment means that, instead of creating a new deployment from a blueprint to add the new nodes, you add and connect them in your existing deployment, while retaining the state of your current settings.

Deleting a Deployment

After you have uninstalled an application, you can delete it from Cloudify Manager. After you uninstall an application, all of its static and runtime properties are still stored in the Manager’s database and the deployment-specific agents continue to consume resources on the Manager. Deleting a deployment enables you to clean the environment of those excess artifacts. To delete a deployment from the manager with the CLI, run: cfy deployments delete nodecellar The delete options are:

Deleting a Blueprint

Deleting a blueprint removes its model from the database and deletes its resources from the fileserver. Deleting a blueprint does not delete the deployments created from that blueprint or resources of those deployments. To delete a blueprint from the manager with the CLI, run: cfy blueprints delete [OPTIONS] BLUEPRINT_ID The delete options are: -v, --verbose - Show verbose output. You can supply this up to three times, for example -vvv. -t, --tenant-name - Specify the tenant where the blueprint in stored.

Using Clusters to Provide High Availability

If you have a Premium version of Cloudify Manager, an admin user can create a cluster of Cloudify Managers to enable high availability. It is recommended that you have three Cloudify Managers in a cluster for the following reasons: To ensure resilience in the case of a failure To reduce the probability of multiple hot standbys being activated as the active Manager in the event of a network failure (split-brain.

Using the Secrets Store

The secrets store provides a variable storage (key-value pairs) for data that you do not want to expose in plain text in Cloudify blueprints, such as login credentials for a platform. When you create a secret, the key value can be a text string or it can be a file that contains the key value. With the secrets store, you can make sure all secrets (for example credentials to IaaS environments) are stored separately from blueprints, and adhere to isolation requirements between different tenants.

Maintenance Mode

When in maintenance mode, Cloudify Manager activity is suspended. It rejects all requests, and does not perform any action other than to display the status of the Manager and it’s version, and to execute sub-commands of the maintenance mode. Cloudify Manager has three maintenance states, activated, activating, and deactivated. To view the current maintenance state of the Manager, run cfy maintenance-mode status. The state is also displayed when you run cfy status (so long as the state is not deactivated).

Broker Security (RabbitMQ)

Cloudify uses RabbitMQ as its broker, and supports configurable security. Authentication When installing, the Cloudify Manager must be provided with credentials for RabbitMQ. These will use default values if not overridden in the inputs. Username It is suggested that you change the username to something other than the default. It is recommended that you use only upper and lower case letters and numbers for the username. The username can be set using the rabbitmq_username input to the manager blueprint.

Service Logs

This page briefly explains the different log files that will be available on the Cloudify Manager host. Running cfy logs download will download a tar gzipped file containing most log files discussed in this page. REST The REST service runs using the Flask web framework on top of the Gunicorn HTTP server. Each of these layers has its own logs. Flask Log The Flask logger is used by the REST service to write custom logs.

Snapshots

A snapshot is a .zip file that contains all relevant data describing the state of a Cloudify Manager the moment the snapshot is created on this Manager. There are four basic operations associated with snapshots: creating, downloading, uploading and restoring. For detailed information about snapshot-related CLI commands, click here. Common use cases for snapshots are: Backing up the Manager to be able to restore its state later on, should it become inconsistent or broken for whatever reason.

Managing Roles

What are Cloudify roles? A role is a group of permissions that are required by a certain type of user to work in Cloudify. You can assign roles to a user to give that user the permissions that are defined in the role. You can also assign roles to user groups to give the permissions that are defined in the role to all of the users in the group. If a user is a member of more than one group, then the user has all of the permissions in the role defined for the user specifically, in addition to all of the permissions defined for all of the roles the user is assigned to via groups.

Managing Users

Cloudify provides a user management mechanism, so you can define different users with different permissions, and upon login perform authentication and authorization to control the users’ access to resources. The users can be either defined and managed in Cloudify itself, or you can configure your Manager to integrate with an LDAP-based user-management system. You must select one of these options, as you cannot do both, and you must configure your manager accordingly upon installation or immediately afterwards, when no actions were performed on it yet.

Integrating with LDAP

Okta Authentication

Cloudify enables integration with your local Okta system to authenticate users. In this guide, the configuration steps required to enable Okta authentication are described. openssl version To enable Okta integration, the openssl package on Cloudify Manager needs to be of version 1.0.2. If you are running a Cloudify image this is already the case, however if you are installing make sure to update the openssl package prior to the Okta configuration.

Insights Widget

Cost and Usage Analytics for Cloud Insights shows analytics of cloud platform costs and usage. With the information shown in the Insights widget, business owners and IT managers can make decisions to control and reduce usage costs for their single, multi-, and hybrid-cloud infrastructure. When you install Insights and add the Insights widget to the Cloudify Dashboard, the widget gives you an end-to-end environment monitoring and orchestration solution, so that you can make the best decisions regarding your resources based on the most critical considerations.