Comments 6
Хорошая идеологически попытка автоматизации всего, но довольно много применено сомнительных, скажем так, решений, которые сводят классические плюсы от использование докера и CI/CD к нулю. Навскидку:
- разные образы не то что для dev и prod, а даже для stage и prod.
- использование .env файла в образе, а не настройка приложения для, как минимум, stage и prod через env переменные при запуске контейнера (можно указывать тот же env файл как параметр запуска, а не как часть образа)
- сами образы совмещают и php, и статику для веб, что исключает отдельный билд и деплой бэка и фронта, а также раздельное масштабирование
- сами образы содержат билд/дев зависимости, не нужные в prod/stage окружениях, билд-контейнеры или мультистейдж билды не используются
- установка зависимостей composer и yarn/npm будет проходить на каждый чих, кэширования vendor/node_modules нет
- используется редактирование конфиг-файлов php и apache в процессе билда образа, а не просто копирование готовых конфигов
По флоу сразу бросается в глаза, что на stage деплоится каждый пуш в репу, кроме мастера, что несколько отличается, во-первых, от обычного понимания stage как полной копии того, что будет деплоиться на прод, а, во-вторых, разработчик запушивший свою ветку может очень долго пытаться понять, что не так, потому что кто-то запушил свою через секунду и перезатёр его. Обычно два основных варианта используется для деплоя прод и стейдж:
- деплой стейджа и его проверка просто шаг во флоу деплоя прода. Деплоится один и тот же образ, построенный по последнему коммиту (или по конкретному тагу, если используется релиз по тагам) в мастер. Проверка может быть и ручной или полуавтоматической (кнопочку QA/релиз-менеджер нажимает), так и полностью автоматической.
- деплой прода по каждому коммитув мастер или релизному тегу, а стейджа из специальной ветки (develop/stage/release/..) или RC-тега.
Что-то замечания скоро будут больше по объёму чем статья...
Вы не комментируете статью, а пишите про другое флоу. Для разработчика, не для команды, это будет хорошим стартом, к примеру, если программист (один, не команда) постоянно поддерживает проект. Стейджинг, описанный мною, это окружение для тестирования кода, не более и не менее, дев кластер я не вводил, для старта я считаю его избыточным. Разумеется при наличии дев'а, где разработчик обкатывает свою часть задачи, затем собирается релиз из многих для стейджа, конфиги бы были иными, но статья несколько о другом, потому я специально в начале указал кому она будет интересна — понятно, что она не для devops инженеров, которые, разумеется, будут указывать на минусы конкретной реализации
Я пишу как разработчик и никогда не был девопс-инженером, указываю прежде всего на недостатки DX. Как разработчик вижу, что разрабатывать будет неудобно:
- практически полный ребилд фронта и бэка на каждое изменение исходников, например, маленькое изменение CSS-файлов "сделай цвет кнопки повеселее" потребует выполнения composer install и yarn install
- постоянное слежение за синхронизацией стейдж и прод докерфайлов и их енв-файлов или большое количество ситуаций "ну на стейдже же работает"
- при каких-то проблемах в конфигах php и apache нужно будет каждій раз лезть внутрь образа или даже работающего контейнера, чтоб посмотреть а какие текущие значения конфигов. Не говоря, что для многих синтаксис sed вовсе не что-то легкочитаемое и редактируемое.
- ничего про собственно процесс локальной разработки (кластера на каждую ветку у нас же нет:) )
И основные замечания прежде всего не к флоу (допустим для единственного разработчика, который ещё и сам себе девопс, они действительно не очень актуальны, хотя в посте вроде нет ничего про единственного), а к содержимому докерфайлов причём почти все замечания поправить — один из них удалить полностью, удалить одну строку из оставшегося, перегруппировать существующие и добавить несколько "заголовков" для этих групп.
Владимир, отвечу по пунктам:
практически полный ребилд фронта и бэка на каждое изменение исходниковвсе верно, если тут вы говорите про то, что следовало бы применить сначала копирование package.json и установить зависимости, а затем уже всего остального, чтобы воспользоваться преимуществом промежуточных контейнеров, то какой в этом профит, когда вы запускаете сборку из CI? а если в ответ вы напишите подобное «неправильно запускать сборку из CI» — значит другой флоу. я исправлю этот момент в статье и в репозитории, но скорее для того, что так правильно и лучше всегда привыкать писать так (установка зависимостей отдельно, а код отдельно), конкретно в данном случае, повторюсь, выгоды вы не увидите. поправьте, если ошибаюсь
постоянное слежение за синхронизацией стейдж и прод докерфайлов и их енв-файловтут я с вами согласен, хотя и постоянного слежения не предполагается, так как изменять содержимое Dockerfile'ов нужно крайне редко, если процесс деплоя, за который они отвечают, отлажен, тоже касается и .env файлов. но и тем не менее да, лучше иметь один Dockerfile и один .env, а строку подключения к БД задавать в переменных окружения системы, по крайней мере это убирает шанс на ошибку. мною приведен такого рода пример главным образом в образовательных целях, потому как он более нагляден и приближен к той версии приложения, которая есть у разработчика до внедрения данных практик. однако, если сообщество сочтет нужным — я изменю данный пункт, пока же оставлю как домашнее задание для тех, кому такой подход выгрузки кода придется по душе.
ничего про собственно процесс локальной разработкиверно, но и статья о деплое, а не о том, как правильно готовить окружение. лично я не использую docker для dev, у меня mamp, все по-старинке, и мне так удобнее, есть коллеги, которые поднимают БД и другие сервисы в docker-compose, пользуются встроенным веб-сервером. суть в том, что как бы у вас не была настроена система локальной разработки, после прочтения данной статьи деплой у вас будет настроен.
при каких-то проблемах в конфигах php и apache нужно будет каждій раз лезть внутрь образа или даже работающего контейнераесть задача — развернуть приложение на AWS. можно раскатывать операционную систему и весь необходимый софт на EC2, настраивать компоненты отдельно, тогда бы этот пункт у вас ушел. я использую Elasticbeanstalk, указав причину. можно ввести php.ini в файлы проекта и копировать его в Dockerfile'е, тогда опять же, настройки будут «под руками» и вопрос будет закрыт, я же написал в конце статьи, что нужно идти дальше, а данный материал не серебряная пуля, хотя и приведенные настройки абсолютно рабочие и вопрос покрывают.
удалить одну строку из оставшегося, перегруппировать существующие и добавить несколько «заголовков» для этих группВладимир, если вы хотите поделиться опытом и улучшить данную статью, ведь через время пользователи не будут влезать в дебри комментариев, а использовать лишь приведенный в материале код, то welcome, напишите конкретно, что именно по вашему мнению будет лучше, я изменю материал, если в этом действительно есть смысл. я не занимаюсь бахвальством, и уверен, что материал статьи действительно стоящий и будет полезен коллегам.
есть задача — развернуть приложение на AWS. можно раскатывать операционную систему и весь необходимый софт на EC2, настраивать компоненты отдельно, тогда бы этот пункт у вас ушел. я использую Elasticbeanstalk, указав причину.
Я, надо заметить, не понимаю, зачем вам EBS, если все приложение у вас все равно в докере (который вы собираете на стороннем билд-сервере). Чего бы уж не взять тогда чистый ECS?
А если к этому добавить развертывание через CloudFormation, то вы вообще избавитесь от ручных действий вида "перейдите в сервис RDS и создайте 2 инстанса необходимой вам мощности и объема" (а создание репозитория в ECR вы и вовсе пропустили).
Ровно потому, что сказано в aws.amazon.com/ru/ecs/faqs:
Elastic Beanstalk является идеальным решением, если вы хотите воспользоваться преимуществами контейнеров, но при этом вам требуется только простота развертывания приложений от разработки и до рабочей стадии через загрузку образа контейнера. Вы можете работать с Amazon ECS напрямую, если хотите иметь более полный контроль над архитектурой настраиваемых приложений.действительно, для разработчиков, которые вчера выкладывали приложение посредством git pull в консоли сервера (а может и заливкой файлов по FTP) информации и новых механизмов хватает, чтобы еще и тут же погружать его в систему оркестрации… И, при всем уважении, EBS — это в терминологии AWS Elastic Block Store, не Elasticbeanstalk
Sign up to leave a comment.
Deploy Symfony + React приложения на AWS посредством CI