Rundeck Runbook Automation on Ubuntu 24.04 on Azure User Guide

Overview

Rundeck is a self hosted runbook automation and self service operations platform. Define jobs once, then run commands and scripts across your fleet of nodes on a schedule or on demand, straight from the browser. Every execution is captured with its output and recorded in an audit log, so you always know who ran what and when. Install the cloudimg image and you have a ready to use automation server with a clean web UI. The image installs Rundeck 6.0.0 from the official packagecloud package and runs it as the dedicated rundeck system service on OpenJDK 17. The web UI is bound to the loopback connector 127.0.0.1:4440, and nginx on port 80 reverse proxies to it plus an unauthenticated health endpoint. The embedded database that holds your jobs, executions and key storage, along with your projects and logs, lives on a dedicated Azure data disk. A unique admin password is generated on the first boot of every VM, so a fresh VM never ships the default admin login. Backed by 24/7 cloudimg support.

What is included:

• Rundeck 6.0.0 installed from the official packagecloud package and run as the rundeck system service on OpenJDK 17
• The built in embedded H2 database (no external database required), with your projects and job logs, on a dedicated Azure data disk at /var/lib/rundeck
• Rundeck bound to 127.0.0.1:4440, fronted by nginx on port 80
• Port 80 serving an unauthenticated /healthz endpoint for load balancer probes
• A unique admin password generated on first boot and written to a root only file, so no shared or default admin ships in the image
• rundeckd.service and nginx.service as system services, enabled and active
• 24/7 cloudimg support

Prerequisites

An active Azure subscription, an SSH key pair, and a VNet plus subnet in the target region. Standard_B2ms (2 vCPU / 8 GiB RAM) is a reasonable starting point for a Java web application; size up for more concurrent executions and nodes. NSG inbound: allow 22/tcp from your management network and 80/tcp (and 443/tcp if you add TLS) for the web UI. The web UI is served over plain HTTP by default, so for production put your own domain and a trusted certificate in front of it (see Maintenance).

Step 1 - Deploy from the Azure Marketplace

Sign in to the Azure Portal, choose Create a resource, search the Marketplace for Rundeck 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) and HTTP (80). Review the dedicated data disk on the Disks tab, then Review + create and Create.

Step 2 - Deploy from the Azure CLI

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

az vm open-port --resource-group <your-rg> --name rundeck --port 80 --priority 1010

Step 3 - Connect to your VM

ssh azureuser@<vm-public-ip>

Step 4 - Confirm the services are running

systemctl is-active rundeckd.service nginx.service
ss -tlnp | grep -E '4440|80'

Both services report active. Rundeck listens only on the loopback address 127.0.0.1:4440, and nginx on port 80 reverse proxies to it. The web connector is never exposed directly on a public interface.

Step 5 - Retrieve your admin password

The Rundeck admin password is generated uniquely on the first boot of your VM and written to a root only file:

sudo cat /root/rundeck-credentials.txt

This file contains RUNDECK_USERNAME (admin), RUNDECK_PASSWORD and the web UI URL. Store the password somewhere safe. The file is mode 0600 and owned by root, so only an administrator can read it. The embedded H2 database that holds your jobs and executions lives on the dedicated Azure data disk mounted at /var/lib/rundeck.

Step 6 - Confirm the health endpoints

nginx serves an unauthenticated health endpoint for load balancers and probes, and fronts the Rundeck login page:

curl -s http://localhost/healthz
curl -s -o /dev/null -w 'healthz HTTP %{http_code}\n' http://localhost/healthz
curl -s -o /dev/null -w 'login   HTTP %{http_code}\n' http://localhost/user/login

/healthz returns ok with HTTP 200 and never requires authentication, so it is safe for an Azure Load Balancer health probe. The login page at /user/login returns HTTP 200, which confirms Rundeck is up behind nginx and ready to sign in to.

Step 7 - Verify authentication from the command line

Rundeck signs in with a standard form login that posts to /j_security_check. The check below signs in with the correct per VM password (a successful sign in authenticates the session, so a follow up request to the authenticated home page returns HTTP 200) and, for contrast, with the default admin password and a wrong password (both rejected, the session stays unauthenticated so the home page redirects with HTTP 302). Because the command embeds your unique password, run it interactively rather than from a script; substitute the value of RUNDECK_PASSWORD from Step 5 for <RUNDECK_PASSWORD>:

login() {
  J=$(mktemp)
  curl -s -c "$J" -o /dev/null http://localhost/user/login
  curl -s -b "$J" -c "$J" -o /dev/null \
    --data-urlencode "j_username=admin" --data-urlencode "j_password=$1" \
    http://localhost/j_security_check
  curl -s -b "$J" -o /dev/null -w "%{http_code}\n" http://localhost/menu/home
  rm -f "$J"
}
echo "per-VM password -> HTTP $(login '<RUNDECK_PASSWORD>')"
echo "default admin   -> HTTP $(login 'admin')"
echo "wrong password  -> HTTP $(login 'wrong')"

The correct per VM password prints HTTP 200 (signed in, the authenticated home page loads). The default admin password prints HTTP 302, proving the appliance rotated the default login away on first boot; a wrong password prints HTTP 302 as well (rejected).

Step 8 - Sign in to the web UI

Browse to http://<vm-public-ip>/. You land on the Rundeck login page. Enter admin as the username and the password from Step 5, then select Log In.

Step 9 - Explore the projects dashboard

After signing in you land on the projects home. Rundeck organises your automation into projects: each project has its own jobs, nodes, and execution history. From here you create a new project with New Project, and you see a rolling count of recent executions across your server.

Step 10 - Create a project and define a job

Select New Project, give it a name, and open it. Inside a project, choose Jobs then New Job (or Upload Definition to import a job from a YAML or XML file). A job has a name and a Workflow of one or more steps: shell commands, scripts, or calls to other jobs. You choose which Nodes it runs on, an optional Schedule, and Notifications. The screenshot below shows a project with a simple Hello World job in the examples group that prints a greeting and the date on the server node.

Step 11 - Run a job and read the execution log

Open a job and select Run Job Now. Rundeck dispatches the workflow to the selected nodes and streams the output live. When it finishes you get a full execution record: the overall result, per node status, timing, and the complete Log Output. Every run is retained in the audit log so you can see who ran what and when, and re run it with a click.

Step 12 - Confirm data lives on the dedicated disk

Rundeck's data, the embedded H2 database that holds your jobs, executions and key storage, along with your projects and logs, is stored under /var/lib/rundeck on the dedicated Azure data disk, so it survives OS changes and can be resized independently:

findmnt /var/lib/rundeck

The mount is backed by a separate Azure data disk captured into the image and re provisioned on every VM.

Maintenance

• Password: the admin password is set on first boot and stored in /etc/rundeck/realm.properties. To change it, edit that file (the format is admin:<password>,user,admin,architect,deploy,build) and restart with sudo systemctl restart rundeckd.
• Serve a real domain and TLS: the appliance serves the web UI over plain HTTP on port 80. For production, point a DNS name at the VM, obtain a trusted certificate (for example with certbot / Let's Encrypt), and front Rundeck with nginx TLS on port 443. Then set grails.serverURL in /etc/rundeck/rundeck-config.properties to your https:// URL so the links Rundeck generates are correct, and restart the service.
• LDAP and single sign on: the image uses a local file realm for the admin account. For teams, connect Rundeck to your directory by configuring a JAAS LDAP login module in /etc/rundeck/jaas-loginmodule.conf, or enable SSO with the appropriate Rundeck plugin.
• Access control: Rundeck authorises actions with ACL policies under /etc/rundeck. Add project and system ACL policy files to grant teams the exact rights they need.
• Nodes: by default jobs run on the Rundeck server node. Add your fleet by defining node sources (SSH, cloud model sources, or a resources file) in each project, and Rundeck will dispatch commands and scripts across them.
• Storage and backup: all Rundeck state lives under /var/lib/rundeck on the data disk; back up that volume to protect your jobs, executions and key storage.
• 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.