Обновить
256K+

Серверное администрирование *

Установка, настройка, обслуживание

250,37
Рейтинг
Сначала показывать
Порог рейтинга

Соло-инференс-провайдер в ЕС: как я снизил цену на 11 центов и получил 146 миллионов токенов за сутки.

Дисклеймер: я оператор LLM Tech, инференс-провайдера из одного человека и одной GPU. Пост про технику и экономику, не реклама. Цифры можно проверить на публичной странице статуса, ссылка в конце.

Сетап

Одна RTX PRO 6000 Blackwell 96GB в аренде в финском датацентре, edge-VPS в Германии, между ними nginx и самописный шим на aiohttp, примерно 700 строк. Модель — Qwen3.8-27B в NVFP4: это аппаратный формат Blackwell, по качеству близко к fp8, по стоимости обслуживания примерно вдвое дешевле. Контекст 262К.

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

Как устроен рынок, если ты маленький

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

Механика такая: запросы с включённым промпт-кешированием роутятся только на кеш-способных провайдеров, по сумме базовых цен вход+выход. Провайдеры на llama.cpp с Q4_0 в этой лиге не играют, мультитенантный префикс-кеш там не работает.

Ход на 11 центов

Я снизил цену выходных токенов с $2.20 до $2.09 за миллион — на 11 центов ниже ближайшего кеш-неспособного конкурента по сумме. Через час роутер площадки перечитал мой /v1/models (цены они читают живьём) и весь кеш-тяжёлый трафик модели поехал ко мне.

Следующие сутки: 2 087 запросов, 146 миллионов токенов, из них 129М отданы из кеша. В пике — 8 миллионов токенов за 5 минут и больше сотни конкурентных стримов. Карта в моменте делала 40М токенов в час.

Экономика кеша

До меня неделю доходило, что кеш работает не как скидка, а как ров. При 91% кеш-хитов из 145М входных токенов реально прожёвано около 16М, остальное — чтение готовых KV-блоков из VRAM по $0.04 за миллион. Взвешенная цена входа вышла $0.06–0.08/М, дешевле авто-пула площадки, хотя базовая цена у меня выше, чем у части конкурентов.

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

Технические грабли, о которых нигде не написано

Кеш на гибридной архитектуре. У Qwen3.8 смешанное внимание (full attention + GDN-слои), и vLLM кеширует их иначе, чем чистые трансформеры: блоки по 1 584 токена, потому что страница внимания выравнивается по mamba-странице. Материализация ленивая: первый запрос кеш не создаёт, второй создаёт, читает только третий. Промпты короче ~5К токенов в кеш не попадают вовсе. Я сначала решил «кеш сломан», потому что тестировал двумя одинаковыми запросами. Тестируйте тремя.

Поля reasoning. В нестриминговых ответах vLLM кладёт рассуждения в поле reasoning, в стриминговых дельтах — в reasoning_content. Я потерял день, читая не то поле, и успел записать чекпоинт в «инстракт-онли».

NVFP4-квант сохранил vision-башню. Модель всюду числится текстовой, но OpenAI-шный image_url просто работает: картинка 768×512 плюс 40 токенов ответа занимает 1.2 секунды, а в usage прилетает multimodal_tokens. Узнал случайно, когда полез смотреть карточку модели у крупного агрегатора.

Таймауты складываются в гильотину. Генерация 32К токенов на 50 ток/с занимает 640+ секунд. Проверьте всю цепочку: у меня aiohttp с ClientTimeout(total=600) молча убил легитимный стрим и записал его в журнал как 200. nginx при этом невиновен, его proxy_read_timeout считает паузу между байтами, а не общее время.

429 вместо очереди. Лимиты конкурентности на канал, при превышении — мгновенный 429 с Retry-After. Тихая очередь портит TTFT всем сразу, быстрый отказ даёт клиенту среагировать. Единственный настоящий 502 за ~6000 запросов оказался гонкой с протухшим keep-alive и лечится одним

Теги:
+4
Комментарии2

Compact OS в Windows: как освободить место без удаления файлов

Если системный SSD почти заполнен, не обязательно сразу удалять программы, игры или личные данные. В Windows есть встроенный механизм Compact OS, который сжимает системные файлы и помогает освободить несколько гигабайт.

Функция появилась в Windows 10 и поддерживается в Windows 11. Отдельного переключателя в настройках нет: управлять Compact OS нужно через команду Compact.exe.

Как работает Compact OS

Windows хранит часть системных файлов в сжатом виде, а при обращении распаковывает их на лету. Компоненты ОС при этом не удаляются и не отключаются.

Технология поддерживается на компьютерах с UEFI и классическим BIOS. Windows Update также умеет обслуживать сжатую установку: заменять и удалять необходимые файлы без постоянного увеличения её размера.

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

Как проверить и включить функцию

Откройте командную строку от имени администратора и выполните:

Compact.exe /CompactOS:query

Команда покажет, используется ли Compact OS сейчас.

Для включения сжатия:

Compact.exe /CompactOS:always

Чтобы вернуть обычное состояние:

Compact.exe /CompactOS:never

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

Сколько места можно освободить

Точный результат зависит от версии Windows и конфигурации системы. В документации Microsoft для 64-разрядной Windows 10 версии 1607 приведён пример установки объёмом 15,06 ГБ. После применения Compact OS размер уменьшался до 11,3 ГБ — экономия составляла более 3,7 ГБ.

При дополнительном single-instancing объём снижался до 10,09 ГБ, а суммарная экономия превышала 4,75 ГБ.

Это ориентиры, а не гарантия для любого компьютера. На Windows 11 результат может быть другим.

Когда Compact OS имеет смысл

Функция пригодится, если:

  • системный SSD небольшой;

  • раздел почти заполнен;

  • удалять приложения и пользовательские файлы не хочется;

  • нужно освободить несколько гигабайт именно за счёт компонентов Windows.

На компьютере с SSD на 1–2 ТБ польза обычно ограничена: несколько гигабайт редко решают проблему нехватки места.

Важно помнить, что Compact OS сжимает только системные файлы. Место также занимают:

  • Pagefile.sys и Hiberfil.sys;

  • обновления Windows;

  • точки восстановления;

  • журналы и кэши;

  • языковые пакеты;

  • компоненты Windows;

  • приложения и временные файлы.

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

Итог

Compact OS — штатный способ уменьшить размер Windows без удаления системных компонентов. Он особенно полезен на устройствах с небольшими накопителями, но не является универсальным решением проблемы нехватки места.

Если свободного пространства критически мало, можно начать с проверки:

Compact.exe /CompactOS:query

А затем, при необходимости, включить режим:

Compact.exe /CompactOS:always

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

✔ Код — журнал о технологиях https://t.me/kodjournal подпишитесь на наш Telegram-канал! 😎

Теги:
+1
Комментарии0

Пройти идентификацию через ЕСИА за пару минут

Мы уже рассказывали, зачем нужно подтверждение данных владельца домена через Госуслуги — с 1 сентября без этого нельзя будет зарегистрировать, продлить и передать домены .ru, .рф и .su.

Теперь пройти идентификацию можно в панели, в разделе «Домены и SSL». Пока она доступна только для физлиц, юрлица смогут подтвердить данные после 1 сентября.

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

Теги:
+18
Комментарии0

Как аптечная сеть «36,6» снизила ИТ-расходы в 1,5 раза после переезда на bare metal

Аптечная сеть «36,6» росла, а инфраструктура за этим не успевала. Аналитические расчеты требовали все больше мощности, а ядро сети держалось на двух коммутаторах Cisco с потолком 1 Гбит/с — в часы пик из-за этого могли сбоить аптеки. Бюджет при этом растягивать не хотелось.

Решением стал переход на bare metal в Рег.облако. Собрали инфраструктуру, которая оставила «36,6» полный контроль над железом и дала запас мощности для роста.

Что сделали:

  • перенесли больше 400 виртуальных машин за два месяца, без простоев в бизнес-процессах;

  • в основном ЦОДе — хосты на AMD EPYC с памятью DDR5 и три системы хранения;

  • заменили ядро сети: вместо упиравшихся в 1 Гбит/с коммутаторов Cisco поставили масштабируемое программное решение;

  • добавили серверы с GPU под большие языковые модели и резервный ЦОД с объектным хранилищем S3.

В результате расходы на инфраструктуру снизились в 1,5 раза, производительность кластера выросла в среднем на 40%, а ключевой расчет ускорился с 22 до 16 часов. Подробнее о технической реализации — в кейсе на сайте Рег.облака.

Теги:
+5
Комментарии1

Режим стримера 🎮

Теперь можно спокойно снимать скринкасты, стримить работу в панели или шарить экран на демо-звонке. Нам, кстати, тоже стало заметно проще записывать для вас инструкции. Все потому, что в панели появился режим стримера.

Включаете — и панель сама блюрит конфиденциальные данные:

➖ Публичные IP-адреса
➖ Баланс
➖ Личные данные: ФИО, телефон, email
➖ Домены и почтовые ящики

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

Попробовать на своей панели →

Теги:
+18
Комментарии0

Дайджест Рег.облака за июль

В июле запустили третий этап Free Tier — бесплатный облачный сервер, ресурсов которого хватает уже на бизнес-проекты. Плюс упростили работу с ispmanager, открыли линейку «Стандартные» в двух регионах, добавили готовые образы в аттестованный контур ФЗ-152 и поделились исследованием о спросе на облако и GPU. Ниже — главное.

Запустили третий этап Free Tier — теперь и для бизнес-нагрузок

Расширили бесплатный облачный сервер до конфигурации, которой хватает для корпоративных порталов, крупных интернет-магазинов и ресурсоемких сервисов. На третьем этапе Free Tier дает выделенный облачный сервер бесплатно на два месяца: два виртуальных ядра, 4 ГБ оперативной памяти и 40 ГБ NVMe. Сервер подходит для проектов на «1С-Битрикс», переноса крупных сайтов с виртуального хостинга, баз данных и подготовки CI/CD-сред.

Подробности — на странице программы.

Исследование: спрос смещается к облаку, bare metal и GPU

Посмотрели, как за два года изменился спрос бизнеса на инфраструктуру. В публичном облаке акцент сместился с запуска проектов на резервирование: снапшоты используют 35,2% компаний малого бизнеса и 37% среднего. В dedicated и bare metal стало больше крупных клиентов — число компаний с расходами выше 500 тыс. руб. в месяц выросло более чем вдвое.

Особенно вырос спрос на GPU: за январь–июнь 2026 г. потребление прибавило 507% год к году. Чаще всего берут NVIDIA A4000 — у 63% компаний, и приходят за ускорителями уже не только ИТ, но и электронная коммерция, производство, логистика и финансы.

Все цифры — в исследовании.

Управление ispmanager для выделенных серверов в личном кабинете Рег.облака

Теперь панель ispmanager для выделенных серверов можно заказать и настроить прямо в личном кабинете Рег.облака. Если панель уже подключена, в интерфейсе ЛК виден блок с доступами и ссылкой на саму панель на сервере.

Открыли линейку «Стандартные» в Москве-1 и Санкт-Петербурге-1

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

Готовые образы GitLab, GitLab Runner, Nextcloud и Portainer в регионе Москва ФЗ-152

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

Разобрали свои продукты в статьях

В июле вышли два продуктовых обзора на Хабре — если пропустили, читайте:

Желаем всем продуктивного месяца и спасибо, что следите за обновлениями Рег.облака!

Теги:
+4
Комментарии1

Первые шаги на сервере: что быстрее освоить — консоль или ispmanager

У новичка на сервере обычно два пути: открыть панель управления в браузере или подключиться по SSH и разбираться с командами. Панель дает готовые формы под типовые операции, консоль — прямой доступ к системе. Освоить панель получится быстрее, но Linux под ней никуда не денется.

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

Подробности — в блоге Рег.облака.

Теги:
Всего голосов 4: ↑3 и ↓1+4
Комментарии0

Антипаттерн при работе с VPS: почему не стоит постоянно работать под root?
Работать под root на VPS удобно: перед командами не нужно вводить sudo. Но ошибка может затронуть весь сервер, а безопасность VPS требует разделять обычные и административные действия.

Почему работа под root удобна и опасна? В Unix доступ к файлам и управление процессами зависят от пользователя и его групп. Root может изменять системные файлы, управлять службами, пакетами и сетью. При постоянной работе под root ошибка в команде способна затронуть системные файлы и службы. Опечатка в пути команды удаления или ошибка в скрипте, запущенном от root, может стереть системные файлы, изменить права на каталоги и остановить сервисы. При запуске от обычного пользователя ущерб чаще ограничен его правами. Украденный ключ, разрешающий вход под root, или пароль этой учётной записи сразу дают административные права. Ключ обычного пользователя даёт доступ только с его правами. Получение root-прав зависит от настроек sudo, пароля, уязвимостей и ошибок конфигурации.

Как правильно: отдельный пользователь и sudo.

В Ubuntu или Debian создайте пользователя и добавьте его в группу sudo:

adduser operator
 usermod -aG sudo operator

Добавьте публичный ключ в файл .ssh/authorized_keys в домашнем каталоге нового пользователя и проверьте вход по SSH. Затем задайте параметр в

/etc/ssh/sshd_config:
PermitRootLogin no

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

sshd -t && systemctl reload ssh

Мини-чек-лист безопасного старта на VPS

•        Отдельный пользователь создан, команды запускаются через sudo.

•        Публичный ключ добавлен, приватный защищён парольной фразой.

•        Вход по SSH под root отключён.

•        Обновления системы устанавливаются регулярно.

Проверьте настройки доступа к VPS: создайте отдельного пользователя с sudo, протестируйте вход по SSH и только после этого отключите вход под root.

Теги:
Всего голосов 10: ↑9 и ↓1+11
Комментарии25

Почему дешёвый VPS-сервер может обойтись дорого в продакшене? Тариф в 3–5 долларов в месяц за VPS кажется приятной экономией на старте. Но если тариф выбран только по цене, счёт за простой, срочную миграцию и потерянных клиентов может прийти позже и оказаться выше, чем сэкономленная разница в ценнике.

Что скрывается за низким ценником? За низкой ценой могут стоять оверселлинг, общий диск, ограниченная поддержка и слабые гарантии по SLA. У части провайдеров низкая цена достигается за счёт плотного размещения клиентов на одной ноде: продаётся больше vCPU и RAM, чем физически доступно, в расчёте на то, что нагрузки не совпадут. В результате могут появляться CPU steal time, просадки I/O от соседей по железу и нестабильная производительность общего хранилища. SLA на бюджетном VPS-сервере может отсутствовать или ограничиваться формальным обещанием без понятной компенсации.

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

Как считать полную стоимость VPS? Реальная цена – это не только тариф, а TCO: тариф + стоимость инцидентов. Один час простоя интернет-магазина в пиковый сезон легко перекрывает годовую разницу между дешёвым и надёжным VPS. Добавьте часы на диагностику и миграцию, потери из-за недовольных клиентов – и экономия быстро испаряется.

Чек-лист: признаки надёжного VPS:

•        SLA не ниже 99,9%

•        NVMe-хранилище со стабильной производительностью или понятными IOPS-лимитами

•        Современная аппаратная виртуализация, например KVM, и понятная политика изоляции ресурсов

•        Автоматические бэкапы с проверенным восстановлением

•        Поддержка 24/7 с заявленным временем ответа

•        Гарантированная пропускная способность сети

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

Теги:
Всего голосов 5: ↑3 и ↓2+3
Комментарии0

С днём системного администратора!

Стабильного коннекта, низкого пинга, работающего резервного копирования!

Теги:
Всего голосов 4: ↑4 и ↓0+6
Комментарии0

Почему аптайм зависит не только от VPS-провайдера?

Провайдер может обещать 99,9% аптайма VPS, но аптайм продукта и аптайм инфраструктурного узла остаются разными показателями. Когда сервис падает, причина часто находится за пределами зоны ответственности провайдера: в приложении, деплое, базе данных, DNS или внешних API.

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

Где на самом деле ломается аптайм? На практике многие простои возникают не из-за сбоев инфраструктуры, а из-за ошибок в коде и операционных процессах. Неудачный деплой, утечка памяти, переполненный диск, истёкший SSL-сертификат, недоступный DNS или упавший сторонний API гасят сервис независимо от стабильности хостинга.

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

Как повысить реальный аптайм сервиса? Стабильность сервиса на VPS складывается из нескольких пунктов. Автоматические бэкапы и снапшоты упрощают восстановление после сбоя. Проверки состояния и алерты сокращают время обнаружения инцидента. CI/CD-пайплайн с проверками и понятным откатом снижает риск ошибок при деплое.

Чек-лист надёжности:

  • Бэкапы и снапшоты настроены и проверены

  • DNS TTL снижен перед плановыми миграциями

  • SSL-сертификаты обновляются автоматически

  • Есть процедура отката для каждого релиза

  • Мониторинг и алерты подключены до деплоя

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

Теги:
Всего голосов 3: ↑2 и ↓1+3
Комментарии0

Как разрешить пользователю реплики удаленно подключаться к Master-серверу PostgreSQL?

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

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

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

Откройте конфигурационный файл клиентской аутентификации:

nano /etc/postgresql/17/main/pg_hba.conf

Обратите внимание, что тут рассматривается настройка репликации на примере PostgreSQL 17.

Найти точное расположение файла можно в командной строке PostgreSQL с помощью команды SHOW:

sudo -u postgres psql -c "SHOW hba_file;"

Добавьте в pg_hba.conf следующую строку, указав вместо REPLICA_ВНУТРЕННИЙ_IP сетевой адрес вашего ведомого сервера:

host    replication    replicator    REPLICA_ВНУТРЕННИЙ_IP/32    scram-sha-256

Для доступа к реплицируемым данным у пользователя replicator должна быть привилегия replication:

ALTER ROLE replicator WITH REPLICATION;

Предварительно ознакомьтесь с порядком применения правил в pg_hba.conf в официальной документации.

Чтобы PostgreSQL применил изменения в конфигурации авторизации, выполните reload службы в терминале:

systemctl reload postgresql

В качестве альтернативы можно отправить сигнал процессу postmaster с помощью pg_ctl reload, вызовом SQL-функции pg_reload_conf() или используя kill -HUP.

После применения изменений Master-сервер начнет принимать входящие пакеты от указанного IP-адреса, и процесс репликации сможет успешно инициализироваться.

На первый взгляд, настройка репликации в PostgreSQL кажется простой задачей: достаточно открыть доступ в pg_hba.conf и подключить standby-сервер.

Но в production-инфраструктуре за этой «простой настройкой» скрывается целый стек инженерных задач: необходимо следить за консистентностью WAL-журнала, контролировать лаг между репликами, обеспечивать безопасную сетевую доступность между узлами, настраивать резервное копирование, регулярно тестировать сценарии аварийного переключения и быть готовым вручную восстанавливать кластер в случае деградации одного из серверов.

Поэтому в ряде сценариев современные команды переходят от self-managed PostgreSQL к PaaS-решениям вроде Managed Databases, где отказоустойчивость, репликация и обслуживание кластера уже реализованы на уровне платформы.

Это позволяет сократить операционные расходы на сопровождение инфраструктуры и снизить риск простоев критичных сервисов.

Теги:
Всего голосов 4: ↑3 и ↓1+6
Комментарии0

Мой опыт работы с Selectel: первые впечатления от российского облачного провайдера

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

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

Именно в этот момент я решил попробовать Selectel.

Почему выбрал Selectel

До этого я рассматривал разные варианты. Главными критериями были:

  • стабильность работы;

  • удобное управление сервером;

  • понятная документация;

  • возможность быстро менять конфигурацию;

  • наличие необходимых инструментов.

Хотелось получить не просто сервер, а платформу, с которой можно спокойно развивать проект.

Первое знакомство

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

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

Что понравилось

За время использования больше всего обратил внимание на несколько моментов:

Скорость запуска.
Не нужно ждать длительных настроек - необходимые ресурсы можно получить достаточно быстро.

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

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

Что можно улучшить

При этом идеальных сервисов не бывает.

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

Итоги

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

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

Теги:
Всего голосов 5: ↑3 и ↓2+4
Комментарии2

Ближайшие события

Как связать контейнеры Nginx и PHP в Docker Compose, чтобы Nginx мог проксировать запросы?

Допустим, вы пытаетесь развернуть связку из веб-сервера и PHP. Контейнеры поднимаются, но веб-сервер выдает ошибку сети и не может достучаться до PHP-бэкенда. Разберемся, что нужно прописать в конфиге Nginx, чтобы они увидели друг друга.

Чаще всего подобная проблема возникает из-за того, что контейнеры изолированы друг от друга на сетевом уровне, либо в конфигурационном файле веб-сервера некорректно указан адрес целевого хоста. В экосистеме Docker Compose встроенный DNS-сервер автоматически сопоставляет имена сервисов с их внутренними IP-адресами. Поэтому не нужно прописывать статические IP — достаточно правильно использовать имена, заданные в манифесте. 

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

Чтобы Nginx мог передавать запросы PHP-FPM, необходимо:

  • убедиться, что оба контейнера находятся в одной сети (app_network),

  • указать в конфигурации Nginx правильный адрес PHP-контейнера (в нашем примере это php:9000, где php — имя сервиса в docker-compose.yml).

Шаг 1: Проверка манифеста docker-compose.yml

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

version: '3.8'
services:
  nginx:
    image: nginx:latest
    container_name: nginx
    ports:
      - "80:80"
    volumes:
      - ./nginx/nginx.conf:/etc/nginx/nginx.conf
      - ./nginx/html:/var/www/html
    depends_on:
      - php
    networks:
      - app_network

  php:
    image: php:8.2-fpm
    container_name: php
    volumes:
      - ./php:/var/www/html
    networks:
      - app_network

networks:
  app_network:
    driver: bridge

Шаг 2: Настройка конфигурации Nginx

В блоке location, отвечающем за обработку PHP-скриптов, в директиве fastcgi_pass вместо 127.0.0.1 или localhost необходимо подставить имя сервиса PHP из файла конфигурации:

server {
    listen 80;
    server_name localhost;

    root /var/www/html;
    index index.php index.html;

    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }

    location ~ \.php$ {
        fastcgi_pass php:9000;  # Связь с PHP-контейнером
        fastcgi_index index.php;
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    }
}

Директива depends_on в блоке Nginx гарантирует, что веб-сервер не начнет стартовать раньше, чем поднимется контейнер с PHP. Это предотвратит падение Nginx при первичном запуске окружения, если он не сможет сразу разрешить DNS-имя php.

Если вы хотите глубже разобраться в сетевых механизмах, управлении volumes и оркестрации контейнеров, читайте наш полный материал: Docker Compose и основы работы с контейнерами.

Теги:
Всего голосов 6: ↑6 и ↓0+11
Комментарии0

Что делать, если Python-сервер падает из-за утечки памяти?

Привет, Хабр! Это наша экспериментальная рубрика, в которой мы даем новичкам быстрые ответы на четкие вопросы. Писать статью будет излишним, а некоторую пользу до аудитории донести, возможно, получится.

Итак, допустим, агент спустя время начинает расти по памяти и в итоге все падает. Где копать и как временно ограничить ущерб, пока ищете утечку?

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

Часто проблема в неограниченных кэшах, списках или в C-расширениях. Сначала стоит включить tracemalloc, дать процессу поработать и снять снапшот:

import tracemalloc
tracemalloc.start()
# после нагрузки
snapshot = tracemalloc.take_snapshot()
top = snapshot.statistics('lineno')[:10]
for stat in top:
    print(stat)

Параллельно делайте gc.collect() и логируйте число объектов len(gc.get_objects()), чтобы увидеть рост. На время расследования применяйте эксплуатационные меры: для WSGI-сервисов используйте Gunicorn с --max-requests и --max-requests-jitter, чтобы процессы периодически перезапускались и не накапливали мусор. А в контейнерах ставьте cgroup-пределы (--memory) и настраивайте restart-политику, чтобы платформа автоматически перезапускала упавшие поды.

Пример запуска Gunicorn:

gunicorn myapp:app --workers 4 --max-requests 1000 --max-requests-jitter 50

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

Если хотите освоить инструменты Python, то в Академии Selectel у нас есть отдельная подборка статей. Там мы рассказываем, как настраивать инструменты, работать с базами данных, создавать программы с интерфейсом и использовать Python для парсинга.

Теги:
Всего голосов 3: ↑3 и ↓0+7
Комментарии0

Почему трафик в ЦОДе балансируется не так, как вы ожидали

LAG часто воспринимают как простую и понятную вещь: объединили несколько линков — получили больше пропускной способности и отказоустойчивость. Но в реальности всё упирается не только в наличие агрегированного канала, а в то, как именно по нему раскладываются потоки.

Из-за этого и появляются знакомые инфраструктурные сюжеты: один линк забит, другой почти пустой; после изменения топологии поведение трафика меняется неочевидно; ECMP вроде есть, но равномерности всё равно нет; в VxLAN/EVPN-фабрике проблема становится ещё менее прозрачной.

7 июля в 20:00 на бесплатном уроке вместе с преподавателями-практиками разберём, как на самом деле работает балансировка трафика в сетях ЦОД: от LAG и хеширования до ECMP, vPC/MLAG и VxLAN/EVPN. Фокус — на том, какие решения в дизайне сети помогают избежать перекосов, перегрузок и сценариев уровня «всё упало, всё пропало». Присоединяйтесь.

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

Теги:
Всего голосов 2: ↑2 и ↓0+4
Комментарии0

Как я в Zabbix мониторю аккаунт в REG.RU: баланс, неоплаченные счета и сроки всех услуг - через API reg.ru

Домен можно сторожить по WHOIS: взял имя, посмотрел дату, повесил триггер «истекает через 30 дней». Но WHOIS видит ровно один домен и ничего вокруг. Он не знает, что на счёте кончились деньги, что висит неоплаченный счёт, из-за которого услугу снимут раньше срока, что в том же аккаунте ещё десяток доменов, SSL и хостинг. Поэтому я опрашиваю не WHOIS, а биллинговый API самого регистратора - он отдаёт весь аккаунт целиком. Собрал из этого шаблон под Zabbix 7.0, MIT. Расскажу, как он устроен и что в нём, на мой взгляд, сделано правильно.

Архитектура Три HTTP-айтема ходят в api.reg.ru - список услуг, неоплаченные счета и баланс - и складывают сырой JSON. Дальше всё считается из него: dependent items тянут баланс, сумму и число счетов через JSONPath, а LLD разворачивает прототипы под каждую услугу (ненужные типы отсекаются макросом-регуляркой). Каждая цепочка начинается с error_handler - битый или пустой ответ API не роняет айтем, а подставляет безопасное значение. На весь аккаунт получается несколько запросов в час, а не отдельная проверка на каждую услугу.

Что считаю правильным дизайном - две цепочки зависимостей Первое - nodata. Когда API регистратора отваливается целиком, каждый триггер «нет данных» (услуги, счета, баланс) хочет сработать сам, и ты получаешь пачку алертов про одну причину. Я завязал nodata услуг и счетов на корневой «No data from balance API». Полный отвал API теперь - один алерт, а не три. Корень я специально оставил без зависимостей, чтобы случайно не завязали и его, - об этом есть комментарий прямо в шаблоне.

Второе - сроки. На каждую услугу не один триггер, а каскад: ИСТЕКЛА (Disaster) → ≤7 дней (High) → ≤14 (Warning) → ≤30 (Info). Каждый уровень зависит от более тяжёлого. Поэтому услуга, которой осталось три дня, даёт один алерт High - а не три штуки (Info, Warning, High) одновременно. По мере приближения срока ты видишь ровно один триггер нужной серьёзности.

Для работы API, необходимо прописать разершенные IP в кабинете https://www.reg.ru/user/account/settings/api/, в настройках API задать адьтернативный пароль, и сохранить в макрос хоста {$RR_PASSWORD} как Secret. Логин - {$RR_USERNAME}. Для рег.облако взять API в https://cloud.reg.ru/panel/settings и сохранить в {$RRC_API_KEY}

Итог Баланс, неоплаченные счета и сроки всех услуг - под алертами в одном дашборде, без отдельного демона-прослойки. В репозитории два шаблона: разобранный выше под api.reg.ru (домены, хостинг, SSL) и отдельный под облачный api.cloudvps.reg.ru - там к балансу и срокам добавлен мониторинг самих VPS: реглеты, снапшоты, сети. Шаблоны, README и changelog - GitHub, PR и issues welcome.

А чем вы следите за биллингом у провайдеров и регистраторов - дёргаете API, или живёте на письмах «ваша услуга истекает»?

Теги:
Всего голосов 7: ↑7 и ↓0+10
Комментарии1

Вебинар: через час расскажем, как управлять IT-инфраструктурой через Terraform

Terraform-провайдер Selectel позволяет управлять физическими серверами и другими ресурсами по концепции IaC. Мы готовим большой апдейт этого сервиса — на вебинаре расскажем все подробности.

Что вас ждет:

  • поделимся возможностями Terraform-провайдера для управления IT-инфраструктурой;

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

  • объясним, как работают новые функции.

Приятный бонус: все слушатели вебинара получат промокод на 3 000 бонусов в панели Selectel, чтобы протестировать возможности Terraform.

📹 Смотреть на YouTube

📹 Смотреть в VK

Теги:
Всего голосов 7: ↑5 и ↓2+8
Комментарии0

Вебинар «Переход с Microsoft Exchange на Почту VK WorkSpace: пошаговый план»

16 июня в 11:00 К2Тех совместно с VK Tech проведет вебинар о переходе с Microsoft Exchange на почту VK WorkSpace. Поговорим о том, как подойти к миграции без лишнего стресса, что важно учесть на старте проекта и как перенести ключевые данные без потерь.

Поддержка Microsoft Exchange 2016 и 2019 завершена, поэтому вопрос миграции для многих компаний уже перестал быть теоретическим. Когда обновления безопасности больше не выходят, почтовая система становится источником растущих рисков, а откладывать переход все сложнее.

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

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

Еще один важный блок — экосистемность платформы. Коротко пройдемся по возможностям VK WorkSpace: почта, календарь, мессенджер, видеоконференции, диск, документы и другие сервисы для совместной работы в едином контуре.

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

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

Спикеры:

  • Антон Тен, коммерческий директор VK WorkSpace, VK Tech.

  • Павел Бухтияров, руководитель направления «Почта» VK WorkSpace, VK Tech.

  • Владимир Сергеев, эксперт практики UC и ПО для совместной работы, К2Тех.

Для кого будет полезен вебинар

  • ИТ-директора и CIO, которые планируют отказ от Exchange и выбирают целевую почтовую платформу.

  • Руководители ИБ и CISO, отвечающие за снижение рисков, связанных с устаревшими системами и отсутствием обновлений безопасности.

  • Руководители инфраструктурных и почтовых команд, администраторы Exchange и VK WorkSpace.

  • Архитекторы и руководители проектов, которым нужно спланировать миграцию и оценить ее влияние на бизнес-процессы.

🎁 Бонус:

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

Зарегистрироваться

Теги:
Всего голосов 4: ↑1 и ↓30
Комментарии0

Веб-поиск и генерация изображений

Развивается не только наша инфраструктура, но и сервисы. Сегодня — про AI-агентов.

За последние три месяца количество активных агентов выросло в 4 раза, а пользователи тратят больше миллиарда токенов в день.

Теперь можно закрывать больше сценариев в одном диалоге: поиск актуальных данных и создание визуалов под запрос.

Веб-поиск

Агент ищет информацию в интернете перед ответом, а вы получаете актуальные цены, тарифы, новости, данные с сайтов. Под капотом — интеграция с Яндексом.

Функция включается в настройках агента. Стоимость — 0,49 руб. за запрос.

Генерация изображений

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

Доступные модели: Gemini 3.1 Flash Image Preview и Gemini 3 Pro Image Preview, они же Nano Banana. Список будет пополняться.

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

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

Использовать новые функции для своих проектов →

Теги:
Всего голосов 13: ↑12 и ↓1+18
Комментарии0
1
23 ...