Эта шпаргалка - набор готовых команд для поиска контейнеров в Marathon. Копируйте, подставляйте свои значения и получайте результат за секунды. Фильтрация по имени, статусу, меткам, ресурсам, комбинирование условий через пайпы и регулярные выражения - всё, что нужно DevOps-инженеру и системному администратору для быстрой навигации по хранилищу ядер.
Все примеры используют Marathon REST API через curl и утилиту jq для обработки JSON. Убедитесь, что переменная MARATHON_URL указывает на ваш endpoint (по умолчанию http://master:8080). Если вы только начинаете работать с хранилищем, загляните в полное руководство по магазину контейнеров Marathon - там разобраны стратегии инвентаризации и массовых операций.
Базовый поиск контейнера по имени или образу
Самая частая задача - найти конкретный контейнер, зная часть его имени или используемый Docker-образ. Marathon API поддерживает фильтрацию по полю id и позволяет комбинировать её с утилитами командной строки.
Поиск по точному совпадению имени
Когда известно полное имя приложения, используйте прямую фильтрацию через параметр id. Этот метод возвращает строго одно совпадение и работает быстрее всего.
curl -s "${MARATHON_URL}/v2/apps?id=/production/web-service" | jq '.apps[] | {id: .id, instances: .instances, status: .tasks[0].state}'Вывод содержит идентификатор приложения, количество экземпляров и состояние первой задачи. Если приложение не найдено, массив apps будет пустым.
Поиск по части имени или образу
Часто точное имя неизвестно. Тогда получите полный список приложений и отфильтруйте его через grep или jq. Для поиска по имени контейнера:
curl -s "${MARATHON_URL}/v2/apps" | jq -r '.apps[] | select(.id | contains("nginx")) | "\(.id) \(.container.docker.image)"'Для поиска по Docker-образу - например, все контейнеры на базе redis:
curl -s "${MARATHON_URL}/v2/apps" | jq -r '.apps[] | select(.container.docker.image | contains("redis")) | "\(.id) \(.container.docker.image)"'Учитывайте регистрозависимость. Имена приложений в Marathon чувствительны к регистру: WebService и webservice - разные сущности. Если не уверены в регистре, приводите строки к нижнему регистру через ascii_downcase в jq:
curl -s "${MARATHON_URL}/v2/apps" | jq -r '.apps[] | select(.id | ascii_downcase | contains("webservice")) | .id'Фильтрация контейнеров по статусу и состоянию
Состояние контейнеров в Marathon определяется статусом задач. Основные статусы: Running (работает), Stopped (остановлен), Waiting (ожидает ресурсов), Delayed (отложен после сбоя), DeploymentFailed (ошибка развёртывания). Быстрая фильтрация по этим статусам критична при мониторинге и отладке. Если поиск не работает, обратитесь к руководству по диагностике проблем поиска - там разобраны типичные причины сбоев и способы их устранения.
Отбор только запущенных контейнеров
Получить список активных сервисов можно, отфильтровав приложения, у которых есть хотя бы одна задача в состоянии TASK_RUNNING:
curl -s "${MARATHON_URL}/v2/apps" | jq -r '.apps[] | select(.tasks[].state == "TASK_RUNNING") | "\(.id) \(.instances) \(.tasks[0].state)"' | sort -uБолее строгий вариант - проверить, что все задачи приложения запущены и здоровы. Для этого сравнивайте количество запущенных задач с полем instances:
curl -s "${MARATHON_URL}/v2/apps" | jq -r '.apps[] | select(([.tasks[] | select(.state == "TASK_RUNNING")] | length) == .instances) | .id'Поиск проблемных контейнеров
Контейнеры в статусах Waiting, Delayed или с ошибками развёртывания требуют немедленного внимания. Выявить их можно одной командой:
curl -s "${MARATHON_URL}/v2/apps" | jq -r '.apps[] | select(.tasks[] | .state == "TASK_WAITING" or .state == "TASK_ERROR" or .state == "TASK_FAILED") | "\(.id) \(.tasks[0].state) \(.tasks[0].message // "no message")"' | sort -uДля поиска приложений с неудавшимся развёртыванием проверяйте поле deployments - оно содержит информацию о текущих операциях:
curl -s "${MARATHON_URL}/v2/deployments" | jq -r '.[] | "\(.affectedApps[]) \(.currentStep) \(.totalSteps)"'Завершённые и остановленные контейнеры не исчезают бесследно - их записи доступны через API. Подробный разбор методов извлечения логов и конфигураций остановленных задач вы найдёте в статье поиск и анализ остановленных контейнеров в Marathon.
Продвинутый поиск: метки, окружение и ресурсы
Метки и переменные окружения - основной механизм организации контейнеров в Marathon. С их помощью разделяют production и staging, маркируют версии сервисов, указывают команду-владельца. Фильтрация по этим метаданным экономит часы при аудите и миграции.
Фильтрация по меткам
Метки хранятся в объекте labels определения приложения. Marathon API поддерживает прямую фильтрацию по меткам через параметр label:
curl -s "${MARATHON_URL}/v2/apps?label=environment%3Dproduction" | jq -r '.apps[] | "\(.id) \(.labels.environment)"'Для поиска по нескольким меткам указывайте параметр label несколько раз. Этот запрос найдёт все production-сервисы команды backend:
curl -s "${MARATHON_URL}/v2/apps?label=environment%3Dproduction&label=team%3Dbackend" | jq -r '.apps[] | .id'Если API-фильтрация недоступна, используйте jq для постобработки полного списка:
curl -s "${MARATHON_URL}/v2/apps" | jq -r '.apps[] | select(.labels.environment == "staging") | .id'Поиск по переменным окружения
Переменные окружения находятся в словаре env внутри определения контейнера. Прямой фильтрации через API нет, поэтому применяйте jq:
curl -s "${MARATHON_URL}/v2/apps" | jq -r '.apps[] | select(.container.docker.parameters // {} | .[].value? | contains("JAVA_OPTS")) | .id'Более точный поиск - проверка конкретного ключа и значения в env. Например, все контейнеры с Java-опциями, содержащими флаг -Xmx2g:
curl -s "${MARATHON_URL}/v2/apps" | jq -r '.apps[] | select(.env.JAVA_OPTS // "" | contains("-Xmx2g")) | "\(.id) \(.env.JAVA_OPTS)"'Отбор контейнеров по потреблению CPU и памяти
Ресурсные лимиты хранятся в полях cpus и mem. Чтобы найти все контейнеры, запрашивающие больше 2 CPU:
curl -s "${MARATHON_URL}/v2/apps" | jq -r '.apps[] | select(.cpus > 2) | "\(.id) \(.cpus) CPU \(.mem) MB"'Поиск контейнеров с памятью больше 1024 МБ:
curl -s "${MARATHON_URL}/v2/apps" | jq -r '.apps[] | select(.mem > 1024) | "\(.id) \(.mem) MB"'Комбинированный поиск «тяжёлых» сервисов - больше 4 CPU и больше 4096 МБ памяти:
curl -s "${MARATHON_URL}/v2/apps" | jq -r '.apps[] | select(.cpus > 4 and .mem > 4096) | "\(.id) CPU:\(.cpus) MEM:\(.mem)MB"'Комбинирование условий: пайпы и регулярные выражения
В крупных кластерах с сотнями контейнеров одного фильтра недостаточно. Пайпы и регулярные выражения позволяют строить точные запросы, отсекая лишнее на каждом шаге конвейера.
Объединение фильтров через пайпы
Классический пример: найти все запущенные контейнеры с образом, содержащим java, и памятью больше 512 МБ. Сначала фильтруем через jq, затем дофильтровываем grep-ом:
curl -s "${MARATHON_URL}/v2/apps" | jq -r '.apps[] | select(.mem > 512) | "\(.id) \(.container.docker.image) \(.mem)MB"' | grep 'java'Обратный порядок - сначала grep, потом jq - работает быстрее на больших выводах, но требует аккуратности с форматом:
curl -s "${MARATHON_URL}/v2/apps" | jq -r '.apps[] | "\(.id)|\(.container.docker.image)|\(.mem)|\(.tasks[0].state)"' | grep 'java' | awk -F'|' '$4=="TASK_RUNNING" && $3>512 {print $1, $2, $3"MB"}'Этот конвейер выдаёт список запущенных Java-контейнеров с памятью больше 512 МБ. Подставьте свои значения порогов и образа.
Использование регулярных выражений
Регулярные выражения незаменимы при поиске по шаблонам версий, окружений или соглашениям об именовании. Marathon API не поддерживает regex нативно, поэтому фильтрация выполняется на стороне клиента через grep -E или jq с функцией test.
Поиск всех контейнеров с версиями v1.2.x в имени:
curl -s "${MARATHON_URL}/v2/apps" | jq -r '.apps[] | select(.id | test("v1\\.2\\.\\d+")) | .id'Поиск контейнеров, имена которых соответствуют формату service-<окружение>-<название>:
curl -s "${MARATHON_URL}/v2/apps" | jq -r '.apps[] | select(.id | test("^/service-(prod|stage|dev)-[a-z]+$")) | .id'Через grep с Perl-совместимыми выражениями - поиск образов, содержащих openjdk любой версии:
curl -s "${MARATHON_URL}/v2/apps" | jq -r '.apps[] | .container.docker.image' | grep -P 'openjdk:\d+'Регулярные выражения оправданы, когда количество контейнеров переваливает за сотню и ручной перебор становится неэффективным. Для небольших кластеров достаточно фильтрации по подстроке.
Форматирование вывода для отчетов и скриптов
Сырой JSON неудобен для чтения человеком и избыточен для скриптов. Настройте вывод под конкретную задачу - таблица для визуального анализа, JSON для автоматизации, CSV для импорта в отчёты.
Вывод в табличном виде
jq позволяет собрать кастомную таблицу с нужными колонками. Минимальный набор полей для инвентаризации - ID, статус, количество экземпляров:
curl -s "${MARATHON_URL}/v2/apps" | jq -r '["ID","STATUS","INSTANCES","CPU","MEM(MB)"], (.apps[] | [.id, .tasks[0].state // "NO_TASKS", .instances, .cpus, .mem]) | @tsv' | column -t -s $'\t'Вывод с информацией о Docker-образе и метке окружения:
curl -s "${MARATHON_URL}/v2/apps" | jq -r '["ID","IMAGE","ENV"], (.apps[] | [.id, .container.docker.image, .labels.environment // "no-label"]) | @tsv' | column -t -s $'\t'Экспорт в JSON и обработка с jq
Для автоматизации собирайте агрегированные данные. Подсчёт контейнеров по статусам - полезно для дашбордов мониторинга:
curl -s "${MARATHON_URL}/v2/apps" | jq -r '[.apps[] | .tasks[0].state // "NO_TASKS"] | group_by(.) | map({status: .[0], count: length}) | .[]'Экспорт только ID и статуса в CSV для импорта в Google Sheets или Excel:
curl -s "${MARATHON_URL}/v2/apps" | jq -r '.apps[] | [.id, .tasks[0].state // "NO_TASKS"] | @csv' > marathon_inventory.csvСуммарное потребление CPU и памяти всеми контейнерами в кластере:
curl -s "${MARATHON_URL}/v2/apps" | jq '{total_cpus: [.apps[].cpus] | add, total_mem_mb: [.apps[].mem] | add}'Эти команды - основа для скриптов автоматизации. Интегрируйте их в CI/CD пайплайны или cron-задачи для регулярного аудита кластера. Если вы управляете контейнерами не только в Marathon, но и в Docker напрямую, обратитесь к шпаргалке по управлению Docker-контейнерами - там собраны практики отладки и мониторинга для production-окружения. Для построения централизованного сбора логов и метрик со всех контейнеров используйте руководство по маршрутизации логов и метрик - готовые конфигурации Fluentd, Prometheus и Grafana.