Как остановить запуск Undertow предупреждений от gVisor в Cloud Run - PullRequest
Новая
       83

Как остановить запуск Undertow предупреждений от gVisor в Cloud Run

0 голосов
/ 14 октября 2019

Недавно мое приложение Undertow запускает Cloud Run, чтобы сообщить следующее: 

Container Sandbox Limitation: Unsupported syscall setsockopt(0x13,0x1,0xa,0x3e05747fe5a0,0x4,0xfc1abc10). Please, refer to https://gvisor.dev/c/linux/amd64/setsockopt for more information.

Я выполнил попытку, и похоже, что опция сокета для включения внеполосного встраивания (SO_OOBINLINE) имеет значениеотправляется Undertow. Я недвусмысленно сказал ему не делать этого в конфигурации (двумя способами), но это все еще происходит. Использование Undertow с Cloud Run кажется разумным вариантом использования, но без более глубокого понимания того, что такое внеполосное встраивание для Undertow и почему gVisor не поддерживает это, я заблокирован, какая программа нецелесообразна. Подчиняется ли он тому, что другие веб-серверы не делают этого, или gVisor слишком незрел, чтобы справиться с этой конкретной функцией сокета? Может быть, gVisor поддержит его в будущем, и мне просто нужно подождать? 

  def main(args: Array[String]): Unit = {
    val server = Undertow.builder
      .addHttpListener("8080", "0.0.0.0")
      .setHandler(defaultHandler)
      .setSocketOption[java.lang.Boolean](XnioOptions.TCP_OOB_INLINE, false)
      .setWorkerOption[java.lang.Boolean](XnioOptions.TCP_OOB_INLINE, false)
      .build
    server.start()
  }

1 Ответ

0 голосов
/ 16 октября 2019

Мой ответ покрывает «прослушивание» служб в контейнере в Cloud Run Managed. Мой ответ не включает Anthos или пользовательские приложения, в которых ваш контейнер подключается за пределами Cloud Run через TCP, gRPC или WebSockets. В вашем вопросе ваш пример - HTTP-сервер, который является слушателем, а не клиентом.

Это не проблема gVisor. Первый шаг - понять, что делает SO_OOBINLINE.

Если эта опция включена, внеполосные данные включаются в поток принимаемых данных. В противном случае вы должны использовать флаг MSG_OOB во время вызова recv () для получения внеполосных данных.

Теперь, кто будет отправлять вам внеполосные (msg) данные? Интерфейс Google Cloud Run Managed - это внешний интерфейс Google (GFE). Это прокси-сервер Google и балансировщик нагрузки для Cloud Run Managed (и многих других сервисов Google). Интерфейс к GFE - HTTP / HTTPS. Клиент / браузер не может генерировать внеполосные данные. Клиент подключается к GFE. GFE подключается к вашей службе, работающей в Cloud Run.

Если gVisor будет поддерживать SO_OOBINLINE, кто может отправлять внеполосные данные? Никто / ничего в цепочке TCP / IP, которыми вы можете управлять / управлять.

Существует интернет-проект Out-of-Band 'Кодировка контента для HTTP . Я только следил за этим документом. Это может быть поддержано в будущем для HTTP, но не сегодня.

В вашем вопросе вы устанавливаете SO_OOBINLINE в false. Это случай по умолчанию (false), поэтому установка его в false не требуется.

Примечание. Есть несколько веских причин для использования OOB, но они встречаются редко. OOB - это только один байт данных. В мире HTTP, если что-то идет не так, стандартное ожидание - это код состояния, указывающий на проблему или попытку повторной попытки.

Как прекратить вызывать предупреждения, вызванные gVisor в Cloud Run

Не называйте API setSocketOption() и равнозначны. Нет способа отключить предупреждения gVisor.

...