Docker Build/Deploy using Bash Script

Typically a Docker image is self-contained, and knows how to start itself up without any user intervention. With some limited exceptions, you shouldn't ever need to docker-compose run interactive shells to do post-deploy setup, and docker exec should be reserved for emergency debugging.

You're doing two things in this script.

The first is to install Node packages. These should be encapsulated in your image; your Dockerfile will almost always look something like

FROM node
WORKDIR /app
COPY package*.json .
RUN npm ci              # <--- this line
COPY . .
CMD ["node", "index.js"]

Since the dependencies are in your image, you don't need to re-install them when the image starts up. Conversely, if you change your package.json file, re-running docker-compose build will re-run the npm install step and you'll get a clean package tree.

(There's a somewhat common setup that puts the node_modules directory into an anonymous volume, and overwrites the image's code with a bind mount. If you update your image, it will get the old node_modules directory from the anonymous volume and ignore the image updates. Delete these volumes: and use the code that's built into the image.)

Database migrations are a little trickier since you can't run them during the image build phase. There are two good approaches to this. One is to always have the container run migrations on startup. You can use an entrypoint script like:

#!/bin/sh
python manage.py migrate_all
exec "$@"

Make this script be executable and make it be the image's ENTRYPOINT, leaving the CMD be the command to actually start the application. On every container startup it will run migrations and then run the main container command, whatever it may be.

This approach doesn't necessarily work well if you have multiple replicas of the container (especially in a cluster environment like Docker Swarm or Kubernetes) or if you ever need to downgrade. In these cases it might make more sense to manually run migrations by hand. You can do that separately from the main container lifecycle with

docker-compose run web \
  python manage.py migrate_all

Finally, in terms of the lifecycle you describe, Docker images are immutable: this means that it's safe to rebuild new images while the old ones are running. A minimum-downtime approach to the upgrade sequence you describe might look like:

git pull

# Build new images (includes `npm install`)
docker-compose build

# Run migrations (if required)
docker-compose run web python manage.py migrate_all

# Restart all containers
docker-compose up --force-recreate