Автор оригинального руководства указывает заголовок «за $5/месяц», но на практике минимально жизнеспособная конфигурация обходится в $6–12/месяц. За $5 дроплет даёт всего 1 ГБ ОЗУ — для семимиллиардной модели этого катастрофически мало. Ниже — реальные цифры и честная смета.

Что такое Llama 2 и зачем её self-hostить

Llama 2 — семейство открытых больших языковых моделей от Meta. Версия 7B содержит 7 миллиардов параметров, понимает английский и ряд других языков, умеет писать код, отвечать на вопросы и дополнять текст. Лицензия разрешает коммерческое использование при соблюдении простых правил, а веса можно скачать с Hugging Face.

Self-hosting в данном случае означает, что вы сами устанавливаете модель на арендованный сервер, контролируете окружение, не делитесь данными пользователей с третьими лицами и не зависите от чужих rate limit. Главная экономика: при интенсивном использовании собственный инференс обходится в десятки раз дешевле облачных API.

• Llama 2 7B можно запустить на DigitalOcean Droplet с 2 vCPU и 4 ГБ ОЗУ при 4-битном квантовании.
• Реальная стоимость — $12/месяц за Droplet плюс около $0,50 за трафик, а не $5.
• Docker + FastAPI дают воспроизводимое окружение и HTTP API из коробки.
• Для загрузки весов с Hugging Face нужен токен и принятая лицензия на Llama 2.
• Для публичного доступа обязательны HTTPS, базовая аутентификация и rate limiting.

Что понадобится для развёртывания

Аппаратная часть

• DigitalOcean Droplet на Ubuntu 22.04 LTS.
• Минимум: 1 vCPU / 2 ГБ ОЗУ ($6/месяц) — только для экспериментов.
• Рекомендуемый: 2 vCPU / 4 ГБ ОЗУ ($12/месяц) — стабильная работа с квантованием.
• 80 ГБ SSD: ~13 ГБ уйдёт на Docker-образ, модель и кэш.

Программная часть

• SSH-ключ и базовое умение работать в терминале.
• Docker и Docker Compose для управления контейнером.
• Аккаунт на Hugging Face с принятой лицензией Llama 2 и API-токеном.
• Nginx или аналогичный reverse proxy для вывода API в интернет.

Российская специфика: сайт DigitalOcean периодически попадает под блокировки Роскомнадзора. Для регистрации и управления Droplet может понадобиться VPN. Альтернативы — Hetzner, Selectel, Yandex Cloud или другие европейские и российские провайдеры; логика развёртывания от этого почти не меняется.

Шаг 1. Создаём Droplet и подключаемся по SSH

В панели DigitalOcean нажимаем Create → Droplet. Выбираем ближайший к целевой аудитории регион — для России это обычно Франкфурт или Амстердам. В качестве образа указываем Ubuntu 22.04 x64, тип — Basic Shared CPU, конфигурацию — 2 vCPU / 4 ГБ RAM. Авторизацию настраиваем через SSH-ключ, парольный вход отключаем.

Сгенерировать ключ и подключиться можно так:

Шаг 2. Устанавливаем Docker и зависимости

После подключения обновляем пакеты и ставим Docker официальным скриптом. Добавляем root в группу docker, чтобы не писать sudo перед каждой командой.

Шаг 3. Собираем Docker-образ с FastAPI

Приложение состоит из трёх файлов: Dockerfile, requirements.txt и app.py. Ключевой трюк — CPU-версия PyTorch и библиотека bitsandbytes, которая позволяет загрузить 7-миллиардную модель в 4 ГБ видеопамяти/ОЗУ.

Dockerfile

requirements.txt

Шаг 4. Пишем FastAPI-приложение

Приложение загружает модель при старте, кэширует её в /app/models и предоставляет три endpoint: /health, /info и /generate. Квантование в 4 бита снижает точность незначительно, но уменьшает потребление памяти в 3–4 раза.

Создаём файл с токеном Hugging Face. Никогда не коммитьте его в репозиторий: в продакшене используйте переменные окружения или секрет-менеджер.

Шаг 5. Собираем и запускаем контейнер

Первый запуск занимает 10–15 минут: скачиваются зависимости PyTorch и веса модели. Чтобы не качать веса при каждом перезапуске, подключаем Docker volume.

Для удобного управления добавляем docker-compose.yml:

Шаг 6. Проверяем API

Когда в логах появится Uvicorn running on http://0.0.0.0:8000, тестируем endpoint'ы:

Ответ должен содержать сгенерированный текст, количество токенов и время инференса. На CPU одна генерация из 100 токенов занимает 4–10 секунд — это нормально для бюджетного дроплета.

Шаг 7. Безопасно выводим API в интернет

Открывать порт 8000 напрямую в интернет небезопасно. Ставим Nginx как reverse proxy, настраиваем HTTPS через Let's Encrypt и базовую аутентификацию. Для rate limiting используем limit_req в Nginx или облачный firewall DigitalOcean.

Минимальная конфигурация Nginx выглядит так:

Про безопасность: Llama 2 — мощная модель, способная генерировать вредоносные инструкции, персональные данные или нежелательный контент. Не выставляйте публичный API без аутентификации, логируйте запросы и рассмотрите фильтрацию промптов на уровне приложения.

Выводы

Self-hosted Llama 2 — рабочий способ снизить затраты на генеративный ИИ в pet-проектах и прототипах. При правильном квантовании семимиллиардная модель помещается в бюджетный дроплет, а Docker + FastAPI превращают развёртывание в рутинную процедуру. Главное — не экономить на RAM и не забывать про безопасность публичного API.

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

Если соберётесь повторить гайд, начните с $12 Droplet и протестируйте нагрузку вручную. А если DigitalOcean недоступен — переносите тот же Docker Compose на Hetzner, Selectel или Yandex Cloud без изменения кода.

Источник: How to Deploy Llama 2 on DigitalOcean for $5/Month: Complete Self-Hosting Guide — RamosAI, Dev.to.

Арендовать мощные VPS под ресурсоемкие задачи в текущих реалиях выходит неоправданно дорого. При этом дома у меня уже был выделенный неттоп (мини-ПК) с 16 ГБ оперативной памяти на базе энергоэффективного процессора Intel N95.

Пройдя путь от простых Bash-скриптов и сторонних туннелей до полностью автоматизированной инфраструктуры, я создал проект ServeHub-2. В этой статье я подробно разберу, как эволюционировала сеть проекта, почему декларативный подход победил императивный и с какими неочевидными багами пришлось столкнуться в процессе автоматизации.

История настройки сетевой архитектуры

Использование Tuna

В самом начале проекта я еще не думал о VPN как о способе пробития NAT и основе, на которой будет строиться вся система. Первое, к чему я пришел — сервис Tuna. Если кратко, это аналог Cloudflare Tunnel за условные 300 рублей. У него очень приятный веб-интерфейс и невероятно простая настройка. Однако для полноценной независимой архитектуры он не подошел по двум причинам:

• Сервера Tuna находятся вне контроля пользователя.
• На удаленном сервере нельзя развернуть свои сопутствующие сервисы.

В целом сервис действительно удобный, но для моих задач он оказался слишком ограничивающим.

Вот пример конфига для tuna (все максимально просто, создаем контейнеры для ssh туннеля, чтобы был доступ ssh, а также основной http туннель с привязкой к nginx или любому другому прокси если такой есть):

В поисках гибкости: тесты Pangolin и переход к FRP

После Tuna я решил двигаться в сторону собственного контроля и попробовал Pangolin. Однако решение быстро отвалилось: для дешёвого сервера оно оказалось слишком «тяжёлым» и избыточным. Главные минусы — ощутимый оверхед по ресурсам и лишний слой принудительной веб-аутентификации перед самими сервисами. Это ломало нормальное взаимодействие с родными мобильными клиентами (вроде Element для Matrix или Bitwarden для паролей), где повторная авторизация в браузере просто не нужна.

На смену пришел FRP (Fast Reverse Proxy). Он выполнял ту же функцию проброса, но хостил я его уже на собственном арендованном VPS в режиме Layer 4 (TCP). Это дало абсолютную гибкость: внешний VPS не заглядывал внутрь пакетов и ничего не расшифровывал, а просто пересылал сырой поток домой. Кроме того, это отлично оптимизировало расходы: вместо 300 рублей за Tuna и ещё 300 рублей за отдельный VPN, я стал платить всего 500 рублей за один стойкий VPS, который мог настраивать как хочу. (к тому же можно было обойтись даже дешевле, так как VPS с 4 гб оперативки загружен всего лишь на 40%, процессор всего на 20%-40%)

FRP состоит из 2 конфигурационных файлов (один на удаленном сервере frp server, другой на локальном frp client), все также довольно просто, однако его можно использовать на разных слоях. У меня он брал трафик за стандартный TCP и передавал его на локальный сервер.

Также доп. фишка в том что основная конфигурация происходит именно в frpc, который, в свою очередь, передает часть настроек на frp на удаленном сервере.

frpc.toml:

frps.toml:

Полноценный переезд на WireGuard (AmneziaWG) и 8 часов отладки

Со временем архитектура эволюционировала в сторону полноценной VPN-сети на базе WireGuard, а точнее — его модификации AmneziaWG. Причин для этого шага было несколько:

• Безопасность: FRP всё же открывал внутренние ресурсы в публичный интернет, оставляя их доступными для сканеров портов.
• Удобство маршрутизации: Все участники сети стали равноправными узлами в одной виртуальной локальной подсети. Больше не нужно было настраивать постоянные односторонние пробросы.
• Дополнительный бонус: Поскольку удаленный VPS был куплен в Нидерландах, через этот же VPN я автоматически получил безопасный доступ ко всем зарубежным ресурсам.

Для реализации схемы на удаленном VPS был развернут контейнер wg-easy с поддержкой AmneziaWG, а на домашнем мини-ПК — клиентский контейнер Amnezia (сборка из Dockerfile с использованием amnezia-tools и модулем ядра хоста).

И именно здесь я поймал самый изнурительный баг проекта. После развертывания трафик упорно шёл только в одну сторону. Часов 8 ушло на диагностику iptables, маршрутов и чтение зарубежных форумов (что бесполезно, учитывая специфику наших блокировок). Оказалось, провайдер просто дропал обратный трафик стандартного WireGuard, так как пакеты шли без маскировки. Причина крылась в docker-compose.yml: у меня было прописано image: ghcr.io/wg-easy/wg-easy:latest. Как выяснилось, тег latest на Docker Hub намертво прилип к старой 14-й версии, а поддержка параметров AmneziaWG появилась только в ветке 15.x. Изменение тега на конкретную версию (15.3) решило проблему за секунду.

Благодаря переходу конфигурация получилась максимально простой, основные отличия от стандартной документации выделил в коде: (в основном то, на что пришлось долго рыть информацию)

Настройка Nginx

Чтобы сервисы были доступны исключительно внутри подсети VPN, я задействовал Nginx. Доступ к приложениям был жестко ограничен на уровне конфигурации — веб-сервер принимает запросы только из диапазона IP-адресов 10.8.0.0/24. Любые попытки постучаться на сервер из внешнего интернета без активного VPN-туннеля автоматически сбрасываются Nginx.

Логика распределения завязана на proxy-протоколе: Nginx на удаленном VPS выступает основным входным узлом, принимает зашифрованный трафик, заворачивает его в заголовки с реальным IP-адресом клиента и через туннель перекидывает на локальный Nginx домашнего сервера. Локальный веб-сервер уже сам расшифровывает SSL и распределяет трафик по конечным Docker-контейнерам, сохраняя реальные IP в логах безопасности.

Вставлю один кусок кода из nginx на удаленной машине для примера, так все остальное примерно похоже (конфиги использовались в виде .template):

SSL-сертификаты

Для получения валидных SSL-сертификатов я настроил работу через автоматический Certbot по challenge-валидации DNS-01 c API Webnames. Сам домен привязан к внутреннему IP-адресу 10.8.0.1. Проверка через DNS позволила выпустить единый wildcard-сертификат на весь домен и его поддомены без необходимости держать открытым 80-й порт веб-сервера наружу.

Уточню, что certbot запускается автоматически во время выполнения Ansible плейбука, поэтому самому кроме указания переменных ничего делать не нужно.

В итоге получилась схема, при которой все сервисы доступны по красивым доменным именам с HTTPS, но абсолютно невидимы для внешнего интернета.

Вот настройка certbot:

История софта

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

Первый стек и оптимизация

Первыми на домашнем сервере прижились медиа-сервисы: Navidrome для стриминга музыки и Audiobookshelf для аудиокниг и подкастов. Они легковесные, имеют отличные мобильные клиенты с синхронизацией прогресса и полностью закрывают мои потребности. Позже к ним добавился Nextcloud как единое независимое облако для файлов, контактов и семейных документов.

Затем встал вопрос безопасного хранения паролей. Сначала я смотрел в сторону оригинального Bitwarden, но в итоге я выбрал Vaultwarden — альтернативный сервер на Rust, полностью совместимый с API Bitwarden. Он потребляет считанные мегабайты оперативной памяти и работает идеально. Дополнительно для удобства управления всей этой распределенной Docker-инфраструктурой в локальный стек был добавлен Portainer. (+ Portainer Agent на удаленный сервер)

Из интересных моментов, где мне пришлось немного больше возиться, чем с остальными сервисами это nextcloud настройка:

Ошибки проектирования: почему я удалил Matrix (Synapse)

Не все решения прошли проверку временем. На этапе использования Tuna и FRP я развернул сервер Matrix (Synapse) для защищенного обмена сообщениями. Мне казалось это крутой идеей, но когда я окончательно перешел на AmneziaWG, целесообразность мессенджера внутри закрытого туннеля сошла на нет.

Synapse требовал слишком много ресурсов, впустую расходовал оперативку домашнего ПК и усложнял конфиг Nginx. При этом реальной пользы для семьи он не приносил. Для критических алертов инфраструктуры и повседневного общения проще и эффективнее оказалось использовать Telegram. (плюс алертинг настроен именно через него) В итоге я полностью выпилил Synapse из стека, освободив ресурсы.

Вместо него я добавил в связку к wg-easy локальный AdGuard Home. Теперь он работает прямо внутри VPN-сети: очищает весь трафик от рекламы и трекеров на лету, кэширует DNS-запросы и не дает истории веб-серфинга улетать внешним провайдерам.

Основной проблемой с которой я столкнулся при использовании AdGuard Home, так это то что я так и не понял как заставить использовать AmneziaVPN клиент AdGuard как основной DNS, при этом AmneziaWG работает прекрасно. Как я понимаю дело в том что AmneziaWG работает намного проще на уровне ip и у него нету никаких доп фильтров, настроек и подобного, поэтому он просто берет данные из конфига.

От костылей на Bash к декларативному Ansible

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

Так я пришел к декларативному подходу и Ansible. Теперь вся конфигурация описывается в виде плейбуков и ролей, отражающих конечное желаемое состояние серверов. Конфиденциальные данные перенесены в файл secrets.yml, а хрупкие конструкции автоматизированы через шаблоны Jinja2. Проект стал идемпотентным: если шаги уже выполнены, Ansible их просто пропускает.

В итоге получилось несколько yaml файлов для стандартной настройки системы (bootstrap_os.yml) и для настройки каждого из хостов (setup_local.yml и setup_remote.yml). В итоге теперь все что нужно чтобы полностью с нуля развернуть проект - скачать Ansible, несколько других зависимостей на свой рабочий пк и запустить один manage_deploy.sh, в котором можно будет выбрать сценарий как будет вести себя Ansible и спокойно дождаться разворачивания сервисов.

Также благодаря Ansible я удобно реализовал переносимость проекта. Так как я решил не использовать тома docker, и вместо этого храню все в папках, чтобы перенести старые данные проекта нужно просто скопировать папку apps-data и положить ее в нужное место и все само заработает после повторного развертывания проекта. В Ansible выделяется отдельная пауза для этого.

Вот пример основного плейбука deploy.yml:

Тестирование мультидистрибутивности с помощью Vagrant

Проект изначально затачивался под работу на трех дистрибутивах: Ubuntu, Debian и Arch Linux. Тестировать Ansible-плейбуки прямо на рабочей локальной машине (в моем случае — EndeavourOS) слишком рискованно, а создавать виртуальные машины руками — долго и неудобно.

Решением стал Vagrant, позволяющий за пару минут развернуть чистые ОС в VirtualBox из готовых образов. Но в процессе настройки мультивендорного стенда в режиме сетевого моста (public_network) всплыли две критические проблемы:

1. Конфликт DNS: По умолчанию Vagrant создает NAT-интерфейс для управления нодой. При включении второго (публичного) интерфейса для локальной сети ломался дефолтный DNS-резолвер. Проблему пришлось решать принудительной очисткой и перезаписью файла /etc/resolv.conf через inline-скрипт автоматизации Vagrant.
2. Проблема с GRUB на Debian: В используемом базовом образе generic/debian12 конфигурация GRUB сохраняла жесткую привязку к конкретному имени диска из окружения сборщика. При повторном развертывании плейбуков на тестовом стенде это приводило к сбоям загрузчика. Чтобы автоматизировать очистку, пришлось внедрить скрипт, который на лету определяет имя системного диска через lsblk и автоматически передает правильные параметры в загрузчик через утилиту debconf-set-selections.

Вот код Vagrantfile: (в node.vm.provision происходит основное решение ошибок)

Надежная система бэкапов на базе BorgmaticДля создания резервных копий я внедрил Borgmatic (удобную надстройку над дедуплицирующим инструментом Borg Backup). Весь процесс автоматизирован с помощью связки системных юнитов borgmatic.service и borgmatic.timer. В бэкап уходят две ключевые директории: apps-data (конфигурации приложений и баз данных) и PersonalData (медиатека: музыка, книги, подкасты, файлы Nextcloud).

Развертывание системы бэкапов полностью берет на себя Ansible. Мне достаточно указать UUID внешнего жесткого диска — скрипт сам проверит его наличие в системе, примонтирует в нужную директорию, создаст зашифрованный репозиторий и настроит политику ротации (хранение 7 ежедневных, 4 еженедельных и 6 ежемесячных копий). Также в Prometheus выведен мониторинг самого репозитория .borg для отслеживания его размера и статуса успешности архивации.

Главная проблема при бэкапе работающих Docker-контейнеров — риск скопировать базу данных в «битом» или неконсистентном состоянии, если в момент создания архива в нее шла активная запись. Чтобы решить эту проблему, я задействовал механизм хуков в конфигурации Borgmatic.

Перед началом резервного копирования автоматически срабатывает команда остановки контейнеров проекта (docker-compose down), а после успешного завершения (или в случае возникновения непредвиденной ошибки) контейнеры автоматически поднимаются обратно в фоновом режиме. Для удобного просмотра архивов и быстрого восстановления файлов я развернул веб-интерфейс Borg UI.

Конфигурация borgmatic: (использую как Jinja2 шаблон, чтобы Ansible в плейбуках сам подставил переменные)

Наблюдаемость (Observability) уровня Enterprise

В последних релизах (v1.2.0 и v1.3.0) фокус проекта сместился на мониторинг и работу с логами.

Эволюция алертинга и переход на Gatus

Изначально для мониторинга доступности я смотрел на Uptime Kuma, но отказался из-за отсутствия удобной декларативной настройки через конфиги. Затем я развернул связку Blackbox Exporter и Alertmanager с уведомлениями в Matrix. Но тут крылась логическая несостыковка: весь алертинг был завязан на локальном ПК, и в случае его аппаратного отказа я бы просто лишился уведомлений.

Тогда я решил вернуть Uptime Kuma, но развернуть его на удаленном VPS в качестве внешнего «сторожа» и автоматизировать его настройку через Python-скрипт с библиотекой uptime-kuma-api. Но и тут ждали «грабли» — библиотека не обновлялась три года и намертво ломалась на свежих версиях Kuma.

В итоге идеальным решением стал Gatus. Он изначально проектировался под управление через YAML-конфиги и поддерживает отправку алертов, если сервер не отвечает. Из-за специфики фронтенда Gatus (он не умеет работать из подкаталога типа /gatus), мне пришлось перенести его и wg-easy на полноценные субдомены gatus. и wireguard.

Для Gatus получился простой конфиг:

Для мониторинга аппаратных ресурсов удаленного и локального серверов была развернута связка node-exporter + cAdvisor. Все уведомления теперь приходят мгновенно в Telegram-бота. Чтобы избежать лавины одинаковых сообщений (например, при перезагрузке хоста), в Alertmanager настроена жесткая группировка и дедупликация событий. Также добавлен экспортер для AdGuard Home, выводящий статистику заблокированных запросов в Grafana.

Централизованные логи: Loki + Grafana Alloy

В релизе v1.3.0 в стек была добавлена централизованная система сбора логов Loki. Вместо устаревшего Promtail в качестве агента сбора я применил Grafana Alloy.

Он эффективно собирает логи со всех запущенных Docker-контейнеров, парсит их и передает в Loki. Теперь вся история событий, ошибок веб-сервера Nginx или падений внутренних приложений доступна в едином интерфейсе Grafana с возможностью удобной фильтрации через LogQL, что значительно упрощает отладку.

Конфиг Loki:

Конфиг Grafana Alloy: (локальный конфиг)

Интерфейс: переход на Homepage

Изначально для домашней страницы я написал кастомную минималистичную HTML-панель с Glassmorphism-дизайном. Выглядело это красиво, но добавлять новые сервисы вручную через постоянную правку исходного кода было крайне неудобно.

В итоге я заменил самописную страницу на полноценный комьюнити-проект Homepage. Это дало некоторую гибкость: вся панель настраивается через простые YAML-файлы и поддерживает встроенные виджеты интеграции. Пока что она простенькая, но возможно в будущем сделаю что-то более продвинутое.

Заключение

Постарался подробно рассказать о структуре проекта и как я к этому пришел, очень много я не добавил, если пост зайдет, то я обязательно более подробно пройдусь по некоторым моментам: как я настраивал Matrix и на каком моменте я решил его убрать, как собирал локальный amnezia контейнер-клиент, что нового я добавил в релизе 1.4.0 и другое.

Также я перешел с manage_deploy.sh на отдельный GUI клиент, который будет полностью автоматизировать процесс подготовки к deploy. (написан на Go Wails). Про это тоже возможно сделаю статью.

Вся кодовая база проекта, подробная документация, инструкции по развертыванию открыты и доступны для сообщества:

🔗 GitHub-репозиторий: https://github.com/canntstand/ServeHub-2

Это моя первая статья на этом сайте и в то же время первый личный проект, которому я отдал так много времени (3 месяца). Буду рад вашему фидбеку в комментариях!

SafeLine WAF — это бесплатный инструмент, который я лично тестировал.

Это полностью open-source решения, продукт с действительно бесплатной Community Edition, где ключевые функции не урезаны.

SafeLine WAF — веб-приложенийный межсетевой экран, который действительно поставляется с разумными настройками по умолчанию

Что он делает:

Защищает веб-приложения от SQL-инъекций, XSS-атак, командных инъекций, CSRF, SSRF, атак включения файлов и других угроз из списка OWASP Top 10. Также поддерживает защиту от CC/DDoS-атак, управление ботами и может работать как шлюз аутентификации.

Почему он:

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

SafeLine использует другой подход — вместо того чтобы полностью полагаться на сигнатурное обнаружение, он применяет движок семантического анализа, который фактически анализирует и понимает входящие HTTP-запросы. Это позволяет добиться более высокого уровня обнаружения при значительно меньшем количестве ложных срабатываний по умолчанию.

Некоторые показатели, которые стоит учитыват

1. Уровень обнаружения - SafeLine (Balanced) (71.65%), ModSecurity (Level 1) (69.74%), Cloudflare (Free) (10.7%)
2. Уровень ложных срабатываний - SafeLine (Balanced) (0.07%), ModSecurity (Level 1) (17.58%), Cloudflare (Free) (0.07%)
3. Точность - SafeLine (Balanced) (99.45%), ModSecurity (Level 1) (82.20%), Cloudflare (Free) (98.40%)

Сбалансированный профиль SafeLine обнаруживает более 70% атак, при этом блокируя легитимный трафик ошибочно всего в 0.07% случаев. Это именно тот уровень настроек по умолчанию, который можно использовать в промышленной среде без постоянного ручного контроля.

Установка выполняется одной командой

После запуска он разворачивается как набор Docker-контейнеров: Tengine (форк Nginx) используется в качестве reverse proxy, отдельный сервис отвечает за семантический анализ, PostgreSQL хранит конфигурации и логи, а удобная веб-панель администратора работает на порту 9443.Community Edition поддерживает до 10 сайтов, чего достаточно для большинства личных проектов и небольших бизнес-сценариев.

Сайт: https://cyberserval.tech/landing/safeline

GitHub: github.com/chaitin/SafeLine (более 21 тыс. звёзд)

Лицензия: GPL-3.0 / MIT (Community Edition)

Выход — поднять собственное S3-совместимое хранилище на том же VPS, где крутится staging. MinIO реализует API Amazon S3, понимает те же SDK и presigned URL, но стоит ровно столько, сколько стоит диск сервера. Один и тот же код приложения работает и с MinIO на dev, и с R2 в проде — меняются только переменные окружения.

Что такое MinIO и почему он подходит для staging

MinIO — это open-source сервер объектного хранилища, написанный на Go. Он поддерживает основные операции S3: бакеты, объекты, multipart upload, versioning, lifecycle, шифрование SSE-S3, CORS и IAM-политики. Для приложения он выглядит как обычный S3-эндпоинт, поэтому подходит почти любой SDK: AWS SDK, boto3, minio-js, aws-sdk-go.

На staging важно не столько масштабирование, сколько идентичность поведения продакшена. Если в проде R2 или S3, а в staging — локальная файловая система, вы тестируете не тот код. MinIO закрывает этот разрыв: тот же PutObjectCommand, те же presigned URL, те же ошибки SignatureDoesNotMatch.

• MinIO — полноценный S3-совместимый сервер, который можно развернуть в Docker на VPS за 10–15 минут.
• Для staging это экономия на хранении тестовых файлов и единый код с продакшеном.
• HTTPS и домен лучше отдавать reverse proxy — Traefik или NGINX — с Let’s Encrypt.
• Presigned URL позволяют загружать и скачивать файлы напрямую из браузера, не проксируя байты через бэкенд.
• Root-ключи MinIO нельзя отдавать приложению: создавайте отдельного пользователя с IAM-политикой только на нужный бакет.

Архитектура: прод против staging

В продакшене обычно используется управляемое хранилище: AWS S3, Cloudflare R2, Yandex Object Storage, Hetzner Object Storage. Там работают репликация, резервное копирование и чужой дежурный. В staging достаточно одного MinIO-контейнера на сервере с регулярным зеркалированием в дешёвое холодное хранилище.

Приложение не знает, с кем оно говорит: код инициализации клиента одинаков. Разница только в переменных окружения: эндпоинте, регионе, ключах и флаге forcePathStyle, который нужен большинству S3-совместимых сервисов, включая MinIO и R2.

Важно: виртуальный хостинг bucket.example.com в MinIO работает, но на staging проще включить path-style и не мучиться с DNS-записями под каждый бакет.

Что понадобится

• VPS с Linux, публичным IP и открытыми портами 80/443.
• Два A-записи: minio-staging.example.com и minio-console.example.com.
• Docker и Docker Compose v2.
• Reverse proxy с TLS — в примере Traefik v2 + Let’s Encrypt.
• Около 10 ГБ свободного места под тестовые данные.

Разворачиваем MinIO в Docker Compose

Минимальный docker-compose.staging.yml заводит один контейнер, внешнюю сеть для Traefik и именованный том для данных.

Два параметра критичны для presigned URL. MINIO_SERVER_URL говорит серверу, на каком публичном домене подписывать ссылки. Без него ссылка будет подписана для http://minio:9000 и браузер отклонит подпись. MINIO_BROWSER_REDIRECT_URL нужен для корректных редиректов веб-консоли.

Прокидываем HTTPS через Traefik

Добавляем лейблы к сервису minio, чтобы Traefik маршрутизировал API и консоль на разные порты и автоматически выпускал сертификаты.

Проверяем здоровье сервера с локальной машины: curl -I https://minio-staging.example.com/minio/health/live должен вернуть HTTP 200.

Cloudflare: для поддомена с API лучше выключить оранжевое облако. Бесплатный тариф Cloudflare обрезает тело запроса на 100 МБ и может убирать S3-заголовки, из-за чего ломается подпись.

Бакеты, политики и отдельный пользователь для приложения

После запуска создаём бакет и отдельного IAM-пользователя. Делать это root-ключами приложения — плохая идея: root может удалить всё.

Теперь создаём пользователя staging-app и IAM-политику, ограничивающую права только этим бакетом.

Логин staging-app и его секрет — это и есть S3_ACCESS_KEY и S3_SECRET_KEY для приложения.

Код приложения не меняется

Пример на AWS SDK v3 для Node.js. Обратите внимание на forcePathStyle: true: без него SDK попытается обратиться к bucket.minio-staging.example.com, и запрос уйдёт в никуда.

Переменные для staging:

Для продакшена — только другой набор значений, код идентичен.

Presigned URL: загрузка и скачивание без проксирования

Presigned URL — это обычный HTTPS URL с короткой подписью в query string. Кто угодно может выполнить ровно то действие, на которое выдана подпись: PUT для загрузки или GET для скачивания. Бэкенд проверяет права, подписывает URL и отдаёт клиенту — сам файл идёт напрямую в MinIO.

Загрузка из браузера

Важный подводный камень: Content-Type, который браузер отправляет при PUT, должен точно совпадать с тем, что было передано в PutObjectCommand. Иначе MinIO вернёт SignatureDoesNotMatch.

Скачивание приватных файлов

Почему это лучше проксирования: при прямой загрузке через ваше API все байты проходят через приложение, съедая CPU, RAM и пропускную способность. С presigned URL трафик идёт между клиентом и MinIO — бэкенд только подписывает ссылку.

CORS, lifecycle и безопасность

Несколько команд, которые стоит выполнить сразу после создания бакета.

CORS для браузерных загрузок

Автоудаление старых тестовых файлов

Шифрование данных в покое

И ещё раз: root-ключи храните в менеджере секретов и используйте только для mc admin. Консоль MinIO, если она доступна из интернета, закрывайте IP-allowlist или базовой авторизацией на уровне Traefik.

Бэкапы и мониторинг

Staging не должен хранить что-то ценное, но периодическое зеркалирование в дешёвое холодное хранилище спасает от случайного удаления. Команда mc mirror синхронизирует бакет в Backblaze B2, Yandex Object Storage или другой S3-совместимый бэкенд.

Для метрик MinIO отдаёт Prometheus-экспортёр по пути /minio/v2/metrics/cluster. В Grafana можно импортировать дашборд ID 13502 и сразу видеть занятое место, RPS, задержки и ошибки.

Типичные проблемы

• SignatureDoesNotMatch при PUT — браузер отправил Content-Type, отличный от подписанного. Проверьте заголовок PUT.
• Подписанная ссылка работает локально, но не в браузере — не задан MINIO_SERVER_URL. Ссылка подписана для внутреннего http://minio:9000.
• 403 после Cloudflare — бесплатный тариф Cloudflare модифицирует заголовки. Переведите A-запись в режим DNS-only.
• CORS preflight failed — на бакете не настроены CORS-правила.
• Консоль редиректит на http://minio:9001 — не задан MINIO_BROWSER_REDIRECT_URL.

Выводы

Self-hosted MinIO на staging — это не попытка заменить облако, а способ сделать тестовую среду дешевле и ближе к продакшену. Тот же API, те же SDK, те же presigned URL, но без счетов за хранение битых файлов и ночных сбросов базы.

Ключевые моменты, которые стоит запомнить: всегда указывайте MINIO_SERVER_URL для корректных подписей, не используйте root-ключи в приложении, включайте path-style на staging и настраивайте lifecycle, чтобы мусор не копился.

Самое дорогое в staging — не железо, а различия в кодовых путях между dev и prod. MinIO помогает убрать одну из этих разниц почти бесплатно.

Источник: freeCodeCamp — How to Self-Host an S3-Compatible Object Store with MinIO on Your Staging Server.

Написать оператор можно на Go с помощью operator-sdk: сгенерировать скелет проекта, определить CRD, реализовать Reconcile и задеплоить в кластер. В этой статье разберём паттерн Operator и соберём рабочий оператор, который создаёт Deployment и Service по декларативной спецификации, отслеживает дрейф конфигурации и мгновенно откатывает несанкционированные изменения.

Оператор Kubernetes — это пользовательский контроллер, который расширяет API кластера собственными ресурсами (CRD) и непрерывно приводит фактическое состояние к желаемому.

Шаблон Reconcile — Observe → Create → Correct → Report — лежит в основе любого оператора: контроллер наблюдает, создаёт недостающее, исправляет отклонения и сообщает статус.

С помощью operator-sdk и kubebuilder-меток можно сгенерировать скелет проекта, CRD и RBAC-манифесты, не писать boilerplate вручную.

Owner Reference связывает дочерние ресурсы с родительским кастомным ресурсом (CR): при удалении WebApp Kubernetes автоматически уберёт связанные Deployment и Service.

Обновление статуса через Status().Update() изолировано от основного ресурса и предотвращает бесконечные циклы реконсиляции.

Почему стандартных примитивов Kubernetes не хватает

Kubernetes предоставляет мощный набор базовых абстракций: Pod, Deployment, StatefulSet, Service, Ingress. Они отлично справляются с запуском контейнеров, балансировкой трафика и базовым масштабированием. Однако эти примитивы агностичны к бизнес-логике приложения.

Представьте, что вам нужно развернуть production-grade кластер PostgreSQL. Помимо самих подов с базой, потребуются: инициализация репликации, управление резервными копиями, обновление версий без простоя, автоматическое переключение при отказе мастера. Всё это — операционная экспертиза, которую DevOps-инженеры накапливают годами. Оператор превращает эту экспертизу в автоматизированный контроллер, который круглосуточно следит за ресурсом и принимает решения.

Сегодня операторы де-факто стали стандартом для управления сложными stateful-приложениями в Kubernetes: от баз данных и брокеров сообщений до сервисных mesh и CI/CD-систем. Концепция была сформулирована инженерами CoreOS ещё в 2016 году, а сейчас поддерживается Cloud Native Computing Foundation (CNCF) как ключевой паттерн платформенной инженерии.

Архитектура оператора: CRD, Reconciler и control loop

Любой оператор состоит из двух ключевых компонентов:

• Custom Resource Definition (CRD) — расширение API Kubernetes, которое определяет новый тип ресурса со своей схемой Spec (желаемое состояние) и Status (фактическое состояние).
• Контроллер (Reconciler) — программный цикл, который постоянно сравнивает Spec и Status, а затем выполняет действия для их сближения.

Контроллер не работает по принципу «выполнил шаги и вышел». Вместо этого он реализует control loop: каждую итерацию можно запускать снова и снова — результат не сломается, потому что код сравнивает «что есть» с «что нужно» и корректирует только расхождения. Это критически важно, потому что события в распределённой системе приходят асинхронно, а состояние объекта могло измениться за время обработки предыдущего события.

Создаём проект с operator-sdk

Вручную писать весь boilerplate контроллера — неэффективно. Инструмент operator-sdk (основанный на Kubebuilder) генерирует стандартную структуру проекта Go, включая точку входа main.go, Makefile с целями для сборки и тестирования, а также инфраструктуру для управления CRD.

Инициализируем проект и создаём API с контроллером:

Флаг --resource сгенерирует Go-структуры, описывающие схему пользовательского ресурса. Флаг --controller создаст шаблон reconciler'а — файла, в котором мы будем писать логику управления.

Определяем схему CRD

Откроем api/v1/webapp_types.go. Здесь мы описываем два структурных блока: WebAppSpec — то, что задаёт пользователь в YAML-манифесте, и WebAppStatus — то, что оператор сообщает о текущем состоянии.

Важнейшая часть — kubebuilder-маркеры над основной структурой:

Маркер +kubebuilder:subresource:status сообщает Kubernetes, что для этого ресурса нужен отдельный endpoint /status. Без него любое обновление статуса будет восприниматься API-сервером как изменение всего объекта, что вызовет каскадную реконсиляцию и может привести к бесконечному циклу.

Маркеры +kubebuilder:printcolumn настраивают вывод команды kubectl get webapps: вместо голого имени ресурса пользователь увидит фазу, желаемое и доступное количество реплик.

Reconciler: сердце оператора

Файл internal/controller/webapp_controller.go содержит функцию Reconcile — точку входа в control loop. Перед ней размещаются RBAC-маркеры, которые генерируют манифесты прав доступа при выполнении make manifests:

Без этих маркеров оператор не получит прав на чтение и запись стандартных ресурсов Deployment и Service, и при запуске в кластере упадёт с ошибкой доступа. Разберём функцию Reconcile по шагам.

Шаг 1. Получение актуального состояния

Reconciler получает не сам объект, а лишь его имя и пространство имён. Это архитектурное решение Kubernetes: между постановкой события в очередь и его обработкой объект мог измениться. Поэтому первое действие — всегда запросить свежую версию ресурса из API.

Здесь apierrors импортируется из пакета k8s.io/apimachinery/pkg/api/errors, а ctrl — из sigs.k8s.io/controller-runtime.

Шаг 2. Реконсиляция Deployment

Сначала проверяем, существует ли связанный Deployment. Если нет — создаём его через вспомогательную функцию deploymentForWebApp.

Вызов return ctrl.Result{Requeue: true}, nil ставит событие обратно в очередь: контроллер немедленно перезапустит Reconcile для того же объекта, чтобы продолжить с следующего шага. Это удобнее, чем ждать следующего внешнего события.

Вот как выглядит функция deploymentForWebApp:

Owner Reference — это механизм garbage collection в Kubernetes. Когда пользователь удаляет ресурс WebApp, кластер автоматически удалит все дочерние объекты, на которые ссылается поле ownerReferences. Без этой связи после удаления кастомного ресурса в кластере останутся «зомби»-поды и сервисы.

Шаг 3. Обнаружение дрейфа конфигурации

Если Deployment уже существует, мы не просто идём дальше — сравниваем желаемое и фактическое состояние. Это и есть то, что отличает оператор от одноразового скрипта.

Представьте, что кто-то из команды в обход оператора выполнил следующую команду или подменил образ на уязвимую версию. Оператор мгновенно фиксирует расхождение и принудительно возвращает ресурс к значениям, заданным в WebApp.Spec.

Шаг 4. Реконсиляция Service

С вычислительным слоем разобрались — теперь нужен сетевой доступ. Логика полностью идентична: проверяем наличие Service, создаём при отсутствии, устанавливаем Owner Reference. Для локального тестирования в Minikube используем тип NodePort.

Вспомогательная функция serviceForWebApp строит объект Service с нужными селекторами и портами:

Шаг 5. Обновление статуса

Последний шаг — сообщить пользователю текущее состояние приложения через status subresource. Здесь критически важно использовать именно r.Status().Update(), а не r.Update().

Разделение основного endpoint ресурса и subresource /status — фундаментальное свойство Kubernetes. Оно гарантирует, что обновление статуса не триггерит новое событие изменения ресурса и, соответственно, не запускает бесконечную реконсиляцию.

Тестирование: как проверить, что оператор работает

Для локального тестирования подойдёт Minikube. Запускаем оператор в одном терминале, а в другом — создаём кастомный ресурс.

Проверяем, что оператор создал инфраструктуру и отчитался о статусе:

Демонстрация: откат несанкционированных изменений

Главная ценность оператора — самовосстановление. Сымитируем вмешательство: масштабируем Deployment в обход кастомного ресурса.

Мгновенно в логах контроллера появляется сообщение:

Лог оператора:
INFO Drift detected! Updating Deployment {"DesiredReplicas": 3, "ActualReplicas": 10}

А через несколько секунд избыточные поды начинают завершаться:

В это время статус WebApp отражает промежуточное состояние Scaling, а после полного схождения — автоматически переключается обратно на Running.

Когда операторы необходимы, а когда избыточны

Не каждому приложению нужен собственный оператор. Для stateless-сервисов, которые достаточно описать парой манифестов Deployment + Service, оператор будет накладным расходом. Однако есть категории систем, где без оператора не обойтись:

• Базы данных — PostgreSQL, MySQL, MongoDB, etcd: репликация, бэкапы, обновления, failover.
• Брокеры сообщений — Kafka, RabbitMQ, NATS: управление партициями, топиками, кластерной топологией.
• Сетевые компоненты — Ingress-контроллеры, service mesh: динамическая маршрутизация и политики безопасности.
• CI/CD и GitOps — Tekton, Argo CD: оркестрация пайплайнов и синхронизация состояния кластера с репозиторием.

В российской инфраструктурной практике операторы активно используются в Managed Kubernetes от крупных облачных провайдеров. Например, в Яндекс Облаке операторы лежат в основе managed-сервисов баз данных, обеспечивая автоматизацию резервного копирования, мониторинга и масштабирования.

Выводы

Паттерн Operator — это не просто модное слово в экосистеме Kubernetes, а проверенный подход к автоматизации эксплуатации сложных приложений. Вместо того чтобы полагаться на runbook'и и ручные действия инженеров, оператор кодирует операционную экспертизу в программу, которая работает круглосуточно, не устаёт и не забывает проверить важный шаг.

В этой статье мы прошли полный путь: от генерации скелета проекта через operator-sdk до работающего контроллера, который создаёт инфраструктуру, отслеживает дрейф конфигурации и автоматически восстанавливает желаемое состояние. Ключевые навыки — понимание асинхронной природы control loop, правильное использование Owner Reference и изолированное обновление статуса — применимы далеко за рамками Kubernetes.

Оператор — это не магия, а дисциплина. Каждая итерация Reconcile — это честный вопрос: «Что должно быть?» против «Что есть сейчас?». Ответить на него правильно — значит построить надёжную систему.

Полный код проекта доступен в репозитории автора оригинального туториала: SandeshOjha06/k8-operator. Если вы планируете развиваться в направлении platform engineering или SRE, умение писать и отлаживать собственные контроллеры станет серьёзным конкурентным преимуществом.

Источники:

• Building a Kubernetes Operator from Scratch with Operator SDK — оригинальный туториал Сандеша Оджха.
• Kubernetes Operators — официальная документация Kubernetes.
• Operator SDK — фреймворк для разработки операторов.
• The Kubebuilder Book — руководство по построению Kubernetes API и контроллеров.

Если верить статистике, сейчас ежедневно создается около 402,74 миллионов терабайт данных.

Согласитесь, довольно внушительная цифра.

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

Меня зовут Оксана, я маркетолог в Beget и в этой статье хочу поделиться решением, которое мы выбрали у себя в отделе для хранения файлов, когда заметили, что их стало слишком много.

Мы решили перейти на гибкое объектное хранилище S3 – чтобы централизовано хранить и управлять текстами, креативами, отчетами и другими маркетинговыми материалами с удобным доступом внутри команды, ведь S3 позволяет хранить файлы любого типа и объема и масштабируется автоматически. Осталось только выбрать ПО для хранения файлов в облаке, к которому можно подключить S3.

Ранее у нас был опыт использования Nextcloud, однако его функционал, подобный швейцарскому ножу (встроенные календарь, конференции, таск-трекер и т. д.), оказался слишком объемен для нашей, по сути, скромной задачи – удобного и стабильного хранения файлов.

Вот почему мы подыскали аналог Nextcloud – ownCloud. В отличие от более функционального Nextcloud, ownCloud заточен исключительно на работу с файлами. И при этом он поддерживает подключение облачного объектного хранилища S3. Поэтому для нас в сравнении Nextcloud vs ownCloud выбор был очевиден.

В этой статье я расскажу, какие возможности есть у ownCloud, почему это ПО может быть полезно и как настроить связку ownCloud и S3. Если вы хотите организовать безопасное, контролируемое хранение и обмен данными на работе или дома, то этот материал будет для вас полезен.

Что может ownCloud

Для начала – буквально несколько слов об ownCloud и его возможностях.

Это программное обеспечение с открытым исходным кодом для хранения, синхронизации и обмена файлами появилось в 2010 году благодаря усилиям разработчика KDE Франка Карличека, который стремился создать бесплатную альтернативу коммерческим облачным сервисам хранения данных.

OwnCloud позволяет:

1. получать доступ к данным из любой точки мира и хранить файлы на собственном сервере – под вашим полным контролем;
2. синхронизировать данные между устройствами – доступ к файлам возможен с компьютеров (Windows, macOS, Linux), смартфонов (iOS, Android) и через браузер, изменения на одном устройстве мгновенно появляются на всех остальных;
3. делиться файлами и папками по ссылке, настраивая права доступа, пароли и срок действия ссылок;
4. совместно работать с документами, отслеживать историю изменений и возвращаться к любой предыдущей версии файла.

Только ownCloud сочетает в себе полный контроль над данными с простыми в использовании функциями обмена файлами, делая совместную работу более эффективной и безопасной.

Сегодня ownCloud используют компании (Philips, Nationwide, Zeppelin и др.) в самых разных сферах (IT, машиностроение, медицина и т. д.).

При этом решение подходит не только для работы, но и для личных целей, когда нужно обменяться фото и видео с родственниками и друзьями, ведь, по мнению пользователей, среди преимуществ ownCloud – простота настройки и удобная синхронизация с различными гаджетами.

С ownCloud мне не нужно слепо доверять какой-то неопределенной организации. Я контролирую, как происходит обмен файлами, и ownCloud помогает мне на каждом этапе.

OwnCloud позволяет решать самые разные задачи, связанные с работой с файлами, – расскажем на примере трех кейсов, как это облачное хранилище помогает нам в отделе маркетинга.

Для каких задач мы используем ownCloud и S3

1. Централизованное управление материалами

Мы часто работаем с текстами, изображениями и презентациями. Дизайнеры и авторы загружают эти материалы в ownCloud, файлы автоматически сохраняются в S3, а для удобства поиска у нас настроены теги.

В итоге каждый член команды может видеть версии файлов (это важно для правок), нет хаоса в почте и мессенджерах.

2. Безопасное взаимодействие с подрядчиками

Связка ownCloud и S3 позволяет выгружать внешним специалистам материалы и получать результаты работ без прямого доступа к внутренней сети компании. Мы создали папку с публичной ссылкой, но жесткими ограничениями – паролем, сроком жизни ссылки в течение нескольких дней и разрешением на загрузку файлов без права просмотра папки.

На практике это работает так: менеджер создает ссылку и отправляет подрядчику, подрядчик переходит по ссылке и загружает архив с готовыми материалами, файл попадает в ownCloud, а его содержимое сохраняется в S3. Таким образом, подрядчик не видит, какие еще файлы лежат в папке, а мы контролируем, кто, что и когда загрузил.

3. Долгосрочный архив креативов и отчетов

По закону (152-ФЗ в РФ или GDPR в Европе) компания обязана хранить персональные данные клиентов, а также отчеты о рассылках и рекламных акциях на протяжении определенного времени.

Для решения этой задачи мы настроили правило: файлы старше 90 дней автоматически перемещаются в S3 Glacier (холодное хранилище) – этот класс снижает стоимость хранения, а если, например, юристу понадобится скачать какой-нибудь отчет спустя 2–3 года, он просто выгрузит его из ownCloud буквально за 5–10 минут.

Теперь – в деталях и по шагам о том, как начать использовать ownCloud в связке с S3.

Как развернуть ownCloud и подключить S3

OwnCloud удобно использовать с объектным хранилищем S3 – таким образом можно:

1. масштабировать систему – S3 расширяется автоматически и не имеет ограничений по объему и количеству размещаемых данных и файлов;
2. оптимизировать затраты – можно платить не за дорогую конфигурацию виртуального сервера с большим объемом диска, а лишь за фактически занимаемое место, по модели pay as you go (оплата по мере потребления);
3. повысить надежность хранения – за счет встроенной в S3 тройной репликации данных (файлы хранятся в 3 копиях и размещаются на независимых серверах в разных стойках для абсолютной сохранности данных).

Итак, разберем, как настроить связку ownCloud и S3.

Разработчики ownCloud предлагают два варианта установки. Можно скачать ownCloud и установить его вручную или использовать Docker-контейнеры. Мы выберем второй вариант.

Для размещения ownCloud в нашем примере создадим виртуальный сервер на базе готового решения Docker.

Можно подключиться к серверу по SSH или с помощью терминала в панели управления.

Для размещения файлов создайте бакет объектного хранилища S3. Реквизиты доступа к нему будут в карточке бакета в панели:

Создайте директорию для размещения конфигурационных файлов проекта и перейдите в нее:

Затем вставьте в файл docker-compose.yml следующее содержимое с помощью любого текстового редактора:

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

Теперь необходимо отредактировать эти строки:

1. ownCloud_DOMAIN и ownCloud_TRUSTED_DOMAINS – укажите домен (так как ownCloud будет размещен за обратным прокси, указывать рабочий порт здесь не требуется);
2. ADMIN_USERNAME – логин администратора;
3. ADMIN_PASSWORD – пароль администратора.

Обратите внимание! Изменение ADMIN_USERNAME и ADMIN_PASSWORD уже после развертывания контейнеров не возымеет эффекта. Изменить пароль администратора вы можете в настройках пользователя в веб-интерфейсе.

Далее необходимо указать параметры подключения к S3.

• ownCloud_OBJECTSTORE_BUCKET – имя бакета S3;
• ownCloud_OBJECTSTORE_ENDPOINT – эндпоинт хранилища (например, https://s3.ru1.storage.beget.cloud);
• ownCloud_OBJECTSTORE_REGION – регион (ru1 для Beget);
• ownCloud_OBJECTSTORE_KEY – Access key бакета;
• ownCloud_OBJECTSTORE_SECRET – Secret key бакета.

Сохраните файл.

Остается лишь добавить файл конфигурации для Caddy – обратного прокси, через который пользователи будут получать доступ к ownCloud.

Создайте директорию config:

После чего создайте в ней файл конфигурации Caddyfile. Добавьте в него следующее содержимое, указав вместо ownCloud.betutorial.ru ваш домен ownCloud:

Обратите внимание! Caddy выпустит SSL-сертификат на домен автоматически.

Все запросы к домену будут проксироваться в контейнер ownCloud_server.

На этом настройка конфигурационных файлов завершена, можно запускать контейнеры:

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

После запуска перейдите по домену, чтобы проверить работу хранилища:

Выполните вход со стандартными доступами.

Обратите внимание! Если ownCloud недоступен или вы получаете ошибку при входе со стандартными доступами, проверьте корректность конфигурационных файлов. После внесения изменений перезапустите контейнеры.

После входа вы попадете на главную страницу ownCloud. Перед началом работы мы крайне рекомендуем сменить стандартный пароль администратора. Сделать это можно, нажав на кнопку с именем пользователя в верхней правой части страницы и открыв раздел настроек.

Теперь проверим работу объектного хранилища – перейдем на главную страницу и загрузим файлы:

Файлы также появились и в объектном хранилище:

Обратите внимание! Файлы, которые вы удалите в ownCloud, будут перемещены в корзину и останутся в S3. Для их полного удаления очистите корзину ownCloud.

Чтобы делиться паролями с новыми пользователями, необходимо настроить отправку почты в ownCloud, сделать это можно в разделе Settings>General.

В нашем примере мы настроим отправку через SMTP:

После указания данных введите тестовый email и нажмите “Send email”. Если отправка успешна, вы получите уведомление об этом:

А на почтовый ящик поступит письмо:

На этом настройка завершена – можно начинать работать с файлами, используя связку ownCloud и S3.

Заключение

Если вы ловите себя на мысли, что данных стало настолько много, что поиск нужного файла порой происходит дольше, чем работа с ним (особенно если одни файлы хранятся на почте или в мессенджере, а другие – на ноутбуке или флешке), облачное хранилище может вам помочь.

Подобное ПО пригодится как для личных целей, так и для бизнеса – недаром в 2025 году в нашей стране был зафиксирован рост интереса крупного и среднего бизнеса к технологии облачного хранилища.

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

Однако недавно проект получил второе дыхание. Разработчик Александр Тишов (Amro) — создатель CMS Seditio и основатель веб-студии «Авего» — выпустил Denwer SE (Second Edition). Это не просто обновление, а полный реинжиниринг с сохранением классической философии: портативность, скорость работы и привычная структура каталогов.

В этой статье разберём, что изменилось под капотом, почему панель управления переехала с Perl на Python, как работает автоматический HTTPS с собственным корневым сертификатом и зачем нужен зоопарк версий PHP от 5.6 до 8.5.

Краткий экскурс: от Denwer 3 до Denwer SE

Оригинальный Denwer (сокращение от Джентельменский Набор Веб-разработчика) появился в начале 2000-х. Он представлял собой связку Apache + PHP + MySQL, упакованную в самораспаковывающийся архив. Главные фишки:

• Виртуальный диск (по умолчанию Z:), который монтировался через subst.
• Автоматическое создание виртуальных хостов по именам папок в home.
• Консольные exe-файлы (Run, Stop, Restart) без графического окна.

Проблемы оригинала:

• Управление на Perl — медленно, тяжело поддерживать в Windows.
• Только 32-битные компоненты.
• Невозможно быстро переключать версии PHP или БД.
• Отсутствие нормального HTTPS (только самоподписанные сертификаты с ошибками в браузере).
• Поддержка прекратилась в 2016 году.

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

Архитектура: Python вместо Perl

Denwer SE — панель управления написана на Python и скомпилирована в один EXE-файл (через PyInstaller).

Внутри служебной папки denwer\ лежат:

• DLL-версия Python — интерпретатор, который использует основной исполняемый файл.
• Скомпилированные модули .pyd — в том числе GUI на базе Tcl/Tk для оконного интерфейса и системного трея.
• Минимальный набор библиотек для управления службами, правки hosts и генерации сертификатов.

Это даёт несколько преимуществ:

• Портативность — панель ищет соседние папки home и usr, поэтому каталог со стеком можно переносить куда угодно без переустановки.
• Скорость — Python-скрипты запускаются быстрее, чем Perl, особенно на холодном старте.
• Читаемость кода — разработчику проще поддерживать и расширять функционал.

Полный переход на x64

Оригинальный Denwer навсегда остался 32-битным, что в современных реалиях просто неприемлемо. Denwer SE собирается исключительно под x64:

• Apache (версия 2.4.x) — 64-битный.
• Все модули PHP (от 5.6 до 8.5) — Thread Safe x64.
• MySQL / MariaDB — 64-битные сборки.

Системные требования — Windows 7/8/10/11 (x64). Для работы компонентов потребуются Microsoft Visual C++ Redistributable (VC11, VC12, VC14, VC15). Разработчик положил установщики этих пакетов в папку vcredist\ — при необходимости можно доустановить вручную.

Структура каталогов: преемственность и гибкость

Denwer SE сохранил классическую структуру, чтобы старые пользователи не ломали голову:

Главный конфиг — usr\configuration.txt. В нём задаются пути без жёсткой привязки к букве диска, например:

При старте панель монтирует виртуальный диск (по умолчанию Z:) и динамически подставляет путь через переменную subst_drive.

Управление версиями PHP и БД без танцев с бубном

В Denwer SE встроен менеджер версий. Вы просто выбираете из выпадающего списка нужную версию PHP (например, 8.3 или 5.6) — панель сама правит конфигурацию Apache.

Как это работает под капотом:

В папке usr/local/apache/php лежат подкаталоги php5.6, php7.4, php8.3 и т.д..

В каждом из них есть файл php-denwer.conf— шаблон для подключения модуля к Apache. При выборе версии этот файл копируется в conf/extra/httpd-denwer.conf, который затем включается в основной httpd.conf.

Если вы хотите добавить свою сборку PHP (например, PHP 8.4-rc), достаточно:

• Распаковать x64 Thread Safe версию в отдельный каталог внутри php\.
• Создать php-denwer.conf по образцу.
• Убедиться, что все DLL от VC++ установлены.

Аналогично для баз данных: переключение между MySQL 5.7 и MariaDB 11.8 происходит через тот же интерфейс. В каталоге СУБД может лежать файл db-denwer.conf, который при старте копируется в my.ini.

HTTPS, который не бесит: локальный Root CA

Самое болезненное место при локальной разработке это самоподписанные сертификаты. Браузеры постоянно ругаются, приходится кликать «Принять риск». Для командной разработки это вообще катастрофа: каждый участник должен сгенерировать свой сертификат и добавить в исключения.

Denwer SE решает проблему элегантно — он создаёт собственный корневой центр сертификации (CA) и подписывает им сертификаты для всех ваших локальных доменов.

Как это работает:

1. При первом запуске (если найден OpenSSL) панель генерирует ключи denwer-ca.key и сертификат denwer-ca.crt в папку usr/local/apache/conf/cert/denwer-ca/.
2. Для каждого виртуального хоста (папки в home/) автоматически создаётся сертификат в conf/cert/<domain>/.
3. Все сертификаты хостов подписаны локальным CA.

Чтобы браузер доверял им, нужно один раз установить denwer-ca.crt в хранилище «Доверенные корневые центры сертификации» Windows. Для этого в панели есть специальная кнопка (требует прав администратора).

После этого любые HTTPS-запросы к локальным хостам работают без единого предупреждения.

Удобства для разработчика (DX)

В версии 1.2.4 добавили несколько фич, которые экономят время каждый день:

• Лог с таймштампами — каждая строка в окне панели имеет префикс [чч:мм:сс]. Теперь видно, сколько секунд сервер поднимается и где возможны задержки.
• Прямой доступ к php.ini и my.cnf — рядом со списками версий появились кнопки, открывающие конфигурацию именно активной версии.
• Автоматическое ведение hosts — панель в реальном времени сканирует home/, находит новые домены и прописывает их в C:\Windows\System32\drivers\etc\hosts. Журнал добавляемых записей сохраняется в usr\AddedHosts.txt. При остановке стека лишние строки удаляются.
• Для смены версии PHP или базы данных панель требует полной остановки всех служб. Вы нажимаете «Стоп», меняете версию в списке, затем «Старт» — и стек поднимается уже с новыми настройками. Автоматический перезапуск без вашего участия работает только для Apache: когда вы добавляете новый домен в папку home/, панель сама переписывает vhosts.conf и перезапускает веб-сервер, не трогая БД.

Почему не Open Server или Docker?

Этот вопрос закономерно возникает у всех, кто видит очередной локальный веб-сервер. Ведь есть уже давно Open Server Panel, Laragon, XAMPP, а для продвинутых — Docker. Зачем ещё один?

Open Server — мощный и удобный комбайн с десятками версий PHP и настройками «на века». Но он разворачивается в системе не портативно: создаёт папки в ProgramData, пишет в реестр, а запуск может занимать 5–10 секунд. Denwer SE, напротив, полностью переносим: скопировал папку на флешку или в облачный каталог — и всё работает. Запуск стека — буквально 1–2 секунды, что критично, когда вы десятки раз за день перезапускаете сервер для тестов.

Docker — индустриальный стандарт для изоляции и воспроизводимости окружений. Но для локальной разработки простого сайта он часто избыточен. Вам нужно разобраться в образах, контейнерах, пробросе портов, volume’ах и docker-compose.yml. А в Denwer SE вы просто создали папку в home/ — и готово. Никакой работы с командной строкой, никакого потребления гигабайт ОЗУ на фоновую службу Docker Desktop.

Laragon — быстрый, портативный, поддерживает не только PHP, но и Node.js, Python, Go. Но он ориентирован на современные фреймворки, особенно Laravel. Denwer SE же сделан для тех, кто вырос на классическом Денвере: виртуальный диск Z:, папка home/имя_домена/www, минимум настроек. Не нужно переучиваться — просто распаковал и работаешь как 10 лет назад, но с новыми версиями PHP и HTTPS.

Как начать пользоваться Denwer SE

1. Скачать архив с официального сайта автора.
2. Распаковать в любое место, например C:\web\DenwerSE\.
3. Запустить DenwerSE.exe — если нет прав администратора, попросит их для монтирования диска и правки hosts.
4. Нажать «Запустить» — появится виртуальный диск Z:, а в системном трее иконка.
5. Создать папку сайта — например, home\myproject.local и положить туда index.php.
6. Открыть в браузере http://myproject.local/ (или https://myproject.local/). HTTPS будет работать сразу после установки корневого сертификата (кнопка в панели).

По умолчанию пароль к MySQL/MariaDB — пустая строка (пользователь root). При желании его можно сменить через phpMyAdmin.

Заключение

Denwer SE — это не просто ностальгический проект. Это действительно современный инструмент, который доказывает, что концепция «локального сервера в одну папку» всё ещё актуальна. Отказ от Perl в пользу Python, менеджер версий PHP/БД, нормальный HTTPS, портативность и мгновенный запуск — всё это делает его отличным выбором для быстрого прототипирования, тестирования легаси-кода или обучения веб-разработке.

Если вы устали ждать, пока Open Server применит настройки, или не хотите разбираться в Docker Compose — попробуйте Denwer SE. Вероятно, он напомнит вам старые добрые времена, но уже без боли устаревших технологий.

• Автор проекта: Александр Тишов (Amro), разработчик CMS Seditio.
• Лицензия: Freeware.
• Совместимость: Windows 7/8/10/11 x64.

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

Я Java-разработчик и в основном работаю с backend: Spring Boot, базы данных, интеграции, авторизация, WebSocket — всё то, что обычно находится за интерфейсом.

В какой-то момент я поймал себя на мысли: я каждый день пользуюсь мессенджерами, но плохо понимаю, как они устроены внутри. Окей, JWT, WebSocket, PostgreSQL, Redis — это понятно. Но что технически означает фраза "end-to-end encryption"? Как сервер доставляет сообщения, если он не должен их читать? Где живут ключи? Что хранится в базе? Что происходит, если у пользователя два устройства?

Решил разобраться через практику. Написал мессенджер с нуля. Назвал Chaos Messenger.

Сразу честно: криптографическую часть я изучал вместе с Claude и ChatGPT — читал спецификации X3DH и Double Ratchet, разбирал примеры, задавал вопросы, пока не сложилась цельная картина. Frontend тоже делался с активной помощью ChatGPT: я backend-разработчик, React для меня не основная среда. Но архитектура, backend, интеграция WebCrypto, модель конвертов, хранение сообщений и принципиальные решения — мои.

Для меня AI здесь был не заменой понимания, а инструментом — примерно как документация, Stack Overflow и ревью коллег. Без понимания threat model и архитектуры такой проект всё равно не собрать.

В статье расскажу, как работает E2EE изнутри: как устанавливается сессия через X3DH, как каждое сообщение получает отдельный ключ через Symmetric Ratchet, почему сервер хранит только зашифрованные конверты, и какие ошибки я допустил по дороге.

Стек: Spring Boot 3, React 18, WebCrypto API, PostgreSQL, Redis, WebSocket/STOMP, Prometheus, Grafana.

Важная оговорка про web-E2EE

Когда я говорю, что сервер не может прочитать сообщения, я имею в виду backend, базу данных, WebSocket-слой и уже сохранённые ciphertext-конверты. У них нет ключей и plaintext.

Но у web-E2EE есть отдельная проблема: frontend-код тоже приходит с сервера. Теоретически скомпрометированный сервер может отдать изменённый JavaScript, который украдёт ключи или plaintext до шифрования. Это ограничение не конкретно моего проекта, а браузерной модели в целом.

Поэтому корректная формулировка такая: backend не получает ключи и не может расшифровать уже переданные или сохранённые сообщения. Защита от подмены клиентского кода — отдельный слой безопасности: подпись сборок, независимая верификация клиента, desktop/mobile-приложения, reproducible builds.

Почему обычный подход не работает

Большинство "мессенджеров" на GitHub выглядят примерно так:

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

E2EE решает это радикально: backend не получает ключи и не хранит plaintext. Сообщение шифруется на устройстве отправителя до отправки в сеть, а расшифровывается только на устройстве получателя.

Это уже не вопрос политики конфиденциальности в стиле "мы обещаем не читать". Это архитектурное ограничение: если у сервера нет ключа, он не может превратить ciphertext обратно в текст.

Звучит как магия. На самом деле — два протокола и немного WebCrypto.

Главная идея: конверты

Представь что Алиса хочет написать Бобу. Вместо того чтобы положить письмо на стол и надеяться что никто не прочитает — она кладёт его в запечатанный конверт. Конверт может открыть только Боб своим ключом. Сервер просто передаёт конверт не заглядывая внутрь.

Именно так это работает в коде. В базе данных у меня это выглядит так:

Когда я впервые увидел

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

А вот что сервер возвращает при запросе списка чатов через API:

Не

. Не

. Буквально

(DevTools → Network → ответ API с

)

Откуда берутся ключи: X3DH

Главный вопрос: как Алиса и Боб получают общий секрет, если они никогда раньше не общались? И как сделать это так, чтобы сервер только помог передать публичные данные, но сам не смог вычислить итоговый ключ?

Для этого используется X3DH — Extended Triple Diffie-Hellman, протокол из экосистемы Signal. Его задача — установить общий секрет между двумя устройствами, используя долгосрочные и временные ключи.

Что хранится на сервере

Когда пользователь регистрирует устройство, он загружает на сервер пакет публичных ключей:

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

Здесь важно сказать честно: хранение приватных ключей в

Более строгий вариант — использовать Web Crypto API с

, чтобы приватный ключ жил внутри браузерного crypto runtime и его нельзя было экспортировать в байты. Но у этого подхода есть практическая сложность: ключи нужно переживать между перезагрузками страницы, синхронизировать с IndexedDB, аккуратно восстанавливать состояние устройства и не сломать UX.

В браузерных E2EE-приложениях обычно приходится выбирать между несколькими вариантами:

• Сериализуемые ключи в localStorage или IndexedDB — проще реализовать, но нужно очень серьёзно относиться к XSS и целостности frontend-кода.
• extractable: false + IndexedDB — безопаснее, но сложнее в реализации и восстановлении состояния.
• Нативное secure storage вроде Android Keystore или iOS Secure Enclave — лучший вариант для мобильных клиентов, но он недоступен обычному web-приложению.

В текущей версии Chaos Messenger используется первый вариант. Это осознанный компромисс для pet/open-source проекта и удобного запуска в браузере. Переход на non-extractable ключи и более строгую модель хранения стоит в roadmap.

Ключевой момент: backend всё равно не получает приватные ключи и не может расшифровать сохранённые ciphertext-конверты. Но защита ключей на клиенте — отдельная задача, и её нельзя честно замалчивать.

Установка сессии

Когда Алиса открывает переписку с Бобом впервые, происходит следующее:

В классическом X3DH четвёртая DH-операция с one-time prekey опциональна: она выполняется, если сервер выдал доступный OPK получателя. В моей реализации устройство публикует набор one-time prekeys при регистрации, поэтому первое сообщение обычно использует DH4. Если OPK закончились, сессию всё равно можно установить через остальные DH-компоненты, но это уже менее сильный вариант.

Боб, получив конверт с эфемерным публичным ключом Алисы, повторяет те же операции со своими приватными ключами и получает тот же самый

. Математика симметрична.

Сервер в этот момент видит только публичные ключи и зашифрованный конверт. Он помогает устройствам найти друг друга, но не участвует в вычислении секрета.

Получить

Как шифруется каждое сообщение: Symmetric Ratchet

X3DH даёт нам стартовый

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

Решение — симметричный ratchet. После каждого сообщения цепочка ключей продвигается вперёд:

Визуально это выглядит так:

используется для шифрования одного сообщения через AES-GCM, после чего уничтожается. Если атакующий компрометирует

— он прочитает только второе сообщение.

В рамках такой симметричной цепочки это даёт forward secrecy назад по цепочке: зная текущий или отдельный

Само шифрование сообщения:

А вот что уходит на сервер — живой пример из DevTools:

Сервер получает

и

. Расшифровать без

Важная оговорка: это ещё не полный Double Ratchet

В этом проекте реализован Symmetric Ratchet — цепочка, где из

для каждого сообщения выводится отдельный

Это защищает прошлые сообщения: если атакующий узнает текущий ключ или отдельный

, он не сможет откатить HMAC назад и получить старые ключи.

Но это не полный Double Ratchet из Signal Protocol.

В полном Double Ratchet есть ещё DH ratchet step: стороны периодически выполняют новый Diffie-Hellman обмен и обновляют root key. Это даёт break-in recovery — возможность восстановить безопасность будущих сообщений после компрометации части состояния.

В моей реализации DH ratchet step пока нет. Если атакующий получит актуальное состояние сессии на устройстве и сможет продолжать его читать, он сможет расшифровывать будущие сообщения до переустановки сессии. Это честное ограничение текущей версии, и оно стоит первым пунктом в roadmap.

Мультиустройство: один пользователь, несколько конвертов

Первый неочевидный момент: в E2EE сообщение адресуется не просто пользователю, а конкретным устройствам пользователя.

Если у Боба два устройства — телефон и ноутбук — нужен отдельный encrypted envelope для каждого устройства. Сервер не может взять один конверт, расшифровать его и "переупаковать" для второго устройства: у него нет ключей и он не знает plaintext.

Значит при отправке сообщения нужно зашифровать его отдельно для каждого устройства каждого участника чата.

Для чата где у каждого по 2 устройства — 4 конверта на одно сообщение. Для группы из 10 человек — потенциально 20 конвертов. Это нормально, это цена безопасности.

Сервер: хранение и доставка конвертов

На сервере сообщение создаётся с контентом

, а конверты сохраняются отдельно:

После сохранения — fanout по WebSocket. Каждое устройство получает свой конверт и только его:

Это важное отличие от обычного WebSocket-чата. В обычном чате сервер рассылает одно и то же событие всем участникам. В E2EE-чате сервер рассылает разные события разным устройствам: payload для каждого устройства содержит свой

Топик

— строго персональный. Устройство А не получает конверт устройства Б. Никакого broadcast — только адресная доставка.

Архитектура целиком

Баг который долго не замечал

В панели чатов показывается превью последнего сообщения. Я реализовал это через

Запускаю — в списке чатов у всех написано

.

Конечно. Сервер же не знает что там написано.

Я полчаса думал как решить это на сервере. Потом дошло: нельзя решить это на сервере — у него нет ключей. Решение только на клиенте.

После того как пользователь открыл чат и сообщения расшифровались — кешируем последнее в памяти:

Это хороший пример того, как E2EE меняет привычное мышление backend-разработчика. В обычном приложении preview — это поле в SQL-запросе. В E2EE-приложении preview — это локальное клиентское состояние, потому что только клиент видел plaintext.

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

Rate limiting: дыра которую легко не заметить

Эндпоинт

отправляет SMS с кодом. Без защиты любой скрипт может дёргать его тысячи раз — это называется SMS pumping fraud, SMS стоят реальных денег.

Redis у нас уже был для хранения онлайн-статусов. Добавил rate limiting поверх него:

При превышении — HTTP 429 с заголовком

. Клиент знает через сколько секунд можно повторить.

Важный нюанс: в текущей реализации, если Redis недоступен, сервис не блокирует авторизацию полностью. Для pet-проекта это приемлемый компромисс: лучше рискнуть одним лишним SMS, чем положить вход в приложение.

В production я бы сделал строже: fallback in-memory лимит на инстанс, отдельные лимиты по IP и телефону, антифрод-логику и алерты на всплески отправки кодов.

Авторизация WebSocket

Отдельная история — авторизация WebSocket соединений. HTTP-эндпоинты защищены Spring Security автоматически, но WebSocket — другое дело. STOMP-соединение устанавливается один раз, и нужно проверять JWT при каждом подключении.

Отдельно важно не только проверить JWT, но и связать WebSocket-соединение с конкретным устройством. Пользователь может быть один, но устройств у него несколько, а encrypted envelope адресован именно

Поэтому при подключении я проверяю не только токен, но и

: устройство должно быть зарегистрировано и принадлежать текущему пользователю. Иначе легко случайно превратить per-device E2EE-доставку обратно в обычный broadcast по пользователю.

Что получилось — живые скрины

Что реализовано:

• E2EE-модель с per-device encrypted envelopes
• X3DH session setup + Symmetric Ratchet + AES-GCM
• Мультиустройство
• Личные и групповые чаты
• Realtime доставка через WebSocket/STOMP
• Статусы SENT → DELIVERED → READ
• Редактирование и soft delete сообщений
• Online presence, typing indicator
• Фото-вложения
• Поиск пользователей
• Rate limiting на SMS через Redis
• Prometheus метрики + Grafana дашборд
• Swagger UI с JWT авторизацией
• 24 backend-теста на Testcontainers, 12 frontend на Vitest, E2E на Playwright
• GitHub Actions CI

Что ещё не сделано:

• Полный Double Ratchet с DH ratchet step и break-in recovery
• Ротация signed prekey и аккуратное пополнение one-time prekeys
• Более строгая модель хранения приватных ключей на клиенте: non-extractable CryptoKey + IndexedDB
• Защита от подмены frontend-кода: подпись сборок, независимая верификация клиента, reproducible builds
• Android-клиент с Android Keystore
• Реальный SMS-провайдер вместо кода в backend-логах
• Push-уведомления без утечки содержимого сообщений
• Более строгая metadata-модель для групповых чатов

Главный инсайт

E2EE — это архитектурное решение, а не библиотека.

Нельзя взять обычный Spring Boot чат и просто "включить шифрование". Нужно с самого начала проектировать систему так, чтобы backend не был участником доверенной зоны: он не должен получать plaintext, не должен иметь ключи и не должен уметь пересобирать сообщение из данных в базе.

Это меняет почти всё:

• структуру БД — вместо текста появляются encrypted envelopes
• API — сервер отдаёт [encrypted], а не preview сообщения
• WebSocket — доставка идёт не по пользователю, а по конкретному устройству
• мультиустройство — одно сообщение превращается в несколько ciphertext-конвертов
• frontend — становится полноценной криптографической частью системы, а не просто UI

Второй инсайт: мессенджер — это не "чат с WebSocket". В E2EE-модели это система доставки зашифрованных конвертов с адресацией по устройствам. Как только это принимаешь, многие странные на первый взгляд решения становятся логичными.

Репозиторий

Код открыт: github.com/vaazhen/chaos-messenger

В репозитории есть README на русском и английском, диаграммы, скриншоты, security audit, Docker Compose и запуск одной командой.

Проект не претендует на уровень production-криптомессенджера вроде Signal. Это учебный и инженерный open-source прототип, цель которого — показать, как E2EE меняет архитектуру backend, frontend и realtime-доставки.

Если вы делали что-то похожее — особенно интересно сравнить подходы к ротации prekey-ов, хранению non-extractable ключей в браузере и реализации DH ratchet step. Вопросы и критика приветствуются.

Релиз Kubernetes 1.36, запланированный на 22 апреля 2026 года, содержит разнообразный набор новых alpha-фич, сфокусированных на трёх ключевых направлениях: производительность рабочих нагрузок, масштабируемость API и эффективное использование ресурсов. В этом обновлении много давно ожидаемых возможностей: workload-aware preemption для AI/ML-задач, шардирование API-стримов для больших кластеров, глубокая интеграция Dynamic Resource Allocation (DRA) в scheduler.

В обзоре — 20 новых фич, добавленных в Kubernetes как alpha (то есть выключены по умолчанию): от node-уровневых gRPC API до graceful leader transitions. Это даёт представление, куда движется контейнерная оркестрация.

Прим. Авторы стараются указывать актуальные изменения, но из-за быстро меняющегося ландшафта фич Kubernetes часть KEP (Kubernetes Enhancement Proposals) может быть исключена из milestone ближе к дате релиза.

— Релиз. Kubernetes 1.36 выходит 22 апреля 2026. Статья рассматривает 20 alpha-фич.

— Фокус. AI/ML (workload-aware preemption, gang scheduling, DRA), масштабируемость (sharded watches, kubelet gRPC API), ресурсы (pod-level resource managers, HPA scale-to-zero).

— По категориям. Nodes (5), Scheduling (6), API (4), Apps (1), Storage (1), Various (3) — итого 20 KEP-ов.

— Non-alpha. OCI VolumeSource → Stable; Device taints в DRA → Beta (включены по умолчанию). User namespaces в Pod → Stable после 3,5 года в альфе. gitRepo volume plugin удалён.

Nodes

DRA: Device Attributes в Downward API

KEP #5304 · Feature gate: отсутствует. Фреймворк предоставляет boolean-флаг (например, --enable-device-metadata), который драйверы встраивают в свой CLI.

KEP-5304 вводит стандартный способ для DRA-драйвера наполнять метаданные устройства. Фреймворк затем автоматически передаёт эти метаданные в контейнер, монтируя их как JSON-файл по заданному пути. Больше не нужно изобретать кастомные контроллеры или запрашивать Kubernetes API из самой рабочей нагрузки только ради этих деталей.

В текущей версии DRA, чтобы получить информацию о выделенных устройствах (например, PCIe-адреса для GPU или UUID для mediated-устройств), нужно читать статус ResourceClaim, находить подходящий ResourceSlice и парсить атрибуты. Неудобно. KEP-5304 позволяет DRA-драйверу возвращать метаданные устройства прямо в ответе на gRPC-вызов PrepareResourceClaims (kubelet → driver), а kubelet пишет их в JSON-файл и монтирует его в контейнер. В итоге приложение внутри контейнера просто читает файл /var/run/dra-device-attributes/{claimName}/{requestName}/{driverName}-metadata.json.

Новый kubelet gRPC API для локальных подов

KEP #4188 · Feature gate: PodInfoAPI.

Сейчас, чтобы получить свежий статус пода (ready ли он, его IP, его labels), компоненты на той же ноде — CNI-плагины, мониторинг-агенты — должны ходить в API-сервер. Это создаёт проблемы с надёжностью (если нода потеряла связь с control-plane, локальные компоненты не получат свежие данные, хотя они есть у локального kubelet), масштабируемостью (нагрузка на API-сервер от агентов на каждой ноде) и задержкой (сетевой вызов всегда медленнее локального).

Предлагается новый gRPC API для подов прямо на ноде: UNIX-сокет /var/lib/kubelet/pods/kubelet.sock, доступ только для привилегированных процессов. API возвращает самую свежую информацию, доступную kubelet, даже если она ещё не синхронизирована с API-сервером. Клиент может запросить полный PodSpec и PodStatus либо конкретные поля через google.protobuf.FieldMask. Три основных метода: ListPods, GetPod, WatchPods.

CRI List Streaming

KEP #5825 · Feature gate: CRIListStreaming.

Иногда kubelet нужен список всех контейнеров на ноде (например, для garbage collection). Для этого он отправляет CRI-запрос ListContainers. Проблема: существующие CRI RPC — unary, то есть клиент (kubelet) шлёт один запрос, сервер (container runtime) возвращает один ответ со всем списком. На нагруженных нодах с тысячами контейнеров (например, от множества короткоживущих CronJob) список может превысить 16 МБ — дефолтный максимум в gRPC. Этот лимит достигается уже на ~11 000 контейнерах (~14 000 подов).

Чтобы не ломать совместимость, KEP добавляет новые server-side streaming RPC. При streaming-вызове container runtime не строит весь ответ в памяти — открывает gRPC-поток и отправляет StreamContainersResponse для каждого контейнера по очереди. kubelet читает из потока, пока тот не закроется, затем обёртка собирает куски в единый список.

DRA: видимость доступности ресурсов

KEP #5677 · Feature gate: DRAResourcePoolStatus.

Разработчику хочется видеть, какие DRA-ресурсы свободны в кластере, чтобы траблшутить Pod, который не шедулится из-за «insufficient DRA resources». Админу — знать, сколько GPU доступно, для планирования мощностей. Сейчас это сложно: ResourceSlices — cluster-scoped и показывают только общую capacity, ResourceClaims — namespaced и отслеживают конкретные выделения, пользователь с ограниченными правами не видит ResourceClaims вне своего namespace, нет API-механизма видеть соотношение available/allocated.

KEP добавляет ResourcePoolStatusRequest — паттерн CertificateSigningRequest: пользователь создаёт объект с указанием driver (обязательный) и pool filter (опциональный), контроллер в kube-controller-manager подхватывает его, считает availability и пишет результат в status. Для обновления — удалить старый запрос и создать новый.

Пример — посмотреть статус всех GPU-пулов:

Pod-Level Resource Managers

KEP #5526 · Feature gates: PodLevelResources, PodLevelResourceManagers.

KEP-2837 позволил задавать единый бюджет ресурсов (CPU, память и т.д.) для всего пода целиком, а не для каждого контейнера отдельно. Это полезно для Guaranteed-QoS-подов в HPC, AI/ML, NFV. Проблема: текущие resource managers работают на уровне контейнера и не умеют использовать pod.spec.resources для NUMA-решений.

KEP-5526 даёт выбор из двух моделей управления ресурсами (обе поддерживают Guaranteed-поды с mix из Guaranteed- и non-Guaranteed-контейнеров):

• Pod Scope — Topology Manager назначает один ресурсный пул с одной NUMA-ноды на весь под, используя pod.spec.resources. CPU и Memory managers выделяют эксклюзивные сегменты для Guaranteed-контейнеров, остаток идёт в shared-пул для остальных
• Container Scope — ресурсы управляются для каждого контейнера отдельно, pod.spec.resources игнорируется при размещении

Первая модель — для ML-тренировочного контейнера с сайдкарами (логирование, ingestion, мониторинг) на одной NUMA-ноде. Вторая — для независимого управления контейнерами с разными требованиями внутри одного Guaranteed-пода: Guaranteed-контейнер получает эксклюзивные NUMA-выровненные ресурсы, non-Guaranteed в том же поде работают в shared-пуле ноды. Раньше это было невозможно: все контейнеры в поде должны были быть Guaranteed.

Scheduling

Workload-aware preemption

KEP #5710 · Feature gate: WorkloadAwarePreemption.

Scheduler может инициировать preemption — принудительное удаление подов с более низким приоритетом, чтобы освободить ресурсы под высокоприоритетный под. Проблема: он делает это пер-под. А AI/ML- и HPC-нагрузки обычно — группа тесно связанных подов (например, для распределённого обучения). Если даже один под из группы вытеснен, весь job стопорится и просто ждёт возврата этого пода, удерживая ресурсы впустую.

KEP-5710 вводит workload-aware preemption: группы связанных подов (PodGroups) теперь — единая сущность для scheduling и preemption. Scheduler прикидывает, можно ли освободить место под высокоприоритетную группу, вытеснив менее важные группы целиком.

Новое поле DisruptionMode в GangSchedulingPolicy контролирует, может ли Kubernetes вытеснять отдельные поды или группу только целиком (PodGroup). Поле PriorityClassName в PodGroupSpec задаёт приоритет всей группы — используется для всех решений о scheduling/preemption, перекрывая приоритеты отдельных подов. Строится на KEP-4671 (Gang Scheduling в Kubernetes).

Topology-aware workload scheduling

KEP #5732 · Feature gate: TopologyAwareWorkloadScheduling.

Строится на идеях KEP-4671 и KEP-5710. Классический scheduler принимает решения пер-под, что неоптимально для групп связанных подов: их имеет смысл размещать на одной ноде или хотя бы близких нодах — для снижения latency. KEP-5732 делает scheduler topology-aware: можно указать, чтобы группа подов размещалась в пределах одного topological domain, определённого общим label — например, topology.kubernetes.io/rack.

DRA: List-типы для атрибутов

KEP #5491 · Feature gate: DRAListTypeAttributes.

KEP обновляет DRA API под более сложные hardware-конфигурации. Раньше атрибуты устройств в ResourceSlice могли быть только скалярными (string, number, boolean). Нельзя было описать устройство с несколькими соединениями — например, CPU, подключённый к нескольким PCIe-шинам.

Теперь драйверы могут отдавать атрибуты как списки строк, чисел или версий. Обновлена логика в ResourceClaim: matchAttribute теперь требует непустого пересечения списков (не точного совпадения), distinctAttribute — попарной непересекаемости.

Пример ResourceSlice с атрибутом resource.kubernetes.io/pcieRoot в разных форматах:

DRA: поддержка ResourceClaim для Workloads

KEP #5729 · Feature gate: WorkloadPodGroupResourceClaimTemplate.

DRA даёт использовать специализированные ресурсы — GPU, FPGA, кастомные сетевые карты. Чтобы под получил такой ресурс, нужно создать соответствующий ResourceClaim. Проблема: если несколько подов делят ресурс, максимум было 256 подов на один ResourceClaim из-за лимита status.reservedFor.

KEP-5729 чинит: ResourceClaims теперь могут быть на уровне PodGroup. Один claim на всю группу, все поды в ней могут использовать ресурс. Поды ссылаются на ресурс по локальному group-name через PodGroupResourceClaim, а не прямому имени. Динамически создаваемые поды получают доступ к общему ресурсу, автоматически созданному для группы, без необходимости знать его имя заранее.

DRA: Native Resource Requests

KEP #5517 · Feature gate: DRANativeResources.

Появление DRA в Kubernetes породило два независимых механизма учёта ресурсов, которые управляют одним и тем же. Это даёт двойной учёт:

• Supply — capacity CPU/памяти ноды хранится в двух местах: Node.Status.Allocatable у kubelet и ResourceSlice у DRA-драйвера
• Consumption — поды могут запрашивать ресурсы двумя путями: через spec.containers[].resources.requests или spec.initContainers[].resources.requests (проверяет NodeResourcesFit) или через ResourceClaim (обрабатывает DynamicResources)

KEP-5517 интегрирует DRA-ресурсы со standard resource tracking scheduler-а, обеспечивая единый учёт и предотвращая overcommit. Пример: ML-job запрашивает GPU через ResourceClaim, но конкретная модель GPU требует определённого количества CPU и HugePages. Раньше пользователь должен был знать об этом и прописывать в PodSpec. Теперь GPU-устройство декларирует зависимости само — scheduler учитывает потребности GPU в CPU и HugePages дополнительно к обычным requests.

WAS (Workload-Aware Scheduling): декомпозиция PodGroup API

KEP #5832 · Feature gate: GenericWorkload.

Kubernetes имеет gang scheduling — запуск всех подов в группе вместе. Проблема: логика gang scheduling изначально тесно связана с конкретной реализацией API под названием PodGroup, которая была частью объекта Workload. Это создавало два неудобства:

• Другие проекты экосистемы (Kueue, JobSet), тоже требующие gang scheduling, были вынуждены использовать этот конкретный PodGroup API — не могли применить свои CRD для описания групп
• Обновление статуса одной маленькой Pod-группы требовало чтения/записи всего Workload-объекта, что давало просадку производительности и конфликты при большом числе групп

KEP-5832 разделяет PodGroup и Workload: PodGroup становится самостоятельным объектом, Workload — статичным шаблоном, определяющим общую политику и структуру групп. Высокоуровневые контроллеры (Job, JobSet, LeaderWorkerSet) автоматически создают инстансы PodGroup из шаблона Workload, затем поды этой PodGroup. В Pod spec появилось поле spec.schedulingGroup.podGroupName, указывающее прямо на PodGroup. Scheduler больше не следит за Workload-объектами — работает напрямую с потоком PodGroup.

API

Stale Controller Mitigation

KEP #5647 · Feature gate: StaleControllerConsistency.

Контроллеры в Kubernetes (например, kube-controller-manager) работают в reconciliation loop: следят за состоянием кластера, сравнивают желаемое с фактическим, синхронизируют. Они используют локальный кэш состояния, чтобы не перегружать API-сервер. Кэш обновляется через watch — это eventually consistent, то есть «когда-нибудь» изменения доедут. Задержка бывает от миллисекунд до минут.

В больших high-load кластерах проблема обостряется. Контроллер создаёт Pod, через секунду получает запрос reconcile того же объекта, но кэш ещё не обновился — контроллер «не видит» созданный под и пытается создать его снова или делает что-то ещё не то.

KEP-5647 вводит два изменения:

• В informer добавляется BookmarkFunc, единственная задача которого — уведомить слушателей, что произошло обновление. Вместе с обычными Add/Update/Delete это позволяет контроллеру знать, насколько свеж его кэш
• Улучшена логика контроллера. После успешной операции CREATE или UPDATE сохраняется новый resourceVersion объекта. Перед следующим reconcile контроллер проверяет, обработал ли informer resourceVersion как минимум такой же свежий. Если да — кэш актуален, можно продолжать. Если нет — reconcile пропускается, объект ставится обратно в очередь с exponential backoff

Graceful Leader Transition

KEP #5366 · Feature gate: GracefulLeaderTransition.

В high-availability кластерах несколько реплик ключевых control-plane-компонентов (kube-controller-manager, kube-scheduler) работают одновременно. Чтобы избежать конфликтов, используется leader election. Старый механизм при потере лидерства просто завершал процесс через os.Exit(), kubelet его рестартовал. Это съедало ресурсы, и компонент не мог gracefully завершить работу.

KEP-5366 вводит smarter способ передачи лидерства без полного рестарта:

• Рефакторинг кода контроллеров — чтобы все внутренние goroutines завершались чисто. Критично, чтобы не утекали ресурсы при частой смене ролей
• Улучшен release leader lease: вместо ожидания TTL, уходящий лидер активно освобождает lock при shutdown, ускоряя новые выборы. Управляется флагом ControllerManagerReleaseLeaderElectionLockOnExit
• Финальная стадия (флаг GracefulLeaderTransition) меняет core-логику компонента: при потере лидерства он не завершается через os.Exit(), а переходит в follower-состояние и пытается стать лидером снова

Server-side Sharded List and Watch

KEP #5866 · Feature gate: ShardedListAndWatch.

В Kubernetes контроллеры непрерывно мониторят состояние ресурсов (Pods, Services) через LIST и WATCH. С ростом кластеров эти операции тяжело масштабировать. Большинство контроллеров, как kube-controller-manager, масштабируются только вертикально — не умеют разделять watch-поток. Некоторые (kube-state-metrics) научились делать client-side sharding, но каждая реплика всё равно получает все события ресурса, десериализует всё, потом выбрасывает то, что не для её шарда. Лишняя сетевая нагрузка и CPU.

KEP-5866 переносит фильтрацию на API-сервер. Новый параметр shardSelector позволяет клиенту подписаться на конкретный шард данных — задаётся хэш-диапазон. Пример запроса:

API-сервер использует быстрый FNV-1a для хэша metadata.uid. Если хэш попадает в диапазон — событие уходит клиенту. Каждая реплика подписывается на свой диапазон и получает clean, non-overlapping поток.

Manifest Based Admission Control Config

KEP #5793 · Feature gate: ManifestBasedAdmissionControlConfig.

Чинит серьёзную startup-уязвимость в Kubernetes. Обычно все правила валидации запросов (admission webhooks — MutatingAdmissionWebhook, ValidatingAdmissionWebhook, access policies) — это API-объекты внутри кластера. Это даёт опасное окно: при старте API-сервера (или недоступности etcd) запросы могут обрабатываться до того, как правила загружены. Плюс любой пользователь с повышенными правами может — намеренно или случайно — удалить admission policies по сети.

KEP-5793 добавляет способ задавать security-политики через локальные манифест-файлы на диске control-plane-сервера. Эти файлы загружаются и применяются до того, как сервер начнёт слушать сеть. API-сервер непрерывно мониторит локальный каталог — при изменении файла правило немедленно подхватывается, валидируется и применяется без рестарта. Если валидация упала, сервер отклоняет новый манифест, логирует warning и возвращается к last-known-good конфигурации.

Apps

WAS: интеграция Workload API с Job controller

KEP #5547 · Feature gate: EnableWorkloadWithJob.

Job controller в Kubernetes отвечает за запуск джобов. Он создаёт поды, но нет гарантии, что они стартанут одновременно. Реальная проблема для распределённых нагрузок (AI/ML, MPI-задачи), где всё должно стартовать синхронно.

KEP-5547 расширяет Job controller нативной поддержкой gang scheduling (KEP-4671) через Workload и PodGroup API. Когда создаётся Job с нужными параметрами (для альфы это parallelism > 1, completionMode: Indexed, parallelism = completions), контроллер автоматически:

• Создаёт объект Workload с политикой scheduling для группы подов, указывая gang.minCount равным parallelism
• Создаёт объект PodGroup по шаблону из Workload
• При создании подов Job добавляет schedulingGroup.podGroupName в их спецификацию, связывая поды с соответствующей PodGroup

Scheduler видит, что поды — часть PodGroup, и ждёт возможности запустить все поды из minCount (минимум для старта workload) одним махом.

Storage

PVC — время последнего использования

KEP #5541 · Feature gate: PersistentVolumeClaimUnusedSinceTime.

Со временем в кластерах накапливаются PVC, которые больше не используются. Приложение удалили, мигрировали или просто остановили, а PVC остаётся — жрёт хранилище и деньги. Сейчас в Kubernetes нет простого способа посмотреть, когда PVC использовался в последний раз.

KEP-5541 добавляет поле UnusedSince в статус PVC (PersistentVolumeClaimStatus). PVC protection controller ставит туда metav1.Now при удалении или переходе в terminal state последнего пода, ссылающегося на PVC, и nil при появлении нового пода, начинающего ссылаться на этот PVC.

Various

HPA: масштабирование до/от нуля по object/external metrics

KEP #2021 · Feature gate: HPAScaleToZero.

Раньше Horizontal Pod Autoscaler не мог скейлить до нуля реплик. Он опирался на метрики активных подов — CPU, память — поэтому всегда требовался минимум один работающий под для сбора данных.

KEP вводит поддержку external и object metrics: HPA может принимать решения по внешним индикаторам (например, длина очереди сообщений). Если задач нет — число подов приложения скейлится до нуля, фактически глушит его. HPA записывает это в специальный status-поле ScaledToZero. Это предотвращает случайный scale-up приложения, которое админ вручную опустил до нуля через replicas: 0. Как только появляется задача (сообщение в очереди) — HPA поднимает первую реплику.

Native Histogram Support для метрик Kubernetes

KEP #5808 · Feature gate: NativeHistograms.

Гистограммы в Prometheus сейчас работают через предопределённые buckets. Разработчик заранее задаёт диапазоны значений. Например, для latency: до 10 мс, до 50 мс, до 100 мс, до 500 мс. Если запрос занял 49 мс — инкрементится «до 50 мс». У этого два недостатка:

• Неоднозначность — невозможно узнать точное распределение внутри bucket (все запросы на 11 мс или все на 49 мс? Эта информация теряется)
• Избыточность — передаются данные для всех bucket'ов, даже если туда ничего не попало. Жрёт ресурсы и диск

Prometheus v2.40 ввёл Native Histograms (стали stable в v3.8.0) с умными auto-adjusting экспоненциальными buckets. KEP-5808 интегрирует Prometheus Native Histograms в метрики компонентов Kubernetes.

Обработка незашифровываемых ресурсов

KEP #3926 · Feature gate: AllowUnsafeMalformedObjectDeletion.

Шифрование API-ресурсов at-rest давно используется в Kubernetes. Иногда оно ломается из-за внешних сбоев или неверной настройки. Если один объект определённого типа не расшифровывается, то list этого типа в префиксе, содержащем объект, всегда падает — даже если остальные объекты читаются. Поломанный объект нельзя удалить через Kubernetes API, админ должен лезть в etcd вручную.

KEP-3926 предлагает метод идентификации ресурсов, которые не расшифровываются или не декодируются в объект, и вводит новый DeleteOption — IgnoreStoreReadErrorWithClusterBreakingPotential, разрешающий удалить ресурс, даже если его данные не читаются.

Non-alpha highlights релиза 1.36 — выбор Дмитрия Шурупова

Статья намеренно фокусируется на alpha-фичах, чтобы показать, куда движется разработка. Но каждый релиз содержит много других обновлений — это alpha, введённые раньше, или фичи, сейчас находящиеся в beta/stable. Самые заметные, по мнению Дмитрия Шурупова (сооснователя Palark, CNCF Ambassador):

• Device taints и tolerations в DRA (KEP 5055) и DRA support for partitionable devices (KEP 4815) — Beta. Включены по умолчанию
• OCI VolumeSource (KEP 4639) — Stable. Новый VolumeSource (появился в 1.31), поддерживает OCI-образы: хранение файлов и расшаривание между контейнерами в поде без включения в основной образ
• User namespaces в Pods (KEP 127) — Stable. Стартовал в alpha в 1.25 (август 2022), через 3,5 года наконец GA
• Mutating Admission Policies (KEP 3962) — Stable. Расширяет mutating admission webhooks через CEL-выражения
• Accelerated recursive SELinux label change (KEP 1710) — Stable. В beta с 1.27 (апрель 2023)
• gitRepo volume plugin (KEP 5040) — удалён. Критическая security-проблема: выполнение кода как root на ноде

Часть alpha-фич из 1.35 и более ранних релизов (gang scheduling, user namespaces в HostNetwork-подах) значительно доработана, но осталась в альфе.

Это не полный список изменений — полную информацию можно посмотреть в official enhancements tracker и changelog.

Заключение

Релиз Kubernetes 1.36 существенно расширяет инструментарий оркестратора, фокусируясь на производительности, безопасности и удобстве использования. Интегрируя gang scheduling и продвинутое управление ресурсами, Kubernetes всё лучше подходит для современных распределённых нагрузок и больших кластеров, одновременно оптимизируя ядро своих API.

Спасибо всем разработчикам и авторам KEP, сделавшим Kubernetes 1.36 возможным. Вы потрясающе сработали.

Интересуют другие alpha-фичи, недавно добавленные в Kubernetes? Читайте deep-dives по Kubernetes 1.35 (декабрь 2025) и Kubernetes 1.34 (август 2025).

Оригинал статьи: palark.com/blog/kubernetes-1-36-release-features/. Перевод публикуется с сохранением оригинальной структуры и всех технических деталей.

Свежий тред на Hacker News снова показал: на прошлых выходных docker pull из Испании стабильно ломался. Причина — судебный приказ от декабря 2024-го, который разрешает La Liga просить всех испанских ISP мгновенно блокировать любые IP без предварительной проверки, если лига считает, что на них ведётся нелегальный стрим футбольного матча.

• Судебный приказ Торгового суда №6 Барселоны (декабрь 2024) разрешает La Liga блокировать любые IP-адреса на время матчей без уведомления сервисов-владельцев.
• Пиратские стримы прячутся за CDN Cloudflare, Vercel, Netlify, где один IP обслуживает тысячи легитимных сайтов — в итоге блокируются Docker Hub, Twitch, Steam, LinkedIn, X, часть ИИ-провайдеров.
• Cloudflare и RootedCON проиграли апелляцию в марте 2025. Правительство Испании в октябре 2025 отказалось вмешиваться. Сезон 2025/26 продлится до 24 мая 2026 — до этого блокировки регулярны.
• Docker уже падал по всей Испании осенью 2025 на несколько дней. Новые жалобы в апреле 2026 — это уже рутина, а не единичный случай.
• Обход — VPN или прокси вне Испании. Для команд с испанскими разработчиками — зеркало реестра, резервный CI-раннер вне страны, жалоба в Еврокомиссию по регламенту 2015/2120.

Что именно ломается

Разработчики из Испании (в основном из Мадрида и Барселоны) сообщают о регулярных сбоях по субботам и воскресеньям во время матчей La Liga. Конкретно ломается:

• docker pull для образов, раздающихся через Docker Hub (Cloudflare CDN)
• GitHub Actions на self-hosted runners в Испании, а также у GitHub-hosted runners, если они тянут образы через испанский ISP
• Vercel-хостинг (фронтенд-сайты внезапно возвращают 5xx)
• Twitch, Steam, LinkedIn, часть Twitter/X — всё, что висит за Cloudflare
• API некоторых LLM-провайдеров, которые используют Cloudflare Workers

По словам Guillermo Rauch (CEO Vercel), La Liga даже не связывается с владельцами инфраструктуры — просто присылает ISP IP-адрес для блокировки. Даже после открытия официального канала связи (апрель 2025) Vercel в мае 2025 жаловался, что их CDN продолжают блокировать «без разбора».

Почему страдает именно инфраструктура

La Liga идентифицирует сайты, где, по их мнению, идёт пиратский стрим, и записывает IP серверов этих сайтов. Но сами стримы стоят за Cloudflare/Vercel/Netlify — эти CDN используют anycast: один и тот же IP-адрес объявляется из десятков дата-центров и обслуживает тысячи клиентов одновременно. Когда La Liga просит ISP заблокировать конкретный IP, отваливаются не только пиратские стримы, но и Docker Hub, SaaS-панели, виджеты поддержки и всё остальное, что делит IP с «подозреваемым».

Это не баг блокировки, а её фундаментальное свойство. Cloudflare прямо указывает на непропорциональность меры: блокировка одного IP выключает миллионы легитимных ресурсов. Суд это аргумент отклонил.

Как мы сюда пришли

• Декабрь 2024: Торговый суд №6 Барселоны выдаёт La Liga разрешение на блокировки без предварительной проверки. Условие одно: «не затрагивать третьих лиц» — условие, которое физически невозможно соблюсти.
• Февраль 2025: первая крупная блокировка IP Cloudflare, массовые сбои в Испании. La Liga обвиняет Cloudflare в «защите преступных организаций».
• Март 2025: Cloudflare и RootedCON проигрывают апелляцию. Суд заявил, что доказательств влияния на третьи стороны нет.
• Апрель–май 2025: CEO Vercel Guillermo Rauch публично жалуется, что La Liga игнорирует обращения и продолжает блокировать IP CDN без согласования.
• Осень 2025: Docker падал по всей Испании на несколько дней после старта нового сезона.
• Октябрь 2025: испанский парламент отклоняет инициативу остановить блокировки. RootedCON публикует шаблон коллективного иска.
• Апрель 2026: сезон 25/26 в разгаре, свежий тред на HN показывает, что docker pull всё ещё не работает по выходным.

Что делать, если вас задело

1. Проверьте, затронут ли ваш сервис, на hayahora.futbol — сайт мониторит IP, которые La Liga активно блокирует. Список меняется каждую неделю.
2. Для быстрой разблокировки команды: корпоративный VPN с выходом вне Испании (Нидерланды, Ирландия, Франция) или SSH-туннель через зарубежный VPS. Для российских разработчиков SSH-туннель через собственный VPS — надёжнее публичных VPN-сервисов, которые в РФ могут быть недоступны.
3. Для CI/CD: поставьте self-hosted runner в AWS/GCP/Yandex Cloud за пределами Испании. GitHub-hosted runners тоже затронуты, если трафик идёт через CDN.
4. Для docker pull: поднимите pull-through mirror — это локальный прокси-кэш Docker-образов, который живёт на вашем сервере вне Испании. Демон тянет слои через него, и трафик к Docker Hub (а значит, к Cloudflare) идёт уже не из Испании.
5. Для сайтов на Vercel/Cloudflare Pages: рассмотрите резервный деплой на AWS CloudFront или Yandex Cloud CDN — хотя бы как fallback на время матчей.
6. Подайте жалобу в Европейскую комиссию (регламент 2015/2120, нарушение сетевой нейтральности). Массовые жалобы — единственный реальный путь давления на Испанию.

Вывод

Это прецедент, который неприятнее, чем кажется на первый взгляд. Страна ЕС на уровне судебного приказа разрешила частной лиге блокировать произвольную инфраструктуру интернета «по субботам» — и это не останавливают ни Еврокомиссия, ни парламент, ни публичное давление. Если такая практика закрепится, завтра правообладатели фильмов, музыки или игр захотят тот же инструмент, и уже не только в Испании.

Проблема не в том, что они это делают. Проблема в том, что они МОГУТ это делать. Это вид государственной цензуры, который не должен быть возможен в принципе.

Для разработчиков прагматичный вывод один: если у вас есть критическая зависимость от CDN Cloudflare или Vercel и хоть одно звено инфраструктуры физически в Испании, заложите план-B. Зеркало реестра, резервный CI-раннер, fallback-домен — мелочь в обычное время, страховка в выходные.

Источники: Hacker News, daniel.es, TechRadar.

— 3 материала про ИИ в IDE: какие ассистенты доступны в РФ, Copilot бесплатно, ловушки Cursor

— 3 материала про контейнеры: Docker-советы, Podman как альтернатива, Docker для фронтендеров

— 4 материала про инструменты: Bruno вместо Postman, Linux-команды, Playwright + VS Code, дебаг vs console.log

ИИ в IDE

1. Топ 5 ИИ-ассистентов для IDE, доступных российским разработчикам

Обзор ИИ-ассистентов, которые реально работают в России: от GigaCode (Сбер) до Codeium. Для каждого — поддерживаемые IDE, ограничения и стоимость. 24 000+ просмотров — один из самых читаемых материалов за год.

Читать статью →

2. GitHub Copilot стал полностью бесплатным в VS Code

В декабре 2025 Microsoft сделала Copilot бесплатным внутри VS Code. Что входит в бесплатный тир, какие ограничения и стоит ли переходить с платных альтернатив — разбор для тех, кто пропустил.

Читать статью →

3. «Безлимит» Cursor оказался не таким уж безлимитным

Пользователи Cursor обнаружили, что тарифы меняются без предупреждения, а «безлимитный» план имеет скрытые ограничения. Если вы платите за ИИ-IDE — полезно знать, за что именно.

Читать статью →

Контейнеры

4. 6 советов, которые прокачают работу с Docker

Многоэтапные сборки, кеширование слоёв, health checks, .dockerignore и другие практики, которые сокращают время сборки и размер образов. 7 600+ просмотров.

Читать статью →

5. Контейнеры после Docker: Podman и что нас ждёт

Docker — уже не единственный вариант. Podman работает без демона, поддерживает rootless-режим из коробки и совместим с Docker CLI. Обзор состояния экосистемы контейнеров в 2026 году.

Читать статью →

6. 5 вещей про Docker, которые должен знать фронтенд-разработчик

Docker для тех, кто привык к npm start. Зачем фронтендеру контейнеры, как контейнеризировать React/Next.js-приложение и что такое Docker Compose на практике.

Читать статью →

Инструменты и приёмы

7. Bruno API Client — альтернатива Postman

Коллекции хранятся в Git, нет облачного аккаунта, работает офлайн. Bruno дошёл до версии 1.35 и стал серьёзной альтернативой Postman для тех, кому важна приватность и версионирование API-запросов. 6 200+ просмотров.

Читать статью →

8. 7 команд Linux, которые экономят время

Команды за пределами стандартного набора: от быстрого поиска по истории до мониторинга ресурсов. Подойдёт и тем, кто только осваивает терминал, и тем, кто ищет новые трюки.

Читать статью →

9. Playwright + VS Code: автотест за 15 минут

Пошаговый гайд: установка Playwright, расширение для VS Code, запись и запуск первого теста. Полезно, если откладывали автотесты — теперь порог входа ниже некуда.

Читать статью →

10. 1% разработчиков используют дебаг в VS Code. 99% — console.log

Исследование показало, что подавляющее большинство разработчиков игнорирует встроенный дебаггер VS Code. Разбор: почему так происходит, что теряют те, кто не дебажит, и стоит ли менять привычки.

Читать статью →

Что такое Kubernetes

Kubernetes (произносится «кубернетес», сокращённо K8s) — это система оркестрации контейнеров с открытым исходным кодом, которая автоматизирует развёртывание, масштабирование и управление контейнеризированными приложениями. Kubernetes был создан компанией Google на основе внутренней системы Borg и передан в открытый доступ в 2014 году. Сегодня он управляется фондом Cloud Native Computing Foundation (CNCF).

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

- Kubernetes автоматизирует развёртывание, масштабирование и управление контейнерами - Основные сущности: Pod, Node, Cluster, Deployment, Service, Namespace - Архитектура делится на Control Plane (управление) и Worker Nodes (исполнение) - K8s поддерживает самовосстановление: упавший Pod перезапускается автоматически - Kubernetes подходит для больших распределённых систем; для небольших проектов достаточно Docker Compose - Минимальный старт — Minikube или kind на локальной машине за 10 минут - Облачные решения GKE, EKS, AKS берут на себя управление Control Plane - По данным CNCF на 2024 год, Kubernetes используют или оценивают более 84% организаций (CNCF 2023)

Зачем нужен Kubernetes — проблема управления контейнерами в масштабе

Контейнеры решили проблему «у меня работает, у тебя не работает» — приложение вместе со всеми зависимостями упаковывается в изолированный образ. Но с ростом количества контейнеров появляются новые проблемы.

• Высокая доступность. Если контейнер упал — его нужно перезапустить. Вручную это нереально при сотнях сервисов.
• Балансировка нагрузки. Трафик нужно распределять между несколькими экземплярами одного сервиса.
• Масштабирование. В час пик нужно быстро добавить экземпляры, ночью — убрать, чтобы сэкономить ресурсы.
• Обновления без даунтайма. Rolling update или blue-green деплой требуют координации.
• Управление конфигурацией и секретами. Переменные среды, токены, сертификаты — всё это нужно доставлять в контейнеры безопасно.
• Размещение на серверах. Решить, на каком из 50 серверов запустить очередной контейнер, учитывая доступные ресурсы CPU и памяти.

По данным CNCF, организации, использующие микросервисную архитектуру, в среднем управляют более чем 10 сервисами в продакшене, а крупные компании — тысячами. Вручную это не масштабируется. Kubernetes решает все перечисленные задачи декларативно: вы описываете желаемое состояние системы, а K8s сам приводит её к этому состоянию и поддерживает его.

Основные концепции Kubernetes

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

Pod — минимальная единица развёртывания

Pod — это один или несколько контейнеров, которые всегда запускаются вместе на одном узле и разделяют сетевое пространство (один IP-адрес) и тома хранилища. Обычно один Pod = один контейнер с основным приложением. Второй контейнер в Pod используется как sidecar: например, для сбора логов или проксирования трафика.

Node — рабочий узел кластера

Node (узел) — это физическая или виртуальная машина, на которой запускаются Pod-ы. Каждый узел содержит kubelet (агент, который следит за Pod-ами), kube-proxy (сетевые правила) и container runtime (Docker, containerd или CRI-O). В кластере обычно несколько узлов — от 3 до тысяч в крупных системах.

Cluster — совокупность всех узлов

Cluster (кластер) — это набор узлов, управляемых единым Control Plane. Весь Kubernetes работает внутри кластера. Один кластер может объединять сотни серверов в разных датацентрах.

Deployment — управление жизненным циклом приложения

Deployment — это объект, который описывает желаемое состояние для набора Pod-ов: сколько реплик должно работать, какой образ использовать, как выполнять обновления. Deployment следит за тем, чтобы нужное количество Pod-ов всегда было запущено, и управляет rolling-обновлениями.

Service — стабильная точка доступа к Pod-ам

Service — это абстракция, которая предоставляет стабильный IP-адрес и DNS-имя для набора Pod-ов. Pod-ы могут создаваться и удаляться, их IP меняется — Service обеспечивает постоянную точку входа и балансирует нагрузку между ними. Основные типы: ClusterIP (внутри кластера), NodePort (снаружи по порту узла), LoadBalancer (облачный балансировщик).

Namespace — изоляция ресурсов внутри кластера

Namespace — это виртуальный раздел внутри кластера. Позволяет изолировать ресурсы разных команд, проектов или окружений (dev, staging, production) в рамках одного кластера. По умолчанию существуют namespace-ы: default, kube-system, kube-public.

Как работает Kubernetes — архитектура изнутри

Kubernetes состоит из двух уровней: Control Plane (управляющий слой) и Worker Nodes (рабочие узлы). Разберём каждый компонент.

Control Plane — мозг кластера

• API Server (kube-apiserver) — единственная точка входа для всех операций с кластером. Все компоненты общаются только через API Server. kubectl, CI/CD системы, внутренние контроллеры — всё идёт через него. Принимает REST-запросы, валидирует их и сохраняет состояние в etcd.
• etcd — распределённое хранилище типа «ключ-значение», где хранится всё состояние кластера: конфигурации, метаданные Pod-ов, секреты. Это единственное место с состоянием в Kubernetes — если etcd жив, кластер восстановим.
• Scheduler (kube-scheduler) — отвечает за размещение новых Pod-ов на узлах. Учитывает доступные ресурсы узлов, affinity-правила, ограничения и политики. Не запускает Pod-ы сам — только решает, на каком узле их запустить.
• Controller Manager (kube-controller-manager) — набор контроллеров, каждый из которых следит за определённым типом ресурсов. Deployment Controller следит, чтобы работало нужное число реплик. Node Controller реагирует на отказ узлов. ReplicaSet Controller поддерживает заданное количество Pod-ов.

Worker Nodes — исполнители

• kubelet — агент на каждом узле. Получает от API Server описание Pod-ов, которые должны работать на этом узле, запускает их через container runtime и сообщает статус.
• kube-proxy — управляет сетевыми правилами на узле (iptables или IPVS). Обеспечивает работу Service: трафик к виртуальному IP Service перенаправляется на реальные Pod-ы.
• Container Runtime — движок для запуска контейнеров. Kubernetes поддерживает containerd (рекомендован), CRI-O и Docker Engine через специальный shim.

Типичный жизненный цикл запроса: вы применяете YAML через kubectl apply → API Server сохраняет объект в etcd → Scheduler находит подходящий узел → kubelet на том узле получает задание и запускает контейнер → Controller Manager следит, что всё работает как описано.

Kubernetes vs Docker Compose vs Docker Swarm — когда что использовать

Выбор инструмента зависит от масштаба задачи. Не стоит использовать Kubernetes там, где достаточно Docker Compose — это избыточная сложность.

• Docker Compose — идеально для локальной разработки и небольших проектов на одном сервере. Простой синтаксис, быстрый старт, нет оверхеда. Не умеет автоматически восстанавливаться при отказе хоста, не масштабируется горизонтально.
• Docker Swarm — встроенная кластеризация Docker. Проще Kubernetes, подходит для небольших кластеров (2–10 серверов), когда не нужны продвинутые возможности. Экосистема значительно меньше, развитие заморожено.
• Kubernetes — для продакшен-систем с требованиями к высокой доступности, горизонтальному масштабированию, сложным сетевым политикам и богатой экосистеме. Оправдан при наличии хотя бы 3–5 сервисов и команды DevOps.

Если вы можете управлять системой через Docker Compose — используйте Docker Compose. Kubernetes стоит выбирать, когда боль от ручного управления стала больше, чем сложность K8s.

Ключевые отличия в цифрах: Docker Compose запускается за секунды, Kubernetes требует минимум 3 узла для продакшена и несколько часов на начальную настройку. Зато Kubernetes поддерживает до 5000 узлов и 150 000 Pod-ов в одном кластере.

Как начать работу с Kubernetes

Для изучения и разработки не нужен облачный кластер. Есть несколько способов запустить Kubernetes локально.

Minikube — классический локальный кластер

Minikube запускает однонодовый кластер Kubernetes в виртуальной машине или контейнере. Поддерживает macOS, Linux и Windows. Встроен dashboard, поддержка нескольких профилей и дополнений.

kind — Kubernetes в Docker

kind (Kubernetes IN Docker) запускает узлы кластера как Docker-контейнеры. Быстрее Minikube, идеален для CI/CD и тестирования, поддерживает многонодовые кластеры.

Облачные управляемые сервисы

Для продакшена большинство команд выбирает управляемый Kubernetes — облачный провайдер берёт на себя Control Plane, обновления и резервирование etcd.

• GKE (Google Kubernetes Engine) — оригинальный управляемый K8s от Google. Лучшая интеграция с экосистемой Google Cloud, автопилот-режим для полностью управляемой инфраструктуры.
• EKS (Amazon Elastic Kubernetes Service) — Kubernetes на AWS. Глубокая интеграция с сервисами AWS: IAM, ALB, EBS. Самый популярный выбор среди enterprise-компаний.
• AKS (Azure Kubernetes Service) — K8s на Microsoft Azure. Хорошая интеграция с Azure Active Directory, бесплатный Control Plane.
• Yandex Managed Service for Kubernetes — российский вариант с серверами в РФ, интеграция с Yandex Cloud.

Помимо самого кластера, при работе с REST API сервисов внутри Kubernetes понадобится настроить Ingress-контроллер (nginx, Traefik) для маршрутизации внешних HTTP-запросов к нужным Service-ам.

Выводы

Kubernetes — это де-факто стандарт оркестрации контейнеров в 2024–2025 годах. По данным CNCF Annual Survey, более 84% компаний используют или оценивают K8s, а рынок контейнерной оркестрации продолжает расти двузначными темпами.

Kubernetes решает реальные проблемы масштаба: автоматическое самовосстановление, горизонтальное масштабирование, нулевой даунтайм при обновлениях, декларативное управление инфраструктурой. За это приходится платить сложностью — не стоит применять K8s там, где хватает Docker Compose.

Путь в Kubernetes начинается с понимания контейнеров, затем — знакомство с kubectl и Minikube, первые Deployment-ы и Service-ы, потом — изучение Ingress, ConfigMap, Secret, HorizontalPodAutoscaler. Это путь в несколько месяцев, но он открывает доступ к одной из самых востребованных технологий в DevOps.

Изучаете облачные технологии? Прочитайте наши статьи о микросервисной архитектуре и Docker — они помогут выстроить полную картину современной облачной разработки. Автоматизировать деплой в Kubernetes поможет CI/CD: пайплайн собирает образ, прогоняет тесты и автоматически деплоит в кластер.

Если хотите собрать Kubernetes не как отдельный страшный инструмент, а как часть цельного пути, посмотрите план обучения DevOps-инженера. Там видно, почему Kubernetes появляется после Docker, CI/CD и инфраструктуры, а не вместо них.

Docker — это платформа для контейнеризации приложений. Она позволяет упаковать программу вместе со всеми её зависимостями в изолированный контейнер, который одинаково работает на любом компьютере — от ноутбука разработчика до боевого сервера. Docker выпущен в 2013 году компанией Docker, Inc. и с тех пор стал стандартом индустрии: по данным Stack Overflow Developer Survey 2023, его используют более 52% профессиональных разработчиков.

— Docker упаковывает приложение и все его зависимости в контейнер, который запускается одинаково в любой среде

— Контейнер — это запущенный экземпляр образа, а образ — шаблон для создания контейнеров

— Dockerfile описывает, как собрать образ, а Docker Compose управляет несколькими контейнерами сразу

— Docker потребляет значительно меньше ресурсов, чем виртуальная машина, и запускается за секунды

— Для начала работы достаточно установить Docker Desktop и выполнить одну команду

Зачем нужен Docker — проблема «у меня работает»

Каждый разработчик хотя бы раз сталкивался с классической ситуацией: код отлично работает на его машине, но ломается на сервере или у коллеги. Причина — различия в окружении: другая версия языка, недостающая библиотека, конфликт зависимостей.

Docker решает эту проблему радикально. Вместо того чтобы настраивать каждое окружение вручную, вы упаковываете приложение вместе со всем необходимым в контейнер. Этот контейнер работает одинаково везде — на macOS, Windows, Linux, в облаке AWS или на сервере в дата-центре.

Вот что это даёт на практике:

• Воспроизводимость — «у меня работает» превращается в «работает у всех»
• Изоляция — приложения не мешают друг другу, каждое живёт в своём контейнере
• Скорость развёртывания — новый сервер поднимается за секунды, а не за часы
• Масштабирование — нужно больше мощности? Запустите ещё контейнеров

Основные понятия Docker

Образ (Image)

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

Образы хранятся в реестрах (registry). Самый популярный — Docker Hub, где доступны тысячи готовых образов: Python, Node.js, PostgreSQL, Nginx и многие другие.

Контейнер (Container)

Контейнер — это запущенный экземпляр образа. Если образ — это класс, то контейнер — это объект. Внутри контейнера работает ваше приложение в изолированном окружении со своей файловой системой, сетью и процессами.

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

Dockerfile

Dockerfile — это текстовый файл с инструкциями для сборки образа. Каждая строка описывает один шаг: какой базовый образ взять, какие файлы скопировать, какие пакеты установить, какую команду запустить.

Пример Dockerfile для Python-приложения:

Разберём построчно:

• FROM python:3.12-slim — базовый образ с Python 3.12
• WORKDIR /app — рабочая директория внутри контейнера
• COPY requirements.txt . — копирует файл зависимостей
• RUN pip install — устанавливает зависимости
• COPY . . — копирует остальной код
• CMD — команда запуска приложения

Docker Compose

Docker Compose — инструмент для запуска многоконтейнерных приложений. Реальные проекты редко состоят из одного сервиса: обычно есть веб-сервер, база данных, кеш, очередь сообщений. Compose описывает их все в одном файле compose.yml.

Пример — веб-приложение с PostgreSQL и Redis:

Одна команда docker compose up поднимает все три сервиса разом. Остановить — docker compose down.

Как начать работу с Docker

1. Скачайте и установите Docker Desktop (Windows, macOS) или Docker Engine (Linux)
2. Проверьте установку командой docker --version
3. Запустите первый контейнер

Вот команда, которая запустит ваш первый контейнер:

Docker скачает образ hello-world из Docker Hub и запустит контейнер, который выведет приветственное сообщение. Весь процесс занимает несколько секунд.

Хотите попробовать что-то серьёзнее? Запустите Nginx-сервер одной командой:

Откройте http://localhost:8080 в браузере — там будет работающий веб-сервер. Флаг -d запускает контейнер в фоне, а -p 8080:80 пробрасывает порт.

Больше полезных команд для ежедневной работы — в нашей подборке 10 команд Docker, которые должен знать каждый разработчик.

Docker и виртуальная машина — в чём разница

На первый взгляд Docker похож на виртуальную машину (VM): и то, и другое изолирует приложения. Но под капотом — принципиально разные подходы.

Виртуальная машина эмулирует целый компьютер: процессор, память, диск, сетевую карту. Внутри VM работает полноценная операционная система со своим ядром. Это тяжело — VM занимает гигабайты памяти и запускается минутами.

Контейнер Docker использует ядро хост-системы и изолирует только процессы приложения. Это легко — контейнер весит мегабайты и стартует за секунды.

• Размер: образ Docker — 50–500 МБ, VM — 5–20 ГБ
• Запуск: контейнер — 1–3 секунды, VM — 1–5 минут
• Ресурсы: на одном сервере работают десятки контейнеров, но лишь единицы VM
• Изоляция: VM — полная (отдельное ядро ОС), контейнер — на уровне процессов

Когда использовать что: Docker подходит для микросервисов, CI/CD и быстрого развёртывания. VM — когда нужна полная изоляция на уровне ОС, например для запуска Windows-приложений на Linux-хосте.

Заключение

Docker изменил подход к разработке и развёртыванию приложений. Вместо многочасовой настройки серверов — одна команда. Вместо «у меня работает» — гарантированная воспроизводимость на любой машине.

Начните с малого: установите Docker, запустите docker run hello-world, а затем контейнеризируйте свой pet-проект. Когда освоите основы — переходите к Docker Compose для многосервисных приложений.

Docker — ключевой строительный блок современной DevOps-экосистемы. Контейнеры отлично сочетаются с микросервисной архитектурой — каждый сервис упаковывается в отдельный образ и деплоится независимо. Когда сервисов становится много, ими начинает управлять Kubernetes. А автоматизировать сборку и доставку образов поможет CI/CD — связка Docker + CI/CD является стандартом современной разработки.

Если хотите понять, какое место Docker занимает во всей цепочке, посмотрите план обучения DevOps-инженера. Там Docker показан как мост между Git, CI/CD, инфраструктурой и Kubernetes.

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

Что такое Dockerfile

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

Для приложения важно, чтобы контейнер, в котором оно запускается, всегда собирался правильно и единообразно. Чтобы этого добиться, нужно подготовить специальную инструкцию — Dockerfile. В этом файле описывают, какой базовый образ взять за основу, какое ПО установить, какие команды выполнить при запуске приложения и так далее.

Dockerfile можно составить по-разному, и даже самые примитивные его варианты могут работать, но это не значит, что их стоит использовать. Давайте вместе пройдём путь от самого простого Dockerfile до состояния production ready.

1. Лишь бы запустилось

Представим, что мы написали приложение на Go, которое нужно поскорее залить в продакшен. Подготовим простейший Dockerfile:

Тут я взял последнюю версию образа Golang, скопировал весь проект, установил зависимости, собрал и запустил бинарник.

Внешне всё хорошо: образ собирается, приложение запускается. Но на самом деле у меня получился типичный результат из серии «минимум усилий — максимум проблем». И вот почему:

• Получившийся образ очень тяжёлый — весит 1,3 ГБ. В него попали папка .git, README, тесты и другие файлы, которые засоряют рантайм.
• Сборка непредсказуема, так как для базового образа Golang используется тег latest — завтра версия Go может измениться, и контейнер уже не будет идентичен текущему.
• Каждая новая сборка занимает 5–10 минут, потому что каждый билд начинается с нуля, а кеши слоев инвалидируются из-за появления новых файлов.
• Коллегам будет непонятно, кто собирал образ и зачем, — история сборок непрозрачная, так как нет меток (LABEL).
• Есть риски безопасности — команды в контейнере запускаются с правами пользователя root, поэтому любое уязвимое приложение получает права администратора внутри контейнера.

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

2. Первые улучшения: воспроизводимая сборка

Чтобы версия Golang не менялась от сборки к сборке, пропишем в Dockerfile конкретную версию. Это также сделает образ воспроизводимым и уменьшит его объём.

Добавим метки LABEL, чтобы было понятно, что это за образ и кто его поддерживает. Также благодаря меткам этот Dockerfile будет проще найти в registry.

Определим рабочую директорию (WORKDIR) для организации файлов внутри контейнера и заменим go mod tidy на go mod download. Дело в том, что tidy в Docker — плохая идея, потому что он меняет манифесты зависимостей, может модифицировать go.mod/go.sum. Это делает билд непредсказуемым: вы каждый раз рискуете получить чуть другой результат. go mod download лишён этого недостатка — он просто скачивает зависимости строго по зафиксированным манифестам.

И напоследок выделим в отдельный файл (.dockerignore) всё то, что не должно попадать в образ.

Вот что получилось:

Хорошие новости: образ стал весить меньше, стал воспроизводимым, а благодаря меткам и выделенной директории с ним стало удобнее работать. Но есть и плохая: образ по-прежнему не дотягивает до production ready.

• Для запуска образа нужен только бинарник, а в моём случае в финальном образе остаются исходники и кеш. Сборку и запуск лучше разделить, чтобы не тянуть в итоговый образ лишнее.
• Я добавил .dockerignore, но он не идеален: в образ по-прежнему попадают тесты, временные файлы, а возможно, и конфиденциальная информация, например токены, ключи.
• Я не выделил отдельного пользователя, от которого запускается контейнер, а значит, не решил проблему запуска от root, которая была ещё на прошлом этапе.

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

3. Multi-stage build: разделяем сборку и запуск образа

Прежде всего, избавимся от лишнего: чтобы в финальный образ не попадали исходники и кеш, применим multi-stage-подход к созданию Dockerfile. Он предполагает, что сборка и запуск образа происходят на разных стадиях (stages). Таким образом, все зависимости и необходимые для сборки файлы останутся только на первой стадии.

Чтобы решить проблему с root, добавим группу пользователей и конкретного пользователя, от имени которого будет запускаться приложение.

Также учтём потребности приложения в runtime-зависимостях и конфигурации. Наше приложение работает с PostgreSQL, поэтому добавим в образ клиент postgresql17-client — он понадобится для запуска миграций через psql перед стартом приложения. А ещё приложение использует токен для авторизации API-запросов — пока передадим его через переменную окружения API_TOKEN.

В итоге Dockerfile будет выглядеть так:

Разберём, что ещё было сделано, чтобы оптимизировать образ. На этапе сборки я:

• зафиксировал зависимости — скачал их строго по зафиксированному go.sum;
• собрал бинарник для Linux, чтобы сборка всегда проходила верно, даже если builder-образ изменится или сборка будет кросс-платформенной;
• явно задал имя бинарника через флаг -o myapp — это гарантирует, что имя файла всегда совпадёт с тем, на которое ссылаются COPY и ENTRYPOINT, даже если имя модуля в go.mod отличается от названия приложения;
• сделал Go-бинарник независимым от системных библиотек, что позволит избежать проблем с совместимостью;
• использовал ENTRYPOINT вместо CMD — теперь ./myapp нельзя случайно переопределить при docker run, а переданные аргументы будут добавляться к команде, а не заменять её.

На этапе подготовки финального образа теперь:

• итоговый образ минимальный и не содержит компилятора Go;
• копируется только бинарник, а не все файлы проекта;
• явно указано, что нужно приложению для запуска (PostgreSQL-клиент);
• кеш пакетного менеджера apk не создаётся и не увеличивает размер образа.

Мы решили проблемы, которые выделили на предыдущем этапе. Dockerfile вроде бы готов к продакшену, но на всякий случай пройдёмся по файлу ещё раз. На этапе запуска можно заметить, что в ENV зашит секретный токен — из-за этого образ точно не пройдёт аудит безопасности, так как конфиденциальные данные нельзя хранить в коде.

Кроме того, контейнеру не помешает HEALTHCHECK — без него Docker не узнает, отвечает приложение или зависло. Также, поскольку Dockerfile уже достаточно объёмный и сложный, можно добавить комментарии к элементам, которые важны для поддержки, но со временем перестанут быть очевидными. И последнее: так как образ предназначен для продакшена, лейблы можно подогнать под стандарты OCI, принятые в большинстве компаний.

4. Финальный рывок: контейнер, которому можно доверять

По традиции учтём недочёты предыдущего этапа и исправим Dockerfile.

Что изменилось:

• Я подогнал лейблы под стандарты OCI — теперь они соответствуют правилам, принятым в корпоративной среде.
• Добавил аргументы BUILD_TIME и VERSION, чтобы время сборки и версия образа динамически добавлялись в метаданные из CI/CD. Это позволит не редактировать Dockerfile вручную при каждом релизе и сделает его более управляемым и прозрачным для аудита.
• Объединил инструкции RUN в одну строку, чтобы сделать образ более компактным и улучшить читабельность.
• Добавил комментарии и инструкции для указания порта и проверки доступности контейнера.
• Определил запуск и поведение контейнера через ENTRYPOINT и CMD.

Теперь в нашем Dockerfile не хранятся чувствительные данные, и он наконец соответствует всем формальным требованиям для продакшена.

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

Сейчас мало кто работает с Dockerfile в терминале — чаще всего это делается через оркестратор, Kubernetes или как минимум Docker Compose. Поэтому, создавая Dockerfile, стоит помнить, что он не существует в отрыве от инфраструктуры. В таких условиях некоторые компоненты передаются в файл извне, а то, что считается лучшей практикой, не всегда применимо в реальности.

Так, в нашем случае передача порта, проверки доступности и параметры запуска могут быть определены в конфигурации инфраструктуры, например в docker-compose.yaml или в манифесте Deployment. Поэтому, чтобы не дублировать инструкции, можно удалить EXPOSE, HEALTHCHECK и CMD.

Вот наш итоговый оптимизированный, стабильный, multi-stage Dockerfile:

В этой статье мы ограничимся таким Dockerfile, однако при желании его можно ещё улучшить: например, вместо версии базового образа использовать хеш контейнера из registry, подключить hadolint для автоматического линтинга, написать README с инструкциями по сборке и запуску, унести секреты в специальное хранилище, добавить проверку на уязвимости.

Проблемы безопасности, найденные на финальных этапах эксплуатации/продакшен, обходятся до тридцати раз* дороже, чем найденные в процессе активной разработки.

ОТП Банк спроектировал и внедрил систему, которая применяет различные практики подходов оценки безопасности DevSecOps при создании каждого Pull Request — ещё до слияния с основной веткой.

За месяц один опытный инженер спроектировал систему, а потом в течение 3 месяцев совместно с коллегами внедрил систему, которая снизила затраты на устранение проблем безопасности до 30 раз и существенно разгрузила нагрузку с команд разработчиков.

* согласно IBM Cost of a Data Breach Report и NIST Guide for Conducting Risk Assessments

Задача: найти уязвимости до их попадания в продакшен

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

Техническая задача — создать автоматический сканер по всем практикам DevSecOps, который выявляет проблемы безопасности на самом раннем этапе: при создании Pull Request для слияния с основной веткой репозитория. Система должна работать независимо от платформы, выдерживать повышенные нагрузки и автоматически создавать задачи на устранение найденных проблем.

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

Параметры проекта

Срок создания архитектуры: 1 месяц

Срок разработки: 3 месяца от постановки задачи до релиза

Технологический стек: Python, Docker Compose, PostgreSQL, LDAP, LLM

Статус: внутренняя разработка, активно развивается

Архитектура: модульная система на Docker

Система представляет набор сервисов на Docker Compose, которые можно развернуть на любой машине на базе ОС *nix.

* - любой из возможных префиксов существующих ОС, построенных на базе Unix.

Архитектура построена по модульному принципу:

→ Модуль обработки/записи событий от внешних систем

→ Модуль управления очередью очереди событий

→ Модуль управления состоянием событий

→ Модули для каждой практики DevSecOps

→ Модули сервисных процедур

→ Модули работы с таблицами базы данных

→ Модуль автоматического создания задач в job-tracker

→ Ядро системы

Описание функционала:


Pull Request создан/изменён

Внешними системами созданы WEB-hooks

→ Каждый модуль системы отвечает за конкретную практику DevSecOps/сервисную процедуру

→ Ядро обеспечивает координацию работы модулей и реализацию логики системы в целом

→ Результаты записываются в единую базу данных на основе PostgreSQL

→ Логи работы системы и её компонентов передаются в БД или внешний агрегатор событий

→ Автоматическое создание задач на устранение проблем

→ Аутентификация через LDAP

→ Дедубликация уязвимостей

Ядро системы управляет соответствующими модулями выявления проблем с безопасностью, а также прочими сервисными процедурами. Каждый сервис является самостоятельным и отвечает за функционал по конкретной практике DevSecOps. Это даёт независимость от платформы и возможности горизонтального и вертикального масштабирования.

Модульная архитектура была выбрана, потому что это удобно и потенциально выгодно для горизонтального расширения, есть возможность создания контуров High Availability. Каждый модуль можно масштабировать отдельно под нагрузку.

Пять ключевых возможностей сканера

1. Проверка на этапе Pull Request

Система срабатывает автоматически при попытке слить код с основной веткой. Разработчик создаёт PR — сканер запускается и анализирует изменения на все известные уязвимости.

В едином инструменте разработчика видны статусы прохождения Quality Gate. Ссылки на отчёты находятся прямо в Git-системе, а цвет отчёта сразу говорит о наличии проблем.

2. Полная автоматизация без участия команды

Вся проверка происходит без действий со стороны разработчиков или DevSecOps-инженеров. Не нужно запускать сканы вручную, отслеживать результаты или формировать отчёты. Система сама находит проблемы, записывает их в базу и создаёт задачи на устранение с указанием ответственных лиц.

Не требуется привлечение команд для настройки pipeline. Автоматическое создание задач включает проверку на дублирование — если задача на такую же уязвимость уже есть, новую не создаём.

3. Интеграция со сторонними инструментами

Сканер может работать с внешними сканерами безопасности и агрегаторами событий. Это позволяет встроить его в существующую инфраструктуру банка без перестройки процессов. Логи системы передаются в PostgreSQL или внешние системы мониторинга.

В BI на дашборде можно получить информацию по статусам сканирования всех проектов. Менеджеры могут получить общую картину состояния безопасности по каждому проекту Банка.

4. Работа под высокой нагрузкой

Система выдерживает одновременную проверку множества Pull Request без деградации производительности. Модульная архитектура позволяет масштабировать сервисы горизонтально — добавлять новые контейнеры под нагрузку, или вертикально — увеличивать ресурсы существующих.

5. Фильтрация ложных срабатываний через LM

Статические анализаторы кода часто выдают false positive — помечают безопасный код как небезопасный, но в реальности это не так. Это создаёт шум и заставляет разработчиков тратить время на проверку несуществующих проблем. Для решения этой задачи в систему интегрировали специализированную языковую модель, которая анализирует контекст и отсеивает ложные срабатывания.

Отчёт о найденных уявимостях содержит только релевантную информацию.

6. Модификация пояснений к уявзимостям через LM

Статические анализаторы кода часто предоставляют инструкцию по устранению выявленных уязвимостей в неинтуитивном/неструктурированном виде. Это создаёт трудности для разработчиков и увеличивает time-to-market для создаваемых программных продуктов в целом. Для решения этой задачи в систему интегрирована большую специализированная языковая модель, которая оптимизирует текст и делает инструкция более понятной и эффективной.

Задачи содержат эффективные инструкции по устранению выявленных уязвимостей в коде.

7. Дайджест по уязвимостям

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

В отчёте есть дайджест по найденным уязвимостям с понятным описанием. Разработчик сразу видит, что критично, а что можно отложить.

Главные трудности в реализации

🔴 Сложность логики выявления артефактов сканирования

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

✅ Решение: Провели анализ выходных данных всех используемых инструментов и создали унифицированные модули парсинга. Каждый модуль преобразует специфичный формат внешнего сканера в единую структуру для записи в PostgreSQL.

🔴 Специфика работы разных сканеров

Инструменты DevSecOps работают по-разному: одни проверяют зависимости, другие — статический код, третьи — конфигурации. Нужно было объединить их в единую систему без потери функциональности.

✅ Решение: Разработали модульную архитектуру, где каждый сервис отвечает за конкретную практику DevSecOps и работает независимо. Это позволило легко добавлять новые типы проверок без переписывания всей системы.

🔴 Отсутствие информации о состоянии процессов

Внешние системы не всегда предоставляют актуальную информацию о статусе проверок в режиме реального времени. Сложно понять, завершился ли скан или ещё выполняется.

✅ Решение: Настроили систему событий (events), которая отслеживает изменения состояний во внешних инструментах и синхронизирует данные.

🔴 Отсутствие стандартизации в выполнении операций в CI/CD

Современные системы CI/CD предоставляют обширный выбор в реализации того или иного шага, будь то сборка проекта или пуш готового образа. Есть сложность в интерпретации выполняемых операций и предсказания ожидаемого типа артефакта на выходе, например, образ или биллютень используемых в разработке сторонних компонентов.

✅ Решение: Создали отдельные модули анализа и парсинга этапов CI/CD, что позволило гарантировано определить scope применимых практик DevSecOps, тем самым повысить эффективность оценки уровня безопасности проекта в целом.

Результаты: экономия и качество кода

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

Главные эффекты для бизнеса: повышение качества кода продукта через постоянные автоматические проверки, снижение репутационных рисков компании за счёт предотвращения утечек и инцидентов безопасности, снижение технического долга команд разработки, улучшение процессов разработки через встраивание security practices в ежедневный workflow.

Полная автоматизация освободила разработчиков и DevSecOps-инженеров от рутинной работы по запуску сканов и анализу результатов. Система работает сама — от триггера PR до создания задачи на исправление.

Планы развития

1. Интегрировать в систему процессы выявления проблем безопасности при разработки собственных LM;
2. Интегрировать в систему процессы выявления проблем безопасности при разработки агентов AI;
3. Интегрировать в систему процессы выявления проблем безопасности при внедрении LLM;
4. Интеграция с системой класса ASPM;
5. Интеграция с собственной системой уведомления;
6. Внедрение метрик health-check для оценки состояния работоспособности системы и её компонентов.

Реклама. АО «ОТП Банк», ИНН 7708001614, erid: 2W5zFHcyG5F

1. H3LLO.CLOUD

H3LLO.CLOUD — молодая, но амбициозная облачная платформа гиперскейлерского уровня, построенная с нуля без легаси и на передовом железе. Облако уже находится в боевой эксплуатации, с гарантированным SLA 99.97% и возможностью масштабирования клиентских нагрузок в 10 раз и более в моменте. Команда обещает бенчмарк на уровне 1 миллиарда запросов в секунду — подобную нагрузку держит только AWS. Пока кейсы клиентов в процессе подготовки, платформа уже показывает уверенную стабильность: с момента запуска не было зафиксировано ни одного падения нагрузки в проде. Под капотом — каналы до 800 Гбит/с, внутренние сети на 400 Гбит/с, балансировщик нагрузки, автоскейлинг (в разработке), быстрый отклик техподдержки (от нескольких минут до пары часов).

H3LLO.CLOUD предлагает IaaS и PaaS: виртуальные машины, объектное хранилище (S3), DNS, балансировщики, базы данных, Kubernetes, очереди и SOC — всё на собственной платформе без OpenStack. В архитектуре предусмотрено размещение в трёх дата-центрах: два в IXCellerate (Москва) и один собственный, до конца года появятся еще пять региональных площадок. Используются серверы последнего поколения HP Proliant Gen11 на процессорах Intel Gen6 и памяти DDR5 — это дороже, но в 3 раза быстрее, обеспечивая до 40% экономии для клиента.

Условия тарификации прозрачны: базовый набор ресурсов (2 vCPU, 4 ГБ RAM, 40 ГБ диска, белый IP, база данных, 100 ГБ S3 и Load Balancer) предоставляется на год бесплатно при пополнении баланса всего на 5000₽. Управление — через собственную панель с мониторингом, поддержка API и скриптов для автоматизации.

2. L1veStack

L1veStack — бессерверная PaaS-платформа, созданная для быстрого развёртывания, управления и масштабирования приложений на базе Docker-контейнеров. Это решение фокусируется на упрощении работы DevOps-инженеров и разработчиков: запуск микросервисов происходит за секунды, а мониторинг и настройка портов — через интуитивную панель. SLA платформы составляет 99.97%, показатели отказоустойчивости и масштабируемости соответствуют продакшен-нагрузкам. Кейсы клиентов находятся в процессе, однако инфраструктура уже стабильно работает в разных сценариях: от слабонагруженных Dev-сред до боевых систем с нестабильным трафиком.

L1veStack подходит для тех, кто ищет баланс между простотой VPS и возможностями облачной архитектуры. Платформа реагирует на пиковые нагрузки, адаптируясь под разные среды: dev, stage, прод и внутренние сервисы. Средний аптайм — 99.97%, масштабирование происходит гибко и без участия пользователя.

Цены прозрачны:

• 1%vCPU (High Performance) — 0,45 ₽/час
• MB RAM (DDR5) — 0,00085 ₽/час
• GB SSD (3xReplicated) — 0,015 ₽/час
• IPv4 Public IP — 0,015 ₽/час

Сейчас проект в бете: все ресурсы предоставляются бесплатно, а ранние пользователи получат бонусы. Управление — через удобную визуальную панель со статусами контейнеров и настройкой в пару кликов.

3. Incloud

Incloud — облачная платформа для бизнеса любого масштаба, работающая на отказоустойчивом кластере VMware с использованием Enterprise-СХД NetApp и HPE 3PAR. Вся инфраструктура резервирована: дублируются сетевые устройства, питание обеспечивается двумя вводами от разных подстанций и собственными дизельными генераторами. Это гарантирует стабильность и защищённость сервисов, что подтверждается аптаймом 100% за последние 12 месяцев при SLA 99.95%.

На платформе развёрнуты десятки проектов малого и среднего бизнеса, в том числе NT-IT — IT-аутсорсер, обслуживающий клиентов с разнообразной инфраструктурой. До перехода в облако Incloud компании приходилось сталкиваться с разрозненными системами и частыми инцидентами у разных провайдеров. После миграции в Incloud удалось централизовать управление пулами ресурсов, сократить сроки запуска новых проектов с нескольких дней до часов и снизить число простоев до минимума. Инженеры NT-IT отмечают быстрый отклик поддержки и возможность гибкого масштабирования без расширения штата.

Incloud предоставляет IaaS и SaaS-решения, включая корпоративную почту Exchange, базы данных и 1С. Масштабирование происходит мгновенно за счёт резерва мощностей: в любой момент можно увеличить ресурсы под пиковую нагрузку. Среднее время реакции техподдержки на инциденты — 15 минут.

Тарифы прозрачны: базовый CPU — от 250 ₽, RAM — от 200 ₽ за 1 ГБ, диски — от 4 ₽ за 1 ГБ (SATA) до 12 ₽ (SSD/NVMe), резервные копии — 2 ₽ за 1 ГБ. Для производительных конфигураций CPU доступен от 500 ₽ за ядро и RAM — от 250 ₽. Калькулятор для расчёта доступен на сайте.

4. Cloud.ru

Cloud.ru Evolution — это масштабируемая облачная платформа, построенная на собственных технологиях и открытых компонентах. Пользователям доступны десятки IaaS- и PaaS-сервисов: от виртуальных машин и управляемых баз данных до платформы для ML-задач и AI-инструментов. Облачная инфраструктура размещена в дата-центрах Tier III на территории РФ, соответствует требованиям 152-ФЗ и аттестована по УЗ-1. SLA — 99.95%.

Платформа работает по модели «pay-as-you-go» и предлагает гибкую архитектуру: Managed Kubernetes, бессерверные контейнеры, балансировщики нагрузки, геораспределённые хранилища и поддержку Terraform. Есть и физические выделенные серверы, и мощные вычислительные ресурсы с GPU. Новые пользователи получают грант в 4000 бонусов и доступ к free tier. В числе PaaS-инструментов — Kafka, Redis, PostgreSQL, ArenadataDB, Spark, Trino и платформа AI Factory с LLM, инференсом, агентами и обучением ML-моделей в распределённой среде. Панель управления объединяет весь стек облачных сервисов и даёт полный контроль над расходами, доступами и ресурсами.

Cloud.ru подходит как для построения базовой инфраструктуры проекта, так и для сложных AI- и data-driven-сценариев. Среди преимуществ — поддержка контейнеров, работа с Terraform и CLI, встроенные инструменты безопасности и быстрое масштабирование.

Узнать цену для своего сервиса можно через калькулятор.

5. Selectel

Частное облако Selectel — решение для проектов со строгими требованиями к информационной безопасности и кастомизации. Оно может быть развернуто как на инфраструктуре Selectel, так и on-premise, с полным сопровождением инженеров 24/7, лицензированием по модели «за хост» и временем реакции на критические инциденты от 15 минут. Облако полностью совместимо с OpenStack и входит в реестр российского ПО.

Selectel проектирует архитектуру под конкретные задачи клиента: гибкая настройка железа (Intel Xeon, AMD EPYC, NVIDIA GPU), интеграция с СХД, конвергентное и гиперконвергентное хранение на базе Ceph. Возможны сценарии с геораспределённостью и гибридной инфраструктурой. Поддерживаются масштабируемые отказоустойчивые базы данных (PostgreSQL, Kafka, Redis и др.) и Managed Kubernetes до 1 500 нод с GPU-кластерами.

Компания также реализует меры защиты данных под любые регуляторные требования: 152-ФЗ, ФСТЭК №17/21, ГОСТ Р 57580, PCI DSS 4.0. Selectel помогает пройти аттестацию до К-1/УЗ-1 и развивать инфраструктуру с ежемесячными обновлениями и SLA до 99.98%. Это облако для тех, кому нужно не просто IaaS, а стабильная и безопасная цифровая среда, полностью адаптированная под бизнес.

Цены рассчитываются индивидуально.

6. VK Cloud

VK Cloud — универсальная облачная платформа, включающая широкий спектр IaaS- и PaaS-сервисов для разработки, хранения данных, масштабирования и построения отказоустойчивой cloud-native инфраструктуры. Платформа подходит как для стартапов, так и для крупных корпоративных заказчиков, предлагая гибкие условия подключения, бесплатную миграцию и сертифицированную безопасность.

VK Cloud предоставляет виртуальные серверы, сети, объектное хранилище, управляемые базы данных, Kubernetes-кластеры, а также решение VK Data Lakehouse для работы с большими данными. Вся инфраструктура размещена в дата-центрах уровня Tier III в России и соответствует требованиям 152-ФЗ, ГОСТ Р 57580, ISO, PCI DSS. Облачные серверы аттестованы по 152-ФЗ.

Платформа построена на OpenSource и российском ПО, обеспечивает единое резервируемое окружение, автоматическое масштабирование, плановые бэкапы и послеаварийное восстановление. SLA — 99,95% с финансовыми гарантиями. Поддержка 24/7 и «IT-служба одного окна» делают VK Cloud удобным выбором для любых сценариев.

Дополнительно: приветственный бонус 5000 ₽ для новых аккаунтов (до 12 000 ₽ — для юрлиц), гранты до 2 млн ₽ для стартапов и 10 000 ₽/мес. для благотворительных фондов.

7. Timeweb.Cloud

Timeweb.Cloud предлагает аренду выделенных серверов (bare metal) в дата-центрах уровня Tier III в России и Европе с гарантированным SLA до 99,98%. Это решение для тех, кто ищет высокую производительность, изолированную инфраструктуру и максимальную гибкость в управлении.

Вы получаете физический сервер полностью в своё распоряжение: root-доступ, KVM-консоль в панели управления, возможность установить любое ПО и ОС, а также подключать дополнительные процессоры, диски и шлюзы. Вся настройка доступна на уровнях сервера, железа и сети — вплоть до объединения в приватную сеть между регионами и провайдерами.

Timeweb.Cloud предоставляет мощные конфигурации на базе процессоров Intel Xeon Gold, AMD Ryzen 9 и EPYC, с NVMe-дисками и премиальными сборками от Supermicro и Gigabyte. Быстрый запуск готовых конфигураций — от 1 часа, индивидуальные — за 1 день.

Техподдержка — сильная сторона сервиса: персональный менеджер, ответы по телефону и в чате — за минуту, в тикетах — до 15 минут. Надёжность подтверждена соответствием 152-ФЗ, PCI DSS и ISO. Timeweb.Cloud — подходящее решение для разработчиков и бизнеса, которым нужно больше, чем просто «облако», и которые ценят контроль, мощность и поддержку.

На что ориентироваться при выборе облака

Универсального «идеального» облака не существует: платформа должна соответствовать именно вашим задачам. Для стартапов и быстрых MVP подойдут решения с простым управлением и гибкой тарификацией вроде L1veStack или H3LLO.CLOUD. Если ключевую роль играет отказоустойчивость и предсказуемый SLA — обратите внимание на Incloud, Cloud.ru или Selectel. Для работы с большими данными, ML и высоконагруженными сервисами удобнее использовать экосистемы уровня VK Cloud. А если требуется полный контроль над железом и гарантированная изоляция, оптимальным выбором станут выделенные серверы Timeweb.Cloud.

При выборе облака важно учитывать три фактора: технические возможности (производительность, поддержка контейнеров, интеграция с CI/CD), надёжность (аптайм, резервирование, дата-центры Tier III) и экономику (модель тарификации, стоимость ресурсов, наличие грантов и бонусов). Сравнив эти параметры в разрезе реальных сценариев, вы сможете выбрать платформу, которая не подведёт именно в вашем продакшене.

Все образы теперь доступны без подписки, но под лицензией Apache 2.0. Ими может воспользоваться любой разработчик — без ограничений и скрытых условий.

Ранее DHI были коммерческим продуктом. В октябре Docker уже делал шаг навстречу сообществу, открыв неограниченный доступ и предложив 30-дневный пробный период.

Теперь компания пошла еще дальше и полностью убрала платный барьер.

Что такое Docker Hardened Images

Docker Hardened Images — это минималистичные, защищенные базовые контейнерные образы, которые Docker представил в мае. Они предназначены для продакшена и поддерживаются самой компанией.

Образы собраны таким образом, чтобы не содержать в себе ничего лишнего. То есть в них нет ненужных компонентов, что позволяет достичь минимальной поверхности атаки. Более того, в DHI в принципе отсутствуют известные на момент публикации уязвимости.

Безопасность без компромиссов

Docker подчеркивает, что перевод DHI в open-source не означает снижения уровня защиты. Все образы остаются проверяемыми через SBOM, сборки соответствуют SLSA Build Level 3, а каждый образ сопровождается доказательством подлинности.

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

Что остается платным

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

Для платных клиентов Docker гарантирует выпуск патчей для критических CVE в течение семи дней после раскрытия уязвимости. В бесплатной версии исправления тоже будут, но без жесткого SLA.

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

Вы научитесь:

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

Каждую команду объясняем простым языком, показываем синтаксис и приводим примеры использования.

Как найти любой файл за пару секунд

Команда find ищет файлы и папки по критериям. Finder тоже умеет искать, но через терминал вы получаете точный контроль над параметрами поиска.

Синтаксис:

Попробуем найти все PDF-файлы в папке «Документы»:

Символ «~» обозначает вашу домашнюю папку. Звёздочка «*» заменяет любую последовательность символов, поэтому «*.pdf» означает «все файлы с расширением pdf».

Больше примеров:

Команда find пригодится, когда:

• Вы не помните, куда сохранили файл.
• Нужно найти все скриншоты или документы определённого типа.
• Хотите очистить диск от больших файлов, но не знаете, где они лежат.

Как узнать, что съедает место на диске

Команда du (disk usage) показывает, сколько места занимают папки и файлы.

Самый полезный вариант использования:

Флаг «-s» выводит итоговый размер каждого элемента, «-h» форматирует числа в человекочитаемый вид (килобайты, мегабайты, гигабайты).

Результат выглядит так:

• 1.8G — /Users/username/Downloads/video.mp4
• 46M — /Users/username/Downloads/archive.zip
• 7.9M — /Users/username/Downloads/document.pdf

Найдём 10 самых больших папок в домашней директории:

Здесь команды объединены через символ «|». Результат du передаётся в «sort», который сортирует по размеру в обратном порядке, «head» оставляет только первые 10 строк.

Функции du пригодятся, когда:

• MacOS предупреждает о нехватке места на диске.
• Хотите понять, какие папки разрослись за время использования.
• Нужно решить, что удалить или перенести на внешний накопитель.

Как скачать файл по ссылке без браузера

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

Базовый синтаксис:

Флаг «-O» сохраняет файл с оригинальным именем в текущую папку.

Чтобы сохранить файл с другим именем:

Продолжить прерванную загрузку:

Флаг «-C -» проверяет, сколько уже скачано, и продолжает с того места, где загрузка прервалась.

Показать прогресс загрузки:

Флаг «-#» отображает прогресс-бар вместо технической информации.

Перед загрузкой перейдите в нужную папку командой cd /путь/к/папке, иначе файл сохранится в текущей директории (по умолчанию — домашняя папка).

Как быстро просмотреть содержимое текстового файла

Команда cat показывает весь файл целиком.

Текст выводится прямо в терминал. Подходит для коротких файлов.

Команда head показывает начало файла.

Число после «-» задаёт количество строк. В данном случае head покажет первые 20 строк.

Команда tail выводит конец файла:

Так удобнее просматривать логи, где свежие записи добавляются в конец файла.

Команда less запускает постраничный просмотр:

Навигация:

• пробел — следующая страница;
• b — предыдущая страница;
• /слово — поиск по файлу;
• q — выход.

Как изменить скрытые настройки macOS

Команда defaults управляет системными настройками macOS. Включая те, которых нет в стандартных «Настройках». Apple хранит параметры в файлах формата .plist, и defaults редактирует их напрямую.

Показать скрытые файлы в Finder:

Строка «killall Finder» перезапускает Finder, чтобы изменения вступили в силу.

Изменить формат скриншотов с PNG на JPG:

JPG-файлы занимают меньше места, что удобно, если вы регулярно делаете скриншоты.

Изменить папку сохранения скриншотов:

Теперь скриншоты перестанут захламлять рабочий стол.

Ускорить анимацию Dock:

Первая команда убирает задержку перед появлением Dock, вторая ускоряет саму анимацию.

Вернуть настройку к значению по умолчанию:

Команда defaults пригодится, если:

• Хотите настроить систему под себя, но в «Настройках» нет нужной опции.
• Раздражают стандартные анимации или поведение интерфейса.
• Нужно оптимизировать рабочее окружение.

Перед изменением настроек запишите текущее значение. Посмотреть его можно командой «defaults read». Например, «defaults read com.apple.screencapture type».

Как управлять процессами и освобождать ресурсы системы

Команда top показывает запущенные процессы в реальном времени: какие программы потребляют процессор и память.

Запуск:

Экран обновляется каждые несколько секунд. Вы увидите таблицу с колонками:

• PID — идентификатор процесса;
• COMMAND — название программы;
• %CPU — процент использования процессора;
• MEM — использование памяти.

Управление внутри:

• q — выход;
• o cpu — сортировка по использованию процессора;
• o mem — сортировка по использованию памяти.

Чтобы завершить зависший процесс, найдите PID процесса в top или через команду «pgrep -l "название_программы"».

Затем завершите процесс:

Если процесс не реагирует на обычный kill:

Флаг «-9» принудительно завершает процесс без возможности сохранить данные.

Когда пригодится:

• Вентиляторы Mac работают на полную, и непонятно, какая программа нагружает систему.
• Приложение зависло и не закрывается обычным способом.
• Хотите понять, куда уходят ресурсы компьютера.

Команда htop показывает ту же информацию в более удобном виде, но её нужно установить отдельно через Homebrew.

Как упростить ввод длинных команд

Терминал macOS поддерживает алиасы — короткие команды, которые заменяют длинные.

Создать временный алиас (работает до закрытия терминала):

Теперь команда «ll» выводит содержимое папки в подробном формате, включая скрытые файлы.

Чтобы создать постоянный алиас, откройте файл конфигурации Zsh:

Добавьте строку с алиасом в конец файла. Сохраните файл (Ctrl+O, затем Enter) и выйдите (Ctrl+X).

Примените изменения:

Примеры полезных алиасов:

Команда alias пригодится, если вы часто выполняете одни и те же длинные команды или хотите создать свои «горячие клавиши» для терминала.

Как узнать информацию о своём Mac одной командой

Чтобы выяснить, какой процессор стоит в Mac, сколько оперативной памяти установлено или какая версия macOS запущена, обычно открывают меню «Об этом Mac». Терминал даёт гораздо больше информации и делает это быстрее.

Команда system_profiler выводит подробные сведения о железе и программном обеспечении. Для обзора основных характеристик введите:

Терминал покажет модель Mac, идентификатор модели, название процессора, количество ядер, объём оперативной памяти и серийный номер. Информация пригодится при обращении в поддержку Apple или при продаже устройства.

Для просмотра информации о дисках:

Отобразится название каждого тома, файловая система, общий объём и свободное место.

Если хотите узнать всё о сетевых интерфейсах:

Команда выведет список всех Wi-Fi, Ethernet, Bluetooth PAN. Для каждого интерфейса отобразится IP-адрес, MAC-адрес и статус подключения.

Полный отчёт о системе:

Команда сохраняет подробный отчёт в текстовый файл на рабочем столе. Файл содержит информацию обо всём: от установленных приложений до подключённых USB-устройств.

Как проверить скорость интернета и сетевые соединения

Команда ping отправляет тестовые пакеты на указанный адрес и измеряет время ответа:

Терминал начнёт отправлять запросы и показывать время отклика в миллисекундах. Нормальный пинг до крупных сайтов — 20-100 мс.

Чтобы остановить ping, нажмите «Ctrl+ C». Для отправки определённого количества запросов добавьте флаг «-c»:

Команда отправит ровно 10 пакетов и покажет статистику: минимальное, среднее и максимальное время отклика с процентами потерянных пакетов.

В macOS Monterey и новее появилась встроенная утилита для измерения скорости интернета:

Команда измерит скорость загрузки и выгрузки, покажет показатель RPM (Round-trips Per Minute) — он отражает отзывчивость соединения. Тест занимает около 15-20 секунд.

Как очистить кэш DNS при проблемах с сайтами

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

Система запросит пароль администратора. После выполнения кэш очистится, и macOS начнёт заново запрашивать адреса сайтов у DNS-серверов.

Когда это помогает:

• Сайт не открывается, хотя у других пользователей работает.
• После смены DNS-серверов в настройках сети.
• При разработке, когда переключаетесь между локальным и рабочим сервером.
• Когда сайт переехал на новый хостинг, но отображается старая версию.

Проверить текущий DNS-кэш нельзя — Apple не предоставила такой команды. Очистка занимает секунду и ничего не ломает, поэтому при проблемах с доступом к сайтам стоит попробовать.

Как создавать и распаковывать архивы

Finder умеет создавать ZIP-архивы через контекстное меню. Терминал даёт больше контроля: выбор степени сжатия, исключение определённых файлов, работа с разными форматами архивов.

Создание ZIP-архива из папки:

Флаг «-r» означает рекурсивную обработку — в архив попадут все вложенные папки и файлы. Без этого флага заархивируется только сама папка.

Создание архива с паролем:

Флаг «-e» включает шифрование. Терминал дважды попросит ввести пароль. Без этого пароля распаковать архив не получится.

Исключение определённых файлов:

Команда создаст архив проекта, но пропустит служебные файлы .DS_Store и папку node_modules.

Распаковка ZIP-архива:

Архив распакуется в текущую директорию. Для распаковки в конкретную папку:

Как узнать историю введённых команд и повторить их

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

Просмотр последних команд:

Терминал выведет пронумерованный список всех введённых команд. По умолчанию Zsh хранит 1000 последних команд.

Для поиска конкретной команды используйте grep:

Эта команда покажет только строки, содержащие слово «docker».

Повторение последней команды:

Два восклицательных знака выполнят предыдущую команду.

Очистка истории (если вводили что-то конфиденциальное):

Для полной очистки, включая файл истории:

Как переименовать много файлов одной командой

Переименование одного файла — это стандартная задача, для неё необязательно открывать терминал. Зато в ситуации, когда нужно переименовать 500 фотографий или добавить префикс к сотне документов, использование Finder превращается в пытку.

Базовое переименование одного файла через терминал:

Команда mv (move) перемещает файл. Если указать тот же каталог, но другое имя — файл переименуется.

Массовое переименование с добавлением префикса:

Цикл пройдёт по всем JPG-файлам в текущей папке и добавит к каждому префикс «vacation_». Файл «IMG_001.jpg» станет «vacation_IMG_001.jpg».

Замена части имени во всех файлах:

Конструкция ${file/IMG/Photo} заменяет «IMG» на «Photo» в имени файла. Файл «IMG_001.jpg» станет «Photo_001.jpg».

Добавление даты к имени файла:

Каждый PDF-файл получит префикс с текущей датой в формате «2025-01-15_».

Изменение расширения файлов:

Конструкция ${file%.jpeg} удаляет расширение .jpeg, а затем добавляется .jpg.

Как выключить или перезагрузить Mac из терминала

Немедленная перезагрузка:

Система запросит пароль и сразу начнёт перезагрузку. Несохранённые данные в приложениях будут потеряны.

Перезагрузка через определённое время:

Mac перезагрузится через 5 минут. Таймер даст время сохранить работу в других приложениях.

Выключение Mac:

Флаг «-h» означает «halt» — полное выключение.

Выключение в определённое время:

Mac выключится в 23:00.

Отмена запланированного выключения:

Если передумали, команда отменит запланированное выключение.

Усыпление Mac:

Команда не требует sudo и мгновенно переводит Mac в режим сна.

Как открыть файл или папку в нужном приложении

Команда open связывает терминал с графическим интерфейсом macOS.

Открытие текущей папки в Finder:

Точка означает текущую директорию. Команда пригодится, когда вы перешли в нужную папку через терминал и хотите продолжить работу в Finder.

Открытие конкретной папки:

Finder откроет папку «Загрузки».

Открытие файла в приложении по умолчанию:

PDF откроется в программе, назначенной по умолчанию для этого типа файлов (обычно «Просмотр»).

Открытие файла в конкретном приложении:

Флаг «-a» указывает приложение. Файл project.py откроется в VS Code, даже если по умолчанию Python-файлы открываются в другом редакторе.

Открытие нескольких файлов:

Все JPG-файлы в текущей папке откроются в приложении для просмотра изображений.

Показать файл в Finder (не открывая):

Флаг «-R» откроет Finder и выделит указанный файл. Полезно, чтобы определить расположение файла.

Итоги

Начните с команд find, du и cat. Они решают повседневные задачи: найти потерянный файл, выяснить, что занимает место на диске, быстро просмотреть содержимое документа.

После освоения базы переходите к связкам команд. Например, find находит файлы, а du показывает их размер — вместе они помогают очистить диск.

Для специфичных задач используйте:

• ping и networkQuality — диагностируют проблемы с интернетом;
• top — выявляет программы, загружающие процессор;
• kill — завершает зависшие процессы;
• defaults — настраивает скрытые параметры интерфейса;
• цикл for с командой mv — переименовывает сотни файлов за секунды;
• history возвращает ранее введённые строки.

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

Продуктивность разработчика повышается, когда к VSCode подключены инструменты для командной работы, контейнеризации и анализа данных. В статье по шагам разобрали, как интегрировать VSCode с GitLab, Docker и Jupyter.

Зачем всё это подключать

VSCode из коробки умеет работать с Git. Но когда ваш репозиторий лежит на GitLab, хочется создавать merge request прямо из редактора, просматривать pipeline, работать с issues.

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

Jupyter традиционно запускают в браузере. Но переключаться между браузером и редактором неудобно. VSCode умеет работать напрямую — редактируете код, запускаете ячейки, смотрите графики в одном окне.

Как подключить VSCode к GitLab

Шаг 1. Устанавливаем расширение

Откройте VSCode и нажмите Ctrl+Shift+X. В поиске введите «GitLab Workflow». Установите официальное расширение. После установки в левой панели появится иконка GitLab.

Шаг 2. Получаем токен доступа

Расширению нужен способ общаться с вашим GitLab-сервером. Для этого создадим персональный токен:

1. Зайдите в GitLab через браузер.
2. Кликните на аватар >> Settings >> Access Tokens.
3. Придумайте название токена.
4. Выберите срок действия.
5. Отметьте галочками права доступа: api, read_user, read_repository, write_repository.
6. Нажмите «Create personal access token».
7. Скопируйте токен — он покажется только один раз.

Шаг 3. Настраиваем расширение

Вернитесь в VSCode. Нажмите Ctrl+Shift+P и введите «GitLab: Add Account». Расширение попросит два параметра:

• GitLab instance URL — адрес вашего GitLab (например, https://gitlab.com или адрес корпоративного сервера).
• Personal Access Token — токен, который только что создали.

Вставьте токен и нажмите Enter. Если всё правильно, в статус-баре внизу появится ваше имя пользователя GitLab.

Шаг 4. Работаем с проектом

Попробуем клонировать проект. Нажмите Ctrl+Shift+P и выберите «GitLab: Clone from GitLab». Расширение покажет список доступных проектов. Выберите нужный, укажите папку для клонирования.

Теперь вам доступны функции Git:

• Pipeline — в боковой панели GitLab видны все запущенные сборки, их статусы и логи.
• Issues — создавайте, редактируйте и закрывайте задачи прямо из редактора.
• Merge requests — посмотрите список MR, оставьте комментарии к коду, одобрите изменения.
• Snippets — сохраняйте фрагменты кода для повторного использования.

Как подключить VSCode к Docker

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

Шаг 1. Подготовка

Установите Docker Desktop с официального сайта. После установки убедитесь, что Docker запущен — в системном трее должна появиться иконка кита.

В VSCode установите два расширения:

• Docker.
• Dev Containers.

Шаг 2. Создаём Dockerfile

В корне проекта создайте файл Dockerfile. Пример для Python-проекта:

Этот файл говорит Docker:

1. Возьми базовый образ Python 3.11.
2. Создай рабочую директорию /app.
3. Скопируй и установи зависимости.
4. Скопируй весь код проекта.
5. При запуске выполни команду python main.py.

Шаг 3. Настраиваем Dev Container

Создайте папку .devcontainer в корне проекта. Внутри создайте файл devcontainer.json:

Конфигурация использует ваш Dockerfile для сборки контейнера. Она автоматически устанавливает Python-расширения внутри контейнера, пробрасывает порт 8000 (если у вас веб-приложение) и выполняет команду после создания контейнера.

Шаг 4. Запускаем разработку в контейнере

Нажмите Ctrl+Shift+P и выберите «Dev Containers: Reopen in Container». Редактор соберёт Docker-образ по вашему Dockerfile, запустит контейнер, подключится к нему и откроет ваш проект уже внутри контейнера.

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

Как подключить VSCode к Jupyter

В классическом интерфейсе нет нормального автодополнения кода, сложно работать с Git, неудобно рефакторить код и нет полноценной отладки. Плагины VSCode решают эти проблемы.

Шаг 1. Установка

Установите расширение «Jupyter» от Microsoft. Оно автоматически подтянет все необходимые зависимости.

В терминале установите Jupyter и ipykernel:

Шаг 2. Создаём первый ноутбук

Создайте файл с расширением .ipynb или нажмите Ctrl+Shift+P >> «Create: New Jupyter Notebook».

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

Шаг 3. Выбираем ядро

Кликните на «Select Kernel» в правом верхнем углу. VSCode покажет список доступных интерпретаторов:

• Локальные Python-окружения.
• Виртуальные окружения (venv, conda).
• Docker-контейнеры (если настроены).
• Удалённые Jupyter-серверы.

Выберите нужное окружение. VSCode запомнит выбор для этого ноутбука.

Шаг 4. Пишем и выполняем код

В ячейке напишите код:

Нажмите Shift+Enter для выполнения ячейки. График отобразится прямо под кодом.

Для Python-файлов можно включить интерактивный режим. Добавьте комментарий # %% в .py файл:

VSCode покажет кнопки «Run Cell» над каждым блоком. Теперь можно выполнять код частям.

Что в итоге

Первая настройка VSCode с GitLab, Docker и Jupyter занимает 30-40 минут. В итоге вы получаете единое рабочее пространство для ваших задач разработки.

Начните с GitLab и научитесь создавать merge requests из редактора. Потом добавьте Docker для одного проекта. Когда освоитесь, подключите Jupyter для работы с данными. Инструменты решают разные задачи, а VSCode объединяет их функции в одном интерфейсе.

Возьмите проект и последовательно подключите каждый инструмент. Через неделю удивитесь, как раньше работали без этой связки. Код пишется быстрее, ошибок меньше, а переключений между окнами почти нет.

Если что-то непонятно или не получается настроить — пишите в комментариях, разберёмся вместе!

Это краткое руководство поможет быстро разобраться с Lakehouse‑архитектурой (лейкхаус): ключевые особенности, сильные стороны, типовые сценарии, а также как быстро собрать решение на базе StarRocks. В конце вы найдёте практические шаги и реальные кейсы использования StarRocks Lakehouse.

Ссылки на официальные материалы:

• Подробный туториал StarRocks + Iceberg: https://docs.starrocks.io/en/docs/quick_start/iceberg/
• Iceberg Spark Quickstart: https://iceberg.apache.org/spark-quickstart/
• Видео‑демо: https://www.bilibili.com/video/BV1ET42167TY/?spm_id_from=333.999.0.0&vd_source=1cb452610138142d1300dd37a6162a88

Введение в Apache Iceberg

Apache Iceberg — открытый табличный формат, созданный для масштабных и сложных наборов данных (до ПБ и выше). Изначально разработан в Netflix для управления большим числом таблиц, открыт в инкубаторе Apache в 2018 году и получил статус верхнеуровневого проекта в 2020 году.

Iceberg располагается между вычислительными движками (например, Apache Flink и Apache Spark) и форматами хранения (ORC, Parquet, Avro), выступая прослойкой, которая абстрагирует сложность низкоуровневых форматов и предоставляет унифицированные табличные семантики. Такой дизайн обеспечивает гибкость операций и управления схемой в разных средах без привязки к конкретному движку хранения, с масштабированием в HDFS, S3, OSS и т. п.

Архитектура и ключевые компоненты

Архитектура Iceberg состоит из трёх слоёв:

• Слой данных: фактические файлы данных (Parquet, ORC и др.).
• Слой метаданных: многоуровневая структура со схемой таблицы и индексами файлов данных.
• Слой каталога (Catalog): указатели на местоположения файлов метаданных; доступны реализации вроде HadoopCatalog и HiveCatalog.

Управление метаданными включает три ключевых сущности:

• Файл метаданных (Metadata File): хранит текущую версию метаданных, включая все снимки.
• Снимок (Snapshot): отражает состояние таблицы после конкретной операции (коммита); новый коммит — новый снимок.
• Манифест (Manifest): перечисляет файлы данных, связанные со снимком, задаёт целостное представление организации данных и ускоряет поиск/модификации.

Цель Iceberg — отслеживать эволюцию таблицы во времени с помощью снимков, которые фиксируют полный набор файлов данных на произвольный момент. Каждый апдейт создаёт новый снимок, обеспечивая согласованность и упрощая историческую аналитику и инкрементальное чтение.

Ключевые возможности

• Скрытое партиционирование (Hidden partitioning): автоматическое разбиение по времени и другим функциям без необходимости знать детали партиций.
• Эволюция схемы (Schema evolution): безопасные изменения структуры таблицы без переписывания данных, с историей изменений.
• Эволюция партиционирования (Partition evolution): смена стратегии партиционирования без воздействия на исторические данные; новые данные следуют новой стратегии.
• Многоверсионный контроль (MVCC): записи не блокируют чтения; управление через Manifest‑файлы.
• ACID‑транзакции: оптимистичная блокировка для конкурентных записей, атомарность операций.
• Обновления на уровне строк: в v1 — Copy‑on‑Write (COW), в v2 — Merge‑on‑Read (MOR), поддержка position deletes и equality deletes для логических обновлений.

Преимущества Apache Iceberg

• Широкая поддержка движков вычислений: Spark, Flink, Hive и др.; есть нативный Java API.
• Гибкая организация данных: работает для потоковых инкрементальных и пакетных сценариев на единой модели хранения (HDFS, Apache Ozone и др.); поддерживает Parquet/ORC/Avro; скрытое партиционирование и эволюция партиций устраняют «островки данных».
• Оптимизированная загрузка данных (ingest): ACID делает новые данные мгновенно видимыми без влияния на текущие задачи; upsert/merge на уровне строк сокращают задержки.
• Инкрементальное чтение: встроенная интеграция со Spark Structured Streaming и Flink Table Source; поддержка исторических версий повышает надёжность и аудитируемость.

Типовые сценарии использования

• Импорт и запросы в реальном времени: непрерывная запись в таблицы Iceberg и мгновенная аналитика через Hive/Spark/Presto/Iceberg. ACID обеспечивает изоляцию и отсутствие «грязных» данных.
• Удаление/обновление данных: операции на уровне файлов вместо полной переработки таблицы; например, DELETE FROM test_table WHERE id > 10.
• Контроль качества данных: валидация схемы при загрузке; изменения схемы через DDL Spark SQL без переэкспорта исторических данных; ACID изолирует изменения схемы от текущих чтений.
• ML в реальном времени: конвейер подготовки данных (очистка/трансформации/feature engineering) превращается в надёжный поток; поддержка нативного Python SDK.

Ускорение запросов StarRocks × Iceberg

StarRocks эффективно анализирует как внутренние данные, так и данные в озере, поддерживает внешний каталог Iceberg (External Catalog) и позволяет запрашивать таблицы Iceberg без миграции данных. Поддерживаются Iceberg v1 и v2 (чтение/запись).

Оптимизации:

• Метаданные: кэш метаданных снижает избыточный I/O; распределённое планирование заданий ускоряет параллельное чтение/фильтрацию Manifest‑файлов; Manifest Cache уменьшает накладные расходы парсинга.
• План выполнения: стоимостной оптимизатор (CBO) использует статистики; StarRocks собирает статистики по внешним таблицам (включая гистограммы и сложные типы).
• Форматы файлов: оптимизации для Parquet/ORC снижают объём сканирования и I/O.
• Снятие различий между внешними и внутренними таблицами: кэш данных (Data Cache) снижает удалённый I/O; «умные» материализованные представления обеспечивают переписывание запросов и инкрементальное обновление.
• Интеграция с экосистемой: поддержка чтения/записи Iceberg упрощает обратную выгрузку в озеро и лёгкую переработку данных, улучшая производительность запросов и единое управление.

Быстрый старт

В рамках руководства вы:

• Развёрнёте объектное хранилище, Apache Spark, Iceberg Catalog и StarRocks с помощью Docker Compose.
• Импортируете данные в озеро Iceberg.
• Настроите StarRocks для доступа к Iceberg Catalog.
• Выполните запросы к данным озера из StarRocks.

Подробный учебник: https://docs.starrocks.io/en/docs/quick_start/iceberg/

Iceberg Spark Quickstart: https://iceberg.apache.org/spark-quickstart/

Развёртывание Iceberg

Чтобы добавить Iceberg в существующий Spark, достаточно подключить соответствующий JAR в параметры запуска. В данном руководстве используется контейнер tabulario/spark-iceberg — Spark уже с интегрированным Iceberg, что позволяет сразу работать в среде PySpark.

Окружение (Docker Compose)

Используется шесть контейнеров:

• starrocks-fe: метаданные, подключения клиентов, планирование и диспетчеризация запросов.
• starrocks-be: выполнение планов запросов.
• rest: сервис метаданных — Iceberg Catalog (REST).
• spark-iceberg: окружение Apache Spark для PySpark.
• mc: MinIO Client.
• minio: объектное хранилище MinIO.

Docker Compose файл (скачайте из репозитория StarRocks) настраивает:

• Iceberg REST‑каталог (http://iceberg-rest:8181) с CATALOG_WAREHOUSE=s3://warehouse/, S3FileIO и CATALOG_S3_ENDPOINT=http://minio:9000.
• MinIO с публичной политикой на bucket warehouse.
• Переменные доступа S3‑совместимого хранилища: AWS_ACCESS_KEY_ID=admin, AWS_SECRET_ACCESS_KEY=password.

Загрузка Docker Compose и набора данных

Запуск окружения в Docker

Подсказка: команды docker compose выполняйте из каталога, где лежит docker-compose.yml.

Дождитесь, когда starrocks-fe и starrocks-be перейдут в состояние healthy (обычно ~30 секунд).

Работа с PySpark и Iceberg

Скопируйте набор данных в контейнер spark-iceberg:

Запустите PySpark:

Загрузите данные в DataFrame и проверьте схему/выборку:

Создайте таблицу Iceberg и запишите в неё данные:

Примечание: таблица будет доступна через внешний каталог StarRocks (External Catalog) на следующем шаге.

Подключение к StarRocks и настройка доступа к Iceberg Catalog

Подключитесь к StarRocks из MySQL‑клиента (из контейнера FE):

Создайте внешний каталог iceberg в StarRocks:

Проверьте каталоги, переключитесь и посмотрите БД/таблицы:

Замечание по типам: в Spark

будет отображаться в StarRocks как

(и возможны другие конверсии типов).

Запросы к таблицам Iceberg из StarRocks

Время приёма заказа (первые 10 строк):

Пиковые часы по количеству поездок:

Видео‑демонстрация

Демонстрация StarRocks + Iceberg + MinIO (EN)https://www.bilibili.com/video/BV1ET42167TY/?spm_id_from=333.999.0.0&vd_source=1cb452610138142d1300dd37a6162a88

Расширенные материалы

• Apache Iceberg — Spark Quickstart: https://iceberg.apache.org/spark-quickstart/
• Apache Iceberg — Catalogs: https://iceberg.apache.org/docs/latest/catalogs/
• Apache Iceberg — REST Catalog: https://iceberg.apache.org/docs/latest/rest-catalog/
• StarRocks — Quick Start с Iceberg: https://docs.starrocks.io/en/docs/quick_start/iceberg/
• StarRocks — External Catalog (Iceberg): https://docs.starrocks.io/en/docs/data_source/catalog/iceberg_catalog/

Примечания по терминологии

• Catalog → каталог; External Catalog → внешний каталог (External Catalog).
• Metadata File / Snapshot / Manifest — используем русские эквиваленты с английскими терминами в скобках при первом упоминании.
• Hidden partitioning → скрытое партиционирование.
• Schema/Partition evolution → эволюция схемы/партиционирования.
• MVCC, ACID, CBO, Data Cache, Manifest Cache, Copy‑on‑Write (COW), Merge‑on‑Read (MOR), position/equality deletes — используем английские аббревиатуры/термины, так как это общепринятая практика в индустрии.

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

Сегодня причислять себя к Senior-грейду без знания основ контейнеризации — неоправданно.

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

Давайте разбираться, что должен знать фронтенд-разработчик про Docker.

Что такое Docker?

Docker — это программа для создания, развёртывания и управления приложениями в контейнерах. Контейнер создаётся на основе образа, который описан в Dockerfile.

Dockerfile — по сути, инструкция для создания контейнера. В нём описывается окружение, зависимости и команды для запуска приложений внутри, например, прокси-сервера или микросервиса авторизации.

Какие проблемы решает Docker во фронтенде?

В небольшом проекте работа с web-приложением сводится к использованию четырёх команд: start, build, test, deploy.

А вот запуск веб-приложения в большом и устоявшемся коммерческом проекте выглядит так:

• Запусти Nginx, чтобы отдать клиент.
• Подними (а перед этим установи) бекенд на Go и кэш на Redis, чтобы заработало API.
• Запусти БД, чтобы были данные.
• Запусти вспомогательные сервисы для API, например, аутентификацию или backoffice.

Без контейнеризации запуск сложного приложения превращается в филиал ада: разработчики тратят время на запуск инфраструктуры, у пользователей MacOS не работает то, что работает у пользователей Ubuntu, а порты Postgres конфликтуют с портами локально поднятого почтового сервера.

Так ноутбук начинает выполнять функцию обогревателя для помещения площадью 40 квадратных метров 🙂

Для решения каких задач фронтенд-разработчики выбирают Docker чаще всего?

На стороне фронтенда Docker чаще всего используют для:

• Запуска и работы web-приложения.
• Запуска инфраструктуры для web-приложения.
• Запуска тестов (создание скриншотов, e2e-тесты).
• Сборка приложения на CI.

Что же должен знать фронтенд-разработчик про Docker?

Основные команды для работы с Docker

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

Базовое управление контейнерами также доступно через интуитивно понятный Docker UI.

Важно: все основные команды имеют полезные аргументы. Полный список аргументов вы можете найти в документации.

Как создать базовый Docker-образ для веб-приложения?

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

Образ стандартного web-приложения выглядит примерно так:

При создании Dockerfile рекомендуем следовать минимальному набору лучших практик:

• Использовать базовые образы, чтобы не нагружать образ лишними модулями.
• Добавлять .dockerignore, чтобы исключать лишние файлы из сборки.
• Не запускать контейнер от root, чтобы снизить риски для безопасности.
• Проверять сторонние образы с помощью docker scan, опять же, чтобы снизить риски для безопасности.

Как отправить образ в Container Registry?

Container Registry — это хранилище для Docker-образов.

Container Registry можно сравнить с Github, только вместо репозиториев — готовые для развёртывания образы.

Для работы с Container Registry есть несколько основных команд:

По тегу latest вы всегда можете получить последнюю версию вашего контейнера.

Популярные Container Registry:

• Docker Hub (публичный, простой и бесплатный для открытых проектов);
• GitHub Container Registry (платный, интегрирован с GitHub);
• Google Container Registry (платный);
• Yandex Container Registry (платный).

Важно: старайтесь подбирать Container Registry под экосистему, в которой будет работать ваше приложение. Это сэкономит много сил и времени.

Как запустить Docker-контейнер локально и на сервере?

Для локального запуска контейнера потребуется пройти простой пайплайн:

Если вы хотите запустить контейнер на удалённом сервере с установленным Docker, то вам потребуется пройти пайплайн посложнее:

Важно: в данном примере мы используем в качестве Container Registry — Docker Hub.

Как подключить фронтенд к бэкенду внутри Docker?

Чтобы не настраивать общение клиента и сервера через порты, хорошая практика — объединять сервисы в рамках единой Docker-сети.

Обычно этой задачей занимается файл-оркестратор docker-compose.yml:

Чтобы поднять весь стэк, нам понадобятся команды:

Ключевые моменты:

• Сервисы в одной сети могут общаться по имени (в примере фронтенд обращается к бэкенду по http://backend:5000);
• depends_on гарантирует порядок запуска, но не ждёт готовности сервиса;
• Для продакшена можно разделить конфигурации на docker-compose.yml и docker-compose.prod.yml.

Бонус: Как управлять контейнерами через UI?

В случае отсутствия опыта контейнеризации у команды разработки, управление контейнерами можно осуществлять через UI (вместо терминала) при помощи Portainer.

Portainer — это легковесная панель управления Docker-контейнерами. Через удобный графический интерфейс он позволяет выполнять операции, которые обычно отправляются через терминал (docker run, docker ps, docker compose up).

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

Portainer не заменяет необходимость знания Docker, но значительно ускоряет и упрощает такие рутинные операции, как развёртывание и мониторинг.

Когда Docker необходим, а когда можно обойтись?

Используйте Docker когда:

• работаете в команде с разными ОС;
• проект имеет сложные внутренние и внешние зависимости;
• нужно обеспечить идентичность разных сред: разработки, тестирования, продакшена;
• работаете с full-stack приложениями, где фронтенд тесно связан с бэкендом.

Без Docker можно обойтись когда:

• работаете над небольшим проектом;
• вся команда использует одинаковое железо и ОС;
• проект не имеет сложных зависимостей;
• нет необходимости в изоляции окружений.

Заключение

В последние годы Docker прочно вошёл в арсенал фронтенд-разработчиков, перестав быть инструментом исключительно для бэкенда и DevOps.

Основная ценность Docker для фронтенд разработчика заключается в решении двух ключевых задач: быстрый запуск сложной рабочей среды приложения и обеспечение стабильности на протяжении релизного цикла.

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

В своём телеграмм-канале я делюсь практическим опытом разработки, честно рассказываю о трудностях в работе, а также показываю кейсы проектов, которыми занимаюсь в свободное время!

Буду рад каждому, кто подписался ✨

Возможно, вам будет интересно:

Делитесь своими находками и полезными командами для работы с Docker в комментариях!

Редакция Tproger сделала и адаптировала перевод подборки программ для Windows и macOS. Здесь вы найдёте проверенные временем решения для работы, развлечений и повседневных задач. Мы сосредоточились на бесплатных и условно-бесплатных приложениях с отличной репутацией, которые решают реальные задачи без навязывания ненужных функций.

Список разбит по категориям: от браузеров и гейминга до утилит безопасности и инструментов для продуктивности.

Неважно, опытный вы пользователь или новичок — здесь найдётся что-то полезное для каждого.

Браузеры

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

• Большинство пользователей: Chrome, Edge или Safari
• Защита приватности: Firefox, Brave, Ungoogled Chromium
• Опытные пользователи: Vivaldi
• Максимальная анонимность: Tor Browser

Google Chrome

Chrome остаётся самым популярным браузером в мире — и не просто так. Он быстрый, стабильный и отлично интегрируется с экосистемой Google. Огромная библиотека расширений из Chrome Web Store позволяет настроить браузер под любые задачи. Синхронизация между устройствами работает безупречно: вкладки, пароли, закладки и история всегда под рукой.

Минус один, но существенный: Chrome прожорлив. Если у вас открыто больше десятка вкладок, он может съесть несколько гигабайт оперативной памяти. На компьютерах с 8 ГБ RAM и меньше это становится проблемой.

Mozilla Firefox

Firefox — это выбор тех, кто ценит приватность и открытость. Mozilla не зарабатывает на продаже ваших данных, а сам браузер активно развивается сообществом. Встроенные инструменты защиты от трекинга работают из коробки, блокируя рекламные сети и скрипты слежения.

По скорости Firefox не уступает Chrome, а по потреблению памяти даже выигрывает. Библиотека расширений чуть меньше, чем у Chrome, но все основные инструменты доступны.

Microsoft Edge

Edge построен на том же движке Chromium, что и Chrome, но при этом лучше оптимизирован для Windows. Microsoft вложилась в производительность: браузер работает быстро, потребляет меньше ресурсов и отлично интегрируется с системой.

Особенно приятны функции вроде Collections (коллекции вкладок для организации исследований), режим чтения и встроенный скриншотер. Edge поддерживает все расширения Chrome, так что переход безболезненный.

Brave

Brave — это Chrome на стероидах приватности. Браузер блокирует рекламу и трекеры по умолчанию, что делает сёрфинг быстрее и безопаснее. При этом он полностью совместим с расширениями Chrome.

Есть интересная фишка: Brave Rewards позволяет зарабатывать криптовалюту за просмотр приватной рекламы (если захотите её включить). Спорная механика, но как опция — почему нет. Для тех, кто хочет Chrome без Google и с упором на приватность, Brave — отличный выбор.

Safari (только macOS)

Если у вас Mac, Safari заслуживает внимания. Это самый энергоэффективный браузер для macOS: на MacBook он даёт ощутимо больше автономности по сравнению с Chrome или Firefox. Интеграция с экосистемой Apple безупречна: Handoff, синхронизация через iCloud, Reading List, автозаполнение паролей.

Safari быстрый, безопасный и не перегружен функциями. Единственный минус — библиотека расширений заметно скромнее, чем у конкурентов. Но для большинства задач базового функционала хватает.

Ungoogled Chromium

Для ультраосторожных Ungoogled Chromium удаляет всё отслеживание и сервисы Google — но вам придётся настраивать всё самостоятельно, так как в нём нет автообновлений или встроенной синхронизации.

Для максимально осторожных пользователей — это Chrome, из которого убрали всю телеметрию Google, отслеживание и облачные сервисы. Браузер работает, но требует ручной настройки: отсутствуют автоматические обновления и встроенная синхронизация между устройствами.

Tor Browser

Выводя приватность на следующий уровень, Tor Browser маршрутизирует ваш трафик через сеть Tor, анонимизируя ваш IP и многократно шифруя соединение. Он медленнее по задумке, но идеален, если ваш приоритет — максимальная анонимность, а не скорость или удобство.

Vivaldi

Vivaldi — браузер мечты для тех, кто хочет полного контроля. Стекирование вкладок, тайлинг, кастомные горячие клавиши, встроенная почта и календарь, веб-панели — это полноценный десктопный опыт внутри браузера. Хотите боковую панель браузера, открывающую ваши заметки, RSS-ленты или любой нужный сайт? Vivaldi это умеет.

Arc

Наконец, Arc — когда-то новичок на рынке браузеров, нацеленный на переосмысление UX: замена традиционной панели вкладок на боковую панель, акцент на веб-приложениях, интегрированные разделённые виды и easels для заметок и доски. К сожалению, компания за Arc прекратила разработку, чтобы полностью переключиться на ИИ с новым браузером, который сейчас в закрытой бета-версии.

Управление паролями

• Лучший бесплатный выбор: Bitwarden
• Также отлично: 1Password, Dashlane, KeePass

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

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

Bitwarden

Полностью опенсорсный, зашифрованный и щедрый даже в бесплатной версии. Вы получаете неограниченное количество паролей, синхронизацию между устройствами и приложения для всех платформ. Премиум ($10/год) добавляет безопасный обмен файлами и инструменты 2FA. Также есть доступные семейные и командные планы.

1Password

Премиум-решение с отполированным интерфейсом, сильной кроссплатформенной поддержкой и отличными функциями вроде Travel Mode (режим путешествий) и полной интеграцией passkeys.

Dashlane

Предлагает мониторинг даркнета, интеграцию VPN и плавный пользовательский опыт. Есть бесплатный тариф с ограниченными функциями, но премиум-версия конкурентоспособна.

KeePassXC

Отличная оффлайн-альтернатива, если хотите полного контроля и не против ручной синхронизации (или использования чего-то вроде Syncthing или Dropbox для синхронизации базы данных).

Пропустите LastPass — когда-то фаворит, он упал в немилость после повторных утечек безопасности. Для душевного спокойствия лучше поискать в другом месте.

Продвинутые утилиты и дополнения к ОС

• Поиск + лаунчеры: Everything или Wox (Windows), Alfred или Raycast (macOS)
• Пакетные менеджеры: WinGet, Homebrew (macOS)
• Для пользователей Windows: PowerToys
• Для пользователей Mac: Rectangle
• История буфера обмена: ClipClip, Flycut (macOS)
• Скриншоты + аннотации: Monosnap

Winget

Официальный менеджер пакетов Microsoft, встроенный в Windows 10 и 11. Работает похоже на Chocolatey, но разработан и поддерживается Microsoft. Homebrew — самый популярный менеджер пакетов для macOS. Позволяет быстро устанавливать, обновлять и управлять приложениями и CLI-инструментами с помощью команд в терминале.

Everything

Что касается поиска, Everything остаётся золотым стандартом сверхбыстрого поиска по именам файлов в Windows. Он индексирует диски за секунды и выдаёт почти мгновенные результаты с минимальной нагрузкой на систему. Если нужен функционал шире базового поиска, Wox использует движок Everything и добавляет мощные возможности лаунчера: поиск файлов, запуск приложений, калькулятор, перевод текста и расширения через плагины. Получается более гибкий опыт в духе Spotlight для Windows.

Command Palette/Alfred/Raycast

В который раз Microsoft не смогла существенно улучшить встроенный поиск Windows, хотя Command Palette в PowerToys даёт неплохой компромисс для тех, кто не хочет ставить сторонние утилиты.

На macOS Alfred по-прежнему главный лаунчер и утилита поиска. Он быстрый, интуитивный и в бесплатной версии включает историю буфера и настраиваемые поиски; расширенная автоматизация и «воркфлоу» доступны в Powerpack.

Тем, кто хочет современную облачно-интегрированную альтернативу с готовыми расширениями и встроенной поддержкой Notion, GitHub и Slack, стоит присмотреться к Raycast — это стильный, дружественный к разработчикам вариант, который стремительно набирает популярность.

Менеджеры буфера обмена

Они позволяют возвращаться к ранее скопированному — тексту, изображениям, ссылкам — и сильно ускоряют рутинные операции.

В Windows встроенная история буфера (Win + V) кое-как выручает, но продвинутым пользователям обычно хочется большего. В числе бесплатных рекомендаций — ClipClip для Windows и Flycut для macOS.

Когда речь о скриншотах и аннотациях, штатные инструменты macOS и Windows заметно выросли. Но многим всё равно удобнее сторонние решения. Нам по-прежнему нравится Monosnap за простоту и возможность мгновенно заливать снимки в облако для шаринга (и это бесплатно).

PowerToys — набор полезных утилит от Microsoft для продвинутых пользователей Windows, повышающих продуктивность и упрощающих рабочие процессы. Среди инструментов: FancyZones для продвинутого раскладывания окон, PowerRename для пакетного переименования, Keyboard Manager для ремапинга клавиш, универсальный color picker и другие.

Rectangle и Magnet — два самых популярных приложения на macOS для закрепления окон: быстрые выравнивание и ресайз по хоткеям или перетаскиванием, примерно как по умолчанию в Windows. Пользователям, пришедшим с Windows и скучающим по системному снапингу, одно из них жизненно необходимо.

Широко используемая альтернатива в Windows — FancyZones (часть PowerToys), предлагающая продвинутое управление окнами: настраиваемые сетки, зоны привязки и поддержку нескольких мониторов — поэтому это фаворит пауэр-пользователей на Windows.

Для рутины и создания проектов

• Бесплатные инструменты: FreeOffice, LibreOffice и WPS Office
• Microsoft Office за единовременную плату $49, Office 2024 — $129
• Заметки: Notion, OneNote, Obsidian
• Бесплатный PDF-редактор: PDFsam
• Почтовые клиенты: Thunderbird, eM Client

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

Microsoft Office остаётся отраслевым стандартом для профессиональной продуктивности. Подписка Microsoft 365 открывает доступ к Word, Excel, PowerPoint, Outlook и включает 1 ТБ облачного хранилища.

Среди бесплатных альтернатив LibreOffice — мощный open-source комплект с сильным сообществом (хотя интерфейс некоторым кажется старомодным). Если нужна внешне более майкрософтовская альтернатива, попробуйте FreeOffice или WPS Office Free — у них хорошая совместимость.

На macOS Pages, Numbers и Keynote предустановлены и более чем достаточны для большинства задач, особенно если вы в экосистеме Apple.

Знания и ведение заметок

Notion стал универсальной платформой организации: заметки, базы данных, to-do, управление проектами, создания совместных рабочих пространств. Если нужны более локальные заметки с синхронизацией между устройствами и поддержкой Markdown, Obsidian — любимец студентов и исследователей.

Для быстрых кроссплатформенных заметок OneNote — крепкий бесплатный вариант от Microsoft. В качестве альтернатив — Simplenote или open-source Joplin.

Если вы занимаетесь академической работой и научными статьями, Zotero — отличный open-source менеджер источников с интеграцией в браузер и совместными коллекциями. Milanote предлагает визуальный подход к заметкам и планированию — идеально для креативных пользователей.

Работа с PDF

Хотя Adobe Acrobat остаётся премиальным редактором PDF, бесплатные альтернативы вроде PDFsam позволяют без усилий объединять, разбивать, редактировать и поворачивать страницы.

Инструменты для дизайна и создания контента

Для дизайна два выделяющихся приложения хорошо дополняют набор продуктивности. Figma Desktop — совместная платформа интерфейс-дизайна, широко используемая UI/UX-дизайнерами и фронтенд-разработчиками. Десктоп-версия работает быстрее, чем браузер, и лучше интегрируется с ОС — это удобно для сложных дизайн-систем и коллаборации в реальном времени.

Canva с интуитивным drag-and-drop превосходно чувствует себя и как десктоп-приложение. Отлично подходит для быстрых графических материалов для соцсетей, маркетинга, постеров и презентаций. Благодаря тысячам шаблонов и совместной работе это фаворит как у профи, так и у новичков.

Почтовые клиенты

Если вы предпочитаете отдельный почтовый клиент, у eM Client много функций, бесплатный — до двух аккаунтов. Mozilla Thunderbird — мощная open-source альтернатива с удобной настраиваемостью, а Mailbird — вариант с упором на продуктивность для тех, кого не пугает подписка.

Инструменты разработчика

• Редакторы кода и текста: VS Code, Cursor, Sublime Text
• Система контроля версий: SourceTree, GitHub Desktop
• Контейнеры: Docker
• Локальные LLM: Ollama
• SFTP, загрузка файлов: WinSCP, Forklift

Для разработчиков Visual Studio Code — безусловный вариант. Бесплатный, лёгкий, но мощный, кроссплатформенный — тысячи расширений покрывают практически любой язык, фреймворк или инструмент. Набирающая популярность альтернатива — Cursor, редактор на базе VS Code с усиленной AI-помощью. Он подходит для связки с LLM: даёт inline-подсказки, генерирует код, рефакторит и позволяет редактировать кодовую базу.

При этом Sublime Text остаётся для скорости и простоты, а Notepad++ — отличный лёгкий редактор для быстрых правок в Windows.

Для Git графические клиенты SourceTree и SmartGit дают понятный интерфейс для управления репозиториями на GitHub, GitLab и не только. GitHub Desktop раньше был простоват и не слишком хорош, но сейчас существенно прибавил — всё ещё простой для работы, но в хорошем смысле.

Для локальных окружений, API-тестирования или терминального воркфлоу инструментов — пруд пруди. Например, Docker Desktop стал стандартом для тех, кто собирает и запускает контейнеризированные приложения на разных платформах. Он упрощает настройку окружений и держит систему чистой.

Ollama позволяет запускать большие языковые модели (LLM) локально с минимальной настройкой. Поддерживает модели вроде LLaMA, Mistral и другие open-weight альтернативы GPT, так что можно работать с ИИ прямо на своём компьютере без отправки данных в облако.

Если вы работаете с облачными хранилищами или SFTP, WinSCP (Windows) и ForkLift (macOS) — отличные клиенты с двухпанельным управлением файлами, синхронизацией и автоматизацией. На Mac также популярны Commander One и Transmit — у них есть встроенные подключения к удалённым и облачным путям.

Безопасность

И Windows, и macOS сегодня предлагают более чем достойную встроенную защиту. С защитой в реальном времени, интеграцией с файерволом и биометрией вроде Windows Hello и Touch ID. Для обычных пользователей, которые соблюдают гигиену безопасности: не скачивают сомнительное ПО, используют менеджеры паролей и включают 2FA — встроенной защиты часто хватает.

Для продвинутых пользователей есть дополнительные варианты.

Отличное первое дополнение — Malwarebytes. Это давний фаворит в обнаружении и удалении malware, adware и руткитов; бесплатная версия по-прежнему хороша для ручных сканов. В платной — защита в реальном времени без ощутимой просадки производительности.

Если не хочется ставить традиционный антивирус, есть достойные альтернативы. Emsisoft Emergency Kit — мощный портативный сканер, который можно запускать с флешки: идеально для редких глубоких сканов или лечения заражённых систем без установки чего-либо. Просто подключаете, когда нужно.

Ещё один отличный инструмент — VirusTotal: бесплатный веб-сервис, который проверяет файлы и URL через десятки антивирусных движков. Прежде чем открывать подозрительную загрузку, можно залить файл на VirusTotal.com или использовать их расширение для браузера, чтобы проверять ссылки в реальном времени. Быстро, просто и удобно для осторожных пользователей.

Мы не поклонники установки антивирусов на каждый компьютер и не полностью в курсе, какие сейчас показывают лучшие результаты. Тем не менее, AV-Test давно и регулярно оценивает популярные решения, поэтому советуем смотреть их свежие отчёты. В текущем списке высокооценённых — Avast, BitDefender, ESET и другие; многие из них предлагают бесплатные версии для пробы.

Удалённый доступ и вспомогательные утилиты

RustDesk стал современным, ориентированным на приватность аналогом TeamViewer. Он с открытым исходным кодом, быстрый и работает кроссплатформенно.

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

Превращение смартфона в пульт дистанционного управления компьютером бывает невероятно удобно — будь то презентации, потоковое видео или просто навигация с дивана.

Remote Mouse — простой и эффективный способ эмулировать мышь и клавиатуру с телефона. Для более продвинутых сценариев можно использовать приложения вроде Unified Remote.

Редактирование изображений и видео

• Профессиональный видеомонтаж: DaVinci Resolve
• Простой видеомонтаж: CapCut
• Редакторы изображений: GIMP, PhotoDemon, Pixelmator Pro
• Бесплатное улучшение изображений: Upscayl
• RAW-редактирование: RawTherapee
• Видеоконвертация: HandBrake

Если вам нужен бесплатный инструмент для редактирования изображений, GIMP — один из самых мощных вариантов. Он предоставляет профессиональные возможности, такие как слои, маски и настраиваемые плагины, что делает его идеальным для продвинутых пользователей. Если вы ищете более лёгкий редактор с чистым интерфейсом, стоит обратить внимание на PhotoDemon. Он работает как портативное приложение на Windows, поддерживает слои и редактирование — отличный выбор для быстрых правок или ретуши.

Если вы хотите увеличивать разрешение изображений без потери качества, Upscayl — мощный и бесплатный инструмент для апскейла. Он кроссплатформенный, и по нашим тестам показывает результаты на уровне платных решений вроде Topaz.

Для векторной графики — логотипы, иллюстрации — Inkscape является достойным open-source вариантом с полной поддержкой редактирования SVG. Krita — ещё один отличный бесплатный инструмент, особенно подходящий для цифровой живописи и художественного творчества.

Для редактирования RAW-фотографий, Darktable и RawTherapee — два высококлассных open-source аналога Adobe Lightroom. Их широко используют фотографы, которым нужна работа с изображениями без подписки.

Для простых GIF-анимаций ScreenToGif — удобная утилита, мгновенно записывающая область экрана и экспортирующая в GIF или другие форматы с оверлеями.

Среди платных фоторедакторов Adobe Photoshop остаётся лидером, но для macOS есть Pixelmator Pro — мощное приложение с разовой оплатой, а Affinity Photo предлагает профессиональные возможности по более доступной цене.

Видеомонтаж и конвертация

DaVinci Resolve считается лучшим бесплатным профессиональным ПО. Его используют и энтузиасты, и профессионалы — от простого тримминга до цветокоррекции и сложного постпродакшена.

Shotcut и Kdenlive — тоже сильные бесплатные варианты, предлагают более простой фукнционал с хорошим набором функций для новичков и продвинутых пользователей. CapCut, изначально мобильное приложение, теперь доступен на десктопе — идеально подходит для быстрых монтажей и роликов для соцсетей.

Для пользователей macOS iMovie предустановлен и остаётся надёжным вариантом для базовых видео. Если вам нужно просто конвертировать или сжимать видео в современные форматы, HandBrake — проверенное бесплатное решение с поддержкой и вариацией входных и выходных форматов.

Тем, кто ищет топовый профессиональный монтаж, подойдут Adobe Premiere Pro и Final Cut Pro, но там есть дорогая подписка и более высокий порог входа.

Коммуникации и совместная работа

• Для повседневной связи: WhatsApp, Messenger и Zoom, если у вас нет FaceTime
• Для приватности: Signal
• Для работы: Slack, Teams
• Для игр и общения: Discord

Выбор коммуникационных и мессенджерных приложений в первую очередь зависит от того, с кем вы общаетесь — с семьёй, друзьями, коллегами или игровым сообществом. Вот актуальная картина:

Для личной переписки WhatsApp и Facebook Messenger остаются самыми массовыми платформами по всему миру. У них есть десктопные клиенты и встроенное сквозное шифрование по умолчанию. Telegram также крайне популярен благодаря синхронизации между устройствами и поддержке крупных чатов. Пользователи Apple продолжают активно использовать iMessage для приватного, шифрованного общения в экосистеме Apple.

Из видеоконференций Zoom остаётся одним из лидеров для групповых звонков и онлайн-ивентов, предлагая локальные записи, демонстрацию экрана и комнаты (breakout rooms). Однако бесплатный тариф ограничивает 1:1 звонки 40 минутами, если не перейти на платный план. Zoom поддерживает сквозное шифрование, но при включении E2EE отключаются некоторые функции вроде облачной записи и комнат.

Google Meet — отличный браузерный аналог без необходимости установки, который заметно улучшился по качеству и удобству использования. Многие компании применяют Meet в ежедневной работе и гибридных форматах. Если ваша организация использует Microsoft 365, скорее всего, вы работаете в Microsoft Teams, который уже заменил Skype на корпоративном уровне. Teams поддерживает большие созвоны, обмен файлами и глубоко интегрирован с Office. Сквозное шифрование доступно, но только для 1:1 звонков.

FaceTime по-прежнему отличный для пользователей Apple, и благодаря новым обновлениям к звонку теперь могут присоединяться и пользователи Android/Windows по ссылке через браузер.

Когда приватность критична, Signal — один из лучших вариантов. Разработан некоммерческой организацией, бесплатен, open-source, без рекламы, использует надёжное сквозное шифрование для сообщений и звонков.

Для рабочих коммуникаций Slack и Teams продолжают использоваться в бизнес-среде. Бесплатный тариф Slack ограничивает историю 90 днями и звонки, но остаётся любимцем стартапов и малых команд благодаря интеграциям и ботам. Cisco Webex — также крепкий вариант, особенно популярен в корпоративной среде.

Если вы работаете с креативными командами, сообществами или геймерами, Discord стал явным лидером. Изначально созданный для игр, он превратился в полноценную коллаборативную платформу с текстом, голосом и видео, стримингом экрана и ботами для автоматизации. Многие комьюнити — и даже IT-компании — используют Discord как основной рабочий инструмент.

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

Гейминг, моддинг и стриминг

• Игровые платформы: Steam, Epic Games, EA App, Ubisoft, GOG
• Последние драйверы для GPU: Nvidia GeForce, AMD Radeon, Intel Arc
• Стриминг: OBS Studio

Steam остаётся центром PC-игр. Это не только магазин, но и социальная платформа, лаунчер и площадка с модами, облачными сохранениями и встроенным стримингом. Регулярные распродажи, поддержка контроллеров и сообщества делают его обязательным для любого PC-геймера.

Не менее важно установить Epic Games Store. Хотя библиотека меньше, он регулярно раздаёт бесплатные игры, доступные любому с аккаунтом Epic. Это также must-have, если вы играете в Fortnite.

Помните: не все издатели размещают игры на Steam или Epic. Для тайтлов EA понадобится EA App (ранее Origin), для Ubisoft — Ubisoft Connect, для Blizzard/Activision — Battle.net, а GOG Galaxy не только предлагает DRM-free классику, но и может агрегировать игры из других лаунчеров.

Некоторые сверхпопулярные игры распространяются отдельно: Minecraft (через Minecraft.net или Microsoft Store), Roblox, League of Legends и Valorant (через лаунчер Riot Games). Если вы новичок и ищете что-то лёгкое, можно начать с free-to-play тайтлов или классики вроде Brutal Chess или GZDoom.

Если вы играете с геймпадом, Windows поддерживает Xbox-контроллеры из коробки. PlayStation-контроллеры теперь тоже отлично работают: Steam через Steam Input поддерживает DualShock 4 и DualSense практически во всех играх. При необходимости глубокой кастомизации можно использовать DS4Windows, но большинству хватает возможностей Steam.

Если вас интересует моддинг, хороший менеджер модов время в этой жизни:

• Mod Organizer 2 — лучший для RPG Bethesda (Skyrim, Fallout).
• Vortex (от Nexus Mods) — дружелюбный к новичкам и поддерживает широкий перечень игр.

Для записи геймплея или стриминга Nvidia ShadowPlay и AMD Radeon ReLive подходят для простых задач. Но для стриминга с вебкой, сценами, оверлеями или многосценовым продакшеном OBS Studio — безальтернативный лидер. Он бесплатный, open-source и подходит как новичкам, так и про-стримерам (Twitch, YouTube, Kick и т.д.). SignalRGB помогает синхронизировать весь RGB-зоопарк и задавать динамические эффекты.

Мониторинг железа и разгон

• Мониторинг: CPU-Z, HWMonitor, HWiNFO64
• Настройка и разгон: Afterburner, FanControl, ThrottleStop, SignalRGB

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

Начать стоит с CPU-Z — классического бесплатного инструмента, показывающего информацию о CPU, материнской плате, оперативной памяти и других компонентах. Он также умеет запускать простой стресс-тест и бенчмарк для проверки стабильности.

Для более широкого мониторинга HWMonitor показывает температуры, напряжения и скорости вентиляторов в реальном времени. Если нужно ещё глубже и с более гибким интерфейсом — HWiNFO64 считается одним из лучших: поддерживает логирование датчиков и интеграцию с оверлеями (например, RTSS или Rainmeter).

Чтобы проверить хранилище, CrystalDiskMark измеряет скорость чтения/записи SSD и HDD — это помогает понять, соответствует ли диск заявленным характеристикам. Глубже оценить здоровье накопителя можно в Hard Disk Sentinel, который анализирует SMART-данные, оценивает срок службы и предлагает ограниченный ремонт.

С точки зрения охлаждения, всё больше геймеров используют утилиты для настройки вентиляторов. FanControl — актуальный бесплатный фаворит: поддерживает сложные кривые оборотов, привязку к датчикам, и совместим с большинством современных материнских плат. На Mac одной из лучших утилит остаётся Macs Fan Control.

Для настройки видеокарт долгое время стандартом был MSI Afterburner — для разгона, настройки вентиляторов и мониторинга с RTSS-оверлеем. Однако из-за замедления обновлений многие сегодня используют встроенные утилиты от Nvidia (GeForce Experience/Control Panel) и AMD (Adrenalin Software).

Если вы меняете видеокарту или подозреваете проблемы с драйверами, обязательно используйте Display Driver Uninstaller (DDU) — он полностью очищает систему от старых драйверов перед переустановкой.

Если вы играете на ноутбуке или хотите снизить нагрев и повысить автономность, ThrottleStop остаётся одним из лучших инструментов для андервольта CPU и настройки энергопрофилей.

Тем, кто серьёзно подошёл к разгону CPU и GPU, пригодятся фирменные инструменты вроде Intel XTU (для Intel) и AMD Ryzen Master — они дают контроль над частотами, напряжениями и лимитами мощности.

Управление файлами

• Поиск больших файлов: SpaceSniffer, WizTree, Disk Drill (macOS)
• Поиск дубликатов: dupeGuru
• Архивы и ZIP: PeaZip, The Unarchiver
• Очистка: BCUninstaller, CCleaner Portable, AppCleaner (macOS)

Чтобы грамотно управлять файлами и освобождать место, нужно понимать, что именно занимает пространство. На Windows популярны WinDirStat и WizTree — быстрые бесплатные инструменты для визуализации диска. SpaceSniffer предоставляет динамическую схему.

На macOS — GrandPerspective и Disk Drill предлагают аналогичный функционал, а DaisyDisk — один из самых красивых платных вариантов с молниеносным сканированием.

Если дубликаты засоряют диск, dupeGuru (open-source) отлично справляется с поиском повторяющихся изображений и музыки, даже слегка изменённых.

Для пакетного переименования файлов (например, фоточек с камеры) существует гибкий Bulk Rename Utility. Если нужно что-то попроще: PowerRename из PowerToys (Windows) или встроенный инструмент в Finder (macOS) подходят большинству.

Встроенный File Explorer в Windows недавно получил вкладки и стал удобнее, но Files (open-source) — современная альтернатива с улучшенным UX. Кто-то ещё пользуется Total Commander или Directory Opus, благодаря расширяемости и скриптам, хотя новичкам они кажутся устаревшими. Для просмотра изображений по-прежнему незаменим IrfanView.

Для работы с архивами, если не устраивает встроенный ZIP-менеджер Windows, скачайте 7-Zip или PeaZip. На Mac лучшим бесплатным инструментом остаётся The Unarchiver.

Для очистки системы важно выбирать надёжные утилиты. На Windows, BCUninstaller (Bulk Crap Uninstaller) — один из самых проверенных для удаления программ и их хвостов. BleachBit и Wise Disk Cleaner — безопасные альтернативы CCleaner (лучше использовать Portable-версию, так как стационарная испортила репутацию). На Mac AppCleaner всё ещё любим за полное удаление приложений без мусора.

Если вы организуете большую библиотеку медиа, стоит взглянуть на open-source TagSpaces, позволяющий тегировать файлы локально, без облака.

Облачное хранилище и резервное копирование

• Простая синхронизация: Dropbox, Google Drive
• Фото между устройствами: Apple iCloud, Google Photos
• Приватность: pCloud, Proton Drive, Internxt
• Полные бэкапы: Backblaze, IDrive

Базовое облачное хранилище

Dropbox — один из самых простых в использовании, хотя бесплатных 2 ГБ мало.

Google Drive — 15 ГБ бесплатно, используется Gmail, Docs и Photos. Идеален для Android.

OneDrive — идёт в комплекте с Windows и Microsoft 365. 1 ТБ включён в большинство Office-планов. Хотя по скорости и интерфейсу уступает Dropbox/Google.

iCloud Drive — лучший выбор для пользователей Apple, глубокая интеграция с macOS/iOS. Бесплатно 5 ГБ, далее по планам до 2 ТБ.

Proton Drive — шифрованная альтернатива от создателей ProtonMail.

Фото и видео

На macOS приложение Photos автоматически создаёт альбомы по людям и локациям, синхронизирует всё через iCloud.

На Windows мы часто рекомендуем Google Photos, который предлагает аналогичный набор функций и автоматизацию. Для пользователей Android — это стандарт по умолчанию. Да, раньше было безлимитно, теперь фото занимают общее место Google Drive (15 ГБ), которое быстро заканчивается.

Полные бэкапы

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

Backblaze — топ в этой категории: фиксированная цена (~$8/месяц за устройство), безлимитное хранилище, минимум настроек: установил и забыл.

IDrive — более контролируемый вариант, поддерживает несколько устройств, внешние диски и версионность файлов.

Простой для не-технарей — Carbonite, с возможностью быстрого восстановления и круглосуточной поддержкой.

Профессионалам — Acronis Cyber Protect: клон дисков, анти-вымогатель, гибридное облако.

Для особо чувствительных данных

Если вы храните личные финансовые документы или медицинские сведения, стоит выбрать end-to-end решений.

pCloud предлагает клиентское шифрование (через платный «Crypto»). Даже при взломе аккаунта файлы не расшифруются без ключа.

Proton Drive — аналогичный подход, с прозрачностью open-source.

Прочие полезные инструменты, не вошедшие в другие разделы

Google Earth — для любителей карт и планировки.

qBittorrent — лучший torrent-клиент: чистый, без рекламы, с поиском. Альтернатива — легковесный Transmission или кастомизируемый Deluge.

iMazing — must-have для владельцев iPhone: резервные копии, экспорт медиа, проверка батареи, конвертация HEIC.

AirDroid — аналог для Android: управление файлам, уведомления, SMS с ПК.

Rufus — лидер по созданию загрузочных USB-дисков для Windows/Linux.

Open Shell — возвращает классическое меню «Пуск» в стиле Windows 7.

Stretchly — напоминает делать перерывы — полезно удалёнщикам и фрилансерам.

AutoHotkey — скриптовый движок для Windows: переназначение клавиш, макросы, автоматизация.

VPN: бесплатные — ProtonVPN, Windscribe, TunnelBear (с лимитом). Платные — ProtonVPN, NordVPN.

Calibre — лучшее бесплатное решение для чтения, организации и конвертации e-book (EPUB, MOBI, PDF и др.).

Заключение

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

Несколько советов напоследок:

1. Не захламляйте систему. Устанавливайте только то, что действительно используете. Чем меньше фоновых процессов — тем быстрее работает компьютер.
2. Следите за обновлениями. Большинство программ обновляются автоматически, но некоторые требуют ручного апдейта. Свежие версии — это не только новые функции, но и закрытые уязвимости.
3. Делайте резервные копии. Никакие утилиты не спасут от отказа жёсткого диска. Регулярный бэкап на внешний носитель или в облако — обязательная практика.
4. Экспериментируйте. Попробуйте несколько браузеров, редакторов, плееров. То, что подходит большинству, может не подойти именно вам.
5. Читайте отзывы. Перед установкой незнакомого приложения загляните на форумы или Reddit. Сообщество быстро выявляет проблемы и подводные камни.

Теперь ваш компьютер готов к работе, учёбе, развлечениям — и чему угодно ещё. Главное — не забывайте, что инструменты важны, но ещё важнее то, как вы их используете. Удачи!

1. DevOps Deflope News

DevOps Deflope News — один из самых известных русскоязычных каналов о DevOps, созданный инженерами компании «Флант». Здесь собирают только то, что действительно нужно специалистам: обновления инструментов, результаты исследований индустрии, новые интересные проекты и технологии. Авторы фильтруют десятки новостных потоков и выкладывают лишь проверенные и практически полезные материалы.

Помимо дайджестов и аналитических постов, команда выпускает подкаст с живыми разговорами о DevOps и опыте из первых рук.

Подход и методология

Редакция делает акцент на практических кейсах и обзорах инструментов, которые уже применяются в продакшене. Формат — короткие советы, лонгриды и подборки ссылок с экспертными комментариями. За контентом стоят инженеры «Фланта» — те самые, кто ежедневно работает с инфраструктурой и CI/CD-пайплайнами.

Сценарии использования

Канал рассчитан на DevOps-инженеров уровня middle и выше: тех, кто хочет держать руку на пульсе инструментов и технологий. Что можно найти: идеи для интеграции CI/CD и оптимизации пайплайнов; материалы о тестировании инфраструктуры и автоматизации проверок; опыт внедрения DevOps-практик и управления командами. Контент подаётся без избыточных объяснений, поэтому даже короткий пост часто даёт инсайт, который экономит часы экспериментов.

Особенности и отличия

DevOps Deflope News выделяется тем, что сохраняет баланс между экспертностью и живостью подачи. Это сообщество специалистов, у которых есть мнение и чувство юмора. Канал связан с подкастом DevOps Deflope, где обсуждают свежие релизы и реальные кейсы внедрения DevOps в российских компаниях.

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

2. Mops DevOps

Mops DevOps — один из самых насыщенных по контенту русскоязычных каналов о DevOps, который уже много лет служит своеобразным путеводителем по экосистеме Kubernetes, Docker, Terraform и облачных технологий. Здесь собирают и систематизируют всё, что нужно инженеру: свежие релизы, обучающие статьи, подборки инструментов, ссылки на книги, вебинары и курсы. Канал живёт за счёт сообщества — контент обновляется несколько раз в неделю.

Подход и методология

Создатели канала делают ставку на системность и навигацию. Каждый пост сопровождается хэштегами по темам — от #kubernetes и #terraform до #aws, #book и #conference. Это превращает канал в удобный справочник: можно быстро найти нужный материал по конкретной технологии или инструменту. Подход к подаче — максимально утилитарный: короткие аннотации, конкретные ссылки, минимум воды. Авторы не пересказывают документацию, а делятся тем, что реально работает в продакшене.

Сценарии использования

Канал полезен тем, кто живёт в инфраструктуре. DevOps-инженеры находят здесь новые практики, примеры конфигов и инструменты для автоматизации; гайды по CI/CD и интеграции пайплайнов с кодом; советы по логированию, мониторингу и тестированию на уровне инфраструктуры.

Особенности и отличия

Главная фишка Mops DevOps — масштаб и удобство поиска. Благодаря продуманной системе тегов канал можно использовать как базу знаний: хочешь курс — открываешь #course, ищешь утилиты — идёшь в #tools, интересуешься конференциями — смотришь #conference. Контент подаётся в ровном ритме и не скатывается в поток случайных ссылок. Баланс между серьёзными статьями и лёгкими материалами выдержан — можно прочитать разбор безопасности AWS, а затем переключиться на мем про Docker.

Технические детали

Канал открыт и активно обновляется. Новые посты появляются несколько раз в неделю. Комментарии выключены. За контентом стоит команда инженеров и энтузиастов, которые делают это не ради трафика, а из интереса к профессии.

3. OrangeDevOps

OrangeDevOps — камерный, но один из самых живых русскоязычных каналов о системном администрировании и DevOps. Здесь нет вылизанных шаблонов и корпоративной редакции — всё строится вокруг опыта одного автора, инженера @il_da_r, который пишет по ходу работы: делится новыми инструментами, ссылками на статьи, наблюдениями из практики и собственными лайфхаками. Канал напоминает инженерный дневник, где полезные материалы чередуются с ироничными комментариями и находками из комьюнити.

Подход и методология

Подход к подаче — предельно неформальный, но выверенный по сути. Автор не пересказывает новости, а делится тем, что действительно пригодилось в деле: от обхода блокировок Docker Hub до настройки мониторинга через Selectel. Формат — короткие посты, часто с рабочими конфигами, YAML-фрагментами и ссылками на исходники. Каждый материал сопровождается коротким комментарием из жизни, что создаёт эффект личного общения, а не учебника.

Сценарии использования

Канал подойдёт прежде всего практикующим DevOps-инженерам и сисадминам, которые ищут конкретные решения и идеи. Здесь можно подсмотреть, как быстро настроить зеркало Docker Hub, найти сборник GitHub-репозиториев по инфраструктуре, вспомнить про бесплатные метрики в Selectel или почитать живое обсуждение собеседований.

Особенности и отличия

OrangeDevOps выделяется своей аутентичностью — это не медиа и не агрегатор, а личный инженерный журнал. Публикации идут неровно: сегодня может быть YAML-файл с инфраструктурой под Яндекс.Облако, завтра — ссылка на «взаимное собеседование в поезде» с ироничным комментарием. Канал создаёт ощущение присутствия в живом профессиональном кругу, где обсуждают не тренды, а реальные задачи.

Технические детали

Канал открыт, посты выходят несколько раз в неделю — в зависимости от находок и вдохновения автора. Комментарии активны, дискуссии случаются нечасто. За всё отвечает один человек, без редакционной фильтрации — именно поэтому контент выглядит живым, честным и «полевым».

4. DevOps&SRE Library

Канал, который стоит в закладках у каждого инженера, следящего за практиками DevOps и Site Reliability Engineering. DevOps&SRE Library — это библиотека по эксплуатации, инфраструктуре, автоматизации и наблюдаемости.Куратор канала — инженер @mxssl, известный своей любовью к чистому коду и точной подаче технического контента.

Подход и методология

Здесь публикуются только материалы, прошедшие фильтр технической ценности — руководства, блоги компаний, репозитории и статьи от экспертов. Каждый пост оформлен в едином лаконичном формате: краткое описание и ссылка на первоисточник. Такой подход экономит время и помогает быстро понять, стоит ли углубляться в тему.

Сценарии использования

DevOps&SRE Library подойдёт инженерам, архитекторам и техническим лидам, которые хотят оставаться в контексте инфраструктурных практик. Это место, где можно найти проверенные материалы о Kubernetes, CI/CD, миграциях баз данных, наблюдаемости, Terraform и автоматизации с элементами AI. Канал станет хорошим источником для составления внутренней библиотеки ссылок в команде или подготовки к архитектурным интервью.

Особенности и отличия

Главная особенность — высокий порог качества. Контент здесь напрямую ведёт к источникам знаний: официальным блогам, исследовательским материалам и репозиториям. Канал не перегружен комментариями, но создаёт ощущение спокойного, академичного пространства, где инженер учится думать системно. DevOps&SRE Library — это скорее инструмент самообразования, чем информационный поток.

Технические детали

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

Из тени вышел Podman. Это был ответ на вопросы, которые раньше боялись или не хотели задавать. Нужен ли нам процесс, который работает с правами root? Можно ли управлять контейнерами иначе и обеспечить безопасность по умолчанию, а не в виде опции?

Разберемся без предвзятости и выясним, что предлагают оба инструмента, где они находятся в 2025 году и что нас ждёт дальше.

Архитектура: демон против бездемонного подхода

Главное различие лежит в самой основе продуктов. Podman, как альтернативный инструмент управления контейнерами, базируется на принципиально иной технологии. Это формирует не только технические, но и идеологические различия.

Docker построен вокруг демона dockerd — это фоновый процесс, который работает с повышенными привилегиями. Когда вы пишете docker run, CLI-утилита не запускает контейнер сама, а даёт команду демону. Демон, обладая правами root, делает всю грязную работу.

Это создает единую точку контроля и отказа. Если демон падает, вы на время теряете управление контейнерами. Уязвимость в демоне открывает путь к захвату всей системы.

Podman пошёл другим путем. В его основе — децентрализованная архитектура. Команда podman run запускает контейнер напрямую, через библиотеку libpod. Процесс работает от имени вашего пользователя. Нет центрального сервера, который можно атаковать.

Это похоже на разницу между центральным сервером и персональными компьютерами. Первый мощный, но его поломка парализует всех. Вторые — независимы, и выход одного из строя не затронет остальных.

Безопасность: rootless как новая норма

В 2025 году запуск контейнеров из-под root — критическая ошибка. Это создает критический риск для всей системы. Идея «безопасность по умолчанию» окончательно победила. Rootless-режим стал обязательной практикой для всех, кто серьезно относится к защите серверной инфраструктуры.

Podman и Docker поддерживают эту практику. Но их подходы различаются на фундаментальном уровне. Podman родился с этой идеей, его архитектура изначально заточена под обычного пользователя. Docker же добавил rootless-режим позже, как важный, но всё же надстрочный элемент.

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

Оба инструмента используют пространства имён пользователей (user namespaces), чтобы обмануть контейнер. Внутри контейнера процесс может работать от имени root (UID 0). Но ядро хоста прозрачно пробрасывает этот внутренний root-идентификатор на обычный, непривилегированный UID (уникальный идентификатор пользователя) снаружи.

Контейнер внутри работает с правами суперпользователя. Он «считает», что может делать что угодно. Но ядро операционной системы обманывает его. Снаружи контейнер работает с правами обычного пользователя, который его запустил. Все его действия проходят через этот фильтр.

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

Podman: rootless из коробки

У Podman этот механизм включен по умолчанию. Вы устанавливаете Podman и сразу можете запускать контейнеры без sudo (команды с повышенными привилегиями). Хранилище образов и контейнеров создаётся в вашем домашнем каталоге (~/.local/share/containers), изолируя работу от действий других пользователей на том же сервере.

Это решает проблему многопользовательских сред. В Docker все, у кого есть доступ к демону (через группу docker), получают эффективные права root на хосте. В Podman пользователь может управлять только своими контейнерами. Он не вправе вмешаться в работу соседа.

Docker: ручная настройка безопасности

Docker проделал большой путь. Его rootless-режим — серьезное достижение. Но он не работает по умолчанию. Системному администратору нужно его сначала установить и настроить.

В rootless-режиме Docker использует дополнительные компоненты, такие как RootlessKit, для эмуляции ряда низкоуровневых функций. Это создаёт определенные проблемы. Например, сетевая связность может быть более ограниченной, а Docker Swarm в rootless-режиме не работает вовсе.

Docker можно обезопасить. Но для этого системному администратору нужно:

• вручную установить и настроить rootless-режим;
• правильно настроить cgroups и делегирование прав;
• переконфигурировать демон для работы без привилегий.

Podman предлагает безопасную конфигурацию сразу после установки. Его архитектура не требует дополнительных настроек для работы в rootless-режиме.

Больше, чем просто rootless — глубина защиты

Безопасность Podman не ограничивается rootless-режимом:

• Меньше прав по умолчанию. Контейнер в Docker изначально получает около 14 System Capabilities — привилегий внутри пространства ядра. Podman по умолчанию выдаёт только 11, следуя принципу минимальных привилегий и отсекая, например, возможность модификации настроек сети.
• Глубокая интеграция с SELinux. В системах вроде RHEL или Fedora Podman автоматически назначает контейнерам SELinux-метки для изоляции. Docker тоже поддерживает SELinux, но часто это требует ручных настроек.
• Аудит и отслеживаемость. Поскольку каждый контейнер — это процесс пользователя, системные журналы и аудиты однозначно показывают, кто именно его запустил. В модели Docker с демоном все действия в журналах проходят как действия пользователя root, что размывает ответственность.

Какая разница для инженера

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

• С Docker по умолчанию: атакующий получает доступ к демону, который работает как root.
• С Docker в rootless-режиме риск снижен. Атакующий остаётся в рамках пользователя, который запустил демон.
• С Podman атакующий попадает в песочницу того пользователя, который выполнил команду podman run. Его возможности строго ограничены. Он не может трогать системные службы, контейнеры других пользователей или критичные файлы хоста.

Индустрия делает осознанный сдвиг в сторону security-by-default (безопасности по умолчанию). Podman здесь чувствует себя увереннее, поскольку его архитектура не заставляет вас делать лишние телодвижения для защиты. Вы с самого начала работаете в более безопасном контуре, не жертвуя при этом удобством или функциональностью.

Комментирует Дмитрий Зайцев, CTO Flocktory, программный директор DevOpsConf:

Несмотря на то, что риски атаки в вашу сторону невелики — они есть, и примерно раз в год мы видим уязвимости в разных частях системы (но в основном в runc), которые позволяют зловреду выйти за пределы своего контейнера и получить доступ к докер-демону. Это, в свою очередь, работая от рута, даёт доступ ко всему серверу. Лучше заранее перестраховаться и перейти на решения без центрального демона с рут-доступом.

Комментирует эксперт Лев Прокопьев, технический директор Privesc Technique:

Мило всё это — стандарты, OCI, проверки на деплое. Буду честен: всё это — меры необходимые, но недостаточные. Когда внутри контейнера у вас дырявое приложение, плоская сеть и набор привилегий, которые дают атакующему лёгкий путь к хосту — вы в опасности. Можно ставить любую тулзу, но если в логике приложения заложены возможности вырваться из неймспейса (capabilities, setuid-баги, неограниченные mount/namespace-операции) — вы уже проиграли. Если в сети контейнеров открыт административный интерфейс, а в одном из контейнеров живёт «php-уродец» от племянника подрядчика, который пишет код после двух онлайн-курсов — поздравляю, у атакующего есть не одна, а десятки точек входа. У злоумышленников есть козырь, которого вы не имеете, — время и отсутствие реальных технических возможностей его деанонимизации. А вот e-mail-адреса и пароли ваших разработчиков порой встречаются в логах стиллеров. Вы тюнингуйте CI, но не забывайте, что в наше время паранойя спасает бизнес.

Жёсткие факты, без иллюзий:

• Демонстрация standard-compliance и добавление проверок в CI — это полезно, но недостаточно.
• Архитектурные решения движков — лишь часть картины; реальная опасность — в приложениях и в политике привилегий.
• Плоская сеть + доступные админ-панели = тривиальная возможность для lateral movement в вашей инфраструктуре.
• Непроверенный код в образах, секреты в Dockerfile/контексте сборки, неограниченные capability — прямой путь к компрометации хоста.
• Нет ничего зазорного в том, чтобы смотрeть публичные образы на Docker Hub, но если вы тупо его скопировали и не проанализировали (например, с помощью https://github.com/wagoodman/dive), при наличии уязвимости у автора образа или при переиспользовании его конфигураций вы можете подарить атакующим точку входа».

Совместимость: Podman учится говорить на языке Docker

Огромная заслуга Docker — стандарт OCI (Open Container Initiative). Спецификации OCI Runtime и Image Format способны переносить контейнеры между разными системами. Образы, созданные в Docker, работают в Podman через общий формат. Это снимает главный барьер для миграции.

Podman понимает команды Docker. Алиас alias docker=podman у программистов стал мемом, но он реально работает. Большинство базовых команд выполняются одинаково благодаря совместимой CLI-структуре.

Но есть нюансы. Сложные сценарии, особенно связанные с сетью или volumes, могут вести себя по-разному. Прямая замена не всегда срабатывает при использовании специфических флагов или параметров монтирования.

Инструмент podman-docker заменяет бинарник Docker на Podman на системном уровне. Это помогает тестировать Podman в существующих CI/CD-пайплайнах без их переписывания, обеспечивая прозрачную замену.

Docker Compose — отдельная история. Podman долгое время не имел полноценной альтернативы. Сейчас есть podman-compose — реализация на Python, которая всё ещё догоняет по функциональности оригинал. Для простых случаев хватает, но для сложных композиций с несколькими сетями и томами могут возникнуть проблемы с совместимостью.

Комментирует Дмитрий Зайцев, CTO Flocktory, программный директор DevOpsConf:

Это момент, на котором смена решения часто буксует. Docker Compose — буквально стандарт-дефакто для большинства ci-пайплайнов мира. В итоге на Podman и прочие аналоги легко и просто уходят в рантайме, где нужно только запускать контейнеры. А CI остаётся жить с Докером и проблемами, которые вызывает там docker in docker (добавьте ещё пару слоёв in docker по вкусу).

В 2025 году Podman 4.x значительно улучшил совместимость с Compose через нативную поддержку Podman Compose. Однако если ваш пайплайн завязан на специфические функции Docker Compose V2, такие как расширения профилей или кастомные интерполяции, переход потребует дополнительного тестирования и адаптации конфигурационных файлов.

Производительность: битва за миллисекунды и мегабайты

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

Запуск контейнера. Podman, благодаря отсутствию демона, избавляется от одного сетевого hop'а при коммуникации CLI с движком. На практике это экономит десятки миллисекунд. Для человеческого восприятия разница неощутима. Но в автоматизированных пайплайнах, где запускаются тысячи контейнеров последовательно, это может дать небольшой накопительный эффект.

Потребление памяти. Архитектура без демона означает отсутствие постоянно висящего в памяти dockerd. Это экономит от 50 до 100 МБ оперативки. На сервере с десятками гигабайт RAM — это капля в море. Однако для embedded-систем, edge-устройств или стесненных сред каждый мегабайт на счету.

Сетевой стек. И Docker, и Podman в 2025 году используют CNI для настройки сети. Оба поддерживают rootless-сети через slirp4netns. Пропускная способность и задержки практически идентичны. Разницу можно заметить только в очень специфических сценариях с интенсивным сетевым трафиком.

Время сборки образов. Здесь Docker с BuildKit пока сохраняет небольшое преимущество за счет кэширования и параллельного выполнения слоев. Podman тоже развивает свою систему сборки, но для очень больших образов разница может составлять 5-10%.

Вывод по производительности простой. Не она должна быть решающим фактором выбора. Разница не настолько велика, чтобы из-за нее менять инструмент. Гораздо важнее архитектурные особенности и экосистема.

Экосистема: что вокруг них выросло

Docker — это целая вселенная. Docker Hub, Docker Desktop, Docker Scout, BuildKit. Огромная инфраструктура для разработки, сканирования образов и управления уязвимостями.

Podman Desktop — относительно молодой проект для macOS и Windows. Он предлагает графический интерфейс для управления контейнерами и подами и в ближайшее время способен догнать по базовой функциональности Docker Desktop. Но экосистема плагинов и интеграций пока скромнее.

Docker Hub остаётся крупнейшим реестром образов. Podman легко с ним работает. При этом вокруг Podman уже выросла собственная инфраструктура. Проекты по сканированию образов, такие как trivy, интегрируются с Podman не хуже.

Если вы завязаны на конкретные сервисы Docker вроде Scout или Build Cloud, переход на Podman будет болезненным. Если вы используете только базовые функции, разницы не заметите.

Поддержка Pod: группа контейнеров как единое целое

Изначально Podman задумывался как инструмент для работы с подами. Pod — это группа контейнеров, которые разделяют общее сетевое пространство, volumes и другие ресурсы.

Концепцию популяризировал Kubernetes. Podman позволяет создавать и управлять подами на одной машине. Это мощный инструмент для локальной разработки под Kubernetes.

Вы можете описать pod в YAML и запустить его через podman play kube. Это ближе к продакшен-окружению, чем отдельные контейнеры через Docker Compose.

Docker не имеет нативной поддержки пода. Есть сторонние плагины, но они не стали мейнстримом. Если ваша цель — Kubernetes, Podman даёт более точную эмуляцию его поведения.

Что выбрать в 2025 году: практические рекомендации

Сложно сказать однозначно, какой инструмент лучше. Всё сводится к вашим задачам, окружению и философии.

Выбирайте Docker, если:

• ваша команда привыкла к нему — переобучение обойдётся дороже гипотетических выгод;
• вы плотно используете Docker Desktop на macOS/Windows — его экосистема пока богаче;
• ваши CI/CD пайплайны завязаны на специфические фичи Docker Engine или Docker Compose V2;
• вы активно используете Docker Scout, Build Cloud и другие проприетарные сервисы вендора.

Смотрите в сторону Podman, если:

• безопасность — ваш приоритет: rootless-архитектура из коробки более эффективна;
• вы разрабатываете для Kubernetes: возможность работать с подами на локальной машине — ощутимый плюс;
• вы работаете в средах, где недопустимы демоны с правами root (строгие корпоративные политики, госсектор);
• вы используете RHEL, Fedora, CentOS Stream, где Podman предустановлен и считается стандартом де-факто;
• вам нравится философия Unix-way: одна программа — одна задача.

Гибридный подход тоже возможен. Разработчики используют Docker Desktop на ноутбуке, а на продакшен-серверах крутится Podman. Инструменты оркестрации вроде Kubernetes скрывают разницу между Docker и Podman. Платформа работает с обоими движками через стандартные интерфейсы, поэтому пользователю не нужно задумываться о выборе.

Комментирует Лев Прокопьев, технический директор Privesc Technique:

Таблетка:

1. Пересмотрите необходимость каждой capability. Если контейнеру не нужен CAP_SYS_ADMIN — удалите её. Пройдитесь по списку и вычёркивайте всё лишнее — философия «минимальных прав» обязательна.
2. Бизнес-логика под нож. Любая операция, которая запрашивает информацию из внешних сервисов (за эксплуатацию которых вы платите), запускает исполняемые файлы, делает mounts или управляет сетью, — должна быть проверена на предмет злоупотреблений. Логика должна быть проста, предсказуема и проверяема. Если читали новости недавно, наверняка видели, как в недавнем голосовании за изображение на купюре массово эксплуатировали недостатки верификации пользователей на основном сайте ЦБ. Несложно догадаться, что именно сотрудники регулятора получили жёсткую обратную связь и теперь придётся тратить бюджет не только на устранение тривиальных уязвимостей, но и на антикризисный PR.
3. Сегментируйте сеть. Никаких «все входят ко всем». Сетевой доступ по принципу least-privilege: management-interfaces — только из доверенных подсетей через jump-hosts и VPN, не из контейнерной сети.
4. Запретите админ-панели в открытом доступе. Если сервис нужен только для админов — закройте его за IP-фильтрами, MFA и надёжными механизмами контроля доступа.
5. Проверьте supply-chain. Кто собирает образы, какие зависимости подтягиваются, есть ли секреты в CI-контексте. Подпишите и верифицируйте артефакты.
6. Runtime-защита и аудит. Включите SELinux/AppArmor, seccomp-профили, логирование действий пользователей и процессов. Аудит должен показывать, кто и что запустил.
7. Тестируйте логику, а не только окружение. unit/integration + fuzzing + SAST/DAST по бизнес-логике — баги в логике ищутся иначе, чем уязвимости в движке. Разберитесь уже с Burp Professional — Postman круто, но это инструмент QA-шника.
8. Не доверяйте подрядчику по умолчанию. Код сторонних разработчиков — предмет проверки, а не слепого доверия. Code review, dependency-pinning, CVE-сканирование образов.
9. Автоматизируйте инцидент-реакцию. Планы, playbooks, тестовые срабатывания. Чем быстрее вы сокращаете время обнаружения, тем меньше у атакующего «времени в руке».
10. Домашнее задание. Возьмите SAST, например semgrep, и напишите к нему MCP-оснастку; поставьте в Ollama условный Qwen3-Coder и натравите на ваш код в тестовой среде промптом. Его задача — не просто найти уязвимости и пройти ваш compliance, а буквально «раскурочить» код: найти все потенциальные недостатки, внешние библиотеки, которые можно заменить нативным кодом, проверить весь пользовательский ввод и то, как он фильтруется, сделать анализ конфигураций и переменных окружения. И ещё важный нюанс — LLM не должна опрашивать о задаче каждые n секунд: RAG должен передавать завершённую задачу в LLM.

Прогноз на 2026: универсализация и специализация

Мир не стоит на месте. К 2026 году границы между инструментами продолжат размываться. Эти прогнозы — экстраполяция текущих трендов в развитии инструментов:

1. Полная совместимость. Podman добьёт оставшиеся проблемы с Docker Compose. Мы увидим почти прозрачную взаимозаменяемость для 95% сценариев. Стандарт OCI победит.
2. Рост Podman в корпоративном секторе. Благодаря усилиям Red Hat и IBM, Podman будет все чаще появляться в крупных компаниях. Особенно там, где есть сильная команда Linux и требования безопасности.
3. Docker сосредоточится на SaaS. Бизнес Docker будет смещаться в сторону платных облачных сервисов: реестры, сканирование уязвимостей, управление образами. Движок Docker Engine может стать более открытым и модульным.
4. Война за десктоп. Podman Desktop будет активно развиваться, догоняя по удобству Docker Desktop. Возможно, появление новых GUI-инструментов, которые работают поверх обоих движков.
5. Ниша для новых игроков. Появятся инструменты, созданные под специфические сценарии: WebAssembly-контейнеры (Wasm), крайне легковесные среды. Нишевые решения для edge-устройств и IoT.

К 2026 году вопрос «Docker или Podman?» может потерять остроту. Как сегодня мы не спорим, использовать ли vim или nano. Инструменты станут взаимозаменяемыми кирпичиками в более крупных системах. Вашим основным интерфейсом будет не CLI docker или podman, а платформа оркестрации или платформа разработки.

Комментирует Лев Прокопьев, технический директор Privesc Technique:

Вкратце: сложно не любить Podman и не кайфовать от rootless-режима из коробки, но если ваша архитектура и приложения позволяют “выйти наружу” — вы создаёте идеальные условия для тихой и долговременной компрометации. Можете ставить все даты деплоя в зеленый CI-статус — злоумышленник же ставит себе цель не «поймать красный билд», а жить в вашей сети месяцами, собирая деньги, данные и аргументы для дальнейшей эскалации. Не устраняете уязвимости и не режете привилегии — значит, вы просто откладываете неизбежное. Разберитесь с этим сейчас, иначе красивые диаграммы по стандартам станут вашим приговором.

Самый правильный подход в 2025 году — знать оба инструмента. Поэкспериментировать с Podman в pet-проекте. Установить Podman Desktop рядом с Docker. Прочувствовать разницу.

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

По его словам, система нарушает базовые принципы проектирования: объединяет все режимы рендеринга (SSR, CSR, SSG, ISR), но делает это «магическими» способами, из-за чего теряется ясность и усложняется поддержка.

Жесткая связность

Next.js строится на четырех опорах — CLI, компилятор, роутер и рантайм.

Но заменить или расширить любую часть почти невозможно: миграция с Webpack на Vite в одном из проектов заняла более полугода. Такая связность убивает гибкость и мешает инновациям.

Нет модульности

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

Проблемы есть и с переменными окружения — фреймворк смешивает их на этапе сборки и выполнения, что противоречит 12-Factor-принципам и мешает корпоративным пайплайнам.

Ограничения для бизнеса

Эксперт приводит реальные кейсы, где Next.js бессилен: динамическая смена тем в CRM, модульные платформы для разных команд, финансовые системы без пересборки Docker-образов, проекты с dual-licensing.

Во всех случаях фреймворк накладывал ограничения и мешал масштабированию.

Сложность убивает. Я выбираю простоту. Next.js — это удобный инструмент для быстрых проектов, но не фундамент для устойчивой архитектуры.

• Тестовая среда: используйте последний стабильный релиз (например, 3.5.6; см. страницу Tags на GitHub).
• Staging (предпроизводственная) и Production (производственная) среды: используйте последний минорный релиз предыдущей стабильной ветки.
• Если требуется новый функционал или критическая фиксация, можно собрать из актуального кода ветки main, используя официальный Docker-образ сборочного окружения.
• Компонент BE (Backend) требует CPU с поддержкой AVX2. Возможна сборка без AVX2 (работоспособно, но не рекомендуется — нет полноценного покрытия тестами).
• Начиная с 1.19 StarRocks поддерживает ARM, но потребует самостоятельной сборки на ARM-хосте (официальные готовые бинарники под ARM пока не публикуются).

Справочные ссылки:

• Страница Tags (например, 3.5.6, 4.0.0-rc01): https://github.com/StarRocks/starrocks/tags
• Release Notes 1.19 (сообщество): https://forum.mirrorship.cn/t/topic/552

Ниже — пример сборки из актуального кода ветки main с использованием официального Docker-образа.

1. Установка Docker и загрузка сборочного образа

Для примера используется CentOS 7.6 в виртуальной машине (рекомендуется ≥2 vCPU и ≥4 ГБ RAM). Во время сборки требуется стабильное сетевое подключение.

1.1 Установка Docker

1.2 Запуск Docker и автозапуск

1.3 Проверка установки

При успешном выполнении отобразится сообщение “Hello from Docker!”.

1.4 Ускорение загрузки образов (для нестабильных каналов)

Если загрузка официальных образов Docker медленная/нестабильная, можно использовать сервисы Alibaba Cloud Container Registry (ACR). Важно: официальный ACR image accelerator больше не синхронизирует последние образы. Если образ не скачивается или тег latest не содержит актуальную версию, воспользуйтесь альтернативами:

• Подписка в ACR на зарубежные исходные образы (subscription of overseas source images).
• Использование GA (Global Accelerator) для ускорения прямого доступа к зарубежным реестрам.

Рекомендация для Production: минимизируйте зависимость от Docker Hub из‑за сетевых рисков.

Если вы используете containerd:

• Убедитесь, что в /etc/containerd/config.toml задан config_path, например: [plugins."io.containerd.grpc.v1.cri".registry] config_path = "/etc/containerd/certs.d"
• Уберите конфликтующие mirrors (если есть), перезапустите containerd: sudo systemctl restart containerd
• При ошибке старта изучите вывод: journalctl -u containerd
• Создайте файл /etc/containerd/certs.d/docker.io/hosts.toml: server = "https://registry-1.docker.io" [host."https://<your-ACR-accelerator-address>"] capabilities = ["pull", "resolve", "push"]

1.5 Загрузка сборочного образа StarRocks

Выбирайте тег образа в соответствии с веткой/версией исходников (для ветки main — тег main; для ветки 3.5 — тег 3.5 и т. п.):

1.6 Просмотр локальных образов

2. Получение исходников StarRocks

2.1 Клонирование из GitHub или скачивание архива

Стандартно:

Если из‑за сетевых ограничений возникают ошибки (например, EOF), можно:

• использовать зеркало GitHub (пример): git clone https://github.com.cnpmjs.org/StarRocks/starrocks.git
• либо скачать архив кода из браузера: https://github.com/StarRocks/starrocks
• архив конкретного релиза: https://github.com/StarRocks/starrocks/tags

Чтобы ускорить клонирование, добавьте --depth 1 (если не требуется полная история).

2.2 Загрузка архива на сервер и распаковка (вариант с ZIP)

2.3 Запуск контейнера со сборочным окружением и монтированием кэшей

Рекомендуется смонтировать локальный Maven-кэш (~/.m2) для ускорения повторных сборок.

(Опционально — подключите ccache, смонтировав ~/.ccache, если это поддерживается образом.)

2.4 Проверка запущенных контейнеров

2.5 Вход в контейнер

2.6 Переход в каталог исходников

2.7 Сборка FE и BE

Скрипт скачает зависимости и выполнит сборку (может занять значительное время). Благодаря монтированию ~/.m2 зависимости будут переиспользованы в следующих сборках.

Результаты сборки — в каталоге output/:

Сборка без AVX2 (только при необходимости; не рекомендуется)

Измените build.sh, чтобы принудительно отключить AVX2:

Измените сборку сторонней библиотеки в thirdparty/build-thirdparty.sh (блок croaring):

Повторно выполните ./build.sh. Учтите: такой вариант не имеет полноценного покрытия тестами.

Полезные опции build.sh

2.8 Сборка Broker

Broker не собирается шагом выше — его нужно собирать отдельно:

Готовые файлы появятся в

.

2.9 Выход и повторный запуск контейнера при необходимости

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

Примечания и рекомендации

• FE (Frontend) и BE (Backend) — основные компоненты StarRocks, сборка которых выполняется скриптом build.sh.
• Для воспроизводимости привязывайте тег сборочного Docker-образа к ветке/версии исходников (например, starrocks/dev-env:3.5 для ветки 3.5.x).
• Для ускорения повторных сборок используйте кэш Maven (~/.m2) и, при возможности, ccache для C++.
• ARM: официальный сборочный Docker-образ пока не рассчитан на ARM. Для ARM-сборки потребуется нативный ARM-хост и корректные версии зависимостей (JDK, CMake и др.).
• Список актуальных релизов и тегов: https://github.com/StarRocks/starrocks/tags
• Release Notes 1.19 (сообщество): https://forum.mirrorship.cn/t/topic/552

После этих шагов у вас будут собранные бинарные артефакты FE/BE и Broker, готовые к дальнейшему развертыванию кластера StarRocks.

1. 10-Страйк: Мониторинг Сети Pro

10-Страйк: Мониторинг Сети Pro — это российская программа для системных администраторов, которая позволяет контролировать состояние сетевых устройств, серверов, рабочих станций, коммутаторов, баз данных и других ресурсов инфраструктуры. Она отслеживает ключевые параметры — от свободного места на дисках и загрузки процессора до температуры оборудования — и в случае проблем отправляет уведомления по email, SMS или в мессенджеры. Система может не только сигнализировать о сбоях, но и автоматически устранять их, например, перезапуская службы или выполняя скрипты.

Технические возможности

Продукт поддерживает десятки видов сетевых проверок через ICMP, SNMP, HTTP, SQL, SSH и другие протоколы. Возможно мониторить серверы Windows и Linux, сетевые службы, видеокамеры, принтеры, СУБД и промышленное оборудование. Визуализация данных доступна на карте сети с графиками и индикаторами. В версии Pro предусмотрен распределённый мониторинг с несколькими серверами и аген­тами, а также веб-интерфейс для удалённого управления.

Сценарии использования

Для DevOps и системных администраторов 10-Страйк подходит как инструмент централизованного мониторинга с алертами и картой сети. IT-отделы предприятий используют его для контроля доступности каналов связи, серверов, баз данных и устройств. Руководители могут формировать отчёты по аптайму и SLA для анализа стабильности работы инфраструктуры.

Особенности

Программа выделяется простотой настройки проверок, наличием наглядной карты сети и гибкой системой сигнализации. Важное преимущество — возможность распределённого мониторинга в удалённых сетях и работы в круглосуточном режиме без участия администратора. Решение разработано в России и подходит под задачи импортозамещения.

Тарифы и условия

Продукт распространяется по лицензии с ограничением на число сенсоров: версия Pro на 100 сенсоров стоит 40 000 рублей, стандартная версия — 20 000 рублей. Для корпоративных лицензий действует ограничение на количество серверов мониторинга.

2. Deckhouse Prom++

Deckhouse Prom++ — это Open Source-система мониторинга на базе Prometheus, которая потребляет до 10 раз меньше памяти. Она собирает метрики приложений, сервисов и инфраструктуры в реальном времени, хранит их во встроенной TSDB и поддерживает PromQL для анализа. Deckhouse Prom++ умеет формировать алерты и легко интегрируется с Grafana, оставаясь привычным для команд, которые уже работают с Prometheus.

Технические возможности

Deckhouse Prom++ может собирать любые инфраструктурные метрики напрямую или через экспортеры: состояние серверов, контейнеров, сетей, баз данных и приложений. Главная оптимизация по сравнению с «ванильным» Prometheus — переработка Write Ahead Log — позволяет снизить потребление памяти без ущерба производительности. Продукт полностью совместим с API и настройками Prometheus: дашборды, правила алертинга и интеграции продолжают работать без изменений. Prom++ уже используется на более чем 1000 кластеров и поддерживает до 10 млн активных метрик на кластер.

Сценарии использования

DevOps-инженеры и SRE могут использовать Deckhouse Prom++ для мониторинга Kubernetes и традиционной инфраструктуры. Архитекторы и CTO получают возможность сократить расходы на RAM без отказа от привычной экосистемы. Prom++ подходит и для on-prem, и для облачных окружений, а также уже встроен в Deckhouse Kubernetes Platform.

Особенности

Ключевое преимущество Deckhouse Prom++ — низкое потребление ресурсов: до 10 раз меньше памяти, чем у Prometheus, и до 3 раз меньше, чем у VictoriaMetrics. Сервис полностью совместим с экосистемой Prometheus, не создаёт вендорлока и распространяется под лицензией Apache 2.0. Поддержка осуществляется инженерами Deckhouse и сообществом через открытый Telegram-чат.

Тарифы и условия

Deckhouse Prom++ — полностью бесплатный Open Source-продукт. Ограничений по количеству пользователей или метрик нет.

Есть инструкция по миграции, потребуется только предварительная конвертация WAL-файлов. Вы также сможете без труда вернуться с Deckhouse Prom++ на Prometheus.

Инженеры Deckhouse и сообщество помогают пользователям в Telegram-чате Prom++ User Group.

3. GMONIT

GMONIT — российская платформа класса Observability, которая собирает и анализирует метрики, логи, трассировки и бизнес-показатели в едином интерфейсе. Она даёт ИТ-командам полный обзор цифрового контура: от сетей, серверов, баз данных и контейнеров до пользовательских действий и бизнес-метрик. GMONIT помогает перейти от «реактивного» реагирования на инциденты к проактивному управлению ИТ, сокращая время диагностики и повышая стабильность сервисов.

Технические возможности

GMONIT поддерживает мониторинг сетей, серверов, виртуальных машин, баз данных, контейнеров, API, реальных пользователей в браузере или мобильном приложении и бизнес-процессов. Система строится на микросервисной архитектуре, легко масштабируется и формирует дашборды для разных ролей — от инженеров до CIO. В одном интерфейсе доступны ключевые показатели доступности, SLA, конверсии, скорость обработки заказов и другие бизнес-метрики. Платформа обеспечивает предиктивную аналитику, раннее выявление аномалий и ускоренное RCA (Root Cause Analysis — анализ первопричин): TTD (Time To Detect — время до обнаружения) — менее 10 минут, RCA — около 15 минут.

Сценарии использования

• Разработчики используют GMONIT для отладки сервисов и мониторинга CI/CD, что ускоряет релизы и сокращает время устранения ошибок.
• QA-команды применяют платформу при нагрузочных тестах и фиксации ошибок в продакшене.
• DevOps и SRE получают централизованный мониторинг с алертами, предиктивной аналитикой и интеграцией в пайплайны.
• PM и CIO работают с визуальными панелями SLA, аптайма и бизнес-метрик, чтобы видеть реальное влияние инфраструктуры на продажи и пользовательский опыт.
• Поддержка сокращает время реакции на инциденты и устраняет сбои до того, как о них сообщают пользователи.

Особенности

GMONIT строится как масштабируемая система с единым «окном наблюдения»: метрики инфраструктуры, пользовательского опыта в браузере, приложений, API; а также вызовы во внешние сервисы и бизнес-процессы отображаются на одном дашборде. Архитектура ориентирована на работу с большими объёмами данных, а визуализация адаптирована как под инженеров, так и под управленцев. Сервис интегрируется с CI/CD, мессенджерами и сторонними системами через API. Поддерживаются как on-prem, так и облачные сценарии.

Тарифы и условия

Информацию о тарифах можно найти на официальном сайте GMONIT. Ограничений по числу пользователей и метрик нет. API и SDK доступны, а интеграции гибко настраиваются под нужды заказчика.

Управление и поддержка

Управление осуществляется через веб-интерфейс и API. Поддержка организована через чат, систему тикетов, SLA и подробную документацию.

4. Zabbix

Zabbix — это платформа мониторинга корпоративного уровня, которая обеспечивает полную наблюдаемость IT- и OT-инфраструктуры. Решение ориентировано на крупные компании и поставщиков управляемых услуг, отличается низкой совокупной стоимостью владения и предсказуемой моделью поддержки без лицензионных сборов. Zabbix создан для долгосрочного использования: он масштабируем, безопасен «по конструкции» и подходит для критически важных систем.

Технические возможности

Платформа поддерживает мониторинг серверов, приложений, облачных сервисов, сетевых устройств и IoT, включая многоуровневые среды. Важной функцией выступает вложенное низкоуровневое обнаружение, позволяющее автоматически создавать иерархические правила для хостов и сервисов. Zabbix предлагает мастер создания хостов, встроенную проверку форм для сокращения ошибок, расширенные сетевые карты и новый виджет карточки товара для детальной визуализации метрик. Платформа может быть развернута локально, в облаке Zabbix или в сторонних облаках (AWS, Azure, Google Cloud).

Сценарии использования

Zabbix применяют IT-отделы и DevOps-команды для централизованного мониторинга инфраструктуры и соответствия требованиям безопасности. Поставщики управляемых услуг используют его как MSP-дружественное решение с многопользовательским доступом и возможностью масштабирования под клиентов. Платформа востребована в высокозащищённых и регулируемых отраслях, где важны автономность и полный контроль над данными.

Особенности

Ключевые преимущества Zabbix — это открытый исходный код и отсутствие лицензионных ограничений. Архитектура платформы масштабируется «под будущее» и интегрируется с системами управления конфигурацией. Пользователи получают полное владение данными, гибкость в развертывании (on-premise, облако, гибрид) и широкие возможности кастомизации визуализации.

Тарифы и условия

Zabbix распространяется как решение с открытым исходным кодом и не требует лицензионных платежей. Стоимость формируется только за счет технической поддержки, которая предоставляется по фиксированным тарифам в зависимости от уровня сервиса.

5. LibreNMS

LibreNMS — это система мониторинга сетевой инфраструктуры с автоматическим обнаружением устройств и сервисов. Она ориентирована прежде всего на мониторинг сетей по SNMP, но также поддерживает серверы на Windows, Linux и FreeBSD через собственные агенты. Решение работает на базе PHP и MySQL, имеет удобный веб-интерфейс, мобильные приложения и широкий набор встроенных метрик, которые не требуют ручной настройки.

Технические возможности

Система автоматически обнаруживает топологию сети с помощью протоколов CDP, FDP, LLDP, OSPF, BGP, SNMP и ARP. Поддерживается интеграция с NfSen, collectd, SmokePing, RANCID и Oxidized. Встроенный API позволяет управлять установкой, строить графики и выгружать данные. Реализована гибкая система оповещений с поддержкой email, IRC, Slack и других сервисов, а также встроенная биллинговая система для учета использования полосы пропускания. LibreNMS поддерживает различные методы аутентификации, включая LDAP, Radius и Active Directory, и обновляется автоматически.

Сценарии использования

LibreNMS выбирают компании, которым важно быстрое развертывание мониторинга сети без сложной ручной настройки. Решение подходит интернет-провайдерам и корпоративным IT-отделам для учета трафика и выставления счетов, а также администраторам, которым нужен автоматический контроль устройств и серверов с оповещениями в удобных каналах. Благодаря мобильным приложениям и демо-версии система подходит для тестирования и удаленной работы.

Особенности

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

Тарифы и условия

LibreNMS распространяется как проект с открытым исходным кодом и бесплатен для использования. Доступна онлайн-демонстрация (https://demo.librenms.org, логин: demo, пароль: demouser).

Мы собрали подборку провайдеров VPS, где можно быстро поднять сервис — от тестового окружения до продакшн-нагрузки. Каждый вариант отличается своим подходом: где-то ставка на скорость запуска, где-то на бэкапы и приватные сети, а где-то на инфраструктурные гарантии.

KoaraCloud

Железо и минимальный порог входа

Бесплатных тестовых периодов провайдер не предоставляет, но минимальный тариф обойдётся в 279 рублей в месяц. За эти деньги выдают машину на базе процессора Ryzen 9 3900 с 1 vCPU, 1 ГБ оперативной памяти и диском на 15 ГБ. Ресурсы честно изолированы с помощью аппаратной виртуализации KVM, поэтому соседи по серверу не смогут забрать ваше процессорное время.

К каждому серверу бесплатно идёт выделенный IPv4, а если для архитектуры API требуется IPv6, адрес выдают по отдельному запросу. Мощностей стартового тарифа обычно хватает, чтобы развернуть легковесное API или Telegram-бота без серьезных нагрузок. Для тех, кто пишет бэкенд на PHP, предусмотрена установка окружения с ISPmanager в один клик прямо из панели управления.

Практика: как держит нагрузку

Отклик серверов площадки до дата-центров Telegram составляет около 10 мс. В качестве примера из реальной практики: на мощностях провайдера крутится развлекательный Telegram-бот, который обслуживает аудиторию более 10 000 чатов. Он работает на тарифе START-2 — это аналог базового сервера, но с увеличенным объемом диска и 2 ГБ RAM.

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

Саппорт и решение инцидентов

Штат технической поддержки работает круглосуточно. Часть рутинных задач площадка закрывает автоматически с помощью ИИ, но при необходимости к тикету подключается живой инженер — среднее время ответа составляет 5–10 минут. Технические неполадки обычно носят очень локальный характер и затрагивают лишь несколько серверов клиентов. Информацию о таких сбоях сразу публикуют в специальном канале, а на само решение уходит от 5 до 20 минут.

Связаться с техподдержкой можно в личном кабинете на сайте. Для общих вопросов предусмотрены Telegram-бот, чат на сайте и отдельный чат комьюнити.

2. Beget: VPS с посуточной тарификацией и готовыми сборками

Beget предлагает виртуальные серверы с посуточной тарификацией и запуском за секунды. Для разработчиков это значит, что можно развернуть бота или тестовый API с ходу, а потом уже решать, насколько масштабировать проект. В придачу — встроенные сборки популярных инструментов, автоматические бэкапы и мониторинг, который сам предупредит о проблемах.

Базовая конфигурация

Минимальный тариф начинается с 1 CPU (Intel Xeon Scalable или AMD Epyc 3–3.3 ГГц), 1 ГБ RAM и 10 ГБ NVMe-диска. Стоимость — 7 ₽ в день. В линейке есть варианты до 8 CPU и 16 ГБ RAM, что позволяет поднимать проекты разного масштаба. Подключение занимает меньше минуты, а тариф можно «докрутить» на ходу.

Сценарии для ботов и API

На минимальном тарифе можно без проблем держать телеграм-бота или внутренний API для небольшой команды: авторизация, опросники, простые интеграции. Для проектов с нагрузкой в несколько тысяч запросов в сутки хватает даже пары ядер. Если требуется больше (например, API с долгоживущими соединениями или сервисы с видеоконференциями), конфигурацию можно нарастить буквально за минуту.

Функции для разработчиков

• Поддержка Docker «из коробки», что удобно для микросервисов и API;
• Более 50 готовых сборок: от Ubuntu 24.04 и Hestia CP до BitrixVM и FASTPANEL;
• Автоматические бэкапы, которые можно восстановить на другой сервер или развернуть отдельные файлы без остановки работы;
• Приватные сети с пропускной способностью 1 Гб/сек для балансировки нагрузки и выноса базы данных;
• Интеграция с Telegram: уведомления о превышении лимитов CPU/RAM/SSD приходят прямо в чат.

Панель и управление

Управление серверами и доменами объединено в одном дашборде: там же доступны DNS-хостинг, почта на домене и файловый менеджер. Есть встроенный VNC-терминал с вкладками и возможность мониторинга ресурсов в реальном времени.

Стабильность и инфраструктура

Сервера работают на KVM без оверселлинга, то есть ресурсы действительно выделены. Дата-центры в России, Казахстане и Европе соответствуют Tier III: профилактика и ремонты проходят без остановки сервисов. Плюс встроенная защита от DDoS на сетевом уровне.

Поддержка

Круглосуточная помощь по вопросам VPS, DNS и доменов. Без навязывания апгрейдов, но с разбором проблем — полезно, если ночью упал какой-то сервис и нужно быстро понять, где слабое место.

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

3. Спринхост — VDS в формате «Спринтбокс»

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

Конфигурации и цены

• Джун: 1 CPU, 512 МБ RAM, 10 ГБ NVMe — от 91 ₽ в месяц
• Мидл: 2 CPU, 2 ГБ RAM, 30 ГБ NVMe — от 691 ₽ в месяц
• Сеньор: 4 CPU, 6 ГБ RAM, 70 ГБ NVMe — от 2 291 ₽ в месяц

Все тарифы идут с портом на 10 Гбит/с и безлимитным трафиком.

Сценарии для ботов и API

Минимальная конфигурация подойдёт для лёгких телеграм-ботов или микросервисов с парой сотен пользователей в день. Если нагрузка растёт, «Мидл» или «Сеньор» уже позволяют держать полноценный API с тысячами запросов и несколькими интеграциями. Отдельный плюс — IPv4 и целая подсеть IPv6 в комплекте, что полезно для сервисов с большим количеством соединений.

Что выделяет Спринтбокс

• 10 Гбит/с порт даже на минимальном тарифе — редкость для сегмента VDS;

• Автоматические бэкапы за последние 30 дней хранятся отдельно и не съедают дисковое место;

• Управление через телеграм-бота — мониторинг и базовые операции доступны прямо в мессенджере;

• Большое количество готовых образов: можно поднять сервер с чистой ОС или сразу с приложением.

Инфраструктура и поддержка

Сервера размещаются в двух Tier III дата-центрах («АТОМДАТА Xelent» и «Ростелеком-ЦОД»). Используется QEMU-KVM, так что ресурсы предсказуемо закреплены за пользователем. Поддержка отвечает круглосуточно и может помочь с переносом виртуальной машины, если она тоже на KVM.

Спринтбокс подойдёт для тех случаев, когда нужна скорость запуска, гибкая тарификация по дням и возможность управлять инфраструктурой через Telegram. Хороший вариант для ботов и API, где нагрузка может меняться, а быстрый масштаб или пауза в работе — часть рутинного сценария.

4. Рег.ру — VPS с почасовой оплатой и API для управления

Услуга построена на KVM-виртуализации, что даёт предсказуемое поведение серверов — работать с ними можно так же, как с полноценным физическим железом. Создание нового VPS занимает около минуты, после чего сразу можно переходить к настройке.

Конфигурация и тарифы

Пример минимального тарифа:

• 1 vCPU (2.8 ГГц)
• 1 ГБ RAM DDR4
• 10 ГБ NVMe SSD
• 1 плавающий IP

Стоимость: от ~0,94 ₽/час (~630 ₽ в месяц). Минимальный платёж — 100 ₽.

Есть и другие тарифы, которые масштабируются по CPU, памяти и дискам. Оплата почасовая, что удобно для тестов, обучения или временных проектов.

Сценарии использования для ботов и API

Минимальная конфигурация подходит для учебных API, внутренних ботов в команде или тестовых окружений. На тарифах постарше уже можно держать продакшн-сервисы с постоянной нагрузкой: инфраструктура выдерживает тысячи запросов и умеет справляться с сетевыми атаками. Поддержка популярных шаблонов (LAMP/LEMP, Node.js, Django, Docker) позволяет развернуть готовый стек из коробки.

Что выделяет Reg.ru

• Автоматические бэкапы и снэпшоты: до четырёх копий в неделю + ежедневные сохранения при почасовой оплате.
• API для управления VPS: удобно интегрировать в CI/CD или собственные панели.
• Сетевая изоляция: клиенты не делят один широковещательный домен, что снижает риски и повышает стабильность.
• Резервные серверы «на подхвате»: при поломке железа диски переносятся на запасной сервер за 15–20 минут.
• Защита от DDoS (L3/L4) включается автоматически при первых признаках атаки.

Дата-центры

Сервера расположены в Москве (Курчатовский институт), Санкт-Петербурге (Tier III ЦОД), и Тольятти («Жигулевская долина», сертифицированный Tier Facility). Это значит, что проекты разворачиваются ближе к пользователям и имеют запас по надёжности.

Поддержка и документация

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

Reg.ru подойдёт, если нужны предсказуемость работы и инфраструктурные страховки: изоляция сетей, резервные серверы и защита от DDoS. Удобно для API и ботов, которые должны работать стабильно и без простоев, даже если что-то ломается на железном уровне.

5. Евробайт

Евробайт предлагает VPS с упором на стабильность и гибкость, что делает их удобным решением для запуска ботов и API. Минимальный тариф начинается от 145 ₽ в месяц и включает 1 ядро CPU, 512 MB RAM и 10 GB NVMe-диска. Доступна также посуточная аренда от 5 дней, что подходит для тестов или краткосрочных проектов.

Что выделяет Евробайт

На практике серверы выдерживают работу Telegram-бота с нагрузкой до 600 активных пользователей одновременно и скоростью до 130 запросов в секунду без лагов. Среднее время отклика составляет 90–120 мс, аптайм — 99,7% при стабильном ping и отсутствии потерь пакетов.

Инфраструктура хостинга

Инфраструктура построена на быстрых NVMe SSD и канале в 1,5 Тбит/с, дата-центры уровня Tier III расположены в Москве и Нидерландах, а защита от DDoS обеспечивает бесперебойную работу. Есть root-доступ, SSH, выбор ОС и готовые окружения с Python, что удобно для разработчики скриптов, парсеров и Telegram-ботов.

Тарифы и поддержка

Все тарифы включают безлимитный трафик, выделенный IP, бесплатный SSL и удобные панели управления (ispmanager или FastPanel). В любой момент можно увеличить ресурсы без потери данных. Поддержка работает 24/7 через тикеты, телефон, чат, Telegram и соцсети — среднее время ответа не превышает 10 минут.

6. PSB HOSTING

PSB HOSTING — это хостинговое решение для быстрой и стабильной работы проектов, построенное на современном оборудовании с акцентом на производительность и надежность. В основе инфраструктуры — процессоры AMD и Intel, оперативная память DDR5, NVMe SSD и выделенные каналы до 10 Гбит/с. Все серверы размещены в дата-центрах уровня Tier III+ и Tier IV, что гарантирует стабильный трафик и доступность до 99,99%.

Особенности решения

Провайдер предлагает аренду виртуальных серверов (VPS) в Европе и США. Доступны как стандартные конфигурации, так и High-CPU VPS на базе AMD Ryzen 7950X для задач, требующих максимальной вычислительной мощности. Используется виртуализация KVM, обеспечивающая полную изоляцию ресурсов и стабильную работу.

Возможна предустановка популярных окружений и программ: Docker, LAMP, Node.js, Wordpress, Django, FastPanel, Keitaro, OpenVPN, Wireguard, Bitrix и другие. Все серверы создаются моментально после оплаты, достаточно дождаться установки выбранной ОС.

Кому может быть полезен

PSB HOSTING подходит для разработчиков и компаний, которым нужны быстрые VPS в зарубежных локациях, поддержка Windows, Linux и FreeBSD, а также гибкие настройки окружения под задачи. Благодаря неограниченному трафику и поддержке современных решений, сервис удобен как для веб-проектов и приложений, так и для разворачивания корпоративных сервисов, тестирования или запуска приложений с высокой нагрузкой.

Стоимость

Цены стартуют от $6 в месяц (1 vCPU, 2 GB RAM, 30 GB SSD NVMe). Оплата возможна банковскими картами, через Qiwi, а также криптовалютами (BTC, ETH, USDT, TON и др.). Для всех услуг действует возврат средств в течение 72 часов, если качество не соответствует ожиданиям.

Как выбрать VPS

Выбор VPS для бота или API в 2025 году зависит от вашего сценария:

• если нужен быстрый запуск с готовыми сборками и уведомлениями в Telegram, подойдёт Beget с посуточной тарификацией и приватными сетями для балансировки нагрузки;
• для тестовых проектов с паузами в работе — Спринтхост с портом 10 Гбит/с и безлимитным трафиком, где даже минимальный тариф выдерживает сотни пользователей;
• если важна почасовая оплата и API для CI/CD — Рег.ру с автоматическими бэкапами и защитой от DDoS, обеспечивающими стабильность при пиковых запросах;
• для простых ботов с root-доступом и поддержкой Python — Евробайт с аптаймом 99,7% и скоростью отклика 90–120 мс под нагрузкой до 130 запросов в секунду;
• для международных проектов с высокой мощностью — PSB HOSTING с DDR5 и NVMe в Tier III+ дата-центрах, где трафик неограничен, а возврат средств возможен в 72 часа.

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

Сегодня, в условиях конкуренции, компании стремятся доставлять продукт до пользователей максимально быстро – и автоматизация ИТ-инфраструктуры может в этом помочь. Она включает автоматическое развертывание, настройку, мониторинг и управление IT-ресурсами и сервисами с помощью специализированных инструментов.

О некоторых из таких инструментов и пойдет речь в этой статье.

Мы разберем возможности Ansible, Terraform, Zabbix, Kubernetes и GitHub Actions, расскажем, как они могут помочь автоматизировать вашу инфраструктуру. Наш материал пригодится всем, кто хочет сократить время на рутинные задачи, ускорить развертывание IT-систем и управлять инфраструктурой с минимальными рисками человеческой ошибки.

Ansible

Этот сервис автоматизации с помощью простых YAML-скриптов работает через SSH и позволяет автоматизировать буквально всё – от создания учетных записей пользователей до крупных многоуровневых развертываний приложений.

С Ansible легко выполнять автоматизацию, даже если у вас нет глубоких знаний в программировании – к примеру, вот код, который установит последнюю версию Nginx на Ubuntu/Debian:

При этом за счет множества модулей инструмент подходит для самых разных задач по автоматизации инфраструктуры – например, для создания пользователя на сервере можно использовать такой код:

С помощью Ansible многие компании решают задачи, связанные с автоматизацией. Например, используя этот инструмент, NASA уменьшило время развертывания с нескольких часов до нескольких минут, разработчик ПО ITQ Group добился более прозрачной реализации задач, Hootsuite сократил время развертывания новых сред на 90%, а BMW внедрил модель “инфраструктура как код”.

У себя в Beget тоже используем Ansible: для IaC и разворачивания софта в облаке – весь софт из панели Cloud, кроме образов операционных систем, мы устанавливаем с помощью Ansible.

Если для ваших задач тоже может быть полезен Ansible и вы хотите автоматизировать процессы сборки, тестирования и развертывания приложений в собственной инфраструктуре, у нас есть готовый кейс по автоматизированному развертыванию Gitea Runner с помощью Ansible – поделились им в отдельной статье.

Terraform

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

Основные преимущества Terraform:

✔ мультиоблачность – инструмент работает с AWS, Google Cloud, Azure и другими провайдерами;

✔ декларативный подход – вы описываете желаемый результат, а Terraform сам определяет, что нужно создать, изменить или удалить;

✔ версионирование инфраструктуры – вся инфраструктура хранится в Git, поэтому видна история всех изменений и можно легко откатиться к предыдущей версии;

✔ предварительный просмотр – команда terraform plan показывает, что именно изменится, так что не будет никаких сюрпризов в продакшене.

С Terraform можно развертывать среды за 5 минут вместо 2 дней и быстрее выкатывать новые фичи, поэтому он особенно полезен, если у вас несколько сред (dev, test, prod), необходим контроль затрат на инфраструктуру и соответствие стандартам безопасности.

Terraform оценили по достоинству многие компании – вот лишь несколько примеров:

• системный IT-интегратор Nixys использует манифесты Terraform для описания состояния инфраструктуры;

• компания Uber применяет Terraform для управления сложными мультиоблачными средами и масштабирует инфраструктуру в периоды высокого спроса;

• онлайн-банк Monzo запускает новые инфраструктурные среды за считанные минуты, а не часы;

• платформа Shopify успешно справляется с такими событиями с высоким трафиком, как “черная пятница”.

Примеры управления инфраструктурой Docker с помощью Terraform можно найти в официальной документации.

Zabbix

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

Она отлично подходит, если вам важна автоматизированная инфраструктура – Zabbix поддерживает множество протоколов и методов мониторинга (SNMP, IPMI, JMX, SSH, Telnet, ICMP, HTTP и т. д.), а также сотни готовых шаблонов для оборудования.

Примеры параметров, которые можно отслеживать в реальном времени:

► состояние серверов, сетевого оборудования, баз данных, приложений и других компонентов инфраструктуры;

► загрузка процессора;

► использование памяти;

► сетевой трафик;

► доступность сервисов;

► срок действия SSL-сертификата и т. д.

Наглядные отчеты и диаграммы помогут знать всё о работе и производительности систем, а благодаря поддержке Telegram, Discord и прочих сервисов получать оповещения максимально удобно.

Пошаговые инструкции по установке и использованию разных версий Zabbix для выполнения задач мониторинга можно найти в официальной документации.

Уже сейчас Zabbix используют более 13 тыс. компаний. Если вы тоже хотите, чтобы ваш системный администратор тревожился чуточку меньше, а мониторинг был как по нотам, то буквально в пару кликов вы можете развернуть для вашей компании собственный виртуальный сервер с Zabbix.

Kubernetes

Kubernetes aka K8s (8 – это количество букв между “k” и “s”) – это система для автоматического управления контейнеризированными приложениями. Своего рода умный дирижер оркестра, который следит, чтобы все части вашего приложения работали слаженно, а еще – автоматически заменяет “заболевших музыкантов” и добавляет новых, когда нужно сыграть иначе.

Среди сильных сторон K8s:

→ автоматическое масштабирование за несколько секунд – увеличение количества копий приложения при росте нагрузки и уменьшение при спаде;

→ самовосстановление – работа Kubernetes предполагает автоматический перезапуск упавших контейнеров и замену контейнеров при сбое серверов;

→ простое управление конфигурацией – пароли и настройки хранятся отдельно от кода, а обновление конфигураций происходит без пересборки приложения.

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

Приведем вариант использования Kubernetes.

Рассмотрим применение K8s в связке с Helm на примере одной из самых популярных баз данных “ключ-значение” – Redis.

Итак, предположим, нам нужен отказоустойчивый кластер из трех копий. Убедившись, что у нас установлен Helm и настроен доступ к кластеру, загрузим и распакуем helm chart:

helm fetch oci://registry-1.docker.io/bitnamicharts/redis

tar xf redis-21.2.7.tgz

cd redis

Затем отредактируем values.yaml, изменив параметры на:

· replica.replicaCount: количество нужных нам реплик, в данном случае 3

· sentinel.enabled: true

· sentinel.quorum: 2

После этого создадим пространство имен для кластера Redis:

kubectl create namespace redis

И установим Helm chart с названием релиза redis-cluster в пространстве имен Redis:

helm install redis-cluster ./ -n redis

Вуаля – через некоторое время поды (то есть развертываемые вычислительные единицы) успешно запустятся:

Как инструмент автоматизации процессов Kubernetes популярен среди множества компаний: Huawei, Nokia, OpenAI, Yahoo, Spotify и т. д. – подробные кейсы есть на официальном сайте.

GitHub Actions

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

Ключевые достоинства GitHub Actions:

■ автоматическое выполнение тестов, сборка и развертывание приложений;

■ интеграция с различными сервисами и платформами (AWS, Azure, Docker и др.);

■ уведомления в Slack и Telegram;

■ создание кастомных workflows для CI/CD и управление релизами;

■ гибкая конфигурация через YAML-файлы в репозитории.

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

Наглядные примеры рабочих процессов и вариантов использования GitHub Actions на русском языке можно найти в официальной документации, а в нашем маркетплейсе готовых решений для VPS есть удобный и совместимый с GitHub Actions сервис Gitea, который позволяет в короткие сроки развернуть вашу собственную платформу для разработки.

Чек-лист: что продумать при автоматизации инфраструктуры:

✹ Анализ текущего состояния – до начала работ с системами автоматизации инфраструктуры важно провести инвентаризацию всех сервисов, выявить болевые точки и оценить технический долг.

✹ Цели и приоритеты – сформулируйте измеримые цели (например, снижение времени деплоя, уменьшение инцидентов), приоритизируйте их и определите критерии успеха.

✹ Выбор инструментов – в зависимости от поставленных целей, изучите возможности инструментов (например, Terraform и Ansible для IaC, Jenkins и GitHub Actions для CI/CD, Prometheus и Zabbix для мониторинга, Docker и Kubernetes для контейнеризации).

✹ Безопасность – продумайте управление доступами и ролями, шифрование данных, аудит и логирование всех действий.

✹ Команда и компетенции – оцените текущие навыки сотрудников, подготовьте план обучения и распределите зоны ответственности.

✹ Мониторинг и метрики – важно продумать KPI для оценки эффективности, алертинг и оповещения, дашборды для визуализации, SLA и SLO.

✹ Риски – этот пункт предполагает наличие тестовых сред для экспериментов и плана Б с ручным вмешательством на случай сбоев.

✹ Бюджет – следует учесть стоимость инструментов и лицензий, затраты на обучение и ROI (то есть возврат инвестиций).

И главное – автоматизируйте только то, что уже хорошо работает вручную и делается регулярно 🙂

Заключение

Сегодня развертывание ПО больше не напоминает шаманские пляски с бубном, а контролировать серверы можно, сидя дома в уютном кресле или находясь где-то еще – и в этом могут помочь грамотно настроенные автоматизация, диспетчеризация и IT-инфраструктура.

Неудивительно, что сейчас, когда 94% компаний выполняют повторяющиеся и отнимающие много времени задачи, российский рынок автоматизированных систем управления технологическими процессами продемонстрировал рост на 50%.

Ведь автоматизация рабочих процессов позволяет сократить повторяющиеся задачи на 60–95% и в результате сэкономить до 77% времени, затрачиваемого на рутинные действия.

Согласитесь, это именно то, что нужно в современном стремительно развивающемся цифровом мире 🙂

Надеемся, этот материал был для вас полезен и автоматизация сетевой инфраструктуры принесет успех вашему бизнесу.

Если у вас остались вопросы, вы хотите обсудить эту статью или облачную IT-инфраструктуру, будем рады видеть вас в нашем уютном Telegram-чате – с удовольствием на всё ответим и пообщаемся 🙂

Если не разбираться в этих технологиях, работа Kubernetes выглядит как магия: создаешь под и вдруг у него есть собственная сеть, ограничения по CPU и память, отдельная файловая система и даже правила безопасности.

Под капотом же работают вполне конкретные компоненты ядра Linux: namespaces, cgroups, iptables/nftables, seccomp/AppArmor, OverlayFS и eBPF.

Именно они отвечают за изоляцию, контроль ресурсов, сетевые правила, безопасность и файловые слои.

Как Kubernetes использует Linux

• Namespaces изолируют процессы, сеть, файловые системы, пользователей и IPC. Именно они позволяют подам работать как будто в собственном окружении.
• cgroups управляют ресурсами: когда в поде прописаны resources.requests и resources.limits, Kubernetes через cgroups регулирует доступ к CPU и памяти.
• iptables / nftables обеспечивают сетевые возможности: от NAT для ClusterIP-сервисов до реализации сетевых политик.
• OverlayFS делает возможной архитектуру Docker-образов и быструю работу контейнеров: базовый слой остается неизменным, поверх накладывается writable-слой.
• eBPF открывает новый уровень сетевой безопасности и наблюдаемости. Например, Cilium заменяет iptables и использует eBPF для реализации политик безопасности на уровне L3–L7, а также для трассировки трафика и сервисов.

Зачем это знать

Kubernetes и Docker — это всего лишь удобные обертки над возможностями Linux.

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

Именно понимание Linux превращает Kubernetes из «магического» инструмента в предсказуемый и управляемый механизм.

А значит, вывод здесь может быть лишь один: сначала стоит разобраться в Linux и тогда Kubernetes и Docker перестанут быть магией и станут мощным инструментом в ваших руках.

Владение Django — это старт, а не финиш. Чтобы оставаться востребованным, нужно постоянно расширять знания и навыки. В этой статье разберем пути и направления для улучшения своих компетенций.

Почему владение Django — не предел для разработчика

Особенности Django

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

Основные плюсы:

• Полноценный стек: ORM для работы с базой, мощная система маршрутизации URL, шаблоны для рендеринга, встроенная админка, формы, система аутентификации и авторизации.
• Архитектура MTV (Model-Template-View): похожа на классический MVC, но с особенностями, которые упрощают разделение логики, представления и данных.
• Безопасность: Django автоматически защищает от CSRF, XSS, SQL-инъекций и других распространенных атак. Не нужно писать много дополнительного кода.
• Активное сообщество и экосистема: тысячи сторонних пакетов, расширений и готовых решений.
• Поддержка нескольких баз данных: PostgreSQL, MySQL, SQLite, Oracle и др.

Ограничения:

• Синхронная природа Django.
• Монолитность: архитектура фреймворка ориентирована на создание крупных приложений, но в микросервисах может быть избыточна.
• Ограниченная гибкость ORM: нестандартные SQL-запросы иногда сложно выразить средствами ORM, приходится использовать raw SQL или сторонние библиотеки для запросов.
• Строгие правила организации кода: требуют дисциплины и могут ограничивать свободу в архитектурных решениях.
• Недостаточная производительность: уступает лёгким асинхронным фреймворкам (например, FastAPI), особенно под высокими нагрузками. Но для большинства проектов пока это не критично.

В каком направлении двигаться после изучения Django

Задача — создавать продукт, который будет нужен конечному потребителю.

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

Возможные пути:

• Изучить другие веб-фреймворки (Flask, FastAPI)
• Углубиться в асинхронное программирование (asyncio, aiohttp)
• Работать с API и микросервисами

Flask и FastAPI

Flask — минималистичный микрофреймворк, даёт полную свободу в выборе компонентов. Используют для небольших приложений и микросервисов.

FastAPI — современный асинхронный фреймворк, ориентирован на создание высокопроизводительных API. Поддерживает стандарт OpenAPI и автоматическую генерацию документации. Он быстрее Flask и Django благодаря asyncio и Pydantic.

Асинхронное программирование

Веб-разработка всё активнее использует асинхронные технологии. Django не всегда справляется с задачами высокой конкурентной нагрузки.

Поэтому изучение asyncio — стандартной библиотеки Python для асинхронного программирования — откроет перед вами новые возможности. Вместе с aiohttp или тем же FastAPI вы сможете создавать приложения, которые обрабатывают тысячи одновременных соединений. Это особенно важно для real-time сервисов, чат-приложений и систем с интенсивным обменом данными.

Второе направление — расширить навыки в смежных областях

Можно пойти по пути расширения компетенций за пределы основной специализации. Важно не только уметь писать код, но и понимать, как приложения разворачиваются и работают в продакшене. Знание DevOps-практик помогает наладить эффективное взаимодействие между разработкой и эксплуатацией.

Изучение DevOps и контейнеризации

Контейнеры позволяют запускать приложения в изолированной среде, это упрощает настройку и развертывание. Например, Docker помогает упаковать приложение с зависимостями в один контейнер, а Kubernetes — управлять такими контейнерами в продакшене. Знание этих технологий улучшит взаимодействие с операционной командой и ускорит выпуск новых версий приложений.

CI/CD и автоматизация процессов

Непрерывная интеграция (Continuous Integration) и непрерывное развертывание (Continuous Deployment) — ключевые практики современной разработки ПО. Они позволяют автоматизировать сборку, тестирование и доставку приложений, масштабировать процессы.

Инструменты CI/CD (например, Jenkins, GitLab CI/CD, GitHub Actions) помогают настроить автоматические пайплайны, которые обеспечивают быструю обратную связь и минимизируют человеческий фактор в релизах. Автоматизация процессов снижает количество ошибок и позволяет сосредоточиться на разработке новых функций.

Настройка непрерывной интеграции и доставки (Continuous Integration / Continuous Delivery) снижает поток ошибок при релизах и экономит время. Пример: GitHub Actions для автоматического запуска тестов и сборки проекта при каждом коммите.

Больше знаний в области баз данных

Помимо классических реляционных баз данных (PostgreSQL, MySQL), современные приложения часто используют NoSQL для специфичных задач. MongoDB, Redis, Cassandra обеспечивают гибкость в хранении данных, горизонтальное масштабирование и высокую производительность при работе с большими объемами информации.

Графовые базы данных (Neo4j, ArangoDB) предназначены для эффективного хранения и анализа связей между объектами, что важно для социальных сетей, рекомендательных систем и других приложений с богатой структурой.

Так, Redis хорошо подходит для кэширования данных, а Neo4j — для сложных связей между объектами.

Третье направление — переход к другим аспектам Python-разработки

Рассмотрим четыре варианта карьерного развития для Python-программиста: Data Science и машинное обучение, автоматизация бизнес-процессов, разработка десктопных приложений и встраиваемые системы (IoT).

Почему стоит попробовать?

• Высокий спрос на специалистов. Они востребованы в банках и инвестиционных компаниях, в сфере медицины и биотехнологии, в консалтинге, автомобильной промышленности и т.д..
• Широкий набор библиотек: pandas, NumPy, scikit-learn, TensorFlow, PyTorch.
• Возможность работать с реальными задачами: от бизнеса до науки.

Автоматизация и скрипты для бизнеса

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

Знание таких библиотек, как openpyxl (работа с Excel), requests (HTTP-запросы), BeautifulSoup и Scrapy (парсинг веб-страниц), а также умение писать скрипты под конкретные задачи, делают разработчика ценным специалистом в корпоративной среде.

Примеры задач:

• Автоматическая загрузка данных из Excel и их преобразование
• Скрипты для отправки email-рассылок
• Интеграция с CRM и другими сервисами через API

Разработка десктопных приложений (PyQt, Kivy)

Хотя сейчас популярность уходит к вебу и мобильным платформам, десктопные приложения на Python востребованы в таких сферах: инструменты для анализа, редакторы, утилиты.

Инструменты для создания:

• PyQt — мощный фреймворк для создания кроссплатформенных GUI.
• Kivy — библиотека для разработки приложений с поддержкой сенсорных экранов.

Этот путь подходит тем, кто хочет создавать удобные инструменты с графическим интерфейсом для пользователей на Windows, macOS или Linux.

Встраиваемые системы и IoT

В области IoT и встроенных систем Python набирает популярность благодаря легкости освоения и поддержке на маломощных устройствах. Помогают в этом платформы по типу Raspberry Pi и MicroPython.

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

Например, с помощью Python на Raspberry Pi можно разрабатывать датчики для мониторинга состояния оборудования на производстве и разрабатывать прототипы носимых устройств для сбора данных о здоровье.

Если рассматривать профессию “Python-разработчик на Django”, то сразу получится сужение до конкретной библиотеки на конкретном языке. Если же в резюме у специалиста стоит, что он “разработчик Python”, возможностей сильно больше. Если написать про себя “разработчик”, будет не понятно, разработчик чего. Но изменив резюме на “DevOps инженера”, становится понятен карьерный трек.

Собрали пять VPS-хостингов, которые показывают, как должны выглядеть выжившие серверы под нагрузкой: современное железо, каналы без счётчиков трафика, живая поддержка инженеров и опыт клиентов. Ниже — конфигурации, цены и метрики, чтобы вы подобрали сервер под свой сценарий.

1. ИХЦ (Интернет ХостингЦентр): конфигурации под нагрузку с NVMe, CPU до 5 ГГц и трафиком без ограничений

Один из самых гибких по конфигурациям хостеров в обзоре. Работает с 2009 года. Поддерживает разные типы виртуализации (KVM и Virtuozzo), предлагает линейки с SSD и NVMe, российские и европейские площадки, разные уровни мощности — от базовых до высоконагруженных.

Линейки VPS и конфигурации

1. ssdVPS — базовая линейка для России. Позволяет собирать конфигурации от 1 до 32 ГБ оперативной памяти, от 1 до 10 виртуальных CPU и от 20 до 300 ГБ SSD-диска.
2. NVMe/ — линейка на базе KVM с более высокой производительностью ввода-вывода. Доступны конфигурации от 1 до 24 ГБ RAM, от 1 до 12 vCPU, SSD от 15 до 300 ГБ.
3. EU-NVMe/ — аналог NVMe-линейки, но размещённый в Амстердаме. Конфигурации расширены: от 1 до 64 ГБ оперативной памяти, от 1 до 18 CPU, от 15 до 1000 ГБ SSD, скорость порта — от 200 до 500 Мбит/с.
4. VPS 5 ГГц — отдельная линейка на KVM, ориентированная на проекты с высокой частотной нагрузкой, до 5 ГГц на ядро, порт до 1000 Мбит/с.

VPS Windows — выделенная категория для задач на Windows.

Особенности и инфраструктура

В ИХЦ можно выбрать между двумя видами виртуализации: KVM и Virtuozzo. Виртуализация KVM подходит для задач, где нужна изоляция ресурсов, стабильность под нагрузкой и совместимость с Linux и Windows. Virtuozzo — более экономный вариант с быстрой настройкой, но с возможной перераспределённой нагрузкой между соседними VPS.

Связь с поддержкой доступна через тикеты, онлайн-чат на сайте, телеграм-бота, телефон и сообщения ВКонтакте. Поддержка работает 24/7. На всех тарифах включена базовая DDoS-защита.

Примеры использования VPS от IHC

Компания предоставляет конкретные кейсы. Примеры:

• Проект 1: VPS NVMe/24 (24 ГБ RAM, ~200 ГБ SSD) используется под бэкенд iOS-приложения. Стек: nginx, PHP, MySQL. Нагрузка: 12 000 уникальных пользователей в сутки. Утилизация CPU — 25%.
• Проект 2: VPS NVMe/12 (12 ГБ RAM, ~120 ГБ SSD) для развлекательного сайта. Стек: nginx, Docker, Node.js. Нагрузка: 7 000 уникальных пользователей в сутки, загрузка CPU — около 20%.

Серверы стабильно держат среднюю и высокую нагрузку — даже с трафиком в 10–12 тысяч пользователей в сутки остаётся запас по ресурсам.

Дополнительные опции

ИХЦ предлагает тестовый период в 3 дня, безлимитный трафик, бесплатный первый месяц ispmanager 6 в подарок, а также предустановку панелей управления (ispmanager, FastPanel) или VPN-шаблонов по выбору при заказе. Также доступны бэкапы, SLA и автоснапшоты.

Цены

Что касается ценовой политики, стоимость VPS в России (линейка «ssdVPS») начинается от 380 руб/мес или 3800 руб/год (12 месяцев по цене 10). Европейские VPS («EU-NVMe/») и VPS на KVM («NVMe/») стартуют от 440 руб/мес или 4400 руб/год, а каждый дополнительный гигабайт памяти стоит 6 рублей.

2. FirstVDS: мощные VDS на AMD EPYC и Ryzen

FirstVDS — хостинг-провайдер с опытом на рынке более 20 лет. Предлагают VPS и VDS с виртуализацией KVM для проектов любого размера. Все серверы работают на современном оборудовании. Трижды победитель в номинации «Хостер года» Национальной премии «ЦОДы.РФ».

Есть VPS для разных сценариев нагрузки — от стандартных сайтов до тяжёлых веб-приложений и проектов с высокими требованиями к CPU и отказоустойчивости. Отдельные решения для Битрикс, установка ОС семейства Linux, FreeBSD и Windows Server.

Линейки VPS: от базовой мощности до кластера Ceph

FirstVDS предлагает три основные линейки, которые отличаются архитектурой и назначением:

1. VDS Форсаж — гибкая конфигурация сервера на базе AMD EPYC, до 128 ядер (до 3,7 ГГц), до 512 Гб оперативной памяти и до 4 000 Гб быстрого NVMe-накопителя. Локации Москва и Амстердам. Стартовая стоимость такой конфигурации составляет от 749 руб/мес.
2. Для нагруженных проектов — CPU.Турбо — гибкая конфигурация сервера на базе AMD Ryzen с частотой до 5,7 ГГц, DDR5 и с быстрыми NVMe-накопителями. Идеально для Битрикс. Локация Москва. Начальная цена CPU.Турбо — от 624 руб/мес. При покупке лицензии Битрикс (1С-Битрикс: Управление сайтом или Битрикс24) есть дополнительная скидка 30% на 3 месяца аренды этого тарифа.
3. Отказоустойчивый VDS Атлант — гибкая конфигурация сервера на базе AMD EPYC — до 192 ядер (до 3,5 ГГц), до 768 Гб оперативной памяти и до 8 Тб быстрого NVMe-накопителя. Репликация данных между узлами кластера Ceph и дублирование сетевого оборудования. Локация Москва. Его стартовая стоимость от 1619 руб/мес, при этом бесплатные автобэкапы уже включены.

Компания использует два центра обработки данных в Москве: IXcellerate (уровень Tier III) и Web DC. Для тарифа Форсаж и готовых тарифов также доступен ЦОД euNetworks (уровень Tier III) в Амстердаме.

Сетевые возможности, трафик и безопасность

В стоимость каждого сервера входит бесплатный выделенный IP-адрес. Клиенты могут выбрать между 100 Мбит/с с безлимитным трафиком или портом 1 Гбит/с с включёнными 32 Тб трафика.

Защита от DDoS-атак и система безопасности BitNinja для сервера и сайта доступны как подключаемые опции. Также предоставляются объектное хранилище S3, автобэкапы и Кибер-бэкап. Для безопасности коммуникаций используются SSL-сертификаты GlobalSign.

Управление, ПО и поддержка

При заказе сервера клиент получает лицензию ispmanager 6  lite: первый месяц панель предоставляется бесплатно, дальше оплачивается по тарифу самой панели. Предлагается гибкий выбор операционных систем, включая Linux, FreeBSD и Windows Server. Под разовые задачи доступны готовые рецепты установки — от Битрикс и GitLab до TeamSpeak, LAMP‑стека и других популярных наборов ПО.

Для установки и решения любых вопросов — доступна живая круглосуточная техническая поддержка 24/7 через чат на сайте, в личном кабинете и по телефону, без использования чат-ботов. Для самостоятельного решения вопросов предусмотрена обширная база знаний.

Клиентские бонусы и программы

Есть тестовый период до 3 дней. Регулярно проводятся акции и предоставляются скидки, в том числе на тарифы для нагруженных проектов.

1) При переходе от другого хостера FirstVDS бесплатно переносит до 10 сайтов. Дополнительно предоставляется скидка 40% на первый месяц аренды VPS при оплате сервера на 1, 3 или 6 месяцев, либо 3 месяца бесплатной аренды VPS при оплате на год.

2) Клиенты с возрастом аккаунта от 5 лет получают постоянную скидку на аренду VPS, начиная от 5% и увеличиваясь ежегодно до 20%.

3) Действует реферальная программа, по которой партнёр получает 10% от расходов привлечённых клиентов, а привлечённый пользователь — скидку 25% на первый месяц аренды VPS.

4) Стоимость продления домена у FirstVDS равна актуальной стоимости его регистрации.

3. InCloud: VPS‑площадки для бизнеса, где важен SLA

InCloud продаёт виртуальные серверы, работающие в отказоустойчивом кластере на базе enterprise хранилищ NetApp и HPE 3PAR. Позиционируется как решение для 1С, малого/среднего бизнеса и аутсорс компаний, которым нужны предсказуемые ресурсы и техподдержка профессиональных инженеров, а не чат‑ботов.

Тарифные планы и ценообразование

InCloud предлагает две основные линейки тарифов:

1. Стандартный тариф: внутри процессоры Intel Xeon 2600v4 2ГГц и оперативная память DDR4 2400 МГц.Стоимость: 1 CPU – 200 рублей, 1 Гб RAM – 200 рублей.
2. Производительный тариф: использует процессоры AMD EPYC до 3.8 ГГц и оперативной памяти DDR5 4800 МГц. Стоимость: 1 CPU – 250 рублей, 1 Гб RAM – 250 рублей.

Стоимость дискового пространства: SATA диски: 3 рубля за 1 Гб. SSD и NVMe диски: 13 рублей за 1 Гб.

Архитектура и поддержка

Теперь про то, что упрощает жизнь и добавляет надежности нашим развернутым сервисам:

• Ежедневные бэкапы: данные ваших серверов будут копироваться каждый день, и храниться они могут до 30 дней.
• Удобная панель управления: через нее можно делать снапшоты и клонировать серверы. Для разработчиков это просто золото – быстро накатить тестовую среду, попробовать новую фичу, а потом откатиться или создать идентичные рабочие среды.
• SLA-договор: есть возможность заключить SLA-договор, чтобы получить гарантированный уровень доступности услуг.
• Новейшие мощные серверы — на базе AMD EPYC 4 поколения.

Одна из фишек – это возможность напрямую проконсультироваться с сертифицированными инженерами InCloud по сложным проектам.

А что с клиентскими кейсами

1. Кейс Vamkamin: производственная компания, которая ускорила работу своей системы 1С и сократила IT-расходы на 35%. У них была проблема с медленной работой 1С при одновременном доступе бухгалтерии, склада и отдела продаж, а также с частыми простоями на локальных серверах. InCloud предложил перенести все сервисы в облако, используя серверы на базе AMD EPYC 9554, что обеспечило прирост производительности более 40% по сравнению с предыдущими решениями. Также были внедрены гибкое масштабирование ресурсов и ежедневное резервное копирование.
2. Кейс Веб-студии 100UP: компания занимается разработкой и поддержкой сайтов для крупных торговых сетей и e-commerce проектов. 100UP переехала к облачному провайдеру InCloud, выбрав тарифы на базе AMD EPYC 9554 с высокой тактовой частотой и большим количеством ядер. Благодаря разнообразию тарифов команда легко распределила проекты по нужным по производительности виртуальным серверам. После переезда 100UP смогла сократить время отклика клиентских сайтов в среднем на 45%, обеспечить бесперебойную работу даже в периоды высокой сезонной нагрузки, ускорить запуск новых проектов, фокусироваться на разработке и маркетинге и улучшить качество предоставляемых услуг.

4. SmartApe: быстрые VPS на NVMe‑SSD

SmartApe подойдет проектам, где дисковая подсистема и CPU работают без простоя: интернет‑магазины, порталы с большим количеством контента, внутренние корпоративные системы, высоконагруженные API. Если нужен быстрый старт — сервер создаётся за одну‑две минуты; если понадобится масштабирование, тариф можно увеличить без миграции.

Преимущества этих VPS

Используются современные серверные NVMe SSD диски в RAID массиве, которые в 600 раз быстрее обычных HDD. Скорость чтения достигает 8000 Мбайт/с, а записи — 2000 Мбайт/с.

Серверы работают на мощных процессорах Intel Xeon Gold или AMD EPYC (до 3.7 ГГц) и быстрой памятью DDR4. Используется полноценная виртуализация KVM с выделенными ресурсами для гарантии их предоставление. Дата-центры уровня TIER-III и TIER-IV обеспечивают Uptime 99.982%. Данные хранятся в хранилище RAID-10.

Дополнительно клиенты получают полный root-доступ (по SSH для Linux и RDP для Windows), возможность установки любых операционных систем (более 20, включая Ubuntu, CentOS, Debian, Windows Server) и ПО, а также полную изоляцию от других клиентов.

Удобство и поддержка

• Бесплатная панель управления (Hestia) или платная ISPmanager для простого управления сервером.
• Бесплатное базовое администрирование и помощь в переносе сайтов.
• Круглосуточная квалифицированная поддержка 24/7.
• Бесплатный тестовый период 10 дней без оплаты и ввода карты.
• Защита от DDoS-атак включена в стоимость.
• Выделенный внешний IP-адрес (возможность купить до 10 IP).

Перед покупкой дают десять дней теста без привязки карты; если сервис не подойдёт, в течение тридцати дней можно вернуть деньги за неиспользованный период.

Пример использования: интернет‑магазин

VPS c 2 vCPU, 4 ГБ RAM, 80 ГБ SSD и портом 100 Мбит/с; при обычном трафике сайт обслуживает 300–500 уникальных посетителей в день, одновременно на страницах бывает 10–20 человек, а в пиковую распродажу до 50; средняя нагрузка 5–10 запросов в секунду, короткими всплесками до 20; заявленный аптайм 99,982 %, реальные замеры отклика после кэширования — 200–300 мс; счёт за такой сервер выходит около 1 300 рублей в месяц.

Пример использования: API на Node.js

4 vCPU, 8 ГБ RAM, 160 ГБ NVMe и канал 200 Мбит/с; сервис стабильно обрабатывает 50–100 запросов в секунду, на пике достигает 200, одновременно подключены 500–1 000 клиентов, максимум 2 500; трафик близок к 200 ГБ в месяц; при том же аптайме 99,982 % средняя задержка ответа укладывается в 50–100 мс; ежемесячная стоимость в зависимости от опций колеблется в диапазоне 2 600–3 000 рублей.

SmartApe имеет смысл брать, когда дисковая скорость и гарантированные ресурсы важнее высокого GUI и почасовой тарификации, для расчёта стоимости есть калькулятор конфигураций на сайте и оперативная техподдержка.

5. PSB Hosting: что даёт их VPS‑платформа

PSB Hosting продвигает VPS-хостинг как решение для сайтов, приложений и SaaS-сервисов, которым нужна предсказуемая мощность и высокий SLA. Провайдер делает упор на новое оборудование, пропускную способность без ограничений и инфраструктуру уровня Tier III+.

Локации и тарификация

Серверы разворачиваются в четырёх точках: Нидерланды, США, Германия и Финляндия. Для каждой площадки доступен одинаковый конструктор конфигураций. Базовый план NL‑100, который включает 1 vCPU, 2 ГБ RAM и 30 ГБ SSD, стоит 6 долларов в месяц. Линейка поднимается ступенчато:

Слайдеры позволяют довести параметры до 32 ядер, 64 ГБ RAM и 510 ГБ SSD; верхняя планка оплаты — 220 $ в месяц.

Трафик безлимитный на любых конфигурациях — дополнительной оплаты за гигабайты нет.

Аппаратная платформа, ОС и предустановки

В хост-узлах применяются процессоры последних линеек AMD и Intel. Оперативная память — DDR5, что снижает задержки при обращении к ОЗУ. Дисковая подсистема полностью на NVMe, объединена в RAID 10: чтение и запись выше, чем у классических SSD, а отказ одного накопителя не выводит хранилище из строя. К каждому VPS подключён выделенный канал с пропускной способностью до 10 Гбит/с.

Сервер можно поднять сразу с Windows Server, Ubuntu, Debian, CentOS или FreeBSD. Для быстрого старта доступны готовые образы: Bitrix, Django-стек, Docker, FastPanel, Hestia CP, Keitaro, LAMP, Node, OpenVPN, Outline, Portainer, Vesta CP и другие.

Управление и поддержка

Провайдер обещает круглосуточную техническую поддержку, резервные копии (бэкапы) и автоснапшоты. Для автоматизации предусмотрен API; в панели управления можно масштабировать ресурсы, перезагружать сервер и следить за статистикой.

Как выбрать VPS под свой проект

Для сайта с пиковыми нагрузками подойдёт SmartApe, где дисковая подсистема на NVMe-SSD в RAID-10 обеспечивает скорость чтения до 8000 Мбайт/с и записи до 2000 Мбайт/с, а сайт на конфигурации с 2 vCPU, 4 ГБ RAM и 80 ГБ SSD выдерживает 300–500 уникальных посетителей в день с пиком до 50 одновременных пользователей и нагрузкой 5–10 запросов в секунду (короткими всплесками до 20).

Если проект включает высоконагруженный API, например, на Node.js, то оптимален SmartApe с конфигурацией 4 vCPU, 8 ГБ RAM и 160 ГБ NVMe, которая стабильно обрабатывает 50–100 запросов в секунду (пики до 200) при 500–1000 одновременных подключениях (максимум 2500) и трафике до 200 ГБ в месяц.

Для задач с 1С, где важна стабильность и сокращение IT-расходов, выбирайте InCloud на базе AMD EPYC 9554: в кейсе Vamkamin это ускорило работу системы на 40%, сократило расходы на 35% и минимизировало простои, с ежедневными бэкапами до 30 дней и SLA-договором.

Если нужен VPS для Битрикс с высокой частотой CPU, подойдёт FirstVDS на AMD Ryzen (CPU.Турбо) с частотой до 5,7 ГГц и DDR5: скидка 30% на 3 месяца при покупке лицензии Битрикс, плюс отказоустойчивость на кластере Ceph с репликацией данных.

Для веб-студий с разработкой и поддержкой сайтов для e-commerce, где требуется распределение проектов по производительности и бесперебойная работа в сезонные пики, подойдёт InCloud на AMD EPYC 9554: в кейсе 100UP это сократило время отклика на 45% и обеспечило стабильность под высокой нагрузкой.

Если проект ориентирован на международный трафик с предсказуемыми ресурсами и высоким SLA, выбирайте PSB Hosting с локациями в Нидерландах, США, Германии или Финляндии, безлимитным трафиком и каналом до 10 Гбит/с на DDR5 и NVMe в RAID 10.

Для бэкенда мобильного приложения с нагрузкой до 12 000 уникальных пользователей в сутки (утилизация CPU 25%) подойдёт ИХЦ на NVMe/24 с 24 ГБ RAM и ~200 ГБ SSD, стеком nginx, PHP, MySQL.

Если развлекательный сайт с более чем 5000 уникальных пользователей в сутки (загрузка CPU ~20%), то подходит ИХЦ на NVMe/12 с 12 ГБ RAM и ~120 ГБ SSD, стеком nginx, Docker, Node.js. Он обеспечит стабильность с безлимитным трафиком и DDoS-защитой.

Выбор сводится к трём вопросам: где ваши
пользователи, какую пиковую нагрузку вы ждёте и нужен ли формальный SLA.
Сформулируйте эти требования заранее — и любой из пяти хостингов закроет задачу
без проблем в продакшне. Добавить свои рекомендации VPS хостингов — вы всегда
можете в комментариях, желательно описывать короткие кейсы.

1. Yonote

Yonote — российская база знаний и система для работы с проектами. Помогает командам и отдельным пользователям собирать и систематизировать информацию, вести базы знаний, планировать проекты и обмениваться документами. Платформа сочетает гибкий интерфейс, как в Notion, и функциональность KMS-систем: блочный редактор, доски, таблицы и базы данных работают в одном окне. Отличие Yonote — бесконечные доски для визуального планирования, поддержка on-prem-развёртывания и хранение данных в России.

Сценарии использования

Yonote подходит для:

• Командной работы: планирование задач, контроль
  сроков, управление проектами, CRM, сбор и визуализация отчётов, хранение
  инструкций и регламентов.
• Личных целей: заметки, трекер задач,
  бюджетирование, планирование поездок, учёба и хранение материалов.
• Создания Wiki: организация базы знаний о
  продукте с древовидной структурой, вставкой таблиц, диаграмм и медиа, историей
  изменений и комментариями.
• Ведения
  документации: базы данных по
  клиентам, проектам и инвентарю с таблицами, фильтрами, канбан-досками и
  календарями, прикреплением файлов и ссылок.

Формат работы

Yonote работает через web-интерфейс с удобным Markdown-редактором, поиском и историей изменений. Можно встраивать код, схемы и embed-ссылки из GitHub, Figma, Miro и других сервисов.

Поддерживается полный доступ по API, импорт и экспорт в Markdown и PDF, хранение на своих серверах (on-prem) и в облаке. Yonote предлагает более 30 интеграций, включая GitHub, Jira, Trello, Telegram, Miro и Airtable. Настраиваются уровни доступа: можно создавать гостевые аккаунты, разграничивать права на чтение и редактирование, делиться публичными ссылками.

Yonote заменяет несколько инструментов сразу (Trello, Google Docs, Confluence, личные заметки), легко адаптируется под любые задачи, подходит для госорганизаций, частных компаний и личного использования.

Тарифы

• Базовый — бесплатно, 5 ГБ, до 5 пользователей и 10 гостей.
• Старт — 149 ₽ за пользователя в месяц, 20 ГБ, до 50 гостей.
• Про — 249 ₽ за пользователя в месяц. Доступен безлимит гостей, неограниченное хранилище, SSO.
• Enterprise — тариф для организаций с расширенной поддержкой и контролем.

2. Anytype

Anytype — «приложение для всего», которое предлагает создать собственную локальную сеть для хранения знаний, заметок, трекеров привычек, рецептов и канбан-досок. По принципу работы похоже на Notion: блоковая структура, гибкие базы данных и визуальные представления информации.

Главное отличие — Anytype полностью локален и использует P2P-синхронизацию без серверов и посредников, данные остаются только у вас, никто не имеет к ним доступа. Приложение с открытым кодом и доступной архитектурой, работает без интернета и требует установки на устройство.

Сценарии использования

Личные цели: создание ежедневников, трекеров привычек, расписаний, конспектов, ведение стратегических заметок в одном месте, даже без подключения к интернету.

Работа в команде: организация командных вики и канбан-досок, совместная работа в группах, ведение календарей.

Сообщество и креатив: управление блогом, создание лент-контента, рекомендаций и курируемых подборок, построение сообщества с объявлениями и вики-страницами.

Формат работы

Anytype работает офлайн на мобильных и десктопных устройствах (iOS, Android, Windows, macOS, Linux), без веб-версии. Скоростная P2P-синхронизация возможна через локальные сети.

Интерфейс основан на визуальном код-фри (no-code) редакторе: можно создавать базы данных, таблицы, канбаны, галереи и граф-связи между объектами.

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

Для разработчиков:

• Поддерживает локальное хранение данных и самостоятельный бэкап в любое место по выбору пользователя.
• Нет API в привычном виде, но возможно расширить функциональность за счёт открытого кода и протоколов.
• Настройки доступа гибко регулируются на уровне устройства, команды и отдельных объектов в приложении.

Цена и условия пользования

• Explorer — бесплатно, подходит для личного использования.
• Builder — $99 в год за пользователя, открывает расширенные функции и поддержку командной работы.
• Co-Creator — $299 в год за пользователя, с расширенными возможностями и дополнительной свободой кастомизации.

Весь интерфейс и работа — на английском языке.

3. Obsidian

Obsidian — это бесплатное и гибкое приложение для ведения заметок, личных знаний и проектного управления. Поддерживает базы знаний, связи между заметками, визуализацию в графах и публикацию вики. Главная особенность — работа локально на устройстве с хранением заметок в открытых форматах Markdown, без принудительной привязки к облаку. Обеспечивает полную приватность и контроль над данными, даже оффлайн.

Сценарии использования

Есть несколько сценариев:

• Личные заметки и дневники: быстрый доступ к записям на устройстве, структурирование мыслей, создание связей между идеями.
• База знаний и обучение: построение персональных вики с перекрёстными ссылками, графами связей и быстрым поиском.
• Управление проектами и исследованиями: создание канбанов и карт идей в Canvas для планирования и брейншторминга, публикация заметок для команды

Формат работы

Obsidian — десктопное и мобильное приложение (Windows, macOS, Linux, iOS, Android). Доступны следующие форматы:

1. Поддержка открытых форматов файлов (Markdown), которая обеспечивает долгосрочное хранение данных без зависимости от сервиса.
2. С помощью Obsidian Publish можно публиковать заметки как публичную вики, документацию с настраиваемым внешним видом и быстрым поиском.

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

Есть поддержка истории версий и работы с командой в рамках общих хранилищ, при этом приватность отдельных файлов сохраняется.

Цена и условия пользования

• Бесплатно: использование приложения для личных нужд, хранение данных локально.
• Sync — $4 в месяц за пользователя при оплате за год, синхронизация заметок между устройствами с шифрованием, история версий, совместная работа в общих хранилищах.
• Publish — $8 в месяц за сайт при оплате за год, публикация заметок на сайт без технических знаний, настройка тем и структуры.

4. Gramax

Gramax — платформа для подготовки документации в подходе Docs as Code. Позволяет создавать и редактировать статьи в визуальном редакторе, хранить исходники в Markdown и версионировать их с помощью Git. Подходит для тех, кто хочет управлять документами, знаниями и любым другим контентом в своей инфраструктуре гибко и безопасно.

Как и в Notion, в Gramax есть совместное использование, комментарии и AI-функции (создание и форматирование текста, перевод, поиск по статьям). Отличие — в Git‑first подходе, открытом коде и возможности использовать платформу бесплатно без ограничений.

Сценарии использования

Gramax особенно полезен для:

• Документации по продукту: создание портала с инструкциями, оформленного в корпоративном стиле, с быстрым обновлением и AI-поиском.
• Внутренней проектной документации: база знаний с версиями, Merge Request, поддержкой OpenAPI и технических требований.
• Базы знаний для команд: хранение описаний процессов и систем с удобным поиском и доступом через Git.

Формат работы

Gramax делится на:

• Редактор: web и десктоп на Win/Mac/Linux, можно использовать офлайн.
• Git-хранилище: подключается GitLab, GitHub, Bitbucket и другие, команды Git встроены в интерфейс.
• Портал документации: разворачивается как статический сайт или через Docker.

Для разработчиков есть поддержка диаграмм (Mermaid, Draw.io, PlantUML), подсветка кода (100+ языков), механизм сравнения версий, мультиязычность. Также на портале для чтения можно отображать документацию на разные версии ПО.

Gramax также поддерживает API для передачи данных в сторонние системы и CLI для интеграции в CI/CD, позволяя автоматически собирать документацию в HTML, PDF и DOCX. Есть импорт из Confluence, Notion и Yandex Wiki, экспорт в DOCX и PDF с фирменным стилем.

Цена и условия

• Open Source — бесплатно, без ограничений. Управление доступом на уровне репозиториев.
• Gramax Enterprise Server — 54 000 ₽ за редактора навсегда, первый год обновления бесплатно, далее 40% от лицензии. Управление доступом — по ролям и группам с SSO и корпоративными политиками.

5. KMS Gran

KMS Gran — база знаний с API и выстроенными бизнес-процессами. Помогает создавать и структурировать проектную документацию, управлять знаниями в команде и автоматизировать рутину. Платформа сочетает возможности вики, систем управления документами, визуальных блок-схем и AI-инструментов для поиска и анализа.

Как и в Notion, в KMS Gran есть WYSIWYG-редактор, мобильная версия и AI для работы с текстом. Отличие в том, что на платформе есть модуль «Скриптинг» для построения процессов и гибкая система прав доступа. Подходит командам, которым важно хранить данные локально и быстро строить рабочую рутину.

Сценарии использования

• Вики по продуктам и техдокументация. Доступно создание структурированных статей, глоссариев, руководств и спецификаций. Удобный поиск с морфологией и AI-помощником помогает находить информацию, а кириллица поддерживается корректно.
• Автоматизация бизнес-процессов. С помощью модуля «Скриптинг» можно строить визуальные блок-схемы процессов, задавать условия и добавлять к шагам инструкции и файлы. Подходит для команд поддержки и контакт-центров.
• AI-помощник для пользователей. Индексирует статьи и отвечает на вопросы по проектам с указанием источников. Сохраняет контекст диалогов, позволяет оценивать ответы и формирует отчеты для анализа востребованности контента.

Формат работы

KMS Gran работает через web-интерфейс с удобным WYSIWYG-редактором, поддерживающим Markdown, и адаптирован под мобильные устройства. В системе доступен полнотекстовый поиск с морфологией и возможностью получать ответы от AI, а также версионирование с откатом и архивацией статей. Для согласования внутри команды предусмотрена отметка о прочтении. В документы можно вставлять код и схемы через интеграцию с Draw.io, но подключение embed-ссылок из GitHub и Figma не поддерживается.

Платформа поддерживает работу через API для интеграции с внешними системами, хотя CLI в ней не предусмотрен. Можно настроить подключение к Slack, GitHub, CI/CD и Jira через API. Гибкая система управления доступом позволяет задавать роли как на уровне всей системы, так и в отдельных проектах и разделах, а также управлять доступом к разным документам.

Цена и условия

• SaaS: аренда по подписке, ежемесячная оплата за пользователя. Включены базовый функционал, серверные ресурсы и поддержка 9×5, опционально AI-модуль.
• On-Premise: развёртывание у заказчика, лицензия на длительный срок, поддержка AI-модуля и техподдержка.
• AI-модуль доступен как в SaaS, так и On-Premise.

Условия зависят от объема лицензий, срока использования и набора функций, обсуждаются индивидуально. Все тарифы включают базовый функционал.

Как выбрать платформу для базы знаний

Выбор платформы зависит от ваших задач. Для удобства собрали таблицу с особенностями платформ.

Таким образом:

Если приоритет — работа с документацией как с кодом, версионирование и публикация через Git — ваш выбор Gramax.

Нужна визуализация, работа с таблицами, досками и интеграции для команды — стоит обратить внимание на Yonote.

Если вы ищете корпоративное решение с AI, разграничением прав доступа и встроенными процессами — подойдёт KMS Gran.

Anytype или Obsidian подойдут тем, кто ценит контроль над данными и гибкость кастомизации.

Рассказываем про 7 команд, влияющие на скорость работы в терминале. Вы узнаете:

• про встроенные bash-операции, которые заменяют пайплайны,
• про способы работы с файловыми дескрипторами,
• про wildcards, которые избавляют от сложных конструкций с find.

Каждая команда в подборке решает конкретную проблему:

• массовая обработка файлов,
• отладка скриптов,
• работа с длинными путями.

1. Bash variable expansions

Вместо basename, cut для простых операций со строками можно использовать встроенные возможности Bash:

% режет справа до первого совпадения, %% — до последнего. Символ # работает слева направо.

В реальной работе это помогает при массовой обработке файлов. Например, есть 1000 логов, и нужно каждый переименовать.

Если использовать basename, запустится 1000 отдельных процессов. Variable expansions работают без fork/exec, без задержек на создание процессов.

Bash variable expansions используют в циклах с файлами и при работе с массивами. Когда скрипт обрабатывает сотни файлов, разница в скорости становится заметной. Еще и код выглядит чище.

2. Here-string (<<<)

Here-string упрощает передачу строковых данных в команды без создания временных файлов или использования echo с пайпом.

Реальная экономия времени проявляется при отладке и модификации скриптов. Например, когда SQL-запрос или конфигурация зашиты в here-документ. С here-string данные собраны в одном месте, легко редактируются и переиспользуются.

Работает не только с базами данных. Отправка в API, конфигурирование сетевых устройств через expect, передача команд в Docker — через <<< код будет понятнее, а сопровождение проще.

3. /proc/$$/fd

Каждый процесс имеет стандартные дескрипторы 0 (stdin), 1 (stdout), 2 (stderr), которые представлены как символические ссылки. Директория /proc/$$/fd предоставляет доступ к файловым дескрипторам текущего процесса:

Переменная $$ содержит PID текущего процесса, поэтому /proc/$$/fd ведет к дескрипторам именно вашего шелла.

Практическое применение — отладка перенаправлений и работа с дескрипторами в сложных скриптах:

4. Wildcards с диапазонами

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

Wildcards автоматически раскрываются шеллом в список подходящих файлов — это их основная функция. Кавычки нужны только когда передаете символы [, ] как литеральные:

Экономия времени заметна при работе с логами, бэкапами и в скриптах автоматизации. Например, для архивации файлов с определенными номерами, очистки временных файлов с нужными паттернами.

5. sudo !!

Набрали длинную команду, нажали Enter, получили «Permission denied». Рука на рефлексе тянется к стрелке вверх и Home, чтобы добавить sudo в начало.

Вот способ в разы быстрее:

Двойное восклицание !! — это ссылка на предыдущую команду целиком. Bash подставит всю строку со всеми аргументами и ключами. Кажется мелочью, но для админа, который 10 раз в день забывает sudo, это серьезная оптимизация.

Двойное восклицание универсально и работает не только с sudo:

• time !! для замера времени выполнения,
• nohup !! & для запуска в фоне,
• strace !! для отладки.

Если между командой и sudo !! выполнялись другие команды, восклицание сработает для последней из них. Для поиска конкретной команды в истории используйте !строка.

6. ^старое^новое

Основной способ исправления опечатки — стрелка вверх, поиск ошибки, исправление. Смотрите, как можно сделать это побыстрее:

Символ ^ ищет первое вхождение слова и заменяет его. Работает с последней командой.

Заменяется только первое вхождение. Если ошибочное слово встречается несколько раз, способ не сработает. В таких случаях придется использовать классическое редактирование или history expansion.

7. Alt+.

Создали файл с длинным именем — теперь его нужно отредактировать, переместить, изменить права. Каждый раз перепечатывать путь утомительно и чревато ошибками.

Комбинация Alt+. (Alt + точка) вставляет последний аргумент предыдущей команды в текущую позицию курсора. Повторное нажатие перебирает аргументы из более ранних команд.

Экономия времени проявляется при работе с файлами и директориями. Например: распаковали архив, теперь нужно зайти в созданную папку, затем посмотреть содержимое, потом изменить права. Вместо того, чтобы 3 раза печатать один путь, можно 3 раза нажать Alt+.

Еще этой комбинацией вставляются:

• имена пользователей,
• IP-адреса,
• названия сервисов,
• параметры конфигурации.

Alt + точка работает в большинстве шеллов. Привыкнув к ней, начинаешь использовать на автомате.

Что запомнить

• ${filename%.*} и встроенные операции со строками работают быстрее внешних утилит. % режет справа, # — слева. Полезно при работе с циклами для массовой обработки файлов.
• <<< — here-string удобен для передачи коротких строковых данных в команды. С многострочными данными лучше использовать here-document или переменные.
• /proc/$$/fd — доступ к файловым дескрипторам текущего процесса. Ускоряет отладку перенаправлений и работу с дескрипторами.
• file[1-5] и [^b]* — диапазоны в wildcards для точного отбора файлов. Кавычки нужны только для передачи литеральных символов.
• sudo !! — повторяет последнюю команду с sudo. Также работает с time !!, nohup !! &. Если между нужной командой и !! выполнялись другие операции, используйте !строка для поиска конкретной команды в истории.
• ^старое^новое — заменяет первое вхождение в предыдущей команде. Работает только с последней командой и заменяет первое совпадение.
• Alt+. — вставляет последний аргумент предыдущей команды. Повторное нажатие перебирает аргументы из истории команд. Экономит время при работе с длинными путями.

Теперь они предлагают решения, которые не хуже, а где-то даже и лучше международных аналогов и по надёжности, и по цене.

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

1. FirstVDS: профессиональные решения для любых проектов

FirstVDS — хостинг-провайдер с опытом на рынке более 20 лет. Предлагают VPS и VDS с виртуализацией KVM для проектов любого размера. Все серверы работают на современном оборудовании. Трижды победитель в номинации «Хостер года» Национальной премии «ЦОДы.РФ».

Хостинг подойдет бизнесу любого масштаба: для любых сайтов — от визиток до высоконагруженных интернет-магазинов, для разработки и тестирования, для сервисов и других проектов. Отдельные решения для Битрикс, установка ОС семейства Linux и Windows Server.

Особенности хостинга

Надёжность

FirstVDS обеспечивает аптайм 99,97–99,99% в 2025 году, подтверждённый замерами (например, отклик из Москвы — 27 мс в апреле 2025). Серверы размещены в трёх дата-центрах уровня Tier III: два в Москве (IXcellerate и Web DC) и один в Амстердаме (euNetworks). Отказоустойчивый кластер Ceph гарантирует работу даже при сбоях точки или канала.

Инфраструктура

Серверы работают на процессорах Intel Xeon и AMD EPYC (до 5,7 ГГц в линейке CPU.Турбо), с быстрыми NVMe-дисками объёмом до 8 ТБ и оперативной памятью DDR5 (до 768 ГБ в VDS Атлант). Это обеспечивает высокую производительность для ресурсоёмких задач, таких как Битрикс или высоконагруженные приложения.

Гибкость

Тарифы масштабируются: от базовых конфигураций (1 CPU, 1 ГБ RAM, 40 ГБ SSD) до мощных серверов (192 ядра, 768 ГБ RAM, 8 ТБ NVMe). Линейки:

• VDS Форсаж: AMD EPYC, до 128 ядер, 512 ГБ RAM, 4 ТБ NVMe, от 749 ₽/мес (Москва/Амстердам).
• CPU.Турбо: AMD Ryzen до 5,7 ГГц, DDR5, от 624 ₽/мес (Москва).
• VDS Атлант: отказоустойчивый, до 192 ядер, 8 ТБ NVMe, от 1619 ₽/мес (Москва).
• VDS Storage: хранилище, от 704 ₽/мес (Москва).Горячее масштабирование (hot-resize) позволяет добавлять CPU, RAM или диск без перезагрузки.

Автоматизация

Шаблоны для быстрого развёртывания: Django, Redmine, Tomcat, Teamspeak, Nextcloud, LAMP, LEMP, Forgejo Git, GitLab, Битрикс. Поддерживаются ОС Linux (Ubuntu, Alma, Debian, Rocky, CentOS, Oracle), FreeBSD, Windows Server. API и панель ispmanager 6 lite (бесплатно на месяц) упрощают управление.

Безопасность

Включена защита от DDoS-атак на сетевом уровне, BitNinja для защиты сервера и сайта, SSL-сертификаты GlobalSign. Доступны автобэкапы, снапшоты, Кибер-бэкап и объектное хранилище S3 для больших данных.

Поддержка

Круглосуточная поддержка 24/7 без чат-ботов, ответ до 15 минут через чат, личный кабинет или телефон. Бесплатно: помощь с активацией и первичной настройкой. Платно: установка ПО, администрирование. Экспертная линия для мониторинга и устранения сбоев.

Бонусы

• Тестовый период 3 дня.
• Бесплатный перенос до 10 сайтов с другого хостера.
• Скидки: 40% на первый месяц при оплате на 1/3/6 месяцев или 3 месяца бесплатно при оплате за год.
• Лояльность: скидка 5–20% для клиентов от 5 лет.
• Реферальная программа: 10% от расходов привлечённых клиентов для партнёра, 25% скидка для нового пользователя на первый месяц.
• Домены: продление по цене регистрации.

Тарифы и условия

Тестовый период 3 дня, после него подключаете один из основных тарифов:

• Линейка готовых конфигураций от 1 CPU, 1 Гб RAM, 40 Гб SSD-накопителя и от 219 руб/мес. до сервера с 8 CPU, 12 Гб RAM, 150 Гб NVMe-накопителя. Локация в РФ и Нидерландах.
• VDS Форсаж: на AMD Epyc от 749 ₽/мес. Локации: РФ и Нидерланды.
• CPU.Турбо: гибкая конфигурация на базе высокочастотных AMD Ryzen 9 от 624 ₽/мес. При покупке лицензии Битрикс дополнительная скидка 30% на 3 месяца аренды CPU.Турбо. Локация в РФ.
• VDS Атлант: отказоустойчивый с автобэкапами от 1 619 ₽/мес. Локация: РФ.
• VDS Storage: сервис как хранилище с гибкой конфигурацией от 704 ₽/мес. Локация: РФ

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

2. UltraVDS: для малого бизнеса и стартапов

Компания UltraVDS, провайдер услуг виртуальных серверов (VPS/VDS), работает на рынке с 2014 года — предлагает решения для разных операционных потребностей. Сервисы UltraVDS можно использовать для развертывания торговых роботов, запуска чат-ботов, хостинга веб-сайтов, а также для создания FTP-хранилищ данных. Есть предложения для фрилансеров, цифровых агентств, корпоративных пользователей и стартапов, которым требуются функциональные инфраструктурные решения.

Технические особенности

Серверы UltraVDS размещены в современном дата-центре, расположенном в Москве. Доступность сервиса (аптайм) составляет 99,98%, что обеспечивает высокую стабильность работы. Сетевая пропускная способность превышает 200 Мбит/с, при этом трафик предоставляется без ограничений.

Система защиты от DDoS-атак способна обрабатывать трафик до 1,5 Тбит/с и поддерживает стабильность работы сервера даже при интенсивном внешнем воздействии. Лицензия на Windows Server входит в стоимость обслуживания в данном предложении. Это упрощает развертывание сервера: вам не нужно отдельно покупать и устанавливать лицензию. Плюс снижает общие операционные расходы для пользователей этой операционной системы.

Тарифные планы

Для новых пользователей UltraVDS предусмотрена возможность 3-дневного тестового периода, позволяющего оценить функциональность и производительность сервиса.

После тестового периода стоимость тарифов начинается от 119 рублей в месяц. На сайте доступен онлайн-калькулятор, позволяющий подобрать конфигурацию сервера и рассчитать итоговую стоимость.

Клиентам доступны различные варианты оплаты, включая ежемесячную систему без предоплаты. При авансовой оплате на период от 3 до 12 месяцев предоставляются скидки до 20%, размер которых зависит от выбранного срока. В случае досрочного прекращения использования сервиса, неиспользованный остаток средств возвращается на баланс пользователя.

Поддержка и обслуживание

Техническая поддержка UltraVDS работает круглосуточно, 7 дней в неделю. Среднее время ответа на запросы составляет до 15 минут. Связь со службой поддержки возможна по электронной почте и телефону, указанным на официальном сайте.

3. RUVDS: 10 лет на рынке облачных решений

RUVDS — облачный провайдер, имеющий десятилетний опыт работы на рынке услуг виртуальных серверов (VPS/VDS). Является официальным партнером Huawei в России, работает по SLA. Компания предоставляет инфраструктурные решения, которые могут быть применены для широкого спектра задач, включая хостинг высоконагруженных интернет-магазинов, корпоративных порталов, игровых серверов, сложных backend-систем и чат-ботов.

Платформа RUVDS спроектирована для оптимизации процесса развертывания ресурсов. Одной из ее особенностей является маркетплейс, который позволяет быстро запускать серверы с предустановленным программным обеспечением. Это способствует ускорению старта проектов, снижая потребность в ручной настройке распространенных CMS, игровых серверов и сред разработки.

Тарифная политика и варианты оплаты

RUVDS предлагает различные тарифные планы. Например, стоимость конфигурации Linux-сервера (1 CPU, 512 МБ RAM, 10 ГБ HDD, 1 IPv4) начинается от 139 ₽/месяц. Это может быть рассмотрено как экономичное решение для запуска небольших проектов и проведения тестирования.

Клиентам доступны разные опции оплаты:

1. Ежемесячные платежи или предоплата на срок от 3 до 12 месяцев, при которой предоставляются скидки до 20%, зависящие от продолжительности периода.
2. Для проектов с динамической нагрузкой предусмотрена посекундная тарификация, оплата по которой взимается только за фактически использованные ресурсы. Неиспользованный остаток средств в рамках этой модели возвращается на баланс пользователя

Дополнительно, до конца 2025 года панель управления ISP Manager для сервера и сайта предоставляется без дополнительной платы при создании любого VPS.

Глобальная инфраструктура и стабильность

Инфраструктура включает 17 дата-центров уровня Tier III, расположенных по всему миру. Это один из самых больших показателей по количеству геолокаций среди российских провайдеров. Для работы используются корпоративное оборудование и накопители (HDD, SSD, NVMe), чтобы обеспечить стабильную работу и производительность размещенных проектов.

Поддержка клиентов и доступные ресурсы

Техническая поддержка RUVDS доступна круглосуточно, 7 дней в неделю. Среднее время ответа на запросы через тикет-систему или онлайн-чат составляет 15 минут. Клиентам предоставляются полные административные права и консультации по вопросам запуска и настройки серверов. Для самостоятельного изучения доступна база знаний, включающая инструкции и руководства.

Безопасность и масштабирования

В контексте безопасности данных, RUVDS предлагает несколько решений:

- Встроенная защита от DDoS-атак, способствующая поддержанию бесперебойной работы серверов при внешнем воздействии.

- Стандартный IPv4-адрес включен в стоимость каждой виртуальной машины, с опцией аренды дополнительных IP-адресов.

- API, соответствующий OpenAPI 3.0.0, предоставляет возможности для интеграции и автоматического масштабирования серверных ресурсов в зависимости от нагрузки.

- Компания официально подтверждает соответствие требованиям ФСТЭК и ФЗ-152 по защите персональных данных, что обеспечивает соблюдение соответствующих законодательных норм.

4. McHost: решения для бизнеса разного масштаба

McHost предоставляет комплексные хостинговые решения, включая виртуальный хостинг и VPS/VDS с NVMe-накопителями. Сервис поддерживает популярные CMS (WordPress, Joomla, 1С-Битрикс) с оптимизированными настройками и автоматической установкой через панель управления.

McHost ориентирован на широкий круг клиентов:

• владельцы сайтов-визиток, блогов и лендингов — благодаря низким тарифам и полному набору опций;
• интернет-магазины с небольшой нагрузкой — тарифы с SSD-накопителями и автоматическим резервным копированием обеспечивают стабильную работу;
• разработчики, которым нужны
  VPS/VDS с root-доступом — работают серверы на KVM-виртуализации с ОС Linux и Windows;
• госучреждения и компании,
  работающие с персональными данными — соответствие 152-ФЗ и размещение в дата-центрах Tier III в Москве.

Особенности сервиса

McHost поддерживает стабильную работу с аптаймом 99.9% за счет размещения оборудования в дата-центрах уровня Tier III — в Москве и Нидерландах.

Сервис предоставляет защиту от DDoS-атак, автоматическое резервное копирование раз в два дня с хранением данных в течение 30 дней для виртуального хостинга и 14 дней для VPS, а также поддержку российских криптографических стандартов. Клиентам доступны различные варианты размещения: от виртуального хостинга с SSD (от 157.5 ₽/мес) до выделенных серверов с NVMe-накопителями.

Технические параметры и условия

Инфраструктура McHost базируется на серверах Dell с NVMe-накопителями и процессорами Intel Xeon (частота ядер от 2.35 ГГц). Для виртуального хостинга используется CloudLinux с технологией CageFS, обеспечивающей изоляцию аккаунтов. Поддержка российских ОС («Альт») подтверждена для VPS-тарифов.

В техподдержку можно обратиться по телефону, через тикет или в Telegram-боте. Время ответа — до 10 минут.

Текущие тарифы:

• Виртуальный хостинг: от 157 ₽/мес
  (3 ГБ SSD, 1 сайт).
• VPS: от 396 ₽/мес (15 ГБ SSD, 1
  ядро CPU).
• Выделенные серверы: от 3 000 ₽/мес
  (32 ГБ RAM, 2×1 ТБ HDD).

5. UFO Hosting: VPS/VDS и выделенные серверы с портом до 10 Гбит/с и безлимитным трафиком

UFO Hosting предлагает VPS/VDS и выделенные серверы на партнёрской инфраструктуре IXcellerate (Tier III). В портфолио — недорогие виртуальные машины и серверы с портом 10 Gbps для проектов, которым нужна стабильность без завышенных цен.

Сервис подходит для пользователей разных масштабов: от фрилансеров и веб‑студий до средних и крупных компаний. Для DevOps‑специалистов доступны API и инструменты автоматизации.

Основные сценарии использования

• корпоративные сайты, CRM‑системы и веб‑приложения;
• аналитические сервисы и SaaS‑продукты;
• инфраструктура для разработки и тестирования;
• задачи фрилансеров, агентств и digital‑команд.

Формат работы, особенности и интеграции

Серверы установлены в российском дата‑центре Tier III (IXcellerate), что означает резервирование по питанию и каналам связи. Заявленный аптайм — 99,98 %. Поддержка работает круглосуточно в тикетах, чате и по телефону; среднее время ответа 5–10 минут.

Сервис UFO Hosting делает акцент на безопасности и гибкости. Есть сеть с защитой от DDoS, возможность горячего расширения ресурсов, автоматическое развёртывание из шаблонов и API для интеграции. Поддерживаются популярные фреймворки и CMS, есть интеграции с GitLab, Telegram и DockerHub. Бэкапы, снапшоты и резервирование входят в стандартный набор, так что восстанавливать тестовую среду не придётся вручную.

В панели управления можно автоматически установить популярные CMS, панели управления, хранилища и DevOps‑инструменты. Это экономит время на настройку и подходит тем, кто не хочет поднимать всё с нуля.

Условия использования и тарифы

Базовые конфигурации начинаются от 577 руб./месяц. Заявленная скорость порта — до 10 Gbps, что подходит для проектов, где много трафика.

Есть возможность бесплатно попробовать сервис присутствует, но предоставляется по запросу в поддержку, а при оплате на срок от трёх месяцев действуют скидки, а также регулярно проводятся акции: это поможет оптимизировать бюджет.

В целом, UFO Hosting выглядит как практичное решение для тех, кому нужны производительные VPS/VDS и выделенные серверы в России. При выборе стоит оценить, насколько конфигурации подходят под конкретные нагрузки и есть ли необходимость в интеграциях из коробки.

6. Timeweb: хостинг для веб-проектов

Timeweb предоставляет услуги хостинга для различных типов веб-проектов. Сервис поддерживает популярные CMS, включая WordPress, 1C-Битрикс и Joomla, что делает его подходящим как для личных блогов, так и для корпоративных сайтов.

Платформа использует собственную панель управления с инструментами для работы с сайтами, базами данных и резервными копиями. Ежедневное автоматическое резервное копирование с хранением данных до 30 дней включено во все тарифные планы. Базовая защита от DDoS-атак доступна для всех клиентов без дополнительной платы.

Инфраструктура Timeweb размещена в дата-центрах уровня Tier III в России (Санкт-Петербург) и Казахстане (Алматы). Гарантированный показатель uptime составляет 99.98%. Поддерживаются современные технологии: PHP версий от 5.3 до 8.4, MySQL от 5.6 до 8.0, а также Perl, Python, SSH, FTP и Cron.

Тарифные планы:

• Year+: от 164 ₽/мес (2 сайта, 15
  ГБ NVMe, 2 БД);
• Optimo+: от 248 ₽/мес (15 сайтов,
  40 ГБ NVMe, безлимитные БД);
• Century+: от 347 ₽/мес (35 сайтов,
  50 ГБ NVMe, безлимитные БД);
• Millennium+: от 482 ₽/мес (60
  сайтов, 60 ГБ NVMe, безлимитные БД).

Все тарифы включают бесплатный SSL-сертификат, 10 ГБ почтовой квоты с неограниченным количеством ящиков и DNS-хостинг. При оплате годового тарифа предоставляется домен в зонах .RU/.РФ в подарок.

Техническая поддержка доступна круглосуточно через онлайн-чат, тикет-систему и по телефону. Среднее время ответа не превышает 15 минут. Новые клиенты могут протестировать сервис бесплатно в течение пробного периода.

7. Reg.ru: комплексные решения для сайтов и доменов

Reg.ru сочетает услуги хостинга и регистрации доменов, что упрощает управление веб-проектами. Компания работает с 2005 года, имеет статус аккредитованного регистратора доменных имён в зонах .RU и .РФ.

Функциональные возможности

Платформа предоставляет доступ к трём панелям управления: ISPmanager, cPanel и Plesk. Это позволяет выбрать наиболее удобный интерфейс для работы с сайтами. Все тарифы включают бесплатный SSL-сертификат от Let’s Encrypt, который автоматически устанавливается при создании сайта.

Начинающим пользователям доступен конструктор сайтов с готовыми шаблонами. Поддерживаются популярные CMS, включая WordPress, Joomla и 1С-Битрикс. Ежедневное резервное копирование данных с хранением копий в течение 30 дней входит в стандартный набор услуг.

Техническая инфраструктура

Серверы размещены в дата-центрах уровня Tier III в Москве. Средний показатель uptime составляет 99.9%, что подтверждается ежемесячной статистикой. Подключение к сети осуществляется по выделенным каналам со скоростью до 1 Гбит/с на выделенных серверах.

Поддержка и тарифы

Техническая поддержка доступна 24/7 через онлайн-чат и тикет-систему. Среднее время ответа составляет 15-20 минут. Для срочных вопросов можно обратиться по телефону.

Тарифы — от 151 ₽/мес (7 ГБ SSD, 15 сайтов). При регистрации домена в зонах .RU или .РФ предоставляется скидка на другие доменные имена.

8. Спринтхост: хостинг с персональным подходом

Sprinthost предлагает услуги хостинга с акцентом на индивидуальную поддержку клиентов. Сервис работает с 2011 года и специализируется на VPS-решениях для различных веб-проектов.

Особенности сервиса

Компания предоставляет персонального менеджера для каждого клиента, который помогает с настройкой сервера и решением технических вопросов. А если вы остались недовольны услугами, то в течение 30 дней сервис вернёт деньги. Sprinthost проводит бесплатные обучающие вебинары по DevOps и администрированию серверов.

Технические характеристики и тарифы

Инфраструктура размещена в дата-центрах Москвы и Санкт-Петербурга с аптаймом 99.9%. Поддерживаются современные технологии разработки, включая Ruby on Rails, Node.js, Python и Docker. Все серверы используют SSD-накопители с гарантированной скоростью чтения/записи.

Тарифные планы:

• Start: 290 ₽/мес (1 ядро, 1 ГБ
  RAM, 15 ГБ SSD);
• Turbo: 1 900 ₽/мес (4 ядра, 8 ГБ
  RAM, 100 ГБ NVMe).

Поддержка

Техническая помощь доступна 24/7 через тикет-систему и онлайн-чат. Среднее время ответа составляет 10-15 минут. Для корпоративных клиентов предусмотрена приоритетная поддержка по телефону.

Как выбрать хостинг в 2025 году

Выбор хостинга зависит от типа проекта и его требований. Для небольших сайтов и блогов подойдет виртуальный хостинг с поддержкой популярных CMS — важно проверить наличие автоматических бэкапов и базовой защиты от DDoS. Если проект связан с обработкой персональных данных, убедитесь, что провайдер соответствует 152-ФЗ и использует сертифицированное оборудование.

Для высоконагруженных сервисов и интернет-магазинов лучше рассматривать VPS или выделенные серверы. Обратите внимание на тип накопителей (SSD/NVMe), возможность масштабирования ресурсов и аптайм дата-центров (рекомендуется от 99.9%).

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

Главное правило — выбирайте решение, которое покрывает текущие потребности проекта. Важно, чтобы конфигурацию можно было оперативно менять по мере роста запросов и масштабирования бизнеса. Технологии меняются быстро, и гибкость конфигурации часто важнее сиюминутной экономии.

FAQ

Что такое виртуальный хостинг и когда его выбирать?

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

Преимущества: низкая стоимость, простота управления через панели, автоматические обновления и базовая защита. Минусы: ограниченные ресурсы; производительность зависит от соседних сайтов; минимальный контроль над настройками.

Что такое VPS/VDS и для каких проектов он подходит?

VPS (Virtual Private Server) или VDS — это виртуальный сервер с выделенными ресурсами (процессор, память, диск), предоставляющий доступ для полной настройки. Идеален для проектов среднего масштаба: интернет-магазинов, API, SaaS, чат-ботов, корпоративных порталов или приложений с умеренным трафиком.

Преимущества: гибкость конфигураций, выбор ОС, изоляция ресурсов. Минусы: требует базовых навыков администрирования, стоимость выше, чем у виртуального хостинга.

Что такое выделенный сервер и когда его использовать?

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

Преимущества: максимальная производительность, полный контроль, высокая отказоустойчивость. Минусы: высокая цена, сложность настройки и обслуживания.

В чём основные различия между виртуальным хостингом, VPS и выделенным сервером?

Виртуальный хостинг — самый дешёвый и простой, но ресурсы делятся между пользователями, что ограничивает производительность (до 1000–2000 посетителей в сутки).

VPS обеспечивает выделенные ресурсы и гибкость, справляясь с нагрузкой до 5000–10 000 пользователей в сутки.

Выделенный сервер — максимум мощности для пиков свыше 10 000 пользователей, но требует значительных затрат и технических знаний.

Выбор зависит от масштаба: виртуальный для старта, VPS для роста, выделенный для enterprise.

Нужны ли навыки администрирования для хостинга?

Для виртуального хостинга навыки не нужны — управление идёт через интуитивные панели, а провайдеры обеспечивают обновления и базовую поддержку. Для VPS желательны базовые знания (настройка ОС, установка ПО), хотя многие провайдеры предлагают помощь. Для выделенного сервера навыки администрирования необходимы, так как вы полностью отвечаете за сервер, хотя провайдеры могут предлагать платное администрирование.

Что такое Kaniko и зачем он был нужен

Kaniko — это инструмент от Google для сборки OCI-совместимых образов контейнеров внутри контейнеров без необходимости root-доступа и запуска Docker-демона. Он получил широкое распространение как решение для CI-сборок в Kubernetes, особенно в таких платформах, как GitHub Actions и GitLab CI.

Преимущества Kaniko

Безопасность: не требует привилегий (rootless). Kaniko может запускаться в обычном (непривилегированном) контейнере, без необходимости доступа к root. Это значительно повышает безопасность, так как сборка образа происходит изолированно и не требует доступа к системным ресурсам.

Например, в Kubernetes можно создать под с Kaniko, где контейнер работает с обычным пользователем без securityContext.runAsRoot: true. Это значит, что злоумышленник не сможет получить root-доступ через этот контейнер.

Простота: легко запускать как задачу (Job) или контейнер в Kubernetes. Kaniko легко интегрируется в Kubernetes — он просто запускается как обычный контейнер, который выполняет сборку образа и загружает его в реестр. Не нужно устанавливать и настраивать Docker-демон.

Так выглядит запуск сборки в GitLab CI/CD с использованием Kaniko:

Совместимость: поддержка стандартных Dockerfile. Kaniko понимает обычные Dockerfile и может собрать образ из них, не требуя переписывать или адаптировать существующие инструкции.

Например, если есть обычный Dockerfile…

… то можно просто указать Kaniko использовать этот Dockerfile, и он построит такой же образ.

Конец поддержки Kaniko и альтернативы

В июне 2025 года публичный репозиторий Kaniko перевели в архив — теперь он доступен только для чтения, что фактически означает прекращение его активной поддержки и развития со стороны разработчиков.

Несмотря на то, что вскоре начали появляться форки (самый заметный — это chainguard-dev/kaniko), они ориентированы на режим поддержки (фикс багов и безопасность), а не на дальнейшее развитие инструмента. Поэтому многие пользователи ищут замену Kaniko — если и не сегодня, то в обозримом будущем.

Наиболее популярные в сообществе альтернативы:

• BuildKit от Docker/Moby (особенно в связке с docker buildx);
• Buildah от Red Hat из экосистемы Podman. Стал Sandbox-проектом CNCF в январе 2025 года.

Почему стоит рассмотреть werf и как начать

Помимо низкоуровневых инструментов, таких как Kaniko, BuildKit и Buildah, существует также высокоуровневое решение — werf. Это production-ready-инструмент, предназначенный не только для сборки, но и для доставки контейнеров в Kubernetes. Утилита позволяет использовать любую предпочтительную CI-систему. Является Sandbox-проектом в CNCF.

Что предлагает werf:

• Native Kubernetes-ориентированная архитектура, то есть можно легко интегрировать сборку, деплой и управление приложениями прямо в Kubernetes-кластере.
• Поддержка Buildah или BuildKit в качестве backend для сборки, причём Buildah полностью интегрирован в werf и может работать в rootless-режиме. Это позволяет собирать образы без необходимости запуска процессов с правами root.
• Удобная интеграция с другими инструментами доставки софта в Kubernetes (включая GitLab, GitHub Actions и Argo CD). Например, связка из werf и Argo CD позволяет полностью интегрировать между собой любую CI/CD-систему и Argo CD. При этом от каждого из инструментов берутся свои возможности и особенности.

• Автоматическое кэширование сборки и тегирование на основе содержимого, как результат — инкрементальные сборки и оптимальное использование container registry.
• Надёжное развёртывание и управление релизами в Kubernetes. werf расширяет возможности Helm, используя встроенный инструмент Nelm, который обеспечивает точное отслеживание состояния ресурсов, умное ожидание их готовности, мгновенное завершение проблемных релизов и применяет более надёжный метод обновления ресурсов — Server-Side Apply. При этом сохраняется полная совместимость с Helm-чартами и релизами.
• Дистрибуция релизных артефактов. Утилита упаковывает Helm-чарт и связанные с ним образы контейнеров в единый бандл, который затем можно опубликовать в OCI-совместимый реестр. Кроме того, бандлы можно копировать между реестрами, выгружать на USB-флеш-накопитель и развёртывать в Kubernetes с помощью werf или других решений, которые поддерживают работу с OCI-чартами (Helm, Flux, ArgoCD).
• Умная очистка container registry, которая автоматически удаляет неактуальные теги образов с учётом их использования в Kubernetes и истории Git, что позволяет безопасно освобождать место и контролировать рост хранилища без риска удаления нужных образов.

Примеры использования werf

Как будет выглядеть werf в CI/CD-системах? В общем случае достаточно добавить в свой пайплайн CLI-команду werf converge, которая собирает образ, пушит его в registry и выкатывает в Kubernetes.

Листинг с конфигурацией .github/workflows/converge.yml для использования werf в GitHub Actions может выглядеть так:

А использовать werf в GitLab CI/CD можно так:

Более подробные инструкции для доставки приложений в Kubernetes с werf можно найти в официальном руководстве по началу работы проекта.

В документации можно найти интерактивные сценарии, пояснения терминов, готовые CI-конфигурации и Helm-интеграцию. Всё это будет полезно и новичкам, и опытным DevOps-инженерам.

Вместо заключения

Поскольку Kaniko больше не развивается, многие могут задуматься о миграции на другой инструмент. Помимо очевидных вариантов вроде BuildKit и Buildah, рекомендуем попробовать werf. Он подойдет, если вам нужен CI-first-подход с нативной Kubernetes-интеграцией и интересны дополнительные фичи «из коробки» для CI/CD, например дистрибуция релизных артефактов и умная очистка container registry.

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

Реклама. Рекламодатель: АО «Флант». ИНН 772366143. erid: 2W5zFGNuWcp.

Давайте представим ситуацию, что нужно запустить код, минуя все эти стадии. Прям в production-среде. На первый взгляд — бред! Но если подумать, то на самом деле, не такая уж редкость. Например, некоторые системы предоставляют своим пользователям возможность расширять функциональность за счет прикладных скриптов. Наш любимый CI/CD-конвейер зачастую построен на пользовательских скриптах.

С одной стороны, для большинства подобная постановка вопроса — крайность. С другой, появляется возможность рассмотреть проблему с разных ракурсов. Уверен, что какие-то части общего решения, о котором пойдёт речь далее, могут быть использованы повторно и в других проектах.

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

Ненадёжный код

Для начала определимся, что же считать ненадёжным кодом? На самом деле ответ зависит от решаемой задачи, правил и процессов, принятых в компании:

• Код, который не прошел CI, review и т.п.
• Код из ненадёжного или неизвестного источника.
• Закрытый (проприетарный) код.
• Код, содержащий уязвимости.
• Код, использующий запрещенные функции.
• Любой код, который написал коллега:)

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

Уровни изоляции кода

Можно выделить три варианта запуска внешнего кода — три уровня изоляции. Каждый следующий увеличивает дистанцию между кодом приложения и запускаемым кодом. Чем выше уровень изоляции, тем меньше вероятность, что запускаемый код нанесет вред приложению и системе.

Уровень 1: тот же процесс

Запуск внешнего кода в адресном пространстве процесса приложения.

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

Примером может служить использование интерпретаторов скриптов (Rhino, IronPython, Jython и т.п.), визуальных языков программирования (workflow-движков) или подключение модулей расширения (плагинов).

Способов защиты на этом уровне не так много. Пожалуй, самым эффективным выступает (self-sandboxing), при котором приложение делает самозапрет на доступ к некоторым ресурсам системы. Например, сразу после инициализации — самозапрет на доступ к файловой системе.

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

Что же касается плагинов, то они призваны расширять возможности приложения, поэтому их использование изначально не предполагает сильной изоляции. Здесь можно предложить усилить контроль взаимодействия на уровне контракта (API). В идеале — если плагины будут публиковаться в некоторый центральный репозиторий, которому вы доверяете и который может производить дополнительные проверки и тестирование до этапа запуска кода плагина.

Уровень 2: отдельный процесс

Запуск внешнего кода на той же машине, но в отдельном процессе ОС.

Поскольку и приложение, и внешний код взаимодействуют в рамках одного узла, используя локальные ресурсы ОС (оперативная память, файловая система и т.п.), скорость межпроцессного взаимодействия очень высокая.

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

Уровень 3: отдельная машина

Запуск внешнего кода на отдельной машине — песочнице.

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

Самый главный недостаток этого подхода — необходимость сетевого взаимодействия между узлом, на котором работает приложение, и песочницей. Передача входных данных в песочницу, запуск процесса внутри, ожидание окончания его исполнения, получение выходных данных — всё это сетевые обращения. Так существенно замедляется процесс исполнения, а само взаимодействие подвержено сетевым сбоям, что ведёт к нестабильности системы и получаемых результатов.

Использование песочницы

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

Пересоздание или переиспользование песочницы

Песочницу требуется пересоздавать перед исполнением каждой задачи, если требуется особенное окружение (например, определенная версия ОС, пакетов или ресурсов) или идентичность этого окружения (для стабильности получаемых результатов). Схожие вопросы возникают, например, при интеграционном тестировании: каждому тесту нужны свои предустановки.

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

Основным преимуществом пересоздания песочницы выступает стабильность получаемых результатов. К недостаткам относится медленный запуск и перерасход ресурсов. На пересоздание песочницы уходят десятки секунд или даже минут, следовательно, большая часть ресурсов будет тратиться именно на это. Существует множество техник ускорения пересоздания, благодаря которым можно сократить время запуска. Прежде всего, сюда можно отнести backup/restore (snapshot песочницы, базы данных и т.п.). Также если поток задач небольшой и ресурсы позволяют, можно попробовать организовать пул песочниц и создавать их заранее.

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

Последовательное или параллельное исполнение

Теперь осталось ответить на вопрос, как именно можно или нужно исполнять задачи: последовательно или параллельно. Последовательное исполнение требуется в следующих случаях:

• важен порядок следования и исполнения задач;
• задачам нужен эксклюзивный доступ к определенному ресурсу;
• задачи ёмкие и их совместное исполнение вызовет нехватку ресурсов;
• задачи могут мешать исполнению друг друга из-за борьбы за ресурсы.

Например, шаги установки и настройки ПО; шаги CI/CD-конвейера; рендеринг изображения на GPU; интенсивные вычисления. Все эти задачи, скорее всего, придётся исполнять последовательно.

В остальных случаях допустимо параллельное исполнение. Яркой аналогией может служить одна из лучших практик в тестировании: тесты не должны оказывать влияние друг на друга, а порядок их запуска не должен иметь значения.

Последовательное исполнение обеспечивает стабильность получаемых результатов, однако приводит к низкой пропускной способности и дороговизне масштабирования (песочница обходится дороже процесса ОС). Параллельное исполнение, напротив, увеличивает пропускную способность системы и улучшает утилизацию ресурсов песочницы, но одновременно повышает вероятность нестабильных результатов. Более того, при параллельном исполнении появляется шанс перегрузить песочницу или вывести её из строя таким образом, что приведет к увеличению времени исполнения всех запущенных задач или потере результатов их работы.

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

Управление песочницами

Допустим, переиспользование песочниц возможно. В таком случае необходимо определить способ управления ими. Можно выделить два подхода, основанные на принципах микросервисной архитектуры, но адаптированные к специфике рассматриваемой проблемы.

Оркестрация

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

Основное преимущество оркестрации в контексте решаемой проблемы — её простота и ясность. Код легко читается и сосредоточен в одном месте. Однако у этого решения есть и недостатки. Рассмотрим их в порядке от простого к сложному.

• Синхронное взаимодействие. Так или иначе, для результата приложение вынуждено ожидать окончания исполнения задачи. Для продуктивного использования ресурсов приходится прибегать к техникам асинхронного программирования: пока задача исполняется, приложение будет занято полезной работой. Это малозаметный недостаток в языках со встроенной поддержкой концепции асинхронного программирования. Для упрощения работы с асинхронным кодом в Java я создал небольшую вспомогательную библиотеку asynchronizer, снабдив её подробной документацией.

• Отслеживание доступности песочниц. Поскольку хотелось бы, чтобы количество песочниц менялось в зависимости от нагрузки на систему, придётся отслеживать их доступность. Это прямая обязанность оператора песочниц, которую можно выделить в отдельный discovery-сервис (например, на базе Netflix Eureka), либо реализовать как часть приложения с использованием инфраструктурных механизмов (например, Kubernetes API). Важно отметить, что оператор песочниц не имеет отношения к бизнес-логике приложения.

• Отслеживание загруженности песочниц. Оркестратор исполнения должен выбрать подходящую стратегию балансировки, основанную на состоянии песочниц, предоставляемых оператором. На практике наилучшую эффективность демонстрирует алгоритм Least connections, с помощью которого можно выбирать наименее загруженные песочницы. Для этого достаточно вести учёт количества задач, исполняемых каждой песочницей. Конечно, это не серебряная пуля, а лишь частное наблюдение, поэтому в идеале нужно предусмотреть несколько стратегий балансировки и выбрать наилучшую по результатам нагрузочного тестирования.

• Неопределённость результата, если нет ответа от песочницы. Песочница может быть недоступна по различным причинам, включая не только проблемы с сетью, но и падения песочницы из-за ненадёжного кода. К сожалению, в общем случае эта проблема не имеет решения, так как делать повторные запуски (retries) может быть опасно. Всё, что остаётся, это использовать таймауты и откладывать неуспешную задачу на потом.

Ещё один существенный минус, который стоит упомянуть, это возможный побочный эффект, возникающий при масштабировании системы и проявляющийся в виде перегрузки песочниц. Для наглядности рассмотрим конкретный пример.

Для отслеживания нагрузки на песочницы экземпляр приложения ориентируется на количество задач в каждой из доступных песочниц. Предположим, что было принято решение увеличить количество экземпляров приложения. Этот экземпляр исполняет 5 задач в двух песочницах (3 процесса в одной и 2 в другой). Известно, что каждая песочница может вынести максимум 4 параллельных задачи.

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

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

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

• Для контроля количества исполняемых задач в песочнице использовать распределённый счётчик (например, на базе Redis). Проблема в том, что распределённый счётчик имеет латентность и на момент запуска задач может выдать устаревшее значение. Кроме того, в системе появляется еще один инфраструктурный компонент, который не несёт бизнес-пользы.

• Выделить каждому экземпляру приложения эксклюзивное подмножество песочниц. Подобное решение существенно усложнит deployment-скрипты и процесс масштабирования, а также снизит степень утилизации выделенных ресурсов, ведь нет никаких гарантий того, что экземпляр приложения сможет хорошо нагрузить все выделенные ему песочницы.

Кстати, после доклада на TechLeadConf 2025 мне задали интересный вопрос: Можно ли при балансировке нагрузки на песочницы учитывать не только количество исполняемых задач, но и процент загрузки CPU, памяти и прочих ресурсов? Если у кого-то возник такой же вопрос, то отвечу, что это не имеет смысла, поскольку ситуация в песочнице может поменяться мгновенно. Полученный практический опыт и нагрузочное тестирование показали, что простой подсчёт задач работает эффективно.

Самоорганизация

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

Ключевой момент в архитектуре — это появление двух очередей: очередь задач на исполнение (Task Queue) и очередь результата их исполнения (Result Queue). Все поступающие задачи приложение направляет в первую очередь, а результаты — во вторую. Дополнительно появляется роль агента — микросервиса, который исполняется в рамках узла песочницы и координирует исполнение поступающих задач.

Основной недостаток самоорганизации — распределённый процесс обработки задач. Учитывая простоту алгоритма обработки, это не так существенно. Стоит отметить преимущества этой архитектуры.

• Максимальная изоляция ненадёжного кода. Ненадёжный код, как и в случае с оркестрацией, по-прежнему работает в песочнице в рамках отдельного процесса ОС.

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

• Контролируемая нагрузка на песочницы. Агент, выступая в роли консюмера очереди задач, может точно контролировать степень параллелизма и выбирать новые задачи только тогда, когда он закончил обрабатывать предыдущие.

• Минимум инфраструктурного кода. Очереди избавляют от необходимости иметь оператор песочниц, отслеживать их состояние и осуществлять балансировку нагрузки.

• Простота масштабирования. Приложение и песочницы масштабируются независимо друг от друга без негативных побочных эффектов.

Запуск процесса ОС

К запуску процесса ОС, в рамках которого будет исполняться ненадёжный код, нужно подойти с особой осторожностью. Здесь важно ответить как минимум на три вопроса.

• Как ограничить права доступа к ресурсам. Самое простое решение — запуск процесса от имени пользователя с ограниченными правами (на доступ к ресурсам ОС).

• Как ограничить объем используемых ресурсов. Для запускаемого процесса нужно определить доступные ресурсы и возможные действия.

• Как осуществлять анализ поведения и результатов исполнения. Наличие и решение этой проблемы целиком и полностью зависит от специфики проекта. Здесь невозможно предложить универсального решения.

Рассмотрим варианты ограничения ресурсов процесса ОС.

Ограничение ресурсов процесса

Ресурсы процесса могут быть ограничены на трех уровнях:

• Лимиты узла. Физические ограничения машины, на которой исполняется процесс. В частном случае можно говорить об инфраструктурных лимитах, определённых для Docker/Kubernetes контейнера.

• Лимиты контейнера. Программные лимиты, задаваемые выбранным инструментом контейнеризации (cgroup, Docker, Bubblewrap, ProcessSandbox и т.п.).

• Лимиты процесса. Программные лимиты, задаваемые средствами ОС. На этом уровне можно осуществлять гибкую настройку вариантов запуска и исполнения.

Можно использовать все три уровня лимитирования, либо какой-то определенный.

Между тем, важно отметить некоторые трудности, которые могут возникнуть при использовании инструментов контейнеризации.

Например, для использования cgroup или Docker внутри Kubernetes-контейнера нужно эскалировать привилегии контейнера, что в общем случае небезопасно в контексте исполнения ненадёжного кода. Более того, практика показала, что легковесных rootless-средств, предоставляемых ОС, вполне достаточно, чтобы снять большую часть рисков. В частности, Linux API позволяет не только лимитировать CPU и память, но и блокировать доступ к некоторым возможностям самой ОС. Например, можно наложить фильтр, который запретит вызов определённых системных функций.

Проблемы жёсткого лимитирования

Рассмотренные выше способы лимитирования задают жёсткие границы (hard limit), нарушение которых замедляет исполнение процесса, либо приводит к его принудительному завершению. При этом поведение наблюдаемого процесса и системы сильно варьируется в зависимости от того, какой лимит был превышен. Например, превышение по использованию CPU может привести к троттлингу (throttling), приостановке работы или принудительному завершению; превышение по использованию памяти заканчивается принудительным завершением со стороны ОС (OOM Killer) либо самостоятельным падением процесса (с ошибкой Out Of Memory).

Подобная вариативность осложняет анализ поведения и результатов исполнения. В этом случае можно использовать подход с программной мягкой границей (watchdog limit). Суть заключается в запуске дополнительного следящего потока (или процесса) ОС, который контролирует поведение и расход ресурсов у наблюдаемого. Как только детектируется превышение одного из лимитов, производится принудительное завершение наблюдаемого процесса, но уже не со стороны ОС, а со стороны приложения.

Такой подход имеет несколько преимуществ.

• Точное определение причин принудительного завершения. Жёсткие лимиты чуть выше мягких, благодаря чему для исполняемого кода создаётся иллюзия отсутствия каких-либо лимитов. Между тем, если лимиты всё-таки нарушаются, процесс всё равно будет завершен (либо со стороны приложения, либо гарантированно со стороны ОС). Но подобный дополнительный контроль со стороны приложения оставляет для него гораздо больше шансов понять причину принудительного завершения наблюдаемого процесса.

• Возможность гибкого лимитирования ресурсов. Приложение (или агент), ответственное за запуск наблюдаемого процесса, может обратиться к средствам ОС (в частности, к Linux API) и гибко настроить параметры запуска и исполнения. Как минимум, жёстко определить лимиты по CPU и памяти; наложить ограничения на объем I/O; создать запрет на вызов некоторых системных функций (например, запрет использования сетевых операций или файловой системы) и т.п.

Такой подход я назвал watchdog и в целях иллюстрации реализовал его в виде .NET-библиотеки ProcessSandbox. Помимо прочего, на странице проекта подробно рассмотрена проблематика контроля и анализа поведения процесса ОС со стороны прикладного кода.

Итоговая схема лимитирования может выглядеть так, как показано на рисунке ниже. Вместо тяжеловесных инструментов контейнеризации используется легковесный rootless-инструмент (watchdog) на базе средств ОС и только.

Для задач, где не нужен анализ поведения процесса и тонкая настройка лимитов, можно воспользоваться готовым инструментом — утилитой.

Многоконтейнерные поды

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

Несмотря на всю заманчивость данной идеи, она несёт ряд недостатков.

• Плохая масштабируемость. Соотношение приложение-песочница всегда один к одному. Однако не исключено, что в некоторых случаях это вполне приемлемо.

• Плохая утилизация ресурсов. Сможет ли приложение достаточно нагрузить песочницу, если количество песочниц будет в избытке; и наоборот, нужно ли столько же экземпляров приложения, сколько и песочниц.

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

• Риск нарушить работоспособность приложения. Выход песочницы из строя скорее всего приведет к перезапуску всего пода. Более того, если приложение и песочница обмениваются файлами через общий раздел (shared volume), это может стать уязвимым местом.

Образ для песочницы

Основные моменты, которые следует учесть при создании (Docker) образов песочниц:

• Заменить init-процесс на tini, чтобы не превысить лимит по PIDs.

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

• Регулярно сканировать версии образов и пакетов на наличие уязвимостей.

Инфраструктура исполнения

Основные моменты, которые следует учесть при настройке инфраструктуры исполнения:

• Обеспечить быстрый (пере)запуск песочниц. Нужно быть готовым к тому, что песочницы будут падать. Если речь идет о Kubernetes, то улучшить время запуска может подходящая настройка Image Pull Policy. При этом лучше не использовать тег `latest`, а указывать конкретную версию или хэш-код образа, чтобы не тратить время на попытки определения последней версии при каждом запуске.

• Установить приемлемый лимит на PIDs. Необходимо контролировать число активных процессов в системе. Особо вредоносный код может попытаться создать очень много дочерних процессов, поэтому при отсутствии лимита на PIDs узел быстро будет выведен из строя. Важно отметить, что лимит задаётся для пользователя, а не для запускаемого процесса. По этой причине он должен быть разумно большим.

• Установить лимиты на ресурсы узла. В Kubernetes для каждого контейнера нужно указать, как минимум, лимиты по CPU и памяти. Значения лимитов лучше всего определить в ходе нагрузочного тестирования или путём сбора метрик приложения.

Заключение

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

Я постарался показать последовательность шагов по направлению к целевой архитектуре, которая будет отвечать требованиям бизнеса и справляться с ненадёжным кодом. Если вам интересна данная тематика, подписывайтесь на мой Telegram-канал Архитектоника в ИТ (@arch_and_dev). Буду рад поделиться опытом.

В статье рассмотрим:

- Установку локально и в облаке;

- Интеграцию с Python, Node.js и PHP;

- Примеры автоматизаций;

- Интеграцию с AI Mistral.

Установка n8n

Локальная установка

Нам потребуется Docker, проверьте установку:

Шаги установки:

1. Создайте том данных:

2. Запустите контейнер:

После запуска откройте: `http://localhost:5678`

Установка на удаленном сервере

Развертывание мы произведем в облаке Amvera, так как в нем n8n предоставляется как преднастроенный сервис с бесплатным доменом (он нам нужен), настроенными переменными и проксированием до заблокированных в РФ LLM (OpenAI, Gemini, Claude и др.).

1. Регистрируемся на Amvera;

2. Выбираем n8n в плитке на главной странице;

3. Вводим название для проекта и выбираем тариф.

Готово, через 30 секунд запустится n8n с выделенным доменом и настроенными основными переменными.

Настройка n8n

Первоначальная настройка

1. Откройте n8n (локально: `localhost:5678`, в облаке: ваш домен)

2. Заполните данные администратора:

• Email

• Имя/Фамилия

• Пароль

3. По желанию вы можете получить бесплатный лицензионный ключ:

• Введите email → "Send me a free license key"

• Активируйте в разделе Settings → Usage

Настройка для HTTP

1. Создайте новый workflow → Start from scratc

2. Добавьте триггер: Webhook - On webhook call

3. Настройте:

• HTTP Method: POST

• Path: `/n8n` (пример)

• Respond Mode: Using 'Respond to Webhook' node

4. Добавьте обработчик: Core → Respond to Webhook

5. Настройте ответ:

Примеры использования

Пример на Python

В примере на Python мы сделаем калькулятор. Суть: отправляем выражение через POST, n8n делает вычисление, возвращаем результат.

Workflow:

1. Добавьте Core → Code node между Webhook и Respons:

Клиент (Python):

Запустим код и посмотрим результат:

Пример на PHP

В примере на PHP мы сделаем валидацию данных. Суть: отправляем данные через POST, n8n проверяет данные, возвращает результат.

Workflow (Code node):

Клиент (PHP):

Можем зайти на нашу страницу, все работает нормально:

Пример на Node.js

Примером на node.js будет фильтр запрещенных слов. Суть: отправляем текст, n8n проверяет на наличие плохих слов, возвращает результат.

Workflow (Code node):

Клиент (Node.js):

Перед запуском установим библиотеку командой `npm install axios`

Интеграция n8n с Mistral AI

Мы интегрируем нейросеть Mistral в телеграмм-бота на C# с помощью n8n. Перед тем как начать, нам нужно получить токен.

1. Зарегистрируйтесь на Mistral

2. Создайте агента Сreate an agent

3. Перейдите в раздел API Keys

4. Создайте и скопируйте API-ключ (звездочки наложены):

Теперь нужно создать credentials для работы с созданной моделью. Для этого в правом верхнем углу нажмите Create credentials. В списке найдите Mistral Cloud API. В открывшемся окне вставьте скопированный ключ и сохраните.

Осталось настроить workflow.

1. Добавляем Webhook:

• Method: POST

• PATH: n8n

• Respond: Using 'Respond to Webhook' Node

2. Добавляем AI Agent:

• Source for Prompt: Define below

• Prompt: `{{ $json.body.text }}`

3. Подключаем Chat Model к созданному агенту:

• Credential to connect with: Mistral Cloud API

• Model: mistral-large-2411

4. Добавляем Respond to Webhook

Вот так выглядит готовый workflow:

Можем приступить к созданию бота. Для начала введите эти команды по очередности:

Переходим в папку с кодом и редактируем файл `Program.cs`:

Запустите бота с помощью команды `dotnet run`.

Автоматизируем с помощью n8n

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

Для работы с Telegram Node понадобиться создать credentials Telegram API. Туда вставляем токен бота, полученный в @BotFater. Сохраняем и переходим к настройке workflow.

Создаем новый workflow.

1. Добавляем On form submission. В качестве примера я создам самую простую форму:

Перейдите по ссылке в Producrion URL чтобы заполнить форму.

2. Добавляем Telegram Node:

• Credential to connect with: Telegram account

• Resource: Message

• Operation: Send message

• Chat ID: вставьте свой telegram id

Text:

Готово! При новых заявках бот будет присылать уведомления.

Деплой бота в Amvera Cloud

Перед тем как начать деплой, мы должны создать конфигуационнный файл `amvera.yml`. Для этого создаем его в рабочем каталоге с ботом и вводим следующее:

Строго говоря, этот файл проще создать в конфигураторе в интерфейсе.

2. Структура проекта будет такой:

tg-bot/

├── Program.cs

├── tg-bot.csproj

├── amvera.yml

├── bin/

└── obj/

Идем В Amvera Cloud и создаем приложение Приложения — Создать приложение. Вводим название и выбираем тариф.

Далее загружаем все файлы, что есть у нас в каталоге, с ботом. В конце будет окно с настройкой конфигуцрации, выглядит оно так:

Нажимаем Завершить и ждем когда приложение будет запущено.

Заключение

n8n — мощный инструмент для создания интеграций и автоматизаций. Надеюсь, статья была вам полезна и буду рад обсудить в комментариях любые вопросы!

1. МояДоска

«МояДоска» — это российский SaaS-сервис для совместной работы и визуализации идей. У онлайн-доски бесконечный размер: это значит, что вы можете размещать сколько угодно элементов и никогда не упретесь в границу. Так, команды, преподаватели и креативные специалисты могут проводить брейнштормы, планирования, презентации и обучение в одном пространстве.

Что под капотом

Фронт написан на React + PixiJS, а бэк — Node.js + PostgreSQL. Это обеспечивает быстрый и понятный интерфейс и стабильную работу даже при большом объёме объектов на доске. Команда выпускает обновления несколько раз в месяц, а о новинках можно узнать в Telegram-канале сервиса. Например, в недавнем апдейте появилась возможность превратить фрейм в таблицу или тетрадь за пару кликов, а еще задать нужное число столбцов, колонок, толщину границ и цвет.

Из главных функций:

• Понятный интерфейс
• Совместная работа в реальном времени
• Привычные инструменты: фигуры, стрелки, стикеры, текст, загрузка файлов, маркер, карандаш
• Обрезка фото прямо на доске, воспроизведение аудио, поддержка PDF
• Гибкое управление доступом
• Возможность повторного использования шаблонов
• Поддержка фреймов и создание логичных пространств для разных задач

Переезд на сервис

«МояДоска» интегрируется в процессы на разных этапах, упрощая жизнь команде. Например, сама команда сервиса перешла с Miro на свою доску для стратегического планирования. С помощью стикеров и стрелок они построили дерево решений, чтобы лучше расставить приоритеты. А одно маркетинговое агентство перевело все документы и сессии планирования на доску, отказавшись от Google Docs и таблиц. Это ускорило принятие решений: сотрудники работали с данными в одном формате, точно собрались в одном кабинете перед маркерной доской.

2. METEOR

METEOR — инструмент управления проектами. Это трекер задач с дашбордами, досками канбан, диаграммами Ганта и API, который работает в виде веб-приложения как в облаке, так и на своих серверах. Продукт создавался как универсальный центр управления задачами: он объединяет в себе все — от разработки и тестирования до маркетинга и поддержки. Сейчас его используют более 250 команд и свыше 2000 пользователей ежедневно.

Что под капотом

В основе — стек Ruby on Rails, React и TypeScript, PostgreSQL и Redis, плюс современная инфраструктура на Docker и Kubernetes.

Система разбита на микросервисы — за фоновую обработку, нотификации и работу с файлами отвечает отдельный функционал. Авторизация построена через OAuth 2.0 (Google, Yandex), а для аналитики используется Posthog и ELK-стек. Мониторинг реализован на Prometheus + Grafana. Обновления выходят каждую неделю, а обратная связь приходит разработчикам METEOR через Telegram-бот.

Вот главные функции:

• Гибкие доски задач (Kanban, Scrum) — 6 видов.
• Списки задач с группировками и иерархией.
• Автоматические отчеты (ежедневные/еженедельные сводки).
• Умные напоминания (Telegram-бот, email).
• Глубокая аналитика (время выполнения задач, загрузка команды).
• Потоковая автоматизация процессов

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

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

Разработчики используют METEOR для линковки задач с pull-requests и контроля бэклога. Менеджеры получают отчеты автоматически и не тратят часы, чтобы собрать всю информацию вручную. QA ведут тест-кейсы и баги в удобных досках, а DevOps отслеживают инциденты и шаги деплоя. Даже HR подключаются — через систему проходят кандидаты и стажеры.

Переезд на сервис

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

• скорость выполнения задач увеличивается в среднем на 25% — благодаря автоматическим напоминаниям и чётким процессам;
• количество потерянных задач снижается на 70% — исчезают хаотичные чаты и забытые письма;
• на составление отчетов и сбор метрик уходит не 5 часов, а всего 30 минут в неделю;
• а экономия времени — около 75 часов в месяц на команду из 10 человек.

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

3. Gitlife

GitLife — это универсальная платформа для хостинга репозиториев и построения полного DevOps-процесса внутри компании. Разработана с прицелом на закрытые контуры, импортозамещение и гибкость — подходит как для современных Git-проектов, так и для инфраструктур, где все еще используется SVN.

Помимо самого Gitlife, разработчики делают Gitlife AI, в котором есть доступ к топовым ИИ-моделям и инструментам, чтобы разрабатывать ИИ-решения.

Что под капотом

Внутри Gitlife собраны модули для:

• Кода — репозитории, ветвление.
• Задач — бэклоги, спринты, дашборды.
• Документации — совместное редактирование документов, управление правами.
• Аналитики — карты потока ценности, качество кода, метрики по инженерам.
• Пайплайны — модуль «Конвейер» управляет сборками и CI/CD.

Gitlife используется ИТ-отделами и R&D-подразделениями в компаниях с высокими требованиями к информационной безопасности. Подходит как для небольших команд, так и для распределённых корпораций с десятками проектов.

Что решает:

• Безопасный и полностью локальный хостинг исходного кода (Git + SVN)
• Управление задачами и CI/CD в одном месте
• Централизованный доступ, права, аудиты и история изменений
• Полная поддержка DevOps-процессов на российском ПО
• Альтернатива GitHub, GitLab и Bitbucket в условиях ограниченного доступа и санкционных рисков

Переезд на сервис

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

4. Cerebro

Cerebro — профессиональная система для совместной работы и управления проектами. Она помогает ставить задачи, планировать этапы, следить за выполнением, обмениваться файлами и комментировать их прямо в системе. Особенно полезна для команд, которые делают VFX, 3D, анимацию или дизайн — но при этом легко адаптируется и под другие команды.

Платформа охватывает полный цикл — от первых идей и планирования до комментирования финальных шотов (отдельных сцен или кадров в видео/анимации) и соблюдения дедлайнов. Такой подход помогает команде ускорить работу на 20%, сократить время на правки и держать весь процесс под контролем — от начала до сдачи проекта.

Cerebro подходит для команд от 1 до 1000+ человек с задачами на проекте от 1 до 10000+. Сервис работает с 2009 года, сейчас им пользуются более 400 команд в России и СНГ.

Что под капотом

Cerebro поддерживает десктоп (Windows, Mac и Linux), веб-версию и мобильное приложение, локальное, облачное и гибридное развертывание. Инструмент построен на клиент-серверной архитектуре — она гибкая, поэтому можно настраивать конфиги исходя из потребностей бизнеса.

Из технологий:

• Backend: C, C++, Python, SQL
• Frontend: JS, TypeScript, ReactJS, Qt, PyQt
• Мобильные клиенты: React Native
• БД: PostgreSQL с проприетарными расширениями + SQLite
• Файловое хранилище: Cargador
• Плагины: Tentaculo (встраивается в производственные программы)

Cerebro покрывает весь пайплайн — от идеи до финала. Вот основные возможности сервиса:

• Множественные уровни вложенности задач — подходит для сложных иерархий продакшена
• Планирование с помощью диаграммы Ганта и специального инструмента «План»
• Канбан-доска для визуального контроля задач
• Инструмент «Моё пространство» — для персонализированной фильтрации и отбора задач
• Уровни доступа и ролевое управление
• Расширенная статистика по проектам, командам, сотрудникам
• Совместная работа над большими файлами (видео, изображения, 3D) — Mirada позволяет комментировать, делать подрисовки, оставлять голосовые заметки
• Интеграция с пакетами Adobe, Autodesk и мессенджерами, возможность встраивать в любые пайплайны
• Удобное подключение фрилансеров

Переезд на сервис

Обычно внедрение начинается еще на этапе препродакшена — во время разработки концепции и четкого плана действий. Затем система сопровождает проект на всех стадиях, вплоть до постпродакшена (финального тестирования и релиза), где она закрывает 80-100% задач. Cerebro позволяет собирать всё в одном месте: задачи, правки, сроки, бюджеты, загрузку сотрудников и статус проекта в целом.

После переезда снимается много рутинных задач: больше не нужно вручную назначать исполнителей, комментировать медиаконтент, передавать файлы между программами и так далее. В среднем проекты выполняются на 20% быстрее, без потери качества. В больших студиях объем выпускаемых шотов может вырасти до 20+ тысяч — это уже работает у других клиентов, среди которых СберМаркетинг, Sinners, Black Point и другие. Cerebro также помогает переехать с других такс-трекеров и систем для управления проектами.

5. Replit Teams

Replit Teams — это платформа для совместной разработки в реальном времени. По сути, это интегрированная IDE + git-репозиторий + система управления задачами — и все доступно через браузер. Подходит как для командной работы в стартапах, так и для образовательных проектов, хакатонов и небольших продуктовых команд.

А главная фишка — встроенный ИИ, к которому можно обращаться прямо во время написания кода. Инструмент разработан с акцентом на простоту входа, командную работу и быстрое прототипирование. Поддерживает более 50 языков программирования и позволяет запускать полноценные веб-приложения в облаке.

Что под капотом

Внутри Replit Teams есть интерфейсы для:

• Кода — редактор с автокомплитом, подсветкой синтаксиса, терминалом и интеграцией с Git.
• Задач — встроенный таск-менеджер с распределением задач по участникам.
• Общения — встроенные комментарии в коде, возможность ревью и обсуждений.
• CI/DevOps — запуск и отладка приложений без настройки окружения.
• Доступа — гибкие роли, приглашения по ссылке, настройки приватности.

Переезд на сервис

Replit Teams позволяет моментально начать работу: не нужно ставить зависимости, конфигурировать CI или закупать сервера. Подходит как для быстрой прокачки навыков, так и для реальных командных проектов в продакшене.

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

Рассказывайте в комментариях, какими сервисами пользуетесь вы.

Эта статья — подробная хроника эволюции программистов: какие языки и технологии они осваивали, как менялись их рабочие места, методы обучения и даже само восприятие профессии. Мы разберем ключевые этапы, от первых веб-гигантов до эпохи совместного программирования с ИИ, и попробуем представить, что ждет нас дальше.

2005-2009: Эпоха авторских решений и первых веб-фреймворков

В середине 2000-х типичный рабочий инструмент программиста — это громоздкий системный блок с процессором Intel Pentium 4 или новеньким Core 2 Duo. Мониторы с ЭЛТ-трубкой постепенно уступали место LCD-экранам с разрешением 1024×768 — именно на таких дисплеях создавались первые версии Wikipedia и набирающих популярность соцсетей. Оперативная память в 1-2 ГБ считалась нормой, а жесткие диски на 80-160 ГБ часто заполнялись до отказа — проекты редко весили меньше нескольких гигабайт.

Серьезная разработка велась преимущественно на стационарных компьютерах. Ноутбуки только начинали входить в обиход — их брали в офис, но для реальной работы предпочитали мощные десктопы. Операционная система Windows XP доминировала на рабочих станциях, в то время как серверы чаще всего крутили на Linux — Red Hat Enterprise или Debian.

Среды разработки того времени сегодня кажутся архаичными. Eclipse и NetBeans потребляли гигабайты памяти, Visual Studio 2005 требовала серьезных ресурсов. Многие разработчики предпочитали простые текстовые редакторы вроде Notepad++, а для отладки использовали примитивные методы вроде вывода значений переменных через print. Контроль версий только начинал входить в практику — Git появился в 2005 году, но большинство команд продолжали использовать SVN или вообще заливали файлы по FTP напрямую на продакшен.

Языковая экосистема этого периода вращалась вокруг трех основных технологий. PHP версий 4 и 4.3 доминировал в веб-разработке — на нем работало около 80% всех сайтов в интернете. Однако его объектно-ориентированные возможности были крайне ограничены до выхода PHP 5 в 2004 году.

Java в лице J2EE оставалась стандартом для корпоративных решений — банковских систем, крупных порталов и ERP-комплексов. Spring Framework только начинал набирать популярность, а Hibernate упрощал работу с реляционными базами данных. C++ сохранял свои позиции в разработке игр (особенно с использованием Unreal Engine), драйверов и высоконагруженных сервисов.

Фронтенд-разработка в те годы была невероятно простой по современным меркам. Верстали преимущественно таблицами, а всю динамику реализовывали через jQuery, который появился в 2006 году и быстро вытеснил нативный JavaScript из повседневной практики. AJAX-запросы казались революционной технологией, позволяющей обновлять части страницы без ее полной перезагрузки.

Обучение программированию в этот период кардинально отличалось от современных подходов. Онлайн-курсы практически отсутствовали. Основными источниками знаний служили бумажные книги:

• «Философия Java» Брюса Эккеля;
• «Совершенный код» Стива Макконнелла;
• «PHP и MySQL. Разработка веб-приложений» Люка Веллинга.

Русскоязычное сообщество активно обсуждало вопросы разработки на форумах RSDN.ru и CyberForum.ru. В 2008 году появился Stack Overflow, который постепенно стал главной площадкой для профессиональных обсуждений.

Университетское образование давало хорошую теоретическую базу — алгоритмы, структуры данных, принципы ООП. Однако практическим навыкам приходилось учиться самостоятельно, методом проб и ошибок. Документацию часто скачивали в формате CHM-файлов или читали непосредственно на сайтах вроде php.net и MSDN.

Типичный стек начинающего разработчика в 2009 году:

• HTML/CSS с jQuery для фронтенда;
• PHP или Ruby on Rails для бэкенда;
• MySQL в качестве базы данных.

ORM-технологии еще не получили широкого распространения, поэтому SQL-запросы писали вручную. Многие проекты представляли собой монолитные приложения, где весь код хранился в единой кодовой базе без четкого разделения на модули.

Показательный кейс:

В 2007 году разработчик PHP-приложений из МЭСИ (Москва) столкнулся с типичной для того времени проблемой — SQL-инъекциями. Вместо стандартных решений он создал DLAC (Data Logic Access Component) — обертку для работы с базой данных, которая автоматически экранировала параметры запросов. Это выглядело революционно на фоне типичного кода того периода, где строки запросов часто собирали через конкатенацию с пользовательским вводом.

Компонент использовал новую для 2005 года технологию Generics в C#. Он генерировал параметризованные запросы, что резко снижало риски взлома.

Разработчики в университетской среде тогда редко задумывались о безопасности — многие проекты содержали уязвимости вроде SELECT * FROM users WHERE name = ‘.$_POST[‘name’].

DLAC стал локальным спасением для внутренних систем МЭСИ, пока в 2009 году не появился NHibernate — порт популярного Java-фреймворка Hibernate.

Этот кейс хорошо иллюстрирует дух эпохи: отсутствие готовых безопасных решений заставляло программистов изобретать велосипеды. Многие подобные наработки позже легли в основу ORM-библиотек, но тогда они рождались в муках — через пробелы в безопасности и километры самописного кода.

2010-2014: Мобильная революция и рассвет JavaScript

Начало нового десятилетия ознаменовалось стремительным ростом мобильных технологий. Выход iPhone 4 в 2010 году и Android 2.3 Gingerbread задал новые стандарты мобильной разработки.

Программисты массово переходили на MacBook Pro — не столько из-за преимуществ macOS, сколько благодаря появлению Retina-дисплеев в 2012 году, которые кардинально улучшили качество отображения кода.

Железо продолжало стремительно эволюционировать. Твердотельные накопители (SSD) начали вытеснять традиционные жесткие диски в рабочих станциях. Облачные платформы вроде AWS и Heroku стали реальной альтернативой локальным серверам, которые раньше часто стояли прямо под рабочими столами в офисах. Оперативная память в 8 ГБ стала стандартом для комфортной разработки, а четырехъядерные процессоры ускорили сборку крупных проектов.

Языковая палитра этого периода значительно расширилась. Objective-C стал основным языком для iOS-разработки и оставался таковым до появления Swift в 2014 году. Python 3 начал набирать популярность благодаря веб-фреймворку Django и научным библиотекам NumPy и Pandas, которые открыли дорогу для анализа данных в массовом сегменте.

JavaScript пережил настоящий ренессанс — после выхода AngularJS в 2010 и Node.js в 2009 году он перестал быть просто «языком для анимаций на сайте», превратившись в полноценную платформу для fullstack-разработки.

Важный факт. В 2011 году разработчик из Сан-Франциско Райан Даль представил Node.js — среду выполнения JavaScript на стороне сервера. За первые 24 часа после релиза проект собрал 10 000 звезд на GitHub, что для того времени стало рекордом. Многие скептически относились к идее использовать JavaScript вне браузера, но уже через год такие компании как LinkedIn и Walmart перевели части своего бэкенда на Node.js, получив прирост производительности в 2-3 раза по сравнению с традиционными решениями на Java и Ruby.

Образовательная сфера претерпела значительные изменения. В 2011 году запустилась Coursera с первым массовым курсом по программированию — Machine Learning от Эндрю Ына. В 2012 году в Кремниевой долине открылся Hack Reactor, ставший прототипом современных coding bootcamps (интенсивов по программированию). Эти форматы предложили альтернативу традиционному университетскому образованию, сделав акцент на практических навыках.

Параллельно в России:

• В 2012 году появился Hexlet — одна из первых русскоязычных платформ с практико-ориентированными курсами по программированию. Особенность: выполнение заданий в реальной среде разработки через браузер. Платформа до сих пор работает: на текущий момент 80% выпускников трудоустраиваются в IT, согласно исследованию ВШЭ. В 2012 этот показатель был еще выше.
• «Нетология» (основана в 2011) к 2013 году запустила курсы по веб-разработке с акцентом на JavaScript и Python, сотрудничая с российскими tech-компаниями. Их модель включала менторство и проектные работы.
• В 2013 году стартовал Stepik — платформа с открытыми курсами от ведущих вузов (ИТМО, МФТИ). Особенность: интерактивные задачи с автоматической проверкой кода, что было прорывом для местного рынка.

Курс «Введение в Linux» от Stepik (2014) за полгода собрал 50 тыс. студентов — рекорд для Рунета. Задания включали настройку виртуальных серверов, что сразу применялось в работе.

Эти проекты заложили основу для бума EdTech в России после 2015 года, доказав, что онлайн-формат может давать актуальные навыки быстрее вузов.

Типичный разработчик среднего уровня в 2014 году:

• понимал принципы REST API;
• начинал осваивать основы DevOps с появлением Docker в 2013;
• экспериментировал с микроконтроллерами вроде Arduino или Raspberry Pi, создавая собственные IoT-устройства.

В профессиональной среде начал формироваться консенсус о том, что PHP устаревает для сложных коммерческих проектов.

2015-2019: Эра больших данных и облачных технологий

Аппаратные возможности сделали очередной рывок вперед. Многоядерные процессоры Intel i7 и AMD Ryzen стали стандартом для рабочих станций. 16 ГБ оперативной памяти перестали быть роскошью, а мониторы с разрешением 4К стали доступны широкому кругу разработчиков. В 2015 году появился Visual Studio Code, который быстро обогнал по популярности Sublime Text и Atom благодаря удачному сочетанию функциональности и производительности.

Языковая экосистема продолжила развитие. TypeScript, представленный в 2014 году, предложил решение проблемы масштабируемости JavaScript-кода в крупных проектах. Go от Google, созданный еще в 2009, нашел свою нишу в разработке микросервисов и инструментов оркестрации вроде Kubernetes (2015). Rust от Mozilla начал завоевывать доверие системных программистов благодаря уникальной системе владения памятью.

JavaScript-сообщество столкнулось с первыми серьезными проблемами. В 2016 году инцидент с пакетом left-pad показал уязвимость экосистемы npm — удаление одного небольшого модуля привело к сбоям в работе тысяч проектов по всему миру. Это заставило разработчиков задуматься о зависимости от сторонних библиотек.

Типичный senior-разработчик в 2019:

• разбирался в микросервисной архитектуре и понимал, как избежать vendor lock-in (привязки к поставщику) при работе с облачными провайдерами;
• имел опыт работы с React или Vue.js;
• знал, что понимание принципов работы алгоритмов становится менее важным, чем развитие soft skills для работы в команде.

Ключевые технологии этого периода включали Kubernetes, который стал стандартом де-факто для оркестрации контейнеров, а также TensorFlow (2015) и PyTorch (2016), открывшие эру машинного обучения для широкого круга разработчиков. Появились первые серьезные инструменты для работы с большими данными — Apache Spark, Hadoop.

Ключевой момент. В 2016 году Netflix раскрыл детали своего перехода на облачную инфраструктуру AWS. Компания полностью перенесла все сервисы — от рекомендательной системы до биллинга — в облако за семь лет. Главным триггером стала катастрофа 2008 года, когда три дня простоя дата-центра оставили 8,4 млн подписчиков без доступа к сервису. Миграция потребовала перепроектирования архитектуры: инженеры разбили монолит на 500 микросервисов и внедрили Chaos Monkey — инструмент для тестирования отказоустойчивости, который случайно отключал серверы в продакшене.

Этот кейс стал хрестоматийным примером cloud-native подхода. Облачные технологии стали активно использоваться в разработке, а обращение с ними — обязательным навыком для прогеров.

2020-2024: AI-assisted разработка и новые парадигмы

Пандемия COVID-19 ускорила переход на удаленную работу. Программисты по достоинству оценили макбуки на чипах M1 (2020) за их энергоэффективность и производительность. Домашние офисы оснащались 32-дюймовыми 4К-мониторами и механическими клавиатурами, ставшими своеобразным профессиональным стандартом.

Языковая палитра продолжала обогащаться. Rust официально вошел в ядро Linux в 2022 году, подтвердив свой статус системного языка нового поколения. Zig появился как современная альтернатива «C» с акцентом на безопасность. WebAssembly (Wasm) позволил запускать ресурсоемкие приложения прямо в браузере, открыв новые возможности для веб-разработки.

Искусственный интеллект начал проникать в повседневную работу программистов. GitHub Copilot на базе GPT-3, представленный в 2021, изменил сам процесс написания кода, предлагая контекстные подсказки. Low-code платформы вроде Retool упростили создание внутренних инструментов для бизнеса.

Типичный lead-разработчик в 2024 году:

• умел эффективно работать в гибридных командах (офис + удаленка);
• автоматизировал рутинные задачи через ChatGPT API;
• следил за развитием квантовых вычислений, хотя практическое применение пока оставалось ограниченным.

Ключевой момент. В 2023 году GitHub Copilot, разработанный совместно с OpenAI, стал катализатором перемен в индустрии. За первый год после релиза инструмент использовали более 1,3 млн разработчиков — каждый десятый подписчик GitHub. Система анализировала контекст кода и предлагала целые функции: например, при написании SQL-запроса она автоматически генерировала соответствующую модель данных на Python. Amazon внедрил аналогичный инструмент Amazon Q Developer для внутренних команд — по заявлению CEO Энди Джесси, это сэкономило компании 4,500 человеко-лет работы и $260 млн ежегодно.

Но были и курьезы. В 2024 году разработчик из Берлина случайно отправил в продакшен код, полностью сгенерированный Copilot. Система использовала фрагмент из GPL-лицензированной библиотеки, что нарушило политику компании по открытому ПО. Инцидент заставил пересмотреть процессы ревью: теперь 78% команд требуют ручной проверки AI-кода перед мержем (слиянием).

Параллельно выяснилось, что Copilot в 40% случаев предлагает уязвимый код при работе с СУБД — это привело к взлому API стартапа через SQL-инъекцию. Такие кейсы показали, что ИИ пока не заменяет программистов, а требует от них новых навыков — критического анализа машинных предложений и понимания юридических аспектов кода.

2025: Современное состояние профессии

Современные рабочие станции программистов оснащены ноутбуками с процессорами Apple M4 (3 нм) или Windows-машинами на Snapdragon X Elite. Мониторы с разрешением 8К используются для разработки AR-приложений, а OLED-экраны с HDR стали стандартом для работы с графикой. Появляются первые экспериментальные IDE с нейроинтерфейсами, способные предсказывать код на основе анализа мозговой активности.

Среди языков программирования выделяется Mojo (2023) — «Python для GPU», набирающий популярность в сфере машинного обучения. Carbon как потенциальный наследник C++ пока остается в тени Rust. Квантовые языки вроде Q# и Cirq интересуют в основном энтузиастов и исследователей.

Профессия претерпела значительные изменения. ИИ стал не конкурентом, а помощником — по некоторым оценкам, около 60% рутинного кода в 2025 году (тесты, документация) генерируется автоматически. Знание английского языка стало важнее знания сложных алгоритмов — без него невозможно эффективно работать с современными AI-инструментами. Понятие «fullstack-разработчик» трансформировалось — теперь оно подразумевает владение фронтендом, одним бэкенд-языком и основами машинного обучения.

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

Будущее обещает новые трансформации. К 2030 году нейроинтерфейсы смогут заменить традиционные устройства ввода, а квантовые компьютеры — перевернуть основы криптографии. Но пока актуальными остаются проверенные временем принципы: изучать перспективные технологии (вроде Rust и Mojo), осваивать работу с ИИ и, конечно, совершенствовать главный навык любого программиста — умение быстро и грамотно гуглить.

Ты уже программист, если читаешь это! Больше о кодинге тут.

Его тезис прост: Kubernetes работает, но технический долг и архитектурные ошибки накапливаются — и пора перезапустить проект как Kubernetes 2.0.

В посте инженер прошёлся по истории Kubernetes с момента первых коммитов в 2014 году до текущего состояния, а затем предложил перечень изменений, которые могли бы серьёзно упростить работу с платформой — особенно для малых и средних команд.

Что работает хорошо в Kubernetes

• Масштабируемость контейнеров — от Docker Compose к кластерам из тысяч машин;
• Самовосстановление — ментальная модель «петы → скот → UUID» с переходом к полной заменяемости нод;
• Джобы и фоновые задачи — больше никакого cron01;
• Простой сервис-дискавери — DNS и стабильные IP без танцев с IP-таблицами.

Но что пора менять

1. YAML нужно заменить на HCL

Автор критикует YAML за отсутствие типизации, частые ошибки из-за отступов и странное поведение (вроде «проблемы Норвегии», где 'NO' парсится как false). Взамен он предлагает HCL — тот самый язык, что используется в Terraform. Он типизирован, валидируем, поддерживает выражения, условия, шаблоны и модули.

2. Нужно позволить заменить etcd

Автор предлагает сделать абстракцию для хранилища состояния и разрешить использовать альтернативы, вроде kine или dqlite, особенно для малых кластеров или edge-устройств.

3. Helm устарел — нужен родной пакетный менеджер

Helm вырос из временного решения и теперь тянет за собой ворох проблем: хрупкие шаблоны, сложные зависимости, неработающий механизм проверки, нестрогое семантическое версионирование. Взамен предлагается создать KubePkg — систему управления пакетами с:

• семантическими зависимостями,
• встроенной поддержкой CRD и состояний,
• политиками обновлений и резервным копированием,
• полноценной схемой конфигураций, проверкой и подписями.

4. IPv6 по умолчанию

Модель с NAT, приватными IPv4-диапазонами и ручной настройкой стала тормозом. Автор предлагает сделать IPv6 дефолтом, чтобы:

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

«По-настоящему важны не только возможности, а то, что стоит по умолчанию», — пишет автор. И предлагает не ждать, пока сторонние проекты исправят архитектурные слабости Kubernetes, а включить необходимые фичи в саму платформу.

Полный текст манифеста можно прочитать в материале по ссылке.

Этап 1: Простой MVP за $0

Изначально нужно создать максимально простое приложение для управления задачами: веб-страница с несколькими категориями и возможностью добавлять таски. На фронте разработчик использует библиотеку Shad CN UI, а на бэке — Flask. Данные хранятся просто в словаре Python. Все приложение — это один файл. Оно запускается в Docker-контейнере через docker compose.

Это MVP работает локально на компьютере разработчика и рассчитано на одного пользователя. Такой подход позволяет всё упростить, но при перезапуске контейнера все данные будут утеряны. Правда, чтобы получить прибыль, этого недостаточно.

Этап 2: Инфраструктура на $30

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

• База данных: PostgreSQL.
• Веб-сервер: Nginx для проксирования запросов и избавления от портов.
• Аутентификация: авторизация через JWT и интерфейсы входа и регистрации на фронтенде.

Все эти компоненты подключаются к существующему приложению через docker-compose.yml. Благодаря этому теперь можно запускать приложение на localhost, а не по порту, и все будет работать как полноценное веб-приложение. Размещение такой системы на бесплатном облачном тарифе или VPS обойдётся в пределах 30 долларов.

Этап 3: Допиливание до $100

Разработчик добавляет допфункции:

• Уведомления по email: вместо стороннего API — система очередей с RabbitMQ и воркером, который отправляет письма.
• Обновления в реальном времени: WebSocket’ы для синхронизации задач на разных устройствах.
• Кэширование: Redis для хранения данных в памяти, что значительно ускоряет работу.

Также подключается Docker Build Cloud — сервис для параллельной сборки контейнеров и шаринга кеша между проектами. Это повышает производительность и ускоряет разработку.

Теперь в системе работает очередь заданий, кеш, WebSocket-сервер, SMTP и полноценная база данных. Все эти компоненты увеличивают инфраструктурные затраты до примерно $100 в месяц.

Этап 4: Мониторинг и масштабирование за $500

Разработчик внедряет:

• Логирование: стек ELK (Elasticsearch, Logstash, Kibana).
• Мониторинг: Prometheus и Grafana.
• Горизонтальное масштабирование: добавляются реплики некоторых сервисов и балансировка нагрузки через Nginx.

Эти инструменты позволяют отслеживать метрики, визуализировать логи, следить за состоянием приложений и быстро выявлять сбои. Инфраструктура становится ближе к корпоративному уровню. Стоимость такого комплекса достигает уже около 400–500 долларов в месяц.

Этап 5: Целых $2000 долларов

Разработчик решает перейти на Kubernetes и развернуть приложение в разных дата-центрах по всему миру. Для управления трафиком используется глобальный балансировщик нагрузки (например, Cloudflare). А чтобы все работало стабильно, внедряются:

• Postgres с репликацией в реальном времени,
• Redis для быстрой отдачи данных.

Сейчас без ИИ приложение уже не имеет смысла. Поэтому разработчик решает добавить серверлесс-функции с категоризацией задач, приоритетами и предложениями на основе поведения пользователей, а также с использованием обработки естественного языка для создания тасков. Также подключаются правовые ограничения — поддержка GDPR и CCPA.

Для мониторинга:

• Jaeger — для распределённой трассировки,
• ELK Stack — для логов,
• Grafana + PagerDuty — для алертов и инцидентов.

Вишенка на торте — план восстановления после катастроф: бэкапы, автоматическое переключение на другие регионы и подготовка команды.

Хотя вся система началась с одного Python-файла и простого UI, шаг за шагом разработчик добавлял в нее компоненты, которые делают её пригодной для реального продакшена: защита, масштабируемость, отказоустойчивость, мониторинг, кеширование и очереди. И оно вполне может стоить несколько сотен или даже тысяч долларов в месяц при развертывании в облаке.

Сделайте минимальный Docker-образ, не ломая прод

Большинство Docker-образов в проектах содержат больше данных, зависимостей и инструментов, чем требуется для работы приложения. Это приводит к избыточному объёму, медленной сборке и повышенным рискам безопасности. Умение собирать минимальный образ — один из базовых навыков работы с Docker, который напрямую влияет на стабильность и скорость развёртывания.

Начать стоит с multi-stage сборки: на первом этапе — установка зависимостей и сборка, на втором — только нужные артефакты. Это позволяет исключить лишние файлы и утилиты из финального образа. В качестве базового слоя лучше использовать alpine, distroless или даже scratch, если вы точно понимаете, какие бинарники и библиотеки требуются приложению.

Хорошая практика — использовать утилиты docker history и dive для анализа того, какие файлы и слои попали в образ. Если размер превышает ожидания, стоит проверить, не остались ли во внутреннем слое временные файлы, dev-зависимости или директории кэша.

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

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

Попробуйте контейнизировать то, что изначально не предназначалось для этого

Работа с Docker чаще всего начинается с бэкенд-приложений, сервисов и утилит, которые изначально проектировались как самостоятельные процессы. Они хорошо вписываются в модель контейнеров: запускаются из CLI, работают в изоляции, не требуют доступа к UI или железу. Но стоит выйти за эти рамки — начинаются сложности.

Попробуйте упаковать в контейнер любую графическую программу. Технически это возможно: X11 или Wayland можно пробросить через сокет, устройства передать через volume, окружение прописать вручную. Но на практике вы столкнётесь с рядом ограничений: отсутствие звука, глюки интерфейса, ошибки в драйверах, проблемы с доступом к GPU или нестабильное поведение при рендеринге.

В этом упражнении ценен не сам результат, а путь. Вы увидите, как устроена изоляция в Docker, почему графические приложения не работают «из коробки» и где находятся реальные границы контейнеризации. Контейнер — это не виртуальная машина, у него нет полноценного init, драйверов или прямого доступа к оборудованию. Многие фичи, которые работают локально, в контейнере требуют дополнительных танцев с бубном.

Такая практика особенно полезна, если вы имеете дело с devtool'ами, UI-обвязкой или тестированием в headless-средах. Понимание, что именно ломается и почему, позволяет более точно проектировать окружение и избегать архитектурных ловушек в будущем.

Соберите базовый образ с нуля

Когда разработчик пишет FROM node или FROM ubuntu, он автоматически получает десятки слоёв, библиотек и утилит, о которых, скорее всего, не задумывается. Это удобно, но не даёт понимания, как вообще работает контейнер на низком уровне. Попробуем разобраться.

Укажите в Dockerfile FROM scratch — и не увидите ни bash, ни glibc, ни стандартных каталогов. Вам придётся самостоятельно добавить всё необходимое: бинарник, зависимости, библиотеки, конфигурацию. Если пишете на Go, задача упрощается: можно собрать статически слинкованный исполняемый файл и скопировать его в образ. Для других языков, особенно тех, что зависят от динамических библиотек или рантайма (например, Python или Node.js), придётся вручную подтягивать зависимости.

Такая практика заставляет иначе взглянуть на структуру контейнера. Вы начнёте понимать, чем отличается CMD от ENTRYPOINT, зачем в некоторых образах используется sh -c, и что произойдёт, если не задать WORKDIR. Вы столкнётесь с ошибками «no such file or directory» даже тогда, когда файл вроде бы существует — потому что в контейнере не хватает нужной libc.

Отдельный повод для размышлений — Alpine. Его любят за размер и минимализм, но он использует musl вместо glibc, и не всё с ним работает корректно. В процессе сборки на практике увидите, почему иногда проще остаться на Debian Slim, чем пытаться адаптировать всё под Alpine.

Этот эксперимент не нужен для продакшена — он нужен вам, как разработчику. Прокачивает понимание, как устроен Docker, что по-настоящему важно приложению для запуска, и какие зависимости вы добавляете бессознательно.

Делайте разные варианты Docker-образов

Хороший Dockerfile — тот, который гибко адаптируется под разные сценарии: продакшен, отладку, тестирование, запуск на ARM или x86. Если вы умеете собирать только один универсальный образ — вы ещё не освоили Docker по-настоящему.

Попробуйте собрать сразу несколько версий своего образа: на Debian и на Alpine, с минимальным размером и с полным набором утилит, для amd64 и arm64. Добавьте build-аргументы (ARG) — они позволяют передавать параметры на этапе сборки: выбрать базовый образ, включить или выключить зависимости, задать переменные окружения. Используйте RUN if или шаблонизацию через Dockerfile.template, чтобы варьировать поведение без дублирования кода.

Вот типичный пример: в режиме отладки вам нужен образ с установленным curl, vim, доступом к логам и расширенной трассировкой. А в продакшене — максимально облегчённый, с удалёнными временными файлами, сжатым слоем и только необходимыми бинарниками. Один и тот же проект — два разных образа. Добавьте сюда ещё поддержку разных архитектур (multi-arch build через --platform), и вы выйдете на уровень CI/CD, где из одного пайплайна собирается три-четыре артефакта.

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

Поиграйте в «А что если запустить чужой (небезопасный) код?»

Представьте задачу: вам нужно запустить код, который написал кто-то другой. Вы не уверены, что он безопасен. Это может быть скомпилированный бинарник, питоновский скрипт или даже npm-зависимость с подозрительным хуком. Где-то в коде может быть rm -rf /, попытка выйти за пределы контейнера, установить рутовый доступ или просто майнить крипту. И теперь этот код запускается на вашей машине — внутри Docker.

Кажется, контейнер защитит? Не всегда.

Docker не является полноценной песочницей. По умолчанию контейнер может обращаться к файловой системе, к ядру и к хостовым ресурсам — особенно если вы запускаете его с --privileged или без ограничения пользователя. Даже docker run -it ubuntu работает от root внутри контейнера, что уже создаёт риски.

Если вы действительно хотите запустить небезопасный код, нужно жёстко ограничить контейнер:

• отключить права root (через --user);

• запретить модификацию файловой системы (--read-only);

• отобрать лишние возможности ядра (--cap-drop=ALL);

• включить seccomp-профиль, AppArmor или SELinux;

• отключить доступ к сети или монтированию сокетов.

Список можно продолжать. Главное — понять, что Docker по умолчанию не даёт изоляции на уровне VM. Если вы работаете с кодом, которому не доверяете, этого может быть недостаточно.

Это упражнение учит думать о безопасности как о процессе. И особенно важно пройти его, если вы когда-нибудь планируете запускать user-generated code: плагины, кастомные скрипты, пайплайны CI. Только на практике становится ясно, где заканчиваются возможности Docker и начинаются границы настоящей песочницы.

Работайте без Docker CLI

Если убрать Docker CLI — что останется? Больше, чем кажется.

Docker ― это не единый монолит. Он работает поверх набора инструментов и стандартов: buildkit, containerd, спецификация OCI. CLI просто прячет эту архитектуру за удобными командами: docker build, docker run, docker push. Но всё, что кажется магией, можно повторить вручную.

Попробуйте отказаться от docker как от инструмента. Сконфигурируйте buildctl напрямую и соберите образ без Dockerfile. Или вообще создайте его вручную: сформируйте структуру, описания слоёв, метаданные, манифест. Прочитайте спецификацию OCI Image Format и идите по ее шагам. Понадобится tar, sha256sum, немного JSON — и внимательность.

Образ собрали? Отлично. Теперь отправьте его в реестр без docker push. Используйте oras, skopeo или curl с аутентификацией и ручной отправкой слоёв по HTTP API. Узнаете много нового: как работает digest, что такое manifest list и зачем нужны media types.

Наконец, запустите контейнер без docker run. Через ctr, runc или даже напрямую с помощью systemd-nspawn.

Зачем это нужно? Чтобы воспринимать Docker глубже. Так, вы понимаете, как устроен pipeline сборки и запуск контейнера, и точнее управляете им. Особенно это важно в продакшн-среде: когда образы не собираются, push падает, реестр отвечает 403, а пайплайн горит.

Ты точно программист, если читаешь это! Больше мемов, инсайтов и боли кодеров тут.

Монолитная архитектура

Исходная схема:

• Backend: Spring Boot
• Frontend: Angular

Так как у меня уже был арендованный VDS, я зарегистрировал домен у одного известного провайдера, а хостил сайт уже на VDS сервере. Для простоты интегрировал Angular-сборку в Spring Boot как статику через frontend-maven-plugin. Всё собиралось в один JAR. Почему так? Ранее уже был такой опыт, и я решил пойти этим путем.

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

• Отсутствие SSR в Angular негативно влияло на SEO;
• Ошибка в Angular ломала Maven-сборку;
• Сложно поддерживать и масштабировать.

Переход на микросервисы

Было принято решение разделить фронтенд и бэкенд на отдельные сервисы и использовать микросервисный подход с SSR для Angular:

Новая структура:

• Backend: Spring Boot
• Frontend: Angular Universal (SSR)
• Инфраструктура: Docker Compose, Nginx, HTTPS

Docker, Nginx и запуск

Создана базовая структура docker-compose.yml:

И соответствующий Nginx:

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

• Дублирование API-префиксов: /api/api/endpoint → Решение: корректировка proxy_pass и URL в Angular
• Редиректы на POST: Spring добавлял лишние слеши → Решение: правильные аннотации и настройка Nginx
• 405 Method Not Allowed → Решение: использовать @PostMapping
• Docker-сети → Решение: задать общую сеть в docker-compose.yml

Безопасность: HTTPS, SSL, CORS

Чтобы сайт открывался по имени с панели провайдера для моего домена, значения DNS-сервера оставил без изменений (провайдер предоставляет их бесплатно), а для ресурсной записи @ и www указал ip адрес своего хостинга. Так как провайдер домена бесплатно предоставил SSL-сертификаты (Let's Encrypt), то как я их интегрировал:

Скачал с панели провайдера и перенес на хостинг такие файлы:

domain.crt — сертификат

domain.key — приватный ключ

ca_bundle.crt — цепочка доверия

Добавил в Nginx такую запись для HTTPS:

Но при обращении к сайту по https конечно же возникли ошибки. А именно: в логах Nginx были ошибки на SSL_CTX_use_PrivateKey_file. Оказалось формат был PKCS#7, а требовался PEM. Конвертировал через OpenSSL:

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

К тому же всегда следует проверять логи Nginx (error.log), там могут находится ответы на вопросы, почему сайт не работает.

На стороне Spring Boot были CORS-проблемы, решено так:

Атаки ботов и защита

После запуска сайта в логах Nginx стали появляться тысячи запросов от ботов, ищущих уязвимости WordPress, PHPMyAdmin и других популярных утилит, хотя мой сайт работает на Java/Angular. Пример лога:

45.155.205.213 - - [01/Jan/2023:04:12:11 +0000] "GET /wp-login.php HTTP/1.1" 404 153

Добавлен фильтр в nginx.conf:

Финальная конфигурация

После всех настроек мой сайт работает и полностью функционирует. Конфигурация сильно изменена по сравнению с первоначальной. Вот как они выглядят сейчас.

docker-compose.yml

nginx.conf

Dockerfile backend

Dockerfile frontend

Разделение сервисов улучшило поддержку и масштабируемость, к тому же, я получил ценные знания. Надеюсь, статья будет полезна тем, кто разворачивает подобные конфигурации на Java и Angular.

Первые две части лежат здесь: рабочее место/облако и Fedora Core/mise.

Начало проекта и утилита make

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

Первый — классический пайплайн — это утилита make. Обычно она используется для сборки программ из исходного кода. На самом деле make хорошо подходит для решения сразу нескольких задач.

• Первая задача — отслеживание зависимостей одних файлов от других, например, при изменении сервиса пересобрать только соответствующий контейнер.
• Вторая задача, легко реализуемая через make — сборка в один файл много команд или скриптов, чтобы удобно их организовать. Как правило, сборка образа, его загрузка в репо, удаление временных файлов и прочее делается несколькими рутинными командами. Точно так же можно поместить в Makefile команды запуска сервисов и тестирование приложения локально.
• Если эти этапы прошли успешно, можно выполнить коммит кода в репо проекта, сделать деплой в dev или stage environment. В github actions это называется jobs и steps. В make такая группа команд называется целью, она указывается параметром при вызове.

Так, несмотря на разную терминологию, по сути можно создать полноценный пайплайн для современного проекта с контейнеризованными сервисами.

Разбираемся на практике

Возьмём для примера проект с прокси сервером traefik и бэкендом на golang из репозитария awesome-pods. Этот репо задуман как форк замечательного проекта awesome-compose, в котором собраны конфиги docker compose для 41 самого популярного сервиса. Я же пытаюсь сделать что-то похожее для манифестов podman. Приглашаю к сотрудничеству начинающих девопс — сможете поучаствовать в открытом проекте, заработать почётные гитхаб-бейджи и улучшить своё резюме. Подробнее — здесь.

Мой проект в интересном положении: сделаны манифесты для нескольких сервисов, опробованы описанные выше подходы для миграции конфигов compose.yaml в манифесты kube.yaml. Но захотелось большего: а почему бы не сделать сразу пайплайны для тестирования, коммита в апстрим, деплоя и прочее. Зайдём в каталог traefik-golang и создадим пару мейк-файлов. Для начала сделаем всё это локально, начнём с make_compose:

Этот файл уже в истории, равно как и соответствующий README.md, привожу его для примера. Так как я делаю конфиги сразу для двух платформ — docker и podman, для включения соответствующего Makefile’а нужно сделать линк на него: ln -s make_compose Makefile.

Отлично, основную идею обсудили, идём дальше. В docker’е есть замечательная опция context, позволяющая работать с любыми серверами, где настроен доступ. В нашем случае список контекстов выглядит так:

Здесь я использовал простейший хак — сделал копию дефолтного контекста с именем localhost. Теперь мы можем сделать наш пайплайн способным на удалённый деплой. Достаточно прописать в /etc/hosts имя и адрес нашего dev сервера. Вот новая версия make_compose:

Поясню немного подробнее.

• Самая первая строка — стандартное объявление списка целей.
• Строки 2-4 задают дефолтное значение переменной, если оно не задано в текущем env.
• В хелп — строки 5-10 — добавлено предупреждение о текущем контексте, он задаётся в глобальной переменной, например, export DKR_CONTEXT=localhost для локального контекста.
• Также добавлена цель commit в репо — строки 17-21 — после выполнения цели test.
• Test — строки 31-32 — в свою очередь, выполняется для текущего контекста, см. хак #1. Имя контекста должно совпадать с именем хоста нашего dev-сервера.
• Добавлена также цель clean: очистка старых образов с локальном репо,и зависимости в цель up. Здесь убеждаемся, что образ пересобран и старые контейнеры остановлены.

Отлично, пайплайн для докера работает. Пробуем сделать то же самое для подмана. Здесь нас ждёт сюрприз, попробую рассказать в стиле прямого репортажа. Первоначально наш пайплайн для podman выглядел вот так:

В строке 5 определяются зависимости: target back соберёт исполняемый файл только в том случае, если код main.go или сам make_pods новее уже собранного бинарника.

Строка 6 удаляет backend контейнер с едва заметным знаком минус -, чтобы игнорировать ошибку, если контейнер с именем backend не существует.

Строки 7–10 создают контейнер с именем backend из пустого (scratch) контейнера — команды buildah следуют обычным командам Dockerfile, но в нижнем регистре: FROM -> from, COPY -> copy, RUN -> run, ENTRYPOINT -> config –entrypoint и т. д. Здесь вы видите основное отличие от традиционного docker buildx подхода — вы работаете в двух контекстах одновременно: в локальном контексте, используя установленный компилятор go, и в контексте контейнера, копируя файлы в/из контейнера, запуская команды внутри контейнера и т. д. Другая новая возможность buildah — вы можете собирать образ шаг за шагом, то есть отлаживать процесс сборки.

Строка 8 компилирует main.go в исполняемый файл back с соответствующими флагами.

Строка 11 создаёт из контейнера новый образ (image) с тегом backend:latest.

Цель up — строка 16 — зависит от цели down — строка 14, — то есть она сначала останавливает pod и удаляет контейнеры, если они всё ещё запущены, затем запускает новый под.

Цель down в строке 15 подставляет глобальную переменную $XDG_RUNTIME_DIR из env пользователя в kube.yaml, используемый далее в podman kube командах, принимая новый манифест со стандартного ввода. Это также специфика podman — он работает полностью в пространстве пользователя, контейнеры взаимодействуют через собственный podman.sock. Таким образом, делаем пайплайн независимым от UID.

В подмане есть фунциональность наподобие docker context, под другим именем, в подкоманде system connection:

Первым в списке стоит настроенная в прошлой статье ВМ. Пока искал правильные опции для создания коннекшена (aka контекст в докере), столкнулся с подсказкой от подмана — «создайте сначала машину», а именно:

Выполнил эти рекомендации, подман выкачал, настроил и добавил два новых коннекшена для новой ВМ. Какой же меня ждал сюрприз, когда я стал смотреть, что же это за machine. Во-первых, в моём HOME появились новые файлы и каталоги:

Во-вторых, это полноценная ВМ fedora coreos:

Конечно, приятно, что моё мнение совпало с мнением авторов подмана, точнее, со стратегией RedHat — fedora coreos наиболее подходящая система для контейнерных приложений. С другой стороны, ВМ в подмане крутится полностью внутри пространства пользователя. У меня уже настроена почти такая же для удалённой работы всей команды разрабов. Решено: останавливаем новую виртуалку и правим мейкфайл для подмана по образцу компоуза, делаем пайплайн для деплоя и локально, и на удалённый дев-сервер.

Но прежде нам понадобится ещё один хак #2. Если в случае докера переключение контекста можно было сделать любой переменной, то для подмана между локальным соединением через сокет и удалённым, через uri:ssh, имя переменной фиксировано CONTAINER_HOST. Вот как выглядит пайплайн make_pods.v1, настроенный и для локальной сборки, и для деплоя в наш дев-сервер:

По большей части цели мейкфайла остались теми же, но для удалённого деплоя настраиваем переменную export CONTAINER_HOST=ssh://dev@fc42dev:22/run/user/1001/podman/podman.sock — берём её из коннекшена, она служит переключателем между локальным и удалённым контекстом. Для локального контекста эту переменную надо удалить: unset CONTAINER_HOST. Команды в строках 19, 21 и 23 — это обычные команды шелла, они также меняются на локальное либо удалённое исполнение, переопределяются на основе этой же переменной CONTAINER_HOST.

Как заметил внимательный читатель, в цели back исчезла сборка контейнера утилитой buildah. Как и для docker compose, используется возможность самого подмана создавать образы на основе Containerfile, он же Dockerfile, эти названия синонимичны. Это намёк: пора отвыкать от слова докер, контейнеры уже давно стали основой облачных вычислений, для них созданы сотни приложений, например, CNCF и общепризнанные стандарты.

Принципиальный вопрос о контейнерах

Основное их преимущество — новый способ доставки приложений в облака, решение проблем с зависимостями, версиями библиотек, фреймворков и проч. Сборка контейнеров в контейнерах — побочный эффект облачных сервисов Github, Gitlab и других, с одной стороны, и ограничения Docker — с другой. Он не умеет, в отличие от подмана, точнее, от его сопутствующей утилиты buildah, выполнять билд и создавать образ, используя локальное окружение.

Основная проблема сборки образа внутри контейнера — неэффективное использование кэша. Да, появились возможности как-то сохранять объемные загрузки внешних библиотек, модулей: это опции --mount=type=cache для некоторых языков. Но, во-первых, эти возможности используются далеко не всегда. Во-вторых, опции для кэширования отличаются в podman и buildah, см. podman-build(1), придётся делать отдельный Containerfile. В-третьих, эффект от такого кэширования минимален. Предлагаю замерить время сборки, сделав ещё одну, третью версию пайплайна. Сначала соберём команды для buildah в отдельный файл:

и поправим пару строк в пайплайне:

Уточню условия нашего эксперимента — мы настроили одинаковую среду разработки с помощью утилиты mise (предыдущая статья) на нашем дев-сервере и у каждого из разрабов команды. Репозитарий git использует этот же дев-сервер, доступ к репо и серверу по ключу, парольный доступ закрыт. Пайплайны настроены как для локальной сборки, так и на дев-сервере. Перед запуском 3-й версии пайплайна на дев-сервере нужно сделать коммит изменений в репо — buildah не знает о коннекшенах, работает с кодом в текущем каталоге (строка 1): после логина на сервер переключается в корень проекта. Предварительно выкачиваем образ компилятора go для сборки в контейнере — это вполне честно, мы же выкачали и настроили компилятор golang заранее. Замеряем:

Мы получили 10+-кратный выигрыш по времени сборки образа для подмана. Абсолютные времена не важны, также не влияет, запускали мы сборку локально или на дев-сервере — мы сравниваем только билд в контейнере и в настроенном локальном окружении. Третье измеренное время — сборка в Docker. Он умеет собирать только в контейнере, для него настроили кэширование в Containerfile:

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

Ещё замечание: конечно, образы, собираемые buildah, совместимы с Docker, их можно использовать в конфигах compose.yaml. Но для этого надо настроить репозиторий образов и сначала загрузить образ в него. Локальные репозитории отличаются: Docker использует общий репо для всех пользователей — Docker Root Dir: /var/lib/docker, а в подмане всё хранится в домашнем каталоге пользователя — graphRoot: /home/$USER/.local/share/containers/storage.

Как я предположил в самом начале, мы попробовали вариант с гипотетической идеальной командой разрабов, работающей в Линукс и умеющей в make. А как быть обычному девопсу с разношерстой командой, где кто-то сидит на Винде, а кто-то ни за что не откажется от привычного Макбука на M4? Есть вариант и для этого случая. Пусть они пишут код и тестируют его как им нравится, а в нашем репо на дев-сервере мы сделаем хак #3, а именно git hook и bare репозиторий — githooks(5), выполняющий наши цели сборки и старта приложения при коммите в репо.

Для этого на пару минут придётся стать безжалостным хакером, удаляющим лишнее и открывающим скрытые возможности гита. Выполняем следующие шаги:

1. Заходим под юзером dev на сервер, создадим пустой каталог, например, mkdir -pv ~/bare/t0. Это станет новым GIT_DIR, зайдём в него и выполним cd ~/bare/t0;git init --bare.
2. Видим, что файлы, обычно спрятанные в каталоге .git, лежат прямо в корне. Сделаем дополнительно каталог для логов mkdir logs. Переходим в каталог hooks и создаём файл, где укажем команды выполнения при каждом изменении в репо.

Закомментированные строки 3, 8, 9 полезны при отладке пайплайна. Строки 4 и 5 задают, что есть, собственно, репозиторий, переменная GIT_DIR и переменная WORK_TREE (куда будут записываться файлы проекта). В цикле от строки 6 до 14 читаются и обрабатываются три переменные, с которыми гит вызывает этот хук. Строка 11 принимает все изменения в репо и обновляет WORK_TREE — всё то, что гит обычно делает в общем каталоге, как видим, в bare репо они разные. Далее, в 12 строим имя лога и строка 13 — собственно, пайплайн.

1. Идём в каталог, где расположен репо проекта. Без страха и сожаления удаляем старый и создаём новый под тем же именем: cd ~/src;rm -rf traefik-golang;mkdir traefik-golang.
2. Завершаем сессию на дев-сервере, возвращаемся на рабочий комп и заходим в репо проекта. Конечно, репо цел, клоны репо не так просто уничтожить, пока есть хотя бы одна копия. Теперь смотрим старые настройки git remote -v и удаляем их git remote remove fc42dev в моём случае. Создаём новый remote, указывая новый гит bare репо: git remote add bare.t0 dev@fc42dev:~/bare/t0. Это также нужно сделать всем разрабам в их локальных копиях.
3. Проверяем результат. Возможно, нужно сделать новый комит и push в новый remote. Стоит посмотреть подробнее, как изменился репо проекта на сервере: проверить логи в ~/bare/t0/logs, сравнить конфиги обычного репо проекта и на сервере, проверить, какие команды перестали работать в серверном репо. Например, в WORK_TREE не работают команды гит status; branch; commit; log. То есть наш хак #3 с git --bare не только позволил делать деплой на сервере, но также защитил репо от локальных изменений, а серверный репо всегда в чистоте и порядке. Можно редактировать код, но закомитить его только через обычный репо. Изменения на сервере удалятся после любого коммита.

Надеюсь, мне удалось показать, что пайплайны можно делать на основе древней забытой утилиты make. В следующей статье разберём, как можно добавить в наш скромный дев-сервер нечто похожее на монстров гит-сервисов, Gitlab и Github, создавать пайплайны, совместимые с github Actions, предоставить команде разрабов привычный интерфейс репо в браузере.

Неправильная настройка инфраструктуры в CI/CD пайплайне

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

Настройте окружение

Разные окружения (dev, staging, prod) часто имеют отличия в конфигурации (например, версии библиотек, лимиты ресурсов, настройки сетей). Например, переменные окружения, заданные для staging, перезаписываются в prod — зависимости ломаются.

• Используйте Infrastructure as Code (IaC) инструменты, такие как Terraform или Pulumi, для создания идентичных окружений.
• Храните конфигурации окружений в репозитории (например, в формате YAML или JSON) и применяйте их через CI/CD.
• Настройте переменные окружения через секреты (например, HashiCorp Vault, AWS Secrets Manager) и убедитесь, что они не перезаписываются случайно.

Разворачивайте по стратегии

В Kubernetes, например, при неверной конфигурации стратегии возможны простои. Pods могут быть удалены до того, как новые успеют стартовать, или новые версии вообще не будут работать.

• В Kubernetes используйте RollingUpdate с настройками maxSurge и maxUnavailable, чтобы новые поды стартовали постепенно, а старые были постоянно доступны.
• Настройте readinessProbe и livenessProbe, чтобы Kubernetes не направлял трафик на неготовые поды.
• Ответственно подходите к настройке стратегии и выбору количества реплик.
• Для Helm-чартов фиксируйте версии (helm dependency update, helm package) и используйте helm upgrade --atomic для автоматического отката при сбое.

Например, в манифесте Deployment можно указать:

Избегайте race conditions

Параллельные процессы в CI/CD (например, одновременная сборка и деплой) могут вызывать состояния гонки.

• Настройте блокировки (locks) в CI/CD, чтобы не было параллельных деплоев в одно окружение (например, через environments в GitLab CI).
• Используйте атомарные операции в Helm и Server Side Apply в kubectl.

Обрабатывайте ошибки

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

• Регулярно тестируйте пайплайн на staging-окружении, симулируйте реальные сценарии деплоя.
• Проверяйте доступность сервисов после деплоя с помощью health-check скриптов.

Новую проверку можно, например, добавить так:

curl --fail http://any-app.example.com/health

Нет изоляции переменных окружения и секретов

Представьте: в staging-окружении используются тестовые ключи, а в продакшене — боевые. Но из-за ошибки в CI/CD пайплайне или конфигурации staging берет продовые credentials. Как итог — тестовое удаление данных в песочнице стирает боевую базу. Или еще хуже: токены утекают из-за слабых прав доступа к Secret Manager, и вас могут спокойно взломать. Ниже рассказываем, как это пофиксить.

Разделяйте секреты по окружениям

Если переменные окружения или ключи не разделены между dev, staging и prod, они могут быть случайно использованы в неправильном контексте.

• Храните секреты в Secret Manager (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, Kubernetes Secrets) с четким разделением по окружениям (например, пути secrets/staging/db, secrets/prod/db).
• Используйте префиксы или теги для идентификации окружения (например, STAGING_API_KEY, PROD_API_KEY).
• Настройте права доступа CD так, чтобы пайплайн мог подтягивать только секреты, которые относятся к текущему окружению.

Например, в Vault это настраивается так:

Не храните секреты в коде

Иначе утечка неизбежна.

• Уберите секреты из репозиториев и .env-файлов и используйте Secret Manager.
• Для Kubernetes используйте Secret-объекты или интеграцию с внешними менеджерами (например, External Secrets Operator).
• Проверяйте репозитории на утечки с помощью инструментов типа truffleHog или gitleaks.

Вот пример Kubernetes Secret:

Ограничивайте доступ

Это принцип Scoped Permissions — с помощью него можно снизить риски случайного или намеренного использования секретов.

• Используйте IAM-роли в облаке (например, AWS IAM Roles for Service Accounts) с минимальными правами.
  
• Ограничивайте доступ разработчиков к продовым секретам через RBAC или Vault-профили.

Вот AWS IAM-политика для staging:

Ротируйте ключи

Это поможет избежать ситуации, когда после инцидента или утечки ключи не обновляются.

• Настройте автоматическую ротацию ключей в Secret Manager (например, AWS Secrets Manager поддерживает ротацию через Lambda).
• После инцидента сразу же ротируйте скомпрометированные ключи и пересоздавайте секреты.
• Логируйте доступ к секретам для аудита (например, через Vault Audit Logs).

Неправильная настройка health-checks в Kubernetes или других оркестраторах

Неправильная настройка readinessProbe и livenessProbe в Kubernetes — это, можно сказать, классика. Вы обновляете сервис, поды запускаются, но сразу же помечаются как unhealthy. Причина — неправильный readinessProbe или livenessProbe. Например, путь /healthz больше не существует, или проверка уходит в таймаут из-за долгой инициализации. В результате: контейнеры бесконечно рестартуются, сервис недоступен, кластер в панике.

Разделяйте назначение проб

readinessProbe проверяет, готов ли под принимать трафик, а livenessProbe — не завис ли он. Если их смешать, можно ждать сбой, например, трафик пойдет на не до конца инициализированный сервис.

• Используйте разные endpoints для проб. Например, /health для readinessProbe (готовность сервиса) и /alive для livenessProbe (проверка зависаний).
• Настройте readinessProbe так, чтобы она возвращала 200 только после полной инициализации (например, подключения к базе).
• Для livenessProbe проверяйте минимальную работоспособность (например, ответ сервера без проверки внешних зависимостей).

Учитывай время инициализации

Сервис может запускаться медленно, и слишком строгие таймауты приведут к сбоям.

• Установите initialDelaySeconds с запасом, чтобы учитывать время прогрева (например, загрузку кэша или подключение к базе).
• Настройте timeoutSeconds и periodSeconds так, чтобы проба не завершалась слишком быстро, но и не крутилась вечно.
• Используйте failureThreshold для нескольких попыток перед пометкой пода как unhealthy.

Вот пример для сервиса с долгим стартом:

Добавьте grace period

Он дает сервису время корректно завершиться перед рестартом.

• Установите terminationGracePeriodSeconds в манифесте Deployment, чтобы под мог завершить запросы перед остановкой.
• Настройте preStop хук, если нужно выполнить действия перед завершением.

Тестируйте на staging

Проблемы с пробами часто всплывают только в проде, если staging не идентичен.

• Убедитесь, что staging-окружение повторяет прод по конфигурации и нагрузке.
• Добавьте автоматические тесты в CI/CD для проверки endpoints (/health, /alive) перед деплоем.
• Симулируйте реальные сценарии (например, медленный старт или сбой зависимостей) на staging.

В CI/CD можно добавить:

Неправильная работа с конфигурациями через Helm или Kustomize

Представьте: обновили Helm-чарт, но в values.yaml остались старые переменные, которые ломают новые настройки. Или Kustomize патчит не тот ресурс, и манифесты применяются с ошибками. В итоге: поды падают, сервисы недоступны, и никто не знает что делать. Рассказываем, что с этим делать.

Валидируйте Helm-чарты перед деплоем

Так можно найти ошибки до применения манифестов.

• Используйте helm template или helm install –dry-run для рендеринга манифестов и их проверки.
• Включите schema validation для values.yaml с помощью JSON Schema (поддерживается Helm v3.6+).
• Проверяйте манифесты через kubeval или kubectl apply –dry-run=server для подтверждения соответствия Kubernetes API.

Тестируйте Kustomize-конфигурации

Kustomize может патчить не то, что вы ожидали, если селекторы или структура неправильные.

• Прогоняйте kustomize build для генерации итоговых манифестов и проверяйте их перед деплоем.
• Используйте kubectl apply –dry-run=server -k . для валидации в кластере.
• Проверяйте селекторы патчей в kustomization.yaml на точность (например, name и namespace).

Управляйте версиями и структурой

Несогласованность версий чартов или манифестов приводит к неожиданным изменениям.

• Фиксируйте версии Helm-чартов в Chart.yaml и используйте точные теги (например, 1.2.3, а не latest).
• Храните values.yaml отдельно для каждого окружения (values-staging.yaml, values-prod.yaml).
• Для Kustomize используйте базовые манифесты и патчи, разделённые по окружениям (например, overlays/staging, overlays/prod).

Документируйте и мониторьте

Без документации сложно понять, что изменилось, а без мониторинга — почему упало.

• Ведите CHANGELOG.md для Helm-чартов и Kustomize патчей, описывая изменения в структуре и значениях.
• Логируйте команды деплоя (helm upgrade –debug, kubectl apply -k .) для отладки.
• Настройте мониторинг статуса подов через Prometheus, чтобы сразу видеть сбои из-за ошибок конфигурации.

Вот пример получения подробного лога helm:

Нет политики управления версиями артефактов

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

Используйте семантическое версионирование (semver) или уникальные теги

Так банально будет однозначность и отслеживаемость версий.

• Присваивайте образам теги по схеме semver (1.2.3), commit hash (abc1234) или временной метке (20250429-1345).
• Избегайте latest в продакшене — это бомба замедленного действия.
• В CI/CD автоматически генерируйте теги на основе версии приложения или Git commit.

Вот пример тег-образа:

docker build -t my-app:1.2.3 -t my-app:$(git rev-parse –short HEAD)

Фиксируйте версии в манифестах и пайплайнах

Immutable теги гарантируют, что деплой всегда использует ожидаемую версию.

• В Kubernetes манифестах указывайте точные теги вместо latest.
• Настройте CI/CD так, чтобы тег образа передавался в Helm или Kustomize как параметр.
• Используйте инструменты вроде helm upgrade с фиксированными версиями чартов.

Настройте retention policy для артефактов

Хранение старых образов позволяет откатиться к стабильной версии.

• В container registry (Docker Hub, AWS ECR, Harbor) настройте правила хранения, чтобы сохранять последние N версий или образы за последние X дней.
• Регулярно очищайте устаревшие артефакты, но сохраняйте критические версии (например, те, что в проде).
• Используйте теги для маркировки стабильных версий (например, prod-1.2.3).

Пример — AWS ECR lifecycle policу:

Автоматизируйте версионирование в CI/CD

• В CI/CD пайплайне генерируйте теги на основе Git тегов, commit hash или переменных окружения.
• Проверяйте, что образ с нужным тегом пушится в registry и используется в деплое.
• Добавьте шаг валидации манифестов, чтобы убедиться, что теги фиксированы.

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

Загибайте пальцы:

1. Собрать Docker-образ.
2. Обновить конфигурацию в Kubernetes.
3. Применить изменения командами kubectl.
4. Проверить, что все работает.
5. Если не работает — откатить изменения, исправить, повторить.

И так каждый раз. А если на проекте не только тестовая среда, но и предпродакш, продакшн? А если команда из 10 разработчиков? Кошмар!

Инструмент Argo CD ускоряет развертывание приложений, синхронизирует Git-репозиторий с фактическим состоянием в кластере. В итоге у разработчика больше времени на написание кода и меньше проблем с деплоем. Компания тоже выигрывает — получает более быстрые и надежные релизы.

После прочтения статьи вы сможете самостоятельно настроить деплой Kubernetes с помощью ArgoCD и применить эти знания в собственных проектах.

ArgoCD раскрывается лучше, когда уже понятен весь путь до GitOps: контейнеры, CI/CD, Kubernetes, Helm, наблюдаемость и безопасность. Общий контекст собран в статье Roadmap DevOps-инженера в 2026 году, а сам подход отдельно разобран в материале что такое GitOps простыми словами.

Введение в ArgoCD: возможности и преимущества

Git коммитишь — кластер обновляется

Вася написал новую фичу и отправил ее в Git. Через 2 минуты функция уже работает в тестовой среде, но с багом. Вася исправляет код, делает коммит, — и через 2 минуты исправление снова в тестовой среде.

Когда все готово к релизу, девопс применяет изменения в ветке, и ArgoCD автоматически обновляет продакшн.

Без ArgoCD: 30+ минут ручной работы на каждый деплой, высокая вероятность ошибки.

С ArgoCD: 2 минуты автоматической работы, минимальный риск ошибок.

Изменили код, отправили в Git — работа сделана. Платформа GitOps без вашего участия обнаружит изменения и обновит приложение в кластере.

Интерактивная панель управления

В Argo CD видно все компоненты приложения — деплойменты, сервисы, конфигмапы — и их состояние. В один клик можно посмотреть историю синхронизаций, детали развертывания и логи.

ArgoCD — это быстрый доступ к событиям, управление средами и кластерами с одной панели, мгновенный откат к предыдущей версии. Также доступна проверка изменений перед их применением.

Универсальный подход к конфигурациям

Команда применяет Helm для управления зависимостями?

— ArgoCD интегрируется с ним напрямую.

Предпочитаете Kustomize для настройки под разные среды?

— ArgoCD распознает эти конфигурации автоматически.

Используете стандартные YAML-манифесты?

— Они тоже поддерживаются без дополнительной настройки.

Безопасный доступ для команды любого размера

Можно разделить доступ между участниками проекта с точностью до отдельных приложений и действий:

• Девопсы управляют всеми развертываниями.
• Разработчики получают права на просмотр логов и статуса своих сервисов.
• Тестировщики видят статус только тестовых сред.

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

Система интегрируется с корпоративными провайдерами аутентификации через OIDC, LDAP, SAML. Каждый сотрудник сможет использовать персональные учетные данные для входа.

Установка и настройка Argo CD

ArgoCD устанавливается в действующий кластер Kubernetes с помощью стандартного набора манифестов. Перед установкой потребуются: настроенный kubectl, файл kubeconfig и работающий CoreDNS.

Команды создают пространство имен argocd и устанавливают компоненты: серверы приложений, репозиториев и другие службы.

Доступ к ArgoCD осуществляется через CLI и веб-интерфейс.

CLI устанавливается из официальных релизов:

• brew install argocd — для macOS, Linux и WSL.
• бинарный файл — для Windows.

По умолчанию сервер ArgoCD не имеет внешнего IP. Это значит, что веб-интерфейс и API ArgoCD доступны только из кластера Kubernetes.

Есть три способа настройки доступа:

1. Изменение типа сервиса на LoadBalancer:

2. Настройка Ingress-ресурс для маршрутизации трафика через входной контроллер кластера.

3. Использование kubectl port-forward для временного доступа:

Начальный пароль администратора генерируется автоматически и хранится в секрете argocd-initial-admin-secret:

Вход в систему через CLI:

После первого входа необходимо сменить пароль:

Секрет argocd-initial-admin-secret следует удалить после смены пароля, так как он содержит пароль в открытом виде:

Для веб-интерфейса используется тот же адрес и учетные данные, что и для CLI.

Регистрация кластера (необходима только для внешних кластеров):

При добавлении внешнего кластера ArgoCD создает сервисный аккаунт argocd-manager в пространстве имен kube-system и выдает ему права администратора. При работе с тем же кластером, где установлен Argo CD, используется адрес https://kubernetes.default.svc.

Создание приложения:

То же самое через веб-интерфейс:

1. Нажать кнопку «New App».
2. Заполнить форму с указанием имени, Git-репозитория, пути к манифестам.
3. Выбрать целевой кластер и пространство имен.
4. Нажать «Create».

После создания приложение находится в состоянии «OutOfSync». Для развертывания ресурсов в кластер:

Через CLI:

Через веб-интерфейс:

1. Нажать «Sync» для нужного приложения.
2. В открывшейся панели выбрать «Synchronize».

Для автоматической синхронизации при изменениях в Git-репозитории используется флаг –sync-policy automatic:

При загрузке манифестов из репозитория Арго автоматически определяет формат и применяет соответствующий инструмент для развертывания.

Основные команды и работа с CLI

Рассмотрим 4 базовые команды:

• Добавление нового приложения.
• Проверка состояния развертывания.
• Автоматическая и ручная синхронизация.
• Откат изменений.

Добавление нового приложения

Команда argocd app create создает приложение в Argo CD, связывая Git-репозиторий с целевым кластером Kubernetes.

Нужно указать имя приложения, источник манифестов и целевую среду:

Альтернативой ручному созданию приложения служит определение через YAML-файл:

Проверка состояния развертывания

Команда argocd app get отображает текущее состояние приложения, включая статус синхронизации, ревизию Git и состояние ресурсов:

Для вывода информации о ресурсах приложения используется флаг -o wide:

Можно отслеживать состояние ресурсов во время синхронизации:

Еще ArgoCD сохраняет историю синхронизаций приложения:

Автоматическая и ручная синхронизация

Команда argocd app sync применяет изменения, обнаруженные в Git-репозитории, к кластеру Kubernetes:

При ручной синхронизации Argo CD:

1. Скачивает манифесты из Git.
2. Формирует план изменений.
3. Применяет его к кластеру.
4. Отслеживает состояние до завершения развертывания.

Синхронизация определенной ревизии Git:

Принудительная синхронизация:

Обновление только определенных ресурсов:

Откат изменений

Команда argocd app rollback отменяет последнюю синхронизацию и возвращает приложение к предыдущему стабильному состоянию:

По умолчанию откат выполняется на предыдущую успешную ревизию. Для отката к конкретной ревизии требуется указать ее ID:

где 5 — номер ревизии из истории.

При откате не происходит изменений в Git-репозитории — это временное изменение, направленное на быстрое восстановление работоспособности.

После отката приложение перейдет в состояние «OutOfSync», поскольку Git-репозиторий по-прежнему содержит новую версию.

Для долгосрочного решения после отката нужно:

1. Исправить ошибки в манифестах.
2. Отправить исправления в Git.
3. Синхронизировать приложение.

Работа с ArgoCD в реальных проектах

ArgoCD дополняет классические CI/CD-системы, разделяя ответственность за процесс доставки. CI-системы отвечают за сборку кода и создание артефактов, ArgoCD берет на себя развертывание в Kubernetes.

В GitHub Actions пайплайн компилирует приложение, собирает Docker-образ, обновляет манифест с новым тегом образа и отправляет изменения в Git. ArgoCD замечает изменения в репозитории и обновляет приложение в кластере.

Подробнее про интеграцию CI/CD с GitHub Actions

GitLab CI/CD использует подобную схему — сначала тестирование и сборка, затем запись актуальных версий в манифесты. CI-пайплайн завершается, как только изменения попадают в Git. Остальную работу делает ArgoCD.

Подробнее про инструменты CI/CD на практике от DevOps-инженеров

Jenkins требует дополнительной настройки для интеграции с ArgoCD. Возможна работа через REST API ArgoCD или через обновление манифестов в Git-репозитории. Для командной строки Argo CD создают отдельные сервисные аккаунты с ограниченными правами.

Настройка уведомлений

Уведомления Argo CD информируют команду о состоянии приложений. Система уведомлений настраивается в ConfigMap argocd-notifications-cm:

• Для Slack нужно определять шаблоны сообщений и триггеры событий. Соединение настраивается через токен бота. Приложения активируют уведомления через аннотации.
• Microsoft Teams работает через веб-хуки. Каждый канал получает собственный URL-адрес, который ArgoCD использует для отправки сообщений.
• Email-оповещения требуют настройки SMTP-сервера. ArgoCD поддерживает TLS-шифрование и аутентификацию. Письма содержат детальную информацию о событиях и могут включать ссылки для быстрого доступа.

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

Управление секретами

Стандартная модель GitOps требует хранения всех манифестов в Git, что небезопасно.

Популярные решения для управления секретами:

• Sealed Secrets. Публичный ключ используется для шифрования секретов перед сохранением в Git. Контроллер в кластере расшифровывает их закрытым ключом и создает стандартные Secret-объекты.
• HashiCorp Vault. Манифесты содержат переменные, которые заполняются значениями из Vault в момент синхронизации. Секреты никогда не попадают в Git-репозиторий.

3 лучшие практики использования ArgoCD

1. Организация репозитория

Структура Git-репозитория влияет на эффективность работы с Argo CD. Рассмотрим два основных подхода: «моно» и «мульти» модель.

• Монорепозиторий хранит все манифесты в одном месте. Каталоги первого уровня разделяют приложения и конфигурацию среды. Преимущество — целостная структура и возможность внесения согласованных изменений.
• Мультирепозиторная модель разделяет компоненты по нескольким репозиториям. Каждая команда управляет своим набором приложений. Конфигурации для разных окружений хранятся отдельно. Этот подход четко разграничивает ответственность.

App of Apps упрощает управление множеством приложений через главное приложение ArgoCD. Один манифест верхнего уровня содержит определения для всех приложений, что упрощает развертывание однотипной инфраструктуры.

2. Использование Kustomize и Helm

Kustomize накладывает патчи на базовые манифесты. Конфигурация определяет основные параметры приложения, оверлеи содержат изменения для конкретных сред.

Helm применяет шаблонизацию для создания манифестов. Чарты содержат шаблоны с переменными, значения которых задаются в файлах values.yaml. Для каждого окружения создается собственный файл значений.

Можно комбинировать оба инструмента. Helm создает базовые манифесты, а Kustomize настраивает их под конкретные требования.

3. Мониторинг приложений и настройка alert-уведомлений

Арго собирает метрики синхронизации, состояния здоровья, времени развертывания. Данные передаются в Prometheus для создания дашбордов в Grafana и настройки алертов.

Система уведомлений информирует команды о критичных изменениях: ошибках синхронизации, деградации здоровья, успешных развертываниях. Алерты отправляются в Slack, Teams, Email через настраиваемые триггеры и шаблоны.

6 популярных ошибок при работе с ArgoCD

Ошибка аутентификации по SSH-ключу. ArgoCD выдает «Permission denied (publickey)» при попытке доступа к репозиторию. Причина — неправильно настроенный или отсутствующий SSH-ключ.

Решение:

• Проверить корректность SSH-ключа.
• Убедиться, что в репозитории ключ добавлен как deploy key с правами чтения.
• Проверить формат ключа (должен начинаться с —–BEGIN OPENSSH PRIVATE KEY—–).

Отсутствие прав доступа к репозиторию. Даже при корректных учетных данных пользователь может не иметь прав чтения.

Решение:

• Проверить права доступа пользователя или deploy key к репозиторию.
• Убедиться, что для организации не включено SSO или 2-FA.

Несоответствие версий Helm. Argo CD использует встроенную версию Helm, которая может отличаться от локальной.

Решение:

• Проверить версию Helm в Argo CD через argocd admin helm version.
• Настроить кастомную версию Helm через конфигурацию argocd-cm.

Отсутствующие значения в values.yaml. Ошибка «Error: execution error at line X» с указанием на неопределенное значение.

Решение:

• Убедиться, что все required значения указаны в файле values или через флаги –set
• Использовать условные блоки для необязательных параметров

Одна из основных проблем в GitOps-модели — расхождение между фактическим состоянием кластера и описанием в Git.

Отказ при синхронизации из-за drifts. ArgoCD отображает ресурс как «OutOfSync» и отказывается выполнять синхронизацию.

Решение:

• Использовать флаг –force при синхронизации для перезаписи изменений.
• Включить опцию автоматического самовосстановления (self-heal) для критичных ресурсов

Ошибка Update не разрешена для некоторых полей. Kubernetes запрещает изменение определенных полей после создания ресурса.

Решение:

• Добавить аннотацию argocd.argoproj.io/sync-options: Replace=true

Подведем итоги

Поздравляем! Вы познакомились с инструментом, который спасает от ручных деплоев!

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

Если после внедрения ArgoCD у вас внезапно появилось свободное время — не пугайтесь, это нормально. Используйте его, чтобы наконец-то прочитать те 348 вкладок про Kubernetes, которые вы открыли 2 года назад. А еще можете использовать его, чтобы почитать наш тг-канал, найдете больше советов!

Инструменты и окружение

Современные DevOps-инженеры без инструментов — как админ без терминала. Вот что стоит добавить в стек:

Топ-10 инструментов DevOps, которые упростят вашу жизнь и избавят от ночных релизов — Список лучших инструментов для DevOps-инженеров, которые упрощают релизы, мониторинг и CI/CD-процессы. От логгирования до автоматизации тестов.

Podman: Альтернатива Docker без daemon — Знакомим с Podman, инструментом, который не требует daemon, но дает весь функционал Docker.

Docker Hub в России — всё? Гайд, как обойти блокировку —Объясняем, как работать с Docker Hub после блокировки: альтернативы, зеркала и решения.

CI/CD, Kubernetes и деплой

Когда каждое изменение должно доходить до продакшена быстро и без боли — нужна хорошая сборка:

Разворачиваем инструменты CI/CD: практики от DevOps-инженеров — Практическое руководство по внедрению и настройке CI/CD: инструменты, примеры, лайфхаки.

Собираем и деплоим в Kubernetes приложение на Node.js с помощью werf — Пошагово показываем, как собрать и развернуть приложение на Node.js в Kubernetes с помощью инструмента werf.

Как автоматизировать деплой с использованием Kubernetes — Рассказываем, как автоматизировать процесс деплоя приложений в Kubernetes: подходы, инструменты и советы.

Выбираем оптимальную архитектуру мониторинга: от легковесного сервиса до высоконагруженных кластеров —Рассматриваем варианты мониторинга от минимальных решений до сложных систем, подходящих под высокие нагрузки.

Практики и подходы

Не только инструменты, но и культура разработки — основа DevOps:

Как стать DevOps в 2024 году — Что нужно знать, какие навыки прокачивать, с чего начать.

Как автоматизировать безопасность с помощью DevSecOps и искусственного интеллекта — Объясняем, как применить DevSecOps-подход и AI для защиты приложений на всех этапах разработки.

Как serverless-технологии помогают снизить нагрузку на разработчиков — Разбираемся, как serverless помогает ускорить разработку, упростить масштабирование и снизить поддержку инфраструктуры.

Не забывайте читать предыдущие гайды. Python, React, мобильная разработка, С++, инструменты, фронтенд.

Кстати! Забрать все самые топовые нейронки для айтишников можно в нашем большом гайде с 70+ ИИ-инструментами

Сейчас рынок облачных сервисов — крайне перспективная отрасль. В России процент проникновения облачных услуг по данным провайдера — всего 28%, поэтому возможности для роста очень большие.10 апреля компания провела масштабную конференцию, которую посетили более 5500 айтишников онлайн и офлайн. На открытии GoCloud 2025 топ-менеджеры представили новую платформу для работы с данными, AI-решения, заявили о внедрении AI-агентов в свои платформы, а также рассказали, что такое гибридное облако, почему искусственный интеллект нужен почти всем компаниям, а главное — какие релизы Cloud.ru готовит в будущем.

На конференции было три трека:

1. Инфраструктура и сервисы — здесь спикеры Cloud.ru рассказывали о новых сервисах и платформах, особенно про публичное облако Cloud.ru Evolution
2. AI&ML — был посвящен новым AI-фичам и работе с ML-моделями, которые улучшат клиентский опыт и упростят жизнь разработчикам и пользователям
3. Сценарии работы в облаке — здесь выступали спикеры из крупных компаний и делились своим опытом использования облаков.

В статье рассказываем о главных анонсах Cloud.ru и итогах конференции.

Что нового в Cloud.ru Evolution

Cloud.ru Evolution — публичное облако, построенное на собственных разработках и open source, где интегрированы самые необходимые разработчикам сервисы.

На прошлой конференции в 2024 году Cloud.ru уже успели представить много новых компонентов в платформе — тогда в ней было доступно 20 сервисов. За год ей воспользовались 39 тыс. человек, а число сервисов выросло в 2 раза.

В мае этого года пользователям будут доступны новые платформенные сервисы для работы с большими данными в облаке. Они работают по модели PaaS, используют контейнерную архитектуру и предлагают автомасштабирование, гибкость и безопасность. Сервисы упрощают обработку и анализ данных, подходят для AI/ML-задач, интегрируются с S3, Artifactory Registry и Evolution DBaaS.

Некоторые из них можно попробовать уже сейчас:

• Evolution Managed Arenadata DB — это управляемая PaaS-база на Greenplum для хранения и обработки до 50 ТБ данных. Подходит для аналитики, AI/ML, отчетности, а оплата проходит по модели pay-as-you-go.
• Evolution Data Platform — это платформа от Cloud.ru для работы с большими данными. Уже можно протестировать: Evolution Managed Trino — SQL-движок для работы с разными источниками данных, Evolution Managed Metastore — хранилище метаданных, Evolution Managed Spark — сервис для распределенной обработки данных.

Evolution Managed Trino и Metastore выйдут в коммерческий доступ во втором квартале 2025, а Evolution Managed Airflow и Evolution Managed BI станут доступны для тестирования.

Также в Cloud.ru Evolution появится AI-помощник, который будет закрывать базовые задачи.

Помощник должен автоматизировать рутинные задачи и максимально снизить порог входа в облака и работу с ними, в перспективе значительно упростит работу DevOps. Всю ответственность за то, что он делает, будем нести мы, как провайдер. Помощник будет эволюционировать и закрывать все больше рутинных задач: реагировать на alert и monitoring, следить за автоматизацией, а в будущем поможет управлять эффективностью облачной инфраструктуры, ее масштабированием и стабильностью. С момента запуска помощники будут доступны в публичных, гибридных и частных облаках Cloud.ru.

Cloud.ru Evolution Stack + AI — один из главных анонсов конференции

В марте Cloud.ru выпустили на рынок Cloud.ru Evolution Stack — платформу для создания частных и гибридных облаков. Решение рассчитано на крупный бизнес, госсектор, финтех, ритейл и промышленность. Платформу можно развернуть в собственном ЦОДе или объединить с публичным облаком Cloud.ru Evolution. Внутри — всё, что нужно: виртуализация, инструменты для работы с ML, PaaS- и IaaS-сервисы, управляемый Kubernetes, S3-хранилище, очереди сообщений и даже витрина приложений в формате маркетплейса.

Для удобства администрирования есть Multicloud Manager и VM Manager — с их помощью проще управлять виртуальными машинами, следить за инфраструктурой, учитывать ресурсы и подключать SIEM-системы для безопасности.

Cloud.ru Evolution Stack — наше самое большое достижение за год. Мы создавали его из одной кодовой базы с публичным облаком Cloud.ru Evolution, но пришлось серьезно перестроить процессы. Циклы разработки каждой из платформ отличаются. В публичном облаке можно деплоить непрерывно: если в одном из сервисов появилась ошибка, ее можно сразу же исправить. А в гибриде, релиз которого мы делаем два раза в год, так не получится, поскольку на первый план выходят качество сборки, unit-тесты, интеграционные и нагрузочные тестирования. Процесс разработки усложнился, но мы максимально автоматизировали его. Это серьезная нагрузка, но без серьезного влияния на наш time-to-market.

При разработке Cloud.ru Evolution Stack главным вызовом была смена подхода. Cloud.ru создает софт для одного публичного облака, а здесь нужен продукт, который можно ставить многократно у разных заказчиков — это радикально меняет процессы и мышление команды. Однако понимая запросы рынка на гибрид и потребности клиентов, компания начала разработку этой платформы еще на ранней стадии Cloud.ru Evolution. Если бы решение было старше, переход на дистрибутив съел бы гораздо больше времени и ресурсов.

Многие пользователи уже успели протестировать Cloud.ru Evolution Stack. Вот положительные фидбек:

• Платформа предлагает не только виртуализацию и контейнеризацию, но и полный набор сервисов — аудит, IAM, логирование, мониторинг. Это позволяет сразу запускать частное облако для внутренних подразделений без необходимости настраивать личные кабинеты или доступы.
• Платформа легко интегрируется с системами мониторинга, кибербезопасности и авторизации заказчика, выступая как подчинённый компонент, что упрощает внедрение.
• Интерфейс Cloud.ru Evolution Stack полностью кастомизируется — можно красить во всевозможные цвета, поставить свой логотип и так далее.

Cloud.ru Evolution Stack — мощная платформа со множеством функций, которые расширяют возможности собственной IT-инфраструктуры компаний за счет сервисов публичного облака. Решение может сначала озадачить, но мы всегда рядом: помогаем заказчикам разобраться, обеспечиваем эксплуатацию и полное сопровождение.

Приступая к работе над Cloud.ru Evolution Stack, поменялись и подходы к продуктовой разработке. Главное — начали сертификацию процесса безопасной разработки по стандарту РБПО, чтобы соответствовать требованиям к надежности и безопасности ПО для критически важных систем. Это ускорит сертификацию Cloud.ru Evolution Stack для крупных заказчиков с полугода-года до квартала.

На GoCloud Cloud.ru анонсировали Evolution Stack AI-bundle — новую платформу для локального запуска AI-сервисов. Платформа упрощает разработку и масштабирование AI-продуктов, сохраняя полный контроль над данными. По сути, это первое в России гибридное облако с поддержкой AI.

Что внутри:

• Jupyter Lab для дата-сайентистов;
• инструменты для обучения, дообучения и инференса моделей;
• инфраструктура — Managed Kubernetes с GPU, реестр артефактов, виртуалки с GPU, S3-хранилище и файловая система для ML.

Платформа гибкая: можно обучать модели в публичном облаке, а инференс запускать в закрытом контуре on-prem или переключаться при нагрузках. Она поддерживает мультитенантность, мониторинг и управление доступом. Плюс, её можно дополнить другими сервисами Cloud.ru для комплексных решений.

Cloud.ru Evolution Stack AI-bundle входит в реестр российского ПО, соответствует требованиям импортозамещения и будет доступна как софт или программно-аппаратный комплекс по подписке.

AI, ML и облака (не роботы)

Из других больших анонсов — Cloud.ru Evolution AI Factory. Это новая платформа для создания приложений и AI-агентов в облаке, запускать планируют этим летом.

По своей сути, это цифровая «фабрика», которая объединяет инструменты для работы с искусственным интеллектом — от обучения моделей до запуска сложных мультиагентных систем. Вот, что внутри:

• Evolution ML Inference — с помощью нее можно запускать ML-модели (Hugging Face, Docker-образы) на GPU с поддержкой vLLM, TGI, Ollama, Diffusers, Transformers. Использует Shared GPU, то есть использует столько ресурсов, сколько нужно, для запуска модели.
• Foundation Models — доступ к популярным моделям, вроде GigaChat и Gemma, плюс среда AI Playground для тестирования идей.
• AI Assistants — создание агентов с подключением к внешним системам и автоматизацией задач.
• Cloud.ru ML Space — платформа для глубокого обучения, работает в облаке и on-premise.

Платформа делает работу с AI проще и доступнее. Не нужно быть экспертом в программировании или тратить кучу денег на серверы — всё уже готово в облаке. Она помогает компаниям быстрее создавать свои AI-продукты: агентов, аналитические системы или что-то совсем кастомное. Внутри будут встроенные ассистенты — новички могут легко собрать целое приложение, а профи — все кастомизировать. Это экономит время, снижает затраты на инфраструктуру и ускоряет запуск новых идей на рынок.

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

В Cloud.ru считают, что за нейронками — будущее. И компания уже видит эффект: разработчики активно используют AI-инструменты в задачах, которые не требуют креатива и разработки критических сервисов. Правда, измерить этот эффект пока непросто — слишком уж разные задачи и технологии.

Я точно знаю, что AI помогает в разработке: используют code assistant, применяют CoPilot. Разработчики уже не представляют работу без него — это как Google лет 15 назад, когда им еще не все широко пользовались, а сейчас он у всех в смартфоне. AI помогает развиваться, ускоряет выполнение ежедневных задач. То, что раньше делали месяц, теперь можно уложить в две недели.

Что будет дальше: планы Cloud.ru

В 2025 году Cloud.ru продолжат развивать собственные облачные платформыи PaaS . Сейчас запросы российского бизнеса, особенно крупных B2B-клиентов, часто совпадают с западными стандартами, так как многие из них уже работали с крупнейшими облачными провайдерами. Помимо базовых требований к надежности и безопасности, заказчики ждут продвинутых решений.

Три четверти нашего бэклога — это запросы заказчиков, а четверть — инновации и создание трендов. У нас в России требовательные клиенты, особенно крупные B2B-компании, и они знают, что такое хорошее облако. Помимо надежности и кибербезопасности им нужны продвинутые инструменты — AI, Big Data, высокая производительность. Cloud.ru AI Factory — наш главный фокус, до конца года мы выпустим много новых сервисов. Cloud.ru Evolution Stack будем тиражировать в продакшен, чтобы помогать бизнесу.

А ещё Cloud.ru продолжит прокачивать AI-комьюнити — компания предоставляет открытую экосистему для вендорских продуктов. В ней можно создавать конкурентные решения, например, fully-managed сервисы в Cloud.ru Evolution с помощью Partner API. Так вход в облачные технологии становится еще проще и удобнее.

Реклама. Рекламодатель: ООО «Облачные технологии», ИНН 7736279160, erid: 2W5zFJ5hRC4.

Я создал свой проект с полноценной документацией с сылкой на Github по развертыванию n8n на собственном сервере.

Завязка

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

В сети крутился хайп вокруг n8n — open-source, который можно развернуть на любом сервере, и с полной свободой действий. Конечно, до меня не сразу дошло, на официальном сайте очень дорогие тарифы. Поэтому я начал изучать туториалы на Ютубе. В этот момент я даже не подозревал, что эта идея затянет меня на неделю, подарит десятки ошибок и первый полноценный сервер.

Развитие: от ноды до ноды

Railway: первая проба пера

Самые простые туториалы были про развертывание n8n на собственном компьютере. Некоторые комментарии под такими видео ссылались на то, что развертывание n8n на собственной машине — не самая лучшая идея, и возможно, не самая удачная. Я тогда прислушался к их мнению и решил попробовать сразу поискать другие способы.

Подходящей оказалась платформа Railway. Бесплатный пробный период, $5 бонуса за привязку GitHub — всё выглядело перспективно. Я:

• подключил GitHub;
• получил API-ключ;
• запустил n8n;
• настроил Telegram-бота.

И всё шло нормально, пока не начались проблемы с Telegram Trigger — он просто не отвечал. Ошибок в логах почти не было, но и связи — тоже. Я тратил часы, пробовал разные переменные, гуглил, спрашивал у нейросетей — без толку. Тогда в рекламе мне попался Yandex Cloud с двухмесячным бесплатным периодом. Я решил попробовать развернуть n8n на нем.

Виртуалка, SSH и первый затык

Я развернул ВМ на Ubuntu 20.04 LTS, выбрав её за стабильность и поддержку. Конфигурация:

• 2 vCPU
• 50 ГБ SSD
• Снятие с бонуса: 2683.50 руб/мес

Сгенерировал SSH-ключ через Git Bash. Первый облом: ключ исчез. После нескольких безуспешных попыток изменить его, понял — проще пересоздать ВМ. У Yandex Cloud есть ограничения:

нельзя обновить на лету.

Подключение выглядело так:

Когда получилось зайти — был настоящий кайф. Я обновил систему, установил Docker, понял, что GUI у сервера не будет — только терминал. Ну что ж, поехали.

Docker, docker-compose, и n8n-raw.env

Следующим шагом стал

и файл

В нём я прописал:

Это позволило не держать всё в голове и запускать конфигурации быстрее. Первые ошибки появились почти сразу — что-то не так с путями, потом — с переменными. Без ChatGPT и stackoverflow не обошлось.

Домены и HTTPS

Купил домен

настроил A-записи, скачал сертификаты. Nginx — отдельная песня. Нужно было:

1. Объединить три сертификата в один;
2. Подключить его через конфиг;
3. Настроить редирект на HTTPS.

Вот пример из моего nginx.conf:

Telegram и «почему ты не работаешь?!»

Подключил Telegram Trigger — ноль. Ни один запрос не проходил. Ошибки:

• Lost connection to the server
• Webhook error: unexpected status code 403
• Логи молчали или выдавали бессмысленное.

Проблема оказалась в том, что webhooks шли через HTTP, а всё у меня уже работало через HTTPS. Куки не обрабатывались, туннель API оказался лишним, docker не доверял IP клиента. Пришлось в docker-compose.yml прописывать:

Потом был конфликт сертификатов, SSE и WebSocket. Я потратил день на всё это — и наконец бот ответил.

Разгрузка: спасение в Obsidian и GitHub

Всю документацию, команды, даже ошибки я хранил в Obsidian. Там же создавал шаблоны, чтобы не печатать одни и те же команды. Это было моим вторым спасением после ChatGPT.

Когда всё начало получаться — создал репозиторий. Сейчас там:

• README.md с пошаговыми действиями;
• n8n-raw.env для автоматизации запуска;
• Docker-конфиги.

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

Финал: в этой истории я вырос

Когда Telegram наконец сработал — было 3 часа ночи. Я сидел в темноте, всматривался в терминал и не верил. Всё. Бот работает. HTTPS есть. Docker жив. Я сам развернул свой первый полноценный сервер. Сам. С нуля. С ошибками. Без опыта.

Теперь я могу:

• Развернуть ВМ и подключиться через SSH;
• Настроить Docker и Nginx;
• Создать и связать домен;
• Конфигурировать n8n под прод;
• Документировать всё на GitHub.

Я только начал, но теперь точно знаю — могу не просто тестировать, а создавать решения с нуля.