Кто как деплоит на продакш сервер?
- Ghost_nsk
- Сообщения: 825
- Зарегистрирован: 2012.01.01, 00:45
- Откуда: Новосибирск
- Контактная информация:
Кто как деплоит на продакш сервер?
Народ, опишите как Вы работаете с проектом и выкладываете наработки на рабочий сервак. Очень интересно. Кто-нибудь работает сразу на продакшене?
Re: Кто как деплоит на продакш сервер?
Весь код хранится в Git (как в наше время без систем контроля версий).
Есть 3 окружения: dev, test и prod. Деплой на тест и прод делается через phing + rsync. Способ конечно простой, но для моих проектов пока, что этого достаточно.
Есть 3 окружения: dev, test и prod. Деплой на тест и прод делается через phing + rsync. Способ конечно простой, но для моих проектов пока, что этого достаточно.
Re: Кто как деплоит на продакш сервер?
Присоединяюсь к вопросу!
unclead, а можно поподробней? Особенно для джунов гита и систем непрерывной интеграции. Как я понял, задеплоить проект только гитом можно только через bare-репозиторий. То есть у меня есть репозиторий на компе, с него я пушу в bare из bare я пуллю в директорию куда смотрит домен.
Подскажите как сделать правильно и просто, особенно когда работаешь над проектом один.
unclead, а можно поподробней? Особенно для джунов гита и систем непрерывной интеграции. Как я понял, задеплоить проект только гитом можно только через bare-репозиторий. То есть у меня есть репозиторий на компе, с него я пушу в bare из bare я пуллю в директорию куда смотрит домен.
Подскажите как сделать правильно и просто, особенно когда работаешь над проектом один.
2b||!2b Just read the instructions
- samdark
- Администратор
- Сообщения: 9489
- Зарегистрирован: 2009.04.02, 13:46
- Откуда: Воронеж
- Контактная информация:
Re: Кто как деплоит на продакш сервер?
У нас всё в Git, на тестовый сервер деплоится по коммиту в master через хук. На продакшн отдельная ветка с тегами и надо запускать деплой руками. Написано всё на баше.
Нравится Yii? Давайте сделаем его лучше!.
Re: Кто как деплоит на продакш сервер?
у нас схоже с тем как описал SamDark. Весь код хранится в git.Для разработчик используются ветки, готовые фичи мержатся в masterunclead, а можно поподробней?
Для продакшена есть ветка production. Деплой запускается вручную. В phing для задачи deploy прописан следующий алгоритм:
- создаем тег в ветке production
- выкачиваем исходный код с помощью команды git archive в директорию export
- в папке export устанавливаем зависимости через composer
- подготавливаем конфиги
- запускается команда rsync для синхронизации с боевым сервером. При этом все что нужно во время разработки исключается (не синкуется)
- если есть новые миграции, то заходим на сервер и выполняем их
- при необходимости перезапускаем демоны
На самом деле алгоритм прост и он всего лишь оптимизирует рутину.
Для деплоя есть много других утилит. Я слышал про
http://deployer.org/
http://capistranorb.com/ но он на руби
https://github.com/rocketeers/rocketeer
Re: Кто как деплоит на продакш сервер?
У нас все гараздо веселее ))
Для каждого окружения, dev и prod, есть свой makeFile в котором описаны все необходимые действия для установки проекта
Пример makeFile для prod версии
если выполнить `make install` то проект будет полностью установлен. Но так можно установить только на тестовом сервере. На prod, из-за того что сборка проекта происходин на Jenkins (навароченая bash-а крутилка), а завершается установка уже на prod сервере приходится часть команд выполнять на Jenkins, и часть на prod сервере.
Jenkins:
~$ make composer
~$ make config DB=db_name HOST=db_host USERNAME=db_user_name PASSWORD=db_password
~$ make clear
prod:
~$ make migrate
На данный момент продумываем как избавится от `make config` чтобы логин и пароль вообще нигде не светились.
meke при выполнении команд проверяет каждую на корректность и при возникновении ошибки выполнение скрипта будет прервано
мы намеренно не создавали test environment потому что на тестовом сервере выкатывается prod версия. Таким образом мы тестируем и сам скрипт для выгрузки и сам код в условиях максимально приближенных к боевым.
А вот так мы ловим WebHook
каждая фича находится в своей ветке, а каждая ветка выкатывается на отдельный субдомен (в nginx с помощью регулярного выражения разбирается url и определяется document root) и под неё создается отдельная БД.
0000000000000000000000000000000000000000 - приходят в момент когда ветка была удалена, и значит все файлы что с ней связаны уже можно удалить.
Для каждого окружения, dev и prod, есть свой makeFile в котором описаны все необходимые действия для установки проекта
Пример makeFile для prod версии
Код: Выделить всё
# PostgresDB settings
DB = db
HOST = localhost
USERNAME = postgres
PASSWORD = postgres
CONFIG_FILE = common/config/main-local.php
# =============================================================================
install: composer config migrate clear
composer:
composer global require "fxp/composer-asset-plugin:~1.1.1"
composer install --no-dev --prefer-dist --no-interaction
config:
sed -i -e "s/'dsn'.=>.'.*'/'dsn' => 'pgsql:host=$(HOST);dbname=$(DB)'/g" $(CONFIG_FILE)
sed -i -e "s/'username'.=>.'.*'/'username' => '$(USERNAME)'/g" $(CONFIG_FILE)
sed -i -e "s/'password'.=>.'.*'/'password' => '$(PASSWORD)'/g" $(CONFIG_FILE)
migrate:
php yii migrate/up all --interactive=0
php yii cache/flush-schema --interactive=0
clear:
find -name '.*' ! -name '.' -exec rm -rf {} +
find -name 'composer.*' -exec rm {} +
find -name '*.md' -exec rm {} +
rm -rf environments init
rm -rf */web/assets/*
rm -rf */runtime/*
Jenkins:
~$ make composer
~$ make config DB=db_name HOST=db_host USERNAME=db_user_name PASSWORD=db_password
~$ make clear
prod:
~$ make migrate
На данный момент продумываем как избавится от `make config` чтобы логин и пароль вообще нигде не светились.
meke при выполнении команд проверяет каждую на корректность и при возникновении ошибки выполнение скрипта будет прервано
мы намеренно не создавали test environment потому что на тестовом сервере выкатывается prod версия. Таким образом мы тестируем и сам скрипт для выгрузки и сам код в условиях максимально приближенных к боевым.
А вот так мы ловим WebHook
Код: Выделить всё
$data = json_decode($HTTP_RAW_POST_DATA, true);
preg_match('~([^/]+)$~', $data['ref'], $BR);
$BR = $BR[0];
if ( ! $BR ) exit('Incorrect data');
if ($data['after'] == '0000000000000000000000000000000000000000') {
system('nohup rm -rf ../site.'.$BR.' ../dep_'.$BR.'.log < /dev/null > /dev/null 2>&1 &');
system('mysql -u root -e "DROP DATABASE IF EXISTS site_'.$BR.';"');
} else {
system('cd .. && nohup ./upgrade.sh '.$BR.' < /dev/null > dep_'.$BR.'.log 2>&1 &');
}
0000000000000000000000000000000000000000 - приходят в момент когда ветка была удалена, и значит все файлы что с ней связаны уже можно удалить.
Зачем версировать пакеты это понятно, а вот зачем версировать весь проет если он сам по себе и не встраивается в другие приложения (если вы его только в deb не закатываете ))Sam Dark писал(а):На продакшн отдельная ветка с тегами
- samdark
- Администратор
- Сообщения: 9489
- Зарегистрирован: 2009.04.02, 13:46
- Откуда: Воронеж
- Контактная информация:
Re: Кто как деплоит на продакш сервер?
1. Знать, какая версия сейчас раздеплоена.
2. Помечать стабильный код и важные изменения.
3. Иногда разные мажорные версии выкладываются на разные сервера.
2. Помечать стабильный код и важные изменения.
3. Иногда разные мажорные версии выкладываются на разные сервера.
Нравится Yii? Давайте сделаем его лучше!.
Re: Кто как деплоит на продакш сервер?
master - всегда должен бычть стабильным.Sam Dark писал(а):2. Помечать стабильный код и важные изменения.
У нас разные можорные фичи лежат в разных ветках в git и выкатываютс на тестовом сервере на своем субдомене и со своей БД.Sam Dark писал(а):3. Иногда разные мажорные версии выкладываются на разные сервера.
После тестирования и всех проверок, ветка переносится одним комитом в master.
Таким образом в master находятся комиты с добавлением фич и мелкие правки.
- samdark
- Администратор
- Сообщения: 9489
- Зарегистрирован: 2009.04.02, 13:46
- Откуда: Воронеж
- Контактная информация:
Re: Кто как деплоит на продакш сервер?
Смотря какое ветвление в проекте. У нас в master лежит самый свежий работающий, но, возможно, нестабильный код. Гарантированно стабильный, который преодолел в том числе ручное тестирование, находится в релизной ветке.master - всегда должен бычть стабильным.
А если каждая фича работает по отдельности, но вместе две фичи оказываются нестабильными?У нас разные можорные фичи лежат в разных ветках в git и выкатываются на тестовом сервере на своем субдомене и со своей БД.
После тестирования и всех проверок, ветка переносится одним коммитом в master.
Нравится Yii? Давайте сделаем его лучше!.
Re: Кто как деплоит на продакш сервер?
И опять про deploy https://toster.ru/q/312951
Насколько я вижу проблема возникает из-за того что у наc есть оснавной конфиг (@app/config/main.php) и конфиги окружения (@app/config/main-local.php) который устанавливается в момент инициализации (init). При инициализации проекта приходится постаянно перезаписовать настройки в файле common/config/main-local.php для настройки под конкретный проект. На тестовом сервере одни настройки к db, storage, mail, log, ... на продакшен сервере другие. Честично проблему можно решить с помощью конфигов огружения в которых сразу будут забиты правильне данные для prod и test. Но конфиги со временем будут меняться. И все равно при выгрузке кода на сервер нужна лезть на сервер и исправлять конфиги в ручную. И хорошо если есть доступ к продакшен серверу, а если его нет? А ещё лудше когда ты даже и незнаешь как подключится к продакшен db, нет ни логина ни пароля и db находится на *.*.*.* сервере.
Для этих (и не только) целей я и использую MakeFile с разделом
который и помагает перезаписать настройки в common/config/main-local.php
Хоть оно и работает, но выгледит как хардкод, и я надеюсь избавится от него.
Первый вариант добавить ещё один конфиг файл main-env.php который будет устанавливаться 1 раз и больше никогда не будет перезаписан, но тогда остается проблема его расширения. А также при выгрузке кода на тестовый сервер все ветки из git выгружаются в свои папки и имеют свой субдомен и свою копию master db. Соответственно и настройки к БД для каждой доработки будут отличатся хотя у всех одинаковые настройки окружения.
Второй вариант использовать $_ENV или getenv() в тех местах где нужна что-то переопределять.
Может я что-то упустил. Жду ваших вариантов решения данной проблемы.
Насколько я вижу проблема возникает из-за того что у наc есть оснавной конфиг (@app/config/main.php) и конфиги окружения (@app/config/main-local.php) который устанавливается в момент инициализации (init). При инициализации проекта приходится постаянно перезаписовать настройки в файле common/config/main-local.php для настройки под конкретный проект. На тестовом сервере одни настройки к db, storage, mail, log, ... на продакшен сервере другие. Честично проблему можно решить с помощью конфигов огружения в которых сразу будут забиты правильне данные для prod и test. Но конфиги со временем будут меняться. И все равно при выгрузке кода на сервер нужна лезть на сервер и исправлять конфиги в ручную. И хорошо если есть доступ к продакшен серверу, а если его нет? А ещё лудше когда ты даже и незнаешь как подключится к продакшен db, нет ни логина ни пароля и db находится на *.*.*.* сервере.
Для этих (и не только) целей я и использую MakeFile с разделом
Код: Выделить всё
config:
sed -i -e "s/'dsn'.=>.'.*'/'dsn' => 'pgsql:host=$(HOST);dbname=$(DB)'/g" $(CONFIG_FILE)
...
Хоть оно и работает, но выгледит как хардкод, и я надеюсь избавится от него.
Первый вариант добавить ещё один конфиг файл main-env.php который будет устанавливаться 1 раз и больше никогда не будет перезаписан, но тогда остается проблема его расширения. А также при выгрузке кода на тестовый сервер все ветки из git выгружаются в свои папки и имеют свой субдомен и свою копию master db. Соответственно и настройки к БД для каждой доработки будут отличатся хотя у всех одинаковые настройки окружения.
Второй вариант использовать $_ENV или getenv() в тех местах где нужна что-то переопределять.
Может я что-то упустил. Жду ваших вариантов решения данной проблемы.
Re: Кто как деплоит на продакш сервер?
- первый тезис: настройки и пароли не должны храниться в гите
- второй тезис: есть понимание, что (тут вода) ... и плохо никому от настроек окружения в гите не будет. Поэтому храним сразу конфиги вида config.dev.php, config.test.php, config.prod.php итд
- третий тезис: действительно настройки серверов будут меняться и (тут какое-то беспокойство поэтому поводу, но не очень понятно причем тут я как разработчик - пусть админ коммитит в репо новые пароли, а тестировщик разбирается почему тестовое окружение не работает)...
- четвертый тезис: а почему бы не завести общий сервер конфигурации, откуда в любом виде в любом протоколе загружались бы настройки без хранения в гите.
а вообще проблем не вижу - все проблемы как-то притянуты за уши, пароли никогда не меняются, сервера работают годами... Ну и да, крутишь все в одном докере со своим env-файлом и проблем не знаешь - портабельность независимо от окружения и серверов.
- второй тезис: есть понимание, что (тут вода) ... и плохо никому от настроек окружения в гите не будет. Поэтому храним сразу конфиги вида config.dev.php, config.test.php, config.prod.php итд
- третий тезис: действительно настройки серверов будут меняться и (тут какое-то беспокойство поэтому поводу, но не очень понятно причем тут я как разработчик - пусть админ коммитит в репо новые пароли, а тестировщик разбирается почему тестовое окружение не работает)...
- четвертый тезис: а почему бы не завести общий сервер конфигурации, откуда в любом виде в любом протоколе загружались бы настройки без хранения в гите.
а вообще проблем не вижу - все проблемы как-то притянуты за уши, пароли никогда не меняются, сервера работают годами... Ну и да, крутишь все в одном докере со своим env-файлом и проблем не знаешь - портабельность независимо от окружения и серверов.
Re: Кто как деплоит на продакш сервер?
Может задам глупый вопрос ) Но вот часть проектов написанных на Yii1 при деплое на паблик просто заливались по ФТП, где лежал .htaccess с установленным ENV=production
ну и собственно так система понимала что она в реале и подтягивала config.prod.php
можно ли организовать с Yii2 такой же механизм, чтобы деплоить проект на шаред хостинг где нет доступа к ssh и нет возможности запускать composer и прочее =)
ну и собственно так система понимала что она в реале и подтягивала config.prod.php
можно ли организовать с Yii2 такой же механизм, чтобы деплоить проект на шаред хостинг где нет доступа к ssh и нет возможности запускать composer и прочее =)
Re: Кто как деплоит на продакш сервер?
можно. точно также как в yii1.
Re: Кто как деплоит на продакш сервер?
причем тут композер? композер вам сливает сторонние зависимости, а деплой в основном про выливку непосредственно вашего кода.
Re: Кто как деплоит на продакш сервер?
если вкратце то оптимальный деплой идет так
Делаем commit
Заходим на сайт по ssh
git pull
php composer.phar install
yii migrate
вот про эти вещи я и говорил, что изначально проект заточен на такой деплой (vendor кстати при заливке в git игнорируются) поэтому изначально была мысль что только так надо загружать рабочую версию проекта, ведь часть кода собирается после yii init
Опять же повторюсь, может глупость пишу, так как информации прочитано много, голова кругом, а начинать с чего-то надо.
Re: Кто как деплоит на продакш сервер?
Код: Выделить всё
# Убираем из крона задачи
crontab -r
# Отправляем в демоны сигнал остановки
./yii system/stop-daemons-signal
# В цикле проверяем демоны и крон-скрипты, пока те не остановятся (сигнал остановки отправлен выше командой)
YII_PROCESSES=`ps ax | grep yii | grep -v grep`
while [ -n "$YII_PROCESSES" ]; do
echo "Обнаружены запущенные YII-скрипты:"
echo "$YII_PROCESSES"
echo " "
echo "Повторная проверка процессов через 3 сек..."
sleep 3
YII_PROCESSES=`ps ax | grep yii | grep -v grep`
done
# Подтягиваем изменения в гит
git fetch --prune
# Установливаем на фронте сообщеньку "Извините, на сайте идут технические работы"
./yii system/set-maintenance-mode
# Применяем изменения гита
git pull
# Накатываем конфу продакшена
./init --env=Production --overwrite=y
# Устанавливаем все зависимости композера на основе composer.lock
composer install --no-dev --optimize-autoloader
# Дропаем мемкэш
echo 'flush_all' | nc -q 1 127.0.0.1 11211
# Накатываем миграции
echo yes | ./yii migrate
# Накатываем RBAC
./yii rbac/init
# Удаляем старьё из assets
find ./admin/web/assets -type l -delete
find ./frontend/web/assets -type l -delete
# Сжимаем css/js
./yii asset frontend/config/assets-compilation.php frontend/config/assets-compiled.php
# Убираем с фронта сообщеньку "Извините, на сайте идут технические работы"
./yii system/unset-maintenance-mode
# Устанавливаем кронтаб (хранится под гитом в проекте)
crontab ./crontab
# Выводим git-статус
git status
Для сложных сайтов делаю сборку в отдельной папке с переключением симлинка. Подробнее здесь.
Re: Кто как деплоит на продакш сервер?
неплохо. на работе более обширный деплой, но примерно с такими же шагами.
личные проекты деплою через свой docker-registry в docker-имиджах.
личные проекты деплою через свой docker-registry в docker-имиджах.
Re: Кто как деплоит на продакш сервер?
Эмм, а без down time слабо?rugabarbo писал(а): ↑2017.01.12, 17:03Код: Выделить всё
# Установливаем на фронте сообщеньку "Извините, на сайте идут технические работы" ./yii system/set-maintenance-mode
А так не катит?rugabarbo писал(а): ↑2017.01.12, 17:03Код: Выделить всё
# Дропаем мемкэш echo 'flush_all' | nc -q 1 127.0.0.1 11211
Код: Выделить всё
~$ service memcached restart
Код: Выделить всё
~$ yii cache/flush-all
Молодец, про такие финты не каждый знает, но это можно сделать прощеrugabarbo писал(а): ↑2017.01.12, 17:03Код: Выделить всё
# Накатываем миграции echo yes | ./yii migrate
Код: Выделить всё
~$ yii migrate/up all --interactive=0
Я бы добавил ещё пару полезных параметровrugabarbo писал(а): ↑2017.01.12, 17:03Код: Выделить всё
# Устанавливаем все зависимости композера на основе composer.lock composer install --no-dev --optimize-autoloader
Код: Выделить всё
composer install --no-dev --optimize-autoloader --prefer-dist --no-interaction
--no-interaction - для того чтобы не задавал глупых вопросов, всегда выбирает [yes]
А за это спасибоrugabarbo писал(а): ↑2017.01.12, 17:03Код: Выделить всё
# Устанавливаем кронтаб (хранится под гитом в проекте) crontab ./crontab