#инфраструктура

Эти три поста — мини-ода серверу Nginx и его создателю Игорю Сысоеву. Я не написал о покупке компании NGINX американским гигантом F5 за 670 миллионов долларов в феврале (профайл в Ведомостях и в Форбсе), исправляюсь.

Nginx — это скотч веб-разработчика. Вы ведь знаете, что именно с помощью скотча астронавты починили свой автомобиль на луне? С помощью Nginx можно скрепить разные части сайта между собой (микросервисы, ау), ускорить сайт с помощью кеширования (скорость работы Медузы и RAWG), серьезно сэкономить на хостинге и даже защититься от DDoS-атак. Nginx поддерживает и простейшие одностраничные сайты и гигантские корпорации. Это сервер, который вобрал в себя лучшее от таможни, DHL и завода.

Мы с коллегами недавно сделали с помощью nginx две необычные вещи, которыми я хочу поделиться.

Вспомнил, как именно сломался сервер с первой версией. Мы удалили его в админке хостера, перепутав один сервер с другим.

Такие дела.

Обрыв двух независимых 20kV линии питания и всей оптики до основных площадок обмена трафиком в Европе — не очень частая ситуация. Тем более хороший повод повторить основные правила.

Идеальная схема — когда запросы идут параллельно на две площадки у двух не-аффилированных провайдеров (не два ДЦ у одного и того же провайдера, а прямо разные компании). Админ в Букмейте был из старой гвардии Яндекса и поддерживал такое. В таком сетапе падение одного провайдера проходит незаметно для читателей. Это обычно сложно технически и стоит денег по ресурсам.

Чуть похуже — горячая замена (опять же у отдельного провайдера). Это когда есть копия полностью рабочего сервиса, которая стоит ждет своего времени. В этом случае вы упадете, но минут на 10. Это проще технически, но стоит денег — половина железа «простаивает».

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

В противном случае – молимся, постимся и слушаем радио Радонеж при каждом падении.

Прямо сейчас часть корневых серверов .io вместо правильных NS-ответов (списка серверов, на которых вы хостите свои DNS-записи) возвращает тыкву.

Из-за этого могут не открываться сайты в зоне .io, например, meduza.io

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

Обсуждение вот тут https://news.ycombinator.com/item?id=15293578

Про совпадения.

Прямо сейчас Серебреников в наручниках в зале суда в Москве. Медуза ведет онлайн.

За 5 минут до начала трансляции что-то происходит со связностью между Lattelecom и Amazon (пару минут всё отлично, пару минут пакеты не ходят совсем). Редакция замечает это, в первую очередь, по недоступности Slackа.

Мы переключаем uplink на резервный LTE-роутер от LMT (латышский аналог МТС). Всё хорошо, пока редакторы не пытаются зайти на HTTP-сайты (смотрю нехорошим взглядом на tass.ru и interfax.ru). Происходит мистический 302 редирект на 192.168.8.2, который не грузится. Времени на поиск причины нет, решаем заплаткой с Chrome Data Saver (де-факто, VPN).

Оказалось, что LTE-роутер хочет обновить прошивку, делает DPI HTTP-сессий (но не HTTPS) и заменяет ответ сервера на 302 редирект. Из-за того, что таких запросов много — его веб-сервер не выдержал и ничего не отдавал. Одна из редакторов оказалась достаточно терпеливой, чтобы дождаться загрузку админки, я кликнул там «не сообщать об этом больше» и проблема решилась окончательно.

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

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

Небольшой рассказ, как дидосили Медузу 2 недели назад и пара советов для медиа в мире дидоса: https://dev.meduza.io/ddos-ab63424e595e

Короткая (14 страниц A4) и познавательная статья про безопасность в гугле: https://cloud.google.com/security/security-design/
Проходится «по верхам» обеспечения безопасности такого монстра, как Google.

Мне было особенно интересно про аутентификацию/авторизацию на уровне общения сервисов друг с другом (внутри есть больше подробностей про это):

Each service that runs on the infrastructure has an associated service account identity. A service is provided cryptographic credentials that it can use to prove its identity when making or receiving remote procedure calls (RPCs) to other services. These identities are used by clients to ensure that they are talking to the correct intended server, and by servers to limit access to methods and data to particular clients.

Длинная и годная статья. Тезисно:
1. осторожнее с облаками, иногда железо и админ дешевле в несколько раз (наверное всем уже надоел с этим утверждением!);
2. cloud provider lock-in = ☠;
3. нет блидинг эдж тулзам (они называют hipster tools всё, что моложе 18 месяцев).

http://firstround.com/review/the-three-infrastructure-mistakes-your-company-must-not-make/

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

Никогда не использовал сложные функции aws, видимо стоит внимательно присмотреться к этому совершено адовому списку (в админке весь экран заполнен мелким шрифтом названиями сервисов). https://fmlnerd.com/2016/08/16/30k-page-views-for-0-21-a-serverless-story