How could this be extended properly with another Dockerfile (if at all)

[SHxKM]

So, yesterday I managed to deploy a pet project to Railway based on this template. Like most other "serverless" hosting providers, they provide a lot of convenience at the cost of being less flexible about stuff. Neither Railway, Heroku, or Render support a native docker-compose file.

But since Redis and Postgres have public images, and since they don't depend on a project's specific codebase (we'll get to that in a bit), I was able to use the Dockerfile at the root of the project.

It did require doing two things:

Adding the following to bin/docker-entrypoint-web:

# Apply database migrations
echo "Apply database migrations"
python manage.py migrate

And binding to Railway's $PORT variable in Dockerfile:

ENTRYPOINT ["/app/bin/docker-entrypoint-web"]
ENV PORT=${PORT:-8000}
EXPOSE $PORT

But what about a 2nd service?

I know this is a project that is supposed to work where docker-compose works, but I was wondering what are my options here if I want to add celery or – in my case – dramatiq.

Railway doesn't support private images yet, so I can't publish one to a repository and use that.

The only option left is another Dockerfile, but I wonder if that is feasible without adding a lot of duplication/complexity. Right now the Dockerfile wants to start a gunicorn service, if I move that part out of there up to the docker-compose file, then Railway won't know what CMD to trigger when I deploy the web app.

Note: I'm looking to spin up this additional service inside a different dyno/vm/container.

[nickjj]

Hi,

Here's a couple of notes:

• The ENV and EXPOSE properties of your Dockerfile have no direct relationship to which port your app runs on
  • ENV just sets an env var, this app already configures gunicorn to read from the PORT env var with a fallback if it's undefined
  • EXPOSE is nothing more than documentation so when you run a docker container ls you can see which port your container is running on, but you can omit this or even set this to a different number and things will still work

I never used Railway but the only difference between Celery and gunicorn here is which command gets run when your container starts. Both services share the same code base and can use the same Dockerfile.

I don't know what Railway has for running multiple services but hopefully you can feed it the Celery command for your worker service and the gunicorn command for your web service. If not, then I would question that service because that's a really basic feature. I guess in the worst case scenario you can use the entrypoint script to pick which service to run based on setting an ENV var. This way both commands are defined in the entrypoint script and you'd set different env vars for the Celery or gunicorn services.

For example you can have WEB=true and in the entrypoint script you can have an if condition to run gunicorn if it's set else Celery or dramatiq.

I don't love this though because that's way different than how things will work in development and everywhere else besides Railway. You could introduce another env var like RAILWAY=true and only do that if it's Railway but this is starting to feel like a rat's nest of conditions but if that's the cards you're dealt with Railway, it could work. You could also piggy back off DEBUG here too, where the idea is if it's set to false then you know you're running in a non-development or local environment so it's expected to be Railway then.

[SHxKM]

Thanks @nickjj.

I don't know what Railway has for running multiple services but hopefully you can feed it the Celery command for your worker service and the gunicorn command for your web service.

Looks like they do (see img, or link)

So I guess I can provide the override like so:

web:

CMD ["gunicorn", "-c", "python:config.gunicorn", "config.wsgi"]

celery/dramatiq:

CMD ["python", "manage.py", "rundramatiq]

I wonder though, since I modified docekr-entrypoint-web to include migrations, if that's not gonna run my migrations unnecessarily:

set -e

# Always keep this here as it ensures your latest built assets make their way
# into your volume persisted public directory.
cp -r /public_collected /app

# Apply database migrations
echo "Apply database migrations"
python manage.py migrate

exec "$@"

Given that the Dockerfile references: ENTRYPOINT ["/app/bin/docker-entrypoint-web"]

[nickjj]

Personally I'm not a fan of running migrations in an entrypoint script. I like having this run separately in a pre or post hook depending on how I'm deploying my app. This way it only runs once and it's run in a controlled way that's independent of starting a container.

Most web frameworks have idempotent migrations, meaning if you run it 1 or 8 times, it's still going to produce the same output but it's still unnecessary work and has other negatives to run it as part of your container start process.

[SHxKM]

Oh wait, actually it says:

Dockerfile: the start command overrides the Docker image's ENTRYPOINT in exec form

[nickjj]

It sounds like you can supply a custom start command which means you're good to go without much complexity around entrypoint scripts and env vars. You can supply a different start command for your background worker command.