есть тот же k8s зачем самому его писать и собирать грабли

если кластер - то да, лучше что-то такое ставить

если одиночный сервер - свой костыль будет проще поддерживать

свой костыль всегда сложней поддерживать

если одиночный сервер - свой костыль будет проще поддерживать

нет

свой костыль всегда сложней поддерживать

чужой сложней

ну да чужой сложней а чужой еще и индуский вообще ад

а вообще есть готовые инструменты пользуйтесь

ну да чужой сложней а чужой еще и индуский вообще ад

поэтому делают свои)

k8s и mesos - это клёвые вещи, я очень за, но если нужно просто (пере)запустить службы на 1 сервере - разве не будет оверхёдом ставить всё это на одиночный сервер?

своё решение, генерирующее .service-файлы напитонить довольно просто

когда у тебя 2 контейнера тогда и любой инит скрипт, а когда уже 3 и больше то надо делать нормально

это будет небольшой скрипт в пределах 100 строк

если у нас одиночный сервер, мы хотим BGD, тогда каким-то образом (например, через консоль или боту в телеграмме или HipChat'е) мы посылаем команду upgrade 1.2.3 (номер версии) скрипту , он делает следующее: берёт шаблоны Postgres, Nginx, uWSGI для service-файлов контейнеров (допустим, у нас три контейнера - база, основной код и статика/медиа + какой-нибудь прокси, который нужен ичключительно для переключения трафика для BGD), подставляет туда этот номер версии 1.2.3 (допустим, там есть слово VERSION везде в командах и он его заменяет вот этот 1.2.3) копирует их в /etc/systemd/system/ делает systemctl daemon-reload делает systemctl enable ... для каждого service-файла делает systemctl start ...-1.2.3 - это поднимает контейнеры далее патчит upstream на балансировщике и делает его reload (допустим, там nginx), в итоге трафик перестаёт идти на старые контейнеры, и идёт на новые останавливаем старые контейнеры, удаляем старые service-файлы вот и весь скрипт в а .service-файлах у нас пулл, стоп, рм, старт контейнера (не важно, что там - Rkt/Docker/что-то ещё)

мне кажется, написать этот скрипт проще, чем что-то внедрять

а, да, кроме версии надо передавать ещё идентификатор проекта, если проектов тут на сервере больше 1

ну да написать свой клон ansible проще )) чем с полпинка 1й командой поставить k8s которые делает это да еще и граничные условия ради тебя учли и соломки подложиди

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

просто если задача элементарная - проще самому 100 строчек написать, чем разбираться в чужом коде

в сложных случаях, конечно, стоит ставить те системы

попробуй потом говори что придеться.. интеграции с чатами это вот самое ненужное что есть

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

ну это такой довольно классический спор о том, что проще - конфигурировать что-то или программировать

впрочем, k8s - хорошая система и она мне нравится, когда-нибудь с ней тоже разберусь)

к слову, всё ещё больше упрощается, если BGD не нужен - тогда .service файлы делаются 1 раз и обновление проекта происходит куда проще

а в случае, когда мы хотим не использовать systemd вообще, видимо, придётся или где-то в Evernote'е хранить эти команды со всеми параметрами и копипастить оттуда или делать alias в /root/.bashrc

ну, думаю, вы согласитесь, что если у нас там какой-нибудь сайт-визитка чебуречной - BGD не нужен

Зачем вообще тогда разговаривать о сайтах визитках, там ничего ненужно

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

Слушайте, а можно примаунтить контейнер собранный как вольюм для другого контейнера ?

volumes_from ?

Суть такая, что есть публичный имидж, он довольно толстый и сложный, поэтому тащить на саппорт его не хочется. Там внутри лежит код на питоне, и этому коду можно через envvar указать нечто вроде "Additional_libraray_path". Так вот, эти либы хочется собирать и таскать в отдельном конейтенере.

Вольюмс фром вроде как примаунтит теже тома, что примаунчены к другому контейнеру, нет ?

нет

оно примаунтит тома того контенера

ну да, но само содержимое контейнера же я не смогу увидеть.

сможешь, для этого и нужен volumes_from

иначе зачем он вообще

volumes_from как раз оно.

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

тоесть смысловая нагрузка опции volumes_from вроде как "том сделанный из имиджа" а не "тома вытащенные из имиджа"ю

как раз тома вытащенные из имиджа

просто в дата контейнере тебе надо объвить директорию с нужными тебе данными как volume

и у тя получается аццкая конструкция которая работает как раз как тебе надо

Зачем вообще тогда разговаривать о сайтах визитках, там ничего ненужно

ну, вот в качестве апгрейда сервера для шареда на докер

допустим, условно, есть у вас веб-студия с manаged-shared'ом, надо же как-то от shared'а вперёд двигаться

просто в дата контейнере тебе надо объвить директорию с нужными тебе данными как volume

и как это делается ? )

в Dockerfile сделать директиву VOLUME

и всё

ну и указать на нужную тебе директорию конечно

в Dockerfile сделать директиву VOLUME

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

Вряд ли конечно.. volume именован и привязан к конкретному контейнеру

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

я хз.

но кейс интересный

а если там открытые файлы ?

а если на запись ?

Ну я поразмыслил и решил что нет.. темболее открытые файлы

На самом деле довод о том что у волума есть имя и связь абсолютно убедителен

я так себе делал. у меня php-fpm был одним контерфенром а код другим

но монтировал я его на ro

и перезапускал пачкой

я так себе делал. у меня php-fpm был одним контерфенром а код другим

Мне примерно так же нужно, что бы еще те же данные в nginx были на случай внезапной статики

ага да

Но я спроектировал с полным перезапуском и переключением через haproxy

Потому как переливать файлы налету вообще не есть правильно

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

парни, а кто нибудь использовал это - www.weave.works ??? в связке swarm + compose ?

ERROR: S client not available

парни, а кто нибудь использовал это - www.weave.works ??? в связке swarm + compose ?

зачем ? оно поверх libpcap. скорость сети по тестам что то типа 21мегабит

где? ткните пальцем

про 21 мегабит

зачем ? оно поверх libpcap. скорость сети по тестам что то типа 21мегабит

? зачем поверх pcap это делать?

? зачем поверх pcap это делать?

потому что могут

где? ткните пальцем

тесты легко ищутся.

парни, а кто нибудь использовал это - www.weave.works ??? в связке swarm + compose ?

чому не оверлей?

а overlay как на 1 гигабите например, сколько выжать можно будет?

980

откуда такие цифры?

с моей инсталяции

с двух точнее

с моей инсталяции

а чего на шлюзе и как шлюзуешь ?

докером ?

overlay - это внутри сети

Да там ходить далеко не надо, там вся сеть на цпу работает

получается, самое быстрое и чтобы не ело cpu - это бридж на хост машине ?

логично, как по мне

--net=host

--net=host

не всегда это стоит делать, насколько я заметил

Это быстрее всего

overlay - это внутри сети

оверлей все равно надо шлюзовать

Это докером, да

кто то же должен снять udp

ага

overlay - это внутри сети

Да ладно, как ты столько 980 выжал? Небось цпу половина на это расходуется

тоесть ядром по факту

Да ладно, как ты столько 980 выжал? Небось цпу половина на это расходуется

так же думаю

либо сетевуха умеет офлоад

Да ладно, как ты столько 980 выжал? Небось цпу половина на это расходуется

ну сейчас проверю

но я таких не видел

просто вопрос, разворачивать прод,как там с сетью, на которой нагрузка может быть по 300-500 мегабит. сможем ли такой трафик доставить в контейнеры...