Comments 19
Похоже на ELC
Да, бегло глянул, вроде что-то похожее, но выглядит сложнее. Для себя почерпнул идею, что можно переключаться без указания имени воркспейса, если находишься в папке проекта. Надо будет сделать.
Сейчас ещё раз глянул на описание. Да, я кстати думал наворотить функционал, чтобы поддерживался не только докер. Наверное должно было бы получиться совсем что-то похожее на ELC. Но я сдержался и решил сделать что-то простое под конкретную задачку с docker-compose.
Проблема актуальная, да. Я её иногда решаю примерно так:
docker stop $(docker ps -q) && docker compose up -dЭто остановит все ранее запущенные контейнеры и поднимет те, что описаны в docker-compose.yaml в текущей папке.
В случае с Windows и PowerShell, правда, приходится вместо && использовать ;, но в данном случае это не критично.
Длинно, да, но так как аргументы тут менять не нужно — достаточно просто нажать Ctrl+R в терминале.
Ну, как бы, такое...
Вообще говоря, уже давно мжно давать сервисам имена
Буквально берём compose.yml и пишем
name: app
потом делаем docker compose up -d и docker compose ls и видим name. Собственно в name будет входить всё связанное с проектом. Далее корректнее погасить через docker compose -p app down. И не говрите, что у вас сотни миллиардов запущенных проектов и вы замучаетесь переключать - это проблема на вашей стороне.
Плюс докер умеет в профили. Т.е. каждому сервису можно повесить профиль и запускать (А так же гасить) только нужные профили приложения.
Вообще, самая актуальная проблема с докером в том, что он уже лет 10 как перешёл из разряда хайпа, в разряд обычного инструмента, а люди так и не научились работать с ним и до сих пор лепять какую-то непонятную дичь. ОСобенно это любят делать как раз разработчики, которые делаю докер ради докер, даже там, где он нафиг не нужен.
Не надо давать имена, и уж точно не такие фиксированные.
Одна из фич docker compose - в возможности развернуть несколько независимых проектов рядом. Однако любое фиксированное имя сервиса вызовет конфликт.
Что значит "не надо давать имена"? Кому не надо, тот пусть не даёт. Функция есть. Мне надо - я даю.
Что значит "такие фиксированные"? Я привёл пример. Вы знаете, что такое пример? Это абстракция. Я не буду придумывать за вас имена.
Это не фича docker compose. Это фича docker. Compose Это удобная обёртка, чтобы не пилить конструкции страшного содержимого. И имена вам вообще никак не мешают развернуть несколько независимых проектов рядом.
Более того, расскажу вам очень крутую фишку. Когда-то, 10+ лет назад, когда я ещё был зелёным джуном в джава разработке и не ушёл в инфраструктуру, была там такая штука, как полиморфизм и такая опция, как Override. Я, конечно, извиняюсь, наверное мои знания остались в глубокой древности и современные разработчики не используют такие отсталые инструменты, но в моём мышлении описанная конструкция это всё ещё схема, а итоговая реализация может быть допилена. Так вот, вы не поверите, но описанное в compose.yml это дефолтное значение переменной и его можно переопределить через туже опцию -p или через длинный ключ --project-name. Так что даже если у вас что-то, внезапно, не запустится, а такое иногда бывает, когда Network занят чем-то, то можно просто пересобрать.
Расскажу вам ещё пару хинтов. В докере есть понятие образа, т.е. шаблона изделия и контейнера, т.е. конечной реализации. Как я уже сказал, compose это просто удобный способ делать что-то. Правда бывают ситуации, при которых там описан не image а dockerfile, т.е. образ надо предварительно сбилдить. Потому вызнать надо будет, по хорошему, docker compose --build up -d.
А иногда надо сделать docker compose up -d --force-recreate.
А ещё надо помнить, что погашеный контейнер всё равно существует и может тянуть за собой пачку всякого. Так что иногда неплохо сделать что-то врде docker system prune. Ну, знаете, место освобождает, удаляя кешированые слои, вольюмы с нетворками лишние убирает, а самое офигенное - не трогает текущие контейнеры.
Вообще, самая актуальная проблема с докером в том, что он уже лет 10 как
перешёл из разряда хайпа, в разряд обычного инструмента, а люди так и
не научились работать с ним и до сих пор лепять какую-то непонятную
дичь.
Вот да. По заголовку зашел сказать что то такое, но уже сказали )
Вообще сам всегда запускаю `up` без `-d` чтобы висело где то в консоле `vscode` и по CTRL+C потушить можно было. Ну и не представляю зачем нужно держать кучу запущенных проектов разом. Хотя и делаю всякие финтифлюшки типа ports: ["${DOCKER_HTTP_BIND:-8000}:80"]
Чтобы в `.env` можно было указать другой проброшеный на машину порт.
Можно демонизировать, можно не демонизировать, это вопрос вкуса и потребности.
Просто я уже немного задолбался переписывать кучу всякого за непонятными неумехами.
Люди до сих пор не поняли, что такое контейнеризация и как её использовать. Да и что такое cloud native тоже не поняли. И что такое stateless приложение это тоже вызывает ступор и панику.
Очень часто докер вообще нафиг не нужен, в частности разработчику. Куда чаще нужно навести порядок и начать делать как-то иначе. Т.е. не пытаться решить то, что кажется проблемой, а перестроится и уничтожить их как явление. Инае потом получаются монструозные конструкции, которые работают как попало, а самое главное - зачем они это вообще делают?
Очень часто докер вообще нафиг не нужен, в частности разработчику.
Тут не соглашусь. Я всегда от всяких очередей и редиса сторонился именно потому что не было докера.
Я за подход "запустил одну команду и разрабатывай", а не "установи X Y Z, ах точно еще про A B и C забыли" на свой комп.
`./bin/dev-start` и погнал )
#!/bin/bash
set -e
cd `dirname $0`/..
. bin/.init
./bin/db-init
. .env
export ACT_UID=${SUDO_UID:-${UID}}
docker compose -f docker-compose.yaml -f docker-compose.dev.yaml up
В целом да, указание имени немного облегчает жизнь. Но это не решает полностью проблему, которую я описал и для чего предназначена эта утилита.
Если вы погасили проект по имени, то поднять его по имени уже не получится, надо идти в папку с docker-compose и там писать docker-compose up -d
Чтобы быстро переключиться нужно значительно больше писать в консоли:
docker compose ls
docker compose -p app down
docker-compose up -f where/is/my/project/docker-compose.yml -d
вместо:
dcw up my_project
Так что я считаю, что кому-то это будет наверняка полезно. Мне вот удобно.
У меня ещё есть идея сделать гуёвое приложение, чтобы висело в трее и было видно какое пространство запущено, ну и в выпадающей менюшке была возможность переключить. Жалко что статический бинарь уже не получится.
Есть вариант попроще - вывести текущий воркспейс в bash prompt.
Ну или сделать интерфейс управления в виде веб-приложения, которое показывает какое окружение запущено, позволяет запустит/остановить, и может даже показывает адреса компонентов, получая их из docker inspect (container name + container ip + exposed port) или же из лейблов контейнеров если они заданы
Ну вот веб интерфейс это не очень удобно, надо заглядывать во вкладку в браузере. В трее видеть что сейчас запущено - самое то.
У меня два варианта сейчас, взять Qt и наваять простое приложение для этого. Может его запаковать в AppImage, чтобы было проще распространять.
Второй вариант, например, для KDE можно замутить плазмоид, который будет использовать уже существующий CLI. Второй вариант похуже, так как это только для KDE.
В prompt да, тоже хорошая идея 👍
Я когда-то делал себе "иконку в трее" чтобы управлять vpn-клиентом, у которого есть только cli интерфейс. Кто-то из коллег тогда сказал что вроде как есть уже готовая программа, которая висит в трее и показывает меню, которое задаётся через конфиг. Увы, не помню название.
А этот свой лаунчер я сразу же забросил, т.к. оказалось удобнее просто сделать себе алиасы в баше, а постоянно видеть статус подключения не так уж и важно.
Трей спрячет и так спрятанные вещи.
В чем смысл запускать гору `docker compose` ?
Может быть у вас с организацией проектов проблемы ?
Организационные проблемы выносить в тулзу - такое себе.
ЗЫ. Учитывая что можно было обойтись грубо говоря "bash скриптом", просто захотелось статик uLibc а не этот ваш golang (тупо, но понятно)
Проект чуть больше этого будешь делать и поймешь что "стрелять в ногу" заложено в сраной сишечке )
У меня много микросервисов, в сорцах каждого есть docker-compose с тестовым окружением. Вот поэтому у меня их много. Но я работаю всегда на одним проектом одновременно, но переключаться приходится часто.
C++ выбрал потому что хорошо его знаю и мне сам язык больше нравится чем Go, ещё потому что можно собрать бинарь меньше чем он будет на Go. Сейчас глянул, пустой hello-world уже получается 1,8Мб.
Про стреляние в ногу, везде можно стрелять, не только в сишечке.
Вы слышали об CLI утилите lazzydocker? Отличное решение имхо. Если не хватает функциональности - можно форкнуть
Удобное управление тестовыми окружениями в docker-compose