Текст и данные · Инструкция
Docker ps --filter: фильтрация контейнеров без grep
Docker ps --filter удобнее `grep`, когда нужно выбирать контейнеры по состоянию, имени, label, образу, volume или.
Короткий ответ
Как пользоваться docker ps --filter: фильтры status, name, label, ancestor, volume и publish, комбинации условий и безопасные примеры для shell.
Почему фильтр Docker надёжнее поиска по строке
`docker ps` без `-a` показывает только работающие контейнеры, поэтому поиск завершившихся экземпляров надо начинать с `docker ps -a`. Флаг `--filter` или сокращённый `-f` передаётся в формате `key=value`, а Docker сопоставляет значение с конкретным свойством контейнера. Это принципиально отличается от `grep`: вы фильтруете данные до форматирования вывода, а не ищете случайное совпадение в колонках. Такой подход особенно полезен для `status=exited`, `name=api`, `label=env=prod`, `ancestor=nginx` и выборок по подключённому volume. После того как выборка проверена, её можно сочетать с `--format` или `-q` для машинной обработки.
Предупреждение: Сначала запускайте фильтр в читаемом табличном виде, и только после проверки добавляйте `-q` и команды удаления/остановки.
Полезные ключи фильтра и типичный смысл
- status=exited. завершившиеся контейнеры. поиск остановленных процессов
- name=api. контейнеры с совпадением по имени. выбор сервиса по имени
- label=env=prod. контейнеры с label и значением. группировка окружений
- ancestor=nginx. контейнеры от указанного образа/предка. аудит развернутых образов
- volume=data. контейнеры, монтирующие volume/путь. поиск потребителей хранилища
- publish=8080. контейнеры с опубликованным портом. поиск владельца порта
Совет: Фильтры зависят от команды и версии CLI; перед автоматизацией полезно сверяться с `docker ps --help` и актуальной документацией.
Как собрать точную выборку шаг за шагом
- 1: Определите, нужны только running-контейнеры или все состояния. Для второго случая сразу используйте `docker ps -a`, иначе завершившийся контейнер никогда не попадёт в результат.
- 2: Добавьте первый структурный фильтр, например `docker ps -a --filter status=exited`. Посмотрите на NAME, IMAGE и STATUS и убедитесь, что выборка соответствует задаче.
- 3: Добавьте уточнение, например `--filter label=project=myapp` или `--filter ancestor=nginx`. Несколько фильтров по разным ключам сужают выборку; одинаковые ключи могут использоваться для нескольких допустимых значений.
- 4: Если нужен только идентификатор, после проверки добавьте `-q`. Для отчёта лучше оставить человекочитаемый вывод либо задать `--format` с нужными полями.
- 5: Только после визуальной проверки подставляйте IDs в следующую команду. Для потенциально разрушительных операций сделайте отдельный предварительный запуск без `xargs docker rm` или похожей связки.
Важно: Если команда будет работать по расписанию, добавьте labels при создании контейнеров: стабильная метка обычно надёжнее шаблона имени.
Как комбинировать условия и не получить неожиданно широкую выборку
Самая частая ошибка — предполагать, что любой повтор `--filter` обязательно работает как логическое AND. У Docker правила зависят от ключа: несколько разных критериев обычно уточняют выборку, а несколько значений одного фильтра могут означать альтернативы. Поэтому сложную команду надо проверять на реальном наборе контейнеров до автоматического действия. Например, безопасно сначала выполнить `docker ps -a --filter status=exited --filter label=project=myapp`, сравнить список с ожидаемым и только затем использовать `-q`. Не стоит заменять label фильтром по части имени, если имена формируются оркестратором и могут меняться. Для регулярных операций labels дают более устойчивую семантику: проект, окружение, роль или владелец.
Примеры для диагностики: image, volume и порт
Если нужно понять, какие контейнеры используют конкретный image, фильтр `ancestor` полезнее ручного просмотра колонки IMAGE, потому что учитывает образ как критерий Docker. Фильтр `volume` помогает найти потребителей именованного тома или точки монтирования перед обслуживанием хранилища. Фильтры по опубликованным портам полезны, когда порт хоста уже занят и нужно быстро найти контейнер-владельца. После такой выборки можно добавить `--format 'table {{.Names}}\t{{.Image}}\t{{.Ports}}'`, чтобы вывести только релевантные поля. Не путайте опубликованный порт хоста с `EXPOSE` внутри образа: это разные уровни, и диагностика конфликта порта должна смотреть именно фактическую публикацию.
Проверка перед использованием фильтра в скрипте
- Есть ли `-a`, если важны stopped/exited контейнеры.
- Фильтруется структурное поле Docker, а не текст после `grep`.
- Для production-объектов есть стабильный label, а не только имя.
- Выборка просмотрена без `-q` перед разрушительным действием.
- Команда корректно ведёт себя при нулевом результате.
- В shell учтены пробелы, кавычки и поведение `xargs` при пустом вводе.
Важно: Для удаления контейнеров лучше строить отдельный dry-run список IDs и логировать его. Ошибка фильтра в read-only отчёте безобидна, а в цепочке с `docker rm` — уже нет.
Пример безопасного перехода от поиска к действию
Предположим, нужно найти завершившиеся контейнеры только проекта billing. Сначала выполните `docker ps -a --filter status=exited --filter label=project=billing` и глазами проверьте имена, образ и время завершения. Затем повторите команду с `-q`, но пока только сохраните IDs или выведите их отдельной строкой. Если результат неожиданно пустой, проверьте labels у существующих контейнеров через inspect, а не расширяйте фильтр до случайного совпадения по имени. Если результат слишком широк, добавьте ещё один устойчивый критерий, например environment. Такой двухэтапный подход занимает несколько секунд, зато защищает от удаления контейнеров другого проекта при ошибке в регулярном выражении или соглашении об именах.
Как не превратить фильтр в опасную массовую команду
Главный риск появляется не на этапе просмотра, а когда список сразу передают в `docker stop`, `rm` или другой изменяющий команду вызов. Сначала выполните тот же набор `--filter` без `-q` и проверьте имена, образы, статус и labels. Затем повторите выборку с `--format`, если нужно увидеть только контрольные поля, и лишь после этого используйте `-q` как источник ID. Для автоматизации полезнее фильтровать по стабильному label вроде `env=prod` или `com.example.role=worker`, чем по части имени, которое может измениться после рефакторинга. Если результат неожиданно широкий, добавляйте условия по одному и каждый раз пересматривайте выборку.
Что учитывать
`docker ps` без `-a` показывает только работающие контейнеры, поэтому поиск завершившихся экземпляров надо начинать с `docker ps -a`. Флаг `--filter` или сокращённый `-f` передаётся в формате `key=value`, а Docker сопоставляет значение с конкретным свойством контейнера. Это принципиально отличается от `grep`: вы фильтруете данные до форматирования вывода, а не ищете случайное совпадение в колонках. Такой подход особенно полезен для `status=exited`, `name=api`, `label=env=prod`, `ancestor=nginx`…
Источники и проверка
Фактическая часть сверена по первичным источникам (в т.ч. docker container ls). Пример и формулировки — редакция N1RO на 2026-09-20.