웹사이트 검색

나는 그냥 할 수 있기 때문에 Docker에서 완전한 Linux 데스크톱을 실행한다

나처럼, 당신도 아마 Docker의 비공식 규칙을 들어봤을 것입니다: Docker는 그래픽 인터페이스가 아닌 가볍고 헤드리스 서버와 명령어 기반 애플리케이션을 위한 것입니다. 대부분의 사람들은 정당한 이유로 이 규칙을 따릅니다—CLI가 Docker가 만들어진 목적이기 때문입니다. 하지만 규칙을 깨면 무슨 일이 일어날까요?

나는 평소와 다른 무언가를 하기로 결심했다. 내 목표는 컨테이너 안에서 완전한 리눅스 데스크탑을 실행하는 것이었다. 나는 단순한 셸만 원하지 않았다; 나는 있어서는 안 되는 곳에 존재하는 완전한 기능의 GUI를 원했다. 내가 시도했을 때 일어난 일은 이랬다.

어쨌든 내가 왜 이걸 하고 있는 거지?

그냥 조금 미친 것 같아요

그렇다면 왜 누군가가 이렇게 수고를 들여서 리눅스를 사용하려고 할까요? 결국 우리는 단순히 VirtualBox를 사용하거나 심지어 윈도우와 함께 리눅스를 듀얼 부팅할 수도 있습니다. 제 대답은 간단합니다: 호기심과 도전 욕구 때문입니다.

나는 한동안 Docker에 관심이 있었고, 풀스택 웹 개발 경험은 있었지만 Docker와 컨테이너화 분야에서는 별로 경험이 없었다. 나는 직접 실험하고 경험을 통해 배우고 싶었기 때문에 이 프로젝트가 답이 되었다.

처음부터 나는 이것이 쉽지 않을 것이라는 것을 알고 있었습니다. 나는 그래픽 Linux 시스템을 설치하고 실행하는 데 하루, 많아야 이틀이면 충분할 것이라고 예상했습니다. 하지만 도전의 현실은 전혀 반대였습니다. 다음 사흘 동안 내가 직면한 장애물은 전혀 예상치 못한 것이었고, 내가 상상했던 것보다 훨씬 더 복잡하여 내 인내심을 준비했던 것 이상으로 시험에 들게 했습니다.

기술적인 세부 사항에 들어가기 전에, 여기에 약간의 배경을 제공합니다.

이 전체 실험은 Windows 10 PC에서 이루어졌으며, 특정 질문에 의해 진행되었습니다: 만약 두 세계의 장점을 모두 가질 수 있다면 어떨까? Docker 컨테이너 안에서 전체 Linux 환경이 실행되면서, 동시에 내 일반 Windows 애플리케이션과 나란히 사용할 수 있다는 생각은 너무 매력적이어서 지나칠 수 없었습니다. 재부팅도 없고, 별도의 파티션도 필요 없이, 단지 원활하게 컨테이너화된 Linux 데스크톱이었습니다.

그래서 먼저 내 실험실을 준비해야 했습니다. 이는 Docker를 설치하고 WSL을 설정하는 것을 의미했습니다. 기초 작업이 끝나자, 나는 Docker 기본 지식을 새로 고치고 문서를 읽었습니다. 이를 통해 초기 준비가 완료되었고, 이제 이론을 실제로 적용할 시간입니다.

내 Docker 컨테이너 실행하기

나는 이것을 힘든 방법으로 해보려고 했다

Docker에서 Linux 데스크톱을 실행하려는 나의 첫 번째 시도는, 되돌아보면, 과도한 자신감에서 나온 초보자의 실수였다. 나는 처음부터 맞춤 이미지를 만들기로 결정했다. Docker를 처음 접하는 사람이라면, 이미지란 애플리케이션이 실행되는 데 필요한 모든 것을 포함하는 독립적인 패키지이다. 따라서 이미지를 만들면 하드웨어나 운영 체제에 관계없이 어디서나 동일하게 실행될 것이다.

나는 처음부터 또 다른 실수를 저질렀다: 나만의 이미지를 위한 코드를 생성하는 데 AI 도구에 지나치게 의존했다.

얻은 값진 교훈은 다음과 같습니다: 기술을 이해하지 못한다면, 저처럼 코드를 그냥 복사해서 붙이지 마세요. 저는 아무런 명확한 해결책도 없이 오류를 디버깅하느라 몇 시간을 허비했고, 이해하지 못하는 코드 더미 속을 막무가내로 헤쳐 나가야 했습니다.

이 비생산적인 길에서 하루 종일 시간을 낭비한 후, 나는 결국 포기하고 전략을 바꾸었다. 나의 새로운 접근법은 단순했다: Docker Hub에서 미리 만들어진 이미지를 사용하는 것이었다. Docker Hub는 다른 개발자들이 만든 솔루션으로 가득 찬 컨테이너 이미지의 '앱 스토어'라고 생각하면 된다. 이는 매우 필요한 조정이었고, 마침내 실제 작업이 시작될 수 있게 해주었다.

첫 번째 빛줄기: 좋은 것들과 나쁜 것들

내 커스텀 이미지 시도가 실패한 후, 나는 Docker Hub에서 유망한 XFCE 기반 Debian 이미지를 발견했다. 나는 몇 분 만에 그것을 다운로드했고, 몇 가지 명령어만으로 실행시켰다. URL을 열었을 때, 나는 브라우저 안에서 바로 실행되는 완전히 기능하는 Linux 데스크탑을 맞이했다. Docker 컨테이너 안에서 완전한 OS가 제공되는 것을 보는 순수한 기계적 즐거움은 잊을 수 없는 경험이었다. 작동했다!

사용성은 놀랍도록 괜찮았습니다. LibreOffice와 GIMP는 잘 작동했지만 약간의 지연이 있었습니다. 네이티브 성능의 약 70% 정도라고 추정할 수 있지만, 여전히 사용할 만했습니다. Firefox도 실행되었고, 심지어 YouTube도 시도해 보았습니다. 그때 첫 번째 큰 장애물에 부딪혔습니다: 색상이 흐리고 바래 보였던 것입니다. 빠른 확인 결과 제 의심이 맞았습니다: 브라우저가 소프트웨어 렌더링을 사용하고 있었습니다. 제 GPU는 유휴 상태였습니다.

내가 발견한 또 다른 문제는 Flatpak이 작동하지 않았다는 것입니다. Flatpak에서 앱을 설치하려는 모든 시도는 오류로 실패했기 때문에, 나는 Debian 패키지에 의존할 수밖에 없었습니다. 이러한 제한에도 불구하고, Docker에서 직접 제공되는 브라우저에서 완전한 Linux 데스크톱을 보는 것은 엄청난 성과였습니다.

조정하고 배우기

참을 수 없었어

몇 분간 XFCE를 사용한 후, 나는 변화를 주고 GNOME을 내 데스크톱 환경으로 시도해보기로 결정했다. 큰 실수였다! 실행되기까지 몇 시간 동안 문제를 해결하고 오류를 고쳐야 했고, 마침내 실행되었을 때는 느리고 자원을 많이 소모했다. 결국 나는 자존심을 굽히고 XFCE로 되돌아갔으며, XFCE는 화려하지는 않지만 훨씬 반응이 빠르다고 스스로에게 말했다. 그러니 실용성에 더 무게를 두자.

성능에 집중하기 위해, 나는 처음 시도했던 작업을 다시 시도하기로 결정했다: 처음부터 커스텀 이미지를 만드는 것이다. 이번에는 이전에 사용했던 사전 구축 이미지의 Dockerfile을 공부했다. 내부에서 정확히 무엇이 일어나고 있는지를 이해하고 싶었고, 내가 직접 성능을 개선할 수 있는지도 보고 싶었다. 몇 가지 새로운 구성을 실험했는데, 특히 다른 프로토콜이 더 부드러운 경험을 제공할 수 있는지 보기 위해 noVNC 전달 방식 대신 xrdp를 사용하려 했다. 하지만 xrdp에서는 아무런 차이를 느낄 수 없었다.

복제하려면 'dockerfile'이라는 이름의 파일을 만들고, 코드를 붙여넣고, 실행하세요.

FROM ubuntu:jammy-20230425


RUN apt update && \
    DEBIAN_FRONTEND=noninteractive apt install -y \
        cinnamon locales sudo \
        tigervnc-standalone-server tigervnc-common \
        virtualgl mesa-utils mesa-vulkan-drivers \
        dbus-x11 xterm wget && \
    locale-gen en_US.UTF-8 && \
    update-locale LANG=en_US.UTF-8

# Create user
# Enter the below username and passoword in xrdp login screen
ARG USER=user
ARG PASS=1234
RUN useradd -m $USER -p $(openssl passwd $PASS) && \
    usermod -aG sudo $USER && \
    chsh -s /bin/bash $USER

# Environment for Cinnamon
RUN echo "#!/bin/sh\n\
export XDG_SESSION_DESKTOP=cinnamon\n\
export XDG_SESSION_TYPE=x11\n\
export XDG_CURRENT_DESKTOP=X-Cinnamon\n\
export LIBGL_ALWAYS_INDIRECT=0\n\
exec cinnamon-session" > /home/$USER/.xinitrc && \
    chown $USER:$USER /home/$USER/.xinitrc && chmod +x /home/$USER/.xinitrc

# Setup VNC password
RUN mkdir -p /home/$USER/.vnc && \
    echo $PASS | vncpasswd -f > /home/$USER/.vnc/passwd && \
    chmod 0600 /home/$USER/.vnc/passwd && \
    chown -R $USER:$USER /home/$USER/.vnc

# Start script
RUN echo "#!/bin/bash\n\
export DISPLAY=:1\n\
Xvnc :1 -geometry 1920x1080 -depth 24 -SecurityTypes VncAuth -rfbport 5901 -localhost no &\n\
sleep 2\n\
sudo -u $USER startx &\n\
tail -f /dev/null" > /start && chmod +x /start

EXPOSE 5901

CMD ["/start"]

도커 허브 탐색하기

이렇게 처음부터 했어야 했는데

이 모든 것이 너무 많은 작업처럼 들린다면, 좋은 소식이 있습니다. 시작하기 위해 직접 이미지를 만들거나 오류를 처리할 필요가 없습니다. 제 연구를 통해 훨씬 더 간소화된 경험을 제공하는 두 가지 환상적인, 바로 사용할 수 있는 솔루션을 찾았습니다.

  • LinuxServer.io의 Webtop: 이것은 다양한 Linux 데스크탑 버전을 Docker 이미지로 미리 패키지하여 제공하는 훌륭한 오픈 소스 옵션입니다. noVNC를 사용하여 데스크탑을 바로 브라우저로 전달하며, 설치 과정이 간단합니다.
  • Kasm 작업 공간: 이것은 개인 사용을 위한 또 다른 오픈 소스 옵션입니다.

이 이미지들의 좋은 점은 모든 것이 미리 구성되어 있다는 것이며, 특히 Webtop이 그렇습니다. Docker 이미지를 가져와서 실행하기만 하면 됩니다. 컨테이너가 실행되면 URL을 입력하여 Linux에 접근할 수 있습니다. 이전에 시도해본 것보다 성능이 훨씬 좋았고, 중요한 점으로 Kasm 이미지에서는 찾지 못했던 오디오 패스스루가 있었습니다.

Webtop을 실행하려면 Windows CMD를 열고 이 코드를 붙여넣으세요

docker run -d ^
--name webtop-xfce ^
-e PUID=1000 ^
-e PGID=1000 ^
-e TZ=Etc/UTC ^
-p 3000:3000 ^
--shm-size=1gb ^
lscr.io/linuxserver/webtop:latest

나는 몇 가지 예상치 못한 장점을 발견했다

이 어리석은 설정에는 몇 가지 장점이 있습니다

Docker를 배우고 리눅스 컨테이너를 실험해보기 위한 재미있는 프로젝트로 시작한 것이 진행 과정에서 놀라울 정도로 유용한 기능들을 발견하게 되었습니다. 가장 큰 발견이자 개인적인 '아하!' 순간은 원격 데스크톱 접근의 힘을 깨달은 것이었습니다.

내가 브라우저에서 완전한 리눅스 데스크탑을 보는 순간, 나는 기발한 생각이 떠올랐다: 만약 덜 강력한 기기에서 접속한다면 어떨까? 나는 내 크롬북을 집어 들었다—인텔 셀러론 프로세서를 가진 소박한 기기—URL을 열었고, 거기에 있었다: 내 메인 PC의 모든 성능이 크롬북에서 스트리밍되고 있었다. 갑자기 나는 책상에 묶여 있지 않았다. 소파나 집 안 어디에서든 계속 일할 수 있었다. 성능이 낮은 내 크롬북은 컨테이너 덕분에 데스크탑을 들여다보는 고성능 창이 되었다.

최상의 경험을 위해 유선 이더넷 연결 또는 빠른 5GHz Wi-Fi 네트워크를 사용하세요.

이것 외에도, 나는 몇 가지 다른 이점들을 볼 수 있었다:

  • 일회용 샌드박스: 메인 OS를 망칠 걱정 없이 리눅스 환경에서 테스트하고 망가뜨릴 수 있었습니다. 위험한 실험을 위한 완벽한 놀이터였습니다.
  • 개인 브라우징: 나는 새로운 컨테이너를 실행하고, 웹 브라우저를 사용한 다음, 단 한 번의 클릭으로 전체 환경을 삭제하여 흔적을 남기지 않을 수 있습니다.
  • 전용 작업 공간: 특정 작업에 맞춘 맞춤형 Linux 이미지를 만들 수 있습니다—방해받지 않는 글쓰기 환경, 모든 개발 도구가 미리 설치된 코딩 환경 등.

이 유연성 덕분에 프로젝트를 시작할 때조차 생각조차 못했던 가능성이 열렸습니다.

다음은 뭐야?

내 미완성 실험들

내가 직접 Docker에서 Linux 데스크톱을 실행하는 것이 가능하다는 것을 확인했지만, 나의 여정은 끝나지 않았다. 내가 하고 싶었지만 시간이 없었던 몇 가지 실험이 있었다:

  • Flatpak 및 Snap Store: 컨테이너 안에서 이 앱 스토어들을 작동시키는 방법을 알아내어 소프트웨어 라이브러리를 확장하고 싶습니다.
  • 게임: GPU 패스스루가 없었다면 이건 불가능했겠지만, 저는 이에 대한 해결책을 찾아보고 싶습니다.
  • 추가 최적화: 더 나은 성능을 얻고 입력 지연을 줄일 수 있는지 확인하기 위해 설정을 계속 조정하고 싶습니다.

왜 Docker에서 Linux를 실행하는 것이 어려운가요?

도전 과제

자, 이제 컨테이너 안에서 전체 데스크탑 환경을 실행하고 그것이 Windows에서 일반 데스크탑처럼 동작하기를 기대하는 것이 가능하지만 고통스럽고, 취약하며, VM을 실행하는 것보다 훨씬 더 번거롭다는 것을 이해했으므로, 그 주요 이유는 다음과 같습니다:

  • 컨테이너는 격리된 운영 체제가 아닙니다: Docker 컨테이너는 호스트 커널을 공유합니다. 이것이 컨테이너가 경량이고 단일 서비스에 적합한 이유입니다. 반면 데스크톱 환경은 systemd, logind, udev, DBus와 같은 시스템 서비스와 장치 접근이 사용 가능하기를 기대합니다. 컨테이너는 기본적으로 이를 제공하지 않습니다.
  • 내장 디스플레이 서버 없음: Linux GUI는 컴포지터/디스플레이 서버(X11 또는 Wayland)가 필요합니다. 컨테이너는 이를 제공하지 않으므로 우리가 직접 해야 합니다.
  • GPU 접근: 컨테이너는 기본적으로 GPU를 가상화하지 않으므로 장치 노드를 컨테이너에 전달해야 합니다. 그리고 Windows에서는 넘어야 할 추가 WSL 계층이 있습니다.

수고할 만한 가치가 있었나요?

절대적으로 그렇습니다. 이번 프로젝트는 즐겁고 매우 보람 있었습니다. Docker와 Linux의 내부 작동 방식에 대해 많은 것을 배웠고, 몇 시간 동안 문제를 해결한 끝에 마침내 자신의 작업이 결실을 보는 특별한 만족감을 느꼈습니다.

그렇다면, 제가 추천할까요? 네, 특히 호기심이 있고 기발한 주말 프로젝트를 찾고 있다면요. 하지만 그렇지 않더라도, 제가 발견한 실용적인 이점들—원격 데스크톱 접근, 일회용 샌드박스, 전용 작업 공간 등—은 이것을 단순한 실험 이상으로 만듭니다. 저는 여기에서 실용적인 사용 사례를 볼 수 있습니다.

Docker의 비공식 규칙에는 이유가 있지만, 때때로 가장 귀중한 교훈은 규칙을 깨면서 발견되기도 합니다. 그러니 터미널을 실행하고, 미리 만들어진 이미지를 가져오거나(또는 용감하게 직접 만들어 보세요!), 직접 마법을 경험해 보세요. 그 과정에서 몇 가지 예상치 못한 장점도 발견할 수 있을 것입니다.

관련기사