Комментарии 22
А не поделитесь стеком на котором разрабатывали приложение по скриншотам выглядит приятно но так как код закрыт было бы интересно узнать. Местами кажется что там bootstrap на UI
Штирлиц еще никогда не был так близок к провалу
Да, конечно. Electron + React + Redux + Saga. UI сделан с помощью ANT DESIGN.
P.S. можете подписаться, т.к. в скором времени в свет выйдет один небольшой OpenSource проект, на котором будет базироваться сл. версия DockStation.
Странно, что ни втексте, ни в таблице, нет ни слова про поддержку docker swarm mode. Никто не поддерживает, или настолько базовая вещь, что недостойна упоминания?
В разработке и тестировании не видел чтобы он использовался
Используется. В конце концов, если он используется в продакшене, то логично использовать то же в разработке и тестировании, пускай и без масштабирования как самих контейнеров, так и нод кластера: по одному контенейру на единственно йлокальной ноде, то есть отличия дева от прода лишь в параметрах конфигурации, а не в ещё одной конфигурации.
А работа с контейнерами в Swarm Mode поддерживается всеми инструментами.
Имеется в виду не просто работа с контейнерами, а поддержка всех новых сущностей: стэков, сервисов, секретов, конфигов и т. д.
Только:
1) Ваши разработчики конкретно используют включенный Swarm mode?
2) Какие плюсы ловите с того, что Докер будет работать в режиме кластера?
3) Немного не понял за разные конфиги. Что вы имели ввиду? Или это не ок, что мой Compose конфиг одинаково работает как в включенным Swarm mode так и без него.
Если вам нужна работа больше чем управление контейнерами, при этом Вам до сих пор не подходит Rancher, то здесь либо DockStation, либо Portainer. У Portainer-а это внедрено и настраивается отдельными пунктами. В DockStation это все поддерживается, т.к. поддерживается композом, но отдельных пунктов по визуализации нету, т.к. в рамках текущих задач это не является актуальным. Да и не могу понять одной детали: для чего это все разработчикам и тестировщикам? У которых задачи по взаимодействию с Докером обычно лежат в плоскости посмотреть что работает, а что нет, запустить/остановить контейнер, подключиться к удаленке, посмотреть логи, посмотреть что жрет ресурсы. Для DevOps-ов я специально оставил сноску в самом начале статьи.
1) Ваши разработчики конкретно используют включенный Swarm mode?
Да. Почему нет? Одна команда и готов кластер.
2) Какие плюсы ловите с того, что Докер будет работать в режиме кластера?
Единые обвязки деплоя, отличающиеся только параметрами (в частности количество реплик — для дев-тест только 1, для прода 3 по умолчанию) и монтированием томов на локальные папки в дев-режиме. Поддержка одних и тех же фич одним и тем же способом.
3) Немного не понял за разные конфиги. Что вы имели ввиду? Или это не ок, что мой Compose конфиг одинаково работает как в включенным Swarm mode так и без него.
Ну, есть возможности похожие по результату, но различающиеся по реализации в docker/docker-compose и docker swarm mode. Навскидку сразу же — конфиги и секреты поддерживаются только в кластере (если ничего не пропустил), для обычного режима придётся как-то эмулировать через монтирование локальных файлов. Главное, что в двух местах надо будет писать одно и то же и не забывать менять синхронно, чтобы не получить "а у меня на машине всё работает".
Разработчикам локальный кластер нужен, чтобы вводить туда свои сервисы, девопсы потом допиливают под особенности эксплуатации, но никто лучше разработчика не знает, какие внешние зависимости нужны тому или иному сервису.контейнеру.
Хотелось бы больше инструментов для работы с логами
— фильтрация
— поиск по всем логам проекта Docker Compose.
— «интеллектуальный» фильтр по дате/времени — сегодня/1 мин/5 мин/30 мин/1 час
1) Что Вы имеете ввиду под фильтрацией? Поиск обычный?
2) Пока сложно представить как это будет выглядеть, т.к. там будут в перемешку логи с разных контейнеров.
3) Т.е. вывод последних логов за N времени?
Краткий сравнительный обзор GUI решений для работы с Docker