Micro services architecture often employ the use of container such as Docker to package application services. The use of containers provides many benefits including an independent run environment and self contained 'packages'.
Most modern cloud providers and deployment tools such as Kubernetes work with containers and enable application containers to be deployed and scaled without much manual intervention. However to leverage this advantage application architecture and code has to be build in a way that facilitates this.
Factors to consider when applications are run from containers, including:
Where to store configurations
How communications is routed in / out of the container
The nature of seamless scaling of micro services mean that configurations are stored in a central location such as databases and cloud service stores such as table store / parameter storage services (which most cloud providers offer). Applications should be "stateless" and all instances of the services should be identical.
Certain configurations such as connection strings and internal endpoints might need to be passed in dynamically. In these cases, settings should be provided when the containers are started in the form of environment parameters.
docker run -e "NPGSQL_DB=[conn_string]" -e "NPGSQL_DB_SCHEMA=[schema]" exampleAppdockerimage
Assuming we have a .Net Core API service listening on port 5000 and a database connection using port 1433, the application can be build and packaged with the following Dockerfile.
The packaged container will be in the list of docker images. At this point the Docker image can be pushed to the Docker Registry and further distributed.
To distribute the Docker image, each ECS instance will need to pull the new Docker image and start a new instance. See linked article for more details.
One way to run multiple micro services on a single ECS instance is to have multiple container instances run "behind" a web server reverse proxy such as Nginx.
Connect to RDS
Whenever you have an application that is using an RDS connection, it is best practice to create a user per application. This means applications should not share the same RDS database instance user across different applications.
The user should have minimum access permissions as possible.