Using the Cloudify Manager

Packaging a Blueprint

A structure of blueprint can be simple with one YAML file only, or complex with multiple YAML files, subfolders and other resources. The blueprint should be archived before uploading them to Cloudify Manager via Cloudify Management Console. The Cloudify CLI can manage the archiving process for you during upload, or upload existing archive. Also the archive is needed to upload the blueprint to a marketplace, or a storage cloud.

Uploading a Blueprint

As a first step a blueprint should be uploaded to the Cloudify Manager. Deployment services and deployment environments are spinned up from uploaded blueprints. The blueprint can be uploaded to the Cloudify Manager with Cloudify CLI, Cloudify Management Console, or Cloudify API. The blueprint can be provided as an archive, or a link to github site, or just a YAML file. > Single blueprint YAML file can be uploaded without packaging them through the Cloudify Management Console.

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.

Actionable Events (Hooks)

Overview Actionable Events (or Hooks) allow you to register actions that will be triggered after certain Cloudify events. The hooks are defined in a configuration file, no hooks are handled by default. When the specified event occurs, the specified action will be triggered. Configuration To enable this feature edit /opt/mgmtworker/config/hooks.conf file with the following parameters: Parameter Description event_type The event type you want to hook the action, can be one of the following: workflow_started, workflow_succeeded, workflow_failed, workflow_cancelled, workflow_queued implementation A path to plugin task or an importable function inputs The arguments to be passed to the function When the implementation is a plugin task, the plugin should be uploaded to the manager (managed plugin) and with central_deployment_agent executor.

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, which serves multiple purposes: - Changing the deployment topology: for example, adding a new type of database to an existing deployment of webservers and databases. - Changing the settings of existing nodes: for example, resizing a volume, or changing the size of a VM instance. - Updating the real state of the provisioned resources to match the blueprint. For example: after manually resizing a volume by using a cloud provider’s console, run update to bring the volume back to the state described in the blueprint.

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. Notice that blueprints that are used in other blueprints are protected for deletion until it has no users or it’s deleted with the force flag. To delete a blueprint from the manager with the CLI, run: cfy blueprints delete [OPTIONS] BLUEPRINT_ID The delete options are:

Sharing a Blueprint

About For enabling a fully shareable blueprint or a resource this two abilities were added: importing a catalog blueprint and adding a namespace context to any import available resource. With those two it is possible to share any common blueprint definitions, from a simple data types definitions through an architecture common pattern (like creating an openstack VM with all of its requirements) and up to entire micro-services that are found across in several services.

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 secured 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. The values of the secrets are encrypted in the database. We use the Fernet encryption of cryptography library, which is a symmetric encryption method that makes sure that the message encrypted cannot be manipulated/read without the key. When you create a secret, the key value can be a text string or it can be a file that contains the key value.

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, RabbitMQ credentials can be provided in the configuration file before running cfy_manager install or cfy_manager configure. The default location of this configuration file is /etc/cloudify/config.yaml. 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.

Service Logs

This page briefly explains the different log files that will be available on the Cloudify Manager host. Downloading the logs Running cfy logs download will download a tar gzipped file containing the log files discussed in this page. This archive will be vital when requesting support with your Cloudify Manager. cfy logs download requires SSH access to your Cloudify Manager machine. This means that the SSH key and the SSH username must be set in your CLI profile.

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.

Integrating with LDAP

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 Cloudify Manager to integrate with an LDAP-based user-management system. You must select one of these options, as you cannot do both. If LDAP integration is enabled, Cloudify system role membership should be configured using user-groups.

Okta Authentication

Cloudify enables integration with your local Okta system to authenticate users and provide Role-Based Access Control. This guide describes the configuration steps required to enable Okta authentication. Other SAML 2.0 authentication solutions can be integrated with Cloudify. However, only Okta is tested and officially supported. 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 Cloudify make sure to update the openssl package prior to the Okta configuration.

External Authentication

Overview Cloudify lets you extend the user authentication mechanism so that you can support different external authentication services. You can authenticate users with the basic username/password support in Cloudify or you can configure your Manager to integrate with an external authenticator, such as an LDAP-based user-management system. External authentication is an extension to the Cloudify Manager not included in the standard Manager installation. To support a new external authentication mechanism, you must add a dedicated module in the specified format to a specific location in the Manager and restart the REST services.