도커

도커 기초편 (1) Why Docker

jamie-lee 2023. 6. 25. 15:15

들어가기 전에


포스팅 소개 및 사설

코드와트 프로젝트를 진행하면서 배포 프로세스가 비효율적이라는 문제는 인지하고 있었지만, 다른 것들의 우선순위에 밀려 손을 못 대고 있었다. 어느 정도 여유가 생긴 지금 어차피 공부도 해야할 겸 손보기 딱 좋은 타이밍이라고 생각이 들었다. 또한 AWS, 도커, 컨테이너 기반 개발 프로세스를 배우고 싶다는 흥미도 있었다. 마침 네이버 부스트코스의 코칭 스터디를 통해 얻은 쿠폰으로 모두의연구소 풀잎스쿨 스터디에 참여할 수 있는 기회가 생겼고, 마침 운 좋게도 쿠버네티스에 관해 공부하는 스터디 그룹이 개설되어 참여 중이다. 더더욱 운이 좋게도 내가 제일 관심이 있었던 “도커 기초편” 세션의 발표를 내가 맡게 되었다. 그룹원들의 참여도도 좋았고 적극적인 질문도 오가고 만족스럽게 마무리한 세션이었다. 앞으로 점차 내용도 더욱 유기적으로 연결되면서 심화될 텐데 몹시 기대가 된다.

사설이 길었는데 결론은 도커의 기초적인 내용에 관해 정리한 내용을 공유하면 좋겠다는 생각에 포스팅을 작성하고자 한다는 뜻이다. 개인적으로 도커를 배우면서 기존에 내가 가지고 있던 소프트웨어 엔지니어링 지식의 지평이 한 층 넓어지지 않았나 자평한다. 프로젝트를 진행할 때는 비교적 지엽적인 부분(기능 개발)에 많이 파묻혀 있다 보니 거시적 관점에서 개발 프로세스를 조망하는 법을 배우고, 더 나아가서 최적화하고 싶다는 욕심이 있었다. 도커의 기본적인 내용을 알아보고 나니, 내가 바로 원했던 그 부분을 알아가는데 도커가 좋은 시발점임을 알게 되었다. 그러한 나의 시점에 기반하여 포스팅을 작성해나갈 예정인데 아무래도 나와 비슷한 페인 포인트를 느끼던 사람들에게 도움이 될 만한 글이 될 것 같다.

목차

다음과 같은 구성으로 나누어 포스팅할 예정.

  1. Need for Docker
    • 도커가 등장하게 된 계기, 필요성을 이야기한다
  2. 도커 이해하기
    1. 도커의 정의
    2. 컨테이너화 vs. 가상화
    3. 도커 아키텍쳐
  3. 도커 베이직
    1. 도커 설치하기
    2. 도커 이미지, 컨테이너, 도커파일
    3. 기본 도커 명령어
    4. Dockerfile 작성하기
  4. Docker in Action
    1. 간단한 도커 컨테이너 실행하기
    2. Dockerfile로 도커 이미지 빌드하기
    3. Docker Hub으로 도커 이미지 공유하기
  5. 마무리
    1. 중요 개념
    2. 참고 자료

Need for Docker (WHY Docker?)


사랑 받는 개발 툴, 도커

Pasted image 20230625154545.png[1]

위 그래프는 스택 오버플로우 2023년 서베이의 “가장 인기있는 기타 도구” 결과를 보여준다. 보시다시피 도커가 1위를 차지했다. 사실 2019년 이래로 도커는 동일 서베이에서 3위 밖으로 나간 적이 없다. 단적인 예시이긴 하지만 많은 개발자들이 도커를 사랑하고 있음을 부정하기는 어려울 것 같다.
그렇지만 개인적으로 이보다 더 흥미로운 서베이는 따로 있었다.

Pasted image 20230625160010.png[2]

이 서베이는 "어떤 기술을 사용하는 개발자와 함께 일하고 싶은가? 그리고 당신은 어떤 기술을 사용하는가?"에 관한 결과이다. 놀랍게도 "도커-도커"라고 대답을 한 개발자들이 가장 많았다. 다시 말해 "도커 기술을 사용하고 있으며 동일하게 도커 기술을 사용하는 개발자와 일하고 싶다"고 응답한 사람이 제일 많았다. 타 개발자들과의 협업 면에서도 도커를 배울 이유가 충분하다는 뜻이다.

도커는 왜 사랑받는가?

나는 도커의 인기와 선호도가 높은 것은 알겠으나, 정확히 어떤 이유로 그렇게 사랑받는지 궁금했다. 알아야 나도 더 도커를 사랑할 수 있게 되지 않을까 싶어서(?). "도커를 사용하면 편리하다"는 이야기는 이전부터 들어왔으나 도커가 어떤 문제를 해결하여 훌륭한 솔루션으로 각광받는지 궁금했다.
여러 자료를 조사하며 결론 내린 "도커가 사랑받는 이유"는 다음 두 가지로 요약할 수 있다.

  1. 도커는 “It works on my machine” 문제를 해결하며 그로 인한 비용을 절감시킨다.
  2. “지금은 컨테이너를 요구하는 시대이다”

간단한 부연설명을 하자면, 1) 도커는 개발자가 만든 프로그램이 그대로 어디서든 돌아가도록 보장해준다. 2) 또한 용량이 비교적 적고, 따라서 확장에 용이하고 배포를 편리하게 해주는데 이 점이 지금의 소프트웨어 개발 환경과 잘 들어맞는다.
이게 도대체 무슨 말인지는 아래에서 자세히 얘기하려고 한다.

도커는 어떤 툴인가?

도커가 왜 사랑받는지 알기 위해서는 간단하게나마 도커가 어떤 역할을 하는 툴인지 알아둘 필요가 있다. 그래야 그것이 해결한 문제가 이해되기 때문이다.
Pasted image 20230625161817.png[3]

우리가 웹 사이트나 웹 애플리케이션을 만들고 싶다고 가정하자. 무엇이 필요할까? 당연히 모든 웹 소프트웨어의 핵심인 소스코드가 필요하다. 하지만 이것만으로는 충분치 않다. 코드 외에도 데이터베이스, 라이브러리, 구성 파일, 그 밖의 타사 소프트웨어 등 많은 부분이 추가적으로 필요하다. 도커가 하는 일은 이 모든 부품들을 컨테이너라는 하나의 패키지로 묶는 것이다.
그런데 하나의 상자에 이 많은 것들을 묶는 것이 왜 그토록 훌륭한 아이디어인가?

“It works on my machine” 문제를 해결한다


[4]

그 이유는 하나의 상자에 그 많은 구성요소를 패키징함으로서 “It works on my machine” 시나리오를 잘 해결할 수 있기 때문이다. (구글에 "it works on my machine meme"이라고 검색하면 재밌는 밈들이 많이 나온다. 심심하면 한 번 구경해보시길.)
Pasted image 20230625163302.png[^ “내 컴퓨터에서는 잘 돼요^^ - 응 근데 네 컴퓨터를 고객한테 줄 건 아니잖아^^”]

"내 컴퓨터에서는 잘 작동해요"라는 유명한 개발자의 변명이라고 한다. 문제는 개발자의 컴퓨터에서 작동한다고 해서 서버에서도 잘 작동한다는 보장이 없다는 것이다. 라이브러리나 도구가 누락되었거나 설치된 소프트웨어의 버전이 일치하지 않을 수도 있다. 각 컴퓨터 혹은 서버는 서로 다르며 다른 방식으로 구성된다. 도커를 사용하지 않으면 각 컴퓨터와 시스템을 일일이 사람이 수동으로 설정해야 하므로, 시간 비용을 소모할 뿐더러 오류가 발생하기 쉽다.
도커는 원하는 서버(클라우드 포함) 또는 로컬 머신에서 위에서 언급한 모든 구성 요소를 패키징한 컨테이너를 실행할 수 있도록 해준다. 이는 마치 개발자의 개발 환경을 상자 안에 넣어 포장하여 그대로 배송해주는 것과 같다. 그런 의미에서 첫 번째 밈을 이해하면 된다.
컨테이너는 어디서나 동일하고 일관적이며 예측 가능한 방식으로 실행함을 보장해준다. 실행하는 각 환경에 대한 추가 구성과 설치 및 조정이 불필요하게 된다. 이 말은 곧 많은 수고와 노력, 시간 즉 비용을 절약할 수 있다는 뜻이다.

[5]

컨테이너는 개발 환경을 패키징한다. 도커를 사용하면 모든 수동 설치 및 구성 단계가 도커 컨테이너 내에서 자동으로 수행된다. 이로 인해 협업 면에서는 신규 개발자의 온보딩 작업에 걸리는 시간과 비용을 줄일 수 있다는 이점도 있다. 위 자료가 단적으로 묘사하고 있다. 기존에는 신규 개발자의 개발 환경 세팅을 위해 여러 노고와 시간이 들어간다는 것을 보여주며, 도커를 이용하면 도커 명령어로 비교적 기존보다 더 단순하게 개발 환경 세팅을 마칠 수 있다고 주장한다.
결론적으로 도커가 각광받게 된 첫 번째 이유는 "It works on my machine"으로 대표하는 개발 환경에서 자주 맞닥뜨리는 문제를 해결하며, 이로 인해 어떤 환경에서든 애플리케이션이 예측 가능하고 일관성 있게 동작하도록 보장해준다는 점 때문이다.

“지금은 컨테이너를 요구하는 시대이다”[6]

위 주장은 나로부터 나온 것은 아니고, 자료 조사를 하며 유튜브의 도커 강좌인 “따라하며 배우는 도커” 시리즈에서 발췌했다. 내포하는 바는 지금의 소프트웨어 개발 환경에 컨테이너가 잘 들어맞는다는 뜻이다. 이에 대해 알아보기 위해 마이크로서비스 아키텍쳐(MSA) 와 DevOPs가 중요해진 이유를 먼저 언급하려고 한다.
도커가 애플리케이션을 격리하여 배포할 수 있게 해주고 그로 인해 개발 환경 불일치에서 오는 불편함과 비용을 줄여준다는 사실을 이해했는가? 두 번째 도커가 사랑받는 이유는 어떻게 보면 보다 더 재밌을 수 있는 내용이다.

마이크로서비스 아키텍쳐와 도커

[7]

마이크로서비스 아키텍쳐란 서비스를 특정 비즈니스 기능 별로 작게 쪼개는 서버 아키텍쳐의 디자인 패턴을 말한다. 이와 반대되는 개념으로 모든 비즈니스 기능을 합쳐서 개발하는 모놀리식 아키텍쳐가 있다.
마이크로서비스 아키텍쳐의 각각의 비즈니스 기능은 독립적으로 개발, 배포 및 확장된다(단일 책임 원칙). 그리고 각각의 비즈니스 기능은 RestAPI 등을 통해 서로 통신한다. 예를 들어 전자상거래 애플리케이션의 경우 사용자 관리, 제품 카탈로그, 장바구니, 결제 등을 위한 별도의 마이크로서비스가 있을 수 있다. 또한 서로 독립적으로 배포할 수 있으므로 이를 통해 다른 서비스에 영향을 주지 않고 한 서비스만 업데이트, 수정, 또는 확장시킬 수 있다.(민첩성, 확장성). 이미지를 보면 데이터베이스마저 각 마이크로서비스가 자체적으로 가지고 있는 것을 볼 수 있다(분산형 데이터 관리). 분리되어 있으므로 하나의 마이크로서비스에 장애가 발생해도 다른 서비스의 기능에는 영향을 받지 않는다(장애의 격리). 그리고 마이크로서비스는 다양한 프로그래밍 언어와 기술을 독립적으로 사용할 수 있다. 따라서 서비스 요구사항에 가장 적합한 것을 기반으로 개발할 수 있게 된다(기술의 자유).
[8]

요약하면 MSA 아키텍쳐를 취함으로써 유연한 개발을 할 수 있고, 확장이 용이해지며, 마켓에 내놓는 시간이 단축시킬 수 있다. 이는 빠르게 바뀌는 소비자의 요구와 기대에 적합하다. 하지만 MSA가 가지는 한계도 있는데 그 중 직관적으로 이해할 수 있는 한 가지: 복잡하다는 점이다. 이는 모놀리식 아키텍쳐와 MSA를 비교하는 이미지만 보아도 바로 느낄 수 있다. 여러 마이크로서비스를 관리하고, 배포하고, 모니터링하는 일은 확실히 챌린지이다. 이러한 복잡해진 개발-프로세스 과정을 효율적으로 관리해야 할 필요성이 생겨났고 그에 따라 DevOps의 중요도도 높아졌음을 짐작할 수 있다.


[9]
이러한 맥락에서 위에서 언급한 컨테이너가 가지는 특성, 즉, 애플리케이션을 격리하여 일관성 있게 배포할 수 있다는 점, 그리고 추후에 자세히 이야기할 테지만 비교적 용량이 적고 가볍기 때문에 빠르다는 장점은 마이크로서비스 아키텍쳐와 잘 들어맞는다. 각 마이크로서비스는 자체 도커 컨테이너 하에서 실행되며 컨테이너의 가볍고 빠르다는 장점 덕분에 마이크로서비스를 더 효율적으로 확장하고 업데이트 할 수 있게 된다. 결론적으로 도커는 DevOps의 중요한 구성 요소가 되었다. 이러니 "지금은 컨테이너를 요구하는 시대이다"라는 말도 나오게 된 것이다.

이상으로 본 포스팅에서는 왜 도커를 배워야하는지, 도커의 필요성에 대해 자세히 알아보았다. 개인적으로 조사하면서 흥미로웠던 파트다. 도커가 우리에게 무엇을 가져다주었는지 배웠다면, 다음 포스팅에서는 도커를 본격적으로 사용하기 전에 꼭 알아두어야 할 중요한 기초 개념들을 소개할 예정이다.


  1. Stack Overflow Developer Survey 2023 ↩︎

  2. Stack Overflow Developer Survey 2023 ↩︎

  3. What is Docker and why to use it? Explained for executives. | Accesto Blog ↩︎

  4. The Hitchhiker’s Guide to the Containers: A Foolproof, Hands-on Docker Tutorial (Part 1) (antoniolofiego.com) ↩︎

  5. What is Docker and why to use it? Explained for executives. | Accesto Blog ↩︎

  6. 따배도 도커 시리즈 - YouTubue ↩︎

  7. Why You Should Use Containerized Microservices When Deploying Your Data Science Application | LaptrinhX ↩︎

  8. 모놀리식 아키텍쳐 vs. 마이크로서비스 아키텍쳐 Strangling The Monolith: Microservices And The Future Of Software Architecture - Volition (volitioncapital.com) ↩︎

  9. 컨테이너화 된 마이크로서비스 아키텍쳐 Why You Should Use Containerized Microservices When Deploying Your Data Science Application | LaptrinhX ↩︎