Отличное дополнение к статье! Для моих целей думаю это будет лучше хранения образов в Gitea, но если кто-то серьёзнее будет выбирать и наткнётся на статью и ваш комментарий, это может помочь. Спасибо =)
Спасибо за ответ. Пользователи в докере и правда порой доставляют проблем. Про подключение диска в докер тоже понял. Закину в идеи и подумаю, как об том всём можно подробно написать =)
Не совсем понял про NFS (знаю только файловую систему такую), нужно уточнение.
Про запуск контейнеров от пользователя, в смысле без композа? Я честно не вижу в этом большого смысла. Если запускать один контейнер локально, ещё ладно, но на серваке гораздо удобнее пользоваться композом. Моё мнение.
Да. Очень грубо говоря, это GUI для докера, с возможностью управлять не только локальным, но и внешними докерами через агента. Также в нём имеется API, которое можно использовать, например, в CI
У меня в хозяйстве ноды разных провайдеров. Все ходят в один kubernetes control plane. И я ими управляю "из одного интерфейса". Всё на opensource без вендорлока. Если бы я хотел взять "одну тулзу, чтобы править всеми" я бы взял расширяемый и кастомизируемый набор стандартных компонент, вроде DeckHouse.
Не буду спорить, не пробовал Control Plane.
В чём кайф данного проприетарного инструмента с оплатой лицензии за число нод под управлением?
В таблице представлено множество интересных и полезных решений, авторы которых не один день потратили на изучение и написание, но первое место отхватывает ленивый вайб-кодинг, серьёзно? Настолько человеческий труд теперь обесценен или это такая политика Сбера/GitVerse?
Проще говоря выбирали не по "полезности", а по "трендовости". Сейчас все носятся как "курицы с яйцом" вокруг вайб-кодинга, каждый может стать "программистом" не являясь программистом. И вот такие результаты полностью нивелируют человеческий труд в пользу "хайпа".
Бот всего лишь интерфейс взаимодействия с пользователем. Если не брать в расчёт простейших ботов отвечающих на сообщения предзаготовленными сообщениями, то они могут как много ресурсов потреблять за счёт большой внутренней логике, так и работают такие обычно не на polling, а на webhook сценарии, с реализацией ещё и API. Ну и у упомянутой амверы цены ни разу не демократичные.
Да) И ещё интересно попробовать его управление докерами на серваках в связке с CI, чтоб стучаться в портейнер и делать дела, а не подключаться к каждому по SSH.
У меня в Gnome вот такая панелька, хотелось бы вынести это в отдельный экран, т.к. в полноэкранных приложениях или играх её не видно, а вкорячивать OSD нет желания:
Не пробовал его, если есть опыт, поделитесь =)
Отличное дополнение к статье! Для моих целей думаю это будет лучше хранения образов в Gitea, но если кто-то серьёзнее будет выбирать и наткнётся на статью и ваш комментарий, это может помочь. Спасибо =)
Больше всего интересно разграничение доступов на те или иные образы по конкретным пользователям)
Стараюсь, но если где ошибаюсь, смело меня поправляйте)
Спасибо за ответ. Пользователи в докере и правда порой доставляют проблем. Про подключение диска в докер тоже понял. Закину в идеи и подумаю, как об том всём можно подробно написать =)
Не совсем понял про NFS (знаю только файловую систему такую), нужно уточнение.
Про запуск контейнеров от пользователя, в смысле без композа? Я честно не вижу в этом большого смысла. Если запускать один контейнер локально, ещё ладно, но на серваке гораздо удобнее пользоваться композом. Моё мнение.
Однако, идеи для следующих статей принимаю)
На скриншот можно нажать и он откроется в полном размере.
Да. Очень грубо говоря, это GUI для докера, с возможностью управлять не только локальным, но и внешними докерами через агента. Также в нём имеется API, которое можно использовать, например, в CI
Не буду спорить, не пробовал Control Plane.
Статья написана для тех, кому "за глаза" бесплатной Community Edition, которая вполне себе Open Source https://github.com/portainer/portainer
Ответил выше
Portainer поддерживает и k8s и Swarm. Речь не про то, чтобы кластеры, а про то, что можно управлять докерами с разных VPSок из единого интерфейса.
Выскажу своё "брюзжащее фи".
В таблице представлено множество интересных и полезных решений, авторы которых не один день потратили на изучение и написание, но первое место отхватывает ленивый вайб-кодинг, серьёзно? Настолько человеческий труд теперь обесценен или это такая политика Сбера/GitVerse?
Проще говоря выбирали не по "полезности", а по "трендовости". Сейчас все носятся как "курицы с яйцом" вокруг вайб-кодинга, каждый может стать "программистом" не являясь программистом. И вот такие результаты полностью нивелируют человеческий труд в пользу "хайпа".
А мне он стал интересен) Планирую в несколько статей дальше углубиться в его работу =)
Погуглил, он я полагаю больше для кубера? У меня пока нет необходимости в кубере, композов хватает с головой.
Бот всего лишь интерфейс взаимодействия с пользователем. Если не брать в расчёт простейших ботов отвечающих на сообщения предзаготовленными сообщениями, то они могут как много ресурсов потреблять за счёт большой внутренней логике, так и работают такие обычно не на polling, а на webhook сценарии, с реализацией ещё и API.
Ну и у упомянутой амверы цены ни разу не демократичные.
Нет ничего более постоянного, чем временное =)
Да) И ещё интересно попробовать его управление докерами на серваках в связке с CI, чтоб стучаться в портейнер и делать дела, а не подключаться к каждому по SSH.
Мне теперь больше интересно попробовать его как "панель управления" докерами на разных серверах)
У меня в Gnome вот такая панелька, хотелось бы вынести это в отдельный экран, т.к. в полноэкранных приложениях или играх её не видно, а вкорячивать OSD нет желания:
Тоже Rust)) Но пока особо в подробности не вдавался, хочу сперва получить железку) А потом уже "методом научного тыка" разбираться в его работе)