When building microservices in the cloud, if you were to use the default Postgres container for your database, all of the data would be stored in the container itself. Because containers are meant to be destroyed and recreated, the data in that container would be lost every time the container is replaced. The solution for this is easy: use a volume. Mount a path on the host, put the data there, and every time the container is replaced, it mounts to that place on the host system. There’s one problem: in hosted cloud environments, there is no dry land. There’s no “host” for you to mount a volume to.
Volumes in Kubernetes
Fortunately, you can create volumes for a Kubernetes cluster. Unfortunately, this can be a bit tricky. Often developers don’t have access to the cluster, so it might require coordination with the operations team to get those volume instructions added. Usually, the team will bring a tool like Terraform or write the configuration by hand. This infrastructure code usually lives in a separate repository which can make keeping the infrastructure configuration in sync with your application’s needs can be a hassle.
Volumes in Architect are much easier to work with. The architect.yml file lives right in the code repository, making it much easier for developers to reason about the entire system at once. The volume spec in the architect.yml file allows developers to create volumes that work seamlessly whether the application is run locally or deployed to a cloud service like AWS, GCP, or Azure. So how does it work? I’m glad you asked.
volumes:
src:
mount_path: /file/dir/in/container
host_path: ./dir/on/host/machine
Add the volumes spec with the mount_path (the path that will be used to access the volume within the container) and the host_path (the path that contains the files on the host machine that the container will want to access). So for a Postgres container image, you might want to mount a volume to point to the database files that Postgres uses. Something like:
volumes:
src:
mount_path: /var/lib/postgresql
host_path: ./db/files
In a regular Dockerfile, this would mean that every time you went to /var/lib/postgresql in the container, you would actually be using the files in the local machine’s current directory ./db/files. Which works okay locally, but remember there’s no host machine to use if you’re deploying to a cloud provider. The way that Architect works around this is by tarring and gzipping the directory indicated in the host_path and delivers it to a cloud volume and mounts that to the mount point in the container.
It’s important to remember that the contents of the host_path are compressed and stored in the same Docker registry system that your container uses, and is done at registration time. This means that your data is still under the same access control it has always been.
This means that using volumes in Architect just got MUCH easier. No longer would developers have to coordinate with the operations team and create two different configurations for local and cloud deployments. Simply use the volume spec, and have access to that volume in your local, test, and test environments!
Be aware that these volumes will be overwritten on every deployment. This is not recommended for production databases. The best practice is to use a managed database service and connect to it as an external service to keep persistent data no matter how often you deploy or destroy and create containers.
Learn more about volumes
If you’d like to learn more about volumes or microservices, check out the links below!
- Architect Documentation on Volumes
- Microservice tools: The top 10 for monitoring and testing
- Test environments: Everything you need to know
Also, don’t forget to follow us on Twitter so that you never miss a post or feature update from Architect!
Add your thoughts