1. Подключиться на Веб-интерфейс
2. Перейти в раздел Management -> System Setting
3. Выбрать пункт Component options
4. Установить SSH-сервер и, при желании, SFTP-сервер
5. Перезагрузить роутер
6. По умолчанию SSH-сервер работает в private-сетях, то есть из локальной сети доступ по 22 порту должен быть из коробки, но у меня его не было, хотя сеть отвечала требованиям (и telnet из неё работал) - show interface Home показал security-level: private
7. Проверить, что служба SSH запущена, можно выполнив команду show processes, либо перейдя по ссылке - http://<router_ip>/rci/show/processes, и найдя там "id": "SSH server" (должен быть в статусе RUNNING)
1. Если компонент в статусе STOPPED, надо подключиться к роутеру с помощью telnet и выполнить команду service ssh
2. Либо ту же самую команду выполнить в webcli по адресу http://<router_ip/a
8. Подключиться к роутеру командой ssh <user>@<router_ip>. Пользователь должен быть таким же, как в административном интерфейсе.

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

• Разработка
• DevStack - OpenStack, разворачивающийся в виртуальной машине или на физическом железе. Позволяет развернуть облако как на одной ноде, так и собрать несколько в кластер. Развивается OpenStack-сообществом.
• Kubernetes
• OpenStack-Helm - OpenStack, собранный в Helm-chart, позволяющий управлять виртуальными машинами. Имеет в себе инструментарий для настройки ассетов, например, Storage-backends, таких как Ceph или NFS.
• Sunbeam - Относительно новое решение, позволяющее использовать OpenStack в Kubernetes как на однонодовых решениях, так и с сотнями и тысячами гипервизоров.
• Ansible
• OpenStack-Ansible - деплой OpenStack, упакованного в LXC-контейнеры, при помощи Ansible
• Kolla-Ansible - деплой OpenStack, упакованного в Docker-контейнеры, собирающиеся при помощи Kolla, при помощи Ansible
• OpenStack
• TripleO - использует OpenStack для деплоя OpenStack. В настоящий момент последняя поддерживаемая версия OpenStack - Wallaby. С февраля 2023 года дальнейшее развитие продукта не планируется.
• Canonical Infrastructure
• MicroStack - OpenStack в Kubernetes, упакованный в snap-пакет. Позволяет развернуть облако на локалхосте, либо небольшой приватный кластер.
• Charmed OpenStack - деплой OpenStack с использованием Juju. Использует фреймворк Charmed Operator Framework. Очень лёгкий в управлении и гибкий в настройке. Интегрируется в Metal-as-a-Service (MAAS)
• Baremetal
• Kayobe - инструмент, позволяющий установить OpenStack на железо, используя Bifrost, Kolla и Kolla-Ansible
• Airship - набор утилит, позволяющий развернуть облако с OpenStack в Kubernetes с нуля. Использует yaml для описания конфигурации деплоя.
• Internet of Things
• StarlingX - решение, предназначенное, в основном, для промышленного IOT, где критичны низкие задержки. Использует контейнеры
• Ручная установка
• Никто не запрещает собрать OpenStack из исходных кодов или использовать пакетный менеджер, однако это достаточно трудоёмкий и долгий путь, имеющий в настоящее время академическую ценность

Какой способ подойдёт мне?

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

Кто будет устанавливать, поддерживать и обслуживать OpenStack?

Чтобы было проще оценить свои силы, вот ещё вопросы:

• Вы управляете инфраструктурой своего дата-центра?
• Вы управляете своей сетевой инфраструктурой?
• Вы управляете конфигурацией операционных систем?
• Есть ли у вас опыт оркестрации сложной рабочей нагрузки на десятках-сотнях-тысячах нод?

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

В каком состоянии моя инфраструктура?

Если же вы всё таки решились деплоить OpenStack своими силами, ответьте на следующие вопросы:

• Вы используете Kubernetes?
• Если да, то есть ли у вас административный доступ к кластеру?
• Какой дистрибутив ОС вы используете?
• Что вы используете для оркестрации своей инфраструктуры? (Ansible, Chef, Puppet, etc)
• Деплоите ли вы софт с помощью LXC или Docker?
• Используете ли вы свои образы операционных систем и зеркала дистрибутивов или полагаетесь на общедоступные комьюнити-сборки и репозитории?

Для чего вы будете использовать OpenStack?

• Какой будет рабочая нагрузка?
• Высокопроизводительные вычисления? (HPC)
• Телеком
• Оркестрация контейнеров
• Виртуальные машины
• Кто будет пользоваться этим ежедневно?
• Непревилегированные пользователи (не системные администраторы)
• Вы и ваша команда
• Клиенты

Каждая система деплоя создана под специфические задачи различными людьми. Схожи ли их задачи и взгляды с вашими?

Достаточно ли у вас опыта в Kubernetes?

Если да, OpenStack-Helm может вам подойти

• OpenStack-Helm использует Helm для деплоя OpenStack в Kubernetes, давая возможность запускать виртуальные машины
• Что такое Helm?
• Это пакетный менеджер для Kubernetes
• С помощью Helm вы можете упаковать свой деплой и управлять им в дальнейшем
• Деплой представляет собой Helm-chart
• OpenStack-Helm представляет собой Helm-chart'ы для деплоя OpenStack и сопутствующего программного обеспечения
• Также OpenStack-Helm предоставляет инструменты и скрипты для настройки ассетов, например storage-бэкэнды
• OpenStack-Helm деплоится через Ubuntu и Docker

Используете ли вы Ansible?

OpenStack-Ansible и Kolla-Ansible могут быть хорошим решением, т.к. используют Ansible для деплоя OpenStack

• Используете ли вы LXC или Docker?
• OpenStack-Ansible деплоит компоненты OpenStack используя LXC
• Kolla-Ansible деплоит компоненты OpenStack используя Docker
• Оба решения достаточно гибки и имеют меньше ограничений, чем другие способы деплоя OpenStack
• У решения большая поддержка операционных систем, таких как Debain- и RHEL-based

Есть ли у вас baremetal сервера?

• Kayobe - это хорошее решение, позволяющее управлять железными серверами с помощью Bifrost (ironic)

Выводы

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

Шаг 1. Создаём репозиторий

Идём на https://gitlab.com/, регистрируемся, создаём группу для нашего проекта (чтобы не плодить верхнеуровневый мусор) и пустой репозиторий в этой группе, где будет храниться код сайта.

Шаг 2. Создаём HTML страницу

Кто-то скажет что это слишком дедовский способ - использовать чистый HTML в 2023 году, но во-первых, интернет был 3000 лет назад и я был там, во-вторых, я видел такое, во что вы, люди, просто не поверите. Сайты на flash, табличная вёрстка, гостевые книги... Все эти мгновения затеряются во времени, как слёзы в дожде. Так, стоп. Я слишком увлёкся. На самом деле моя мотивация очень проста. Во-первых, в 2023 году всем абсолютно наплевать на вашу домашнюю страницу и на все её технологии. Во-вторых, чистый HTML идеален в плане кроссплатформенности. Его можно открыть на любом чайнике, даже если тот умеет работать только из текстового терминала, он растягивается под любой экран, весит минимально и грузится мгновенно. Круто же.

В общем, создали файл index.html, добавили туда теги, контент, сохранили, добавили в git, запушили в gitlab-репозиторий. Молодцы.

Пример чистого HTML:

<!DOCTYPE html>
<html>

<head>
  <meta charset="utf-8">
  <title>My homepage</title>
</head>

<body>
  <h1>Welcome to my homepage</h1>
  <p>This site uses pure HTML</p>
</body>

</html>

Шаг 3. Создаём Dockerfile

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

За основу возьму alpine, в котором будет крутиться nginx. Dockerfile будет таким:

FROM alpine:3.18.4

LABEL maintainer="Andrey Dolbilin nonice@ionice.ru"

RUN set -x \
    && addgroup --system --gid 101 nginx \
    && adduser  --system --ingroup nginx --no-create-home --home /nonexistent --gecos "nginx user" --shell /bin/false --uid 101 nginx \
    && apk add --no-cache nginx \
    && ln -sf /dev/stdout /var/log/nginx/access.log \
    && ln -sf /dev/stderr /var/log/nginx/error.log \
    && mkdir -m 755 /www \
    && chown nginx:nginx /www

COPY ./docker/default.conf /etc/nginx/http.d/default.confcat 
COPY --chown=nginx:nginx --chmod=644 ./index.html /www/

WORKDIR /www

EXPOSE 80

STOPSIGNAL SIGQUIT

ENTRYPOINT ["nginx", "-g", "daemon off;"]

Здесь мы создаём группу и пользователя nginx, от которого веб-сервер работать, устанавливаем сервер, логи монтируем в стандартный поток вывода, создадим директорию, скопируем конфигурацию для nginx и сам файл index.html.

Сама конфигурация виртуального хоста для nginx выглядит так:

#docker/default.conf 
server {
	listen 80 default_server;

	root /www;

	location / {
	}
}

Этого хватит чтобы собрать docker-образ, запустить контейнер и проверить проделанную работу, перейдя на http://localhost/:

docker build . -t my/nginx -f docker/Dockerfile
docker run --rm -d -p80:80 my/nginx

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

Предыстория

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

Техническое задание v 0.1

Необходимо создать сайт-визитку в виде статичной HTML-страницы, указав на ней информацию об авторе сайта.

Разработка

• Подготовить Git-репозиторий для размещения исходного кода проекта
• Создать валидную HTML-страницу с указанным содержимым

Контент

• Указать имя автора сайта
• Указать краткую информацию об авторе сайте
• Указать ссылки на блоги и аккаунты в соцсетях и репозиториях

Размещение

• Сайт должен представлять из себя docker-образ или набор образов, позволяющий запускать контейнер в любой среде исполнения, в том числе kubernetes
• Сайт должен размещаться на внешнем выделенном виртуальном сервере (продакшен)
• Сайт должен автоматически разворачиваться на внешнем хостинге при внесении изменений в исходный код

Безопасность

• Доступ к репозиториям исходного кода должен быть ограничен на изменение авторизованными учётными записями
• Доступ к управлению продакшен-сервера должен быть ограничен авторизованными учётными записями с использованием ключевой аутентификации. Парольный доступ должен быть исключён
• Сайт должен использовать протокол подключения HTTPS

Приёмка изменений

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

То есть мы делаем что? Мы делаем сайт и готовим инфраструктуру. Примерно такую:

Архитектура

Я хочу предусмотреть возможность в перспективе развернуть не только статичный сайт, а какой-нибудь свистящий по-всякому CMS, поэтому начальные решения будут такими:

1. Terraform - для раскатки тестового сервера и Gitlab Runner на Qemu/KVM.
2. Ansible - для подготовки окружения на серверах
3. K0S - для запуска контейнеров
4. Репозиторий кода - GitLab. Сначала буду использовать общедоступный, но в перспективе перееду на self-hosted решение.
5. Обеспечение CI/CD - GitLab Runner для деплоя сайта на тестовые и продакшн сервера

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

В следующей части займёмся разработкой. Пока!

Разработка

• 30 Days of Python - обучалка Python за месяц
• Google python style guide - гайд по стилю написания кода на python от Google
• Деплой Kubernetes - гайд по деплою кубера. В кои-то веки что-то годное на Хабре
• direnv - утилита для загрузкии и выгрузки переменных окружения в зависимости от директории
• distrobox - решение, позволяющее использовать любой дистрибутив linux в терминале. По идее, просто удобная оболочка над контейнеризацией
• progress - утилита, позволяющая смотреть прогресс на больших задачах в терминале
• Внедрение DevSecOps - статья о том, как внедрить стратегию shift left в пайплайн для внедрения инструментов безопасности
• DevSecOps RoadMap - дорожная карта по внедрению DevSecOps более подробно
• IKEA-oriented development - очередной способ разработки, на этот раз в стиле ИКЕА
• zellij - альтернатива tmux

Сети

• rconfig core - open source инструмент, позволяющий массово управлять конфигурацией сетевых устройств (snapshot, deploy, etc)
• netbox - решение по автоматизации настройки сети в датацентрах
• RouterOS Scanner - сканер подозрительных настроек на устройствах Microtik
• sx - сетевой сканер, альтернатива nmap
• gping - ping с графиками

Данные

• lakeFS - Git для данных. Например, версионирование данных в S3.
• Vaultwarden - альтернатива Bitwarden, написанная на Rust
• DBA1 - базовый курс по администрированию PostgreSQL 13 от postgrespro
• Postgres tips - 5 советов по настройке PostgreSQL
• rclone - утилита для синхронизации данных с облаками
• fx - консольная утилита для работы с json
• Replace RabbitMQ with a Postgres Queue - мысли о том, почему команда отказалась от RabbitMQ в своём проекте
• PostgreSQL HA - как собрать высокодоступный Posgres
• pg_easy_replicate - утилита для упрощения логической репликации в Postgres

Мониторинг

• parseable - легковесный логгер для cloud native приложений
• manticoresearch - быстрая альтернатива elasticsearch
• openobserve - ещё одна альтернатива elasticsearch
• Uptime checks for availability - статья о том, как с помощью аптайма проверять доступность

Безопасность

• CTR Kubernetes Hardening Guide - Годный PDF по безопасной настройке кубера от NSA CISA
• OSCP - шпаргалка по Offensive Security Certified Professionsl Certification
• sshlog - пассивный мониторинг ssh-сервера

Железо

• psref.lenovo.com - ресурс, на котором можно найти по артикулу ноутбук и проверить, например, напаяна в нём оперативная память или имеет отдельные слоты расширения.
• ventoy - утилита для создания загрузочных флешек, с помощью которой можно грузиться с любых ISO, закинутых в специальную директорию. Суть та же, что у аппаратных решений IODD и Zalman

Подборки

• free-for.dev - очень годный каталог сервисов и софта, который может быть полезен при разработке своего приложения или разворачивания инфраструктуры
• vim для всех уровней погружения - цикл статей по использованию Vim от новичка до ветерана

Забавное

• thefuck - утилита, корректирующая предыдущую неправильно набранную команду
• Душим жабу неэффективности - очередная статья про GTD, успешный успех и прочий культ эффективности
• carbonyl - браузер chromium в консоли
• rePalm - история и попытки воскресить PalmOS на современном железе
• the work - статья о том, почему работа над задачей не про выполнение непосредственно самой задачи, а про предшествующие и последующие задаче действия, которые стоит учитывать при планировании

Немного истории.

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

DevOps-инженеры стали отвечать за подготовку среды в которой запускается приложение - писать пайплайны, terraform-инфраструктуру, ansible-скрипты, docker-образы, k8s-деплойменты, подключать мониторинги, логирование, сканеры безопасности, хранение секретов и прочую автоматизацию для создания единообразной среды разработки и эксплуатации, позволяющей минимизировать ущерб в случае багов и доставлять фиксы и фичи в максимально короткий срок.

Выглядит круто. Но появляется новая проблема. Благодаря ускорению разработки, теперь можно увеличить количество проектов. В каждом проекте сидят свои DevOps-инженеры и пишут свои пайплайны, используя актуальный для проекта стек. Где-то это managed k8s, где-то aws, где-то gcp и так далее. И вот уже получается так, что управление всей этой инфраструктурой становится процессом чуть ли не более сложным, чем разработка продукта - скорость написания качественного deployment для k8s не будет поспевать за разработкой и та начнёт простаивать. К тому же DevOps-инженер должен обладать достаточно высокой квалификацией чтобы не тащить на дно процесс разработки, а это дорого. Проблема примерно та же, что была в начале - бизнес начинает недополучать прибыль на которую рассчитывал. А раз аппетиты растут, а чувство голода не проходит, надо снова сесть за стол переговоров и разобраться с процессами. Где может быть бутылочное горлышко? Правильно - в инструментах, требующих настройки. Потому что писать пайплайны может каждый, кто прошёл инфоцыганские курсы, а поднять кластер k8s, настроить сети и прочую инфраструктурную периферию - уже нужен опыт, которого зачастую может не хватать. А раз в каждой команде очередного проекта своя атмосфера, значит все вспомогательные команды (те же безопасники и мониторщики), тратят время на понимание того, что от них требуется в каждом проекте. То есть масштабирование проектов становится затыком из-за отсутствия внутренних стандартов. И вообще жизнь превратилась в ад, потому что если раньше подход "You build it, you run it" работал, то теперь мир изменился - приложение, состоящее из сотни-другой микросервисов, плюс пары десятков инфраструктурных сервисов, запускается в multi-cloud архитектуре, размазанное по aws, gcp и azure. Ни один здравомыслящий человек уже не разберётся что тут к чему. И в этом не должно быть необходимости - backend-разработчику платят за разработку api, frontend-разработчик пилит красивый интерфейс и никто из них не должен тратить своё время на подготовку инфрастркутуры, поднятие k8s-кластеров и тому подобного - это слишком расточительно. Этим занимается команда DevOps, но и у них случается проблема в стиле "вас много, а я одна" (растёт ответственность и нагрузка, к тому же возникает несогласованность процессов от проекта к проекту) , из-за чего страдает общее качество работы.

И вот тут на помощь приходит подход Platform engineering, отвечающий, по сути, за создание фреймворка разработки.

Platform engineering

Суть подхода заключается в следующих принципах:

• Стандартизация использования инструментов - берём инструменты для деплоя и запуска приложений и стандартизируем подход к их использованию на все команды. Если команды используют разные инструменты CI/CD, предлагаем им перейти на единую платформу. Если на проектах используется k8s, пишем стандарты его применения. То есть всё, что не отвечает за бизнес-логику приложения, должно быть стандартизировано и оптимизировано (VCS, CI/CD, Runtime, Provision, Observing, Securing, etc)
• Разделение ответственности. Каждый инструмент имеет базовую ролевую модель Admin-User. Админы отвечают за настройку инструмента, его безопасность, плагины, бэкапы и т.п., пользователи - за свою работу с этим инструментом. То есть одни управляют, другие используют. Это позволяет разделить ответственность. Как я писал раньше - настроить кластер k8s и писать deployment для него - это скиллы разного уровня, но обычно в DevOps командах всё ложится на плечи простого инженера, квалификация которого страдает от проекта к проекту. Таким образом можно переопределить команды DevOps-инженеров, отправив часть на поддержку платформенных сервисов, а часть оставить на настройку пайплайнов. Таким образом экспертиза в целом будет повышена, т.к. каждая команда наконец-то займётся каким-то одним делом.

Что получается? Получается, что мы опять создали модель, с которой всё начиналось, только теперь в качестве Dev - инженеры, отвечающие за написание пайплайнов, а роль Ops выполняют люди, отвечающие за настройку инструментов. Будут ли у них в итоге те же проблемы? Наверняка ожидание доступов или добавление новых плагинов в сервисы станет бутылочным горлышком. Но (!) подход platform engineering здесь добавляет новый принцип:

• Создание пользовательского интерфейса для взаимодействия с услугами. То есть инженеры платформы пилят сервис с UI или API для заказа тех самых provisioned, up-to-date, secured сервисов, за которые раньше у всех болела голова.

То есть команда разработки не ходит к инженерам платформы, для них сделан PaaS сервис, где они сами вольны выбрать всё что им нужно. Называется он Internal Developer Platform (IDP) Так что цель инженеров платформы - пилить стандартные решения, которые можно заказать через этот сервис. То есть теперь разработчик не идёт заказывать на aws кластер eks, а жмёт кнопку в интерфейсе IDP, который сам закажет кластер, настроит доступы, бэкапы, мониторинг и логирование. И это занимает минуты в отличие от стандартного подхода, когда подобные задачи выполнялись командами DevOps в течение дней.

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

Например, одной команде хватает gitlab-ci, другой привычнее работать с jenkins, третья хочет circleci, четвёртая - argo-ci. Зачастую возникает ситуация, когда компания говорит что "у нас стандартом является только одна CI, кому не нравится - нас не волнует". Задача platform engineering заключается в том, чтобы этот барьер пробивать и находить решения, способные всех удовлетворить. То есть инженеры платформы приходят к команде и говорят "Вы хотите использовать CircleCI? Ок, давайте мы вам настроим её с учётом всех best-practices, а потом интегрируем в нашу платформу чтобы и остальные могли использовать этот инструмент, если в нём возникнет потребность". То есть инженеры платформы вместо ограничений замотивированы на расширение возможностей своего продукта. В реальности, конечно, будет так, что какая-то команда использует маргинальные решения, внедрять которые в платформу не имеет смысла, тогда придётся обслуживать это решение по старинке.

Ещё один момент - инженеры платформы не должны ограничивать возможность конфигурирования сервисов в IDP под себя. Вместо этого они должны предусмотреть возможность гибкой настройки этих сервисов. То есть вместо прибивания всего гвоздями, инженеры должны использовать лучшие практики, такие как Infrastructure as Code (IaC) для создания шаблонов, в которые можно вносить изменения, при этом не нарушая общую безопасность и стабильность.

Внедрение platform engineering

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

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

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

Platform vs DevOps

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

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

С такой философией идём смотреть на мультитулы:

• GHK-9 куплен мной в начале весны в качестве вспомогательного инструмента на загородном участке.
• GHK-6 pro был приобретён в подарок знакомым, чтобы сложить в машину.

Чехлы

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

Кстати, таскать мультитул в чехле на ремне достаточно удобно.

Общий вид

По сути перед нами два мультитула, построенных на единой платформе, различие в которых только в накладках ручек и наличии карабина в GHK-9. Рама и основные компоненты практически идентичны.

С одного бока мультитулы невозможно различить

С другого бока отличия более выражены

Основной инструментарий

На каждой ручке с наружной стороны есть по два инструмента, фиксирующихся лайнер-локами

GHK-6 pro:

• Нож
• Пила
• Ножницы
• Напильник-линейка

GHK-9:

• Нож
• Короткая пила
• Ножницы
• Короткий двусторонний напильник

Лезвие ножа и ножницы отличные. Ножом я срезал ветки с кустов и затачивал колышки, а ножницы спокойно режут и плотный картон, и ногти

Пила на GHK-9 имеет более острый зуб, но полотно короткое - толстые ветки пилить не очень удобно. В GHK-6 pro полотно больше, но заточка зубов тупее. Так что на деле обе пилы больше аварийные, чем рабочие.

Напильник на GHK-9 мне нравится больше, потому что имеет два вида зернистости. Один подходит для обработки твёрдых поверхностей, вторым можно подправить ногти. У GHK-6 pro только грубый напильник, а с другой стороны линейка. Раньше я думал что это глупость, но по факту ей удобно измерять размеры крепежа, диаметры отверстий и прочую мелочёвку. Оба напильника на конце имеют плоскую отвёртку, которую удобно использовать для подковыривания гвоздей или скоб.

Пассатижи

На обоих мультитулах стоят идентичные универсальные пассатижи. Они подпружинены, пружина скрыта в корпусе. Что касается удобства - в GHK-6 pro обе ручки симметричны, это позволяет хватать их из любой позиции, на GHK-9 придётся подбирать "любимую" сторону под свой хват. Люфты ручек на GHK-6 pro больше.

Дополнительный инструментарий

GHK-6 pro:

• Крестовая отвертка
• Шило
• Стропорез
• Бутылочная открывашка с плоской отверткой
• Консервный нож

GHK-9

• Крестовая отвертка
• Консервный нож
• Карабин с бутылочной открывашкой

Также в комплекте идут идентичные адаптеры с битами

Общие впечатления

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

Недостатки

• Грубая обработка ручек. Стоит посильнее сжать мультитул в ладони, как он начинает впиваться в неё и заставляет испытывать боль. Для комфортной работы неплохо иметь перчатки
• Посредственные биты. Даже в наборах из FixPrice можно найти что-то посерьёзнее. Но по факту пользоваться этими битами придётся в очень редких случаях.
• Болтающийся битодержатель. Хоть во втулке и есть прямоугольное отверстие, люфты всё равно достаточно существенные. Тут либо терпеть, либо дорабатывать напильником.

Достоинства

• Фиксаторы на всех инструментах
• Подпружиненные пассатижи
• Сменные губки кусачек
• Сбалансированный набор инструментов
• Цена, позволяющая не переживать насчёт гарантий
• Стандартные биты, которые не страшно потерять
• Хорошая заточка
• Достаточная износоустойчивость в бытовых задачах

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

В садовом инвентаре я не особо силён, поэтому просто поделюсь фотографиями и своим мнением о секаторе.

Мультитул поставляется в чёрной коробочке. Коробочка неожиданно тяжёлая для своего размера.

Извлекаем содержимое и любуемся изделием в сложенном виде. Сразу обращаем внимание на пару моментов:

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

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

Раскрываем мультитул и смотрим что он может:

• Секатор - основная функция мультитула. Снабжён замком и подпружинен. Заточка отличная. Подрезать кусты таким инструментом можно, но обычный секатор справится с более толстыми ветками.
• Ножовка по дереву. Полотно с двойными зубьями, короткое, но заточено хорошо. Ветки толще трёх сантиметров таким спилить будет очень трудно (и зачем?)
• Серрейтор. Спорная опция, но лезвие заточено хорошо.
• Окулировочный нож. Режущая часть лезвия больше на полсантиметра по сравнению с 91 мм швейцарским ножом.
• Нож для снятия коры. Честно, не знаю как пользоваться этим инструментом, но заточка, как и на предыдущих опцияз, отличная.

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

Попользоваться этим инструментом мне, к сожалению, не удалось, но выводы могу сделать следующие:

• Инструменты хорошо заточены и функциональны
• Секатор свою основную функцию будет выполнять на достойном уровне, если не усердствовать на ветках, которым больше подходит веткорез
• Люфты есть, но незначительные
• Нет чехла или любого другого способа носить мультитул в быстром доступе
• Нет главного признака мультитула - бутылочной открывашки

Теперь про бренд Makita. Я так и не смог найти упоминание об этой модели (кстати, так и не понял как правильно - PGC-200190 или PCG-200190) на официальном сайте или в каких-либо новостях, кроме одной, что она является подарочной промо-продукцией. На самом деле этот мультитул выпускался и под другими брендами, например, Draper PS6 или Zenport MFT45.

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

Собираем стенд

Окружение

Собственно, нам много не надо - сервер с qemu-kvm и какая-нибудь виртуалка с не самым маргинальным дистрибутивом. В моём случае qemu-kvm развёрнут прямо на лаптопе, в виртуальной машине крутится Ubuntu Jammy:

andrey@ionice:~$ virsh list

 Id   Name                      State
-----------------------------------------
 7    ubuntu22.04-guest-agent   running

Установка qemu-guest-agent

Установка агента тривиальна и скучна - всё есть в репозиториях, устанавливаем и стартуем службу

andrey@ionice:~$ virsh console ubuntu22.04-guest-agent

qga login: server
Password: 
Welcome to Ubuntu 22.04.1 LTS (GNU/Linux 5.15.0-71-generic x86_64)

server@qga:~$ sudo apt install qemu-guest-agent
server@qga:~$ sudo systemctl enable --now qemu-guest-agent
server@qga:~$ sudo systemctl status qemu-guest-agent
● qemu-guest-agent.service - QEMU Guest Agent
     Loaded: loaded (/lib/systemd/system/qemu-guest-agent.service; static)
     Active: active (running) since Thu 2023-04-27 18:03:54 UTC; 1min 19s ago
   Main PID: 1039 (qemu-ga)
      Tasks: 2 (limit: 4572)
     Memory: 380.0K
        CPU: 1ms
     CGroup: /system.slice/qemu-guest-agent.service
             └─1039 /usr/sbin/qemu-ga

Apr 27 18:03:54 qga systemd[1]: Started QEMU Guest Agent.

^[

Всё, основную часть задачи выполнили. Теперь убедимся что наша виртуалка имеет устройство qemu-ga:

andrey@ionice:~$ virsh dumpxml ubuntu22.04-guest-agent
...
    <channel type='unix'>
      <target type='virtio' name='org.qemu.guest_agent.0'/>
      <address type='virtio-serial' controller='0' bus='0' port='1'/>
    </channel>
...

Если такой секции нет, можем дописать с помощью команды virsh edit ubuntu22.04-guest-agent. Желательно перезагрузить виртуалку после таких манипуляций командой virsh reboot ubuntu22.04-guest-agent.

Проверка связи

Теперь самое интересное - обратимся к виртуальной машине через агента:

andrey@ionice:~$ virsh qemu-agent-command ubuntu22.04-guest-agent '{"execute": "guest-ping"}'
{"return":{}}

Ну... как-то не впечатляем. Дубль два:

andrey@ionice:~$ virsh qemu-agent-command ubuntu22.04-guest-agent '{"execute": "guest-get-time"}' --pretty
{
  "return": 1682620143771430000
}

Сделаем поправку на ветер:

andrey@ionice:~$ virsh qemu-agent-command ubuntu22.04-guest-agent '{"execute": "guest-get-time"}' --pretty | jq .return | date -d -
Чт 27 апр 2023 00:00:00 UTC

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

Обзор протокола QMP

Общение с виртаульной машиной осуществляется по протоколу QMP (QEMU Machine Protocol) через локальный сокет на гипервизоре (то самое виртуальное устройство, которое мы настраивали ранее). Протокол поддерживает весьма обширный набор команд как GET, так и POST. Формат данных протокола - JSON.

Посмотрим, какие команды поддерживает наш qemu-guest-agent в виртуалке:

andrey@ionice:~$ virsh qemu-agent-command ubuntu22.04-guest-agent '{"execute": "guest-info"}' --pretty | jq -r '.return.supported_commands[] | select(.enabled==true) | .name'

guest-ssh-remove-authorized-keys
guest-ssh-add-authorized-keys
guest-ssh-get-authorized-keys
guest-get-osinfo
guest-get-timezone
guest-get-users
guest-get-host-name
guest-exec
guest-exec-status
guest-get-memory-block-info
guest-set-memory-blocks
guest-get-memory-blocks
guest-set-user-password
guest-get-fsinfo
guest-get-disks
guest-set-vcpus
guest-get-vcpus
guest-network-get-interfaces
guest-suspend-hybrid
guest-suspend-ram
guest-suspend-disk
guest-fstrim
guest-fsfreeze-thaw
guest-fsfreeze-freeze-list
guest-fsfreeze-freeze
guest-fsfreeze-status
guest-file-flush
guest-file-seek
guest-file-write
guest-file-read
guest-file-close
guest-file-open
guest-shutdown
guest-info
guest-set-time
guest-get-time
guest-ping
guest-sync
guest-sync-delimited

Впечатляет? Ваш внутренний безопасник уже истерично лупит по кнопке "Запретить"? Мозг рисует безграничные возможности управления инфраструктурой? Чтобы понимать что к чему, сначала рекомендую почитать референс протокола и двигаться дальше.

Примеры выполнения команд

• Данные об операционной системе:

andrey@ionice:~$ virsh qemu-agent-command ubuntu22.04-guest-agent '{"execute": "guest-get-osinfo"}' --pretty | jq

{
  "return": {
    "name": "Ubuntu",
    "kernel-release": "5.15.0-71-generic",
    "version": "22.04.1 LTS (Jammy Jellyfish)",
    "pretty-name": "Ubuntu 22.04.1 LTS",
    "version-id": "22.04",
    "kernel-version": "#78-Ubuntu SMP Tue Apr 18 09:00:29 UTC 2023",
    "machine": "x86_64",
    "id": "ubuntu"
  }
}

• Список IPv4 адресов:

andrey@ionice:~$ virsh qemu-agent-command ubuntu22.04-guest-agent '{"execute": "guest-network-get-interfaces"}' --pretty | jq -r '.return[]."ip-addresses"[] | select(."ip-address-type"=="ipv4" and ."ip-address"!="127.0.0.1") | ."ip-address"'

192.168.122.17

• Список несистемных пользователей

andrey@ionice:~$ virsh qemu-agent-command ubuntu22.04-guest-agent '{"execute": "guest-get-users"}' --pretty | jq -r .return[].user

server

• Добавим пользователю server публичный ключ для доступа по SSH

andrey@ionice:~$ virsh qemu-agent-command ubuntu22.04-guest-agent '{"execute": "guest-ssh-add-authorized-keys", "arguments": {"username": "server", "keys": [ "ssh-rsa xxxxx" ] }}' --pretty

• Убедимся, что ключ был добавлен

andrey@ionice:~$ virsh qemu-agent-command ubuntu22.04-guest-agent '{"execute": "guest-ssh-get-authorized-keys", "arguments": {"username": "server" }}' --pretty
{
  "return": {
    "keys": [
      "ssh-rsa xxxxx"
    ]
  }
}

• Выполним какую-нибудь shell-команду и получим её выхлоп. Для этого нам потребуются две команды - guest-exec, чтобы запустить процесс и получить его PID, и guest-exec-status, чтобы узнать чем завершилось выполнение процесса. Выхлоп будет в формате base64

andrey@ionice:~$ virsh qemu-agent-command ubuntu22.04-guest-agent '{"execute": "guest-exec", "arguments": { "path": "/usr/bin/lsb_release", "arg": [ "-a" ], "capture-output": true }}' --pretty | jq ".return.pid"
832
andrey@ionice:~$ virsh qemu-agent-command ubuntu22.04-guest-agent '{"execute": "guest-exec-status", "arguments": { "pid": 832 }}' --pretty | jq
{
  "return": {
    "exitcode": 0,
    "err-data": "Tm8gTFNCIG1vZHVsZXMgYXJlIGF2YWlsYWJsZS4K",
    "out-data": "RGlzdHJpYnV0b3IgSUQ6CVVidW50dQpEZXNjcmlwdGlvbjoJVWJ1bnR1IDIyLjA0LjEgTFRTClJlbGVhc2U6CTIyLjA0CkNvZGVuYW1lOglqYW1teQo=",
    "exited": true
  }
}

andrey@ionice:~$ echo RGlzdHJpYnV0b3IgSUQ6CVVidW50dQpEZXNjcmlwdGlvbjoJVWJ1bnR1IDIyLjA0LjEgTFRTClJlbGVhc2U6CTIyLjA0CkNvZGVuYW1lOglqYW1teQo= | base64 --decode 
Distributor ID:	Ubuntu
Description:	Ubuntu 22.04.1 LTS
Release:	22.04
Codename:	jammy

andrey@ionice:~$ echo Tm8gTFNCIG1vZHVsZXMgYXJlIGF2YWlsYWJsZS4K | base64 --decode 
No LSB modules are available.

• Прочитаем что-нибудь из файла. Для этого сначала откроем его на чтение, получив его ID, затем прочитаем данные из файла (они будут в base64), а потом закроем файл, чтобы не держать лишние процессы и дескрипторы:

andrey@ionice:~$ virsh qemu-agent-command ubuntu22.04-guest-agent '{"execute": "guest-file-open", "arguments": { "path": "/etc/hosts", "mode" : "r" }}' --pretty
{
  "return": 1000
}

andrey@ionice:~$ virsh qemu-agent-command ubuntu22.04-guest-agent '{"execute": "guest-file-read", "arguments": { "handle": 1000 }}' --pretty
{
  "return": {
    "count": 218,
    "buf-b64": "MTI3LjAuMC4xIGxvY2FsaG9zdAoxMjcuMC4xLjEgcWdhCgojIFRoZSBmb2xsb3dpbmcgbGluZXMgYXJlIGRlc2lyYWJsZSBmb3IgSVB2NiBjYXBhYmxlIGhvc3RzCjo6MSAgICAgaXA2LWxvY2FsaG9zdCBpcDYtbG9vcGJhY2sKZmUwMDo6MCBpcDYtbG9jYWxuZXQKZmYwMDo6MCBpcDYtbWNhc3RwcmVmaXgKZmYwMjo6MSBpcDYtYWxsbm9kZXMKZmYwMjo6MiBpcDYtYWxscm91dGVycwo=",
    "eof": true
  }
}

andrey@ionice:~$ echo MTI3LjAuMC4xIGxvY2FsaG9zdAoxMjcuMC4xLjEgcWdhCgojIFRoZSBmb2xsb3dpbmcgbGluZXMgYXJlIGRlc2lyYWJsZSBmb3IgSVB2NiBjYXBhYmxlIGhvc3RzCjo6MSAgICAgaXA2LWxvY2FsaG9zdCBpcDYtbG9vcGJhY2sKZmUwMDo6MCBpcDYtbG9jYWxuZXQKZmYwMDo6MCBpcDYtbWNhc3RwcmVmaXgKZmYwMjo6MSBpcDYtYWxsbm9kZXMKZmYwMjo6MiBpcDYtYWxscm91dGVycwo= | base64 --decode 
127.0.0.1 localhost
127.0.1.1 qga

# The following lines are desirable for IPv6 capable hosts
::1     ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

andrey@ionice:~$ virsh qemu-agent-command ubuntu22.04-guest-agent '{"execute": "guest-file-close", "arguments": { "handle": 1000 }}' --pretty
{
  "return": {

  }
}

Следы

Хоть мой внутренний автоматизатор ликует, параноик всё равно немного параноит. Как минимум, ему хотелось бы понимать как пользователю гостевой ОС контролировать происходящее с его системой. Посмотрим логи с виртуалки:

root@qga:~# journalctl -u qemu-guest-agent

Apr 27 18:22:54 qga systemd[1]: Started QEMU Guest Agent.
Apr 27 18:28:40 qga qemu-ga[624]: info: guest-ping called
Apr 27 18:29:17 qga qemu-ga[624]: info: guest-ping called
Apr 27 19:55:41 qga qemu-ga[624]: info: guest-exec called: "/usr/bin/lsb_release -a"
Apr 27 19:56:45 qga qemu-ga[624]: info: guest-exec-status called, pid: 832
Apr 27 20:07:06 qga qemu-ga[624]: info: guest-file-open called, filepath: /etc/hosts, mode: r
Apr 27 20:07:06 qga qemu-ga[624]: info: guest-file-open, handle: 1000
Apr 27 20:14:12 qga qemu-ga[624]: info: guest-file-close called, handle: 1000

Как видим, ключевые команды в логе отображаются. Можно выдохнуть.

Выводы

QEMU Guest Agent - очень интересный способ контроля и управления виртуальными машинами, который уже давно используется в продуктовых средах. Если вы заранее подготовите образы ОС, напишете скрипты или сервисы управления, то сможете облегчить себе обслуживание инфраструктуры "без рук". Следует однако помнить, что применение инструмента потребует пересмотра политик безопасности. Ну и классическое - with great power comes great responsibility

Перед Новым годом нашёл себе ноутбук с возможностью разместить внутри 64 Гб памяти и пару дисков - MSI Sword 15 A12UE-486XRU. Ноутбук купил, а апгрейд отложил на пару месяцев. Когда настало время, изучил внимательно спецификацию и не нашёл никакого криминала в ограничениях по железу - ноутбук имеет 2 слота в которые можно воткнуть планки DDR4 по 32 гигабайта со скоростью 3200 МГц.

Раз ограничений нет, купил две планки Kingston Fury Impact (KF432S20IB/32). Воткнул в ноутбук, в BIOS всё определилось корректно, скорость 3200 мГц, тайминги 20-22-22-48, напряжение 1,2 В, dual channel. Однако загрузившись в ОС, обнаружил что при работе от сети ноутбук начал перезагружаться. Стал копать, однако никакой возможности переключить XMP-профили, поменять частоту или вольтаж не удалось. Конечно же я обновил BIOS и зашёл в Advanced режим (Необходимо одновременно зажать Left Alt + Right Ctrl + Right Shift + F2), но без толку. По отдельности каждый модуль в любом слоте работал идеально, но работая в паре они приводили к циклической перезагрузке. От версии ядра или ОС тоже не было обнаружено зависимости.

# dmidecode 3.3
Getting SMBIOS data from sysfs.
SMBIOS 3.4.0 present.

Handle 0x003B, DMI type 16, 23 bytes
Physical Memory Array
	Location: System Board Or Motherboard
	Use: System Memory
	Error Correction Type: None
	Maximum Capacity: 32 GB
	Error Information Handle: Not Provided
	Number Of Devices: 2

Handle 0x003C, DMI type 17, 92 bytes
Memory Device
	Array Handle: 0x003B
	Error Information Handle: Not Provided
	Total Width: 64 bits
	Data Width: 64 bits
	Size: 32 GB
	Form Factor: SODIMM
	Set: None
	Locator: Controller0-ChannelA-DIMM0
	Bank Locator: BANK 0
	Type: DDR4
	Type Detail: Synchronous
	Speed: 3200 MT/s
	Manufacturer: Kingston
	Serial Number: BF8F2D6C
	Asset Tag: 9876543210
	Part Number: KF3200C20S4/32GX    
	Rank: 2
	Configured Memory Speed: 3200 MT/s
	Minimum Voltage: 1.2 V
	Maximum Voltage: 1.2 V
	Configured Voltage: 1.2 V
	Memory Technology: DRAM
	Memory Operating Mode Capability: Volatile memory
	Firmware Version: Not Specified
	Module Manufacturer ID: Bank 2, Hex 0x98
	Module Product ID: Unknown
	Memory Subsystem Controller Manufacturer ID: Unknown
	Memory Subsystem Controller Product ID: Unknown
	Non-Volatile Size: None
	Volatile Size: 32 GB
	Cache Size: None
	Logical Size: None

Handle 0x003D, DMI type 17, 92 bytes
Memory Device
	Array Handle: 0x003B
	Error Information Handle: Not Provided
	Total Width: 64 bits
	Data Width: 64 bits
	Size: 32 GB
	Form Factor: SODIMM
	Set: None
	Locator: Controller1-ChannelA-DIMM0
	Bank Locator: BANK 0
	Type: DDR4
	Type Detail: Synchronous
	Speed: 3200 MT/s
	Manufacturer: Kingston
	Serial Number: E48F37DC
	Asset Tag: 9876543210
	Part Number: KF3200C20S4/32GX    
	Rank: 2
	Configured Memory Speed: 3200 MT/s
	Minimum Voltage: 1.2 V
	Maximum Voltage: 1.2 V
	Configured Voltage: 1.2 V
	Memory Technology: DRAM
	Memory Operating Mode Capability: Volatile memory
	Firmware Version: Not Specified
	Module Manufacturer ID: Bank 2, Hex 0x98
	Module Product ID: Unknown
	Memory Subsystem Controller Manufacturer ID: Unknown
	Memory Subsystem Controller Product ID: Unknown
	Non-Volatile Size: None
	Volatile Size: 32 GB
	Cache Size: None
	Logical Size: None

В процессе поиска информации, нашёл интересный тред на форуме MSI. Оказывается проблема с перезагрузкой обнаружилась не только у меня. Там я нашёл трогательную историю о том, как пользователь смог наладить стабильную работу, вставив планки памяти ADATA Premier (AD4S320032G22-SGN, именно SGN).

Пришлось обменять Kingston на ADATA. Процедура заняла у меня целый день, благо покупал я всё в оффлайн магазинах и сдать память проблем не составило, а вот чтобы купить новую - пришлось съездить в соседний город на склад, поскольку в розничном магазине мне пытались продать какое-то бывшее в употреблении недоразумение в коробке из под оригинальной памяти. Приехав наконец-то домой и воткнув планки в нотубук, стал гонять тесты. Система не перезагружалась, работала и от батареи, и от сети. Разница с Kingston оказалась лишь в таймингах (и цене) - новые были 22-22-22-52, скорость, напряжение, rank - идентичные. Память не такая производительная, однако с ней работа стала действительно стабильной.

# dmidecode 3.3
Getting SMBIOS data from sysfs.
SMBIOS 3.4.0 present.

Handle 0x003B, DMI type 16, 23 bytes
Physical Memory Array
	Location: System Board Or Motherboard
	Use: System Memory
	Error Correction Type: None
	Maximum Capacity: 32 GB
	Error Information Handle: Not Provided
	Number Of Devices: 2

Handle 0x003C, DMI type 17, 92 bytes
Memory Device
	Array Handle: 0x003B
	Error Information Handle: Not Provided
	Total Width: 64 bits
	Data Width: 64 bits
	Size: 32 GB
	Form Factor: SODIMM
	Set: None
	Locator: Controller0-ChannelA-DIMM0
	Bank Locator: BANK 0
	Type: DDR4
	Type Detail: Synchronous
	Speed: 3200 MT/s
	Manufacturer: A-DATA Technology
	Serial Number: F74F0000
	Asset Tag: 9876543210
	Part Number:                     
	Rank: 2
	Configured Memory Speed: 3200 MT/s
	Minimum Voltage: 1.2 V
	Maximum Voltage: 1.2 V
	Configured Voltage: 1.2 V
	Memory Technology: DRAM
	Memory Operating Mode Capability: Volatile memory
	Firmware Version: Not Specified
	Module Manufacturer ID: Bank 5, Hex 0xCB
	Module Product ID: Unknown
	Memory Subsystem Controller Manufacturer ID: Unknown
	Memory Subsystem Controller Product ID: Unknown
	Non-Volatile Size: None
	Volatile Size: 32 GB
	Cache Size: None
	Logical Size: None

Handle 0x003D, DMI type 17, 92 bytes
Memory Device
	Array Handle: 0x003B
	Error Information Handle: Not Provided
	Total Width: 64 bits
	Data Width: 64 bits
	Size: 32 GB
	Form Factor: SODIMM
	Set: None
	Locator: Controller1-ChannelA-DIMM0
	Bank Locator: BANK 0
	Type: DDR4
	Type Detail: Synchronous
	Speed: 3200 MT/s
	Manufacturer: A-DATA Technology
	Serial Number: 244D0000
	Asset Tag: 9876543210
	Part Number:                     
	Rank: 2
	Configured Memory Speed: 3200 MT/s
	Minimum Voltage: 1.2 V
	Maximum Voltage: 1.2 V
	Configured Voltage: 1.2 V
	Memory Technology: DRAM
	Memory Operating Mode Capability: Volatile memory
	Firmware Version: Not Specified
	Module Manufacturer ID: Bank 5, Hex 0xCB
	Module Product ID: Unknown
	Memory Subsystem Controller Manufacturer ID: Unknown
	Memory Subsystem Controller Product ID: Unknown
	Non-Volatile Size: None
	Volatile Size: 32 GB
	Cache Size: None
	Logical Size: None

Для наглядности - результаты тестов Basemark GPU. Хоть этот бенчмарк и расчитан на тестирование производительности графики, однако разница в 100 попугаев между ADATA и Kingston присутствет:

По субъективным ощущениям - c Kingston система гораздо более отзывчива, однако с ADATA охлаждение работает гораздо тише в простое.

Выводы сделаны следующие:

• MSI вводит пользователей в заблуждение своими маркетинговыми заявлениями
• MSI не предоставляет список совместимого оборудования
• MSI не заинтересован в помощи пользователям - по заявлению вендора, хоть проблема и есть, но проявляется у слишком малого количества людей и это не повод пилить апгрейды для BIOS

Следующим этапом буду менять диски и, подозреваю, с этим тоже могут возникнуть какие-то сложности.