это гугловая гадость, я не хочу его учить, и, ИМХО, он такое же зло, как и корос

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

я лучше буду делать это на питоне :)

и с опенстеком

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

Вот об этом я и говорю

Не нужно патчить

Не нужно патчить

да-да-да, и линукс ядро не нужно патчить якобы

а на самом деле нет

Ненужно

если ты не можешь сделать этого, ты не можешь решить проблему

Ненужно

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

к счастью, обычно это нужно действительно не в большинстве инсталляций

Бред

но количество гемороя не уменьшается

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

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

тоже самое и с опенстеком

Опять бред

или кубернетесом

Все наоборот

если ты хороший спец, то нужно уметь править исходники

или ты можешь работать только в эксплуатации "специалистом" по этому решению

Если ты 'спец' ты сможешь сделать тоже самое не лоча версию на свой говнопатч

Опять бред

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

и наш датабейс разработчик написал патч

когда историю коммитов посмотрел

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

Если ты 'спец' ты сможешь сделать тоже самое не лоча версию на свой говнопатч

свой патч потом нужно в апстрим толкнуть

свой патч потом нужно в апстрим толкнуть

Подход обратный должен быть

ладно, сорри, мне нужно работать :(

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

И ты мне пытаешься сказать что это ок. Я не согласен.

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

нужно решать проблемы. А патчи коммитить в апстрим

а по поводу гугла, они раньше были Don't be evil,

а теперь "Do the right thing"

Это очень важно, ИМХО

они даже не скрывают ничего

+ можно почитать разоблачения викиликса

имхо, они куда опаснее майкрософта будут, если будет монополия. Они будут токсичны для IT в целом

нужно решать проблемы. А патчи коммитить в апстрим

описанный метод решает проблему наворачиванием машинерии. и чаще всего на этом всё и останалвивается

всем привет а кто нить знает готовый модуль для оркестрации кластера консула? надо чтобы свежие 0.9 умел и шифрование с ACL. тот что на форже лежит в кластер не умеет судя по всему вообще. :(

всем привет а кто нить знает готовый модуль для оркестрации кластера консула? надо чтобы свежие 0.9 умел и шифрование с ACL. тот что на форже лежит в кластер не умеет судя по всему вообще. :(

тот что от кайла умеет в кластер

странно, ни на форже ни на гитхабе про кластер нет нифига ) но я его ковырну значит еще, спасибо.

Доброго времени. А где почитать сравнение с "фри версией" и "корпоративной"?

Хочу для себя понять разницу и сравнить с тем же Ansible.

А задача у меня: организация доставки патчей с помощью Puppet. Есть сервер "A", на котором в директории /home/updates/simpler будут лежать обновления (различные библеотеки и тд и тп). Есть сервер "B", для которого нужно доставить обновления в директорию /home/servers/неизвестнЫЕ папки/simple То есть, у нас подмножество неизвестных папок с одинаковыми файлами на сервере "B". Нужно по совпадению (или хешам или ещё как-то) с сервера "A" заменить все однотипные файлы в /home/servers/неизвестнЫЕ папки/simple на сервере "B". При этом нам известно: путь до неизвестных папок и пути после неизвестных папок. Как подобное организовать? А так же работа с обновлениями у виртуальных машин. Но тут банальщина: apt update && apt -y full-upgrade apt -y autremove

А задача у меня: организация доставки патчей с помощью Puppet. Есть сервер "A", на котором в директории /home/updates/simpler будут лежать обновления (различные библеотеки и тд и тп). Есть сервер "B", для которого нужно доставить обновления в директорию /home/servers/неизвестнЫЕ папки/simple То есть, у нас подмножество неизвестных папок с одинаковыми файлами на сервере "B". Нужно по совпадению (или хешам или ещё как-то) с сервера "A" заменить все однотипные файлы в /home/servers/неизвестнЫЕ папки/simple на сервере "B". При этом нам известно: путь до неизвестных папок и пути после неизвестных папок. Как подобное организовать? А так же работа с обновлениями у виртуальных машин. Но тут банальщина: apt update && apt -y full-upgrade apt -y autremove

фабрик

puppet и ansible для другого

для infrastructure-as-code

вот если вы не хотите руками настраивать виртуалки, и хотите, что бы они всегда были одинаковые

и процесс деплоя виртуалки можно было менять

и дальше код деплоя юзать в том же дженкинсе, то ансибл и паппет для вас

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

и питон

Спасибо за разъяснения. Что есть "фабрик"?

Спасибо за разъяснения. Что есть "фабрик"?

утилита и фреймворк для деплоя на питоне

Puppet и Ansible про другое

Они нужны, что бы настройка сервера не была ремеслом,

а стала кодингом

что бы чувак, который за это отвечает, был разработчиком, и говорил на одном языке с разработчиками

вот у вас формочки на сайте это код на js, точно так же особенности настройки крона или нгинкса в паппете это тоже код

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

что прикольно

Спасибо за разъяснения. Суть ясна.

Вредные советы какие то

Вредные советы какие то

почему?

ну, напиши свои

Вредные советы какие то

Пожалуйста, аргументируйте...

фабрик плохоподдерживаемое решение

ничем не лучше баш скрипта

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

баш сдерживает от говнокодинга? ойвей, чёт сомнительно :)

не баш сдерживает

а его ограничения

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

питон ни в чём не ограничивает

я встречаю часто такие говняки на фабрике типа... у вас есть куча тасков, есть там таск с параметрами, который в зависимости от переданных значений определяет другие параметры (аля stage \ prod) и представим что это файл на 600 строк. и по середине, _между_ двух тасок, тоесть в _main_ как бы запихано какое нибудь дефолтное поведение аля если не опредлено то вот то то.

не баш сдерживает

Ну я обобщил это всё до "баша". В итоге обычно всё скатывается до баша, вызывающего скрипт на -питоне- -ruby- etc, потому что всегда чего-то не хватает

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

и потому я за "ограниченные" среды )

сделать сложно очень просто.

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

В данном случае так и есть. Но без "лень думать".

успокаивайте себя, уху.

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

возможности это хорошо

и потому я за "ограниченные" среды )

микросервисы не панацея :)