Сегодня мы рассмотрим сбор и визуализацию метрик производительности Red Hat Enterprise Linux 8 с помощью инструментов Performance Co-Pilot (PCP), Grafana и Bpftrace, а также новые возможности по контролю производительности, которые появились в веб-консоли RHEL 8.4.
Всем привет. В этой статье мы расскажем об аппаратных платформах, которые используются в качестве узлов вычисления и хранения для российской гиперконвергентной системы АЭРОДИСК vAIR v2. Также в этой статье мы расскажем о схеме лицензирования программного обеспечения vAIR, его поддержке и затронем вопрос об аттестации по требованиям ФСТЭК.
По ходу разработки генератора кода для виртуальной машины понял, что виртуальная машина не готова к полноценным вызовам функций, с передачей аргументов и хранению локальных переменных функций. Поэтому её необходимо доработать. А именно, нужно определиться с Соглашением о вызовах (calling convention). Есть много разных вариантов, но выбор конечный за разработчиком. Главное - это обеспечить целостность стека, после вызова.
Соглашение о вызовах (calling convention) - это правила по которым при вызове функции передаются аргументы в вызываемую функцию (стек/регистры, порядок), кто и как очищает стек после вызова (вызывающий/вызываемый) и как возвращается результат функции в точку вызова (стек/регистр). Ко всему прочему, вызываемые функции могут создавать локальные переменные, которые будут хранится в стеке, что тоже необходимо учитывать, особенно, чтобы работала рекурсия.
На сегодняшний день, наиболее знакомое мне Соглашение о вызове (calling convention), регулирующее правила передачи аргументов функции, очистки стека после вызова, а также логика хранения локальных переменных - это C declaration (cdecl, x86/64) и pascal. Попробую применить эти знания с небольшими модификациями, а именно без прямого доступа программы к регистрам виртуальной машины (она же всё таки стековая, а не регистровая). Итак, логика будет следующая.
Собрали для вас много полезных ссылок, шпаргалок, мероприятий и книжек в нашем новом полезном дайджесте. Оставайтесь с нами – станьте частью DevNation!
В конце апреля 2021 года Red Hat анонсировала новую редакцию своей платформы OpenShift – OpenShift Platform Plus, в состав которой входит решение Red Hat Advanced Cluster Security for Kubernetes на основе технологий компании StackRox. Сегодня мы расскажем, какие задачи безопасности OpenShift закрывает этот продукт, а также разберем преимущества реализованного в нем Kubernetes-ориентированного подхода к защите контейнерных приложений.
Всем привет. В компании Convergent, где я работаю, в проектные команды часто входят несколько разработчиков: это могут быть специалисты по бэкенду, фронтенду и/или вёрстке. Проекты чаще всего разрабатываются на PHP, что обуславливает зависимости от различных внешних тулов вроде баз данных, систем полнотекстового поиска и прочего. И здесь кроется большая проблема: коллеги, работающие в Linux, который лежит в основе web-разработки, проблем не испытывают. А вот пользователи Windows получают головную боль.
Как решить эту проблему? У себя в компании мы используем несколько вариантов. В этой статье я решил поделиться нашими наработками.
В первой части Разработка стековой виртуальной машины и компилятора под неё (часть I) сделал свою элементарную стековую виртуальную машину, которая умеет работать со стеком, делать арифметику с целыми числами со знаком, условные переходы и вызовы функций с возвратом. Но так как целью было создать не только виртуальную машину, но и компилятор C подобного языка, пришло время сделать первые шаги в сторону компиляции. Опыта никакого. Буду действовать по разумению.
Одним из первых этапов компиляции является лексический разбор исходного кода нашего "C подобного языка" (кстати, надо какое-то название дать как только он станет более формальным). Задача простая - "нарубить" массив символов (исходный код) на список классифицированных токенов, чтобы последующий синтаксический разбор и генерация кода не вызывали сложности.
Image (c) Opensource.com
Новая порция инсайтов, мероприятий, книжек и шпаргалок. Оставайтесь с нами – станьте частью DevNation!
Не далее пяти дней назад на хабре появилась новость под заголовком "В Apple M1 нашли уязвимость M1RACLES — возможна быстрая скрытая передача данных между приложениями". В одном предложении суть формулируется так: в Apple M1 нашли регистр, который кто угодно может читать и писать из непривилегированного режима. Значит, это можно использовать для обмена данными в обход механизмов межпроцессного взаимодействия, предоставленных ОС.
В комментариях к этой публикации развязалась умеренно оживлённая дискуссия о статусе находки: всё-таки серьёзная уязвимость или пустяк? Наряду с @SergeyMaxи @wataru я обратил внимание, что каналов скрытого обмена и так существует предостаточно просто потому, что исполняющая клиентский софт или виртуальные машины аппаратура является разделяемой средой, грамотная модуляция состояний которой делает возможным произвольный обмен данными вне зависимости от инвариантов нижележащей ОС или гипервизора. Противоположной точки зрения придерживаются почтенные господа @creker и @adjachenko, утверждая, что доселе известные побочные каналы качественно уступают возможностям M1RACLES.
Эта заметка является наглядной иллюстрацией к моему утверждению о легкодоступности скрытых каналов обмена. Я собрал простой PoC из ~500 строк на C++, при помощи которого был успешно отправлен файл из одной виртуальной машины в другую на том же физическом хосте. Далее я кратко описываю его устройство, пределы применимости, и привожу выводы и мнение самого автора M1RACLES в конце.
Так сложилось, что за последние 18 лет, не приходилось писать на C/C++. На работе использовалась Java, да и ввиду должностей деятельность больше была связана с предпринимательством - переговоры, корпоративные продажи, выстраивание производственных операций и структурирование инвестиционных сделок. Захотелось в свободное от работы время восстановить навыки, размять часть мозга которую не напрягал все 18 лет и, естественно, начать с самых основ. Осталось придумать себе задачу.
В универе преподаватели, молодость которых приходилась на 70-80е годы, до объектно-ориентированного программирования убивались по теме разработке собственных языков (интерпретаторов, компиляторов) под предметные области. Всё это казалось мне невостребованным "старьём", но появление новых языков за последнее десятилетие (Go, Kotlin и множества других) повысили мой интерес к этой теме.
Решил в качестве хобби написать 32-bit стековую виртуальную машину и компилятор C подобного языка под неё, чтобы восстановить базовые навыки. Такая классическая Computer Science задачка для заполнения вечеров с пивом. Как предприниматель, я четко понимаю, что она никому не нужна, но такая практика нужна мне для эстетического инженерного удовольствия. Плюс когда об этом рассказываешь сам понимаешь глубже. С целью и мотивами определился. Начнём.
Так как это виртуальная машина, мне нужно определиться с её характеристиками:
CPU: 32-bitный набор команд, так как машина стековая, в основном операнды команд храним в стеке, из регистров только IP (Instruction Pointer) и SP (Stack Pointer), пока работаем с целыми числами со знаком (__int32), позже добавим остальные типы данных.
RAM: пусть памяти пока будет 65536 ячеек по 32-bit`а. Которую организуем просто. С нижних адресов в верх будут идти код (code/text) и данные (data, heap), а с верхних адресов вниз будет расти стек (stack). Дёшево и сердито.
Пользователи продуктов Virtuozzo и OpenVZ обычно работают с множеством развернутых машин под управлением нашего ПО. Поэтому для них логично запустить централизованный мониторинг всего парка таких серверов. И сегодня мы расскажем о том, как использовать для этого встроенные сервисы мониторинга Virtuozzo Hybrid Infrastructure на основе Prometheus.
3 мая 2021 года Red Hat выпустила первую общедоступную версию OpenShift Pipelines, облачно-ориентированной системы непрерывной интеграции на базе СПО-проекта Tekton. Решение реализует kubernetes фреймворк CI/CD для разработки и выполнения конвейеров, в которых каждый шаг запускается в своем собственном контейнере, что позволяет масштабировать шаги независимо друг от друга. Сегодня мы вкратце рассмотрим ключевые особенности и преимущества этого решения, а также приведем список дополнительных ресурсов для дальнейшего знакомства с ней и освоения.
Привет, Хабр! Я Александр Воронцов, технический специалист Cloud4Y. В этой статье расскажу про vSphere Virtual Machine Encryption. Здесь не будет описания опыта внедрения. Это, скорее, обзор технологии и её неочевидных нюансов и особенностей, не описанных в документации. Я постараюсь дать ответы на вопросы, которые могут возникнуть у специалиста в процессе изучения.
Демонстрацию буду проводить на тестовом стенде vSphere 6.7 U3, Cloud Director 10.2
Image (c) enterprisersproject.com
Собрали для вас много новых инсайтов, записей важных вебинаров, книжек и шпаргалок. Прокачивайте скилы, читайте, смотрите, думайте, применяйте на практике! Станьте частью DevNation!
Продолжаем публиковать блог нашего друга Алеса Носека. В первой части мы поговорили про CI/CD-конвейеры с охватом нескольких кластеров OpenShift. А сегодня расскажем об архитектуре системы Apache Airflow на платформе OpenShift, рассмотрим функции ее ключевых компонентов и способы их развертывания применительно к Apache Airflow версии 1.10.12.
Мы знаем, как провести эти праздники максимально полезно: собрали для вас много новых инсайтов, записей важных вебинаров, книжек и шпаргалок. Прокачивайте скилы, читайте, смотрите, думайте, применяйте на практике! Станьте частью DevNation!
Традиционно конвейеры CI/CD строились поверх физических серверов и виртуальных машин. Контейнерные платформы, вроде Kubernetes и OpenShift, появились гораздо позже. Однако по мере того, как все больше и больше рабочих нагрузок переводится на платформу OpenShift, туда же движутся и конвейеры CI/CD – они выполняются внутри контейнеров, работающих на кластере.
