Overview
SG-Infra provisions one EC2 instance that runs MongoDB inside a Docker container, plus a separate persistent data volume that holds the database files. This is the dedicated database for Fleet Management Platform only at the time being. It is self-managed, like the legacy instance, but it is larger, runs a newer MongoDB, and separates the data from the instance so the instance can be rebuilt without losing data.The Instance
The Persistent Data Volume
A dedicated EBS volume holds the MongoDB data, defined in its own stack so its lifecycle is independent of the instance:- Size: 256 GiB, GP3, encrypted, with provisioned throughput and IOPS.
- Removal policy: retain, so the volume and its data are not deleted if the stack or instance is removed.
- It is attached to the instance at
/dev/sdfand mounted at/data/mongodb. - On boot the instance checks whether the volume already has a filesystem. If it does, it mounts the existing data. If it does not, it formats the volume and mounts it. This is what allows the instance to be replaced while the data persists on the volume.
This separation of data from compute is the single biggest improvement over the legacy instance, where the data lived on the instance itself.
How MongoDB Runs (Docker)
MongoDB runs as a Docker container (imagemongo:8.2) managed by docker-compose, rather than being installed directly on the host. The container mounts the persistent volume for its data, along with the TLS material and the MongoDB configuration. It is set to restart unless stopped, and has a health check that pings the database and checks replica set status.
How It Is Provisioned
The stack bundles thesetup directory as an S3 asset, and the instance pulls and runs it on first boot through EC2 user data:
1
Prepare the data volume
Download the setup files from S3 and prepare the data volume (mount existing data, or format then mount).
2
Generate TLS material
A self-signed certificate authority and a server certificate are created on the instance, along with a replica set key file. The private keys are generated on the instance and are not stored in source control.
3
Start MongoDB
Install Docker and
docker-compose, read or generate the admin password, start the container, and initiate a single node replica set named rs0.4
Store the connection details
The connection string, the CA certificate and the admin password are written to the Secrets Manager secret so consumers can connect.
5
Install tools and schedule backups
Install the MongoDB tools and set up the backup cron jobs. See Backups and Disaster Recovery.
Security Model
- Network: the MongoDB security group allows inbound only on
27017, and only from the Lambda security group. The instance is in a private subnet with no public address. - Transport: all connections require TLS. Unlike the legacy instance, the certificate authority is generated on the instance (not committed to the repo), certificate validation is enabled, and old TLS versions (1.0 and 1.1) are disabled.
- Authentication: enabled, with an admin user. The admin password is a 128 character random string, stored in Secrets Manager and reused across redeploys (the boot script reads the existing password from the secret if present).
- Credentials for consumers: the secret holds a ready to use connection string and the CA certificate, so a consuming system has everything it needs to connect.