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

사전 요구 지식:


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

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

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

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

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

도커를 위한 개발 환경

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

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

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

활용하는 방법도 있습니다. 여기서는 로컬에서 도커가 올바르게 빌드되고 배포되어 Spring의 로드밸런스를 무설정으로 사용할수 있는가? 가 촛점이기때문에 로컬에 집중을 하겠습니다.


이전에는 격리된 개발환경을 위해 별도의 물리장비가 꼭 필요하였으나, 이제는 도커의 성숙과 함께 격리된 가상 개발환경의 구축을 로컬에 먼저한후 확장을 하는 방식을 선호하고 있습니다. 

테스트및 운영환경이 로컬과 같을수 없으나, 컨테이너를 레고처럼 조립할수 최소 기반을 로컬에서 준비해둠으로 다양한 환경에 대응할수 있는것이 주요 목표입니다. 

 

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(내부) 와 같은 포워딩설정은

단일지점(내부)에서 도커내부 상태 파악하기위한 편의 용도입니다. 격리된 컨테이너 포트를 모두 포워딩할 필요는 없습니다.  


주요 도커 실행의 옵션 

  • --net : 사용할 네트워크 지정
  • --ip : 컨테이너가 실행할 아이피를 지정
  • --hostname : 자신의 hostname을 설정(일반적으로 도메인 컨셉의 영문명을 지정,내부 네이밍 서비스가 있을시 접근에 유용)
  • -p : 도커컨테이너를 , host쪽으로 port 를 오픈
  • -e : 어플리케이션이 사용할 환경변수 설정 ( 복수개 지정 가능)   


설정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툴과 통합되어 개발코드와 유기적인 상호작용도 가능합니다.

또한 모든 컨테이너를 대상으로 리모트 디버깅도 가능하게 합니다. 통합환경에서 디버깅 환경을 복잡하지 않게 사용할수 있다란것입니다. ( 별도로 다룰예정)

왜 최근 개발 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와 유사한스펙 를 통해 통합된 라우팅 외부접근이 가능합니다.

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


도커 이외에 다음과같은 컨셉이 적용되었으며, 이것은 플랫폼,클라우드와 별개로 이해가 되어야하는 컨셉들입니다. 

여기서 시도된 로컬 구동 서비스는 아래 내용을 포함하고 있습니다.


다음목표:

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


  • No labels