Как установить Laravel на обычный хостинг-сервер?

Question

[DenKG]

Всем привет. Вот недавно начал изучать Laravel, решив, что это будет лучше, чем работать с WordPress. Установил его на свой компьютер, использовал OpenServer. Но теперь решил, что пора двигаться дальше и нужно установить его на свой хостинг. Вот только как это сделать? Там нужен композер или еще что-то? Ну и все эти приблуды с локального сервера. Буду благодарен за предоставление мануала. Спасибо :)

Answer 1

[Евгений Вольф]

Но теперь решил, что пора двигаться дальше и нужно установить его на свой хостинг. Вот только как это сделать? Там нужен композер или еще что-то?

Не нужен. Композер - это менеджер пакетов, который разгружает файлы в папку "vendor", а так же обновляет их там и т.д. Нет никакой проблемы закачать их "руками", в конечном виде, на хостинг.

Максимум, что может понадобиться - это наличие сервера Apache (коий есть примерно у 95% хостеров), что бы переопределить корневую директорию проекта.

Весь мануал будет удивительно краток:
1. Загружаете все файлы на хост ("как есть")
2. Создаёте в корешке хоста файл .htaccess вот с таким содержимым:

<IfModule mod_rewrite.c>
  RewriteEngine On
  RewriteRule ^(.*)$ public/$1 [L]
</IfModule>

3. Готово

Там нужен композер или еще что-то? Ну и все эти приблуды с локального сервера. Буду благодарен за предоставление мануала. Спасибо :)

"Композер и что-то ещё" могут быть нужны при наличии некоторых механизмов "деплоя" (англ. "deploy"), но это уже не хостинг, а как минимум VPS, и желательно там иметь Git и другие механизмы и т.д... Когда Вам это очень понадобиться - вопросы подобные тому, что Вы озвучили выше - отпадут сами собой :)

Comments

[Евгений Вольф]

OnYourLips: вообще, примерно у 30% хостеров есть SSH (и там можно в т.ч. попробовать запустить и композер и миграции и пр., но это немного выходит за рамки изначального вопроса). И, это не обязательно, можно напрямую залить базу, через phpMyAdmin, через PHP-скрипт или через любое другое соединение с БД. Или выполнить соотв. запрос, модифицирующий БД нужным образом.

Мы например, миграции в том виде, в котором они есть в Laravel, не используем вообще, за исключением крайне редких случаев, когда нужно где-то сохранить эдакий примитивный "сниппет" вместе с куском структуры данных, принадлежащих персонально ему (например, "новости" [просто "новости", без каких либо доп. механизмов]). В остальных случаях, миграции не только не могут обеспечить сохранение целостности (сохранности) данных, в т.ч. при "откатах", они не имеют даже возможности, создавать такие примитивные вещи, как например, триггеры на уровне MySQL, не говоря уже о каких-то более "глубоких" вещах, свойственных более полноценным БД (например, PostgreSQL). То есть, они даже из типов полей - имеют в своём наборе только базовые типы, не говоря уже про разные параметры (вроде "статистики", или "выражений для смены типа"). По сему, миграции в ряде случаев (в нашем варианте, примерно в 99%), миграции, по природе своей - бесполезны.

[DenKG]

То есть нужно просто с локального сервера залить те же самые файлы на хостинг?

[Евгений Вольф]

В большинстве случаев это возможно.

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

надо писать миграции так, чтобы была возможность отката. В большинстве случаев это возможно.

даже в "лабораторных условиях" и при идеальном раскладе - это не решает проблему примитивизма самих миграций. Теоретическая возможность отката не делает их менее примитивными, не добавляет им все возможные типы данных, которые есть в БД и всего остального. А невозможность выполнить одну любую операцию в производственном цикле, говорит о не ликвидности всей системы. То есть, "пациент либо жив, либо мёртв", вариант "пациент жив на 90%", к сожалению, невозможен. Так же как компьютер, не может работать в отсутствии одного из ключевых компонентов.

Что касается триггеров и т.д., то логика на уровне базы слишком дорого обходится.

При неправильном подходе, даже использование фреймворка слишком дорого обходиться. И есть ряд случаев, когда его использование просто невозможно. Я уже не говорю, про CMS... Есть случаи, когда даже использование JOIN'ов слишком дорого обходится. Но это не повод, перестать использовать JOIN'ы.

Всё зависит от того, что мы хотим получить на выходе. Если у нас стоит цель разработки и поддержки проекта в 1.5 человека, размещаемого на хостинге за 1-2$/мес., где кроме MySQL ничего нет, и сам MySQL настолько ограничен, что кроме создания таблиц - мы ничего не можем создавать кроме простых таблиц (даже View, т.к. это требует доп. привилегий пользователя) - то да, стоимость хостинга проекта на VPS (где мы сможем полноценно использовать хотя бы MySQL), может увеличить в 5-10 раз (до 5-10$/мес.). В этом раскладе в принципе, даже миграции в том виде, в каком они есть в Laravel - выглядят порой довольно привлекательно.

Если же говорить, исключительно о качестве конечного продукта и скорости его работы, предполагая, что мы можем использовать базу на 100%, и даже с учётом того, что базу будет использовать исключительно одно приложение - построение логики работы БД на уровне самой БД - может дать прирост производительности порой в 10-50 раз, за счёт сокращения накладных расходов, возможности использования внутренних механизмов БД. В том числе, планировщик запроса самостоятельно может оценить, какая операция будет менее затратной при использовании того или иного механизма, при получении/обработке данных, в т.ч. используя уже имеющиеся данные/параметры из самой БД. И даже если говорить, о примитивном триггере - триггер реализованный на уровне БД будет много быстрее, чем полная реализация этого же триггера, на уровне PHP-клиента. Хотя бы по тому, что сам механизм триггеров из БД никто не вырезал, и проверка наличия триггеров будет вызываться в любом случае... и было бы крайне странно, если бы запрос на уровне БД, сгенерированный самой БД, не проходящий все этапы парсинга, преобразования и т.д. - работал бы медленнее, чем аналогичный запрос, посланный с клиента и проходящий все эти этапы. Наличие обратного эффекта, говорит как правило, либо о низкой квалификации администратора БД (т.к. он просто не знает, как нужно строить логику на уровне БД правильно), либо о довольно странной реализации движка БД, в котором внутренние механизмы самого же движка, работают медленее, чем аналогичные механизмы написанные на клиенте (с учётом того, что база у нас обычно написана на С/С++, а клиент на PHP в данном случае и с учётом того, что клиент опять же, генерирует запросы к самой БД, а не вмешивается в её файловую систему или внутренние механизмы на низком уровне), либо, о совокупности обоих этих факторов.

[Евгений Вольф]

DenKG: именно так. И залить БД, "как есть", на сервер. И создать файлик .htaccess (есть по тексту выше), что бы корешок сервера для лары правильно определялся.

[Евгений Вольф]

DenKG: ещё, если у Вас база (набор данных) довольно примитивные, не нуждающиеся в какой-то особой логике и у сервера есть SSH, можно рассмотреть механизм миграций, как рекомендует коллега OnYourLips . Так же при наличии SSH, можно попробовать и compser засунуть туда же, на сервер и обновлять папку "vendor" прямо на сервере. Она обычно самая большая (по кол-ву файлов) и загрузка/обновление через composer может сэкономить немного времени.

[Alisher Sabirov]

Большое спасибо бро! Работает =)

[nickon72]

Благодарю, за краткий, толковый ответ, свою проблему решил за 5 минут.
Все по делу, без "воды".
Спасибо что тратите свое время для помощи новичкам!!!

Answer 2

[darksladen]

Все очень просто! На локалке устанавливаете laravel, потом архивируете папку, кидаете по ftp на хостинг, а там разархивируете. Это как по мне самый быстрый и простой способ.

Answer 3

[Flasher]

Копируешь полностью все файлы (абсолютно все папки и файлы, как у тебя лежат на локальном сервере) на хостинг. Меняешь .env (коннект к бд) и в папке app меняешь файлик database.php (коннект к бд). Всё!

Потом ставишь putty и уже там работаешь с artisan migrate, чтобы запушить все таблицы в бд. Ну это уже другой вопрос.

Comments

[Константин Васильев]

Вы можете привести ссылку на статью, как импортировать таблицы в базу данных?

[Константин Васильев]

Чтобы выполнить миграции, нужно в консоли в папке проекта написать php artisan migrate