Comments 62
Идеологически правильнее было бы запускать эти сервисы отдельно, и линковать через docker-compose.
Идеологически правильнее было бы не использовать lxd, это деградация и откат к временам монолитных серверов с мешаниной конфигов. "Портянка сервисов" обеспечивает инкапсуляцию зависимостей.
"Портянка сервисов" обеспечивает инкапсуляцию зависимостей.
зато докеры не обеспечивают персистенцию данных и бонусом хвост еще кучи проблем (с теми же сетями и файрволлами). Спорить можно до хрипоты правильно ли так делать.
А разработчиков я активно уговариваю на vagrant вместо того, чтобы докер пихать в каждую дырку. Как бы под каждую задачу — СВОЕ решение.
На самом проблема статьи — это описание проблематики. Зачем так автор делает? Если речь про облако — я всегда могу затащить виртуалку в нужной конфигурации из шаблона (packer & terraform). Если какие-то vdsки на недохостингах… Ну, что ж — выше коллега советует справедливо lxc/lxd. Либо еще варианты.
Отчасти, да, для примитивного персистенца хватит. Но там надо думать все равно — постоянные нюансы с правами на файлы (если нужно пошарить файлы между несколькими контейнерами или ходить с хоста не под рутом). Это не вжух и магия ( к сожалению.
А по докеру — ну, там ещё отдельные приседания, чтобы systemd в нем завести. Вопрос зачем? А затем, чтобы не городить эти сумасшедшие скрипты запуска. Ну, и пользоваться всеми преимуществами этой инии-системы.
А по докеру — ну, там ещё отдельные приседания, чтобы systemd в нем завести.
Если вам в докере нужен systemd — значит вы что-то делаете неправильно.
Одно приложение — один контейнер. И никакого systemd.
Если вам в докере нужен systemd — значит вы что-то делаете неправильно.
нет. Иногда тестировать софт приходится и тогда это оправдано, но я согласен, что в общем случае это странный граничный кейс, которого лучше избегать.
Одно приложение — один контейнер. И никакого systemd.
очередная догма, которая нарушается сплошь и рядом. Можете рассказать это, например, gitlab'у, который свой докер образ предоставляет со всем нужным (редис, пума, постгрес, гитлаб). Вопрос точки зрения и целей использования. В остальном соглашусь (опять же), что лучше такого сценария избегать.
Мы видим что поехал контейнер, инстанцированный из образа x/y:z.
Мы знаем, что образ x/y:z содержит только приложение Q.
Таким образом мы будем разбираться с исходником приложения Q, а не Q, V, M, если в контейнер запихали именно их.
То, что гитлаб делает не так — оставим на совести гитлаба.
В конце концов, можно накостылить свой systemd/init-like, но это неизбежно влечет за собой борьбу с граблями, ради которых оные и были придуманы.
Вы разделяйте свою внутреннюю разработку, где необходимы правила, и в целом жизнь — тот же гитлаб в такой поставке прекрасно упрощает жизнь разработчику-тестировщику, которому поднять инстанс = docker pull && docker run, а не разбираться в 100500 компонентов и их взаимосвязях. Я сам это не очень люблю, но это подход "докер как пакетный менеджер" в каком-то смысле.
Мы знаем, что образ x/y:z содержит только приложение Q.
К сожалению, это так не работает. Как правило выясняется, что Q не написан Вами, то тянет за собой A, B и C, которые добавляются в образ. А потом еще и не факт, что не конфликтуют с каким-нибудь D, который был в x/y:z. Ах! Еще забыли, что если там внутри какой-нибудь компилируемый язык типа C++, то он запросто может привязаться к архитектуре проца или его фиче флагам. И потом этот докер образ перестает быть переносимым (это не то, чтобы прям ГИПЕР проблема, но это регулярно стреляет и это надо иметь в виду, например, если занимаешься ML). И самое главное из всей этой истории — что если ты делаешь from scratch и добавляешь минимальный набор файлов и свой сервис, то ты молодец. И используешь докер правильно. А если делаешь какой-нибудь from python:3.7, а потом pip install и куча дичи, то это просто попытка замести мусор под ковер со всеми вытекающими нюансами.
В конце концов, можно накостылить свой systemd/init-like, но это неизбежно влечет за собой борьбу с граблями, ради которых оные и были придуманы.
еще раз — если у бизнес-заказчика есть задача — тестировать некие окружения, в которых systemd используется — есть развилка — или использовать тяжелую виртуализацию типа kvm/vagrant, либо lxc/lxd, либо костылять вокруг докера. Каждый решает для себя сам во что стоит идти. Например, это может понадобиться для такого. Просто примите, что у всех задачи разные. Но сказать, что это прям невозможно нельзя. Вот, например, пацаны запилили https://www.hippolab.ru/zapuskaem-systemd-v-docker-konteynere
которому поднять инстанс = docker pull && docker run, а не разбираться в 100500 компонентов и их взаимосвязях
извините, но нет.
docker-compose -f smthng.yml upэто регулярно стреляет и это надо иметь в виду, например, если занимаешься ML
да, но нет. nvcr.io/pytensorflow:* замечательно переносимы и не стреляют, если не заниматься отсебятиной, запускать на ubuntu 18.x, и не забывать про необходимость видеокарты.
Просто примите, что у всех задачи разные.
Так я ж не спорю. Можно и микроскопом гвозди забивать. Если надо тестировать окружение с systemd, где systemd прям обязан стрелять — да, kvm/vagrant/vbox/whatever из гипервизоров.
извините, но нет.
фу, еще и компоуз тащить. Со всеми его нюансами. Например, в последней версии они до сих пор ключ --gpu не реализовали. Ну, оно и понятно — компоуз не для прода, чисто разработческая штука, которую допиливают по мере возможности. А то что при этом python-docker страдает параллельно… Да всем пофиг.
да, но нет. nvcr.io/pytensorflow:* замечательно переносимы и не стреляют, если не заниматься отсебятиной, запускать на ubuntu 18.x, и не забывать про необходимость видеокарты.
фу, будто других целевых платформ нет, и одним единым tensorflow живы.
фу, еще и компоуз тащить. Со всеми его нюансами. Например, в последней версии они до сих пор ключ --gpu не реализовали
Если вам нужен ключ --gpu — то вам нужен NGC, если вам нужен NGC — вы, очевидно, знаете, как его запустить и соркестрировать с другими контейнерами из консоли.
За этим исключением в проде замечательно живет. Несколько менее замечательно, чем k8s, но сильно проще.
фу, будто других целевых платформ нет, и одним единым tensorflow живы.
тут ключевое nvcr.io. а так-то хоть FROM nvcr.io/cuda:10.1 собираться можно, и компиляться прям внутри. RUN nvcc и погналити. люблю этих ребят.
Учитывая, что речь про дистрибутивы gnu/linux — крайне рекомендую попробовать x2go, его обычно достаточно в электричке с lte для вещей использующих ускорение(например QtCreator, glxgears e.t.c.).
docs.docker.com/compose/compose-file/#shm_size
После подключения необходимо ввести пароль от пользователя заданный ранее. Так же рекомендуется сразу же его сменить для большей безопасности.
Для большей безопасности следует подключаться по VNC только через SSH туннель. Иначе все пароли и VNC траффик передаются в открытом виде.
Однако при подключении через туннель задержка явно будет больше.
А у меня дома рабочая машина стоит на Debian 10 и KDE или i3, я бы хотел подключаться к существующей сессии (идеально вообще к display manager, чтобы можно было выбрать wm), но tightvncserver сразу новую неполноценную открывает.
github.com/squizduos/code-server-dev
Нет ну конечно, это займет не пару секунд, а пару минут, но во-первых в отличии от контейнеров виртуальный сервер не надо сбрасывать так же часто, во-вторых все удобства докера заканчиваются на его быстром запуске.
Всю мелкую кастомизацию Visual Code, которую вы делаете после запуска, например, в меню View, вы планируете делать каждый раз после сброса контейнера?
В ходе разработки понадобилось доустановить либу на php? yum install...; service httpd restart? Нет, мы не ищем легких путей, пересоберем контейнер еще разок, запуск же всего несколько секунд.
Решили поменять внешний порт/ip? Не вопрос, сейчас опять пересоберем контейнер, это же так удобно.
Но самая большая проблема — чистый докер уже не модно и не профессионально. Ждем статью «удаленный рабочий стол на кластере Kubernetes с распределенной файловой системой»
Всю мелкую кастомизацию Visual Code, которую вы делаете после запуска, например, в меню View, вы планируете делать каждый раз после сброса контейнера?
Можно просто монтировать папку с хоста внутрь докера, и никаких проблем с сохранением настроек нет.
А можно просто запустить visual studio никуда её не монтируя ¯_(ツ)_/¯
И еще я забыл упомянуть, что докер-композ будет работать примерно пол года, потом версии пакетов и их источники в репах и интернете обновятся, и вам придется уделить ему романтический вечерок под чашечку кофе, и если вдруг, например, из-за несовместимостей с иной версией gcc что-то перестанет компилиться, то вас даже ждет ночь полная страстного секаса.
PS Понятное дело что всегда можно найти обходные пути и костыли, но ломать ноги, чтобы искать костыли… Мне кажется это работает не так.
Что я сделал не так?
Для включения красивого оформления как в скриншоте выше необходимо зайти в Пуск > Preferences > Appearance > LXQt Theme и выбрать тему Kde-plasma.
Пуск > Preferences > Appearance >
не нахожу.
На черном экране могу по правой клавише выбрать только Desktop Preferences.
Как сделать так, чтобы докер строился уже с выбранной темой?
FAQ
Defaul root
И в комментах к файлам:
add support reolution from paramter,
forums.docker.com/t/is-it-possible-to-runn-docker-engine-on-android-devices/16135/8
Если уж совсем ударятся в легковесность, то наверное оно будет точно лучше CentOS, не?
Кстати, я посмотрел на образы OpenSUSE… и как то они меньше по объему, чем CentoS, в два раза почти. Точно оно потребляется больше ресурсов, чем CentOS?
alpine — как правило — отдельный геморрой с зависимостями, а выгоды не очень
https://habr.com/ru/post/486202/
https://m.habr.com/ru/post/415513/
И это только вершина айсберга.
По suse в образах ничего не скажу. Сама система неплохая, но не очень популярная. Поэтому никто особо на ней собирает. Обычно — ubuntu, debian, alpine. С этой точки зрения — тоже, если что-то пойдет не так, то придется колдовать самостоятельно.
Если кто то разберется и пришлет пул реквест или решение внедрение которого не займет много времени, буду премного благодарен.
VNC, при рестарте, смотрит в /tmp/ на наличие свободных дисплеев и видит там уже занятый порт первого дисплея. Создавай новый дисплей, VNC помещает его в порт 590* т.к. 5901 уже занят занят первым дисплеем. Таким образом, 5901 залочен дисплеем, для которого не существует VNC процесса, и присоединистя невозможно.
Решение: $sudo rm -fr /tmp/.X11-unix/; rm -fr /tmp/X1-lock; rm -fr /home/headless/.Xauthority; rm -fr /home/headless/.vnc/*.log; rm -fr /home/headless/.vnc/*.pid с последующим рестартом контейнера. VNC должен работать после рестарта.
Извините, но это не решение, а костыль — мы как бы в XXI веке, а программы все еще не умеют полноценно в лок-файлы (facepalm). Я бы предложил разработчикам VNC подумать об использовании нормальной обертки для сервиса (вот здесь пригождается systemd с его возможностью мониторинга процессов, но, сорян, мы в докере), либо системные функции вроде flock()
Добавил
system «rm -fr /tmp/.X11-unix/*; rm -fr /tmp/X1-lock; rm -fr /home/headless/.Xauthority; rm -fr /home/headless/.vnc/*.log; rm -fr /home/headless/.vnc/*.pid»
без судо, до запуска vnc. Теперь контейнер можно перезапускать.
$sudo rm -fr /tmp/.X11-unix/; rm -fr /tmp/.X1-lock; rm -fr /home/headless/.Xauthority; rm -fr /home/headless/.vnc/*.log; rm -fr /home/headless/.vnc/*
поясните свой вопрос, пожалуйста
И да, и нет. Нет — в смысле — докер — это всего лишь изоляция процессов, а не виртуализация железа. Да — в смысле — могут понадобиться дополнительные телодвижения. Например, пока не прокинете устройство аудио в докер контейнер — аудио из него не вывести.
Да — в смысле — могут понадобиться дополнительные телодвижения. Например, пока не прокинете устройство аудио в докер контейнер — аудио из него не вывестиИмхо, но это одна из самых важных частей. LabEG привёл то, что можно относительно быстро найти, однако не упомянул насколько работоспособным получится результат.
Я некоторое время назад создавал lxd контейнеры, и выяснение подобных подробностей как раз и помешало полноценно этим пользоваться, поскольку из коробки оно не заработало, а времени на доведение до ума не хватило.
Рабочая станция в Docker контейнере