Під акронімом "DevOps Notes" я публікую свої технічні знахідки, які були зібрані під час початкового етапу мого першого проекту в хмарі, так званого "Cloudburo Publishing Bot".
"Платформа Cloudburo Publishing Bot дозволяє мікропідприємцям, малим та середнім підприємствам (SME), а також ентузіастам-блогерам створювати контент-маркетинг з мінімальними зусиллями, зосередженим навколо Evernote."
Опис рішення для ведення блогу на основі Evernote можна знайти в наступній статті на Medium:
Як керувати онлайн- або новинним блогом безпосередньо з Evernote.
Тепер давайте перейдемо до технічної нотатки:
Стаття описує основні кроки для налаштування базової конфігурації середовища виконання Amazon Elastic Beanstalk.
Для обробки аспектів конфігурації на основі S3 для наших мікросервісів ми налаштуємо бакет, який містить будь-які файли, необхідні для наших мікросервісів.
Щоб бути готовими до масштабування, ми впровадимо систему іменування з самого початку. Кожен актив або елемент конфігурації, необхідний для нашої екосистеми мікросервісів, починатиметься з "TST", ви можете застосувати подібну стратегію у вашій сфері.
Налаштування бакету S3 для наших мікросервісів
- Ми назвемо наш бакет Amazon S3, використовуючи ms як акронім для мікросервісу.
- tst.ms.common.
- Бакет міститиме дані, які є спільними для всіх наших мікросервісів.
- Зверніть увагу, що S3 бакет повинен бути в тій самій області, що й ваш Elastic Beanstalk екземпляр, тому ми додаємо постфікс області, наприклад tst.ms.common.us-west-2.
- Завдяки постфіксу області ми можемо легко створити такий самий бакет в інших областях, якщо захочемо реплікувати наші установки між різними областями, слідуючи чіткій та зрозумілій схемі іменування.
Створення IAM політики для доступу до бакету S3
- Тепер створимо політику Amazon AWS Identity and Access Management (IAM), яка дозволяє читати дані, і яка буде прикріплена до будь-якого з наших працюючих мікросервісів:
- IAM Політика: TST.S3.Read.clbmscommon
- Тут ми включимо всі загальні бакети різних областей, наразі ми маємо лише один.
Призначення політики вашій IAM ролі
Ми прикріпимо до ролі створену вище політику доступу до бакету.
Тепер у нас є спільний бакет, готовий до використання в нашій області Elastic Beanstalk, з правами доступу для читання до конфігурації нашого EB екземпляра.
Тепер перейдемо до вашого EB проекту, який містить конфігурацію Docker для EB.
Зберігання ваших даних для доступу до dockerhub, необхідних для доступу до вашого приватного Github Docker акаунту
Цей спільний бакет буде використовуватися для зберігання ваших даних для доступу до Dockerhub, щоб дозволити EB завантажити ваш приватний Docker-образ. Якщо ви працюєте з публічним Docker-образом, цей крок не обов'язковий.
-
Як перший крок збережіть ваші дані для доступу до Github у спільному бакеті, наприклад, у файлі tst.ms.common.us-west-2/credentials.json
-
Ваші чутливі дані для доступу до Docker тепер доступні для EB у зашифрованому вигляді та зберігаються в безпеці.
Налаштування Docker файлу в каталозі Elastic Beanstalk
-
Додайте наступний запис до вашого Dockerrun.aws.json.
Файл описує вашу конфігурацію одного контейнера Docker для EB, і запис вказує EB, де знайти вашу інформацію для автентифікації, щоб отримати доступ до вашого приватного репозиторію Docker Hub. -
Нарешті, додайте запис, де знайти Docker-образ у файл Dockerrun.aws.json.
-
Загальний файл Dockerrun.aws.json виглядатиме наступним чином, і EB завантажить ваш додаток з приватного репозиторію Docker Hub.
Оригінально опубліковано на dev.cloudburo.net 12 травня 2016 року.
Перекладено з: DevOps Notes: AWS Elastic Beanstalk — Github Docker Integration