If you primarily have worked deploying to Linux servers, you are most definitely accustomed to deploying incremental changes. Transitioning to Docker you’ll have to adapt that way of thinking.

Docker containers are ephemeral, which means they don’t last very long in deployment terms. In many cases they will be rebuilt from scratch. It’s almost like starting a new server from zero every single time. This is different than servers where you only change what you need to change and that’s it. If, for instance, you want to add a package with apt you’d just run the command and apart from installing  that new package, the server remains mostly untouched.

In Docker that scenario would be completely different. You would actually have to rebuild the container completely to add the package. This is important because by default dynamic information like user uploaded files, environment-specific files, and databases, aren’t persisted. So the next time you deploy a change you may be surprised that information is missing.

Thankfully Docker allows you to persist data by means of a mounted virtual drive. The next time your container is created, the mounted drive will be attached and the data will exist again in the container. Since the drive is mounted to a path, you might have to take that into consideration when integrating it into your application. For more information on persisting data, have a look at Docker’s documentation.

The recommended way is to use volumes.