Библиотека девопса | DevOps, SRE, Sysadmin

Почему используется Kube-apiserver? Kube-apiserver используется для настройки и проверки объектов API. Кроме того, он используется для того, чтобы пользователи могли взаимодействовать с кластером Kubernetes, где используется API сервера Kubernetes. Таким образом, это часть интерфейса плоскости управления, и именно этот интерфейс проверяет, является ли входящий запрос легитимным или нет. Kube-apiserver проверяет и предоставляет данные для объектов API и включает модули, службы и контроллеры репликации. Сервер API отправляет команды REST-операций и предоставляет самый передовой общий статус кластера, через который взаимодействуют все остальные компоненты.

🧑‍🎓🧑‍🎓 Self-Hosting a Container Registry Иногда вместо того, чтобы полагаться на провайдера, такого как AWS или GCP, вы можете захотеть разместить свои образы самостоятельно. Это позволяет сохранить инфраструктуру внутренней и уменьшить зависимость от внешних поставщиков. Автономный реестр работает на ваших серверах, что дает вам больше контроля над настройками реестра и размещением образов контейнеров. В то же время это связано с затратами на обслуживание и защиту реестра. Продолжение здесь #туториал

#memes

Claudie Платформа для управления multi-cloud и hybrid-cloud кластерами Kubernetes с поддержкой пулов нод различных облачных провайдеров и локальных центров обработки данных Типичные варианты использования 👉 Экономия средств 👉 Локализация данных и соответствие требованиям (например, GDPR). 👉 Управляемый Kubernetes для провайдеров, которые не предлагают подобные услуги 👉 Cloud bursting 👉 Интерконнект сервисов #софт

#дайджест перед выходными 🛟 Фильтры Ansible: превращаем сложное в простое — как легко и просто можно обрабатывать данные прямо в Ansible, используя его собственные мощные возможности 🛟 Azure DevOps с OpenShift — как интегрировать Azure DevOps с кластером OpenShift для создания и развертывания приложений на нем 🛟 От чего зависит, готова ли нода Kubernetes — что делать со статусом NotReady 🛟 pgbackweb — утилита для управления бэкапами PostgreSQL с графическим интерфейсом. 🛟 Inside PromQL: A closer look at the mechanics of a Prometheus query — как данные передаются от источника к конечному пункту назначения в API

😮 SQL: от Тетриса до ИИ — неожиданные возможности языка баз данных Долгое время SQL использовали лишь для запросов и изменения записей в базах данных — для полноценного программирования в привычном смысле слова он не подходил. Однако добавление рекурсивных общих табличных выражений (CTE) сделало SQL полным по Тьюрингу. Рекурсивные CTE состоят из двух частей: • Нерекурсивная часть (базовый случай) — создает начальные данные. • Рекурсивная часть — может выполняться много раз, каждый раз используя результат предыдущего шага. Благодаря CTE на SQL можно при желании реализовать любой алгоритм. Энтузиасты уже сделали: • Визуализацию множества Мандельброта с помощью ASCII-графики. • 3D-движок для рисования объемных фигур. • GPT на 500 строках SQL-кода. Подробная статья о реализации этого проекта опубликована здесь. • Трассировку лучей (это метод создания реалистичных изображений). На прошлой неделе коллекция крутых SQL-проектов пополнилась еще одной интересной разработкой — версией «Тетриса». Эта реализация демонстрирует несколько нестандартных SQL-техник, о которых стоит знать, даже если вы используете SQL только по прямому назначению: • Игровой цикл. В основе игры – рекурсивное общее табличное выражение (CTE). Оно создает бесконечный цикл, который инициализирует состояние игры, обновляет его на основе ввода пользователя и отрисовывает игру. Цикл продолжается, пока игра не закончится. • Вывод игры. Поскольку SQL-запрос обычно возвращает результат только после завершения, для отображения игры в реальном времени используется команда RAISE NOTICE. Эта команда выводит информацию в стандартный вывод, позволяя отображать игровое поле и другую информацию в процессе игры. • Пользовательский ввод. Обработка пользовательского ввода реализована через отдельную таблицу в базе данных. Эта таблица служит коммуникационной шиной между игрой и пользователем. Пользователь добавляет команды в эту таблицу, а игра их считывает. • Решение проблемы изоляции данных. Чтобы игра могла видеть новые команды, добавленные в таблицу ввода во время выполнения запроса, используется расширение dblink. Оно позволяет создавать новое подключение к базе данных с новым снимком данных, что дает возможность считывать самые последние команды пользователя. • Предотвращение кэширования. Чтобы PostgreSQL не кэшировал результаты запроса к таблице ввода, к запросу добавляется уникальный идентификатор итерации. Это заставляет базу данных выполнять запрос заново на каждой итерации игрового цикла. Для управления состоянием игры и обработки игровых событий используются подзапросы и агрегатные функции. • Подзапросы позволяют вычислить новое состояние игры после каждого хода, включая позицию фигуры, состояние поля, счет и т. д. К примеру, рекурсивный подзапрос используется для вычисления максимального количества линий, на которые может упасть текущая фигура. • Агрегации применяются для подсчета очищенных линий, выбора фигуры с наименьшим рангом, обновления счета и уровня игры. Например, BOOL_OR() применяется для определения, есть ли хотя бы одно столкновение между фигурой и занятыми клетками на поле. 🔗 Подробнее читайте в статье 🔗 Зеркало

Linux Dash Позволяет мониторить: 👉 Среднюю загрузку системы (load average) 👉 Оперативную память (Всего/Использовано/Свободно) 👉 Использование дисков (свободное место) 👉 Список пользователей 👉 Список ПО и пути до бинарных файлов 👉 Список интерфейсов с их IP-адресами 👉 Текущую скорость интерфейса (Входящая/Исходящая) 👉 Список подключенных пользователей 👉 Список процессов #софт

❗Вакансии «Библиотеки программиста» — ждем вас в команде! Мы постоянно растем и развиваемся, поэтому создали отдельную страницу, на которой будут размещены наши актуальные вакансии. Сейчас мы ищем: 👉контент-менеджеров для ведения телеграм-каналов 👉Переводчик и автор оригинальных статей Подробности тут Мы предлагаем частичную занятость и полностью удаленный формат работы — можно совмещать с основной и находиться в любом месте🌴 Ждем ваших откликов 👾

Сегодня специалисты DevOps — одни из самых востребованных на рынке. По данным hh.ru, на 2000 вакансий приходится 1900 соискателей. Если вы хотите работать с методологией DevOps — попробуйте курс Практикума. После курса вы: — начнёте применять DevOps в работе, — разберётесь в Docker и Kubernetes, — изучите современные инструменты, — почувствуете себя опытным SRE. Поможем сделать релизы более быстрыми и безопасными, инфраструктуру — стабильной, а взаимодействие команд — более эффективным и слаженным. А дальше — получить новый грейд или ответственную роль в команде. Программа рассчитана на 6 месяцев, учёба займет от 15 часов в неделю. В финале — итоговый проект для портфолио, в котором нужно подготовить инфраструктуру и настроить конвейер деплоя. Осваивать принципы DevOps начнём уже в этом месяце. Приходите учиться!

Как Yandex Cloud делает Managed Service for Kubernetes? В этом выпуске «Как мы делаем Yandex Cloud» обсуждаем работу над Managed Service for Kubernetes. Специальный гость — Александр Хаустов, руководитель подразделения Kubernetes в Yandex Cloud. О чём поговорили? 👉 Как обеспечить стабильность инфраструктуры K8s, где более 4 тысяч кластеров и несколько сотен тысяч ядер? 👉 Как планировать изменения, когда поступает множество запросов от внешних и внутренних пользователей? 👉 Какие компетенции должны быть у разработчика в команде облачного Kubernetes?

🚀 Новые возможности React 19: конец эры повторных рендерингов Новый компилятор React 19 обещает существенное повышение производительности, что станет настоящим прорывом для разработчиков. Но это лишь верхушка айсберга. В этой статье мы не только разберемся, как работает компилятор, но и погрузимся в мир других новейших возможностей React 19. 🔗 Читать статью 🔗 Зеркало

#memes

🤔🤔 Как снизить расходы на мониторинг: более разумный подход к данным Мониторинг может стать дорогостоящим из-за огромных объемов данных, которые необходимо обрабатывать. В этой статье вы узнаете о лучших способах хранения и обработки метрик мониторинга для снижения расходов и о том, как VictoriaMetrics может в этом помочь. Подробности тут #туториал

🪶 Как следовать принципу DRY при настройке Apache APISIX DRY — один из самых известных принципов разработки ПО: он помогает избежать ненужного повторения фрагментов кода, которые выполняют одни и те же действия. DRY также стоит применять при настройке конфигурации сложных систем, поскольку этот принцип: ☑️ Делает конфигурацию более компактной и легкой для понимания. ☑️ Упрощает поддержку — когда нужно внести изменения, вы делаете это только в одном месте. ☑️ Повышает читаемость — конфигурация становится более структурированной и логичной, что облегчает ее понимание. ☑️ Улучшает масштабируемость — при усложнении конфигурации принципы DRY помогают сохранять ее управляемой и расширяемой. ☑️ Сокращает время на настройку — используя переиспользуемые компоненты, можно быстрее создавать новые конфигурации или модифицировать существующие. В качестве примера в статье рассматриваем, как применять DRY при настройке конфигурации API-шлюза Apache APISIX. 🔗 Читать статью 🔗 Зеркало

Очередной #дайджест для DevOps-ов ➕ Улучшенная аналитика предупреждений в Grafana — в Grafana 11.2 появился новый интерфейс для просмотра истории состояний всех оповещений в системе ➕ GlitchTip вместо Sentry — как бесплатно настроить мониторинг ошибок ➕ Может ли пода Kubernetes быть подключена к нескольким сетям — использование Multus CNI и оператора состояния NM для добавления дополнительных сетей к модулям и виртуалкам в OpenShift Virtualization ➕ Kubectl Port-forward Flow — все, в диаграмму Mermaid, начиная с этапа аутентификации и заканчивая отправкой запроса через localhost, который отправляется через SPDY ➕ k8gb — GSLB-решение с открытым исходным кодом для Cloud Native

#memes

📊🚀 Почему все говорят о Kafka? Хочешь узнать, как обрабатывать миллионы событий в секунду и почему такие гиганты, как Netflix и Uber, без ума от Kafka? Давай разберемся, как этот инструмент может превратить поток данных в золотую жилу для твоего проекта. Читать статью

🧑‍🎓🧑‍🎓Спецификации Pod Level Resource Интересный KEP про Pod-level resource limits and requests для всех подов, без необходимости суммировать ресурсы контейнеров при шедулинге. Полезно, если нет желания рассчитывать ресурсы для каждого контейнера отдельно. Подробнее тут