Всем кто отлаживал свои Ansible-плейбуки, Chef-рецепты и Puppet-манифесты, которые потом по какой-то загадочной причине переставали работать посвящается... Этот пост будет об одном случае с неочевидными фейлами при конфигурировании EC2 серверов с помощью Ansible.

Немного контекста

О среде. Стандартные on-demand EC2 инстансы с Ubuntu, используемые как тестовое окружение. Пересоздаются с помощью Terraform’a при каждом деплойменте, для конфигурации впоследствии используется Ansible. Все это работало довольно стабильно, если не считать рабочих фейлов связанных с процессом разработки :)

Как-то однажды…

Ко мне пришел менеджер по тестированию с просьбой посмотреть почему не сработал деплоймент. Просмотрев логи я обнаружил что Ansible фейлиться в самом начале при установке базовых пакетов из apt-репозитория с ошибкой:

E: Could not get lock /var/lib/dpkg/lock - open (11 Resource temporarily unavailable)
E: Unable to lock the administration directory (/var/lib/dpkg/) is another process using it? 

Естественно я полез на сервера и пробовал вручную воспроизвести эту ошибку, но тщетно. Пакеты успешно устанавливались и версия с проблемами в apt-репозиториях или их кешах отпадала.

Чтение логов особой ясности не внесло. Ansible запускал установку пакетов в штатном режиме, асинхронного режима или другой специфичесокй конфигурации не было, другие скрипты паралельно не запускались.

После какого-то времени перезапусков job и ручного(успешного) запуска Ansible, я решил повнимательнее посмотреть, а что же происходит на сервере именно в момент запуска…

И тут оказалось…

После успешного ping && ssh, еще до момента запуска Ansible, ситуацию прояснил просмотр списка процессов с помощью ps -ef. Действительно после запуска работал процесс dpkg и устанавливал какие-то пакеты, хотя Ansible еще не был запущен. Дальнейшее разбирательно привело к тому, что этот процесс запускался механизмом unattended-upgrades и причина появившихся фейлов заключалась в том, что список пакетов для установки на использующийся ami-обарз увеличился и требовал больше времени на установку, что и вызывало коллизию с установкой пакетов Ansible’ом. Проблема решилась увеличением задержки между повторными попытками установки пакетов.

- name: Install packages
  packages:
    ...
  retries: 5
  delay: 30
  register: result
  until: result|succeeded

Happy end

Пока я разбирался с этой проблемой я попутно наткнулся на другую, как правильно обрабатывать exit-code apt утилиты с помощью Ansible, подробности на StackOverflow.