Когда ты делаешь docker-compose up, он основан на docker-compose.yml файл.
Обычно это вызывает сеть, создает и запускает несколько служб. Если вы сделаете все возможное с -d флаг, docker-compose клиент отсоединяется и не трогает серверы.
Если вы сделаете docker-compose down, он отключает запущенные контейнеры и, кроме того, удаляет соответствующие сети.
Но ... что, если после up, то .yml файл ушел?
Вам нужно вручную выключить через docker stop поиск вручную, какие услуги в этом проекте, и docker rm и docker network rm и так далее?
Или docker-compose достаточно умен, чтобы пометить все объекты (контейнеры, сети и т. д.) тегом, чтобы вы могли сказать ему что-то вроде docker-compose down project-name так что это не смотрится в .yml (которого сейчас нет в файловой системе), а проверяет запущенные экземпляры и сети?
AFAIK вы не можете просто использовать docker-compose down без соответствующего docker-compose.yml.
Однако и ваша идея с тегами не так уж далека от реальности: при вызове docker-compose up, docker-compose ставит префиксы ко всем создаваемым им объектам по имени каталога компоновочного файла. Это позволяет идентифицировать наборы контейнеров, которые принадлежат друг другу, даже без соответствующих docker-compose.yml файл. Я часто пишу вариации этого в своей интерактивной оболочке:
docker rm $(docker ps -a | grep ... | cut -c -16)
Конечно, если бы кто-то написал этот сценарий «правильно», можно было бы использовать способность Docker форматировать и искать его выходные данные и правильно полагаться на имена или идентификаторы, а не только на первые 16 символов идентификаторов. Кроме того, эта операция идемпотентна, потому что она терпит неудачу, если нет совпадений для grep.
Впоследствии следуйте docker network rm ... и docker volume rm ... чтобы убрать остаток.