Здравствуйте, Vetal_ca, Вы писали:
V_>Здравствуйте, Zhendos, Вы писали:
Z>>Э... Вы же сами писали что специалистов по k8s очень сложно найти, Z>>я предположил что усложнив технологию еще получим совсем куцое количество специалистов. Z>>Неужели вы не согласны что чем сложнее какой-то предмет тем меньше количество людей Z>>в нем разбираются до конца?
V_>До совершенства в любой теме доходят единицы. Да и не всегда это нужно, если тема уходит со сцены
Совершенство тут не причем, необходим определенный уровень чтобы управлять и отлаживать систему XYZ,
и чем сложнее система тем более больше нужно знать и уметь чтобы с ней справиться.
Даже если каждая программа будет вылизана так что только 1% багов остался для вашего
варианта использования, то наличие N программ с таким охрененным уровнем крутости
уронит эти 99% глубоко вниз. Простая арифметика.
V_>Даже для такого, личного и мелкого односерверного, случая точно окупается. По отсутствию головной боли и легкости переноса/обновлению ОС
Так все эти образы нужно пересобирать при каждом выходе "security" обновлений
в дистрибутиве на котом основаны их образы, а если таких дистрибутивов несколько,
а сроки поддержки некоторых из них окончился?
И конфигурировать k8s все равно нужно, смысл его развертывать для < 10 разных контейнеров,
не проще docker compose использовать?
Здравствуйте, Cyberax, Вы писали:
C> C>>Docker работает через namespace'ы в Линуксе, с использованием cgroups для контроля ресурсов
C> S>Бро, не надо мне этих откровений, о которых в любом детском саду в курсе. А вот тебе следует знать, что в докере поверх cgroups такой очень жирный пласт очень глючного говнокода, которыей ваяли хепстеры, и который толком никто не продумывал, и который толком никто не тестировал. Загляни. Вот он и глючит. Oдин overlay, коего успели наваять уже несколько вурсий одна глучнее другой, чего стоит.
C> Нету там говнокода. Я заглядывал в runc и посылал туда патчи. Можно пример строчек, пономерно?
Здравствуйте, Zhendos, Вы писали:
Z>Здравствуйте, Vetal_ca, Вы писали:
Z>Совершенство тут не причем, необходим определенный уровень чтобы управлять и отлаживать систему XYZ, Z>и чем сложнее система тем более больше нужно знать и уметь чтобы с ней справиться. Z>Даже если каждая программа будет вылизана так что только 1% багов остался для вашего Z>варианта использования, то наличие N программ с таким охрененным уровнем крутости Z>уронит эти 99% глубоко вниз. Простая арифметика.
Что такое сложная? Набор Ansible Playbooks разной степени готовности и глючности запросто переплюнет по сложности взаимозависимостей сложность Kubernetes кластера. При гораздо более низком пороге знаний.
Растет уровень изоляции и структуризации. Image — отдельно, входные данные — отдельно, кластер оттестированный на миллионах пользователей отдельно. Многомерная задача превращается в сумму сложностей. Работает по принципу strategy pattern в программировании
Кроме того, люди по ходу крутят всякие доп-скрипты и патчи, повторяя в жалком прообразе то, что сделано гигантами индустрии. И отшлифовано миллионами пользователей-девопсов.
По факту — гораздо проще, иначе бы и не шел в данном направлении.
V_>>Даже для такого, личного и мелкого односерверного, случая точно окупается. По отсутствию головной боли и легкости переноса/обновлению ОС
Z>Так все эти образы нужно пересобирать при каждом выходе "security" обновлений Z>в дистрибутиве на котом основаны их образы, а если таких дистрибутивов несколько, Z>а сроки поддержки некоторых из них окончился?
Просмотре changelogs, в свободное время. Если ничего не бросается в глаза, то и обновлять не надо.
На практике, я не мог обновить host distro не нарушив работоспособности старой установки FreeSwitch. Теперь он полностью manageable, единственная часть в хозяйстве, перескочившая этап контейнеров.
Z>И конфигурировать k8s все равно нужно, смысл его развертывать для < 10 разных контейнеров, Z>не проще docker compose использовать?
Docker compose страшно ограничен. Кроме того, отсутствует orchestration. "Выстрелил и забыл" основанная на рудиментарной restart-policy. Не говоря уже об отсутствии startup-priority
Дальше, FreeSwitch работает в host network mode, config provisioner — в стандартном. В докере их просто так связать красиво не получится.
Конфигурирование/установка K3S это одна строчка. Не стоит обращать внимание на местных "Рабиновичей", поющих о непомерной сложности:
curl -sfL https://get.k3s.io | sh -
Точно как и на обновление. Единственное что, обновление может идти с доп компонентами, которые нужно отключить. Например, добавили свой LB вместо уже настроенного MetalLB: нужно почитать changelog
Здравствуйте, Stanislav V. Zudin, Вы писали:
SVZ>Либо выкручиваться так, чтобы ни одной dll/so в проекте не использовалось.
dll можно носить с собой, а вот so вроде нет. Но вообще, я вот не вижу ничего плохого в статической линковке, динамическая сегодня нужна в основном когда другого выхода нет.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Ops, Вы писали:
SVZ>>Либо выкручиваться так, чтобы ни одной dll/so в проекте не использовалось.
Ops>dll можно носить с собой, а вот so вроде нет. Но вообще, я вот не вижу ничего плохого в статической линковке, динамическая сегодня нужна в основном когда другого выхода нет.
Насколько я понимаю, всё дело в лицензии. Если статически линкуешь гнутую либу, то надо публиковать исходники. С коммерческим софтом это не вариант.
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, Stanislav V. Zudin, Вы писали:
SVZ>Насколько я понимаю, всё дело в лицензии. Если статически линкуешь гнутую либу, то надо публиковать исходники. С коммерческим софтом это не вариант.
Да, это вынужденная мера. Но многие либы имеют двойное лицензирование, можно и купить, коли софт коммерческий. Чем меньше зависимостей, которые могут обновляться сами по себе — тем лучше.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Ops, Вы писали:
SVZ>>Либо выкручиваться так, чтобы ни одной dll/so в проекте не использовалось. Ops>dll можно носить с собой, а вот so вроде нет.
Можно, просто мало кто так делает. Кроме того, стандартный SOPATH в Линуксе не включает текущий каталог.
Здравствуйте, mogadanez, Вы писали:
M>делают, но все это ненужные сложности которые можно решить и по другому
Куда уж проще, свалил все необходимое рядом с программой, и ни от каких капризов системы, захотевшей обновиться, не зависишь. Свое окружение как в докере, но без докера. Да, в нем изоляция и все такое, но если это не требуется, то почему нет?
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Ops, Вы писали:
C>>Можно, просто мало кто так делает. Кроме того, стандартный SOPATH в Линуксе не включает текущий каталог. Ops>Это ж не проблема вроде? Можно же запускать через env с нужным окружением? Почему тогда не делают? Это бы решило кучу проблем.
Можно, конечно. И часто так и делают для "большого" софта типа Oracle или MSSQL.
Но просто там начинаются проблемы — практически нет системных библиотек с железно стабильным ABI. Фактически, только на glibc можно рассчитывать, но там очень мало функциональности. Так что если просто положить свою libblah рядом, то она потянет свою libssl, libcurl и прочую радость.
В Windows ситуация немного лучше, благодаря магии SxS, которая автоматически заменяет вещи типа msvcrt на правильные. Вдобавок, WinApi более широкий, так что обычно требуется немного меньше библиотек.
Здравствуйте, Cyberax, Вы писали:
C>Но просто там начинаются проблемы — практически нет системных библиотек с железно стабильным ABI. Фактически, только на glibc можно рассчитывать, но там очень мало функциональности. Так что если просто положить свою libblah рядом, то она потянет свою libssl, libcurl и прочую радость.
Так в докере то же самое же, просто эти версии не рядом с программой, а в контейнере? Ну разве что собрать все вместе немного проще, и сложно пропустить, когда чего-то не хватает и тянется системная либа.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Ops, Вы писали:
C>>Но просто там начинаются проблемы — практически нет системных библиотек с железно стабильным ABI. Фактически, только на glibc можно рассчитывать, но там очень мало функциональности. Так что если просто положить свою libblah рядом, то она потянет свою libssl, libcurl и прочую радость. Ops>Так в докере то же самое же, просто эти версии не рядом с программой, а в контейнере?
Да.
Ops>Ну разве что собрать все вместе немного проще, и сложно пропустить, когда чего-то не хватает и тянется системная либа.
Именно так. Докер — просто удобный инструмент для изоляции зависимостей. Можно и без него, но зачем создавать себе лишние сложности?
Здравствуйте, Dziman, Вы писали:
s>> Это не я, это пересказываю впечатления отдела внедрения. Мне с такими субстанциями возиться по долгу службы не довелось, слава богу.
D>Полный отдел Шериданов
S>>Очень надеюсь, что в аду есть отдельный котёл для людей, который ставят в систему софт мимо манагера пакетов. C>Например, с помощью Ansible. Ага.
Нет например.
C>Hint: Docker — это менеджер пакетов.
Ну да, скриптом из цитаты устанавливается ждокер в ждокер. Угу.
Здравствуйте, Privalov, Вы писали:
P>Потому что иначе ты бы еще сказал, что программировать на управляемых языках — глупость, что умные указатели — глупость, ну и что там еще по списку.
Так уже
Здравствуйте, Ops, Вы писали:
Ops>Куда уж проще, свалил все необходимое рядом с программой, и ни от каких капризов системы, захотевшей обновиться, не зависишь. Свое окружение как в докере, но без докера. Да, в нем изоляция и все такое, но если это не требуется, то почему нет?
много кто так делает, если видишь что софт в linux ставится отдельным инсталлятором и для запуска используется shell скрипт, то это скорее всего оно
