Login and API access

The containers in the appliance are configured to use localhost networking, which means they all share the host’s network interface(s), and can thus be reached on the hosts’ IP address(es) at the following ports:

• Keystone – 5000
• Coriolis API – 7667
• Web UI – 80/443 – port 80 automatically escalates to HTTPS on 443, the self-signed HTTPS certificate is unique to the appliance

Technical details and container components

The Coriolis appliance is built on top of an Oracle Linux 7 or Ubuntu 18.04 host, with all of the services required to run or support Coriolis being deployed and run as Docker containers.

The OpenStack components Coriolis leverages (Keystone for multitenancy, and Barbican for secret management) and other supporting services (such as RabbitMQ and MariaDB) are deployed using Kolla.

The table below represents the output of the docker ps command (which lists all the containers) on one of our Oracle Linux 7-based appliances, and it will be used as an example in the following tutorial:

Docker containers in the Coriolis appliance

The containers for each of the Coriolis services are the following:

• coriolis-api – container hosting the Coriolis API service
• coriolis-conductor – container hosting the Coriolis conductor service, which connects the Coriolis components
• coriolis-worker – container for the Coriolis worker service, which interacts with the source/target clouds and executes the tasks needed to perform the migration/replication
• coriolis-web-proxy – container running an Apache service serving as a proxy for the Coriolis UI. All API requests for the underlying Keystone/Barbican/Coriolis API should be proxied through this container
• coriolis-web – container hosting the Coriolis UI
• coriolis-replica-cron – container used for the Coriolis replica functionality
• coriolis-logger – container with the centralized Coriolis logging component. It used influxdb backend.
• coriolis-licensing-server – container running the licensing server

When running docker commands, the containers may be referenced simply by their names (coriolis-api, coriolis-conductor, etc…)

The rest of the supporting services are also deployed as containers using Kolla:

• keystone – container running the OpenStack identity service which is used by Coriolis
• barbican_worker – container running the Barbican worker – Barbican is an Openstack service that is used to store sensitive data such as cloud connection info
• barbican_keystone_listener – container for the Barbican Keystone listener
• barbican_api – container for the Barbican API
• rabbitmq – the container hosting a RabbitMQ server
• mariadb – the container hosting the database
• cron – container for the time-based job scheduler
• kolla_toolbox – contains the Kolla utilities
• fluentd – container running the logging service for all services deployed by Kolla (NOT including the Coriolis components) 
• memcached – container running Memcached 

Editing the configuration of the Coriolis services

In the appliance, the Coriolis configuration directory (/etc/coriolis) is mounted directly into each of the Coriolis containers. Thus, the configuration file may be edited directly on the host as such:

Editing the Coriolis configuration file

After any change to the Coriolis configuration, please remember to restart the containers with the Coriolis components by running the following:

Restarting the Coriolis service containers

$ for c in api conductor replica-cron worker; do docker restart coriolis-$c; done

Updating the Coriolis components

Due to the new container-based delivery methods used, any updates to one of the Coriolis components only require the pulling and redeployment of that component.

New releases will be fetch-able by pulling the new Docker container images from the dedicated Docker Registry at registry.cloudbase.it.

To update the current Coriolis appliance, execute the following:

Updating the Coriolis component containers

Updating the Coriolis CLI client

In order to update the coriolis executable present on the appliance, please run the following:

Updating the Coriolis CLI client

Changing SSL certificates used by the Web-Proxy component

The standard Docker-based Coriolis appliance has a dedicated HTTPS proxy component named the coriolis-web-proxy.

This component acts as a proxy for both the Web UI and underlying services, and forwards requests based on the following rules:

Coriolis Web Proxy forwarding rules

NOTE By default, the actual service endpoints within the Keystone installation reference the direct localhost-based URLs, not the URLs on the proxy, which makes API access using the standard coriolis CLI utility unfeasible (unless the Coriolis appliance is exposed, see details below).

The Coriolis Web-Proxy uses a pre-bundled unique self-signed certificate mounted from the host directory under /etc/coriolis/ssl 

Coriolis Web Proxy forwarding rules

If a different certificate is desired to be used for the Web UI and access to the service APIs from outside, the certificate/key may simply be dropped in after which the proxy container may be restarted by running a docker restart coriolis-web-proxy

Expose Coriolis appliance

By default, all the Coriolis appliance services listen only on localhost. In order to expose all the services from the appliance, execute the following:

Backing up all service Databases from the Docker-based Coriolis appliance

Both Coriolis and most of its supporting services (ex: Keystone, Barbican) save their state in a Relational database.

The standard Docker-based Coriolis appliance ships with MariaDB (a MySQL spin-off) deployed by Kolla as a Docker container which is running locally on the appliance.

Thusly, it is highly recommended that periodic database backups be performed from the Coriolis appliance so as to save any existing data, making it easily recoverable on another appliance in case the main one goes bad.

The backup procedure for all Databases can be run using the following:

Dumping all service databases from the mariadbcontainer

WARNING the below steps will completely replace any existing data in the current DB

To import a previously-dumped database backup to a new appliance, the following may be run:

Reinstating all service databases from a previous SQL dump