тю) яндекс "нжинкс аналоги"

чего стесняться то

ну там дашборд и все такое)))

"аналог нжинкс дашборд и все такое"

версия какая? попробуй
PUT _template/name
_template поменяли на _index_template начиная с версии 7.8

Все починил уже спс

Именно так. Просто цикл создания должен включать шаблонизацию

О скольких дашбордах идёт речь? И есть ли смысл в шаблонизации вообще? Как часто меняется содержание и структура дашбордов?

Добрый
есть домен на 1 сервере
на нем certbot, сертификаты всетип топ
есть 2 поддомен на другом сервере
как для него сгенерить сертификаты?

Всем привет!
20–22 апреля приглашаем на DevOpsDays Kyiv 2021 – конференцию о культуре, процессах и инструментах. Проходит в онлайн формате, участие бесплатное. Язык - английский.

💥 В программе:
— Fireside чат c одним из создателей Kubernetes — Joe Beda, вопросы для Joe можно подготовить тут;
— 5 докладов о культуре DevOps от спикеров из Google, PagerDuty, Dojo and Co, amazee.io;
— 10+ технических докладов от украинского DevOps community и не только;
— Open space discussions и Q&A сессии.

Полный список тем и регистрация 👉
https://bit.ly/DevOps-Days-Kyiv

Предстоящие евенты:
1) Online, 20-22 апреля, DevOpsDays Kyiv 2021, https://bit.ly/DevOps-Days-Kyiv
2) Online, 21 апреля, Все для быстрого старта проекта на Managed-базах данных, https://vk.cc/c0UqC1
3) Offline, 31 мая - 1 июня, DevOpsConf 2021, https://devopsconf.io/moscow/2021

Граждане девопсы, как вы порекомендуете сделать?
Есть некий веб-интерфейс, который хотелось бы упрятать в контейнер.
Этот веб-интерфейс должнен уметь запускать/гасить другие контейнеры, но докер-сокет к нему в контейнер засовывать категорически не хочется, я не рассматриваю его как доверенный.
Как ещё можно поступить?

какие-то противоречивые требования

типа я хочу чтобы сервис управлял контейнерами, но не хочу чтобы он управлял контейнерами, т.к. не доверяю ему

Я хочу, чтобы он умел запускать или останавливать разрешённые ему контейнеры, с контролем и проверками. А не именно что "управлял" всем докером до которого дотянется.

Разделить на два. На веб-интерфейс и на сервис управления докерами. Первый как-то передает команды второму.
Можно их размещать в разных периметрах и вообще разрабатывать с разными требованиями к надежности и безопасности

Да, я думал в эту сторону.
Можно конечно нарисовать в доверенном контейнере какого-то мини-демона, чтоб слушал порт, делал проверки и дёргал докер. А недоверенный будет его неткатом просить.

А можно на чём-то готовом реализовать "как-то передает команды"? Своё API костылить неохота :)

Ну, тут у тебя команды как раз "бизнесовые", т.е. берешь любую платформу для веб-сервисов и фигачишь.
От ktor до ror...
Ну или поднимаешь какой-нибудь API GW с возможностью писать свои скрипты - и там фигачишь.
Там и RBAC есть обычно. Но это может оказаться сложнее

в Docker CE нет RBAC, самым правильным вариантом видится юзать кубер, в котором есть RBAC

там можно создать юзеров с урезанными правами и апи писать не надо, оно уже есть, плюс клиенты под все языки