Ну потому что все считают нужным затолкнуть работу через Docker образ. Это имеет свои плюсы если ты хочешь управлять проектами на удаленной машине через WEB интерфейс (чтобы можно было к примеру с мобилки или пданешета в дороге что-то сделать), но ни разу не удобно если использовать на локальной машине. Пока не буду все спойлерить и расскрывать все карты, но в v2 версии будет широкий выбор типов: как Standalone приложение, так и приложение под WEB-ом.
Да, все верно. Стек: Electron + React + Redux + Saga.. На текущий момент самое оптимальное решения чтобы охватить как можно больше платформ, работая в 2 лица. :)
Если не сложно, напишите issue на GitHub. Просто все технические вопросы мы стараемся решать там из-за того, что возможно у кого-то могут быть аналогичные проблемы и они найдут решение и к issue приложите туда свой первичный compose конфиг. Обычно мы решаем проблемы очень быстро либо же issue уходит с лэйблом bug.
Нет лучше документации чем знакомые/друзья devOps-ы или те кто шарит.
Но вообще у меня было 2 ресурса: оф. дока + stackoverflow. Есть видеотуторы, но что-то ничего так толкового не нашел, чтобы я прям сказал что ВААААУ вот это клево и зашло.
На самом деле мне тут уже поступило много предложение на разные пакеты, чаще всего это RPM. Мы это предвидели уже давно, поэтому чтобы не пложить кучу всего выбрали 2 основных: для Debian/Ubuntu и AppImage, который свободно запускается на всех *nix системах.
Здравствуйте. Спасибо.
Я и друг, на сайте есть информация. Вложения только свое время и небольшие финансовые вложения. Да, но с моментом монетизации тема очень и очень неоднозначная. Нужно монетизировать хотя бы для того чтобы была возможность полноценно работать фуллтайм на проекте.
Вы лучше добавляйте комментарий а не редактируйте, если что-то хотите дополнительно уточнить, т.к. не приходят уведомления.
по п.4
По дефолту всегда берется docker-compose.yml и используется как точка вхождения. Обычно чтобы разделить какие-то окружения, исользуют override конифги, типа docker-compose.dev.yml или docker-compose.prod.yml
У нас есть на гитхабе issue по поводу смены как раз этого entrypoint с docker-compose.yml на какой-нибудь кастомный. Это обсуждали, но пока висит под вопросом, будем вводить эту фичу или нет.
Здравствуйте.
1) Есть. Они берутся из параметров depends_on и links. Сплошная от links и пунктирная для depends_on.
2) Да. Вкладка Containers. Выбираете контейнер и нажимаете на кнопку «Remove».
1. В сл. месяце, я думаю нам нужно будет еще недели 4 на все про все.
2. Ну в принципе так-то это не сложно сделать. Я внесу в список, но это будет в v1.5.
3. Немного не понял какой импорт обратно? Мы работаем с нативным docker-compose, т.е. все что мы генирируем и меняем через интерфейс свободно и нативно поддерживается Docker Compose. Т.е. 100% обратная совместимость. Ну а импорт в docker-compose у нас есть из CLI `docker run ...` команд в compose формат.
1) Ведется работа и она будет в v1.4, к слову что будет в сл. версии можете посмотреть здесь: https://github.com/DockStation/dockstation/milestone/4
2) Можно поподробнее что именно вы имеете ввиду под управлением образов? Build, Push, Pull в/из регистра?
Нет, от Kitematic-а у нас нету вообще ничего, мы делали все с абсолютного нуля и к слову тот же Kitematic так просто не подогнать под работу с Docker Compose, там проще с 0 все переделать.
То что есть сходства в интерфейсе, связано с тем, что библиотека которую используем для GUI имеет визуальные сходства. Если интересно: https://github.com/ant-design/ant-design/
Каюсь. Заглушка висит давно. Вначале у нас была идея снять красивый, профессиональный ролик, но не сложилось финансово. Думаю в ближайшее время запишем небольшое видео-ревью, чтобы за пару минут стало понятно кому, для чего и в чем отличия от других.
Да, все верно. Стек: Electron + React + Redux + Saga.. На текущий момент самое оптимальное решения чтобы охватить как можно больше платформ, работая в 2 лица. :)
Спасибо за отзыв!
Спасибо!
Но вообще у меня было 2 ресурса: оф. дока + stackoverflow. Есть видеотуторы, но что-то ничего так толкового не нашел, чтобы я прям сказал что ВААААУ вот это клево и зашло.
Я и друг, на сайте есть информация. Вложения только свое время и небольшие финансовые вложения. Да, но с моментом монетизации тема очень и очень неоднозначная. Нужно монетизировать хотя бы для того чтобы была возможность полноценно работать фуллтайм на проекте.
по п.4
По дефолту всегда берется docker-compose.yml и используется как точка вхождения. Обычно чтобы разделить какие-то окружения, исользуют override конифги, типа docker-compose.dev.yml или docker-compose.prod.yml
У нас есть на гитхабе issue по поводу смены как раз этого entrypoint с docker-compose.yml на какой-нибудь кастомный. Это обсуждали, но пока висит под вопросом, будем вводить эту фичу или нет.
1) Есть. Они берутся из параметров depends_on и links. Сплошная от links и пунктирная для depends_on.
2) Да. Вкладка Containers. Выбираете контейнер и нажимаете на кнопку «Remove».
2. Ну в принципе так-то это не сложно сделать. Я внесу в список, но это будет в v1.5.
3. Немного не понял какой импорт обратно? Мы работаем с нативным docker-compose, т.е. все что мы генирируем и меняем через интерфейс свободно и нативно поддерживается Docker Compose. Т.е. 100% обратная совместимость. Ну а импорт в docker-compose у нас есть из CLI `docker run ...` команд в compose формат.
2) Можно поподробнее что именно вы имеете ввиду под управлением образов? Build, Push, Pull в/из регистра?
Если возникнут какие вопросы, можете смело обращаться. :)
То что есть сходства в интерфейсе, связано с тем, что библиотека которую используем для GUI имеет визуальные сходства. Если интересно: https://github.com/ant-design/ant-design/