2025. 3. 30. 02:53ㆍTrouble Shootings/Infrastructure
1. 문제의 상황
PWA(Progressive Web App)를 Tizen OS와 Android OS 환경에서도 사용할 수 있게 패키징을 하던 중이었습니다. 그래서 AWS EC2에 관련 Studio CLI들을 설치했는데, 제가 Express.js를 도커 컨테이너로 CI/CD 해놨다는 사실을 까맣게 잊고 있었습니다...
도커 컨테이너는 그 자체로 완전히 논리적으로 독립된 공간이기 때문에, EC2에 있는 Tizen Studio CLI와 Android Studio CLI와 1)통신을 하거나, 2)디렉토리 마운트를 해서 접근할 수 있게 해야 합니다.
하지만 Tizen CLI와 Android CLI는 도커 컨테이너가 아니기에 통신하는 방법은 사용할 수 없었고, 그러면 접근 가능한 게 디렉토리 마운트 밖에 없었습니다. (방법이 있을 수도 있지만, 제 지식에서는 여기까지가 한계였습니다.)
그러나 디렉토리 마운트 방법도 한계가 있었습니다. Express.js에서 Tizen CLI와 Android CLI에게 접근해야 할 새로운 패키지가 늘어날수록 추가적으로 마운트를 해줘야 했는데, 번거로운 일이 아닐 수가 없었습니다.
Q. 그러면 셋 다 모두 담은 도커 컨테이너를 쓰면 되는 거 아니야?
맞습니다. 하지만 DockerHub에 Tizen Studio와 관련된 도커 이미지가 없었고, Tizen과 관련된 자료가 그렇게 많진 않았기에 필요한 의존성과 패키지를 찾는 것도 일이었습니다. 무엇보다도, Express.js를 배포할 때마다 그 무거운 Tizen Studio와 Android Studio를 설치한다면 빌드가 매우 오래 걸릴 거라고 걱정했는데, 이건 도커의 이미지 레이어링 방식에 의해 걱정할 필요가 없더군요.
그렇다면 결국 남은 문제는 필요한 의존성과 패키지로 구성된 공식 도커 이미지가 없다는 건데, 어쩌겠습니까.. 없다면 만들어야죠
2. Docker Image Layering
도커 이미지(Docker Image)는 여러 개 레이어(Layer)로 구성되어 있습니다. 각 레이어는 해당 파일 시스템의 변경 사항(추가, 삭제, 수정)에 대한 내용들이 포함되어 있죠. 이러한 레이어들은 일단 생성되면 변경할 수 없고, 서로 쌓이면서 최종적으로 도커 이미지 형태를 구성하게 되는 것입니다. 그리고 이 최종 형태야말로, 도커 컨테이너가 사용할 수 있는 파일 시스템이 되는 것이죠.
레이어들은 도커 파일(Dockerfile)에서 각 명령어에 해당한다고 볼 수 있습니다. 위의 그림처럼, 도커 파일에 Ubuntu 20.04 이미지를 기반으로 하여 그 위에 Tizen Studio CLI를 설치하고, Android Studio CLI를 설치하고 이러한 과정들이 각각 레이어로 호스트 파일 시스템에 저장된다는 것이죠.
Q. 그래서 이게 왜?!
생성된 불변의 이미지 레이어들은 호스트 파일 시스템에 저장된다고 했습니다. 그리고 이들은 "도커 파일에서의 명령어 + 레이어의 내용"을 조합한 해시 코드값으로 관리되죠. 즉, 변경 사항이 있는지 없는지를 빠르게 파악할 수 있다는 뜻입니다.
만약 도커 파일을 통해 도커 이미지를 생성하는 과정에서, 이미 가지고 있는 레이어가 있다면 어떨까요? 새로 만들 필요 없이 기존에 있는 레이어를 참조하여 만들면 효율적이지 않을까요?
Tizen Studio와 Android Studio은 기본적으로 설치 과정이 복잡하고, 많은 의존성과 패키지를 요구하는 큰 프로그램입니다. 처음에는 설치 과정과 빌드 시간이 오래 걸릴 겁니다. 하지만 그렇게 만들어 놓은 이미지를 도커 허브에 올려두고, EC2에 Pull을 받아둔다면요?
Tizen Studio/Android Studio 이미지는 새로운 패키지를 추가하거나 삭제하는 일이 그렇게 자주 일어나진 않기 때문에, 웬만하면 재사용해서 쓸 수 있습니다. 그리고 개발하느라 빈번하게 변경되는 Express.js는 Tizen Studio/Android Studio 도커 이미지를 빌드할 필요 없이, Pull 받아 둔 이미지 레이어를 그대로 사용하고 다음 레이어를 중첩하러 가면 됩니다.
3. 하지만 Dockerfile을 만드는 것은 쉽지 않았다.
제가 사용해야 할 환경에 맞는 버전과 각 패키지 정보들을 알아보고 그러는 게 오래 걸렸습니다. 특히, Tizen Studio 쪽은 자료가 많이 없었고, 다운로드 페이지가 이전되어서 바뀐 페이지를 다시 찾아보기도 했습니다.
그리고 Tizen과 Android가 요구하는 기본 디렉토리 구조들이 있는데, 그걸 안 지켜줘서 혼나기도 했습니다. 그렇게 삽질하면서 설치에 성공했더라도, 기존 개발 환경과 경로가 달라 명령어를 못 쓰는 사태도 발생했었죠. 이외에도 여기서 설명하지 않은 되게 많은 문제들이 발생해서 새벽까지 컴퓨터를 붙잡고 있기도 했습니다.
우여곡절이 많았지만, 그래도 하나씩 해결하면서 결국 Tizen Studio/Android Studio가 설치된 도커 이미지를 만들 수 있었습니다.
다음 명령어를 통해 받으실 수 있습니다.
docker pull daekyooou/tizen-android-base:latest
4. 회고
같은 환경을 쉽게 구성할 수 있는 도커(Docker)의 힘을 느낀 경험이었습니다. (도커가 없던 이전에는 어떻게 개발을 했을까요...) 도커의 관리 매커니즘에 대해 더 공부하고 이해할 수 있는 시간이었고, 덕분에 인프라 경험치가 +100이 추가되었습니다. 이렇게 공부하다 보면 언젠가 저 혼자서도 서비스를 만드는 날이 올 것 같다는 생각이 듭니다.
'Trouble Shootings > Infrastructure' 카테고리의 다른 글
| [Jenkins] 역방향 프록시 설정이 잘못되었습니다. (0) | 2025.03.22 |
|---|---|
| [Jenkins, Docker] docker.sock: connect: permission denied (0) | 2025.03.18 |
| [Jenkins] ERROR: Error fetching remote repo 'origin' (권한 문제) (0) | 2025.03.18 |
| [Nginx] 413 Error: Request Entity Too Large (0) | 2025.02.16 |