Излюбленный вопрос новичков (и не только) "как развернуть сайт для разработки" по-прежнему вызывает множество споров. С каждым годом появляются всё новые варианты, но в последнее время я стал натыкаться в интернете на вопросы новичков, попавших в какие-то совершенно нелепые ситуации из-за того, что среда для развёртывания сайта была выбрана изначально неверная. Именно поэтому я решил написать эту статью о выборе среды, обобщив свой личный опыт и наиболее часто встречающиеся ошибки.
Далее я перечислю разные способы начиная от наименее предпочтительных, заканчивая наиболее предпочтительными, попутно перечислив их достоинства и недостатки. Сразу отмечу, что речь идёт о развёртывании сайта для разработки, а не для продакшена.
1. Разработка сразу на shared-хостинге.
Этот способ я не советую использовать никогда. На хостингах можно разворачивать сайты для тестирования, но никак не для разработки. Тут нужно маленькое лирическое отступление: когда разработчики высмеивают подход "х*як-х*як и в продакшн", то имеется в виду, что вместо "х*як-х*як" должен быть вдумчивый процесс разработки, а не то, что должно быть сначала в продакшн, а потом "х*як-х*як". Почему я не советую так делать:
- во-первых, новичку вряд ли придёт в голову закрывать тестовый сайт от индексации.
- во-вторых, нет оперативного доступа к файловой системе (все эти синхронизации и FTP очень сильно замедляют работу)
- в-третьих, зачем платить за это?
- в-четвёртых, у вас может быть недостаточно опыта, чтобы выбрать подходящий хостинг, а когда вы это поймёте, тестовый бесплатный период скорее всего закончится.
А потом кто-то гордый и обиженный напишет в интернете после пяти дней мучений "перешёл на вордпресс, потому что друпал так и не заработал на моём хостинге"
2. Денвер.
Этот способ я не советую использовать никогда. Вообще странно, что в 2018 году кто-то пользуется денвером. Когда я впервые использовал его в 2013, уже тогда его не советовали использовать, т.к. он уже тогда морально устарел. Как правило, те корчи, которые всё же отважились его использовать, переходят на что-то другое, когда пытаются развернуть на нём хотя бы самый примитивный интернет-магазин.
3. OpenServer.
Хорошо подойдёт для контент-менеджеров или для начинающих разработчиков. В принципе, там есть всё, что нужно для развёртывания почти любого сайта. Также есть расширенная версия пакета, куда включено огромное множество софта для веб-разработки, что может быть полезно новичкам. Но есть у него и ряд минусов:
непонятно, как обстоят дела с серверным софтом за пределами LAMP-стека, а именно со всякими Node.js, Solr, Redis и т.д.
консольные инструменты не очень удобны. Это извечная проблема Windows - одна консолька для гита, одна для mysqldump, третья для drush, четвёртая для composer, но она не работает.
4. Виртуальная машина.
Виртуальная машина может полностью закрыть все ваши потребности, но этот вариант скорее подойдёт для задротов, ибо возни с настройкой очень много, поэтому этот способ я не советую использовать никогда.
5. Разработка на нативном Linux.
Это очень хороший вариант, но по понятным причинам подходит не всем. Но даже если вас полностью устраивает работа на Linux, всё равно здесь есть несколько подводных камней - если вы работаете над разными проектами, у которых разные продакшн-среды, вам нужно постоянно устанавливать весь серверный софт на свою машину. И если переключаться между версиями PHP можно сравнительно легко, то развернуть два проекта с разными версиями Node.js на одной машине будет крайне затруднительно, если вообще возможно.
6. Docker.
Мой любимый и, пожалуй, самый актуальный на данный момент способ. Docker - это способ контейнерной виртуализации linux-машин. С помощью утилиты docker-compose вы можете за считанные секунды поднять среду с абсолютно любой конфигурацией. Но главное преимущество докера - это экосистема. Вы можете найти контейнер для абсолютно любого серверного софта и включить его в свою сборку. Нужен к примеру solr - добавили пару строк в конфигурационный файл, при этом рядом можно развернуть проект с другой конфигурацией или другими версиями ПО, не загаживая свою систему. Docker можно использовать на любой ОС, правда для Windows нужна 10 версия,иначе не будет работать docker-compose. И даже если вы привыкли работать в нативном Linux, докер всё равно даст вам ряд преимуществ и ускорит работу. В частности в моей компании вся разработка ведётся в докере, все сборки основаны на сборке docker4drupal, ставшей уже де-факто стандартом в мире Drupal-разработки.
Заключение.
Если у вас лапки, используйте Openserver, если вы разработчик, используйте Docker. Остальное - отговорки.
Ссылка на оригинал статьи: https://wellsolutions.by/article/vybiraem-sredu-dlya-lokalnogo-razvyorty...
Комментарии
Можно было короче сформулировать: кто не на докере, или на худой конец, не на опенсервере - тот задрот или корч. "Остальное - отговорки" ©
PS Я-то с автором не согласен, но дискутировать в предложенном тоне не вижу смысла...
Стандартная отговорка - когда нечего сказать, ссылаться на тон))
Почему-то по заголовку топика понял, что речь пойдет про докер-)
Ожидал прочитать про "годный рецепт": как оптимально (с подробностями) поднимать новый проект или разворачивать существующий
по кнопке "Все загребись".А node.js используется с drupal еще как-то помимо "компиляции" sass-less и дополнительного бэкэнда?
Как юзать докер нормально рассказывает Никлан в своих первых видео.
"Как юзать" - найти не проблема, важно взвесить все плюсы-минусы: действительно ли использование докера в конкретно "моем случае" даст хороший прирост производительности.
Кстати, а кто такой "Никлан"?
Прироста производители сайта скорее всего не будет. Речь идёт об удобстве для разработчика. Новый сайт разворачивается быстрее. Плюс если, допустим, все сайты на седьмом пыхе, и тут вдруг надо доработать ещё один старый на пятом, то это не проблема, даже если ничего не понимаешь в системном администрировании.
Я не про производительность сайта, а про производительность себя любимого.-)
Для разработки использую "домашний" сервер (linux), один облачный сервер (linux) для мелких проектов, отдельные облачные сервера для "крупных" проектов с не совсем стандартным окружением.
Чаще всего случается такая ситуация: есть продакшн-сайт, его надо без лишних заморочек развернуть на одном из дев-серверов.
Чаще всего к продакшн-сайту есть или ssh-доступ или как минимум дамп с файлом и БД.
Окружение продакшн-сервера обычно или идентично дев или достаточно совместимо.
Вот я и думаю, есть ли практический смысл заморачиваться с докером или по страинке:
- залить файло
- залит дамп БД
- добавить конфиг в nginx
в идеале, конечно бы, хотелось запустить на дев-сервере команду с нужными параметрами и на пару-тройку часов забыть про него, а потом сразу начать работа-)ть
У меня уже более двух лет на работе все проекты в докере, дома все на убунте, и всегда есть удалённый сервак для экспериментов. Везде развёрнута куча проектов. Так вот по прошествии всего этого времени могу точно сказать, что с докером удобнее всего. Единственная причина, по которой дома не поставил докер - очень редко что-то разрабатываю дома, а если и делаю что-то, то по мелочи, поэтому просто руки не доходят.
В конце статьи ссылка на docker4drupal, это и есть рецепт. А node.js полноценно используется в decoupled-проектах. И кстати рецепт nextjs+d8 в одну cli-команду https://github.com/systemseed/drupal_reactjs_boilerplate
Взгляд снизу.
Разработка на шареде.
Вариант ФТП девелопмента замедляет работу? Да. Но на open server сайты, что я делаю работают гораздо медленнее, чем на шареде. В диспетчере задач Апач жрет все что только можно.
А если разрабатываешь с кем то или для кого-то? Я в курсе, что есть Гит и Фьючерс, но это не для новичков. Хотя бы даже сказал, это для случаев когда от 3-х разработчиков и есть координатор этих разработчиков.
Взгляд сбоку
Немного ДА..
Все же возможность, при помощи drush, установить за пару минут пару десятков модулей или в каждой непонятной ситуации за минуту сдампить БД на всякий пожарный экономит офуенную кучу времени, особенно если дамп все же понадобился-)
Но я не об этом..
Все, приведенные в топике способы "разворота" нужны и часто оптимальны в определенных ситуациях.
Если бы когда-то я не развернул свой первый сайт на drupal 4.7 на Денвере, я бы с вами тут сейчас не общался-)
Плохо лишь одно, что нормальных пошаговых описаний в одном месте
на чистом английскомна чистом понятном всех этих способов нет..И поэтому на форуме drupal.ru почти каждый день одно и тоже:
"Как перенести сайт с хостинга на локалку",
"Как перенести сайт с локалки на хостинг"
и т.д. и т.п.-)
Ну так ставь докер. Он точно должен быть шустрее опенсервера
где я писал про опенсервер?-)
Продвинутая система комментирования - мы в ответе, но не знаем, за что)))
то я был
"при помощи drush, установить за пару минут пару десятков модулей или в каждой непонятной ситуации за минуту сдампить БД на всякий пожарный экономит офуенную кучу времени, особенно если дамп все же понадобился-)"
- ну так все это шареде быстрее
Ой.. извиняюсь, не в свою ветку залез-)
шаред шареду рознь.. тут буквально недавно топик был, как сдампить сайт с шареда, и периодически они опять появляются-)
а drush, он и в африке drush
drush arb
и делай с сайтом все что совесть позволит-)
Что же это за комп такой несчастный?
Вставлю свои 5 копеек. До просмотра видео Никлана я использовал виртуалку с линуксом. Просто чтобы не ставить веб-сервер на свою хостовую машину. Но потом решил попробовать докер и мне понравилось. Да, есть нюансы, как и у любого инструмента.
На OpenServer можно вести разработку простого сайта максимум на Drupal 7. Не представляю как юзать drush и composer на винде, да и всякие GULP, SASS и т.д.
аффигеть чё нагуглил: https://habr.com/post/280560/
оказывается в 10-м маздае есть баш-))
я когда-то для линукс-консоли на винде это использовал: https://www.cygwin.com/
так что, если немного забить на совесть, можно и в винде и GULP и SASS и все остальное-)
Именно поэтому я и упомянул, что для использования docker-compose нужна десятая винда. А gulp и sass спокойно запускаются и на семёрке. Там даже compass, который на руби, запускается, причём из родной виндовской консоли.
Общество анонимных докерщиков:
- Добрый день, меня зовут Алексей, и у меня докер.
Docker отличный вариант для разработчика, надо только не забывать, что в случае Windows и Mac, это не нативный инструмент, и он запущен внутри виртуалки, что даёт заметные накладные расходы, да и проблемы с производительностью диска есть под виндой например, особенно, если это не windows 10 pro, и соответственно, dockerbox основанный на virtualbox, а не hyper-v.
Вообще, докер стоит рассматривать не как какой-то отдельный вариант, а как расширение варианта с linux виртуалкой, добавляющий оснастку для управления различными вариантами окружения в её рамках, чем он и является.
И он не первый и не единственный инструмент, решающий эту задачу, например, был vagrant до него, да и сейчас есть. Просто Docker эффективнее решает задачу, да и заметно более хайповый, к тому же.
Также, вестись на то, что есть контейнеры на все случаи жизни, не всегда разумно. Качество некоторых из них прямо скажем не высокое, даже когда они созданы авторами софта, и если для разработки ещё, зачастую, можно не очень глядя применять "чужие" контейнеры, то для продакшена надо хорошо посмотреть, как построен контейнер, что и как в нём запущено и настроено, и часто, сделать самому и правильно, что сильно уменьшает привлекательность этой экосистемы - сопровождение исправленного варианта ложится на плечи эксплуатации, а в то же время, например, обновление окружения созданного средствами пакетного менеджера системы такую проблему не ставит, и даёт не меньшую гибкость. А автоматически развёртывать окружение можно не только в стиле Docker, но и в стиле систем управления конфигурациями совместно с пакетным менеджером OS, что с точки зрения эксплуатации проще и надёжнее.
Ну а самый хороший вариант, на мой взгляд, это докер в нативном Linux, на стадии разработки, и отдельные виртуалки, возможно облачные/возможно контейнеры, но с полноценной OS внутри средствами мониторинга и прочим необходимым инструментарием, для проектов на стадии эксплуатации.
Я допускаю, что в том же контейнере wodby/php может быть не всё оптимально настроено. Но я на 100% уверен, что лично я не смогу настроить это лучше, чем они, поэтому я и использую их образ.
По поводу продакшена, сейчас в своих проектах я не вижу потребности использовать докер на продакшене. А там, где он на продакшн реально нужен, там нужно нанимать профессионального сисадмина для настройки этого добра. Но этот вопрос выходит далеко за рамки текущей дискуссии.
Всё это было написано с тем, чтобы разработчики не забывали о том, что разработкой не всё кончается, и не все любимые ими инструменты также пригодны и для эксплуатации, по крайней мере "как есть".
А также чтобы подчеркнуть то, что нет идеальных инструментов, и проблемы есть везде, и тут, в случае докера, есть дополнительная проблема - про него сейчас слишком много говорят, и слишком восторженно, зачастую, а это просто один из удобных инструментов, для решения определённых задач, а не некий святой грааль...
И это, в большинстве случаев, вполне разумный подход. Но очень часто бывает наоборот, и "всё становится лучше если добавить докер".
Кстати, я довольно-таки активно использую докер в продакшене, просто для решения совсем других задач. И скажу так, это бывает довольно эффективное решение, но всё там совсем не так радужно, как рассказывается в разных статьях в инете.
Насколько я помню, докер задумывался, да и в большей мере используется не как "виртуальная система", эмулирующая окружение проакшна, а совсем наоборот, как контейнер с "идеальным окружением", для разработки и в последствии для дистрибуции приложения в родной среде в не совсем "родные среды".
Да.. в некоторых случаях, когда на дев-сервере нельзя по-простому организовать совместимую среду для разворачивания продакшн-сайта, скорее всего докер - лучшее решение.
А когда на дев-сервере среда совместима с требованиями проекта, тогда докер - просто еще один геморой..
Так что,без фанатизма..
Блин, и все время забываю, что есть еще вэб-разработчики, которые пользуются виндовс-))
А ещё есть мак.
Он же и используется в описанном сценарии, как система дистрибуции программ фактически. Просто это php определённой версии, или mysql там, распространяется для разработчика, а не разрабатываемое им приложение.
Или вообще какое-то стандартное окружение преднастроенное включающее в себя много компонентов, возможно в составе пачки контейнеров сразу.
И это удобно - одна команда, и у нас получается готовое протестированное окружение для проекта, которое может совпадать с конечным окружением в котором проект будет работать, даже если то запускаться будет не в контейнерах совсем.
Мало того, лёгким движением руки разворачивается другие необходимые компоненты mongodb какой-нибудь или ещё что, можно менять версии тоже в пару команд, и протестировать приложение в разных версиях php, например, заменив просто один из контейнеров.
Можно поднять под один проект среду, поработать, поднять среду под совсем другой проект, опять же в пару команд, ничего не перенастраивая.
Это действительно удобно все очень...
Раз уж про докер завели, кто нибудь знает как заставить докер запускать процессы внутри контейнеров не от рута а от нужного юзера? Поделитесь.
И насчет неудобства удаленного сервера - sftp + sublime text например, и даже не узнаешь что файлы находятся на удаленном сервере, более того, сервер значительно быстрее работает домашнего компа. Особо это видно на д8, если ему чистить кеш, фотошоп быстрей запускается.
Есть возможность запускать контейнер в целом от пользователя:
docker run --user
Но надо понимать, что контейнер произвольный вполне может и не работать так, и многие действительно не будут.
Если собирать свои контейнеры, то там можно создать пользователя и использовать директиву
USER
Но надо понимать, как будут мапится пользователи и uid, и группы и gid между контейнером и основной системой, и как правильно всё это делать.
Всё это есть в документации, в принципе, даже с примерами. НО это не такой уж малых кусок знаний...
Вообще, создавать правильные контейнеры это довольно сложная задача, и большинство разработчиков, просто не знают настолько хорошо своё окружение, чтобы с ней хорошо справляться. В среднем это сложнее, чем просто хорошо настроить окружение в какой-то своей виртуалке, т.к. помимо самой настройки, которую придётся сделать фактически также, да ещё декларативно описать в определённом формате, надо учесть массу нюансов привносимых самим докером...
Мой опыт показывает, что рут или не рут в контейнере - это ровным счётом ни на что не влияет.
Привет. Обычно да, но эти ребята явно не вкурсе.
вот например консоль
docker exec -it drupal_php-fpm_1 dru/drupal
все файлы что она создает root:root
вот как ее запустить что бы не рут был? Сам докер что ли как по другому запускать....
Либо запустить контейнер изначально от пользователя, если это возможно, либо использовать exec с ключом --user, либо использовать sudo в самой команде. Какой метод лучше применять зависит от контейнера и других обстоятельств.
автор не осилил vagrant
вот гляньте https://www.drupalvm.com/
этот подход хорош тем что можно настроить локально окружение, а потом поднять идентичный vps для рабочего сайта
Не осилил и даже не пытался и не буду, т.к. от вагранта все вокруг отказываются в пользу докера.
Дело ваше конечно, но вот эта категоричность звучит как-то по-малолетски.
drupalvm дает возможность настроить с помощью ansible окружение и потом использовать его в vagrant или в docker
Идентичное окружение развернуть одной командой на vps. Или вы принципиально не используете vps?
Т.е я не противопоставляю vagrant и docker, они оба полезны, для разработки чаще использую докер, это проще, для тестирования конфигурации сервера - vagrant
Vps использую конечно, но я не сисадмин,а разработчик, поэтому настройкой окружения я не занимаюсь.
Опять же, как по мне, использование virtual box - это огромный минус.
В чем минус? Я использовал vbox для разработки около 10 лет. На докер перешел только в этом году
Минус в том, что каждой вируалке нужно сразу давать ресурсы, монтировать директории и всё такое. В итоге, когда у тебя слишком много проектов, всё это жрёт очень много места. В то время, как докер-контейнеры занимают ровно столько места, сколько нужно. Плюс docker-compose down выпиливает контейнеры, полностью освобождая память, а поднимаются эти контейнеры обратно за считанные секунды.
Докер под виндой до недавнего времени работал как виртуалка в virtualbox. И сейчас так работает у тех, у кого не windows 10 pro, да и то работает теперь как виртуалка в hyper-v.
Ну и остановка виртуалки, точно также отдаст ресурсы, собственно. Как и её старт не будет долгим, если не напихать туда всего без меры, но это и контейнеров касается.
Опять же динамические образы виртуалок позволяют занимать им столько места, сколько они занимают, а не выделять запас.
В общем, это несколько не те различия, которые действительно имеют значение.
Мне кажется, одна из основных проблем друпалеров в том, что 2-3 года назад для друпалеров это "недавнее время", а в других технологиях это целая вечность))))))))
Проблема в том, что для разработчиков горизонт в год это долго, а для эксплуатации очень мало. Договорённости не будет никогда, и devops никакой не поможет тут.
а если винду надо поднять с фотошопом и IE? вижу в vbox только плюсы ))
На десятой винде докер работает без виртуалбокса.
Только pro, и только потому, что там hyper-v вместо него. Т.е. виртуализация никуда не делась.
Я на 10 винде не разрабатывал, но на маке докер тоже типа в виртуалке, но не в классическом виртуалбоксе, а в docker-vm или как там его. И когда-то давно пробовал докер на седьмой винде в виртуалбоксе. Так вот докер-машина субъективно быстрее, стабильнее и гибче, чем виртуалбокс.
То есть, когда я говорил про минусы виртуалбокса, я имел в виду не виртуализацию, как таковую, а то, что сам виртуалбокс это довольно неудобная в использовании виртуализация.
docker-mashine в 7 это и есть виртуалка в virtualbox, не больше, и не меньше...
Как и везде, кроме win10 _pro_, где она виртуалка в hyper-v, что во многих отношениях является даже большей проблемой, например из-за очень неспешной работы с дисками, например. Ой как я этим накушался, даже обратно в VB хочется.
В начальном посте написал специально, что для докера нужна десятая винда. А ты уже который раз пишешь одно и то же про седьмую. Давай ещё раскритикуй все остальные решения за то, что они не становятся на MS DOS. Его кстати недавно выложили в опенсорс))