Postgres docker containers have a problem of multiple restarts.
A simple way to check for them being 'up' up (i.e. initialized, reachable, and ready) is not through pg_isready but instead by checking on the set database port (default 5432) if a connection can be established.
It will not send anything back really since it's not designed as an http server. So curl -sFfI db:5432 for example will get back 52 Empty Reply with status code 52. If you want to check with that make sure to compare to error code 52!
The easiest option if another container has to wait for this one to start up (and especially in a docker stack environment where no wait_for option exists) is: nc db 5432 which will only return true when the port is ready.
An example for the nextcloud fpm container waiting for database readiness: entrypoint: sh -c "while !(nc -z db 5432); do sleep 1; done; /entrypoint.sh php-fpm"
Amazing pre-setup mopidy and snapcast instance. Simply point your docker-compose file digestor at it and you're basically good to go with iris and spotify integration running (though you have to enter your credentials into .conf file for spotify to fully work). Then begin populating the music folder and you have your local music added.
Using an s3 backend (like wasabi, spaces, minio or others) as the block storage for a jellyfin (vps or homelab) installation with rclone. A bit fiddly, but can probably be adapted to iac -style docker stacks and so on.
Receive notifications when an image is updated on a Docker registry.
Does not auto-update (different from e.g. watchtower), but provides a wide variety of services for notification so that you can manually update the container, after reviewing its changes and potentially creating backups.
When I had this problem, it was a DNS problem. Traefik was trying to connect to the wrong IP address - an IP address that was on a network with no access from traefik.
Setting providers.docker.network solved my problem - but careful, you need to use the full network name as visible with docker network ls (in my case it was pi_traefik-web - for you it should be traefik_proxy).
In theory, you could also set the label traefik.docker.network=traefik_proxy to your nextcloud-app service.
This problem can be diagnosed through the traefik dashboard: look for the network ip a specific service is assigned -- does it show the 'public' network compatible ip?
FoldFold allExpandExpand allAre you sure you want to delete this link?Are you sure you want to delete this tag?
The personal, minimalist, super-fast, database free, bookmarking service by the Shaarli community