Elastic Beanstalk спрощує розгортання додатків на інфраструктурі AWS, включаючи автоматичне масштабування. Коли все працює, це добре. Коли не працює, може бути важко налагодити, але зазвичай у нас є всі необхідні інструменти для пошуку причини.
Я розгортав додаток на Elastic Beanstalk, де Docker-образи знаходилися в репозиторії Elastic Container Service. Це працювало добре, але було лише для тестових цілей, оскільки я вніс специфічні зміни для Beanstalk у конфігурацію Docker. Після того, як додаток був розгорнутий і тести пройшли успішно, мені потрібно було консолідувати зміни в конфігурації Docker і налаштувати Beanstalk на завантаження образу з нашого Docker Hub репозиторію. Це виявилося складним через певні причини.
Спочатку, щоб використовувати репозиторій ECS, я просто вказав повне ім’я репозиторію, наприклад:
“123456789.dkr.ecr.us-east-1.amazonaws.com/service:latest”. Це було достатньо, щоб кластер міг завантажити образ.
Пізніше, при переході до використання приватного репозиторію Docker Hub, все змінилося. AWS каже, що для цього потрібно завантажити файл з Docker-обліковими даними в S3 в старому форматі, а потім посилатися на цей файл у Dockerrun. Отримати облікові дані в правильному форматі просто: потрібно просто видалити проміжний об’єкт (ключ “auths” в кореневому об’єкті) і залишити його ключі як ключі кореневого об’єкта. Для подробиць читайте в документації AWS:
http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/createdeploydocker.container.console.html#docker-images-private
Я спробував налаштувати все відповідно до інструкцій AWS. Це не спрацювало. Розгортання нової версії, що повинна завантажуватися з приватного репозиторію Docker Hub, призвело до помилок у логах:
[Instance: i-1234345] Command failed on instance. Return code: 1
Output: (TRUNCATED)…px/test-service not found: does not exist or no
pull access Failed to pull Docker image 500px/test-service:latest:
Error response from daemon: repository 500px/test-service not found:
does not exist or no pull access. Check snapshot logs for
details. Hook /opt/elasticbeanstalk/hooks/appdeploy/pre/03build.sh
failed. For more detail, check /var/log/eb-activity.log using console
or EB CLI.
Ну ось, це не спрацювало.
Я кілька разів пробував повторити процес, адже ніколи не знаєш… і це не допомогло.
Тепер давайте справді розберемося. У нас є ідентифікатор екземпляра. Ми можемо перейти до цього екземпляра EC2, до якого можемо підключитися через SSH (зверніть увагу, що ми будемо підключатися як ec2-user).
ssh ec2-user@
І подивимося на файл конфігурації Docker:
cat ~/.dockercfg
Все виглядає добре, правильний користувач є. Проте команда docker pull не працює.
cat ~/.docker/config.json
Це старі облікові дані для тестування проти Docker репозиторію на AWS. Давайте спробуємо завантажити образ ще раз:
docker pull 500px/test-service
Не вдалося, як і очікувалося. Що якщо ми видалимо старі облікові дані…
rm ~/.docker/config.json
docker pull 500px/test-service
О, це спрацювало.
З’ясувалося, що цей додаток Elastic Beanstalk був створений за допомогою шаблону AWS. Потім він був змінений для завантаження Docker-образу з репозиторію AWS Docker. Це, ймовірно, створило файл конфігурації Docker з правильними обліковими даними в місці, де нові версії Docker очікують їх, в ~/.docker/config.json. Пізніше, при спробі переключитися на використання образу з Docker Hub, потрібно вказати ключ у S3, який містить облікові дані Docker Hub:
cat Dockerrun.aws.json
[…]
“Authentication”: {
“Bucket”: “devops”,
“Key”: “test.dockercfg”
},
[…]
Beanstalk потім, ймовірно, завантажує об’єкт облікових даних з S3 і зберігає його на екземплярі EC2 в старому місці конфігурації Docker, ~/.dockercfg.
Коли скрипти Beanstalk
(/opt/elasticbeanstalk/hooks/appdeploy/) намагалися завантажити Docker,
вибрали нове місце для конфігурації, а коли це не вдалося, вони не намагалися
повернутися до старого місця конфігурації. Це все має сенс, але, безумовно, призвело до певних проблем.
Ідеально було б, щоб екземпляр EC2 очищався після кожного розгортання, видаляючи всі облікові дані (або інші тимчасові дані),
щоб уникнути таких проблем.
Отже, я думаю, що основна думка тут у тому, що навіть з таким системним інструментом, як Elastic
Beanstalk, який надає велику автоматизацію для полегшення ваших розгортань, все одно можуть виникнути проблеми. Але,
з невеликим розслідуванням, нічого не приховано від вас, і прості практики налагодження все ще будуть вам корисні.
Перекладено з: AWS Elastic Beanstalk and Private Docker Hub Repos