[Feature]: Add support for custom domain names of individual services

[PixelJonas]

Feature detail

Currently, Immich is expecting to have every service run with a specific name inside a docker network.

If someone is to change the name of a service in their docker-compose.yaml these services would not be able to find each other.

I propose to have a set of Environment variables (like REDIS_HOSTNAME is used for redis) for every service to configure hostname and/or port for communication between immich services

Platform

Server

[akoyaxd]

You can change the Name of the container, if you set their original name as hastname in your Docker compose file. That's what I did.

Like this:

machine-learning:
    image: altran1502/immich-machine-learning:release
    entrypoint: ["/bin/sh", "./entrypoint.sh"]
    volumes:
      - /opt/immich/upload:/usr/src/app/upload
    env_file:
      - .env
    environment:
      - NODE_ENV=production
    depends_on:
      - postgres
    restart: unless-stopped
    hostname: immich-machine-learning

[alextran1502]

You can change the Name of the container, if you set their original name as hastname in your Docker compose file. That's what I did.

Like this:

machine-learning:
    image: altran1502/immich-machine-learning:release
    entrypoint: ["/bin/sh", "./entrypoint.sh"]
    volumes:
      - /opt/immich/upload:/usr/src/app/upload
    env_file:
      - .env
    environment:
      - NODE_ENV=production
    depends_on:
      - postgres
    restart: unless-stopped
    hostname: immich-machine-learning

When you specify the container's hostname, does the object objection still work?

[akoyaxd]

When you specify the container's hostname, does the object objection still work?

Yes, I can search for things like planes etc.

[PixelJonas]

So while each component (web, microservices, machine-learning, proxy) are developed in individual projects and can run independently, there are a lot of "assumptions" each services makes about the others.

For example web makes the assumption, that server is running on the same host under /api on port 3000 and is reachable under the DNS name immich-server.

While the app still works, it's still a monolith of things having to be in specific places and be configured at a specific way. I tested removing the rewrite line from the immich-proxy and setting the Nest.js app.setGlobalPrefix("/api") deploying the server directly under /api and removing the dependency to the NGINX server doing something. This breaks immich-web - while I can't pinpoint exactly why I need to re-add the /api in the immich-web - api.ts to the serverApi.setBaseUrl. The /api path seems to be harcoded at a few places and dynamically injected at others (openapi?).

I'm happy to get a draft PR going with the goal of ultimately having the capability to deploy every service separately to each other. But would like to discuss this here first, if this is a direction the projects wants to go.

This would (at least) require that very Hostname, Port and Path of API's need to be configurable via env vars.

@alextran1502 what do you think? Should get something like this going?

[thefirstofthe300]

My homelab is running Kubernetes so I'm building a helm chart to deploy Immich. This capability seems like a requirement to allow for k8s deployments. There is no guarantee the services will be on the same host and it would be nice to not be reliant on hardcoded hostnames.

[PixelJonas]

hey @thefirstofthe300 , this came up while building a helm-chart for immich. We agreed on having hosting community helm-chart at https://github.com/immich-app/immich-charts.

You can find my current WIP for the Chart here https://github.com/PixelJonas/immich-charts/tree/feature/immich-chart

feel free to contribute. This Issue is currently blocking the Helm-Chart though, as there is also some NGINX rewriting as part of immich-proxy which I did not translate to the chart

[ViViDboarder]

Support for this is now merged.