Автообновление контейнеров по Git push

Автоматизация деплоя — один из способов сэкономить часы жизни и избавиться от рутины.

Если вы используете GitLab и Docker, можно настроить простую, но эффективную схему: пушим код — запускается GitLab CI, собирается и пушится образ — Watchtower на проде обновляет контейнер. Всё это без единого ручного действия.

1️⃣GitLab CI собирает и пушит Docker-образ

Пример .gitlab-ci.yml:

stages:
  - build
  - deploy

variables:
  IMAGE_TAG: registry.gitlab.com/yourgroup/yourapp:latest

build:
  stage: build
  noscript:
    - docker build -t $IMAGE_TAG .
    - echo "$CI_REGISTRY_PASSWORD" | docker login -u "$CI_REGISTRY_USER" --password-stdin $CI_REGISTRY
    - docker push $IMAGE_TAG

Для продакшена рекомендуют использовать versioned теги:

IMAGE_TAG: registry.gitlab.com/yourgroup/yourapp:$CI_COMMIT_SHORT_SHA

2️⃣ Watchtower на сервере следит за обновлениями

Запускаем Watchtower с привязкой к сокету Docker:

docker run -d \
  --name watchtower \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -e WATCHTOWER_CLEANUP=true \
  -e WATCHTOWER_POLL_INTERVAL=60 \
  containrrr/watchtower

Если у вас приватный реестр, авторизуйтесь на сервере:

docker login registry.gitlab.com

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

containrrr/watchtower yourapp_container

3️⃣ Запускаем основной контейнер из latest

Контейнер должен быть собран из обновляемого тега:

docker run -d \
  --name yourapp_container \
  yourgroup/yourapp:latest

При обновлении latest Watchtower автоматически остановит и перезапустит контейнер с новым образом.

Ускорение cold-start для systemd-сервисов

Если при загрузке системы или запуске демонов вы замечаете задержки, systemd даёт немало рычагов, чтобы cold-start прошёл быстрее.

Особенно это критично для сервисов, чувствительных к времени реакции (например, прокси, VPN, API-шлюзы).

Вот основные параметры, с которыми стоит поиграться:

⏺IOSchedulingClass и IOSchedulingPriority
Позволяют задать класс и приоритет доступа к диску.

Пример:

[Service]
IOSchedulingClass=best-effort
IOSchedulingPriority=2

Если сервис работает с базами или логами — можно установить класс realtime или поднять приоритет ближе к 0 (чем ниже — тем выше приоритет).

⏺CPUSchedulingPolicy и CPUSchedulingPriority
Контроль приоритетов на уровне CPU-шедулера.
Для критичных задач — SCHED_FIFO или SCHED_RR.

[Service]
CPUSchedulingPolicy=fifo
CPUSchedulingPriority=50

⏺StartLimitBurst и StartLimitInterval
Позволяют контролировать поведение при частых перезапусках. Иногда systemd из-за быстрых рестартов просто «глушит» сервис.

[Unit]
StartLimitBurst=10
StartLimitIntervalSec=30

Можно дать больше попыток на старте — особенно если сервис зависит от сети или сторонних демонов.

⏺TimeoutStartSec
Если cold-start занимает время, а systemd слишком рано считает запуск проваленным — увеличьте таймаут:

[Service]
TimeoutStartSec=60s

⏺ExecStartPre и ReadyNotify
Иногда лучше запускать предварительную инициализацию отдельно, чтобы основная служба стартовала уже с готовым окружением.

[Service]
ExecStartPre=/usr/local/bin/warmup.sh
Type=notify

⏺Nice и OOMScoreAdjust
Если нужно приоритетное планирование и защита от OOM killer’а:

[Service]
Nice=-5
OOMScoreAdjust=-500

💬 Вопрос на собеседовании для DevOps-инженера

Давайте разберем один из частых вопросов, который может быть задан на собеседовании и как на него отвечать.

❓Вопрос: Как работает OverlayFS в Linux и зачем он нужен?

✅Ответ: OverlayFS — это объединяющая файловая система, которая накладывает один каталог (upperdir) на другой (lowerdir), создавая виртуальный слой. Она позволяет изменять содержимое без модификации оригинальных данных, что особенно важно в контейнеризации.

Основные возможности:
— Наложение слоев: изменения записываются только в upperdir, а чтение происходит сначала из него, затем из lowerdir.
— Эффективность: экономия дискового пространства за счёт разделения слоёв и уменьшения количества копий.
— Применение: используется в Docker для организации copy-on-write хранилищ, а также в live-системах и сборках образов.

HIGGS — новый open-source метод сжатия LLM от Яндекса и научных партнёров

Исследователи из Yandex Research, ВШЭ, MIT, KAUST и ISTA представили HIGGS — способ квантизации больших языковых моделей без потери качества.

Метод уже доказал свою эффективность на DeepSeek R1 (671B параметров) и Llama 4 Maverick (400B), позволяя запускать их на более доступных устройствах.

Что делает HIGGS:
⏺Уменьшает размер модели без дообучения
⏺Работает даже без доступа к обучающим данным
⏺Лучше GPTQ и AWQ в диапазоне 2–4 бит
⏺Уже проверен на Llama 3, Llama 4, Qwen2.5

Доступно на:
• GitHub
• Hugging Face
• arXiv (научная статья принята на NAACL 2025)

HIGGS делает LLM доступнее не только для корпораций, но и для независимых разработчиков и лабораторий.

💬 Вопрос на собеседовании для сисадмина

Давайте разберем один из частых вопросов, который может быть задан на собеседовании и как на него отвечать.

❓Вопрос: Как работает CRIU и зачем он нужен?

✅Ответ: CRIU (Checkpoint/Restore In Userspace) — это утилита для создания контрольных точек (checkpoint) работающих процессов и их восстановления. Она позволяет “заморозить” состояние приложения и перенести его на другой сервер или восстановить позже.

Основные возможности:
— Сохранение состояния памяти, сокетов, дескрипторов, PID и даже TCP-соединений.
— Используется в live-миграции контейнеров (например, в Docker и LXC).
— Полезен для отказоустойчивости, быстрого запуска сервисов и отладки.

Пример:

criu dump -t <pid> --images-dir /tmp/checkpoint  
criu restore --images-dir /tmp/checkpoint

Мониторинг сети с помощью sFlow

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

Его основное преимущество — минимальная нагрузка на устройство благодаря выборочному сбору данных.

Как работает sFlow

• Агент sFlow: встроен в сетевое устройство и собирает выборки пакетов.
• Коллектор: сервер, принимающий выборки и анализирующий данные.
• Выборки: небольшие фрагменты трафика передаются на коллектор для анализа.

Настройка sFlow на коммутаторе

1️⃣Включение агента sFlow

На устройствах Cisco:

sflow enable  

На устройствах HPE/Aruba:

sflow 1 sampling 1000  
sflow 1 destination 192.168.1.2 6343  

2️⃣ Настройка параметров

Cisco: Установите IP-адрес агента (IP устройства):

sflow agent-ip 192.168.1.1  

Укажите частоту выборок:

sflow sampling-rate 1000  

Настройте интервал опроса счётчиков:

sflow polling-interval 30  

Укажите IP и порт коллектора:

sflow collector-ip 192.168.1.2 6343  

3️⃣ Проверка и мониторинг

Проверьте текущую конфигурацию:

show sflow  

На HPE:

show sflow agent  

Убедитесь, что данные отправляются на коллектор. Для анализа можно использовать инструменты, такие как sFlowTrend или ntopng.