Комментарии 11
Полагаю что подобный образ типа Hello World! будет занимать килобайты и требовать килобайты же ОЗУ если написать его на C, а не на NodeJS. В чём проблема использовать инструмент, соответствующий задаче?
То что раньше делалось на десятках мегабайт ( а еще раньше в килобайтах), теперь требует десятки гигабайт, а скоро и терабайтом не спасешься при таких подходах
Смотря что вы понимаете под «то что раньше». Не уверен, что решение из статьи самое оптимальное и что на данный момент вообще есть смысл использовать werf, но докер образ на k8s это определённо не то же самое, что просто поднять сервер, который будет отвечать на пинги.
Собственно, если разобраться в компонентах, я не нахожу ничего излишнего:
1. Докер образ нужен для того, чтобы все зависимости приложения и окружение были прописаны явно и не менялись в зависимости от машины, i.e. сводим к минимуму «работает на моей машине».
2. Докер registry, соответственно, нужен просто как хранилище этих образов.
3. k8s отвечает за масштабирование приложения, следит за жизнью контейнеров, раскидывает их по нодам.
4. Ингрес — по сути «мост» между внешним миром и внутренней сетью k8s.
Если у вас есть на примере решение, которое обеспечивает те же характеристики, но в разы проще — пожалуйста, поделитесь. Я порядка 5 лет работал со связкой docker + k8s и многие вещи там делать невероятно легко, на мой взгляд.
Вот тут люди мучаются с "лишней" детализацией (какие-то секции .text модифицируют, сражаются с безопасностью виндового загрузчика и вообще творят извращёный секас). Но в результате они умеют творить изящные миниатюрные штуковины.
Докер с кубом предлагают осилить столь же "лишние" абстракции (а теперь вот Флант с верфью подсуетился помочь с ними удобнее управиться). Опять же, чтобы запускать изящные миниатюрные штуковины.
Боюсь, нормальная человеческая психика должна выбирать одно из двух, что ей ближе: абстракция или детализация. Если конечно есть вкус к изящным миниатюрным штуковинам.
Так что да, абстракции не для всех. Ассемблер с его детализациями лично я уважаю, но издалека.
PS> werf converge --repo <ИМЯ ПОЛЬЗОВАТЕЛЯ DOCKER HUB>/werf-first-appздесь по-прежнему хочет докера (десктоп винда).
А можно обойтись без отдельного докера на хосте, раз уж под рукой миникуб в hyperv ?
Docker сейчас является зависимостью для запуска werf, так что если хотите запускать werf на хосте, то Docker Desktop на Windows таки надо будет поставить.
С другой стороны, теоретически, вы можете поставить werf на одну из нод minikube и попробовать запускать его там, но этот сценарий не проверялся, и часть инструкций по подготовке окружения изменится (как минимум то, что связано с доступом через ингресс).
А почему не хочется Docker на хост ставить?
А почему не хочется Docker на хост ставить?
Ну, просто чтобы не множить сущности без необходимости. docker-desktop для винды жирный, docker-engine только для виндовых контейнеров. Кстати, ваш tldr до боли похож на виндовый scoop (добавляет тому секурности). Подумайте о том, чтобы сделать один субкомандой другого. Мотивация:
1) $env:HOMEPATH/bin на винде пришелец из чуждого мира; прочие портированные с линя пакетники обычно добавляют в PATH каждый свой отдельный bin.
2) scoop юзает свою отдельную хитрую машинерию, чтобы обойтись без общего bin в хомяке и без симлинков (в результате не требует и привилегии симлинки создавать). И вообще, scoop мастхэв пакетник для винды, особенно для CLI инструментов включая портированные: например, обратите внимание на scoop install sudo.
Ну и, обоих tldr и werf недостаёт в репах исконно виндовых пакетников (лично я прежде юзал chocolatey, сейчас предпочитаю scoop).
Спасибо за фидбек.
Scoop по сути получается альтернативой chocolatey или msi-установщикам. У нас в планах разобраться с тем, как лучше устанавливать werf на Windows. Для Linux/macOS недавно сделали установщик (Bash-скрипт), который под капотом устанавливает trdl, и через trdl устанавливает werf, ну и делает ещё некоторые вспомогательные штуки. Что-то подобное хочется иметь и под Windows, как это будет реализовано (скрипты, пакеты, установщики) будем смотреть ближе к делу.
И всё же сам werf будет устанавливаться только через trdl. Основные причины: высокая безопасность (судя по вики scoop у них на это такого большого фокуса нет), эффективные автообновления (что самого trdl, что ПО, которое им устанавливается), кроссплатформенность. Подробнее можно почитать тут: https://ru.trdl.dev/ Хотя мы обязательно подумаем, сможем ли мы как-то подвязать trdl+werf к пакетным системам вроде snoop.
Можно попробовать ещё такой вариант:
& minikube -p minikube docker-env | Invoke-Expression
werf converge
ingress addon не поддерживается драйвером докера на MacOs. Это связано с ограничением Docker Bridge на Mac. Поэтому кто будет пытаться повторить весь этот путь на маках, используйте --driver=hyperkit для старта minikube
Первые шаги с werf: собираем и деплоим простое приложение в Kubernetes