Как развернуть внутренний HTTP (S) Балансировщик нагрузки с помощью Google Deployment Manager (Python YAML)?

#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.