도커에 대해서는 간간히 사용해 보았지만 쿠버네티스는 들어만 보았지 실제로 사용해 본적이 없어서 쿠버네티스 설치부터 배포까지 예시를 작성한다. 테스트하는 OS는 Mac-bigsur에서 테스트 한다.
쿠버네티스 설치
도커 설치 (Homebrew로 Mac에 도커 설치하기)
brew install --cask docker # 참고 사이트에서 알려주는 brew cask install docker 는 예전방식이라서 제대로 동작하지 않음
brew cask(GUI용 brew)로 설치해야 Docker Desktop On Mac 도커를 설치해주며, docker-compose, docker-machine을 같이 설치해준다. 쿠버네티스 설치시 해당 도커앱에 추가로 설치를 하는 것이므로 해당 방식으로 설치하자
우측 상단에 고래 모양 아이콘이 표시되면 정상 설치
쿠버네티스 추가 (쿠버네티스 배포하기)
정상적으로 Docker Desktop On Mac을 설치하였다면, 쿠버네티스는 설정에서 체크하는것만으로 설치를 할 수 있다.
도커 앱 -> 환경설정 -> 쿠버네티스 -> 쿠버네티스 활성화 체크를 하면 꽤 오래기다리면 성공적으로 동작함을 알 수있다.
쿠버네티스 정상 구동 확인하기
$kubectl cluster-info Kubernetes master is running at https://kubernetes.docker.internal:6443 KubeDNS is running at https://kubernetes.docker.internal:6443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy
쿠버네티스 정보 확인하기
$kubectl get all
쿠버네티스 Dashboard 구동하기
Dashboard 설치
대시보드 설치는 미리 원격지에 정의되어 있는 kubernetes-dashboard.yaml 설정 파일을 통해 설치가 가능. 쿠버네티스 특정 이미지들을 올리는 작업이 있다.
$kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.0.0-beta1/aio/deploy/recommended.yaml
Dashboard Proxy 실행 (기본 포트 8001)
$kubectl proxy
Dashboard Proxy 접근
Dashboard Proxy Token 추출
여기서는 Token값을 추출하여 접속하는 방식으로 한다. 해당 명령어로 Token값을 추출하고, 복사하여 접속한다.
$kubectl -n kube-system describe secret $(kubectl -n kube-system get secret | grep admin-user | awk '{print $1}')
접속화면
쿠버네티스 배포하기
샘플프로젝트 정보
- Build tool : gradle 5.6.4
- Test url : http://localhost:8080/api ( return "ok" )
- Framework : Spring Boot 2.1.6.RELEASE
Dockerfile 작성
FROM adoptopenjdk/openjdk11:alpine-jre
VOLUME /tmp
ARG JAR_FILE=build/libs/*.war
COPY ${JAR_FILE} app.war
ENTRYPOINT ["java", "-Djava.security.egd=file:/dev/./urandom","-jar","/app.war"]FROM adoptopenjdk/openjdk11:alpine-jre
OS의 용량문제때문에 최소한의 용량만을 가지고 있는 alpine(알파인)을 베이스 이미지로 지정했으며 Java Version 11로 버전이 명시되어 있다. 마지막으로 jar나 war형태로 배포를 할 것이므로 jdk가 아닌 jre로 명시하였다.
ARG JAR_FILE=build/libs/*.war
COPY ${JAR_FILE} app.war
${프로젝트위치}/build/libs의 모든 war파일을 대상으로 지정하였다.
war파일을 app.war로 복사하여 이름을 명확히 명시한다.
ENTRYPOINT ["java", "-Djava.security.egd=file:/dev/./urandom","-jar","/app.war"]
docker가 실행되고 나서 수행되어야 하는 명령을 작성한다. 여기서 java.security.egd에 대해서 -D옵션을 주었는데 몰라서 찾아보니 다음과 같다.
/dev/./urandom을 사용하는 이유
스프링 부트를 이용해서 웹 애플리케이션을 만들 때, 기본적으로 톰캣을 이용하게 됩니다.
이 톰캣은 자바의 SecureRandom 클래스를 사용해서, 세션 아이디 같은 것을 생성하게 됩니다.
리눅스(linux) 환경의 경우, SecureRandom 클래스는 안전한 난수 생성을 위해서 /dev/random을 사용합니다.
/dev/random 경우 엔트로피 풀에 필요한 크기 만큼의 데이터가 부족할 경우, 블록킹(blocking) 상태로 대기하게 됩니다. 이런 경우 애플리케이션이 행(hang)에 걸린것 처럼 멈처버리는 현상이 발생합니다.
이 문제를 해결하기 위해서 /dev/urandom을 사용한 것입니다.
왜 /dev/urandom이 아니라 /dev/./urandom을 사용했을까요? 그 이유는 자바 버그로 인해서 입니다.
Java5 이휴의 특정 버전에서는 /dev/urandom을 설정하면, /dev/random로 인식해 버리는 버그가 있습니다.프로젝트 build
#war 파일 생성 $./gradlew clean build
Docker build & check
#build docker build -t [도커허브ID]/[프로젝트명] . #check docker images
Docker login & push
#login docker login #push docker [도커허브ID]/[프로젝트명]
Dockerhub에 정상적으로 이미지가 push되었는지 확인
쿠버네티스 배포파일(deployment.yaml 파일 생성)
다음 3가지 명령어로 deployment.yaml의 내용을 채운다
deployment.yaml
$kubectl create deployment [프로젝트명] --image=[도커허브ID]/[프로젝트명] --dry-run=client -o=yaml > deployment.yaml $echo --- >> deployment.yaml $kubectl create service clusterip [프로젝트명] --tcp=8080:8080 --dry-run=client -o=yaml >> deployment.yaml
쿠버네티스 배포 및 확인
#deploy $kubectl apply -f deployment.yaml #check $kubectl get all | grep [프로젝트명]
쿠버네티스 Dashboard 로그 확인
화면에서 Pods부분의 오른쪽 영역메뉴 -> Logs를 통해 정상적으로 배포 및 war가 올라갔는지 확인 할 수 있다.
외부 http 포트포워딩
$kubectl port-forward svc/example 8080:8080 #daemon print Forwarding from 127.0.0.1:8080 -> 8080 Forwarding from [::1]:8080 -> 8080 #connect Handling connection for 8080 Handling connection for 8080
마치며
실제 이방식이 실무방식은 아니라고 한다. 여러가지 규칙이 있고 자동화가 되어있을듯 하다. 처음들어보는 용어도 있고 도커가 무엇인지는 아는데 쿠버네티스를 한번도 경험해보지 않는 사람들에게 예시로 한번쯤 따라해볼만 한것 같다.
