출처: [book]완벽한 IT 인프라 구축을 위한 Docker 책 내용을 기반으로 공부하며 정리한 것입니다.

        



#1. docker version 확인

   $docker version


#2. docker 실행환경 확인

   $docker system info


#3. docker 가 사용하고 있는 disk 이용 상황

   $docker system df


#4. docker image 목록 확인

   $docker image ls

   $docker image ls -a        --->모든(중간 이미지까지) 이미지를 표시

   $docker image ls --digests   ---> 다이제스트를 표시

   $docker image ls -q        ---> docker image id만 표시



#5. docker image 다운로드

   $docker pull [다운받을아이템]

   $docker image pull [다운받을아이템]

   $docker image pull [다운받을아이템]:[태그명]                 ---> 지정한 태그의 아이템을 다운로드

   $docker image pull -a [다운받을아이템]                           ---> 해당 아이템의 모든 태그를 다운로드

   $docker image pull  gcr.io.tensorflow/[다운받을아이템]   ---> url로 부터 다운로드



#6. docker 컨테이너 실행

   $docker container --name [컨테이너명] -d -p 80:80 [이미지명]

   ex) docker container --name webserver -d -p 80:80 nginx


#7. docker 컨테이너 실행목록 확인

   $docker container ps


#8. docker 컨테이너 상세 확인

   $docker container stats [컨테이너명]


#9. docker 컨테이너 정지/기동

   $docker stop/start [컨테이너명]


#10. docker image 상세정보 확인

   $docker image inspect centos:7


#11. docker image tag 설정 하기 (docker hub 에 작성한 이미지를 등록하기 위한 방법)

   $docker image tag [아이템명] [docker hub 사용자명]/이미지명:태그명

  ex) docker image tag nginx gogildong/webserver:1.0        --> 기존에 존재하는 nginx 이미지를 사용하여 gogildong 사용자의 webserver 란 이미지의 1.0 태그 버젼을 설정하는 경우


#12. docker hub에서 검색하기

   $docker search [아이템명]


#13. docker image 삭제

   $docker image rm [이미지명]

  ex) docker image rm nginx

   $docker image rm -f nginx       ---> image 강제 삭제

   $docker image rm --no-prune  nginx      ---> image 삭제(중간이미지는 삭제하지 않음)


#14. 사용하지 않는 docker image 삭제

   $docker image prune 

   $docker image prune -a         --->사용하지 않는 이미지를 모두 삭제

   $docker image prune -f         --->사용하지 않는 이미지를 강제로 삭제


#15. docker hub 에 로그인

   docker hub 레파지토리에 이미지 업로드를 하려면 hub에 로그인을 해야 한다.

   (로그인 상태유저 확인은 $docker info | grep Username  하면 됨 . 아무것도 안나오면 로긴 안된 상태임)

  $docker login

    Username : 등록한 사용자명

    Password : 등록한 패스워드

   Login succeeded



#16. docker image 업로드

   $docker image push [docker hub 사용자명]/[이미지명]:[태그명]

  ex)docker image push reo/nginx

      docker image push reo/nginx:1.1

--------------------------------------------------------------------------------------

docker Container

  - image 로 부터 컨테이너를 생성한다.

  - image의 실체는 docker 에서 서버 기능을 작동시키기 위해 필요한 디렉토리 및 파일들 이다.

  - Life Cycle

     1) Container 생성                        

     2) Container 생성 및 시작

     3) Container 정지

     4) Container 삭제


  - Life Cycle 상세설명

      1) Container 생성

           > 명령어 : docker container create  

           > 명령어 실행하면 이미지에 포함될 linux의 디렉토리와 파일들의 스냅샷(스토리지 안에 존재하는 파일과 디렉토리를 특정 타이밍에 추출한것)을 취한다.

           > 해당 명령어는 컨테이너를 작성하기만 할뿐 실행하지 않는다.           

     2) Container 생성 및 시작

           > 명령어 : docker container run

           > 이미지로 부터 컨테이너를 생성하고, 컨테이너 상에서 임의의 프로세스를 시작한다.

     3) Container 정지

           > 명령어 : docker container stop

                           docker container start (중단된 컨테이너 시작)

                           docker container restart (재시작)

     4) Container 삭제

            > 명령어 : docker container rm 


--------------------------------------------------------------------------------------

#17. 컨테이너 생성 및 시작

   $docker container run [옵션] [이미지명]:[태그명] [인자값]


   ex)docker container run -it --name "test" centos /bin/cal

       : centos 라는 이미지를 사용하여, test 라는 컨테이너를 실행하고, 컨테이너 안에서 /bin/cal 명령을 실행한다.

         근데, 이 결과를 콘솔에 출력(-it) 한다.


#18.컨테이너를 백그라운드로 생성 및 시작

   $docker container run -d [이미지명]:[태그명] [인자값]


  ex) docker container run -d centos /bin/ping localhost     ---> 백그라운드(-d)에서 실행 하는 것을 디태치 모드 라고 한다.


#19. 백그라운드로 실행되고 있는 컨테이너 로그 확인

   $docker container logs -t [컨테이너식별자]

  ex)docker container logs -t fbcddkdhgmdfk     ---> fb~는 컨테이너id 중 일부임     

  

#20. 컨테이너 네트워크 설정

   $docker container run [네트워크 옵션] [이미지명]:[태그명] [인자]


   $docker container run -d -p 8080:80 nginx        --->포트매핑(-p)   host포트(8080):컨테이너포트(80)

   $docker container run -d --dns 192.168.1.1 nginx     --->dns설정(--dns)   

   $docker container run -it --add-host test.com:192.167.1.1 centos     --->/etc/hosts 파일에 값 설정(--add-host) 


#21. 컨테이너 자원 설정

   $docker container run [자원옵션] [이미지명]:[태그명] [인자]


   $docker container run --cpu-shares=512 --memory=1g centos       ---> cpu 상대비율지정(--cpu-shares) 및 메모리 할당(--memory)

   $docker container run -v /Users/reo/tempdir:/user/share/nginx/tdir nginx         ---> 호스트 os와 컨테이너 안의 디렉토리를 공유(-v 또는 --volume) 

                                                                                                                                         호스트(/Users/reo/tempdir):컨테이너(/user/share/nginx/tdir)


#22. 컨테이너 환경을 설정

   $docker container run -it -e utname=gogo centos /bin/bash            ----> 환경변수 설정(-e)

   $docker container run -it --env-file=filename centos /bin/bash        ---> 특정파일내용을 일괄로 환경변수로 설정(--env-file=파일명)

   $docker container run -it -w=/test centos /bin/bash                          ---> 컨테이너의 작업 디렉토리를 설정 (-w=디렉토리명)


#23. 기동중인 컨테이너 상태 확인

   $docker container ls        ---> 실행중인 컨테이너 모두 표시

   $docker container ls -s    ---> file size 표시

   $docker container ls -a    ---> 정지중인 컨테이너도 모두 표시

   $docker container ls -a -f name=test   --->  필터링 하여 표시(-f ) 


#24. 컨테이너 가동 확인

   $docker container stats [컨테이너식별자,즉 id]

   

#25. 컨테이너에서 실행중인 프로세스 확인

   $docker container top [컨테이너식별자,즉 id]


#26. 컨테이너 삭제

   $docker container rm [옵션] [컨테이너식별자,즉 id]

   $docker container rm -f dkdbdhk23fj         --->실행중인 컨테이너를 강제로 삭제

   $docker container rm -v dkjfhddk345dk    ---> 할당한 볼륨을 삭제

   $docker container prune                            ---> 정지중인 모든 컨테이너를 삭제


#27. 실행중인 컨테이너에서 작동중인 프로세스를 모두 중단

   $docker container pause [컨테이너식별자]      ---> 중단 시키면 컨테이너의 status 가 paused 로 변경됨


   $docker container unpause [컨테이너식별자]   ---> 중단 재개함


#28. 가동중인 컨테이너에 연결

   $docker container attach [컨테이너명]

   $docker container attach test           ---> 가동중인 test란 컨테이너에 연결할때 

   연결을 끊으려면 Ctrl+C


#29. 가동중인 컨테이너에서 새로운 프로세스를 실행

   $docker container exec


   $docker container exec -it webserver /bin/bash            ---> 가동중인 webserver 라는 컨테이너 안에서 /bin/bash    를 실행


   exec 명령어는 실행중인 컨테이너에 대해서만 실행 가능한 명령어임!!!



#30. 가동 컨테이너의 포트 확인

   $docker container port [컨테이너식별자]


   $docker container port reoserver

     80/tcp -> 0.0.0.0:80                       (컨테이너의 80 포트 -> 호스트 80 포트로 전송)


#31. 컨테이너 이름 변경

   $docker container rename [올드명] [신규명]


#32. 컨테이너 안의 파일을 호스트로 복사

   $docker container cp [컨테이너식별자]:[컨테이너파일경로] [호스트파일경로]

   

   $docker container cp reoserver:/User/reo/test/test.txt /tmp/test.txt       ---> 컨테이너파일을 호스트로 복사

   $docker container cp ./test.txt reoserver:/tmp/test.txt                             ---> 호스트파일을 컨테이너로 복사


#33. 컨테이너 변경사항 확인

   : 컨테이너 안에서 변경이 발생하여, 이미지로부터 생성되었을때와 달라진 점을 확인하기 위함

    $docker container diff [컨테이너식별자]

    [변경구분]

     - A: 파일추가   

     - D: 파일삭제

     - C: 파일수정


iyeonghoui-MacBook-Pro:~ ireo$ docker diff reoserver

C /root

A /root/.bash_history

C /etc

A /etc/subgid-

C /etc/subuid

C /etc/group

A /etc/shadow-

A /etc/group-

A /etc/gshadow-

C /etc/subgid

A /etc/subuid-

C /etc/gshadow

A /etc/passwd-

C /etc/passwd

C /etc/shadow

C /var

C /var/log

C /var/log/tallylog

C /var/log/faillog    



#34. 컨테이너로부터 이미지 만들기

   $docker container commit [옵션] [컨테이너식별자] [이미지명]:[태그명]

   $docker container commit reoserver iamreob/testserver1:1.0          --> reoserver 컨테이너를 docker hub iamreob 사용자의 testserver 란 이름의 이미지 1.0 태그로 만듦


#35. 기동중인 컨테이너의 디렉토리와 파일들을 모아서 tar 파일로 만들기

   $docker container export reoserver > test.tar


#36. tar 파일로부터 이미지 작성

   $docker image import [파일 또는 url] | - [이미지명]


#37. docker 이미지를 tar 파일로 저장

   $docker image save [옵션] [저장파일명] [이미지명]

   $docker image save -o export.tar tensorflow        ---> tensorflow 이미지를 export.tar 파일로 저장


#38. tar 이미지로부터 이미지를 읽어들이기

   $docker image load [옵션]

   $docker image load -i export.tar        ---> export.tar 라는 이름의 이미지를 읽어들임


!!! export/import  ...... save/load 차이 !!!

   : docker container export 로 만든 tar 파일과 

     docker image save          로 만든 tar 파일은  바탕이 되는 이미지는 똑같지만, 내부적인 디렉토리와 파일 구조가 다름

     (image 를 save 하면 , image의 레이어 구조가 포함된 형태로 tar 파일이 만들어짐)


     따라서, docker container export 로 작성한 것을 읽어들일때는 docker image import 
                 docker image save          로 작성한 것을 읽어들일때는 docker image load



#39. 불필요한 이미지/컨테이너/볼륨/네트워크 를 일괄삭제

   $docker system prune [옵션]

   $docker system prune -a       --->사용하지 않는 리소스를 모두 삭제한다

   $docker system prune -f       --->강제로 삭제한다



#40.   DockerFile 명령

     - FROM : 베이스 이미지 지정

     - RUN :  명령 실행 (Docker Image 를 작성하기 위해 실행하는 명령을 기술할때 사용)

     - CMD : 컨테이너 실행 명령( Image 를 바탕으로 생성된 컨테이너 안에서 실행할 명령을 기술할때 사용)

                   단, dockerfile 에는 1개의 CMD 만 명령을 기술할 수 있습니다. 여러개를 기술할 경우 마지막 명령만 유효합니다.

     - LABEL : 라벨 설정

     - EXPOSE : 포트 익스포트

     - ENV : 환경변수 (Dockerfile 안에서 환경변수를 설정하고 싶을때 사용)

             (!!!지정방식 2가지!!!)

               1) 

     - ADD : 파일/디렉토리 추가

     - COPY : 파일 복사

     - ENTRYPOINT : 컨테이너 실행 명령 

                                ( Dockerfile 에서 빌드한 이미지로부터 Docker 컨테이너를 시작할때, 즉 docker container run 명령실행시에 실행되는 명령어를 기술 )


        (!!!CMD 와 ENTRYPOINT 의 차이 !!!)

         -> ENTRYPOINT 명령으로는 실행하고 싶은 명령어 자체를 지정하고, CMD 로는 해당 명령의 인수를 지정한다.

         -> docker container run 명령 실행시에 인수로 어떤 값을 지정한다면 해당 인수가 우선시되고, CMD 명령은 무시되게 된다.

              (Docker file 샘플)

               FROM ubuntu:latest

              ENTRYPOINT ["top"]

              CMD ["-d", "10"]

             일 경우

             $docker container run -it 이미지명              --> 설정대로 10초간격으로 갱신

             $docker container run -it 이미지명 -d 2      --> 설정무시하고 2초 간격으로 갱신


     - VOLUME : 볼륨 마운트

     - USER : 사용자 지정

     - WORKDIR : 작업 디렉토리 

                           ( Dockerfile 에 씌여있는 (CMD / RUN / ENTRYPOINT / COPY / ADD 등) 명령어를 실행시키기 위한 작업용 디렉토리를 지정함)

                           -> 지정한 디렉토리가 존재하지 않으면 새로 생성함

                           -> 여러번 사용할 수 있음 

                           -> WORKDIR 에서는 ENV 에서 지정한 환경변수를 사용할 수 있습니다.

     - ARG : Dockerfile 안의 변수

     - ONBUILD : 빌드 완료 후 실행되는 명령 

                          ( dockerfile 로 이미지를 생성한 후에, 해당 이미지를 다른 dockerfile 에서 베이스 이미지로 지정하여 빌드할때 실행할 명령을 기술)

     - STOPSIGNAL : 시스템 콜 시그널 설정 ( 컨테이너를 종료할때 송신하는 시그널을 설정할때 사용)

     - HEALTHCHECK : 컨테이너의 헬스체크 (컨테이너 안의 프로세스가 정상적으로 작동하고 있는지를 체크 할때 사용 )

     - SHELL : 기본 쉘 설정


#41. Dockerfile 로 부터 docker image 만들기

   $docker build -t [생성할이미지명] :[태그명] [dockerfile위치]

   $docker build -t reotest:1.0 /Users/reo/Documents/APP/dockerSecondDir


#42. 파일명을 지정한 Dockerfile 로 부터 docker image 만들기

   $docker build -t sample -f Dockerfile.base .           ---> 현재폴더에 있는(.) Dockerfiel.base 파일로 부터 이미지 만들기

     (단, 파일명이 Dockerfile 이외인 경우에는 Docker Hub에서 이미지의 자동생성기능을 사용할 수 없다)고 한다... 잘 이해가 안감


#43. Dockerfile 작성시 RUN 명령어 사용법

     1) Shell 형식으로 기술

         #Nginx 설치

         RUN apt -get install -y nginx


     2) Exec 형식으로 기술

        - Shell 형식으로 명령을 기술하면, /bin/sh 에서 실행되지만, Exec 형식으로 기술하면 쉘을 경유하지 않고 직접 실행한다.

           따라서, 명령인자에 환경변수값을 지정할 수 없다.

           실행하고 싶은 명령을  json배열로 지정해야 한다.

           #Nginx 설치

           RUN ["/bin/bash", "-c", "apt -get install -y nginx"]

       

#44. Docker image 생성시에 어떤 명령이 실행되는지 확인

    $docker history [이미지명]

    



Docker Compose

: 여러 (의존관계에 있는) 컨테이너를 한번에 만들거나 모아서 관리하기 위한 툴

  - compose 정의파일은 web application의 의존관계 (데이터베이스, 큐, 캐쉬, 애플리케이션 등)를 모아서 설정할 수 있음

  - 이 정의 파일을 바탕으로 docker-compose 명령을 실행하면 여러개의 컨테이너를 모아서 시작, 중지 할 수 있음

  $docker-compose up          ---> 컨테이너 시작(이미지 다운로드 및 빌드)

  $docker-compose ps           ---> 가동중인 컨테이너의 상태 확인

  $docker-compose stop        ---> 여러 컨테이너 정지

  $docker-compose down      ---> docker compose에서 이용한 리소스 삭제  


  

 Docker Compose 를 위한 yaml 작성방법

   - 이미지 빌드

     : 이미지의 작성을 Dockerfile에 기술하고, 그것을 자동으로 빌드하여 베이스 이미지로 지정할때 build 를 지정한다.

 docker-compose.yaml

 services:

        webserver:

                 build: . 

 Dockerfile

 FROM ubuntu

  위와 같이 파일 구성을 한 후에 아래명령어로 컨테이너 생성 한다.

  $docker-compose up --build


    - 다른이름의 Dockerfile 과 context 지정

       : dockerfile이 있는 디렉토리나 git repository url 을 context 로 지정하고,

         다른이름의 Dockerfile 을 dockerfile 에 지정한다.

 docker-compose.yaml

 services:

        webserver:

                 build:

                     context: /test

                     dockerfile: Dockerfile-other


     - 빌드시의 인수지정

        : docker image 를 빌드할때 args 로 인수를 지정할 수 있다.

 docker-compose.yaml

 services:

        webserver:

                 build:

                     args: 

                         projectno: 1

                         user: reo


   

     - 컨테이너간 연결( links )

    : 다른 컨테이너에 대한 링크기능을 사용하여 연결하고 싶을때는 links를 사용하여 연결할 컨테이너명을 설정한다.

      logserver 라는 이름의 컨테이너와 링크시키고 싶을때  아래와 같이 지정하고  alias 를 지정하고 싶을때는  (서비스명:alias명) 으로 지정한다.

docker-compose.yaml

 links:

      - logserver

      - logserver:log01

  

     - 컨테이너간 통신(ports/ expose)

       : 컨테이너가 공개하는 포트는 ports 로 지정한다.

         (host 포트:컨테이너 포트)   또는   (컨테이너 포트)  만 지정

        (컨테이너 포트) 만 지정한 경우 host 포트는 랜덤지정임         

        

         !!!주의사항!!!

          yaml 파일은 xx:yy 형식을 시간으로 해석하므로 port번호 설정시에는 반드시 겹따옴표(" ")로 문자열 정의해야 함

         

docker-compose.yaml

 ports:

      - "3000"

      - "8000:8000"


         : host 에 대한 port 는 공개하지 않고, 링크기능을 사용하여 연결하는 컨테이너에게만 port를 공개할때 expose 를 사용한다.

           즉, 컨테이너 내부에만 공개하는 port 지정시 사용


     - 서비스의 의존관계 정의 ( depends_on )

         : 여러 서비스의 의존관계 정의

           webserver 컨테이너를 시작하기 전에 db 컨테이너와 redis 컨테이너를 시작하고 싶을때 아래와 같이 정의한다.

docker-compose.yaml

 services:

      webserver:

            build: .

            depends_on:

                 - db

                 - redis

      redis :

          image: redis

      db :

          image: postgress

         !!!주의사항!!!

           depends_on 은 컨테이너의 시작순서만 제어할 뿐, 컨테이너상의 애플리케이션이 이용가능해질때까지 기다리고 제어를 하지는 않는다.

           따라서, 의존관계에 있는 애플리케이션에서 이에 대한 대비가 필요하다.


     - 컨테이너 데이터 관리 ( volumes / volumes_from ) 

       : 컨테이너에 볼륨을 마운트할 때는 volumes 를 지정합니다. 

         host 측에서 마운트할 경로를 지정하려면 (host 디렉토리경로 : 컨테이너 디렉토리경로) 를 지정한다.    

docker-compose.yaml

volumes :

      - /var/lib/mysql

      - app/ : /tmp/test/app 

      - test/ : /tmp/test/ : ro           ---> 읽기전용지정




#45. Docker compose 버젼 확인

    $docker-compose --version



#45. Docker compose 의 주요 sub 명령어

 sub 명령어 

 설명 

 up

 컨테이너 생성/시작

 ps

 컨테이너 목록 표시

 logs 

 컨테이너 로그 출력 

 run 

 컨테이너 실행 

 start 

 컨테이너 시작 

 stop 

 컨테이너 정지

 restart 

 컨테이너 재시작 

 pause 

 컨테이너 일시정지 

 unpause 

 컨테이너 재가동 

 port

 공개 포트 번호 표시 

 config 

 구성확인 

 kill 

 실행중인 컨테이너 강제 중지 

 rm 

 컨테이너 삭제 

 down 

 리소스 삭제 


















'DevOps' 카테고리의 다른 글

docker - swarm/compose/service/stack  (0) 2019.06.07
Docker Error  (0) 2019.06.05
Docker 명령어 정리  (2) 2019.03.21
쿠버네티스 기존 리소스 수정  (0) 2019.02.08
쿠버네티스 명령어 #6  (0) 2019.01.31
쿠버네티스 구조  (0) 2019.01.10
  1. 김병국 2019.12.18 16:59

    자세한 설명에 도움 받고 갑니다.

  2. ㅇㅇ 2020.04.06 17:24

    감사합니다


$kubectl edit

   기본 편집기에서 객체의 매니페스트 파일을 연다.

   변경한 후, 파일을 저장하고 편집기를 종료하면 오브젝트가 갱신된다.

    ex) kubectl edit deployment kubia


$kubectl patch

    객체의 개별 속성을 수정한다.

    ex) kubectl patch deployment kubia -p '{"spec": {"minReadySeconds": 10 }}'


$kubectl apply

     전체 yaml 또는 json 파일의 속성 값을 적용해 객체를 수정한다.

      yaml , json에 정의된 객체가 아직 존재하지 않으면 생성된다.

     이 파일에는 리소스의 전체 정의가 포함돼야 한다.

     ex) kubectl apply -f kubia-deployment-v2.yaml


$kubectl replace

    객체를 yaml, json 파일의 새 객체로 바꾼다. 

    apply 명령과 달리 해당 명령은 객체가 존재해야 한다. 그렇지 않으면 오류를 출력한다.

      ex) kubectl replace -f kubia-deployment-v2.yaml


$kubectl replace

     pod, replicationcontroller 의 템플릿, 디플로이먼트, 데몬셋, 잡 또는 레플리카셋에 정의된 컨테이너 이미지를 변경한다.

      ex) kubectl set image deployment kubia nodejs=iamreob/kubia:v4







'DevOps' 카테고리의 다른 글

Docker Error  (0) 2019.06.05
Docker 명령어 정리  (2) 2019.03.21
쿠버네티스 기존 리소스 수정  (0) 2019.02.08
쿠버네티스 명령어 #6  (0) 2019.01.31
쿠버네티스 구조  (0) 2019.01.10
pod-레플리케이션컨트롤러-서비스  (0) 2019.01.10

출처 : kubernetes in action


Downward API

 - 해당 POD 의 내부에서 실행중인 프로세스에 POD 자체의 메타 데이터를 노출할 수 있다.

    . pod 명

    . pod ip 주소

    . pod 네임스페이스

    . pod 가 실행되고 있는 Node 명

      ...


1) 환경변수를 통한 메타데이터 노출

apiVersion: v1

kind: Pod

metadata:

  name: 포드명

spec:

  containers:

  - name: main

    image: ㅇㅇㅇ

    command: ㅇㅇㅇ

    resources:

      requests:

         ....

      limits:

         ....

    env:

    - name: POD_NAME

      valueFrom:

        fieldRef:

          fieldPath: metadata.name

    - name: POD_NAMESPACE

      valueFrom:

        fieldRef:

          fieldPath: metadata.namespace

    .....



   2) downward API 볼륨 내의 file을 통한 메타데이터 전달

       




Deployment

- 애플리케이션을 배포하고 이를 선언적으로 업데이트하는데 사용하는 상위 수준의 리소스

- deployment 를 만들면 레플리카셋 리소스가 아래에 만들어짐

   (레플리카셋은 pod를 복제하고 관리)

- deployment 가 필요한 이유는...

   : 애플리케이션을 업데이트할때 추가적인 ReplicationController 가 필요하고, 이전 ReplicationController와 잘 조화되게끔 컨트롤러를 조정해야 한다.

     즉, 전체적으로 통제할 무언가가 필요하고 그 역할을 deployment가 담당한다.

     (deployment 가 직접 수행하는 것은 아니고 쿠버네티스 컨트롤 플레인에서 실행하는 컨트롤러 프로세스가 이를 수행)


- deployment 상태 확인 명령어

   $kubectl rollout status deployment [deployment리소스명]



- Deployment 전략

  > Recreate 전략

     : 새 pod를 만들기 전에 기존 pod를 삭제

       애플리케이션이 여러 버젼을 동시에 실행할 수 없으며, 새 버젼을 시작하기 전에 이전버젼을 완전히 중지해야 하는경우 사용

       애플리케이션 down time 짧게 포함된다.


   > RollingUpdate 전략

      : 오래된 pod를 하나씩 제거하는 동시에 새로운 pod를 추가해 전체 업데이트 프로세스에 걸쳐 애플리케이션을 사용할 수 있도로한다.



Deployment의 롤아웃 히스토리 보여주기

   - deployment는 리비전 히스토리를 유지하므로 롤아웃, 롤백이 가능하다.

   - 히스토리는 레플리카셋 내부에 저장된다.

  $kubectl rollout history deployment [deployment명]


특정 Deployment 리비전으로 롤백하기

    $kubectl rollout undo deployment [deployment명] --to-revision=1

  - 비활성 레플리카셋을 삭제하면 롤백할 수 없으므로 삭제하면 안된다.

 

롤링 업데이트 전략의 maxSurge와 maxUnavailable 속성

    - maxSurge

       : 배포에 구성된 원하는 복제본 수 위에 존재하도록 허용하는 포드 인스턴스 수를 결정한다.

         즉, 이값이 25% 이면 원하는 수보다 25% 더 많은 포드 인스턴스까지만 있을 수 있다.

              25%이고, 원하는 수가 4면, 최대 5개까지만 존재할 수 잇다는 것


    - maxUnavailable

       : 업데이트 중에 원하는 복제본 수에 비례하여 사용할 수 없는 포드 인스턴스 수를 결정한다.


롤아웃 프로세스 일시 중지

    - deployment 는 롤아웃 프로세스 중에 일시 중지될 수 있다.

      이렇게 하면 나머지 롤아웃을 진행하기 전에 새 버전이 제대로 작동하는지 확인 할 수 있다.

      $kubectl rollout pause deployment [deployment명]

    - 카나리아 릴리즈

      : 잘못된 버전의 애플리케이션을 롤아웃 하고 모든 사용자에게 영향을 줄 위험을 최소화하기 위한 기술

    - 롤아웃 재개

      $kubectl rollout resume deployment [deployment명]      


 




'DevOps' 카테고리의 다른 글

Docker 명령어 정리  (2) 2019.03.21
쿠버네티스 기존 리소스 수정  (0) 2019.02.08
쿠버네티스 명령어 #6  (0) 2019.01.31
쿠버네티스 구조  (0) 2019.01.10
pod-레플리케이션컨트롤러-서비스  (0) 2019.01.10
쿠버네티스 명령어#5  (0) 2019.01.02



apache poi(XSSFWorkbook API) 가 갖고 있는 메모리 이슈로 인해 full gc가 지속적으로 발생할 수 있다

이를 근본적으로 해결하기 위해서는 read 시에 메모리 사용 증대가 발생되지 않도록 개선된 무언가가 필요하다.

xml 처리 방식도 있고, 여러가지가 있지만 개인적으로 좋은 api를 발견  업무에 적용하여 해결하여서 공유하고자 한다.



출처는 https://github.com/monitorjbl/excel-streaming-reader


pom.xml에 아래 라이브러리 추가

(해당 라이브러리는 위의 git 에서 가져올 수 있다)

  <dependency>
    <groupId>com.monitorjbl</groupId>
    <artifactId>xlsx-streamer</artifactId>
    <version>2.1.0</version>
  </dependency>


결국엔 대량 데이터를 읽어오면서 대량의 메모리 이슈가 발생되므로

읽어오는 부분을 아래의 api를 적용하면 깔끔하게 해결되었음

(이해가 안되면.... 사용방법은 위 출처의 영문을 조금만 읽어보면 활용방법 파악이 될수 있다.)

import com.monitorjbl.xlsx.StreamingReader;

InputStream is = new FileInputStream(new File("/path/to/workbook.xlsx")); Workbook workbook = StreamingReader.builder() .rowCacheSize(100) // number of rows to keep in memory (defaults to 10) .bufferSize(4096) // buffer size to use when reading InputStream to file (defaults to 1024) .open(is); // InputStream or File for XLSX file (required)


'DevOps' 카테고리의 다른 글

쿠버네티스 기존 리소스 수정  (0) 2019.02.08
쿠버네티스 명령어 #6  (0) 2019.01.31
쿠버네티스 구조  (0) 2019.01.10
pod-레플리케이션컨트롤러-서비스  (0) 2019.01.10
쿠버네티스 명령어#5  (0) 2019.01.02
쿠버네티스 명령어 #4  (0) 2018.12.31

pod 는 한시적

pod가 삭제되거나, 실행중인노드가 실패하게 되면 등등... 레플리케이션컨트롤러가 손실된 pod를 새로운 pod로 대체한다.

대체 pod는 기존의 pod와는 다른 ip를 할당받는다.


서비스는 정적 ip를 얻고, 클라이언트는 이 정적 ip를 통해 서비스에 연결해야 pod의 일시성에 대비해서 정상적인 서비스가 가능하다.

즉, 서비스는 동일한 서비스를 제공하는 하나 이상의 pod 그룹의 정적 위치를 나타냄

'DevOps' 카테고리의 다른 글

쿠버네티스 명령어 #6  (0) 2019.01.31
쿠버네티스 구조  (0) 2019.01.10
pod-레플리케이션컨트롤러-서비스  (0) 2019.01.10
쿠버네티스 명령어#5  (0) 2019.01.02
쿠버네티스 명령어 #4  (0) 2018.12.31
Docker 명령어  (0) 2018.12.28


레디니스 프르브

  - pod를 위한

  - 라이브니스 프로브는 상태가 좋지 않은 컨테이너를 종료하고, 새로운 것으로 교체하여 pod의 상태를 좋게 유지한다.

    레디니스 프로브는 오직 pod가 요청을 수신할 수 있는 환경이 됐을때 수신한다.

  - pod의 레디니스 프로브가 실패하면, 해당 pod는 endpoint 오브젝트에서 제거된다.

  - 레디니스 프로브는 클라이언트가 정상 상태인 pod하고만 통신하게 하고, 시스템에 문제가 있다는 것을 알아차리지 못하게 한다. 


서비스를 통해 pod에 접속하지 못할때

  - 외부가 아닌 클러스터 안에서 클러스터IP를 대상으로 연결하고 있다는 것을 명심

  - 서비스가 액세스 가능한지 확인하기 위해 서비스 ip로 ping 보내는 것을 귀찮게 여기지 마라

  - readiness probe를 정의했다면 성공 여부를 확실히 확인하라

  - pod가 서비스의 일부분인지 확인하라(kubectl get endpoints)

  - 대상 port가 아닌 서비스에 의해 노출된 port에 연결하고 있는지를 확인하라

  - pod ip에 직접 연결을 시도해서 pod가 정확한 port의 연결을 수락하고 있는지 확인하라

  


Volume

- pod의 각 컨테이너에는 고유의 분리된 파일 시스템이 있다.

- 실제 데이터가 있는 디렉토리를 보존하기 위해서 저장소 volume을 정의한다.

- 볼륨은 pod의 컴포넌트이다.

- 독립적인 쿠버네티스 오브젝트가 아니며 스스로 생성하거나 삭제할 수 없다.

- volume의 라이프 사이클은 pod 와 같다



[뜬금 명령어]

 - 특정 리소스의 yaml 파일 확인을 위한 명령어 

   $kubectl get [리소스타입] [리소스명] -o yaml

    ex) kubectl get  pod podname -o yaml

          kubectl get configmap configmapname -o yaml


emptyDir 

- 동일한 pod에서 실행중인 컨테이너간에 파일을 공유할 때 유용



ConfigMap 

 - 설정 데이터를 저장하는 쿠버네티스 리소스

 

>ConfigMap을 구성하는 방법들

 1) pod들 중 하나로 ConfigMap을 사용

    $kubectl create configmap [configmap명] --from-literal=[key값]=[value값]


 2) 개별 파일(을 읽어와서) 내용으로 ConfigMap 엔트리 생성

    - 외부의 설정파일을 통해서 설정 데이터를 저장할 수 있다.

      $kubectl create configmap my-config --from-file = config-file.conf

        -> 위 명령어를 실행하면 kubectl 을 실행하는 디렉터리에서 config-file.conf를 찾는다.

        -> 파일이름이 맵의 키로 사용된다. 파일의 내용이 value 로...

        -> 수동으로 key명 지정도 가능하다.

             $kubectl create configmap my-config --from-file = customkey = config-file.conf


 3) 디렉토리에 있는 파일로 부터 ConfigMap 만들기
     - 파일 디렉토리에서 모든 파일을 가져올 수 있다.
       $kubectl create configmap my-config --from-file =/path/to/dir


 4) 위의 3가지 모두를 결합하여 구성할 수 있다.
     $kubectl create configmap my-config --from-file = config-file.conf --from-file =/path/to/dir --from-literal=xxx=yyy




>ConfigMap의 값을 pod의 컨테이너로 가져오는 방법

  1) 환경변수 설정 (valueFrom 필드사용)
apiVersion: v1

kind: Pod

metadata:

  name: fortune-env-from-configmap

spec:

  containers:

  - image: luksa/fortune:env

    env:

    - name: INTERVAL

      valueFrom: 

        configMapKeyRef:

          name: fortune-config

          key: sleep-interval

 

  2) configmap의 모든 항목을 한번에 환경변수로 전달하기

      - envFrom 속성을 사용

        spec:

            containers:

            - image: some-image

               envFrom:

               -  prefix: CONFIG_

                   configMapRef:

                        name: my-config-map


         ->결과는 configMap 의 key 값에 앞에 prefix 가 붙은 값으로의 환경변수가 컨테이너 내부에 존재하게 됨


    

    3) configmap 항목을 명령해 인자로 전달하기

         - 컨테이너에서 실행중인 메인 프로세서로 configMap의 값을 인자로 전달하는 방법임

           


     4) ConfigMap 엔트리를 파일로 노출하기 위해 ConfigMap Volume 사용

         - 설정파일들이 많을 경우에 사용

         - configMap 볼륨은 ConfigMap의 각 엔트리를 파일로 표시한다.

        


> ConfigMap을 사용해 볼륨을 통해 노출시키면 Pod를 다시 만들거나 Container를 다시 시작하지 않고도 설정을 업데이트 할 수 있음

    1)configmap 파일 수정

        $kubectl edit configmap [컨피그맵명]




Secret

- ConfigMap 과 유사 , key /value 쌍

- 일반설정 데이터를 저장할때는 ConfigMap 을 사용

- 중요한 , 민감한 데이터를 저장할때는 Secret을 사용


> secret 리소스 나열

  $kubectl get secret






'DevOps' 카테고리의 다른 글

쿠버네티스 구조  (0) 2019.01.10
pod-레플리케이션컨트롤러-서비스  (0) 2019.01.10
쿠버네티스 명령어#5  (0) 2019.01.02
쿠버네티스 명령어 #4  (0) 2018.12.31
Docker 명령어  (0) 2018.12.28
쿠버네티스 명령어#3  (0) 2018.12.27


- pod는 일회성

- 여러 pod가 단일 서비스를 제공할 경우, (클라이언트 입장에서)모든 pod는 단일 ip 주소를 통해 액세스 할 수 있어야 한다.


Kubernetes Service

- 동일한 서비스를 제공하는 pod group 에 단일 진입 점을 만들기 위해 생성하는 리소스

- 각 서비스에는 서비스가 존재하는 동안 절대로 변경되지 않는 ip 주소와 port 가 있다.

   클라이언트는  해당 IP 및 포트에 연결할 수 있고, 이런 연결은 해당 서비스를 지원하는 pod 중 하나로 라우팅 된다.

- 서비스는 오직 단일 port 뿐만 아니라, 여러개의 port 도 지원할 수 있다.


[Service의 주 목적 ]

 포드들의 그룹을 클러스터상의 포드에게 노출하는것.



- 원격접속

  $kubectl exec [pod명] 


- Client 로 부터 받은 요청을 매번 같은  pod로 요청하고 싶으면,  sessionAffinity 속성을 ClientIP 로 하면 된다.

   spec: 

       sessionAffinity: ClientIP (None 으로 하는 경우는 랜덤하게 됨)



- 포드의 환경변수 확인

   $kubectl exec [포드명] env


- pod 안으로 들어가기

   $kubectl exec -it [pod명] bash



- 클러스터 외부 서비스에 연결

   . 서비스는 pod를 직접 링크하지 않음

   . 서비스와 pod 사이에 endpoint라는 리소스가 위치함

   . endpoint는 서비스에 의해 노출되는 IP주소와 PORT의 목록임


- 서비스에 대한 상세정보 확인

   $kubectl describe svc [서비스명]


- 서비스의 endpoint 확인

 $kubectl get endpoints [서비스명]


- pod Selector 는 들어오는 연결을 리다이렉트할때 직접 사용되진 않고, ip와 port의 목록을 만드는데 사용된다.

  그리고 이 만들어진 목록이 endpoint에 저장된다. 

- pod Selector 없이 서비스를 만들었다면, 쿠버네티스는 endpoint 리소스 조차 만들지 못한다.



- 서비스가 외부에서 Access 가능하게 하는 방법

1) NodePort 서비스 사용

   . 서비스를 생성하고  타입을 NodePort 로 지정


- jsonPath 를 이용해 모든 노드의 ip 얻기

   $kubectl get nodes -o jsonpath='{.items[*].status.addresses[?(@.type=="ExternalIP")].address}'



2) 외부 로드밸런서를 이용한 서비스 사용

   . 서비스 타입을 LoadBalancer 로 지정

   . 로드밸런서는  자신만의 고유하면서 외부에서 액세스가 가능한 ip 주소를 갖고 모든 연결을 서비스로 리다이렉트 한다.

   

   - externalTrafficPolicy

     : 외부 클라이언트가 서비스로 노드포트를 통해 연결할 때, 임의로 선택된 pod는 연결요청을 받았던 같은 node에서 실행될 수도 아닐수도 있다.

       이를 요청받은 노드에 있는 pod에서 실행되도록 하기 위해 서비스 spec 에 externalTrafficPolicy: Local   을 지정하면 , 로컬내에서  실행되고 있는 pod를 호출하게 된다.

      단, 로컬에 pod가 없으면 대기한다.

            그리고, 이렇게 연결할때 단점은, 일반적으로의 연결은 모든 pod에 걸쳐 전달되지만 이렇게 구성하면 모든 pod 가 되지 않는다.


3) Ingress 리소스를 이용한 방법

    . 필요한 이유 : 각 loadbalancer 서비스는 그 자신만의 외부 ip를 갖는 자체 로드밸런서를 요구하기 때문

    . Ingress 리소스를 작동시키려면, 클러스터에서 Ingress 컨트롤러를 실행해야 한다.

    

- 모든 네임스페이스의 pod 조회

  $kubectl get po --all-namespaces









   



'DevOps' 카테고리의 다른 글

pod-레플리케이션컨트롤러-서비스  (0) 2019.01.10
쿠버네티스 명령어#5  (0) 2019.01.02
쿠버네티스 명령어 #4  (0) 2018.12.31
Docker 명령어  (0) 2018.12.28
쿠버네티스 명령어#3  (0) 2018.12.27
쿠버네티스 명령어 #2  (0) 2018.12.27


- 도커 이미지 빌드

  Dockerfile을 만든 후 해당 디렉토리로 이동하여 다음 명령어를 입력하면 이미지 빌드 완료

1

docker build -t 이미지명 .


- 도커 파일(Dockerfile)

  . ENTRYPOINT 는 컨테이너가 시작되었을때 호출되어야 할 실행파일을 정의한다.

  . CMD는 ENTRYPOINT로 전달할 인자를 지정한다.

 

 

'DevOps' 카테고리의 다른 글

쿠버네티스 명령어#5  (0) 2019.01.02
쿠버네티스 명령어 #4  (0) 2018.12.31
Docker 명령어  (0) 2018.12.28
쿠버네티스 명령어#3  (0) 2018.12.27
쿠버네티스 명령어 #2  (0) 2018.12.27
kubernetes 명령어#1  (0) 2018.12.27

레플리케이션 컨트롤러

: pod가 항상 실행되도록 하는 쿠버네티스 리소스

  - 실행중인 pod의 수를 모니터링하고, 실제 원하는 갯수와 실행수가 일치하는지를 확인한다.

  - 라벨셀렉터와 매치되는 pod를 찾음 -> 매치되는 수와 원하는 수를 비교 -> 많거나 적으면, 생성 삭제 한다.

  - 3가지 필수요소

     1) 레플리케이션컨트롤러의 범위에 있는 pod를 결정하는 label Selector

     2) 실행해야 하는 pod의 원하는 수를 지정하는 복제본 수

     3) 새로운 pod 복제본을 만들때 사용되는 pod Template




- 레플리케이션 컨트롤러 목록 정보 얻기

  $kubectl get rc


- 레플리케이션 컨트롤러 상세 정보 확인

  $kubectl describe rc [rc명]


- 레플리케이션 컨트롤러의 yaml 정의 열기

  $kubectl edit rc [rc명]


- 레플리케이션 컨트롤러 스케일업(pod수 증가)

  $kubectl scale rc [rc명] --replicas=10


- 레플리케이션 컨트롤러 삭제

  1) 레플리케이션 컨트롤러와 pod를 모두 삭제

    $kubectl delete rc [rc명]

  2) 레플리케이션 컨트롤러만 삭제하고 pod는 계속 실행

    $kubectl delete rc [rc명] --cascade=false



레플리카셋

: 차세대 레플리케이션 컨트롤러

  - 일반적으로 레플리카셋을 직접 만들지는 않음 / deployment 할때 생성됨

  - 레플리케이션컨트롤러와 똑같이 동작

     그러나, 더 풍부한 표현식 pod selector 를 갖음

      ex) env=p , env=k   이 조건에 대해서

            레플리케이션 컨트롤러는 포드를 위 2개 조건을 동시에 일치시킬 수 없다.

           그러나, 단일 레플리카셋 은 2개의 pod 세트와 일치시킬수 있으며,  단일 포드로 취급할 수 있다.

     ex ) env=*  ( 값과 상관없이 키 에 대한 일치)

          

- 레플리카셋 조회

  $kubectl get rs


- matchExpression 셀렉터

  spec:

  replicas: 3

  selector:

    matchExpressions:

      - key: app

        operator: In

        values:

         - k



4가지 연산자

 1) In : 라벨의 값이 지정된 값 중 하나와 일치해야 한다.

2) NotIn : 라벨의 값이 지정된 값과 일치해서는 안된다.

3) Exists : pod에는 지정된 key 가 있는 라벨이 포함되어야 한다. (값은 중요하지 않음)

4) DoesNotExist : pod에는 지정된 key가 있는 라벨을 포함하면 안된다.



- 레플리카셋 삭제

  $kubectl delete rs [rs명]

   레플리카셋 삭제하면 해당 pod도 삭제됨




데몬셋

- 각 노드에서 pod를 실행해야 하는 경우가 있음

   ex) 로그 수집기, 리소스 모니터 , kube-proxy

- 데몬셋은 각 노드에서 단일 pod 복제본만 실행하지만, 레플리카셋은 클러스터 전체에서 무작위로 분산시킨다.

- 데몬셋에 의해 만들어진 pod는 이미 대상 node가 지정되어 있고, 쿠버네티스 스케쥴러는 건너뛴다.

- 노드가 다운되더라도, 데몬셋은 어느 곳에서도 pod를 생성하지 않는다.

- 스케쥴을 불가능하게 만드는 속성은 스케쥴러에서만 유효하고, 데몬셋에서 만드는 pod는 스케쥴러와는 무관하다.



- 데몬셋 조회

  $kubectl get ds


- 노드에 라벨 적용하기

  $kubectl label node [노드명] aaa=bbb



잡(job)

 레플리케이션컨트롤러, 레플리카셋 , 데몬셋은 작업의 완료를 고려하지 않고, 계속적으로 타스크를 실행한다.

완료 가능한 타스크에서는 프로세스가 종료된 후 다시 시작하면 안된다. 이를 할 수 있게 해주는게 잡

 - job에서 관리하는 pod는 성공적으로 끝날때까지 재스케쥴 된다.

 - job 조회

   $kubectl get jobs


- job의 타스크가 완료되면 pod 는 더이상 running 하지 않고, Completed 상태로 된다.

  pod가 완료될때 삭제되지 않는 이유는 로그를 검사할 수 있기 위해서다

  (로그 확인 : kubectl logs [pod명] )


- job은 2개 이상의 pod인스턴스를 만들고, 병렬 또는 순차적으로 실행하도록 구성할 수 있다.

  이는 job spec의  completions 와 parallelism  속성으로 수행


spec:

  completions: 5

  parallelism: 2

  template:

    metadata:

      labels:

        app: batch-job


순차적으로 처리를 위해서 completions에 설정


-job이 실행되는 동안에도 scaling 이 가능하다.

 


- 쿠버네티스의 cron 처리는, CronJob 

apiVersion: batch/v1beta1

kind: CronJob

metadata:

  name: 배치잡명

spec:

  schedule: "0,10,20,30,40,50,60 * * * *"

  jobTemplate:

    spec:

      template:

        metadata:

          labels:

            app: ㅇㅇㅇㅇ

        spec:

          restartPolicy: OnFailure

          containers:

          - name: main

            image: 이미지명








'DevOps' 카테고리의 다른 글

쿠버네티스 명령어 #4  (0) 2018.12.31
Docker 명령어  (0) 2018.12.28
쿠버네티스 명령어#3  (0) 2018.12.27
쿠버네티스 명령어 #2  (0) 2018.12.27
kubernetes 명령어#1  (0) 2018.12.27
미니큐브 설치 맥  (0) 2018.12.23

+ Recent posts