Рабочая C++ IDE в docker container

Привет, Хабр! Программирую на C++ / Qt / QML в среде разработки QtCreator уже 6-ой год. У меня есть определенные пересечения мыслей с мозгом груга и еще мне постоянно хочется избавиться от глупой и рутинной работы, которая есть на разных этапах разработки. Одна из таких работ — возня с IDE и рабочим окружением, особенно в мире C++ разработки. В статье постараюсь раскрыть проблему и описать свой текущий подход к решению.

Проблема

Мы пишем кросс-платформенный десктоп C++ клиент-серверный продукт, и у наших разработчиков довольно развесистое рабочее окружение. В системе должно быть многообразие библиотек, некоторые переменные окружения. Иногда это добро расширяется. Плюс есть множество полезных настроек в самой IDE, многими плюшками с моей подачи пользуются коллеги: настроенные форматтеры кода определенных версий, некоторые удобные сниппеты, шаблоны создаваемых библиотек и файлов, конфиг статического анализатора и многие другие, тут на целую статью наберется.

1. Если разработка идет на нескольких компьютерах (домашний, рабочий, ноутбук), то нужно везде поддерживать одни настройки, версии библиотек и прочие детали окружения. Где-то я обновил систему, где-то не обновлял, что-то случайно затерлось. В итоге на всех рабочих компьютерах рабочее окружение отличается, это раздражает

2. Если в команду приходит новый человек, то на первоначальную настройку среды и сборку проекта уходит от одного до пары рабочих дней. Любой крупный проект обрастает нюансами, в которых нужно разобраться

3. Иногда проект изменяется таким образом, что у всех разработчиков внезапно ломается рабочее окружение, нужно что-то поменять. Добавилась необходимая переменная окружения, библиотечная системная зависимость и тд. И всю следующую неделю рабочий чатик разрывается одним и тем же вопросом «а шо делать», несмотря на то, что этот вопрос задавался 2-мя экранами выше. Справедливо, мы ведь работаем, а не чатики читаем 🙂

4. Если нужно на рабочем компьютере переустановить операционную систему. Редко, но случается, особенно под Linux. Тогда даже опытный разработчик возвращается к проблеме номер 2 и кучу времени тратит чтобы восстановить свое рабочее окружение и продолжить работать, ведь последний раз он с нуля все настраивал с годик назад

5. Иногда хочется поэкспериментировать с рабочим окружением, но это может привести к его окирпичиванию. На рефлекторном уровне гасится желание ковырять это окружение для улучшений, особенно после неприятных историй, которые приводят к п.4. Работает — не трожь!

Наступил день, когда эти проблемы меня доконали и я решил что-то с этим сделать.

Требования

Сформулировал требования к решению

1. Достаточно поддержки одной операционной системы — Linux

   Продукт кросс-платформенный, но конкретный разработчик чаще всего сидит на одной системе. Распределение примерно 50 на 50 (Linux, Windows), зависит от предпочтения. Мой выбор продиктован личным предпочтением + пониманием, что автоматизировать разворачивание Linux среды будет сильно проще.

2. Быстрое развертывание (пара минут)

3. Поддержка нескольких версий

4. Быстрая и удобная доставка обновлений до пользователя

5. Коробочное решение — открыл и работаешь

6. Плавность работы, как у нативного приложения

После недолгих раздумий я пришел к Docker.

Решение

DockerFile

Это был мой первый опыт написания Dockerfile. После пары первых попыток столкнулся с тем, что при билде контейнера система просит указать таймзону в интерактивном режиме (для каких-то зависимостей это нужно), на этом ожидаемо валится билд.

p.s. почему-то не вижу в настройках вставки кода язык «Dockerfile», пускай будет «C#» : — )

FROM ubuntu:20.04 ENV TZ=Asia/Yekaterinburg ENV DEBIAN_FRONTEND=noninteractive

Пакеты. Я несколько раз полностью менял стратегию того, как я скачиваю пакеты. По итогу пришел к тому, что update и install должны всегда быть в рамках одного шага, потому что их разделение сработает только в первый билд, а если потом поменять зависимости, то update не отработает и будет проблемес, если он успел устареть. А еще после каждого скачивания в этом же шаге подчищать за собой, это я подсмотрел на форумах.

Итоговый шаблон для скачивания пакетов:

RUN apt update -y && apt install \ lib1 lib2 ... \  -y && apt clean -y && apt autoremove --purge -y

Зависимости, которые понадобились для запуска QtCreator в докере, собраны опытным путем. Выставлял переменную окружения (вроде QT_DEBUG_PLUGINS=1) и это давало расширенный лог ошибки запуска. Там было видно какой библиотеки не хватает. Так было проделано N раз, по количеству недостающих библиотек

RUN apt update -y && apt install \ libgl1 libxkbcommon-dev libegl1 libfontconfig-dev libgssapi-krb5-2 \ libdbus-1-3 libxkbcommon-x11-0 libxcb-icccm4 libxcb-image0 libxcb-keysyms1 \  libxcb-render-util0 libxcb-shape0 libxcb-xinerama0 libxcb-cursor-dev \  -y && apt clean -y && apt autoremove --purge -y

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

Чтобы внутри контейнера работал отладчик, добавил это, решение взял отсюда

RUN echo 0 > /etc/sysctl.d/10-ptrace.conf

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

Локали. Видел разные решения на форумах, работали с переменным успехом, в итоге получилось что-то такое

RUN apt install locales -y && \ locale-gen en_US.UTF-8 ru_RU.UTF-8 && \ update-locale LANG=ru_RU.UTF-8  ENV LC_ALL=ru_RU.UTF-8  ENV LANG=en_US.UTF-8

Свою задачу выполняет и ладно

Создание юзера. Достаточно важный пункт, т.к. по умолчанию контейнер стартует под рутом. В дальнейшем мы будем прокидывать директории хоста в контейнер, например исходники проектов, над которыми идет работа. Любые изменения в файлах/директориях со стороны контейнера приведут к изменению прав на root, и с хоста они будут по умолчанию недоступны без sudo. Неудобненько.

Удивительно, но на этот пункт было потрачено много усилий, почти никакие не-интерактивные способы с интернетов не работали нормально.

ENV USER_NAME=uzver RUN adduser $USER_NAME; usermod -aG sudo $USER_NAME; echo "$USER_NAME:123" | chpasswd USER $USER_NAME ENV HOME=/home/$USER_NAME WORKDIR $HOME

После этих изменений, качать пакеты в Dockerfile не получится, т.к. у обычного юзера нет прав, поэтому все зависимости желательно качать до того как установим пользователя. С другой стороны, именно от лица пользователя нужно копировать в образ все что нам нужно (среду разработки, утилиты, сборочный комплект, настройки и тд), потому что пользоваться контейнером будем от имени созданного пользователя

Примерно так добавляем саму среду разработки. Я брал архив тут

COPY --chown=$USER_NAME qtcreator14 $HOME/qtcreator  ENV PATH=$PATH:$HOME/qtcreator/bin

При копировании указываем принадлежность файлов юзеру. И добавляем пути в PATH если им там нужно быть. Для всего остального что нужно копировать принцип такой же.

Многие конфиги, настройки профилей сборки, компиляторов, отладчиков. Я заранее настраивал это в контейнере и копировал конфиги на хост, чтобы они всегда были одинаковыми, с одинаковыми UUID различных сущностей и тд, чтобы была строгая детерминированность при различных запусках

Запуск контейнера с хоста

Чтобы открывались окошки, перед запуском контейнера необходимо сказать своему x-server, чтобы он давал к себе подключиться. Сначала сделал так

xhost +

Потом подумал, что «access control disabled, clients can connect from any host» наверное не хочу иметь подключения от any host. Можно свести команду к

xhost +local:$USER

Уже приятнее. Эту команду необходимо выполнять каждый раз перед запуском контейнера

Также перед запуском хочется иметь на хосте директории, которые мы пробрасываем через volume. Например, для утилиты ccache директорию ~/.ccache. Соберем всё в запускаемый скрипт my-ide.bash

#!/bin/bash xhost +local:$USER mkdir -p $HOME/.ccache docker start -i CONTAINER_NAME

Точка входа

Сначала я думал сделать точку входа команду qtcreator, которая запускает среду разработки. Тогда при запуске контейнера сразу запускается окошко с IDE. Проблема в том, что не было прямого доступа к терминалу контейнера, а при останове самого qtcreator, контейнер завершал свое выполнение. Иногда очень нужно иметь доступ к терминалу внутри контейнера

Вариант 2 — стартовать bash, тогда пользователь при запуске оказывается внутри оболочки bash и может открывать и закрывать программы, оставаясь в этой оболочке. Но тогда пользователь всегда при запуске контейнера с IDE будет вынужден прописывать эту команду qtcreator руками.

Нашел вариант побороть проблему. Итоговый Entrypoint:

/bin/bash --init-file /home/uzver/utils/init_script.bash

Самое простое (к сложному чуть позже) возможное содержимое этого файла, в моем случае такое:

#!/bin/bash qtcreator&

Таким образом окошко IDE запускается в фоновом режиме и пользователь сразу имеет приглашение ко вводу в терминале контейнера, идеально.

Я также использовал возможности такого способа для кастомизации IDE по некоторым параметрам. Например, некоторые коллеги используют автоформатирование, а некоторые нет. Для некоторых проектов нужен qbs одной версии, для других другой.

Эти параметры задаются переменными среды на хосте, чтобы при обновлении контейнера, при его начальном запуске, эти параметры подтянулись и донастроили систему. Получилось примерно так

#!/bin/bash  if [ "$CONTAINERIDE_ALREADY_CONFIGURED" != "1" ]; then    export CONTAINERIDE_ALREADY_CONFIGURED=1    if [ "$CONTAINERIDE_AUTOCLANGFORMAT" == "0" ]; then     crudini --set "$HOME/.config/QtProject/QtCreator.ini" Beautifier "General\\autoFormatOnSave" false    else     crudini --set "$HOME/.config/QtProject/QtCreator.ini" Beautifier "General\\autoFormatOnSave" true    fi    if [[ "$CONTAINERIDE_QBSVERSION" == 1.20* ]]; then     export PATH=$PATH:$HOME/qbs-1.20/bin    else           export PATH=$PATH:$HOME/qbs-2.3.0/bin    fi  fi  qtcreator&

утилита crudini отлично выполняет свою роль — протолкнуть значение по имени секции + по имени ключа в конфигурационный файл .ini

Создание контейнера из образа

Эту процедуру я вынес в скрипт my-ide-update.bash

#!/bin/bash  # Аргумент запуска - tag, по умолчанию latest DEFAULT_TAG="latest" TAG="${1:-$DEFAULT_TAG}"  # Имя образа IMAGE_NAME=MY_IMAGE_NAME # Имя контейнера CONTAINER_NAME=MY_CONTAINER_NAME # Программа, которая будет запущена PROGRAMM="/bin/bash --init-file /home/uzver/utils/init_script.bash"  docker pull $IMAGE_NAME:$TAG docker rm $CONTAINER_NAME  docker create \ -ti \ --cap-add=SYS_PTRACE \ --name=$CONTAINER_NAME \ --net=host \ -e DISPLAY \ -e CONTAINERIDE_AUTOCLANGFORMAT \ -e CONTAINERIDE_QBSVERSION \ -v $CONTAINERIDE_PROJECTS:/home/uzver/projects \ -v $HOME/.ccache:/home/uzver/.ccache \ -v /dev/dri:/dev/dri \ $IMAGE_NAME:$TAG $PROGRAMM

Некоторые пояснения:

#Чтобы иметь прямой доступ к терминалу системы внутри контейнера -ti  #Чтобы работал отладчик --cap-add=SYS_PTRACE  #ENV CONTAINERIDE_PROJECTS пользователь определяет на своем хосте, эта директория монтируется в контейнер как директория для проектов по умолчанию  -v $CONTAINERIDE_PROJECTS:/home/uzver/projects  #ENV CONTAINERIDE_AUTOCLANGFORMAT, CONTAINERIDE_QBSVERSION пользователь определяет на своем хосте, они помогут в донастройке системы под эти параметры -e CONTAINERIDE_AUTOCLANGFORMAT  -e CONTAINERIDE_QBSVERSION 

Раньше эта процедура была связана с запуском контейнера и там был примерно такой код, опускаю лишние детали

DOCKER_PS=$(docker ps -a)  # это чтобы записать вывод команды pull в файл для дальнейшего анализа docker pull $IMAGE_NAME | tee OUT_FILE OUT_STRING=$(cat OUT_FILE)  COMMAND="docker create ..."  xhost +  mkdir -p $HOME/.ccache  #Если контейнер на текущий момент не создан  if [[ $DOCKER_PS != $CONTAINER_NAME ]]; then    echo "Создаем контейнер на основе свежего образа"    $COMMAND  #Иначе, если контейнер создан и мы обновили образ, удалим контейнер и создадим новый  elif [[ $OUT_STRING != "Image is up to date for" ]]; then    echo "Образ обновлен. Удалим текущий контейнер и создадим новый"    docker rm $CONTAINER_NAME $COMMAND  else    echo "Текущий контейнер использует свежий образ" fi  rm OUT_FILE  docker start -i $CONTAINER_NAME

Таким я видел рабочий контейнер изначально, чтобы бесшовно доставлять обновления пользователю IDE, все происходит через один скрипт. Этот скрипт проверяет обновления и скачивает их, либо запускает текущий контейнер, если обновлений нет.

Мне думалось, что если я быстро решу ново-возникшую проблему с рабочим окружением, пользователь даже не заметит проблему. Заметили. Такой подход приводил к ряду проблем:

1. Никто не любит внезапных автоматических обновлений

2. Если крупно поменялись слои образа, пользователь может попасть на 5-10 минутное ожидание, вместо одной секунды, за которую обычно запускается IDE.

3. Я бы хотел иметь команду навроде docker check IMAGE_NAME latest, которая проверяла бы соответствие локального образа с образом на сервере по определенному тэгу, но ничего подобного не нашел (с кавалерийского наскока, а глубже не разбирался). Тогда можно было бы при запуске проверять версию и ненавязчиво предлагать обновиться, если есть желание.

   Вместо этого я искал в стандартном выводе команды docker pull некоторые слова, как например \*»Image is up to date for»\*, чтобы делать вывод о наличии обновления. Проблема в том, что этот вывод я получу уже после фактического обновления, а еще в том, что красивый форматированный консольный вывод от команды docker pull, сильно ломается если прогонять его через те костыли, которыми я все это подпер

Я пришел к тому, что обновление должно быть сознательным процессом. Я пришел к этому форсированно, т.к. узнал что для одних это стало поводом запускать IDE напрямую через докер команды (минуя мой скрипт), для других это стало поводом стучаться в личку и «а шо так долго не запускается, в прошлый раз запускалось быстро, наверное сломалось». Поэтому обновление и запуск разделены на 2 скрипта

Что можно улучшить

1. Кэшировать больше пользовательских данных
   Сессии, сохранение положения окон, кэш поисковых запросов, паттернов файлов для поиска, … Сейчас при обновлении контейнера многие вещи затираются, т.к. они вперемешку с настройками, которые я хочу выставлять принудительно. Можно делать это только через crudini, сохраняя большинство пользовательской информации. А сами конфиги через volume использовать хостовые. Но это снижает независимость контейнера и в общем пока эту тему не трогаю

2. Прокинуть драйвер звука
   Возникла необходимость в разрабатываемом продукте запустить некий звук. С учетом что там дергаются драйверы, поведение отличалось от тестирования на обычном хосте. С кавалерийского наскока не разобрался как это сделать, быстрее было поставить окружение на хост, чтобы решить задачу. Но осадочек остался

3. Добавить простенький браузер, файловый менеджер
   Когда в коде есть ссылка или нужно открыть директорию с файлами, приходится возвращаться на хост из уютного контейнера

4. Расширить линейку поддерживаемых версий сред разработки и различного инструментария
   С учетом ограниченности ресурсов на текущий момент я выпускаю новые версии, когда наберется некоторое количество улучшений, которые уже недостаточно поддерживать только в локальном контейнере и хочется зафиксировать их. Старый релиз остается только в хранилище для тех кто им еще пользуется, но я не вношу туда изменения, даже если то окружение уже не соответствует действительности разработки. Жива только та версия, на которой я активно работаю, потому что я могу быстро заметить проблему. Жизнеспособность других версий под вопросом

5. Сделать гигачад IDE С++ из VSCode
   Я рассматривал этот вопрос, но уперся во многие вещи, которые в qtcreator есть из коробки, а в VSCode нет даже в формате расширений. Значит пришлось бы писать и поддерживать эти расширения. Если бы у меня было больше ресурса на эту задачу, я бы сделал контейнер на базе VSCode, как ультимативную C++ среду разработки. Ряд фич я подсмотрел у Clion, «можем повторить». И как игра в долгую VSCode как-то интуитивно больше нравится. Но это лишь ощущенения

Итого

Я в таком формате работаю уже больше года, и это реально доставляет мне удовольствие. Коллеги активно пользуются. Кто хоть раз вкусил свободу от мыслей про рабочее окружение, не остался равнодушным