왜 Docker가 필요했을까

<aside> 💡 개발, 배포환경을 동일하게 맞추고 싶었다.

</aside>

우리는 개발 경험이 별로 없기 때문에... 익숙한 개발 환경을 먼저 구성하고, 개발을 진행하면서 인프라를 바꿔주는 식으로 진행되었다.

따라서, 어느정도 개발이 진행된 후에 nginx를 WS, reverse-proxy로 사용하는 배포 환경을 구성했다. 그 이후에 로그인 기능을 개발하면서 JWT를 session storage에서 cookie에 담기로 변경이 이루어졌다. 이 때 처음 겪어보는 samesite규정을 만나면서 CRA를 https로 실행하고, fetch의 옵션을 조절하면서 해결할 수 있었지만... 개발 환경도 배포 환경과 똑같이 nginx를 사용하는 식으로 환경을 맞추고 싶었다.

<aside> 💡 모두가 따로 nginx를 따로 구동해주는 것보다 한번 설정해놓으면 누구나 동일한 환경으로 실행되게 하고싶었다.

</aside>

Docker?

<aside> 💡 docker란 container라는 가상 환경에 실행되는 프로세스를 실행하도록 해준다.

</aside>

여기서 VM과 비슷한 기술이라고 생각할 수 있지만, 차이점이 명확하다.

1. VM은 HW를 SW적으로 emulating하여 새로운 HW환경을 SW적으로 만들지만,

   docker는 그저 process를 독립된 file system안에서 실행되게 할 뿐이다.

2. docker는 새로운 OS전부를 가상으로 만들지 않는다.

따라서, VM보다 적은 overhaed를 가지고 독립된 실행환경을 보장받을 수 있다.

기본 개념

• Container: 실제로 실행되고 있는 docker 프로세스이다.

  • ☝️ contatiner는 외부(local machine)와 격리되서 실행된다.
  • ☝️ container에 접근하는건 ssh와같은 network작업이 아니라, container내의 프로그램을 구동한다.

• image: container를 만들 수 있는 docker 틀이라고 생각할 수 있다.

  • ☝️ docker는 개발자에게 익숙한 git과 같은 VCS의 컨셉을 따른다. 따라서, image를 하나의 commit으로 생각할 수 있다.

    실제로 docker의 명령어들은 commit, push, pull과같은 명령어를 사용하고 명령어들의 동작도 우리의 예상과 비슷하다.

  • ☝️ 같은 image라면 어떤 환경에서도 무조건 똑같은 실행환경을 보장한다.

    혼동되는 개념으로 DockerFile이 있다. DockerFile은 image를 build하고, container를 생성할 수 있는 text파일이다. 어떻게 보면 image와 비슷해보이지만 Dockerfile이 같다고 어떤 환경에서든 완전히 같은 실행환경을 보장하진 않는다고 한다.

• Dockerfile: image를 만들 수 있는 docker 틀이라고 생각할 수 있다.

  docker의 image를 만드는 방법은 크게 2가지가 있다. 이미 만들어진 이미지를 docker hub에서 가져오기, Dockerfile을 통해서 build하는 방법이다.

  • ☝️ 대부분 이미 만들어져 있는 image를 통해서 원하는 기능을 덧붙이는 방식으로 Dockerfile을 만들게 된다.

    docker hub에는 정식으로 등록된 image, 개발자들이 만들어 공개한 image들이 있다.

Docker Compose