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

🐸 Библиотека devops'a #пятничный_деплой

📰 Новости первой недели декабря Новый Год всё ближе, а мы с новостями. — Solus 4.8 — Опасное «обновление» винды — MiniOS v5.1.0 — Linux 6.18 — Let's Encrypt будет выпускать сертификаты на 45 дней 🔹 Специалист по ИИ 🔹 Получить консультацию менеджера 🔹 Сайт Академии 🔹 Сайт Proglib 🐸 Библиотека devops'a #дайджест_недели

⚡️ Let’s Encrypt сократит срок жизни сертификатов Сегодня Let’s Encrypt выдаёт сертификаты на 90 дней, но постепенно этот срок урежут до 45 дней для всех публично доверенных сертификатов. Меняется не только срок действия сертификата, но и период повторного использования авторизации домена: сейчас домен‑валидация может переиспользоваться 30 дней, к 2028 году это окно сократят до 7 часов. То есть подтверждать контроль над доменом придётся намного чаще. Если у вас автоматизированный выпуск и продление сертификатов, скорее всего менять ничего не придётся, но автоматизация должна выдерживать более частые обновления. ➡️ Источник 🔹 Математика для Data Science 🔹 Получить консультацию менеджера 🔹 Сайт Академии 🔹 Сайт Proglib 🐸 Библиотека devops'a #пульс_индустрии

🐳 Почему секреты в Dockerfile остаются навсегда Хардкодить ключи и пароли в Dockerfile кажется быстрым решением, но в контейнерном мире это почти гарантированная утечка. Даже если потом удалить секрет, он уже может остаться в слоях образа, логах, кэше сборки и сторонних регистрах. Docker строит образ послойно, и каждый слой можно просмотреть через docker history или инструменты анализа образов. Если на каком то шаге в Dockerfile задать ENV с токеном или скопировать файл с секретами, этот слой останется в истории образа даже после последующих RUN rm и похожих команд. В результате любой, кто получил образ или доступ к реестру, может восстановить эти данные. Надежное правило для повседневной работы простое — в Dockerfile никогда не должно быть токенов, паролей и ключей. Секреты передаются только в рантайме через env file или встроенные механизмы секретов платформы, а процесс сборки остается максимально слепым к конфиденциальным данным. 🔹 Алгоритмы и структуры данных 🔹 Получить консультацию менеджера 🔹 Сайт Академии 🔹 Сайт Proglib 🐸 Библиотека devops'a #root@prompt

👨‍💻 Fedora на MacBook Pro 2019 На MacBook Pro 2019 с чипом T2 ставить Linux непросто. Но Fedora 42 запускается полностью, с Wi-Fi, звуком и тачпадом, если подготовиться заранее. Если кратко, то раз-раз и готово, а подробности в статье. ➡️ Вот пошаговый план действий 🔹 ML для старта в Data Science 🔹 Получить консультацию менеджера 🔹 Сайт Академии 🔹 Сайт Proglib 🐸 Библиотека devops'a

MLOps — это не только Docker и K8s Чтобы эффективно деплоить и мониторить модели, нужно понимать природу данных и метрик. DevOps, знающий математику ML, стоит на рынке x1.5. Присоединяйтесь к курсу «Математика для разработки AI-моделей». Мы добавили живые вебинары. Что прокачаем: — понимание матричных операций (нагрузка на железо); — логику линейной регрессии (как модель учится); — SVD и сжатие данных (оптимизация хранения и передачи). Первый вебинар уже в записи. Регистрация до 9 декабря: https://clc.to/LojFzw

🔄 Вышла FreeBSD 15.0 Вышел стабильный релиз FreeBSD 15.0. Образы уже доступны для amd64, aarch64, armv7, powerpc64, powerpc64le и riscv64, а также в форматах для виртуализации и облаков Главное: 15.x окончательно про 64‑битные системы. Поддержка 32‑битных платформ в ядре прекращена, но до конца жизни 16.x останется возможность собирать 32‑битные приложения и запускать их через COMPAT_FREEBSD32 в 64‑битном окружении. Теперь базовую систему можно ставить и обновлять через пакетный менеджер pkg, а классический монолитный подход через freebsd-update помечен как устаревающий и планируется к удалению к 16 версии. Часть старых компонентов объявлена устаревшими или удалена: gvinum, ftpd, shar, fdisk, syscons и ряд старых драйверов ➡️ Анонс релиза 🔹 Специалист по ИИ 🔹 Получить консультацию менеджера 🔹 Сайт Академии 🔹 Сайт Proglib 🐸 Библиотека devops'a #пульс_индустрии

💻 Настраиваем узлы Kubernetes автоматически Когда вы разворачиваете Kubernetes кластер вручную, нужно на каждый узел установить куча компонентов: kubeadm, kubelet, kubectl, добавить репозитории, настроить сеть, включить необходимые модули ядра. На одном узле это полчаса работы. На десяти узлах — это часы монотонной, однообразной работы, где легко что-то забыть или неправильно сделать. Подготовили для вас такой плейбук:

- name: Configure Kubernetes node
  hosts: nodes
  become: yes
  tasks:
    - name: Install kubeadm, kubelet, and kubectl
      apt:
        name: "{{ item }}"
        state: present
      loop:
        - kubeadm
        - kubelet
        - kubectl

hosts: nodes — плейбук выполняется на всех серверах, которые помечены как узлы (nodes) в вашем инвентаре Ansible. become: yes — нужны права администратора для установки пакетов и системных изменений. apt: — модуль для управления пакетами в Debian/Ubuntu. Установит из стандартных репозиториев. loop: — устанавливает три компонента: • kubeadm — инструмент для инициализации и управления кластером • kubelet — агент, который запускает контейнеры на узле • kubectl — команда для управления Kubernetes кластером state: present — пакеты должны быть установлены. После установки этих компонентов узел будет готов присоединиться к кластеру Kubernetes. 🔹 Математика для разработки AI-моделей 🔹 Получить консультацию менеджера 🔹 Сайт Академии 🔹 Сайт Proglib 🐸 Библиотека devops'a #root@prompt

🤩 Автоматический бэкап на Python Регулярные бэкапы — то, о чем вспоминают, когда уже поздно. Вот базовый пример скрипта, который архивирует директорию в tar.gz с таймстэмпом в имени и складывает в заданное место:

import shutil
import time

def backup_directory(source, destination):
    timestamp = time.strftime("%Y%m%d%H%M%S")
    backup_file = f"{destination}/backup_{timestamp}.tar.gz"
    # shutil.make_archive ожидает путь без расширения
    shutil.make_archive(backup_file.replace(".tar.gz", ""), "gztar", source)
    print(f"Backup completed: {backup_file}")

backup_directory("/path/to/important/data", "/path/to/backup/location")

Что делает скрипт: • Берёт путь к исходной директории source и каталогу для бэкапов destination. • Генерирует имя файла по текущему времени, чтобы каждый бэкап был уникальным. • Создаёт архив в формате tar.gz с помощью shutil.make_archive. • Печатает путь к созданному бэкапу. Как использовать в продакшене: • Положить скрипт в репозиторий инфраструктуры или ansible/helm-роль. • Прописать запуск через cron, systemd timer или CI-пайплайн. • Добавить логирование в файл и алерт при ошибке Минимальная доработка под боевое окружение: • Проверка существования директорий. • Конфиг через переменные окружения или .env. • Отправка бэкапа в S3 / объектное хранилище / удалённый сервер. Такой небольшой скрипт закрывает базовую задачу резервного копирования важных директорий без лишних зависимостей. 🔹 Программирование на языке Python 🔹 Получить консультацию менеджера 🔹 Сайт Академии 🔹 Сайт Proglib 🐸 Библиотека devops'a #арсенал_инженера

😊 Как управлять микросервисами и AI-нагрузками в закрытом контуре Сегодня на конференции Kuber Conf by AOT можно было посмотреть новое решение Stackland. Оно помогает управлять микросервисной архитектурой и AI-нагрузками внутри корпоративных сред — где важны безопасность, изоляция и контроль инфраструктуры. В основе подхода — автоматизация и оркестрация через Kubernetes. Stackland объединяет управление сервисами, мониторинг и CI/CD-процессы в единой среде. 🐸Библиотека devops'a

📎 Лучшие практики конфигурации в Kubernetes Вот несколько проверенных правил, которые помогут сделать вашу конфигурацию чистой, понятной и удобной в поддержке. — Используйте актуальные версии API Kubernetes быстро развивается. Старые версии API со временем устаревают и перестают работать. Перед созданием ресурсов всегда проверяйте, что используете самые свежие стабильные версии. Команда kubectl api-resources поможет выявить доступные версии. — Храните конфигурацию в системе контроля версий Никогда не применяйте манифесты напрямую с локальной машины. Всегда держите их под контролем версий, например в Git. Это поможет быстро откатиться при ошибках и отслеживать изменения без паники. — Пишите конфигурацию в YAML, а не JSON Технически работают оба формата, но YAML удобнее для человека — читается легче и занимает меньше места. Однако в YAML есть нюансы: используйте только true или false для булевых значений и избегайте yes, no, on или off, поскольку они могут некорректно интерпретироваться. — Минимализм — ваш друг Не задавайте значения по умолчанию, уже обработанные Kubernetes. Минимальные манифесты легче дебажить, они чисты и реже вызывают ошибки. — Группируйте связанные объекты Если ваш Deployment, Service и ConfigMap принадлежат одному приложению, объедините их в один манифест. Это упростит управление и развертывание. Можно даже применять целые директории командой kubectl apply -f configs/. — Добавляйте поясняющие аннотации Манифесты — это не только инструкции для системы, но и документация для команды. Используйте аннотации, например kubernetes.io/description, чтобы описывать, зачем нужен тот или иной объект. Это очень поможет при отладке и совместной работе. — Управление рабочими нагрузками: выбирайте правильный контроллер • Избегайте «голых» Pod без контроллера — они не восстанавливаются при сбоях. • Для приложений используйте Deployments с ReplicaSet — они обеспечивают поддержание нужного количества копий и позволяют безопасно обновлять версии. • Для одноразовых задач подойдут Jobs — выполняют работу и завершаются, перезапускаются при сбоях. — Службы и сетевое взаимодействие Создавайте Services до запуска зависимых подов — это гарантирует правильную инициализацию переменных окружения для подключения. Используйте DNS для сервисов — обращайтесь к ним по имени, а не IP. Это упрощает масштабирование и управление. Осторожно с опциями hostPort и hostNetwork — они ограничивают масштабируемость и усложняют планирование. — Эффективное использование лейблов Хорошо подобранные лейблы позволяют легко группировать и фильтровать ресурсы. Следуйте официальным рекомендациям по семантическим меткам:

labels:
  app.kubernetes.io/name: myapp
  app.kubernetes.io/component: web
  tier: frontend
  phase: test

Полезные команды и советы • Применяйте сразу целые папки с манифестами:

kubectl apply -f configs/

• Используйте селекторы меток для массового просмотра или удаления ресурсов:

kubectl get pods -l tier=frontend
kubectl delete pod -l phase=test

• Для быстрого прототипирования создавайте деплойменты и сервисы из командной строки:

kubectl create deployment webapp --image=nginx
    kubectl expose deployment webapp --port=80

➡️ Оригинальная статья из блога k8s 🐸Библиотека devops'a #локализация

🖥 Смотрим загрузку CPU в реальном времени Сервер тормозит, но вы не знаете, почему. Может, какой-то процесс сходит с ума и съедает все ресурсы? Или это просто пики нагрузки? Нужно быстро посмотреть, что происходит с процессором прямо сейчас. Вот для этого и нужна команда, которая покажет текущую загрузку CPU:

top -b -n 1 | grep "Cpu(s)"

top — это команда, которая показывает, чем занимается система. Она выводит процессы, их загрузку, использование памяти, всё подряд. -b — batch mode. Вместо интерактивного режима top просто выдаёт результат и завершается. -n 1 — одна итерация. Без этого top обновлял бы данные каждую секунду. grep "Cpu(s)" — выбирает из всего вывода только строку с информацией о CPU. Если нужна более глубокая диагностика, есть другие команды: Смотрим среднюю загрузку за 1, 5 и 15 минут:

uptime //14:35:22 up 10 days, 2:45, 1 user, load average: 0.45, 0.52, 0.48

Три числа в конце — это средняя нагрузка за последние 1, 5 и 15 минут. Смотрим загрузку каждого ядра отдельно:

mpstat -P ALL 1 1

Смотрим, какой процесс больше всего грузит CPU:

ps aux --sort=-%cpu | head -10

Или используйте специализированные инструменты мониторинга вроде Prometheus или Grafana — они будут отслеживать метрики автоматически и хранить историю. 🔹 AI-агенты для DS-специалистов 🔹 Получить консультацию менеджера 🔹 Сайт Академии 🔹 Сайт Proglib 🐸 Библиотека devops'a #root@prompt

⚙️ journactl: управление логами systemd journactl — утилита для работы с журналом systemd, которая позволяет просматривать, фильтровать и анализировать системные логи. Журналы systemd хранятся в бинарном формате, что позволяет искать по различным полям — юнитам, уровню приоритета, идентификаторам процессов и другим метаданным. Что можно делать с journactl: Просматривать все системные логи с момента старта:

journalctl

Фокусироваться на конкретном сервисе, например, nginx:

journalctl -u nginx.service

Фильтровать логи по времени, например, за последний час:

journalctl --since "1 hour ago"

Смотреть логи в реальном времени (аналог tail -f):

journalctl -f

Отфильтровать сообщения с ошибками:

journalctl -p err

Узнать, сколько места занимает журнал на диске:

journalctl --disk-usage

Очистить журнал, например, ограничив размер до 500 Мб:

journalctl --vacuum-size=500M

jurnactl позволяет девопсам быстро ориентироваться в событиях системы, находить сбои и контролировать состояние сервисов. 🔹 Алгоритмы и структуры данных 🔹 Получить консультацию менеджера 🔹 Сайт Академии 🔹 Сайт Proglib 🐸 Библиотека devops'a #пульс_индустрии

MLOps: понимай метрики, а не только контейнеры Почему модель деградирует? Что такое дрифт данных? Как мониторить точность? Ответы на эти вопросы лежат в области статистики. Девопс, который понимает математику ML, стоит в два раза дороже. Приходите на курс «Математика для разработки AI-моделей». Старт завтра. 🛠 Прайс: 28 200 ₽. 🛠 Формат: Интенсив. 👉 Стать MLOps-инженером Тест: Проверь знания

💡 Linux 6.18 готов к использованию Linux 6.18 — новый релиз ядра от Линуса Торвальдса. Несмотря на активное исправление багов в последние дни перед выпуском, разработчик считает, что ядро готово к использованию и не требует дополнительного времени на доработку. Большинство исправлений касается драйверов, а также Bluetooth, Ceph и AFS. ➡️ Прочитать письмо Торвальдса 🔹 Математика для разработки AI-моделей 🔹 Получить консультацию менеджера 🔹 Сайт Академии 🔹 Сайт Proglib 🐸 Библиотека devops'a #root@prompt

🐳 Ставим Docker одинаково на все сервера Когда вы разворачиваете Docker на пяти серверах вручную, на каждом может получиться по-своему. На одном установилась одна версия, на другом — другая. На третьем забыли добавить репозиторий. На четвёртом пропустили зависимость. Вот для этого и нужна автоматизация. Вы один раз описываете правильную установку Docker — и она раскатывается идентично на все серверы. Используется всё тот же Ansible. Он подключается к каждому серверу и выполняет одни и те же команды по порядку:

- name: Install Docker
  hosts: all
  become: yes
  tasks:
    - name: Install required packages
      apt:
        name: "{{ item }}"
        state: present
      loop:
        - apt-transport-https
        - ca-certificates
        - curl
    - name: Install Docker
      shell: curl -fsSL https://get.docker.com | bash

Разберём: hosts: all — плейбук запустится на всех серверах из вашего инвентаря. become: yes — нужны права администратора для установки пакетов. apt: — модуль Ansible для управления пакетами в Debian/Ubuntu. Он знает, как работать с apt-get, и сделает это правильно. loop: — устанавливает пакеты по одному: apt-transport-https, ca-certificates, curl. Они нужны, чтобы безопасно загрузить Docker. shell: curl -fsSL https://get.docker.com | bash — официальный скрипт установки Docker от разработчиков. Он сделает все остальное: добавит репозиторий, установит Docker Engine, настроит сервис. state: present — пакет должен быть установлен. Если его нет, установит. Если есть, проверит версию и обновит при необходимости. После установки проверьте, что Docker работает:

- name: Verify Docker installation
  shell: docker run hello-world
  register: docker_test
  failed_when: "'Hello from Docker!' not in docker_test.stdout"

Или добавьте проверку в конец плейбука:

- name: Check Docker status
  systemd:
    name: docker
    state: started
    enabled: yes

🔹 Программирование на языке Python 🔹 Получить консультацию менеджера 🔹 Сайт Академии 🔹 Сайт Proglib 🐸 Библиотека devops'a #root@prompt

⚙️ MiniOS v5.1.0 В свежем релизе MiniOS разработчики сосредоточились на исправлении багов, улучшении стабильности и удобства использования. Важные изменения: • Обновлена система сборки: улучшена генерация man-страниц и локализация, оптимизирована работа с пакетами. • В загрузочные меню добавлена поддержка нескольких языков, теперь часовой пояс и раскладка клавиатуры настраиваются автоматически. • Для виртуальных машин появилась утилита адаптации разрешения экрана. Также улучшена совместимость с Ventoy. • Расширена поддержка Ubuntu Bionic и Focal, изменена логика работы с ядром, добавлен пакет для поддержки MediaTek адаптеров. • Аудиоподсистема переведена с PulseAudio на PipeWire для большей производительности. • Новый менеджер сессий умеет экспортировать и импортировать сессии с конвертацией форматов, установщик и конфигуратор получили многоязычную поддержку и улучшенную интеграцию с загрузчиками. • Появился упрощённый файловый менеджер и новый терминальный меню-утилит. • Экспериментально добавлена поддержка альтернативного сборщика initramfs — dracut, при этом по умолчанию остаётся livekit. Система автоматически определяет используемый сборщик. ➡️ Release Notes 🔹 Программирование на языке Python 🔹 Получить консультацию менеджера 🔹 Сайт Академии 🔹 Сайт Proglib 🐸 Библиотека devops'a #пульс_индустрии

InfraDev Community приглашает на Cloud Fail ((Over)): специальный новогодний выпуск InfraDev Meetup. Без фейлов не обходится ни один крутой продукт, ну а истории успеха — «за ширмой» оказываются историями поисков и ошибок с удачным концом. Поговорим про то, какие проблемы возникают под капотом инфраструктурных продуктов, как они решаются и какие уроки из этого получаются. Спикеры: ☁️Василий Степанов, руководитель направления инфраструктурных сервисов, VK Cloud, VK Tech. ☁️Константин Крамлих, руководитель поднаправления сетевых продуктов, Yandex.Cloud. ☁️Секретный доклад: подробности добавим позднее. Подробнее о докладах читайте на странице мероприятия. Когда: 18 декабря, с 18:00 до 23:59 Где: Москва, Ленинградский пр., 70, офис VK Tech, БЦ «Алкон» (количество мест ограничено). Приходите на встречу или участвуйте онлайн. Зарегистрироваться.

🍔 Топ-вакансий для девопсов за неделю DevOps Engineer — от 4 500 до 6 500 $ DevOps-инженер — от 180 000 ₽ DevOps Engineer — от 250 000 ₽ Бустер — Офис у вас дома. ➡️ Еще больше топовых вакансий — в нашем канале Devops Jobs 🐸Библиотека devops'a #вакансия_недели

🔄 Автоматически перезапускаем упавший сервис Сервис упал ночью, никто не заметил, а клиенты уже час не могут подключиться. Или упал в выходной, когда все спят. Вручную проверять сервисы каждый день — это неправильно. Нужно, чтобы система сама заметила, что что-то не так, и исправила. Вот эта команда делает ровно это: проверяет, работает ли критичный сервис, и если нет — перезапускает его

systemctl is-active --quiet nginx || systemctl restart nginx

Это одна логическая цепочка. Давайте разберёмся: systemctl is-active --quiet nginx — проверяет, работает ли сервис nginx прямо сейчас. Флаг --quiet говорит не выводить никакую информацию на экран, просто вернуть результат: работает или не работает. systemctl restart nginx — перезапускает сервис nginx. Остановит текущий процесс и запустит заново. Как использовать Самый простой способ — добавить эту команду в cron, чтобы она проверяла сервис каждую минуту:

* * * * * /usr/bin/systemctl is-active --quiet nginx || /usr/bin/systemctl restart nginx

Если используете systemd, есть более продвинутый способ — встроенный Restart в конфиге сервиса:

[Unit]
Description=Nginx Web Server

[Service]
Type=notify
Restart=on-failure
RestartSec=5s
ExecStart=/usr/sbin/nginx

[Install]
WantedBy=multi-user.target

🔹 Математика для разработки AI-моделей 🔹 Получить консультацию менеджера 🔹 Сайт Академии 🔹 Сайт Proglib 🐸 Библиотека devops'a #root@prompt