Тоже люблю TreeStyleTab, в дополнение к нему использую Dustman, расширение которое автоматически закрывает вкладки если я на них не вернулся в течении некоторого времени
Да ну, какая императивность? — что мешает описать все ваши шаблоны и объекты мониторинга в виде нескольких yaml-файлов? Применять их можно в любом порядке, с ними легко работать, их можно версионировать, хранить в vcs, следить за изменениями и работать с ними в разных окружениях.
Что не так-то?
Ну не сказать, и snap и appimage оба вполне юзабельны, особенно если автор не хочет раскрывать исходники, но хочет предоставить гарантировано рабочую копию для любого дистрибутива.
Лично я предпочту установить spotify или skype в snap нежели обычными пакетами в виду своей проприетарности.
в docker-entrypoint всякая дичь и софт, который через пакетный менеджер ставится, не всегда ожидает, что он будет запущен, скажем, не от рута.
Это вообще антипатерн, здесь я с вами согласен. Но это проблема не Docker как системы оркестрации контейнеров, а это проблема образов, которые вы используете.
Возможно я смотрю на Docker со своей башни (Kubernetes) где всё хорошо и не замечаю проблем у простых пользователей, которые просто пытаются использовать готовые образы из Docker Hub'а, простите меня за данное допущение.
Чем процесс запущенный в Docker отличается от запуска такого же процесса в системе? — ничем. Чтобы не было проблем с правами достаточно запустить контейнеры с одинаковыми uid/gid. Docker это давно умеет.
По факту я бы советовал рассматривать Docker не как альтернативу LXC, а скорее как альтернативу Systemd.
Обе системы запускают и следят за процессами, то что процесс работает в контейнере — в каком-то смысле второстепенно.
Если честно не знаю как это организованно в docker, но в Kubernetes есть специальная абстракция — Pod, можно сказать это наименьшая единица для запуска workload в кластере. Описать два разных контейнера в одном Pod'е не составляет никакого труда (это всего несколько строк в одном yaml-файле).
Да, работа с Kubernetes ломает привычные принципы и требует определённого уровня сноровки, но научившись "правильно" работать с контейнерами, поверьте, многое становится проще и понятнее.
А в чём проблема запустить php-fpm и nginx в разных контейнерах?
Они всё также могут смотреть в одну директорию и общаться друг с другом через tcp/unix-сокет
Это именно альтернатива докеру и есть, т.е. он предоставляет пользователю знакомый интерфейс для запуска контейнеров в cri-o. В kubernetes тоже есть нативная поддержка cri-o
Тоже люблю TreeStyleTab, в дополнение к нему использую Dustman, расширение которое автоматически закрывает вкладки если я на них не вернулся в течении некоторого времени
Хороший вопрос, на данный момент вручную, но в 12.7 обещают сделать возможность генерировать пайплайн динамически:
https://gitlab.com/gitlab-org/gitlab/issues/16094
Зато TAB есть
А если добавить туда ещё мобильную акустику и аккумулятор помощнее, то получится просто бомба для вылазок с друзьями на природу :)
Неплохая идея, возьму на вооружение!
Как сделать хорошо?
Нужно сделать плохо, а затем вернуть как было...
Спасибо за отзыв, меня тоже смутил данный недостаток, видимо теперь тоже подожду с покупкой.
ИМХО, Fn+стелочки — лучшее решение для размещения Home, End, PgUp, PgDown.
Вот нафига делать их отдельными кнопками да ещё и в таком неудобном месте?
А разве snap не запускает пакеты в chroot?
Да ну, какая императивность? — что мешает описать все ваши шаблоны и объекты мониторинга в виде нескольких yaml-файлов? Применять их можно в любом порядке, с ними легко работать, их можно версионировать, хранить в vcs, следить за изменениями и работать с ними в разных окружениях.
Что не так-то?
Ну не сказать, и snap и appimage оба вполне юзабельны, особенно если автор не хочет раскрывать исходники, но хочет предоставить гарантировано рабочую копию для любого дистрибутива.
Лично я предпочту установить spotify или skype в snap нежели обычными пакетами в виду своей проприетарности.
для конечного пользователя ничего не изменится
и пошёл играться
да, но он встаёт и работает с Kubernetes без каких либо проблем
Как по мне, нет лучше дашборды чем openshift-console:
Намеренно или нет, но почему-то во всех обзорах её забывают упомянуть.
Это вообще антипатерн, здесь я с вами согласен. Но это проблема не Docker как системы оркестрации контейнеров, а это проблема образов, которые вы используете.
Возможно я смотрю на Docker со своей башни (Kubernetes) где всё хорошо и не замечаю проблем у простых пользователей, которые просто пытаются использовать готовые образы из Docker Hub'а, простите меня за данное допущение.
Почему нет? Разработчик и сам может это сделать.
Времена когда для запуска Kubernetes требовалось потратить половину рабочего дня давно прошли.
Теперь же локальный Kubernetes-кластер можно запустить всего в одну-две команды.
Чем процесс запущенный в Docker отличается от запуска такого же процесса в системе? — ничем. Чтобы не было проблем с правами достаточно запустить контейнеры с одинаковыми uid/gid. Docker это давно умеет.
По факту я бы советовал рассматривать Docker не как альтернативу LXC, а скорее как альтернативу Systemd.
Обе системы запускают и следят за процессами, то что процесс работает в контейнере — в каком-то смысле второстепенно.
Если честно не знаю как это организованно в docker, но в Kubernetes есть специальная абстракция — Pod, можно сказать это наименьшая единица для запуска workload в кластере. Описать два разных контейнера в одном Pod'е не составляет никакого труда (это всего несколько строк в одном yaml-файле).
Да, работа с Kubernetes ломает привычные принципы и требует определённого уровня сноровки, но научившись "правильно" работать с контейнерами, поверьте, многое становится проще и понятнее.
А в чём проблема запустить php-fpm и nginx в разных контейнерах?
Они всё также могут смотреть в одну директорию и общаться друг с другом через tcp/unix-сокет
Это именно альтернатива докеру и есть, т.е. он предоставляет пользователю знакомый интерфейс для запуска контейнеров в cri-o. В kubernetes тоже есть нативная поддержка cri-o
Не смотрели в сторону Nomad?