Работа с реестрами контейнеров в CentOS Stream 10

Продолжаем серию веб-кастов о контейнеризации, и на этот раз мы разберем работу с реестрами образов! В этой части мы выясним как конфигурировать источники в CentOS Stream 10 и настраивать инфраструктуру.

В этом веб-касте вы найдете:

• Описание реестров контейнеров: как хост взаимодействует с реестрами образов. Разбор структуры именования от реестра и порта до пространства имен, имени образа и конкретного тэга (quay.io/centos/centos:latest).
• Настройка конфигурации: где искать файлы конфигурации на системном уровне (/etc/containers/registries.conf) и как изолировать настройки для обычного пользователя в его домашней директории ($HOME/.config/containers/).
• Зеркалирование и блокировка: синтаксис для подключения локальных реестров, создания зеркал для бесперебойной работы, а также блокировка скачивания образов на уровне целых пространств имен или отдельных префиксов.
• Поиск и короткие псевдонимы: как управлять поиском через unqualified-search-registries и настраивать псевдонимы для команд pull, run и build. Разбор критически важных режимов short-name-mode (enforcing, permissive, disabled) при работе с короткими именами.

🎬 Ссылка на страницу веб-каста.

Введение в контейнеры в CentOS Stream 10

Открываю новую серию веб-кастов, и речь в ней пойдет о контейнерах! В первом выпуске мы разберем современную экосистему контейнеризации и выясним, почему CentOS Stream 10 предлагает мощную альтернативу привычным Docker-решениям.

В этом веб-касте вы найдете:

• Инструменты командной строки: обзор стека специализированных утилит. Вы узнаете, как Podman управляет подами, Buildah собирает образы, Skopeo инспектирует реестры, а низкоуровневая среда crun обеспечивает максимальную безопасность в Rootless-режиме.
• Главные преимущества нового стека: почему архитектура без демона (Daemonless), запуск без прав суперпользователя (Rootless) и нативная интеграция с systemd делают систему быстрее и безопаснее.
• Миграция с Docker: как пакет podman-docker бесшовно подменяет команды, насколько Docker Socket API совместим с вашими проектами docker-compose и какие ограничения есть у Swarm-оркестрации.
• Быстрый старт и визуализация: как развернуть всё окружение одной командой через мета-пакет container-tools и как управлять контейнерами через удобный веб-интерфейс Cockpit Podman.

🎬 Ссылка на страницу веб-каста.

Бета-версия Fedora Linux 38

 

15 марта 2023-го года проект Fedora анонсировал доступность бета версии Fedora Linux 38 – новейшей версии операционной системы с открытым исходным кодом. Fedora Linux 38 содержит отклик на ожидания глобального сообщества в области рабочих станций, безопасности и разработки инноваций.

Fedora Workstation.

Предыдущие итерации Fedora Workstation позволяли пользователям подключать репозитории, размещаемые сторонними организациями, в том числе отфильтрованные версии Flathub, которые предоставляли небольшое число приложений Flathub. Бета-версия Fedora 38 Workstation удалила эту фильтрацию, позволяя пользователям включить полную версию репозиториев Flathub. 

Дополнительно, бета-версия Fedora 38 Workstation теперь включает в себя GNOME 44. Пользователи могут уже сейчас посмотреть на новую версию экрана блокировки, секцию фоновых приложений в меню быстрого доступа и улучшения в параметрах доступности.

Возможности безопасности.

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

Прочие обновления.

Указатели фреймов (Framer Pointers) теперь встроены в официальные пакеты для улучшения возможностей разработчиков, которые заинтересованы в улучшении производительности приложений Linux. Языки и библиотеки программирования получили видимые обновления, которые включают в себя Ruby 3.2, GCC 13, LLVM 16, Goland 1.20 и PHP 8.2.

Дальнейшие шаги.

Так как это бета-релиз, вы можете столкнуться с ошибками или недостающими/некорректно работающими компонентами/возможностями. Для сообщения об обнаруженных в процессе тестирования и эксплуатации ошибках, свяжитесь с командой Fedora QA через список рассылки или канал #quality в Fedora Chat. Обнаруженные неисправности публикуются в категории известных ошибок на Ask Fedora. Для того чтобы сообщить об ошибке ознакомьтесь с инструкцией.

Дополнительную техническую информацию о новых пакетах и улучшения в бета-релизе Fedora 38 можно найти в наборе изменений Fedora Linux 38.

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

Релиз Fedora Linux 38 ожидается во второй половине апреля.

Релиз Fedora 37

Проект Fedora анонсировал Fedora Linux 37 еще 15 ноября 2023-го года, но поскольку у меня не было возможности рассказать о новой версии операционной системы ранее, я решил это сделать сейчас.

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

Новые редакции.

В релизе Fedora Linux 37 были анонсированы две новые редакции – Fedora CoreOS и Fedora Cloud. Fedora CoreOS – это преемник Fedora Atomic Host. Редакция предоставляет автоматический механизм обновления для размещения рабочих нагрузок на базе контейнеров. Помимо автоматических обновлений, Fedora CoreOS включает в себя простой механизм отката, упрощая управление и поддержку инфраструктуры контейнеров.

Fedora Cloud вместе с Cloud Working Group добавляет собственную редакцию, которая должна закрыть возросшую потребность в облачных образах Fedora. Редакция Fedora Cloud предоставляет базу для запуска в публичных и частных облаках. В первую очередь редакция Fedora Cloud появилась в AWS Marketplace.

Обновленные пользовательские возможности в Fedora Workstation.

Редакция Fedora Workstation известна доставкой новейших релизов GNOME, и Fedora 37 не стала исключением. GNOME 43 упрощает для пользователей доступ к подробностям безопасности системного оборудования и микропрограммного обеспечения. Многие базовые приложения GNOME теперь перенесены на новейшую версию набора инструментов GTK для улучшения производительности и внешнего вида.

Fedora 37 Workstation также обладает опциями для снижения нагрузки за счет возможности удалить ненужные дополнительные пакеты Firefox и пакеты среды gettext, связанные с неиспользуемыми языками. Сборки Fedora и Fedora Labs также получили свежий круг обновлений c предоставленным Fedora Comp Neuro набором инструментов, адаптированных для вычислительных наук и легковесным окружением рабочего стола от Fedora LXQt.

Расширенные возможности системного администрирования.

Fedora Server изначально спроектирован для соответствия потребностям системных администраторов. В Fedora 37 Server добавлены новые инструменты и возможности для обеспечения эволюции данной роли. Редакция теперь может выпускать образ диска KVM для более простого запуска Fedora 37 в виртуальной машине. Криптографические возможности также расширены при помощи политики TEST-FEDORA39, которая предварительно показывает изменения в будущих релизах Fedora, помогая сократить сложности в грядущих релизах от таких шагов, как отказ от алгоритмов SHA-1.

Следующие шаги.

Образ Fedora 37 доступен для загрузки. Для тех, кто уже использует Fedora Linux реализована возможность простого обновления с существующих версий.

Релиз Red Hat Enterprise Linux 9.1

По мере того, как организации распыляют свою инфраструктуру информационных технологий в облаках и периметре сети, остро встает потребность в масштабируемых решениях гибридного облака с расширенными возможностями стабильного управления. При помощи Red Hat Enterprise Linux (RHEL) можно обеспечить целостность, гибкость и устойчивость для инноваций, соответствующую актуальным потребностям.

Обновление Red Hat Enterprise Linux 9.1 добавляет клиентам ряд новых компонентов и возможностей, в том числе расширения для Microsoft SQL Server, Red Hat Smart Management с Red Hat Satellite, а также новые возможности для Red Hat Insights и рабочих станций (редакция Workstation).

Новое в Red Hat Enterprise Linux 9.1.

Red Hat Enterprise Linux 9.1 построен на улучшениях, представленных в версии 9.0, в том числе возможностях расширенной автоматизации и управления, таких как веб-консоль RHEL и системные роли (System Roles), что упрощает клиентам автоматизацию ручных задач, обеспечивает стандартизацию развертываний в любых масштабах и упрощает повседневное администрирование систем.

Расширенные возможности, добавленные в Red Hat Enterprise Linux 9.1, помогут упростить управление безопасностью и соответствием при развертывании новых систем или управлении существующей инфраструктурой. Организации могут получить преимущества от нового инструментария Ansible, получая доступ к системам RHEL при помощи идентификаторов, хранящихся во внешних источниках; применения многоуровневой безопасности (MLS) для соответствия требованиям; а также внешней проверки целостности загрузки операционных систем.

Теперь Red Hat Enterprise Linux предоставляет больше времени для планирования жизненного цикла за счет двухлетнего периода обновления Extended Update Support (EUS). Доступна поддержка обновления на месте (In-place Upgrade) до новейших версий RHEL и Convert2RHEL поддерживает более гибкие сценарии.

Red Hat Enterprise Linux для Microsoft SQL Server.

Расширенная системная роль для Microsoft SQL Server позволяет клиентам, устанавливать, настраивать и оптимизировать как одноузловые окружения, так и группы доступности SQL Server Always-on. Это расширение доступно с дополнением RHEL High Availability Add-On, предоставляющем операционную эффективность для сложных прикладных задач за счет автоматизации.

Red Hat Smart Management с Red Hat Satellite.

Red Hat Smart Management объединяет гибкость и мощь возможностей управления инфраструктурой Red Hat Satellite с возможностью выполнения планов восстановления от Red Hat Insights, ускоряя повторяемые задачи управления жизненным циклом для RHEL с целью увеличения оперативной эффективности, а также расширения безопасности, доступности и соответствия требованиям.

Релиз Red Hat Enterprise Linux 9.1 вышел с расширенными возможностями приведения в соответствие по требованию для применения рекомендаций Red Hat Insights, позволяя клиентам приводить системы в соответствие напрямую из интерфейса Insights или через интерфейс Red Hat Satellite. Обновление Red Hat Satellite 6.12 добавляет ряд новых преимуществ, в том числе обновленный веб-интерфейс для увеличения стабильности, новые улучшения производительности, оптимизацию использования ресурсов и новый режим удаленного выполнения (Pull Mode).

Red Hat Insights для Red Hat Enterprise Linux.

Red Hat Insights помогает упростить управление RHEL за счет использования прогнозирующей аналитики и всесторонней экспертизы в оценке окружений ИТ, определения и приоритезации операционных и программных рисков безопасности, при этом упрощая отслеживание подписки в рамках развертываний гибридного облака. Новые возможности для RHEL 9.1 включают в себя: 

• Обновление подписки – Simple Content Access (SCA) теперь включен по умолчанию.
• Использование ключей активации в Hybrid Cloud Console (HCC) – делает активацию проще.
• В релиз вышли интеграция Snow Software и сервис обнаружения вредоносного программного обеспечения.
• Для устройств периметра предоставляются рекомендации, а авто-регистрация доступна для экземпляров в публичном облаке.

Red Hat Enterprise Linux для рабочих станций (Workstation).

RHEL for Workstations 9.1 теперь обеспечивает простую поддержку Mozilla Firefox в сессиях Gnome Wayland, позволяя пользователям использовать более простые инструменты. Фоновый процесс XWayland/X11 Gtk+ по прежнем может быть использован при помощи дополнительного пакета firefox-x11.

Примечание.

Впервые о возможности работы Firefox непосредственно на Wayland я писал в статье: «Доступна бета-версия Fedora 31».

Дополнительную информацию о новых возможностях Red Hat Enterprise Linux 9.1 можно получить в заметках к релизу.

Релиз Red Hat Enterprise Linux 8.7

Организации по всему миру опираются на Red Hat Enterprise Linux (RHEL) как на ядро корпоративной инфраструктуры информационных технологий (ИТ). В быстро меняющемся окружении ИТ требуется гибкая и стабильная основа для поддержки инноваций гибридного облака, управления приложениями и эффективного развертывания рабочих нагрузок в различных окружениях. RHEL является той основой, которая обеспечивает комплексное управление и ускорение инноваций.

Новейшее обновление Red Hat Enterprise Linux 8, анонсированное 9 ноября 2022 года, уже доступно. Вместе с официальным релизом RHEL 8.7 клиенты могут эффективнее автоматизировать ручные задачи, стандартизировать масштабные развертывания и упростить ежедневное администрирование систем.

Новое в Red Hat Enterprise Linux 8.7.

Red Hat Enterprise Linux 8.7 представил ряд новых возможностей, в том числе: просмотр и управление политиками шифрования всей системы для обеспечения целостности и сокращения рисков, маркировку и опциональное шифрование аварийных отчётов (sosreport) в веб-консоли, выборочную установку обновлений kpatch в веб-консоли с улучшенным процессом применения обновлений к запущенному ядру и редактирование настраиваемых служб в межсетевом экране.

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

Расширенные возможности, добавленные в RHEL 8.7, помогают упростить управление безопасностью и соответствием при развертывании новых систем или управлении существующей инфраструктурой. Организации, использующие управление идентификацией (Identity Management) в RHEL, теперь могут получить преимущества от нового инструментария Ansible для настройки аутентификации с использованием смарт-карт в рамках всей топологии. Дополнительно, теперь можно получить доступ к системам RHEL с использованием внешних идентификаторов, таких как AWS, Azure, Google и прочих.

За счёт поддержки двухлетнего периода обновления (EUS) Red Hat Enterprise Linux даёт больше времени на планирование жизненного цикла. Новая поддержка обеспечивает возможность обновления на месте (In-Place Upgrade) с RHEL 7.9 до RHEL 8.4 или 8.6, 8.6 до 9.0 и 8.8 до 9.2 (в следующем году, когда состоится релиз). Это обеспечивает два полных года на адаптацию и планирование обновления. Также Convert2RHEL теперь поддерживает более гибкую смену релизов (например, с CentOS Linux 7.9 до RHEL 7.9, с CentOS Linux 8.4 до RHEL 8.4 и с CentOS Linux 8.5 до RHEL 8.5).

Red Hat Enterprise Linux для SAP.

Вместе с вновь представленными системными ролями RHEL для System Analysis Program Development (SAP) и соответствующими, сертифицированными Red Hat, коллекциями Ansible, клиенты получат преимущества от предварительно подготовленного и автоматизированного пути настройки кластера высокой доступности (HA) SAP High-performance Analytic Appliance (HANA).

Сборщик образов Red Hat Enterprise Linux.

Сборщик образов RHEL (предоставляемый RHEL в виде размещенного сервиса по адресу console.redhat.com) помогает организациям создавать стандартные, оптимизированные образы операционных систем, которые можно быстро разворачивать в любых окружениях.

Новые возможности в локальной (on-premises) версии сборщика образов включает в себя настройку соответствия требованиям безопасности при помощи профилей OpenSCAP, определяемых в файле чертежа. Дополнительно, можно встраивать контейнеры, такие как RHEL Universal Base Images (UBI), в образ, в соответствии с файлом проекта, что встроит образ контейнера, выгружаемый из реестра, который будет доступен для использования сразу в процессе загрузки.

Обновления для разработчиков.

Red Hat Enterprise Linux 8 представил концепцию потоков приложений (Application Streams) – множества версий компонентов пользовательского пространства, которые доставляются и обновляются чаще, чем основные пакеты операционной системы. Новые потоки приложений, добавляются в каждом релизе, предоставляя новые компиляторы, языки, базы данных и веб-серверы. Вместе с RHEL 8.7 было представлено множество улучшений, в том числе Mercurial 6.2 – новейшее обновление инструмента распределенного управления исходными кодами.

Дополнительную информацию о релизе можно получить в заметках к релизу и документации. Также уже вышел релиз Red Hat Enterprise Linux 9.1, о нем я расскажу в следующий раз.

Доступен Red Hat Satellite 6.11

5 июля 2022 года Matthew Yee анонсировал доступность Red Hat Satellite 6.11. Данный релиз содержит множество новых и обновленных возможностей, в том числе улучшенный пользовательский интерфейс/возможности пользователя и новые компоненты для упрощения управления и администрирования:

• Обновлённый пользовательский интерфейс упрощает использование и улучшает точность операций.
• Поддержка Red Hat Enterprise Linux 9 обеспечивает управление и развёртывание хостов.
• Поддержка обновления сервера Satellite (с RHEL7 до RHEL8) обеспечивает бесшовное обновление операционной системы сервера. 
• Сетевая синхронизация между серверами Satellite (Inter-Satellite-Sync (ISS) Network Sync) обеспечивает возможность обновления серверов Satellite без прямого подключения к интернету.
• Улучшенная автоматизация convert2rhel дает больше автоматизации для ускорения конвертации.

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

Инструкции по чистой установке Red Hat Satellite 6.11 доступны по ссылкам: подключенный сервер и независимый сервер.

Инструкции по обновлению более ранних версий Red Hat Satellite 6.x, доступна по ссылке, а также можно воспользоваться помощником.

Изменения Ansible в Red Hat Enterprise Linux (RHEL)

В Red Hat Enterprise Linux 8.6 и Red Hat enterprise Linux 9.0, бета версии которых уже доступны, произошли изменения, касающиеся всех, кто использует Ansible в RHEL. В том числе, при использовании Ansible Engine, потребуются дополнительные шаги для обновления с RHEL 8.5 до RHEL 8.6.

Пользователи Red Hat Enterprise Linux (RHEL) 7, а также RHEL с 8.0 до 8.5 имеют доступ к отдельному репозиторию Ansible Engine. В RHEL 8.6 и 9.0 клиенты получат доступ к Ansible Core, который включен в соответствующий репоизоиторий AppStream. Переход на Ansible Core в RHEL обусловлен изменениями в исходном проекте Ansible.

Далее мы рассмотрим поддерживаемые сценарии использования Ansible в Red Hat Enterprise Linux, различия между Ansible Engine и Ansible Core, а также затронем вопрос использования Ansible в RHEL 7.

Поддерживаемые сценарии использования Ansible в Red Hat Enterprise Linux.

Ansible предоставляет клиентам Red Hat Enterprise Linux возможность использования контента автоматизации, такого как системные роли RHEL (RHEL System Roles), контент Ansible для управления идентификацией (Identity Management Ansible Content), книги сценариев для приведения в соответствие Insights (Insights Remediation Playbooks) и контент Ansible, генерируемый веб-консолью.

Контент Ansible Engine, как и Ansible Core в RHEL 8.6 и 9.0 обладают ограниченной областью поддержки, которая включает в себя:

• Системные роли RHEL (RHEL System Roles).
• Базовые системные роли RHEL распространяются в пакете rhel-system-roles.
• Системные роли для SAP, включены в пакет rhel-system-roles-sap и распространяются по подписке RHEL for SAP Solutions.
• Роль для Microsoft SQL Server включена в пакет ansible-collection-microsoft-sql.
• Модули Ansible IPMI содержатся а пакете ansible-collection-redhat-rhel_mgmt.
• Контент Ansible для управления идентификацией (Identity Management) включен в пакет ansible-freeipa.
• Рабочие книги, генерируемые сервисом Insights для приведения в соответствие, включают в себя сценарии безопасности, исправлений и настройки.
• Контент Ansible для Performance Co-Pilot (PCP) включен в пакет ansible-pcp.
• Контент Ansible, генерируемый веб-консолью.

Использование Ansible Engine или Ansible Core для других сценариев, в том числе с использованием стороннего контента Ansible не поддерживается без подписки Red Hat Ansible Automation Platform.

Книги сценариев Ansible для приведения в соответствие (Remediation Playbook) от OpenSCAP могут не работать корректно с Ansible Core в RHEL 8.6 и 9.0. Если данный функционал OpenSCAP все же требуется, то рекомендуется использовать соответствие Insights (Insights Compliance) с приведением в соответствие через соединитель Red Hat (Red Hat Connector). Соединитель Red Hat в RHEL 8.6 и 9.0 планировался в том числе для включения необходимых модулей Ansible, позволяющих книгам сценариев для приведения в соответствие работать с Ansible Core.

Различия между Ansible Engine и Ansible Core.

Как говорилось выше, Red Hat Enterprise Linux 9.0 и 8.6 представят Ansible Core (пакет ansible-core) для замены Ansible Engine (пакет ansible). Ansible Core предоставляет значительно меньше плагинов и модулей, чем Ansible Engine.

Ansible Engine содержит более 3000 модулей по сравнению с Ansible Core, который содержит примерно 127 модулей. Так же в Ansible Core отсутствует ряд фильтров, таких как json_query, ipaddr и прочие.

Поддерживаемый в RHEL контент Ansible находится в процессе обновления для полной совместимости с Ansible Core. Таким образом, миграция на Ansible Core не окажет влияния на поддерживаемый в RHEL контент.

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

Миграция с Ansible Engine на Ansible Core.

Ansible Engine не будет доступен в Red Hat Enterprise Linux 9, таким образом, после установки новой системы можно будет установить Ansible Core из репозитория AppStream при помощи следующей команды:

# dnf install ansible-core -y

При использовании систем RHEL 8.0 – 8.5 с установленным Ansible Engine, после обновления до RHEL 8.6 потребуются дополнительные шаги для перехода с Ansible Engine на Ansible Core.

Репозиторий Ansible Engine останется доступным в RHEL 8.6, но он перестанет получать исправления ошибок и безопасности после 29 сентября 2023 года и может быть несовместим с контентом автоматизации Ansible включенным в RHEL 8.6 и более старших версий.

Использование Ansible в RHEL 7.

Ansible Core не будет доступен в Red Hat Enterprise Linux 7. Клиенты могут продолжать использовать Ansible Engine 2.9 в RHEL 7.9, с ограниченной областью поддержки до 29 сентября 2023 года. После этой даты Ansible Engine перестанет получать обновления исправляющие ошибки и устраняющие неисправности безопасности.

Клиенты, использующие системные роли RHEL System Roles) или контент управления идентификацией Ansible (Identity Management), могут использовать управляющие узлы RHEL 8.6 или RHEL 9.0 с Ansible Core для управления узлами RHEL 7 после 29 сентября 2023 года.

Книги сценариев приведения в соответствие Insights (Remediation Playbooks) перестанут поддерживаться в RHEL 7 после 29 сентября 2023 года.

Заключение.

На этом обзор изменений Ansible в Red Hat Enterprise Linux закончен, не забудьте проверить используемый контент Ansible при переходе на Ansible Core, после обновления до RHEL 8.6.

Новое в бета-версии Red Hat Enterprise Linux 8.6

30 марта 2022 года была анонсирована бета версия Red Hat Enterprise Linux (RHEL) 8.6. В новейшую систему включен ряд возможностей, которые транслируются в операционные преимущества для организаций. Я не буду просто перечислять все новинки списком, а сосредоточусь на ключевых изменениях в бета-версии.

Веб-консоль для управления STRATIS и проброса устройств.

Для упрощения администрирования команда разработки, на базе исходного проекта Cockpit, добавила возможность выполнять новые задачи при помощи веб-консоли RHEL:

• Поддержка проброса устройств в веб-консоли позволяет напрямую подключать PCI и USB-устройства хоста к виртуальным машинам при помощи веб-интерфейса. Это позволяет настраивать виртуальные машины на эксклюзивное использование устройств без использования интерфейса командной строки.
• Поддержка STRATIS в веб-консоли – это предварительная версия для ознакомления с технологией. Хранилище Stratis – это решение управления хранилищем для Linux с фокусом на простоте использования возможностей, таких как моментальные снимки на файловой системе, тонкое выделение и прочее, без необходимости прямой работы с фоновыми уровнями хранилища, глубокого понимания лежащих в основе технологий и использования команд. В бета версии RHEL 8.6 представлена возможность управления хранилищем Stratis через веб-консоль.

Примечание.

Для знакомства с технологией и возможностями Stratis можно воспользоваться следующими веб-кастами: «Многоуровневое хранилище Stratis в CentOS 8» и «Моментальные снимки Stratis в CentOS 8».

Новые системные роли RHEL.

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

В RHEL 8.6 добавлено ещё больше системных ролей (System Roles) для ускорения популярных задач настройки Red Hat Enterprise Linux:

• Системная поль для управления высоко доступными кластерами (High Availability Cluster System Role). Начиная с RHEL 8.6, данная роль переведена из предварительной версии для ознакомления с технологией в полностью поддерживаемую. Она предоставляет автоматизированный инструментарий для создания целостных и стабильных решений кластеров высокой доступности на базе red Hat Enterprise Linux. Теперь можно значительно проще создавать высоко доступные кластеры при помощи предварительно подготовленных рекомендованных сценариев использования, конфигураций и топологий.
• Системная роль для веб-консоли (System Role for Web Console). Как уже неоднократно говорилось – веб-консоль максимально упрощает администрирование RHEL. Теперь и настройка самой веб-консоли упрощена. Данная роль автоматизирует установку и настройку веб-консоли RHEL, в том числе указание необходимых для установки пакетов, запуск и включение автоматического запуска сокета, а также, опционально, настройку параметров, таких как тайм-аут простоя (Idle Timeout).
• Системная роль межсетевого экрана (Firewall System Role). Хорошо настроенный межсетевой экран – это обязательная часть сетевой безопасности. Данная роль позволяет автоматизировать управление конфигурациями межсетевых экранов на управляемых узлах с RHEL 7 и 8, также она будет поддерживаться и на узлах с RHEL 9.

Узнать больше о новых возможностях и компонентах бета-версии Red Hat Enterprise Linux 8.6 можно при помощи заметок к релизу.

Бета версия Red Hat Enterprise Linux 8.6 доступна для прямой загрузки на клиентском портале.

Создание модулей скриптов в Windows PowerShell 5

Вот и пришло время для очередного веб-каста на тему модулей в Windows PowerShell 5.

В веб-касте представлено описание основных типов модулей и демонстрируется создание и использование модулей скриптов (Script Module), также известных как модули сценариев.

Подробности и видео: LebedevUM

P.S. Это уже третий веб-каст в группе, поэтому, если вы не знакомы с модулями Windows PowerShell, рекомендую перед просмотром ознакомиться с предыдущими:

• Основы модулей в Windows PowerShell 5
• Работа с модулями в Windows PowerShell 5

Все веб-касты в хронологическом порядке: Windows PowerShell 5

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

Доступна бета-версия Fedora 36

Команда проекта Fedora анонсировала доступность бета-версии Fedora Linux 36. Данный релиз продолжает усилия команды разработки по доставке передовых технологий с открытым исходным кодом и включает в себя обновления GNOME, улучшения Wayland для пользователей Nvidia и многое другое.

Улучшения для рабочих станций.

Возможности настольных версий Fedora становятся лучше с каждым релизом. Бета-версия Fedora 36 Workstation включает в себя GNOME 42 – новейший релиз окружения рабочего стола GNOME.

Пользователи, предпочитающие темный режим интерфейса (Dark Mode) будут рады увидеть такую опцию в GNOME 42. Также в окружение рабочего стола добавлена обновленная тема GNOME Shell, которая использует меньше пространства, улучшает контрастность и прочее, что позволяет сделать пользовательские возможности чуточку приятнее.

Данный релиз также включает в себя новое приложение терминала (Console) и новый текстовый редактор – Text Editor. При выборе схемы именования предпочтение было отдано понятности в ущерб оригинальности. Реальная привлекательность Text Editor заключается в улучшенном пользовательском интерфейсе и возможностях, таких как авто-сохранение, чего не было в предыдущем редакторе по умолчанию.

Для пользователей, которым необходимо делать снимки экрана, должны понравиться новые возможности. Нажатие клавиши [Print Screen] теперь запускает интерактивный инструмент, который позволяет сделать моментальный снимок или запись, как всего экрана, так и отдельной части.

Упрощённое создание моментальных снимков.

Стоит отметить, что все заметные пользователю изменения возможны только за счёт той работы, которая происходит под капотом Fedora. В частности, некоторая работа была проведена в настольных вариантах Fedora Linux 36 по перемещению базы данных RPM из /var и размещению /var на отдельном под-томе (Subvolume), что в конечном счёте упрощает управление моментальными снимками.

Примечание.

Моментальные снимки на файловой системе – это одна из возможностей файловой системы BtrFS, об использовании которой в Fedora Linux я писал в статьях: «Доступна бета-версия Fedora 34» и «Доступна бета-версия Fedora 35».

Перемещение базы данных RPM из /var упрощает работу с различными типами моментальных снимков и операций отката. Результат проделанной работы уже применяется для вариантов Fedora c rpm-ostree, в частности Silverblue, Kinoire, CoreOS и IoT, которые уже используют моментальные снимки и откаты. А также, эта работа закладывает основу для стандартных релизов Fedora чтобы они также могли использовать эти возможности.

Пользователи могут не видеть преимуществ прямо сейчас, но эта работа и ее результаты станут заметны позже, как в самом исходном проекте Fedora, так и, возможно, в Red Hat Enterprise Linux (RHEL).

Прочие улучшения в бета-версии Fedora Linux 36.

Так как пользователям Fedora Linux нравятся возможности выбора, доступные в настольных окружениях, теперь в Fedora стал доступен релиз LXQt 1.0. Можно использовать опцию выбора LXQt или просто установить LXQt в существующем окружении рабочего стола.

Пользователи Nvidia увидят дополнительную поддержку Wayland. В бета-версии Fedora 36 с сессиями GDM, теперь по умолчанию используя Wayland.

И, разумеется, новейший релиз полон обновлений для языков программирования, библиотек и утилит, таких как Ruby on Rails 7.0, Django 4.0, PHP 8.1, PostgreSQL 14 и массы прочих. Также, в бета версии Fedora 36 впервые представлен Podman 4.0.

Помощь в тестировании.

Так как это выпуск бета версии, команда проекта ожидает обратной связи обо всех найденных ошибках или недостающих компонентах. Для передачи информации о найденных ошибках в процессе тестирования, свяжитесь с командой тестирования Fedora QA через почтовый список или канал #fedora-qa на Libera.chat. Процесс тестирования и известные ошибки можно отслеживать на странице Common F36 Bugs.

Подробное описание процедуры сообщения об ошибках доступно в Fedora Docs.

Что такое бета-версия.

Выпуск бета-версии – это законченный код, который имеет сильное сходство с финальным релизом. В этом достаточно просто убедится, скачав и попробовав бета-версию.

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

Дополнительная информация.

Больше информации об изменениях в бета-версии Fedora Linux 36 можно найти по ссылке: «Fedora Linux 36 Change set». Там же присутствует больше технической информации о новых пакетах и улучшениях данного релиза.

Вывод из эксплуатации устаревших компонентов Citrix Gateway

Компания Citrix вместе с релизом Citrix ADC 12.0 (сборка 41.16) анонсировала устаревшие компоненты (Deprecated). Эти компоненты, такие как классические политики (Classic Policy), некоторые темы оформления и классический анализ конечного устройства (EPA) по прежнем поддерживаются в релизах 12.1 и 13.0.

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

Классические политики (Classic Policies).

Политики Citrix ADC используются для управления проверкой данных компонентами. Классические политики оценивают базовые характеристики трафика, в то время как инфраструктура продвинутых политик (Advanced Policy) позволяет анализировать больше данных и настраивать больше операций в правилах. Об отказе от классических политик впервые было объявлено несколько лет назад, я даже писал об этом в статье «Перевод механизма обработки трафика на инфраструктуру расширенных политик (Advanced Policy) в Citrix ADC».

Примечание.

Классические политики для Gateway и AAA продолжат поддерживаться без изменений функционала вплоть до второго квартала 2023-го года.

Для перехода на продвинутые политики существует инструмент Citrix ADC – nspepi, который можно использовать для конвертации команд, выражений и конфигурации. В качестве альтернативы, редактор выражений в графическом интерфейсе Citrix ADC – это отличный путь для ручной переделки классических выражений в продвинутые.

Необходимо отметить, что рекомендуется конвертировать все классические политики в продвинутые, чтобы использовать полностью поддерживаемую конфигурацию. В том числе, это касается таких политик как LDAP, RADIUS, сертификатов (CERT), syslog и политик сессий (session).

Один из способов проверить наличие классических политик, это выполнить поиск классических выражений в запущенной конфигурации nsconfig. Примерами ключевых слов для поиска могут быть «REQ.HTTP» и «ns_true». Обратите внимание, что эти два примера помогут найти большинство, но далеко не все классические политики.

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

Продвинутые политики аутентификации (Advanced Authentication Policy).

В случае использования Citrix Gateway для проксирования ICA или VPN, политики аутентификации привязываются как обязательная часть настройки. Классические политики аутентификации могут быть привязаны в секцию базовой аутентификации (Basic Authentication) виртуального сервера Citrix Gateway, но продвинутые политики так не работают. Чтобы использовать продвинутые политики аутентификации, необходимо настроить виртуальный сервер аутентификации и привязать его в профиль аутентификации на виртуальном сервере Citrix Gateway.

В сценарии с одним фактором это также просто как создать виртуальный сервер аутентификации и привязать продвинутую политику аутентификации со схемой входа (Login Schema) к серверу. Для сценариев с несколькими факторами, необходимо настроить аутентификацию nFactor. Поддержка nFactor для Citrix Gateway доступна с релиза 11.1, таким образом достаточно много информации о настройке уже существует. Вместе с релизом Citrix ADC 13.0, сборка 36.27, добавлена новая возможность для упрощения настройки nFactor при помощи графического интерфейса – nFactor Visualizer.

Мобильные политики (Citrix Workspace App).

Для сценариев двухфакторной аутентификации LDAP и RADIUS с мобильными устройствами, может возникнуть потребность в некоторых изменениях, которые необходимо внести в политики сессий. Это связано с тем, что при использовании потока nFactor, нужен только один поток для мобильных и не мобильных соединений. При использовании базовой аутентификации потоки разделены.

Ранее, при настройке Citrix Gateway на использование аутентификации RADIUS и LDAP с мобильными устройствами, LDAP настраивался в качестве основной политики для веб-соединений, а для соединений Receiver/Workspace в качестве вторичной политики. На диаграмме ниже представлен пример настройки двухфакторной базовой аутентификации с LDAP и RADIUS.

В такой конфигурации, индекс учётных данных в политиках сессий, указывающих на LDAP, должен был отличаться для веб и мобильных соединений. Для веб-соединений индекс учётных данных должен быть установлен в значение основного (Primary), а для соединений Citrix Workspace в значение вторичного (Secondary). При использовании потока nFactor и продвинутых политик, единый поток может обрабатывать как мобильные, так и не мобильные устройства. Это значит, что LDAP может являться основной политикой для обоих сценариев использования, а политика RADIUS будет вторичной. Если политика сессий Citrix Workspace ранее указывала на вторичный индекс учётных данных, ее необходимо обновить на первичную, для успешной аутентификации мобильных устройств на Citrix Gateway.

Темы оформления.

Вместе с отказом от классических политик, устаревшими также становятся и ряд тем оформления. При использовании оформления по умолчанию (Default), Green Bubble или X1, вы могли видеть предупреждение, указывающее на устаревание данных тем и их недоступность в будущих релизах.

Рекомендуется использовать тему оформления RFWebUI с конфигурацией nFactor и продвинутыми политиками. При использовании одной из устаревших тем с внесёнными изменениями, необходимо учесть, что изменения не перенесутся на RFWebUI. Механизм внесения изменений RFWebUI отличается и потребует перенастройки. Одним из отличий является то, что страница входа хранится в другом расположении (/var/netscaler/logon/LogonPoint/) в отличии от устаревших тем (/netscaler/ns_gui/vpn/). Файлы, которые необходимо настраивать для RfWebUI, также отличаются: index.html, strings.en.json и theme.css.

Дополнительные рекомендации.

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

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

Рекомендуется использовать анализ конечного устройства (EPA) с nFactor вместо классического анализа (Classic EPA). Это значит, что любая политика пред-аутентификации или пост-аутентификации, которая привязана напрямую к Citrix Gateway, должна быть удалена и заменена конфигурацией с использованием виртуального сервера аутентификации.

Основные выводы.

Клиенты Citrix, заинтересованные в отказе от устаревших компонентов, должны рассмотреть следующие рекомендации:

• Конвертировать все классические политики в продвинутые.
• Выполнить поиск по активной конфигурации (Running), чтобы убедиться, что классические выражения не были пропущены.
• Использовать виртуальный сервер аутентификации для привязки продвинутых политик к виртуальному серверу Citrix Gateway.
• Использовать nFactor Visualizer (новый компонент в Citrix ADC 13.0) для упрощения настройки nFactor.
• Убедиться, что индекс учётных данных в политике сессий соответствует факторам LDAP.
• Переключить старые неподдерживаемые темы на RfWebUI.
• Отвязать все классические политики от компонентов перед привязкой продвинутых политик.
• Настроить nFactor EPA для любых политик пред и пост-аутентификации.

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

Взаимодействие Red Hat и LLVM

Проект LLVM (ранее известный как Low Level Virtual Machine) – это набор компонентов, которые представляют собой блоки для сборки компиляторов и связанных инструментов. В Red Hat Enterprise Linux (RHEL) эти компоненты используются в компиляторе Rust, встроенном шейдерном компиляторе Mesa, а также в инструментах Berkeley Packet Filter (BPF), таких как BPF Compiler Collection (BCC) и bpftrace. Дополнительно, LLVM содержит собственный компилятор (Clang) и компоновщик (LLD), оба также являются частью RHEL.

Исходный проект для LLVM очень большой и быстро развивающийся почти с сотней правок в день и более чем 250 уникальными участниками в месяц. Помимо сборки и упаковки исходных кодов LLVM для RHEL, инженеры Red Hat активно взаимодействую с сообществом, чтобы сделать проект лучше. Сегодня мы рассмотрим проект LLVM и то, какую работу проделал Red Hat с LLVM за прошлый год.

LLVM Foundation.

LLVM Foundation – это некоммерческая организация, которая отвечает за нетехнические аспекты проекта LLVM в дополнение к обучению и продвижению компилятора и инструментов. Совет директоров LLVM Foundation состоит из девяти человек, в число которых входит Tom Stellard (Principal Software Engineer в Red Hat), также он выполняет функции секретаря в совете и менеджера релизов в проекте.

Управление релизами LLVM.

Исходный проект LLVM использует 6-ти месячный цикл релизов, который включает в себя мажорные релизы (X.0.0) и далее версия увеличивается на единицу при исправлении ошибок (X.0.1) в рамках цикла.

Также несколько инженеров в Red Hat поддерживает процесс релизов, исправляя ошибки и тестируя сборки.

Неявные указатели (Opaque Pointers).

Проект LLVM использует внутреннее представление компилятора, называемое LLVM IR. Компиляторы на базе LLVM выпускают это промежуточное представление и передают его компонентам для оптимизации и генерации машинного кода. LLVM IR – это хорошо определенное, постоянно улучшающееся и дополняемое новыми возможностями представление компилятора. Одним из таких улучшений, над которым работает сообщество, является неявные указатели (Opaque Pointers).

Opaque Pointers – указатели без связанного типа.

На данный момент в LLVM IR каждая запись указателя определяет тип значения, на которое он указывает, так, например i8* указывает на значение i8, i32* на 32-ух битное значение и так далее.

Удаление типа указателя должно упростить IR за счёт устранения необходимости конвертации между типами (очень популярная операция). В свою очередь, это должно помочь сократить сложность оптимизатора, а также ускорить и улучшить его работу. Red Hat помогает исходному проекту, улучшая оптимизатор и прочие части LLVM для работы с новым типом представления указателя.

Улучшения времени компиляции.

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

Помимо прочего, разработчики Red Hat сделали и делают следующее:

• Добавили новых ботов для сборки в инфраструктуру LLVM.
• Помогли улучшить удобство работы с инструментами LLVM при помощи более понятных вспомогательных сообщений.
• Добавили в OpenCL реализацию C.
• Создают каждую ночь моментальные сборки для использования в сообществе.
• Улучшают возможности безопасности.
• Исправляют ошибки.

Эта работа вместе с участием сообщества доступна в текущем и будет доступна в последующих релизах RHEL. Новая версия LLVM добавляется в каждом минорном релизе RHEL, таким образом, новейшие возможности и исправления ошибок всегда доступны пользователям Red Hat Enterprise Linux.

В Red Hat существует политика «Upstream First», по которой предпочтение отдается исходным проектам. Так как здоровое состояние исходного проекта неминуемо ведёт к улучшению качества продуктов Red Hat. Именно поэтому сотрудники Red Hat столь активно участвуют в проекте LLVM, не только в 2021-ом году, но и в предыдущие годы. Совместная работа над проектом LLVM продолжится и в дальнейшем.

Настройка зон сервера BIND в CentOS Stream 9

Второй, он же заключительный, веб-каст на тему сервера разрешения имён BIND в CentOS Stream 9. В веб-касте представлено описание и демонстрации настройки зон прямого и обратного просмотра для сервера BIND. Помимо этого, демонстрируется локальная и удаленная проверка разрешения имён, а также диагностика работы сервера при помощи системного журнала (Journald).

Подробности и видео: LebedevUM

P.S. Это второй, заключительный веб-каст в группе, поэтому если вы не знакомы с сервером разрешения имен, рекомендую начать просмотр с веб-каста «Установка сервера BIND в CentOS Stream 9».

Посмотреть эту публикацию в Instagram

Публикация от Yuriy Lebedev (@lebedevum)

Новый взгляд на консоль управления Citrix App Layering

Citrix продолжает искать способы доставки новых возможностей и улучшений в Citrix App Layering, создавая великолепные административные возможности для управления приложениями и образами. На данный момент Citrix App Layering использует интерфейс управления, размещенный на изолированном виртуальном устройстве Enterprise Layer Manager (ELM). Помимо этого, консоль управления использует Microsoft Silverlight, который был снят с поддержки 12 октября 2021-го года. Так как Microsoft не будет больше активно поддерживать данную технологию, команда разработки начала трансформировать пользовательский интерфейс с Silverlight на новую платформу.

Чтобы помочь клиентам сделать переход бесшовным и быстро доставить новые возможности было принято решение разбить доставку нового интерфейса на две фазы. Об этом я подробно писал в статье «Настоящее и будущее Citrix App Layering».

В рамках релиза Citrix App Layering 2112 была завершена первая фаза улучшения консоли управления Citrix App Layering.

Фаза 1: Новый пользовательский интерфейс, поддерживающий управления шаблонами (Templates) и уровнями (Layers).

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

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

В рамках первой фазы новый пользовательский интерфейс будет сосуществовать с интерфейсом на базе Silverlight в ELM – каждый просто требует уникальный URL для доступа.

Однако, некоторые административные действия за пределами уровней и шаблонов образов по-прежнему требуют доступа к классическому пользовательскому интерфейсу на базе Silverlight. Эти задачи включают в себя применение обновлений к устройству, управление доступом на базе ролей (RBAC), управление подключением к Active Directory и управление соединителями с платформами.

Фаза 2: Завершение нового пользовательского интерфейса и удаление Silverlight.

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

Приступая к работе.

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

Приступить к работе можно уже сегодня, скачав Citrix App Layering 2112 или выполнив обновление уже развернутого виртуального устройства. После обновления можно переключиться на современный браузер, такой как Chrome, чтобы получить опыт работы с новой консолью управления. За дополнительной информацией обратитесь к документации по продукту. Команда разработки будет рада услышать любую обратную связь, которая поможет продолжить разрабатывать и улучшать консоль управления.

Подробнее познакомиться с другими новостями рабочего пространства Citrix можно при помощи моей статьи «Новое в Citrix Virtual Apps and Desktops 2112 и другие новости цифрового рабочего пространства».

Ключевые даты окончания поддержки для Windows Server 2008/2008 R2 и 2012/2012 R2

В прошлом году состоялся релиз Windows Server 2022 о новых возможностях которого я начал публиковать статьи, а также записал несколько веб-кастов на тему развертывания. Многие клиенты Microsoft уже используют новейшую версию серверной операционной системы и смогли оценить ее возможности для приложений, данных и инфраструктуры. С другой стороны, зачастую клиентам требуется больше времени для модернизации поддерживаемых приложений на старых версиях Windows Server. Сегодня мы пройдемся по ключевым датам и опциям для Windows Server 2008/2008 R2 и 2012/2012 R2.

Существует несколько вариантов для продолжения поддержки рабочих нагрузок на старых версиях Windows Server без потери защиты. Клиенты могут мигрировать в Azure с получением бесплатных обновлений безопасности (Extended Security Update, ESU), для защиты на время планирования и миграции на новейшие версии Windows Server. Также можно объединить обновления безопасности (ESU) с Azure Hybrid Benefit для увеличения выгоды от размещения в Azure. Если клиенту необходимо остаться в локальном окружении для соответствия требованиям регуляторов или по иным причинам, то можно приобрести расширенные обновления безопасности (ESU) для локальных серверов. Дополнительно, можно использовать Azure Arc, чтобы получить преимущества от автоматизированной/запланированной установки обновлений (ESU) на локальные серверы, а также получить преимущества безопасности и обслуживания в Azure.

Windows Server 2008 и 2008 R2.

Для клиентов, использующих Windows Server 2008/2008 R2, окончание второго года расширенных обновлений безопасности (ESU) наступило 11 января 2022 года. Третий год станет последним для лицензий Windows Server, он закончится 10 января 2023 года.

Клиенты могут получить дополнительный четвертый год бесплатных расширенных обновлений безопасности только в Azure (в том числе в Azure Stack HCI, Azure Stack HUB и прочих продуктах Azure). Это позволит продолжить получать обновления безопасности для Windows Server 2008 и 2008 R2 вплоть до 9-го января 2024-го года. 

Windows Server 2012 и 2012 R2.

Для клиентов Windows Server 2012/2012 R2 окончание поддержки наступит 10 октября 2023-го года. До октября 2022 года доступны для заказа расширенные обновления безопасности (ESU), их установка начнется с 10 октября 2023 года. Обновления безопасности (ESU) будут доступны в течении трёх лет с ежегодным продлением, вплоть до финальной даты 13 октября 2026-го года.

Заключение.

Для клиентов Software Assurance или лицензий по подписке в рамках корпоративного соглашения, которые не могут мигрировать свои установки Windows Server в Azure, доступна опция расширенных обновлений безопасности (ESU). Дополнительные подробности и инструкции по заказу и активации расширенных обновлений безопасности для Windows Server 2008 и 2008 R2 можно найти по ссылке. Дополнительные сведения о заказе расширенных обновлений безопасности для Windows Server 2012 и 2012 R2 станут доступны ближе к дате окончания поддержки.

VMware vExpert 2022

Третий год подряд компания VMware оценивает мой вклад в развитие сообщества VMware и вручает награду VMware vExpert.

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

Релиз VMware vSAN 7 Update 3

В прошлом году стала доступна новая версия VMware vSAN 7 Update 3, которая доставляет гибкость, устойчивость и готовность к будущим нагрузкам в инфраструктуру. Чтобы материал не остался лежать в столе, я решил опубликовать его сейчас.

VMware vSAN предоставляет общую модель управления в периметре, облаке или корневом центре обработки данных (ЦОД). В новом релизе увеличена надежность платформы, упрощено управление и просмотр, а также расширена инфраструктура для разработки.

Улучшения платформы.

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

Растянутые кластеры vSAN – это мощная топология, которая обеспечивает полную устойчивость в окружении, даже в случае выхода из строя географического расположения (сайта) по какой-либо из причин. VMware vSAN 7 Update 3 увеличивает доступность данных в случае недоступности сайта данных с последующей запланированной или не запланированной доступностью хоста наблюдателя. Доступность данных достигается за счет обеспечения защиты виртуальных машин и данных на уровне сайта, когда сайт данных и хост наблюдатель отключены (Offline). Эта возможность похожа своим поведением на конфигурацию синхронной репликации в массиве хранилища, она применима не только к растянутым кластерам (Stretched Clusters), но и к двух-узловым кластерам vSAN.

Многие клиенты VMware нашли двух-узловую топологию vSAN экстраординарно эффективной для сценариев с удаленным расположением, а также для реализации в периметре. Двух-узловые топологии высоко эффективны за счет предоставления устойчивости к событиям выхода из строя одного из хостов. В vSAN 7 Update 3 эта возможность была расширена за счет добавления вторичного уровня устойчивости. Практически также как растянутые кластеры vSAN, двух-узловые топологии теперь предлагают второй уровень устойчивости при наличии трех и более дисковых групп на хосте. Это значит, что топология способна выдержать полный выход из строя одного хоста, отказ наблюдателя и выход из строя дисковой группы на оставшемся хосте и при этом предоставлять полную доступность данных.

Поддержка хранения ключей через Trusted Platform Module (TPM) на хосте.

VMware vSAN предлагает службы шифрования для обеспечения целостности данных, хранящихся в окружении. Для шифрования данных в состоянии покоя (Data-at-Rest Encryption) управление ключами может обеспечиваться за счет vSphere Native Key Provider (NKP) или внешней службы управления ключами (KMS). В vSAN 7 Update 3 представлена полная поддержка использования Trusted Platform Module (TPM) на хостах с кластером vSAN для сохранения распределенных ключей, что защищает от ошибок коммуникаций с поставщиком ключей. Использование TPM полностью поддерживается при помощи vSphere NKP или внешнего управления ключами (KMS) и является одним из лучших методов построения надежного метода распространения и хранения ключей.

Упрощенное управление.

Анализатор ввода/вывода виртуальной машины, интегрированный в vCenter Server.

Поиск узких мест производительности в распределенных системах хранения, таких как vSAN может стать серьезным испытанием. В vSAN 7 Update 3 добавлен VM I/O Trip Analyzer для определения основных точек конкуренции. За счет возможности иллюстрации части пути данных в интерфейсе vCenter Server, администраторам предоставляется визуализация с индикацией возможных причин. Новая возможность не только отобразит визуальный путь данных, но и измерит вариативность (стандартное отклонение) времени задержки системы, которое поможет администраторам ответить на вопросы производительности и согласованности компонентов. Это дополняет существующие представления производительности vSAN, а также обеспечивает подробности ввода/вывода (IO Insight) для гранулированного отслеживания профилей ввода/вывода определенных виртуальных машин.

Корреляция проверок здоровья Skyline для vSAN.

Проверки здоровья Skyline для кластера vSAN – это внушительный список проверок для захвата наиболее популярных ошибок, таких как ошибки в настройке. Новая логика vSAN 7 Update 3 обладает способностью понять связь между проверками здоровья для более быстрого и эффективного устранения неисправностей. Понимание связей между несколькими вызванными проверками здоровья позволяет быстрее выявлять корневую причину неисправности, что поможет устранить большинство или даже все предупреждения. Функционал также доступен через API, что позволяет использовать его в других решениях, таких как vRealize Operations.

Расширения мониторинга сети.

VMware vSAN 7 Update 3 представил несколько новых метрик и проверок здоровья для предоставления лучшей видимости фабрики коммутации, подключенной к хостам vSAN, и возможности убедиться в наивысшем уровне целостности кластера. Обнаружение дублирования IP-адресов теперь является частью проверок здоровья, как и обнаружение ошибок синхронизации LACP, которые могут привести к задержкам в конфигурации.

Интеллектуальные рабочие потоки остановки и запуска кластера.

В некоторых случаях требуется полостью выключить кластер vSAN. VMware vSAN 7 Update 3 добавил новый подход в обеспечении корректного выключения, таким образом, чтобы данные и плоскость управления были переведены в требуемое состояние. Рабочий поток с предварительными проверками поможет в сценариях выключения и включения для получения целостного, прогнозируемого результата. Упрощенные процедуры выключения и запуска, вместе с прочими улучшениями направлены на упрощение управления окружением vSAN.

Расширение vLCM для поддержки дополнительных рабочих потоков vSAN.

vSphere Lifecycle Manager (vLCM) представил полностью новые уровни управления жизненным циклом хостов в кластерах vSphere и vSAN. VMware vSAN 7 Update 3 предоставил поддержку для топологий vSAN с выделенным хостом-наблюдателем (Witness Host Appliance). Как растянутые кластеры, так и двух-узловые окружения с выделенным наблюдателем, теперь могут управляться и обновляться при помощи vLCM. Дополнительно vSphere Lifecycle Manager теперь может выполнять проверку устройств хранения NVMe по списку совместимого оборудования (HCL).

Доставка инфраструктуры для разработки.

VMware продолжает расширять возможности vSphere и vSAN для соответствия потребностям разработчиков и администраторов. Современная инфраструктура – это ключ к быстрой и эффективной доставке сервисов.

Поддержка растянутых кластеров vSAN для кластеров Kubernetes.

Инфраструктура для разработки должна соответствовать множеству требований организации и разработчиков, которые создают и управляют приложениями. Доступность на уровне сайта часто является одним из таких требований. VMware vSAN 7 Update 3 представляет расширения в платформе для обеспечения требований к устойчивости на уровне сайта. Растянутые кластеры могут быть идеальными для окружений, использующих постоянные тома в оригинальном Kubernetes. Все те же возможности устойчивости, присутствующие в растянутых кластерах vSAN и доступные для традиционных рабочих нагрузок, будут доступны для Kubernetes, в том числе второй уровень устойчивости и привязка к сайту (Site-affinity).

Новые сертифицированные облачные решения и улучшенное обновление.

Вместе с новейшей версией vSAN стали доступны новые сертифицированные операторы постоянных сервисов от партнеров. Партнеры VMware – независимые поставщики программного обеспечения, самостоятельно выпускают анонсы своих предложений, но самое интересное здесь заключается в том, что начиная с VMware vSAN 7 Update 3 операторы могут обновляться без необходимости в обновлении vSphere, vSAN или vCenter Server. Разделение управления жизненным циклом постоянных сервисов (Persistent Services) обозначает более простые обновления для клиентов.

Файловые и блочные постоянные тома в vSphere с Tanzu.

Вместе с новейшей редакцией, использование файловых томов с множественным доступом для записи (Read-Write-Many, RWM) теперь поддерживается в vSphere с Tanzu, в дополнение к блочным томам с единичным доступом для записи (Read-Write-Once, RWO), поддерживаемым в предыдущих версиях. Предоставление полностью новых уровней гибкости и эффективности для микро-сервисов с целью упрощения монтирования и доступа к постоянным томам, как и другим подам в кластере. Тома с множественным доступом для записи (RWM) могут быть легко предоставлены гостевым кластерам Tanzu Kubernetes Grid (TKG) при помощи файловых служб vSAN.

Дальнейшие шаги.

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

Подробнее познакомиться с новыми возможностями VMware vSphere 7 Update 3 можно при помощи моей статьи «Релиз VMware vSphere 7 Update 3».