ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • 도커 엘리 public/private shipping, layer system, -d, tag&untag
    docker 2022. 3. 2. 10:00

    ============

    https://youtu.be/LXJhA3VWXFA

     

    ============

    node의 app.js 어플리케이션을 구동하려면 소스파일만 있으면 되는게 아니라

    nodejs, npm, 라이브러리를사용한다면dependencies, 환경변수...

    오늘날엔 Dev컴과 Server컴을 따로 둬서, 내가 개발했었을 때 했던걸 다른 컴퓨터에서도 할 수 있어야 하는데 똑같이 또 설치하는것도 어렵고 버전맞추기도 일이다

     

    구동시키거나, 배포시킬때 환경제공. 개발 처음부터 도커로 하는게 아니야

    개발하고 jar파일 빼서 그걸 환경에다 집어넣기 하는 것

    처음에 이미지를 갖고와서, 그걸 볼륨매핑한 다음에 내 로컬에서 소스코드를 바꾸고, 이미지를 커밋하면 되긴 하겠네 근데 굳이 그럴 필요가 없다

     

    ============

    Container vs VM

     

    VM은 하드웨어 Infrastructure 위에 vmware나 VirtualBox와 같은 Hypervisor소프트웨어를 이용해서 각각의 가상의 머신을 만들 수 있다

    한 운영체제 위에서 동일한 어플리케이션을 각각의 고립된 다른 환경에서 구동하기 위해서는 이 버추얼 머신을 이용해서 앱을 구동을 해야 했다

     

    버추얼 머신은 각각의 운영체제를 포함하고 있기 때문에 엄청 무거워

    맥 이라는 OS위에서 윈도우와 우분투를 돌리게 할 수 있는데, 무겁고 시간도 오래 걸리고 Infrastructure의 리소스도 많이 잡아먹어 

     

    VM에서 경량화된 컨셉이 컨테이너다!

    하드웨어에 설치된 운영체제(=Host OS)에서 컨테이너 엔진이라는 소프트웨어를 설치만 하면 개별적인 컨테이너를 만들어서 각각의 앱을 고립된 환경에서 구동할 수 있게 해줌 = 컨테이너는 운영체제를 포함하지 않고 컨테이너 엔진이 설치된 Host OS를 공유한다, 이게 어떻게 가능한지는 운영체제와 커널에 대해 깊숙하게 다뤄야하므로 스킵

    컨테이너가 구동되기 위해서는 컨테이너 엔진이란 것이 필요하다

    컨테이너 엔진이 Host OS에 접근해서 필요한 것들을 처리해준다, 컨테이너 엔진중에 가장 많이 이용하는게 도커

     

    ============

    도커의 3대 구성요소

     

    컨테이너를

    만들고

    배포하고

    구동한다

     

    만들기위해선

    도커파일을 만들어서

    도커파일을 이용해서 이미지를 만들고

    이미지로 컨테이너를 구동할 수 있다

     

    도커파일 : 컨테이너 어떻게 만들어야 하는지 설명서

    어플리케이션을 구동하기 위해 꼭 필요한 파일

    어떤 프레임워크나 라이브러리를 설치하는지(외부 디펜던시) 명시

    필요한 환경변수

    어떻게 구동해야하는지 스크립트

     

    이미지 : 실행되고 있는 어플리케이션의 상태를 찰칵!해서 이미지로 만들어둔다 는 느낌

     

    컨테이너 : 이미지를 구동, 수정 가능

     

    객체지향으로 치면

    이미지를 클래스, 컨테이너를 인스턴스

     

    ============

    Shipping Containers 컨테이너 배포 = 이미지를 공유

    개발자들은 퍼블릭 서비스를 이용

    회사에서는 대부분 프라이빗을 사용함. 우리 회사 프로젝트에서 일하지 않는 다른 사람들이 우리 프로젝트 도커 이미지를 쉽게 다운로드 받으면 안되니까 보안적인 이유에서. 저 클라우드 3사에서 도커 컨테이너 레지스트리와 같은 서비스를 제공

     

    ============

    그러므로

    1)개발 로컬 머신에 도커 설치

    2)서버에 도커 설치

     

    (개발 따로 서버 따로)

     

    사실 끝

     

    내 어플리케이션을 구동할 수 있게 도커파일을 만들고, 이걸 이미지로 만들고, 컨테이너 레지스트리에 올리고

    서버에서 그걸 다운받아서 컨테이너를 실행하는 것

     

    ============

    컨테이너를 실행할 수 있는 컨테이너 엔진 도커 !

    vscode 도커 익스텐션은 도커파일 작성할 때 문법 힌트 제공 받을 수 있다

     

    ============

    node js

     

    npm init -y : 프로젝트초기화

    npm i express : 심플한 백엔드를 만드는 프레임워크

     

    그 다음

    index.js를 만들어서 익스프레스 백엔드를 만듦

    그저 요청이 오면 출력하는 애. 8080포트

     

    ============

    도커파일

     

    FROM

    처음에는 항상 FROM 베이스 이미지로 시작

    처음부터 모든걸 우리가 다 만드는게 아니라 베이스 이미지를 갖고 감. 기본적으로는 순수한 리눅스 이미지

    node같은 경우는 운이 좋게도 node에서 미리 만들어둔 노드 이미지가 있다

     

    alpine : 최소 작은 단위의 리눅스버전

    node에 컨트롤 클릭하면 도커허브 node페이지가 뜨는데 nodejs에서 사용가능한 모든 baseimage 확인가능

     

    WORKDIR

    그 다음

    도커 이미지 안에서

    어떤 경로에 이걸 실행할 건지 WORKDIR (=cd와 같은 개념)

    루트 경로의 app이라는 폴더 안에 우리 프로젝트에 관련된 모든 파일들을 카피해 오겠다

    어떤 디렉토리에 우리 어플리케이션을 복사해올건지 명시한 것

    아직 복사 안했어

     

    COPY

    그 다음에 복사를 하는거야

    팁 : 도커 파일에서 카피하고 명령어를 수행하는 것은 레이어 시스템으로 구성(좀 있다 설명)

    빈번히 변경되는 파일일수록 제일 마지막에 작성해주는게 좋음

    index.js가 : 소스코드

    package.json보단 : 다른 디펜던시에 대한 정보를 담고 있다

    더 빈번히 변경될것

    그래서 package.json을 먼저 복사할 것. 소스파일은 마지막에 복사할 것

     

    WORKDIR덕분에 현재 경로인 . 에 복사할 수 있다

    package.json이 프로젝트의 모든 디펜던시를 명시하고 있는애(package-lock.json은 언급안함, 하지만 같이 복사함)

     

    그 다음 npm install하면 package.json에 명시돼 있는 모든 라이브러리들을 다 설치하게 됨.

    ▽아하

     

    *팁 : 근데 npm install 대신 npm ci 가 더 좋다

    npm install은 package.json에서 특정 라이브러리에 버전 3이상은 다 괜찮다 라고 명시를 해두면 실행당시에 최신 버전이 나와버리면 그 버전이 설치됨 => 프로젝트를 개발한 버전과 실제로 설치한 버전이 달라질 수 있는 문제점이 있다

    ci를 사용하면 package-lock.json에 명시돼 있는, 즉 우리가 개발할 때 썼던 정확한 3.어쩌구 버전을 그대로 설치 => 버전이 조금 달라질 수 있는 문제점을 해결할 수 있다

     

    ci/cd세팅할 때 ci명령어를 사용하기 때문에 ci

     

     

    그 다음 소스파일 카피

     

    ---

    ENTRYPOINT

    실행은 이 명령어를 이용

    도커 레퍼런스 ⇢ https://docs.docker.com/engine/refere...

    Dockerfile Best Practices ⇢ https://docs.docker.com/engine/reference/builder/

     : 더 좋은 방식으로 도커파일을 만들 수 있을지 원칙

     

    ============

    레이어 시스템

    명령어 하나하나가 레이어로 돼 있어서

    제일 빈번히 발생하는 것일수록 마지막에 작성해야해 -> 그럼 레이어 제일 위쪽으로 위치가 됨

    이미지를 만들고 나중에 소스파일이 변경돼서 새로운 이미지를 만들어야 할 때

    변경된 최상단의 레이어만 업데이트함 !

    나머지 레이어는 다시 만들지 않는다

    이미지를 다시 만들 때 변경되지 않은 레이어 까지는 캐시된걸 재사용한다

    변경된 레이어부터 그 위로는 다시 빌드해, 이미지를 만드는 시간을 단축하고 효율성이 높아진다

     

    ============

    이미지 만들기

    docker build -f Dockerfile -t fun-docker .

     

    마지막 . : build context, 도커에게 네가 필요한 파일은 여기에 있다

    -f : 어떤 도커 파일을 사용하는지, 기본적으로 Dockerfile, 다른 이름을 지정해줄 수도 있다

    -t : use -t to name the image

    다양한 명령어가 있으니

    여기 docker build로 가기

     

    docker images

     

    REPOSITORY필드 안에 fun-docker라고 우리가 아까 이미지 이름 지정한 것 

    깃허브의 REPOSITORY와 동일한 것

     

    ============

    이미지를 이용해 컨테이너를 실행

    docker run -d -p 8080:8080 fun-docker

    -d : detach, nodejs 백엔드 앱이기 때문에 터미널이 계속 기다려야 하니까, 터미널아 내가 끝날때까지 기다리지 말고 넌 니가 하는 일 해

    ▽-it가 없어도 -d가 쓰인다

    -p : 잘알지

     

    docker ps

     

    docker logs 컨테이너식별자

    로그보려면

     

    ============

    GUI로 LOGS, 환경변수, 사용하고있는 리소스(STATS) 확인 가능

     

    컨테이너 내부에서도 터미널 이용 가능 GUI로

     

    ============

    push

    도커허브에서 레포지토리를 만들면

    어떻게 이미지를 푸시할 수 있는지 나온다 

     

    앞에서 만든 이미지를 리포지토리에 올리기 위해선 이미지의 이름이 리포지토리의 이름과 매칭이 돼야해

    도커허브에서는 이미지의 이름을 어카운트이름 + 슬래시 + 리포지토리이름 으로 해야해

     

    이름 바꾸기 docker tag

    이렇게 바꾸면

    두개의 이름이 태그가 돼 있다 -> 뭔지 알지 이거 이름변경이 아니고 태그 언태그 개념

     

    푸시하기 전 docker login

     

    그리고 저 위에 있는 시키는대로 push 명령어

Designed by Tistory.