PowerJob on Ubuntu 24.04 on Azure User Guide

Overview

PowerJob is a modern, high-performance distributed task-scheduling and computing framework. It gives your teams one central place to define, schedule, dispatch and monitor jobs across a fleet of worker nodes, so batch work, data pipelines and periodic tasks run reliably without a bespoke cron setup on every server. The console supports cron and fixed-rate scheduling, several worker routing strategies, workflows that orchestrate jobs as a DAG, map and map/reduce distributed processing, block and failover handling, run logs, alerting and a live dashboard of scheduling activity.

The cloudimg image runs the official PowerJob server as a Docker Compose stack, pinned to release 5.1.2: a MySQL datastore that holds the scheduler's applications, jobs, instances and run history, and the powerjob-server Spring Boot application (built on Temurin/AdoptOpenJDK) that presents the management web console and the worker transport. MySQL is bound to the internal Docker network only, so just SSH, the console's HTTP port and the worker transport port are exposed on the virtual machine. Job logs are stored in MySQL (the MySQL-series storage backend), so there is no MongoDB to run or manage. Every secret is generated uniquely on the first boot of every VM - the administrator password, the MySQL database password and a per-VM worker application secret are each rotated per instance, replacing the shipped defaults - so no shared or default credential is ever live. This matters for a scheduler that can dispatch commands to your workers, where a known default admin would be remote code execution across the fleet. Backed by 24/7 cloudimg support.

What is included:

• The official PowerJob 5.1.2 server running under Docker (powerjob-server pinned by image digest, powerjob-mysql on mysql:8.4), so it never silently upgrades
• The console on port 7700 (with the OpenAPI) and the HTTP worker transport on port 10010, backed by a MySQL scheduler datastore
• A per-VM ADMIN account generated on first boot, its password recorded in a root-only file, so every VM is secured independently
• A per-VM worker application (cloudimg-app) with its own generated secret, plus the MySQL password, regenerated per VM on first boot, replacing the shipped defaults
• The programmatic OpenAPI is authentication-gated, and MySQL is bound to the internal Docker network only - just 22/tcp (SSH), 7700/tcp (console) and 10010/tcp (worker transport) are exposed
• Job-log storage in MySQL (no MongoDB), the stack managed as one powerjob.service systemd unit, plus docker.service, both enabled
• 24/7 cloudimg support

Prerequisites

An active Azure subscription, an SSH key pair, and a VNet + subnet in the target region. Standard_B2s (2 vCPU / 4 GiB RAM) is a comfortable starting size for the server and its database. NSG inbound: allow 22/tcp from your management network, 7700/tcp from the operators who use the console, and 10010/tcp from the worker nodes that will register with PowerJob. The appliance serves plain HTTP; for production put it behind your own domain and TLS.

Step 1 - Deploy from the Azure Marketplace

Sign in to the Azure Portal, choose Create a resource, search the Marketplace for PowerJob 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), then add 7700 and 10010 after deployment. Review + create -> Create.

Step 2 - Deploy from the Azure CLI

az vm create \
  --resource-group <your-rg> \
  --name powerjob \
  --image <marketplace-image-urn> \
  --size Standard_B2s \
  --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 powerjob --port 7700 --priority 1010
az vm open-port --resource-group <your-rg> --name powerjob --port 10010 --priority 1020

Step 3 - Connect to your VM

ssh azureuser@<vm-public-ip>

Step 4 - Confirm the stack is running

PowerJob runs as a Docker Compose stack managed by a single systemd unit. On first boot the stack rotates every secret, creates a fresh scheduler database, seeds the per-VM ADMIN account and a per-VM worker application, and points its console URL at your VM's address; the stack can take a minute or two to become fully healthy after the VM is first created.

systemctl is-active powerjob.service docker.service
docker compose -f /var/lib/powerjob/docker-compose.yml ps --format '{{.Name}}\t{{.Status}}'

Both containers should report Up.

Step 5 - Retrieve your per-VM credentials

The first boot writes a unique administrator password and worker application secret to a root-only file. Read it over SSH:

sudo cat /root/powerjob-credentials.txt

The file records the console URL, the ADMIN username, the generated password, the per-VM worker application name (cloudimg-app) and its secret. It is mode 0600, owned by root.

Step 6 - Verify the login and that no default credential survives

The first boot initialises the built-in ADMIN account with a per-VM password instead of PowerJob's shipped default (ADMIN / powerjob_admin), so no known credential is ever live. You can prove this from the shell: the per-VM password authenticates ("success":true), while the shipped default is rejected ("success":false).

B=http://127.0.0.1:7700
PASS=$(sudo grep '^POWERJOB_ADMIN_PASSWORD=' /root/powerjob-credentials.txt | cut -d= -f2-)
# The per-VM ADMIN authenticates:
curl -s -X POST "$B/auth/thirdPartyLoginDirect" -H 'Content-Type: application/json' \
  -d "{\"loginType\":\"PWJB\",\"originParams\":\"{\\\"username\\\":\\\"ADMIN\\\",\\\"password\\\":\\\"$PASS\\\"}\"}" | head -c 120
echo
# The shipped default is rejected:
curl -s -X POST "$B/auth/thirdPartyLoginDirect" -H 'Content-Type: application/json' \
  -d '{"loginType":"PWJB","originParams":"{\"username\":\"ADMIN\",\"password\":\"powerjob_admin\"}"}' | head -c 120

The first call returns "success":true (the per-VM admin authenticated, a JWT is issued); the second returns "success":false with a "password is incorrect" message (the shipped default is rejected).

Step 7 - Confirm the pinned image and exposed ports

The server image is pinned to v5.1.2, and only SSH, the console port and the worker transport port are exposed on the VM - MySQL listens on the internal Docker network only, never on the host.

docker compose -f /var/lib/powerjob/docker-compose.yml images --format '{{.Repository}}:{{.Tag}}' | sort -u
sudo ss -tln '( sport = :7700 or sport = :10010 or sport = :22 or sport = :3306 )' | awk '{print $1"  "$4}'

You should see powerjob/powerjob-server and mysql:8.4, with listeners on :22, :7700 and :10010 only - :3306 (MySQL) is not bound on the host.

Step 8 - Sign in to the console

Browse to http://<vm-public-ip>:7700/, choose PowerJob Account, and sign in as ADMIN with the password from Step 5.

Step 9 - Open your application dashboard

After signing in you land on AppManage, which lists the applications registered with this scheduler. The image ships one per-VM application, cloudimg-app, in the default namespace. Select it with Enter to open its dashboard, which summarises the live scheduler state - the number of jobs, running instances, registered worker nodes, and the server's address and time.

Step 10 - Review the scheduler and its jobs

Open Job management to see the scheduled jobs. Each row shows the job name, its schedule (for example a CRON expression), the execution type, the processor type and its status. From here you create your own jobs with New job, set their schedule, choose a routing strategy and enable or disable them; you can also trigger a job immediately with Run.

Step 11 - Register a worker and run a job

Jobs are dispatched to workers - the powerjob-worker SDK embedded in your own applications. Open AppManage to see your applications; the image ships the per-VM application cloudimg-app. To connect your own worker, add the PowerJob worker dependency to your application and point it at this server with the per-VM application name and secret from Step 5:

# In your application's PowerJob worker configuration:
powerjob.worker.server-address=<vm-public-ip>:7700
powerjob.worker.app-name=<POWERJOB_APP_NAME>
powerjob.worker.protocol=http
# authenticate the application with the per-VM secret:
powerjob.worker.app-secret=<POWERJOB_APP_PASSWORD>

Once your worker registers, it appears on the application dashboard with its address, and you can route jobs to it and trigger them from Job management.

Step 12 - Production hardening

• TLS: the appliance serves plain HTTP on port 7700. For production, place it behind your own domain and a TLS-terminating load balancer or reverse proxy.
• Application secret: the per-VM worker application secret (Step 5) is what authorises workers to register and receive dispatched commands. Keep it secret and give it only to your own worker nodes; you can add more applications, each with its own password, under AppManage.
• Admin password: change the ADMIN password from the console (Personal) after first sign-in, or add your own users under UserManager and grant them roles.
• Network: expose port 7700 only to your operators and 10010 only to your worker nodes, not the public internet.
• Backups: the scheduler database lives in the powerjob_mysql_data Docker volume. Include it (and /var/lib/powerjob/.env, which holds your per-VM secrets) in your backup routine.

Managing the service

# Restart the whole stack
sudo systemctl restart powerjob.service

# Stop / start
sudo systemctl stop powerjob.service
sudo systemctl start powerjob.service

# Follow the server logs
docker compose -f /var/lib/powerjob/docker-compose.yml logs -f powerjob-server

Support

Every cloudimg image is backed by 24/7 support. If you have any questions about this PowerJob image, contact us at support@cloudimg.co.uk.