Docker image 빌드

기존의 로컬 환경은 docker-compose를 이용하여 서버를 실행하였고 로컬과 볼륨을 공유하여 개발을 한다는 특징이 있다. 이러한 개발환경은 다음과 같은 장점을 지닌다.

• 로컬의 IDE를 활용하여 변경한 사항이 생기게 되면 docker에서 실행되고 있는 서버가 이를 감지하고 새롭게 빌드를 하게된다.
• 기존의 파일을 볼륨이 아닌 docker의 COPY나 ADD를 사용할 경우에 이미지에 이미 내용이 고정되어 있다보니 개발하는 코드가 효율적으로 반영되기가 어렵다.

하지만 위의 상황을 하게되면 kubernetes를 이용한 배포과정에서 다음과 같은 발생하게 된다.

1. 볼륨을 이용해서 Pod을 만들어야 하는데 이는 Pod이 존재하는 cluster내에 추가적인 volume을 연결해야한다는 단점이 있다.
2. 볼륨 사용에 대한 미숙함...

로컬에 있는 docker container 사용하기

minikube에서 local에 존재하는 container를 사용하기 위해서 추가적인 작업이 필요하다.

• eval $(minikube docker-env)
• docker build .

→ 위의 두 과정을 거치면 빌드된 이미지를 minikube의 yaml에서 사용이 가능하다.

단, 이미 빌드가 된 상태의 docker image를 가져오는 것이 아닌 minikube 환경이 동작하는 상태에서 docker로 빌드한 이미지가 minikube가 인지할 수 있는 이미지 환경에 등록이 되는 것이다.

로컬환경에서의 배포 구조이다. elasticsearch의 경우는 제거를 한 상황이다.

결론

개발 환경의 경우는 docker-compose를 이용한 환경이 개발 상황에서는 가장 접합한 것으로 판단하였다. 그 이유는 다음과 같았다.

1. ⭐효율적인 IDE를 사용하면서 docker 환경의 즉각적인 변화
2. 손쉬운 설치(docker와 docker-compose만 설치하면 빌드가 된다.)
3. 손쉬운 문법 → kubernetes와 같은 복잡한 구조가 필요하지 않다.