How do I prevent my script from being run every time a Docker container is brought up?

The idea of seeding your database in the first run, is a very common case. As others have suggested, you can change your entrypoint.sh script and apply some conditioning logic to it and make it the way you want it to work.

But I think it is a really better practice if you separate the logic for seeding the database and running services and do not keep them tangled to each other. This might cause some unwanted behavior in the future.

I was going to suggest a workaround using docker-compose and started searching for some syntax for excluding some services while doing docker-compose up but found out this is still an open issue. But I found this stack overflow answer witch has suggested a very nice approach.

version: '3' services: all-services: image: docker4w/nsenter-dockerd # you want to put there some small image command: sh -c "echo start" depends_on: - mysql - web - apache mysql: restart: always image: mysql:5.7 environment: MYSQL_DATABASE: 'maps_data' # So you don't have to use root, but you can if you like MYSQL_USER: 'chicommons' # You can use whatever password you like MYSQL_PASSWORD: 'password' # Password for root access MYSQL_ROOT_PASSWORD: 'password' ports: - "3406:3406" volumes: - my-db:/var/lib/mysql web: restart: always build: ./web ports: # to access the container from outside - "8000:8000" env_file: .env environment: DEBUG: 'true' command: /usr/local/bin/gunicorn maps.wsgi:application -w 2 -b :8000 depends_on: - mysql apache: restart: always build: ./apache/ ports: - "80:80" #volumes: # - web-static:/www/static links: - web:web seed: build: ./web env_file: .env environment: DEBUG: 'true' entrypoint: /bin/bash -c "/bin/bash -c \"$${@}\"" command: | /bin/bash -c " set -e python manage.py loaddata maps/fixtures/country_data.yaml python manage.py loaddata maps/fixtures/seed_data.yaml /bin/bash || exit 0 " depends_on: - mysql volumes: my-db: 

If you use something like above, you will be able to run seeding stage before running docker-compose up.

For seeding your databse, run:

docker-compose up seed 

For running all your stack, use:

docker-compose up -d all-services 

I think it is a clean approach and, can be extended to many different scenarios and use cases.

UPDATE

If you really want to be able to run the whole stack altogether and also prevent unexpected behaviors caused by running loaddata command multiple times, I would suggest you define a new django management command to check for existing data. Look at this:

checkseed.py

from django.core.management.base import BaseCommand, CommandError from project.models import Country # or whatever model you have seeded class Command(BaseCommand): help = 'Check if seed data already exists' def handle(self, *args, **options): if Country.objects.all().count() > 0: self.stdout.write(self.style.WARNING('Data already exists .. skipping')) return False # do all the checks for your data integrity self.stdout.write(self.style.SUCCESS('Nothing exists')) return True 

And after this, you can change your seed part of docker-compose as below:

 seed: build: ./web env_file: .env environment: DEBUG: 'true' entrypoint: /bin/bash -c "/bin/bash -c \"$${@}\"" command: | /bin/bash -c " set -e python manage.py checkseed && python manage.py loaddata maps/fixtures/country_data.yaml python manage.py loaddata maps/fixtures/seed_data.yaml /bin/bash || exit 0 " depends_on: - mysql 

This way, you can be sure that if anyone runs docker-compose up -d by mistake, will not cause integrity errors and problems like that.

Instead of using the entrypoint.sh file, why not just run the commands in the web/Dockerfile?

RUN python manage.py migrate maps RUN python manage.py loaddata maps/fixtures/country_data.yaml RUN python manage.py loaddata maps/fixtures/seed_data.yaml 

That way these changes will be baked into the image and, when you start the image, these changes will already have been executed.

I had a similar case recently. As the "ENTRYPOINT" contains the command that will be executed every time the container starts a solution would be to include some logic on the entrypoint.sh script in order to avoid to apply the updates ( in your case the migration and the load of the data ) if the effects of these operations are already present on the database.

For example:

#!/bin/bash set -e #Function that goes to verify if effects of migration and load data are present on database function checkEffects() { IS_UPDATED=0 #Check effects and set to 1 IS_UPDATED if effects are not present } checkEffects if [[ $IS_UPDATED == 0 ]] then echo "Database already initialized. Nothing to do" else echo "Database is clean. Initializing it" python manage.py migrate maps python manage.py loaddata maps/fixtures/country_data.yaml python manage.py loaddata maps/fixtures/seed_data.yaml fi exec "$@" 

However the scenario is more complex because to verify the effects that allow to decide if to proceed or not with the updates can be a quite difficult if these involves multiple data and data. Moreover it becomes very complex if you think on the containers upgrade over time.

Example: Today you're working with a local Dockerfile for your web service but I think in production you'll start to versioning this service uploading it on a Docker registry. So when you'll upload your first release ( for example the 1.0.0 version ) you'll specify the following on your docker-compose.yml:

web: restart: always image: <DOCKER_REGISTRY_HOST>:<DOCKER_REGISTRY_PORT>/web:1.0.0 ports: # to access the container from outside - "8000:8000" 

Then you'll release the "1.2.0" version of the web service container when you'll include other changes on the schema for example loading other data on entrypoint.sh:

#1.0.0 updates python manage.py migrate maps python manage.py loaddata maps/fixtures/country_data.yaml python manage.py loaddata maps/fixtures/seed_data.yaml #1.2.0 updates python manage.py loaddata maps/fixtures/other_seed_data.yaml 

Here you'll have 2 scenarios ( let's ignore for now the need to check for effects on the script ):

1- You deploy for the first time your services with web:1.2.0: As you start from a clean database you should be sure that all updates are executed ( both 1.1.0 and 1.2.0 ).

The solution to this case is easy because you can just execute all updates.
2- You upgrade web container to 1.2.0 on an existing environment where 1.0.0 was running: As your database has been initialized with updates from 1.0.0 you should be sure that only 1.2.0 updates are executed

Here is difficult because you should be able to check what is the version on database applied in order to skip 1.0.0 updates. This will means you should store the web version somewhere on database for example

As per all this discussion so I think the best solution is to work directly on scripts that goes to create schema and populate data in order to make these instructions idempotent paying attention on upgrade ones.

Some examples:

1- Create a table

Instead to create table as follow:

CREATE TABLE country 

use the if not exists to avoid table already present error:

CREATE TABLE IF NOT EXISTS country 

2- Insert default data

Instead to insert data without primary key specified:

INSERT INTO maps.country (name) VALUES ("USA"); 

Include primary key in order to avoid duplicates:

INSERT INTO maps.country (id,name) VALUES (1,"USA"); 

Usually build and deploy steps are separated.

Your ENTRYPOINT is part of deploy. If you want configure manually witch deploy run should run migrate commands and witch just replace containers by a new one (maybe from fresh image), then you can slit it into a separate commands

start database (if not running)

docker-compose -p production -f docker-compose.yml up mysql -d 

migrate

docker run \ --rm \ --network production_default \ --env-file docker.env \ --entrypoint python \ my-backend-image-name:prod python manage.py migrate maps 

and then deploy fresh image

docker-compose -p production -f docker-compose.yml up -d 

And each time manually decide should you run migrate step or not