#google-cloud-platform #google-deployment-manager #infrastructure-as-code #gcp-load-balancer
#google-облачная платформа #google-deployment-manager #инфраструктура как код #gcp-балансировщик нагрузки
Вопрос:
Я внедряю IaC для веб-приложения, состоящего из монолитов и микросервисов. Я хочу разместить внутренний балансировщик нагрузки HTTP перед всеми нашими микросервисами и пока не нашел ни одного примера для этого. Я посмотрел на Cloud Foundation Toolkit. Внутренний балансировщик нагрузки здесь поддерживает только внутренний балансировщик нагрузки TCP / UDP. В deploymentmanager-samples от Google об этом вообще не упоминается!! На данный момент кажется, что единственный вариант — создать шаблон python с нуля.
Прежде чем я прыгну в эту кроличью нору, хотел проверить, доступен ли для этого какой-либо рабочий образец или пример.
Ответ №1:
Согласно какому-то документу Google, вам просто нужно изменить некоторые значения во внутреннем шаблоне TCP LB.
Ниже приведен пример кода regionBackendService внутреннего TCP LB.
{
'name': loadbalancer_name,
'type': 'compute.v1.regionBackendService',
'properties': {
'region': properties['region'],
'network': properties['network'],
'healthChecks': ['$(ref.' healthcheck_name '.selfLink)'],
'backends': properties['instance-groups'],
'protocol': 'TCP',
'loadBalancingScheme': 'INTERNAL',
}
}
И это compute.v1.regionBackendService
ссылка на документ Google.
протокол
Возможными значениями являются HTTP, HTTPS, HTTP2, TCP, SSL, UDP или GRPC. в зависимости от выбранной конфигурации балансировщика нагрузки или директора трафика. Для получения дополнительной информации обратитесь к документации для балансировщика нагрузки или для Traffic Director.
Схема балансировки нагрузки
Выберите INTERNAL_MANAGED для внутренних HTTP (ов) Балансировка нагрузки.
Итак, вам нужно изменить 'protocol':'TCP'
на 'protocol':'HTTP'
или HTTPS
и 'loadBalancingScheme': 'INTERNAL'
на 'loadBalancingScheme': 'INTERNAL_MANAGED'
.
Ниже приведено правило пересылки исходного кода TCP LB.
{
'name': forwardingrule_name,
'type': 'compute.v1.forwardingRule',
'properties': {
'ports': [80],
'network': properties['network'],
'subnetwork': properties['subnet'],
'region': properties['region'],
'backendService': '$(ref.' loadbalancer_name '.selfLink)',
'loadBalancingScheme': 'INTERNAL',
}
}
И вы также можете найти ссылку на этот ресурс.
Схема балансировки нагрузки
INTERNAL_MANAGED используется для: внутренних HTTP (ов) Балансировка нагрузки
IPProtocol
Внутренний HTTP (S) Балансировка нагрузки: схема балансировки нагрузки является INTERNAL_MANAGED, и допустим только TCP.
В результате вам нужно изменить loadBalancingScheme
значение с INTERNAL
на INTERNAL_MANAGED
. Или, возможно, вам нужно добавить значение IPProtocol в ваше правило пересылки.
Наконец, ниже приведена проверка работоспособности внутреннего LB-кода TCP.
{
'name': healthcheck_name,
'type': 'compute.v1.healthCheck',
'properties': {
'type': 'TCP',
'tcpHealthCheck': {
'port': 80
},
}
}
Как я нашел в документе, вы должны использовать «regionhealthcheck» вместо «healthcheck» для http (ов) внутреннего LB.
Итак, вам нужно изменить тип ресурса на compute.v1.regionHealthChecks
Я не совсем уверен в своем описании, но вы можете создать свой собственный HTTP (S) внутренний LB, обратившись к документации Google и образцу кода.
Комментарии:
1. Пожалуйста, нажмите проверить боттон, чтобы принять мой ответ, если он был достаточно полезным 🙂
2. Сначала я проверю это 🙂
3. эй, также проверьте эту документацию, может быть вам интересно 🙂 <a>cloud.google.com/load-balancing/docs/l7-internal/monitoring</a>
4. Забыл обновить здесь, но я заставил это работать. На самом деле он ближе к внешнему HTTP LB, чем к внутреннему TCP LB. Мне пришлось использовать все региональные ресурсы вместо нерегиональных. 2 дополнительных требования: regionalTargetHTTPProxy требует подсети только для прокси-сервера и правила брандмауэра для разрешения трафика из подсети только для прокси-сервера во внутреннюю сеть, где запущены MIGS.
5. Сейчас это развертывание только для конфигурации. Я планирую преобразовать его в шаблон и добавить обратно в cloudfoundry.