Apache Seata Transaction Coordinator on AWS User Guide

Overview

This image runs Apache Seata 2.6.0, an open source distributed transaction solution for microservices. At its centre is the Seata Server, a Transaction Coordinator (TC) that your services register with so a single business operation spanning several microservices and databases either commits everywhere or rolls back everywhere. Seata supports the AT, TCC, SAGA and XA transaction modes. Apache Seata is licensed under Apache-2.0 and is currently an Apache Incubator project.

The image ships two components, both run on a headless OpenJDK Java runtime by a dedicated unprivileged seata system account under systemd:

• Seata Server (Transaction Coordinator / TC) — a headless Netty RPC endpoint on port 8091, running in standalone file store mode, so it is completely self contained with no external database to provision. Your microservice clients (transaction managers and resource managers) connect here.
• Seata NamingServer — hosts the login protected web console and a registry, bound to the loopback interface on port 8081 and published only through an nginx reverse proxy on port 80. The Transaction Coordinator registers to the local NamingServer so the console can display it as a healthy cluster member.

The console password and the console token signing key are generated on the first boot of every deployed instance, so two instances launched from the same Amazon Machine Image never share a credential. The password is written to /root/seata-credentials.txt with mode 0600 so that only the root user can read it. The upstream console ships with no login configured, so no working default credential ever ships in the image.

Prerequisites

Before you deploy this image you need:

• An Amazon Web Services account where you can launch EC2 instances
• IAM permissions to launch instances, create security groups, and subscribe to AWS Marketplace products
• An EC2 key pair in the target Region for SSH access to the instance
• A VPC and subnet in the target Region, with a security group allowing inbound port 22 from your management network, port 80 for the console front, and port 8091 from the networks your microservice clients run in
• The AWS CLI (version 2) installed locally if you plan to deploy from the command line

Step 1: Launch the Instance from the AWS Marketplace

Sign in to the AWS Management Console, open the EC2 service, and select Launch instance. Under Application and OS Images choose AWS Marketplace AMIs and search for Apache Seata. Select the cloudimg listing and choose Select, then Continue on the subscription summary.

Pick an instance type of m5.large or larger (Seata is a JVM workload). Choose your EC2 key pair under Key pair (login). Under Network settings select your VPC and subnet, and either create or select a security group that opens port 22 from your management network, port 80 for the console front, and port 8091 from the networks your clients use. Leave the root volume at the default size or larger.

Select Launch instance. First boot initialisation takes approximately one minute after the instance state becomes Running and the status checks pass.

Step 2: Launch the Instance from the AWS CLI

You can launch the same image from the command line. Replace the placeholders with your subnet, security group and key pair, and use the AMI id from the Marketplace listing for your Region.

aws ec2 run-instances \
  --image-id ami-0123456789abcdef0 \
  --instance-type m5.large \
  --key-name your-key-pair \
  --subnet-id subnet-0123456789abcdef0 \
  --security-group-ids sg-0123456789abcdef0 \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=apache-seata}]'

Connecting to your instance

Connect over SSH using your EC2 key pair. The login user depends on the operating system variant you launched:

ssh -i /path/to/your-key.pem ubuntu@<public-ip>

Step 3: Retrieve the console password

The console password is unique to each instance and is written to a root only file at first boot. Retrieve it over SSH:

sudo cat /root/seata-credentials.txt

The file contains the console URL, the console user (seata), and the generated SEATA_CONSOLE_PASSWORD, along with the Transaction Coordinator RPC endpoint your clients should use.

Step 4: Confirm the services are running

All three services are managed by systemd and start on boot. Confirm they are active:

systemctl is-active seata-namingserver.service seata-server.service nginx.service

Confirm the listeners are in place — nginx on port 80, the console bound to loopback 8081, and the Transaction Coordinator on 8091:

sudo ss -tlnp | grep -E ':(80|8081|8091) '

The unauthenticated console health endpoint returns a JSON success body through nginx:

curl -s http://127.0.0.1/naming/v1/health

Step 5: Sign in to the web console

Browse to http://<public-ip>/ and sign in as seata with the password from /root/seata-credentials.txt. The console is served by nginx from the loopback bound NamingServer.

After signing in, the TransactionInfo view lets you browse global transactions, global locks and the coordinator cluster, filtered by namespace and cluster. The version (Apache Seata 2.6.0) is shown at the lower left.

Step 6: Confirm the Transaction Coordinator is registered

Open ClusterManager in the console and query the public namespace and default cluster. The coordinator appears as a healthy member; choose View to see its control and transaction endpoints on port 8091.

You can prove the same thing from the command line. Log in to the console API with the per instance password to obtain a bearer token, then query the registered coordinators — the Transaction Coordinator is reported as healthy on port 8091:

PW=$(sudo grep '^SEATA_CONSOLE_PASSWORD=' /root/seata-credentials.txt | cut -d= -f2-)
TOKEN=$(curl -s -H 'Content-Type: application/json' -X POST -d "{\"username\":\"seata\",\"password\":\"$PW\"}" http://127.0.0.1/api/v1/auth/login | jq -r '.data')
curl -s -H "Authorization: $TOKEN" 'http://127.0.0.1/naming/v1/clusters?namespace=public' | jq '.'

Step 7: Wire your microservice clients to the coordinator

Your Seata clients (transaction managers and resource managers embedded in your microservices) connect directly to the Transaction Coordinator RPC endpoint on port 8091. This image runs the coordinator in standalone file store mode, so point your clients at it using the file registry model. A typical Spring Boot client application.yml looks like:

seata:
  enabled: true
  tx-service-group: my_tx_group
  service:
    vgroup-mapping:
      my_tx_group: default
    grouplist:
      default: <public-ip>:8091
  registry:
    type: file
  config:
    type: file

Open port 8091 in the instance security group to the subnets your application services run in, and annotate the entry point of a distributed operation with @GlobalTransactional. When the operation runs, the global transaction appears in the console TransactionInfo view.

Security hardening

• Restrict inbound access. Open port 80 (console front) and port 8091 (coordinator RPC) only to trusted networks in your security group. The console (8081) is bound to loopback and is never directly reachable off the instance.
• Terminate TLS. Put a TLS terminating load balancer, or configure TLS on nginx, in front of port 80 so console traffic is encrypted. Restrict the coordinator RPC port to private application subnets.
• Rotate credentials. The console password and token signing key are unique per instance. To rotate the console password later, update console.user.password for the NamingServer and restart seata-namingserver.service.
• Encrypt at rest. Enable AWS EBS encryption on the root volume to protect configuration and transaction state at rest.
• Scale out. For production throughput and durability beyond evaluation, move the coordinator to a database backed store and run multiple coordinators; contact cloudimg support for sizing guidance.

Support

cloudimg provides 24/7 technical support for this Apache Seata image via email and live chat. We assist with deployment, wiring your microservice clients to the coordinator, console and credential administration, TLS termination, and JVM tuning. Contact support@cloudimg.co.uk or reach us via live chat. For sizing recommendations, production architecture planning, or any issues including requesting refunds, contact support@cloudimg.co.uk.

All product and company names are trademarks or registered trademarks of their respective holders. Use of them does not imply any affiliation with or endorsement by them.