⭐️ Вышел FreeBSD 15.0-ALPHA1

Команда FreeBSD представила первую альфа-версию 15.0-RELEASE. Образы доступны в различных форматах: ISO, memstick, QCOW2, VHD, VMDK, а также OCI-контейнеры.

➡️ Официальный анонс

🐸Библиотека devops'a

#свежак

🚀 Как вы стали девопсом

Для многих путь в DevOps — это не линейный процесс, а целое путешествие через различные роли и технологии. Кто-то пришёл из системного администратора, кто-то — из разработки, а кто-то стал девопсом после нескольких лет работы в ИТ-сфере.

Какие шаги стали решающими на вашем пути

Были ли важные курсы или сертификаты, которые помогли вам перейти в эту роль?

Какую роль сыграли практические проекты и опыт работы с CI/CD, контейнерами или облачными сервисами?

Какие сложности возникли при переходе, и как вы их преодолели?

💬 Давайте обсудим! Поделитесь своей историей в комментариях 👇

🐸Библиотека devops'a

#междусобойчик

👀 Домашний докер

Наткнулись на видео, где показывается интересный подход к организации Docker контейнеров в домашней лаборатории. Вместо использования решений вроде Kubernetes, в видео предлагается настройка на виртуальной машине с Debian, с привязкой томов.

А ещё в видео демонстрируется использование нескольких полезных Docker контейнеров, таких как Fresh RSS для удобного чтения новостей, Jellyfin для медиастриминга и Netbird для создания безопасных сетевых соединений.

➡️ Смотреть видео

🐸Библиотека devops'a

#буст

🔄 Жизненный цикл пода в Kubernetes

Жизненный цикл пода в Kubernetes — это цепочка процессов, от создания манифеста до завершения работы контейнеров. Сейчас разберем, как происходит запуск, мониторинг и завершение подов в Kubernetes.

1. Отправка манифеста пода и сохранение в etcd

Первым шагом при создании пода является отправка его манифеста в API-сервер Kubernetes. Этот запрос проверяется на корректность, и после успешной проверки информация о поде сохраняется в распределённом хранилище etcd, которое является источником правды для всего кластера.

2. Выбор ноды для пода планировщиком

После того как манифест пода успешно сохранен, наступает этап его размещения. планировщик Kubernetes принимает решение о том, на какую ноду будет размещен под.

Этот процесс основан на нескольких критериях:

• количество доступных CPU и памяти.

• правила, которые могут ограничивать или рекомендовать размещение подов на определённых нодах.

• метки или предпочтения, которые могут влиять на выбор ноды.

3. Подготовка пода на выбранной ноде

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

4. Запуск контейнеров и мониторинг их состояния

Как только все подготовительные работы завершены, контейнеры начинают переходить в состояние Running. На этом этапе Kubernetes использует health probes для мониторинга состояния контейнеров.

5. Мониторинг фаз пода

Kubernetes отслеживает состояние пода на высокоуровневом уровне. Изначально под находится в статусе Pending, затем, когда контейнеры начинают свою работу, он переходит в фазу Running.

После завершения работы под может попасть в одну из следующих фаз:

• Succeeded — если контейнеры завершили свою работу без ошибок.

• Failed — если контейнеры завершили работу с ошибками.

• Unknown — если состояние пода не удается определить по каким-либо причинам.

6. Завершение работы пода и очистка ресурсов

Когда контейнеры в поде завершили свою работу, Kubernetes посылает SIGTERM сигнал для корректного завершения их работы. Если контейнеры не успевают завершиться в отведённое время, Kubernetes отправляет SIGKILL, чтобы принудительно их остановить.

🐸Библиотека devops'a

#буст

⚙️10 стратегий снижения рисков в гибридных облаках

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

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

➡️ Про стратегии минимизации рисков в статье

🐸Библиотека devops'a

#буст

📰 Недельный дайджест

Собрали для вас материалы прошедшей недели.

— AWS CLI v2 теперь доступен для macOS

С версии 2.30.0 AWS CLI v2 предоставляет универсальные бинарные установщики для macOS, которые работают нативно как на процессорах Apple Silicon, так и на Intel.

— Динамическое обновление доступных слотов в k8s

В Kubernetes v1.34 поддержка динамического обновления количества доступных слотов для CSI-драйверов перешла в стадию Beta. Теперь драйверы могут периодически обновлять информацию о количестве доступных слотов для подключения томов.

— Вышел KDE Linux Alpha

— Unit-лид и Technical Owner

— FreeBSD 15.0-ALPHA1

🐸Библиотека devops'a

🐳 Шпаргалка по сетям Docker

Docker изолирует контейнеры не только по процессам и файловой системе, но и по сети. От этого зависит, смогут ли контейнеры общаться между собой, будут ли они доступны извне и насколько безопасно это взаимодействие.

Основные типы сетей

• Bridge — сеть по умолчанию.

Контейнеры получают внутренний IP и могут общаться друг с другом. Для связки нескольких сервисов в одной среде лучше создавать свои пользовательские сети (docker network create). Тогда контейнеры будут доступны по имени, например ping db.

• Host — общая сеть с хостом.

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

• None — полная изоляция.

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

• Overlay — сеть для кластера.

Объединяет несколько Docker-хостов. Используется в Swarm и Kubernetes. Контейнеры на разных серверах работают так, будто они рядом.

• Macvlan — контейнер как полноценный участник LAN.

Контейнер получает MAC-адрес и «выглядит» в локальной сети как отдельное устройство. Это удобно, если требуется доступ из реальной сети напрямую, например для IoT или legacy-приложений.

Полезные команды

Список сетей:

docker network ls

Подробная информация о сети:

docker network inspect bridge

Создать сеть:

docker network create mynet

Удалить сеть:

docker network rm mynet

Подключить контейнер к сети:

docker network connect mynet app1

Отключить контейнер от сети:

docker network disconnect mynet app1

🐸Библиотека devops'a

#буст

MTC Engineer Hack — хакатон на стыке инженерии и ИТ от МТС. Реши технический кейс онлайн и получи приглашение в финал, где сможешь поработать на реальном оборудовании МТС. 12 победителей разделят призовой фонд в 500 000 рублей.

📎 Зарегистрироваться: ссылка
🎯 Для кого: студенты и молодые инженеры в областях аппаратной разработки, DevOps, радиоинженерии, сетевых технологий.
💻 Формат: онлайн-тур + офлайн-финал в Москве
👤 Участие: индивидуальное

Приглашаем всех, кто интересуется телеком-отраслью, хочет прокачать навыки в инженерии и попробовать себя в задачах МТС. Будет отлично, если ты владеешь одним из навыков:
→ разбираешься в сотовых сетях и оборудовании базовых станций;
→ умеешь работать с данными и статистикой;
→ знаком с LTE/NR и схемотехникой;
→ интересуешься цифровой обработкой сигналов;
→ понимаешь маршрутизацию и пишешь скрипты для сетевого оборудования.

C 3 по 5 октября пройдёт онлайн-этап: участники готовят кейс по своему профилю. 11 октября — встреча финалистов на площадке и работа с настоящим оборудованием МТС, где эксперты компании помогут разобраться в деталях и дадут советы по доработке решений.

Что тебя ждёт:
🔺 Задачи, близкие к реальной работе инженеров МТС: от проектирования до оптимизации сетей.
🔺 Возможность познакомиться с экспертами компании и показать им свои решения.
🔺 Практика, которая позволит почувствовать себя частью технологической команды МТС.
🔺 Офлайн-финал в Москве: живое общение и защита проектов. Билеты и проживание оплатят организаторы.

Регистрация открыта до 1 октября включительно: https://cnrlink.com/mtsengineerhackdevopslib