오늘 배운것
Spring Cloud Config Client와 중앙 집중식 설정 관리
오늘은 Spring Cloud Config Server를 기반으로 실제 Microservice가 외부 설정을 사용하는 Config Client와 Spring Cloud Bus를 학습하였다. 이전까지는 Config Server의 역할과 외부 저장소(Git Repository)에 설정 파일을 관리하는 방법을 배웠다면, 오늘은 각 Microservice가 Config Server로부터 설정을 가져와 사용하는 과정과 변경된 설정을 서비스에 반영하는 방법을 실습하였다.
1. Spring Cloud Config Client
Spring Cloud Config Client는 애플리케이션 실행 시 Config Server에 접속하여 필요한 설정 정보를 가져오는 역할을 수행한다.
기존에는 각각의 Microservice가 자신의 application.yml을 직접 관리하였다.
Catalog Service
└─ application.yml
User Service
└─ application.yml
Order Service
└─ application.yml하지만 Config Server를 사용하면 설정 파일은 Git Repository에서 관리되고, 각 서비스는 실행 시 Config Server를 통해 필요한 설정을 받아온다.
Git Repository
│
▼
Spring Cloud Config Server
▲
│
Config Client
(User Service, Catalog Service ...)이 구조를 통해 설정을 중앙에서 관리할 수 있으며, 여러 서비스의 공통 설정을 하나의 저장소에서 유지보수할 수 있다는 장점이 있다.
2. Config Client의 동작 과정
Config Client는 애플리케이션이 실행되면 다음 순서로 동작한다.
- Config Client 실행
- Config Server 접속
- Config Server가 Git Repository에서 설정 조회
- 해당 설정을 Client에게 전달
- 전달받은 설정으로 애플리케이션 실행
즉, 실제 서비스는 로컬의 설정이 아닌 외부 설정 저장소의 정보를 기반으로 동작하게 된다.
3. 설정 파일 우선순위
수업 중 가장 궁금했던 부분은 외부 저장소와 로컬 설정 파일이 동시에 존재할 경우 어떤 설정이 적용되는가였다.
Spring Cloud Config에서는 기본적으로 외부 저장소(Git Repository)의 설정이 우선 적용된다.
예를 들어,
Local application.yml
server.port=8080Git Repository
server.port=9001이라면 실제 실행 시에는
server.port=9001이 적용된다.
외부 저장소에 존재하지 않는 설정만 로컬 설정을 사용하게 된다.
4. Local Git Repository 구성
Config Server는 Git Repository를 설정 저장소로 사용한다.
Mac 환경에서는
/Users/.../git-local-repo를 사용하지만,
Windows에서는
C:\inspire\git-local-repo와 같이 직접 Repository를 생성하여 사용하였다.
실습 과정
- git-local-repo 생성
- git init
- ecommerce.yml 작성
- git add
- git commit
이후 Config Server에서 해당 Repository를 참조하도록 설정하였다.
Docker 학습
오늘부터 Docker 실습도 함께 진행하였다.
1. Container와 Image
Docker는 컨테이너 기반 가상화 플랫폼이다.
Image는 실행 환경 자체를 의미하며,
Container는 Image를 실제로 실행한 인스턴스이다.
즉,
Image
↓
Container의 관계를 가진다.
Image 하나로 여러 개의 Container를 생성할 수 있다.
2. Docker Image 생성
Dockerfile을 이용하여 Image를 생성하는 과정을 학습하였다.
대표적인 명령어
docker build
docker image ls
docker run등을 사용하였다.
또한 Docker Hub와 Local Registry를 이용하여 이미지를 저장하고 관리하는 방법도 학습하였다.
3. Volume과 Port Mapping
Node.js 실습을 진행하면서
-v옵션을 이용한 Volume 연결과
-p옵션을 이용한 Port Mapping의 의미를 이해하였다.
Volume은
Host의 파일을 Container 내부에서 그대로 사용할 수 있도록 연결하는 기능이며,
Port Mapping은
Host와 Container 간의 네트워크를 연결하는 기능이다.
Spring Cloud Bus
Config Server만 사용할 경우
설정이 변경되면
서버 재시작
또는
/actuator/refresh를 직접 호출해야 한다.
Spring Cloud Bus는 이러한 불편함을 해결하기 위해 RabbitMQ를 이용하여 변경된 설정을 모든 서비스에 전파하는 역할을 수행한다.
동작 과정은
Git 변경
↓
Config Server
↓
Spring Cloud Bus
↓
RabbitMQ
↓
모든 Microservice와 같은 구조이다.
이를 통해 여러 서비스에 동일한 설정 변경을 자동으로 Broadcast할 수 있다.
RabbitMQ
Spring Cloud Bus의 메시지 브로커로 RabbitMQ를 사용하였다.
RabbitMQ는
- 메시지 전달
- Queue 관리
- Publish / Subscribe 구조
를 지원하는 메시지 브로커이다.
Bus는 RabbitMQ를 통해 모든 Microservice에게 설정 변경 이벤트를 전달한다.
트러블 슈팅
Docker Volume 연결 문제
Node.js 실습 과정에서
node app.js실행 시
Cannot find module '/app/app.js'오류가 발생하였다.
원인을 확인한 결과 Git Bash에서 Volume 경로가 Windows 경로로 자동 변환되어 Container 내부에 정상적으로 연결되지 않는 문제였다.
PowerShell에서 다시 실행하여 Volume Mapping을 수정하면서 문제를 해결하였다.
RabbitMQ Queue 생성 오류 (진행중)
Spring Cloud Bus를 적용하는 과정에서
404 NOT_FOUND
springCloudBus.anonymous...오류가 발생하였다.
RabbitMQ는 정상적으로 실행 중이었지만 Spring Cloud Bus가 사용하는 Queue가 생성되지 않아 Config Service가 존재하지 않는 Queue를 참조하고 있었다.
로그를 분석하며
- RabbitMQ Queue 생성 방식
- 익명 Queue(auto-delete)
- Spring Cloud Stream의 Queue 관리 방식
등을 확인하였지만 실습 시간 내에는 정상 동작까지 확인하지 못하였다.
