Тем не менее, даже для кирпича с двигателем боевой радиус важен. Если можно поставить один двигатель вместо двух -- ставят один.
У боевого кирпича кроме боевого радиуса многожество других не менее важных параметров. В большинстве реализаций таких боевых кирпичей этих двигателей стоит две штуки.
А два двигателя ещё и обслуживать нужно в два раза больше, чем один
Но при этом на большинстве транспортников Пентагона стоит не менее 4-х двигателей (очень дорогих изделий) и органы управления многократно дублируются. В пассажирских мы тоже можем наблюдать аналогичную картину, где двигателей не менее 2-хштук. И это никого не смущает, как и то что после посадки и перед взлётом борты проходят проверку и подготовку. Цена вопроса настолько велика, что никто не будет думать о таких вещах как КПД, там больше рулит наработка на отказ.
Если оружиие одноразовое, то при условии достижения нужных ТТХ можно городить любую дичь.
С оружием такое не работает. Потому что оно убивает или колечит. Это работает от светошумовой гранаты до атомной бомбы.
Если же штука многоразовая со сроком службы в десятки лет, то считают TCO
Везде своя специфика, но что касается вооружения обычно на первом месте стоит эффективность (иначе какой смысл в неэффективном оружии?) и надёжность.
мы работаем с облачным хранилищем секретов, а это более тонкая сущность нежели виртуальная машина или meneged service
В чём именно тонкость сущности облачного хранилища секретов? Там вроде нет ничего такого по сравнению с аппаратным HSM.
Представьте, у вас несколько сотен записей, которые периодически надо менять, и, чаще всего, читать в самых разных сценариях, для которых у вас уже написаны плейбуки и роли.
Давайте всё же будем честны. Периодическое обновление записей никак не кореллирует с чтением. Операция чтения идемподентна и нас никак не должна волновать нас. Поэтому это нельзя никак считать в качестве аргумента.
И вот вы пишете кучу однотипных манифестов с ресурсами по документации ..... складываете в отдельный репозиторий, а когда вам надо изменить секрет, пишете ещё манифест
Могу только заметить, что измнение переменной или добавление новой не должно приводить к написаню нового манифеста. У вас где-то рекурсия, с которой надо разобраться. Потому что это совсем не декларативный стиль описания. Должно быть: вы изменили переменную в коде, она автоматически изменилась в инфраструктуре (у вас для этого должны быть pipeline)
И да, читать из секрета через data удобно только внутри терраформа, а реализовать чтение "на лету" при выполнении плейбука ansible - это отдельный квест, и параметр "скорость выполнения сценария" при реализации возрастёт в разы
Но вы сами выбрали инструменты и неподходящую парадигму. Параметр "скорость выполнения сценария" больше зависит от правильности выбранного алгоритма, оценки его сложности и правильной реализиции. Поэтому сложность реализации процедуры "чтение переменных из терраформа" при выполнении плейбука ansible целиком и полностью на плечах задумавшего такое.
Далее, вы спрашиваете, почему передавать секреты через репозиторий, шифруя их c помощью ansible-vault или sops+age, небезопасно. Отвечаю кратко: человеческий фактор.
Тогда под этот критерий попадает практически любая реализация криптографии. Это не ответ на вопрос небезопасности касаемо криптографических инструментов таких как ansible-vault или sops+age. Таким образом ваша реализация аналогично никак не застрахована от человеческого фактора. Тем более для реализации безопасного взаимодействия между командой разработки и командой девопс вам необходим защищённый канал, когда разработчику надо передать переменную команде девопс, которую надо добавить в секреты, либо команде девопс надо передать переменную команде разработки, чтобы выполнить тесты.
Добавлю ещё ремарку про ваше высказывание о том, что код терраформа сам себя документирует
Не писал такого, что код (любое приложение) сам себя документирует. Документация к коду и сам код немного разные вещи. Иногда совсем.
Можно сколько угодно твердить "мы должны использовать Terraform только для работы с инфраструктурой!", но, если молоток не не приспособлен под задачу вкручивания шурупов, не лучше ли взять шуруповёрт?
Хороший вопрос. Часто его приходится задавать людям, которые решили засунуть всё в кубернетес, тем самым (по их мнению) решив все проблемы. Приходилось встречаться с различными применениями Terraform от управления доменными учётными записями и развёртыванием приложений в k8s, до управления дашбордами мониторинга. Но вы сами сказали что молоток (ansible) изначально не предназначен для управления облачной инфраструктурой (даже в документации ЯОблака нет ни одного примера работы с инфраструктурой при помощи ansible), поэтому правильнее воспользоваться шуруповёртом (в документации ЯОблака практически каждый пример работы с инфраструктурой описывается при помощиTerraform). Тем более ЯОблако постоянно обновляет драйвера TF для своего облака и приводит для него примеры в своей документации.
Многие облачные провайдеры предоставляют свои инструменты командной строки для управления инфраструктурой. Поэтому даже от Ansible можно отказаться))) Только Terraform (и Pulumi) это про декларативность описания инфраструктуры, когда в любой момент времени можно посмотреть код и по нему точно понять описание инфраструктуры в облаке. Все последующие изменения можно делать без выяснения текущего положения дел с инфраструктурой: надо увеличить число нод в кластере, просто указали нужное и не надо смотреть какое было до этого; надо удалить инстанс, убрали его из описания (к примеру) манифеста; надо докинуть памяти/ядер/диска, просто указали нужное число; пришло время снести весь стенд (и такое бывает, причём, нередко) - terraform destroy. При использовании инструментов с императивным описанием (например Ansible), прежде чем вносить измнения, надо уточнять текущее положение дел в инфре ну и момент с откатом к предыдущему состоянию инфры не так прост.
для тех действий, которые требуются от DevOps-инженеров на проекте, Terraform не предлагает нужной функциональности.
Очень интересно какой функциональности не хватило?
Регулярные операции по обслуживанию, которые мы обернули в плейбуки Ansible, часто используют чувствительную информацию. Но в силу специфики проекта мы не могли использовать Vault или аналогичное хранилище секретов и до недавнего времени передавали секреты, используя комбинацию из утилит SOPS и Age. Не очень удобно и потенциально небезопасно.
Для Ansible есть утилита ansible-vault. Работает замечательно. Про некоторое неудобство SOPS согласен, про потенциальную небезапосность хотел бы узнать по подробнее.
Дело в том, что продукт Hashicorp декларативен. Это, безусловно, плюс для работы с облачной инфраструктурой в целом, но для тонкой настройки определённых сервисов этого недостаточно.
Возможности userdata в Terraform довольно большие, можно запихнуть много чего.
Кроме этого, есть ещё минусы: необходимо держать отдельный репозиторий с кодом для Terraform, хранить и передавать его state, каждый раз использовать модули shell, terraform, потом обрабатывать их вывод… Лучше уж использовать Bash.
В чём проблема от отдельного репозитория для Terraform? Даже когда в него закидывать кучу модулей, ключей и немного кода на bash, он совсем немного места занимает как и state. И его назначение (репозитория) основное - источник правды. Можно сказать, это документ, по которому другие инженеры должны понимать и принимать вашу инфраструктуру. В командах terraform нет ничего сложного и вывод может быть куда более понятный чем дебаг от Ansible.
В дальнейших планах — собственная коллекция Ansible, в которой хочется охватить те аспекты работы с облачными сервисами, где terraform’у не хватает гибкости
С помощью terraform описывается инфраструктура, с помощью Ansible выполняются задачи администрирования (12-й пункт 12 factors). Довольно распространённый подход.
Прошу прощения сразу за может быть не самый приятный и популярный вопрос. Не подскажите, есть ли в году Брахмы выходные и праздничные дни? Ну чтобы два раза не вставать, чем занимается в это время Шива, потому что в списке дэвов он не значится?
А ещё в Пентагоне понимают, что четыре маленьких двигателя обладают меньшим КПД, чем два бОльших или один большой.
Иногда нужен не КПД, а надёжность. В военной стезе (раз речь зашла про Пентагон) вообще могут даже не обращать внимание на эти три весёлые буквы))) Для решения поставленных задач КПД может быть далеко не третьестепенным фактором.
Также они понимают, что винт бОльшего размера должен меньше разгонять воздух, чтобы добиться той же тяги
Но и шумит он один гораздо звучнее, чем четыре у коптера) Приближение крупного гексакотпера не так заметно на слух чем приближение одновинтового вертолёта, как бы экипаж последнего не пытался "стричь траву".
И когда Пенагону хочется лететь на 4500 км без дозаправки, они принимают это в расчёт.
Они поднимают в воздух самолёты заправщики.
Если говорить о КПД. У ЯО оружия КПД не самый большой, многие компоненты не успевают обжаться и прореагировать, и просто разлетаются вместе со взрывной волной. Но это мало кого волнует. Потому что ЯО обладает самым высоким соотношением выделяемой энергии при вызрыве к массе заряда. Где-то в районе 6 кт на 1 кг заряда. Отдельная песня с хранением и поддержанием боеготовности этого заряда. Это очень сложно и затратно. Но это никого не интересует. Боеголовка при спуске к целе летит по случайной траектории на гиперзвуковой скорости с постановкой ложных статичеких и динамических помех из верхних слоёв атмосферы, куда выводится очень дорогой (произведением инженерного искуства) ракетой. Но это никого не интересует. Про случайность траектории написано для того, чтобы подчеркнуть, что если для выполнения задачи наивысшим приоритетом является маневренность, то на омыляемость будут смотреть в последнюю очередь. Поэтому многие военные самолёты Пентагона обладают аэродинамическим качеством сравнимым с булыжником мостовой и без участия компьютера в полёте практически не управляемы. Но это никого не интересует.
У вас интересные, грамотные и самое главное полезные статьи. Кроме актуальности тем, точности и актуальности примеров подкупает авторский слог, говорящий, что эта объёмная работа делалась в той или иной степени вручную, а не выкидыш ИИ.
Многие приводимые вами примеры и объяснения понятны и с ними согласен. Но как быть с пресловутым человеческим фактором? Когда те или иные решения принимаются не по причине их простого или доступного понимания, а по причине демонстрации власти. Ведь некоторые (хотя, чего греха таить, многие) идут на управленческие должности по этой причине. Когда они могут диктовать свою волю, могут демонстрировать свою значимость и иметь некий статус (начальник). Всё остальное вторично или третично.
Позвольте к вашему тексту написанному не без ИИ (пластмассовый слог) добавить немного человеческого.
Сегодня хотелось бы поговорить о такой быстро набирающую свою популярность методологии - DevOps
Вроде как уже десяток лет или около того миновал с начала её появления.
Обычно, методология DevOps определяется как набор практик, цель которых — сломать барьеры между разработкой (Development) и эксплуатацией (Operations).
Не совсем так. Если следовать первоначальной идее, на которой зарождалась методология DevOps, тогда получается: DevOps - процесс непрерывного совершенствования программных продуктов посредством ускорения циклов релизов, глобальной автоматизации интеграционных и разверточных конвейеров и тесного взаимодействия между командами. Целью DevOps является сокращение времени и стоимости воплощения идеи в продукте, которым пользуются клиенты. Другими словами, удаление барьеров это не сама цель, а всего лишь один из возможных шагов по внедрению методологии. А то некоторые руководители слишком буквально всё понимают, сажают в одной комнате или собирают в одну кучу в опенспейсе разработчиков с инженерами эксплуатации, и после этого начинают думать, что у них таки случился тот самый DevOps, о котором так все говорят и пишут.
Её ключевые принципы:
Движение DevOps основано на четырех принципах: культуре, автоматизации, измерении и разделении (иногда используется аббревиатура CAMS — culture, automation, sharing, measurement).
DevOps — это не про конкретные технологии, а про подход к работе внутри компании.
Увы, но к большому сожалению это не так. Местами совершенно не так. Обычно рукводство как техническое, так и сам бизнес не понимают, что: DevOps (методология) нацелена на сокращение времени между разработкой концепций функционала и его доступностью для клиента.
DevOps-инженер — это одна из самых гибких и адаптивных ролей в современной IT-индустрии. Его задачи, обязанности и даже профессиональный облик могут сильно варьироваться в зависимости от множества факторов.
Обычно это очередная инкарнация многорукого Шивы (были раньше такие системные инженеры), на котором кроме прочего технического ещё учётные записи от сотрудников компании, до клиентских. В основном это учётки для VPN и вообще удалённого доступа к частям системы, доступы и права к репозиториям, хранилищам артефактов, базам данных, брокеров сообщений. Много где на них почта и мессенжеры. Бывает и клиентскими учётками приходиться заниматься. Также вполне могут быть организационные обязанности, когда надо найти подходящего поставщика той или иной услуги (anti DDoS, Cloud, WAF) и провести с ним переговоры. Очень даже возможны длительные дебаты с службой поддержки облачного (отчественного) провайдера. В офисах может наблюдаться мракобесие в виде помощи с почтовым клиентом (частая практика в одной очень крупной продуктовой компании) и с компьютером вообще.
В крупных корпорациях роль DevOps может быть более узкой и специализированной. Например, один инженер может сосредоточиться на автоматизации процессов развертывания, другой — на управлении инфраструктурой через IaC (Infrastructure as Code), а третий — на обеспечении безопасности и соответствия регуляторным требованиям.
В крупняке и на других позициях обычно требуется узкоспециализированный специалист в определённой предметной области
Например, если компания работает с Kubernetes, то инженер будет фокусироваться на оркестрации контейнеров, управлении кластерами и сетевыми политиками. Если же используется традиционная виртуализация или bare-metal серверы, то больше внимания будет уделяться настройке и оптимизации этих сред.
Ничего подобного ни в первом, ни во втором случае.
Успех DevOps во многом зависит от качества взаимодействия между командами.
Аналогично предыдущему - ничего подобного.
В стартапах или малых компаниях нет ресурсов на выделение отдельных специалистов для каждой роли. Поэтому DevOps-инженер часто берет на себя обязанности cloud-инженера, CI/CD-специалиста и даже частично SRE.
Поверьте, это много где и в крупном бизнесе. Даже совсем не в продуктовом. Во многом крупняке именно такое положение дел. Обычно говорят, что таким образом они снижают Bus factor и повышают общую сплочённость и грамотность команды.
DevOps — это не просто роль или набор инструментов, а философия, направленная на улучшение процессов разработки и эксплуатации через автоматизацию, сотрудничество и постоянное совершенствование.
В первую очередь это процесс (берущий свои корни из методологии бережливого производства) как и в случае с другими методологиями в ИТ. Но в подавляющем числе случаев нужен только один результат и до процессов нет никакого дела. То, что бизнесу для получаения успешных результатов надо самому эволюционировать (начинать менять бизнес процессы), обычно остаётся за бортом и без всякого внимания.
Но на самом деле ИБ в малом и среднем бизнесе нет.
Наверное мало кого удивлю, но ИБ и в большом бизнесе не то чтобы есть. Если рассматривать внимательно и с пристрастием, то во многом крупняке эти отделы занимаются имитационной безопасностью (настоящая расшифровка аббревиатуры).
Доступные зарубежные вендоры ушли
Для многих ИБ решений в природе есть масса opensource и freeware решений. Было бы желание.
Бюджетов на ИБ у малого бизнеса обычно нет.
Если по чесноку, то для наступления ИБ больше надо не бюджетов, а культуры безопасной разработки и безопасной эксплуатации. Как показывает практика, про такие вещи (про культуру хороших привычек) думают довольно редко. А у нас подавно, увы.
Реальных ИБ-специалистов за зарплаты малого бизнеса тоже мало.
Тоже помню модемы, тоже помню настройку ADSL-модемов на предприятиях в телефонном режиме вместе со специалистами провайдера и даже активацию Виндовс по телефону)) Только не разу не приходилось по работе сталкиваться с реальными специалистами ИБ, хотя имею опыт работы в нескольких компаниях, которые позиционировали себя как базирующиеся в этом деле. В одной даже работала половина кафеды "Защита информации", причём, это были преподаватели.
ИБ часто требует круглосуточной работы целой службы, а не одного человека.
1 Доступность некоторых сервисов требует круглосуточной работы специалистов 2 На прошлогоднем Беконе был показательный доклад, что для хорошей защиты кластера Kubernetes нужно целое подразделение - в крупняке ни разу такого не встречал.
Низкая культура ИБ и беспечность.
Это везде. Есть небольшое наблюдение, не претендующее на правило, что чем солиднее человек в должности, тем больше беспечности.
Раньше на рынке были понятные и относительно доступные зарубежные решения. Теперь они ушли.
Наличие или отсутствие вендоров никак не влияет на желание заниматься ИБ. Обычно шевеления начинаются, когда возникает угроза бизнесу или владельцам (сейчас могут серьёзно наказать за наплевательское отношение с персональными данными).
Чтобы построить хотя бы подобие нормальной системы ИБ, нужен целый стек технологий ....
Перечисленный стек обычно нужен, чтобы прикрыть дыры в ПО и инфаструктуре. Если на начальных этапах уделяли внимание безопасности и придерживались в дальнейшем, то большинство инструментов для среднего и малого бизнеса будет лишним.
Неподъёмные зарплаты безопасников
Даже по московским меркам не сказать, что неподъёмные
Информационная безопасность — это не работа с 9 до 18. Это круглосуточные мониторинг и реагирование. Это требует целой службы, а не одного, пусть даже гениального, специалиста
Поэтому эти компетенции обычно раскидываются по разным отделам. Именно раскидываются. Браться по собственному почину за такое желающих мало, по причинам описаными вами. Тем более в случае ЧП буду спрашивать с пристрастием.
По факту в малом и среднем бизнесе процветают раздолбайство и крайне низкая культура информационной безопасности.
Довольно часто этим и не только этим занимается человек или группа лиц из силовых ведомств, вышедших на пенсию. Со всеми вытекающими...
Что делать?
Ответили довольно точно тут. Особенно, если учесть, что в некоторых продуктовых (не ИТ) компаниях обыкновенным ИТ специалистам могут сказать, что от них только расходы.
Можно вас попросить (не шантаж) осветить несколько вопросов, возникших при прочтении статьи?
Вот вы пишите про Юридический аспект: *** угрозы увольнения не являются прямым нарушением закона (ц)***
Можно ли в правовом поле однозначно толковать заявление наёмного работника о возможном увольнении (по собственному желанию) проявлением в той или иной форме нарушением действующего законодательства из-за нежелания руководства индексировать заработную плату? Каким образом такое волеизъявление наёмного сотрудника можно истолковать как косвенное нарушение действующего законодательства?
Опять же, вы пишите (вводите свою трактовку такого деяния наёмного сотрудника): *** форма давления, нарушающая трудовой этический кодекс (ц)***
Не сильно знаком со всеми направлениями в юрисприденции и всеми умеющимися у нас в стране кодексами, но не могли бы вы (просто просьба) привести пример такового кодекса? А именно трудового этического кодекса. Ссылки на Консультант будет достаточно.
Вы трактуете систематическое обращение сотрудников на изменение условий оплаты (основным тезисом статьи идёт речь об оплате труда), как изменение условий труда: *** действия носят систематический характер и направлены на принуждение к изменениям условий труда (ц) ***
Хочется уточнить ваше мнение по следующим вопросам: 1 является ли противозаконным обращение (требование) наёмного работника таковым? Обычно даже в трудовых договорах (правда, далеко не вовсех) бывает такой пункт, что работник имеет право требовать от работодателя соблюдения условий труда. Что можно истолковать, как изменение условий труда с целью их улучшения. 2 каким образом с вашей точки зрения должно выполняться обращение к руководству, чтобы это не носило систематический характер и не воспринималось как принуждение? 3 почему вообще надо ходить с челобитной, чтобы получить надбавку к заработной плате? Индексировать ЗП сотрудникам в западло?
Из своего трудового опыта последнюю индексацию заработной платы помню, когда курс доллара был на уровне 35 рублей. Потом как бабушка отшептала. Когда курс перескачил за 52 руб/доллар, в сердцах посетовал руководству на повышение стоимости жизни. Когда курс перевалил за 70 руб/доллар и стоимость жизни подросла соответственно, пошёл к руководству (не от хорошей жизни) с просьбой (не угрозы, не шантаж, не силовое принуждение к действию) повысить заработную плату. На что получил отказ (у руководства большая стройка частного дома недалеко от центра города, а тут я со своими просьбами). Подскажите, пожалуйста, как по вашему следовало поступать мне в этом случае?
Послесловие Помимо вашей статьи с той или иной степенью переодичности появляются статьи схожей направленности, а именно как поступать в случае, когда наёмный работник приходит с просьбой (требованием, волеизъявлением, пожеланием) о повышении оплаты труда. И в качестве аргументов приводит описания вакансий аналогичной своей с зарплатными вилками или даже с оффером на руках. Почему до этого случая не проводили индексацию заработной платы? Ведь не обязательно раз в год делать как себе (+30...50%). Сотрудники после работы остаются людьми с обычными человеческими потребностями и повышения стоимости уровня жизни (что никак не кореллирует с декларируемой минимальной потребительской корзиной и борщевым набором) их касаются тоже. Почему в большинстве случаев шевеления и бурления случаются после того как гром прогремел (работник с оффером или уже с заявлением по собственному)? Какие были ожидания?
подерживаю ansible код в достаточно декларативном стиле (императивный подход остается под капотом)
Сможет ли сторонний человек посмотрев на ваш код ansible понять в какой состоянии находится инфраструктура на данный момент? Ведь это одно из основных достоинств декларативного подхода. И насколько будут корректны (показательны) тесты такого кода?
Зачем вам интеграция инфраструктурной тулзы в ваш язык программирования, а особенно компилируемые? Вам что нужно запускать её раз в 100мкс? Точно нужно, да? А зачем?
Когда проект большой на десяток окружений (есть такие) из кластеров kubernetes, serverless решений, виртуалок, S3 хранилищ и кучи сетевых правил ждать по 15-20 минут, а то и больше пока terrafom (на самом деле terragrunt) очухается и очухается ли - дело такое. Особенно когда надо сделать срочные измнения, что имеет место случаться в самый не подходящий момент.
Ведь в противном случае задача решается самым прямым образом: запускайте самые обычные инструменты через exec. Это не настолько плохо как люди об этом думают, особенно если вы делаете это реже чем раз в секунды.
Автор как раз отметил это в своей статье: Можно создавать инфраструктуру, которая сама подстраивается под нагрузку, автоматически разворачивает тестовые окружения, оптимизирует затраты... И это ни разу не фантастика, особенно когда начинается оптимизация затрат на инфраструктуру или игра в cast cutting. Либо проект настолько громозкий, что для тестов надо генерить определённую часть окружения. Причём, для разных тестов разные варианты ландшафтов надо генерить. Потом их удалять на выходные или в конце рабочего дня (cast cutting).
А еще к вопросу безопасности, вы забиваете в свой код credentials позволяющие, допустим, управлять инстансами VM...
Как инструмент управления инфраструктурой pulumi не должен управлять инстансами. Это как раз задача инструментов императивного управления. В коде pulumi может быть описана установка агента управления или создания пользователя / пользователей с закидыванием соответствующих публичных ключей ssh. А так уже каждый может извращаться как хочет. Встречал рассказ, как в компании даже дашборды мониторинга в Grafana накатываются с помощью terrafom.
Или если вы делаете не mvp колхоз, лишь бы заработало, и вам нужна изоляция, границы модулей - вот это все, то дергаете их по API (например ansible можно дергать через AWX или Semaphore, terraform тоже чем-то, вроде тоже через последний). Зачем миксовать в коде приложения принципильно разные сущности?
Ничто не мешает не миксовать и не варганить кастрюлю венегрета. Это больше по части code style. Для демонстрационной статьи вполне пойдёт.
Тезис про собственные языки ansible и terraform на мой взгляд ошибочен. Их нельзя сравнивать с обычными языками программирования
Всё верно пишите. В ansible и terraform это не более чем формат описания конфигурации, но никак не программирования.
Таким образом остается только ознакомиться с самим dsl, который очень простой, потому что ограниченный. Это близко нельзя сравнить с изучением языка программирования.
Не сказать что очень простой. Тот же hcl свои причуды и нюансы имеет. Для описания инфраструктуры не обязательно изучать ЯП и алгоритмы до состояния готовности пройти лайвкодиниг и алгособес в яндекс или т-банк.
Если позволите, немного добавлю коментариев и внесу небольшую ясность в некоторые вопросы?
Есть ноды управляющие (Control Plane). Раньше их звали Master, но сейчас это слово немодное, так что Control Plane. А есть ноды рабочие (Worker Nodes)
Control Plane и сейчас в некоторой литературе зовут master nodes (мастер нодами). А рабочие ноды раньше звались миньонами))
Рядом с Control Plane живёт etcd
Не совсем корректная формулировка. ETCD - это одна из основных частей мастер нод. Иногда можно встретить ироничное высказывание, что если убрать авторизацию и валидацию запросов, то вполне можно обойтись ETCD без Kube API server)). В этой базе данных с довольно хорошо работающим механизмом консенсуса хранится ообще всё: от настроек всего кластера кубернетес до конфигураций и секретов непосредственно исполняемых приложений. При всей своей простоте, живучести, согласованности и быстродействии она обладает одним существенным недостатком, о котором некоторые не знают, а кто-то не вспоминает - максимальный размер этой базы составляет 8 ГБ. Поэтому когда хочется запихнуть всего и больше в виде конфигураций и секретов тем более на большом кластере, можно внезапно получить не всегда понятный сбой.
Для полной надёжности её ставят отдельно (речь про ETCD)
Это довольно редкий паттерн, когда пытаются разнести CP-часть (Consistent & Partition-tolerant) и AP-часть (eventual consistency) в случаях больших кластеров. Большинство же облачных провайдеров использует запуск запуск ETCD на одних машинах с остальными компанентами Control Plane.
Чтобы прописать нормальные условия для работы кластера, придётся вытащить наружу кучу метрик изнутри ваших приложений. Потому что более-менее доступные условия «из коробки» — это, например, «Если нагрузка на процессор больше 80 % 10 секунд подряд», а не «Если я записываю в базу данных быстрее чем за 0,1 секунды, и очередь — меньше 1 000 событий»
Довольно странный кейс. Приложение можно преспокойно запустить без указания в манифестах (чартах): limits/request, healthcheck, pod distribution budget, QoS, HPA/VPA. Например, nginx взлетает на самом минимальном конфиге без всяких условий. Наверное поэтому его часто используеют в качестве примера в официальной документации.
То есть вам надо будет продумать внешнюю сигнализацию своим приложениям, чтобы отдельные контейнеры могли сообщать внешнему миру о своём состоянии. Например, когда они перегружены, недогружены или что-то ещё.
Здесь хочется внести небольшую правку: не контейнеры, а поды, потому что они являются единственной и основной единицей работы в кластере кубернтес и в одном поде может быть много контейнеров. Случай, когда кубернетес следит за загруженностью (перегружены, недогружены) обычно связан с темой горизонтального, реже вертикального масштабирования и обычно рассматривается отдельно по итогам нагрузочных тестов или хаос инжиниринга.
Вторая особенность — вам надо обеспечить правильное поведение приложения при добавлении-убавлении контейнеров
Повторная неточность/ошибка. Kubernetes не оперирует контейнерами, Kubernetes работает с подами. Если речь идёт о добавлении новых контейнеров в под, то это лишь часть описания манифеста, и там главное не запороть формат yaml-файла. В остальном процедура довольно простая. Что касается правильного поведения приложения при его горизонтальном масштабировании, то это вообще никак не коррелирует со средой исполнения. Если приложение не заточено под Partition-tolerant, то ждать чудес, а потом поносить на чём свет стоит кубы, облака, девопсов/СРЕ, ну знаете - сами себе злобные буратины.
Если у вас планируется реально большой нагруженный кластер, то Control Plane и особенно etcd лучше выносить на отдельные выделенные ноды. Не надо на них вешать рабочую нагрузку, пусть они занимаются только управлением. У себя на деве или стейдже мы можем и совмещать, чтобы экономить ресурсы, но на проде лучше делить. В наших собственных продуктах на dev-части мы совмещаем узлы, а на прод-части создаём два отдельных контура.
Ну знаете, при том количестве ресурсов (особенно дисковых), которых требуется мастер-узлам, экономить, уже кажется проявлением скаредности. Даже такие продукты как Kind и K0s (кубы на максимальных минималках) предполагают, что у вас будет выделенный сервер (виртуалка) для мастер-ноды и отдельные рабочие ноды. Да, они поддерживают режим single-node, но его нужно дополнительно переопределять.
Сразу забудьте про использование локальных дисков на нодах для хранения важных данных в продакшене! Нода умерла — данные пропали.
Ну это рабочая нода должна очень быстро отдать концы. В случае правильной остановке ноды, все поды будут переселены на другие ноды. Согласен, не всегда и корректно это работает особенно у облачных (отечественных) провайдеров. А так в кубах довольно рабочие механизмы переселения подов на другие ноды со всеми данными на дисках.
Базовое решение Ceph — очень популярное, мощное и надёжное распределённое хранилище. Наш опыт показывает, что это отличный выбор. Его можно развернуть отдельно, а можно прямо внутри Кубера с помощью специального оператора Rook. Rook сам поднимает все компоненты Ceph (мониторы, OSD на дисках нод) в виде подов и делает его доступным для Кубера через CSI. Мы у себя часто используем именно связку Ceph + Rook.
Правильно понимаю, что это базовое решение лично у вас, а не во всей индустрии? Проводились ли оценки наработки на отказ такой схемы? Потому что по своей парадигме Kubernetes это история про высокую доступность (СА) и консистентность с непротиворичивостью (СР) не его конёк. Про консенсус голова болит только у ETCD. Т. е. если надо обеспечить доступность сервиса, ожмдания перевыборов лидера или завершения транзакций проводиться не будут. С другой стороны, Ceph использует механизм консенсуса Paxos только в сервисе Ceph Monitors для согласования карты кластера, когда согласуется информация о состоянии хранилищ и пульсов для всех узлов кластера. На этом всё. Также не стоит забывать, что созданное хранилище для пода будет размазано по всему кластеру и когда таких приложений много (что нередко при нынешней моде всё тащить в кубы), возможен неплохой over head по использованию диского пространства (базы на несколько терабайт на раз-два закидывают).
Сеть в Кубере — это, пожалуй, одна из самых сложных тем. Вам точно понадобятся хотя бы базовые знания сетей (IP-адресация, маршрутизация, файрволы).
Отчего же? Сетевая модель Kubernetes основана на плоском адресном пространстве. Все поды в кластере способны видеть друг друга. Нет нужды в настройке NAT. В основе сетевого устройства Kubernetes лежит архитектурный принцип: «У каждого пода свой уникальный IP». Всё как раз очень просто.
В зависимости от выбранного CNI и вашей инфраструктуры вам может потребоваться разбираться с BGP, VXLAN, IPIP-туннелями, настройкой маршрутов и файрволов. Сеть — это то место, где можно застрять надолго.
В каком моменте вдруг может понадобиться разбираться с BGP, VXLAN, IPIP-туннелями? Установили понравившийся плагин на рабочие ноды, дальше организация сетевого взаимодействия целиком и полностью на плечах Kubernetes.
В Кубере есть специальная штука — Service. Это абстракция, которая даёт постоянный IP-адрес и DNS-имя для группы подов
Не совсем так. Это именованная точка входа для доступа к приложению в поде (группа подов совсем не обязательна). Позволяет обращаться по доменному имени к соответствующему поду в кластере. Постоянный IP-адрес уже дело десятое как и забота внутреннего или внешнего сервера имён о преобразовании доменного имени в IP-адрес.
Ingress — стандарт для публикации веб-приложений (HTTP/HTTPS) в продакшене
Ingress можно и даже нужно запускать, если это требуется на любом стенде, а не только на проде.
Работать с кластером Kubernetes без настроенной системы мониторинга и логирования — это посадить админом слепого котёнка.
В чём проблема? Сам кластер Kubernetes довольно живуч и неприхотлив. То что в нём могут устроить лютое мракобесие запущенные приложения, это отдельная история. Родной Metrics Server ставится легко и работает незаметно в отличие от некоторых систем мониторинга и логирования. Всё остальное из разряда Observabilyties довольно легко и быстро ставится готовыми чартами или операторами - больше дело вкуса и личных предпочтений.
Кстати, тут надо передать пламенный привет некоторым российским облакам. У них часто есть довольно смешные лимиты на максимальное количество нод в одном Managed-кластере
Это довольно не самая большая боль для передачи приветов облакоделам. После AWS, GCP наши облака действительно как на Жигули пересел после хорощей иномарки.
Короткий анонс. Приложения должны быть готовыми жить в динамичной эфемерной среде Кубера. Почитайте про 12-factor app — это мастхэв
Вообще это должно быть первым шагом! Это должен быть первый эпат, после корректного завершения которого можно начинать обдумывать переезд в кубы. Но никак не наоборот (из неоднократного личного опыта).
В идеальном розовом мире единорогов ваши разработчики вообще не должны знать слова «Kubernetes». Они просто пишут код, коммитят в Git, а дальше некая «платформа» сама всё собирает, тестирует и выкатывает куда надо. Нажал кнопку — получил фичу в проде. Достичь такого уровня абстракции — это Грааль платформенного инжиниринга.
Типичная работа Devops-инженера. При настроенных CI и CD даже кнопку нажимать не надо. Само протестируется, просканируется, соберётся отправится куда надо (если требуется, дополнительно проверится), задеплоится на нужном стенде с необходимыми проверками, если что-то пойдёт не так или не туда, откатится обратно старую рабочую версию.
P. S. Не сочтите за трудность, вычитывайте, пожалуйста, внимательно текст после нейронок. Проявите уважение к читателям.
Работа проделана немаленькая, где-то подсвечены некоторые интересные и в чём-то важные моменты. Только при этом есть определённые неточности, кое-где переходящие в ошибки. Своим комментарием хочу внести ясность, чтобы начинающие или уже имеющие определённый опыт специалисты Devops не совершали возможных ошибок.
Хочу начать с простенького определения Operational Excellence (OpEx) в контексте методологии Devops. Кратко можно сказать, что данная практика направлена на автоматизацию процессов, для того чтобы уменьшить фактор человеческой ошибки. Опирается на две концепции: Operations as Code (Infrastructure as a Code) Observability (Analytics, Metrics, Actions) Если оставить в стороне рассмотрение Operations as Code, то Observability можно определить как создание, сбор, объединение и использование метрик, которые позволяют получить представление о состоянии системы. Грубо говоря это наши органы чувств, которые позволяют знать, как себя чувствует наша система.
Грамотная стратегия мониторинга решает три ключевые проблемы
Мы внедряем DevOps-практики так, чтобы ваша инфраструктура не просто «работала», а давала вам конкурентное преимущество. И делаем это без лишнего шума: наши решения интегрируются в ваши процессы, а не ломают их
Ну это как бы основное свойство практически всех систем мониторинга))
Почему мониторинг инфраструктуры не справляется с микросервисами и облаками?
Он не должен с ними никак справляться)) Да и зачем экспортёру инфраструктурных метрик лазить за данными managed services облака? Это задача специально заточенных для этого экспортёров метрик
Классический мониторинг, который фокусируется только на инфраструктурных метриках (CPU, RAM, дисковое пространство), не успевает за этими изменениями. Вот основные проблемы: Слепота к бизнес-логике: вы знаете, что сервер «живой», но не видите, почему падает конверсия платежей или тормозит API. Неспособность найти корень проблемы: при сбое в цепочке из 10 микросервисов метрики CPU не скажут, где именно произошла ошибка.
Аналогично тому что было в абзаце выше: мониторинг Operations параметров системы - это мониторинг физических ресурсов системы и к бизнес категориям имеет исчезающе мало отношений. Это история про Node and machine чем про Root cause, если говорить про разбор полётов микросервисов.
Ручная работа: настройка алертов для каждого сервиса отдельно — это часы рутинных задач
Иногда это часы рутинных созвонов, когда надо вытащить и выяснить на какое приложение (микросервис) и какие алерты ставить. С Operations alerts как раз всё намного проще.
Prometheus - это уже не просто база данных временных рядов и не только стек для мониторинга по умолчанию рекомендуемый для Kubernetes. Это не только целая экосистема со своими экспортёрами, которые ориентированы на Operations monitoring и Operations alerts, но и система позволяющая хранить и обрабатывать метрики "бизнес-логики" и метрики "микросервисов". Очень многие вещи делает буквально из коробки. Очень легко и плотно дружит с системой отображения данных Grafana, с которой неплохо дружит Jaeger. А вот выбор стека EFK не совсем понятен. Потому что хранить и обрабатывать 1 ТБ логов (примерно столько выдаёт на гора один стенд за неделю) в S3 bucket (в случае стека Loki + Promtail) и в Elastic вещи немного разные как по цене, так и по удобству администрирования - увеличить размер бакета на живую обходится правкой одной строки в манифесте Terraform, в случае с эластиком действий будет намного больше чем просто указания нового размера диска в том же манифесте Terraform.
Какие метрики критичны для успешного мониторинга?
Service Metrics Reliability – mean time between failure (MTBF) Availability – Uptime, expressed as a meaningful percentage of demand Serviceability – Mean time to repair (MTTR)
IT Metrics Capacity Latency Bandwidth Response time
Особенности для микросервисов: балансировка нагрузки (например, процент ошибок в Istio или Nginx); статус подов в Kubernetes (количество рестартов, фейлов по readiness/liveness проб); трассировка запросов между сервисами (Jaeger): время выполнения каждого этапа. Для Kubernetes используйте метрику kube_pod_status_ready в Prometheus — это помогает быстро находить «битые» поды без ручного проверки логов.
Грамотный мониторинг — это не просто сбор данных, а продуманная система быстрого реагирования. Мы выстраиваем процессы так, чтобы клиенты спали спокойно даже в пиковые нагрузки
Это может выполняться только при грамотной и протестированной программной и инфраструктурной архитектуре. А так ни один мониторинг не спасёт от неработающего мастабирования при росте нагрузке и сбоев в коде приложений.
Мониторинг должен не только сообщать о проблемах, но и подсказывать, что делать. Мы настраиваем его так, чтобы ваша команда тратила время на развитие, а не на тушение пожаров.
Система мониторинга должна отвечать на два вопроса: "что сломалось" и "почему сломалось". "Что сломалось" говорит о симптоме, а "почему сломалось" о причине.
Observability — это не просто «продвинутый мониторинг», а способность системы отвечать на вопросы, которые вы даже не успели задать. Если мониторинг говорит: «Сервер упал», то observability объясняет: «Сервер упал из-за исчерпания памяти в поде Kubernetes, который обрабатывал очередь сообщений с задержкой в 5 секунд из-за проблем с сетью в облаке»
Это будущее агентов ИИ для систем мониторинга)) А пока к таким удобоваримым и понятным объяснениям надо приходить самостоятельно. И ещё потом доказывать службе поддержки облачного провайдера.
Допустим, вы видите в Grafana рост времени ответа API. Вместо ручного поиска причин, observability-стек позволяет мгновенно перейти к связанным трейсам в Jaeger и обнаружить, что 70% задержки возникают в сервисе кэширования. Анализ логов покажет, что ошибки «Connection timeout» начались после обновления версии Redis.
Звучит красиво, но обычно ни один observability-стек ничего не знает об обновлении версий Redis. Ну и анализ логов, обычно ручная операция.
Но observability — это не только инструменты, а культура работы с данными.
Можете более расширено раскрыть про культуру работы с данными (у нас их много и разных этих данных) в контексте observability?
Для настройки трейсинга можно использовать OpenTelemetry — это универсальный стандарт, который применяется даже в сложных .NET-средах.
Как быть людям на проектах без .NET-сред или с ещё более сложными средами такими как С++ или Haskell?
Эффективный мониторинг — это всегда баланс между инфраструктурой, бизнес-логикой и пользовательским опытом
Здесь надо бы добавить уточнение, чтобы было понимание. Мониторинг White-box - Мониторинг, основанный на показателях, отображаемых внутренними компонентами системы Мониторинг Black-box - Тестирование поведения приложения с точки зрения пользователя (тот самый пользовательский опыт и у вас в статье про него ничего нет)
P.S.
перезапуск подов в Kubernetes при превышении лимитов CPU
Kubernetes не будет перезапускать под при превышении лимитов CPU. OOMKill приходит по памяти, для CPU другая стратегия поведения. Поправьте, пожалуйста.
Потом оказывается что на микросервисы нужно вдвое больше разработчиков и многократно больше DevOps
Девопсов на проекте обычно многократно меньше чем разработчиков. Иногда отсутствуют полностью. Кстати, хорошая и грамотная команда инженеров DevOps также играет немаловажную роль - хорошо и грамотно спроектированные микросервисные приложения, могут запнуться о кривую или некудышнюю реализацию в CI/CD и инфраструктуре.
либо того кто ввёл микросервисы гонят ссаными тряпками
Увы, такова действительность. Не всегда бизнес готов к технологическим вызовам: аналитика в Excel, web портал на простенькой CMS, сервис ААА (autorisation, accounting, authentification) на базе AD или 1С
Вы же знаете, что согласно МКБ есть такая болезнь Яндекса в народе именуемая велосипедостроением. Со всеми вытекающими последствиями. И это чуть ли не повсеместно и практически во всех продуктах этой компании.
Куда важнее другое. Причина побудившая автора статьи на такое решение - сетевая недоступность некоторых зон доступности. Если посмотреть список инцидентов, то складывается впечатление, что сеть яндекса представляет из себя тестовый полигон для подготовки к сдаче экзаменов на получение сертификатов CCNA. Ну и при выходе из строя NLB в соответствующей зоне доступности (такое бывало и не раз) толку от такого решения мало.
Или когда вся команда, начиная от архитектора и заканчивая джуном решили использовать микросервисы чтобы записать их в резюме
Встречался и с таким паттерном, когда команда разработки думает не о продукте, а о резюме. Презабавнейшие вещи получались.
А какие озвученные моменты для вас глоток свежего воздуха?
1 Реальные перечисленные проблемы 2 Про не понимание бизнесом микросервисного подхода. Неоднократно слышал пожелание о более тесной связности и зависимости приложений и приходилось доказывать обратное, что приложения (микросервисы) должны быть минимально связаны и зависимы от остальных 3 И то что большинство решающих взяться за микросервисы мало представляют уровень сложности такой разработки
Какой ценой? Особенными требованиями к чистоте, длинне и ровности ВПП.
Ну у МиГ-9 и МиГ-15 тоже был один двигатель. Ровно по той же причине как у МиГ-1 и МиГ-3)) Только потом почему-то отказались от этой схемы
Вроде как давно такие устройства производит концерн Калашников
У боевого кирпича кроме боевого радиуса многожество других не менее важных параметров. В большинстве реализаций таких боевых кирпичей этих двигателей стоит две штуки.
Но при этом на большинстве транспортников Пентагона стоит не менее 4-х двигателей (очень дорогих изделий) и органы управления многократно дублируются. В пассажирских мы тоже можем наблюдать аналогичную картину, где двигателей не менее 2-хштук. И это никого не смущает, как и то что после посадки и перед взлётом борты проходят проверку и подготовку. Цена вопроса настолько велика, что никто не будет думать о таких вещах как КПД, там больше рулит наработка на отказ.
С оружием такое не работает. Потому что оно убивает или колечит. Это работает от светошумовой гранаты до атомной бомбы.
Везде своя специфика, но что касается вооружения обычно на первом месте стоит эффективность (иначе какой смысл в неэффективном оружии?) и надёжность.
В чём именно тонкость сущности облачного хранилища секретов? Там вроде нет ничего такого по сравнению с аппаратным HSM.
Давайте всё же будем честны. Периодическое обновление записей никак не кореллирует с чтением. Операция чтения идемподентна и нас никак не должна волновать нас. Поэтому это нельзя никак считать в качестве аргумента.
Могу только заметить, что измнение переменной или добавление новой не должно приводить к написаню нового манифеста. У вас где-то рекурсия, с которой надо разобраться. Потому что это совсем не декларативный стиль описания. Должно быть: вы изменили переменную в коде, она автоматически изменилась в инфраструктуре (у вас для этого должны быть pipeline)
Но вы сами выбрали инструменты и неподходящую парадигму. Параметр "скорость выполнения сценария" больше зависит от правильности выбранного алгоритма, оценки его сложности и правильной реализиции. Поэтому сложность реализации процедуры "чтение переменных из терраформа" при выполнении плейбука ansible целиком и полностью на плечах задумавшего такое.
Тогда под этот критерий попадает практически любая реализация криптографии. Это не ответ на вопрос небезопасности касаемо криптографических инструментов таких как ansible-vault или sops+age. Таким образом ваша реализация аналогично никак не застрахована от человеческого фактора. Тем более для реализации безопасного взаимодействия между командой разработки и командой девопс вам необходим защищённый канал, когда разработчику надо передать переменную команде девопс, которую надо добавить в секреты, либо команде девопс надо передать переменную команде разработки, чтобы выполнить тесты.
Не писал такого, что код (любое приложение) сам себя документирует. Документация к коду и сам код немного разные вещи. Иногда совсем.
Хороший вопрос. Часто его приходится задавать людям, которые решили засунуть всё в кубернетес, тем самым (по их мнению) решив все проблемы. Приходилось встречаться с различными применениями Terraform от управления доменными учётными записями и развёртыванием приложений в k8s, до управления дашбордами мониторинга. Но вы сами сказали что молоток (ansible) изначально не предназначен для управления облачной инфраструктурой (даже в документации ЯОблака нет ни одного примера работы с инфраструктурой при помощи ansible), поэтому правильнее воспользоваться шуруповёртом (в документации ЯОблака практически каждый пример работы с инфраструктурой описывается при помощи Terraform). Тем более ЯОблако постоянно обновляет драйвера TF для своего облака и приводит для него примеры в своей документации.
Многие облачные провайдеры предоставляют свои инструменты командной строки для управления инфраструктурой. Поэтому даже от Ansible можно отказаться))) Только Terraform (и Pulumi) это про декларативность описания инфраструктуры, когда в любой момент времени можно посмотреть код и по нему точно понять описание инфраструктуры в облаке. Все последующие изменения можно делать без выяснения текущего положения дел с инфраструктурой: надо увеличить число нод в кластере, просто указали нужное и не надо смотреть какое было до этого; надо удалить инстанс, убрали его из описания (к примеру) манифеста; надо докинуть памяти/ядер/диска, просто указали нужное число; пришло время снести весь стенд (и такое бывает, причём, нередко) - terraform destroy. При использовании инструментов с императивным описанием (например Ansible), прежде чем вносить измнения, надо уточнять текущее положение дел в инфре ну и момент с откатом к предыдущему состоянию инфры не так прост.
Очень интересно какой функциональности не хватило?
Для Ansible есть утилита ansible-vault. Работает замечательно. Про некоторое неудобство SOPS согласен, про потенциальную небезапосность хотел бы узнать по подробнее.
Возможности userdata в Terraform довольно большие, можно запихнуть много чего.
В чём проблема от отдельного репозитория для Terraform? Даже когда в него закидывать кучу модулей, ключей и немного кода на bash, он совсем немного места занимает как и state. И его назначение (репозитория) основное - источник правды. Можно сказать, это документ, по которому другие инженеры должны понимать и принимать вашу инфраструктуру.
В командах terraform нет ничего сложного и вывод может быть куда более понятный чем дебаг от Ansible.
С помощью terraform описывается инфраструктура, с помощью Ansible выполняются задачи администрирования (12-й пункт 12 factors). Довольно распространённый подход.
Прошу прощения сразу за может быть не самый приятный и популярный вопрос. Не подскажите, есть ли в году Брахмы выходные и праздничные дни? Ну чтобы два раза не вставать, чем занимается в это время Шива, потому что в списке дэвов он не значится?
Иногда нужен не КПД, а надёжность. В военной стезе (раз речь зашла про Пентагон) вообще могут даже не обращать внимание на эти три весёлые буквы))) Для решения поставленных задач КПД может быть далеко не третьестепенным фактором.
Но и шумит он один гораздо звучнее, чем четыре у коптера) Приближение крупного гексакотпера не так заметно на слух чем приближение одновинтового вертолёта, как бы экипаж последнего не пытался "стричь траву".
Они поднимают в воздух самолёты заправщики.
Если говорить о КПД. У ЯО оружия КПД не самый большой, многие компоненты не успевают обжаться и прореагировать, и просто разлетаются вместе со взрывной волной. Но это мало кого волнует. Потому что ЯО обладает самым высоким соотношением выделяемой энергии при вызрыве к массе заряда. Где-то в районе 6 кт на 1 кг заряда. Отдельная песня с хранением и поддержанием боеготовности этого заряда. Это очень сложно и затратно. Но это никого не интересует.
Боеголовка при спуске к целе летит по случайной траектории на гиперзвуковой скорости с постановкой ложных статичеких и динамических помех из верхних слоёв атмосферы, куда выводится очень дорогой (произведением инженерного искуства) ракетой. Но это никого не интересует. Про случайность траектории написано для того, чтобы подчеркнуть, что если для выполнения задачи наивысшим приоритетом является маневренность, то на омыляемость будут смотреть в последнюю очередь. Поэтому многие военные самолёты Пентагона обладают аэродинамическим качеством сравнимым с булыжником мостовой и без участия компьютера в полёте практически не управляемы. Но это никого не интересует.
У вас интересные, грамотные и самое главное полезные статьи. Кроме актуальности тем, точности и актуальности примеров подкупает авторский слог, говорящий, что эта объёмная работа делалась в той или иной степени вручную, а не выкидыш ИИ.
Многие приводимые вами примеры и объяснения понятны и с ними согласен. Но как быть с пресловутым человеческим фактором? Когда те или иные решения принимаются не по причине их простого или доступного понимания, а по причине демонстрации власти. Ведь некоторые (хотя, чего греха таить, многие) идут на управленческие должности по этой причине. Когда они могут диктовать свою волю, могут демонстрировать свою значимость и иметь некий статус (начальник). Всё остальное вторично или третично.
Позвольте к вашему тексту написанному не без ИИ (пластмассовый слог) добавить немного человеческого.
Вроде как уже десяток лет или около того миновал с начала её появления.
Не совсем так. Если следовать первоначальной идее, на которой зарождалась методология DevOps, тогда получается:
DevOps - процесс непрерывного совершенствования программных продуктов посредством ускорения циклов релизов, глобальной автоматизации интеграционных и разверточных конвейеров и тесного взаимодействия между командами. Целью DevOps является сокращение времени и стоимости воплощения идеи в продукте, которым пользуются клиенты.
Другими словами, удаление барьеров это не сама цель, а всего лишь один из возможных шагов по внедрению методологии. А то некоторые руководители слишком буквально всё понимают, сажают в одной комнате или собирают в одну кучу в опенспейсе разработчиков с инженерами эксплуатации, и после этого начинают думать, что у них таки случился тот самый DevOps, о котором так все говорят и пишут.
Движение DevOps основано на четырех принципах: культуре, автоматизации, измерении и разделении (иногда используется аббревиатура CAMS — culture, automation, sharing, measurement).
Увы, но к большому сожалению это не так. Местами совершенно не так. Обычно рукводство как техническое, так и сам бизнес не понимают, что: DevOps (методология) нацелена на сокращение времени между разработкой концепций функционала и его доступностью для клиента.
Обычно это очередная инкарнация многорукого Шивы (были раньше такие системные инженеры), на котором кроме прочего технического ещё учётные записи от сотрудников компании, до клиентских. В основном это учётки для VPN и вообще удалённого доступа к частям системы, доступы и права к репозиториям, хранилищам артефактов, базам данных, брокеров сообщений. Много где на них почта и мессенжеры. Бывает и клиентскими учётками приходиться заниматься.
Также вполне могут быть организационные обязанности, когда надо найти подходящего поставщика той или иной услуги (anti DDoS, Cloud, WAF) и провести с ним переговоры. Очень даже возможны длительные дебаты с службой поддержки облачного (отчественного) провайдера. В офисах может наблюдаться мракобесие в виде помощи с почтовым клиентом (частая практика в одной очень крупной продуктовой компании) и с компьютером вообще.
В крупняке и на других позициях обычно требуется узкоспециализированный специалист в определённой предметной области
Ничего подобного ни в первом, ни во втором случае.
Аналогично предыдущему - ничего подобного.
Поверьте, это много где и в крупном бизнесе. Даже совсем не в продуктовом. Во многом крупняке именно такое положение дел. Обычно говорят, что таким образом они снижают Bus factor и повышают общую сплочённость и грамотность команды.
В первую очередь это процесс (берущий свои корни из методологии бережливого производства) как и в случае с другими методологиями в ИТ. Но в подавляющем числе случаев нужен только один результат и до процессов нет никакого дела. То, что бизнесу для получаения успешных результатов надо самому эволюционировать (начинать менять бизнес процессы), обычно остаётся за бортом и без всякого внимания.
Наверное мало кого удивлю, но ИБ и в большом бизнесе не то чтобы есть. Если рассматривать внимательно и с пристрастием, то во многом крупняке эти отделы занимаются имитационной безопасностью (настоящая расшифровка аббревиатуры).
Для многих ИБ решений в природе есть масса opensource и freeware решений. Было бы желание.
Если по чесноку, то для наступления ИБ больше надо не бюджетов, а культуры безопасной разработки и безопасной эксплуатации. Как показывает практика, про такие вещи (про культуру хороших привычек) думают довольно редко. А у нас подавно, увы.
Тоже помню модемы, тоже помню настройку ADSL-модемов на предприятиях в телефонном режиме вместе со специалистами провайдера и даже активацию Виндовс по телефону)) Только не разу не приходилось по работе сталкиваться с реальными специалистами ИБ, хотя имею опыт работы в нескольких компаниях, которые позиционировали себя как базирующиеся в этом деле. В одной даже работала половина кафеды "Защита информации", причём, это были преподаватели.
1 Доступность некоторых сервисов требует круглосуточной работы специалистов
2 На прошлогоднем Беконе был показательный доклад, что для хорошей защиты кластера Kubernetes нужно целое подразделение - в крупняке ни разу такого не встречал.
Это везде. Есть небольшое наблюдение, не претендующее на правило, что чем солиднее человек в должности, тем больше беспечности.
Наличие или отсутствие вендоров никак не влияет на желание заниматься ИБ. Обычно шевеления начинаются, когда возникает угроза бизнесу или владельцам (сейчас могут серьёзно наказать за наплевательское отношение с персональными данными).
Перечисленный стек обычно нужен, чтобы прикрыть дыры в ПО и инфаструктуре. Если на начальных этапах уделяли внимание безопасности и придерживались в дальнейшем, то большинство инструментов для среднего и малого бизнеса будет лишним.
Даже по московским меркам не сказать, что неподъёмные
Поэтому эти компетенции обычно раскидываются по разным отделам. Именно раскидываются. Браться по собственному почину за такое желающих мало, по причинам описаными вами. Тем более в случае ЧП буду спрашивать с пристрастием.
Довольно часто этим и не только этим занимается человек или группа лиц из силовых ведомств, вышедших на пенсию. Со всеми вытекающими...
Ответили довольно точно тут. Особенно, если учесть, что в некоторых продуктовых (не ИТ) компаниях обыкновенным ИТ специалистам могут сказать, что от них только расходы.
Лишь бы не одитинг ))
Можно вас попросить (не шантаж) осветить несколько вопросов, возникших при прочтении статьи?
Вот вы пишите про Юридический аспект:
*** угрозы увольнения не являются прямым нарушением закона (ц)***
Можно ли в правовом поле однозначно толковать заявление наёмного работника о возможном увольнении (по собственному желанию) проявлением в той или иной форме нарушением действующего законодательства из-за нежелания руководства индексировать заработную плату? Каким образом такое волеизъявление наёмного сотрудника можно истолковать как косвенное нарушение действующего законодательства?
Опять же, вы пишите (вводите свою трактовку такого деяния наёмного сотрудника):
*** форма давления, нарушающая трудовой этический кодекс (ц)***
Не сильно знаком со всеми направлениями в юрисприденции и всеми умеющимися у нас в стране кодексами, но не могли бы вы (просто просьба) привести пример такового кодекса? А именно трудового этического кодекса. Ссылки на Консультант будет достаточно.
Вы трактуете систематическое обращение сотрудников на изменение условий оплаты (основным тезисом статьи идёт речь об оплате труда), как изменение условий труда:
*** действия носят систематический характер и направлены на принуждение к изменениям условий труда (ц) ***
Хочется уточнить ваше мнение по следующим вопросам:
1 является ли противозаконным обращение (требование) наёмного работника таковым? Обычно даже в трудовых договорах (правда, далеко не вовсех) бывает такой пункт, что работник имеет право требовать от работодателя соблюдения условий труда. Что можно истолковать, как изменение условий труда с целью их улучшения.
2 каким образом с вашей точки зрения должно выполняться обращение к руководству, чтобы это не носило систематический характер и не воспринималось как принуждение?
3 почему вообще надо ходить с челобитной, чтобы получить надбавку к заработной плате? Индексировать ЗП сотрудникам в западло?
Из своего трудового опыта последнюю индексацию заработной платы помню, когда курс доллара был на уровне 35 рублей. Потом как бабушка отшептала. Когда курс перескачил за 52 руб/доллар, в сердцах посетовал руководству на повышение стоимости жизни. Когда курс перевалил за 70 руб/доллар и стоимость жизни подросла соответственно, пошёл к руководству (не от хорошей жизни) с просьбой (не угрозы, не шантаж, не силовое принуждение к действию) повысить заработную плату. На что получил отказ (у руководства большая стройка частного дома недалеко от центра города, а тут я со своими просьбами). Подскажите, пожалуйста, как по вашему следовало поступать мне в этом случае?
Послесловие
Помимо вашей статьи с той или иной степенью переодичности появляются статьи схожей направленности, а именно как поступать в случае, когда наёмный работник приходит с просьбой (требованием, волеизъявлением, пожеланием) о повышении оплаты труда. И в качестве аргументов приводит описания вакансий аналогичной своей с зарплатными вилками или даже с оффером на руках. Почему до этого случая не проводили индексацию заработной платы? Ведь не обязательно раз в год делать как себе (+30...50%). Сотрудники после работы остаются людьми с обычными человеческими потребностями и повышения стоимости уровня жизни (что никак не кореллирует с декларируемой минимальной потребительской корзиной и борщевым набором) их касаются тоже. Почему в большинстве случаев шевеления и бурления случаются после того как гром прогремел (работник с оффером или уже с заявлением по собственному)? Какие были ожидания?
Сможет ли сторонний человек посмотрев на ваш код ansible понять в какой состоянии находится инфраструктура на данный момент? Ведь это одно из основных достоинств декларативного подхода. И насколько будут корректны (показательны) тесты такого кода?
Когда проект большой на десяток окружений (есть такие) из кластеров kubernetes, serverless решений, виртуалок, S3 хранилищ и кучи сетевых правил ждать по 15-20 минут, а то и больше пока terrafom (на самом деле terragrunt) очухается и очухается ли - дело такое. Особенно когда надо сделать срочные измнения, что имеет место случаться в самый не подходящий момент.
Автор как раз отметил это в своей статье: Можно создавать инфраструктуру, которая сама подстраивается под нагрузку, автоматически разворачивает тестовые окружения, оптимизирует затраты...
И это ни разу не фантастика, особенно когда начинается оптимизация затрат на инфраструктуру или игра в cast cutting. Либо проект настолько громозкий, что для тестов надо генерить определённую часть окружения. Причём, для разных тестов разные варианты ландшафтов надо генерить. Потом их удалять на выходные или в конце рабочего дня (cast cutting).
Как инструмент управления инфраструктурой pulumi не должен управлять инстансами. Это как раз задача инструментов императивного управления. В коде pulumi может быть описана установка агента управления или создания пользователя / пользователей с закидыванием соответствующих публичных ключей ssh.
А так уже каждый может извращаться как хочет. Встречал рассказ, как в компании даже дашборды мониторинга в Grafana накатываются с помощью terrafom.
Ничто не мешает не миксовать и не варганить кастрюлю венегрета. Это больше по части code style. Для демонстрационной статьи вполне пойдёт.
Всё верно пишите. В ansible и terraform это не более чем формат описания конфигурации, но никак не программирования.
Не сказать что очень простой. Тот же hcl свои причуды и нюансы имеет. Для описания инфраструктуры не обязательно изучать ЯП и алгоритмы до состояния готовности пройти лайвкодиниг и алгособес в яндекс или т-банк.
Если позволите, немного добавлю коментариев и внесу небольшую ясность в некоторые вопросы?
Control Plane и сейчас в некоторой литературе зовут master nodes (мастер нодами). А рабочие ноды раньше звались миньонами))
Не совсем корректная формулировка. ETCD - это одна из основных частей мастер нод. Иногда можно встретить ироничное высказывание, что если убрать авторизацию и валидацию запросов, то вполне можно обойтись ETCD без Kube API server)).
В этой базе данных с довольно хорошо работающим механизмом консенсуса хранится ообще всё: от настроек всего кластера кубернетес до конфигураций и секретов непосредственно исполняемых приложений. При всей своей простоте, живучести, согласованности и быстродействии она обладает одним существенным недостатком, о котором некоторые не знают, а кто-то не вспоминает - максимальный размер этой базы составляет 8 ГБ. Поэтому когда хочется запихнуть всего и больше в виде конфигураций и секретов тем более на большом кластере, можно внезапно получить не всегда понятный сбой.
Это довольно редкий паттерн, когда пытаются разнести CP-часть (Consistent & Partition-tolerant) и AP-часть (eventual consistency) в случаях больших кластеров. Большинство же облачных провайдеров использует запуск запуск ETCD на одних машинах с остальными компанентами Control Plane.
Довольно странный кейс. Приложение можно преспокойно запустить без указания в манифестах (чартах): limits/request, healthcheck, pod distribution budget, QoS, HPA/VPA. Например, nginx взлетает на самом минимальном конфиге без всяких условий. Наверное поэтому его часто используеют в качестве примера в официальной документации.
Здесь хочется внести небольшую правку: не контейнеры, а поды, потому что они являются единственной и основной единицей работы в кластере кубернтес и в одном поде может быть много контейнеров.
Случай, когда кубернетес следит за загруженностью (перегружены, недогружены) обычно связан с темой горизонтального, реже вертикального масштабирования и обычно рассматривается отдельно по итогам нагрузочных тестов или хаос инжиниринга.
Повторная неточность/ошибка. Kubernetes не оперирует контейнерами, Kubernetes работает с подами. Если речь идёт о добавлении новых контейнеров в под, то это лишь часть описания манифеста, и там главное не запороть формат yaml-файла. В остальном процедура довольно простая.
Что касается правильного поведения приложения при его горизонтальном масштабировании, то это вообще никак не коррелирует со средой исполнения. Если приложение не заточено под Partition-tolerant, то ждать чудес, а потом поносить на чём свет стоит кубы, облака, девопсов/СРЕ, ну знаете - сами себе злобные буратины.
Ну знаете, при том количестве ресурсов (особенно дисковых), которых требуется мастер-узлам, экономить, уже кажется проявлением скаредности. Даже такие продукты как Kind и K0s (кубы на максимальных минималках) предполагают, что у вас будет выделенный сервер (виртуалка) для мастер-ноды и отдельные рабочие ноды. Да, они поддерживают режим single-node, но его нужно дополнительно переопределять.
Ну это рабочая нода должна очень быстро отдать концы. В случае правильной остановке ноды, все поды будут переселены на другие ноды. Согласен, не всегда и корректно это работает особенно у облачных (отечественных) провайдеров. А так в кубах довольно рабочие механизмы переселения подов на другие ноды со всеми данными на дисках.
Правильно понимаю, что это базовое решение лично у вас, а не во всей индустрии? Проводились ли оценки наработки на отказ такой схемы? Потому что по своей парадигме Kubernetes это история про высокую доступность (СА) и консистентность с непротиворичивостью (СР) не его конёк. Про консенсус голова болит только у ETCD.
Т. е. если надо обеспечить доступность сервиса, ожмдания перевыборов лидера или завершения транзакций проводиться не будут.
С другой стороны, Ceph использует механизм консенсуса Paxos только в сервисе Ceph Monitors для согласования карты кластера, когда согласуется информация о состоянии хранилищ и пульсов для всех узлов кластера. На этом всё.
Также не стоит забывать, что созданное хранилище для пода будет размазано по всему кластеру и когда таких приложений много (что нередко при нынешней моде всё тащить в кубы), возможен неплохой over head по использованию диского пространства (базы на несколько терабайт на раз-два закидывают).
Отчего же? Сетевая модель Kubernetes основана на плоском адресном пространстве. Все поды в кластере способны видеть друг друга. Нет нужды в настройке NAT. В основе сетевого устройства Kubernetes лежит архитектурный принцип: «У каждого пода свой уникальный IP». Всё как раз очень просто.
В каком моменте вдруг может понадобиться разбираться с BGP, VXLAN, IPIP-туннелями? Установили понравившийся плагин на рабочие ноды, дальше организация сетевого взаимодействия целиком и полностью на плечах Kubernetes.
Не совсем так. Это именованная точка входа для доступа к приложению в поде (группа подов совсем не обязательна). Позволяет обращаться по доменному имени к соответствующему поду в кластере. Постоянный IP-адрес уже дело десятое как и забота внутреннего или внешнего сервера имён о преобразовании доменного имени в IP-адрес.
Ingress можно и даже нужно запускать, если это требуется на любом стенде, а не только на проде.
В чём проблема? Сам кластер Kubernetes довольно живуч и неприхотлив. То что в нём могут устроить лютое мракобесие запущенные приложения, это отдельная история.
Родной Metrics Server ставится легко и работает незаметно в отличие от некоторых систем мониторинга и логирования. Всё остальное из разряда Observabilyties довольно легко и быстро ставится готовыми чартами или операторами - больше дело вкуса и личных предпочтений.
Это довольно не самая большая боль для передачи приветов облакоделам. После AWS, GCP наши облака действительно как на Жигули пересел после хорощей иномарки.
Вообще это должно быть первым шагом! Это должен быть первый эпат, после корректного завершения которого можно начинать обдумывать переезд в кубы. Но никак не наоборот (из неоднократного личного опыта).
Типичная работа Devops-инженера. При настроенных CI и CD даже кнопку нажимать не надо. Само протестируется, просканируется, соберётся отправится куда надо (если требуется, дополнительно проверится), задеплоится на нужном стенде с необходимыми проверками, если что-то пойдёт не так или не туда, откатится обратно старую рабочую версию.
P. S. Не сочтите за трудность, вычитывайте, пожалуйста, внимательно текст после нейронок. Проявите уважение к читателям.
Пластмассовый мир победил (с)
Для первого (штрафы), второго и даже третьего у нас существует трудовая инспекция. Но тут ключевое слово существует.
Работа проделана немаленькая, где-то подсвечены некоторые интересные и в чём-то важные моменты. Только при этом есть определённые неточности, кое-где переходящие в ошибки. Своим комментарием хочу внести ясность, чтобы начинающие или уже имеющие определённый опыт специалисты Devops не совершали возможных ошибок.
Хочу начать с простенького определения Operational Excellence (OpEx) в контексте методологии Devops. Кратко можно сказать, что данная практика направлена на автоматизацию процессов, для того чтобы уменьшить фактор человеческой ошибки. Опирается на две концепции:
Operations as Code (Infrastructure as a Code)
Observability (Analytics, Metrics, Actions)
Если оставить в стороне рассмотрение Operations as Code, то Observability можно определить как создание, сбор, объединение и использование метрик, которые позволяют получить представление о состоянии системы. Грубо говоря это наши органы чувств, которые позволяют знать, как себя чувствует наша система.
Вообще Google говорит о четырёх золотых сигналах
Ну это как бы основное свойство практически всех систем мониторинга))
Он не должен с ними никак справляться)) Да и зачем экспортёру инфраструктурных метрик лазить за данными managed services облака? Это задача специально заточенных для этого экспортёров метрик
Аналогично тому что было в абзаце выше: мониторинг Operations параметров системы - это мониторинг физических ресурсов системы и к бизнес категориям имеет исчезающе мало отношений. Это история про Node and machine чем про Root cause, если говорить про разбор полётов микросервисов.
Иногда это часы рутинных созвонов, когда надо вытащить и выяснить на какое приложение (микросервис) и какие алерты ставить. С Operations alerts как раз всё намного проще.
Prometheus - это уже не просто база данных временных рядов и не только стек для мониторинга по умолчанию рекомендуемый для Kubernetes. Это не только целая экосистема со своими экспортёрами, которые ориентированы на Operations monitoring и Operations alerts, но и система позволяющая хранить и обрабатывать метрики "бизнес-логики" и метрики "микросервисов". Очень многие вещи делает буквально из коробки. Очень легко и плотно дружит с системой отображения данных Grafana, с которой неплохо дружит Jaeger.
А вот выбор стека EFK не совсем понятен. Потому что хранить и обрабатывать 1 ТБ логов (примерно столько выдаёт на гора один стенд за неделю) в S3 bucket (в случае стека Loki + Promtail) и в Elastic вещи немного разные как по цене, так и по удобству администрирования - увеличить размер бакета на живую обходится правкой одной строки в манифесте Terraform, в случае с эластиком действий будет намного больше чем просто указания нового размера диска в том же манифесте Terraform.
Service Metrics
Reliability – mean time between failure (MTBF)
Availability – Uptime, expressed as a meaningful percentage of demand
Serviceability – Mean time to repair (MTTR)
IT Metrics
Capacity
Latency
Bandwidth
Response time
Strategic Metrics
Business agility
Customer engagement
Customer reach
Financial impact
Solution performance
Ссыль
Это может выполняться только при грамотной и протестированной программной и инфраструктурной архитектуре. А так ни один мониторинг не спасёт от неработающего мастабирования при росте нагрузке и сбоев в коде приложений.
Система мониторинга должна отвечать на два вопроса: "что сломалось" и "почему сломалось". "Что сломалось" говорит о симптоме, а "почему сломалось" о причине.
Это будущее агентов ИИ для систем мониторинга)) А пока к таким удобоваримым и понятным объяснениям надо приходить самостоятельно. И ещё потом доказывать службе поддержки облачного провайдера.
Звучит красиво, но обычно ни один observability-стек ничего не знает об обновлении версий Redis. Ну и анализ логов, обычно ручная операция.
Можете более расширено раскрыть про культуру работы с данными (у нас их много и разных этих данных) в контексте observability?
Как быть людям на проектах без .NET-сред или с ещё более сложными средами такими как С++ или Haskell?
Здесь надо бы добавить уточнение, чтобы было понимание.
Мониторинг White-box - Мониторинг, основанный на показателях, отображаемых внутренними компонентами системы
Мониторинг Black-box - Тестирование поведения приложения с точки зрения пользователя (тот самый пользовательский опыт и у вас в статье про него ничего нет)
P.S.
Kubernetes не будет перезапускать под при превышении лимитов CPU. OOMKill приходит по памяти, для CPU другая стратегия поведения. Поправьте, пожалуйста.
Девопсов на проекте обычно многократно меньше чем разработчиков. Иногда отсутствуют полностью.
Кстати, хорошая и грамотная команда инженеров DevOps также играет немаловажную роль - хорошо и грамотно спроектированные микросервисные приложения, могут запнуться о кривую или некудышнюю реализацию в CI/CD и инфраструктуре.
Увы, такова действительность. Не всегда бизнес готов к технологическим вызовам: аналитика в Excel, web портал на простенькой CMS, сервис ААА (autorisation, accounting, authentification) на базе AD или 1С
Вы же знаете, что согласно МКБ есть такая болезнь Яндекса в народе именуемая велосипедостроением. Со всеми вытекающими последствиями. И это чуть ли не повсеместно и практически во всех продуктах этой компании.
Куда важнее другое. Причина побудившая автора статьи на такое решение - сетевая недоступность некоторых зон доступности. Если посмотреть список инцидентов, то складывается впечатление, что сеть яндекса представляет из себя тестовый полигон для подготовки к сдаче экзаменов на получение сертификатов CCNA. Ну и при выходе из строя NLB в соответствующей зоне доступности (такое бывало и не раз) толку от такого решения мало.
Встречался и с таким паттерном, когда команда разработки думает не о продукте, а о резюме. Презабавнейшие вещи получались.
1 Реальные перечисленные проблемы
2 Про не понимание бизнесом микросервисного подхода. Неоднократно слышал пожелание о более тесной связности и зависимости приложений и приходилось доказывать обратное, что приложения (микросервисы) должны быть минимально связаны и зависимы от остальных
3 И то что большинство решающих взяться за микросервисы мало представляют уровень сложности такой разработки