Volumes are a container level deployment-time configuration that let's you mount Persistent Block Storage onto a path on the containers. Volume and the specific path it attaches to are mentioned while creating a new Deployment.
There are a couple of points to remember when using volume.
A volume can only be attached to one path in one container at a time.
A volume needs to be freed by deleting the deployment before attaching it in another deployment.
Setup AWS Elastic Block Storage for Dockup by following this nice documentation we have prepared for you.
The deployment form would looks like this with optional volumes:
For this particular deployment, it makes sense to have a volume mounted on a path for the postgres container. This would help us re-use the data from this deployment on future deployments having the same container. Postgres data by default has the path
/var/lib/postgresql/data but this might be different for you depending on the container. It is recommended that you check with the documentation of the container image for configurable paths.
That's all you have to do here. Go ahead, deploy this form and you should now be able to use the deployment with a mounted volume. Once you are done with this deployment, delete it and the Volume should be "Available" in a few seconds for re-use.
We will now use OmniDB to add some dummy data to the
We have now added some data on to the database. Now, let's see how the data we wrote on the postgres container persists for re-use on another fresh deployment.
Firstly, we will delete the current deployment and create a new deployment of the blueprint using the same volume and path for the postgres container.
We can then deploy the same blueprint with same volume mount specifications
Let's open up omnidb for the new
postgres container and see if we have the data from the previous deployment.
Please consider these points when re-using volumes across different types of containers:
Containers like postgres depend on version when using data directory, so a mismatch in version across deployment would cause the container to fail. ie. a volume that had postgres data initialised by a PG 9.5 would fail on PG 11.0 container. One way to prevent this is to use custom data directory for different versions of postgres by specifying the same via
PGDATA environment variable.
Since volumes are used to persist data across deployments, Dockup does not clean them after deleting deployments. Although this is intentional, this could cause data inconsistency if the same path is being used by several other deployments.