0510 docker 4

Ada·2022년 5월 10일
0

Playdata-Cloud

목록 보기
18/21

[ 이미지 관리 ]

-이미지 생성(직접 생성, 코드에 의한 관리 IaC)
-이미지 내보내기

  • 이미지 가져오기
  • 이미지 업로드
  • Snowflake Server
    Snowflake : 눈송이
    사용자에 의해서 지속적으로 관리가 수행되는 서버

Phoenix Server

  • Phoenix : 불사조
  • 서버의 상태를 이미지화하는 서버

[ Docker의 이미지 Layer 구조 ]

  • Union Filesystem
  • 하나의 지점에 여러 디렉토리를 마운트 할 수 있는 파일시스템
  • 겹치는 부분이 있을 경우, 층 구조에서 상단에 위치한 층의 정보를 사용
  • 대표적인 Union Filesystem
    - UnionFS
    - AUFS(Advanced multi-layered Unification File System)
    - BTRFS
    - ZFS
    - OverlayFS(v1/v2)

[ OverlayFS ]

  • Union Filesystem을 구현한 파일시스템

  • lsmod | grep overlay
    (lsmod -> 어떤 모듈이 깔려있는지 보여줌)

  • 기본구조
    - lower : 아래쪽 층들의 모임, 절대 수정되지 않음
    - upper : 겹침 구조의 최상층, 실제 수정이 반영되는 부분
    - merge : lower+upper 겹쳐서 보는 통합 View
    - work : 겹침 구조의 병합 작업등을 위하여 사용되는 임시공산

[ OverlayFS 테스트 ]

1) 마운트용 디렉토리 생성

# mkdir /overlay
# cd /overlay/
# mkdir lower upper merge work

2) 테스트용 파일 생성

# echo Hello > lower/fileA
# echo World > upper/fileB

3) OverlayFS 마운트

# mount -t overlay(타입) overlay(오버레이하겠다. 원본) -o lowerdir=lower/,upperdir=upper/,workdir=work/ merge/

mounr -t [TYPE] -o [옵션] <원본> <마운트포인트>

4) 마운트 상태 및 파일 상태 확인

# ls -l lower
# ls -l upper
# ls -l merge

5) lower에 존재하는 fileA 파일을 마운트 된 merge를 통해 접근하여 수정 및 확인

# echo merong >> merge/fileA
# ls -l merge/
# cat merge/fileA
# ls -l lower/
# cat lower/fileA
# ls -l upper/
# cat upper/fileA

결론: lower의 파일은 수정되지 않고, upper에 수정된 파일이 생성되며, merge에서는 upper의 파일이 노출됨

6) upper에 존재하는 fileB 파일을 마운트 된 merge를 통해 접근하여 수정 및 확인

# echo merong >> merge/fileB
# ls -l merge/
# cat merge/fileB
# ls -l lower/
# ls -l upper/
# cat upper/fileB

결론: lower는 upper에만 존재하는 파일과 무관하며, upper에만 존재하는 파일은 upper에서 수정됨

7) lower에 존재하는 fileA 파일을 merge를 통해 접근하여 삭제

# rm merge/fileA
# ls -l merge/
# ls -l lower/
# cat lower/fileA
# ls -l upper/

결론: lower에 존재하는 파일을 삭제할 경우, merge에 파일이 노출되지 않도록 upper에서 masking을 위한 Character 장치파일(c)을 생성. merge에는 해당 파일이 노출되지 않음

8) upper에 존재하는 fileB 파일을 merge를 통해 접근하여 삭제

# rm merge/fileB
# ls -l merge/
# ls -l lower/
# ls -l upper/

결론: upper에만 존재하는 파일을 삭제할 경우 lower는 무관하며, upper에서 직접 파일이 삭제됨

이미지 생성

태그
docker image tag : 이미지 태그 생성 (기존 이미지의 정보와 동일)

$ docker image tag centos:7 mycentos:1.0

현재 사용중인 컨테이너를 이미지화

  • docker container commit <원본컨테이너> <생성할이미지명>[:태그]
  • 원본 이미지의 정보를 그대로 생성할 이미지로 전달
  • 기존 컨테이너 생성 시 사용한 이미지의 레이어 정보도 그대로 유지
  • 옵션
    -a, --author : 작성자 지정
    -m, --message : 별도로 추가하고 싶은 메시지 입력
    -c, --change : 이미지와 관련된 설정 변경
    -p, --pause : 이미지 작성 시 컨테이너 일시 중지 후 작성

[ 이미지 내보내기 / 가져오기 ]

현재 Docker Host(Docker Engine)에 저장되어 있는 이미지를 파일로 내보내기
파일 형태로 저장되어 있는 이미지를 이미지로 불러오기
컨테이너 -> 파일(export), 이미지 -> 파일(save)

<export/import>
컨테이너를 파일로 내보내기

  • docker container export <컨테이너명> > <파일명>
  • docker container export <컨테이너명> -o <파일명>
  • 내보내기 시는 tar 아카이브 파일로 생성

export 한 파일을 이미지로 저장하기
docker image import <TAR파일명> <이미지명>[:태그]
옵션
-m, --message : 메시지 추가
-c, --change : 이미지 속성 정보 추가

export/import의 경우 이미지의 계층 정보 및 이미지의 속성정보 등이 모두 남아있지 않고, 현재 컨테이너의 파일시스템 내의 데이터만 파일로 저장하므로, 해당 이미지를 사용하여 컨테이너를 구동하기 위해서는 필요한 구성 설정을 직접 추가하여야 함 (-c, --change 옵션 사용)

<save/load>
이미지를 파일로 내보내기

  • docker image save <이미지이름>[:태그] > <파일명>
  • docker image save <이미지이름>[:태그] -o <파일명>

파일을 이미지로 가져오기

  • docker image load -i <파일명>

save/load의 경우 이미지의 계층(layer) 정보 및 이미지의 속성정보(manifest) 등을 모두 포함한 형태로 저장하기 때문에, 이미지를 다시 load 하였을 때 정보가 그대로 유지됨

[ Dockerfile을 사용한 이미지 작성 ]

  • 이미지 작성 시, 코드에 의해 이미지를 작성하도록 하는 방법
  • 기본 파일명 Dockerfile (필요시 변경 가능)
  • docker image build 명령어를 사용하여 Dockerfile 내용에 따른 이미지 빌드
    $ docker image build -t <생성할이미지명>[:태그] <Dockerfile위치>
    옵션: -f, –file: Dockerfile 대신 사용할 이름

[ Dockerfile ]

  • 기본 이미지: ubuntu, centos, busybox 등등…
  • 이미지에 추가, 수정할 파일
  • 실행할 명령
    -이미지를 만드는 과정에서 실행할 명령
    - 만들어진 이미지로 컨테이너를 구동하는 과정에서 실행할 명령
    - 만들어진 이미지를 사용하여 다시 이미지를 빌드할 때 실행할 명령
  • 네트워크 정보: 컨테이너에서 노출할 포트 정보
  • 볼륨 정보: 컨테이너에서 사용할 볼륨
  • 기본정보: 컨테이너 작성자
  • 환경변수: 이미지 실행시 사용자화(Customization)를 위한 환경변수 지정
  • 사용자: 컨테이너 내에서 명령을 실행할 사용자 지정
  • 실행위치: working directory 지정

[ Dockerfile에서 사용하는 예약어 ]

1) 베이스 이미지 (기본 이미지): FROM
사용법
- FROM <이미지명> // latest 태그를 자동 지정
- FROM <이미지명>:<태그명>
- FROM <이미지명>@

2) 실행할 명령어 (이미지 작성 시 실행): RUN
사용법
- RUN <실행할 명령>

3) 실행할 명령어 (이미지로부터 컨테이너 구동 시 실행): CMD, ENTRYPOINT

  • CMD와 ENTRYPOINT의 관계
    - CMD만 있을 경우: CMD에 지정된 명령을 실행
    - ENTRYPOINT만 있을 경우: ENTRYPOINT에 지정된 명령을 실행
    - CMD와 ENTRYPOINT가 모두 있을 경우: ENTRYPOINT에 지정된 부분이 명령어, CMD에 지정된 부분이 명령어의 인자
    ex) ENTRYPOINT touch
    CMD /tmp/test
    - CMD의 경우 컨테이너 실행 시 변경가능
    docker run [옵션] <이미지> [명령어]
    - ENTRYPOINT의 경우 옵션을 사용하여 변경 가능
    docker run --entrypoint <ENTRYPOINT에 넣을 내용> …

4) 실행할 명령어 (이미지를 사용하여 빌드할 때 실행): ONBUILD

[ Dockerfile 내에서 실행할 명령을 입력할 때 사용하는 방법 ]

  • Shell 방식 : 명령어를 그대로 입력
    ex) RUN yum -y install httpd
  • Exec 방식 : 명령어를 JSON 포맷 형태로 입력
    ex) RUN ["yum", "-y", "install", "httpd"]

Dockerfile

#나의 첫번째 Dockerfile
FROM centos:7
#이미지 빌드 시 실행할 명령 (빌드시 실행할 명령을 Shell 형식으로 지정)
RUN yum -y install httpd

#나의 첫번째 Dockerfile
FROM centos:7
#이미지 빌드 시 실행할 명령 (빌드 시 실행할 명령을 Exec 형식으로 지정)
RUN ["yum", "-y", "install", "httpd"]

#나의 첫번째 Dockerfile
FROM centos:7
#이미지 빌드 시 실행할 명령 (컨테이너 구동 시 실행할 명령을 Shell 형식으로 지정)
ENTRYPOINT touch
CMD /tmp/test

#나의 첫번째 Dockerfile
FROM centos:7
#이미지 빌드 시 실행할 명령 (컨테이너 구동 시 실행할 명령을 Exec 형식으로 지정)
ENTRYPOINT ["touch"]
CMD ["/tmp/test"]

profile
백엔드 프로그래머

0개의 댓글