Plaything을 개발하면서 주간 회의 때 나온 말이
"배포서버에 직접 접근이 안되면 저희 로컬에서 작업할 수 있게 해주세요. 도커로"
였다.
처음에는 그게 무슨 말인가 싶었다.
문제 상황은 다음과 같다.
배포 서버는 아직 HTTPS를 적용하지 않았다. 도메인 구메와 관련해서 시간이 좀 걸려서 인증서를 받지 못했다.
그런데, STOMP는 알고보니 HTTPS로만 처음에 연결을 할 수 있었다.
그래서 클라이언트에서 배포 서버의 채팅 기능을 활용할 수 없었다.
그래서 도커 컨테이너 이야기가 나온 것이다.
도커 컨테이너란 무엇일까?
여러가지 라이브러리를 이 컨테이너 안에서 조합한 다음에 컨테이어를 띄운다. 그러면 레디스나, 스프링 부트를 실행할 수 있다.
쉽게 생각하면, 내가 자바를 gradle로 build해서 만든 jar파일을 도커 컨테이너에서 바로 실행할 수 있는 것이다. 근데 그러면 이를 실행하기 위한 의존성들이 필요하다.
java도 필요할 것이고, MySQL도 필요하다. 레디스를 연결했다면 레디스도 있어야 한다.
이러한 의존성들을 docker-compose 파일안에다 넣어놓고
그 도커 컨테이너를 띄우면 바로 jar 파일을 실행시킬 수 있도록 해주는 방식이다.
그러면 이 jar 파일을 어디서든 실행할 수 있다.
java나 MySQL 프로그램이 깔려 있지 않은 PC에서도 말이다.
스택오버플로우 글을 보니, 로컬 환경에서는 브라우저들이 http도 신뢰 가능하다고 판단해서 https라서 안된다는 에러들이 발생하지 않는 것으로 보인다.
클라이언트 개발자들에게 로컬호스트에서 스프링서버를 실행시킬 수 있는 도커 스크립트를 전달하면, HTTPS 적용 없이도 API를 사용할 수 있을 것이다.
services:
chat-server:
build: docker
container_name: chat-server
ports:
- "7002:7002"
environment:
- SPRING_DATASOURCE_URL=jdbc:mysql://chat-mysql:3306/plaything_test
- SPRING_DATASOURCE_USERNAME=root
- SPRING_DATASOURCE_PASSWORD=0000
- SPRING_JPA_HIBERNATE_DDL_AUTO=update
depends_on:
- db
networks:
- chat-network
db:
image: mysql:8.0
container_name: chat-mysql
environment:
- MYSQL_DATABASE=plaything_test
- MYSQL_USER=plaything_test
- MYSQL_PASSWORD=0000
- MYSQL_ROOT_PASSWORD=0000
ports:
- "3307:3306"
volumes:
- mysql_data:/var/lib/mysql
networks:
- chat-network
volumes:
mysql_data:
networks:
chat-network:
driver: bridge
//도커의 기본 네트워크 드라이버이며, 대부분의 단일 호스트 도커 애플리케이션에서 사용FROM openjdk:17-alpine
WORKDIR /app
COPY api-0.0.1-SNAPSHOT.jar app.jar
EXPOSE 7002
ENTRYPOINT ["java","-jar","app.jar"]이 스크립트를 보면 MySQL과 자바 17 이미지들을 사용해서 도커 compose 를 실행하는 것을 알 수 있다.
평소에 도커를 왜 써야 할까? 하는 생각을 하긴 했다.
깃헙액션에서 CI/CD를 할 때 이렇게 스크립트를 작성하고, 그 스크립트를 기반으로 의존성을 Import해서 jar 파일을 만드는 건 알고 있었는데...!
컨테이너가 이런 방식으로 많이 쓰이는 거 같다.
