В Shopblocks каждый клиент получает несколько временных поддоменов, чтобы они могли получить доступ к своему веб-сайту, системе администратора и статическим ресурсам. Частью проблемы создания Shopblocks было предоставление всем клиентам по умолчанию SSL-сертификата.
На начальном этапе наша система в значительной степени основывалась на виртуальных хостах Apache, и каждый клиент получал свой собственный файл виртуального хоста. Это было необходимо из-за необходимости настройки SSL-сертификата для каждого домена клиента.
Устранение ограничений при масштабировании
Однако проблема с использованием виртуальных хостов Apache возникла, когда мы увеличили нашу клиентскую базу и начали получать тысячи и десятки тысяч файлов виртуальных хостов.
Мы обнаружили, что использование памяти (без какой-либо пропускной способности запроса) увеличивается с увеличением количества загруженных файлов виртуального хоста; изящные перезагрузки занимали больше времени, чтобы выполнить. Каждый раз, когда клиент регистрировался, процесс запускался для создания его конфигурационных файлов, а затем для перезагрузки Apache.
Другие проблемы возникли, когда мы начали создавать нашу инфраструктуру для размещенного приложения, такую как перезагрузка нескольких серверов, обеспечение того, чтобы все серверы могли обслуживать все сайты, обработка отключенного сервера и синхронизация конфигураций серверов при их повторном подключении. ,
Перенос ответственности SSL-терминации на HAProxy
Многие из этих проблем были решены путем удаления требования виртуального хоста для каждого клиента, но это оставило открытой проблему прекращения SSL. Мы решили эту проблему, перенеся ответственность за прекращение SSL дальше по цепочке на балансировщик нагрузки HAProxy и от самого Apache.
В HAProxy мы используем файлы карт и перезапись заголовков для обработки всех доменов без изменения какой-либо конфигурации Apache для новых клиентов.
Когда вы регистрируетесь в Shopblocks, вы фактически получаете три поддоменов. Например, если вы зарегистрировались под именем bowersbros
, вы получите bowersbros.myshopblocks.com
, bowersbros-admin.myshopblocks.com
и bowersbros-static.myshopblocks.com
.
Это создаст несколько записей в файле карты для нашей конфигурации HAProxy. Эти строки выглядят так:
1
2
3
4
5
|
... bowersbros.myshopblocks.com <id> bowersbros-admin.myshopblocks.com <id> bowersbros- static .myshopblocks.com <id> ... |
Заменив <id>
определенным идентификатором для вашего клиента, вы сможете при необходимости ссылаться на правильную конфигурацию / базу данных. Это будет передано вашему приложению в виде HTTP-заголовка X-Customer-ID
.
При регистрации вы не можете зарегистрироваться с тире от вашего имени, поэтому мы можем с уверенностью предположить, что любые дефисы с -admin
или -static
предназначены для попадания на эти конкретные маршруты в приложении (и без дефисов, -admin
общедоступным веб-сайтом клиентов).
Наша конфигурация HAProxy теперь выглядит примерно так.
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
|
frontend http bind : 80 option forwardfor # Redirect all http requests to be https with a 301 redirect redirect scheme https code 301 frontend https # Check for your PEM certificates bind : 443 ssl crt /path/to/certificates # Check if the hostname is recognised in the map file acl is_customer hdr(host),lower,map_str(/path/to/map/file.map) -m found # If the domain is not recognised, then silently drop the conneciton # You have the option of deny if you want to immediately reject this connection http-request silent-drop unless is_customer # Delete the X-Customer-ID header incase a header is sent through unexpectedly http-request del-header X-Customer-ID # Add a X-Forwarded-Host header with the original hostname http-request add-header X-Forwarded-Host %[req.hdr(Host)] http-request add-header X-Customer-ID %[hdr(host),lower,map_str(/path/to/map/file.map)] default_backend core backend core balance roundrobin http-request set-header Host app.<your domain>.com</your> |
Это упрощенная версия конфигурации, которую мы используем, конечно, и ее нужно будет изменить в соответствии с вашим вариантом использования.
Все запросы, которые обращаются к интерфейсу HTTPS, проверяются на наличие сертификата SSL для расшифровки запроса, а затем мы проверяем их домен по файлу карты. Если мы не найдем их, они будут автоматически удалены из запроса.
Затем мы добавляем их идентификатор в запрос под X-Customer-ID
, который будет отправлен вместе с запросом, когда он поступит на ваш веб-сервер. Внутри вашего веб-сервера вы можете использовать правильную конфигурацию и соединения с базой данных на основе значения этого заголовка.
Вывод
Заголовок хоста также перезаписывается, так что можно использовать правильный виртуальный хост Apache с общим именем сервера в Apache. Это теперь позволяет вашей конфигурации виртуального хоста Apache быть общей для одного приложения, а не для каждого сервера. Единственное требование при добавлении нового клиента, домена или сертификата SSL — изменить файл file.map и выполнить перезагрузку в HAProxy, что является действием без простоев.
И вот он, обзор использования HAProxy для простой настройки приложения SaaS.
Опубликовано на Java Code Geeks с разрешения Алекса Бауэрса, партнера нашей программы JCG . Смотрите оригинальную статью здесь: Настройка HAProxy для приложения SaaS
Мнения, высказанные участниками Java Code Geeks, являются их собственными. |