프로젝트를 진행하면서 로컬에서 잘 작동하던 프로젝트가 서버에 배포하면 잘 작동하지 않을 수 있다.
수많은 원인이 존재하겠지만 라이브러리 버전이 다르다거나 네트워크 환경이 다르다거나 하는 이유가 있을 수 있다.
로컬 환경과 서버 환경의 차이로 인해 이러한 예상치 못한 문제가 발생하는 것을 방지하기 위해 컨테이너 방식이 존재한다.
컨테이너 방식을 사용하면 환경 자체를 배포할 수 있게된다.
VM과 컨테이너
컨테이너와 자주 비교되는 것이 VM(Virutal Machine)이다.
둘 다 독립적인 환경을 가질 수 있고 환경을 이미지로 만들어 공유할 수 있다는 점에서 비슷하지만 약간의 차이가 있다.
우선 VM 방식은 host os 위에 여러 개의 guest os가 존재하고 각각의 guest os 위에 라이브러리, 애플리케이션 등이 설치된다.
그런데 OS는 그 자체로 굉장히 큰 용량을 차지하고 각각의 가상 환경들은 로컬 컴퓨터의 리소스를 할당받기 때문에 성능면에서 문제가 발생할 수 있다.
그에 비해 도커는 각각의 컨테이너마다 os를 가지고 있는 것이 아니라 로컬 os(Host OS)를 공유해서 사용하기 때문에 용량, 성능 측면에서 장점을 가진다.
즉 이러한 컨테이너 방식을 사용하면 서비스를 개발할 때 환경에 구애받지 않고 빠르게 개발 할 수 있고 코드가 오류없이 실행되는 것을 보장해준다.
예를 들어 내 컴퓨터에 Node.js가 깔려있지 않아도 도커를 사용하면 Node.js 웹 서버를 실행할 수 있다.
도커(Docker)의 개념
우선 개발한 서비스를 배포할 때 개발 환경 자체를 이미지로 만든다.
도커 이미지(Docker Image)란 서버 프로그램, 소스 코드 및 라이브러리와 같은 것들을 하나로 묶어서 만든 것이다.
도커 컨테이너(Docker Container)는 도커 이미지로부터 생성되어 실행되는 상태이다.
도커 이미지 하나만 있어도 여러 개의 도커 컨테이너를 만들 수 있다.
도커(Docker)에는 여러 개의 컨테이너를 올릴 수가 있다.
도커 이미지 생성 및 실행
시작 전에 간단한 docker 명령어들을 알아보려고 한다.
참고로 이미지 아이디 대신 이미지 이름을 사용할 수 있고 컨테이너 아이디 대신 컨테이너 이름을 사용할 수 있다.
컨테이너 이름은 docker run --name [컨테이너 이름] [이미지 이름] 명령어를 통해 설정할 수 있다.
1. 도커 허브로부터 이미지 pull
docker pull [이미지 이름]:[태그]
2. 도커 이미지 조회
docker images
3. 이미지 삭제
docker rmi [이미지 아이디]
4. 컨테이너 조회
docker ps
5. 모든 컨테이너 조회 (종료된 컨테이너 포함)
docker ps -a
6. 컨테이너 실행
docker run [이미지 아이디]
docker run [이미지 이름]:[이미지 태그]
docker run --name [컨테이너 이름] [이미지 이름]
7. 컨테이너에 명령어
docker exec [명령어]
8. 컨테이너 쉘 접근
docker exec -it [컨테이너 아이디] /bin/sh
9. 컨테이너 종료
docker stop [컨테이너 아이디]
10. 컨테이너 삭제
docker rm [컨테이너 아이디]
11. 컨테이너 로그 조회
docker logs [컨테이너 아이디]
12. 컨테이너 로그 실시간 조회
docker logs -f [컨테이너 아이디]
docker run은 이미지를 바탕으로 컨테이너를 생성하는 것이고 exec은 이미 존재하는 컨테이너에 명령어를 실행하는 것이다.
Docker Hub Container Image Library | App Containerization
Deliver your business through Docker Hub Package and publish apps and plugins as containers in Docker Hub for easy download and deployment by millions of Docker users worldwide.
hub.docker.com
우선 이미 존재하는 이미지를 받아서 실행해보려고 한다.
위 도커 허브 같은 사이트에서는 수많은 도커 이미지들이 존재하고 원하는 환경을 찾아서 받은 후 실행할 수 있다.
나는 openjdk를 다운받아서 실행해보려고 한다.
도커 허브에서 openjdk를 검색해서 들어간다.
나는 도커 공식 이미지 openjdk를 받을 예정이고 Tags에 보면 많은 버전들이 존재하는데 17-alpine을 사용하려고 한다.
Tag의 종류도 되게 다양하기 때문에 자신의 환경에 맞게 적절히 선택하면 된다.
이 이미지를 받으려면 docker pull 명령어를 사용한다. 잘 보면 원하는 Tag의 pull 명령어를 복사할 수 있도록 되어있는 모습을 확인할 수 있다.
명령어를 입력하면 다운로드 되었다는 메시지가 뜨고 docker images를 입력하면 현재 로컬 내부의 이미지들을 조회할 수 있다.
잘 다운로드 받았다면 우리가 받은 이미지의 정보를 볼 수 있을 것이다.
이제 docker run 명령어를 통해 컨테이너를 실행한다.
docker run 명령어에는 여러가지 옵션을 줄 수 있는데 그 중 -i와 -t에 대해 알아보려고 한다.
-i는 표준 입력(stdin)을 활성화하고 -t는 가상 터미널을 열어 키보드로 입력을 할 수 있게 해준다.
보통 docker run -it로 함께 사용한다.
docker run -it [이미지 아이디] /bin/sh 명령어를 입력하면 리눅스 명령어를 사용할 수 있다.
한 번 java --version 명령어를 입력해보자. openjdk 17 버전을 받았기 때문에 해당 버전이 출력되어야 한다.
도커에서 jar 파일 실행
이제 이 도커에서 jar 파일을 실행해보려고 한다.
우선 exit 명령어를 통해 빠져나온다.
그리고 다음 과정을 순서대로 진행하면 된다.
1. 로컬 파일을 도커 컨테이너로 복사
docker cp [파일 경로/파일 이름] [컨테이너 아이디]:[경로]
2. 컨테이너 재시작
docker restart [컨테이너 아이디]
3. 컨테이너 쉘 접근
docker exec -it [컨테이너 아이디] /bin/sh
나는 컨테이너 내부 "/home" 디렉토리에 jar 파일을 복사했다.
해당 디렉토리로 이동 후 파일들을 출력해보면 jar 파일이 성공적으로 복사된 모습을 확인할 수 있다.
java -jar 명령어로 jar 파일이 성공적으로 실행되는지 확인하자.
도커 컨테이너 이미지화
이미지를 받아서 컨테이너를 실행한 후 컨테이너 안에 jar 파일을 복사했다.
이러한 컨테이너의 변경사항을 commit 명령어를 통해 이미지화 할 수 있다.
docker commit [컨테이너 아이디] [이미지 이름]:[태그]이미지 생성후 docker images 명령어를 통해 이미지가 잘 생성되었는지 확인하자.
컨테이너에서 외부 요청 받기
이제 도커를 통해서 EC2 서버를 로컬에서 실행시켜보자.
먼저 이미지로부터 컨테이너를 실행해준다.
docker run -it -p 8080:8080 openjdk /bin/sh
-p 옵션은 포트를 호스트와 컨테이너 포트를 매핑해주는 역할이다.
호스트 8080 포트와 도커 컨테이너 내부 8080 포트를 일치시켜준다.
이렇게 포트를 매핑해줘야 localhost:8080으로 요청을 보낼 수 있다.
만약 스프링부트 포트 번호를 8080번호로 세팅을 했는데 localhost:8081로 요청을 보내고 싶다면 docker run -d -p 8081:8080 [이미지 아이디] 명령어를 입력하면 된다.
이제 다시 빠져나온 후 똑같이 jar 파일을 원하는 경로에 복사하고 다음 명령어를 날려주면 된다.
docker exec [컨테이너 아이디] -it java -jar [경로/jar 파일 이름]
postman을 통해서 localhost:8080으로 요청을 날려보면 응답을 받을 수 있을 것이다.
그런데 이렇게 일일이 jar 파일을 넣어주는 방식은 귀찮은 방식이다.
스프링 부트에서 Dockerfile을 통해 이러한 과정을 단축시킬 수 있다.
다음에는 Dockerfile을 통해 이러한 과정을 단축시켜보려고 한다.
댓글