Introduction

A Docker volume does not directly attach a Google Compute Engine persistent disk by itself. The normal setup is to attach the persistent disk to the VM, mount it on the host operating system, and then point Docker at that mounted host path through a bind mount or a named local volume.

Understand the Layering

There are three separate layers involved:

• Google Compute Engine attaches a block device to the VM
• Linux mounts that device into the host filesystem
• Docker mounts that host path into the container

Keeping those layers separate makes the setup much easier to debug. If the disk is not mounted on the VM correctly, no Docker configuration will fix it.

Attach and Mount the Persistent Disk

First create and attach the persistent disk. The disk must be in the same zone as the VM instance.

1gcloud compute disks create app-data-disk \
2  --size=50GB \
3  --zone=us-central1-a
4
5gcloud compute instances attach-disk my-vm \
6  --disk=app-data-disk \
7  --zone=us-central1-a

Once attached, log in to the VM and identify the device:

lsblk

If the disk is new, format it once and mount it:

sudo mkfs.ext4 -F /dev/sdb
sudo mkdir -p /mnt/disks/app-data
sudo mount /dev/sdb /mnt/disks/app-data

At this point the persistent disk is just a normal mounted directory from the host's perspective.

Bind-Mount the Host Path Into Docker

The simplest Docker option is a direct bind mount:

1docker run -d \
2  --name app \
3  -v /mnt/disks/app-data:/var/lib/app \
4  my-image:latest

Anything written by the container to /var/lib/app now lands on the persistent disk. If the container is deleted and recreated, the data still exists because the storage lives outside the container filesystem.

This is usually the clearest solution when you want predictable host-level control.

Using a Named Docker Volume

If you prefer Docker volume names instead of raw host paths, you can still point a local Docker volume at that same mounted directory.

1docker volume create \
2  --driver local \
3  --opt type=none \
4  --opt device=/mnt/disks/app-data \
5  --opt o=bind \
6  gce-pd-volume
7
8docker run -d \
9  --name app \
10  -v gce-pd-volume:/var/lib/app \
11  my-image:latest

This does not change the underlying storage model. It just lets Docker refer to the mounted path through a named volume.

Make the Mount Survive Reboots

One of the easiest mistakes is getting the setup to work once and then losing it after the VM reboots. To avoid that, add the mounted disk to /etc/fstab using the filesystem UUID.

sudo blkid /dev/sdb

Then add an entry similar to this:

UUID=your-uuid-here /mnt/disks/app-data ext4 defaults,nofail 0 2

Now the persistent disk remounts automatically on boot, which keeps Docker from starting against an empty local directory by accident.

Compose and Deployment Scripts

In a Compose file, the same pattern applies. You still mount the host path that belongs to the persistent disk:

1services:
2  app:
3    image: my-image:latest
4    volumes:
5      - /mnt/disks/app-data:/var/lib/app

Whether you use docker run, Compose, or a systemd-managed container, the cloud disk integration still happens at the host level first.

Common Pitfalls

Expecting Docker to attach the Google persistent disk without mounting it on the host VM first is the most common misunderstanding.

Forgetting the zone requirement causes attachment failures because the VM and persistent disk must live in the same zone.

Testing with a manual mount and then skipping /etc/fstab often leads to data confusion after the next reboot.

Mounting the wrong host path into the container can make it look like persistence is broken even though the disk itself is fine.

Debugging only inside the container wastes time when the real problem is the host mount or disk attachment state.

Summary

• Attach the GCE persistent disk to the VM and mount it on the host first.
• Give Docker that mounted host path through a bind mount or a named local volume.
• Treat the cloud disk, Linux mount, and Docker mount as separate layers.
• Use /etc/fstab so the host mount survives reboots.
• When debugging, verify the host disk mount before looking at container settings.