G
Помоему как-то так. Давно было, но настраивали
Size: a a a
2020 December 20
G
И это даже работало
AS
Envoy поддерживает proxy protocol
AL
cert-manager сам может смотреть в istio gateway и генерить сертификаты?
AL
Envoy поддерживает proxy protocol
да я уже понял что какоето старье читал
AS
Другое дело как оно работает))
G
Так же как и все истио работает
G
AL
Так же как и все истио работает
ага - я тут тестировал его - если порт назвать http а на него повесить сертификат у приложухи - она неале
AL
а если назвать randomstring то все фурычит
AL
Честно говоря загадка дыры
AS
Надо тестировать на новейших версиях)) фиксят все очень быстро и много)
G
Ога, И производят много других багов
AL
ну я смотрел 1.7 - там щас вроде 1.8 актуальная
AY
Всем привет!
Хотел бы узнать мнение как кто делает, если можно.
Предположим, есть совокупность микросервисов. Каждый из них нужно деплоить в зависимости от окружения в определенный кластер и нэймспэйс. При этом предположим, что окружения три, а кластера два (прод - отдельный кластер Kubernetes).
Вопрос: какая у кого стратегия деплоя? Хотелось было бы с точки зрения правильности как лучше обыграть этот момент.
Например, гитовая ветка = окружение (при этом в пайплайне зашито, что в зависимости от ветки деплоить этот микросервис в определенный кластер и нэймспэйс).
Или, например, и вовсе сквозной пайплайн, где тоже всё зашито, но который при деплоем на, например, QA и прод требует нажатия кнопки "продолжить", а при старте следующей сборки предыдущий пайплайн автоматически отменяется.
Надеюсь, написал понятно.
Буду признателен, если поделитесь практическим опытом на этот счёт)
Хотел бы узнать мнение как кто делает, если можно.
Предположим, есть совокупность микросервисов. Каждый из них нужно деплоить в зависимости от окружения в определенный кластер и нэймспэйс. При этом предположим, что окружения три, а кластера два (прод - отдельный кластер Kubernetes).
Вопрос: какая у кого стратегия деплоя? Хотелось было бы с точки зрения правильности как лучше обыграть этот момент.
Например, гитовая ветка = окружение (при этом в пайплайне зашито, что в зависимости от ветки деплоить этот микросервис в определенный кластер и нэймспэйс).
Или, например, и вовсе сквозной пайплайн, где тоже всё зашито, но который при деплоем на, например, QA и прод требует нажатия кнопки "продолжить", а при старте следующей сборки предыдущий пайплайн автоматически отменяется.
Надеюсь, написал понятно.
Буду признателен, если поделитесь практическим опытом на этот счёт)
TL
Всем привет!
Хотел бы узнать мнение как кто делает, если можно.
Предположим, есть совокупность микросервисов. Каждый из них нужно деплоить в зависимости от окружения в определенный кластер и нэймспэйс. При этом предположим, что окружения три, а кластера два (прод - отдельный кластер Kubernetes).
Вопрос: какая у кого стратегия деплоя? Хотелось было бы с точки зрения правильности как лучше обыграть этот момент.
Например, гитовая ветка = окружение (при этом в пайплайне зашито, что в зависимости от ветки деплоить этот микросервис в определенный кластер и нэймспэйс).
Или, например, и вовсе сквозной пайплайн, где тоже всё зашито, но который при деплоем на, например, QA и прод требует нажатия кнопки "продолжить", а при старте следующей сборки предыдущий пайплайн автоматически отменяется.
Надеюсь, написал понятно.
Буду признателен, если поделитесь практическим опытом на этот счёт)
Хотел бы узнать мнение как кто делает, если можно.
Предположим, есть совокупность микросервисов. Каждый из них нужно деплоить в зависимости от окружения в определенный кластер и нэймспэйс. При этом предположим, что окружения три, а кластера два (прод - отдельный кластер Kubernetes).
Вопрос: какая у кого стратегия деплоя? Хотелось было бы с точки зрения правильности как лучше обыграть этот момент.
Например, гитовая ветка = окружение (при этом в пайплайне зашито, что в зависимости от ветки деплоить этот микросервис в определенный кластер и нэймспэйс).
Или, например, и вовсе сквозной пайплайн, где тоже всё зашито, но который при деплоем на, например, QA и прод требует нажатия кнопки "продолжить", а при старте следующей сборки предыдущий пайплайн автоматически отменяется.
Надеюсь, написал понятно.
Буду признателен, если поделитесь практическим опытом на этот счёт)
Понятно-то оно понятно, но тут 100500 мнений, люди статьи пишут и доклады на конференциях делают
AL
Я бы советовал делать так - как удобно будет разрабам
AL
Вообщем то весь обвес для них
AL
Сходи спроси
AY
Понятно-то оно понятно, но тут 100500 мнений, люди статьи пишут и доклады на конференциях делают
Прекрасно это понимаю.
Поэтому и хотел узнать мнения, если кто поделится, аккумулировать это и обработать на базе своих знаний)
Поэтому и хотел узнать мнения, если кто поделится, аккумулировать это и обработать на базе своих знаний)