@Artem0071
Безработный mr. Junior

Как правильно деплоить проект?

Ларавел используется как апи для фронта и приложения

Есть ли какая то инструкция / шаги по которым стоит делать перенос с локалки на хостинг/сервер?
(на серве)

Как мне сейчас представляется:
1) Делаю git commit -> push // чтобы была какая то версионность и можно было вернуться
Так же читал про то что можно как то сделать так чтобы с гита сразу заливался на сервер, но так и не понял как. Есть какая то нормальная инструкция?
2) В ларавел есть такая вещь как миграции. Я разобрался как с ними работать, но не понимаю как они будут работать когда будут какие то обновления произовдится
Если я на локалке создам еще какие то миграции, то как их переносить на сервер?
К тому же если использовать гит? Ведь гит же не сможет "произвести" миграцию?
3) Как сохранять пароли?
Сейчас все хранится в .env . И сейчас у меня бд находится на хостинге, а не локально. Как сделать так, чтобы на локалке я подсоединялся к одной бд, а на хостинге ларавел уже подсоединялся к другой?
  • Вопрос задан
  • 9857 просмотров
Пригласить эксперта
Ответы на вопрос 5
toxicmt
@toxicmt
CTO at hexlet.io
Если не брать в рассчет современные подходы на основе докера, то самый универсальный способ - использовать ansible и его модуль docs.ansible.com/ansible/latest/deploy_helper_modu...

Если погуглить 'laravel deploy ansible', то вы найдете множество статей и репозиториев на гитхабе, из которых можно почерпнуть всю необходимую информацию.

p.s. И никогда не используйте баш скрипты для подобных задач.
Ответ написан
Maksclub
@Maksclub
maksfedorov.ru
по п.1 — делается черех веб-хук GIT
по п.2 — миграции также как и любые др файлы проекта передаются через GIT на продакшн-сервер
а вот чтобы их применить — нужно на продакшене их накатить
по. п3 — пароли индивидуально на сервере задаются, их нельзя пихать в GIT


Чтобы все автоматизировать по цепочке:
pushвеб-хукpull+migrate+composer update+npm install

Можно использовать полноценные инструменты для деплоя:
Deployer
Capistrano
Ответ написан
Комментировать
zvermafia
@zvermafia
WebDev
Есть бесплатный и хороший интрумент (есть готовые базовые настройки под различные framework'и, в том числе и Laravel): Deployer — Deployment tool for PHP.
И есть платный сервис, тоже хороший (но как по мне дороговатый): Envoyer.
Ответ написан
Комментировать
@jumale
1) Инициатор деплоя: это может быть как гит-хук, так и допустим вызванная вручную команда. Для начала рекомендую не зацикливаться на хуках, а вызывать в ручную. Если деплоите не так часто, то этого будет вполне достаточно и более безопасно.
2) миграции - это всего лишь sql команды которые меняют бд. Запуск миграций - это то же самое если вручную запустить любой sql клиент у себя на компьютере, присоединиться к бд и начать добавлять/удалять таблицы и столбцы. Я веду к тому, что миграцию на prod сервере можно выполнить и с локальной машины, если миграции будут выполнены с продакшн конфигурацией.
3) Конфигурация. В случае с .env файлом это можно сделать таким образом:
- создаем файл .env.dist в котором указываем все переменные которые требуются для приложения, но оставляем значения пустыми
- комитим .env.dist в репозиторий. Теперь у нас в репозитории есть шаблон по которому мы можем создать .env файл на локальной машине и заполнить значения переменных
- добавляем .env в .gitignore (если .env уже был закомичен, то надо его сперва удалить и закомитить удаление, иначе .gitignore будет неправильно игнорировать .env)
- теперь когда .env игнорируется гитом, можно скопировать наш шаблон .env.dist как .env и заполнить значения переменных. Каждый, кто устанавливает этот проект с нуля у себя на машине должен будет сделать то же самое.

Вообще деплой можно разбить на несколько этапов:
- инициатор деплоя (любое событие по которому начинается деплой)
- сборка проекта (подготовка всех файлов в то состояние в котором они должны отправиться на prod сервер и заменить собой текущие файлы на сервере)
- тестирование проекта (запуск юнит и функциональных тестов, чтобы убедиться что мы заливаем рабочий код)
- собственно перенос проекта на сервер
- выполнение post-deployment команд, которые должны быть выполнены когда новые файлы уже на сервере (например миграции и т.п.)
- интеграционные smoke-тесты (можно оправить GET запросы на ключевые страницы нашего prod сервера и проверить, что в ответах содержится ожидаемый текст или HTML, это делается чисто для того чтобы убедиться, что после деплоя сервер все еще живой и отображает нужные страницы)

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

Для автоматизации сборки и деплоя существует множество инструментов. Большинство из них просто предлагает дополнительный уровень абстракции над низкоуровневыми командами, что позволяет удобнее организовывать сборки больших проектов с множеством шагов и меньше задумываться о деталях. Обычно разработчики используют для любых проектов какой либо один инструмент, с которым они на "ты" - это всегда удобно, не надо учить ничего нового, все шишки уже набиты, все грабли наступлены. Если у разработчика нет опыта с подобными инструментами и проект достаточно простой, то я бы порекомендовал начать с написания простого скрипта на любом удобном языке программирования. В этом случае не придется тратить время на освоение нового фреймворка и в ваших руках будет максимум контроля над процессом.

У меня нет опыта с ларавел, но для симфони проекта я бы написал приблизительно такой bash скрипт:
# если Вы деплоите с локальной машины,
# то как минимум не стоит собирать проект из файлов с которыми Вы работаете в редакторе,
# потому что там у нас могут быть незакомиченые изменения, локальные настройки
# и еще много чего, что не должно попасть на prod сервер
# поэтому проект будем собирать с нуля в отдельной директории, например "build"
# (которую тоже нужно предварительно добавить в .gitignore)

# очищаем директорию build и заходим в нее
rm -rf build
mkdir build
cd build
# клонируем наш проект
git clone git@example.com/user/project . # "." клонирует в текущую директорию
git checkout master
# создаем конфиг для prod
cp .env.dist .env
# дальше надо заполнить значения переменных в .env файле
# для начала можно просто поставить скрипт на паузу в этом моменте и заполнить вручную,
# а в будущем как нибудь автоматизировать этот процесс,
# например хранить файл с prod конфигами где нибудь на машине
# и во время сборки копировать их в проект

# устанавливаем вендоры
composer install
# прогоняем юнит и функциональные тесты, чтобы убедиться что мы не зальем какой нибудь баг
vendor/bin/phpunit -c unit.xml
vendor/bin/phpunit -c functional.xml
# прогреваем кеш
bin/console cache:clear --no-warmup --env=prod
bin/console cache:warmup --env=prod

# выполняем любые другие шаги по подготовке проекта
# ...

# теперь наш проект готов к заливке на сервер
# например через scp
scp -r . <username>@<hostname>:<destination path>

# наконец, можно накатить миграции баз данных
php app/console doctrine:migrations:migrate --env=prod

# запускаем смок-тесты которые покажут, что деплоймент прошел успешно
vendor/bin/phpunit -c smoke.xml
Ответ написан
Комментировать
@ProSerg
Предлагаю воспользоваться готовыми решениями типа gitlab ci. Копать в сторону агентов Gitlab Runner и написание ci сценариев. . Там есть возможность deploy, а также разворачивать кластер kubernetis. Gitlab бесплатный сервер с широким набор инструментов, есть возможность его развернуть на собственном сервере на линуксе. Ставиться одной командой.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы