You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 7 Next »

여기서는 로컬 도커에, 모든 마이크로 서비스를 뛰우는 방법에 대해 설명을 합니다.

사전 요구 지식:


클라우드환경에서 도커의 이점은 굳이 설명을 하지 않겠습니다. 

도커이용방법에는 몇가지가 있으며 도커 컴포즈를 통해 그룹화도 될수 있으며, 도커스웜,쿠버네틱스등 

다양한 오케스트라툴과 연동이 될수도 있으며 , AWS 도커지원 툴과 연동될수도 있습니다.

하지만 그전에, 단일 도커객체 즉 로컬 도커환경에서 빌드및 배포가 먼저 가능한후 다음으로 연계할수가 있으며 이것은 중요합니다.

이 프로젝트에서 실험되고 있는 마이크로 서비스를 로컬도커에 모두 뛰울수 있는 방법에 대해 알아 보겠습니다.

도커를 위한 개발 환경

도커사용이 준비된 로컬 도커 개발환경의 모습은 위와 같을것입니다. 고정 아이피를 명시한것은

DNS룰을 따르기보다, 직접 아이피를 할당하고, 유레카의 마이크로 서비스 발견서비스를 직접 이용하기 위해서입니다.

클라우드를 어떻게 이용하냐에따라 DNS툴을 이용할수도 있으며, 도커 객체가 여러개여서 Overlay Network를

활용하는 방법도 있습니다. 여기서는 로컬에서 도커가 올바르게 빌드되고 배포되어 Spring의 로드밸런스를 무설정으로

사용할수 있는가? 가 촛점이기때문에 로컬에 집중을 하겠습니다.

보통 이정도만 구축이 되어도  우리의 마이크로 서비스는 클라우드로 전환및 테스트환경을 구성하기 하기위해 준비가된것입니다.

즉, 인프라를 구성할수 있는 데브옵스가 존재한다면 최소 이정도 레이아웃이 되게끔 한후 , 넘겨야한다는 의미입니다.

자신이 생성한 프로젝트를 도커빌드구성을 못한다고 하면 꾸준하게 학습하는것이 권장됩니다.

요즘은 도커를 왜 알아야되? 라는 질문은 , git을 왜 써야되 혹은 알아야되? 와 동급질문일수 있습니다.

 -그만큼 마이크로서비스를위해 도커가  성숙을 하였으며 더이상 도입에대해 논의 대상이 아닙니다.

 

Static IP환경을 위한 도커 네트워크 생성

# 로컬 개발환경을 위한 devnet 네트워크 생성
docker network create --driver=bridge --subnet=172.19.0.0/16 devnet

# 네트워크 조회
network ls

# 네트워크 살펴보기
docker network inspect devnet
# "Subnet": "172.19.0.0/16",
# "Gateway": "172.19.0.1"

# 네트워크 제거
docker network rm devnet

위와같은 명령어로, 172.19.0.2 ~ 172.244.244 까지 아이피를 내부에서 사용할수가 있습니다.

이범위는 Subnet 에서 범위를 지정하는것으로 172.19.0.0./16 에서 정해집니다.  자세한것은 서브넷마스크의 원리를 참조하세요

네트워크의 이름을 devnet 으로 주었기때문에 , 도커명령에서 devnet을 항상 이용할수가 있습니다.


어플리케이션 빌드 생성

Dockerfile
FROM openjdk:8-jre-alpine
MAINTAINER wiki.webnori.com
ENV APP_FILE config-service-0.0.1-SNAPSHOT.jar
ENV APP_HOME /usr/apps
COPY target/$APP_FILE $APP_HOME/
WORKDIR $APP_HOME
ENTRYPOINT ["sh", "-c"]
CMD ["exec java -jar $APP_FILE"]
EXPOSE 8888

이 프로젝트의 샘플 :https://github.com/psmon/springcloud/tree/master/config-service


프로젝트 마다, 도커 빌드가되는 스크립트인 Dockerfile을 포함하여 유지해주면 , 로컬 개발중에 언제든 이용할수가 있습니다.

공식 배포 빌드에서는 어플리케이션의 버젼및 몇가지 환경설정이 주입되어야하지만, 일반적인 Java 어플리케이션은

위와같은 스크립트로 도커 빌드가 가능합니다.


빌드및 로컬 실행

빌드를 성공시키고 실행을 하기위해, 우선 Spring Cloud의 종속관계를 정확하게 알고 있어여합니다.  - 더많은정보

3가지 설정 Type이 있으며, 발견서비스(유레카),설정서비스(ConfigServer)  만 나머지와 약간다르며

우리가 구현해야할 서비스는 중앙 컨피그에서 모두 제어될수 있기때문에 나머지 추가되는 서비스는 동일합니다.


설정 Type A : 유레카

eureka
# 기존서비스를 중지하고 날린다.
docker stop eureka1
docker rm eureka1

# 빌드를 수행하여, 로컬 도커 저장소에 추가시킨다.
docker build -t psmon.eureka .

# 빌드된 도커베이스로 실행을 한다. ( 주의 : 개행처리 ^ 는 윈도우베이스,리눅스일시 \ 사용)
docker run --net devnet --ip 172.19.0.31 -it -d -p 8761:8761 -e "SPRING_PROFILES_ACTIVE=dock-local" ^
--hostname 172.19.0.31 ^ --name eureka1 psmon.eureka

여기서는 단일 유레카를 사용했으며, 여기서 핵심 포인트는 발견서비스는 상위 의존이 없어서

자신의 아이피만 지정후 그냥 구동되면 됩니다.  8761(외부):8761(내부) 와 같은 외부는  로컬에서 상태를 파악하기위한

편의 용도입니다.  


설정Type B : 설정 서버

configservice
# 기존서비스를 중지하고 날린다.
docker stop configservice
docker rm configservice


# 빌드를 수행하여, 로컬 도커 저장소에 추가시킨다.
docker build -t psmon.configservice .


# 빌드된 도커베이스로 실행을 한다. ( 주의 : 개행처리 ^ 는 윈도우베이스,리눅스일시 \ 사용)
docker run --net devnet --ip 172.19.0.30 -it -d -p 8888:8888 -e "SPRING_PROFILES_ACTIVE=dock-local" ^
-e "SPRING_CLOUD_CONFIG_SERVER_GIT_URI=https://github.com/psmon/mycloudconfig.git" ^
-e "SERVICE_URL_DEFAULT_ZONE=http://172.19.0.31:8761/eureka/" ^
--hostname 172.19.0.30 ^
-e "MY_HOST_IP=172.19.0.30" --name configservice psmon.configservice

여기서 중요설정은 , 환경설정에 이용되는 세부사항 git을 지정해야하는것과

유레카 서버를 지정하는것입니다.  ( 유레카에 내가 있노라하고 등록이됨 )

설정 TypeC : 나머지

edgeservice
docker stop edgeservice
docker rm edgeservice
docker build -t psmon.edgeservice .

docker run --net devnet --ip 172.19.0.32 -it -d -p 80:8888 -e "SPRING_PROFILES_ACTIVE=dock-local" ^
--hostname 172.19.0.30 ^
-e "SPRING_CLOUD_CONFIG_URI=http://172.19.0.30:8888" --name edgeservice psmon.edgeservice

나머지 서버의 특징은, 설정 서버만 지정되면 됩니다. 그러면 설정서버의 존과 룰에의해 나머지 설정이

자동으로 됩니다.  즉 유레카 서버설정 자체도..설정서버에 포함이 되어 있다란 의미 입니다.

여기서 중요한 의미를 가지게됩니다.  나머지 설정을 지저분하게 Java옵션을통해 전달하는게 아닌

최소한의 설정만한후... 통합된 설정 ( git) 을 이용하고 제어하는것이 Spring Cloud Config의 최종 목표입니다.


InteliJ 에서 Docker구동하기

도커 명령실행은, 개별 커멘드창에서도 가능하지만  IDE툴과 통합되어 도커 컨테이너의 상태를 바로 확인할수가 있습니다.

도커를 올바르게 사용하기 까지 엄청난 고통에 시다릴것이기때문에, 통합하여 빠른실패를 반복하여 학습시간을 줄이는것을 권장합니다.

그리고 이것은은 도커에 리모트 디버깅도 가능하게 합니다. ( 별도로 다룰예정)


유레카 설정

application.properties
spring.application.name=eureka
server.port=8761
eureka.client.register-with-eureka=false
eureka.client.fetch-registry=false
eureka.instance.preferIpAddress=true

로컬에서 ip사용 전략을 선택하였기때문에, 유레카 서버는 위와같은 설정이 포함되어 있습니다.


성공적인 유레카 모습

 url : http://localhost:8761/

이 프로젝트에서 사용되는 주요 3가지 서비스가 유레카에의해 정확하게 아이피 기반으로 감지되는 결과입니다.

이 과정이 한번 셋팅이되면, 나머지 서비스는 Type3방식을 사용하여 유연한 노드 증설이 가능하며 

각각의 모든 api 서비스는 edgeservice(zullu)-nginx와 유사한스펫 를 통해 통합된 라우팅 외부접근이 가능합니다.

그리고 이것은 리본에의해 로드 벨런스를 이용할 준비가 마쳤음을 의미합니다.


마이크로 서비스가 가야할길

Netflix에서 성공한 패턴을 Spring 에서 사용하는것으로 자세한것은 Spring Cloud Netflix 문서를 참고합니다.

DB의 트랜잭션을 포함하여 저장소 다루는 방식을 변경하고 개선하는것은 MSA의 기본목표와 무관합니다. 

마이크로서비스는 전통적인 CRUD를 사용할수도 있고 CQRS,EventSourcing등을 활용할수도 있습니다.

각각 다른 목표를 가진 마이크로서비스에서 CRUD에 이점이 있는것을 무리하게

CQRS로 통합하는것은 마이크로서비스의 본질을 망치는것일수 있습니다. 

이것은 도메인 주도 설계와 관련된 내용으로  MSA에 포함되거나 확장될수 있는 내용입니다.

이와 관련한것은 다음을 참고합니다.  마이크로 서비스에서 CQRS의 도입

또한 도메인 주도설계는 CQRS를 포함하고있고 그 자체를 의미하는것이 아니기때문에 다음 연구활동을 참고하십시오 - 도메인주도설계 연구활동


다음 저장소는 로컬 실행과 로컬 도커 실행을 일괄된 방식을 사용하여

작동이되며, 다양한 MSA를 위해 다양한 인프라이용을 위해 실험되고 있는 프로젝트입니다.

git : https://github.com/psmon/springcloud


다음목표:

  • 도커 컴포져를 통해 빌드를 그룹화하기
  • 도커를 통해 테스트 db를 마이그레이션하고 구동하는 방법
  • OverLay 네트워크 이용
  • 쿠버네틱스 이용과 클라우드 적용


  • No labels