Системное администрирование *

Для умных дядь в статье ничего интересного, это статья про обычный туннель. Оно для самых маленьких, но отчаянно нуждающихся. Никаких wg-quick'ов тут, впрочем, не будет. :)

Когда я стал упорядочивать «знания» ввиде этой статейки, и понял, что в итоге получилось, то заметил, что информации по данной теме, оказывается, предостаточно (даже на Хабре), жаль, что осознал я это только уже когда всё сделал и понял, что мне, собственно, нужно было гуглить. В общем, пусть останется, дабы кто‑то, кто гуглит так же неправильно, мог случайно на эту статью наткнуться и что‑то полезное для себя почерпнуть. В процессе реализации я на каждом шаге споткнулся по нескольку раз, поэтому решил прокомментировать тут всё максимально подробно.

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

Выход Windows Server 2025 запланирован на четвертый квартал 2024 года. Протестировать ее уже можно в облаке mClouds или скачав ISO-файл в Центре оценки Microsoft. А пока мы ждем выхода на рынок финального публичного релиза, давайте вместе разбираться, какие значимые улучшения обещают пользователям.

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

Меня зовут Кирилл Борисов, я в IT около 13 лет. Создавал DevOps-процессы и инфраструктуру в больших проектах, руководил группой сопровождения. Сейчас SRE-инженер в VK, в проекте VK Реклама.

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

В очередной рабочий день поступила задача обновить Gitlab. Задача в общем-то не сложная, ни смотря на то, что там он установлен в докере из многим знакомого образа от sameersbn, что впоследствии было переделано на omnibus (что бы это не значило), т.к. по моему опыту omnibus версия (установка на чистый линукс) гораздо проще и предсказуемей в эксплуатации. Впрочем статья совсем не об этом.

Но как можно понять из наличия этой статьи, что-то пошло не так...

Всем привет! Меня зовут Дмитрий Мамонтов, я DevOps-инженер с опытом работы более пяти лет, а также наставник на курсе «DevOps для эксплуатации и разработки» и один из авторов курса «Эксплуатация и разработка в Kubernetes» в Яндекс Практикуме.

Представим, что у нас есть приложение, которое шлёт свои метрики в Yandex Monitoring, и стоит задача: масштабировать это приложение с помощью HPA в кластере Kubernetes в зависимости от метрики.

Есть два популярных варианта решения этой задачи:

В конце августа разработчики проекта OpenTofu приняли решение ограничить доступ к своему реестру для российских IP-адресов и удалить из GitHub-репозитория провайдеров российских облачных сервисов, таких как Yandex Cloud, Cloud.ru, Rustack Cloud Platform, VK Cloud и других.

​​Команда OpenTofu объяснила свои действия необходимостью соблюдать международные санкции против России, а технический лид проекта предоставил ссылки на политику безопасности и сводку заседания Технического руководящего комитета (TSC) от 20 августа 2024 года, на котором и было принято решение.

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

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

Как отмечается в сводках заседаний Технического руководящего комитета (TSC) от 15 октября 2024 года и Технического руководящего комитета (TSC) от 23 октября 2024 года, Технический лидер проекта готов ответить на вопросы касательно политики для существующих issues и pull request'ов на GitHub, включая обсуждения в официальном Slack проекта. Тем не менее, в настоящее время команда не планирует принимать какие-либо действия по ранее предпринятым шагам, например, возвращать ранее удаленные провайдеры в реестр.

Когда был создан SMTP, он работал, передавая данный в открытом виде, поскольку тогда мы ещё не разработали решение для безопасной передачи данных, то, что мы называем сейчас «безопасность транспортного уровня» (transport layer security, TLS). Когда TLS наконец-то был готов, нам потребовалось придумать способ поэтапного внедрения TLS. Был создан STARTTLS, предлагающий шифрование «по возможности». По сути, почтовый сервер отправителя мог спросить почтовый сервер получателя: «Поддерживашь ли ты шифрование?», и, если ответ был положительным, устанавливалось TLS-соединение с использованием сертификата, предоставленного сервером. Если нет, использовалось SMTP-соединение с передачей данных в открытом виде.

Любой, кто знаком с темой сетевой безопасности, увидит здесь проблему. Активно действующий злоумышленник, осуществляющий атаку «атакующий посередине» (attacker-in-the-middle, AitM), может подставить свой собственный ответ, указывая, что шифрование не поддерживается, и обманом заставить отправителя использовать открытый текст, что позволит злоумышленнику перехватывать сообщения. Это классическая атака понижения версии.

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

Но буквально на днях вышел PostgreSQL 17 и может там что-то изменилось? И да, и нет. Та самая мана небесная в виде pg_awesome_backup_tool так и не появилась, однако в релиз попал механизм walsummarizer, который обещает нативно отслеживать изменения в файлах баз данных, что позволит делать инкрементальные бекапы нативно и без лишних приседаний.

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

Привет, Хабр! Рассказываем об одном из вариантов применения Open Source инструментов Software Supply Chain Security. Коллеги по цеху попросили выложить небольшой его обзор сюда:)

Эта статья является краткой текстовой версией моего доклада с конференции PHD2. Если тема вас заинтересует, можете посмотреть полное выступление по ссылкам: [RuTube] / [YouTube].

В этой статье мы рассмотрим процесс создания кастомного scheduler'а для Kubernetes, ориентируясь на Kubernetes Scheduling Framework.

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

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

Меня всё чаще в комментариях и ПМ спрашивают, как установить так рекомендуемую мной Windows IoT Enterprise LTSC поверх существующей инсталляции (будь то Windows 7, Windows 10 или Windows 11) с сохранением всех приложений, данных и настроек. Я уже писал подробную статью об установке ОС как апгрейда – Как правильно сделать апгрейд ОС — установить Windows 11 поверх существующей с сохранением приложений и настроек / Хабр (habr.com), где рассказывал о разных сложностях, встречающихся на пути установки ОС – новых требованиях к железу, разных языках и, конечно, о несовместимости изданий, не позволяющих обновиться с сохранением приложений и данных пользователя. Но методы редактирования реестра для многих читателей оказались сложными.

И я вообще не затронул тогда Windows Server – как обновиться с Server Core до Server с рабочим столом, как обновить AzureStackHCI до Server Datacenter Azure Edition, и как обновляться с Annual Cycle изданий Windows Server AC (например, 23H2) до LTSC (например, 24H2) и наоборот с LTSC до AC (в 2025 году нас ждёт только ServerDatacenterACorCore).

За пару месяцев с прошлой заметки на форумах MyDigitalLife было выпущено два новых проекта, позволяющих очень упростить процедуру апгрейда, и ниже я расскажу как раз об этом. Мы сможем подготовить образ Windows 11 24H2 IoT Enterprise LTSC так, что с любого издания Windows 7/8/8.1/10 вы сможете обновиться до него без потери данных. Ну и научимся обновлять Windows Server.

Для примеров ниже я буду рассказывать о трёх сценариях:

Друзья, сегодня мы погрузимся в мир Pydantic 2 – мощного инструмента для валидации данных в Python! Узнаем, почему эта библиотека стала незаменимой в 30% Python-проектов и как она упрощает работу с данными. От базовых концепций до продвинутых техник – мы охватим всё, что нужно знать современному Python-разработчику. Готовьтесь к практике – ведь только так можно по-настоящему освоить Pydantic и сделать ваш код более надёжным и эффективным.

Делюсь лайфхаком по уменьшению размеров Docker-образов. Как-то нам попалась на поддержку и развитие CRM-система, написанная на Ruby...

Обновили Ruby-пакеты и под них код, написали Dockerfile. Первая сборка была удручающей: образ в 2Гб. Это нормальный размер, если ты собираешь образ с Torch и другой ML-штуковиной, но CRM - нет. В результате дальнейших действий, удалось сократить размер образа до 200Мб.

Привет! Я Ильдар Бигашев, Product Owner Ринго MDM, более 10 лет работаю с корпоративными технологиями Apple: прошел путь от сотрудника Service Desk до руководителя системных интеграций.

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

Как только на WWDC 2024 состоялся анонс новой операционки от Apple, мы, со свойственным системным администраторам вожделением, стали ждать выхода первой Developer Beta, чтобы как можно скорее установить ее на свои устройства, протестировать новые фичи и репортить фидбэк в Apple.

Как это часто бывает, не вся информация по новым возможностям системы была доступна в KB Apple или на Apple Developer. Со многими вещами пришлось разбираться самостоятельно. Немало информации удалось получить из тематических блогов и таких сообществ, как Mac Admins в Slack и MacSysAdmin Group в Telegram.

Как технический менеджер в Яндексе я отвечаю за эксплуатацию больших кластеров, через которые мы передаём данные, — для этого мы используем YDB Topics, собственный аналог Apache Kafka, о котором я уже рассказывал.

Но если посмотреть не только на нас, но и на примеры других крупных систем, то становится понятно, почему энтерпрайзу сложно брать готовые опенсорс‑решения. Стоит лишь представить, что бывает, если команда с большими масштабами начинает использовать Apache Kafka.

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

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

В этот раз мы дополнительно сравним результаты со значениями проведенного анализа в 2022 и 2023 годах.

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