Apache Ignite on Ubuntu 24.04 on Azure User Guide

Overview

Apache Ignite is a distributed in-memory database and compute grid that keeps the hot dataset in RAM for memory-speed reads and writes while persisting durably to disk. This cloudimg image runs a single Ignite node with native persistence enabled, so your data survives restarts on a dedicated Azure data disk. It installs Apache Ignite 2.16.0 (the official Apache binary release into /opt/ignite), runs it on OpenJDK 11 as a dedicated ignite system user, enables Ignite authentication, and rotates a unique password into the cluster on first boot. Management is via the bundled control.sh and sqlline.sh CLIs and the thin-client SQL port. Backed by 24/7 cloudimg support.

What is included:

• Apache Ignite 2.16.0 from the official Apache binary release, on OpenJDK 11
• Native persistence (work directory, persistence store and WAL) on a dedicated 40 GiB Azure data disk at /var/lib/ignite
• A unique per-VM password generated on first boot (no shared default credential)
• Ignite authentication enabled, with the node bound to 127.0.0.1 only
• The thin-client / JDBC SQL port 10800 on loopback (not exposed publicly)
• 24/7 cloudimg support

This is a datastore product: Ignite listens on 127.0.0.1 only. There is no web console (GridGain Control Center is a separate commercial product and is not shipped). The SQL port is not opened to the internet - connect locally on the VM or over an SSH tunnel.

Prerequisites

An active Azure subscription, an SSH key pair, and a VNet + subnet in the target region. Standard_B4ms (4 vCPU / 16 GiB RAM) is a good starting point because Ignite is memory-hungry. NSG inbound: allow 22/tcp from your management network. No inbound application ports are needed because Ignite is reached over the SSH tunnel.

Step 1 - Deploy from the Azure Marketplace

Sign in to the Azure Portal, choose Create a resource, search the Marketplace for Apache Ignite by cloudimg, and select Create. On Basics pick your subscription, resource group, region and size; under Administrator account choose SSH public key and paste your key; under Inbound port rules allow SSH (22) only. Then Review + create -> Create.

Step 2 - Deploy from the Azure CLI

az vm create \
  --resource-group <your-rg> \
  --name apache-ignite \
  --image <marketplace-image-urn> \
  --size Standard_B4ms \
  --admin-username azureuser \
  --ssh-key-values ~/.ssh/id_ed25519.pub \
  --vnet-name <your-vnet> --subnet <your-subnet> \
  --public-ip-sku Standard

Step 3 - Connect to your VM

ssh azureuser@<vm-public-ip>

Step 4 - Confirm Apache Ignite is installed and running

ls /opt/ignite/libs | grep -oE 'ignite-core-[0-9.]+'
systemctl is-active ignite

You should see the Ignite 2.16.0 core jar and active:

ignite-core-2.16.0
active

Step 5 - Confirm the cluster state and persistence directory

The node activates automatically on first boot. Confirm the SQL/thin-client port is listening on loopback only and that native persistence lives on the dedicated data disk:

ss -tln | grep 10800
findmnt -no SOURCE,TARGET /var/lib/ignite
sudo ls /var/lib/ignite

LISTEN 0      50     [::ffff:127.0.0.1]:10800            *:*
/dev/sda /var/lib/ignite
lost+found
store
wal
walarchive
work

The work, store and wal directories on /var/lib/ignite are the native-persistence store on the dedicated Azure data disk, so the keyspace and cluster metadata survive reboots.

Step 6 - Retrieve your per-VM password

Each VM generates its own unique Ignite password on first boot and writes it to a root-only credentials file:

sudo cat /root/ignite-credentials.txt

The file contains IGNITE_USERNAME (ignite), IGNITE_PASSWORD, the SQL connection details and the SSH-tunnel instructions. Store the password in your secrets manager. In the steps below, <IGNITE_PASSWORD> stands for the value of IGNITE_PASSWORD.

Step 7 - Run SQL with sqlline

Apache Ignite ships a JDBC SQL CLI, sqlline.sh. Connect as the ignite user with your per-VM password (run this in your shell, substituting the real password for <IGNITE_PASSWORD>):

/opt/ignite/bin/sqlline.sh -u 'jdbc:ignite:thin://127.0.0.1/' -n ignite -p '<IGNITE_PASSWORD>'

At the sqlline prompt you can create a table, insert rows and query them:

0: jdbc:ignite:thin://127.0.0.1/> CREATE TABLE city (id INT PRIMARY KEY, name VARCHAR);
0: jdbc:ignite:thin://127.0.0.1/> INSERT INTO city (id, name) VALUES (1, 'London'), (2, 'Paris');
0: jdbc:ignite:thin://127.0.0.1/> SELECT name FROM city ORDER BY id;
+--------+
|  NAME  |
+--------+
| London |
| Paris  |
+--------+
0: jdbc:ignite:thin://127.0.0.1/> !quit

Step 8 - The authentication wall

Ignite authentication is enabled. The default ignite/ignite credential is rotated to a unique per-VM password on first boot, so neither the default password nor any wrong password authenticates - only the per-VM password in your credentials file works. You can see the rejection by attempting a connection with a wrong password (substitute any wrong value); the connection is refused with an authentication error, while the per-VM password from Step 6 connects successfully.

Step 9 - Inspect the cluster with control.sh

The bundled control.sh utility reports cluster state and topology. Because authentication is enabled, pass your per-VM credentials (substitute the real password for <IGNITE_PASSWORD>):

/opt/ignite/bin/control.sh --state --user ignite --password '<IGNITE_PASSWORD>'

It reports the cluster ID, tag and that the state is ACTIVE.

Step 10 - Connect remotely over an SSH tunnel

Ignite listens on 127.0.0.1 only (ports 10800, 47500, 47100) and is not exposed publicly - this is the secure default. To reach the SQL port from your workstation, open an SSH tunnel and point a local JDBC client (or a local sqlline) at localhost:10800:

# On your workstation:
ssh -L 10800:127.0.0.1:10800 azureuser@<vm-public-ip>

# In another terminal, point a thin-client / JDBC tool at:
#   jdbc:ignite:thin://127.0.0.1:10800/  user=ignite  password=<IGNITE_PASSWORD>

For production remote access without a tunnel, bind Ignite to a private NIC and front it with TLS. Never expose 10800 to the internet without transport encryption.

Maintenance

• Persistence: the work directory, persistence store and WAL live on the dedicated data disk at /var/lib/ignite, so the cluster state survives reboots and the volume is independently resizable.
• Password: rotate it from a sqlline session with ALTER USER "ignite" WITH PASSWORD '<new-password>'; and update your credentials store.
• Configuration: edit /etc/ignite/ignite-config.xml (data region sizes, ports, persistence paths) and JVM options in /etc/ignite/ignite-env.sh, then sudo systemctl restart ignite.
• Cluster control: use /opt/ignite/bin/control.sh for state, baseline and topology operations (pass --user/--password).
• Security patches: unattended-upgrades remains enabled so the OS continues to receive security updates automatically.

Support

cloudimg provides 24/7 expert support for this image. Contact support@cloudimg.co.uk.

Apache Ignite and Apache are trademarks of the Apache Software Foundation. This image is provided by cloudimg and is not affiliated with or endorsed by the Apache Software Foundation. GridGain Control Center is a commercial product and is not included.