개발공부 기록지

목차

• 도커 허브에 공유된 이미지 사용하기
  • 소단원
• Dockerfile 작성하기
  • 소단원
• 컨테이너 이미지 빌드하기
  • 소단원
• 도커 이미지와 이미지 레이어 이해하기
• 이미지 레이어 캐시를 이용한 Dockerfile 스크립트 최적화
• 연습문제: Dokerfile 스크립트 없이 도커 이미지 빌드 

도커 허브에 공유된 이미지 사용하기

레지스트리(registry)

• 이미지를 제공하는 저장소
• docer image pull (이미지 이름) 을 입력하면 필요한 이미지 중 로컬 컴퓨터에 없는 이미지를 도커 허브(레지스트리)에서 다운 받는다.

docker image pull diamol/ch03-web-ping

이미지 레이어?

위 그림에서 보면  docker image pull diamol/ch03-web-ping  를 실행해서 

하나의 이미지를 다운 받는데 여러 건의 파일을 다운받는 것을 볼 수 있다.

이미지는 여러 개의 작은 파일로 구성돼있다. 이 각각의 파일을 이미지 레이어라고 부른다.

내려받은 이미지로 컨테이너를 실행하고 실행된 애플리케이션의 기능을 확인

docker container run -d --name web-ping diamol/ch03-web-ping

이 때 환경 변수에 있는 블로그 주소 blog.sixeyed.com 에 요청을 보내는 로그 를 확인 가능 

이 환경변수는 호스트 운영체제의 것을 가져오는 것이 아니라 도커가 기본값을 컨테이너에 적용하고 이 값을 애플리케이션에서 이용하는 방식이다.

- 환경 변수 변경하여 새로운 컨테이너 실행

docker rm -f web-ping
docker container run --env TARGET=google.com diamol/ch03-web-ping

• --env TARGET=google.com : 애플리케이션에서 사용할 환경 변수 값을 지정 (구글에 요청을 보내도록 변경)

포인트!

- 도커 이미지는 설정값의 기본값을 포함해 패키징 된다. 컨테이너를 실행할 때 이 설정값을 바꿀 수 있게 구성해야한다.(환경변수 이용)

이미지에 포함된 기본 값 외의 다양한 설정값이 반영된 컨테이너 그림

호스크 컴퓨터는 고유한 환경 변수가 있다.

하지만,  컨테이너의  환경 변수는 도커가 부여한 환경 변수만 가진다. 

위의 그림에 보이듯이 같은 애플리케이션을 실행하고 있지만 주어진 환경 변수에 의해 동작이 달라지고 있다.

Dockerfile 작성하기

Dockerfile?

- 애플리케이션을 패키징하기 위한 간단한 스크립트.

- 일련의 인스트럭션으로 구성

- 어떠한 애플리케이션이라고 패키징 가능

예시

FROM diamlo/node

ENV TARGET="blog.sixeyed.com"
ENV METHOD="HEAD"
ENV INTERVAL="3000"

WORKDIR /web-ping
COPY app.js

CMD ["node","/web-ping/app.js"]

• 인스트럭션 설명
  • FROM : 시작 지점을 지정
  • ENV : 환경 변수 값을 지정
    • INTERVAL 3000 = 3 초 마다 요청 전송
  • WORKDIR : 컨테이너 이미지 파일 시스템에 디렉터리를 만들고, 해당 디렉터리를 작업 디렉터리로 지정
  • COPY : 로컬 파일 시스템의 파일 혹은 디렉터리를 컨테이너 이미지로 복사 [원본경로] [복사경로]
    • 로컬 파일 시스템에 있는 app.js 파일을 이미지의 작업 디렉터리로 복사
  • CMD : 도커가 이미지로 부터 실행할 때 실행할 명령을 지정
    • node 로 애플리케이션을 시작하도록 app.js 를 지정

컨테이너 이미지 빌드하기

이미지를 빌드하기 위해 Dockerfile 스크립트, 이미지의 이름, 패키징에 필요한 파일의 경로를 지정

docker image build --tag web-ping (파일의 경로)

• --tag의 인자값(web-ping) 은 이미지의 이름
• 다음 인자는 파일의 경로 (도커에서는 이 디렉터리를 컨텍스트 라고함)
  • . 을 찍으면 현재 작업 디렉토리를 의미

빌드 후 이미지 확인 ( w 로 시작하는 모든 이미지 목록 출력)

docker image ls w*

이렇게 빌드된 이미지는 도커 허브에서 내려받은 이미지와 같은 똑같은 방식으로 사용할 수 있다.

도커 이미지와 이미지 레이어 이해하기

• 도커 이미지는 이미지 레이어가 모인 논리적 대상이다.
• 레이어는 도커 엔진의 캐시에 물리적으로 저장된 파일이다.

만약에 Nods.js 애플리케이션이 실행되는 컨텡너를 여러 개 실행한다면 이들 컨테이너는 모두 Nods.js 런타임이 들어 있는 이미지 레이어를 공유한다. 아래 그림에 해당 상황을 표현했다.

이 경우 이미지의 용량을 확인하는 방법

docker image ls

  - 출력되는 화면에서 SIZE 확인 ( 논리적인 용량)

• REPOSITORY 에 있는 3 이미지는 모두 Node.js 기반 레이어를 공유
• SIZE 에 있는 수치가 실제로 디스크 용량을 차지하는 크기 같지만, 이 수치는 이미지의 논리적 용량으로 공유된 레이어의 용량이 반영되지 않은 수치 ( 약 151 MB )

docker system df

- 출력되는 화면에서 Type Images 의 SIZE 확인 ( 이미지 캐시에 실제 사용된 디스크 용량)

• 80.79 MB 가 이미지 레이어를 저장하는데  실제 사용된 디스크 용량이다.
• 약 70MB 는 이미지 끼리 레이어를 공유하여 디스크 공간 절약

이미지 레이어 캐시를 이용한 Dockerfile 스크립트 최적화

도커는 캐시에 일치하는 레이어가 있는지 확인하기 위해 해시값을 이용한다.

해시

• 입력값이 같은지 확인할 수 있는 일종의 디지털 지문
• 해시값은 Dockerfile 스크립트의 인스트럭션과 인스트럭션에 의해 복사되는 파일의 내용으로 부터 계산
• 기존 이미지 레이어에 해시값이 일치하는 것이 없다면 캐시 미스가 발생하고 해당 인스트럭션이 실행

한번 인스트럭션이 실행되면 그 다음에 오는 인스트럭션은 수정된 것이 없더라도 모두 실행

 ( 예시) Dockerfile 예시 (step 1 ~ step 7)

FROM diamlo/node

ENV TARGET="blog.sixeyed.com"
ENV METHOD="HEAD"
ENV INTERVAL="3000"

WORKDIR /web-ping
COPY app.js

CMD ["node","/web-ping/app.js"]

만약

step 1 ~ 5 ( FROM ... ~ WORKDIR/ web-ping)  변경이 없음  → 캐시에 저장된 것을 재사용

step 6      (COPY app.js)                                     변경(app.js 수정) → 다시 실행

step 7      (CMD).                                                  변경 없음 → step 4의 캐시를 재사용하지 못하여 다시 실행

Dockerfile 스크립트의 인스트럭션은 작성 시 숙지하면 좋은 사항들

• 잘 수정하지 않는 인스트럭션을 앞에 배치
• 자주 수정되는 인스트럭션이 뒤에 배치
• 이유는 캐시에 저장된 이미지 레이어를 되도록 많이 재사용하기 위함

예시 Dockerfile 최적화 

FROM diamlo/node

CMD ["node","/web-ping/app.js"]

ENV TARGET="blog.sixeyed.com"\
    METHOD="HEAD" \
    INTERVAL="3000"

WORKDIR /web-ping
COPY app.js

  - 자주 수정되는 COPY 를 제일 뒤로 배치

 - ENV 는 하나의 인스트럭션으로 여러 개의 환경 변수를 정의 

연습문제 : Dockerfile 스크립트 없이 도커 이미지 빌드

이미지 위치 : diamol/ch03-lab
이미지 속 파일 : diamol/ch03.txt
문제 : 이미지 속 파일 뒤에 나의 이름을 추가한 다음 수정된 파일을 포함하는 새로운 이미지를 빌드
조건: Dockerfile 스크립트 사용 불가

• -it ( --interactive --tty) : 이미지 안에서 터미널 켜기
• --name : 컨테이너 이름 짓기 ( ch03ex)
• diamol/ch03-lab : 이미지 이름

• docker commit (컨테이너 이름) (새로운 이미지 이름) : 컨테이너 이름에 있는 변경 사항을 저장하여 새로운 이미지 생성

목차

• 컨테이너가 IT 세상을 점령한 이유
  • 레거시 애플리케이션 현대화 하기
  • 클라우드 환경에 적합한 새로운 애플리케이션 개발하기
  • 기술 혁신: 서버리스와 그 너머
  • 데브옵스 도입하기

컨테이너가 IT 세상을 점령한 이유

깃 허브에 있는 소스코드를 다운받아서 소스코드에 사용되는 환경에 맞추기 위해서 버전에 맞는 도구를 설치해야한다.

만약 이것이 큰 프로젝트라면 새로운 개발팀과 운영팀이 인계 받을 때 소스코드를 빌드하고 실행하기위해서 여러가지 도구를 버전에 맞게 설치해야 한다. 

하지만, 컨테이너를 이용하면 소스코드를 내려받고 나서 명령 한 줄로 배포 및 실행이 가능하다.

레거시 애플리케이션 현대화 하기

컨테이너를 활용하면 거의 모든 애플리케이션을 클라우드에서 실행할 수 있다.

그러나, 기존 애플리케이션의 구조를 낡은 모놀리식(monolithic) 설계로 방치한다면 도커 혹은 클라우드 플랫폼의 진가가 발휘되기 어렵다.

이유는 기민성에 제약이 따르기 때문이다. 모놀리식에서 새 기능을 추가하여 출시하려면 기존의 기능이 망가지지 않았늦니 확인하는 회구 테스트에만 적어도 2주가 걸릴 것이다.

도커로 이주하는 과정을 애플리케이션의 낡은 설계를 탈바꿈하는 첫걸음이다. 애플리케이션을 전면적으로 재구현하지 않고도 새로운 패턴을 도입할 수 있다.

이 그림은 통짜 애플리케이션을 분할해 기능별로 별도의 컨테이너에 배치하여 여러 개의 컨테이너로 분할된 분산 애플리케이션을 만드는 과정을 나타낸것이다.

이렇게 설계를 하면 변경내용에 해당되는 컨테이너만이용하여 빠르게 테스트할 수 있다.

클라우드 환경에 적합한 새로운 애플리케이션 개발하기

도커는 기존 애플리케이션을 클라우드로 이주하는데 유용하다.

통짜 애플리케이션이라면 도커를 통해 컴포넌트를 분할하고 새로운 설계를 적용해 클라우드나 데이터센터 어디든 원하는 곳에서 애플리케이션을 운영할 수 있다.

클라우드 환경을 고려한 완전히 새로운 애플리케이션 개발이라면 도커를 통해 더 빠른 개발이 가능하다.

아래 그림은 전형적인 마이크로 서비스 아키텍처의 애플리 케이션을 나타낸 것이다.



• 각 컴포넌트는 자신만의 데이터를 가지며 API를 통해서 이 데이터를 외부에 제공한다.
• 프런트 앤드는 이 API를 이용하는 웹 애플리케이션 형태
• 도커는 여러가지 프로그래밍 언어로 구현하거나 서드 파티 소프웨어를 도입하여 애플리케이션을 구현하는데 유용하다.

기술 혁신: 서버리스와 그 너머

현대 IT 기술을 주도하는 요소 중 하는 일관성이다.

특히, 개발 팀은 모든 프로젝트에서 같은 도구, 같은 프로세스, 동일한 런타임을 사용하기를 원한다.

도커를 이용하면 어떠한 형태의 애플리케이션이라도 모든 제품의 빌드, 배포, 운영을 같은 도구와 같은 방법으로 수행할 수 있다.

즉, 아키텍쳐나 기술 기반과 무관하게 이들 애플리케이션의 빌드, 배포, 관리를 일원화 할수 있다.

*서버리스 기술은 곧 컨테이너 기술이다. 서버리스 기술의 목표는 모든 일이 플랫폼이 처리하도록 하는 것이다.

데브옵스 도입하기

데브옵스(DevOps)는  개발과 운영을 합친 이름으로, 애플리케이션의 전체 생애주기를 담당하는 전담 팀을 둔다.

운영자와 개발자는 다른 도구를 다루는데 이 사람들끼리 하나의 팀을 이룰수 있도록 도와주는 것이 도커이다.

Dockerfile 과 도커 컴포드 스크립트를 사용하면 같은 기술과 도구로 팀을 통일할 수 있다.

CALMS 라는 데브옵스를 위한 프레임워크가 있다.

• cluture (문화)
• automation (자동)
• lean (린)
• metric(측정)
• sharing(공유)

의 머리 글자를 딴 것이다. 도커는 이들 개념 모두와 밀접한 관련이 있다.

자동화는 컨테이너 환경의 핵심,

분산 애플리케이션은 린 원칙에 따라 만들어진다.

배포 프로세스와 운영 로그로부터 얻은 측정치를 쉽게 사용할 수 있다.

도커 허브는 이미 있는 것을 공유의 장이다.