📘

Important

This section is extremely important for running production-grade application. Please read the recommendations below.

If you've already created a staging environment, you’ll have by now everything you need to successfully build environments, deploy and maintain your applications in production! There are however some nuances in the configuration of production environments you will want to make to improve cluster and service availability and reliability.

1. When building production environments, we recommend using (1) multiple nodes and (2) general purpose tier databases.

In practice, when using multi-node architectures, we find that:

• Small nodes are suitable for staging environments that don't run heavy workloads
• Medium nodes or larger make appropriate Manager nodes in production environments.
• At least 2 medium nodes are appropriate Worker nodes in production environments and scaled to large and x-large nodes as needed.
• You can always add more worker nodes of any size to meet the performance requirements of your services.

2. When deploying services, it's important to leave the Manager node as free of tasks/processing as possible.

This is because the Manager node is responsible for orchestrating Docker. If the Manager node's resources are ever exhausted, Docker will have trouble orchestrating and the performance of managing your cluster in MedStack Control can become very slow. This is because MedStack Control interacts directly with Docker. Another symptom of an overworked Manager node is that the web services become unavailable. There are some strategies you can do to prevent this from happening:

• Run a Manager node of considerable size, at least a Medium sized node.
• Use service placement constraints to devise conditions for containers to run on nodes other than the Manager node. For example, this could be node.role != manager. This service placement constraint could be coupled with others that might be used by stateful services, for example like node.labels.database == true provided that you've created a node label for database = true for running a containerized database on a specific node.

Resources

The production-recommended cloud resources to use in a production environment are as follows.

Nodes

See the complete list of nodes in the node specifications table.

• Large (2 vCPU, 8 GB memory)
• X-Large (4 vCPU, 16 GB memory)

Databases

See the complete list of databases in the database specification table.

• General purpose (2 vCPU, 10 GB memory)
• General purpose (4 vCPU, 20 GB memory)

Optimize Docker application

Docker's official documentation has the following recommendations for running your application on a production environment.

1. Keep your images small. This will speed image download which is a key factor in deployment time.

   Digital Ocean has an extensive guide on optimizing images for production. See the official Digital Ocean guide on optimizing Docker images for production.

2. Switch from bind mounts to volumes. Bind mounts are convenient for development but are not available in production.

3. Make use of secrets and configs.

For more information, see the official Docker development best practices guide.

Production switchover

If you're migrating to MedStack Control, before performing a production switchover, we recommend you have first done the following:

1. Test a database dump from the current environment and restore into the MedStack Control environment.

2. Map an A record in your DNS settings to point to the manager node in the production Docker environment. The load balancer is pinned to the manager node thus it is the IP address where traffic will ingress. We recommend mapping the DNS setting 48 hours in advance if possible to mitigate any issues of the DNS settings being delayed in propagating.

3. Schedule at least a two (2) hours maintenance window with your end users where the application may not be available.