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

Но уже не в первый раз сталкиваюсь с тем, что практика показывает обратное.

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

Так уж получилось, что мне пришлось разобраться с кубернетесом. И знаете что? Это штука, сделанная правильными инженерами правильно. В нём нет никаких недостатков. У него документации уйма. Он легко ставится — одной командой. Для него куча качественного тулинга. Я искренне жалею, что не познакомился с ним раньше. Да, штука решает много проблем, для этого вводит много концепций, с которыми надо ознакомиться прежде, чем использовать его по-полной. Хотя начать можно и нужно с малого. И в этом нет никаких проблем. Нет ничего сложного в том, чтобы написать ямл для сервиса, это не сложней написания куска докер-композа. Зато оно работает, как говорится, рок солид. И у него есть ответы на все потребности, которые когда-либо могут возникнуть.

И я осознал, что всё нытьё от тех, кто не хочет сесть и потратить сто часов на вдумчивое чтение документации. Которая доступна. А тех, кто таки сел и потратил эти жалкие сто часов, минусуют и считают маргиналами. Вот такая вот штука.

Теперь придётся ещё в интернете учиться отличать фриков от не-нубов. Беда.

Здравствуйте, vsb, Вы писали:

vsb>Теперь придётся ещё в интернете учиться отличать фриков от не-нубов. Беда.

А также тех, кто сидел с ним слишком мало, от тех, кто сидел на нём слишком много. Кубер — штука хорошая, но на практике его используют как фиговый листик, прикрывающий неспособность IT построить хорошую экосистему.
Например, автоматическое планирование ресурсов подов выливается в неадекватные (в обе стороны) лимиты и неустойчивость системы в целом, авторестарт подов — в нежелание чинить проблемы в приложениях, ингресс — в нежелание повышать качество балансировки, легкость масштабирования кластера — в нежелание делать нагрузочные тесты и понимать ньюансы работы приложения под нагрузкой.

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

Здравствуйте, vsb, Вы писали:

UPD: знал бы я, что за "утилиту" ты взял, чтобы здесь понтоваться, не стал бы столько писать. Я откровенно вообще не понял, ДЛЯ КОГО ты тут пишешь! Мы тут программисты, родной — нам твои кубернетесы — до лампочки, это вообще работа девопсов и администраторов! Причём РАЗОВАЯ работа для чела, специализирующегося именно на сложной инфраструктуре под десятки контейнеров. Тут и трёх человек не наберётся для таких задач! Тут контейнеры-то не все используют, а ты про целый оркестр контейнеров.
Кстати, там действительно ничего сложного — тупо терминология и архитектура. Нужная 0.000001% проектов.

Здравствуйте, vsb, Вы писали:

vsb>Я не знаю, почему ты считаешь vim черезжопным.
Да потому что он черезжопный.
Редактор, в котором невозможно ничего сходу сделать без мануала.

Здравствуйте, vsb, Вы писали:

https://www.youtube.com/watch?v=9wvEwPLcLcA

Здравствуйте, ути-пути, Вы писали:

K>>>Нет такой программы, где прям нужно читать талмуды доков для простых действий. Даже фотошоп дети осваивают на интуиции!! Хотя казалось бы, тоже навороченная программа.

vsb>>Полно таких программ. Как насчёт вима? Емакса?

УП>Такое говно не нужно. Есть куда более удобные редакторы и IDE, которые можно начать использовать сходу, вообще ничего о них не зная.

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

УП>Их ниши: а) админка систем, где ничего другого нет

ssh, да, тоже маст хэв.

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

Здравствуйте, vsb, Вы писали:

vsb>Пока ты свой удобный редактор запустишь, я уже отредактирую в виме что мне надо.

Ну блин, есть же нечерезжопные консольные редакторы, mcedit или хотя бы nano.

Здравствуйте, vsb, Вы писали:

vsb>А я вообще не вижу смысл не применять кубер. Ну разве что жалко денег на control plane, он таки жручий, да, гигабайт памяти отъедает влёгкую. Если весь проект на текущем этапе умещается в этот самый гигабайт, то да, кубер пока не нужен, хватит докера. Как только проект стал жрать больше гигабайта, лично я теперь буду заменять докер на полноценный кубернетес, пусть и с одной нодой, совмещённой с мастером и томами на локальном диске. Это в любом случае не хуже докера. Но позволит органично расти.

Вы почему-то сравниваете кубер с железным сервером, а надо бы — с VPS в облаке. Моя мысль в том, что для небольших команд разработчиков кубер мало что добавляет к классическому "крутим приложение в докере на VPS, деплоим ансиблом".

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

vsb>Так уж получилось, что мне пришлось разобраться с кубернетесом. И знаете что? Это штука, сделанная правильными инженерами правильно. В нём нет никаких недостатков.

Если это сарказм — то — зачет, отличный троллинг.

Ну а если всерьез, то таки снова попрошу администрацию вдогонку к "-1" добавить оценку "facepalm"

Здравствуйте, vsb, Вы писали:

K>>Нет такой программы, где прям нужно читать талмуды доков для простых действий. Даже фотошоп дети осваивают на интуиции!! Хотя казалось бы, тоже навороченная программа.

vsb>Полно таких программ. Как насчёт вима? Емакса?

Такое говно не нужно. Есть куда более удобные редакторы и IDE, которые можно начать использовать сходу, вообще ничего о них не зная.
Их ниши: а) админка систем, где ничего другого нет и б) раздувание ЧСВ у красноглазиков.

Здравствуйте, student__, Вы писали:

vsb>>Раньше я привык к тому, что если в интернете техническое мнение грубо говоря заплюсовано, то скорей всего оно более-менее правильно.

__>видел пару опровержений на SO, когда неверный ответ принят автором вопроса

Обычно в таких случаях правильный заплюсован.

Здравствуйте, scf, Вы писали:

scf>А также тех, кто сидел с ним слишком мало, от тех, кто сидел на нём слишком много. Кубер — штука хорошая, но на практике его используют как фиговый листик, прикрывающий неспособность IT построить хорошую экосистему.
scf>Например, автоматическое планирование ресурсов подов выливается в неадекватные (в обе стороны) лимиты и неустойчивость системы в целом

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

> авторестарт подов — в нежелание чинить проблемы в приложениях

Авторестарт есть всегда. Будь то systemd или start.sh. Проблемы в приложениях есть всегда и авторестарт прикручивают в первую же ночь субботы, когда тебя сняли с тёплой жены.

> ингресс — в нежелание повышать качество балансировки

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

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

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

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

А я вообще не вижу смысл не применять кубер. Ну разве что жалко денег на control plane, он таки жручий, да, гигабайт памяти отъедает влёгкую. Если весь проект на текущем этапе умещается в этот самый гигабайт, то да, кубер пока не нужен, хватит докера. Как только проект стал жрать больше гигабайта, лично я теперь буду заменять докер на полноценный кубернетес, пусть и с одной нодой, совмещённой с мастером и томами на локальном диске. Это в любом случае не хуже докера. Но позволит органично расти.

Здравствуйте, Kolesiki, Вы писали:

vsb>>Раньше я привык к тому, что если в интернете техническое мнение грубо говоря заплюсовано, то скорей всего оно более-менее правильно.

K>ИТ — очень специфическая отрасль, где даже миллионы мух могут ошибаться (посмотри на лопухов, ставящих себе Win10). Но бывает и как в жизни: большинство право. Так что ты ещё не достиг настоящего дзена.

Ну я же не утверждаю, что большинство всегда право. Я утверждаю, что всё стало сложно.

K>Может так и есть — я его даже в глаза не видел. Но если чел преодолел лень и даже написал в сети, что это "Сложнаааа!" (ц) Карина ... то вполне естественно полагать, что эта штука сложная для освоения "с наскока".

Ну да. Программирование тоже сложное для освоения с наскока. Много чего сложное для освоения с наскока. Не надо наскакивать на всё подряд. Иногда надо остановиться и вдумчиво покурить.

K>Банальный пример — Haskel. Те, кто его освоил, как долбаные веганы МИНУТЫ не усидят, чтобы не похвалиться, какие они умные, а все дураки пишут на "жавах". Кстати, ты тоже из них. Но Хасекль ОБЪЕКТИВНО сложный! Уверен, практически каждый, кто слышал про Хаскель, непременно его попробовал. И много на нём осталось?? Полтора инвалида, да и те ради хобби.

Я тоже хаскель пробовал. И своё мнение про хаскель основываю пусть и на небольшом, но опыте. Хотя, честно говоря, мнения про хаскель у меня нет. Ему просто в моей жизни нет места, работать на нём негде, фо-фан тоже как-то желания писать не возникает. Поэтому то такое. Я однозначно уверен, что хаскель не даст ничего особенного. Может быть он чуток лучше жавы, будет меньше багов, будет быстрей скорость разработки при большом опыте. Это всё ерунда. Если бы я жил в окружении, где есть программисты на хаскеле и есть работа на хаскеле, может он и был бы интересен.

vsb>> Это штука, сделанная правильными инженерами правильно

K>Никто ж не против! Может и правильно. Но мало ВНУТРИ сделать правильно — надо не быть тупорылым занудой и сделать адекватный ИНТЕРФЕЙС, чтобы вся ненужная сложность "ушла" унутря. Этим ещё линуксоиды страдают: напишут какое-то консольное г****но, прикрутят к нему конфиг из иероглифов и кидают в толпу: на те вам плод моего гения! (см. sendmail) Ну и кому оно надо, если как ты пишешь, надо "потратить сто часов на вдумчивое чтение документации"?? Да в том и дело, что для тех функций, что делает любая перделка, 90% технического шлака запросто можно убрать в дефолты и не парить мозг!

В кубернетесе нормальный интерфейс. Что самое крутое — он унифицированный. Один раз понимаешь концепцию и потом тебе всё конфигурируется однотипно.

Ну ямлы их слегка перегружены деталями, ок. Тут дело не в дефолтах, дефолты там везде есть, где они имеют смысл. Скорей дело в том, что, например, можно было бы сделать name: "somens:somename" а они разнесли это в 2 атрибута — "namespace": "somens", "name": "somename". И так во многих местах — для машинночитаемости принесли в жертву человекочитаемость. Но в целом это мелочи и ерунда, копипаст и автодополнение всякой скучной ерунды никто не отменял и время это особо не отнимает.

vsb>>И я осознал, что всё нытьё от тех, кто не хочет сесть и потратить сто часов на вдумчивое чтение документации

K>гыгыгыг Родной, я винду первый раз в жизни поставил, не поверишь, ПО ИНТУИЦИИ! Ну вот просто вставил диск, клик-клик, стоит венда! А если б для неё надо было тратить 100 часов... это говно никогда б не попало на десктопы! (см. OS/2)

А я на линукс потратил куда больше, чем 100 часов. И сейчас иногда трачу.

Если говорить про винду, я вот умею писать батники. И там как бы тоже нифига не интуитивно и это мягко говоря. Повершелл не интуитивен. Это всё инструменты, даже не программиста, а просто продвинутого юзера.

K>Нет такой программы, где прям нужно читать талмуды доков для простых действий. Даже фотошоп дети осваивают на интуиции!! Хотя казалось бы, тоже навороченная программа.

Полно таких программ. Как насчёт вима? Емакса?

vsb>>Теперь придётся ещё в интернете учиться отличать фриков от не-нубов. Беда.

K>А сам-то ты кто?

На словах я Лев Толстой. Про дела не будем.

> Жалуешься на "анти-читателей-доков", а сам даже не можешь понять простую человеческую суть — лень. Более того — не только лень, а даже банальное отсутствие времени — не каждый может просрать 100 часов только на то, чтобы какая-то вспомогательная перделка вертелась там в бэкграунде. Ну и как я сказал, ИНТЕРФЕЙС — если ты его сделал на отъ___ись, так не удивляйся тухлым помидорам в ответ! ХОРОШИЕ программы ругать не станут.

Дело в том, что некоторые программы фундаментальны и требуют времени на обучение и освоение. Если тебе хочется примера не из программирования — я как раз этим летом осваивал 3D-моделирование на Fusion 360. И времени я, конечно, не 100 часов потратил, но часов 15-20 на ютубе я точно потратил. И при этом я этот пакет знаю очень слабо, по сути самые вершки ухватил. Я, кстати, пытался с налёту наскочить, тыкал по менюшкам и кнопочкам. Ну может быть там UI не слишком интуитивен, но я потерпел полный крах. А так — подучил и в целом свои небольшие задачи выполняю, какие-то модели строю и даже на мой вкус вполне себе интересные.

K>Не самый идеальный, но вот пример студии: запускаешь сетап, выбираешь ОДИН чекбокс "desktop development" и "Next" — всё, тебе на диск ставится целая охренительная IDE!! Вот смогли же сделать просто? Почему тяп-ляпычи кубернетеса не смогли? Или они только кульхацкеров могут изображать? Вот это и есть отличие профи от дилетантов: профи пишет программу для людей, дилетанты — для чесания своего тщеславия.

В кубе ещё проще. Пишешь kubeadm init и всё. Куда уж проще. Никаких сетапов, никаких галочек.

Продолжу оффтопом, всё равно болтаем

Здравствуйте, vsb, Вы писали:

K>>Нет такой программы, где прям нужно читать талмуды доков для простых действий. Даже фотошоп дети осваивают на интуиции!! Хотя казалось бы, тоже навороченная программа.

vsb>Полно таких программ. Как насчёт вима? Емакса?

Вим — это вирус, который "только бибикает и портит текст". И из которого практически невозможно выйти, если не знать спец.код.
Емакс — тоже такое себе поделие... Емакс — это всё, что угодно, кроме редактора. Не удивительно, что это Г никто не использует.

vsb>Дело в том, что некоторые программы фундаментальны и требуют времени на обучение и освоение

Касательно кубернетеса — абсолютно солидарен. Но я 100% уверен, те, кто его пытались освоить, тоже не "методом тыка" его ставили! К нему вообще не подступиться, если не читал азов и конкретных примеров сетапа.
Но я вот прочитал пяток статей и прямо скажу: эти статьи как обучающий материал — полное говно. Это как с физикой: чтобы объяснить атомную структуру, надо сначала знать атомную структуру. Чтобы понять "умную белиберду", написаную про кубер, надо сначала полностью знать кубер. Я в плане софта много чего знаю, но я 100% не смогу ничего настроить, даже если прочту все их пляски со стручками и сервисами. Если люди не понимают кубер, значит тот, кто про него пишет, сам его не понимает и не умеет объяснять. Так что я солидарен с теми, кому "сложна" — они тыкаются в уйму терминов, но не понимают, что и зачем существует.
Думаю, обучалкам (скорее всего скопипижженым друг с друга) нехватает грамотного кубер-гуру и реальных примеров из "простой среды" — вот они могли бы в терминах, понимаемых учениками, объяснить, что и зачем существует в этом "гиперкластере".

Здравствуйте, vsb, Вы писали:

vsb>...В нём нет никаких недостатков.
vsb>...И у него есть ответы на все потребности, которые когда-либо могут возникнуть.
Вроде бы мода на веру в серебрянные пули в IT прошла лет 30 назад?

Здравствуйте, Kolesiki, Вы писали:

K>Касательно кубернетеса — абсолютно солидарен. Но я 100% уверен, те, кто его пытались освоить, тоже не "методом тыка" его ставили!

В современном docker desktop он ставится нажатием на ровно одну галочку. А в облаках есть решения типа AKS, которые тоже для старта не требуют прохождения курсов.

Здравствуйте, scf, Вы писали:


scf>Вы почему-то сравниваете кубер с железным сервером, а надо бы — с VPS в облаке. Моя мысль в том, что для небольших команд разработчиков кубер мало что добавляет к классическому "крутим приложение в докере на VPS, деплоим ансиблом".

В докере рудиментарная политика перезагрузок. Если надо определенная последовательность загрузки, то тут не работает.

Потом, "ввернутая сеть", вместо вывернутой наружу

Только одно это уже не подошло для моего даже домашнего использования.

Вот случись что, контейнер лег а я на велосипеде вокруг озера. Кто рестартовать будет?

У меня есть поды, проверил, 2y132d. Работают сами, 15 рестартов за эти годы, ноль моего вмешательства.

Опять же, поставить какую программу... вот, последнее NextCloud. One liner. Попробовал, поставил, удалил, потом, передумал, опять поставил

Это для дома, тут все супер.


Проблемы у малых и средних компаний, когда пытаются все сами. И программу, и logging и APM и чтобы все по SOC2. Вот тут, проблемы. Тут тупо не хватает сил у людей, обманутых кажущейся простотой. Для того же APM нужен отдельный человек или комманда, а, лучше, внешнее решение. С докером, IMHO, еще кустарнее и сложнее. И самоделкину кустарщину потом тяжело поддерживать

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

Здравствуйте, scf, Вы писали:

vsb>>Пока ты свой удобный редактор запустишь, я уже отредактирую в виме что мне надо.

scf>Ну блин, есть же нечерезжопные консольные редакторы, mcedit или хотя бы nano.

mcedit надо ставить (про него ничего не знаю), систем без vim я пока не встречал. nano ужасен. Вообще консольные редакторы без поддержки мыши не могут тягаться с vim-ом. Слишком быстро управляется курсор в vim. Если есть мышка — ок, там скролл покрутил, тыкнул куда надо, это частично компенсирует убогость редактора, но в консоли обычно мышка в редакторах не работает (а там, где работает, там она и в vim работает).

Я не знаю, почему ты считаешь vim черезжопным. Как раз потому, что тебе лень потратить полчаса на vimtutor, после которого и небольшой практики он уже станет удобней nano?

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

Здравствуйте, vsb, Вы писали:

vsb>И я осознал, что всё нытьё от тех, кто не хочет сесть и потратить сто часов на вдумчивое чтение документации.

По моему, ты сейчас только что ныл.

Здравствуйте, vsb, Вы писали:

vsb> mcedit надо ставить (про него ничего не знаю), систем без vim я пока не встречал.

Позанудствую немного — vim тоже надо ставить, он (в отличии от vi) не является стандартным в POSIX.

Здравствуйте, vsb, Вы писали:

vsb>Раньше я привык к тому, что если в интернете техническое мнение грубо говоря заплюсовано, то скорей всего оно более-менее правильно.

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

Здравствуйте, Vetal_ca, Вы писали:

V_>https://www.youtube.com/watch?v=9wvEwPLcLcA

А почему он говорит, что первая версия кубернетеса не использовала го? Посмотрел первый коммит — вроде го. Или он про прародителей вроде borg?

Здравствуйте, vsb, Вы писали:

vsb>А почему он говорит, что первая версия кубернетеса не использовала го? Посмотрел первый коммит — вроде го. Или он про прародителей вроде borg?

Я не в курсе.

Но субж намного глубже чем изначально кажется.

Здравствуйте, vsb, Вы писали:

vsb>И я осознал, что всё нытьё от тех, кто не хочет сесть и потратить сто часов на вдумчивое чтение документации. Которая доступна. А тех, кто таки сел и потратил эти жалкие сто часов, минусуют и считают маргиналами. Вот такая вот штука.

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

Скажем, докер требует всего ничего — иметь минимальное представление о том, как работает компьютер, сеть, операционка, что имеем искаропки у студента второго курса, и небольшое время на практику — docker run, docker-compose up, написать несколько Dockerfile, объединить их docker-compose.yaml

Здравствуйте, Pauel, Вы писали:

P>Скажем, докер требует всего ничего — иметь минимальное представление о том, как работает компьютер, сеть, операционка, что имеем искаропки у студента второго курса, и небольшое время на практику — docker run, docker-compose up, написать несколько Dockerfile, объединить их docker-compose.yaml

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

После этого приходит понимание, зачем нужен Kubernetes.

Тут спор не про Docker против Kubernetes. А Kubernetes против Serverless

Здравствуйте, Vetal_ca, Вы писали:

V_>Потом начинается написание собственных оркестраторов, разной степени костыльности.

А если не начинается?

Здравствуйте, Pauel, Вы писали:

P>А если не начинается?

Да, для дома можно ограничится отдельными контейнерами. И для тривиальных случаев, тоже, особенно если есть человек, который может в случае чего зайти и перегрузить с docker (re)start

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

Здравствуйте, Kolesiki, Вы писали:

K>Но я вот прочитал пяток статей и прямо скажу: эти статьи как обучающий материал — полное говно.
Так можно сказать про 95% статей.

Здравствуйте, Vetal_ca, Вы писали:

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

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

Здравствуйте, vsb, Вы писали:

Может, он хороший и удобный, но пусть его настраивают сисадмины. Программист знать докеры и куберы не обязан.

Здравствуйте, Worminator X, Вы писали:

WX>Может, он хороший и удобный, но пусть его настраивают сисадмины. Программист знать докеры и куберы не обязан.

А что программист знать обязан?

Здравствуйте, vsb, Вы писали:

vsb>А что программист знать обязан?
Помимо программирования?
Ну, например то, как правильно установить и настроить его приложение, какими сервисами его обложить и как лучше эти сервисы настроить.
Мы то, админодевопсы, конечно помесь псайкеров с механикусами но всему же предел есть.

Здравствуйте, Sheridan, Вы писали:

vsb>>А что программист знать обязан?
S>Помимо программирования?
S>Ну, например то, как правильно установить и настроить его приложение, какими сервисами его обложить и как лучше эти сервисы настроить.
S>Мы то, админодевопсы, конечно помесь псайкеров с механикусами но всему же предел есть.

Ну вот описание «как правильно установить и настроить приложение, какими сервисам его отложить» формально специфицируется в куб манифестах. Можно, конечно, выразительно это все объяснять и руками при этом махать. Или в ридми расписать на литературном русском или английском. Но вроде программисты должны любить формальные языки.

И в этом, я считаю, важный плюс докера и куба. Он даёт общий язык для общения между админом и программистом.

Как лучше эти сервисы настроить это уже к админам. Откуда программисту знать, как лучше настроить постгрес. Это уже точно за пределами его компетенций.

Здравствуйте, vsb, Вы писали:

vsb>>>А что программист знать обязан?
S>>Помимо программирования?
S>>Ну, например то, как правильно установить и настроить его приложение, какими сервисами его обложить и как лучше эти сервисы настроить.
S>>Мы то, админодевопсы, конечно помесь псайкеров с механикусами но всему же предел есть.

vsb>Ну вот описание «как правильно установить и настроить приложение, какими сервисам его отложить» формально специфицируется в куб манифестах. Можно, конечно, выразительно это все объяснять и руками при этом махать. Или в ридми расписать на литературном русском или английском. Но вроде программисты должны любить формальные языки.
Уж лучше на ансибле если уж так. Но текстом в реадми ещё лучше. Потому что одни захотят в кубы, вторые сразу на железо. К тому же при описании контейнеров многое теряется. Например, рассовывание файликов проекта по папкам с выставлением нужных прав.

vsb>И в этом, я считаю, важный плюс докера и куба. Он даёт общий язык для общения между админом и программистом.
Он даёт общай язык для общения между куберфилом и куберфилом. В итоге никто из них не понимает как поднять проект без контейнеров.

vsb>Как лучше эти сервисы настроить это уже к админам. Откуда программисту знать, как лучше настроить постгрес. Это уже точно за пределами его компетенций.
Он должен знать как приемлемо для его приложения настроить постгрес. А девопс уже дальше должен копнуть.

Здравствуйте, Sheridan, Вы писали:

vsb>>Ну вот описание «как правильно установить и настроить приложение, какими сервисам его отложить» формально специфицируется в куб манифестах. Можно, конечно, выразительно это все объяснять и руками при этом махать. Или в ридми расписать на литературном русском или английском. Но вроде программисты должны любить формальные языки.
S>Уж лучше на ансибле если уж так. Но текстом в реадми ещё лучше. Потому что одни захотят в кубы, вторые сразу на железо. К тому же при описании контейнеров многое теряется. Например, рассовывание файликов проекта по папкам с выставлением нужных прав.

Почему? Как раз все рассовывания будут в Dockerfile прописаны.

vsb>>И в этом, я считаю, важный плюс докера и куба. Он даёт общий язык для общения между админом и программистом.
S>Он даёт общай язык для общения между куберфилом и куберфилом. В итоге никто из них не понимает как поднять проект без контейнеров.

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

Здравствуйте, vsb, Вы писали:

S>>Уж лучше на ансибле если уж так. Но текстом в реадми ещё лучше. Потому что одни захотят в кубы, вторые сразу на железо. К тому же при описании контейнеров многое теряется. Например, рассовывание файликов проекта по папкам с выставлением нужных прав.
vsb>Почему? Как раз все рассовывания будут в Dockerfile прописаны.
Ну кстати да. Возможно тут ты прав.


vsb>Чего там понимать, просто повторяешь все команды из докерфайла ручками и прописываешь все сервисы и энвы как в манифесте и всего делов. Не понятно, только, зачем, но если хочется.
Тогда уж лучше в ансибол описать. Заодно параметризировать можно.

Здравствуйте, Sheridan, Вы писали:

vsb>>А что программист знать обязан?
S>Помимо программирования?
S>Ну, например то, как правильно установить и настроить его приложение, какими сервисами его обложить и как лучше эти сервисы настроить.

Нереально. Эти вещи знают разве что команды деливери, эксплуатации, тестировщики и тд.

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

Все что я могу как разработчик — запилить тот вариант, который подкинет мне архитектор. Могу сообщить архитектору о каких то проблемах найденых, например, что пишем в сторадж самое меньшее в 10 раз чаще, чем он рассчитывал.
Архитектор может упростить вариант, и вместо <произвольный бесплатный мейлсервер> выбрать sendgrind или mailgun который будет слать нужные вещи по адресам в конфиге, в таком случае я могу написать тест, что моё приложение подымает транспорт для сендгрида, что туда пролезут корректные параметры, и что взаимодействие будет делаться именно через этот транспорт.

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

Если я как архитектор — то могу выбрать тот вариант, который лучше подходит под задачи заказчика с учетом его бюджета. Например — sendgrid что бы всё было просто и ровно. Могу сообщить разработчику, как именно построить взаимодействие с sendgrid, могу проверить работу разработчика, сделать ревью конечного решения и тд.

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

Здравствуйте, vsb, Вы писали:

vsb>А что программист знать обязан?

Алгоритмы, паттерны проектирования и фреймворки. И предметную область для разрабатываемой программы.
Программист пишет код, а не настраивает инфраструктуру и не ремонтирует технику, для этого есть другие люди.
Докер собственно для того и придуман, чтобы давать программистам готовую среду разработки, в виде образа, без необходимости что-то настраивать, читать man'ы и т.д.
Если в вакансии требуется совмещение 2-х должностей за 1 зарплату — для меня лично это сразу стоп-сигнал, такая компания сразу отправляется в черный список.
Скорее всего, там рулят типичные эффективные совы вроде Шурика Агапитова, считающие наемных работников за крепостных холопов, привыкшие кидать и недоплачивать за выполненную работу.
В серьезных компаниях всегда четко поставлены бизнес-процессы, разграничены обязанности, у каждого работника своя сфера ответственности.
Виртуальные машины настраивают девопсы, программисты пишут код, тестировщики его проверяют, а руководители ставят задачи и контролируют их исполнение.
А если Java программисту нужно настраивать узлы в кластере, front end'еру — рисовать макеты в фотошопе, тимлиду — ревьюить код каждого программиста, то от такого бардака лучше держаться подальше.

Здравствуйте, Worminator X, Вы писали:

WX>А если Java программисту нужно настраивать узлы в кластере, front end'еру — рисовать макеты в фотошопе, тимлиду — ревьюить код каждого программиста, то от такого бардака лучше держаться подальше.

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