docker컨테이너에서 debug with webstorm IDE

도커는 사랑이며 희망이며 모든 변화에 시작이다.
그만큼 도커의 개념을 좋아한다.

도커의 장점은 따로 도카에 대해서 포스팅하겠지만 내가 원하는 상태를 이미지로 만들어두고 필요할때고는 언제든지 불러와서 재현할 수 있다는 것이다.

dockerfile을 통해서 내가 원하는 구성과 계정, 프로그램, workdirectory, 네트워크 등의 세밀한 부분을 구성이 가능하다. 심지어 이러한 이미지들의 상호작용하는 구성을 한번에 연동시켜두어 docker compose로 바로 재현이 가능하다는 것이다. 그리고 쿠버네티스 수준의 디테일함은 부족하지만 그래도 충분히 좋은 오케스트레이션으로 Swarm이 존재한다.

그리고 개인적으로 좋아하는 부분은 호스트pc가 지저분해지지 않는다는 것이다. 개발에 필요한 다양한 라이브러리를 하나의 호스트에 설치하고 구성하다가 다르 호스트에서 실행하면 컴파일에러가 발생하는 문제가 있다.

일단 지저분 해지는 문제만 해결하는 것으로도 충분히 좋은 용도이다. 물론 기존에도 상영화된 가상화 프로그램들이 존재하지만 도커는 가벼워도 너무나도 가볍다.

이러한 상황에서 하나의 특정 환경을 구성하고 해당 이미지를 통해서 개발을 하는데 디버깅이 쉽지 않은 문제가 발생한다. IDE는 호스트 파일만 접근이 가능한데 다버깅이 도커 컨테이너 내에서 실행되는것이 아니라 호스트에서 실행된다는 것이다. (모든 디버깅이 그런건 아니지만.. )

그래서 처음에는 컨테이너에 폴더를 마운트시켜서 기능개발 코드만 편집 추가하고 실제 작동은 컨테이너 내로 접근해서 CLI를 통해서 수동으로 테스트하는 방법을 썻다. 이 방법은 물론 불편하고 시간도 많이 필요하게 된다.

내가 사용하는 IDE는 jetbrains에 Webstorm을 사용하는데 이녀석 역시 다른 IDE들 처럼 도커를 지원한다. 그중에서 remote 디버깅이 가능하도록 지원하는데 이때 도커 컨테이너 내에 접근이 가능하도록 해준다. 이 말인 즉슨, 호스트에서 컴파일과 같은 작업을 하고 디버깅을 실행했을때 컨테이너 내 환경에서 작동이 되며 호스트 환경과는 별개로 작동하는 것이다.

(임베디드 개발할때 보게되는 크로스 컴파일과 같은.. 정확히 같지는 않지만 호스트에서 돌아가는게 아닌 다른 타겟 장치에서 작동이나 실행되는것을 호스트에서 디버깅하는 그런.. 원격 디버깅의 모습을 하고 있다)

구조를 풀이하면,
호스트에 디렉터리가 있다. 여기에는 내가 개발중인 파일들이 하나의 프로젝트 단위로 들어가있게 된다. 평소 그냥 프로젝트 하나만들면 생기는 그 폴더다. 이 디렉토리는 호스트 환경에서 실행이 가능한것이 누가 묻지않아도 당연한 것이다. 그런데 이 디렉토리를 도커 컨테이너를 생성할때 마운트 시켜서 컨테이너 내 하나의 폴더로 인식하게 만든다. 이제 IDE는 호스트에 있는 node를 실행하지 않고 컨테어너 내에 존재하는 node를 실행하여 디버깅을 시작하는 것이다.

구조를 간단히 보면,
도커 컨테이너가 호스트 디렉토리를 마운트하고
도커 컨테이너 내에서 해당 프로그램을 실행 및 디버깅.

ide는 매 디버깅시마다 컨테이너를 삭제하고 다시 만들어낸다. 그래서 별도의 컨테이너 이름을 설정할 수 없게 해두었다. 랜덤으로 만들어지는 이름이라 신경안써도 되지만 다수의 컨테이너를 실행 할때는 이게 여간 햇갈리는게 아니다. alt+8로 service 로 도커 컨테이너를 볼수있지만 그거또한 비교해가면서 확인이 필요하다.

원하는 이미지를 바탕으로 계속해서 컨테이너 생성 삭제를 반복하는데 이때 ide가 자체적으로 이미지를 또 만들어서 그 이미지를 통해서 최종적인 컨테이너를 생성한다. 그러다보니 이미지를 빌드하는 시간이 매번필요하고 이미지가 크다면 그 시간또한 길어지는 문제가 발생한다.

구글링을통해서 찾다보면 도커가 좋은데 디버깅에는 아직 다들 지원해주는게 부족해서 시급하게 다양한 라이브러리나 미들웨어들이 지원해주기를 바라고 있다. 그러다보니 꼭 컨테이너 내에서 디버깅을 해야하는게 아니라면 그냥 포기하고 호스트에서 한다는 댓글도 보이고는 한다. 아직 명확한 가이드라인이 존재하지는 않앗서 혼란스럽기는 하지만 또 한편으로 찾다보면 모든 빌드를 이미지 단위로 한다는 댓글도 많다.

이처럼 조금은 덜 준비된 모습을 보이기는 하지만 쿠버네티스를 생각하면 CRI(쿠버네티스 런타임 인터페이스) 규격에 맞는 도커나 podman의 이미지는 필요한 기술이고 유용한 기술임이 틀림이 없다. 서비스는 더욱 다양해지고 그 규모를 가늠할 수 없는 환경에서 사용자 대응은 빨라지고 서비스는 연속적이며 새로운 기능은 수시로 생겨나는 환경 그리고 모든 개발 테스트 빌드 배포가 연계되어 진행되는 이러한 전반적인 대응에 아주 적합한 기술이다.

불편하고 고민이 늘어나는 도커이지만 결국 그것들을 하나씩 이겨내면서 횐경을 만들어가야 할 것이다.

끝.