а с системд — хренушки

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

Но вы всегда можете поставить сторонний супервизор или написать свой внутри приложения. Мы все немного любим делать троллейбус из буханки)

порт ВСЕГДА не слушается после старта приложения и начинает слушаться только через какое-то время после старта

Но вы всегда можете поставить сторонний супервизор или написать свой внутри приложения. Мы все немного любим делать троллейбус из буханки)

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

порт ВСЕГДА не слушается после старта приложения и начинает слушаться только через какое-то время после старта

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

дело не в том, что что то пошло не так

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

вот и все

Мне позиция Джейка ближе ))

и вообще с линукса надеюсь, но это оффтопик

так некуда банально, остальное все вообще говно

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

хелсчеки на уровне супервизора -- кмк не самая лучшая идея

Да речь не столько о хелсчеках, как о способе оповестить супервизор что инициализация завершена, боевой режим включен, можно зависимости стартовать. Watchdog в systemd отдельно включается, просто пользует тот же сокет.

хелсчеки хорошо

меня радует как это в докере запилили

щас бы еще докеркомпоуз подтянулся

и было бы вообще шоколадно

Да речь не столько о хелсчеках, как о способе оповестить супервизор что инициализация завершена, боевой режим включен, можно зависимости стартовать. Watchdog в systemd отдельно включается, просто пользует тот же сокет.

но зачем это на уровне работы с системными службами?

Да хз. Нормальный софт сам разберется даже с сокетами, в документации systemd так и пишут при освещении параллельного старта служб. А вот для мелких поделок вполне себе дополнительный контроль и упрощение задачи обработки ошибок. Сломался? Насрать - передернут сверху. Воркеры не умеют дождаться сокета сами? Насрать - скажем когда готовы.

А у кого докер используется для продакшена и для девелопмента/стеджа?

Димас, иди спать :D

сколько можно то ))))

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

Да у меня тут работы непочатый край ))

ENV не очень вариант?

устанавливать через окружение

У меня в ансибле порядка 50ти переменных

Для приложения

исходники в контейнере, конфигурация в окружении

Чем вы все это устанавливаете?

Т.е. если ансибл то тут все ясно, просто генерим конфиг. А вот с докером не совсем.

мы в рамках амазона какую-то тамошнюю дрянь ))

хотя речь уже не про амазон? :D

отпустило?

Во, щас глянул — в другом у меня 80 переменных

или 100

Хер знает, на глаз прикинул

И все они должны быть разные для каждого из окружений

Какой здесь best practice?

Речь про абстрактный докер.

Можно эти переменные держать в каком-нить файле и пробрасывать в контейнер этот файл

А вообще не вижу проблем хоть 1000 переменных окружения импортировать. Тормозить не должно, пусть юникосзадроты поправят меня

А как быть, если у меня конфиг nginx например разный для dev/prod. Ведь в идеологии докера, все должно быть 1 в 1? Или это не так?

Можно собрать 2 контейнера - один для prod, а от него отнаследовать dev

И там переопределить конфиги и настройки

> Ведь в идеологии докера, все должно быть 1 в 1 Не, 1 в 1 полюбому не получится, ведь если например собираешь контейнеры для пхп, то там же в дев среде еще всякие xdebug, phpunit, лимиты памяти выкручены. То есть конфигурация проекта довольно сильно отличается.

Ага

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

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

Слушайте, а KVM умеет вот так взять и смигрировать VDS со стораджем в онлайн режиме? А то я нагуглить не могу - всё или libvirt предлагают, непонятно что там под капотом, или shared storage на NFS... Ещё про NDB говорится, но док найти не могу.

nbd

От, кстати, прикольный и простой

а ман что?

И какой там перфоманс? И собственно опять же - куда смотреть про лайф миграцию?

Лайв миграция хочет shared storage

Перформанс от реализации и зависит

Лайв миграция хочет shared storage

ну вот virsh --live --copy-all-storage как-то делает это без?

Перформанс от реализации и зависит

Ну так вот по NBD найти ничего не могу

libvirtd не даст миграцию без shared storage на nfs/fc...

libvirtd не даст миграцию без shared storage на nfs/fc...

Всё прекрасно мигрирует. Многие хостинги так работают. http://sappyit.blogspot.ru/2015/01/kvm-live-migration-without-shared.html

А т.е. копирование это норма? Имхо нет

А т.е. копирование это норма? Имхо нет

Всмысле?

Утра всем

Since the 1.0.3 release, libvirt is using the new NBD way of migrating non-shared storage. Previously, the storage was migrated in the same data stream as domain's RAM and qemu's internal state. This carried some notable disadvantages, e.g. under heavy workload the guest was nearly unable to migrate. For more info see Fedora Feature Page. Since the qemu 1.3.0 release, bunch of new features were added, notably NBD Storage migration. That is, qemu is able to send a disk over a stream either to local file or remote host. And this is what libvirt's adapted and refer to as NBD migration

ERROR: S client not available

Да я про это

А почему это не норма?

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

Учим приложения читать конфигурацию из consul.

Кто-нибудь пробовал размещать данные Jenkins на glusterfs? Или glusterfs до сих пор тормоз и его репликация разваливается при высокой нарузке?

Да хз. Нормальный софт сам разберется даже с сокетами, в документации systemd так и пишут при освещении параллельного старта служб. А вот для мелких поделок вполне себе дополнительный контроль и упрощение задачи обработки ошибок. Сломался? Насрать - передернут сверху. Воркеры не умеют дождаться сокета сами? Насрать - скажем когда готовы.

то есть костыли и подпорки вокруг криво написанного говнософта? ну отлично, че, мало того, что с кривым софтом будут проблемы, так еще и эти костыли с подпорками добавят радости и счастья

https://github.com/open-guides/og-aws

А как быть, если у меня конфиг nginx например разный для dev/prod. Ведь в идеологии докера, все должно быть 1 в 1? Или это не так?

https://github.com/jwilder/nginx-proxy

то есть костыли и подпорки вокруг криво написанного говнософта? ну отлично, че, мало того, что с кривым софтом будут проблемы, так еще и эти костыли с подпорками добавят радости и счастья

хуже всего, что эти костыли считаются дохуя благом и засовываются в дефолтную систему.

МНе эти команды запуска докера, напоминают команду запуска GCC компилятора.

хуже всего, что эти костыли считаются дохуя благом и засовываются в дефолтную систему.

это лютое говно и так делать плохо и только в случае тотальной жоппы

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

То теперь от тебя все это абстрагировано.

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

А потом тебе в наследство от предыдущей команды достается ферма, где из каждого сервера торчит лом, и никто не может объяснить, зачем.

Очень напоминает виндовое админство

Но без лома не работает

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

Если проблема не решается для общего случая, не надо глубоко в систему засовывать костыль, которй решает ее на 95%

Пусть это будет опциональный костыль

Opt-in, not opt-out

Чот я опять на реактивной тяге взлетаю над стулом

Пойду пожру

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

так некуда банально, остальное все вообще говно

уникернелы!

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

Я старался пиздить погроммистов а не вкручивать костыли

МНе эти команды запуска докера, напоминают команду запуска GCC компилятора.

Вот поэтому и удобно через systemd его запускать

Вот поэтому и удобно через systemd его запускать

или через docker-py ^_^

(шуткую)

первый слой https://gist.github.com/ifokeev/2238135cb78752efb5c410515894c75b второй слой https://gist.github.com/bbqtd/b47bbbc8dfd8b45407a683dba91385c9

ЧТО МНЕ ДЕЛАТЬ

образ работал и перестал работать