Вопрос или проблема
Мы используем собственный агент Bitbucket для пайплайнов, для чего установили Bitbucket runner на машине EC2 типа Amazon Linux.
Пайплайны работали правильно в течение месяца. Позже контейнеры пайплайнов начали завершаться с ошибкой Docker 137.
Примечание: Мы запланировали обновления yum, которые будут выполняться каждую неделю на машине runner.
Итак, вот действия, которые я предпринял:
- Проверил обновления yum и системные журналы на предмет аномалий
- Перезапустил службу Docker и перезагрузил машину
- Мониторил загрузку ЦП и память во время выполнения пайплайнов
- Обновил версию bitbucket runner до последней
- Увеличил конфигурацию ЦП и памяти машины
- Проверил место на диске, которое составляет всего 35%
Ничто не помогло. Пайплайны продолжали завершаться с той же ошибкой.
Позже, так как проблема была непредсказуемой, с помощью команды поддержки AWS я перенес все runners на оптимизированную машину AMI ECS, так как эта AMI в основном предназначена для контейнеров. То же самое произошло с этой машиной. Через месяц пайплайны начали снова завершаться с той же ошибкой. На этот раз я повторно исследовал проблему и вручную проверил обновления yum на предмет несовпадений с Docker.
Примечание: Контейнер runner работает правильно, но контейнеры пайплайнов завершаются с кодом 137, что не связано с проблемами OOM и хранилищем.
Позже мы снова перенесли его на другую машину Amazon Linux. Та же проблема в третий раз через месяц.
Ничто не помогает. При проверке я обнаружил, что удаление декларации “Docker as a service” в пайплайне делает пайплайн успешным. Вот пример конфигурации пайплайна.
- step:
name: generate dbt elementary report
image:
name: edr-build:latest
clone:
enabled: true
runs-on:
- 'linux'
- 'self.hosted'
- 'test'
services:
- docker
caches:
- docker
script:
- docker --version
- docker build -t <tag> .
- docker push to <ecr>
Я не могу удалить раздел services:docker, так как мне нужно выполнять команды docker в пайплайне.
И пайплайны завершаются внезапно. Если это действительно связано с разделом services:docker или с машиной runner, пайплайны должны были бы завершаться с ошибкой 137 с самого начала.
Я не могу просмотреть журналы контейнеров пайплайнов, которые завершаются, так как они удаляются сразу после завершения выполнения пайплайна. Я также не могу их перечислить с помощью “docker ps -a”. Все записи контейнеров пайплайнов стираются, что может быть функциональностью Bitbucket runner.
Все еще не уверен, где проверить и что проверить с этой ошибкой, так как эта проблема возникает на нескольких машинах.
Примечание: Версия Docker одинакова на всех машинах.
Пожалуйста, помогите мне с этим.
Ответ или решение
Решение проблемы с кодом завершения 137 на Bitbucket самоуправляемых раннеров в EC2
Введение
Проблема с выполнением пайплайнов в Bitbucket с кодом завершения 137 может быть связана с различными факторами, включая ограничения ресурсов, конфигурацию Docker и взаимодействие с сервисами. Этот код обычно указывает на то, что контейнер был принудительно завершен, скорее всего, из-за недостатка памяти (OOM – out of memory). Однако в вашем случае, после тщательной проверке, выяснилось, что память и дисковое пространство находятся на приемлемом уровне, что делает проблему более сложной.
Основные шаги для диагностики и исправления
-
Проверка ресурсов на уровне EC2:
- Проверьте, хватает ли выделенных ресурсов (CPU, RAM) на ваших EC2 экземплярах. Увеличение памяти и процессоров может помочь, но минимальные размеры тоже имеют значение. Попробуйте изменить тип экземпляра EC2 на более мощный.
-
Настройка Docker:
- Важно убедиться, что настройки Docker адекватны. Проверьте конфигурацию Docker на наличие ограничений, что может приводить к преждевременному завершению задач. Например, параметры
--memoryи--cpusследует тщательно рассмотреть.
- Важно убедиться, что настройки Docker адекватны. Проверьте конфигурацию Docker на наличие ограничений, что может приводить к преждевременному завершению задач. Например, параметры
-
Логи и журнал событий:
- Вы упомянули о том, что не удается получить логи ваших контейнеров. Проверьте, установлен ли уровень логирования для Docker на более высокий, чтобы избежать потери логов при завершении контейнеров. Используйте команду
docker logs CONTAINER_IDдля получения информации о сбоях.
- Вы упомянули о том, что не удается получить логи ваших контейнеров. Проверьте, установлен ли уровень логирования для Docker на более высокий, чтобы избежать потери логов при завершении контейнеров. Используйте команду
-
Проблемы с обновлениями YUM:
- Регулярные обновления YUM могут вызывать конфликтующие версии библиотек или зависимостей. Проверьте, какие именно пакеты обновляются, и попытайтесь выяснить, какие из них могут конфликтовать с Docker.
-
Тестирование без
services: docker:- Вы упомянули, что исключение секции
services: dockerрешает проблему. Это может указывать на то, что контекст выполнения Docker внутри контейнера (или ограничения) отличается от ожиданий. Попробуйте выполнить Docker команды отдельно вне пайплайна или измените конфигурацию таким образом, чтобы уменьшить нагрузку на Docker.
- Вы упомянули, что исключение секции
-
Мониторинг системы:
- Используйте инструменты мониторинга, такие как CloudWatch, для отслеживания использования ресурсов в реальном времени. Это позволит вам идентифицировать возможные пики нагрузки в момент исполнения пайплайна.
-
Проверка конфигурации Bitbucket Runner:
- Убедитесь, что ваша конфигурация Bitbucket Runner соответствует рекомендациям Bitbucket. В некоторых случаях загрузка контейнеров может зависеть от настроек безопасности, которые могут ограничивать использование ресурсов.
Заключение
Сложность проблемы с кодом завершения 137 на Bitbucket самоуправляемых раннерах в EC2 может быть связана с недостаточностью ресурсов, конфигурационными ошибками, а также потенциальными конфликтами между обновлениями. Рекомендуется провести детальный аудит текущей конфигурации, использовать мониторинг для выявления узких мест и подойти к тестированию с разных сторон, чтобы эффективно устранить проблему.
Если указанные меры не принесут результатов, возможно, стоит рассмотреть более детальное коллективное обсуждение с поддержкой Bitbucket и AWS, чтобы выявить скрытые конфигурационные вопросы или особенности взаимодействия между сервисами.