-
-
Notifications
You must be signed in to change notification settings - Fork 3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: microservices be gone #9551
Conversation
661ea35
to
65248e8
Compare
Deploying immich with
|
Latest commit: |
cc12c61
|
Status: | ✅ Deploy successful! |
Preview URL: | https://d139b555.immich.pages.dev |
Branch Preview URL: | https://feat-remove-microservices-co.immich.pages.dev |
Can you help write up the motivations behinds this change? So we can include those information in the next release note? Thank you! |
65248e8
to
89da5d6
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Noice
89da5d6
to
7a7ce85
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🚀
7a7ce85
to
264fa1b
Compare
264fa1b
to
cc12c61
Compare
Edit: leaving start.sh immich, start.sh microservices works fine. I will move this comment into the docs as an example of a simple split worker setup. To add to release notes: If you prefer to retain the previous structure, with a separate immich_server and immich_microservices container, this can be accomplished as follows: services:
immich-server:
...
+ environment:
+ IMMICH_WORKERS_INCLUDE: 'api'
immich-microservices:
...
+ environment:
+ IMMICH_WORKERS_EXCLUDE: 'api' |
Caution
Suggested change:
immich-microservices
container can be removed from docker composeBreaking change:
start-microservices.sh
andstart-server.sh
has been removed, we haven't used these for a while nowThis PR removes the need for the seperate microservices container, we tested the workers in the 1.105.0 release by moving microservices into a worker process and we've had no issues off the back of that.
api
workerIMMICH_WORKERS_INCLUDE
andIMMICH_WORKERS_EXCLUDE
as comma seperated variables to specify which workers you want to runIMMICH_WORKERS_INCLUDE
will override the defaults, only running what you specifyIMMICH_WORKERS_EXCLUDE
will apply against the defaults, orIMMICH_WORKERS_INCLUDE
if for whatever reason you wanted to include and then exclude some workers 😆This will simplify the setup process for most users by reducing the amount of containers they are running, the only real downside is that you now can't apply resource constraints against the microservices individually, however you could just go back to having the API and Microservices seperated using the env vars specified above.
Motivation
This is one of many pieces of upcoming work to change the way we handle jobs, microservices was always really a patch for the problem that we couldn't run background tasks within the main server as that would introduce contention for the API itself. Using workers, we can now have these within the same container but separated out into different V8 engines. Moving forwards, we will be looking to split out microservices into more underlying segments such as transcoding, thumbnails, etc, allowing us to have actual "microservices" and people who want to distribute just transcoding for example will be able to.