Docker 적용하기
Dockerizing
시작하기에 앞서 당일 공부하여 적용하려 했기 때문에 많은 우여곡절이 있었다.
따라서 기본적인 Docker의 사용에서도 많은 실수를 했으며, 해당 내용을 어느정도 포함할 예정이다.
Dockerfile Create
FROM node:18`// 사용할 Node Version인데 사용하고 있는 babel 적용을 위해 14이상의 버전필요
WORKDIR /wetube-practice // Working directory
COPY package.json . // [상대경로,절대경로 둘다가능] package 목록 COPY
RUN npm install // 사용중인 package를 설치한다.(Container에 node_modules 생성)
COPY . . // 현 Working space의 모든 내용 COPY
EXPOSE 4000 // Docker 내부 port 개방
CMD ["node","app.js"] // node 실행 command line아래에서 모든 내용을 복사하는데 package.json을 먼저 복사한 이유는 단순하다.
먼저 Docker image는 스냅샷이라는 점과 그러한 image를 빌드할때 중요한 것은 Dockerfile은 layer 방식으로 실행된다는 점으로 변경된 부분만 감지(Dockerfile을 기준으로 각라인으로 이해하면 될듯)하여 리빌드한다는 것인데 만약 모든 파일을 복사하고 npm install을 한다면 package의 변화가 없어도 매번 install을 하는 상황이 발생할 것이다. 따라서 이러한 리소스의 낭비를 막기위해 위와 같은 형태가 되었다.
해당 workspace에서(Dockerfile이 있는) docker build . 명령어
에러의 이유는 docker desktop이 실행 중이 아니어서.
다시 실행하면 dockerfile에서 image를 빌드한다. 해당 image의 id를 확인할수있다.(windows 기준)
또다시 에러 발생.
파일의 Local Path가 src/app.js 이기때문에 못찾아서 생긴 오류.
바꾼후 빌드를 다시 해줬으므로 Image 또한 다시 생성 바뀐 ID값으로 실행했는데 (run -p system-port:container-prot)
내용을 보니 확장자를 mjs로 바꾸거나 type:module을 설정하라고 한다. 확장자를 변경.
실행 확인했다.
실행했던 Docker를 종료.
Nodemon 적용하기
단순한 Docker 환경은 마련되었지만 매번 바뀔때마다 image를 재생성하고 빌드하며, run을 해야하는 상황으로 이 상태에서는 매우 번거로울 수밖에없다.
따라서 해당 부분을 해결하기 위해 몇가지를 변경하려고 하는데, 먼저 Nodemon이 적용되어 있는 상태이므로 NodeJS는 신경쓸 필요가 없는 상황이지만 실질적으로 위와 같은 문제때문에 의미가 없는 상태이다. 따라서 적용될 수 있도록 부차적인 작업을 해줘야한다.
현재 시스템의 상황은 Docker Desktop이 WSL2를 기준으로 되어있는데 예상되는 문제는 VSCode에서 사용하고 있는 파일들은 윈도우 시스템으므로 두가지를 생각해볼수있다.
나는 파티션을 별도로 나누어 쓰지 않았으므로 디바이스의 상황은 아래와 같다.
이러한 상태에서 wsl로 mount를 시도한다면
wsl을 통해 Docker를 사용중이었으므로 해당 Device는 mount 하고있을거라 판단.
Docker의 Bind Mount를 사용하여 변경사항을 바로 적용할 예정이다.
간단하게 Bind Mount에 대해 이야기한다면, 호스트 머신에 매핑 될 컨테이너의 경로를 설정하는 것이다.
즉 컨테이너가 컴퓨터에 저장된 해당 내용을 참조하여 즉각 적용된다고 생각하면 될 듯 하다.
Volume은 그 위치를 알 수 없기 때문에 (Docker가 알아서 관리한다.) Bind Mount를 사용할 수밖에 없는 상황.
그렇다면 어디서 어떻게 적용하는가?
먼저 Docker의 Image는 스냅샷이라고 했다. (그리고 도커가 호스트를 직접 수정하는 일은 없다.)
이후의 변경점에 대해 논하는 것이므로 Dockerfile을 기반으로 빌드하는 시점까지는 동일한 프로세스일 것이며 그렇다면 빌드까지는 그대로 적용하고 run에서 제어하면 될듯하다.
WORKDIR /app
EXPOSE 8000
CMD ["node","dev"] CMD에 Script를 적용했다.
아래는 발생한 Error들이다.
https://learn.microsoft.com/en-us/windows/wsl/filesystems 에서 wsl로 접근하는 방식을 확인.
해결되었음을 확인할 수 있었다.
여기서 NodeJS에 대한 매우 기본적인 실수를 했는데 아래와 같다.
WORKDIR /wetube-practice // 잘못된 패스설정
CMD ["npm","run","dev"] // 언급한 scpript 실행부따라서 당연히(WORKDIR 문제로) Path상에서 못찾았던 것.
이미지를 다시 빌드 후 필요없던 -v wetube:/app/wetube 와 같은 볼륨제거 후 실행하니 제대로 동작하는 것을 확인.
(단, 내가 열어둔 내부 포트는 8000이므로 저부분은 소스내에서 변경이 필요.)
이로써 Docker 환경에서 기본적인 적용이 가능해졌음을 알 수 있었다.
접근권한의 문제는 System에 따라 나누어질 수 있는데, 보편적으로 Docker Desktop의 Setting- Resources-File Sharing에서 설정하는 것 같으나, 나의 경우 File Sharing이 없었으며 WSl로 window에서 직접 관리된다는 메세지를 확인할 수 있었다. 이 부분에서 문제없이 진행 된 것으로 보아서 초기 Docker를 설치하면서 WSL2에 관한 세팅에서 이미 권한 설정이 되었던 것으로 생각된다.
문제가 추가로 발생하여 해결중...
실시간으로 적용되지 않고있음.
위에서 경로의 오타를 발견했지만 수정해도 변함없는 것으로 보아 WSL에서 Docker로 전달이 되지 않고 있음을 확인.
https://www.docker.com/blog/docker-desktop-wsl-2-best-practices/
에서 추천하는바로 VSCode의 WSL Extension을 이용한 방법을 사용하기로 변경.
https://docs.docker.com/desktop/windows/wsl/ 에서 마운트의 방식에 대해 /mnt 를 지양.
https://devblogs.microsoft.com/commandline/access-linux-filesystems-in-windows-and-wsl-2/ 단일 파티션에 대해서는 지원되지 않는 상황으로 현재 파티션이 1개 이기때문에 윈도우즈 파일의 마운트는 현재로썬 진행불가.(파티션을 나눌수도 없는 상황.)
결국 위에서 나온바와 같이 WSL의 내부에서 작업하는 방식과 nodemon -L 옵션조차 되지 않는 상황으로 보아 WSL와 Docker 사이에서 제대로 전달이 안되는 듯하다.
https://stackoverflow.com/questions/39239686/nodemon-doesnt-restart-in-windows-docker-environment?rq=3 확인. 2022년까지도 해결되지 않은 문제로 윈도우용 Docker의 문제로 일단락. 해당 세팅은 맥북을 기준으로 하고 윈도우는 배포된 것을 테스트하는 용으로 당분간 운용해야겠다.
Extra
Docker 또한 Repository를 제공한다.(무료는 하나뿐이지만...)
따라서 pull, push가 가능한데 가입하여 VSCode내에서도 login완료.
현재 DockerHub의 repository 이름과 image의 이름은 같지만, 태그가 추가되어있어 동일하지 않은 상황.
다시 빌드하긴 싫으므로 docker tag wetube-practice:dev primicream/wetube-practice로 이미지를 복제하여 push하는 방법을 선택했다.(만약 동일하지 않은 상태에서 push한다면 denied: requested access to the resource is denied 메시지를 확인할 수 있을것이다.)
push가 잘이루어졌음을 확인.
이제 본격적으로 wetube 내용을 진행하게 되었다.
