Суровый рынок веб-разработки в России или зачем нам базы данных, постоянное хранилище и FTP

Чем бы дитя ни тешилось, лишь бы по FTP не деплоило и не масштабировало свои продукты, перекачивая образы виртуальных машин. Респект и хвала умным парням и девушкам, которые знают, что такое CI, CD и активно их используют в своем продакшне. Cust Dev по России показал, что все очень плохо. Увы.

Крик души

Соблюдаем анонимность и надеемся никого не обидеть. На вопрос “Как вы работаете и доставляете свой продукт в продакшн?” мы услышали уйму различных ответов. Вот некоторые тезисы из самых популярных ответов:

1. Я не пользуюсь ide, все делаю через админку вордпресса, ручками открывая файлы с фтпшника в саблайме.
2. Разворачиваем новые экземпляры своего SaaS, копируя целиком виртуалки. За ночь копируется нормально.
3. Как-как? По ftp, а git используем для резервных копий.
4. Мы планировали использовать git, но как-то не получилось. Сейчас все руками.
5. У меня все настроено с помощью капистрано.
6. Все через пулл-реквесты, потом суровый код-ревью, потом CI подтягивает все в прод.

Это не сферические кони в вакууме, а реальные люди из реальных студий и агентств России из крупных и мелких городов. На удивление различия в относительных долях того или иного ответа в зависимости от региона оказались несущественными. Быть может, для небольшого и несерьезного проекта, типа сайта-одностраничника, подобный подход вполне себе вменяемый, но если ты ответственный за DevOps в более-менее крупной веб-студии, для безболезненного масштабирования просто жизненно-необходимо придерживаться git workflow и использования ряда CI/CD инструментов.

SaaS масштабирование

Боль у каждого своя, и как использовать тот или иной инструмент решает каждый сам. Если вы — счастливый обладатель SaaS решения (системы мониторинга, CRM, CMS, в общем, все, где нужно масштабироваться быстро по горизонтали) и вы до сих пор клонируете виртуалки, то бог вам в помощь мы вас ждем. Пишите нам в саппорт, и мы предложим вам выгодные условия использования нашей платформы для обеспечения быстрого масштабирования. Небольшое демо такого прикладного использования нашей системы

Использование системы не по назначению, перманентное хранилище и FTP

Есть то, что есть, и работать приходится именно с этим. Особенности работы Docker образов и контейнеров включают в себя определенные ограничения для файловых операций внутри контейнера, а именно — неперсистентность результата их выполнения после перезапуска процесса веб-сервера (что порождает пересоздание контейнера) или перебилда image вашего приложения. Мы, хоть и косвенно, но являемся Shared CaaS решением. Наше предложение — хранилище с FTP доступом из вне. Папка монтируется в контейнер при билде и запуске приложения.

Для любителей писать на шаблонизаторе php систем эта проблема наиболее актуальна, ибо 90% написанных решений безбожно творят уйму операций с файлами, сохраняют туда данные, конфиги, темы, настройки и пр. Если взять пример запуска веб-сервера, совместимого с большинством php-систем (наличие апача для многих является просто необходимым) https://github.com/dokkur/php-common/blob/master/Procfile, то мы в самом простейшем варианте даем возможность закинуть все необходимое содержимое в примонтированную папку через FTP. Для этого нужно:

1. Зарегистрироваться у нас
2. Нажать кнопку + справа вверху
3. Ввести имя приложения, выбрать датацентр
4. Выбрать нужный темплейт — Any PHP
5. Дождаться окончания создания приложения, перейти в п.меню Storage
6. Кликнуть на строку /app/www и получить данные для подключения: Host, Username, Password. Если изменения DNS еще не настигли ваш узел связи или у вас закешировано там что-то другое, то советуем использовать доменное имя инстанса, на котором создано ваше приложение: п.меню Settings, посмотреть на git url и прочитать хостнейм — то, что между символами “@” и ”:”.

Подчеркну, что мы далеки от такого подхода в разработке, поэтому будем крайне призательны вам за фидбек по этому флоу — что нужно, что не нужно.

Что делать и кто виноват?

Виноваты все по чуть-чуть никто не виноват и что делать решает каждый сам для себя.

Если вы разработчик и вы заинтересованы в своем профессиональном росте, то мы с радостью окажем вам консультацию по работе с git, билдпаками, поможем подобрать оптимальную продакшн-конфигурацию вашего приложения. Саппорт всегда к вашим услугам.

Если же у вас есть собственный проект и вы испытываете определенные сложности в работе/продакшн настройке или просто хотите оптимизировать деплой вашего проекта, сделать все по уму, наладить масштабирование, быть уверенными в отказоустойчивости, мы готовы вам помочь с переездом к нам и попутно проведем полный аудит вашей архитектуры.