DevOps

TTL (Time To Live) — это восьмибитное поле в IP-заголовке, определяющее максимальное количество «хопов» (узлов), которые пакет может пройти до того, как будет отброшен. При прохождении через любой маршрутизатор значение TTL уменьшается на 1.

Типичные значения TTL по умолчанию

Разные операционные системы используют разные начальные значения. Это позволяет удаленно определить тип ОС (OS Fingerprinting).

Зачем менять TTL? Паттерны использования

1. Обход ограничений тетеринга (раздачи интернета)

Самый частый сценарий. Мобильные операторы анализируют входящий трафик.

Если ты до сих пор делаешь next build прямо на продакшен-сервере — твой сервер действительно страдает. CPU в полку, OOM-kill, 502-е ошибки и долгие простои — это классика, которой пора положить конец.

В 2026 году стандарт индустрии — это раздельная сборка:

1. Собираем минимальный standalone-образ в облаке GitHub Actions.
2. Пушим его в GHCR (GitHub Container Registry).
3. На сервере делаем только pull + атомарный перезапуск.

Глава 1. Идеальный Dockerfile (Multi-stage + Standalone)

Весь секрет маленького и быстрого образа — в режиме standalone. Next.js сам вычисляет, какие файлы и части node_modules реально нужны для работы сервера, и копирует только их.

Когда технология Docker только появилась, её полюбили за лозунг: «Build once, run anywhere» (Собери один раз, запускай везде). Разработчики перестали слышать фразу «на моей машине всё работает, а на сервере — нет». Но вместе с удобством пришла и новая угроза.

Контейнер — это не просто ваше приложение. Это целая мини-операционная система (ОС) со своими библиотеками, утилитами и системными вызовами. И если вы не следите за этой ОС, вы оставляете хакерам огромную дверь, открытую настежь.

Представьте, что вы строите дом. Вы сами спроектировали стены, проверили каждый кирпич и убедились, что не забыли ключи в замке. Но что, если бетон, который вы купили у стороннего поставщика, со временем начинает рассыпаться? Или в готовых оконных рамах, которые вы установили, есть скрытые дефекты?

В современной разработке ситуация именно такая. Среднестатистическое приложение сегодня на 80–90% состоит из Open Source библиотек. Вы пишете лишь небольшую часть кода (верхушка айсберга), которая управляет огромным массивом чужого кода, скрытого «под водой».

Вы когда-нибудь задумывались, как опытные программисты находят ошибки в чужом коде, просто взглянув на него? Они ищут паттерны. Они знают, что если данные от пользователя попадают прямиком в SQL-запрос — это плохо. Если пароль сравнивается через обычное == вместо безопасной функции — это риск.

Но человек не может просмотреть 100 000 строк кода и ничего не упустить. Здесь на сцену выходит SAST (Static Application Security Testing).

Что такое SAST и как он работает?

SAST — это технология анализа исходного кода, которая работает без запуска самого приложения. Представьте, что это очень продвинутый «Spell-checker» (проверка орфографии), только ищет он не опечатки, а архитектурные и логические уязвимости.

Представьте ситуацию: вы работаете над крутым проектом всю ночь. К 4 часам утра всё готово, вы делаете финальный git push и со спокойной душой идёте спать. А утром обнаруживаете, что ваш баланс в AWS обнулён, а на серверах запущен майнер. Что произошло? Оказывается, в одном из файлов вы оставили строчку: AWS_ACCESS_KEY_ID = "AKIA...".

Это классическая ошибка, через которую проходили тысячи разработчиков. В этой статье мы разберём, почему «просто удалить пароль» не поможет и как настроить автоматическую защиту, которая физически не даст вам совершить ошибку.

Написать Dockerfile просто: FROM node, COPY ., CMD run. Это работает, и для локальных тестов этого часто достаточно. Но когда такой образ попадает в CI/CD или, не дай бог, в продакшн, начинаются проблемы: сборка длится вечность, образ весит гигабайты, а безопасники хватаются за голову.

Разница между «работает» и «работает правильно» колоссальна. Давайте разберем четыре уровня оптимизации, которые отделяют любительскую поделку от надежного инженерного решения.

1. Фундамент: Выбор образа и детерминизм

Всё начинается с инструкции FROM. Многие по привычке берут полные образы (например, стандартную ubuntu или python:3.9), не задумываясь о последствиях.

OpenVPN — это надёжный и проверенный временем VPN-протокол, который позволяет организовать защищённый удалённый доступ к локальной сети. MikroTik RouterOS поддерживает OpenVPN в режиме сервера начиная с версии 6.x (TCP), а с версии 7+ — также и UDP, но с рядом архитектурных ограничений:

• обязательная аутентификация по логину/паролю даже при использовании сертификатов;
• ограниченный список шифров и алгоритмов;
• отсутствие некоторых возможностей «классического» OpenVPN.

Несмотря на это, OpenVPN на MikroTik остаётся востребованным решением — особенно в сценариях, где клиенты не поддерживают WireGuard или требуется совместимость со старыми системами.

Если вы занимаетесь self-hosting’ом, держите домашнюю лабораторию или управляете небольшим VPS, то наверняка знакомы с Portainer. Это де-факто стандарт: мощный, всеобъемлющий «швейцарский нож» для Docker.

Но давайте будем честны: иногда швейцарский нож слишком тяжёлый, когда нужно просто почистить яблоко.

Недавно я открыл для себя Dockge — инструмент от того же разработчика, что и популярный Uptime Kuma. Он заставил меня полностью пересмотреть подход к управлению контейнерами. В этой статье расскажу, почему Dockge может стать идеальной заменой Portainer для многих сценариев.

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

На первый взгляд задача кажется тривиальной: sed -i 's|old|new|g' **/* — и готово.

В реальности такой подход — это русская рулетка.

Неосторожная замена приводит к:

• 💀 Повреждению бинарных файлов (images, pdf, archives);
• 📉 Мусору в git-истории (бинарники помечаются как изменённые);
• 🚫 Невозможности чистого отката, если бэкап не был сделан.

В этой заметке разберём production-grade алгоритм: меняем только текст, не трогаем бинарники, делаем точечный бэкап.