Никакой найм не решит твои проблемы, твои проблемы решит только твой собственный стартап. Игорю Сысоеву никто бы не дал столько денег в найме, сколько у него образовалось от факта авторскости nginx. Делай своё, двигай движуху, не пытайся починить найм.
Nginx часто воспринимают как «просто веб-сервер», который достаточно поставить и запустить с дефолтным конфигом. На этом этапе обычно и останавливаются: процессы работают как попало, заголовки отдаются по умолчанию, SSL настроен формально, keepalive либо не используется, либо вредит, а маршрутизация запросов со временем обрастает хаотичными location. В результате конфигурация вроде бы выполняет свою задачу, но остаётся плохо управляемой, неочевидной и далёкой от оптимальной.
Эта статья — о базовых, но часто недооценённых возможностях Nginx. Мы последовательно разберём настройку рабочих процессов, управление HTTP-заголовками, корректную конфигурацию SSL, работу keepalive-соединений и маршрутизацию запросов. Без магии и редких трюков — только то, что действительно используется в продакшене и позволяет сделать конфигурацию понятной, предсказуемой и безопасной даже для начинающего администратора
Ранее мы рассматривали различные варианты балансировки нагрузки (HTTP, L4) с помощью Angie. Однако мы обходили стороной вопрос отказоустойчивости. Балансировщик становится единой точкой отказа для системы, и эту проблему необходимо решать. Одним из решений является использование протокола VRRP для организации отказоустойчивого кластера — его мы и разберём в этой статье.
Каждый раз, когда в айтишных чатах всплывает тема веб-серверов, кто-то пишет: «Apache умер», «Nginx — наше всё», «за Caddy — будущее, просто попробуйте». В статье разберём, в каких случаях веб-сервер действительно нужен, в чём плюсы и минусы популярных решений и как сделать выбор под свою задачу. Детали внутри.
В первой части мы создавали простого бота для управления одним сервером. Во второй — учили его измерять скорость и обновляться. Казалось бы, задача решена? Как бы не так.
В этой статье я расскажу, как проект VPS Manager перерос статус «скрипта для себя» и превратился в полноценную асинхронную платформу с Web-админкой, поддержкой Docker-кластера и базой данных SQLite. Встречайте версию 1.13.0.
Всем привет! Часто требуется поднять свой проект на VPS/VDS. Именно это я и покажу в статье.
Мы настроем сервер, NGINX, выпишем SSL-сертификат и развернём код тестового приложения.
Привет.
Я студент, изучаю Ansible на Raspberry Pi через Tailscale. Делюсь полным путем от первой ошибки до работающих веб-серверов. Код + выводы + уроки. Репозиторий на GitHub.
Аннотация: Рассказываю, как наша команда реализовала мониторинг состояния шины и аналитику запросов к ней через обратный прокси. Пришлось повозиться, ведь Zabbix из коробки не очень успешно с этим взаимодействует.
В сложных интеграционных системах мониторинг является неотъемлемым инструментом как для инженера, так и для бизнеса. Zabbix показал себя надёжной и гибкой системой, которая позволяет строить понятные дашборды. Но я, как тимлид команды поддержки, столкнулся с тем, что шину Red Hat JBoss Fuse так просто к Zabbix не подключить. Шина работает на JVM, а значит, нужен мониторинг по JMX.
Привет, Хабр! Я заметила, что в стартап-культуре и среди небольших команд бытует миф: «Мы слишком малы, чтобы нас атаковали». Я считаю, что сейчас это одно из опаснейших заблуждений, поэтому и решила написать статью, чтобы поделиться своими мыслями и некоторыми знаниями на эту тему.
При разработке сложной системы приходится сталкиваться с использованием nginx в качестве reverse proxy: роутинг, список правил, регулирующих путь запроса во внутренние системы или между подсистемами.
Быстро развивающиеся сервисы обрастают правилами, назначение которых не очевидно или имеет недокументированные особенности. Проверенный способ рефакторинга таких систем: зафиксировать и вылечить упростить. Фиксировать будем тестами.
Как проверить корректность вашей конфигурации Nginx'а? Как проверить ее безопасность и нет ли уязвимостей ? Какие есть для этого варианты, их плюсы, минусы, практическая применимость и как эти проверки встроить в CI пайплайн ?
Ответы на эти вопросы под катом. Будет полезно, погнали.
Привет, Хабр! Меня зовут Сергей Черкашин, и я — руководитель команды по эксплуатации систем и защиты от DDoS-атак в Wildberries & Russ.
Мы с командой обеспечиваем работу сайта даже в условиях DDoS-атак, разрабатывая и поддерживая защиту от них. Возможно, у вас нет значительного бюджета на такие задачи, или вы работаете над проектом в одиночку и сосредоточены на разработке функционала и базовой безопасности. В этой статье я расскажу о том, какие шаги можно предпринять быстро и с минимальными затратами, чтобы получить базовую защиту от DDoS.
За выходные поднял «свой Dropbox/Google Drive» на Raspberry Pi 5 через Docker-compose: Nextcloud + PostgreSQL + Redis + Nginx Proxy Manager + автокрон. Бонусом — SMTP-уведомления, капча на регистрации и аккуратный config.php. Ключевой инсайт: даже без специфических знаний это реально, если уметь правильно «разговаривать» с ИИ и копипастить команды не глядя в дебри мануалов.
Контроль основных метрик веб‑сервера или балансировщика — основа надежной работы системы. Ранее мы разбирали работу с мониторингом через API и Angie Console Light, но это не единственный вариант, доступный в Angie. Использование встроенного экспортера Prometheus и визуализация через Grafana дают принципиально другие возможности. Итак, в этой статье мы запустим полноценную систему мониторинга Angie.
Наряду с развитием искусственного интеллекта, облачные вычисления названы основополагающей технологией будущего. Наверное, многие слышали, как важны и ценны знания Docker и Kubernetes в современном мире ИТ. Но как подступиться к этим технологиям, если ранее с ними вы не сталкивались?
Я всегда считал, что серьезные вещи начинаются с малого, но это малое должно быть самой сутью интересующего феномена. Предлагаю разобраться, как работает полнофункциональное веб-приложение, реализующее современный стек технологий и, конечно же, развёрнутое в кластере Kubernetes. Сделав первый шаг, вы всегда сможете продолжить свой путь исследования, заниматься самообразованием и отладкой разнообразных приложений, реализующих различные подходы, в том числе и самые современные.
Я — Bitrix-разработчик со стажем 8+ лет.
Начинал дружить с битрой ещё с версии 12 — когда всё было максимально квадратно, можно сказать что я тот самый "проженный" битриксоид, а любой деплой превращался в ночной марафон из консоли, логов и bash-скриптов.
Со временем стало понятно: BitrixEnv решает задачу,
но не решает боль инженера.
Он требует привыкания, ручной рутины и десятков часов конфигурации.
Поэтому я переписал его заново — на Python + HTML5 + Vanilla JS.
Без bash-магии запрещенной в хогвартсе и с прозрачной архитектурой собрав все года боли общения в единую точку невозврата возрождение Битрикс!
Современная инфраструктура приложений динамична и требует гибкости от конфигурации ключевых элементов. В этой статье мы разберём все варианты реализации динамических групп серверов (upstream) в Angie. С помощью этих методов вы сможете изменять состав и статус серверов без вмешательства в конфигурацию Angie.
Рядовые инфраструктурные задачи иногда преподносят неожиданные сложности. Нашей целью была организация защищённого доступа к внутренним сервисам через единую точку входа с авторизацией в Keycloak, чтобы приложения получали проверенные пользовательские данные без необходимости реализации собственной логики аутентификации.
Изначально решение виделось простым — настроить Nginx и прописать правила маршрутизации. Ключевые трудности скрывались в деталях: тонкой настройке редиректов, работе с access token и интеграции с бэкенд-сервисами, потребовавших значительного внимания.
В статье расскажем о нашем пути построения схемы обратного прокси с авторизацией через Keycloak: от поиска решения до создания стабильного и масштабируемого результата.
Один из самых простых способов ускорить работу сайтов и снизить нагрузку на инфраструктуру — корректно использовать клиентское кэширование. Механизм одновременно и простой, и сложный. В этой статье посмотрим, как можно управлять клиентским кэшированием в веб‑сервере Angie.
Когда вы работаете с распределённой системой — будь то микросервисы, фронтенд + бэкенд или nginx + приложение — жизненно важно иметь возможность «протянуть» один и тот же идентификатор запроса через все её компоненты. Это позволяет сопоставлять логи из разных источников, быстро находить ошибки и проводить корреляционный анализ.
В nginx для этого из коробки есть переменная $request_id — 32-символьный hex-идентификатор (например, a1b2c3d4e5f678901234567890abcdef). Его можно передать бэкенду через proxy_set_header X-Request-ID $request_id; или fastcgi_param HTTP_X_REQUEST_ID $request_id;, а также сохранить в access-логах.
Однако стандартный $request_id — это просто случайная строка без временной привязки и без структуры, удобной для аналитики. В этой статье мы рассмотрим, как улучшить ситуацию с помощью ULID и UUIDv7.
Возможности Angie в качестве веб‑сервера и обратного прокси довольно известны. Но кроме работы на уровне L7 (HTTP), мы можем применять его на L4 (TCP и UDP) в качестве балансировщика и прокси‑сервера. Именно об этой функциональности мы и поговорим в сегодняшней статье.
