AL
И правильно делают
Ну и какой тогда подход лучше чем такой? Тут же передается поддержка конкретного чарта конкретной команде и ты просто используешь чужой результат
Size: a a a
2020 December 19
AL
А так тебе придется сидеть и крутить свстоперделки для всех вложенных зависимостей
DS
чем тут подобный подход не устраивает ?
ты говорил что kustomize лучше всего, в том числе и helm. Берём рандомное приложение ingress nginx, смотрим чарт, смотрим аналогичную реализацию с поддержкой тех же опций в kustomize. И сравниваем. И что-то мне подсказывает, что в kustomize будет ад. Получается он так себе, чем больше опций тем хуже, хуже даже чем шаблоны helm
AL
Я прям представляю себе удобство устанавливать какой нибудь гитлаб через кастомайз и тд
AS
конкретно в нашу инфру установка гитлаба через кастомайз только и работает
AS
я говорил про то, что ситуация с хелмом нехорошая и качество чартов там так себе.
AS
что в большинстве случаев перевод чарта на кастомайз если смотреть со стороны ендюзера - это хорошее решение
AS
и подход тут должен быть такой же как и везде, есть базовый функционал, он пусть ставится хелмом, стандартизировано и прочее. хочешь кастомизаций, делай сам. так же как в линуксе. хочешь нджинкс, dnf install. хочешь модули экзотические - садись пиши собирай.
AS
а хелм пытается миллион херни всякой впихнуть и делать вид, что там чет пытается настраивать, получается весьма плохо
DS
конкретно в нашу инфру установка гитлаба через кастомайз только и работает
ну это helm template > gitlab.yaml. А не реализация и поддержка всех опций как в чарте только на kustomize
AS
про реализацию и подержку всех опций никто не говорил кроме тебя ))
AS
зачем? если я аппликуху себе собираю и ставлю себе сам, зачем мне там все опции? мне только нужные нужны
A
если есть возможность брать что-то, что кто-то другой поддерживает - лучше взять
A
у хелма миллион проблем, но он стал стандартным решением и особо тут ничего не поделать
DS
зачем? если я аппликуху себе собираю и ставлю себе сам, зачем мне там все опции? мне только нужные нужны
ну то есть для поставки проектов другим людям нормально на kustomize не сделать. Если там вариативность чуть больше чем одна/две опции. В отличии от helm или каких нибудь jsonnet вариантов.
DS
тогда чё говном бросаться я не понял. Ну покажи как красиво делать людям. PR зашли с кастомайзом. А то они бедные helm юзают, и щас вжух и весь опенсорс, чарты свои на kustomize перепишит 😂 (нет)
AL
да, не подумал. а если в server-snippet тупо добавить
listen 8080 proxy_protocol; listen 8443 ssl proxy_protocolВообщем взлетело вот так:
proxy-real-ip-cidr: lbipcidr
server-snippet: |
listen 8443 ssl proxy_protocol;
real_ip_header proxy_protocol;
+ добавил в демонсет 8443 слушать - с 8080 он не захотел прибиндить потому что чем то уже занято - а hostNetwork требует чтобы containerPort = hostPort - поэтому пока оставил http - главное что https завелся
proxy-real-ip-cidr: lbipcidr
server-snippet: |
listen 8443 ssl proxy_protocol;
real_ip_header proxy_protocol;
+ добавил в демонсет 8443 слушать - с 8080 он не захотел прибиндить потому что чем то уже занято - а hostNetwork требует чтобы containerPort = hostPort - поэтому пока оставил http - главное что https завелся
AS
почему не сделать? делай как в линуксе уже давно придумали
DS
Вообщем взлетело вот так:
proxy-real-ip-cidr: lbipcidr
server-snippet: |
listen 8443 ssl proxy_protocol;
real_ip_header proxy_protocol;
+ добавил в демонсет 8443 слушать - с 8080 он не захотел прибиндить потому что чем то уже занято - а hostNetwork требует чтобы containerPort = hostPort - поэтому пока оставил http - главное что https завелся
proxy-real-ip-cidr: lbipcidr
server-snippet: |
listen 8443 ssl proxy_protocol;
real_ip_header proxy_protocol;
+ добавил в демонсет 8443 слушать - с 8080 он не захотел прибиндить потому что чем то уже занято - а hostNetwork требует чтобы containerPort = hostPort - поэтому пока оставил http - главное что https завелся
о прикольно