Здравствуйте. Спасибо за отзыв. Да согласен, нужно было бы подробнее описать работу с CircleCI. В данном контексте CircleCI позволяет нам автоматизировать процесс запуска тестов и деплоя на dev, staging окржуения.

Про AWS CodePipeline не слышал, но звучит очень круто. Большое спасибо, обязательно возьму на изучение

Я понял. Прошу прощение за недопонимание.
Да, вы все верно говорите. В таком случае мы не можем использовать volumes. Поэтому решение в этой часте только для кейса когда у нас один инстанс на котором все сервисы.

Случай когда нам нужно запускать задачи на нескольких инстансах, я буду рассматривать в следующей часте, напримере масштабирования и какие сложности с ним могут возникнуть (stateless особенности контейнера). Как предложенное решение — использовать RDS, ElastiCache.

Для dev/staging инфраструктуры используется один инстанс для postgres, redis, application и т.д., (в целях экономии).

Этот инстанс не удаляется и не заменяется новым (как в случае с auto scalling) Это нам позволяет все данные из директории контейнера postgres (`/var/lib/postgresql/data`) складывать в директорию инстанса (`/postgres`). Когда контейнер postgres заново запустится, ему вмонтируется директория `/postgres`, которая хранится непостредственно в инстансе, который, повторю, не удаляется.

volumes:
— /postgres:/var/lib/postgresql/data

Нет. После рестарта сервисов данные не пропадают. Это было бы глупо.
Прошу прощения, если высказался непонятно. Я имел ввиду сложности масштабирования в случае когда у нас на одном инстансе запущенны все сервисы, как и statefull, так и stateless

Все верно. Поскольку AWS не умеет шарить volumes для разных инстансов (пытался всеми возможными способами это сделать), то конфигурация в этой главе предназначена только для dev, staging окружений. Поэтому для production лучше использовать отдельные инстансы/сервисы с postgres, redis и т.д. Если же встал вопрос о перезде с одной архитектуры на другую, то да, придется делать импорт. Если все же не хотите подключать внешние сервисы, то вы сетапите отдельную задачу для postgres и отдельно сервис с одной или несколькими задачами для application server (которые уже коннектите к инстансу с базой данных)

Здравствуйте. Если я правильно понял ваш вопрос, то подобный кейс я буду рассматривать в следующей части туториала. В случае когда одно хранилище используется несколькими сервисами, лучше использовать RDS . Разумеется можно запустить контейнер с постгресом на отдельном инстансе, но в этом нет смысла, так как по стоимости разница не стоит того.

Поэтому этот туториал и вышел. Разобраться с документацией Amazon ECS не так-то просто

Больше спасибо за комментарий. Несомненно эти инструменты более элегантны для развертывания инфраструктуры. Я об этом упоминал 🙂

Есть много удобных инструментов развертывания инфраструктуры, например Terraform и CloudFormation,

Так как рассматривая тема непроста, как и работа с этими инструментами, их лучше подавать в отдельном материале.

Наша основная задача в этой главе ‒ разобраться, какие Amazon сервисы используются для развертывания приложения на AWS с помощью Docker.

Огромное спасибо. Крутые советы, не знал. Обязательно возьму на вооружение 💪
Тоже слышал про проблемы с Docker compose, но он используется только для работы в локальном окружение. Но старт контейнеров с сетью на bash тоже рассматрю. Спасибо.
В контексте AWS не используется Docker compose, там есть ECS Task Definitions. Amazon уверяет что их способ надеженее 🙃

Дякую за пропозицію 😌

Перепрошую за незрозумілу відповідь, я саме це

git push heroku master і поїхали :)))

мав на увазі під ’рішення де потрібно натиснути декілька кнопок для отримання бажаного результата’

Дякую. Я розумію ваше позитивне ставлення до Heroku, Beanstalk. Але я намагаюся використовувати рішення де потрібно натиснути декілька кнопок для отримання бажаного результата лише коли напередодні добре розібрався як влаштовані процеси зсередини

Тому цим туторіалом я хочу зняти завісу нерозуміння, з яким сам зіткнувся на початку свого шляху

Дякую за Ваш коментар.

Питання з RDS, Elasticache. Так. Звісно зручніше використовувати RDS з готовою збіркою під Posgtres та Elasticache для Redis. Але використання цих сервісів тягне за собою додаткові витрати. Мінімальний інстанс RDS — коштує 13$ на місяць, Elasticache — 12 $. Коли проект тільки починає розвиватися, або ви налаштовуєте свій pet-project, ресурси обмежені. Потрібно бути готовим до того, що замовник відмовиться нести додаткові витрати на обслуговування dev, staging оточень. Гадаю що цим ми закриваємо питання з використання Heroku. У разі, якщо бюджет проекту готовий покрити використання AWS на максимум, то не бачу складнощів змінити, у конфігурації додатку, хост з локального сервісу на сторонній.

Питання з Docker + AWS ECS. Так, це рішення безсумнівно зручніше для налаштування production оточення. Але для розробників які тільки намагаються познайомитися зі світом DevOps це чорний ящик. Якби я почав знайомство з DevOps відразу з Docker + сервіс оркестрації контейнерів, то багато процесів залишилися б для мене складними та незрозумілими, а це може виплити у проблеми з безпекою оточення додатку. Тому цим туторіалом я хочу зняти завісу нерозуміння, з яким сам зіткнувся на початку свого шляху і надати коробкове рішення, яким можна піднімати новий та захищенный environment додаток за кілька хвилин.

Питання по CI / CD закривається тим що chef/сapistrano-скрипти з деплоя зберігаються безпосередньо в репозиторії проекту.

Навіщо давати «готовий сценарій», якщо можна навчити збирати свій? 🙌

Ні. Ви могли б обґрунтувати ваше запитання, будь ласка?

З правильним використанням Chef такої проблеми не буде 😉

Бо OpsWorks окремий інструмент який потребує детального вивчення, це краще винести до окремого туторіалу

Дякую за ваш коментар. У даній серії туторіалів не стоїть завдання показати повне покриття інфраструктури за методологією IaC. Даний підхід показаний з боку скриптів, які налаштовують усе необхідне ПО однією командою. Ми не розглядаємо інші підходи задля спрощення і так складного для новачків матеріалу.

Дякую за зауваження. Хоча серія статей не передбачає використання подібних инструментів, згадати про них потрібно було.