Spring Cloud Local Infrastructure: Fixed-Version Docker Compose Learning Environment

This article is for local learning only. For production environments, please use the official deployment methods for each component, fixed versions, independent credentials, persistent storage, and high-availability solutions.

1. Why Not to Use latest

Using latest causes the same Compose file to pull different versions at different times, leading to unreproducible configurations, database scripts, client protocols, and startup behaviors. Nacos, Seata, RabbitMQ, MySQL, Elasticsearch, and Kibana should all have fixed versions, and Elasticsearch/Kibana versions must match.

2. Service Decomposition

A local environment can include:

MySQL       Configuration and business data
Nacos       Service registry and configuration center
Seata       Distributed transaction coordinator
RabbitMQ    Message queue
Elasticsearch/Kibana Optional logging or search environment

Don't configure all components with default passwords, and don't expose admin ports to the public. Inject credentials via .env, Docker secrets, or uncommitted local files.

3. Compose Design Principles

Each service should have a fixed image tag, persistent volumes, isolated networks, health checks, resource limits, and minimum privileges. depends_on only indicates startup order, not that the dependent service is ready to accept requests; applications must still implement connection retries and readiness checks.

Database initialization scripts must come from the corresponding component version. This especially applies to Seata TC tables and business database undo_log — don't copy from outdated tutorials.

4. Nacos 2.x

Nacos 2.x requires attention to client ports, cluster communication ports, database initialization tables, and authentication. For single-machine learning environments, you can disable unnecessary cluster capabilities; production environments should deploy authentication, persistence, and high availability according to official documentation.

Spring Cloud Alibaba client versions must be compatible with Spring Boot, Spring Cloud, and Nacos client. When using Config Data Import, don't continue using bootstrap configuration as the default approach.

5. Seata 2.x

Seata Server and clients use the same compatibility scheme. TC using file storage is only suitable for local verification; production requires recoverable databases or officially supported high-availability storage, along with same-version database scripts.

Every business database participating in AT must have a corresponding versioned undo_log. AT cannot rollback messages, caches, and third-party API calls; external side effects require idempotency, reliable messaging, or compensation.

6. RabbitMQ

Use supported versions 3.13+ or 4.x. Critical message configurations include publisher confirms, persistence, consumer ack, limited retries, dead letters, and idempotency. Default users, default passwords, and public-facing admin ports should only appear in temporary local environments.

7. Local Verification Checklist

• All containers have fixed versions and can restart and recover;
• Data volumes and initialization scripts are idempotent;
• Applications can detect unreadiness and retry;
• Nacos registration, config import, and refresh are verifiable;
• Seata can register TM/RM and complete rollback tests;
• RabbitMQ can confirm publish, consume ack, and handle dead letters;
• Compose files contain no real passwords, tokens, or production addresses.

The goal of this environment is reproducible learning, not a production architecture template. Network, storage, backup, monitoring, upgrades, and disaster recovery must be redesigned before production deployment.