Installer Deployment Manual

Before you begin

Installer limitations

It is necessary to review this section to take into account the limitations when using the installer.

• The installer is bound to a single environment of Anjana. Multiple instances will be necessary to manage different environments.

• The machine where the installer runs must belong to a single Anjana environment, since it will be platformed and will undergo changes according to the environment being managed.

• If the installation fails and the relaunch also fails, it is recommended to reprovision the machine from scratch and start again.

• The anjana user is a reserved user and must not already exist on the machine.

Requirements

Connectivity

The installer will download all the necessary resources from the Anjana Data central repository over HTTPS protocol and port 443 against the server releases.anjanadata.com, so connectivity from the servers to be provisioned to that service will be required.

Additionally, the installer will contact the licensing service at veltesta.anjanadata.com for activation and validation, so that connectivity is also required over HTTPS and port 443.

Machine and access

The installer is distributed as a standalone binary that includes both the backend and the frontend - it does not install or configure anything else on its own until it is explicitly run. To be able to download it and start it up, the following is needed:

• Ubuntu 24.04 or RedHat 9 operating system

• User with root permissions on the machine

• Fixed outbound IP to the Internet

• x86_64 architecture (Intel/AMD 64-bit)

• Access credentials for the Anjana Data repository (Nexus user), requested beforehand from cs@anjanadata.com - these will be used in the next step to download the kit

Install the installer binary

Once the requirements are met, the steps to start up the installer service are as follows.

1. Download the kit

The kit is distributed from releases.anjanadata.com with the name format kit-anjana-installer-VERSION.tgz, under the Maven path com/anjana/kit-anjana-installer/VERSION/ (the version goes in its own directory).

wget --user=<nexus-user> --ask-password \
  "https://releases.anjanadata.org/repository/releasesraw/com/anjana/kit-anjana-installer/VERSION/kit-anjana-install
  er-VERSION.tgz" \
  -P /tmp/

2. Extract to /opt

sudo tar -xzf /tmp/kit-anjana-installer-VERSION.tgz -C /opt

This creates the /opt/anjana-installer/ directory with the following structure:

/opt/anjana-installer/
├── anjana-installer.service
├── bin/
│   └── anjana-installer        # Launcher
├── jre/                        # Embedded JRE
└── lib/
    └── anjana-installer.jar    # Spring Boot Fat JAR

3. Run the install command

sudo /opt/anjana-installer/bin/anjana-installer install

This command automatically performs the following steps:

1. Detects the operating system (debian / redhat)

2. Installs JDK 17 via apt-get or dnf depending on the OS

3. Creates the data directory at /opt/anjana-installer/data

4. Registers the systemd unit at /etc/systemd/system/anjana-installer.service

5. Runs systemctl enable --now anjana-installer

It is not necessary to manually copy the .service file or run systemctl daemon-reload. The install command manages the entire service registration cycle.

4. Access the interface

When finished, the installer is available over HTTPS on port 8787 under the path /installer. The final message of the command shows the URL with the hostname or the IP of the machine, for example https://<host-or-ip>:8787/installer.

Access is done directly from the client's network: corporate internal network, the organization's VPN, or the controlled exposure path defined for the installer machine (for example, a load balancer or a dedicated bastion). If the machine is not directly reachable from the workstation of the person who will administer the installer, the corresponding network path (firewall rule, VPN, etc.) must be enabled according to how the environment is deployed, before opening the above URL in the browser.

On first startup, if a password has not been set beforehand, the installer automatically generates a secure random password for the admin user and displays it once in the service startup log. This generated password does not require changing it at that first login: the requirement to change it is triggered later, at the moment the installer's secrets manager is initialized, which happens when the Wizard configuration is saved for the first time. From that save onward, the system will require changing the admin password before continuing. For automated deployments it is possible to set the initial password via an environment variable before the first startup, thus avoiding the random generation.

First startup and initial configuration

With the installer already running and accessible, the next step is to complete the configuration wizard (Wizard). There are three paths to reach a complete configuration - choose the one that matches your situation:

• A. Configure from scratch: for a new environment that has never been deployed.

• B. Import a configuration already exported from the installer itself: to restore or clone a previous configuration (YAML file).

• C. Migrate from an existing Ansible kit: for an environment already deployed with the Ansible kit that will now be managed with the installer.

A. Configure from scratch

The wizard requests the following data:

• Installation mode (new environment)

• Nexus credentials requested beforehand from Anjana Data.

• Domain required for the frontend and communication between microservices

• TLS certificate corresponding to the chosen domain (the installer generates a self-signed one by default if none is specified)

• Product license key provided by Anjana Data

• Monitoring, to enable the Open Telemetry agent

• Persistence layers, with the connection configuration for databases, S3 services and other persistence layers

A connection check button allows validating the entered Nexus credentials before moving on to the next step of the wizard.

Single VM: For Single VM environments, no additional connectivity settings for persistence layers are required when these are local. It is not necessary to fill in the persistence URLs since they will always be localhost.

Core + Persistence (Distributed): For distributed environments it will be necessary to configure the SSH connection credentials to the additional instances and the URLs of the managed or remote persistence layers.

Authentication (Zeus SSO)

As part of the wizard, the authentication providers that Zeus will use for user access to the Anjana platform are configured. Four types of providers are supported:

The secrets associated with each provider (LDAP password, OIDC client secrets, SAML2 keys) are stored in the installer's secrets backend and managed from the wizard's Secrets screen. Full detail of parameters per provider and of the user provisioning step in Installer Advanced Functionality.

B. Import a configuration already exported from the installer itself

Allows importing a YAML file previously exported by the installer itself (the "Export YAML" button on the Configuration page). The file is deserialized directly and the entire configuration is applied. This is the tab selected by default in the import dialog, accessible from the Configuration page.

For security reasons, the YAML exported by the installer never includes the persistence credentials (PostgreSQL, MongoDB, S3/SeaweedFS, etc.) in plain text: those values are not part of the exported file. After importing this configuration, those credentials must be filled in manually in the wizard before continuing.

C. Migrate from an existing Ansible kit

Applies to environments already deployed with Anjana's Ansible kit that are transitioning to being managed by the installer. The import translates the kit's configuration into the installer's format, so it is not necessary to rebuild it by hand in the wizard.

Files to prepare

Unlike importing the installer's own YAML (path B), the Ansible kit's all.yaml file does contain the persistence credentials in plain text, as managed by that kit. The migration automatically extracts them for the persistence layers that are not yet deployed on the machine; it is not necessary to re-enter them by hand in the wizard for those cases. For persistence layers already deployed, the existing credential is not overwritten (see "Credential protection during import" below): in that case it must be reviewed or completed manually in the wizard.

From the Ansible kit inventory, the following are needed:

• all.yaml (group_vars): environment configuration and credentials

• hosts.yaml: inventory and node definition

Optionally, the import also accepts the anjanauihosts.yaml file (group_vars of the anjana_ui group) to carry over the kit's access whitelists: the apache whitelist moves to the General list and the persistence and horus whitelists are combined into the Internal list of IP Access Control (see Settings, full detail in Installer Advanced Functionality). The interface's import dialog requests all.yaml and hosts.yaml; the anjanauihosts.yaml file can be provided as an optional third file through the installer's import API.

Import flow

1. In Configuration, open the import dialog and select the Ansible Kit tab

2. Select the all.yaml and hosts.yaml files and click Preview Import (if the files are uploaded in the wrong order, the installer detects it and swaps them automatically, indicating this with a notice)

3. Review the preview: mapped configuration (detected topology, version, domain, hosts, persistence layers, Nexus, monitoring), list of warnings, migration notices and detected secrets

4. Click Confirm Import to persist the configuration and the secrets

What gets mapped automatically

• All configuration values from all.yaml to the installer's format

• The environment's topology (Single VM, Distributed, etc.) based on the inventory

• The detected credentials, which are stored as installer secrets

• The access whitelists, if the anjanauihosts.yaml file is provided (malformed entries or entries with an invalid CIDR are discarded and reported as warnings)

Migration notices

During the preview, notices requiring action may be shown:

• MinIO to SeaweedFS: MinIO is no longer supported as an object storage backend; the installer deploys SeaweedFS instead. In this import flow from an Ansible kit, data migration is manual: after completing the installation, the MinIO buckets must be migrated to SeaweedFS with mc mirror and MinIO must be removed from the original Ansible kit (anjana -t delete-minio)

• TLS certificate regeneration: Platform Setup generates new self-signed certificates and keystores; the certificates deployed by the Ansible kit are not imported. After Platform Setup, a full restart of all Anjana services is required to apply the new certificates

This manual migration notice applies only to importing from an existing Ansible kit (path C). This is a different case from the 25.2 → 26.1 update of an environment already managed by the installer: in that case, if the update includes object storage migration, MinIO is migrated and completely removed (service, binary and data) automatically, once the health validation after the migration is confirmed (see "Platform update" below).

Credential protection during import

When confirming an import, the installer checks which persistence layers are already deployed (via systemctl). Credentials for deployed services are not overwritten, avoiding desynchronizing the secrets store from the service's actual password. A grouped notice is shown: "Credentials not overwritten for deployed services: PostgreSQL, SeaweedFS, ... Use Tools > Credentials to rotate them."

Credentials for services not yet deployed are imported normally and will be applied during installation.

What to review after importing

• The warnings shown in the preview and in the import result (missing sections, unknown values replaced by defaults, unresolved references)

• The carried-over whitelist entries, from Settings > IP Access Control (ranges, labels and discarded entries)

• The full configuration in the wizard before launching the Preflight, especially credentials and persistence URLs

Install Anjana Data Platform