Telegram Web
🖥 Опубликован выпуск основной ветки nginx 1.27.2, в рамках которой продолжается развитие новых возможностей. В параллельно поддерживаемой стабильной ветке 1.26.x вносятся только изменения, связанные с устранением серьёзных ошибок и уязвимостей. В дальнейшем на базе основной ветки 1.27.x будет сформирована стабильная ветка 1.28

🔍 Среди изменений:

🌟 При запуске и обновлении конфигурации реализовано кэширование SSL-сертификатов, ключей и CRL (Certificate Revocation List)

🌟 В модуль stream добавлена поддержка проверки отзыва сертификатов клиентов, используя протокол OCSP (Online Certificate Status Protocol)

🌟 В модуле stream реализована поддержка техники проверки отзыва сертификатов OCSP Stapling, суть которой в том, что при согласовании TLS-соединения заверенный удостоверяющим центром ответ OCSP передаётся сервером, обслуживающим сайт, без необходимости прямого обращения к удостоверяющему центру)

🌟 В модуль ngx_http_proxy_module добавлена директива "proxy_pass_trailers", разрешающая передачу полей заголовков в конце ответа от проксируемого сервера к клиенту

🌟 В директиве "ssl_client_certificate" обеспечена поддержка сертификатов с дополнительной информацией

🌟 Для проверки клиентских SSL-сертификатов директива "ssl_client_certificate" теперь не является обязательной

🔗 Подробнее: *клик*

@devopsitsec
Please open Telegram to view this post
VIEW IN TELEGRAM
🔍 Нотация Big O 101: Секрет написания эффективных алгоритмов

О-большое (Big O) – это специальная нотация, используемая для описания асимптотической сложности; то есть, скорости роста времени выполнения алгоритма с увеличением размера входных данных.

Это нужно, чтобы понимать, насколько быстро или медленно работают алгоритмы. В О-большом нет коэффициентов, минут, секунд и так далее. Об этом будет наглядно показано в примере про логарифмическую сложность O(log n).

@devopsitsec
🖥 Полезный репозиторий на Github, в котором собраны вопросы с собеседований по всевозможным IT сферам!

🔍 Что есть?

🌟 Фронтенд
🌟 Бэкенд
🌟 DevOps
🌟 Android - разработка
🌟 Fullstack
🔥 И многое другое!

🔗 Смотрим здесь: *клик*

@devopsitsec
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥 Git 2.47 вышел: что нового?

💡 В новой версии Git 2.47 разработчики добавили ряд полезных функций и улучшений:

🌟 Инкрементные многопакетные индексы (Incremental MIDX):

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


🌟 Улучшенная команда for-each-ref:

Новый атом %(is-base:atom) помогает быстро находить базовые ветки для любого коммита, минимизируя количество уникальных коммитов в истории первого родителя.

🔗 Подробный список изменений: *клик*

@devopsitsec
Please open Telegram to view this post
VIEW IN TELEGRAM
🖥 Karpenter — это автомасштабирующий кластер, который автоматически запускает только необходимые вычислительные ресурсы для обработки модулей вашего кластера. Он разработан, чтобы позволить вам в полной мере использовать преимущества облака с помощью быстрого и простого предоставления вычислительных ресурсов!

🔗 Ссылка: *клик*
▪️Github

@devopsitsec
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Golang
👣 helm-chartsnap предоставляет инструмент для Snapshot тестов (snapshot testing) Helm-чартов.


💡 Snapshot тесты — это тесты, которые делают скриншот экрана (эталонный скриншот) и сравнивают с актуальным скриншотом, который делается во время прогона тестов.

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

Чарты – это пакеты, которые могут включать в себя все для запуска приложения в Kubernetes, от deployments до services.

helm-chartsnap помогает тестировать Kubernetes Helm-чарты, автоматически сравнивая текущее состояние с предыдущими снимками, что позволяет выявлять изменения и предотвращать нежелательные конфигурации

🔐 Лицензия: MIT

▪️Github

@golang_google
Please open Telegram to view this post
VIEW IN TELEGRAM
🖥 Ubuntu или Kubuntu: в чем разница?

🌟 Ubuntu — самый популярный дистрибутив Linux для пользователей настольных компьютеров. Он включает в себя настраиваемый рабочий стол GNOME, обеспечивающий бесперебойный пользовательский опыт

🌟 С другой стороны, Kubuntu — это одна из версий Ubuntu, включающая рабочий стол KDE Plasma .

🌟 По своей сути оба дистрибутива схожи, а главное отличие заключается в среде рабочего стола .

В чем именно различия? Один из них лучше другого? Какой дистрибутив идеально подходит для вашего варианта использования? Узнаете в этой статье!

🔗 Ссылка: *клик*

@devopsitsec
Please open Telegram to view this post
VIEW IN TELEGRAM
🖥 oci-registry — это реализация спецификации OCI Registry, предназначенная для работы в качестве pull-through кэша (зеркала) для контейнерных регистров. Поддерживает два хранилища данных: локальную файловую систему и S3. Модель потребляет меньше ресурсов по сравнению с аналогами, но пока не реализует push-запросы и аутентификацию. Используется для создания зеркал публичных или приватных реестров, но требует внешних решений для шифрования TLS

🔐 Лицензия: MIT

▪️Github

@devopsitsec
Please open Telegram to view this post
VIEW IN TELEGRAM
🖥 Docker и микросервисы для начинающих: полный курс с практическими примерами использования Docker Compose!

🕞 Продолжительность: 1:35:01

🔗 Ссылка: *клик*

@devopsitsec
Please open Telegram to view this post
VIEW IN TELEGRAM
🖥 kubernetes-the-hard-way-aws — пошаговое руководство по настройке кластера Kubernetes вручную на AWS. Оно предназначено для тех, кто хочет глубже понять внутреннюю архитектуру Kubernetes без использования автоматизированных инструментов вроде AWS EKS или Kubernetes Operations (kops)

🌟 Процесс включает настройку сетей, машин и всех компонентов кластера, включая контрольные узлы и рабочие ноды

▪️Github

@devopsitsec
Please open Telegram to view this post
VIEW IN TELEGRAM
Как Kubernetes определяет готовность узла: детальный разбор

💡 В Kubernetes узлы играют ключевую роль, предоставляя ресурсы для запуска контейнеров. Чтобы гарантировать, что узел может эффективно выполнять свои функции, Kubernetes использует статус "Node Ready", который указывает, что узел готов к обработке рабочих нагрузок. Однако этот статус не статичен и может изменяться в зависимости от состояния различных компонентов узла.

Как работает определение готовности узла?

❗️ Kubernetes использует компонент kubelet для управления состоянием узла. Kubelet — это агент, который работает на каждом узле кластера и отвечает за запуск и мониторинг контейнеров через контейнерный runtime (например, Docker или containerd). Этот агент регулярно отправляет обновления в контроллер управления жизненным циклом узлов (node lifecycle controller), который определяет состояние узла и решает, может ли узел принимать новые задачи.

💡 Чтобы узел считался "готовым", kubelet проверяет состояние различных критичных компонентов, включая:
🌟 Контейнерный runtime. Он отвечает за выполнение контейнеров, и если он не функционирует корректно, узел будет считаться неготовым.
🌟 Сетевые компоненты. Узел должен иметь рабочее сетевое соединение, чтобы взаимодействовать с другими узлами кластера и внешними ресурсами.
🌟 Физическое состояние узла. Например, узел может стать неготовым, если заканчиваются ресурсы (память, процессор и т.д.).

🔍 Проверка состояния узла

💡 Kubelet периодически отправляет Heartbeat сигналы, которые содержат данные о состоянии узла. Если контроллер не получает такие сигналы в течение определённого времени, он считает, что узел "упал", и изменяет его статус на Unknown (неизвестно), чтобы предотвратить отправку задач на этот узел.

Если хотя бы один из критичных компонентов перестает работать, статус узла изменяется на NotReady (не готов). В такой ситуации узел продолжает функционировать, но новые задачи на него не отправляются.

🔍 Метки состояния узла

Каждый узел в Kubernetes имеет набор меток (conditions), которые описывают его текущее состояние. Например, для статуса "Node Ready" используются следующие метки:
🌟 Ready: True, False или Unknown. Определяет, может ли узел принимать новые задачи.
🌟 MemoryPressure: указывает, если на узле нехватка оперативной памяти.
🌟 DiskPressure: показывает, есть ли проблемы с дисковым пространством.
🌟 PIDPressure: информирует о том, что узел исчерпал лимиты процессов.

Эти метки позволяют Kubernetes принимать автоматические решения, например, мигрировать рабочие нагрузки с узла, который испытывает проблемы

Как отслеживать готовность узлов?

Чтобы узнать статус узлов в кластере, можно использовать команду:

kubectl get nodes


💡 Она покажет список всех узлов и их состояние. Узлы со статусом "NotReady" могут временно не принимать задачи, что может быть вызвано, например, недостатком ресурсов или проблемами с контейнерным runtime.

Для более детальной информации можно использовать:

kubectl describe node <node-name>


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

@devopsitsec
Please open Telegram to view this post
VIEW IN TELEGRAM
🖥 Курс по сертификации младшего администратора AWS SysOps! (2024)

🌟 Огромный курс на 68 (!) часов, который идеально подходит для младших инженеров DevOps или системных администраторов, которые хотят поддерживать и обслуживать существующую облачную инфраструктуру!

🕞 Продолжительность: 2:20:24:00

🔗 Ссылка: *клик*

@devopsitsec
Please open Telegram to view this post
VIEW IN TELEGRAM
🖥 kobs — это платформа для наблюдаемости за Kubernetes. Она помогает разработчикам и администраторам управлять своими Kubernetes-кластерами и отслеживать метрики, логи и события в рамках единого интерфейса. Платформа поддерживает интеграцию с различными инструментами для мониторинга и логирования, такими как Prometheus, Jaeger и Grafana.

🔍 Основные функции:

🌟 Мониторинг и логирование — сбор данных из различных источников для анализа и визуализации

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

🌟 Kubernetes API — взаимодействие с Kubernetes API для управления ресурсами и сбором метрик

💡 Проект написан на Go для бэкенда и TypeScript/React для фронтенда, что позволяет легко расширять и адаптировать его под нужды компании

🔐 Лицензия: MIT

▪️Github

@devopsitsec
Please open Telegram to view this post
VIEW IN TELEGRAM
This media is not supported in your browser
VIEW IN TELEGRAM
🖥 Полезная шпаргалка по консольным командам Git

В Git есть много команд, и если ты часто их забываешь, эта шпаргалка специально для тебя.

В этом репозитории можно быстро ознакомиться с основными командами и концепциями, а затем одним лёгким нажатием на Ctrl+C скопировать их.

Дополнительный плюс — всё написано на русском. Так что сохраняем!

🔗 Шпаргалка

#git #шпаргалка

@devopsitsec
Please open Telegram to view this post
VIEW IN TELEGRAM
👩‍💻 Эта полезная для новичков статья описывает основы работы с сетями в Docker. Она объясняет типы сетей, такие как bridge, host, none, и overlay, которые Docker использует для подключения контейнеров

🌟 В статье также приведены примеры настройки и использования этих сетевых типов для эффективного взаимодействия между контейнерами. Рассматриваются сценарии применения каждого типа сети, а также полезные команды для управления сетями Docker

🔗 Ссылка: *клик*

@devopsitsec
Please open Telegram to view this post
VIEW IN TELEGRAM
💻 Разрешения Kubernetes RBAC, о которых вы могли не знать, но должны знать!

🌟 K8s RBAC предлагает три разрешения со скрытыми полномочиями, которые могут быть использованы злонамеренно. Узнайте, как контролировать их использование!

🔗 Читать: *клик*

@devopsitsec
Please open Telegram to view this post
VIEW IN TELEGRAM
В чем разница между балансировщиком нагрузки и API-шлюзом?

1️⃣ NLB (Network Load Balancer) обычно разворачивается перед API-шлюзом и отвечает за маршрутизацию трафика на основе IP-адресов. Он не анализирует HTTP-запросы

2️⃣ ALB (Application Load Balancer) маршрутизирует запросы на основе HTTP-заголовков или URL, предоставляя более сложные правила маршрутизации. Выбор балансировщика нагрузки зависит от требований к маршрутизации. Для простых сервисов с меньшим масштабом достаточно одного балансировщика

3️⃣ API-шлюз работает на уровне приложения и решает задачи, отличные от тех, которые выполняет балансировщик нагрузки

💡 На схеме выше показаны подробности. Чаще всего они используются в комбинации для обеспечения масштабируемой и безопасной архитектуры современных веб-приложений.

🌟 Вариант A: ALB используется для распределения запросов между различными сервисами. Поскольку сервисы сами реализуют ограничение скорости, аутентификацию и т.д., такой подход более гибкий, но требует больше работы на уровне сервиса

🌟 Вариант B: API-шлюз берёт на себя задачи по аутентификации, ограничению скорости, кэшированию и другим функциям, что снижает нагрузку на уровне сервисов. Однако этот вариант менее гибкий по сравнению с использованием ALB

@devopsitsec
Please open Telegram to view this post
VIEW IN TELEGRAM
💻 Kubernetes для современной инженерии данных!

🌟 В этом видео вы подробно окунетесь в мир Kubernetes — мощного инструмента для управления контейнеризированными приложениями, а также рассмотрите его применение в области инжиниринга данных!

🕞 Продолжительность: 1:25:17

🔗 Ссылка: *клик*

@devopsitsec
Please open Telegram to view this post
VIEW IN TELEGRAM
2025/07/07 15:27:07
Back to Top
HTML Embed Code: