The content in this article is written in the recommended order for configuring Docker environments on MedStack Control.
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:
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.
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.
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.
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:
- Create a new config in Docker.
- Configure the relevant services to utilize the new config and delete the utilization of the old config.
- Delete the old config in Docker.
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.
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:
- Create a new secret in Docker.
- Configure the relevant services to utilize the new secret and delete the utilization of the old secret.
- Delete the old secret in Docker.
Learn about Docker volumes
To learn more about Docker volumes, please see the official Docker documentation on using volumes.
In the Volumes tab, you can click the New volume button to create a volume mapping for utilization in services.
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.
In order to upload data, there must be at least one volume mapping created.
- Click the Upload data button.
- Click the BROWSE button to select the desired file from your file system.
- Select the volume mapping for inferring the destination.
- 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.
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.
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.
Updated almost 3 years ago