Docker 학습

docker_study.txt

Docker 를 공부하면서 기억해둘만한 것들을 메모해둔다.



1. Container와 Image 개념이 핵심. 찾아보면 많이 나온다

- 좀 쉽게 생각하면, Image는 설치된 프로그램, Container 는 실행한 프로그램 정도의 개념으로 생각하면 된다.

- docker는 격리된 환경이니 처음 공부할때 Image든 Container든 맘대로 올렸다 지웠다 하면서 연습해보면 된다. 쫄지 말자.

 

2. Docker Hub : Image Repository 개념이다 (npm같은). 

- Github 도 Github Packages 를 만들어서, 자체적인 docker image repository 서비스를 제공하기 시작했다.

- https://docs.github.com/ko/actions/use-cases-and-examples/publishing-packages/publishing-docker-images

- 다만 아직 국룰은 Docker Hub 인 듯하다. 



3. Docker Compose 가 V1 에서 V2로 바뀌면서 파일 명이나 작성법이 조금 바뀌었다.

https://docs.docker.com/compose/intro/history/

docker-compose.yml 은 V1 방식이고, compose.yml 이 V2 방식이니까 참고하자..

v1에서는 상단에 version 명시가 필수였는데 v2에서는 이게 optional 이어서 없어도 된다.



4. Dockerfile 과 compose.yml 의 차이를 이해해야 한다

- Dockerfile : Docker Image 생성 (build) 할 때 실행하는 command sequence

	- https://docs.docker.com/build/concepts/dockerfile/

- compose.yml : Docker Container 를 어떻게 올릴지 (start) 를 명시해놓은 설정 파일

	- https://docs.docker.com/compose/intro/compose-application-model/

	- docker run, start 처럼 개별로 container 를 실행하던 것을, 
	  compose.yml 에 configuration 을 다 작성해두고, docker compose up 으로 간소화 시킬 수 있다.

	- compose 는 여러개의 container를 명시할 수 있는데, 이를 service 라고 한다

	- 이렇게 compose 파일에 의해서 묶인 container 집합을, "project" 라고 부른다

	- https://docs.docker.com/compose/how-tos/project-name/
  
  - compose 에 의해서 구동된 container들은, container-name 앞에 project-name 이 prefix로 붙는다.
  
(주의) Dockerfile 과 compose.yml 은 완전 별개의 설정파일이 아니다. (뭔소리...?)

- compose 파일에서 Dockerfile에 정의한 stage 를 읽어서 build.target 으로 참조 할 수 있다. 

	- https://docs.docker.com/get-started/introduction/develop-with-containers/ 
	- https://github.com/docker/getting-started-todo-app  이 예제에 있는 compose.yml, Dockerfile 참고


5. 영속성을 유지하고 싶다면, Volumn 을 쓰면 된다 (DB 파일을 Host 컴퓨터에 보관) 

- 즉 volume에 데이터를 저장해놓으면, container를 죽였다가 새로 올려도 데이터가 유지된다.

- https://docs.docker.com/engine/storage/volumes/



6. 명령어를 많이 작성하고, compose, build 를 자꾸 해보면서 머릿속에 개념을 탑재시키는 것이 좋다

- 인프런의 박재성 님의 docker 강좌 (비전공자도 이해할 수 있는 Docker 입문/실전) 에 쉽게 설명이 잘 되어 있다

- https://www.inflearn.com/course/%EB%B9%84%EC%A0%84%EA%B3%B5%EC%9E%90-docker-%EC%9E%85%EB%AC%B8-%EC%8B%A4%EC%A0%84



7. 로컬에서 개발할 때, Docker 로 어디까지 개발환경을 구축해야하나

- 웹 개발을 하려면, DB (main db, cache db), 각종 service (MQ, Eureka 같은..) 를 셋팅한다음
  backend application, frontend application 을 실행 해야한다
  
- 회사에서 진행하는 프로젝트여서, 공용 개발서버에 저런 service 들을 띄워놓은 다음, 로컬에서 저걸 바라보게 하면 별 문제 없지만

- 혼자 진행하는 프로젝트에서는 별도의 개발서버를 두고 작업하는 것이 아니니, 저런 것들을 일일이 다 띄워야 하는 번거로움이 있는데, 당연히 docker 를 쓰면 많이 편해질 것이다. 

- 근데 docker 공홈에 있는 예제를 보면 
 (위에서 언급한 예제, https://docs.docker.com/get-started/introduction/develop-with-containers/ )

 이 예제는 docker container에 mysql, phpmyadmin 뿐만 아니라, 
 
 backend, frontend application 까지 container 로 실행을 시킨다.

- 그럼 개발자는 본인의 host 영역에 있는 소스를 수정한다음 docker container에 반영을 해야하는데 이를 우째하냐? 

- 예제에서는, "docker compose watch" 를 통해서, container를 올리는데, compose.yml 파일에 action: sync 라는 설정이 있어서, host 에서 편집된 소스코드 수정사항을, container에 그대로 동기화 시키게 된다. 

- 따라서 host의 소스 수정 -> container 의 소스 동기화 반영 -> container에서 HMR 을 통해서 갱신 -> 갱신된 application이 보여집니다 짜잔! 이렇게 예시를 만들어 놓았다.

- 음... 별로 좋지 않은 예시같다. 소스 수정을 단순히 한두줄 하는게 아니라 대규모 refactoring 할때도 있고, 상황에 따라서 잠깐 컴파일이 안되는 상태로 방치할때도 있는데, 이렇게 watch 를 무작정 켜놓으면 불필요한 컴퓨터 리소스 낭비의 원인이 될 것이다. 

- 백, 프론트 application 은 host 로컬에서 구동하되, 그 외의 것들은 docker compose 로 모아서 깔끔하게 한큐에 올려놓는게, best practice 인 것 같다. 

- 다만 배포단계에서는, build 된 image 파일을 docker 를 통해서 배포 서버에 올리는 것이 깔끔할 것이다.