내가 받은 프로젝트에 RUNNING_ENV 가 세가지가있었다. local, nonprod, production.
기존에 하던 프로젝트는 로컬로 돌리면 소스단까지 바로 접근이가능했고, dev 환경과 production 과 동일한 환경인 staging(sandbox 라고 생각하면된다), 그리고 production 이 있었기때문에,
nonprod환경은 dev 환경이고, local은 말그대로 로컬 렙탑에서 돌리면 되는것이라고 생각했었는데, 이해가 안되는 부분이 있었다.
우리회사는 dev 환경 온프로미스 클라우드가 있다.
(온프레미스(On-premise) – 소프트웨어 등 솔루션을 클라우드 같이 원격 환경이 아닌 자체적으로 보유한 전산실 서버에 직접 설치해 운영하는 방식. 온프레미스는 클라우드 컴퓨팅 기술이 나오기 전까지 기업 인프라 구축의 일반적인 방식이었고 이전 또는 전통적인 이라는 단어와 함께 사용된다. 그런데 우리회사는 일단 ‘on-premise cloud’를 가지고있음.사내 방화벽 내의 기업 데이터센터에서 기존에 투자한 IT장비(자산)를 활용하면서 보안을 강화하고, 퍼블릭 클라우드의 장점에 과금 모델을 접목된 형태)
암튼, local.yaml 도 있고 nonprod.yaml 도 있기에 이것과 디버깅과 어떻게 연관해서 사용할수있는가..어떤걸로 디버깅을 할수있는가. 했는데 잘생각해보면..
결국 각 서비스들을 프로세스로 올리고 카프카도 이미지 도커로 올리고.. 이 모든걸 로컬호스트로 동작시키려고 생각해보면 사람이 다 그건 하나하나 프로세스 올리고 포트 모두 포워딩 해주고 포트를 변경해주고 등등… 너무 복잡하다. 그래서 도커 컴포즈를 쓰는것.
(도커 컴포즈 – 여기에 마무리 해서 쓰려고 했는데 다른 포스트로..)
대부분은 도커를 운영하는 사람들은 도커컴포즈를 쓰곤하는데 회사에서 사용하는 경우 쿠버네티스로 고래(컴퓨터 노드) 여러개를 오케스트레이션을 해서 컨테이너를 서비스한다. 근데 로컬 셋팅을 하려면.. 로컬은 한대이지만 쿠버네티스처럼 동작할수있도록 미니큐브로 잘 만들어졌다.
로컬에서 틸트로, 셋팅을 쫙되게 해준다음에 nonprod config yaml 을 읽으면 컨테이너 환경을 바라보게 한것이다.
Stop playing 20 questions with kubectl each time your app misbehaves. Tilt collects problems from across tools and services into one UI. One place to see build breakages, yaml typos, crash loops, and request exceptions.
https://tilt.dev/
암튼 로컬에서 틸트라는 도구를 사용해서 미니큐브로 쿠버네틱스를 구현했으니 미니큐브에 대해서 모르고 넘어갈순 없지.
그래서 미니큐브란
Minikube is a tool that makes it easy to run Kubernetes locally. Minikube runs a single-node Kubernetes cluster inside a Virtual Machine (VM) on your laptop for users looking to try out Kubernetes or develop with it day-to-day.
https://kubernetes.io/docs/setup/learning-environment/minikube/
친절한 Kubernetes의 실서비스 도입 전 미리 (조그맣게)사용해 볼 수 있는 Minikube(Mini Kubernetes)를 지원하는 것이다.
당연히 Docker for mac 는 깔려있어야한다.
MiniKube는 Kubernetes VM을 관리하기위해 Docker Machine을 사용한다. Docker Machine을 사용하기 때문에 다양한 VM providers를 일관되게 관리할 수 있다는 이점이 있다. Minikube는 VirtualBox와 VMware Fusion drivers는 내장하고 있어 사용을 지원하지만, 다른 드라이버들은 별도의 설정이 필요하다.
하지만 나는 별도의 포트 설정이나 DNS 설정은 하지 않아도 되었기 때문에 hyperKit 은 별도로 설치해주지 않았다.
Kubernetes의 클러스터들과의 상호작용을 하기위해 kubectl(Kubernetes Command-Line Tool)을 설치한다.
쿠버네티스(특히 미니큐브) 에 대해서는 공식 홈페이지가 정말 설명이 잘되어있는 느낌이다.
(https://kubernetes.io/docs/setup/learning-environment/minikube/)
오픈소스와 함께 사는 개발자로써 자바 환경에서 개발을 시작할때의 그 막막함에 답답함을 느꼈던 이후에 msdn의 감사함이 항상 마음속 깊은곳에 자리하고있었는데 쿠버네티스는 조금 다른 느낌이랄까.
미니큐브는 아주 간단하게 실행할수 있지만( minikube start ) 사실상 이 커멘드는 kubectl context 를 생성하는것이다. 이것이 미니큐브 인것이고.. 이 컨텍스트(문맥 – 한글로는 참 답답한 단어매칭이다..) 는 나의 미니큐브 클러스터와 소통할수있는 컨피규레이션을 포함하고있다.( This context contains the configuration to communicate with your Minikube cluster. – 답답함에 이해를 돕기위한 원문추가)
미니큐브는 기본설정이 자동으로 되지만 만약에 뭔가 변경이 되는것이 필요하다 싶으면
$ kubectl config use-context minikube
(kubectl get pods --context=minikube)
use-context 명령어는 클러스터 변경시 사용.
이렇게 설정 할수 있다.
미니큐브는 사용하면서 엄청 섬세하게 무엇인가를 다루지는 않아(못해) 봤고
미니큐브에는 몇개의 addon 이 있다. 그 에드온 중에 하나가 대시보드(dashboard)이다.
Addon 소개
Dashboard : Kubernetes 클러스터 또는 클러스터에서 실행중인 프로그램들을 웹 UI 관리페이지
Heapster : Metrics-server 와 같은 타사의 메트릭 파이프 라인을 사용하라고 함.
Registry : ImagePullSecrets으로 Kubernetes 클러스터 내에서 레지스트리 자격 증명을 새로고침 가능 .
CoreDNS : 표준 Kube-DNS 대신 CoreDNS를 실행.
Ingress : Kubernetes Ingress 리소스를 기반으로 구축 된 NGINX 컨트롤러.
freshpod : 이미지가 업데이트 될 때 컨테이너를 자동으로 다시 시작.