Что не так с DevOps?

Мне сложно что-либо сказать не зная, что конкретно крутится на серверах, сколько рабочих реплик требуется для той или иной софтинки, …

Гугл/яндекс поиск

Глянул на вскидку статейку, имеющую отношение к разговору - почитайте:
Как устроен поиск Яндекс.Маркета и что будет, если упадёт один из серверов

Все устроено не так просто, как кажется.

Аппку всю ронять нельзя.

Партиционирование. Вы рестартуете сразу весь кластер и надеетесь что будет хорошо? Я же говорю, стоит только копнуть, а там сразу какие-то приколы :DDDDD

Пошел я нахер со своими 20к хостов.

А, кстати, было бы неплохо. Твои миллиарды хостов в каждой теме уже несколько надоели.

«Своими» бгггг.

Партиционирование. Вы рестартуете сразу весь кластер и надеетесь что будет хорошо? Я же говорю, стоит только копнуть, а там сразу какие-то приколы :DDDDD

Никто не рестартит весь кластер, я как раз полтреда тебе и пишу, что так делать нельзя. Каким именно образом организовать роллинг рестарт - вопрос чисто технический, но роллинг ребилд займет значительно (зачастую на порядки, то есть в 10-100 раз) времени больше, потому является наркоманией.

А, кстати, было бы неплохо. Твои миллиарды хостов в каждой теме уже несколько надоели.

«Своими» - потому что я их менеджу, в составе небольшой команды. Нет, не владею. У тебя с этим проблемы, и ты решил перейти к ad hominem, не имея технической возможности изучать подобные инфраструктуры вживую?

В один прекрасный день кто-то заддосил sourcehut, и этот прекрасный сайт полностью лег больше чем на неделю.

А был бы в кубере - влетел бы на бабки.

А с бабками-то оно как связано, куб можно и на своем железе гонять. Вот если облачный, то да…

Вот если облачный, то да…

Ну так такие стартапы, скорее всего, в облаке и сидят.

И как кубер спасет его десять серверов в одном датацентре от ddos?

Никто не рестартит весь кластер, я как раз полтреда тебе и пишу, что так делать нельзя.

И тебе этого никто не предлагает.

«Своими» - потому что я их менеджу

Так-так-так…

в составе небольшой команды

Так-так-так вот, это называется как минимум «нашими».

У тебя с этим проблемы

Чувак, это у тебя с этим проблемы, и это прям заметно. И да, ad hominem это единственно возможное развитие разговора после ad verecundiam, когда ты заходишь с козыря типа «я здесь главный или пошел я нахер». Ну так и пошел ты нахер, какие проблемы?

Ансибля с папитом — норм. А вот куберы, докеры-шмокеры та ещё порнуха.

Поправьте меня, но не все ли эти технологии - лишь

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

Тем им легче клиентскую базу расширять, чем больше приложений разрабатывается сразу под подход «надо будет больше — ещё N инстансов купим у облачного провайдера». Надо лишь в личный кабинет покупателям успевать кнопочки добавлять «развернуть на наших мощностях „ваше“ $AppName в один клик».

Заодно и на разработчиках можно экономить. Зачем нанимать одного за 100К, когда можно нанять 10 по 10К? Десять-то их, пусть криво-косо, но 10 фич запилить смогут. А один… и кому его нормальный код нужен? Кто его вообще смотреть будет из клиентов?

Они и хорошую возможность докера (упростить разработчику тестирование в разных пользовательских средах) испохабили, превратив в «пусть пользователь тащит к себе среду разработчика».

А индустрия это радостно жрёт. Потому что рулят ей сейчас не технари, а маркетологи. И вот уже вместо 10 «по 10» быдлокодят 100 по одной.

Все в шоколаде. Ну что, накушались докерхаба уже?

А вот куберы, докеры-шмокеры та ещё порнуха.

Да детка, давай по серверу на сервис. Это же так удобно, чтобы там везде свой systemd был, виртуализация там своя, трансляции. Чтобы все это надо было паппетом менеджить. Это же так удобно!

Во-первых, не ставь знак равенства между докером и контейнеризацией. Во-вторых, многое что «надо распихать по отдельным контейнерам» спокойно садится в одной виртуалке. В-третьих, менеджить что-то все-равно придётся. Разница лишь в требованиях к обслуживающему персоналу.

Во-первых, не ставь знак равенства между докером и контейнеризацией.

docker/podman гораздо более вменяемы, чем lxc и его форк. А больше у нас особо ничего и нет.

Во-вторых, многое что «надо распихать по отдельным контейнерам» спокойно садится в одной виртуалке.

Если у тебя десять сервисов – да. Если у тебя постоянный шафлинг, то нет.

В-третьих, менеджить что-то все-равно придётся. Разница лишь в требованиях к обслуживающему персоналу.

Да не особо. Вопрос в инструментах – напилить годных контейнеров могут и умудренные жизнью UNIX админ, если они ещё не сгнили.

гораздо более вменяемы

Субъективное суждение. ИМХО, не гипервизора ума дело что там внутри него лежит. Для сконфигурировать окружение внутри, как раз, и есть папиты с ансиблями.

Если у тебя постоянный шафлинг

Вчера предприятие выпускало металлопрокат, сегодня торгует цветами, а завтра санфаянсом будет заниматься? Так не бывает.
А реагировать на вопли маркетологов «ща фичей А народ будет массово пользоваться, потом на фичу Б попрут» можно не менее оперативно тем же энсиблом.

Да не особо. Вопрос в инструментах

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

Субъективное суждение. ИМХО, не гипервизора ума дело что там внутри него лежит. Для сконфигурировать окружение внутри, как раз, и есть папиты с ансиблями.

Это лютый оверхед, как по ресурсам, так и по настройке. Memory ballooning до сих пор пытаются нормально сделать, г-ди.

Вчера предприятие выпускало металлопрокат, сегодня торгует цветами, а завтра санфаянсом будет заниматься? Так не бывает.

Лолшто? Ты ни разу не работал в компании, которая делает больше одного продукта/проекта одновременно? :DDDD

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

docker/podman или lxc/incus. Я не вижу принципиальной разницы в количестве вариантов, прости.

Лолшто?

Вот и я об этом же. Вряд ли под шафлингом ты имел в виду вчерашнее закрытие позавчера открытого сервиса (для конечных пользователей), сегодняшнее закрытие вчерашнего и завтрашнее — сегодняшнего. Сервис какое-то время всё-равно жить будет.

Это лютый оверхед, как по ресурсам, так и по настройке

Ямл докера от ямла энсибла не сильно будет легче) А по ресурсам разницы никакой. Что там «кто-то» подключился, установил нужное и оно работает, что сям. Единственное, возможно, по месту для хранения образов, если ты пользуешься сторонними репозиториями образов.

PS ну и вообще нет претензий если мы ведём речь про обслуживание разработки\тестирования, а не про прод.

Вот и я об этом же.

Нет, ты явно о чем-то другом.

Вряд ли под шафлингом ты имел в виду вчерашнее закрытие позавчера открытого сервиса (для конечных пользователей), сегодняшнее закрытие вчерашнего и завтрашнее — сегодняшнего. Сервис какое-то время всё-равно жить будет.

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

Ямл докера от ямла энсибла не сильно будет легче

Причем тут ямл? Я про накладные расходы от второго ядра в виртуализации.

А по ресурсам разницы никакой.

Между Docker и QEMU + KVM? lol. lmao, even.

Все устроено не так просто, как кажется

Всё гениальное просто, [s]дегенераты[/s] олимпиадники от программирования из яндекса конечно же всё усложнили.

Мы живем в мире микросервисов: каждый входящий запрос на market.yandex.ru вызывает очень много подзапросов, и в их обработке участвуют десятки сервисов

Я конечно знал, что там [s]дегенераты[/s] олимпиадники, так ещё и смузихлёбы…

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

Если и так все работало в рамках одной ос - экономии конечно не выйдет.

У меня все в порядке, предпочитаю не работать в описанных говно конторах.

По сравнению с чем?

Не совсем понял кто мешает взять куб-спрей и поднять свой кубик.

Мне пшеничное не особо нравится. Мягкое чрезмерно и бананом отдает

у Solaris zones, админы ими рулили еще в незапамятные времена, теперь вот везде Linux и docker.

Деплоить зоны в солярисе, как и все остальное-одно удовольствие. Какая-то там красота во всем и чуствуется культура администрирования. Текущие распространненые линуксовые облачные технологии реально смердят. Их лепили какие-то неряхи, неумехи. Сделели гомно, тонны гомна.

Всё гениальное просто, … олимпиадники от программирования из яндекса конечно же всё усложнили.

:)) Ну, в принципе, если абстрагироваться от ограничений по мощности и скорости работы железа и дисков - считать, что хватит одного компа:) - и иметь в каждом датацентре просто по standby-запаске такой мощи или какого-то надежного временного переключения на другие датацентры, то софтовую архитектуру конечно можно подупростить) Нынешняя-то проектировалась из расчета на старенькое железо. Правда, для этого придется слегка причесать и тот же кубер - типа, убрать ограничения на число Pod-ов на одном узле, поскольку он тут всегда один (в AWS и Azure я столкнулся с такой фичей ихних кубов, связанной с поддержкой виртуальной сети кубового кластера). Может, еще чего придется допилить в кубере для оптимальной работы с дисками. Собственно, таким допиливанием занимается каждая облачная платформа, используя свои решения.

Я имел в виду декомишонинг серверов, ввод новых серверов и перераспределение ресурсов.

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

lol. lmao, even.

lxc несёт второе ядро? Ну и да, если у вас на серверах отдельные «веб сервер для приолжения А», «СУБД для приложения А», «веб сервер для приложения Б», «СУБД для приложения Б», то, конечно, тут нагрузка лишняя будет именно от лишнего ядра.

Зачем мне это?

… Ну что, накушались докерхаба уже?

Ну чего уж так прям всех-то…)) Единственное, что реально нужно брать на докерхабе - это базовые брендовые docker-образы от соответствующих компаний. Остальное - чисто посмотреть, как свои собственные образы и entrypoint-скрипты запилить под потребности конкретного проекта.

… Они и хорошую возможность докера (упростить разработчику тестирование в разных пользовательских средах) испохабили, превратив в «пусть пользователь тащит к себе среду разработчика».

Никто же не заставляет вас использовать деплой монолитных docker-образов. Есть init-контейнеры, через которые можно развертывать в Pod-e очередную версию приложения. Я, например, просто добавляю прикладной код в виде архива в busybox-образ (который сам по себе «весит» меньше мегабайта), а потом использую этот busybox в качестве образа init-контейнера. А основные docker-образы Pod-ов меняются, когда уж совсем приспичит - типа, раз в год или даже реже.

Ну и docker-образы для разработки (для Docker Compose проекта) готовлю для разработчиков тоже я, а не они сами.

Ну просто голову на плечах надо иметь и немножко трудолюбия)

Короче ты кукаретик, ясно.

Возможно. Значит не попадались мне трудолюбивые любители докера у которых была бы голова на плечах)

хватит одного компа

Не одного, а двух (один на подстраховку в другом датацентре, а лучше в другой стране) мощных компов и несколько широких каналов, чтобы яндекс.маркет работал без перебоев.

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

Ну, так потому что олимпиадники (опустим слово дегенераты, они всё таки стараются) во главе эффективных менеджеров. Уже лет 5 как доступны очень мощные сервера с сотнями ядер и терабайты оперативки. Я уже не говорю о том, что контора уровня Яндекс должна самостоятельно проектировать ЦПУ под свои сервисы. И разрабатывать стандарты типа CXL еще в 2010 годах для получения терабайтов оперативной памяти под кеширование БД.

На этот план хороший Ералаш был: Петров! Ты что тут забыл с пятиклашками? Тебе на 3-й этаж в 10а класс… Вот этот Петров и есть современный Яндекс. Ему ещё к яндекс.маркету, яндекс.столовую нужно сделать (если ещё не сделал). А как ИТ пионеры они просто смешны.

Вот нашёл «Самый умный» https://www.youtube.com/watch?v=PxCvINIYWLQ Прямо в точку!

… Не одного, а двух (один на подстраховку в другом датацентре, а лучше в другой стране) мощных компов и несколько широких каналов …

Ну, второй, я так понял, это чисто для подстраховки (типа, standby) и, возможно, для обслуживания поближе к месту запроса - всю реальную нагрузку должен выдерживать один комп и он же должен хранить весь поисковый индекс и, возможно, «сырые» данные, собираемые поисковыми роботами - хотя это достаточно автономная задача и её уже можно отделить по железу.

Я ради любопытства спросил Гугл «размер поискового индекса Google». Ответ: Индекс Google Поиска включает сотни миллиардов веб-страниц. Его объем значительно превышает 100 млн гигабайт.

Это дело + «сырые» данные роботов надо хранить для надежности в N-экземплярах в разных местах. Ну и, получается, надо как-то очень быстро работать с таким индексом в пределах одного компа, обслуживая поисковые запросы со всего мира.

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

сотни миллиардов веб-страниц

Это как в том анекдоте: А мой сосед говорит, что с женой ежедневно, а ему 95! — Ну так и вы говорите!

Какие миллиарды веб-страниц? Куда тогда пропала выдача не больше 5 страниц или сколько там сейчас? Я лично проверял один нишевый локальный форум, существующий с 90-х годов и дай бог он на 5% в индексе гугла.

обслуживая поисковые запросы со всего мира.

Не нужно обслуживать одним сервером весь мир (хотя сейчас уже и можно, если спроектировать специализированную систему и оптику со всех континетов завести в один датацентр). Один сервер обслуживает подгруппу пользователей на определенном языке или континенте.

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

Ну, если вы хотите воплотить свою идею в реальность - как говориться, сломать шаблон - то вам нужно общаться с кем-то, кто реально варится в этой «кухне». Железо - это еще не все. Нужны и люди, способные создать поисковик.

то вам нужно общаться с кем-то, кто реально варится в этой «кухне»

Вы бы ещё автору Биткойна посоветовали в ЦБ обратиться или в банк устроиться. То, что я вам рассказал олимпиадники из гугла или яндекса допруст лет через 10. Я уже давно ушел дальше, а здесь вывалил старые идеи, чтобы языком почесать, толксы же )

Ваше огромное (но верное) сообщение можно уместить в одно емкое слово geospatial.

Абсолютно с тобой согласен.

В контейнеризации by design нет ничего плохого - это хороший способ запустить недоверенное приложение в системе, ничего в ней не убив.

Но если этим занимается твой собственный программист - то убить нужно уже его.

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

Что касается кривожопости оркестровок - ну а как ты хотел? Это неизбежное следствие огромного спектра задач. Когда ты изучаешь эту срань, чтобы решить свой необходимый спектр задач, то рано или поздно удивленно замечаешь, что вроде бы и изучил, а всё равно оно что-то не умеет, то что нужно тебе, и что лучше бы ты изучил какой нибудь bash\perl\python\php и покрыл бы 100% требований.

Что самое забавное, проходил just for lulz одно собеседование, второй этап, видеоконфа, тестировали меня умные люди, и на мое предложение решения задачи, «сениор» задвинул шикарную идею: так бы мы не делали, потому что кубер этого не позволяет. Вчитайся. Люди в относительно большой конторе устанавливают задачи исходя из того, что умеет какой-то сраный (пусть и взлетевший) набор портянок. Само собой я засмеялся, сказал что напишу реализацию этого «не позволяет» за полдня на любом из трех языков, но к сожалению за $1500 на данный момент не готов сотрудничать с их компанией.

Поэтому мой тебе совет бывалого админа: просто стреляй в сторону звука «ансибл», «паппет» или «кубер» =)

Devops - изначально создавалось людъми без глубокого технического образования, что-бы была своеобразная cреда, где можно быстро и без проблем развернуть софт. Они ориентировались на бабло, а тонкие моменты различного рода специфики, там обратная совместимость, их, мягко говоря, интересовало мало. А разбор всяческих проблем на местах, по их мнению, будут заниматься всякие индусы и прочий - «нанятый персонал», но он будет строго огорожен в юридическом смысле слова и ничего не сможет сделать. Будут 'употреблять' подаваемую пищу с тараканами, как в cоветских столовых.