1. The “Wallpaper” Analogy
Imagine your Docker Image is a room where you have glued Wallpaper (your Code) to the walls during the build phase (COPY ./src ./src).
- The Build: When you build the image, the wallpaper is baked in. If you push it to Google Cloud, the room arrives with the wallpaper inside.
- The Volume (The Problem): When you run the container with
- web_src:/app/src, you are essentially placing a Temporary Partition Wall in front of the wallpaper. - The Result: The container only sees what is on the partition wall (the Volume). It can’t see the wallpaper (the Code) behind it.
2. What happens on Google Cloud?
If you deployed that exact docker-compose.yml to Google Cloud:
- First Deployment: Google Cloud pulls the image. It sees the volume requirement. It creates a brand-new, empty volume.
- The Result: Because the volume is empty, it mounts an empty folder over your code. Your app crashes because it can’t find
app.py. - The “Stuck” Part: Your code isn’t “stuck” on Unraid—it’s safely inside the image—but the instruction to use a volume is what breaks it.
3. Why this is “Ghosting” your Updates on Unraid
On your Unraid server, the volume web_src isn’t empty. It has the version of the code from the very first time you ran the container.
- You change
admin.pyon your host. - You build a new image (The wallpaper in the “room” is now updated).
- You restart the container.
- Docker says: “I already have a partition wall (Volume) for this room. I’ll use that instead of looking at the new wallpaper.”
- You see: The old code.