[Docker]1. Intro[도커 기초 | Week1]

목차

1-1 강의 소개

1-2 도커 기초 파트 소개

1-3 컨테이너 기초

2-1 도커는 00이다

2-2 클라우드와 마이그레이션

2-3 컨테이너와 MSA

2-4 도커의 역할

---

1-1 강의 소개

도커는 우리가 아는 대부분의 응용프로그램을 말한다.

이 응용프로그램이 실행되는 플랫폼을 말한다.

 

우리는 보통 운영 프로그램이라고 하면

윈도우다 리눅스다 맥이다 라고 얘기하는데,

쿠버 네티스는 이것들을 좀 더 숲의 관점에서 멀리 바라보는 것인데요

이 도커 컨테이너들을  관리하고 운영하고 배포하고 롤백하고,

이런 것들을 대응하는 게 바로 '쿠버네티스' 입니다

 

이 도커와 쿠버네티스는 

여러분들 디버깅할 때 항상 사용하는 사이트인

stack overflow에서 'Most Wanted Platform' 설문조사를 했는데

1등이 '도커'였고 3등이 '쿠버네티스' 였습니다.

 

그만큼 지금 이 시대에서 가장 핫한 수업이고

꼭 알아야 하는 수업이기 때문에 여러분들 끝까지 완주하시고

한 글자 한 글자 놓치지 마시고  

개발자로서 한 단계 위로 올라갈 수 있는 이 기회,

꼭 살리시길 바랍니다.

---

1-2 도커 기초 파트 소개

1. Docker 컨테이너와 도커

 

컨테이너의 개념과 도커의 역할, MSA의 역할 설계

그리고 왜 개발자가 도커를 알아야 하는지 살펴보겠습니다.

 

2. 도커 엔진

 

도커는 OS에 구애받지 않고 모두 운용이 가능합니다.

가장 흔하게 사용되는 윈도우 환경뿐만 아니라

맥, 리눅스 등의 운영체제를 모두 지원하고 있습니다.

 

3. 도커 컨테이너 운용

 

도커에서 애플리케이션을 실행하기 위해서는 컨테이너가 필요합니다.

컨테이너를 직접 실행/정지/삭제해보면서

작동원리를 이해하고 명령어를 익히는 시간을 가집니다.

 

4. 도커 이미지

 

컨테이너를 실행하려면 구축할 환경

애플리케이션에 대한 정보가 담겨 있는 이미지가 필요합니다.

프로그램을 실행할 때 CD가 필요한 것과 같은 맥락이라고 보시면 됩니다.

 

5. DockerFile

 

이미지를 생성하기 위해서는 DockerFile이 필요합니다.

어떤 이미지를 베이스로 사용할지, 포트는 어떻게 설정할지 등

다양한 내용을 담고 있습니다.

 

6. 도커 볼륨과 네트워크

 

도커를 통해서 스토리지인 볼륨과 가상 네트워크를 구축할 수 있습니다.

서비스 환경에 맞게 이 둘을 구성하는 것이 매우 중요한데

도커는 이를 손쉽게 세팅할 수 있도록 돕습니다.

 

7. 도커 레지스트리

 

이미지는 한 번 생성하고 증발하는 것이 아니라

레지스트리에 올려 언제든 다시 사용할 수 있도록 저장할 수 있습니다.

 

도커 허브라고 하는 기본 레지스트리 외에도

사설 레지스트리를 자체 구축하여 사용할 수 있습니다.

 

8. 도커로 Apache 웹서버 구축하기

 

앞에서 학습했던 내용을 바탕으로 컨테이너에 웹서버를 직접 띄어보는

실습을 해봄으로써 작동하는 원리를 이해할 수 있습니다.

 

9. Docker Compose

 

서비스는 단일 애플리케이션으로 구성되어 있지 않고

여러 애플리케이션이 기능적으로 결합되어 있습니다.

 

도커에서는 Docker Compose라는 플랫폼을 통해

멀티 컨테이너 환경을 지원하죠.

우리는 이 Docker Compose를 어떻게 활용해야 하는지에 대해서 배워봅니다.

 

10. 도커로 API 구축하기

 

일반적으로 API를 구축하기 위해서는 

사용자의 요청을 받아 처리하는 웹서버와

데이터를 관리하는 DB서버가 필요합니다.

 

Docker Compose와 FastAPI, Postgresql를 사용하여 API를 구축합니다.

 

---

1-3 컨테이너 기초

 

이번 강의에서 컨테이너가 무엇인지,

왜 필요한지 함께 배워보도록 하겠습니다.

 

우선 컨테이너는 기본적으로 해운 업계에서 사용하는 용어인데요.

해운 업계에서 다양한 종류의 화물을 

어떻게 하면 효율적으로 운반할 수 없을까를 고민하다가 

 

표준화된 컨테이너 박스를 만들게 되었습니다.

컨테이너 박스가 표준화되어 있으니

어떤 물건을 담더라도 표준화된 운송선만 있으면

여러 개의 화물들을 효율적으로 운반할 수 있게 된 것이죠.

 

 

이러한 개념이 프로그래밍 세계에서도 적용되는데요.

 

기업에서 어떤 서비스를 운영한다고 했을 때

하나의 환경에서 모든 서비스가 돌아가는 것이 아니라

기능별로 나누어서

여러 기능을 가진 애플리케이션이 결합되어 작동하게 되는데요.

 

이렇게 다양한 기능별 애플리케이션을 효과적으로 제어하기 위해서

컨테이너라는 개념이 등장하게 됩니다.

즉, 애플리케이션이 동작하기 위해 필요한 각종 요소들을 

표준화된 방식으로 묶어서

돌아갈 수 있도록 하는 구조를 컨테이너라고 합니다.

 

이렇게 컨테이너 단위로 묶게 되면 하나의 컴퓨팅 환경 안에서도

여러 개의 애플리케이션을 효율적으로 나누어서 관리할 수 있게 됩니다.

 

이렇게 보시면 가상 머신의 개념과 유사하다고 생각하실 수 있는데요.

가상 머신은 하나의 OS 위에 별도의 OS를 새롭게 올려서

속도가 느려지지만 

컨테이너는 하나의 운영체제를 논리적인 구획으로 구분하여 사용하는 것으로

OS를 추가로 실행하는 것이 아니기 때문에

그 속도가 조금 더 빠릅니다.

 

---

2-1 도커는 00이다

현업에서 업무를 하고 계시는 개발자뿐만 아니라

다양한 직무에 있는 분들이 도커에 대해서 큰 관심을 가지고 계시죠?

하지만 책이나 공식 문서로는 해소되지 않는 가려운 부분이 분명히 있을 것으로 생각됩니다.

 

이 강의의 목표는 컨테이너의 핵심적인 개념을 이해하고 

도커라는 플랫폼을 효과적으로 습득하는 것입니다.

앞으로는 주변 사람들에게 도커는 00을 하기 위한 플랫폼이야 라고 

당당하게 말할 수 있게 되실 거예요.

 

그럼 본격적으로 강의의 시작해보겠습니다.

 

앞선 인트로 강의에서 이두희 님 조 코딩님께서

컨테이너의 개념을 알게 쉽게 설명을 하셨죠. 

우리는 도커가 등장하게 된 배경과 역사에 대해서 잠시 알고 가겠습니다.

 

여기에 서버가 한 대 있습니다. 기본적으로 서비스를 구축하려면

서버가 필요하죠? 서버에서 실행되는 것들은 아주 무궁무진합니다.

흔히 오라클이나 mySql 같은 관계형 db를 많이 사용하죠?

 

스토리지, 이메일, 웹 서버(서버 중의 많이 이용되는 NGINX의 로고) 등

 

셀 수도 없이 많은데, 서비스가 고도화될수록 서버 한 대로는 

원활한 이용이 불가능합니다.

 

그러면 증설을 하게 되는데, 또 증설을 하게 되고

서비스가 일정 이상의 유저를 확보하게 되면 관리해야 할 서버가

기하급수적으로 늘어나게 됩니다. 이 서버들을 효율적으로 관리하기 위해

VM이 등장하게 됩니다.

 

가상 머신이라고 하는데, 가장 서버를 효율적으로

운영하기 위해 대안으로 나온 것인데, 서버의 상태, 의존성이라던지 

환경을 스냅샷으로 관리할 수 있고 물리적인 영역을 분리할 수 있기 때문인데,

 

물리적인 영역이라면 (보통 IP), 이런 부분이 장점이 있으며

설치가 쉽다는 이점도 있지만 속도가 느리다는 단점이 있습니다.

 

가상화를 구동을 해야 한다던지, OS를 개별적으로 구동해야 합니다.

 

속도가 느리기 때문에 지속적인 서버 관리를 하기가 어렵습니다.

 

이러한 과정에서 dotCloud에서 Docker라는 opensource 플랫폼을 발표하게 됩니다.

Docker가 설치된 곳이라면 어떤 컨테이너든지 모두 실행할 수 있는 환경을 만들었습니다.

 

컨테이너는 격리되어있는 환경으로 구성되어있기 때문에,

test용 서버도 간단하게 생성이 가능했고

 

의존성 문제를 해소하게 되면서

이식성, 즉 portability을 비교할 수 없을 정도로 높이게 되었습니다.

 

이식성은

흔히 말해서 서버 이전이라던지 DB 이전이라던지 하나의 시스템을 

다른 곳으로 이동시키는 것을 의미합니다.

 

dotCloud는 docker 이외의 기존의 사업을 정리하고 dotCloud 상호를 docker로 변경하게 되면서

docker서비스에 집중하기로 합니다. 

 

---

2-2 클라우드와 마이그레이션

안녕하세요, 저번 시간에 이어서 클라우드와 마이그레이션에 대해서

학습해 보겠습니다.

 

오늘은 클라우드를 활용한 서버 구축 방식에 대해서 알아보겠습니다.

서버를 구축하는 방식에는 크게 두 가지의 방식이 있습니다.

 

자체적으로 데이터 센터나 서버실을 운영하는 온프레미스(on-premise),

클라우드 사업자가 제공하는 인프라, 플랫폼, 서비스를 사용하는 클라우드(cloud)

방식이 있습니다.

 

이 두 가지는 무엇이 더 낫다고 할 수 있는 우열이 있는 것은 아닙니다.

서비스 환경과 규모에 알맞게 적용을 하는 것이 바람직하겠죠.

 

먼저 온프레미스에 대해서 설명을 드리고 클라우드 서비스를 세 가지 관점으로 나누어서

설명을 드리도록 하겠습니다.

 

제가 먼저 레이어로 구분해서 설명을 해드릴 건데

하늘색으로 표시된 영역은 사용자 혹은 관리자가

직접 작업을 해야 하는 뜻을 가지고 있습니다.

 

 

보안 패치, 또한 버전 업데이트, 이런 것들을 모두 자체적으로 진행해야 하는 것이죠.

서비스가 대규모로 성장할 경우, 이 모든 작업을 소화하기에는 기업에 적지 않은

부담이 됩니다.

 

on-premise의 방식에서는 기본적으로 서비스를 구성하는 모든 요소들을

직접 관리를 합니다. 

 

 

 

다음은 Cloud 모델 중 IaaS라는 것이 있습니다.

Infra as a Service의 약자로 스토리지나 가상화에 대한 서비스를

클라우드 사업자에게서 제공받는 것을 말합니다.

 

주황색으로 표시된 부분은 클라우드 사업자에서 처리를 하는 것을

말합니다. 통상 종량제 형식으로 과금이 되며 사용한 만큼만 비용을

지불한다는데서 효율적인 예산 관리가 됩니다.

 

가장 많이 쓰는 서비스로는 AWS에서 제공하는 EC2라는 것이 있습니다.

EC2 사용량이 일정 수준 넘으면 알림을 해주는 기능들이 있습니다.

(환경설정을 해줄 경우)

 

 

 

다음은 PasS라는 것이 있습니다.

Platform as a Service라고 하는 PasS는 

IaaS에 비해 좀 더 많은 영역을 Cloud사업자가 관리합니다.

 

개발자가 인프라를 처음부터 구축을 할 필요가 없이,

사업자가 제공하는 통합 솔루션을 build 하고 deploy만 하면 되는 것이죠.

대표적으로는 AWS의 elastic beanstalk와 heroku가 많이 사용됩니다.

 

우리가 elastic beanstalk나 heroku를 deploy 하는 경우에는 각각에 맞게 설정 파일만 작성해주면 내부적으로 build부터이제 외부 deploy까지 모두 완성이 되는 것이죠.

 

직접 관리자나 사용자가 처리할 부분은 화면에 보시면 애플리케이션, 그리고 데이터 등만 처리해주면 나머지는 알아서 클라우드 사업자에서 처리하게 됩니다.

 

 

클라우드 컴퓨팅 모델 중에 마지막은 SaaS인데요.

우리가 편리하게 사용하고 있는 대부분이 여기에 해당되는데요.

 

일반적으로 솔루션을 사용한다고 하죠. 

Google Workspace, 혹은 erp로 많이 사용되는 이제 국내에는 더 존 비즈온 같은 것들이 모두 SaaS에 해당하네요.

 

 

여기까지 각 모델에 대한 차이점이 눈에 들어오시나요?

 

이런 것들은 하나의 기업에 일괄적으로 적용되는 것이 아니라 서비스 별로, 혹은 부분별로 각각의 사정에 맞게 적용이 되고 있고 적용 예정인 것도 현재 굉장히 많습니다.

 

 

DI라고 하는 디지털 트랜스포메이션, 이 관련해서, 이제 클라우드

마이그레이션 작업이 굉장히 활발하게 이루어지고 있습니다.

 

그러면 마이그레이션에 대해서 알아보자면,

Migration: 이주

인터넷에 검색을 해보시면 슬라이드에 나오는 것처럼

새가 무리를 짓고 날아가는 모습이 잔득나옵니다.

다른 서식지로 이동하는 것이죠. 

 

서비스도 한 곳에 영원히 정착하지 않습니다.

유저가 많아지고 서비스가 고도화되면

필연적으로 서식지를 옮겨야 하죠.

이 것을 마이그레이션이라고 합니다.

 

우리가 뉴스에서 접하는 금융 차세대들이 여기에 해당하죠.

 

이런 마이그레이션 작업은 무중단으로 진행되기도 하지만

아마 대부분의 많은 분들이 명절 때 운행 서비스를 사용하지 못하는,

이런 것들이 기억이 나실 거예요. 

 

그래서, 대량으로 대규모로 마이그레이션이 이루어질 때는 서버를

중단해 놓고 작업을 하기도 합니다.

 

클라우드 환경의 도입이 활발한 지금은 더욱더 빈번하게 마이그레이션이

이루어지고 있죠. 

 

앞서 보셨던 것처럼 마이그레이션이 활발하게 이루어지고 있는 이런 상황 속에서

docker라는 플랫폼이 급부상하게 된 것인데요. 컨테이너 기반으로 서비스를 

구동하기 때문에, 어느 환경으로 옮겨가던지 의존성에 영향을 받지 않고

신속하게 마이그레이션이 가능해진 것입니다.

 

이식성, portability가 높다고 표현을 하기도 합니다.

 

다음 시간에는 docker에서 컨테이너가 실행되는 구조를 구체적으로 살펴보도록 하겠습니다.

 

---

2-3 컨테이너와 MSA

처음에 컨테이너라는 단어를 듣고 이런 그림을 상상하셨을 거예요.

항만에 쌓여 있는 컨테이너와 우리가 다룰 컨테이너는 어떤 공통점이 있는 걸까요?

 

아주 기본적이고 원초적인 기능은 둘 다 같습니다.

무언가를 섞이지 않도록 분리해놓고 그것들을 쌓아 올리는 것이죠.

 

게다가 컨테이너는 나름의 규격화 표준화가 되어있기 때문에

효율적으로 공간 자원 활용이 가능합니다.

 

 

우리가 사용하는 데스크톱, 노트북, 서버 등과 같은 컴퓨터는 구성이 

비슷합니다. 역할에 따라서 CPU, SSD, RAM, LAN 카드, 이런 다양한

하드웨어가 탑재되어 있죠.

 

하드웨어 자원을 사용하고 애플리케이션을

실행할 수 있도록 해주는 윈도우, 맥 OS, 리눅스 등의 이런 것들을

운영체제라고 합니다. 운영체제도 있죠.

 

우리가 개발하고 사용자에게 제공한 애플리케이션도 모두 OS위에서

실행하게 됩니다. 이 애플리케이션들이 OS의 하드웨어 자원의 자원에 할당을

요청하기 때문이죠.

 

그럼 고민이 생깁니다. 도입하려는 대규모 프로젝트에서 애플리케이션이나

플랫폼이 서로 다른 요구사항이나 의존성을 가지면 어떻게 해야 할까요?

 

게다가 성능까지 고려하게 된다면, 개발자의 고뇌가 굉장히 깊어지는 부분이죠.

이 고뇌를 해결해줄 구세주가 도커입니다. 이 귀여운 고래 마스코트 등 위에 컨테이너가

한 가득 쌓여있는 것이 보이시나요?  이 로고에서 도커라는 플랫폼의 역할이 아주 직관적으로

드러나는 되는데요.

 

 

다음 도식으로 넘어가서 구조를 살펴보도록 하겠습니다.

기본적인 컴퓨터의 구성과 더불어서 컨테이너의 구조를 간단하게 나타내고 있습니다.

 

호스트 OS에 애플리케이션을 실행할 공간을 각각 구성하고 IP를 분리시켜놓은 것이

바로 컨테이너입니다. 이 컨테이너라는 공간은 애플리케이션의 표준화된 실행 단위라고

표현할 수 있습니다.

 

docker 공식 소개 페이지에서는 이렇게 설명을 하고 있더라고요

 

"표준화된 공간에 애플리케이션을 패키 징하고 이를 개발, 공유, 배포 등에 활용할 수 있게 하는

플랫폼이 바로 도커"

 

vmware나 virtual box에서 가상 머신을 운영해 보신 분들이라면 뭔가 비슷한 개념이라고

생각하실 수도 있습니다. IP도 분리되어 있고 독립적으로 영역이 구성되어있기 때문인데요.

 

하지만 가상 머신과 컨테이너는 당연히 다른 부분이 있습니다. 

 

자, 먼저 가상 머신의 경우 가장 아래 호스트 OS와는 별개로 게스트 OS를 필요로 합니다.

OS가 구동되려면 당연히 리소스도 필요하고 시간도 걸리겠죠.

 

애플리케이션 하나하나당 OS가 별도로 실행된다. 이건 저희가 원하는 그림은 아닌 것 같습니다.

 

방금 앞에서 봤던 도커의 구조를 함께 띄었는데요.

 

이 도커 환경에서는 애플리케이션이 요구하는 환경을 구성해주는 것이지, 가상의 컴퓨터를 만들어

주는 것이 아닙니다. 컨테이너에 OS를 설치를 하고 구동하는 그런 일련의 과정이 없는 것이죠.

그렇기 때문에가상 머신보다 훨쉰 가볍고 유연하게 세팅을 할 수 있습니다.

 

 

 

다음은 MSA에 대한 용어를 살펴볼 텐데요. 

Microservice Architecture

 

이 컨테이너로 구성되어있는 애플리케이션을 통합하면 대규모 시스템을 구축을 할 수가 있습니다.

이것이 바로 우리가 자주 들었던 MSA, Microservice Architecture입니다.

 

이 MSA는 기능과 용도에 따라 서비스를 모듈화하고 이를 독립적으로 배포할 수 있는 환경을 지향합니다.

도커는 이러한 MSA 방식의 시스템 구축에서 빼놓을 수 없는 존재가 될 수밖에 없겠죠?

 

그러면 다음 시간에 도커의 역할에 대해서 자세히 살펴보고, 우리가 시스템 구축을 할 때 우리가 어떻게

도커를 활용할 수 있을지, 개발자가 왜 도커를 배워야 하는지 까지 알아보겠습니다.

 

---

2-4 도커의 역할

 

다시 한 번 이 도커 로고가

등장을 했는데요.

이제 본격적으로 실습에 앞서서 워크플로우를 한번 살펴보도록 하겠습니다.

 

자 여기 스프링 부트, NGINX, MariaDB로 웹 서비스를 구축하려고 하는 개발자가 있습니다.

이 웹서버, WAS, 웹 애플리케이션 서버죠 DBMS의 아주 기본적인 웹서비스 조합이죠.

 

이 세 가지를 위한 독립적인 환경을 구성하면서도 유기적인 결합을 이루어내려면 어떻게 해야 할까요?

도커는 애플리케이션을 실행하는 데에 필요한 각종 요소들을 묶어서 하나의 이미지로 생성합니다.

 

이 과정을 CD를 굽는 과정에 비유하기도 하는데요, 뭐 요즘은 CD를 많이 사용하지 않으니

굽는다는 표현이 익숙하지 않은 분들도 있을 수 있겠네요.

 

지금 보시면 화면에 NGINX, 스프링 부트, MariaDB의 로고가 있고

이 각각의 실행되는 환경이 이미지로 생성이 되는 모습을 도식화된 것을 보실 수가 있어요.

 

이 생성된 이미지는 레지스트리라고 하는 이미지 저장소에 공유가 가능합니다. 

이 도커에서 기본적으로 사용되는 레지스트리는 도커 허브(docker hub)입니다.

 

뒤에서 추가로 다루겠지만 로컬의 사용하고자 하는 이미지가

존재가 하지 않을 경우에 도커는 도커 허브로 가서 이미지를 탐색한 후 내려받습니다.

 

이 보안 강화, 혹은 기타 필요에 따라 도커 허브가 아닌 사설 레지스트리를 구축해서 

이미지를 관리할 수도 있습니다. 현재 AWS, 아마존이죠. GCP, 구글 등이죠.

클라우드 플랫폼에서 이런 서비스를 제공을 하고 있습니다. 

 

혹은 특정 물리 서버에 폐쇄형 레지스트리도 구축 가능합니다. 

 

그래서 이미지가 이제 저장되고 공유되는 것은 단일 채널이 아니라

멀티채널, 여러 개로 운영이 가능합니다.

 

 

자 여기까지 도커로 서비스를 구성하는 이제 아주 기본적인 웹서비스 구성을 봤는데요.

아직 의문을 가지시는 분들이 좀 많으실 거예요. 

 

이 컨테이너를 환경을 분리하는 것이 어떤 의미이지?

굳이 머리 아프게 이제 컨테이너를 따로 구성을 해야 되나?

라는 생각이 충분히 드실 수 있습니다.

 

그럼 우리가 일반적으로 운영하는 서비스를 이제 배포하는 과정을 한 번 살펴보면서

개발자에게 도커가 가져다주는 이점을 확인해 보도록 합시다.

 

 

일반적인 우리 서비스를 개발해서 운영, 이제 제품 상황으로 배포를 하는 과정을

보여 드릴 텐데요. 자, 개발자가 열심히 소스코드를 작성합니다. 비즈니스 로직, 문제없고,

DB에 데이터도 잘 쌓이고 이제 행복해 보이죠?

 

통합 테스트도 문제없이 잘 끝났습니다. 오늘따라 개발이 좀 잘되는 거 같아요.

 

자, 스테이징, 운영에 배포하기 전에 스테이징 환경에서도 꼼꼼하게 검증을 진행해야 되겠죠?

 

바로 이제 다음 단계가 대고객, 이 유저들이 사용한다, 혹은 사내 엔터프라이즈 급에서 직접 사용하고 있는

운영환경에 배포를 하게 됩니다.

 

근데, 이 소스, 운영에 배포하게 되는 순간, 에러 로그가 잔뜩 발생하게 되는데요.

이런 모니터링 툴에서도 이제 심상치 않은 기운이 감지가 되죠? 

소위 말하는 장애가 발생을 한 겁니다.

 

모든 검증 단계에서 작성한 소스 코드가 정상적으로 실행이 되었는데

운영에서 문제가 생기는 경우는 심심치 않게 접할 수가 있습니다.

 

근본적인 원인은 각 단계의 환경이 모두 동일하다는 보장을 할 수가 없기 때문이죠.

환경변수 IP, 포트, 이런 것들이 서로 다른 경우에 이를 조금 더 꼼꼼히 챙기려고 이제 개발자도

운영자도 노력을 하지만 이런 크로스 체킹을 하는 정도로는 문제를 완전히 해결할 수가 없습니다.

 

이렇게 열심히 개발도 하고 테스트했는데 운영에서 장애가 발생하면 너무 슬픈 일이죠.

 

 

도커는 기본적으로 이미지를 기반으로 컨테이너를 구성합니다. 

 

이미지에서는 애플리케이션을 작동하기 위한 환경변수 설정들, 모두 정리되어 있으므로 

도커가 설치된 곳이라면 어디에서든 실행할 수 있습니다. 개발과 운영환경 혹은 스테이징과 운영 환경이

예상과 달라서 생길 수 있는 이런 대형장애를 근본적으로 미연에 방지할 수 있는 것이죠.

 

개발자는 배포에 대한 스트레스를 덜 수가 있고, 소스코드 및 설정들 이런 것들만 도커 파일에

도커 파일 (뒤에서 배우겠지만 이미지를 생성하기 위한 베이스 파일입니다)

도커 파일을 잘 작성해서 이미지를 생성하기만 하면 됩니다.

 

이 도커의 영향력은 점점 확대되고 있습니다.

지금 슬라이드에 보이는 수치상으로만 봐도 확연히 드러나죠.

 

여기까지 컨테이너의 기초 개념과 도커의 작동원리를 이제 간단한 형태로 살펴보고

개발자가 도커를 왜 배워야 하는지 확인해 봤습니다.

 

다음 시간부터는 본격적으로 실습을 진행하게 될 텐데요.

여러분들 모두 걱정하지 마시고 도커와 함께 즐거운 개발을 할 수 있도록 해봅시다.

 

---