Стейджинг, CI

ну и норм. хуйни им по контейнеру на папку, ничего не выдавая

Лучше всего чтобы собиралось CI

это ясно

После тестов

что лучше всего)

Далее на прод после приемочного

ну ясное дело

но это в целом про процесс. Я началось с окружения для разработчика

В локале докер только если есть проблемы с несовпадающим окружением

и к тому же подобные вещи не внедряются внезапно

CI

Для начала чтобы привыкать начали

Тесты, анализ кода

но это в целом про процесс. Я началось с окружения для разработчика

Рекомендую с самого начала делать правильно. Все равно прийдется воевать с разработчиками, все равно они полезут на стену

Можно деплой через докер вкрутить, но аппу надо будет подпиливать

деплой через докер?

как оно выглядит? билдится контейнер и выливается на прод?

Вроде того

Имейдж метиться тегом

стоп, но ведь контенер - это про процессы. А не про код?

Эмм

А что у вас внутри имейджа?

Процесс да в первую очередь

Ну значит я про четвертый пых почти угадал )))

5.4)))

не все так плохо, тсссс

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

не все так плохо, тсссс

Ну к фтп то хоть через phpstorm?

я в контейнерах кода просто ни разу не держала, данные приложений вытаскивала наружу.

Аль блокнот

Аль блокнот

не сыпьте соль на рану XD

да ладно, phpstorm

:))

Эмм код снаружи это порой глючит

зато при дестрое контейнера он цел

Эмм

Докер зачем тогда?

Окружение поднять?

Я его пользовала для запуска обособленых процессов

зато при дестрое контейнера он цел

Вот эт их идеология парочная, его можно не дестроить

две версии эластика, гитлаб

чтобы это все не ругалось между собой

Окружение поднять?

а зачем он ещё нужен?

я ж чего и спрашиваю про деплой - не пользовалась

Окружение конечно удобно, но в основном это деплой

Артефакты + раскатывание по серверам

зато при дестрое контейнера он цел

А как ты юзеров разделяешь? Или у тебя все девы с одной папкой работают?

Особенно с каким нить кореось

Или ранчос

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

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

потом все равно нужно полностью пересетапливать сервер. И вот к этому счастливому моменту мне надо продумать схему, как все будет работать

если докер и вправду может облегчить деплой - здорово

Главное не забывать про версионирование

Релиз, версия, тег

И деплой тега

ага

Релиз, версия, тег

Прикольно, а код как собирается?

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

Из гита просто накатывается с файлами в момент деплоя?

коллеги, кто с hashicorp vault работал? Есть ли адекватные способы перенести данные между secret backends?

например mysql -> consul?

Код из гита на интеграционке

Собирается в имейдж

Деплой выкатыванием нового тега имейджа

девопсы подскажите пожалуйста, есть такая проблема upstream timed out (110: Connection timed out) , если увеличить MaxKeepAliveRequest она может пропасть?

ERROR: S client not available

девопсы подскажите пожалуйста, есть такая проблема upstream timed out (110: Connection timed out) , если увеличить MaxKeepAliveRequest она может пропасть?

сомнительно

судя по вашему запросу - увеличивать вам надо proxy_read_timeout

судя по вашему запросу - увеличивать вам надо proxy_read_timeout

увеличивать таймауты это не выход

увеличивать таймауты это не выход

тогда решайте проблему

upstream timed out - это не проблема. Это симптом

upstream timed out - это не проблема. Это симптом

да понятно

upstream timed out - это не проблема. Это симптом

просто не понятно где тормоза :(

да понятно

тут только профилировать бэкенд

счетчики там всякие

я в контейнерах кода просто ни разу не держала, данные приложений вытаскивала наружу.

для пхп удобнее в data volume'ах код держать, да, если там CMS'ка

я ж чего и спрашиваю про деплой - не пользовалась

ты можешь просто .service -файл сделать и там команды docker pull docker run docker stop

и будет через systemctl управляться как обычный сервис

Деплой выкатыванием нового тега имейджа

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

а версию узнавать через docker exec cat /usr/src/app/version

А откат?

Новый прод собирать?

ну, по идее можно сейвить старый образ под другим тегом перед принятием нового

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

ну, ввести какой-нибудь тег backup

Может быть, обновление тега пока не большая проблема

ну да, тут смотря как прописано

Есть ещё момент - в деплой тикете указана определенная версия

просто мне кажется не очень удобным каждый раз менять .service-файлы

Тае что чётко ясно что выкатывается и когда

и делать systemctl daemon-reload

я версии храню в файлах version внутри образа

то есть через cat по идее всегда можно залезть и посмотреть их

И это тоже

И сами сервисы через /version умеют отдавать

если докер и вправду может облегчить деплой - здорово

Загоняй их в гит, и каким нибудь jenkins-php гони через тесты. Там же можно выкатку докер контейнера сделать и смотреть что и куда.

И сами сервисы через /version умеют отдавать

?

О однофамилец ))