개발자를 위한 쉬운 도커, 독서록
황현우라는 개발자가 쓴 책이다. 부제는 '컨테이너 기초부터 개발자에게 필요한 네트워크, 볼륨 개념과 다양한 실무 사례까지'.
https://product.kyobobook.co.kr/detail/S000216089379
도커는 이름만 많이 들어봤지 실제로 사용해 본 적은 없어서 뜬구름 잡듯 머리에 저장돼 있던 기술이었는데 어느 날 서점에서 문득 이 책이 눈에 띄어 구매했다. 현실의 압박에 문학이나 인문계 서적에서 잠시 마음이 뜬 상태였는데 그렇다고 진짜 업무와 관련된 책을 읽자니 주말에 일하는 기분이 들 것 같아서 애매한 포지션에 있는 책에 눈이 갔던 것 같다. 지금 생각해 보면 바람직하지 않은 도피성 독서였다고 생각하는데, 그와는 별개로 도커의 개념을 이해하고 간단한 실습까지 해보고 싶은 사람이라면 이 책을 추천한다. 책 자체는 좋았다.
가상화, 하이퍼바이저, 컨테이너, 도커, 클라우드, 마이크로서비스 아키텍처, 스테이트리스 등
책에서 배운 개념들을 적당히 책에 나오는 순서대로 기록해 놓는다. 요즘에는 이렇게 정리해 기록으로 남겨도 머리에서 금방 지워져 버리는 것 같다. 세월이 야속할 뿐.
도커는 컨테이너를 관리하는 소프트웨어이고, 컨테이너는 서버를 효율적으로 사용하기 위한 가상화 기술이며, 가상화 기술은 하나의 물리적인 컴퓨터 환경에서 여러 개의 논리적인 컴퓨팅 환경을 만들 수 있는 기술이다.
가상화 기술을 사용하는 이유는 한 프로그램에서 발생한 오류 혹은 자원 사용량 급증이 다른 프로그램에 영향을 주지 않도록 만들기 위함이다. 여러 대의 하드웨어를 구입하는 대신 가상화 기술을 사용하는 이유는 낮은 사양의 컴퓨터를 여러 대 사용하는 것보다 높은 사양의 컴퓨터 한 대를 사용하는 편이 전력, 관리 인력, 설치 공간 등 여러 측면에서 더 저렴하고, 일반적으로 하나의 소프트웨어가 요구하는 사양은 하드웨어 한 대의 성능보다 훨씬 낮기 때문이다.
책은 도커와 컨테이너라는 용어에 익숙지 않은 독자들을 위해 서버가 무엇인지 기본 개념을 짚어본 뒤 가상화 기술의 일종인 하이퍼바이저와 컨테이너를 서로 비교하며 살펴보는 것으로 시작한다. 이를 통해 어디에 사용하는 기술인지, 왜 이 기술이 널리 사용되고 있는지 개념을 제대로 정립하고 실습에 들어설 수 있다.
하이퍼바이저와 컨테이너의 차이는 격리된 공간을 만들기 위한 기능을 직접 모두 개발했느냐 아니면 호스트 OS의 커널에서 제공하는 기능을 이용했느냐이다. 하이퍼바이저는 직접 모두 개발했고, 컨테이너는 호스트 OS의 커널 기능을 이용했다. 즉, 하이퍼바이저 방식에서 각 게스트 OS는 각자의 커널을 갖고 있고, 컨테이너 방식에서 각 컨테이너는 호스트 OS의 커널을 공유한다.
하이퍼바이저 방식은 부팅할 때 각 커널을 실행해야 하기 때문에 부팅 시간이 길고 각 시스템 콜이 하이퍼바이저를 통해 커널 간 통신으로 진행되기 때문에 느리다. 대신 각각의 커널이 독립적이기 때문에 보안 측면에서 유리하고 호스트 OS와 상관없이 원하는 OS를 사용할 수 있다.
반면 호스트 OS의 커널을 공유하는 컨테이너 방식은 부팅 시간과 시스템 콜 요청 시간 모두 하이퍼바이저 방식보다 빠르다. 책에 따르면 바로 이 장점이 요즘 애플리케이션들이 바라는 사항이며, 그래서 컨테이너 기술이 더 널리 사용되고 있다고 한다.
여기서 한 가지 의문이 들 수 있다. ‘잠깐, 나는 지금 MacBook에서 실습할 예정인데 그럼 macOS에서는 어떤 구조로 실행되는 것이지?’ 아쉽게도 책에는 이에 대한 설명이 없고, 아래는 검색으로 찾아낸 답변이다.
실제로 도커는 리눅스의 커널의 기술을 활용하기 때문에, Windows와 macOS는 기본적으로 지원하지 않습니다. 그래서 도커 데스크톱(Docker Desktop)은 Windows나 macOS의 하이퍼바이저 가상화 기술을 사용하고 있는데요. Windows/macOS에서 리눅스 가상머신을 실행한 다음에, 그 리눅스의 커널을 사용해서 컨테이너 환경을 구성하는 것입니다. 컨테이너 가상화 기술을 사용하기 위해 하이퍼바이저 가상화 기술을 활용하는 것이죠.
친절히 답변을 남겨 놓은 사람의 이름이 익숙해서 보니 이 책의 저자였다. 다음에는 이 내용을 책에 넣어주면 어떨까 싶다.
여기까지의 결론은, 도커는 Linux에서 제공하는 가상화 기술을 ‘일반 사용자’가 쉽게 다룰 수 있도록 포장한 기술이고, 이 책은 도커 개발자 기준에서는 ‘일반 사용자’에도 속하지 못하는 나 같은 ‘더 일반 사용자’들을 위해 탄생한 책이라는 것이다.
여기서 짚고 넘어가야 할 도커의 진정한 장점이 또 하나 있다. 아래는 도커 홈페이지에서 가져온 것이다.
Docker란 무엇인가요?
애플리케이션 구축, 공유 및 실행 속도를 가속화하세요.
Docker는 개발자가 번거로운 환경 설정이나 관리 없이 어디서나 애플리케이션을 구축, 공유, 실행 및 검증할 수 있도록 지원합니다.
앞서 살펴본 것과 같이 도커를 이용하면 가상화를 통해 외부와 격리된 환경, 즉 컨테이너를 만들 수 있다. 이 컨테이너를 실행하기 위해서 ‘이미지’라는 것이 필요한데 도커 영역에서 이미지란 ‘컨테이너에서 프로그램을 실행하는 데 필요한 모든 것이 포함된 압축 파일’로 정의된다. 여기서 ‘모든 것’에는 실행하려는 프로그램과 그 프로그램을 실행하기 위해 필요한 모든 것(패키지, 라이브러리, 런타임 언어 등)에 OS까지 포함된다. 말 그대로 모든 것이 포함되는 것이다.
즉, 프로그램과 실행 환경을 함께 압축한 파일인 이미지로 컨테이너를 실행하면 격리된 환경이 생성되면서 그 안에서 이미지 속 프로그램이 이미지 속 실행 환경에서 실행된다. 이런 방식으로 작동하기 때문에 같은 이미지로 실행한 컨테이너는 어디에서든(내 컴퓨터에서든 동료의 컴퓨터에서든 고객의 컴퓨터에서든) 완전히 동일한 모습과 기능으로 실행된다. 해당 컴퓨터에 설치된 OS가 무엇이든, 프로그램 실행에 필요한 패키지나 라이브러리가 있든 없든, 있으면 버전이 몇이든 상관없이 격리된 환경 속에서 이미 설정된 환경 하에 동일한 기능이 동일하게 작동한다는 것이다. 이 기술을 적용하지 않고 여러 사람 혹은 여러 팀으로 나뉘어 하나의 시스템을 개발해 본 사람이라면 이 특성이 얼마나 큰 장점인지 알 것이다. ‘제 컴퓨터에서는 되는데요?’ 혹은 ‘내 컴퓨터에서는 왜 안 되지?’를 원천 차단할 수 있는 훌륭한 기술이다.
도커를 공부할 때 또 하나 살펴봐야 할 개념이 ‘클라우드’다. 클라우드 서비스는 파일을 저장하거나 프로그램을 실행하는 것을 내 컴퓨터가 아니라 네트워크를 통해 서비스 제공자의 장치에 저장하거나 실행하면서 저장량 혹은 사용량에 따라 비용을 내는 서비스다. 클라우드 서비스는 인터넷에 연결할 수만 있다면 내 장비가 없어도 어디서나 접근할 수 있으며 초기 비용이 저렴하고 필요에 따라 간단하게 저장 용량이나 사용량을 늘리거나 줄일 수 있다는 장점이 있다. 물론 내 데이터나 프로그램 직접 제어할 수 있는 영역이 줄어든다는 단점도 있기는 하다.
클라우드가 제공하는 장점이 워낙 막강했기 때문에 클라우드를 최대한 잘 이용할 수 있도록 애플리케이션을 설계/개발/운영하고자 하는 움직임이 생겼으며, 이와 같이 클라우드 환경에 최적화해 설계/개발/운영하는 방식을 ‘클라우드 네이티브’라고 부르며, 클라우드 네이티브 방식의 특징 중 하나가 ‘마이크로서비스 아키텍처(microservice architecture)’다.
마이크로서비스 아키텍처는 애플리케이션을 기능별 혹은 서비스별 등으로 잘게 나눠 각각을 모듈화해 서로 독립적으로 작동하며 통신하는 구조로 설계하는 아키텍처를 말한다. 이렇게 설계하면 특정 기능이나 서비스의 트래픽이 갑자기 급증할 때 해당 모듈만 스케일 아웃해 대처하는 게 가능해지고, 특정 모듈에서 발생한 문제가 끼치는 영향의 범위를 줄일 수 있다는 장점이 있다. 다만 시스템이 복잡해지면서 개발/테스트/디버깅 난이도가 올라가고, 운영 및 배포 비용이 늘어나며, 모듈 간 통신이 네트워크를 거치게 되면서 지연 시간 증가 및 에러 발생 가능성이 올라간다는 단점도 존재한다. 참고로 애플리케이션의 모든 기능을 하나로 묶어 설계하는 기존의 방식은 모놀리식이라고 부른다.
짧게 살펴본 것만으로도 마이크로서비스 아키텍처는 컨테이너를 활용하기에 딱 좋은 아키텍처라는 것을 알 수 있다. 따라서 클라우드 환경에서 서비스를 제공하고 싶을 때에는 컨테이너를 활용하는 것이 좋다.
컨테이너 기반으로 애플리케이션을 개발하고자 할 때 고려해야 할 컨테이너의 중요한 특징 중 하나는 컨테이너는 스테이트리스(stateless)하다는 것이다. 스테이트리스하면 불변성, 격리성, 이식성, 확장성, 복원력 같은 장점을 얻을 수 있다. 다만 로그인도 없는 아주 단순한 애플리케이션을 만들 게 아니라면 이런 장점을 유지하기 위해 손이 좀 가야한다. 예를 들어 데이터를 영구 저장하려면 컨테이너가 아닌 외부 저장소를 사용해야 한다. 세션과 캐시 정보도 외부에서 관리해야 하며, 설정 정보 역시 환경 변수로 외부에서 주입해야 한다.
이를 위해 도커에서는 볼륨이라는 이름으로 외부 저장소와 마운트하는 기능도 제공하고 있고 설정 정보를 환경 변수로 주입할 수 있는 기능도 제공하고 있다. 관련 기능들을 제공하고 있다.
스테이트풀과 스테이트리스에 대한 자세한 설명은 아래 RedHat의 설명을 참고하길 바란다. 자사 상품 광고로 끝나는 글인데 자사 상품을 많이 팔기 위해 설명을 아주 잘해놓았다.
https://www.redhat.com/ko/topics/cloud-native-apps/stateful-vs-stateless
실습 중 발생한 에러들
책은 도커의 개념과 구조만 간략히 살펴본 뒤 바로 실습에 들어간다. 기능 하나를 알려준 뒤 바로 해당 기능을 사용하는 실습을 해보는 식이다.
실습에서는 각 명령어를 실행해야 하는 폴더로 이동하는 명령어까지 모두 제공하므로 제대로만 따라한다면 대부분의 경우 별 어려움 없이 도커의 기능을 하나씩 차근차근 사용해 볼 수 있다. 다만 안타깝게도 몇몇 소수의 실습의 경우 오타가 있거나 책 출간 후 업데이트된 사항이 있어 책에 나온 그대로 명령어를 실행하면 에러가 발생했다.
다음은 실습하면서 에러가 발생해 수정했던 내용들이다. 예전 같았으면 구글링해서 찾은 어떤 블로그나 스택오버플로에서 답을 찾았겠지만 이제 그들은 로저나 흰수염 같은 존재가 되었다. 다음 해적왕은 AI 집단에서 배출되겠지. 이번에는 그중에서 패권에 가장 가까운 것으로 보이는 ChatGPT가 답을 구해줬다.
1. 다음 명령어 실행 시 에러 발생
$ docker commit -m “edited index.html by devwiki” -c “CMD [‘nginx’, ‘-g’, ‘daemon off;’]” officialNginx (레지스트리계정명)/commitnginx
ChatGPT에게 문의한 결과 “CMD [‘nginx’, ‘-g’, ‘daemon off;’]”에서 큰 따옴표는 작은따옴표로, 작은따옴표는 큰 따옴표로 수정해야 한다고 해 수정하니 잘 실행됐다.
‘CMD [“nginx”, “-g”, “daemon off;”]’
2. LegacyKeyValueFormat
아래는 권고하는 대로 수정하면 경고를 없앨 수 있다.
3. Bitnami 유료화 이슈
2025년 하반기부터 Bitnami가 유료화됐다고 한다. 난 ChatGPT의 첫 번째 권고를 따랐다.
4. EOL 버전 Node.js 사용 이슈
실습에서 Node.js 14 버전을 사용하는데 이 버전은 2023년 4월 30일부로 공식 지원이 종료된 버전이라고 한다. 이 책이 나온 게 2025년 3월 25일이니 이미 책이 나오기 전에 EOL된 것인데 그대로 출판된 것을 보면 EOL된 후에도 한동안은 사용할 수 있었던 것 같기도 하다.
아무튼 이제는 사용할 수 없어서 에러가 발생하며, ChatGPT가 권고하는 대로 22 버전으로 업데이트하면 이후 실습은 문제없이 진행할 수 있다.
