Using the Conductor Manager

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 Conductor 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 Conductor Management Console, or send them to others. Single YAML file blueprints Conductor Management Console supports single YAML file blueprints.

Uploading a Blueprint

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

Creating a Deployment

In order for Studio Conductor 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 Studio Conductor 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 Studio Conductor Premium-edition feature that enables you to create multiple independent logical groups of resources as isolated environments on a single Conductor Manager. A tenant is a logical entity that contains a group of Studio Conductor 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.

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 Studio Conductor 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 Studio Conductor, 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 Conductor 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 Conductor Manager, an admin user can create a cluster of Conductor Managers to enable high availability. It is recommended that you have three Conductor 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 Studio Conductor 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.

Maintenance Mode

When in maintenance mode, Conductor 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. Conductor 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)

Studio Conductor uses RabbitMQ as its broker, and supports configurable security. Authentication When installing the Conductor 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 Conductor 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 Conductor Manager. cfy logs download requires SSH access to your Conductor 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 Conductor 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 Studio Conductor roles? A role is a group of permissions that are required by a certain type of user to work in Studio Conductor. 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.

Managing Users

Conductor 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

Studio Conductor 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 Studio Conductor itself, or you can configure your Conductor 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, Studio Conductor system role membership should be configured using user-groups.

Okta Authentication

Studio Conductor 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 Conductor Manager needs to be of version 1.0.2. If you are running a Studio Conductor image this is already the case, however if you are installing Studio Conductor make sure to update the openssl package prior to the Okta configuration.

External Authentication

Overview Studio Conductor 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 Studio Conductor 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 Conductor 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.