Настраиваем гугловый 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 выглядел примерно вот так:

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

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

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

Да, в общем случае нам нужно будет добавить ещё пару вспомогательных ресурсов. Во-первых, нужно настроить файрвол для 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 позеленеют:

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

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

Мораль

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

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