Niedawno pomyślałem sobie jak to wdrażając drugą osobę w nowe środowisko do pracy z nową technologią możemy mieć problem. Zamiast wymagać od nich umiejętności instalacji X paczek, edycji plików konfiguracyjnych, etc. chcemy dać im środowisko, gdzie kod od razu będzie się kompilował. A jakby użyć do tego Docker?

Postanowiłem przygotować sobie środowisko do pracy z F# i .NET Core, więc utworzyłem Dockerfile, który bazował na obrazie microsoft/dotnet:2.0-sdk. Zacząłem od instalacji paczki F#. Ponieważ na razie nie ma wsparcia FSI dla .NET Core to oznacza to zainstalowanie całego mono-complete. Następnie chciałem zainstalować w obrazie VS Code. Do tego okazuje się potrzeba bardzo dużo paczek

RUN apt-get install libnotify4 libnss3 libxkbfile1 libgconf-2-4 \
                libsecret-1-0 libgtk2.0-0 libxss1 libasound2 -y
RUN curl -L "https://go.microsoft.com/fwlink/?LinkID=760868" -o vscode.deb
RUN dpkg -i vscode.deb

Na koniec określiłem, żeby uruchamiając kontener uruchamiać VS Code i czekać na jego zamknięcie (flaga -w)

CMD code -w /home/dev/workdir --user-data-dir /home/dev

Tak przygotowany Dockerfile zbudowałem poleceniem

docker build -t manio143/fscodeenv .

Następnie trzeba urchomić kontener w trybie udostępniania X11. Obecnie protokół X11 posiada pewne zabezpieczenia, więc aby móc korzystać z udostępnionego socketa to trzeba zmienić uprawnienia, żeby użytkownik root mógł korzystać. W tym celu uruchamiamy polecenie

xhost +SI:localuser:root

Powyższe ma skutek tylko w danej sesji, więc po ponownym uruchomieniu komputera należy wykonać polecenie ponownie (albo poszukać jak dodać te uprawnienia na stałe).

Uruchomimy nasz kontener tym poleceniem

docker run \
    -e DISPLAY=unix$DISPLAY \
    -v $HOME/Code:/home/dev/workdir \
    -v /tmp/.X11-unix:/tmp/.X11-unix \
    --net=host \
    manio143/fscodeenv

Gdzie --net-host oznacza uruchomienie konteneru w tej samej sieci co host, bez izolacji w podsieci; zmienna DISPLAY oznacza gdzie jest uruchomiony X11; wolumen /tmp/.X11-unix to plik naszego udostępnianego socketu, a drugi wolumen to nasz folder z kodem.

I tak oto uruchamiamy VS Code z wewnątrz kontenera na naszym komputerze mając izolowane środowisko programistyczne z odpowiednimi narzędziami. W dodatku jest ono przenośne, idąc na inny komputer wystarczy, że będzie miał zainstalowany Docker, a my jednym poleceniem pobieramy niezbędne narzędzia.

Kompletny Dockerfile znajdziesz tutaj, a mój gotowy obraz na Docker Hubie.