Кстати, вопрос про масштабирование микросервисов. Как оно происходит на практике? Ну, т.е. понятно, что в настройках Deployment кубера указано, что сервис можно масштабировать до 10X от обычного количества (и он это сделает), но... Для этого же реальное железо нужно (про абстрактные облака только трепать языком можно, как все хорошо, а когда теория сталкивается с реальной реальностью, то все оказывается сильно другим).
И тут два варианта. Либо железо свое, тогда вряд ли часть серверов выключены — скорее всего работают в холостую и тогда можно заранее все микросервисы отмасштабировать по масимуму. Если же используется "облачный провайдер", то там ценник такой, что дешевле на те же деньги закупить арендованных машин у обычных хостеров раз в 10 больше и там запустить свой кубер (что возвращает к первому варианту).
Хочу узнать, какова реальная реальность масштабирования микросервисов у тех, кто этим пользуется?
И другой вопрос про Postgres. Как я понял, в облаках принято использовать эфемерные контейнеры (StateLess) и объектные хранилища, которые отлично мастштабируются за счет автошардирования. Но если хочется из контейнера использовать Postgres, причем масштабировать его до производительности железа машины. Какие есть варианты. Как я понял, в докер пихать production Postgres не вариант. Разве что использовать stolon (тогда все будет в кубере). Можно накатить Postgres как обычно на отдельную машину (вообще без использования кубера, т.е. по старинке), но после этого придется всерьез запариться защитой от расщепления сети, и это не просто. Какие еще надежные варианты используют? Было бы круто, если бы Postgres был на одной ноде с контейнером, который его использует, чтобы исключить сетевые задержки (терять 0.5ms на запрос как-то расточительно, хотя я уже понял, что кубер это не ради производительности) и чтобы этот postgres был единственным на ноде на все контейнеры, которым он нужен...
S>Это всё как раз не про несчастный глючный докер. Если у тебя софт -не маленькая программулька aka сайтик на lamp, а целый кластер, то, чтоб энтот кластер в виде кубернетиса на машину вкорячить нужно:
Я уже давно понял, что большинство разработчиков не могут в принципе выполнять работу админа/девопса и причина эта кроется где-то глубоко. Впрочем, этого и не требуется (для того и есть девопсы/админы, чтобы делать свою работу, чтобы разработчики могли делать свою). Однако, я не могу понять, почему твои девопсы тебе не дают
тестовый кластер для работы? Чем ты им так насолил, что тебя самого заставляют этот кластер настраивать? Или ты не в состоянии осилить работу с тестовым кубером, чтобы на нем развернуть приложение и работать с ним в полноценном кластере?
В общем, я это к тому, что тебе не нужно разворачивать кластер, тебе нужно уметь развернуть в тестовом кластере свое приложение. А при нормально построенном CI/CD, он сам все развернет, и тебе нужно будет только поменять ту часть, которую ты сам пишешь.
И, кстати, если у вас нет автоматического развертывания всего в тестовый кубер, то как вы вообще все это тестируете.
C>>Ещё один воинствующий неумеха появился в теме.
S>Это не я, это пересказываю впечатления отдела внедрения. Мне с такими субстанциями возиться по долгу службы не довелось, слава богу.
S>>Если софт — коробка, то это просто обязан быть пакет. (deb, rpm итд), который должен ставиться штатными средствами. M>и в нем как раз таки проблема версий будет стоять жестко. ты не контролируешь когда и как пользователи проапгрейдятся
Давно уже все коробочные продукты либо статикой линкуют все, кроме libc, либо динамикой с RPATH (и отдельной папкой с нужными библиотеками). А в системных библиотеках типа libc и libstdc++ обратная совместимость отлично реализована. Только это offtop.
Здравствуйте, Vetal_ca, Вы писали:
S>>У тебя в этом мире нет понимания что программеры без девапсов/админов клепают таоке уродство что остаёься только улыбаться. V_>Да, как мир без Шеридана живет, диво-дивное
Не знаю про какой ты мир, а в этом шеридан востребован ибо регулярно приходят предложения поработать.
CK>Я еще раз повторю, что все эти проблемы, они не про пакетирование, а про разработку. Тебе легко писать — пусть программисты пишут хорошо, вместо того чтобы писать плохо. Но попробуй сделай хорошо основываясь на зависимости, которая ломает обратную совместимость или работает по разному в разных дистрибутивах linux, т.к. собрана там с разными флагами.
Можешь добавить эту зависимость к своему проекту и собирать проект либо с ней (RPATH, статика), либо с системной либой.
R>И тут два варианта. Либо железо свое, тогда вряд ли часть серверов выключены — скорее всего работают в холостую и тогда можно заранее все микросервисы отмасштабировать по масимуму. Если же используется "облачный провайдер", то там ценник такой, что дешевле на те же деньги закупить арендованных машин у обычных хостеров раз в 10 больше и там запустить свой кубер (что возвращает к первому варианту).
У облачных провайдеров ты не платишь за то, что не используешь (в отличие от датацентра, которому пофиг, в холостую твои сервера работают или нет). Поэтому облачные провайдеры хороши для внезапных пиковых нагрузок.
Как пример, который у нас недавно был. Из-за ошибки в одной из версий приложения некоторые данные отсылались неправильно. На три дня отключили обработку этих данных, пока находили причину и как это решить. За три дня скопились несколько десятков миллионов необработанных сообщений. Когда фикс выкатили, включили обработку обратно. Пять минут данные жевались одним обработчиком, потом автоматом заскейлились до 10, прожевали все данные за 20 минут, вернулись обратно к одному обработчику.
Но да. С облаками надо быть осторожным. Можно влететь в копеечку.
Здравствуйте, Sheridan, Вы писали:
S>И всё это магическим образом само появляется на ваших серверах и потом на серверах заказчика, ага.
пользователь заходит на cloudsmith.io и ставит себе софт, зачем там девопсы/админы
S>Докер охрененно здорово откладывает решение проблем.
каких еще проблем? продукт практически коробочный, инфраструктуры на нашей стороне нет, CI и деплой делается через SAAS, который стоит не дорого и дает возможность не поддерживать свою инфраструктуру
Здравствуйте, Reset, Вы писали:
R>Можешь добавить эту зависимость к своему проекту и собирать проект либо с ней (RPATH, статика), либо с системной либой.
Так можно втащить очень много всего, изначально хотелось все это сделать "правильно", через "linux way", без всяких RPATH и докеров, все зависимости через пакетный менеджер ОС, чтобы пользователь поставил самым стандартным для своей ОС способом и порадовался (и чтобы такие как Шеридан не бухтели).
Просто, как выяснилось, это не очень просто для разработки, а Шеридан почему-то считает что там каким-то боком должны присутствовать девопсы и программисты опять где-то обосрались, хотя вообще непонятно при чем там девопсы, т.к. зависимостями они не управляют а CI и упаковка отданы в SAAS
Вообще пока не понятно вообще, при чем там админы девопсы, я пытаюсь понять, но никак не могу. Вот пишу я допустим софт и ко мне подходит девопс Васян и говорит — я вижу ты тут начал использовать этот синтаксис в SQL запросах, а sqlite3 в ubuntu 16.04 такой-то версии его еще нет поэтому перепиши пожалуйста, так штоле? А как Васян это узнает, он типа следит за тем как мейнтейнеры всех дистров упаковывают наши зависимости и одновременно как-то разбирается в деталях работы каждой зависимости и всего нашего кода? Он всеведущ как боженька может быть? Как он узнает про sqlite, там же abi не сломан. Я знаю как я узнаю — запущу на CI и увижу что сломалось, но нафига мне девопс для этого? У меня есть SAAS CI и github enterprise и SAAS хостинг пакетов.
Здравствуйте, Sheridan, Вы писали:
S>Кек, а когда я такое предлагаю — мне все начинают втирать что я ничего не понимаю в бизнесе, что мне из колхоза надо вырасти но сначала школу закончить. S>
потому что ты предлагаешь не это, люди, которые занимаются SDLC — программисты и менеджеры, а не девопсы, девопсы (точнее SRE) у нас этим не занимаются, у них другая работа, понятное дело, они мейнтейнять репозитории с пакетами (софт и сервера), но содержимое этих репозиториев уже не их дело
и такой фокус могут себе позволить провернуть не так много компаний в мире, большинство вынуждены полагаться на 3rd party в виде пакетных менджеров ОС, например
Здравствуйте, Sheridan, Вы писали:
S>Так фокусируйся. И следуй рекомендациям админа/девапса. И не по желанию левой пятки внешнюю либу добавляй в проект, а после обсуждения с этим самым админом/девапсом.
А ты, я смотрю, в своем репертуаре. Админ решает, что должен, а что не должен использовать разработчик. Я из опыта участия в проектах знаю, что реальность немного суровее, в том числе и по отношению к админам.
Вот если, к примеру, прикладная программа ни с того ни с сего при запуске требует прав администратора сети, это повод админу вмешаться. Админ также может возразить руководству заказчика, если у оного заказчика хотелки зашкаливают. Например, требует заказчик новый сервис. Причем вчера. А сервис выглядит, скажем там, странно, да еще хочет изменений в инфраструктуре. Повод задуматься.
А вот чтобы админ решал, какие сторонние библиотеки использовать для расчетов по астрофизике, я не видел ни разу.
Здравствуйте, Privalov, Вы писали:
S>>Так фокусируйся. И следуй рекомендациям админа/девапса. И не по желанию левой пятки внешнюю либу добавляй в проект, а после обсуждения с этим самым админом/девапсом. P>А ты, я смотрю, в своем репертуаре. Админ решает, что должен, а что не должен использовать разработчик.
Перечитай ещё раз что я пишу. Админ НЕ решает. Админ работает в команде и консультирует.
Приблизительно так:
р: буду использовать либу Х
а: возьми версию У, она сейчас везде используется
р: но мне позарез нужен функционал свежей версии
а: понял, тогда ща заведу тикет себе на учитывание этого при деплое
R>И тут два варианта. Либо железо свое, тогда вряд ли часть серверов выключены — скорее всего работают в холостую и тогда можно заранее все микросервисы отмасштабировать по масимуму. Если же используется "облачный провайдер", то там ценник такой, что дешевле на те же деньги закупить арендованных машин у обычных хостеров раз в 10 больше и там запустить свой кубер (что возвращает к первому варианту).
"в облаках" обычно много способов сэкономить. on-demand, spot-инстансы. но это требует тщательного планирования конечно
Здравствуйте, Sheridan, Вы писали:
S>Изоляция строго необходима -> глупость. Изоляция нужна при запуске опасных процессов, способных развалить систему. Например, при экспериментах с вирусами. Либо для ещё одного слоя усложнения доступа к важным данным из соседних процессов. Например, к персональным данным. В остальных случаях можно обойтись.
Можно, но не нужно. С появлением докера развернуть на своей машине какой нидь teamcity можно одной командой. При наличии корпоративного кластера и всяких кубернейтсов можно тривиальным образом уже получить корпоративное приложение, минимальными усилиями и вообще без напрягов. На разнородном окружении. Я помню каков был мир до докера и кубернейтса, и сейчас просто не нарадуюсь, насколько все стало проще. Обеспечение горизонтального масштабирования приложения — вообще тривиально стало. Мы меняли датацентры — тоже тривиально, можно быстро развернуть инфраструктуру в другом датацентре, можно в облаке, можно на соседнем компе, причем в случае если у нас электричество отрубится автоматом поднимется все в другом месте и будет незаметно — вообще красота. Более того, это можно самостоятельно все делать без особых напрягов, а ранее приходилось черти как напрягать админов, которые делали то, что сейчас я могу сделать за 10 минут неделями. И с появлением докеров мне пофиг какая там таймзона на серваке, какая там локаль, какая версия ядра, у меня все работает само, причем без падения производительности. Мне блин даже конфигурить не надо зачастую ничего, сервисы сами друг друга находят. Не нужно логами заморачиваться, логи централизованные, мониторинг ресурсов централизованный, я могу вообще не думать о куче вещей, про которые приходилось думать раньше. Настолько все упростилось. И упростится далее еще больше, есть куда стремиться.
Здравствуйте, elmal, Вы писали:
S>>Изоляция строго необходима -> глупость. Изоляция нужна при запуске опасных процессов, способных развалить систему. Например, при экспериментах с вирусами. Либо для ещё одного слоя усложнения доступа к важным данным из соседних процессов. Например, к персональным данным. В остальных случаях можно обойтись. E>Можно, но не нужно.
Если можно — то зачем лишние сущности?
E>С появлением докера развернуть на своей машине какой нидь teamcity можно одной командой. При наличии корпоративного кластера и всяких кубернейтсов можно тривиальным образом уже получить корпоративное приложение, минимальными усилиями и вообще без напрягов. На разнородном окружении. Я помню каков был мир до докера и кубернейтса, и сейчас просто не нарадуюсь, насколько все стало проще. Обеспечение горизонтального масштабирования приложения — вообще тривиально стало. Мы меняли датацентры — тоже тривиально, можно быстро развернуть инфраструктуру в другом датацентре, можно в облаке, можно на соседнем компе, причем в случае если у нас электричество отрубится автоматом поднимется все в другом месте и будет незаметно — вообще красота.
Подобный хелловорд без данных прекрасно и без докера жить будет.
E>Более того, это можно самостоятельно все делать без особых напрягов, а ранее приходилось черти как напрягать админов, которые делали то, что сейчас я могу сделать за 10 минут неделями.
Естественно, на все грабли наступили админы. И не говори что их опыт ты не используешь совершенно.
А вообще непонятно что за админы там у вас. Почему тратили недели. Есть подозрение что их надо было уволить и взять нормальных.
E>И с появлением докеров мне пофиг какая там таймзона на серваке, какая там локаль, какая версия ядра, у меня все работает само, причем без падения производительности. Мне блин даже конфигурить не надо зачастую ничего, сервисы сами друг друга находят. Не нужно логами заморачиваться, логи централизованные, мониторинг ресурсов централизованный, я могу вообще не думать о куче вещей, про которые приходилось думать раньше. Настолько все упростилось. И упростится далее еще больше, есть куда стремиться.
Аналогично и с деплоем на ансибле.
Здравствуйте, Sheridan, Вы писали:
S>Если можно — то зачем лишние сущности?
Можно кодить прямо в машинном коде. Зачем нужен ассемблер и тем более ЯВУ? Можно же в машинном коде писать!
S>Подобный хелловорд без данных прекрасно и без докера жить будет.
Угу. Всего то нужно поставить томкат, сконфигурить его, так как порты могут быть заняты и на машине может стоять другой томкат или что еще, сконфигурить nginx, чтоб это было все таки на стандартном порту. Очень занимательное занятие, учитывая что конфиги постоянно разные, от версии к версии формат меняется, соответственно еще и доку читать.
S>А вообще непонятно что за админы там у вас. Почему тратили недели. Есть подозрение что их надо было уволить и взять нормальных.
Да они в силу своего непрофессионализма возможность бекапов, хранения логов, мониторинга, автоподнятия и т.д. И для каждого приложения приходилось этим заниматься индивидуально. Причем этих приложений до черта и больше. Серверов до черта и больше. Но это было до докеров. С появлением докеров и кубернейтсов все стало происходить с гораздо меньшими проблемами и гораздо быстрее. Кстати, до докеров использовались сервера виртуалок, в случае с серверами виртуалок еще можно было адекватно тратить время на рутину.
Здравствуйте, Sheridan, Вы писали:
S>Перечитай ещё раз что я пишу. Админ НЕ решает. Админ работает в команде и консультирует.
Это если речь идет об инструментах, с которыми админ сталкивался. Библиотеки для построения GUI, каких-нибудь почтовых или FTP клиентов и все в таком духе. А вот когда решается вопрос, что взять для решения жестких систем ОДУ, у админа могут возникнуть серьезные затруднения. Просто потому, что он может просто не знать, что такое жесткая СОДУ. Я не встречал среди сисадминов ни геологов, ни астрофизиков, ни спецов в распознавании образов.
Им иногда приходится выбирать из нескольких библиотек. А иногда и использовать одновременно разные, делающие, казалось бы, одно и то же. Но одни на одном наборе данных лучше работают, другие — на другом. Математика — тетка весьма капризная. И как тогда вести себя админу?
Здравствуйте, elmal, Вы писали:
S>>Если можно — то зачем лишние сущности? E>Можно кодить прямо в машинном коде. Зачем нужен ассемблер и тем более ЯВУ? Можно же в машинном коде писать!
Можно палкой бананы сбивать, ага. Я в курсе что можно съехать на гиперболизации.
S>>Подобный хелловорд без данных прекрасно и без докера жить будет. E>Угу. Всего то нужно поставить томкат, сконфигурить его, так как порты могут быть заняты и на машине может стоять другой томкат или что еще, сконфигурить nginx, чтоб это было все таки на стандартном порту. Очень занимательное занятие, учитывая что конфиги постоянно разные, от версии к версии формат меняется, соответственно еще и доку читать.
Становится понятно...
Зачем устанавливать томкат? Надо добавлять его в зависимости пакета. Вместе с бинарниками устанавливать также кусок конфига, в мануале описать как инклудить его в конфиг томката.
Так-же и для nginx и так далее.
Опять же, мне может быть и не надо "на стандартном порту". Поэтому не стоит хардкодить.
S>>А вообще непонятно что за админы там у вас. Почему тратили недели. Есть подозрение что их надо было уволить и взять нормальных. E>Да они в силу своего непрофессионализма возможность бекапов, хранения логов, мониторинга, автоподнятия и т.д. И для каждого приложения приходилось этим заниматься индивидуально. Причем этих приложений до черта и больше. Серверов до черта и больше. Но это было до докеров. С появлением докеров и кубернейтсов все стало происходить с гораздо меньшими проблемами и гораздо быстрее. Кстати, до докеров использовались сервера виртуалок, в случае с серверами виртуалок еще можно было адекватно тратить время на рутину.
А, я понял. Они всё это руками делали наверное. Знаю я несколько таких админов, да. Которые "ансибол(чиф, паппет, iac вообще) нинужэн" и в итоге любая рутина превращается в квест.
Здравствуйте, Privalov, Вы писали:
S>>Перечитай ещё раз что я пишу. Админ НЕ решает. Админ работает в команде и консультирует.
P>Это если речь идет об инструментах, с которыми админ сталкивался. Библиотеки для построения GUI, каких-нибудь почтовых или FTP клиентов и все в таком духе. А вот когда решается вопрос, что взять для решения жестких систем ОДУ, у админа могут возникнуть серьезные затруднения. Просто потому, что он может просто не знать, что такое жесткая СОДУ. Я не встречал среди сисадминов ни геологов, ни астрофизиков, ни спецов в распознавании образов. P>Им иногда приходится выбирать из нескольких библиотек. А иногда и использовать одновременно разные, делающие, казалось бы, одно и то же. Но одни на одном наборе данных лучше работают, другие — на другом. Математика — тетка весьма капризная. И как тогда вести себя админу?
А серебряной пули не бывает. Подобный человек — не панацея для всех бед. К тому же и у тебя изначально нужных знаний не было. Понятное дело что в чём-то он будет опираться на ваше мнение, гдето на своём настаивать и так далее. Но он избавит вас от проблем "аааа дллхэллл нада три версии одной либы линупсгавно".
Пойми, у него другое направление работы. Вы пишете код, а админ/девапс для этого кода обеспечивает нужное окружение. Либо советует вам как не выйти из существующих окружений. Не воспринимайте админа в своей команде как зло, это совершенно не так. Нормально установите с ним общение и вы избавитесь от необходимости решать кучу вопросов, которые вам неинтересны. А судя по тому что вы выбираете самый лёгкий путь — они вам таки совершенно неинтересны.
Здравствуйте, Sheridan, Вы писали:
S>А серебряной пули не бывает. Подобный человек — не панацея для всех бед. К тому же и у тебя изначально нужных знаний не было. Понятное дело что в чём-то он будет опираться на ваше мнение, гдето на своём настаивать и так далее. Но он избавит вас от проблем "аааа дллхэллл нада три версии одной либы линупсгавно".
Серебряная пуля — это немного о другом. Да, изначально у меня не было нужных знаний. Но во время работы над проектом они появились. Разработчик же читает литературу, ставит эксперименты. Это исттчник нужных знаний, нет? А вот админу этого ничего не нужно. У него другие задачи. Например, заставить разработчиков не использовать умные указатели или вообще управляемые языки.
S>Пойми, у него другое направление работы. Вы пишете код, а админ/девапс для этого кода обеспечивает нужное окружение. Либо советует вам как не выйти из существующих окружений. Не воспринимайте админа в своей команде как зло, это совершенно не так. Нормально установите с ним общение и вы избавитесь от необходимости решать кучу вопросов, которые вам неинтересны.
Я ж не раз писал, в нормальных командах админ — друг разработчика. За свою практику я не нашел общего языка только с одним. ну тем, которого в конце концов уволили.
S>А судя по тому что вы выбираете самый лёгкий путь — они вам таки совершенно неинтересны.
Опять ты за свое. Выбрать легкий путь решения задачи — обязанность любого нормального человека. Самый легкий — не самый простой. Эти понятия часто путают. У тебя такое тоже случалось в прошлых дискуссиях, в том числе со мной. Напомню: самый простой путь: чего там думать, трясти надо! В разработке — везде пихать new / delete. А легкий путь — один раз сделаьб сложный умный куазатель, который позволит перестать бороться с утечками и позволит сосредоточиться на поставленной задаче.
Или как у меня когда-то было. Нужно было с Си-программе использовать некий функционал. Оказалось, что тот написан на Фортране. Самый простой путь — переписать все на Сях. А самый легкий, как выяснилось, разобраться, как заставить сишный и фортрановский код работать в одной программе.
