compose: docker-compose up fails if network attached to container is removed

Thanks for the report! I think there are several things to note here:

1. First and foremost, you shouldn’t delete networks managed by Compose unless you’re doing through Compose (typically with docker-compose down). Outside of this particular problem, it will certainly lead to a slew of other issues down the line.
2. Containers always connect to networks using the network ID which is guaranteed to be unique, whereas no such guarantee exists for names.
3. Your container is being restarted because no changes in configuration were detected, and the recreation of the network is considered to be an independent event. You could actually workaround the issue by using the --force-recreate flag.
4. There’s a case to be made for checking the network containers will connect to still exists, and reconnecting to the new network if necessary, but see item 1: this probably shouldn’t happen in the first place, and I think raising an error is equally valid in this instance.

It would be nice to have some “recreate if necessary” flag. I.e we want to ensure docker-compose up does whatever it takes to bring the environment up and if that means it needs to create a network then so be it!

--force-recreate fixed my problem, but it’s strange that the network reference persisted even after using down.

My 2 cents: of course it is an issue with docker-compose. When there is no container it will be created by default. When there is no image it will be built by default. When there is no network it will fail. That feels wrong for a tool that helps managing docker containers, images, networks and volumes.

From compose help:

...
  down               Stop and remove containers, networks, images, and volumes
...

I strongly disagree @shin- that you should know what you can and can not do with containers, images, networks and volumes managed from a docker-compose file. In worst case you are working together on one host and don’t know where the compose file is that created one of the things that you see with docker.

I’d second the suggestion from @dazinator for a “recreate if necessary” flag. I ran a docker network prune command just like @adambro, and since I run several different Docker setups for different projects, I didn’t realize that pruning while working on one large project was going to negatively affect the others. (My fault for not reading and thinking through the warning from network prune more when I did so.) But a flag like that would be a nice way of getting a project back on its feet quickly.

I had a similar problem. caused by trying to create botfront projects in two separate directories, completely borked the project.

I did:

docker-compose rm
botfront up -e botfront

and was able to get started again.

FYI If you use the docker dashboard to start/stop/restart the project from the image is a good idea.

you can also see the sub-services there too.

Thanks for detailed explanation. Indeed, it happened because I’ve run docker network prune some time before.

What I don’t get still is why it tries to remove Network that does not exist any more? I guess that caused “not found” error. I haven’t found any other instance of such error message.