Виртуализация

Не так давно мы публиковали интервью Один день из жизни разработчика VMware рассказ о карьере ИТ-специалиста в крупной международной компании.

А сейчас у нас возникла идея поискать в своем отечестве, и мы обратили внимание на российский офис VMware. Программистов в нем нет, но есть о чем поговорить с инженерами presales. Встречайте Михаил Михеев!

Если вы стояли у истоков использования виртуализации в России, то вы могли знать о нем как о человеке, который:

• вел блог по этой узкой тематике и обучающие курсы;

• участвовал в организации встреч сообщества;

• написал книгу Администрирование VMware vSphere.

Мы решили поговорить с Михаилом по душам и выведать, как он попал в ИТ, почему решил написать собственную книгу и как стал сотрудником VMware, не будучи программистом. Небольшой спойлер: оказалось, под маской уверенного в себе специалиста скрывается обычный человек. Скромный и с превосходным чувством юмора.

Эксперт с форума

Пути, по которым ведет нас жизнь, не всегда поддаются логическому анализу. Порой даже случайности, которым не придаешь особого значения, становятся решающими. Итак, представьте: Казань. Я учусь на последнем курсе университета. Стажируюсь за еду бесценный опыт у местного интегратора. (Большое спасибо им, кстати: я в первые полгода действительно не умел делать ничего полезного, чтобы просить денег.) И вот передо мной поставили задачу разобраться с неподдавшимся с наскока продуктом, Microsoft SMS 2003. Мне удалось найти один админский форум: там я искал информацию и задавал тонны вопросов в основном как раз по этому продукту. В первое время я только спрашивал, затем осмелел и начал понемногу отвечать менее опытным товарищам. Как потом выяснится, потребность делиться знаниями это неотъемлемая часть моего характера.

Мои ответы заметил форумчанин, очень много помогавший мне на начальных этапах. Можно сказать, я рос на его глазах. Совпало, что в то же самое время к нему обратился один из московских учебных центров: мол, есть ли на примете тренер, который может прочитать курс по MS SMS? И он пришел с этим предложением ко мне.

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

Сейчас я понимаю, что учебный центр тогда пошел на авантюру, доверив вести серьезный курс неопытному и неизвестному мне. Видимо, вакансия преподавателя совсем горела :)

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

Шел 2005 год. Товарищ с форума оставил мне контакты учебного центра. Представьте мое состояние: где я, студент Миша из Казани, а где это достойное заведение! Заметьте: я раньше не только лекции сам не вел, но даже слушателем подобных вендорских курсов мне бывать не доводилось. Я очень ОЧЕНЬ волновался перед звонком.

Но, как говорится, колени дрожат, а руки делают. Я согласился на этот вызов. Мы договорились о личной встрече, я съездил в Москву на собеседование, а дальше как в тумане. Чтобы я получил представление о том, как все это вообще происходит, учебный центр позволил мне принять участие в качестве слушателя на другом курсе. Затем предоставил trainer guide и назначил дату курса уже со мной в роли тренера.

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

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

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

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

(Сейчас душевная рана почти затянулась, поэтому расскажу: моя будущая жена смогла переехать лишь спустя целый год. Все это время я жил в Москве один, без нее. Это было отдельным вызовом.)

Со временем я начал читать и другие курсы по продуктам Microsoft немного, буквально две-три штуки. Учебный центр нашел еще одного нишевого вендора, и некоторые курсы по его продуктам тоже достались мне. Приблизительно в то же время (2006 год) на российский рынок вышла и VMware. Мой учебный центр оперативно заключил с ними соглашение, и я стал первым преподавателем по vSphere (тогда продукт носил немного другое название) на территории РФ. Наверное, достаточно долгое время я был вообще единственным. Как и сейчас, курс назывался Install, Configure, Manage (ICM). Добротный и весьма полный материал для подготовки молодых бойцов в сфере виртуализации.

Личный блог для самообучения

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

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

Затем я открыл для себя мир блогов. Они стали сами собой появляться по всему интернету: гуглишь что-то специфическое, и бац! выдается чей-то личный блог. Я перешел в фазу жадного поглощения информации и спустя короткое время оказался подписан буквально на десятки тематических блогов. Тогда я столкнулся со следующей проблемой: оказалось, недостаточно просто прочитать информацию, чтобы ее запомнить. Мне нужен был способ пропустить знания сквозь себя, выделить наиболее важные моменты и усвоить их. Так и возник мой собственный блог не из желания продвинуть свою фигуру, а чтобы важная информация откладывалась в голове через написание статей и заметок. Надо сказать, этот шаг тоже дался мне непросто. Все-таки, это публичное поле, новая ответственность :)

Работа преподавателем, с одной стороны, заставляла меня постоянно получать новые знания, с другой оставляла много свободного времени на учебу. Либо тренинги удавалось закончить немного пораньше, либо выдавались свободные недели, и я мог активно постить в блог. Можно сказать, я тогда занимался на 90% именно переработкой: публиковал короткое резюме-выдержку со ссылкой на оригинальную заметку.

Эта схема себя оправдала: со временем в блог подтянулась моя аудитория. Люди комментировали, задавали вопросы, даже уточняли что-то. Это давало много пищи для изучения. Забавно, что в какой-то момент я столкнулся с тем, что мне задают вопрос, я ищу ответ и нахожу его у себя же в блоге. Получалось, я забывал даже то, о чем сам писал.

Огонь в глазах, дискуссии и споры

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

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

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

Так я заметил еще один момент: в каждой группе между инициативными слушателями возникали дискуссии, споры. Я поощрял такие ситуации, даже говорил: Ребята, так получилось, что преподаватель здесь я, но у многих из вас есть опыт, которого нет ни у меня, ни у ваших коллег. Обменивайтесь этим опытом!. Наблюдая со стороны, я обратил внимание на то, что многие споры возникали из-за недопониманий между людьми. Два человека могли говорить об одном и том же, но разными словами. Или для обозначения разных понятий использовали одни и те же термины. Я старался всеми силами минимизировать такие ситуации, выводя спор в конструктивное русло. Дискуссии хороши, если обе стороны понимают друг друга и не пускаются в терминологические споры. Возможно, эта практика помогала людям учиться эффективнее и, в том числе, находила свое отражение в позитивных отзывах.

Мужики в свитерах: правда или вымысел?

Пару слов скажу о контингенте на моих курсах: на 98% процентов это были системные администраторы и инженеры заказчиков или интеграторов. Как правило, характеры у тех, кто представляет заказчиков, отличаются от тех, кто пошел на работу к интеграторам. Это, скорее, курьезное наблюдение, чем строгое. Что касается возраста были все, от молодежи до зрелых специалистов. Люди постарше приходили, конечно, реже.

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

Когда в 2008-ом у меня вышла собственная книга и в узких кругах я стал Тем-Самым-Михаилом-С-Книжкой, я даже дежурно шутил: жаль, что в ИТ мало девушек. Приятно, конечно, когда бородатые мужики в свитерах пожимают тебе руку и говорят, какую классную книгу ты написал. Это льстит. Но все равно это бородатые мужики в свитерах

(На всякий случай еще раз поясню: это дежурная шутка!)

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

Как писалась книга

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

Я хорошо запомнил день, с которого все началось. Меня тогда отправили в командировку в Хабаровск как раз таки с курсами по VMware. Время от времени я летал с учебными задачами, в основном по отдаленным от Москвы местам: Казахстан, Баку, Дальний Восток. А длительный перелет это смена часовых поясов и неминуемый джет лаг.

Представьте себе: 4 часа утра. Гостиница, сна ни в одном глазу. Чтобы занять руки, отвечаю на вопрос читателя моего блога. Гуглю, чтобы уточнить информацию и попадаю... правильно, в собственный блог! Выходит, я все это знал, даже писал об этом, но забыл. За пониманием пришло озарение: а что, если я возьму и зафиксирую свои текущие знания в виде книги? Под рукой как раз была программа для составления mind mapов, в ней я начал накидывать приблизительное содержание про что и в каком порядке можно рассказать. Это был первый подход: крупные мазки, обширные планы.

Запала хватило на то, чтобы написать начало, а потом я стал перегорать. Не знаю, продвинулся бы я дальше, если бы не очередное удивительное совпадение. Спустя короткое время я поехал на конференцию VMware. Во время перерыва ко мне подошел представитель нишевого издательства: Вы Михаил Михеев? Очень приятно. Мне посоветовали обратиться к вам по поводу написания книги по теме виртуализации. Звезды сошлись: мысли о книге одновременно пришли в голову и мне, и издателю.

(Только сейчас понял, что забыл спросить у представителя издательства, кто указал ему именно на меня!)

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

Есть несколько воспоминаний из той поры:

• Издатель выдал набор правил оформления рукописи (подозреваю, что-то из области ГОСТов). А-ля пункты нумерованного списка должны заканчиваться точкой, а не-нумерованного точкой с запятой, кроме последнего, где тоже нужна точка. Запомнить все эти заморочки оказалось непросто, но в дальнейшем эти знания мне не раз пригодились.

• Скриншоты это сущий ад. На них уходила если не бльшая, то как минимум львиная доля времени. А в инструкции от издателя было указано: скриншоты сохраняйте в таком-то формате, притом обязательно черно-белые. Я люблю делать все по инструкции, поэтому не противился. И угадайте что? Оказывается, инструкция не учитывала существование электронных версий книг, где, очевидно, не имеет смысла черно-белить картинки. Подозреваю, издатель попросту не подумал об электронной книге (да-да, смешно звучит с высоты 2021 года). А для меня это обернулось повторным созданием почти всех скринов, так как исходники я почему-то не сохранял.

• Знали бы вы, как я стеснялся выложить анонс у себя в блоге. Очень сильно нервничал :)

Всего было три релиза: первый по 4-ой версии vSphere, второй по 4.1, а последний был посвящён уже 5-ой версии. Бумажные издания оформлены в разных цветах, чтобы читатели не путались.

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

В свое время я шутил: мол, я написал самую лучшую книгу по VMware на русском языке. Знаете, почему? Потому что единственную, других нет.

В какой-то момент я увидел свою книгу на торрентах. Примерно в тех же раздачах, что и продукты VMware. Эмоции я испытал сложные. С одной стороны, по моему карману это не ударило. С другой было чуть-чуть обидно из за потери права распоряжаться своим детищем.

Один писатель-фантаст сказал: автор [в случае пиратства] теряет не столько деньги, сколько право распоряжаться плодом своего труда. В правовом поле автор может убрать свое произведение из конкретного магазина или вообще изъять из продажи. С условным торрентом это не так, это обидно. Вне зависимости от того, будешь ты что-то такое делать или нет.

Меня часто спрашивают, пишу ли я новую книгу. Короткий ответ нет. Чаще всего отшучиваюсь: мол, куда, у меня уже двое детей!

А если серьезно я и блог-то уже лет 7 не веду. Когда я был занят преподаванием, и блог, и книга были частью моей работы. В том числе, над собой. Моя текущая работа в VMware оставляет намного меньше времени на такие проекты. Честности ради в какой-то момент я предпринял еще одну попытку обновить книгу, но буквально через неделю понял: нет, не стоит этим заниматься. На предыдущем жизненном этапе у меня была четкая цель: что я хочу сделать, для кого и зачем. А книга ради книги это никому не интересно.

Сам собой назревает дискуссионный вопрос: вот я молодой, горящий специалист, есть ли мне смысл заявить о себе, написав книгу? [не суть важно, но, допустим, по решению VMware].

Выскажу свое мнение.

С одной стороны, сейчас у VMware есть продукты, по которым нет русскоязычных материалов. Так что смысл написать по ним книгу имеется, у специалистов она будет востребована. Но насколько велика будет аудитория? Вопрос открытый. К примеру, первый тираж моей книги составил порядка 5 тысяч экземпляров (за давностью могу ошибаться).

Это много или мало?

C другой стороны, старая добрая книга это уже немного олдскул. Есть блоги, есть YouTube. Есть Telegram-каналы, в конце концов. Может, лучше в эту сторону копнуть?

Готовогоответа у меня нет, но мне кажется, что классическая книга по-прежнему имеет смысл. Все-таки, когда ты говоришь: я Миша, автор [например] Telegram-канала такого-то или я автор такой-то книги, эффект получится разным.

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

Как я попал в VMware

Наступил 2011 год. К тому моменту я уже имел около 6 лет преподавательского стажа. Популярность VMware и, соответственно, номенклатура курсов росли. Бывало так, что в течение месяца я мог читать один и тот же курс двум-трем разным группам.

С одной стороны, работа мне нравилась: я получал удовольствие от общения с людьми. Любил объяснять какие-то нетривиальные моменты. А с другой стал замечать, что прихожу на работу в понедельник, а голова включается только к среде. Рутина. Вышел к доске и пошел по накатанной: одни и те же слова, одни и те же шутки. Всем, вроде, нравится, а мне нет.

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

Помнится, сижу я в больнице. Жду приема врача. Раздается звонок с незнакомого номера: оказалось, звонит руководитель пресейлов VMware. Предлагает пообщаться. Я тогда ничего не понял какую именно работу мне предлагают, чем я буду заниматься... Но все равно согласился на встречу.

По итогам собеседования меня приняли. В силу того, что в учебном центре существовал определенный горизонт планирования на пару месяцев вперед, когда набрана группа, составлен график, у слушателей куплены билеты и командировки, сразу же уйти я не мог. В VMware мне пошли навстречу, я доработал необходимый срок, съездил в небольшой отпуск в Питер и 13 февраля вышел на работу.

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

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

Значимую долю времени занимает обучение на внутренних и внешних курсах. Мир развивается, портфолио развивается, продукты обзаводятся новыми функциями и возможностями. Без обучения никак.

Кстати: еще в задачи пресейл-инженера входит обучение заказчиков и партнеров, а также выступления на различных мероприятиях. Например, в этом году наши пресейлы проводят цикл весенних вебинаров VMware 2021, которые будут идти до июня. На них можно не только послушать экспертов, но и пообщаться с ними в чатах и Q&A. Зарегистрироваться на вебинары можно на сайте, а посмотреть онлайн-мероприятия в записи на нашем YouTube-канале. А для энтузиастов у нас есть канал в Telegram: там мы напоминаем о старте вебинаров и делимся видео.

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

Как водится, решение пойти в эту область не было для меня легким. Другие задачи, другая ответственность, потенциально иные отношения с коллегами. В новые обязанности мне удалось войти не спеша, совмещая их с работой пресейла. Более того, я по прежнему прикладываю усилия чтобы оставаться одной ногой на земле. Оторваться всегда легко, а вернуться обратно, как говорят старшие товарищи, невозможно.

Немного об изоляции

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

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

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

Кто востребован в VMware

Наверное, я сейчас скажу не самую очевидную вещь. Нам не особо важно, является ли человек экспертом в продуктах VMware. Этому мы как раз можем научить на месте: и ресурсов, и учебных материалов, и опыта у нас достаточно. Любые ИТ-продукты это не квантовая физика. Получить нормальную или даже отличную экспертизу в них можно. Главное воспринимать это не как проблему, а как задачу. Попробовал получилось. Поотвечал на вопросы и сам не заметил, как освоил тему.

Гораздо сложнее научить человека soft-скиллам и такому навыку, как доведение дел до конца. Работы больше, чем времени в сутках, поэтому всегда есть соблазн что-то здесь поделать, там поковырять, но до конца не доводить. Льется нескончаемый поток задач, и ты думаешь: я буду что-то отдельное выхватывать. Это не очень хорошая история. Если уж взялся делай. Не берешься скажи. Не оставляй повисшим в воздухе.

Один из главных soft-скиллов уметь говорить на языке собеседника. Отличным примером является известный в хаброкругах Milfgard. Помните шикарную статью про недочеты в унаследованной архитектуре живых существ? Огонь же! И в том числе потому, что материал подан на языке читательской аудитории.

Вернемся к теме. При всем вышесказанном айтишный бэкграунд иметь все-таки желательно. Научить продуктам можно, но если вообще никакого бэкграунда нет, это может стать большой проблемой. С другой стороны, нам бывают нужны люди с разным рабочим опытом. Где-то сетевой бэкграунд более важен, где-то менее, например.

Из очевидных требований сотруднику необходим разговорный английский. VMware мировая компания, на ежедневной основе люди работают в интернациональных группах, обращаются за консультацией или помощью к западным коллегам. По-моему, это здорово, когда ты в рамках рабочего общения можешь поговорить с крутыми людьми, представителями родственной профессии, живущими в другой стране или даже части мира. Прикоснуться к их культуре, менталитету. Незабываемый опыт. Отдельная приятность прямой доступ к Product Managerам, которые непосредственно отвечают за развитие продуктов (нередко прямо в Кремниевой долине, с географической точки зрения). Лично мне очень импонирует возможность обратиться к первоисточникам, а то и пригласить их на конф-колл по проекту с заказчиком.

Немного о Хабре

Хабр для меня один из главных источников информации из разных сфер.

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

Просто просмотр заголовков статей в RSS-клиенте позволяет составить мнение о событиях мира ИТ в целом.

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

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

Ну и нельзя не сказать, что именно с его статьи Настольные игры: во что играют в IT-офисах? от далекого 2011 года началось мое нынешнее увлечение настольными играми, в котором я весьма глубоко погряз :)

Друзья! Если вам интересен такой формат, будем рады вашим пожеланиям. Поделитесь в комментариях, интервью с представителями каких сфер и профессий вам бы хотелось видеть на Хабре.

В интернете кто-то неправ

Не далее пяти дней назад на хабре появилась новость под заголовком "В Apple M1 нашли уязвимость M1RACLES возможна быстрая скрытая передача данных между приложениями". В одном предложении суть формулируется так: в Apple M1 нашли регистр, который кто угодно может читать и писать из непривилегированного режима. Значит, это можно использовать для обмена данными в обход механизмов межпроцессного взаимодействия, предоставленных ОС. Однако, сам автор эту особенность значимой уязвимостью не считает, о чём пишет в разъяснительном комментарии:

So what's the point of this website?
Poking fun at how ridiculous infosec clickbait vulnerability reporting has become lately. Just because it has a flashy website or it makes the news doesn't mean you need to care.

If you've read all the way to here, congratulations! You're one of the rare people who doesn't just retweet based on the page title :-)

But how are journalists supposed to know which bugs are bad and which bugs aren't?
Talk to people. In particular, talk to people other than the people who discovered the bug. The latter may or may not be honest about the real impact.

If you hear the words covert channel it's probably overhyped. Most of these come from paper mills who are endlessly recycling the same concept with approximately zero practical security impact. The titles are usually clickbait, and sometimes downright deceptive.

В комментариях к этой публикации развязалась умеренно оживлённая дискуссия о статусе находки: всё-таки серьёзная уязвимость или пустяк? Наряду с @SergeyMaxи @wataru я обратил внимание, что каналов скрытого обмена и так существует предостаточно просто потому, что исполняющая клиентский софт или виртуальные машины аппаратура является разделяемой средой, грамотная модуляция состояний которой делает возможным произвольный обмен данными вне зависимости от инвариантов нижележащей ОС или гипервизора. Противоположной точки зрения придерживаются почтенные господа @creker и @adjachenko, утверждая, что доселе известные побочные каналы качественно уступают возможностям M1RACLES.

Эта заметка является наглядной иллюстрацией к моему утверждению о легкодоступности скрытых каналов обмена. Я собрал простой PoC из ~500 строк на C++, при помощи которого был успешно отправлен файл из одной виртуальной машины в другую на том же физическом хосте. Далее я кратко описываю его устройство, пределы применимости, и привожу выводы и мнение самого автора M1RACLES в конце.

Я не являюсь специалистом по информационной безопасности, поэтому чрезмерно полагаться на мои собственные выводы в конце статьи не следует.

Передача

Повторю ключевой тезис для прозрачности: в общем случае, полная информационная изоляция исполняемых на едином аппаратном узле сред невозможна, потому что общая среда исполнения является разделяемым ресурсом, модуляция состояний которого может использоваться для построения каналов обмена данными. Гипервизоры, MMU, ОС, и прочие информационные барьеры могут лишь затруднить скрытый обмен данными, но не предотвратить его.

В случае M1RACLES, Apple случайно положила подходящий аппаратный ресурс на самое видное место. В других платформах общих регистров может не быть, но остаются другие средства. Сегодня мы сфокусируемся на вычислительных ресурсах процессора; любознательный читатель может в качестве факультатива слегка модифицировать код PoC, чтобы вместо процессорного времени модуляции подвергались, скажем, температура видеокарты, задержка доступа к файловой системе или RAM (забиванием кэша), и т.п.

Известная теория обработки сигналов предлагает метод кодовой модуляции, широко применяемый для широкополосной передачи через зашумлённую среду. Кодовая модуляция позволяет получателю вытянуть полезный сигнал из-под шумовой полки, если известна кодирующая последовательность; для остальных же наблюдателей (включая приёмники с другой кодирующей последовательностью) сигнал будет выглядеть как шум. Единая среда может поддерживать теоретически неограниченное количество передатчиков с разными кодирующими последовательностями при условии их достаточного различия.

Мы будем передавать высокие уровни кодирующего сигнала повышая нагрузку на процессор, и наоборот:

void drivePHY(const bool level, const std::chrono::nanoseconds duration){    static auto deadline = std::chrono::steady_clock::now();    deadline += duration;  // Используем абсолютное время для предотвращения дрейфа фазы сигнала    if (level)  // Передаём высокий уровень высокой нагрузкой    {        std::atomic<bool> finish = false;        const auto loop = [&finish]() {            while (!finish) { }        };        static const auto thread_count = std::max<unsigned>(1, std::thread::hardware_concurrency());        std::vector<std::thread> pool;        for (auto i = 0U; i < (thread_count - 1); i++)        {            pool.emplace_back(loop);        }        while (std::chrono::steady_clock::now() < deadline) { }        finish = true;        for (auto& t : pool)        {            t.join();        }    }    else  // Низкий уровень -- низкой нагрузкой    {        std::this_thread::sleep_for(deadline - std::chrono::steady_clock::now());    }}

В примере мы нагружаем все ядра, что весьма расточительно. Можно нагружать лишь одно ядро, если ОС предоставляет API для задания CPU core affinity (macOS, насколько мне известно, не предоставляет), но это создаст трудности в преодолении барьеров виртуализации, потому что одно ядро внутри гипервизора может отображаться на другое физическое ядро хоста. Однако, если API для affinity есть, и нет нужды пробрасывать канал передачи между изолированными виртуальными средами, можно сделать так:

#include <pthread.h>  // -lpthreadcpu_set_t cpuset{};CPU_ZERO(&cpuset);CPU_SET(0, &cpuset);pthread_setaffinity_np(pthread_self(), sizeof(cpu_set_t), &cpuset);

Как уже сказано, один бит передаётся прямым или инверсным кодом:

constexpr std::chrono::nanoseconds ChipPeriod{16'000'000};  // ок. 1...100 мсstd::bitset<CDMACodeLength> CDMACode("...");                // код пропущенvoid emitBit(const bool value){    for (auto i = 0U; i < CDMACode.size(); i++)    {        const bool bit = value ^ !CDMACode[i];        drivePHY(bit, ChipPeriod);    }}

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

void emitByte(const std::uint8_t data){    emitBit(1);   // Стартовый бит    auto i = 8U;  // Старший бит идёт первым    while (i --> 0)    {        emitBit((static_cast<std::uintmax_t>(data) & (1ULL << i)) != 0U);    }}void emitFrameDelimiter(){    for (auto i = 0U; i < 20; i++)  // не менее 9 нулевых битов    {        emitBit(0);    }}

Для обнаружения ошибок в конце каждого пакета добавим два байта обыкновенной CRC-16-CCITT:

void emitPacket(const std::vector<std::uint8_t>& data){    emitFrameDelimiter();    std::uint16_t crc = CRCInitial;    for (auto v : data)    {        emitByte(v);        crc = crcAdd(crc, v);    }    emitByte(static_cast<std::uint8_t>(crc >> 8U));    emitByte(static_cast<std::uint8_t>(crc >> 0U));    emitFrameDelimiter();}

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

Приём

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

bool readPHY(){    static auto deadline = std::chrono::steady_clock::now();  // См. заметку о дрейфе фазы    deadline += SampleDuration;    const auto started_at = std::chrono::steady_clock::now();    std::vector<std::int64_t> counters;    const auto loop = [&counters](std::uint32_t index) {        auto& cnt = counters.at(index);        while (std::chrono::steady_clock::now() < deadline)        {            cnt++;        }    };    static const auto thread_count = std::max<unsigned>(1, std::thread::hardware_concurrency());    if (thread_count > 1)    {        counters.resize(thread_count, 0);        std::vector<std::thread> pool;        for (auto i = 0U; i < thread_count; i++)        {            pool.emplace_back(loop, i);        }        for (auto& t : pool)        {            t.join();        }    }    else    {        counters.push_back(0);        loop(0);    }    const double elapsed_ns =        std::chrono::duration_cast<std::chrono::nanoseconds>(std::chrono::steady_clock::now() - started_at).count();    const double rate = double(std::accumulate(std::begin(counters), std::end(counters), 0)) / elapsed_ns;    static double rate_average = rate;    rate_average += (rate - rate_average) / PHYAveragingFactor;    return rate < rate_average;  // Просадка производительности если передатчик нагрузил ЦП}

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

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

Полученный зашумлённый сигнал с удалённым постоянным смещением мы направляем в CDMA коррелятор, как я изобразил на схеме:

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

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

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

Знакомый с обработкой сигналов в телекомах читатель сейчас понимающе позёвывает, ведь похожие принципы используются во многих распространённых приложениях, от GPS до сотовых сетей. Для сравнения, типичная архитектура приёмного тракта GPS приёмника выглядит примерно так (каналы Qx на схеме можно проигнорировать, поскольку квадратурное разложение в нашей среде смысла не имеет):

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

Прямое применение кодов Хэмминга здесь вряд ли оправданно, потому что условия, при которых могут возникать битовые инверсии сигнала, неизбежно приведут к искажениям тактового сигнала, из чего последуют пропуски либо спонтанное защёлкивание бит, что сделает коды Хэмминга неэффективными. Более совершенные методы коррекции ошибок вроде кодов Рида-Соломона или LDPC представляют интерес, но их реализация несколько выходит за рамки этого эксперимента ввиду сравнительно высокой сложности.

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

https://github.com/pavel-kirienko/cpu-load-side-channel

Результат

Процесс передачи файла с одной виртуалки на другую я записал на видео:

Условия здесь были далеки от идеальных, потому что в фоне на хосте виртуализации работал ffmpeg (записывающий это видео в 4K в реальном времени на процессоре), браузер с ~30 вкладками и музыкой, вечно голодная до ресурсов плазма с виджетами и обычный набор каждодневного софта на моей рабочей станции. Я привожу это в качестве дополнительной иллюстрации (очевидного) факта, что устойчивость канала к шуму является лишь вопросом минимальной скорости передачи.

Последняя может вызвать у читателя здравое недоумение: на видео, тактовый период кодирующей последовательности был равен 16 мс, и её длина 1023 бит, т.е., передача одного бита занимала примерно 16 секунд, давая скорость около 0.06 бит в секунду. Передача семибайтового файла с CRC и разделителями заняла почти полчаса. Много ли можно дел наворотить на такой-то скорости?

Если сравнивать с M1RACLES (скорость передачи более 8 Mb/s), то нет. Если сравнивать с популярным предположением по-умолчанию об информационной изоляции виртуализированных сред (скорость передачи 0 b/s), то да.

Преодоление барьеров виртуализации сильно зашумляет канал, что требует использования более длинной кодирующей последовательности. Также увеличивается временной джиттер, что требует и увеличения продолжительности тактового периода. Процессы же в пределах одной ОС могут коммуницировать на скорости более одного бита в секунду, в чем легко убедиться на практике, поменяв параметры ChipPeriod и CDMACodeLength в PoC (я экспериментировал на Manjaro с ядром 5.4 на Intel Core i7 990X @ 4 GHz).

Поддержание канала в текущей реализации требует постоянной полной загрузки процессора (или хотя бы одного его ядра) процессом-приёмником, что может стать серьёзным ограничением. Это, вероятно, можно обойти использованием более сложных схем модуляции, либо модуляцией состояний других системных ресурсов; например, загрузки диска или кэша процессора. Желающие поэкспериментировать приглашаются поделиться результатами.

Также было бы интересно поэкспериментировать с передачей за пределы изолированных систем (airgapped networks), о чём писал Mordechai Guri и многие до него. Для этого можно подвергать модуляции шум системы охлаждения, температуру её выхлопа, ЭМИ, светодиоды на клавиатуре, и вообще всё, что имеет видимые внешние проявления.

Выводы

Я опубликовал заметку в /r/netsec об этом эксперименте, где в комментариях отметился Hector Martin, автор M1RACLES. Моя изначальная позиция была следующая: побочные каналы присутствуют всегда и в любой системе; M1RACLES лишь добавляет ещё один, а значит, это ничего кардинально не меняет. Если считать его уязвимостью, это делает любую систему в принципе уязвимой по-умолчанию, ведь побочные каналы устранить невозможно; значит, сам термин "уязвимость" применимо к компьютерным системам теряет информационную нагрузку.

Вероятно, сведущему в инфобезе человеку такой взгляд на вещи покажется наивным, я мало знаком с этой областью. Hector Martin скорректировал мои заблуждения, указав на то, что уязвимость как абсолютная метрика бессмысленна, всегда необходимо учитывать контекст. В этом смысле, наличие высокоскоростного канала скрытого обмена несколько расширяет множество реализуемых атак, следовательно, M1RACLES является вполне реальной уязвимостью, пусть и по-прежнему крайне малой значимости. Ниже релевантная часть его комментария для полноты:

We already know all systems are vulnerable to certain side-channel attacks. In particular, all systems with shared resources have side channels. Those side channels are easy to turn into covert channels, as you did. The bandwidth, and the severity, is proportional to how closely coupled the security domains are (as you found out, where the VM boundary reduces your performance). As the severity gets higher, you go from 1 bit per second covert channels, to megabytes per second covert channels, to actually being able to steal data from noncooperative entities (actual dangerous side channels) under increasingly less demanding circumstances.

[...]

So M1RACLES is interesting because it is not a side channel - so it poses no danger of leaking data from unwitting processes - but it is a highly efficient covert channel, which does matter under a very small but not nonexistent set of attack scenarios. Does it add covert channel capability where none existed prior? No. But that doesn't mean it's not a vulnerability; as I said, we don't qualify systems on some kind of absolute "vulnerable/not vulnerable" scale. We look at individual issues and then figure out how they affect the overall security of the system under certain attack scenarios.

Заодно он жёстко раскритиковал работу Mordechai Guri, указав на околонулевую дельту его публикаций. Однако, это я не берусь комментировать, поскольку в инфобезе не ориентируюсь. Для меня это всё представляет интерес лишь в контексте технической реализации обработки сигналов, нежели значения для отрасли.

Финальные выводы я сделал следующие:

• ОС и гипервизоры не являются средствами информационной изоляции и не в состоянии предотвратить межпроцессный обмен данными.

• Однако, скрытый межпроцессный обмен серьёзной угрозой не является.

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

О технологии RemoteFX от Майкрософт, которая повышает качество работы в режиме удалённого рабочего стола, известно давно. В интернете хватает материалов, демонстрирующих её эффективность. Но большинство оценок носят качественный характер: "вот играем в %game_name%, fps в норме", "вот запустили 3D софт, как будто локально работает! Скриншот здесь, видео там".

В данном исследовании мы разберёмся, как перейти от "попугаев" к конкретным метрикам, чтобы количественно оценить эффективность технологии и объективно сравнить её использование с обычным режимом RDP.

Кратко о RemoteFX

Традиционный RDP работает так, чтобы как можно больше работы по отрисовке окна удалённого рабочего стола переложить на клиента: по сети передаются графические примитивы и инструкции, которые должна выполнить клиентская видеокарта. Такой подход, в случае показа видео или использования интерфейса Windows Aero, требует поддержки со стороны клиента. Иначе вместо Aero будет использована упрощённая схема, а обработанный CPU сервера видеопоток передан клиенту в виде растровой графики, производительность отрисовки при этом может оказаться просто неприемлемой. Поэтому приходилось выбирать: либо использовать традиционный RDP только в связке с достаточно производительным клиентским железом, либо отказываться от сложной графики.

При включении RemoteFX клиенту по сети по прежнему передаются растровые кадры. Но есть два существенных отличия от традиционного RDP. Во-первых, вся подготовка и обработка графики перекладывается на GPU сервера, это происходит намного быстрее и разгружает CPU. А во-вторых, используется сжатие кадра, которое выполняет кодек RemoteFX. Это существенно снижает объём передаваемых по сети данных, тем самым разгружая канал связи. Это существенно снижает требования к клиентскому железу, но сохраняет достаточный уровень отрисовки и отзывчивости удалённого рабочего стола.

Конфигурация тестовой среды

Сервер

• 2 vCPU Intel(R) Xeon(R) CPU E5-2696 v4 @ 2.20GHz

• 8 GB RAM

• GPU NVIDIA GRID M60-1Qб, Dedicated Memory 929 MB, Shared Memory 4095 MB

• гостевая ОС Windows Server 2019 Standart x64 1809 (Version 10.0.17763.1577), DirectX 12

• network in/out rate limit 50 Mbps

Клиент

• Intel(R) Core(TM) i5-7600K CPU @ 3.80GHz, 3801 МГц, ядер: 4, логических процессоров: 4

• 16 GB RAM

• network in/out rate limit 100 Mbps

• OS Windows 10 Pro 2004 (Version 10.0.19041.685), DirectX 12

• настройки RDP-сеанса

  • 1920 x 1080 (32 bit) (32Hz)

  • на вкладке "Взаимодействие" выбрано "Локальная сеть (10 Мбит/с и выше)"

Выбор показателей для измерений

Качество и производительность удалённого рабочего стола нужно оценить с точки зрения как пользователя, так и потребления облачных ресурсов. Будем собирать данные о частоте кадров отрисовки, задержках отклика на ввод данных, сетевом трафике и загрузке CPU/GPU/RAM. Метрики выбраны с учётом официальныхрекомендаций по диагностике.

Замеры выполним с помощью стандартного средстваСистемный монитор. Для этого на каждый тест определим свой сборщик данных, который в течении двух минут будет каждую секунду фиксировать в двоичном blg-файле журнала показания счётчиков:

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

Методика тестирования

Чтобы оценить эффективность использования выделенной видеокарты на облачным сервере, нужно провести две серии одинаковых тестов: до и после включения отрисовки удалённого рабочего стола на GPU.

В каждой серии выполним следующие тесты:

1. ввод текста

2. ввод текста + 3D BenchMark

3. ввод текста + просмотр локальных видеофайлов

4. ввод текста + просмотр youtube-ролика

Для оценки влияния теста на задержку обработки ввода от пользователя поверх основной программы открывается стандартныйБлокноти зажимается произвольная клавиша. Окно редактора на протяжении теста будет постоянной частью всех кадров, поэтому исказит результат в лучшую сторону. Чтобы снизить эффект, размер окна уменьшим до 122*156% 99% кадра будут меняться и визуально будет видно, что имитация активности пользователя работает.

Тест #1: ввод текста

В качестве тестоврекомендуется"использовать любые приложения, которые плотно работают с графикой (например, потоковое видео), приложения, использующие DirectX". Результаты первого теста, с точки зрения пользователя (частота кадров и задержка ввода), практически одинаковые. Поэтому строить графики и анализировать их нет особого смысла. Такой тест больше пригодится для диагностики RemoteFX.

Тест #2: ввод текста + 3D BenchMark

Выполнялся при помощи FurMark в полноэкранном режиме.

Тест #3: ввод текста + просмотр локальных видеофайлов

Локальные видеофайлы воспроизводились в Windows Media Player, равёрнутом на весь экран, без установки каких-либо дополнительных кодеков, по кругу в следущем порядке:

1. "Ants carrying dead spider": 1920 x 1080, 10667 кбит/с, 19 секунд, 29.97 fps

2. "Flying Through Forest 1": 1920 x 1088, 48072 кбит/с, 9 секунд, 25 fps

3. "Low Angle Of Pedestrians Walking In Busy Street, Daytime": 4096 x 2160, 31721 кбит/с, 13 секунд, 25 fps

Единственным критерием отбора была динамичность ролика: видеоряд должен был как можно сильнее нагрузить кодек RemoteFX. Но ролик "Flying Through Forest 1" оказался в этом плане интересной находкой: выходной FPS заметно проседал, а входной от запуска к запуску был сильно выше или ниже среднего! Его влияние на различные метрики будет заметно на графиках, которые будут ниже.

Тест #4: ввод текста + просмотр youtube-ролика

В качестве youtube-теста был выбран чудесный ролик "Коста-Рика", который проигрывался в качестве1080p60в браузере Firefox, режим "киоск".

Обработка данных и построение графиков

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

Сначалаконвертируем двоичные файлы в csv (см. Приложение)с помощью стандартной утилитыreglogиочистим их заголовки (см. Приложение).

Затем вJupiter-блокноте при помощи библиотекpandasиmatplotlibпрочитаемcsv (см. Приложение, Jupiter Notebook: импорт) ипостроимграфики (см. Приложение, Jupiter Notebook: одна метрика одна диаграмма).

Анализ результатов и наиболее интересные графики

Задержки при обработке ввода от пользователя

До включения групповых политик сильнее всего на обработке ввода сказалось проигрывание локальных видеофайлов: в среднем 45 мс при рекомендованных 33 мс.

Включение отрисовки через GPU в групповых политиках стабилизировало этот показатель во всех сценариях.

Частота кадров

После включения GPU ускорения ситуация явно становится лучше, особенно в 3D тесте. Результаты двух других тестов хоть и демонстрируют улучшение, но недостаточно: провалы на графиках соответствуют визуальным "рывкам" при просмотре.

Воспроизведение"Flying Through Forest 1"(1920 x 1088, 48072 кбит/с, 9 секунд, 25 fps): от запуска к запуску на вход кодека RеmoteFX поступало либо повышенное либо пониженное количество кадров. Возможно, причина в перекодировке из формата QuickTime, "лишних" 8 пикселях ширины кадра или битрейте.

"Коста-Рика"также вызвал "проседание" FPS у RemoteFX: его проигрывание в браузере в1080p60ложилось на центральный процессор. Возможно, он просто не успевал перекодировать из 60fps и подготовить нужный кадр для RemoteFX.

Общие сетевые метрики

При включении GPU ускорения происходит рост сетевого трафика, который зависит от сценария теста.

Видно, что самым тяжёлым для кодека RemoteFX опять оказался тот же самый видеофайл,"Flying Through Forest 1". Первый запуск этого теста, когда наблюдается провал входящих кадров, также видим скачки трафика до 60 Мбит/с и потери до 30% - 40%.

Загрузка центрального процессора

Включение GPU ускорения практически вдвое разгружает центральный процессор, за исключением youtube-теста. И даже здесь удалось уйти от периодической 100% загрузки.

Загрузка видеокарты

Возможно, разгадка странного поведения второго ролика кроется в графике 17: входящих для RemoteFX кадров было больше, когда видеокарта была больше загружена кодированием.

Выводы

В RDP протоколе частота кадров ограничена 30-ю кадрами в секунду. Со стороны сервера увеличить лимит FPSможно, но бессмысленно: на практике терминальная сессия перестала отрисовывать окно и реагировать на действия как раз при проигрывании"того самого"видеофайла :).

Итоги в цифрах:

1. Частота кадров стабилизируется почти на максимально возможном для протокола уровне: 29-30 FPS в среднем вместо 25 или даже 15 FPS

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

3. Заметно, на 20-50 %, разгружается центральный процессор

4. Немного возрастает утилизация канала связи, на 3-6 Мбит/сек

5. Утилизация GPU составила до 20%

Результат действительно очень хороший: RemoteFX значительно увеличивает качество работы в терминальной сессии плавность отрисовки окна и отклик на действия пользователя сравнимы с локальным режимом. Даже "тяжёлые" сценарии показывают в этом плане заметный прирост.

Тесты, конечно, носят искусственный характер: выбором способа нагрузки на кодек RemoteFX можно как "завалить" так и "подтянуть" его результаты. Возможно, более релевантным было бы проведение чего-то вроде "конфетти-теста",например, такого.

Что дальше

Так как на этом этапе тесты проводились для одной сессии и при включении лишь рекомендованных настроек, то далее имеет смысл протестировать производительность:

• при одновременной работе нескольких пользователей

• при включении в групповых политиках различных дополнительных настроек кодека

Приложения

@echo offsetlocal EnableDelayedExpansion@REM для сбора используются счётчики, перечисленные в _1_counters.cfg@REM счётчики называются только на английском, на русском это просто описание@REM @REM запуск сбора данных:@REM    при каждом входе на удалённый рабочий стол исправить _1_counters.cfg:@REM    1)  посмотреть номер своей терминальной сессии консольной командой@REM        query session@REM    @REM    2)  вписать этот номер в _1_counters.cfg, например, RDP-Tcp 9@REM    @REM    3)  перерегистрировать сброщик запуском данного файла@REM @REM    4)  замер производительности производится запуском _2_task_run_X.cmd и длится 2 минуты@REM @REM удаление старого сборщика данныхlogman delete -n RemoteFX_1logman delete -n RemoteFX_2logman delete -n RemoteFX_3logman delete -n RemoteFX_4logman delete -n RemoteFX_5for /F "usebackq delims= " %%a IN (`query session ^| find "Administrator"`) DO (    set "x=%%a"    set "x=!x:~9,10!"    echo !x!    type NUL>_1_counters.cfg    echo ^\NVIDIA GPU^(^*^)^\%% Video Decoder Usage>>_1_counters.cfg    echo ^\NVIDIA GPU^(^*^)^\%% Video Encoder Usage>>_1_counters.cfg    echo ^\NVIDIA GPU^(^*^)^\%% GPU Memory Usage>>_1_counters.cfg    echo ^\NVIDIA GPU^(^*^)^\%% GPU Usage>>_1_counters.cfg    echo.>>_1_counters.cfg    echo ^\Processor Information^(_Total^)^\%% Processor Time>>_1_counters.cfg    echo.>>_1_counters.cfg    echo ^\RemoteFX Network^(RDP-Tcp !x!^)^\Loss Rate>>_1_counters.cfg    echo ^\RemoteFX Network^(RDP-Tcp !x!^)^\Current TCP Bandwidth>>_1_counters.cfg    echo ^\RemoteFX Network^(RDP-Tcp !x!^)^\Current UDP Bandwidth>>_1_counters.cfg    echo.>>_1_counters.cfg    echo ^\RemoteFX Network^(RDP-Tcp !x!^)^\Total Sent Rate>>_1_counters.cfg    echo ^\RemoteFX Network^(RDP-Tcp !x!^)^\TCP Sent Rate>>_1_counters.cfg    echo ^\RemoteFX Network^(RDP-Tcp !x!^)^\UDP Sent Rate>>_1_counters.cfg    echo.>>_1_counters.cfg    echo ^\RemoteFX Network^(RDP-Tcp !x!^)^\Total Received Rate>>_1_counters.cfg    echo ^\RemoteFX Network^(RDP-Tcp !x!^)^\TCP Received Rate>>_1_counters.cfg    echo ^\RemoteFX Network^(RDP-Tcp !x!^)^\UDP Received Rate>>_1_counters.cfg    echo.>>_1_counters.cfg    echo ^\RemoteFX Graphics^(^*^)^\Output Frames/Second>>_1_counters.cfg    echo ^\RemoteFX Graphics^(^*^)^\Input Frames/Second>>_1_counters.cfg    echo.>>_1_counters.cfg    echo ^\RemoteFX Graphics^(^*^)^\Frames Skipped/Second - Insufficient Server Resources>>_1_counters.cfg    echo ^\RemoteFX Graphics^(^*^)^\Frames Skipped/Second - Insufficient Network Resources>>_1_counters.cfg    echo ^\RemoteFX Graphics^(^*^)^\Frames Skipped/Second - Insufficient Client Resources>>_1_counters.cfg    echo ^\RemoteFX Graphics^(^*^)^\Frame Quality>>_1_counters.cfg    echo ^\RemoteFX Graphics^(^*^)^\Average Encoding Time>>_1_counters.cfg    echo ^\User Input Delay per Session^(Max^)^\Max Input Delay>>_1_counters.cfg    echo.>>_1_counters.cfg    echo ^\RemoteFX Graphics^(^*^)^\Graphics Compression ratio>>_1_counters.cfg    echo ^\NVIDIA GPU^(^*^)^\%% FB Usage>>_1_counters.cfg    @REM счётчик памяти не работает, сброс кэша счётчиков также не помог    @REM    https://docs.microsoft.com/ru-ru/troubleshoot/windows-server/performance/manually-rebuild-performance-counters    echo ^\Memory^\%% Committed Bytes In Use>>_1_counters.cfg    echo ^\Memory^\Available Bytes>>_1_counters.cfg)@REM и регистрация нового сборщикаlogman create counter -n RemoteFX_1 -f bin -max 10 -si 00:00:01 -rf 00:02:00 --v -o "%~dp0logs\test #1 void GPO X" -cf "%~dp0_1_counters.cfg"logman create counter -n RemoteFX_2 -f bin -max 10 -si 00:00:01 -rf 00:02:00 --v -o "%~dp0logs\test #2 3D GPO X" -cf "%~dp0_1_counters.cfg"logman create counter -n RemoteFX_3 -f bin -max 10 -si 00:00:01 -rf 00:02:00 --v -o "%~dp0logs\test #3 wmp GPO X" -cf "%~dp0_1_counters.cfg"logman create counter -n RemoteFX_4 -f bin -max 10 -si 00:00:01 -rf 00:02:00 --v -o "%~dp0logs\test #4 youtube GPO X" -cf "%~dp0_1_counters.cfg"logman create counter -n RemoteFX_5 -f bin -max 10 -si 00:00:01 -rf 00:02:00 --v -o "%~dp0logs\test #5 webGL GPO X" -cf "%~dp0_1_counters.cfg"@REM pause@REM exit

@REM запускаем сбор данныхlogman stop RemoteFX_1logman stop RemoteFX_2logman stop RemoteFX_3logman stop RemoteFX_4logman stop RemoteFX_5

@echo off@REM смена кодировки нужна для powershell-скрипта "%~dpn0.ps1"chcp 65001@REM работаем в текущей папке скриптаcd "%~dp0logs"@REM включаем расширения для переопределения переменных в циклеsetlocal EnableDelayedExpansion@REM цикл по двоичным файлам мониторингаFOR /F "usebackq delims=." %%a IN (`dir *.blg /b`) DO (    set "blg=%%a.blg"    set "csv=%%a.csv"    @REM convert binary to csv    relog "!blg!" -f csv -o "!csv!" -y)@REM имена cmd и powershell скриптов должны совпадатьstart "%~dpn0.ps1" /WAIT /B pwsh.exe -Command "& {%~dpn0.ps1 -en:$False}"@REM справка reglog - утилиты работы с журналами производительности@REM https://docs.microsoft.com/ru-ru/windows-server/administration/windows-commands/relog

[CmdletBinding()]param (    [switch] $en       = $False  # substitute ru alias of counters by real en name)$WorkDir = $MyInvocation.MyCommand.Definition | Split-Path -Parent$LogsDir = Join-Path -Path $WorkDir -ChildPath 'logs'$EncodeFrom = [System.Text.Encoding]::GetEncoding(1251)$EncodeTo = New-Object System.Text.UTF8Encoding $False$names = @(    New-Object psobject -Property @{ 'ru' = 'Задержка ввода данных пользователем на сеанс(Max)\Максимальная задержка ввода' ; 'en' = 'User Input Delay per Session\Max Input Delay'}    New-Object psobject -Property @{ 'ru' = 'Графика RemoteFX\Входящих кадров в секунду' ; 'en' = 'RemoteFX Graphics\Input Frames/Second'}    New-Object psobject -Property @{ 'ru' = 'Графика RemoteFX\Исходящих кадров в секунду' ; 'en' = 'RemoteFX Graphics\Output Frames/Second'}    New-Object psobject -Property @{ 'ru' = 'Графика RemoteFX\Среднее время кодирования' ; 'en' = 'RemoteFX Graphics\Average Encoding Time'}    New-Object psobject -Property @{ 'ru' = 'Графика RemoteFX\Качество кадра' ; 'en' = 'RemoteFX Graphics\Frame Quality'}    New-Object psobject -Property @{ 'ru' = 'Графика RemoteFX\Коэффициент сжатия графических данных' ; 'en' = 'RemoteFX Graphics\Graphics Compression ratio'}    New-Object psobject -Property @{ 'ru' = 'Сеть RemoteFX\Общая скорость отправки' ; 'en' = 'RemoteFX Network\Total Sent Rate'}    New-Object psobject -Property @{ 'ru' = 'Сеть RemoteFX\Общая скорость приема' ; 'en' = 'RemoteFX Network\Total Received Rate'}    New-Object psobject -Property @{ 'ru' = 'Сеть RemoteFX\Потери' ; 'en' = 'RemoteFX Network\Loss Rate'}    New-Object psobject -Property @{ 'ru' = 'Графика RemoteFX\Пропущено кадров в секунду  недостаточно сетевых ресурсов' ; 'en' = 'RemoteFX Graphics\Frames Skipped/Second - Insufficient Network Resources'}    New-Object psobject -Property @{ 'ru' = 'Графика RemoteFX\Пропущено кадров в секунду  у сервера недостаточно ресурсов' ; 'en' = 'RemoteFX Graphics\Frames Skipped/Second - Insufficient Server Resources'}    New-Object psobject -Property @{ 'ru' = 'Графика RemoteFX\Пропущено кадров в секунду  у клиента недостаточно ресурсов' ; 'en' = 'RemoteFX Graphics\Frames Skipped/Second - Insufficient Client Resources'}    New-Object psobject -Property @{ 'ru' = 'Сведения о процессоре(_Total)\% загруженности процессора' ; 'en' = 'Processor Information(_Total)\% Processor Time'}    New-Object psobject -Property @{ 'ru' = 'NVIDIA GPU\% GPU Usage' ; 'en' = 'NVIDIA GPU\% GPU Usage'}    New-Object psobject -Property @{ 'ru' = 'NVIDIA GPU\% GPU Memory Usage' ; 'en' = 'NVIDIA GPU\% GPU Memory Usage'}    New-Object psobject -Property @{ 'ru' = 'NVIDIA GPU\% Video Decoder Usage' ; 'en' = 'NVIDIA GPU\% Video Decoder Usage'}    New-Object psobject -Property @{ 'ru' = 'NVIDIA GPU\% Video Encoder Usage' ; 'en' = 'NVIDIA GPU\% Video Encoder Usage'}    New-Object psobject -Property @{ 'ru' = 'NVIDIA GPU\% FB Usage' ; 'en' = 'NVIDIA GPU\% FB Usage'}    New-Object psobject -Property @{ 'ru' = 'Сеть RemoteFX\Пропускная способность текущего UDP-подключения' ; 'en' = 'RemoteFX Network\Current UDP Bandwidth'}    New-Object psobject -Property @{ 'ru' = 'Сеть RemoteFX\Пропускная способность текущего TCP-подключения' ; 'en' = 'RemoteFX Network\Current TCP Bandwidth'}    New-Object psobject -Property @{ 'ru' = 'Сеть RemoteFX\Скорость отправки UDP-данных' ; 'en' = 'RemoteFX Network\UDP Sent Rate'}    New-Object psobject -Property @{ 'ru' = 'Сеть RemoteFX\Скорость получения UDP-данных' ; 'en' = 'RemoteFX Network\UDP Received Rate'}    New-Object psobject -Property @{ 'ru' = 'Сеть RemoteFX\Скорость отправки TCP-данных' ; 'en' = 'RemoteFX Network\TCP Sent Rate'}    New-Object psobject -Property @{ 'ru' = 'Сеть RemoteFX\Скорость получения TCP-данных' ; 'en' = 'RemoteFX Network\TCP Received Rate'})$Heads = @()foreach ($f in Get-ChildItem -Path $LogsDir -File -Filter '*.csv'){    $FileContent = $f | Get-Content -Encoding $EncodeFrom    $HeadOrig = $FileContent[0]    # приводим заголовки к единому виду, убираем ненужное    # "\\TESTGPU\NVIDIA GPU(#0 GRID M60-1Q (id=1, NVAPI ID=513))\% GPU Memory Usage"    if ($HeadOrig -match '.*(?<hostname>\\\\[a-zA-Z0-9]*\\).*')    {        $HeadOrig = $HeadOrig.Replace($Matches['hostname'], '')    }    if ($HeadOrig -match '.*NVIDIA GPU(?<gpu>\(#[A-Z0-9 ]*-[A-Z0-9]* \(id=[0-9,]* NVAPI ID=[0-9]*\)\))')    {        $HeadOrig = $HeadOrig.Replace($Matches['gpu'], '')    }    # "\\TESTGPU\Графика RemoteFX(RDP-Tcp 55)\Входящих кадров в секунду"    if ($HeadOrig -match '.*(?<session>\(RDP-Tcp[ 0-9]*\)).*')    {        $HeadOrig = $HeadOrig.Replace($Matches['session'], '')    }    # "(PDH-CSV 4.0) (Russia TZ 2 Standard Time)(-180)"    if ($HeadOrig -match '.*(?<time>\(.*\) \(.*Time\)\([0-9 +-]*\))')    {        $HeadOrig = $HeadOrig.Replace($Matches['time'], 'Time')    }    if ($en)    {        $HeadOrig = ($HeadOrig -split '","') -replace '"', ''        foreach ($h in $HeadOrig)        {            if ($h -notin $names.ru) { continue }            $n = $names | Where-Object {$_.ru -eq $h}            $HeadOrig[($HeadOrig.IndexOf($h))] = $n.en  # $h = $n.en не работает        }        $HeadOrig = '"{0}"' -f ($HeadOrig -join '","')    }    $FileContent[0] = $HeadOrig  # перезапись заголовка    $FileContent | Out-File -Encoding $EncodeTo -FilePath $f.FullName    $Heads += $f.Name + $HeadOrig  # сохранение заголовка}# вывод заголовков столбцов в отдельный файл для доп. контроля порядка, названий и т.д.$Heads | Out-File -Encoding $EncodeTo -FilePath (Join-Path -Path $LogsDir -ChildPath 'heads.txt')

import pandas as pdimport matplotlib.pyplot as pltfrom matplotlib.ticker import EngFormatter  # для вывода форматированных единиц измеренияplt.rcParams['figure.max_open_warning'] = 30  # порог предупреждения при одновременном построении нескольких рисунков%matplotlib inline# импорт данных csv-файловt21 = pd.read_csv('./logs/test #2 3D GPO 1.csv', na_values=' ')t20 = pd.read_csv('./logs/test #2 3D GPO 0.csv', na_values=' ')  # , encoding='cp1251')t31 = pd.read_csv('./logs/test #3 wmp GPO 1.csv', na_values=' ')t30 = pd.read_csv('./logs/test #3 wmp GPO 0.csv', na_values=' ')t31_prev = pd.read_csv('./logs/test #3 wmp GPO 1 anomaly.csv', na_values=' ')t41 = pd.read_csv('./logs/test #4 youtube GPO 1.csv', na_values=' ')t40 = pd.read_csv('./logs/test #4 youtube GPO 0.csv', na_values=' ')# слияние результатов каждого теста: сначала рекомендованные GPO, потом default GPOt2 = pd.concat([t21, t20],           join='inner', axis=1)t3 = pd.concat([t31, t30, t31_prev], join='inner', axis=1)t4 = pd.concat([t41, t40],           join='inner', axis=1)# разные наборы для итерации и рисования в циклеdataframes = [t2, t3, t4]ax_titles = ['test #2: 3D benchmark', 'test #3: play 1080p video', 'test #4: play 1080p youtube video']legend = ['GPU acceleration', 'default', 'GPU, anomaly']img_sx, img_sy = 15, 5  # размеры одного ряда графиковfgs = [  # макет графиков  # yunit ед. изм., ylabel метка Y-оси, ydata колонка из датафрейма    {'yunit': 'ms',     'ylabel': 'Input Delay',            'ydata': 'Задержка ввода данных пользователем на сеанс(Max)\Максимальная задержка ввода'},    {'yunit': 'fps',    'ylabel': 'RemoteFX input FPS',     'ydata': 'Графика RemoteFX\Входящих кадров в секунду'},    {'yunit': 'fps',    'ylabel': 'RemoteFX output FPS',    'ydata': 'Графика RemoteFX\Исходящих кадров в секунду'},    {'yunit': 'bps',    'ylabel': 'Tx Speed',               'ydata': 'Сеть RemoteFX\Общая скорость отправки'},    {'yunit': 'bps',    'ylabel': 'Rx Speed',               'ydata': 'Сеть RemoteFX\Общая скорость приема'},    {'yunit': '%',      'ylabel': 'Tx / Rx Loss',           'ydata': 'Сеть RemoteFX\Потери'},    {'yunit': '%',      'ylabel': 'CPU Usage',              'ydata': 'Сведения о процессоре(_Total)\% загруженности процессора'},    {'yunit': '%',      'ylabel': 'GPU Usage',              'ydata': 'NVIDIA GPU\% GPU Usage'},    {'yunit': '%',      'ylabel': 'GPU Memory Usage',       'ydata': 'NVIDIA GPU\% GPU Memory Usage'},    {'yunit': '%',      'ylabel': 'GPU Decoder Usage',      'ydata': 'NVIDIA GPU\% Video Decoder Usage'},    {'yunit': '%',      'ylabel': 'GPU Encoder Usage',      'ydata': 'NVIDIA GPU\% Video Encoder Usage'},    {'yunit': 'ms',     'ylabel': 'Encoding Time',          'ydata': 'Графика RemoteFX\Среднее время кодирования'},    {'yunit': '%',      'ylabel': 'Frame Quality',          'ydata': 'Графика RemoteFX\Качество кадра'},    {'yunit': '%',      'ylabel': 'Compression: enc byte / in byte', 'ydata': 'Графика RemoteFX\Коэффициент сжатия графических данных'},    {'yunit': 'fps',    'ylabel': 'FPS Loss by network',    'ydata': 'Графика RemoteFX\Пропущено кадров в секунду  недостаточно сетевых ресурсов'},    {'yunit': 'fps',    'ylabel': 'FPS Loss by server',     'ydata': 'Графика RemoteFX\Пропущено кадров в секунду  у сервера недостаточно ресурсов'},    {'yunit': 'fps',    'ylabel': 'FPS Loss by client',     'ydata': 'Графика RemoteFX\Пропущено кадров в секунду  у клиента недостаточно ресурсов'},    {'yunit': '%',      'ylabel': 'GPU Framebufer Usage',   'ydata': 'NVIDIA GPU\% FB Usage'},    {'yunit': 'bps',    'ylabel': 'Tx Speed UDP',           'ydata': 'Сеть RemoteFX\Скорость отправки UDP-данных'},    {'yunit': 'bps',    'ylabel': 'Rx Speed UDP',           'ydata': 'Сеть RemoteFX\Скорость получения UDP-данных'},    {'yscale': 1000,    'yunit': 'bps', 'ylabel': 'Bandwidth UDP', 'ydata': 'Сеть RemoteFX\Пропускная способность текущего UDP-подключения'},    {'yunit': 'bps',    'ylabel': 'Tx Speed TCP',           'ydata': 'Сеть RemoteFX\Скорость отправки TCP-данных'},    {'yunit': 'bps',    'ylabel': 'Rx Speed TCP',           'ydata': 'Сеть RemoteFX\Скорость получения TCP-данных'},    {'yscale': 1000,    'yunit': 'bps', 'ylabel': 'Bandwidth TCP', 'ydata': 'Сеть RemoteFX\Пропускная способность текущего TCP-подключения'},]

for i in range(len(fgs)):  # сколько метрик, столько рисунков (рядов диаграмм)    fig, axs = plt.subplots(1, 3, figsize=(img_sx, img_sy), sharex='col', sharey='row', gridspec_kw=dict(hspace=0, wspace=0, ))  # width_ratios=[1, 1, 1]    fig_name = fgs[i]['ydata'].split('\\')[1]    fig.suptitle(f'Рис. {i + 1:>2}. {fig_name}', fontsize=14)  #, color='grey')  # имя рисунка    fig.patch.set_facecolor('white')  # фон рисунка белый вместо прозрачного    axs[0].set(ylabel=fgs[i]['ylabel'])  # подпись Y-оси только на первых (левых) графиках из трёх    axs[2].yaxis.set_tick_params(labelleft=False, labelright=True, which='major')  # дублируем значения справа    for ax, d, title in zip(axs, dataframes, ax_titles):  # на каждый тест своя диаграмма        ax.plot(d.index.values, d[fgs[i]['ydata']] * (fgs[i].get('yscale', 1)))  # строим график        ax.set_title(title)  #, color='grey')  # заголовок диаграммы                ax.xaxis.set_tick_params(which='major', labelcolor='grey')  # подписи к X-шкале        ax.xaxis.set_major_formatter(EngFormatter(unit='s'))  # по X секунды        ax.yaxis.set_tick_params(which='major', labelcolor='grey')  # подписи Y-шкале        ax.yaxis.set_major_formatter(EngFormatter(unit=fgs[i]['yunit']))  # по Y у каждого графика своя ед. изм.        # расчёт средних и вывод в легенду диаграммы "на лету"        avg = [EngFormatter(places=0).format_eng(avg * (fgs[i].get('yscale', 1))) for avg in d[fgs[i]['ydata']].mean()]        lgn = [f'avg {m}{fgs[i]["yunit"]}, {l}' for l, m in zip(legend, avg)]        ax.legend(lgn, fontsize=8)  # отображение легенды графика        ax.grid(axis='y')  # горизонтальная сетка        ax.set_xlim(0,119)  # метка "120" засоряла график        if ax == axs[1]:  # выделяем аномалии на средней диаграмме            ax.axvline(x=15, linestyle=":", color='C0')            ax.axvline(x=58, linestyle=":", color='C0')            ax.axvline(x=101, linestyle=":", color='C0')        fig.tight_layout()  # (pad=0.4, w_pad=1.5, h_pad=30.0)

# один рисунок  # plt.style.available  # plt.style.use('seaborn-whitegrid')fig, axs = plt.subplots(len(fgs), 3, figsize=(img_sx, img_sy * len(fgs)), sharex='col', sharey='row', gridspec_kw=dict(hspace=0.2, wspace=0))fig.patch.set_facecolor('white')  # фон рисунка белый вместо прозрачного# заголовки только вверху[ax.set_title(title) for ax, title in zip(axs[0], ax_titles)]  # ax.set_title(title, color='grey')for i in range(len(fgs)):    axs[i,0].set(ylabel=fgs[i]['ylabel'])    fig_name = fgs[i]['ydata'].split('\\')[1]    axs[i,1].set(xlabel=f'Рис. {i + 1:>02}. {fig_name}')    # axs[i,1].xaxis.label.set_color('grey')    axs[i,2].yaxis.set_tick_params(labelleft=False, labelright=True, which='major')    for ax, d, title in zip(axs[i], dataframes, ax_titles):        ax.plot(d.index.values, d[fgs[i]['ydata']] * (fgs[i].get('yscale', 1)))        ax.xaxis.set_tick_params(which='major', labelcolor='grey')  # подписи к X-шкале        ax.xaxis.set_major_formatter(EngFormatter(unit='s'))  # по X секунды        ax.yaxis.set_tick_params(which='major', labelcolor='grey')  # подписи Y-шкале        ax.yaxis.set_major_formatter(EngFormatter(unit=fgs[i]['yunit']))  # по Y у каждого графика своя ед. изм.        # расчёт средних и изменение легенды диаграммы "на лету"        avg = [EngFormatter(places=0).format_eng(avg * (fgs[i].get('yscale', 1))) for avg in d[fgs[i]['ydata']].mean()]        lgn = [f'avg {m}{fgs[i]["yunit"]}, {l}' for l, m in zip(legend, avg)]        ax.legend(lgn, fontsize=8)  # отображение легенды графика        ax.grid(axis='y')  # горизонтальная сетка        ax.set_xlim(0,119)  # метка "120" засоряла график        if ax == axs[i,1]:  # выделяем аномалии на средней диаграмме            ax.axvline(x=15, linestyle="--", color='C0')            ax.axvline(x=58, linestyle="--", color='C0')            ax.axvline(x=101, linestyle="--", color='C0')

Продолжение истории будет на следующей неделе. Спасибо за внимание!

Что ещё интересного есть в блогеCloud4Y

Частые ошибки в настройках Nginx, из-за которых веб-сервер становится уязвимым

Пароль как крестраж: ещё один способ защитить свои учётные данные

Тим Бернерс-Ли предлагает хранить персональные данные в подах

Подготовка шаблона vApp тестовой среды VMware vCenter + ESXi

Создание группы доступности AlwaysON на основе кластера Failover

Подписывайтесь на нашTelegram-канал, чтобы не пропустить очередную статью. Пишем не чаще двух раз в неделю и только по делу.

От старого Умного перекрестка, который россиянам начали ставить недавно, до самообучающегося.

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

Адаптивный работаетна сравнительно простыхперекрестках, где правила и возможности переключения фаз совершенно очевидны.Адаптивное управлениеприменимо лишь там, где нет постоянной загрузки по всем направлениям, иначе ему просто не к чему адаптироваться нет свободных временных окон. Первые перекрестки на адаптивном управлении появились в США в начале 70-х годов прошлого века. К сожалению, до России они дошли только сейчас, их число по некоторым оценкам не превышает 3 000 по стране. (Часто под этим же названием понимаются обычные светофорные объекты, алгоритмы работ которых меняются в зависимости от времени суток и дней недели. С терминологией в Раше пока совсем плохо, здесь мы точно обсуждаем не адаптацию по времени.)

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

(Некоторые фирмы, и даже в этом был замечен Яндекс, предлагают ещеГеоинформационные светофоры. Эти декларируют использование GPS и GLONASS навигации для определения ТС общественного автотранспорта, а также спецмашин, чтобы подстраиваться под их беспрепятственное прохождение. Но мы не рассматриваем этот тип умных перекрестков уже потому, что практика показала их несостоятельность. Такое дистанционное планирование постояннонатыкается на резкие изменения в характере движения потоков, в результате чего расчеты все время претерпевают изменения и не согласуются с текущей обстановкой на перекрестке, где важна каждая доля секунды. Пока не будет доказано обратное, мы эту тему не описываем.)

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

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

Нейросетевые светофорыи для распознавания объектов тоже используютнейронные сети,за счет этого они получают более информативную и супер точную картину происходящего. Эти мозги распознают любые образы в их любых положениях и поэтому более точно считают количество транспортных средств, делают это на гораздо большем расстоянии с одной камеры. Кроме этого,нейронные сетиопределяют качественный состав ТС как по типу, так и множеству других параметров. Например, длинная фура и быстрый Ferrari имеют совершенно разную манеру начала движения, что по-разному влияет на алгоритмы умного светофора. Даже постоянно забывающая трогаться на зеленый свет блондинка со знаком У на ТС постепенно включается в коэффициент поправки расчетов.Кроме того,нейронные сетиумеют распознавать и людей, что тоже очень важно ведь пешеходам тоже хочется пройти через дорогу. А такженейросетидиагностируют более сотни других объектов от детской коляски с велосипедами до чемоданов и оружия.

Нейронные сетивообще почти не имеют ограничений по точкам установки, они распознают любые объекты из любых ракурсов в любом виде и при больших перекрытиях часто достаточно видеть лишь 15% автомобиля, чтобы понять, что это автомобиль. Соответственно,нейросетевой светофордешевле в монтажном плане, в количестве видеокамер, длине проводов и прочих монтажных хитростях.

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

Разберем подробнее, где и за счет чего эти умные светофоры позволяют повысить пропускную способность:

Пример 1.Прилегающая к трассе второстепенная дорога.

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

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

Кто-то здесь скажет: -Давайте лучше построим разгоночную полосу и светофор вообще не нужен. - Но машинам иногда надо поворачивать налево тогда придется делать и разворотное кольцо. А у нас еще и пешеходы, которые тоже не прочь пересечь трассу им нужно построить под- или надземный переход. Всё это потребует уже десятки миллионов рублей на строительство и миллионы на обслуживание. Поставить и обслуживать два столба с тремя лампочкам и с парой видеокамер цифры на два порядка дешевле. Хотя выбор есть.

Пример 2.Городской перекресток в незагруженное время.

В обычных городах мы часто сталкиваемся с ситуацией, когда стоим на красный свет в то время, как в поперечном направлении никого нет. Например, в Иванове час пик бывает только несколько часов в сутки. А ночью и вообще всех нас нервирует никому не нужное ожидание чуть ли не на каждом перекрестке. Зачем мы тратим время и бензин, а также изнашиваем тормозные колодки? Здесь постоянно приходит на ум ненормативный термин - тупой светофор.

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

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

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

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

Вы еще что-то хотели сказать:в ночное время надо включать мигающий желтый на всех перекрестках!- Пробовали, уже много десятков лет. Выяснили, что в нашей стране это очень опасно. Интернет просто забит роликами автогонок, никакие измерители скорости не останавливают ночных любителей разогнаться по городским дорогам до 300 км/час. В хлам превращаются не только автомобили, люди тоже переходят дороги по ночам.

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

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

Пример 3.Постоянно загруженный перекресток.

Здесь, наверно, каждому понятно, что подойдет тольконейросетевой светофор, потому что очевидной логики по переключению светофорных фаз просто нет: со всех сторон идет автотранспорт сплошным потоком, и кому дать приоритет?

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

Мы еще ничего не рассказали, но уже услышали ваш вопрос: -Не все ли равно? Нет, потому что движение неоднородное, мы имеем автотранспортную пружинку: при трогании потока она растягивается, при остановке сжимается. И по времени часто превышает сам процесс движения между соседними перекрестками. Чем больше остановок, тем меньше ТС пройдет в результате всего времени.

И вы сразу предлагаете: -Тогда надо дать максимально длинную фазу, чтобы не создавать частых пружин. Правильно это было бы, если у нас не было другого направления: с востока на запад. Оно тоже требует максимальную фазу. Эта игра у нас называется волки овцы: Те, кто едет волки, а стоят овцы.

И вы, уже не подумавши скажете: -Давайте всем дадим поровну! Допустим! Но сколько именно поровну? Ладно, договорились на 5 минут каждому. Но одно направление утыкается во второй перекресток, и ему эти 5 минут как мертвому припарка, оно встает уже через 3 минуты. Остальные две минуты перекресток просто забит еле двигающимися автомобилями. Мы теряем в скорости трафика, что тоже ведет к понижению пропускной способности.

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

Кстати, об авариях, это еще целый комплекс вводных с тысячью неизвестных. Просчитать оптимальные режимы всех светофорных объектов задача для компьютера, а не примитивной житейской логики. Когда на совершенно простом незагруженном перекрестке фура уронила ящик,адаптивный светофорсошел с ума. Он все время пытался пропустить загруженное направление, а это было невозможно физически. В результате в пробку встало и другое свободное направление.

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

И это только 30% повышения эффективности на загруженных всегда перекрестках. Самое интересное, что эту цифру легко довести до 60%, как вам такое? Не устали стоять в пробках?Хотите ездить в два раза быстрее?Здесь уже говорили, что самая затратная часть в этом процессе автотранспортная пружинка: на остановки и троганья уходит где-то ДО, а где-то БОЛЕЕ 50% времени. Что, если мы не будем останавливать больше половины автотранспорта? Если к нашему Умному светофору подключить соседние Умные светофоры, тонейронная сетьполучает ценную информацию: когда, где и на какой скорости движется поток, какой типа транспорта в каждом потоке, даже манеру вождения отдельных транспортных средств (помните блондинку, которую все объезжают?). Таким образом, мы уже можем убрать каждую вторую пружинку, а то и больше.

- Видим, что у вас появились и конструктивные предложения: -А что если и пред-предыдущие светофоры завести в общую систему? Совершенно верно,таким способом по Москве или Питеру можно ездить в разы быстрее!

А что сейчас? В больших городах построены шикарные центры АСУДД, в которых профессиональные специалисты (извините за тавтологию) управляют светофорными объектами. Они, конечно, не нажимают кнопку для каждой лампочки, но именно вручную выставляют режимы работы каждому светофору. В других городах и этого нет просто среднестатистическое расписание. Наверно, это круто для 30-х годов! Не сегодняшнего, а прошлого века, когда на улице стоял в будке регулировщик теперь его работа ведется удаленно.

Хотя, человек может обыграть компьютер в шахматы! В этой игре тоже миллион неизвестных. Наверно, в АСУДД работают профи. Но сколько существует гроссмейстеров на миллион людей, которые просто умеют играть в эту игру?Все-таки в 99,999999999999% выиграет компьютер.

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

В 3 раза повышается пропускная способность на загруженных перекрестках!

И снова вопрос: -Да, вы сделаете 3 участка, где транспорт будет летать, но весь этот поток упрется в четвертый уже не такой умный перекресток! Позвольте сразу не согласиться с фразой весь этот поток. Перегруженные перекрестки находятся в городах, обычно в их центрах, соответственно там много жилых домов, офисов, магазинов и прочих мест, куда едут люди. Т.е. за 3 участка не весть поток упрется в 4-ый перекресток, часть рассосется опять женейросетеваясистема управления может это легко рассчитать. К тому же за эту зеленую фазу мы исключаем приток других авто, т.е. мы можем заранее узнать максимальный объем ТС и соответственно вывести всех на такой участок дороги, который позволит создать приемлемую очередь перед обычным перекрестком. Т.е. заранее нужно выбирать длинные участки дорог перед старой версией светофоров.Никакого коллапса здесь не будет!

Хотя правильно замечено, что на общую системунейросетевогоуправления лучше завязывать вообще весь город. И это тоже возможно и нужно, к этому мы когда-нибудь все придем!Умные светофоры на базенейронных сетей это безусловное будущее для России. Невозможно бесконечно строить высотки в центре Москвы, торпедировать продажу автомобилей и при этом ездить медленнее, чем ходить пешком. Для всего развитого миранейросетевыетехнологии стали уже обыденностью, и такие задачи там решаются очень быстро.

Внедрение Умных перекрестков.
Это самый простой с точки зрения технической реализации и самый сложный с точки зрения борьбы с технократией вопрос. Достаточно поставить 4 камеры во все направления даже на уже имеющиеся опоры и в большинстве случаев можно запускаться в работу. Главным элементом Умного перекрестка является программное обеспечение. Конечно, чем больше камер, тем выше эффективность, количество подбирается путем проектирования.

О самом сложном!
Сегодня везде уже стоят светофорные объекты прошлого века. Под них создана огромная инфраструктура с немалыми деньгами на обслуживание. Руководство регионов РФ само по себе технократично, а тут еще и передел рынка.

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

Есть еще одна новость средней позитивности: Прогресс все равно придет! Было бы неправильно думать, что деньги выделяются просто так, правительственные круги активно двигают московские фирмы, которые занимаются поставкойадаптивных светофоров. И против Москвы сопротивляться сложно, она придет и снесет всех политиков региона. Но новость средняя, потому чтоадаптивное управление это прошлый век, оно уже 50 лет как используется в Штатах исегодня там меняется нанейросетевое.

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

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

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

Информативности ради, надо добавить, что через десяток лет придет еще один тип Умных светофоров - Коммуникационный. Уже сегодня в машинах марки Volvo устанавливается оборудование, способное передавать данные о себе всем заинтересованным системам управления движением. Не потребуются даже камеры. Но для этого надо, чтобы поржавеливсе старые модели. Хотя не исключено, что такие устройства станут обязательными - также как автолокаторы на самолетах, которые ввели после одной из воздушных авиакатастроф. До России, конечно, полезные и спасающие жизни технологии могут долго не дойти.

Это первая статья в цикле Знакомство с Docker. Если вы раньше не работали с Docker, мы расскажем, что он из себя представляет.

Что такое Docker?

Docker - это инструмент DevOps для контейнеризации сервисов и процессов... Подождите... Подождите... Подождите! Что такое DevOps? Что такое контейнеризация? Какие услуги и процессы я могу контейнеризовать? Начнём с самого начала.

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

Контейнер - это не более чем процесс, который выполняется изолированно в операционной системе. У него есть собственная сеть, собственная файловая система и выделенная память. Вы можете подумать, а почему бы просто не использовать виртуальную машину? Что ж, виртуальная машина - это отдельная ОС, сильно загруженная множеством других процессов, которые могут вам никогда не понадобиться, вместо виртуализации всей операционной системы для запуска одной службы вы можете виртуализировать службу. Точнее говоря, вы можете создать легкую виртуальную среду для одной службы. Этими службами могут быть серверы Nginx, NodeJS или приложения angular. И Docker помогает нам в этом.

Название Docker происходит от слова док (dock). Док используется для погрузки и разгрузки грузов на кораблях. Здесь можно провести простую аналогию, груз может быть контейнерами, а корабль может быть нашей операционной системой. Все товары в составе груза изолированы от товаров другого груза и самого корабля. Точно так же в Docker процесс одного Docker контейнера (Docker Container) изолирован от процесса другого контейнера и самой операционной системы.

Как работает контейнеризация

Docker использует технологию Linux Containers (LXC) и механизмы ядра Linux. Поскольку у docker-контейнера нет собственной операционной системы, он полагается на хостовую операционную систему. Контейнер, созданный в Linux, может быть запущен в любом дистрибутиве Linux, но не может работать в Windows, и то же самое касается образа, созданного в Windows. Docker расширяет возможности LXC, но также использует контрольные группы (cgroups), которые позволяют ядру хоста разделять использование ресурсов (ЦП, память, дисковый ввод-вывод, сеть и т. д.) на уровни изоляции, называемые пространствами имён (namespaces).

Как создать Docker контейнер?

Чтобы создать Docker контейнер, нам нужно сначала создать архив, содержащий все файлы и зависимости, необходимые для нашего проекта. Этот архив называется Docker образом (Docker Image). Важно помнить, что после создания Docker образа его уже нельзя изменить или модифицировать.

Большое количество готовых образов можно найти в DockerHub, общедоступном репозитории Docker, который позволяет вам делиться своими образами или использовать образы, созданные другими людьми. Вы также можете создавать свои собственные образы и помещать их в свой частный репозиторий (например, Harbor). В дальнейшем этот образ будет использован для создания контейнеров. Один и тот же образ можно использовать для создания одного или нескольких контейнеров, используя Docker-CLI. А что такое Docker CLI спросите вы?

Рассмотрим архитектуру Docker,

1. Docker демонслушает запросы Docker API и управляет всеми объектами Docker, такими как образы, контейнеры, сети и тома. Это основная служба Docker, которая необходима для работы контейнеров и других компонентов Docker. Если Docker демон перестанет работать, так же перестанут работать все запущенные контейнеры.

2. Docker демон также предоставляет REST API. Различные инструменты могут использовать его для взаимодействия с демоном. Вы также можете создать приложение, для работы с Docker REST API.

3. Docker-CLIэто инструмент командной строки, который позволяет вам общаться с демоном Docker черезREST API.

Сеть Docker

Docker предусматривает несколько режимов работы сети. Подробнее о работе сети можно прочитать в нашей статье Сеть контейнеров это не сложно.

• Host networks -Контейнер Docker будет использовать сеть хоста, соответственно он не будет изолирован с точки зрения сети, это не коснётся изоляции контейнера в целом, например изоляции процессов и файловой системы.

• Bridge networks - Позволяет изолировать ваши приложения, но они могут взаимодействовать между собой и принимать трафик снаружи, если включено сопоставления портов (port forwarding).

• Overlay networks - Оверлейные сети соединяют вместе несколько демонов Docker и позволяют службам Docker Swarm взаимодействовать друг с другом. Docker Swarm (аналог Kubernetes) может использоваться, если у вас несколько серверов с Docker.

• Macvlan networks - Позволяет назначить MAC-адрес контейнеру, чтобы он отображался как физическое устройство в вашей сети.

• None -Сеть отсутствует, соответственно вы не сможете подключиться к контейнеру.

И всё же, почему стоит использовать Docker?

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

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

• Вы можете ограничить потребляемые контейнером ресурсы - ЦП и память, это позволит запустить больше контейнеров на одном сервере.

• Возможность запуска нескольких контейнеров из одного образа, позволит сэкономить место на диске и в репозитории образов.

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

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

Вместо заключения

Это только первая статья из цикла знакомство с Docker. В следующих статьях мы расскажем о работе с командной строкой Docker и создании собственных образов.

В этом посте мы собрали советы и рекомендации, которые стоит изучить, прежде чем переносить свои приложения в сервисную сетку OpenShift Service Mesh (OSSM). Если вы никогда не сталкивались с сервисными сетками Service Mesh, то для начала можно глянуть страницу OSSM на сайте Red Hat и почитать о том, как система Istio реализована на платформе OpenShift.

Начав изучать Istio, вы скорее всего столкнетесь с приложением bookinfo, которое почти повсеместно используется в качеств наглядного пособия, или же с более продвинутым вариантом в виде приложения Travel Agency. Разбирая эти и другие примеры, вы сможете лучшее понять, как устроена mesh-сетка, и затем уже переносить в нее свои приложения

Сначала о главном

Начать стоит с официальная документация OpenShift Service Mesh 2.0 (OSSM), в ней можно найти массу полезных материалов, в том числе:

• Описание различий между OSSM и родительским СПО-проектом Istio.

• Описание, как установить OSSMи

• Протестировать ее с помощью приложения-примера bookinfo.

• Istiov1.6(архив версий).

• Kialiv1.24(архив версий).

• Jaeger1.20.

Когда дойдет до интеграции вашего приложения в mesh-сетку, надо будет копнуть поглубже и заглянуть в документацию по Istio. Также стоит ознакомиться с release notes соответствующих версий компонентов, входящих Red Hat OSSM.

Если еще не сделали это, то протестируйте свою mesh-сетку с помощью приложения-примера Bookinfo. Если все пройдет нормально, то в нее уже можно будет добавлять ваше приложение.

Первое, что надо сделать при добавлении в mesh-сетку своего приложения убедиться, что sidecarы проксей Envoy правильно внедрены в podы вашего приложения. В OSSM такое внедрение делается довольно просто и хорошо описывается в документации.

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

Выбор протоколов

Важно четко понимать, как Istio определяет, какие протоколы использует ваше приложение. Для этого изучите все, что связано с Protocol Selection и app and version labelsв разделе документации Pods and Services.

В противном случае скорее всего произойдет следующий казус. Допустим, вы внедряете в свое приложение sidecarы проксей Istio, загружаете его тестовым трафиком и идёте смотреть граф Kiali. И видите там совсем не то, что ожидали (рис. ниже). Почему? Потому что Kiali и Istio не смогли правильно определить, какие протоколы используют наши сервисы, и отобразили соединения между ними как TCP, а не HTTP.

Istio должен точно знать, какой протокол используется. Если Istio не может определить протокол автоматически, то трактует трафик как обычный (plain) TCP. Если у вас какие-то другие протоколы, их надо вручную прописать в определениях служб Kubernetes Service вашего приложения. Подробнее об этом написано в документации, раздел Protocol Selection.

Чтобы вручную задать, какой протокол использует ваш сервис, надо соответствующим образом настроить объекты Kubernetes Service. В нашем случае в них по умолчанию отсутствовало значение параметра spec -> ports -> name. Если прописать "name: http" для сервисов A, B и C, то граф отобразит эти соединения как HTTP.

Kiali

Kiali это отличный инструмент для того, чтобы начать работать с OpenShift Service Mesh. Можно даже сказать, что именно на нем и надо сосредоточиться, когда вы начинаете работать с mesh-сеткой.

Kiali визуализирует метрики, генерируемые Istio, и помогает понять, что происходит в mesh-сетке. В качестве одной из первоочередных задач мы настоятельно рекомендуем изучить документацию Kiali.

Kiali не только пригодится для визуализации вашего приложения, но и поможет с созданием, проверкой и управлением конфигурациями mesh-сетки. Поначалу изучение конфигураций Istio может быть делом сложным, и Kiali тут сильно поможет.

В Kiali есть много полезных вещей, поэтому мы очень советуем изучить список ее возможностей и FAQ. Например, там есть следующие интересные вещи:

• Функции настройки и валидации

• Мастера настройки и верификация настроек

• Автоматическое внедрение sidecarов

• Функции корреляции в Kiali

Другая важная вещь умение маркировать сервисы приложения с помощью меток (label). Istio, а следовательно и Kiali, требует, чтобы маркировка велась строго определенным образом, который поначалу отнюдь не кажется очевидным, особенно когда весь ваш опыт исчерпывается работой с приложением-примером Bookinfo, где все метки уже есть и всё прекрасно работает из коробки.

Развертывания с использованием меток app и version это важно, поскольку они добавляет контекстную информацию к метрикам и телеметрии, которые собираются Istio и затем используются в Kiali и Jaeger.

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

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

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

Jaeger-выборки

При первоначальном тестировании своего приложения в mesh-сетке вам, скорее всего, захочется, чтобы частота трассировки была больше 50%, желательно, 100%, чтобы отслеживать все тестовые запросы, проходящие через приложение. В этом случае Jaeger и Kiali быстрее наберут необходимые данные, а вам не придется долго ждать обновления информации.

Иначе говоря, нам надо, чтобы sample rate был равен 100% (тут есть соответствие: 10000 = 100%).

Для этого надо подредактировать объект ServiceMeshControlPlane (обычно называется basic-install) в вашем проекте Control Plane (обычно istio-system) и добавить или изменить там следующее значение:

spec: tracing:  sampling: 10000 # 100%

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

Распространение заголовков контекста трассировки

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

Очень полезно отслеживать, как запросы ходят через сервисы (или даже множество сервисов) в вашей mesh-сетке. OSSM может здесь помочь за счет сбора данных в форме spanов и трасс (trace). Просмотр трасс очень помогает понять сериализацию, параллелизм и источники задержек в вашем приложении. Вкратце, span это интервал от начала выполнения единицы работы до ее завершения (например, полная отработка запроса клиент-сервер). Трасса это путь, по которому запрос проходит, двигаясь по mesh-сети, или, другими словами, по мере того, как он передается от одного сервиса вашего приложения к другому. Подробнее об этом можно и нужно почитать в документации OSSM.

Обратите внимание, что в OSSM spanы (единицы работы) автоматически генерируются средствами Istio, а вот трассы нет. Поэтому чтобы распределенные трассы (distributed traces) были полностью просматриваемыми, разработчик должен изменить код так, чтобы любые существующие trace-заголовки правильно копировались при передаче запроса между сервисами. К счастью, вы не обязаны сами генерировать эти заголовки. Если изначально их нет, то они будут автоматически сгенерированы и добавлены первым Envoy-прокси, который встретится на пути запроса (обычно это прокси на ingress-шлюзе).

Вот список заголовков для распространения:

• x-request-id

• x-b3-traceid

• x-b3-spanid

• x-b3-parentspanid

• x-b3-sampled

• x-b3-flags

• x-ot-span-context

Распространение заголовков может выполняться вручную или с использованием клиентских библиотек Jaeger, реализующих OpenTracing API.

Вот как делается ручное распространение trace-контекста на Java:

HttpHeaders upstreamHttpHeaders = new HttpHeaders();if (downstreamHttpHeaders.getHeader(headerName: "x-request-id") != null)   upstreamHttpHeaders.set("x-request-id", downstreamHttpHeaders.getHeader( headerName: "x-request-id"));

Примечание: это надо повторить для всех заголовков из списка выше.

Мастера Kiali и редактор YAML

Проверки

Ручная настройка yaml-манифестов дело утомительное, особенно если значения в одном yaml должны совпадать со значениями в другом, а еще ведь есть жесткие правила отступов. К счастью, в Kiali есть отличная функция, которая поможет при создании и проверке конфигураций.

Создание Istio-ресурсов с помощью Kiali-мастеров

Большую часть конфигураций, которые понадобятся вам в первое время, можно создать с помощью соответствующих мастеров Kiali, которые вызываются через меню Services.

YAML-редактор

Kiali имеет собственный редактор YAML для просмотра и редактирования конфигурационных ресурсов Istio напрямую, который также выявляет некорректные конфигурации.

Часто бывает так, что граф Kiali вдруг выявляет в вашем приложении неизвестные ранее (в том числе и разработчикам) коммуникационные пути. Другими словами, Kiali помогает найти и выявить все существующие пути во время тестирования вашего приложения. Это, конечно, полезно, но иногда может и раздражать. В этом случае их можно просто не отображать на графе, введя "node=unknown" в поле ввода над графом Kiali.

Уберите из кода шифрование коммуникаций

Если вы уже защитили соединения между своими сервисами и/или (скорее всего) используете TLS для внешних соединений, то при переводе приложения в mesh-сетку их надо будет в обязательном порядке выключить и переключиться на чистый HTTP без шифрования. А всем шифрованием теперь займутся Envoy-прокси.

Если ваши сервисы будут связываться с внешними сервисами по TLS, то Istio не сможет инспектировать трафик и Kiali будет отображать эти соединения только как TCP.

В общем, используйте для взаимодействия сервисов только HTTP, но не HTTPS.

Также про внешние сервисы надо поставить в известность и вашу mesh-сетку (см. ниже Настройка внешних сервисов).

Упростите код

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

Одно из преимуществ Service Mesh состоит в том, что реализацию многих вещей по сервисам можно убрать из приложения и отдать на откуп платформе, что помогает разработчикам сосредоточиться на бизнес-логике и упростить код. Например, можно рассмотреть следующие доработки:

• Как сказано выше, убрать HTTPS-шифрование.

• Убрать всю логику обработки таймаутов и повторных попыток.

• Убрать все ставшие ненужными библиотеки.

• Помните, что mesh-сетка увеличивает количество пулов подключений. Если раньше два сервиса связывались напрямую, то теперь у каждого из них есть свой прокси-посредник. То есть фактически вместо одного пула подключений появляются три:

  1. От вашего первого сервиса к локальному для него sidecarу Envoy (расположены в одном и том же podе).

  2. От этого sidecarа к другому sidecarу Envoy, который обслуживает второй сервис и расположен в одном podе с этим сервисом.

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

Еще один плюс оптимизации кода это возможность уменьшить размер сервисов и (возможно) поднять их производительность, убрав из них те вещи, которые теперь реализуются на уровне mesh-сетки.

Объекты Service

Убедитесь, что все сервисы вашего приложения взаимодействуют друг с другом через имена объектов Kubernetes Service, а не через OpenShift Routes.

Просто проверьте, вдруг ваши разработчики используют OpenShift Routes (конечные точки ingress на кластере) для организации коммуникаций между сервисами в пределах одного кластера. Если эти сервисы должны входить в одну и ту же mesh-сетку, то разработчиков надо заставить поменять конфигурации/манифесты своих приложений, чтобы вместо конечных точек OpenShift Route использовались имена объектов Kubernetes Service.

Функции аварийного переключения (fallback)

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

Настройка внешних сервисов

Envoy-прокси могут работать не только внутри кластера, но и отправлять трафик за его пределы, если зарегистрировать внешние сервисы в mesh-сетке.

Скорее всего, ваше приложение общается с сервисами за пределами mesh-сетки. Поскольку это внешние по отношению mesh-сетке сервисы, то толку от нее здесь не будет, да? А вот и нет. Эти внешние сервисы можно прописать в Service Mesh и использовать часть её функций и для них.

Подробнее и с примерами можно почитать об этом в документации OSSM. Есть и подробный разбор, как визуализировать внешний трафик Istio в Kiali, и как использовать TLS originationдля зашифрованного egress-трафика.

Вот некоторые из функций Istio, которые можно использовать при работе с внешними сервисами:

1. Шифрование (и простое, и Mutual TLS).

2. Таймауты и повторы.

3. Circuit breakerы.

4. Маршрутизация трафика.

Заключение

С OpenShift Service Mesh вы можете лучше понять, как устроена ваша mesh-сетка, сделать ее более просматриваемой, что, в свою очередь, помогает поднять общий уровень сложности микросервисной архитектуры. Бонусом идет возможность реализовать больше функций и возможностей на уровне самой платформе OpenShift, а не кодировать их на уровне отдельных приложений, что облегчает жизнь разработчикам. Еще один плюс реализация вещей, которые раньше казались неподъемными, например, канареечное развертывание, A/B-тестирование и т.п. Кроме того, вы получаете целостный подход к управлению микросервисными приложениями на всех своих кластерах OpenShift, что хорошо с точки зрения преемственности людей и непрерывности процессов. В конечном итоге, это поможет перейти от монолитных приложений к распределенной микросервисной архитектуре и работать в большей степени на уровне конфигураций, чем кода.

Традиционно конвейеры CI/CD строились поверх физических серверов и виртуальных машин. Контейнерные платформы, вроде Kubernetes и OpenShift, появились на этой сцене гораздо позже. Однако по мере того, как все больше и больше рабочих нагрузок переводится на платформу OpenShift, туда же движутся и конвейеры CI/CD, а конвейерные задания все чаще выполняются внутри контейнеров, работающих на кластере.

Этот пост представляет собой перевод блога нашего друга Алеса Носика, автора блога имени себя ("Helping you navigate the world of Kubernetes"). Девиз Алеса: "Software developer and architect passionate about new technologies, open-source and the DevOps culture. Making the world a better place with software".

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

В реальном мире компании не ограничиваются одним-единственным кластером OpenShift, а имеют их сразу несколько. Почему? Чтобы запускать рабочие нагрузки как в различных публичных облаках, так и на своих собственных ИТ-мощностях. Либо если организация хранит верность какому-то одному поставщику платформ для того, чтобы эффективно работать в различных регионах мира. А иногда необходимо иметь несколько кластеров и в одном регионе, например, при наличии нескольких зон безопасности, в каждой из которых должен быть свой кластер.

Как видим, у организаций есть масса причин иметь нескольких кластеров OpenShift. Соответственно, конвейеры CI/CD должны уметь работать в таких мультикластерных системах, и ниже мы расскажем, как проектировать такие конвейеры.

CI/CD-конвейер Jenkins

Jenkins это настоящая легенда в мире CI/CD. А ведь когда-то давно он назывался Hudson, впрочем, это совсем уже древняя история. Вернемся к нашей теме и зададимся вопросом, как построить конвейер Jenkins, охватывающий сразу несколько кластеров OpenShift? При проектировании такого конвейера очень важно предусмотреть единую информационную панель, где отображались бы результаты выполнения всех заданий, задействованных в этом конвейере. Если немного подумать, то для этого надо иметь некий главный Jenkins (назовем его мастер-Jenkins), который будет связан с каждым кластером OpenShift. При выполнении конвейера мастер-Jenkins сможет запускать отдельные задания на любом из подключенных кластеров, а журналы вывода заданий будут собираться отправляться на этот мастер-Jenkins, как обычно. Если у нас есть три кластера OpenShift (Dev, Test и Prod), то схема будет выглядеть следующим образом:

Для подключения Jenkins к OpenShift есть замечательный Kubernetes-plugin, с помощью которого мастер-Jenkins сможет создавать эфемерные worker-ы на кластере. Каждому кластеру можно присвоить свою метку узла, чтобы иметь возможность запускать каждый этап конвейера на разных кластерах, просто задавая соответствующую метку. Вот как выглядит простое определение такого конвейера:

stage ('Build') {  node ("dev") {    // running on dev cluster  }}stage ('Test') {  node ("test") {    // running on test cluster  }}stage ('Prod') {  node ("prod") {    // running on prod cluster  }}

В OpenShift есть специальный шаблон для Jenkins, который можно найти в проекте openshift. Этот шаблон позволяет создать мастер-Jenkins, который преднастроен для запуска worker-podов на одном кластере. А дальше придется приложить определенные усилия, чтобы подключить этот мастер-Jenkins к другим кластерам OpenShift, и вся хитрость здесь заключается в настройке сети. Jenkins-овский worker-pod после запуска подключается к мастер-Jenkins. Поэтому нам надо, чтобы мастер-Jenkins был доступен для worker-ов, работающих на любом из наших кластеров OpenShift.

Кроме того, стоит обсудить безопасность. Если мастер-Jenkins может запускать worker-овские pod-ы на OpenShift, то значит он может запускать на этих worker-ах произвольный код. Кластер OpenShift не имеет возможности контролировать, какой код запустит Jenkins-овский worker. Определения заданий управляется Jenkins, поэтому только Jenkins-овские средства контроля доступа решают, можно ли выполнять то или иное задание на том или ином кластере.

Kubernetes-нативный конвейер Tekton

Теперь посмотрим, как организовать мультикластерный конвейер CI/CDВ с помощью Tekton. В отличие от Jenkins, Tekton это Kubernetes-нативное решение: он реализован на основе строительных блоков Kubernetes и тесно интегрирован с Kubernetes. Естественная граница Tekton это кластер. И как тут построить конвейер, который будет охватывать сразу несколько кластеров OpenShift?

Для этого можно скомпоновать схему из несколько конвейеров Tekton. Чтобы объединить несколько конвейеров в один, мы создадим задачу execute-remote-pipeline, которая будет запускать Tekton-конвейер, расположенный на удаленном кластере OpenShift. При выполнении удаленного конвейера эта задача будет подхватывать его вывод. Теперь с помощью этой задачи мы можем объединять несколько конвейеров Tekton на разных кластерах OpenShift и запускать их как один конвейер. Например, на диаграмме ниже показана композиция из трех конвейеров, где каждый из них расположен на своем кластере OpenShift (Dev, Test и Prod):

Выполнение этого конвейера начинается на кластере Dev. Конвейер Dev запустит конвейер Test, который, в свою очередь, запустит конвейер Prod. Объединенные логи можно отследить к окне терминала:

$ tkn pipeline start dev --showlogPipelinerun started: dev-run-bd5fsWaiting for logs to be available...[execute-remote-pipeline : execute-remote-pipeline-step] Logged into "https://api.cluster-affc.sandbox1480.opentlc.com:6443" as "system:serviceaccount:test-pipeline:pipeline-starter" using the token provided.[execute-remote-pipeline : execute-remote-pipeline-step][execute-remote-pipeline : execute-remote-pipeline-step] You have one project on this server: "test-pipeline"[execute-remote-pipeline : execute-remote-pipeline-step][execute-remote-pipeline : execute-remote-pipeline-step] Using project "test-pipeline".[execute-remote-pipeline : execute-remote-pipeline-step] Welcome! See 'oc help' to get started.[execute-remote-pipeline : execute-remote-pipeline-step] [execute-remote-pipeline : execute-remote-pipeline-step] Logged into "https://api.cluster-affc.sandbox1480.opentlc.com:6443" as "system:serviceaccount:prod-pipeline:pipeline-starter" using the token provided.[execute-remote-pipeline : execute-remote-pipeline-step] [execute-remote-pipeline : execute-remote-pipeline-step][execute-remote-pipeline : execute-remote-pipeline-step] [execute-remote-pipeline : execute-remote-pipeline-step] You have one project on this server: "prod-pipeline"[execute-remote-pipeline : execute-remote-pipeline-step] [execute-remote-pipeline : execute-remote-pipeline-step][execute-remote-pipeline : execute-remote-pipeline-step] [execute-remote-pipeline : execute-remote-pipeline-step] Using project "prod-pipeline".[execute-remote-pipeline : execute-remote-pipeline-step] [execute-remote-pipeline : execute-remote-pipeline-step] Welcome! See 'oc help' to get started.[execute-remote-pipeline : execute-remote-pipeline-step] [execute-remote-pipeline : execute-remote-pipeline-step] [prod : prod-step] Running on prod cluster[execute-remote-pipeline : execute-remote-pipeline-step] [execute-remote-pipeline : execute-remote-pipeline-step][execute-remote-pipeline : execute-remote-pipeline-step]

Обратите внимание, что в этом примере показано каскадное выполнение конвейеров Tekton. Есть и способ компоновки последовательное выполнение нескольких удаленных конвейеров.

Прежде чем переходить к заключению, кратко обсудим компоновку конвейеров с точки зрения безопасности. Kubernetes-нативность Tekton означает, что все управление доступом в нем осуществляется через RBAC. Поэтому, чтобы задача, запущенная на локальном кластере (допустим, на кластере Test на нашей схеме), могла запустить конвейер на удаленном кластере (Prod), у нее должны быть соответствующие разрешения, которые задаются на удаленном кластере (Prod). Таким образом, удаленный кластер, работающий в среде более высоко уровня (Prod), может ограничивать доступ для задач, работающие в среде более низкого уровня (Test). Например, Prod может разрешать Test-у запускать только штатные продакшн-конвейеры, поэтому Test не сможет создавать новые конвейеры в кластере Prod.

Заключение

Итак, мы показали, как в Jenkins и Tekton создавать конвейеры CI/CD, охватывающие сразу несколько кластеров OpenShift, обсудив некоторые аспекты их проектирования, безопасности и реализации.

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

Автор: Ales Nosek

13 мая Алес расскажет про Apache Airflow на OpenShift, и там тоже можно будет задавать вопросы, получать подарки и все такое.

• 13 мая. Вебинар про бессерверные технологии в OpenShift
  Мы начинаем серию вебинаров, посвященных OpenShift'у и его окружению.
  Первый вебинар в серии про бессерверные технологии.

• 20 мая. Вебинар OpenShift Virtualization: Виртуальные машины, контейнеры и serverless вместе, в идеальном порядке
  Третий вебинар в серии про OpenShift Virtualization.

3 мая 2021 года Red Hat выпустила первую общедоступную версию OpenShift Pipelines, облачно-ориентированной системы непрерывной интеграции на базе СПО-проекта Tekton. Решение реализует Kubernetes фреймворк CI/CD для разработки и выполнения конвейеров, в которых каждый шаг запускается в своем собственном контейнере, что позволяет масштабировать шаги независимо друг от друга. Сегодня мы вкратце рассмотрим ключевые особенности и преимущества этого решения, а также приведем список дополнительных ресурсов для дальнейшего знакомства с ней и освоения.

Но, прежде чем переходить к OpenShift Pipelines, освежим в памяти основные концепты Tekton.

Основные концепты Kubernetes-нативной CI/CD

OpenShift Pipelines дополняет Kubernetes/OpenShift соответствующими CRD (ресурсами, определяемыми пользователем) для концептов CI/CD, таких как конвейер (pipeline), задача (task), шаг (step). В результате, эти концепты становятся своими (native) инстанцируемыми их можно создавать в виде отдельных экземпляров и, как следствие, полноценно масштабировать и развертывать, а также обеспечивать их безопасность средствами Kubernetes.

Поэтому для начала вспомним, что такое концепты Tekton:

По сути, основные концепты Tekton делятся на два вида: те, что задают конвейер, и те, что запускают конвейер.

Концепты, задающие конвейер (define pipeline)

• Task повторно используемые и слабо связанные серии шагов (step), которые выполняют определенную задачу, например, сборку контейнерного образа.

• Pipeline описание конвейера и задач (Task), которые он должен выполнять.

Концепты, запускающие конвейер (run pipelines)

• TaskRun запуск и результаты выполнения экземпляра Task.

• PipelineRun запуск и результаты выполнения экземпляра конвейера, который включает в себя ряд концептов TaskRun.

Подробнее об этих концептах можно почитать в официальной документации.

Теперь разберемся, что такое OpenShift Pipelines и для чего он нужен

Что такого особенного в OpenShift Pipelines?

OpenShift Container Platform это ведущая отраслевая Kubernetes-платформа корпоративного класса, которая предоставляет разработчикам множество функций, среди которых есть и CI/CD.

OpenShift Pipelines базируется на СПО-проекте Tekton и расширяет функционал платформы OpenShift стандратными методами, что сильно облегчает жизнь разработчикам.

Установка OpenShift Pipelines через механизм Operator

OpenShift Pipelines поддерживается на уровне механизма операторов, поэтому он легко устанавливается и обновляется, и, соответственно, легко администрируется.

OpenShift Pipelines доступен на сайте OperatorHub, где представлены более 450 различных операторов для OpenShift Container Platform:

Установка OpenShift Pipelines предельно проста, и он сразу устанавливается как оператор уровня кластера, автоматически становясь доступным для всех проектов:

OpenShift Pipelines также дополняет OpenShift соответствующими CR, которые позволят добиться еще большей универсальности в плане конфигурации и интеграции с консолью OpenShift и т.д.

При появлении в OperatorHub новой версии OpenShift Pipelines, вы как администратор можете выбрать обновление до следующей версии, задав нужный канал обновления.

Развитый UI в рамках консоли OpenShift

Tekton тоже дополняет стандартную поставку OpenShift концептами CI/CD, но в нем при создании и запуске конвейеров сложно обойтись без создания YAML-кода, и этого кода требуется писать очень много, тысячи строк. Поэтому Red Hat реализовала в консоли OpenShift полноценный UI для запуска и визуализации конвейеров (как тех, что работают сейчас, так и тех, что уже отработали), а также для графического создания конвейеров. При этом все необходимые YAML-файлы создаются автоматически, без написания какого-либо кода.

Ниже показано графическое представление конвейера, который уже был выполнен на платформе OpenShift, причем прямо из него можно получить доступ к журналам и событиям всех задач этого конвейера:

При желании можно легко просмотреть полный лог выбранной задачи:

Чтобы еще больше облегчить жизнь разработчикам, OpenShift Pipelines позволяет рисовать конвейеры прямо в консоли OpenShift, поэтому вам больше не нужен черный пояс по YAML, чтобы создать свой первый конвейер Tekton:

Но если вы, как обладатель черного пояса по YAML, захотите что-то подправить, это всегда можно сделать прямо из консоли OpenShift:

Более того, OpenShift Pipelines пригодится, даже если вы решите пойти по пути чистого YAML, и предложит вам готовые примеры и снипеты кода для более быстрой разработки конвейеров YAML. Кроме того, в систему можно интегрировать ваши корпоративные снипеты, сделав их доступными всем разработчикам. Именно для этого мы и добавили специальный CRD под названием ConsoleYAMLSamples.

События как триггеры для запуска конвейеров

Хотите увязать запуск конвейеров с некими внешними событиями (в терминах Tekton это называется Trigger), например, push- или pull-запросами Github или Gitlab? Вообще не проблема, в OpenShift Pipelines это есть из коробки, причем поддерживаются различные вендоры, включая Github, Gitlab, BitBucket и т.д.

Вы просто создаете нужный триггер в UI, а OpenShift сам формирует все необходимые концепты, такие как EventListeners, TriggerTemplates (подробнее о них можно почитать в официальной документации).

Готовые повторно используемые задачи и кастомизация

OpenShift Pipelines из коробки содержит десятки готовых задач, которые можно использовать в составе конвейеров, включая задачи по клонированию кода из репозитория, сборки приложений на различных языках программирования, таких как java, dotnet core, python go, nodejs или использования инструментов сборки вроде maven, развертывания приложений и т.д. Список доступных задач можно увидеть в консоли OpenShift, раздел ClusterTasks, меню Pipelines -> Tasks:

Кроме того, этот список можно легко расширить. Для этого достаточно добавить ClusterTasks в кластер, после чего вам станут доступны сотни дополнительных задач на сайте TektonHub, который представляет собой публичный репозиторий для обмена задачами Tekton:

Интеграция с IDE

Разработчики, использующие командную строку и IDE, могут воспользоваться преимуществами Tekton CLI, расширения Tekton для Visual Studio Code и плагина Tekton для IntelliJ, чтобы взаимодействовать с конвейерами прямо из своей обычной среды разработки и создавать, запускать, просматривать и выполнять действия на кластере непосредственно из командной строки.

Полезные ресурсы

В заключение советуем посмотреть видеоверсию этой статьи на английском:

А также рекомендуем следующие ресурсы (EN):

• Запись в блоге Red Hat к выпуску первых общедоступных версий OpenShift Pipelines и OpenShift GitOps

• Cтраница продукта OpenShift Pipelines

• Документация OpenShift Pipelines

• Интерактивные руководства по работе с OpenShift Pipelines

• Демовидео от Siamak Sadeghianfar, продакт-менеджера OpenShift Pipelines

• Серия статей Guide to OpenShift Pipelines в блоге Red Hat OpenShift

Видеоролики на русском:

• Все необходимое за две минуты

• Подробно про Tekton (включая предыдущий ролик с озвучкой)

Вебинары:

• 1 июня. Red Hat Advanced Cluster Security Надежная защита облачных приложений
  На вебинаре рассмотрим инструментыRed Hat Advanced Cluster Security, необходимые для обеспечения безопасности облачных приложений. Эксперты Red Hat и BCC расскажут, как Advanced Cluster Security защищает жизненно важные приложения на протяжении всего процесса сборки, развертывания и выполнения. Устраняет слепые зоны в безопасности и сокращает время и усилия, необходимые для реализации максимального уровня безопасности, а также упрощает анализ, расследование и исправление в системе безопасности

• 17 июня.Установка и операции второго дня
  Расскажем про то, как ставитьOpenShiftс помощью Helper Node и еще немного про Day-2, а также проведеммастер-класс, на котором объясним, что стоит проделать после того, как OpenShift вошел в вашу жизнь.

• OpenShift Serverless (в записи)

• OpenShift Virtualization (в записи)

• Принципы Cloud native apps design (в записи)

• 10 уровней контейнерной безопасности(в записи)

Пользователи продуктов Virtuozzo и OpenVZ обычно работают с множеством развернутых машин под управлением нашего ПО. Поэтому для них логично запустить централизованный мониторинг всего парка таких серверов. И сегодня мы расскажем о том, как использовать для этого встроенные сервисы мониторинга Virtuozzo Hybrid Infrastructure на основе Prometheus.

Схожие сервисы доступны и в VHS, но только если вы используете графические интерфейс для управления кластером Virtuozzo Storage. Если же у вас нет кластера Storage, или вы не используете GUI для его администрирования (либо работаете с OpenVZ, где подключение Virtuozzo Storage является возможным, но редко встречающимся сценарием), то для мониторинга приходится обращаться к сторонним решениям.

Анализ предпочтений пользователей (публично доступный для OpenVZ здесь) показывает следующее: как и для мониторинга серверов с Linux и основанных на нем решениями, для продуктов Virtuozzo популярны Zabbix и Prometheus.

Мы поговорим сегодня про Prometheus более молодой, но активно набирающий популярность инструментарий.

Непосредственно Prometheus занимается сбором данных от подвластных ему экспортеров - в репозиториях VHS доступны node_exporter (для сбора общих характеристик сервера, таких как использование ресурсов и состояние дисков) и libvirt_exporter (для сбора информации о виртуальных машинах, управляемых libvirt). Экспортеры основаны на соответствующих стандартных проектах, но содержат ряд специфичных для Virtuozzo изменений.

Для удобного изучения собираемой информации, в связке с Prometheus обычно устанавливается инструментарий визуализации данных Grafana, а для возможности получения оповещений о требующих внимания администратора событиях Alertmanager.

Готовим плацдарм

Prometheus, Grafana и Alertmanager можно развернуть на отдельной машине, не обязательно физической. Раз уж мы говорим о Virtuozzo Hybrid Server, то логично развернуть их внутри контейнера на одной из машин VHS. Например, внутри контейнера с Virtuozzo Linux 8; для функционирования вполне достаточно двух ядер ЦПУ и пары гигабайт памяти:

# prlctl create promct --vmtype=ct --ostemplate=vzlinux-8-x86_64# prlctl set promct --cpu 2# prlctl set promct --memsize 2G

Не забудьте выставить необходимый IP адрес и доменное имя, по которым будет доступен ваш контейнер.

Внутри контейнера не помешает выставить правильный часовой пояс:

# timedatectl set-timezone 'Europe/Moscow'

А также настроить firewall порт 9090 для веб-интерфейса Prometheus, 9093 для AlertManager и 3000 для Grafana. Обратите внимание, что веб Prometheus и Alertmanager доступны без пароля, так что выставляйте их только в ваши внутренние сети.

# firewall-cmd --zone=public --permanent --add-port=9090/tcp# firewall-cmd --zone=public --permanent --add-port=9093/tcp# firewall-cmd --zone=public --permanent --add-port=3000/tcp# firewall-cmd --reload

Устанавливаем Prometheus & co.

Prometheus входит в репозитории многих дистрибутивов, в том числе и Virtuozzo Linux 8, поэтому можно его установить штатными средствами:

# yum install prometheus

Если вас не устраивает версия из дистрибутива (например, хочется самую свежую, либо наоборот - свежая имеет какие-то раздражающие вас проблемы), то можно просто скачать бинарные файлы с GitHub и положить их в директорию /opt (или в другую на ваш выбор). Например, для версии 2.21.0:

# cd /opt# wget https://github.com/prometheus/prometheus/releases/download/v2.21.0/prometheus-2.21.0.linux-amd64.tar.gz# tar -xzf prometheus*.tar.gz

Единственный нюанс при ручной установке - не забыть создать (либо скорректировать) service-файл для systemd, чтобы там были правильные пути:

# cat /lib/systemd/system/prometheus.service[Unit]Description=PrometheusWants=network-online.targetAfter=network-online.target[Service]Type=simpleWorkingDirectory=/opt/prometheus-2.21.0.linux-amd64Restart=on-failureExecStart=/opt/prometheus-2.21.0.linux-amd64/prometheus[Install]WantedBy=multi-user.target

Аналогично с Alertmanager - можно установить из репозиториев:

# yum install alertmanager

... А можно и с сайта, точно также не забыв service-файл:

# wget https://github.com/prometheus/alertmanager/releases/download/v0.21.0/alertmanager-0.21.0.linux-amd64.tar.gz# cd /opt# tar -xzf alertmanager*.tar.gz# cat /usr/lib/systemd/system/alertmanager.service[Unit]Description=AlertmanagerWants=network-online.targetAfter=network-online.targetAfter=prometheus.service[Service]Type=simpleWorkingDirectory=/root/alertmanager-0.21.0.linux-amd64Restart=on-failureExecStart=/root/alertmanager-0.21.0.linux-amd64/alertmanager --config.file=alertmanager.yml[Install]WantedBy=multi-user.target

Grafana сразу предоставляет собранные rpm-пакеты, так что можно, опять же, поставить либо из дистрибутива:

# yum install grafana

либо с сайта проекта:

# yum install https://dl.grafana.com/oss/release/grafana-7.1.5-1.x86_64.rpm

Подготавливаем машины с Virtuozzo Hybrid Server

На каждом сервере VHS, который предполагается мониторить, необходимо установить пакеты с экспортерами:

# yum install node_exporter libvirt_exporter

Чтобы экспортеры могли отдавать данные в Prometheus, необходимо открыть соответствующие порты - 9177 для libvirt_exporter и 9100 для node_exporter. Доступ к ним желательно ограничить адресом машины с Prometheus, чтобы посторонние люди не делали попыток снять метрики с ваших серверов:

# firewall-cmd --permanent --zone=public --add-rich-rule=' rule family="ipv4" source address="1.2.3.4/32" port protocol="tcp" port="9177" accept'# firewall-cmd --permanent --zone=public --add-rich-rule=' rule family="ipv4" source address="1.2.3.4/32" port protocol="tcp" port="9100" accept'# firewall-cmd --reload

Здесь "1.2.3.4" необходимо поменять на реальный адрес Prometheus.

Наконец, смело включаем и запускаем сервисы экспортеров:

# systemctl enable node_exporter# systemctl enable libvirt-exporter# systemctl start node_exporter# systemctl start libvirt-exporter

Дело за малым - надо сообщить Прометею, откуда ему собирать информацию.

Настройка Prometheus

Конфигурация самого Prometheus содержится в наборе Yaml-файлов. Писать их с нуля, даже с помощью примеров из документации то еще развлечение. Именно этот процесс и решили улучшить в Virtuozzo, положив в репозитории VHS 7 пакет vz-prometheus-cfg с шаблонами файлов конфигурации. Его можно установить на любой машине VHS 7, а если вы развернули Prometheus внутри VzLinux 8 то можно его поставить прямо на сервере из репозиториев этого дистрибутива:

# yum install vz-prometheus-cfg

После чего изучать директорию /usr/share/vz-prometheus-cfg/, начав с файла prometheus-example.yml.

Этот файл необходимо отредактировать под ваши нужды и под именем prometheus.yml сохранить в машину или контейнер, где у вас расположен Prometheus. Главное, что там необходимо изменить это местоположение файлов *rules.yml и *alerts.yml, которые также можно скопировать из директории /usr/share/vz-prometheus-cfg/ на сервер Prometheus. Можно их изучить и даже отредактировать, однако они вполне работоспособны и в исходном варианте.

В первую очередь здесь интересны vz-rules, содержащие правила сбора информации о потреблении ресурсов (диска, процессора, памяти и сети) виртуальными окружениями и предупреждения о проблемах с ресурсами (останов ВМ из-за ошибки диска, исчерпание диска на сервере и тому подобное).

Непосредственно машины, с которых надо собирать информацию, указываются в target-файлах. В первом приближении достаточно одного такого файла со списком машин для каждого экспортера (напомним, node_exporter отдает информацию на порту 9100, а libvirt - 9177):

# cat my-vz-libvirt.yml- labels: group: my-vz-deployment targets: - my.node1:9177 - my.node2:9177# cat my-vz-node.yml- labels: group: my-vz-deployment targets: - my.node1:9100 - my.node2:9100

Пути к этим файлам необходимо указать в соответствующих разделах секции scrape_configs в prometheus.yml:

scrape_configs: ... - job_name: node ... file_sd_configs: - files: - /root/prometheus-2.21.0.linux-amd64/targets/my-vz-node.yml - job_name: libvirt ... file_sd_configs: - files: - /root/prometheus-2.21.0.linux-amd64/targets/my-vz-libvirt.yml

Пример полного файла конфигурации можно посмотреть в документации: https://docs.virtuozzo.com/virtuozzo_hybrid_server_7_users_guide/advanced-tasks/monitoring-via-prometheus.html. Обратите внимание, что важными параметрами являются job_name на них идет отсылка в файлах с правилами и алертами. Так что если задумаете менять эти имена не забудьте пройтись и по другим файлами конфигурации и провести соответствующие замены.

Как только все необходимые файлы отредактированы - пора стартовать сервисы:

# systemctl start prometheus# systemctl start alertmanager# systemctl start grafana-server

После чего продолжать уже с настройкой двух других инструментов

Grafana и Alertmanager

Конфигурация Grafana осуществляется через ее веб-интерфейс по адресу http://<ваш-сервер>:3000. Логин-пароль по умолчанию - "admin" / "admin".

Настройка достаточно проста и стандартна - сначала необходимо указать "Prometheus" как источник данных, пройдя в Configuration -> Data Sources -> "Add data source", выбрав "Prometheus" и указав http://localhost:9090 в качестве его адреса.

Далее можно импортировать готовые json-файлы, опять же поставляемые с пакетов vz-prometheus-cfg - grafana_hn_dashboard.json и grafana_ve_dashboard.json - служащие соответственно для отображения информации о серверах и о виртуальных окружениях. Импорт осуществляется в меню "Dashboards" -> "Manage" -> "Import", в качестве источника данных необходимо добавить настроенный ранее Prometheus.

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

Наконец, настройка оповещений Alertmanager тут все на ваше усмотрение, готовых рецептов а-ля отправить отчет в саппорт Virtuozzo не предусмотрено. Так что можно, например, просто настроить типичные оповещения по email в /etc/alertmanager/alertmanager.yaml:

route:   receiver: 'email'  group_by: ['alertname', 'cluster']   group_wait: 30s   group_interval: 5m   repeat_interval: 3h   receivers:  - name: 'email'   email_configs:   - to: 'admin@myserver.com'   from: 'vz-alert@myserver.com'   smarthost: smtp.myserver.com:587

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

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

В первой части Разработка стековой виртуальной машины и компилятора под неё (часть I) сделал свою элементарную стековую виртуальную машину, которая умеет работать со стеком, делать арифметику с целыми числами со знаком, условные переходы и вызовы функций с возвратом. Но так как целью было создать не только виртуальную машину, но и компилятор C подобного языка, пришло время сделать первые шаги в сторону компиляции. Опыта никакого. Буду действовать по разумению.

Одним из первых этапов компиляции является синтаксический анализ (parsing) исходного кода нашего "C подобного языка" (кстати, надо какое-то название дать как только он станет более формальным). Задача простая - "нарубить" массив символов (исходный код) на список классифицированных токенов, чтобы последующий разбор и компиляция не вызывали сложности.

Итак, первый шаг - определиться с типами токенов (интуитивно будем ориентироваться на синтаксис C), символами которые будут отделять токены друг от друга, а также определить структуру для хранения токена (тип, текст токена, длина, строка и столбец в исходном коде).

constexpr char* BLANKS = "\x20\n\t";constexpr char* DELIMETERS = ",;{}[]()=><+-*/&|~^!.";enum class TokenType {NONE = 0, UNKNOWN, IDENTIFIER,CONST_CHAR, CONST_INTEGER, CONST_REAL, CONST_STRING,COMMA, MEMBER_ACCESS, EOS, OP_BRACES, CL_BRACES, OP_BRACKETS, CL_BRACKETS, OP_PARENTHESES, CL_PARENTHESES,BYTE, SHORT, INT, LONG, CHAR, FLOAT, DOUBLE, STRING, IF, ELSE, WHILE, RETURN,ASSIGN, EQUAL, NOT_EQUAL, GREATER, GR_EQUAL, LESS, LS_EQUAL,PLUS, MINUS, MULTIPLY, DIVIDE, AND, OR, XOR, NOT, SHL, SHR,LOGIC_AND, LOGIC_OR, LOGIC_NOT};typedef struct {TokenType type;          char* text;              WORD length;             WORD row;                WORD col;                } Token;

Далее напишем класс для разбора, ключевым методом которого станет parseToTokens(char*). Тут алгоритм простой: идем до разделителя (BLANKS и DELIMETERS), определяем начало и конец токена, классифицируем его и добавляем в вектор (список) токенов. Особые случаи разбора - это отличать целые числа от вещественных, вещественные числа (например, "315.0") отличать от применения оператора доступа к членам структуры/объекта ("obj10.field1"), а также отличать ключевые слова от других идентификаторов.

void VMParser::parseToTokens(const char* sourceCode) {TokenType isNumber = TokenType::UNKNOWN;bool insideString = false;                                         // inside string flagbool isReal = false;                                               // is real number flagsize_t length;                                                     // token length variablechar nextChar;                                                     // next char variablebool blank, delimeter;                                             // blank & delimeter char flagstokens->clear();                                                   // clear tokens vectorrowCounter = 1;                                                    // reset current row counterrowPointer = (char*)sourceCode;                                    // set current row pointer to beginningchar* cursor = (char*)sourceCode;                                  // set cursor to source beginning char* start = cursor;                                              // start new token from cursorchar value = *cursor;                                              // read first char from cursorwhile (value != NULL) {                                            // while not end of stringblank = isBlank(value);                                          // is blank char found?delimeter = isDelimeter(value);                                  // is delimeter found?length = cursor - start;                                         // measure token length    // Diffirentiate real numbers from member access operator '.'isNumber = identifyNumber(start, length - 1);                    // Try to get integer part of real numberisReal = (value=='.' && isNumber==TokenType::CONST_INTEGER);     // Is current token is real numberif ((blank || delimeter) && !insideString && !isReal) {          // if there is token separator                   if (length > 0) pushToken(start, length);                      // if length > 0 push token to vectorif (value == '\n') {                                           // if '\n' found rowCounter++;                                                // increment row counterrowPointer = cursor + 1;                                     // set row beginning pointer}nextChar = *(cursor + 1);                                      // get next char after cursorif (!blank && isDelimeter(nextChar)) {                         // if next char is also delimeterif (pushToken(cursor, 2) == TokenType::UNKNOWN)              // try to push double char delimeter tokenpushToken(cursor, 1);                                      // if not pushed - its single char delimeterelse cursor++;                                               // if double delimeter, increment cursor} else pushToken(cursor, 1);                                   // else push single char delimeterstart = cursor + 1;                                            // calculate next token start pointer}else if (value == '"') insideString = !insideString;             // if '"' char - flip insideString flag else if (insideString && value == '\n') {                        // if '\n' found inside string// TODO warn about parsing error}cursor++;                                                        // increment cursor pointervalue = *cursor;                                                 // read next char}length = cursor - start;                                           // if there is a last tokenif (length > 0) pushToken(start, length);                          // push last token to vector}

Наряду с методом parseToTokens, помогать в разборе и классификации нам будут простые методы, определяющие разделители и тип найденного токена. Плюс метод добавления токена в вектор.

class VMParser {public:VMParser();~VMParser();void parseToTokens(const char* sourceCode);Token getToken(size_t index);size_t getTokenCount();  private:vector<Token>* tokens;WORD rowCounter;char* rowPointer;  bool isBlank(char value);bool isDelimeter(char value);TokenType pushToken(char* text, size_t length);TokenType getTokenType(char* text, size_t length);TokenType identifyNumber(char* text, size_t length);TokenType identifyKeyword(char* text, size_t length);};

Попробуем используя класс VMParser разобрать строку исходного кода C подобного языка (исходный код бессмысленный, просто набор случайных токенов для проверки разбора):

int main(){    printf ("Wow!");    float a = 365.0 * 10 - 10.0 / 2 + 3;while (1 != 2) {    abc.v1 = 'x';}if (a >= b) return a && b; else a || b; };

В итоге получаем в консоли следующий перечень классифицированных токенов:

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

Для простоты сначала реализуем компилятор арифметических выражений с целыми числами (приоритет "*" и "/" над "+" и "-" учитывается), без скобок, унарных операций и других важных вещей, в том числе проверки синтаксических ошибок. Разбор выражений напишем вот так:

void VMCompiler::parseExpression(size_t startIndex, VMImage* destImage) {Token tkn;currentToken = startIndex;parseTerm(destImage);tkn = parser->getToken(currentToken);while (tkn.type==TokenType::PLUS || tkn.type==TokenType::MINUS) {  currentToken++;  parseTerm(destImage);  if (tkn.type==TokenType::PLUS) destImage->emit(OP_ADD); else destImage->emit(OP_SUB);  tkn = parser->getToken(currentToken);}}void VMCompiler::parseTerm(VMImage* destImage) {Token tkn;parseFactor(destImage);currentToken++;tkn = parser->getToken(currentToken);while (tkn.type == TokenType::MULTIPLY || tkn.type == TokenType::DIVIDE) {  currentToken++;  parseFactor(destImage);  if (tkn.type == TokenType::MULTIPLY) destImage->emit(OP_MUL); else destImage->emit(OP_DIV);  currentToken++;  tkn = parser->getToken(currentToken);}}void VMCompiler::parseFactor(VMImage* destImage) {Token tkn = parser->getToken(currentToken);char buffer[32];strncpy(buffer, tkn.text, tkn.length);buffer[tkn.length] = 0;destImage->emit(OP_CONST, atoi(buffer));}

Попробуем скормить этому компилятору выражение "3+5*6+2*3+15/5", запускаем компилятор с выводом скомпилированных команд и сразу запускаем виртуальную машину. Ожидаем, что результат вычисления должен остаться на вершине стека - 42.

Ура! Получилось! Первые шаги в сторону компилятора сделаны.

По ходу разработки генератора кода для виртуальной машины понял, что виртуальная машина не готова к полноценным вызовам функций, с передачей аргументов и хранением локальных переменных функций. Поэтому её необходимо доработать. А именно, нужно определиться с Соглашением о вызовах (calling convention). Есть много разных вариантов, но конечный выбор за разработчиком. Главное - это обеспечить целостность стека, после вызова.

Соглашение о вызовах (calling convention) - это правила по которым при вызове функции передаются аргументы в вызываемую функцию (стек/регистры, порядок), кто и как очищает стек после вызова (вызывающий/вызываемый) и как возвращается результат функции в точку вызова (стек/регистр). Ко всему прочему, вызываемые функции могут создавать локальные переменные, которые будут хранится в стеке, что тоже необходимо учитывать, особенно, чтобы работала рекурсия.

На сегодняшний день, наиболее знакомые мне Соглашения о вызове (calling convention), регулирующее правила передачи аргументов функции, очистки стека после вызова, а также логика хранения локальных переменных - это C declaration (cdecl, x86/64) и pascal. Попробую применить эти знания с небольшими модификациями, а именно без прямого доступа программы к регистрам виртуальной машины (она же всё таки стековая, а не регистровая). Итак, логика будет следующая:

Поясню что происходит. Функция main() вызывает функцию sum() и передаёт ей два аргумента - значение переменной i и константное число 10. Осуществляется передача аргументов путём добавления значений аргументов в стек слева направо (как в pascal). После чего осуществляется вызов функции инструкцией виртуальной машины call, которой указывается адрес вызова и количество передаваемых через стек аргументов - 2.

Дальше команда call должна сделать следующие вещи:
1) сохранить в стек адрес возврата после вызова IP (Instruction Pointer + 1)
2) сохранить в стек значение Frame Pointer (регистр виртуальной машины, которым мы показываем до куда очищать стек после вызова).
3) сохраняем в стек значение Locals Pointer (регистр указывающий на место в стеке где начинаются локальные переменные вызывающей функции).
4) выставить значение Frame Pointer на первый аргумент в стеке, чтобы мы знали докуда очищать стек после завершения выполнения функции.
5) выставить значение Locals Pointer на адрес в стеке сразу после сохранных значение IP, FP, LP.

В свою очередь команда ret должна выполнить действия в обратном порядке:
1) Восстановить из стека предыдущие значения IP, FP, LP.
2) Взять результат выполнения функции с вершины стека.
3) Выставить SP = FP (очистить стек в состояние до вызова).
4) Положить на вершину стека результат выполнения функции.

Так как делаем стековую, а не регистровую виртуальную машину, не хочу давать прямой доступ к регистрам, поэтому доработаем инструкцию CALL / RET, а также добавим четыре дополнительные инструкции LOAD (положить в стек значение локальной переменной с указанным индексом), STORE (взять верхнее значение в стеке и сохранить в локальной переменной с указанным индексом), ARG (добавить в стек значение аргумента функции с указанным индексом), а также DROP - инструкция выбросить из стека верхнее значение. Последняя инструкция DROP нужна для функций значение которых нам не нужно, так как мы не даём прямой доступ к регистрам.

case OP_CALL:a = memory[ip++];      // get call address and increment addressb = memory[ip++];      // get arguments count (argc)b = sp + b;            // calculate new frame pointermemory[--sp] = ip;     // push return address to the stackmemory[--sp] = fp;     // push old Frame pointer to stackmemory[--sp] = lp;     // push old Local variables pointer to stackfp = b;                // set Frame pointer to arguments pointerlp = sp - 1;           // set Local variables pointer after top of a stackip = a;                // jump to call addressbreak;case OP_RET:a = memory[sp++];      // read function return value on top of a stackb = lp;                // save Local variables pointersp = fp;               // set stack pointer to Frame pointer (drop locals)lp = memory[b + 1];    // restore old Local variables pointerfp = memory[b + 2];    // restore old Frame pointerip = memory[b + 3];    // set IP to return addressmemory[--sp] = a;      // save return value on top of a stackbreak;case OP_LOAD:a = memory[ip++];         // read local variable indexb = lp - a;               // calculate local variable addressmemory[--sp] = memory[b]; // push local variable to stackbreak;case OP_STORE:a = memory[ip++];         // read local variable indexb = lp - a;               // calculate local variable addressmemory[b] = memory[sp++]; // pop top of stack to local variablebreak;case OP_ARG:a = memory[ip++];         // read parameter indexb = fp - a - 1;           // calculate parameter addressmemory[--sp] = memory[b]; // push parameter to stackbreak;case OP_DROP:                   // pop and drop value from stacksp++;break;

Скомпилируем код представленный на иллюстрации выше чтобы протестировать как работают новые инструкции CALL, RET, LOAD, STORE, ARG (примечание: syscall 0x21 - это распечатка числа с вершины стека в консоль):

Запустим исполнение этого кода с распечаткой состояния виртуальной машины после выполнения каждой инструкции:

[   0]    iconst  5     IP=2 FP=65535 LP=65534 SP=65534 STACK=[5] -> TOP[   2]    iload   #0    IP=4 FP=65535 LP=65534 SP=65533 STACK=[5,5] -> TOP[   4]    idec          IP=5 FP=65535 LP=65534 SP=65533 STACK=[5,4] -> TOP[   5]    idup          IP=6 FP=65535 LP=65534 SP=65532 STACK=[5,4,4] -> TOP[   6]    istore  #0    IP=8 FP=65535 LP=65534 SP=65533 STACK=[4,4] -> TOP[   8]    idup          IP=9 FP=65535 LP=65534 SP=65532 STACK=[4,4,4] -> TOP[   9]    iconst  10    IP=11 FP=65535 LP=65534 SP=65531 STACK=[4,4,4,10] -> TOP[  11]    call [32], 2  IP=32 FP=65533 LP=65527 SP=65528 STACK=[4,4,4,10,14,65535,65534] -> TOP[  32]    iconst  10    IP=34 FP=65533 LP=65527 SP=65527 STACK=[4,4,4,10,14,65535,65534,10] -> TOP[  34]    iarg    #0    IP=36 FP=65533 LP=65527 SP=65526 STACK=[4,4,4,10,14,65535,65534,10,4] -> TOP[  36]    iarg    #1    IP=38 FP=65533 LP=65527 SP=65525 STACK=[4,4,4,10,14,65535,65534,10,4,10] -> TOP[  38]    iadd          IP=39 FP=65533 LP=65527 SP=65526 STACK=[4,4,4,10,14,65535,65534,10,14] -> TOP[  39]    iload   #0    IP=41 FP=65533 LP=65527 SP=65525 STACK=[4,4,4,10,14,65535,65534,10,14,10] -> TOP[  41]    isub          IP=42 FP=65533 LP=65527 SP=65526 STACK=[4,4,4,10,14,65535,65534,10,4] -> TOP[  42]    ret           IP=14 FP=65535 LP=65534 SP=65532 STACK=[4,4,4] -> TOP[  14]    syscall 0x21  IP=16 FP=65535 LP=65534 SP=65533 STACK=[4,4] -> TOP[  16]    iconst  0     IP=18 FP=65535 LP=65534 SP=65532 STACK=[4,4,0] -> TOP[  18]    icmpjg  [2]   IP=2 FP=65535 LP=65534 SP=65534 STACK=[4] -> TOP[   2]    iload   #0    IP=4 FP=65535 LP=65534 SP=65533 STACK=[4,4] -> TOP[   4]    idec          IP=5 FP=65535 LP=65534 SP=65533 STACK=[4,3] -> TOP[   5]    idup          IP=6 FP=65535 LP=65534 SP=65532 STACK=[4,3,3] -> TOP[   6]    istore  #0    IP=8 FP=65535 LP=65534 SP=65533 STACK=[3,3] -> TOP[   8]    idup          IP=9 FP=65535 LP=65534 SP=65532 STACK=[3,3,3] -> TOP[   9]    iconst  10    IP=11 FP=65535 LP=65534 SP=65531 STACK=[3,3,3,10] -> TOP[  11]    call [32], 2  IP=32 FP=65533 LP=65527 SP=65528 STACK=[3,3,3,10,14,65535,65534] -> TOP[  32]    iconst  10    IP=34 FP=65533 LP=65527 SP=65527 STACK=[3,3,3,10,14,65535,65534,10] -> TOP[  34]    iarg    #0    IP=36 FP=65533 LP=65527 SP=65526 STACK=[3,3,3,10,14,65535,65534,10,3] -> TOP[  36]    iarg    #1    IP=38 FP=65533 LP=65527 SP=65525 STACK=[3,3,3,10,14,65535,65534,10,3,10] -> TOP[  38]    iadd          IP=39 FP=65533 LP=65527 SP=65526 STACK=[3,3,3,10,14,65535,65534,10,13] -> TOP[  39]    iload   #0    IP=41 FP=65533 LP=65527 SP=65525 STACK=[3,3,3,10,14,65535,65534,10,13,10] -> TOP[  41]    isub          IP=42 FP=65533 LP=65527 SP=65526 STACK=[3,3,3,10,14,65535,65534,10,3] -> TOP[  42]    ret           IP=14 FP=65535 LP=65534 SP=65532 STACK=[3,3,3] -> TOP[  14]    syscall 0x21  IP=16 FP=65535 LP=65534 SP=65533 STACK=[3,3] -> TOP[  16]    iconst  0     IP=18 FP=65535 LP=65534 SP=65532 STACK=[3,3,0] -> TOP[  18]    icmpjg  [2]   IP=2 FP=65535 LP=65534 SP=65534 STACK=[3] -> TOP[   2]    iload   #0    IP=4 FP=65535 LP=65534 SP=65533 STACK=[3,3] -> TOP[   4]    idec          IP=5 FP=65535 LP=65534 SP=65533 STACK=[3,2] -> TOP[   5]    idup          IP=6 FP=65535 LP=65534 SP=65532 STACK=[3,2,2] -> TOP[   6]    istore  #0    IP=8 FP=65535 LP=65534 SP=65533 STACK=[2,2] -> TOP[   8]    idup          IP=9 FP=65535 LP=65534 SP=65532 STACK=[2,2,2] -> TOP[   9]    iconst  10    IP=11 FP=65535 LP=65534 SP=65531 STACK=[2,2,2,10] -> TOP[  11]    call [32], 2  IP=32 FP=65533 LP=65527 SP=65528 STACK=[2,2,2,10,14,65535,65534] -> TOP[  32]    iconst  10    IP=34 FP=65533 LP=65527 SP=65527 STACK=[2,2,2,10,14,65535,65534,10] -> TOP[  34]    iarg    #0    IP=36 FP=65533 LP=65527 SP=65526 STACK=[2,2,2,10,14,65535,65534,10,2] -> TOP[  36]    iarg    #1    IP=38 FP=65533 LP=65527 SP=65525 STACK=[2,2,2,10,14,65535,65534,10,2,10] -> TOP[  38]    iadd          IP=39 FP=65533 LP=65527 SP=65526 STACK=[2,2,2,10,14,65535,65534,10,12] -> TOP[  39]    iload   #0    IP=41 FP=65533 LP=65527 SP=65525 STACK=[2,2,2,10,14,65535,65534,10,12,10] -> TOP[  41]    isub          IP=42 FP=65533 LP=65527 SP=65526 STACK=[2,2,2,10,14,65535,65534,10,2] -> TOP[  42]    ret           IP=14 FP=65535 LP=65534 SP=65532 STACK=[2,2,2] -> TOP[  14]    syscall 0x21  IP=16 FP=65535 LP=65534 SP=65533 STACK=[2,2] -> TOP[  16]    iconst  0     IP=18 FP=65535 LP=65534 SP=65532 STACK=[2,2,0] -> TOP[  18]    icmpjg  [2]   IP=2 FP=65535 LP=65534 SP=65534 STACK=[2] -> TOP[   2]    iload   #0    IP=4 FP=65535 LP=65534 SP=65533 STACK=[2,2] -> TOP[   4]    idec          IP=5 FP=65535 LP=65534 SP=65533 STACK=[2,1] -> TOP[   5]    idup          IP=6 FP=65535 LP=65534 SP=65532 STACK=[2,1,1] -> TOP[   6]    istore  #0    IP=8 FP=65535 LP=65534 SP=65533 STACK=[1,1] -> TOP[   8]    idup          IP=9 FP=65535 LP=65534 SP=65532 STACK=[1,1,1] -> TOP[   9]    iconst  10    IP=11 FP=65535 LP=65534 SP=65531 STACK=[1,1,1,10] -> TOP[  11]    call [32], 2  IP=32 FP=65533 LP=65527 SP=65528 STACK=[1,1,1,10,14,65535,65534] -> TOP[  32]    iconst  10    IP=34 FP=65533 LP=65527 SP=65527 STACK=[1,1,1,10,14,65535,65534,10] -> TOP[  34]    iarg    #0    IP=36 FP=65533 LP=65527 SP=65526 STACK=[1,1,1,10,14,65535,65534,10,1] -> TOP[  36]    iarg    #1    IP=38 FP=65533 LP=65527 SP=65525 STACK=[1,1,1,10,14,65535,65534,10,1,10] -> TOP[  38]    iadd          IP=39 FP=65533 LP=65527 SP=65526 STACK=[1,1,1,10,14,65535,65534,10,11] -> TOP[  39]    iload   #0    IP=41 FP=65533 LP=65527 SP=65525 STACK=[1,1,1,10,14,65535,65534,10,11,10] -> TOP[  41]    isub          IP=42 FP=65533 LP=65527 SP=65526 STACK=[1,1,1,10,14,65535,65534,10,1] -> TOP[  42]    ret           IP=14 FP=65535 LP=65534 SP=65532 STACK=[1,1,1] -> TOP[  14]    syscall 0x21  IP=16 FP=65535 LP=65534 SP=65533 STACK=[1,1] -> TOP[  16]    iconst  0     IP=18 FP=65535 LP=65534 SP=65532 STACK=[1,1,0] -> TOP[  18]    icmpjg  [2]   IP=2 FP=65535 LP=65534 SP=65534 STACK=[1] -> TOP[   2]    iload   #0    IP=4 FP=65535 LP=65534 SP=65533 STACK=[1,1] -> TOP[   4]    idec          IP=5 FP=65535 LP=65534 SP=65533 STACK=[1,0] -> TOP[   5]    idup          IP=6 FP=65535 LP=65534 SP=65532 STACK=[1,0,0] -> TOP[   6]    istore  #0    IP=8 FP=65535 LP=65534 SP=65533 STACK=[0,0] -> TOP[   8]    idup          IP=9 FP=65535 LP=65534 SP=65532 STACK=[0,0,0] -> TOP[   9]    iconst  10    IP=11 FP=65535 LP=65534 SP=65531 STACK=[0,0,0,10] -> TOP[  11]    call [32], 2  IP=32 FP=65533 LP=65527 SP=65528 STACK=[0,0,0,10,14,65535,65534] -> TOP[  32]    iconst  10    IP=34 FP=65533 LP=65527 SP=65527 STACK=[0,0,0,10,14,65535,65534,10] -> TOP[  34]    iarg    #0    IP=36 FP=65533 LP=65527 SP=65526 STACK=[0,0,0,10,14,65535,65534,10,0] -> TOP[  36]    iarg    #1    IP=38 FP=65533 LP=65527 SP=65525 STACK=[0,0,0,10,14,65535,65534,10,0,10] -> TOP[  38]    iadd          IP=39 FP=65533 LP=65527 SP=65526 STACK=[0,0,0,10,14,65535,65534,10,10] -> TOP[  39]    iload   #0    IP=41 FP=65533 LP=65527 SP=65525 STACK=[0,0,0,10,14,65535,65534,10,10,10] -> TOP[  41]    isub          IP=42 FP=65533 LP=65527 SP=65526 STACK=[0,0,0,10,14,65535,65534,10,0] -> TOP[  42]    ret           IP=14 FP=65535 LP=65534 SP=65532 STACK=[0,0,0] -> TOP[  14]    syscall 0x21  IP=16 FP=65535 LP=65534 SP=65533 STACK=[0,0] -> TOP[  16]    iconst  0     IP=18 FP=65535 LP=65534 SP=65532 STACK=[0,0,0] -> TOP[  18]    icmpjg  [2]   IP=20 FP=65535 LP=65534 SP=65534 STACK=[0] -> TOP[  20]    ---- halt ----IP=21 FP=65535 LP=65534 SP=65534 STACK=[0] -> TOPEXECUTION TIME: 0.620997s

В консоли данная программа выдает следующее

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

Ура! Это вдохновляет!

Недавно Battlestate Games, разработчики Escape From Tarkov, наняли BattlEye для реализации шифрования сетевых пакетов, чтобы мошенники не могли перехватить эти пакеты, разобрать их и использовать в своих интересах в виде радарных читов или иным образом. Сегодня подробно расскажем, как мы взломали их шифрование спустя несколько часов.

Анализ EFT

Мы начали с анализа самого "Escape from Tarkov". В игре используется Unity Engine, который, в свою очередь, использует C# промежуточный язык, а это означает, что можно очень легко просмотреть исходный код игры, открыв его в таких инструментах, как ILDasm или dnSpy. В этом анализе мы работали с dnSpy.

Unity Engine без опции IL2CPP генерирует игровые файлы и помещает их в GAME_NAME_Data\Managed, в нашем случае это EscapeFromTarkov_Data\Managed. Эта папка содержит все использующие движок зависимости, включая файл с кодом игры Assembly-CSharp.dll, мы загрузили этот файл в dnSpy, а затем искали строку encryption и оказались здесь:

Этот сегмент находится в классе EFT.ChannelCombined, который, как можно судить по переданным ему аргументам, работает с сетью:

Правый клик по переменной channelCombined.bool_2, которая регистрируется как индикатор того, было ли включено шифрование, а затем клик по кнопке Analyze показывают нам, что на эту переменную ссылаются два метода:

Второй из них тот, в котором мы сейчас находимся, так что, дважды щёлкнув по первому, мы окажемся здесь:

Вуаля!Есть вызов BEClient.EncryptPacket, клик по методу приведёт к классу BEClient, его мы можем препарировать и найти метод DecryptServerPacket. Этот метод вызывает функцию pfnDecryptServerPacket в библиотеке BEClient_x64.dll. Она расшифрует данные в пользовательском буфере и запишет размер расшифрованного буфера в предоставленный вызывающим методом указатель.

pfnDecryptServerPacket не экспортируется BattlEye и не вычисляется EFT, на самом деле он поставляется инициализатором BattlEye, который в какой-то момент вызывается игрой. Нам удалось вычислить RVA (Relative Virtual Address), загрузив BattlEye в свой процесс и скопировав то, как игра инициализирует его. Код этой программы лежит здесь.

Анализ BattlEye

В последнем разделе мы сделали вывод, что, чтобы выполнить все свои криптографические задачи, EFT вызывает BattlEye. Так что теперь речь идёт о реверс-инжинеринге не IL, а нативного кода, что значительно сложнее.

BattlEye использует защитный механизм под названием VMProtect, который виртуализирует и изменяет указанные разработчиком сегменты. Чтобы правильно выполнить реверс-инжинеринг защищённого этим обфускатором бинарника, нужно распаковать его.

Распаковка это дамп образа процесса во время выполнения; мы сделали дамп, загрузив его в локальный процесс, а затем поработав в Scylla, чтобы сбросить его память на диск.

Открытие этого файла в IDA, а затем переход к процедуре DecryptServerPacket приведут нас к функции, которая выглядит так:

Это называется vmentry, она добавляет на стек vmkey, а затем вызывает обработчика виртуальной машины vminit. Хитрость вот в чём: из-за того, что инструкции виртуализированы VMProtect, они понятны только самой программе.

К счастью для нас, участник Секретного Клуба can1357 сделал инструмент, который полностью ломает эту защиту, VTIL; его вы найдёте здесь.

Выясняем алгоритм

Созданный VTIL файл сократил функцию с 12195 инструкций до 265, что значительно упростило проект. Некоторые процедуры VMProtect присутствовали в дизассемблированном коде, но они легко распознаются и их можно проигнорировать, шифрование начинается отсюда:

Вот эквивалент в псевдо-Си:

uint32_t flag_check = *(uint32_t*)(image_base + 0x4f8ac);if (flag_check != 0x1b)goto 0x20e445;elsegoto 0x20e52b;

VTIL использует свой собственный набор инструкций, чтобы ещё больше упростить код. Я перевёл его на псевдо-Си.

Мы анализируем эту процедуру, войдя в 0x20e445, который является переходом к 0x1a0a4a, в самом начале этой функции они перемещают sr12 копию rcx (первый аргумент в соглашении о вызове x64 по умолчанию) и хранят его на стеке в [rsp+0x68], а ключ xor в [rsp+0x58]. Затем эта процедура переходит к 0x1196fd, вот он:

И вот эквивалент в псевдо-Си:

uint32_t xor_key_1 = *(uint32_t*)(packet_data + 3) ^ xor_key;(void(*)(uint8_t*, size_t, uint32_t))(0x3dccb7)(packet_data, packet_len, xor_key_1);

Обратите внимание, что rsi это rcx, а sr47 это копия rdx. Так как это x64, они вызывают 0x3dccb7 с аргументами в таком порядке: (rcx, rdx, r8). К счастью для нас, vxcallq во VTIL означает вызов функции, приостановку виртуального выполнения, а затем возврат в виртуальную машину, так что 0x3dccb7 не виртуализированная функция! Войдя в эту функцию в IDA и нажав F5, вы вызовете сгенерированный декомпилятором псевдокод:

Этот код выглядит непонятно, в нём какие-то случайные ассемблерные вставки, и они вообще не имеют значения. Как только мы отменим эти инструкции, изменим некоторые типы var, а затем снова нажмём F5, код будет выглядеть намного лучше:

Эта функция расшифровывает пакет в несмежные 4-байтовые блоки, начиная с 8-го байта, с помощью ключа шифра rolling xor.

Примечание от переводчика:

Rolling xor шифр, при котором операция xor буквально прокатывается [отсюда rolling] по байтам:

• Первый байт остаётся неизменным.

• Второй байт это результат xor первого и второго оригинальных байтов.

• Третий байт результат XOR изменённого второго и оригинального третьего байтов и так далее. Реализация здесь.

Продолжая смотреть на ассемблер, мы поймём, что она вызывает здесь другую процедуру:

Эквивалент на ассемблере x64:

mov t225, dword ptr [rsi+0x3]mov t231, byte ptr [rbx]add t231, 0xff ; uhoh, overflow; the following is psuedomov [$flags], t231 u< rbx:8not t231movsx t230, t231mov [$flags+6], t230 == 0mov [$flags+7], t230 < 0movsx t234, rbxmov [$flags+11], t234 < 0mov t236, t234 < 1mov t235, [$flags+11] != t236and [$flags+11], t235mov rdx, sr46 ; sr46=rdxmov r9, r8sbb eax, eax ; this will result in the CF (carry flag) being written to EAXmov r8, t225mov t244, raxand t244, 0x11 ; the value of t244 will be determined by the sbb from above, it'll be either -1 or 0 shr r8, t244 ; if the value of this shift is a 0, that means nothing will happen to the data, otherwise it'll shift it to the right by 0x11mov rcx, rsimov [rsp+0x20], r9mov [rsp+0x28], [rsp+0x68]call 0x3dce60

Прежде чем мы продолжим разбирать вызываемую им функцию, мы должны прийти к следующему выводу: сдвиг бессмыслен из-за того, что флаг переноса не установлен, а это приводит к возвращаемому из инструкции sbb значению 0; в свою очередь, это означает, что мы не на правильном пути.

Если поискать ссылки на первую процедуру 0x1196fd, то увидим, что на неё действительно ссылаются снова, на этот раз с другим ключом!

Это означает, что первый ключ на самом деле направлял по ложному следу, а второй, скорее всего, правильный. Хороший Бастиан!

Теперь, когда мы разобрались с реальным ключом xor и аргументами к 0x3dce60, которые расположены в таком порядке: (rcx, rdx, r8, r9, rsp+0x20, rsp+0x28). Переходим к этой функции в IDA, нажимаем F5 и теперь прочитать её очень легко:

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

Заключение

Это шифрование было не самым сложным для реверс-инжиниринга, и наши усилия, безусловно, были замечены BattlEye; через 3 дня шифрование было изменено на TLS-подобную модель, где для безопасного обмена ключами AES используется RSA. Это делает MITM без чтения памяти процесса неосуществимым во всех смыслах и целях.

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

Узнайте, как прокачаться и в других специальностях или освоить их с нуля:

• Профессия Data Scientist

• Профессия Data Analyst

• Курс по Data Engineering

Новая порция инсайтов, мероприятий, книжек и шпаргалок. Оставайтесь с нами станьте частью DevNation!

Узнать новое:

• Anacron для более удобной работы с crontab
  Вместо того, чтобы вручную выполнять повторяющиеся задачи, позвольте Linux сделать все за Вас

• Гайд по команде git stash
  Узнайте, когда и как пользоваться командой git stash

• Быстрая конфигурация SD-карт для кластера Raspberry Pi
  Создавайте несколько SD-карт, которые сконфигурированы для кластеров Pi с помощью Cloudmesh Pi Burner.

• 3 причины использовать команду Git cherry-pick

• DevOps-руководство по документации

• 20 способов стать продуктивным и начать уважать себя

• Как разделить диск на разделы под Linux с помощью GNU Parted

Скачать:

• Шпаргалка по SQLite
  Держите под рукой полезный список распространенных команд SQLite

Почитать на досуге:

• Электронная книга: Переход на .NET Core на Red Hat Enterprise Linux
  Здесь уже скачана на Google Drive

• Безопасность в числе главных приоритетов при поддержке исследований в IT

• Бесплатный онлайн-курс: "Разработка облачных приложений с микросервисной архитектурой"

• Понять разработчика: иллюстрированное руководство по графикам

• 7 вопросов для собеседования на позицию Site Reliability Engineer (SRE)

• 5 малоизученных, но полезных команд Linux для сисадминов

Мероприятия:

• Виртуальный Red Hat Summit 2021, 27-28 апреля
  Бесплатная онлайн-конференция Red Hat Summit это отличный способ узнать последние новости ИТ-индустрии, задать свои вопросы техническим экспертам, услышать истории успеха непосредственно от заказчиков Red Hat и увидеть, как открытый код генерирует инновации в корпоративном секторе.

• Cook Your Own Cloud: OpenShift + OpenStack + немного перца! 30 апреля
  Миграция на облачную платформу тем актуальнее, чем сложнее инфраструктура и выше число изменений. Как насчет того, чтобы автоматизировать рутинные задачи и сконцентрироваться на бизнес-процессах? Мы в Red Hat знаем, как создать облачное решение для IaaS и PaaS- платформ. И мы хотим поделиться своим опытом! На вебинаре архитектор Дмитрий Алехин расскажет про связку Red Hat Openstack Platform и Red Hat Openshift Container Platform, которые позволяют осуществить стратегию открытого гибридного облака. Регистрируйтесь и приходите!

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

Узнать новое:

• 6 советов по защите Linux-сервера для начинающих
  Воспользуетесь ими, чтобы сделать свою среду Linux более безопасной.

• Играем в прикольную арифметическую игру с помощью команд Linux
  Почему бы не устроить британское телевикторину Countdown у себя дома?

• 4 способа переключения контекста в Git
  Сравниваем плюсы и минусы четырех подходов к смене бранчей в Git.

• 5 причин, по которым сисадмин должен любить systemd

• Как зариповать и каталогизировать свои аудио-CD с помощью опенсорсных инструментов

• Как сбрасывать сканы документов на Linux-машину по сети

• Балансировка нагрузки, руководство для начинающих

Скачать:

• Шпаргалка по Linux-командам для работы сетями
  Основные команды и что можно узнать с их помощью.

• Шпаргалка по GNU Screen
  В GNU Screen есть море клавиатурных команд. Часто используемые запоминаются легко, а вот за остальными приходится обращаться к экрану справки. Или их можно распечатать и держать под рукой.

Что еще интересного:

• Бесплатный онлайн-курс Основы Ansible

• Шпаргалка по Linux-командам для работы с текстом, дисками, сетями и учетными записями

• Бесплатная запись Red Hat Summit 2021

• 5 аппаратных архитектур для машинного обучения на edge-системах

• 5 признаков, что вам надо поработать над эмоциональным интеллектом

• Домашняя автоматизация: запускаем Home Assistant через Podman

Мероприятия:

• 6 мая. DevNation: The Show

Вебинары:

• 13 мая. Вебинар про бессерверные технологии в OpenShift
  Мы начинаем серию вебинаров, посвященных OpenShift'у и его окружению.

  Первый вебинар в серии про бессерверные технологии.

• 20 мая. Вебинар OpenShift Virtualization: Виртуальные машины, контейнеры и serverless вместе, в идеальном порядке
  Третий вебинар в серии про OpenShift Virtualization