Academic Earth — огромная библиотека бесплатных курсов обо всем на свете от ведущих специалистов мира. От обучения химии и информатике до бизнеса и психологии;
Classcentral — самый удобный поисковик по бесплатным курсам на любую тему;
Edx — тут собраны обучающие курсы от самых топовых ВУЗов мира, таких как Гарвард, Стэнфорд и Массачусетский технологический институт. Разумеется, бесплатно;
Google Garage Courses — библиотека бесплатных курсов от Google с возможностью получить карьерный сертификат от технологического гиганта;
Khanacademy — лучший сайт для углубленного изучения математики и других прикладных наук;
Udemy — для тех, кто планирует работать в «диджитале»: отличные курсы по программированию, дизайну, веб‑разработке, графике;
Treehouse — мастхэв для будущих программистов. Простые и понятные курсы по Python, Data Science, React и другим темам.
Хотите выяснить, где учиться IT? В экосистеме Хабра есть маркетплейс курсов на Хабр Карьере, на котором собраны сотни онлайн‑обучений в самых разных специализациях: программировании, аналитике, дизайне, менеджменте и других. Чтобы пользователи могли проверить качество курсов, там показаны отзывы от тех, кто уже прошел обучение — изучайте и выбирайте лучшее для себя.
Cloud GPU: как работает и для каких задач используется
GPU в облаке — это вычислительный ресурс для задач с высокой долей параллельных операций. Такие серверы используют, когда стандартных CPU недостаточно по производительности или времени выполнения. Ниже — как устроен Cloud GPU и для каких задач его применяют на практике на примере сервиса в Рег.облаке.
Cloud GPU — это виртуальный сервер с подключенным графическим ускорителем. Он используется для:
обучения и использования моделей ИИ;
обработки изображений, видео и звука;
3D-моделирования и рендеринга;
параллельных вычислений и аналитики.
Инфраструктура Cloud GPU построена на серверах с процессорами AMD EPYC и накопителями NVMe SSD. Используются видеокарты NVIDIA A4000 (16 ГБ), A5000 (24 ГБ) и A100 (80 ГБ). Для работы доступен готовый образ Ubuntu GPU с предустановленными библиотеками и инструментами для ML и ИИ. Управлять серверами можно через облачную платформу.
Сервис работает по модели pay-as-you-go — пользователь оплачивает только фактическое время работы GPU. Такой формат подходит для сценариев с переменной нагрузкой: обучение и дообучение моделей, периодические расчеты и inference.
количество пользователей Cloud GPU выросло на 189%;
среднее время выполнения задачи на одном сервере составило 15 часов в сутки;
среднее количество дней использования GPU на одного клиента выросло в два раза;
48% пользователей повторно заказывают Cloud GPU для новых задач.
Cloud GPU используют в e-commerce, розничной торговле и сфере услуг для аналитики, рекомендательных систем и автоматизации процессов. Наиболее востребованной видеокартой за последние шесть месяцев стала NVIDIA A5000 (24 ГБ) — ее выбрали почти 60% пользователей как сбалансированный вариант для ML- и inference-задач.
Больше о технических параметрах сервиса, доступных конфигурациях и условиях использования GPU Cloud можно узнать на сайте Рег.облака.
Программист Тирекс написал праздничное веб-приложение с обратным отсчетом до Нового года и хочет поздравить им всех коллег. Приложение уже собрано: в директории web находятся готовые статические артефакты (HTML, JavaScript и изображения). У Тирекса есть TLS-сертификат и приватный ключ, и он хочет, чтобы приложение работало по HTTPS.
Задача
Нужно упаковать приложение в Docker-контейнер, чтобы его можно было легко запускать на любом сервере, и сделать доступным из интернета. Времени у Тирекса осталось совсем немного!
Как разделить строку в Python: «split()» и альтернативы для разработчиков и аналитиков данных
Разделение строк — рутина для разработчиков и аналитиков: парсинг CSV, обработка логов, пользовательского ввода. Подготовили подробный обзор, где разобрали, как работает «split()» (включая «sep» и «maxsplit»), когда выбирать «partition()/rpartition()», «splitlines()», преобразование в список символов и «re.split()» для сложных правил. И добавили практические примеры, где и какой подход удобнее и надежнее применять.
Запуск GitLab Runner в Yandex Cloud Serverless Containers
Я Павел Елисеев, старший разработчик в команде Serverless в Yandex Cloud. Мы реализовали сценарий использования сервиса — Serverless GitLab Runner. В посте покажу архитектуру и поделюсь кодом решения.
GitLab Runner — агент, выполняющий задачи (jobs) из CI/CD‑пайплайнов GitLab. Он получает инструкции от GitLab, запускает сборку, тесты или деплой в нужной среде и передаёт результат обратно.
Раннер работает в разных окружениях:
на общих серверах GitLab (shared runners);
на выделенных VM;
в K8s‑кластере.
В первом варианте репозитории должны размещаться на gitlab.com. В случае Managed GitLab или self‑hosted GitLab развёртывание выполняется самостоятельно.
Для shared‑раннеров free‑tier ограничен 400 мин./мес. Учёт идёт по формуле (duration × price-factor), так что число доступных минут зависит от используемого типа раннера. А за пределами лимита нужна привязка не российской банковской карты.
Serverless‑сценарии пытались реализовать на Cloud Functions, что требовало отдельной VM и сложной конфигурации. А мы хотели объединить плюсы serverless‑модели с CI‑задачами:
оплата за время
масштабирование за секунды
изоляция выполнения
отсутствие инфраструктурной рутины
Архитектура
GitLab Runner работает по модели pull: запускает процесс, устанавливающий long‑polling‑соединение с GitLab API, и ожидает появления задач.
Пришла задача — раннер выбирает executor:
shell — job выполняется в текущем окружении
docker — под job создаётся отдельный контейнер со всеми зависимостями
Эта модель плохо подходит для serverless‑окружения, где нельзя держать постоянно активный процесс.
Для перехода на push‑модель используем GitLab Webhooks — HTTP‑уведомления о событиях. С появлением задач GitLab отправляет вебхук в Serverless Container, который:
запускает раннер;
получает информацию о задаче;
выполняет её и возвращает результат в GitLab.
Так, выполнение задачи инициируется событием, а не постоянным опросом API.
Для упрощённого развёртывания есть лёгкий образ раннера с поддержкой docker-executor, размещённый в Container Registry. Раннер автоматически загружает и запускает контейнер, указанный в конфигурации job. Секреты для аутентификации в GitLab API хранятся в Lockbox.
GitLab требует от обработчика вебхуков быстрого ответа без ошибки. А выполнение задачи может занимать часы. Поэтому вебхуки обрабатываются асинхронно:
GitLab отправляет вебхук.
Платформа проверяет авторизацию и сразу отвечает 202 Accepted.
Обработка выполняется асинхронно в фоне.
Платформа решает, запускать ли новый экземпляр контейнера. Когда job завершается, контейнер остаётся активным какое‑то время, чтобы обработать вызовы без cold‑start.
GitLab не отправляет событие «создание job», поэтому раннер сперва проверяет, есть ли задачи со статусом pending.
Для docker‑executor требуется dockerd. Инициализация демона и подготовка окружения выполняются 1 раз при старте контейнера. Если job найдётся, запускается эфемерный раннер, исполняющий ровно 1 задачу.
Раннер загружает docker‑образ, выполняет команды, передаёт результат обратно через GitLab API.
Docker внутри Serverless Containers. Это не Docker‑in‑Docker: внутри serverless‑контейнера jobs исполняются без отдельного демона Docker, но с аналогичной логикой. Примеры есть в исходном коде.
Важные особенности serverless‑подхода
Эфемерность: кеш между вызовами отсутствует. Для хранения артефактов используйте Object Storage или свои базовые образы.
Загрузка образов: выполняется при каждом запуске. Рекомендуем использовать оптимизированные образы и близкий реестр (Cloud Registry), а при критичных требованиях к скорости старта — перейти на shell‑executor, собрав образ с установленным раннером и нужными зависимостями.
Ограничение времени: не более 1 часа. Для длинных задач разделите пайплайн на этапы с промежуточным сохранением результатов.
Ограничение по диску: до 10 ГБ.
Сценарий Serverless GitLab Runner позволяет выполнять CI/CD‑задачи GitLab, оплачивая лишь время выполнения job. Serverless Containers дают возможности для CI‑нагрузок: асинхронные вызовы, часовой таймаут, эфемерный диск и поддержку docker‑executor внутри контейнера.
Проект с открытым исходным кодом bookhunter позволяет охотиться за книгами. Не нужно искать по сети и натыкаться на ограничения. Решение имеет удобный интерфейс.
Еще один вариант маршрутизации трафика через два сетевых интерфейса на основе списка доменных имен.
Сразу оговорюсь: все лучшие и хорошие варианты решения этой проблемы уже были рассмотрены на Хабре. Но для тех, кто использует linux и кого существующие варианты почему-либо не устраивают, предлагаю рассмотреть еще один.
Краткое содержание: ставим локальный dns resolver с плагином на python, который, при разрешении имени в адрес, устанавливает маршрут через альтернативный интерфейс, если адрес соответствует регулярному выражению. Для использования решения требуется умение сконфигурировать и запустить сервис в вашем любимом дистрибутиве/сервис-менеджере, готового пакета для установки нет.
Для реализации идеи нужен ДНС сервер, который позволяет достаточно просто писать плагины/хуки. Первым попавшимся на глаза был PowerDNS Recursor, который позволяет писать плагины на lua. И первая реализация была для него. Но lua это больше про компактность, чем про удобство, например, поддержку регулярных выражений можно так назвать только из вежливости. Тем не менее, всё работало как предполагалось, и достаточно надежно, пока не был найден Unbound DNS который позволяет писать плагины на python, и, в итоге, был написан аналог на питоне, который и предлагаю вашему вниманию.
Файл reroute.conf: пример файла конфигурации ДНС сервера. 192.168.0.1 и 172.16.17.1 — это адреса маршрутизаторов для первого и второго интерфейсов, соответственно. /etc/unbound/reroute.py — собственно плагин выполняющий основную работу. Из существенных моментов: chroot необходимо отключить, чтобы могли нормально работать скрипты на python и сервис должен работать от root чтобы добавлять маршруты.
Файл reroute.py — плагин, который выполняет необходимые дествия, reroute_conf.py — файл конфигурации для плагина, можно записать оба параметра прямо в плагин и обойтись без него. Вся работа выполняется в функции do_reroute, весь остальной код взят, практически без изменений, из документации unbound dns.
Файл rrdomains.txt — список регулярных выражений в формате python regex, при совпадении с которыми для всех ip-адресов разрешаемого доменного имени выполняется установка альтернативного маршрута.
Файл bashrc содержит определение функции reroute. Если во время работы наткнулись на сайт, для которого необходима маршрутизация через второй интерфейс, можно воспользоваться быстрым перенаправлением с помощью команды reroute в терминале. Или добавить доменное имя или регулярное выражение для него в rrdomains.txt и перезапустить dns сервер.
Обновили PaaS в Рег.облаке: конфигуратор DBaaS и Kubernetes 1.34
В Рег.облаке мы постоянно развиваем наши PaaS-сервисы, чтобы давать пользователям больше гибкости и контроля для удобства работы с IT-инфраструктурой. Сегодня представляем два крупных обновления: гибкий конфигуратор для управляемых баз данных в облаке и свежую версию Kubernetes в нашем KaaS. Разбираем, что изменилось и как это упростит работу с IT-проектами.
1. DBaaS: забываем про готовые тарифы. Привет, конфигуратор!
Раньше для Managed PostgreSQL и MySQL в Рег.облаке был доступен набор готовых конфигураций. Это просто, но не всегда идеально: где-то не хватало RAM, где-то были дополнительные vCPU, а для нестандартных нагрузок приходилось брать тариф с запасом. Теперь DBaaS можно точно калибровать под свои бизнес-требования и бюджет.
Что поменялось: мы запустили полностью гибкий конфигуратор. Теперь вы сами собираете кластер, как конструктор:
выбираете точное количество vCPU (от 1);
задаете нужный объем RAM;
определяете размер диска.
В цифрах: это дает 2 761 возможную конфигурацию для точного подбора ресурсов. А значит — точное соответствие вашей задаче:
Платите только за то, что действительно используете. Для тестового стенда — минимум ресурсов, а для высоконагруженного продакшена — мощная конфигурация без компромиссов.
Баланс производительности: теперь можно тонко сбалансировать соотношение vCPU/RAM/Диск под специфику своей нагрузки (CPU-bound или I/O-bound задачи), добиваясь оптимальной цены и скорости.
Горизонтальная и вертикальная масштабируемость: по мере роста нагрузки можно увеличить или уменьшить количество vCPU и RAM (масштабирование «вверх-вниз») и расширить дисковое пространство.
2. KaaS: встречаем Kubernetes 1.34
Kubernetes-as-a-Service (KaaS) обновили до актуальной версии Kubernetes 1.34. Релиз принес 58 улучшений, и мы уже интегрировали его в нашу платформу Рег.облака. Основные направления — безопасность, стабильность и операционная гибкость.
На что обратить внимание:
Усиление безопасности: появились новые декларативные политики безопасности, которые помогают контролировать доступ к ресурсам кластера на более тонком уровне. Это еще один шаг к Security-by-design.
Стабильность API: критически важные интерфейсы стали еще надежнее, что уменьшает риски при обновлениях и работе сторонних инструментов.
Улучшения в управлении ресурсами и производительности: под капотом — множество оптимизаций в работе с подами, узлами и сетевыми плагинами, которые положительно скажутся на отзывчивости и эффективности кластеров.
Теперь кластеры становятся быстрее, стабильнее и безопаснее. Вы получаете доступ к современному стеку технологий, не тратя время на самостоятельное обновление и отладку control plane.
Все новшества уже доступны в панели управления Рег.облака. Нам важно ваше мнение — пробовали уже гибкие конфигурации БД, какие задачи планируете решать с помощью KaaS? Задавайте вопросы в комментариях — обсудим детали.
Открытый проект Digler помогает спасти удалённые файлы на жёстком диске, проводит глубокий анализ SSD или HDD и может вернут утерянные данные. Работает со всеми файловыми системами, даже если метаданные отсутствуют. Сканирует не только физические SSD, но и образы дисков. Создаёт детальные отчёты, которые помогут точечно спасти нужные файлы. Умеет работать с файлами любых форматов.
Российский IT-рынок после шторма: подкаст с Фиделиной
Всем привет! Я — Данила Трусов, директор продукта «Инферит ИТМен». Недавно я стал гостем подкаста ИТ-блогера Фиделины, где мы подробно разбирали, что на самом деле произошло с отечественным IT-рынком и какие выводы можно сделать сейчас. В разговоре затронули несколько важных тем:
насколько зрелыми стали отечественные решения спустя несколько лет после «шторма»;
почему импортозамещение — это не просто замена ПО, а пересборка процессов;
с какими ошибками компании сталкиваются чаще всего при переходе на российские продукты;
какие возможности появились у разработчиков и вендоров в новых условиях.
Отдельно говорили о практических кейсах и о том, почему без понимания собственного IT-ландшафта любые изменения быстро упираются в потолок.
А мы продолжаем дарить подарки хорошим айтишникам. Вы точно оцените наши сюрпризы: в адвенте — скидки и кешбэк до 100% на сервисы и IT-инфраструктуру. Заглядывайте каждый день в календарь, чтобы узнать, что мы спрятали для вас сегодня. 18 декабря дарим кешбэк 100% за покупку сервера. Это 49 170 бонусов в панели управления Selectel 🔥
Каждый день с 15 по 23 декабря в 12:00 мск будем открывать окошки с подарками. Присмотритесь к карточкам на сайте: в них спрятали подсказки, какой сюрприз вас ожидает.
Предложение действует только один день. Как только откроется новая ячейка, старая перестанет действовать. А еще количество подарков ограничено, так что успейте забрать свой подарок первым.
Разная тарификация. Один провайдер включает трафик в стоимость ВМ, второй берёт за каждый гигабайт отдельно. Третий считает по часам, четвёртый – по фиксу. Свести все это воедино – задачка со звездочкой.
Стоимость межоблачного трафика. Если база живёт в одном облаке, а приложение – в другом, каждый запрос гоняет данные туда-обратно.
Отсутствие прозрачности. Когда никто не знает, во что обходится работа, – это большая проблема. Ведь если не знаешь цифры, то и оптимизировать нечего.
Что с этим делать?
Закладывать мультиклауд в архитектуру сразу. Kubernetes, Terraform, инфраструктура как код — это не модные словечки, а реальная защита от vendor lock-in.
Считать cost per unit для каждого сервиса.
Давать командам бюджеты и показывать реальные цифры. Когда разработчики видят, что их фича жрёт 300 тысяч в месяц, они вдруг начинают задумываться об оптимизации.
Нарисовать схему, где что лежит. Часто оказывается достаточно просто переставить сервисы и таким образом сократить расходы на трафик почти вдвое.
Есть что сказать по теме мультиклауд? Присоединяйтесь к нашему комьюнити Практики FinOps. Там очень ждут вашего мнения.
В Рег.облаке появился Terraform-провайдер для IaaS
В Рег.облаке стал доступен Terraform-провайдер для управления IaaS-инфраструктурой. Теперь облачные серверы и их снэпшоты можно создавать, изменять и удалять через код.
Terraform работает по декларативному принципу: пользователь описывает желаемое состояние инфраструктуры, а инструмент рассчитывает порядок действий и приводит ресурсы к нужной конфигурации через API облака.
На текущем этапе провайдер позволяет управлять облачными серверами, их снэпшотами и SSH-ключами. Через Terraform можно создавать серверы с GPU и без GPU, разворачивать их из готовых образов и снэпшотов, массово поднимать и удалять ресурсы, менять конфигурацию и тарифы, а также управлять SSH-ключами.
Использование Terraform упрощает работу с инфраструктурой: окружения для разработки, тестирования и продакшена становятся воспроизводимыми, изменения контролируются через Git, несколько специалистов могут работать над инфраструктурой одновременно, а сами ресурсы легко встраиваются в CI/CD-процессы.
В следующих обновлениях планируется расширение провайдера и добавление поддержки других ресурсов Рег.облака, включая управляемые базы данных и Kubernetes-кластеры. А уже сейчас на сайте Рег.облака можно посмотреть документацию и начать работу с Terraform-провайдером.
Четвертый год подряд мы организуем Firebird Conf, чтобы объединить на одной площадке экспертов, администраторов, разработчиков и активных пользователей Firebird.
Почему о Firebird говорят?
Firebird — это не просто СУБД, а рабочий инструмент, который ложится в основу интересных кейсов:
— Помогает создавать уникальные и функциональные продукты — Встраивается в любую ИТ-инфраструктуру и справляется с большими нагрузками — Предлагает обширный набор инструментов для автоматизации процессов
Разумеется, и в этом году вас ждут кейсы и обзор лучших практик применения Firebird для решения бизнес-задач и построения отказоустойчивой ИТ-инфраструктуры.
А как это было в прошлом году?
Firebird Conf 2025 собрала более 350 участников. Деловая программа включала 12 экспертных докладов, а за пределами конференц-зала шли обсуждения ИТ-разработок. Погрузитесь в атмосферу мероприятия!
Что вас ждет в 2026?
Насыщенная программа, которую мы будем раскрывать постепенно. Экспертные доклады, мастер-классы, активности, уникальный мерч и, конечно же, неформальное общение.
S3 редко работает в одиночку — чаще он взаимодействует с другими сервисами: Lambda, EC2 и CloudFront. Через Lambda можно автоматически обрабатывать файлы сразу после загрузки, через EC2 — работать с данными напрямую, без промежуточных копий, а CloudFront ускоряет доставку контента пользователям по всему миру.
SimpleOne и «Инферит ИТМен» объявили о технологическом партнерстве
Коллеги, хочу поделиться новостью о технологическом партнерстве, которое, на мой взгляд, важно для всего рынка управления ИТ-инфраструктурой.
«Инферит ИТМен» (кластер «СФ Тех» ГК Softline) и SimpleOne (направление прикладных бизнес-систем корпорации ITG) подписали соглашение о технологическом партнерстве. В рамках этого партнерства «Инферит ИТМен» сможет размещать собственные решения, разработанные на базе платформы SimpleOne, на маркетплейсе компании-вендора.
Наша общая цель — создать взаимодействие двух решений, которое закроет максимально широкий спектр задач рынка: от учета и инвентаризации до управления конфигурациями, процессами и сложными ИТ-ландшафтами. Новое решение объединит возможности системы учета, инвентаризации и контроля ИТ-активов «Инферит ИТМен» и модуля CMDB ESM-платформы SimpleOne.
Взаимодействие систем позволит решать сразу несколько задач, которые сегодня компании зачастую закрывают по отдельности или собирают заново под каждый проект: — автоматизированный сбор и дискаверинг оборудования; — агрегация данных в едином окне; — передача информации в CMDB; — формирование целостной картины ИТ-ландшафта — от «железа» и сетевого оборудования до ПО, лицензирования и связанных затрат.
На рынке давно назрела потребность в едином мощном решении, которое объединяет управление ИТ-активами, CMDB и практики корпоративного сервис-менеджмента. Наше партнерство с SimpleOne позволяет соединить лучшие подходы, накопленные обеими компаниями, и создать продуктовый пак enterprise-уровня, который комплексно решает задачи бизнеса. Мы уверены, что это решение станет стандартом качества на рынке и задаст новую планку для экосистем управления ИТ-инфраструктурой.
Со стороны SimpleOne партнерство также рассматривается как шаг к формированию технологически выверенного подхода к управлению ИТ-ландшафтом — от учета активов до сервис-менеджмента. Совместно с партнерами SimpleOne развивает инструменты, которые помогают организациям быстрее принимать обоснованные решения и устойчиво развивать инфраструктуру, сокращая время на интеграции и внедрение решений.
Взаимодействие наших решений упростит компаниям работу с ИТ-инфраструктурой за счет изначальной совместимости компонентов и единого подхода к данным. Это позволит сократить время на подбор инструментов под проект и уменьшить объем интеграционных работ.
Для рынка это означает возможность использовать готовую связку решений без необходимости повторно собирать архитектуру из отдельных элементов для каждого внедрения. Такой подход помогает быстрее запускать проекты и фокусироваться на прикладных задачах заказчиков, а не на технической «склейке» инструментов.
Недавно я написал статью про небольшой домашний стенд на Raspberry Pi и Orange Pi: Tailscale, Ansible, Nginx и базовую автоматизацию. В процессе чтения комментариев решил сделать несколько улучшений. Особенно благодарен комментариям от @Tony-Sol
Первое, что сделал — убрал root из inventory.
ansible_user=root Не надо так, лучше создать отдельного пользователя
На обеих машинах завёл отдельного пользователя ansible и команды на хосте:
sudo adduser ansible
sudo usermod -aG sudo ansible
echo 'ansible ALL=(ALL) NOPASSWD: ALL' | sudo tee /etc/sudoers.d/ansible
sudo chmod 440 /etc/sudoers.d/ansible
2. Создание роли
Такие штуки как установка и конфигурация сервисов, лучше размещать в отдельные роли, а в плейбуке уже собственно подключать нужные роли
Теперь создал роль и подключил ее в основной плейбук:
tasks / handlers / templates разнесены по каталогам;
apt заменён на package;
state: latest → present;
become используется только там, где реально нужен;
проверка конфига вынесена в handler через nginx -t.
Отдельно напишу вещь, на которой споткнулся: host_vars/<имя>.yml работает только если имя совпадает с inventory_hostname. У меня хост назывался orange, а файл был pi2.yml — из-за этого Jinja-шаблоны молча брали дефолты.
3. ansible.cfg — мелкие, но полезные настройки
Добавил минимальный ansible.cfg в проект:
roles_path=./roles;
gathering=explicit (факты включаю только там, где нужны);
небольшие SSH-настройки для стабильности.
vault_password_file имеет смысл добавлять только когда реально используется vault, иначе Ansible начинает ругаться.
4. Добавил на Raspberry Pi Мониторинг: VictoriaMetrics + Grafana
Мониторинг вынес на более мощную Raspberry Pi, а Orange Pi оставил агентом:
VictoriaMetrics + Grafana в Docker Compose;
node_exporter на обоих устройствах;
сбор метрик через static targets.
В итоге стенд стал аккуратнее.
Если интересно — базовая архитектура и исходная версия описаны в предыдущей статье.
Расскажем сегодня в 18:00 мск на Selectel Network MeetUp. А еще поговорим про подсчет сетевого трафика на сотни гигабит и сложности воспроизведения сетевых проблем в лабораторных условиях.
Программа у нас такая:
▪️ Маршрут одного инженера: FreeBSD → Linux → VPP
▪️ Пакет с пакетами: как считать, когда их много миллионов?
▪️ Повторить нельзя закрыть: сложности воспроизведения сетевых проблем в лаборатории
Все это — в легкой предпраздничной атмосфере и с огоньками гирлянд.
РЕД ОС 8 сертифицирована ФСТЭК России! Продукт соответствует требованиям к операционным системам общего назначения, средствам виртуализации и контейнеризации 4-го класса защиты.
Пользователям доступны все необходимые компоненты для создания защищенной ИТ-инфраструктуры:
— Поддержка архитектуры x86_64 и ARM, в том числе процессоров Байкал-М — Сертифицированные интерпретаторы, веб-серверы, средства виртуализации и контейнеризации — Kubernetes и оптимизированные образы контейнеров k8s для развертывания кластера в закрытом контуре — Сканер безопасности Trivy в составе — Приятным бонусом: новый дизайн и графические окружения KDE Plasma 5 и MATE 1.28
В течение года команда разработки РЕД ОС проводила планомерную работу по строгому соблюдению всех условий, необходимых для успешного прохождения сертификационных испытаний ФСТЭК России. Наши клиенты, партнёры и активные пользователи давно ждали выхода Сертифицированной редакции РЕД ОС 8 — и теперь мы рады предложить рынку наиболее актуальную и защищённую редакцию с обширными возможностями для построения защищенных ИТ-инфраструктур на базе отечественных решений. — прокомментировал Рустам Рустамов, заместитель генерального директора РЕД СОФТ.
