Eg
Application Infrastructure Azure

Eclipse GlassFish on Ubuntu 24.04 on Azure User Guide

| Product: Eclipse GlassFish on Ubuntu 24.04 LTS on Azure

Overview

Eclipse GlassFish is the official reference implementation of Jakarta EE, the open specification for enterprise Java. It ships a full web based admin console plus the asadmin command line for deploying applications, managing resources and tuning the runtime. Install the cloudimg image and you have a ready to use Jakarta EE application server. The image installs GlassFish 8.0.3 from the official Eclipse Foundation release and runs it as the dedicated glassfish system service on OpenJDK 21. The admin console is bound to the loopback connector 127.0.0.1:4848, and nginx on port 80 reverse proxies to it plus an unauthenticated health endpoint. Application HTTP traffic is served directly on GlassFish's own port 8080, alongside a minimal demo Servlet/JSP application that proves the container executes dynamic Java code. The domain (configuration, deployed applications, 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 a shared or guessable admin login. Backed by 24/7 cloudimg support.

What is included:

  • Eclipse GlassFish 8.0.3 installed from the official Eclipse Foundation release and run as the glassfish system service on OpenJDK 21
  • The relocated domain1 directory (config, deployed applications, logs) on a dedicated Azure data disk at /var/lib/glassfish
  • GlassFish bound to 127.0.0.1:4848 for the admin console, fronted by nginx on port 80
  • Application HTTP traffic served directly on port 8080, including a minimal demo Servlet/JSP application
  • 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 password ships in the image
  • glassfish.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 application server; size up for heavier workloads. NSG inbound: allow 22/tcp from your management network, 80/tcp for the admin console, and 8080/tcp for application traffic (and 443/tcp if you add TLS). The admin console 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 Eclipse GlassFish 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), HTTP (80) and a custom rule for 8080. 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 glassfish \
  --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 glassfish --port 80 --priority 1010
az vm open-port --resource-group <your-rg> --name glassfish --port 8080 --priority 1020

Step 3 - Connect to your VM

ssh azureuser@<vm-public-ip>

Step 4 - Confirm the services are running

systemctl is-active glassfish.service nginx.service
ss -tlnp | grep -E '4848|8080'

Both services report active. The admin listener is bound only to the loopback address 127.0.0.1:4848 behind nginx on port 80; the application http-listener on port 8080 is exposed directly for your own web traffic.

systemctl is-active reporting glassfish.service and nginx.service both active, with the admin listener bound to loopback 127.0.0.1:4848 and the application port 8080 listening directly

Step 5 - Retrieve your admin password

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

sudo cat /root/glassfish-credentials.txt

This file contains GLASSFISH_ADMIN_USER (admin), GLASSFISH_ADMIN_PASSWORD, and the admin console and application URLs. Store the password somewhere safe. The file is mode 0600 and owned by root, so only an administrator can read it. The domain (config, deployed applications, logs) lives on the dedicated Azure data disk mounted at /var/lib/glassfish.

The root only 0600 credentials file with the per VM admin username, password and console/app URLs

Step 6 - Confirm the health endpoint and application port

nginx serves an unauthenticated health endpoint for load balancers and probes, fronting the admin console, while the demo application answers directly on port 8080:

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 "app     HTTP %{http_code}\n" http://localhost:8080/

/healthz returns OK with HTTP 200 and never requires authentication, so it is safe for an Azure Load Balancer health probe. The demo application on port 8080 returns HTTP 200, confirming the servlet container is up and serving requests.

Step 7 - Verify authentication from the command line

The admin console's REST management API authenticates with standard HTTP Basic auth. The check below authenticates with the correct per VM password (HTTP 200 on /management/domain) and, for contrast, with a wrong password (rejected, HTTP 401). Because the command embeds your unique password, run it interactively rather than from a script; substitute the value of GLASSFISH_ADMIN_PASSWORD from Step 5 for <GLASSFISH_PASSWORD>:

code() { curl -s -o /dev/null -w '%{http_code}' -m 15 -u "$1" http://127.0.0.1:4848/management/domain; }
echo "per-VM password -> HTTP $(code admin:<GLASSFISH_PASSWORD>)"
echo "wrong password  -> HTTP $(code admin:wrong-password)"

The correct per VM password authenticates and prints HTTP 200; a wrong password is rejected and prints HTTP 401. This is the same rotation-by-file mechanism used at first boot: the shipped image never accepts a shared or guessable admin password.

The admin auth round trip and the health/app endpoint checks: healthz and the demo app both return HTTP 200, the correct per VM password authenticates with HTTP 200 on /management/domain, and a wrong password is rejected with HTTP 401

Step 8 - Sign in to the web admin console

Browse to http://<vm-public-ip>/. You land on the GlassFish Administration Console login page. Enter admin as the user name and the password from Step 5, then select Login.

The GlassFish Server Open Source Edition Administration Console login page served through nginx on port 80

Step 9 - Explore the Common Tasks dashboard

After signing in you land on the Common Tasks page. From here you can browse the domain configuration tree on the left (Applications, Resources, Configurations), deploy a new application, create JDBC resources, and review monitoring data - everything you need to administer the server.

The GlassFish Console Common Tasks dashboard, with the configuration tree (Applications, Resources, Configurations) on the left and Deployment/Administration/Monitoring shortcuts

Step 10 - View the deployed demo application

Select Applications in the left tree. The image ships a minimal demo Servlet/JSP application (demo-app) deployed to the root context, already Enabled, so you can see exactly how a real deployment looks before uploading your own.

The Applications list showing the demo-app web application deployed, enabled, and running on the web engine

Step 11 - Deploy your own WAR/EAR

From the admin console, select Applications then Deploy, choose your .war or .ear file, set the context root, and select OK. From the command line, use asadmin directly against the loopback admin port:

sudo -u glassfish /opt/glassfish/glassfish8/bin/asadmin \
  --user admin --passwordfile <(echo "AS_ADMIN_PASSWORD=<GLASSFISH_PASSWORD>") \
  deploy --contextroot /myapp --name myapp /path/to/myapp.war

The demo application's own page (below) shows exactly what real dynamic content looks like: a live server time, hostname and remote address rendered by the JSP container on every request, not a static file.

The demo-app response on port 8080, rendering live server time, hostname, remote address and container info from a JSP, proving real dynamic execution

Step 12 - Confirm data lives on the dedicated disk

The domain - configuration, deployed applications, and logs - is stored under /var/lib/glassfish on the dedicated Azure data disk, so it survives OS changes and can be resized independently:

findmnt /var/lib/glassfish

findmnt showing /var/lib/glassfish mounted from a dedicated ext4 data disk

Maintenance

  • Password: the admin password is set on first boot via GlassFish's asadmin update-file-user mechanism against the admin-realm file realm. To change it yourself, use the admin console's Change Administrator Password page under Common Tasks, or run asadmin update-file-user from the CLI with a fresh --passwordfile.
  • Serve a real domain and TLS: the appliance serves the admin console over plain HTTP on port 80 and the application on plain HTTP on port 8080. For production, point a DNS name at the VM, obtain a trusted certificate (for example with certbot / Let's Encrypt), and front both with nginx TLS on port 443.
  • Deploying applications: use the admin console's Applications -> Deploy page or asadmin deploy from the CLI (see Step 11). GlassFish supports WAR, EAR and JAR (EJB) modules.
  • Resources: add JDBC connection pools, JMS resources and connectors from the admin console's Resources section, or with asadmin create-jdbc-connection-pool and related subcommands.
  • Clustering: this appliance runs a single standalone DAS (Domain Administration Server) instance. For multi-instance clusters, use asadmin create-cluster and asadmin create-instance following the GlassFish clustering documentation.
  • Storage and backup: all domain state (config, deployed apps, logs) lives under /var/lib/glassfish on the data disk; back up that volume to protect your applications and configuration.
  • 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.