Настраиваем гугловый External Load Balancer через Deployment Manager

Как я и обещал когда-то, посмотрим теперь, как создать и настроить в гугловом облаке балансировщик нагрузки уже для внешнего траффика. External load balancer (ELB), то есть. Не кнопочками и формочками, а через файлы конфигурации и Deployment Manager, чтобы всё по-взрослому. Ведь хотя external балансировщик и будет похож на internal load balancer, это всё-таки совсем другой зверь:

  1. Во-первых, к external load balancer подключаются «снаружи» (Ваш КО. Не благодарите.). Но так как под «снаружи» попадает весь мир, основные компоненты балансировщика будут либо глобальные, либо хотя бы региональные.
  2. Во-вторых, ELB очень понимает, с каким траффиком он работает, и есть вдруг ему на вход подадут HTTP(S), то он в состоянии прочитать его заголовки и по URL выбрать тот бэкэнд сервис, которому этот траффик предназначался. Ага, на один ELB можно навесить много сервисов.
  3. В-третьих, ELB к тому же ещё и прокси, и если на вход ему приходит SSL, то на нём же SSL сессия и закончится. А дальше контент пойдёт либо с новой сессией, либо вообще нешифрованный.
  4. Ну и, наконец, убер бонус. Из-за того, что ELB умный, глобальный и исключительно софтварный, его нереально за DDoS’ить. По крайней мере, не сегодня. Серьёзно, самая мощная задокументированная DDoS атака была, кажется, что-то около 500 гигабит траффика в секунду. Всего один гугловый датацентр же может без особых проблем принять 1300. Датацентров много, ELB глобальный, так что have fun. После того как ELB поймёт, что траффик подозрительный, он его просто отсечёт от принимающих инстансов и «растворит» в себе.

На сегодня у гугла есть четыре породы внешних лоад балансеров: HTTP, HTTPS, SSL Proxy и TCP Proxy. Так как HTTPS самый замудрёный, его мы и будем сегодня препарировать.

Из чего сделан HTTPS ELB

Если вы помните, то internal load balancer выглядел примерно вот так:

internal load balancer без чёрной магии

Структурно, HTTPS ELB выглядит практически так же, плюс пару дополнительных компонентов посередине:

  1. Глобальный forwarding rule
  2. TargetHTTPSProxy
  3. SSLCertificate
  4. URLMap
  5. Бэкенд сервис (один или много) и его health check
  6. Региональная управляемая группа инстансов (виртуальных машин) и шаблон для неё.

Вместе это выглядит примерно вот так:

external load balancer

Да, в общем случае нам нужно будет добавить ещё пару вспомогательных ресурсов. Во-первых, нужно настроить файрвол для health check траффика. Во-вторых, возможно, придётся явно задать внешний IP адрес, если вдруг захочется использовать уже существующий или просто дать ему имя как ресурсу.

И ещё одно «да». Я же упомянул, что для HTTPS ELB на вход можно подавать HTTPS траффик, но дальше к конкретным сервисам и виртуальным машинам он уже может идти расшифрованным. Если наша сеть хорошо защищена, то почему бы и нет. Тот же гугл в пределах одного датацентра не всегда его шифрует, чем мы хуже. В общем, пусть в нашем примере будет именно такой сценарий.

Как обычно, мы рассмотрим все компоненты один за одним, и начнём с конца списка: с управляемой группы инстансов (managed instance group) и её шаблона.

Управляемая группа инстансов (виртуальных машин) и её шаблон

В конфигурации шаблона инстанса нет абсолютно ничего интересного. Обычная заготовка Ubuntu сервера с установленным на нём Apache. Хотя в виртуальной машине и задана внешняя айпишка, строго говоря, для ELB она не нужна. Но так как для выхода в интернет такая айпишка уже понадобится, а наш apt-get, устанавливающий Apache сервер, туда обязательно полезет, пришлось её оставить. Можно было бы конечно настроить какой-нибудь NAT Gateway, либо создать образ инстанса с уже предустановленным софтом, но ай.

Кстати, в этот раз управляемая группа инстансов (managed instance group, MIG) стала региональной, что очень полезно для high-availability. Мы скажем группе создать сразу две виртуальные машины, та автоматически раскидает их по разным зонам одного региона, и теперь внезапно мы и отказ одной из зон сможем пережить, и будет среди кого балансировать входящий траффик. Всё по-взрослому.

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

Бэкенд сервис

MIG — группа инстансов — в каком-то смысле образует сервис, так что почему бы не объявить его явно. К тому же, если в будущем у нас появится ещё один MIG, например, в другом регионе, но раздающий тот же контент, можно будет добавить его в этот же сервис и таким образом сделать последний глобальным.

Последние три строки конфигурации сервиса — одновременно и самые интересные — подготавливают сервис к работе с балансировщиком нагрузки. Там мы указываем, что балансировщик будет EXTERNAL, что траффик для него будет идти к порту с именем http, и протокол того траффика — HTTP.

Так как сервис ссылается на health check, которого ещё нет, то создадим-ка мы и его. Ну и ещё правило для файрвола, чтобы траффик пропустили.

URL Map

А вот теперь что-то совсем новенькое. URL Map работает как роутер для траффика из ELB. Мы можем завести несколько бэкенд сервисов, каждый со своей логикой, а затем настроить URL Map перенаправлять траффик к тому либо другому сервису в зависимости от URL. Это очень круто, потому что API сервисы могут висеть на одних инстансах, медийный контент — на других, а ELB будет общий.

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

HTTPSTargetProxy and SSLCertificate

Почти закончили. Ресурс targetHttpsProxy — это именно та штука, которая будет шифровать и расшифровывать нам траффик при помощи sslCertificate, ну а так же управлять SSL сессией. Одним своим параметром он ссылается на сертификат-ресурс, а другим — на urlMap, который будет принимать эстафету.

sslCertificate — это всего лишь ещё один тип ресурса, поддерживаемый Deployment Manager’ом. Я сгененировал сертификат, положил его в YAML, и отправил вместе с ресурсом прямо в бесконечное гугловое облако. Две минуты работы.

Глобальный forwarding rule и внешняя айпишка

Наконец, точка входа в наш ELB — глобальный forwarding rule.

Forwarding rule принимает трафик на 443-м порту из внешнего мира, передаёт его targetHttpsProxy, и в конечном итоге получается external load balancer.

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

И наконец…

После того, как мы положим все куски конфигурации в какой-нибудь elb_https.yaml, то можно запустить итоговую конфигурацию в гугловый космос и начать ждать. Сам Deployment Manager работает достаточно быстро, но всё-таки между там, как все куски ELB родятся на свет, и тем, когда они начнут возвращать HTTP 200, может пройти и пять минут, и десять.

Но в конце-концов этот момент наступит. Health checks позеленеют:

Позеленевшие health check'и

Менеджер группы инстансов отрапортует, что все сервера живы-здоровы:

Похорошевший managed instance group

И наступит вселенская благодать:

Рабочий external load balancer

Мораль

Я только вот автоматом собрался писать, что «ну вот видите, всё было просто», как спохватился. Ну какое оно нафик просто. Это же гугл! Там и от меньшего мозг сворачивало, а уж от балансировщиков нагрузки… Но, в принципе, все компоненты разумны, их связь понятна, просто с количеством перебор. А так, воспринять можно.

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

4 мысли о “Настраиваем гугловый External Load Balancer через Deployment Manager”

    1. Первые 5 forwarding rule стоят что-то около 18 баксов в месяц за штуку. SSLCertificate, URL Map, сервисы и прокси, вроде, не стоят ничего. Дальше стоить уже будут инстансы, и там можно разгуляться. Один f1-micro (vcpu, 0.6 GB) в месяц идёт бесплатно, но самая дешёвая нормальная машинка будет стоить вроде 32 бакса в месяц. + Диски, тоже зависит от размера. Но теоретически самый дешёвый ELB на одной f1-micro машине можно собрать именно за 18 баксов. Просто непонятно, среди чего именно он будет балансировать траффик 🙂

      1. То есть в принципе, на те 300 баксов кредита на год что они предлагают, можно развернуться и все протестить. Интересно, а потом, если втянешься в это дело, цена не вырастет на порядок?

        1. Не, цены у них стандартные, что в бесплатные 300 баксов, что после них. + если ресурсы используются предсказуемо: если виртуальная машина непрерывно работала целый месяц, то даже идут скидки за постоянное использование (sustained use discounts), которые я совсем забыл учесть, когда думал, стоит ли переезжать в Digital Ocean на гугл. Ну и квоты в настройках проекта можно проставить, мол, если я потратил больше чем сотню, тормози всё.
          Насколько я помню, AWS тоже даёт кредит денег на год, и тоже можно играться. Microsoft немного жмоты, там вроде всего на месяц, но я знаю кучу случаев, когда MS давали какой-нить промо сертификат на 10-100k на год на использование в Azure. Типа для продвижения в массы.
          Тут главное ни в гугле, ни в любом другом облаке не засветить свои ключи от сервисных аккаунтов и тем более не закоммитить их на гитхабе. Народ репозитории сканит регулярно, мгновенно просекают такие ключи, создают при их помощи биткойн фермы, а в конце месяца приходит счёт на средних размеров новую Тойоту. Но в таких случаях часто можно договориться со службой поддержки, мол, то были злоумышленники, и счета прощают.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *