best practices for deploying FastAPI, Redis and RQ workers?

I have deployed a FastAPI server and a RQ Worker in separate containers on Railway based on the same monorepo: https://github.com/kristiankauffeld/fastapi-redis The repo is structured by separating the services into different directories where they have their own Dockerfile. The two services communicate through a Redis instance. Currently there is some code duplication since I have copied the "utils" folder both into the "api" and the "rq-worker" folder. So if anyone perhaps could share some insight whether there is a better approach to deploy an application like this. Thanks
GitHub
GitHub - kristiankauffeld/fastapi-redis
Contribute to kristiankauffeld/fastapi-redis development by creating an account on GitHub.
Solution:
why not deploy from the root of the repo, with the same dockerfile for both services just set the applicable start command in each service settings
Jump to solution
26 Replies
Percy
Percy4mo ago
Project ID: eed3718a-5d34-41b6-87e6-0d476ca1cc53
kristiankauffeld
eed3718a-5d34-41b6-87e6-0d476ca1cc53 Specifically I'm interested in knowing if it's possible for me to just have a single Dockerfile in the root of the repository instead of having almost identical dockerfiles in the "api" and "rq-worker" folders where the only difference is the last CMD instruction so to reduce code duplication
kristiankauffeld
https://docs.railway.app/guides/monorepo so as I understand, I would have to use Nixpacks to solve me issue?
Railway Docs
Deploying a Monorepo | Railway Docs
Documentation for Railway
Brody
Brody4mo ago
can you send me your two Dockerfiles
Solution
Brody
Brody4mo ago
why not deploy from the root of the repo, with the same dockerfile for both services just set the applicable start command in each service settings
kristiankauffeld
let me try
kristiankauffeld
so now the repo only contains a single Dockerfile in the root of the project, but Nixpacks build fails with error: "No start command could be found".
No description
No description
Brody
Brody4mo ago
nixpacks isnt used when theres a dockerfile, you have something misconfigured somewhere
Adam
Adam4mo ago
also, you’ve set the build command. Not the start command
kristiankauffeld
omg I just realized haha
Adam
Adam4mo ago
if you’re using a dockerfile you shouldn’t need either, but just pointing out
kristiankauffeld
@Adam but I am trying to figure out how to start both the FastAPI and the RQ Worker using a single Dockerfile in the root project
Brody
Brody4mo ago
a custom start command is needed for that yes
kristiankauffeld
the FastAPI deploy now logs the error "Invalid value for '--port': '$PORT' is not a valid integer."
No description
kristiankauffeld
should I just ignore the "buildCommand is only supported for the Nixpakcs builder" warning?
Brody
Brody4mo ago
yes it can be ignored what is your current start command for this service
kristiankauffeld
uvicorn api.src.main:app --host 0.0.0.0 --port $PORT
Brody
Brody4mo ago
set the start command to
/bin/sh -c "uvicorn api.src.main:app --host 0.0.0.0 --port $PORT"
/bin/sh -c "uvicorn api.src.main:app --host 0.0.0.0 --port $PORT"
kristiankauffeld
thx @Brody ! now the FastAPI server is up and running
Brody
Brody4mo ago
awsome
kristiankauffeld
but still having issues with the RQ Worker container. The deployment logs the error: "ValueError: Redis URL must specify one of the following schemes (redis://, rediss://, unix://)". I'm using this custom start command: rq worker --url $REDIS_URL
No description
kristiankauffeld
is the solution the same?
Brody
Brody4mo ago
yep without wrapping the command in a shell the environment variables arent escaped so the command would see the literal string $REDIS_URL or $PORT and of course those literal strings are not a valid redis url or a valid port
kristiankauffeld
that makes sense now the whole application works. Thanks again @Brody !
Brody
Brody4mo ago
no problem!