The content in this article is written in the recommended order for configuring Docker environments on MedStack Control.

Registries

📘

Use a common set of read-only credentials

MedStack stores the registry credentials in an encrypted state on our database as the credentials are required when pulling a container image from a registry. This happens when deploying and updating services. As such, we recommend using a common set of read-only credentials that your entire development team can use.

In the Registries tab you can click the Add registry button to add registry credentials.

These credentials will be used to pull container images from the image registry and must be configured for each user.

You may configure the URL to contain the library if you'd like to have more than one set of registry credentials for a registry service.

For example, you could have multiple docker.io registry credentials when creating credentials if you specify the library in the URL:

• docker.io/medstack-v1
• docker.io/medstack-v2

🚧

Each user needs to add registry credentials

Although located within the "Manage Docker" section of a cluster, credentials are bound to a user, thus each user will need to add a set of registry credentials before they can deploy custom services from this registry. These could be the common set of read-only credentials.

Update credentials

When you update registry credentials, the changes do not automatically propagate across the services configured in Docker on MedStack Control.

❗️

Updating registry credentials?

If you update/rotate registry credentials, you will need to create new services in Docker to deploy images from the registry. Updating the existing services will result in a deployment failure.

Configs

📘

Learn more about Docker configs

To learn more about Docker configs, please see the official Docker documentation on storing configuration data using Docker configs.

In the Configs tab, you can click the New config button to create a config for utilization in services.

Configs are used to store configuration files and other non-sensitive information. Configs are mounted into virtual files that are accessible inside your container at custom path specified by the user. These files are not encrypted at rest nor in transit, but they are only accessible to containerized services configured to utilize the config.

Later on in the guide, you'll learn about utilizing configs when deploying a service.

Update configs

Configs cannot be updated, but they can be viewed. This makes them more appropriate for containing non-sensitive data used by services. If you're intending on updating a config utilized by a service, you will need to:

1. Create a new config in Docker.
2. Configure the relevant services to utilize the new config and delete the utilization of the old config.
3. Delete the old config in Docker.

Secrets

📘

Learn about Docker secrets

To learn more about Docker secrets, please see the official Docker documentation on managing sensitive data with Docker secrets.

In the Secrets tab, you can click the New secret button to create a secret for utilization in services.

Secrets store confidential information such as passwords, SSH private keys or SSL certificates. Secrets are mounted into virtual files that are accessible inside your container, typically in /var/run/secrets/. These files are encrypted at rest and in transit and can only be decrypted by containerized services configured to utilize the secret.

Later on in the guide, you'll learn about utilizing secrets when deploying a service. We've created a video tutorial for creating and using secrets below.

Update secrets

Secrets cannot be viewed nor can they be updated. If you're intending on updating a secret utilized by a service, you will need to:

1. Create a new secret in Docker.
2. Configure the relevant services to utilize the new secret and delete the utilization of the old secret.
3. Delete the old secret in Docker.

Volumes

📘

Learn about Docker volumes

To learn more about Docker volumes, please see the official Docker documentation on using volumes.

Volumes are used to persist data and to share data between containers. When a volume mapping is created in MedStack Control, the data stored to that volume persists on the node's disk beyond the lifecycle thanks to MedStack Control's backup and restore system for Docker.

It's important to note that volume data is not synchronized nor copied to other node disks. Thus:

• Volumes will only exist on the disks of nodes running the service as a container, and;
• The data inside that volume will only pertain to the data managed by the container running on the node.

Furthermore, data required by containers is only backed up if that data is mapped to a Docker volume. If data is not stored in a Docker volume, it will be destroyed when the container is destroyed.

Upload data

In order to upload data, there must be at least one volume mapping created.

1. Click the Upload data button.
2. Click the BROWSE button to select the desired file from your file system.
3. Select the volume mapping for inferring the destination.
4. Select the node containing the volume where you'd like to upload the data. The data will be stored on the selected node's disk.

Since the path of a volume is specified in a service's configuration, data can only be uploaded to nodes that are actively running a container configured with the volume mapping.

List Backups

A list of Docker volume backups can be found in the "Volumes" section of "Manage Docker", allowing teams to generate evidence of Docker volume backups and export the evidence to CSV. The list contains information about the backup timestamp, locality, encryption status, and compressed file size.

📘

Restoring a backup

Docker volume backups can be restored to nodes using the restore volume feature.

📘

Validating backups

It may be valuable to periodically check that backups of data volumes have a compressed file size greater than 0 Bytes. If the compressed file size is 0 Bytes, it means that no data exists in the backup snapshot.

Additional information

Recommendations for development

MedStack Control supports local volume mounts only and does not support bind mounts. Bind mounts are convenient for development but are not available in MedStack Control environments. As such, we encourage the utilization of volume mounts over bind mounts.

Managed volumes

Volumes may be added automatically by MedStack managed services to track internal data such as TLS certificates, such as the acme volume created by the load balancer service.