Не очень стандартное использование Docker

В то время как настоящие разработчики активно используют в своей работе всякие продвинутые IDE с элементами искуственного разума - некоторым по прежнему хватает текстового редактора.

Нет, в самом деле, а что еще нужно? Несколько файлов с исходным кодом, Makefile для сборки всего этого, MidnightCommander чтобы копировать файлы туда-сюда и удобный текстовый редактор, например Vim.

А еще куча установленных пакетов типа gcc, make, cmake - в общем, настроенная и подготовленная среда, вплоть до указания желаемой цветовой схемы в редакторе.
И вот однажды так получилось, что удобный настроенный компьютер вдруг накрылся медным тазом: жесткие диски тоже выходят из строя.

Конечно, все самое ценное лежало в архивах, но вот рабочая среда...
Настройка на новом железе, доустановка недоустановленного, в общем куча совершенно лишней работы. И как от нее избавиться на будущее, делать дамп рабочего компьютера? Использовать настроенную виртуалку?

И оказалось, что для этого прекрасно подходит Docker. Во-первых, он есть и используется в работе - не надо ничего выдумывать и осваивать. Во-вторых, он не тормозит и не требует специальной поддержки на аппаратном уровне, и в третьих - всегда можно сделать готовый образ системы, который можно использовать на других компьютерах.

И в четвертых, если возникла необходимость во временной установке каких-то экзотических программ - всегда можно запустить "песочницу", поработать в ней и удалить, не волнуясь о том что где-то сломались зависимости и всё надо снова переустанавливать.

Конечно, кто знает что такое Docker вообще не поймет зачем рассказывать очевидные вещи, но оказывается в 2024 году существуют люди, которые вообще об этом ни разу не слышали, а если и слышали - то о запуске сервисов где-то там на серверах и о всяких строгих правилах создания контейнеров: минимальный обьем, ничего лишнего и т.д.

К черту правила, поехали:
Устанавливаем (всё - debian-style, тлетворное влияние Ubuntu):

sudo apt install docker.io

sudo docker ps

CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES

Пусто. Здесь ничего нет. Попытаемся что-то создать:

docker run -ti debian

Unable to find image 'debian:latest' locally
latest: Pulling from library/debian
53769c348e57: Pull complete 
Digest: sha256:17122fe3d66916e55c0cbd5bbf54bb3f87b3582f4d86a755a0fd3498d360f91b
Status: Downloaded newer image for debian:latest
root@f3fa3de53231:/# 

Ок, скачали и запустили контейнер с Debian, в котором почти ничего нет. Вот его теперь и настраиваем под себя:

apt update

apt upgrade

apt install всё-самое-необходимое все-100500-пакетов

и выходим:

exit

Смотрим, что получилось:

sudo docker ps -a

CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS                     PORTS               NAMES
f3fa3de53231        debian              "bash"              12 minutes ago      Exited (0) 5 minutes ago                       gallant_morse

Контейнер создан, и теперь остановлен. Имя придумывается автоматически, но можно будет потом задать своё.

Сохраним его:

sudo docker commit gallant_morse my_toolbox

Всё, больше gallant_morse не нужен, создан новый образ my_toolbox.
Удаляем лишнее, запускаем новый контейнер, и сразу выходим:

sudo docker rm gallant_morse

sudo docker run -ti --name my_work1 my_toolbox

exit

sudo docker ps -a

CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS                       PORTS               NAMES
2f60aa370d90        my_toolbox          "bash"              1 minutes ago       Exited (0) 1 minutes ago                         my_work1

Создан новый контейнер my_work1, который сейчас выключен. Но его можно запустить:

sudo docker start my_work1

sudo docker ps

Теперь он появится в списке работающих процессов. И как с ним работать? Очень просто:

sudo docker exec -ti my_work1 /bin/bash

Всё, мы попадаем в контейнер, где находятся все рабочие программы. Монтируем сетевые диски - можно работать.

Нужно открыть еще один терминал - запускаем еще один. И еще. И сколько надо.

Не надоело еще писать везде sudo? Если надоело - делаем это последний раз:

sudo vim /etc/group

....
docker:x:121:my_username
....

Перезаходим в систему (открываем новое окно терминала) - всё, docker работает без sudo.
Все открытые терминалы к нему работают в одном контейнере, можно одновременно работать с разными файлами проекта и т.д.

Для чего так сложно, зачем нужно было два раза создавать контейнеры? А вот зачем:
Во-первых, теперь у нас есть образ my_toolbox, его можно экспортировать, сохранить и потом при необходимости запускать на других машинах:

docker save my_toolbox | gzip > my_toolbox.gz

gunzip my_toolbox.gz

docker load < my_toolbox

docker run ...

Во-вторых, можно легко и быстро создать временную песочницу:

docker run -ti --name tmp_bebebe my_toolbox

apt install something_terrible

rm -rf /*

docker rm tmp_bebebe

Или создать рабочую среду с подключением локальных каталогов:

docker run -ti -v /home/user/project/blablabla/work_dir:/work_dir --name blablabla my_toolbox

В общем, можно развлекаться как угодно. Это быстрее делать, чем запускать виртуальные машины с установкой ОС, да и работает оно быстрее.

Конечно, есть и другие решения для подобных задач - это просто один из вариантов.

@JBFW
23.12.2024 23:36 UTC
Первоисточник

Комментарии

@0x00fe
23.12.2024 19:32 UTC
+6

всё уже украдено до нас - https://code.visualstudio.com/docs/devcontainers/containers

@JBFW
23.12.2024 21:19 UTC
0

Это примерно как Kali Linux - можно собрать все под себя, а можно поставить дистрибутив где уже собрали ))

Ну и без MS VS

24.12.2024 02:35 UTC
+1

devcontainers-cli можно использовать без vscode

@QtRoS
23.12.2024 19:35 UTC
+1

В целом бывает удобно собрать контейнер с нужными утилитами определенной тематики, например попадался вот такой toolkit для bug-bounty: https://registry.hub.docker.com/r/hackersploit/bugbountytoolkit

@black1277
23.12.2024 21:36 UTC
0

Весьма, интересное применение докера! Надо будет замутить для себя образ с настройками редакторов под конкретные цели...

@lexore
24.12.2024 02:35 UTC
0

Конечно, все самое ценное лежало в архивах, но вот рабочая среда...

Можно расширить область того, что считается ценным и начать бекапить избранные файлы и папки "~/.name".

@
24.12.2024 06:05 UTC
0
НЛО прилетело и опубликовало эту надпись здесь
24.12.2024 07:52 UTC
0

и начать с /

Потому что /etc/*, /usr/lib/*, и т.д.
Или сделать сразу дамп рабочей станции, о чем и была речь ))

25.12.2024 08:13 UTC
+1

Для /etc есть etckeeper.

24.12.2024 08:29 UTC
0

Гит для этого плохо подходит, особенно когда будет идти речь про большие файлы. Себе настроил snapper (поверх файловой системы btrfs). Точно не помню, но по умолчанию хранится 10 ежемесячных/10 ежедневных/10 ежечасных бекапов.

@remzalp
24.12.2024 04:10 UTC
+13

Меня сильно покоробило:

sudo vim /etc/group

docker:x:121:my_username

Вы уж если не особо образованных людей просвещаете, что посоветовали? Добавить строчку? Отредактировать строчку? Что в этом случае будет? А с кривыми ручками пользователя, работающего по инструкции?

Человечьим языком - добавить своего пользователя в группу докера и будет хорошо, но это делается через usermod, а никак не прямым редактированием groups

@jackgrebe
24.12.2024 04:29 UTC
+1

но это делается через usermod

это делется примерно десятью плюс-минус PI разными методами.
догматики и зубрилы должны страдать.
"не особо образованные люди" тоже должны страдать.

24.12.2024 07:26 UTC
+5

не, ну товарищ прав -- что за 121? кривая магия. на убунте это avahi вообще)..

@JBFW
24.12.2024 07:55 UTC
0

Вообще-то предполагается что юзер найдет строчку с ключевым словом docker и проставит там себя как члена группы.
Без вписывания цифры 121 вместо оригинальной (я просил 400 капель, а здесь 402!!)

usermod примерно это и делает, только с дополнительными телодвижениями.

@andmerk93
24.12.2024 07:30 UTC
+3

Велосипед, который вы придумали, называется Devcontainers. И он уже вполне стандартный.

Теория - https://habr.com/ru/articles/814071/

Практика - https://habr.com/ru/articles/734062/

Спецификация - https://containers.dev/

Обратите внимание на первую статью, там люди делали примерно то же, что и вы, только раньше и лучше.

Cобирать девконтейнеры можно не только на VS Code / VSCodium, для JetBrains уже тоже есть. Если сильно хочется собрать такое на Vim, гугл показывает статьи и реддит с решениями на NeoVim, выглядит рабочим. Хотя я бы рекомендовал не сходить с ума, просто взять VSCodium, обвешать плагинами и включить хоткеи из вима. Знакомые вимеры говорят, что почти то же самое.

@JBFW
24.12.2024 08:20 UTC
-2

Я не продаю решение, не предлагаю новый велосипед, я просто написал об использовании технологии которую применяю сам примерно лет 7+, чтобы не соврать (когда там у меня диск посыпался?). Эт во-первых.

А во вторых - я описываю именно сам подход.
Это не обязательно должно быть программирование на c++, не обязательно связанное с какой-то организацией, компанией или консорциумом.
Это может быть, например, "разработка сайтов на PHP", где у разработчика настроена среда со всеми нужными зависимостями, или работа с каким-то хитромудрым фреймворком, который абсолютно так же точно может быть установлен в контейнере, или программирование девайсов с установкой специфических тулчейнов.

И это может сделать буквально любой на коленке, опять же не обращаясь к компаниям, организациям и консорциумам.
Взять и сделать как удобно самому. Это просто, не надо гуглить решения, принцип одинаковый.

А предложение заменить удобный МНЕ инструмент на какие-то мутные VS-чего-то-там, или хотя бы просто по похожий на названию NeoVim, потому что где-то _написано что оно должно работать_ почти так же, да еще "обвешивать плагинами" - ну, это и есть тот самый подход "поставить IDE покруче и посовременнее", от которого я ушел давно и целенаправленно ))

Не нужны там лишние плагины. Лучше mc ими обвешать: этот файл редактируем, этот компилируем, этот заливаем через репозитарий на тест, а этот через USB в прошивку.

@simplepersonru
24.12.2024 12:24 UTC
+2

писал примерно об этом статью https://habr.com/ru/articles/849432/, упаковать все свое рабочее окружение в докер-контейнер
Работаю так уже 2 года

@JBFW
24.12.2024 13:17 UTC
-1

Ну да, о том и речь.

@Jolt
24.12.2024 16:57 UTC
+2

@JBFWкажется вам стоит попробовать NIX OS))

@lsw
24.12.2024 18:41 UTC
+2

На волне популяризации докера шутили, что "скоро vim будем из докера запускать". Прошло N лет...

@Pubert
25.12.2024 07:17 UTC
0

Теперь давайте прокинем в docker образ X-11 сервер, и будет вообще конфетка

@JBFW
25.12.2024 08:25 UTC
0

а вот это уже излишество: Х-сервер работает с железом, ему не надо в контейнере сидеть, т.к. именно железо тут и может меняться.
Разве что Xvnc какой-нибудь или Xrdp...

25.12.2024 21:04 UTC
0

Wayland или X11 , причем тут железо.. даже с wsl через x11 прокидывали в те времена пока МС не сделала все проще. Xvnc rdp абсолютно не удобны для разработки. Запаритесь экраны переключать, особенно если машина разработки может содержать только софт для разработки, без почты, мессенджер и тп..

25.12.2024 22:20 UTC
-1

X-сервер - это та часть системы, где стоит монитор с видеокартой, вот причем тут железо. Как правило вы за ним сидите, на рабочей станции.
Кроме случаев где "монитор" виртуальный, те же vnc или rdp.

А то, что к нему подключается, прикладной софт, даже если он крутится на сервере - это X-клиенты. Почему все это путают постоянно?

Насчет удобства для разработки при наличии почты и мессенджера говорить вообще нельзя - это жутко отвлекающие штуки. Ну, кроме тех людей которые постоянно коллег дергают "а подскажи как это делать?".

Вот переключать экраны как раз удобно ))

@kain64b
25.12.2024 21:05 UTC
0

Каких только костылей не напридумывают https://www.vagrantup.com/

@JBFW
25.12.2024 22:24 UTC
0

Одних только виртуалок сколько уже напридумывали ...

@Tony-Sol
25.12.2024 22:15 UTC
0
  1. export XDG_CONFIG_HOME=$HOME/.config

  2. cd $XDG_CONFIG_HOME

  3. git init; git add .; git commit -m 'all my configs'; git push

  4. PROFIT

А если серьезно, то метод с контейнером конечно тоже неплох, но не исключает предварительного провижена новой машины. Имхо лучше или прям конкретно заморочиться с flakes для nix или не заморачиваться вообще и просто как в шутке выше xdg_config_home в репозиторий положить

@BaJIepoH
26.12.2024 06:41 UTC
+1

Просто надо конфиги под энвы отдельно в репозитории хранить. Задумка хорошая, но я вот сталкивался с тем что через некоторое время шаг в сторону приводит к пересборке, гаданию где и чего еще надо напильником доработать. Как итог - я просто не использую винду, а свои конфиги под ансибл,вим и zsh я храню в гите. Под zsh до недавнего времени использовал только те параметры, для которых не надо ставить плагины и расширения.