bebebe
envsubst это начало, я жду когда там появится ... | awk | ...
bebebe
а лучше ... | awk | yq | ..
G72K
У меня сотни строк на jsonnet (через ksonnet) , для сложных штук самое оно.
bebebe
коллеги, как бы задача генерации тектовых файло за 30 лет этого вашего POSIX решена не один и не два раза
плясать можно по разному
Rainbow
У меня нет сложных штук в плане devops, кроме этого полно других дел...
G72K
коллеги, как бы задача генерации тектовых файло за 30 лет этого вашего POSIX решена не один и не два раза
плясать можно по разному
Задача генерации структурированных файлов классическими тулзами решена только в m4 и то с натяжкой )
bebebe
я пару недель назад уже предлагал в подобном диалоге да, использоать m4
Rainbow
Его нет в обычных дистрах вроде
G72K
"Все есть строка". В затишье обязательно сяду за PowerShell и может быть расширение для него напишу, что б примитивы куба были встроенными и родными
G72K
Строки задолбали и сдерживают прогресс
Rainbow
JSON вместо строк уже предлагали
Rainbow
Давно
Rainbow
Json pipe и тп
bebebe
(╯°□°）╯︵ ┻━┻
Rainbow
Я же говорю, что я за. А смайл схоронил
Stanislav
Хе... У нас пришли к генерации конфигов для всякого при помощи go, темплейтов и json с параметрами...
bebebe
"Все есть строка". В затишье обязательно сяду за PowerShell и может быть расширение для него напишу, что б примитивы куба были встроенными и родными
я так понимаю, в карму вы совсем не верите? :)
Anton
День добрый. Кто работал с rancher можете помочь?
https://toster.ru/q/563328
G72K
я так понимаю, в карму вы совсем не верите? :)
Со стороны PowerShell выглядит как удачная технология страдающая от предвзятого отношения и вообще инерции мышления. Надо попробовать изнутри, чтобы понять так ли это
Core
ЗАДАЧА:
"Видеть" содежимое каталога "www" в "kubernet-docker"-контейнере и на host-системе:
под "host-системой" понимается "железный" сервер на fedor-e 28.
Что имеем? Делается по "нативной" инструкции:
"Configure a Pod to Use a PersistentVolume for Storage":
https://kubernetes.io/docs/tasks/configure-pod-container/configure-persistent-volume-storage/
PersistentVolume и PersistentVolumeClaim и Pod устанавливаются без проблем.
путь хост-системы: /var/www/html
путь Pod-a: /usr/share/nginx/html
Но вот "хоть убей":
когда "кладём" файл в хост-систему:
echo "Hello World!" > /var/www/html/index.html
на Pod-е его не видно:
ls -la /usr/share/nginx/html
result -> empty
и наоборот:
когда "кладём" файл в Pod:
echo "Hello World!" > /usr/share/nginx/html/index12345.html
на хост-системe его не видно:
ls -la /var/www/html/
index.html
ПРОСЬБА: "пнуть" в правильном направлении:
Как "приготовить" PersistentVolume, PersistentVolumeClaim,
Так чтобы папки и для host-системы и для Pod-а были "те же",
т.е., после "выключения/удаления" Pod-а папки и файлы, созданные на Pod-е сохранялись
на хост системe?
bebebe
Со стороны PowerShell выглядит как удачная технология страдающая от предвзятого отношения и вообще инерции мышления. Надо попробовать изнутри, чтобы понять так ли это
а где можно прочитать про "удачная тенология"? ткните пальцем пожалуйста
G72K
У меня нет какой то статьи куда ткнуть. Из того что понравилось - стандартные интерфейсы для всех команд, т.е. хелп меню, парсинг параметров, форматирование результатов - всем занимается PowerShell , ну и о объекты в пайпах это киллер фича
Core
ЗАДАЧА:
"Видеть" содежимое каталога "www" в "kubernet-docker"-контейнере и на host-системе:
под "host-системой" понимается "железный" сервер на fedor-e 28.
Что имеем? Делается по "нативной" инструкции:
"Configure a Pod to Use a PersistentVolume for Storage":
https://kubernetes.io/docs/tasks/configure-pod-container/configure-persistent-volume-storage/
PersistentVolume и PersistentVolumeClaim и Pod устанавливаются без проблем.
путь хост-системы: /var/www/html
путь Pod-a: /usr/share/nginx/html
Но вот "хоть убей":
когда "кладём" файл в хост-систему:
echo "Hello World!" > /var/www/html/index.html
на Pod-е его не видно:
ls -la /usr/share/nginx/html
result -> empty
и наоборот:
когда "кладём" файл в Pod:
echo "Hello World!" > /usr/share/nginx/html/index12345.html
на хост-системe его не видно:
ls -la /var/www/html/
index.html
ПРОСЬБА: "пнуть" в правильном направлении:
Как "приготовить" PersistentVolume, PersistentVolumeClaim,
Так чтобы папки и для host-системы и для Pod-а были "те же",
т.е., после "выключения/удаления" Pod-а папки и файлы, созданные на Pod-е сохранялись
на хост системe?
"Магия", оказалась в том,что на "хост-системе" файл кладётся:
echo "Hello World!" > /var/www/html/index.html
только после команды:
minikube ssh
Core
"Магия", оказалась в том,что на "хост-системе" файл кладётся:
echo "Hello World!" > /var/www/html/index.html
только после команды:
minikube ssh
После команды
minikube ssh
создаётся файл:
echo "Hello World!" > /var/www/html/index.html
через "minikube ssh" его видно:
ls -la /var/www/html/index.html
-rw-r--r-- 1 root root 30 Sep 17 07:34 /var/www/html/index.html
В Pod-e, его тоже видно (Pod при-mount-ен к /usr/share/nginx/html/):
ls -la /usr/share/nginx/html/
-rw-r--r-- 1 root root 30 Sep 17 07:34 /usr/share/nginx/html/index.html
Вопрос:
Как увидеть на хост-системе (на железном сервере)
вновь созданный файл: "/var/www/html/index.html"
т.е. как увидеть этот файл вне "minikube ssh"?
Rainbow
А может кто в двух словах сказать, что будет с кублетами за натом? Они у меня давно работают, только штуки вроде kubectl logs не работаю. Куда копать?
Core
у тебя куб в вмке
да, в virtualboxe:
sudo minikube start --vm-driver virtualbox --v 1
файл из Poda вытаскивается вот так:
sudo kubectl exec -it nginx -- cat /usr/share/nginx/html/index2.html > /tmp/index2.html
хотелось бы понять:
почему:
ls -la /var/www/html (на железе)
и
ssh minikube
> ls -la /var/www/html
почему - это "разные" каталоги?
Rainbow
они будут одинаковые только если примонтировать через
volumes:
- name: name
hostPath: /var/www/html
Andrey
Core
они будут одинаковые только если примонтировать через
volumes:
- name: name
hostPath: /var/www/html
Спасибо огромное: хорошего дня!!!!
/report
Core
они будут одинаковые только если примонтировать через
volumes:
- name: name
hostPath: /var/www/html
Core
Core
они будут одинаковые только если примонтировать через
volumes:
- name: name
hostPath: /var/www/html
Rainbow
persistentVolumeClaim тут не причем. Просто
spec:
volumes:
- name: html
hostPath: /var/www/html
containers:
volumeMounts:
- name: html
mountPath: /var/www/html
Rainbow
Я не в курсе прокидывает ли minikube примонтированные папки на host систему, если нет, то это отдельно пробросить с vm на хост нужно.
Rainbow
docker - vm - host
вы понимаете, что там такая схема? Выше конфиг под слой docker - vm
Rainbow
https://github.com/kubernetes/minikube/blob/master/docs/host_folder_mount.md
Rainbow
minikube mount
Rainbow
на vm - host
Core
docker - vm - host
вы понимаете, что там такая схема? Выше конфиг под слой docker - vm
Да, на "чистом" docker-e просто:
при монтировании -> файлы, что - на железе, что в doсker-контейнере - те же (bind), видны "одинаково".
в minikube, оказывается для расшаривания хост-директорий и minikube-related, необходим дополнительный "танец с бубном"
в виде: minikube mount ~/mount-dir:/mount-9p
ожидалось: что задачу "minikube mount ~/mount-dir:/mount-9p" возможно решить в рамках yaml-конфига.
Или всё же, указанный вами конфиг рабочий (для Pod-a)? ->
spec:
volumes:
- name: html
hostPath: /var/www/html
containers:
volumeMounts:
- name: html
mountPath: /var/www/html
Rainbow
У вас 3 уровня. Нужно 2 «моста» сделать
Rainbow
От докера к vm и от vm на хост.
Rainbow
minikube запускает кластер в virtualbox
Core
minikube запускает кластер в virtualbox
Вопрос -> как "3 уровня и 2 моста" реализовать в рамках yaml конфига?
Rainbow
Вопрос -> как "3 уровня и 2 моста" реализовать в рамках yaml конфига?
Никак. В конфиге прямой mount. А перед деплоем писать minikube mount
Rainbow
Вообще это странно, не стоит так делать. У каждого разработчика своё окружение, сломаете
Дмитрий
А как сделать в ingress динамический url, который прокидывается на сервис?
Core
Вообще это странно, не стоит так делать. У каждого разработчика своё окружение, сломаете
Так, как же правильно? Для случая "директории-хост-машины-и-Pod-a—те-же"?
Core
Так, как же правильно? Для случая "директории-хост-машины-и-Pod-a—те-же"?
Имеется ввиду не все директри, а к, примеру:
Rainbow
А как сделать в ingress динамический url, который прокидывается на сервис?
Что значит динамический? Там path и весь хвост уходит на сервис. Как location у nginx
Core
Так, как же правильно? Для случая "директории-хост-машины-и-Pod-a—те-же"?
"железо": /mnt/sdd1/kubernetes/storage
"Pod(s)": /usr/share/nginx/html
Дмитрий
я поднимаю kubeless и каждый ендпойнт маппится на определенный сервис (->деплоймент ->под).
Допустим, пишем обычный CRUD через kubeless. Как сделать GET по id?
Но пока что-то не понял, как сделать динамический ingress, который будет мапить его с сервисом. Мб как-то иначе можно это сделать?
Rainbow
Замапить / на kubeless
Дмитрий
А, либо просто внешний сделать ingress типа
http:/..../mymodel - сервис list get
http:/.../mymodel/ - сервис detail get
а там уже получать и парсить оставшуюся часть
Rainbow
Там же у kubeless свой ingress?
Дмитрий
там как-то через kube proxy это делается, но я не совсем пока освоился с ним
Дмитрий
мне проще пока описать свой ингрес
Rainbow
Это базовая вещь которую должны были решить. Точно есть в доке
Yes
Добрый день, вопрос на засыпку - что порекомендуете почитать новичку ? Доки - это понятно.
Sergey
Sergey
https://leanpub.com/the-devops-2-toolkit
Rainbow
там как-то через kube proxy это делается, но я не совсем пока освоился с ним
kubeless ingress
там есть (сам только собираюсь пробовать kubeless). Т.е. каждую функцию нужно забиндить на url
Rainbow
kubeless ingress create route1 --function get-python
Дмитрий
да, я видел это
Дмитрий
но я ещё использую serverless фреймворк для удобной конфигурации функций. А вот там с ингрессом тоже пока не разобрался. Поэтому exposить ендпойнты решил через обычный ingress конфиг)
Andor
чота посмотрел три разных оператора для монги и кажется все херовые какие-то
Andor
может есть готовые не херовые?
Макс
.
Alexander
Нормально ли, у меня кластер на бареметал, если я диапазон nodeport сменю начиная с 80 порта, чтобы ingress nginx работал на 80 порту? Или есть более нормальный вариант?
Artem
Artem
и controller.daemonset.useHostPort
Alexander
есть. controller.hostNetwork=true
Спасибо. Странно, эндпоинт почемуто появился только на одной ноде
Artem
потому что контроллер в 1 экземпляре
Core
"железо": /mnt/sdd1/kubernetes/storage
"Pod(s)": /usr/share/nginx/html
Текущее состояние:
окружение: minikubе -> virtualbox
Чтобы видеть содержимое директории Pod-a /usr/share/nginx/html
на "железной хост машине": /mnt/sdd1/kubernetes/storage
("сквозной bind")
Пока помогло решение:
шаг 1:
sudo minikube mount /mnt/sdd1/kubernetes/storage:/mnt/sdd1/kubernetes/storage
при этом просесс висит в терминале - это - нормально (констатация факта) -> <Ctrl-c> -> не нажимаем.
шаг 2:
sudo minikube start --vm-driver virtualbox --v
Замечено:
В этом случае контент в Pod-e ( /usr/share/nginx/html ) и на "железной-хост-машине" ( /mnt/sdd1/kubernetes/storage )
сохрaняется и при дальнейшем:
sudo minikube stop
sudo minikube start --vm-driver virtualbox --v
Если есть решение в рамках yaml конфига
(видеть содержимое директории Pod-a /usr/share/nginx/html
на "железной хост машине" ("сквозной bind"): /mnt/sdd1/kubernetes/storage)
буду рад увидеть.
D
ребят, подскажите, пытаюсь прикрутить гитлаб к кастомному кластеру кубернетес, при нажатии установить Helm Tiller, ругается:
Kubernetes error: SSL_connect returned=1 errno=0 state=error: certificate verify failed
. мне сказали в чате гитлаба, что это из за самоподписанного сертификата, возможно я накостылял создав admin-user service account и cluster role binding и воткнул этот токен в момент интеграции в гитлабе
D
как правильно делать?