Pull to refresh

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
Only those users with full accounts are able to leave comments. Log in, please.