Docker Community Forums

Share and learn in the Docker community.

Refresh Docker image without touching database

I am a Docker newbie working with a private copy of the Coral Talk project (Docker Hub).

I first tried to install from the source available from the Coralprojet Github repo, but ran into many problems. Because the developers offer both source and container versions, I tried building my own container from the source that I modified slightly. It took a really long time to build but in the end, it worked!

I then installed the software - or anyway got the thing running - using the commands provided by the Coral developers for use with their own Docker image and provided example docker-compose.yml file, as below:

# Create directories to persist the data in MongoDB and Redis.
mkdir -p data/{mongo,redis}

# Create the `docker-compose.yml` file to get started.
cat > docker-compose.yml <<EOF
version: "2"
# Changed image: to my private repo on Everything else the same
    image: coralproject/talk:6 
    restart: always
      - ""
      - mongo
      - redis
      - MONGODB_URI=mongodb://mongo:27017/coral
      - REDIS_URI=redis://redis:6379
      - SIGNING_SECRET=<replace me with something secret>
    image: mongo:4.2
      - ./data/mongo:/data/db
    image: redis:3.2
      - ./data/redis:/data

# Start up Coral using Docker.
docker-compose up -d

It ran perfectly!

Now however, I need to make some further changes to my version of the Coral app.

I can build a new image, but how can I replace the image without touching the Mongo database?

I already learned that docker-compose down wipes out any data.

What would be the correct series of commands to stop the system, replace the image, and restart?

Depending wether you use the same tag for the new image, your steps will be slightly different:
– reuse tag: executing docker-compose pull && docker-compose up -d should do the trick.
– new tag: replace the image tag in your compose.yml, then execute docker-compose up -d

If your volumes (in fact your “volumes” are mount-binds rather then “real” volumes) are the only location in the container that needs to be preseved, then you should be good. All data outside the container side of the volume mapping will not survive when the container is replaced.

Great, that sounds easy. No need to stop the system?

Perfect, all is well. Thanks.