Использование инструментов написанных на других ЯП.

  • Автор темы Автор темы AmdY
  • Дата начала Дата начала
А чем вам докер не угодил? По моему отличная штука)
А как в докере осуществить перенос содержимого (конфигов) из контейнера в контейнер? Да еще с учетом того, что на продакшн машине может быть много контейнеров, и часть библиотек должна быть шареная.
 
MiksIr, а зачем переносить конфиги в докере? У тебя контейнер - готовая единица. Можешь поднять сколько угодно контейнеров - надо подготовить только один. И это по моему главный плюс.
 
hell0w0rd, ибо вопрос был ;)
Т.е. создали контейнер, подняли скока угодно... как дальше то жить?
Предположим есть папочка etc, в которой лежат все конфиги в репозитории.
И вот часть Dockerfile:
Код:
ADD etc/php.ini /etc/php5/fpm/php.ini
ADD etc/php-fpm.conf /etc/php5/fpm/php-fpm.conf
Ну а дальше порты из контейнера пробрасываешь в хост, хочешь сразу 80, хочешь - через nginx. У тебя внутри контейнера изолированное окружение, которое ты строго контролируешь.
И так-то у контейнера своя fs, состояние которой можно фиксировать, так что ты можешь один раз создать бинарник и дальше просто разослать по нодам, ну, теоретически - мне это не было нужно, так точно не знаю.
 
hell0w0rd, угу, конфиги в репозитории =) В общем, что-то для управления конфигурацией/конфигами отдельно ставить все-равно. Докер хорошо, но немного другие цели.
 
Конфиги отдельно от кода - это вроде очевидно, как иначе-то
 
MiksIr, не понял, а какие другие цели? Волшебную кнопку "сделать хорошо" хочешь?)
 
MiksIr, не понял, а какие другие цели? Волшебную кнопку "сделать хорошо" хочешь?)
Очень смешно, ага.
post-720370 - как мне сделать это с докером? Ясно дело, плавно, не прерывая работу контейнера. У докера есть свои механизмы для этого или нет?

Конфиги отдельно от кода - это вроде очевидно, как иначе-то
Нынче конфиги nginx часто неотделимы от кода и по хорошему должны с кодом в репе быть.
 
ага, и php.ini и my.ini и ldap.conf a также hosts и fstab на всякий случай
Ну .htaccess кладут же :D
Еще часто и роутинг апачем делают :D

Нынче конфиги nginx часто неотделимы от кода и по хорошему должны с кодом в репе быть.
Зачем? Хочу пример такого конфига.
Потому что обычные приложения на фреймворках типовым конфигом удовлетворяются.
 
MiksIr, посмотри сам на доки docker. Ты можешь создать контейнер, протестировать и деплоить ровно то, что точно заведется. Серебрянной пули нет.
 
Зачем? Хочу пример такого конфига.
Потому что обычные приложения на фреймворках типовым конфигом удовлетворяются.
Мог бы наковырять. Из "не обычных на фреймворке". Но на самом деле так далеко ходить не нужно. Банальные редиректы - лучше писать на уровне вебсервера.
 
nginx монолитностью конфига все портит, да. Приходится как-то разделять и делать генерацию.
 
Absinthe, у нас приложение обрабатывает 200 доменов, по домену на город, то есть у нас домен - это входной параметр, так исторически сложилось.
так что конфиг nginx - явно часть приложения.
 
Absinthe, у нас приложение обрабатывает 200 доменов, по домену на город, то есть у нас домен - это входной параметр, так исторически сложилось.
так что конфиг nginx - явно часть приложения.
Я бы на уровне роутинга приложения использовал город в поддомене: http://laravel.com/docs/5.0/routing#route-groups
 
  • Like
Реакции: WMix
опять пошла в огороде бузина, а в городе дядька.
у нас не ларавел, у нас город используется в роутинге.
вы мою бизнес-логику не знаете, несколько десятков правил роутинга не видите.
у многих доменов кастомные редиректы, несколько десятков 301х редиректов в nginx, и я вынес еще больше, чтобы правила роутинга стали одинаковыми для всех городов.
впереди у меня посадочные страницы по ключевым словам, без контроля nginx тут будет неуютно
 
у нас не ларавел, у нас город используется в роутинге.
Да все равно, какой у вас там фреймворк. Я просто пример привел, чтобы ты какашками опять не кидался, не поняв, про что я говорю.
Не помогло.

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