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 ★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.