ahab guessed that the django service is called django and the postgres one db,
falling back on AHAB_DJANGO_CONTAINER and AHAB_POSTGRES_CONTAINER. The standard
project layout happens to agree, but nothing enforces it, and a stack naming
them web and database could not use ahab without setting both variables.
One `docker compose config --format json` call, roughly 120ms, resolves the
stack even while it is down, and the services are identified from what they
are rather than what they are called:
- postgres is the service whose image is a postgres flavour, matching postg,
timescale, pgvector or citus. Nothing else counts.
- django is the service that both builds an image and has
DJANGO_SETTINGS_MODULE in its environment. A celery worker sharing the same
build and env_file matches too, so published ports break the tie: the service
answering requests wins.
Neither guess is allowed to be wrong quietly. No match, or two candidates that
cannot be told apart, is an error naming the services it looked at. There is no
variable to fall back on: both container variables are gone, along with the
guessed defaults they backed up, so an ambiguous stack is fixed in the compose
file rather than worked around per developer.
Every service lookup goes through these rules, so `compose exec` and the whole
django group agree on which container they mean.
POSTGRES_USER and POSTGRES_DB come off the detected service, so dropdb,
createdb, pg_restore and pg_dump stop assuming the role and database are both
literally `db`, falling back to that only when the service declares neither.
Note that env_file entries are merged into a service's environment, so
POSTGRES_* is not safe for identifying the database service: one such line in a
project's .env would make the django service match as well. That is why
identification uses the image and only credentials use the environment.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Read default postgres compose service name and default django compose
service name from env variables.
AHAB_POSTGRES_CONTAINER - defaults to `appserver`
AHAB_DJANGO_CONATINER - defaults to `postgresdb`
Default values are there for 100% backwards compatibility.
Fixed issue where arguments passed to `compose stop` weren't passed to
the underlying command. Added pg_isready call between each command call
in restore script.
Exec is new command scoped under compose. It allows sending commands
directly into appserver container. I will make this
customizable/controllable in the future.
Implemented custom command builder with nicer api suited for my needs.
Also returned error if there are no containers in
`scripts::postgres::get_containers`.
Allow for starting just some of the containers. This will be needed for
implementing postgres::import where we'll need to stop all containers
and then only start postgres container.
Implemented basic wanted functionality for docker compose subcommands.
We currently assume that docker-compose.yaml file is located in
local/docker/ folder.
Made initial command scopes
d -> docker related commands
dc -> docker compose related commands
dj -> django related commands
pg -> postgres related commands
