Nacos on Ubuntu 24.04 on Azure User Guide

Overview

This guide covers the deployment and configuration of Nacos on Ubuntu 24.04 on Azure using cloudimg Azure Marketplace images. Nacos is an open source platform for dynamic service discovery, configuration management and service management. It gives microservices a service registry to find and call each other, a distributed configuration center for managing application settings at runtime with instant push, and built in health checking, making it a core building block for cloud native applications and service meshes.

The image ships Nacos 3.2.3 running in standalone mode under systemd as the unprivileged nacos system user, backed by the built in embedded datastore, so there is no external database to run. The Nacos server exposes its OpenAPI on port 8848 and its gRPC client port on 9848 for SDK clients, while the web console runs on port 8080 and is published to the network only through nginx, which terminates TLS on port 443 with a self signed certificate regenerated per instance on first boot.

Secure by default, with no known bootstrap credential. Stock Nacos is associated with a well known nacos / nacos login. This image enables nacos.core.auth.enabled=true so the naming and configuration OpenAPI and gRPC endpoints require an access token, and it generates all secret material uniquely for this VM on first boot: the JWT signing key, the server identity pair, and a strong random admin password initialised through the Nacos admin API. The embedded datastore ships empty, so nothing secret is baked into the image and the stock nacos / nacos login never works.

What is included:

• Nacos 3.2.3 running standalone under systemd as the unprivileged nacos system user, with the embedded datastore (no external database required)

• Server API and gRPC authentication enabled so unauthenticated OpenAPI calls are rejected

• A unique admin password, JWT signing key and server identity generated per VM on first boot, written to /root/nacos-credentials.txt (mode 0600)

• The web console on :8080 published only through nginx terminating TLS on :443, with HSTS and sensible security headers

• Port :80 returns a 301 redirect to HTTPS, plus an unauthenticated /healthz endpoint (HTTP 200) for load balancer probes

• A self signed TLS certificate regenerated per VM on first boot (Subject Alternative Names include the VM IP, hostname and 127.0.0.1) — replace it with your own CA signed certificate for production

• A built in self test at /opt/nacos/nacos-selftest.sh that proves authentication is enforced and that the naming registry round trip works

• Ubuntu 24.04 LTS base with latest security patches applied at build time

• Azure Linux Agent for seamless cloud integration and SSH key injection

• 24/7 cloudimg support with guaranteed 24 hour response SLA

Prerequisites

• An Azure subscription with permission to deploy virtual machines

• An SSH key pair for administrative access to the VM as the azureuser account

• A Network Security Group allowing inbound TCP 443 (HTTPS console) from your operators, 8848 and 9848 (Nacos server API and gRPC) from your application subnets, and 22 (SSH) from your management network only

• A recommended size of Standard_B2s or larger

Step 1: Deploy from the Azure Portal

1. Locate the Nacos on Ubuntu 24.04 LTS image in the Azure Marketplace and select Create.

2. Choose your subscription, resource group and region.

3. Select a VM size (Standard_B2s or larger) and provide your SSH public key for the azureuser account.

4. On the Networking tab, allow inbound 443 for the console, 8848 and 9848 for your application clients, and restrict 22 to your management network.

5. Review and create. When the VM is running, browse to https://<your-public-ip>/.

Step 2: Deploy from the Azure CLI

You can deploy the same image from the Azure CLI. Replace the resource group, location and image URN as needed:

az vm create \
  --resource-group my-nacos-rg \
  --name nacos \
  --image <cloudimg-nacos-image-urn> \
  --size Standard_B2s \
  --admin-username azureuser \
  --generate-ssh-keys \
  --public-ip-sku Standard
# then open the console and client ports
az vm open-port --resource-group my-nacos-rg --name nacos --port 443 --priority 1001
az vm open-port --resource-group my-nacos-rg --name nacos --port 8848 --priority 1002
az vm open-port --resource-group my-nacos-rg --name nacos --port 9848 --priority 1003

Step 3: Verify the Nacos and nginx services

SSH in as azureuser and confirm both services are active and that the server is listening on the OpenAPI port 8848, the gRPC client port 9848, the console port 8080, and nginx on 443 and 80:

sudo systemctl is-active nacos nginx

ss -tln | grep -E ':8848 |:9848 |:8080 |:443 |:80 '

You should see nacos + nginx: active active, with the Nacos server bound on 8848, 9848 and 8080, and nginx public on 80 and 443.

Step 4: Retrieve the per VM admin credentials

The admin password, console URL and client server address are generated uniquely for this VM on first boot and written to a root only file. Read them with:

sudo cat /root/nacos-credentials.txt

The NACOS_ADMIN_PASSWORD value is unique to this instance. The stock nacos / nacos login is disabled, so this is the only credential that works.

Step 5: Open the Nacos console

Browse to https://<your-public-ip>/. Because the certificate is self signed and generated per VM, your browser will warn about the certificate the first time. Accept it (or install your own certificate, see Step 11). Log in as nacos with the password from Step 4.

Step 6: Browse the service registry

Open Services then Service List to see every service instance registered with Nacos, along with its group, instance count and health status. This is the heart of Nacos service discovery: applications register here on start up and discover each other through the same registry.

Step 7: Manage configuration

Open Configuration then Configurations to see the configuration items Nacos is serving. Each item has a Data ID, a group and a format. Nacos pushes changes to subscribed clients in real time, so applications pick up new configuration without a restart.

Select Detail on a configuration item to view its full content, metadata and history. The content editor shows exactly what subscribed applications receive.

Step 8: Run the built in authentication self test

The image ships a self test that proves authentication is enforced and that the naming registry round trip works end to end. It confirms that an unauthenticated register is rejected, that the stock nacos / nacos login is refused, and that the per VM admin can register an instance and read it back:

sudo /opt/nacos/nacos-selftest.sh

The expected output reports round-trip OK, confirming that authentication is enforced and the registry works.

Step 9: Prove authentication is enforced and register a service through the API

Server API authentication is enabled, so an unauthenticated call is rejected with 403. Log in with the per VM admin to obtain an access token, then use it to register a service instance and read it back. Run the whole block in one session so the access token is available to the register and list calls:

PW=$(sudo grep -m1 '^NACOS_ADMIN_PASSWORD=' /root/nacos-credentials.txt | cut -d= -f2-)
TOKEN=$(curl -s -X POST 'http://127.0.0.1:8848/nacos/v3/auth/user/login' \
  --data-urlencode 'username=nacos' --data-urlencode "password=$PW" \
  | python3 -c 'import sys,json; print(json.load(sys.stdin)["accessToken"])')
echo "obtained access token: ${TOKEN:0:24}..."
curl -s -X POST "http://127.0.0.1:8848/nacos/v3/admin/ns/instance?accessToken=$TOKEN" \
  --data-urlencode 'serviceName=demo-service' --data-urlencode 'groupName=DEFAULT_GROUP' \
  --data-urlencode 'ip=10.0.0.10' --data-urlencode 'port=8080'
echo
curl -s "http://127.0.0.1:8848/nacos/v3/admin/ns/instance/list?serviceName=demo-service&groupName=DEFAULT_GROUP&accessToken=$TOKEN"

The register call returns "data":"ok" and the list call returns the instance you just registered.

Step 10: Connect an application

Point your application's Nacos client at this VM. Use the server address for the OpenAPI, the gRPC client port for real time discovery and configuration push, and the per VM admin credential (or a dedicated user you create in the console under the users section) for authentication. For a Spring Cloud Alibaba application, the equivalent properties are the server address <your-ip>:8848, and the username and password for authentication. Because authentication is enabled on this image, every client must supply credentials.

Step 11: Use your own domain and a trusted certificate (production)

The image ships a self signed certificate so the console is secure out of the box, but browsers will warn on it. For production, point a DNS name at the VM and install a CA signed certificate. Inspect the current per VM certificate with:

sudo openssl x509 -in /etc/nginx/tls/nacos.crt -noout -subject -ext subjectAltName

With your own domain you can obtain a free certificate from Let's Encrypt:

sudo apt-get update && sudo apt-get install -y certbot python3-certbot-nginx
sudo certbot --nginx -d <your-domain>

Certbot installs the certificate into nginx and sets up automatic renewal.

Step 12: How the appliance is wired

• Nacos server — run by nacos.service as the unprivileged nacos user from /opt/nacos, in standalone mode with the embedded datastore, exposing the OpenAPI on 8848 and the gRPC client port on 9848. The heap is sized for a Standard_B2s VM.

• Console — the Nacos web console runs on 127.0.0.1:8080 and is published to the network only through nginx.

• nginx — nginx.service, terminating TLS on :443 and reverse proxying to the console, redirecting :80 to HTTPS, and serving an unauthenticated /healthz for load balancer probes.

• First boot — nacos-firstboot.service runs once on first boot: it generates the per VM JWT signing key, server identity and admin password, renders them into the configuration, starts Nacos, initialises the admin user, proves the authentication round trip, regenerates the per VM TLS certificate, and writes /root/nacos-credentials.txt. The nacos.service is gated so it can never start before the per VM secrets are rendered.

Step 13: Managing the Nacos service

sudo systemctl restart nacos

sudo journalctl -u nacos.service --no-pager | tail -20

Server settings live in /opt/nacos/conf/application.properties. After changing a setting, run sudo systemctl restart nacos.

Step 14: Security recommendations

• Restrict SSH. Allow inbound 22 only from your management network.

• Scope the client ports. Open 8848 and 9848 only to the application subnets that need service discovery and configuration, and keep the 443 console open to your operators.

• Install a trusted certificate. Replace the self signed certificate with a CA signed one (Step 11) so operators are not trained to click through warnings.

• Create per application users. In the console, add a dedicated user and role for each application rather than sharing the admin credential, and keep the admin password safe.

• Keep the image updated. Unattended security upgrades remain enabled so the OS keeps receiving patches.

Step 15: Support and Licensing

Nacos is open source software distributed under the Apache License 2.0. This image bundles the upstream Nacos 3.2.3 release; the licence file is retained on the image under /opt/nacos/. cloudimg packaging, hardening and support are provided by cloudimg.

Deploy on Azure

Find this image on the Azure Marketplace and deploy it in minutes. See www.cloudimg.co.uk for the full catalogue.

Need Help?

cloudimg provides 24/7 support with a guaranteed 24 hour response SLA. Contact us through www.cloudimg.co.uk for deployment assistance, configuration help or any questions about this image.