LINUX.ORG.RU
Ответ на: комментарий от anonymous

аргументы-то ?

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

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

stevejobs
() автор топика
Последнее исправление: stevejobs (всего исправлений: 1)
Ответ на: комментарий от stevejobs

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

Rancher.

Или OpenShift. Сам по себе он для других задач, но такой функционал тоже имеется.

l0stparadise
()
Ответ на: комментарий от Deleted

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

stevejobs
() автор топика
Ответ на: комментарий от stevejobs

мдя, это теперь называется обновлять?

Deleted
()
Ответ на: комментарий от l0stparadise

docker rm && docker run?

тут только надо скопировать тонну параметров которые передавались в run предыдущий раз 8)

Deleted
()
Ответ на: комментарий от Deleted

Ну я просто приучил себя сразу писать .sh файл со всеми параметрами, чтоб не забыть :D

Кстати, у вас в haven есть инструментарий для автоматизации сего процесса?

l0stparadise
()
Ответ на: комментарий от l0stparadise

ну блин, он создавался ради этого, потому что сначала наразворачиваешь а потом ... эээ.

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

А потом оказывается, что если ты задеплоил что-то в обход композа то сам и обновляй, ну и т.п. Мы опятьже старались избежать этого - т.е. можно наш UI поставить на имеющуюся систему, она «отреверсит» исходные настройки и позволит безболезненно обновиться. А потом все также рулить через нее или руками скриптами и чем угодно если сильно хочется.

Deleted
()
Ответ на: комментарий от stevejobs

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

Стейтфул в докере? Ковырять по ссш? Ты уверен что понимаешь зачем нужен докер? Или у вас начали особо забористые вещества распылять?

anonymous
()
Ответ на: комментарий от anonymous

Стейтфул в докере?

https://hub.docker.com/_/sonarqube/
https://github.com/SonarSource/docker-sonarqube/issues/63
как насчёт «плагины пряма в контейнер ставятся»? — это стейтлесс?

Ты уверен что понимаешь зачем нужен докер?

ты уверен, что вообще хоть кто-то понимает зачем нужен докер, если такое сплошь и рядом?
я лично глубоко уверен, что он в принципе нужен ради того, чтобы сказать: он ненужен, сделайте нормально

system-root
()
Ответ на: комментарий от system-root

ты уверен, что вообще хоть кто-то понимает зачем нужен докер, если такое сплошь и рядом?
я лично глубоко уверен, что он в принципе нужен ради того, чтобы сказать: он ненужен, сделайте нормально

глядя вокруг себя, склонен согласится с твоим мнением

anonymous
()
Ответ на: комментарий от system-root

он ненужен, сделайте нормально

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

Deleted
()
Ответ на: комментарий от Deleted

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

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

anonymous
()
Ответ на: комментарий от anonymous

Ну стиви просто потеряет стейт при обновлении контейнера. Если не будет обновлять - то ничего не потеряет, все также как с обычной виртуалкой (просто виртуалки обычно не обновляют накатывая образ).

Deleted
()
Ответ на: комментарий от Deleted

Ну стиви просто потеряет стейт при обновлении контейнера.

Он там выше уже написал, что подразумевает что-то свое под обновлением контейнера. Судя по описанию и софт внутри контейнера он обновляет как в виртуалке, но тогда в чем профит докера относительно kvm/xen/etc для которых это нормальный режим использования?

anonymous
()
Ответ на: комментарий от anonymous

в том что докер - не виртуалка, и нет накладных расходов на виртуализацию

ну и что если покурить документацию то можно лазить в шелл без ssh, а простым `docker exec -ti /bin/bash`

Deleted
()
Ответ на: комментарий от Deleted

в том что докер - не виртуалка, и нет накладных расходов на виртуализацию

тут он не лучше lxc, а, возможно, и хуже в контексте управления ресурсами

ну и что если покурить документацию то можно лазить в шелл без ssh, а простым `docker exec -ti /bin/bash`

локально - да, по сети - нет

anonymous
()

кубернетес? Или тебе без оркестрации?

leave 👍
()
Ответ на: комментарий от anonymous

тут он не лучше chroot, а, возможно, и хуже в контексте управления ресурсами

пофиксил во имя примитивизма

по сети - нет

`docker -H IP:PORT exec -ti container_name /bin/sh`

8)

Deleted
()
Ответ на: комментарий от Deleted

пофиксил во имя примитивизма

хороший, годный фикс :)

`docker -H IP:PORT exec -ti container_name /bin/sh`

А за это спасибо, не обращал внимания на эту опцию докера

anonymous
()
Ответ на: комментарий от Deleted

что тут не нормального?

откровенно говоря, в докере много чего не нормального
у меня нет списка «как сделать лучше», только список уродств в дизайне, которые вынудили меня снести к чёрту всё это непотребство и использовать jails
но уверен, нынешние хипстеры, повзрослев, сделают нормально. главное, чтобы убирая одни костыли, они не придумали новых

system-root
()
Последнее исправление: system-root (всего исправлений: 1)
Ответ на: комментарий от Deleted

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

плюс В РЕАЛЬНОСТИ настроенный скриптами либо по инструкции сервер почти никогда не работает, и нужен разработчик, чтобы с горящей жопой залететь в инстанс и понять, что в очередной раз отвалилось (и не всегда это решается интерактивной отладкой! Особенно когда там внутри не правоверная джава, а какое-нибудь goвно бай дизайн не имеющее нормального отладчика)

так что SSH просто небоходимая фича

хотя кому я рассказываю, ты и так всё это знаешь

stevejobs
() автор топика
Последнее исправление: stevejobs (всего исправлений: 4)
Ответ на: комментарий от stevejobs

так что SSH просто небоходимая фича
хотя кому я рассказываю, ты и так всё это знаешь

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

Deleted
()
Ответ на: комментарий от stevejobs

запущенные инстансы надо еще настраивать энсиблом, и настраивать вообще

Вам однозначно нужен не докер

Например, если к нам пришла слишком большая для железа нагрузка, надо динамически выделить на облаке еще несколько виртуалок и перефигачить конфиги nginxов итп, и не рестартом а релоадом

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

плюс В РЕАЛЬНОСТИ настроенный скриптами либо по инструкции сервер почти никогда не работает, и нужен разработчик, чтобы с горящей жопой залететь в инстанс и понять, что в очередной раз отвалилось (и не всегда это решается интерактивной отладкой! Особенно когда там внутри не правоверная джава, а какое-нибудь goвно бай дизайн не имеющее нормального отладчика)

решается проверкой и пересборкой образа до деплоя

так что SSH просто небоходимая фича
хотя кому я рассказываю, ты и так всё это знаешь

тут с белкой согласен, не нужен там ссш

anonymous
()
Ответ на: комментарий от anonymous

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

можно - но сейчас не так, и специально под тебя софт никто переписывать не станет

решается проверкой и пересборкой образа до деплоя

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

stevejobs
() автор топика

Поставь ранчер и успокойся

anonymous
()
Ответ на: комментарий от stevejobs

можно - но сейчас не так, и специально под тебя софт никто переписывать не станет

монтируешь volume с конфигом и все

Deleted
()
Ответ на: комментарий от stevejobs

можно - но сейчас не так, и специально под тебя софт никто переписывать не станет

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

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

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

ЗЫ Ты вроде всегда стремился делать все более-менее нормально. Чего сейчас с изолентой на перевес закатываешь солнце вручную?

anonymous
()
Ответ на: комментарий от anonymous

потому что сейчас у меня кроме основной работы есть еще пет проект, связанный с гальванизацией трупа легаси писанного десятками лет толпой индусов, а в этом пет проекте участвует всего 3 человека (один из которых жс-фронт, а второй - вообще аналитик). С такими ресурсами нет никакого шанса сделать это правильно, можно только поднять эту систему, чтобы стояло вертикально и не заваливалось от ветерка. С другой стороны, бабла чтобы запихать это в настоящие виртуалки тоже нет.

но есть и радостный момент. Настоящие шедевры рождаются именно при наличии жестких ограничений на художника! :3

stevejobs
() автор топика
Ответ на: комментарий от anonymous

Ну теоретически можно docker commit'ом баловаться. Только не нужно.

unikoid
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.