Use Cases

Single node environment deployment

To deploy a single node Anjana environment, you must follow the steps described in the Anjana Deployment section. These steps can be summarized as follows, but you will still need to follow the section for more detail:

• Create or have available a virtual machine according to the recommendations.

• Request the necessary access and credentials.

• Provision the environments according to what is documented.

• Clone the appropriate inventory to create the inventory defined in the provisioning script:

  • localhost: when the ansible kit is located on the same machine where the product will be installed.

  • sample: when the ansible node is a different node from the Anjana node.

• Make the required adjustments.

• In the all.yml file of the chosen inventory, edit the desired version for the Anjana deployment according to the instructions.

• Run ansible to deploy the product with or without sample data as needed.

AWS S3 as a replacement for MinIO

Buckets in AWS S3 will be managed in the same way as buckets in MinIO, with the option to customize the region and name of the buckets to connect to.

More details about connecting to AWS S3 can be found in the Cloud Integrations section, Buckets in AWS S3.

PostgreSQL RDS as a replacement for PostgreSQL

Connecting to an RDS will have practically no differences, since only the connection host and port need to be changed.

More details about connecting to RDS can be found in the Cloud Integrations section, PostgreSQL on RDS.

Balanced environment deployment

For the distributed and balanced Anjana deployment mode, the following machines are required:

• 2 VM Front + Back

• 1 VM Tot + Plugins

• 1 VM Solr + Zookeeper

• 4 VM MinIO (Cluster) or AWS S3

• PostgreSQL RDS

• 1 VM ansible manager (optional)

Next, the steps described in the Anjana Deployment section will be followed, except for running Ansible to deploy Anjana, since it will be necessary to complete some prior steps.

Once the steps have been carried out, taking into account that:

• The necessary credentials and access are already available.

• The script has already been downloaded and the nodes that will make up the Anjana environment have already been provisioned (all the VMs mentioned above).

• A customized inventory for the environment is already available.

• The hosts.yml file has already been adjusted to include the IPs and other data of all the nodes in the environment.

• The all.yml file has already been adjusted to determine the version or versions chosen for the deployment, as well as the ansible roles that will take part in the environment.

Next, the following sections are followed to adjust the persistences as needed.

MinIO (Cluster)

For MinIO in cluster mode, the miniohosts.yml file in the inventory must be edited to adjust the volumes to the four available nodes.

The volumes option for Standalone mode will be commented out, and the volumes line for MinIO cluster will be uncommented and adjusted.

Next, the additional nodes for the MinIO balancer must be uncommented in the anjanauihosts.yml file and edited to correspond to the existing nodes:

Now, once everything necessary to deploy the product has been adjusted, proceed with the installation using the ansible kit.

sudo ansible -i /opt/ansible/ansible-inventories/<inventario>/hosts.yml all -m ping

To install Anjana with sample data:

anjana -t anjana-sample

To install Anjana without sample data:

anjana

Multiple plugin instances

To generate a second instance of an existing plugin, the following steps are required:

• Duplicate the configuration template and the service descriptor of the chosen plugin in the inventory in use as many times as new instances you want to create, adding the appropriate numbering.
  It should look as follows:

• Add as many new entries for the selected plugin in the inventory's hosts.yml file as instances of that same plugin you want to add, changing the port, service name, configuration profile, and index (required for utilities such as start/stop).

• If the configuration of the second instance is different, the configuration profile will also need to be modified so that it is applied correctly.

Once everything has been adjusted, the configuration update will be run with the command:

anjana -t update-config

To deploy the new instance, the plugin's role must be run with the following command:

anjana -t tot-plugin-<plugin>

Anjana environment + standalone plugins deployment

This use case covers the installation of a single-node Anjana environment, except for Tot+Plugins, which will be hosted on a separate machine.

To do this, the steps described in the Anjana Deployment section will be followed as if the deployment were a distributed environment, since it will indeed be so for the Tot+Plugins part, taking into account the additional adjustments detailed below:

• All the plugins to be deployed will be enabled in the all.yml file's import_role section, according to what is mentioned in the Role and configuration import section.

• The anjana.plugins_config.standalone property will be edited in the all.yml file to set it to true, according to what is mentioned in the installation configuration section.

Once these changes have been made, it will be possible to continue with the installation steps.

Cloning a PRE environment to PRO

For this use case, a pre-existing PRE environment will be taken as the starting point, whose data is to be migrated to another PRO environment.

It is possible to clone the persistences and the configuration using the clone functionality or tag.

Preparation for cloning

It is taken as a starting point that the following requirements have been met:

• installation.mode has been set to manager in the all.yml file.

• Credentials and access to the Anjana repositories are available and correctly configured.

• All connection strings belonging to the persistences are correctly configured. For more information, see the Connection Strings section.

In case of doubts regarding the all.yml file, you can consult the All.yml explained section.

Data + configuration cloning

All the persistence data and the configuration of the Anjana microservices and plugins will be backed up using the following command:

anjana -t clone

To transfer the data to the destination machine, run the following commands:

scp -i /<user>/.ssh/<key>.pem <user>@<origen>:/opt/export-import/anjana_clone.tgz /<ruta_local>
scp -i /<user>/.ssh/<key>.pem /<ruta_local> <user>@<destino>:/tmp/anjana_clone.tgz
sudo mv /tmp/anjana_clone.tgz /opt/export-import/anjana_clone.tgz

Data restoration

To perform the data restoration, after being on the destination machine (PRO), there are two possible cases:

CASE 1 - Restoration in a new environment

If the restoration is carried out in a newly created environment or machine, it will be necessary to deploy Anjana and all the persistences, without data, in order to later fill them with the cloned data.

To do this, after being on the destination machine, you would need to download and adjust the ansible kit to deploy Anjana, using the command without tags:

anjana

CASE 2 - Restoration in an existing environment

If the restoration takes place in an environment with Anjana already deployed, the following points must be checked:

The destination environment where the restoration will be performed must have the same Anjana version as the source environment of the data. If there are discrepancies, the versions must be adjusted in the all.yml file and then updated with the command:

anjana -t update

The restoration process does not overwrite or delete data, so it is necessary to first delete the data and the configuration, by running the following command:

anjana -t delete,delete-config

Once the tasks and requirements corresponding to the case the environment is in have been completed, in order to proceed with the data restoration, the .tgz archive generated in the cloning process must be located at the path defined in the variables file mentioned above, by default /opt/export-import/anjana_clone.tgz.

For general restoration, the following command will be run:

anjana -t deploy

For individual restoration of persistences and/or configuration:

anjana -t deploy-s3
anjana -t deploy-bbdd
anjana -t deploy-config

After the data restoration, it is recommended to restart the environment with:

anjana -t restart

Loading an accelerator sample after deployment

Once the solution has been deployed, Anjana Data Platform allows you to load a sample of data from the accelerators offered by Anjana Data Platform to facilitate the adoption of data and AI governance. These samples include predefined metadata configurations, templates, taxonomies, and asset examples that serve as a starting point for implementation projects.

A common case is loading the sample associated with the HEALTH DCAT-AP metadata standard, available as a functional accelerator.

Sample loading steps

1. Go to the environment's Ansible inventory variables directory:

   cd /opt/ansible/ansible-inventories/<inventario>/group_vars
   

2. Open the global configuration file:

   vim all.yaml
   

3. Configure the name of the sample to load.
   In this example, for the HEALTH DCAT-AP accelerator, enter:

   sample: "pub-health-dcatap"
   

   Save the changes and close the editor.

4. Run the task to clean up the previous content of the environment's persistences:

   anjana -t delete
   

5. Run the insertion of the configured sample:

   anjana -t insert
   

6. Unlock the schemas to avoid migration locks when starting the microservices.
   This step prevents errors such as "Waiting for changelog lock":

   anjana -t unlock-schemas
   

7. Wait for the microservices to finish starting up and, once they are operational, access the platform to verify that the sample has loaded correctly.