I have minor beef with Immich and basically any larger project and the way they go about their Docker Compose. Basically I feel they make the assumption that they’re the only thing running.

^Disclaimer: I fully accept this is all just me being too stupid and not the Immich development team.

This might be my turn to be too stupid but isn’t the point of docker that they all run in containers so it doesn’t matter? They can all use the same database port, because the database is in a container and so doesn’t prevent another database container using the same port. The port doesn’t need to be exposed to the host.

The only issue that comes up when running lots of services is accessing them all over http, and that’s what a reverse proxy is for. I run a dozen services on the same machine, mostly using the default docker compose files, and never have to mess with things like you have here.

So first things first, let’s rename database to immich-database, redis to immich-redis

Docker compose does this for you, so a service named database becomes immich-database if your compose project is named “immich” by placing it inside a folder by that name. You would have ended up with immich-immich-database

Same goes for your volumes.

most importantly, let’s give it a port that’s not the default postgres port that everyone wants to use. Easy right? Nope.

Since the postgres container is on that specific compose project network, the port is not shared and won’t interfere with any other compose projects, so there’s no need to change it away from the default. The main thing is each compose project is isolated by itself.

Also get rid of the ports: map for the database, it’s already part of the same compose network and does not need a port exposed to the outside.

so I went in and added the IP as the DB_URL to the .env

Don’t use IPs to refer to docker containers as they change, instead use the container name so database for example. (Just don’t prefix it with the project name, so don’t use immich-database for example).

Essentially just undo your changes and it should all work as expected, and will be entirely isolated so won’t interfere with any other containers or compose projects you run.

I don’t understand why you even change the names and ports. If you have a seperate docker-compose.yml file for Immich, the names won’t clash with other services (except if container_name is duplicated, but services like postgres and redis normally get one assigned automatically).

The ports are also limited to the container networks, so running several postgres instances still allows all of them to use the default port (except you pass them through from the host, which you normally shouldn’t do in closed networks like Immich’s or you run all services in network_mode: host, which is often a bad idea).

Opening ports in a postgres instance is not always needed, because you can attach yourself to the container and use the cli interface to do what you need.

They are the only thing running in that container/compose environment. That’s one of the main points of containerization! If you need to connect it to something else, like a reverse proxy, have it run in its own compose network and connect the two networks together.

RIP

I sympathize with the dissatisfaction with container and service naming schemes - it does get annoying when you take an overall look at all the containers and services running and things get muddy. In Immich, I renamed my services and containers for overall clarity. But why mess with ports?

Something I’ve noticed that is somewhat related but tangential to your problem: The result I’ve always gotten from using compose files is that container names and volume names get assigned names that contain a shared prefix by default. I don’t use docker and instead prefer podman but I would expect both to behave the same on this front. For example, when I have a file at nextcloud/compose.yml that looks like this:

volumes:
  nextcloud:
  db:

services:
  db:
    image: docker.io/mariadb:10.6
    ...
  app:
    image: docker.io/nextcloud
    ...

I end up with volumes named nextcloud_nextcloud and nextcloud_db, with containers named nextcloud_db and nextcloud_app, as long as neither of those services overrides this behavior by specifying a container_name. I believe this prefix probably comes from the file-level name: if there is one and the parent directory’s name otherwise.

The reasons I adjust my own compose files to be different from the image maintainer’s recommendation include: to accommodate the differences between podman and docker, avoiding conflicts between the exported listen ports, any host filesystem paths I want to mount in the container, and my own preferences. The only conflict I’ve had with other containers there is the exported port. zigbee2mqtt, nextcloud, and freshrss all suggest using port 8080 so I had to change at least two of them in order to run all three.

When you rename a service it helps to figure out why you’re doing it, because there’s different ways in which they relate to each other. There’s usually no point in renaming the services because they’re only used inside the compose for dependencies. You can rename the containers names but you have to be careful because if you don’t specify hostnames explicitly it uses the contain name and the services won’t find each other anymore.

I believe Immich ignores those env vars that specify the db and redis hostnames so don’t mess with that.

Man, I feel you. I hate Mattermost for its utter inability to run on anything else than port 8065 specifically.

The port for your postgres container is still the same for other containers, what you did was just map 5432 to 8765 for your host.

You don’t need to change the port or the host the immich services try to access within the network docker compose creates. You still have container_name: immich_postgres so you didn’t change anything for the other containers.

What you did was change how to write the command to up or down the container. From docker compose up database to docker compose up immich-database (which normally you won’t use since you want to up and down everything at once).
If you do docker ps you’ll still see the name of the container is immich_postgres

Hey so I’m intermediate at best. This to me sounds like permissions/routing problems. No user name specified in startup packet?

This sounds to me like you edited something that starts up postgres such that when it is started up it is not receiving a username at all

Shooting in the dark here, but perhaps take a look through logs for postgres. Check postgres and redis configs in these docker containers, they might be set up expecting something you changed, so they’re not receiving anything at all.

You’re sending an unmodified username to a new host name from what I see, right? Is the other side of this connection aware of these modifications?

Fuck that sounds vague. I might not even be right. I’d be digging through error logs for clues.

Like others have said, though. The whole benefit of dockerizing/containerizing services is so that that Docker container can contain anything that might otherwise conflict with it running in your systems environment. So it’s okay to have a doctor container where you’re using some environment variable like “database”. You don’t need to make it “service_database” in that services container.

Hope I am am providing some value here. It’s possible I not 🤷‍♂️

Can’t help but I totally agree about projects that assume they are the only thing running. That is the reason I don’t run nextcloud.

Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I’ve seen in this thread:

3 acronyms in this thread; the most compressed thread commented on today has 10 acronyms.

[Thread #659 for this sub, first seen 6th Apr 2024, 12:15] [FAQ] [Full list] [Contact] [Source code]

deleted by creator