Ответ

moko 03.07 04:49

Кроме как через env прокинуть как ещё?

Гм, через файлы, что считается более безопасным. В примере ниже секреты будут каждый в своем файле в /etc/secrets.

spec:
  containers:
  - name: mycontainer
    image: nginx
    volumeMounts:
    - name: secret-volume
      mountPath: "/etc/secrets"
      readOnly: true
  volumes:
  - name: secret-volume
    secret:
      secretName: mysecret

Но никто же не возражает добавить фичу в парсер. Мой ответ объясняет, почему сейчас так и предлагает несколько вариантов реализации данной возможности.

Кстати забыл еще один вариант. При обращении к $env:name смотреть сначала в переменных http запроса, а если там нет, в переменных окружений процесса веб-сервера. С точки зрения результата это будет похоже на копирование env процесса веб-сервера, но без накладных расходов. И $env:fields не будет содержать env процесса веб-сервера (хотя это обсуждаемо).

Кстати заметил ещё один момент - если веб-сервером парсера отдать txt файл с диска ~80кбайт браузер показывает ожидание 70-80мс. Если отдавать тот же файл с того же диска на том же сервере nginx-ом с gzip, то он жмется до 13 кбайт и ожидание отдачи сервером составляет 22мс.
Это из-за gzip?

Скорее из-за latency (времени отклика) сервера. Такие вещи надо смотреть с самого сервера и если там будет заметная разница, это уже повод изучить почему так.

Нет планов реализовать gzip парсерным веб-сервером на респонсе?

Нет. Для целей разработки разницы нет, а для "боя" в любом случае потребуется обратный прокси - сейчас же везде https.

---