Unable to stop compose services

[OnkelTem]

So I have the following services defined in my dobi.yaml:

compose=c-db:
    files: [docker-compose.db.yml]
    project: '{project}'

compose=c-app1:
    files: [docker-compose.app1.yml]
    project: '{project}'
    depends: ['c-db:detach']

compose=c-app2:
    files: [docker-compose.app2.yml]
    project: '{project}'
    depends: ['c-db:detach']

compose=c-app3:
    files: [docker-compose.app3.yml]
    project: '{project}'
    depends: ['c-db:detach']

alias=start:
    tasks: ['app1', 'app2', 'app3']

alias=stop:
    tasks: ['c-app1:down', 'c-app2:down', 'c-app3:down', 'c-db:down']

A side note: the reason why I have to create garbage docker-compose.*.yml for every app is that Dobi unable to run tasks in background, it wants docker-compose for itself, not matter is it really needed or not. See #42 for more info.

So they are started without problems:

$ dobi start

But then I can't stop them. No matter in which order I enumerate resources in the task property of the stop alias I always get an error message like:

$ dobi stop
[compose:down c-app1] docker-compose.app1.yml project down
Removing network project_default
ERROR: network project_default id 79145815095a9931e7177cbe5dba4fc892e5525f62c297d0139263015649c270 has active endpoints
[ERROR] failed to execute task "c-app1:down": exit status 1

Also, without recently added :detach task I could not even have been able to run dependent services ("composes") since Dobi is always exiting any previous composed containers before starting a new one (this is however not the case for job + a dependent compose - then it seems to not require :detach and usual :up works pretty well).

Placing apps and db in a separate docker-compose has the following drawbacks:

1. I need to run apps separately, e.g. dobi app1-start / dobi app1-stop etc and so to get this all working I'd have to create a Cartesian product of every combination of apps and database, having a lot of duplicating records and docker-compose files like:

   • docker-compose.app1.yml
   • docker-compose.app2.yml
   • docker-compose.app1-app2.yml
   • docker-compose.app1-app2-app3.yml
   • etc.. well you got the idea, right?

2. My jobs depend on at least db docker compose service so I need to depend on it in the dobi.yaml. So having it listed in there is inevitable.

[dnephin]

Why do you want to put the apps into different compose files instead of putting them all in the same compose file?

You can get around the network remove error by making the docker-compose files 2 and 3 use an external network for default. https://docs.docker.com/compose/networking/#configure-the-default-network

[OnkelTem]

Why do you want to put the apps into different compose files instead of putting them all in the same compose file?

Daniel. How would I run my applications separately then? I can't use Dobi for that. Which means that I can use only docker-compose, so is that what you propose now - using both docker-compose AND Dobi at the same time? The need of Dobi appears exactly when you want to have something more than that bloody docker-compose which is unable to comprehend a TASK concept. Now we have yet another tool which is unable to comprehend a SERVICE concept and not only that - being absolutely eligible and potent to automate docker-compose tasks (like up service, run service, build service), it like refuses to be more usable than now, like you're obligated (by work in docker-compose team maybe?) to not doing something which docker-compose already does.

And I already opened a question about making Dobi a replacement for docker-compose but you have declined the proposition. Now when I have almost completed setup which is based on Dobi and uses docker-compose files only as a workaround to overcome the missing concept of service in Dobi, I can prove it to you: there is no need for docker-compose at all if only you make a little step forward with Dobi development.

You can get around the network remove error by making the docker-compose files 2 and 3 use an external network for default. https://docs.docker.com/compose/networking/#configure-the-default-network

One more pair of crutches? Thanks I'll take a look.

[dnephin]

there is no need for docker-compose at all if only you make a little step forward with Dobi development.

Yes I agree. I would like to add the service concept, but I haven't had the time.

[OnkelTem]

I haven't had the time.

heh, that's what I've just guessed in the famous #45 ticket :)