Kubernetes — как получить доступ со своей машины внутрь примонтированного хранилища?
Мой кейс:
Есть kubernetes с nodejs сервисом. Я пишу на NodeJS, хочу писать код на локальном компе на своей локальной IDE, при любом изменении в IDE изменения копируется на удаленный сервер через ssh. Это удобно, не надо настраивать локальное окружение, ты можешь работать с любого PC, откуда можешь синхронизировать код по ssh , настройки днс, версии БД и др...
Через докер на удаленном сервере это достаточно просто реализовать, монтируем директорию к контейнеру, даем доступ по ssh к этой директории, запускаем контейнер, вуаля! При изменении кода, измененная часть копируется на удаленный сервер, а-ля supervisor видит изменения , ваши изменения уже на сайте!
Как сделать то же самое в kubernetes, причем хочется, чтобы директория была на ноде вместе с сервисом, а не где-то расшарена на мастере. Я думаю можно было бы создать volume, но пока не понял как получить доступ внутрь него из вне ......
Не достаточно внимательно прочитал этот раздел... Сейчас еще раз его прочту.
В целом получится делать сборку пода , добавлять к нему хранилище с данными, отправлять этот под вместе с хранилищем на ноду и получать доступ из вне к этому хранилищу (как например я бы мог получить доступ к примонтированной директории через ssh в случае с обычным докер контейнером) ?
Или у вас нет готового ответа на это ?
rustler2000, Слегка запутался....
1. Создаем новый деплой
2. Добавляем к нему volume, засовываем внутрь нужные данные
3. Отправляем это все на ноду
4. Как получить доступ именно к volume via ssh ? Пробрасывать ssh порт в поде и давать права чтение\запись?
Как создать директорию - я в курсе, понятно , что ее можно рекурсивно создать , но причем здесь это ?
rustler2000, так а директория сама будет на ноде или на мастере, т.е. там , где создавали ?
По поводу странности - на цвет и вкус фломастеры разные.
Мне вот удобно удаленно развернуть рабочую среду просто подконнектиться туда , вносить изменения и смотреть результат .
Вам docker-compose нужен при таком workflow, а не k8s.
А вообще нормальные люди пользуются системами контроля версий, и пуш с настроенным автодеплоем будет гораздо лучше.
Не понял, причем здесь compose??? Он как бы нужен для упрощения конфигов и деплоя контейнеров.
Я как и все нормальные люди пользуюсь гитом, так же присутствует автодеплой.
Лучше не будет, т.к. он решает совсем другую задачу.
Вы наверно не до конца прочитали вопрос.....
Я хочу производить разработку на локальном компе, компиляция должна быть на удаленном серваке в контейнере, а после всех изменений я делаю пуш в гит.
Кирилл Казаков, Если для сборки проекта вам нужна БД, вы точно делаете что-то не так. Если нужна для прогона тестов - так заведите CI, чтобы он собирал проект и запускал под с этим билдом и окружением.
chupasaurus, Если в проекте на бекенде используется БД - ее никуда не выкинешь, да и зачем, как без БД будет работать проект ? Я вас не понимаю. Уже есть CI на базе Jenkins, я же написал суть вопроса , ДВАЖДЫ ! Зачем вы даете советы, которые никак не связаны с сутью вопроса !??!
chupasaurus, Это не деплой через ssh.
Деплой для dev среды выглядит так :
Через web интерфейс отправляем команду на сборку нужных частей проекта ( отдельно бекенд,новая бд, фронтенд или все вместе )
После успешной сборки мы можем открыть локальную копию фронтенда из гита на своем PC или бекенда и настроив синхронизацию по ssh можем видеть изменения на удаленном сервере
После того, как будем готовы сделать коммит в git, с локальной копии отправляем изменения в гит
При необходимости делаем сборку с новыми изменениями из гит
Плюса такого подхода в следующем:
Все операции по компиляции происходят на удаленном сервере, т.е. ваши локальные ресурсы не расходуются
Вам не нужно у себя делать сборку каких либо частей проекта, чтобы заняться отладкой или разработкой
Вам не нужно что-либо знать о том, как происходит процесс сборки проекта, вам нужно только писать код, все остальное будет сделано автоматически после нажатия на кнопочку сборки
Кирилл Казаков, и чем это лучше привычных пуш - пересборка на CI - деплой? Первые два плюса присутствуют и там, последний - s/кнопочку сборки/push to remote/
chupasaurus, В том, что я не должен на локальном компьютере поднимать всю систему , я сделал 1 изменение в коде, хочу посмотреть результат, но не хочу отправлять это в гит. Я это увижу сразу на удаленном сервере, в противном случае мне на локальном компе надо поднимать , БД , бекенд, фронтенд, выкачивать модули , заливать дамп в БД ну и другие нюансы такие как версионность. модулей.
Еще раз повторяю, это не замена деплою , это более гибкий вариант разработки приложений, для тех , кто не хочет заморачиваться с разворачиванием всей системы на локальном компьютере !
Алексей Ямщиков, Имел в виду, что сделали изменение в скажем в коде веб интерфейса , код синхронизировался, в контейнере наблюдатель ( например supervisor) увидел изменения, пересобрал код, мы увидели результат на веб странице.
