не совсем понимаю задачу. Выкинуть порт в интернет и повесить авторизацию не подходит?

Ну задача с траблшутингом нормально решится через порт, думаю. А вообще, например локально запустить тестовый клиент который должен иметь доступ ко всем адресам... Но, скорее всего, я не правильно понимаю концепцию, и нужно использовать ingress

ну, собственно, я про это и говорил. Как минимум, это нормальная практика

вообще, 1. можно ли как-то подключиться к weave сети с мака? 2. Так вообще делают?

weave/flannel/calico..

ну в теории очень даже реально, но на практике такого не видел. Может кто другой ответит

Ок, мне важно знать что юзают обычные люди))

спасибо

Вот еще, тупой базовый вопрос. (Я пробую мир куба, хотя всю жизнь работаю с амазоном). вот есть helm charts. и есть stable/mysql. В доках написано как вручную задеплоить. А как это запихнуть в что-то а-ля docker-compose? Народ пишет счто создает common.yml, prod.yml итд. Есть где-то базовые примеры структуры репозоитория со всем этим добром?

хочу сориентироваться на низшем уровне, типа "куда мне вписать `stable/mysql`", докер композ все понятно и явно, тут не особо). Копировать charts в свой репозиторий как-то не хочется.

Посмотрел тесты... по идее будет достаточно положить db.yml charts: - stable/mysql - stable/postgresql и запустить helm db.yml | kubectl apply -f - ?

(в простейшем виде, конечно)

и да, какие best practices? каждый конфиг под своим неймспейсом запускать?

Ну вот есть деплой kubernetes конфига через ansible, оно вообще одобряется? Модуль kubernetes?

Посмотрел тесты... по идее будет достаточно положить db.yml charts: - stable/mysql - stable/postgresql и запустить helm db.yml | kubectl apply -f - ?

чарты хельма — это просто шаблоны, в которые вставляются нужные "значения". helm install --name my-release --namespace production -f my-values-for-prod.yml path_to_chart Если правильно синтаксис помню. Это вариант, где в кластере установлен tiller, ваш вариант выше — это просто генерация шаблона и деплой голым kubectl

Ну ок, а как это запилить в единый конфиг файл?

что есть конфиг-файл?

Или нужно чарт отрендерить и сохранить как конфиг куба?

ну, который применим при помощи kubectl apply или ansible

Чтобы в итогде запустить одну команду а она все остальное развернет.

да, чарт нужно пропустить через хельм и на выходе получатся сконкаченые манифесты кубернетеса (в теории, так ещё не делал)

да, чарт нужно пропустить через хельм и на выходе получатся сконкаченые манифесты кубернетеса (в теории, так ещё не делал)

Ну то есть "правильная" практика - хранить все в манифестах? А как же зависимость от helm? Я запарился.

настройки как генерить манифесты находятся в values.yaml, который вы подсовываете хельму в определённый чарт. Так же можно использовать аргументы, которые переопределяют проперти в values.

Вот представим, что мы сдаем работу заказчику. Работа должна быть в репозитории, со списком внешних зависимостей

с хельмом не особо сталкивался, написал свой шаблонизатор на sed'е и не парюсь

с хельмом не особо сталкивался, написал свой шаблонизатор на sed'е и не парюсь

да не, прост проще же

Ну ок, при таком раскладе как разворачивать известный софт который может поддерживаться коммьюнити?

типа mysql

да не, прост проще же

это ойти стыд

Ну ок, при таком раскладе как разворачивать известный софт который может поддерживаться коммьюнити?

можно хельмом, можно свой чарт\манифест и поддерживать самому. Можно вообще оператор написать) Много вариантов. Можно один софт так развернуть, другой так

Вот в этом и запар) Меня интересует наиболее поддерживаемый сообществом вариант, похоже что. это helm

это ойти стыд

ну для чего-то сложного — конечно седом не обойтись) Для ELK писал свой чарт

helm для коммьюнити, понятно. для своего - шаблонизатор либо манифесты для сред, выходит так?

тогда как хранить свзи с helm чартами?

Вот в этом и запар) Меня интересует наиболее поддерживаемый сообществом вариант, похоже что. это helm

да, только вот к хельму существует 2 подхода деплоя: 1. использовать хельм чисто как шаблонизатор и просто генерить манифесты, а потом деплоить через kubectl. 2. использовать helm+tiller.

tiller рабоатет как шаблонизатор - деплой на стороне сервера, так?

Условно — да. Прочитайте лучше доку по helm: https://github.com/kubernetes/helm

Краткий ответ: Helm has two parts: a client (helm) and a server (tiller)

Обязательно. Но все же вопрос, как это все хранится в репе ?

в докер компоуз, например, мы описываем службы и деплоим именно этот файл. Там образы с тех или иных репозиториев явно прописаны... Что у меня в случае с helm (в случае с tiller)? не похоже что я должен хранить манифесты...

тут тоже несколько подходов. Кому как нравится. Кто-то хранит чарты\манифесты рядом с софтом, а кто-то отдельный репо только с манифестами\чартами делает.

Ну вот отдельный репо вариант.

я хочу задеплоить mysql из чарта по стандарту. Скажем, что мой репо деплоит mysql и nginx. Есть какой-то conventional подход как это все хранить? в доках не особенно про подходы

каждый делает как ему нравится, единого подхода как и везде в кубернетесе — нет

можете по чату тут поискать, много холиваров было

каждый делает как ему нравится, единого подхода как и везде в кубернетесе — нет

Ну вот спрашиваю личного мнения, как мне сохранить конфиг для nginx, mysql

с минимальной дупликацией апстримовского кода

нужно понимать объём приложения, поделить его на логические части, если получится, и деплоить независимыми частями. Хранить как душе угодно.

конкретнее подсказать не могу. На мой взгляд, деплой mysql и nginx — это настолько абстрактно, что можно и без helm-а справиться.

Я задаю очень базовые вопросы чтобы понять куда складывать дальнейшие знания.

Ну вот, https://github.com/kubernetes/charts/blob/d284317c2258f4e9d6a870d79db1e4095e441ac3/stable/lamp/examples/wordpress.yaml

это что?

это чарт или пример манифеста или пример параметров для чарта?

с минимальной дупликацией апстримовского кода

Helm

Helm

Ну вот я смотрю в эту сторону.

это чарт или пример манифеста или пример параметров для чарта?

это values-файл для конкретной сборки той солянки, что доступна в чарте

Ну вот я смотрю в эту сторону.

Респект таким пацанам

это values-файл для конкретной сборки той солянки, что доступна в чарте

Ок, понял. То есть мне надо как минимум value файл сохранить в репе. далее helm натравить на чарт с этими value.

а потом селать kube apply из того что получится, так?

да, но помните, что chart'ы могут внезапно поменять свой синтаксис и уже вроде и не круто совсем)

да, но помните, что chart'ы могут внезапно поменять свой синтаксис и уже вроде и не круто совсем)

Как это? Ведь версионность helm никто не отменял?

поэтому тут вариант — форк или submodule

А, речь про содержание а не синтаксис.

про сам чарт. Сегодня есть поддержка мускула в этом чарте, а завтра уже нет.

вот я о чем и задумываюсь, в ansible есть requirements.yml где это все решается, типа requireemnts.txt для python.

Теперь к самому важному. Как мне описать список чартов и сохранить это, а потом натравить н это helm?

Не каждый же раз вручную вводить helm install --name mysql stable/mysql ?

именно так, для апгрейда и релоада всяких конфигов у хельма есть механизм upgrade

Ну представим что там 40 чартов для всей инфраструктуры надо. Я даю всю работу заказчику, он должен 40 раз запустить это? или обернуть в bashскрипт? неуженли встроенного механизма зависимостей нет?

(я доки почитаю, конечно)

в скрипт

ещё раз напоминаю — хельм по большей части просто шаблонизатор

ну официально он называется The Kubernetes Package Manager

так же можно обратить внимание на ansible-container

но там порог вхождения/внедрения больше чем helkm

ммм, спасибо

Видимо как раз то что я искал

но он чарты уже не берет, похоже.

Последний раз когда я его смотрел, это был docker-compose на стеройдах

он с чартами не работает. а умеет сам шипать в k8s/openshift