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

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'еру — рисовать макеты в фотошопе, тимлиду — ревьюить код каждого программиста, то от такого бардака лучше держаться подальше.

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