반응형

출처: https://seongjin.me/how-to-prepare-cka-exam/

 

Certified Kubernetes Administrator(CKA) 자격증 합격 후기 및 유용한 팁 (2022.02, v1.23)

CKA는 쿠버네티스 클러스터 관리 능력을 검증하는 대표적인 국제 자격증 중 하나다. 엔지니어 경험이 없는 초심자로서 이 CKA 자격증 시험에 도전하여 합격한 과정과 후기를 공유한다. 같은 시험

seongjin.me

 

 

CKA 자격증 시험은 쿠버네티스 기술을 관리하는 Linux Foundation 산하의 Cloud Native Computing Foundation(CNCF)에서 주관하며, 컨테이너 관리 도구인 쿠버네티스 클러스터의 관리 능력 검증을 목적으로 한다. 따라서 쿠버네티스 클러스터의 설치와 운영, 내부 리소스 배포 및 네트워크 설정, 그리고 클러스터에 발생한 문제 해결에 이르기까지 넓은 범위의 응용 지식을 다룬다. 또한 단순 이론 암기를 지양하고 철저한 실습 위주로 검증하므로 배움의 과정 자체에서도 얻을 것이 많다.

시험 진행 방식

시험 개요

  • Hands-on Practical Lab 형식의 온라인 원격 시험이다.
  •  120분 동안 약 15~20문제 가량을 풀어야 한다.
  • 100점 만점(100%) 중 66점(66%) 이상을 얻어야 한다.
  • 시험은 항상 최신 버전의 쿠버네티스 환경에서 진행된다. 만약 새 버전이 릴리즈 될 경우 시험 환경에는 4-8주 이내에 반영된다.
  • 1회 등록시 1년 이내에 총 2회까지 응시 가능하다. 1차에서 불합격해도 2차 기회가 주어진다.
  • 자격 유효기간은 3년이다.

응시 환경 체크

온라인 원격 시험이므로 시험을 치르는 주변 환경에 대해 상당히 엄격한 점검이 이루어진다. 아래 사항들을 꼼꼼히 살펴서 미리 준비해두자.

  • 응시자 외에 아무도 없는 격리된 개인 공간이어야 한다. 공공장소는 허용되지 않는다.
  • 시험 공간 4면에 책장, 액자, TV 등 시선을 끌만한 요소가 없어야 한다.
  • 책상 위의 불필요한 물품을 모두 치워야 한다. 내 경우엔 신분증도 신분 확인 후엔 치워야 했다. 단, 라벨 없는 투명한 물병은 허용되었다.
  • 신분 인증을 위해서는 시험 등록시 입력한 이름을 직접 확인 가능한 국가 공인 신분증이 필요하다. 어떤 언어로 입력했느냐에 따라 준비해야 할 신분증이 달라진다. 국문으로 입력했다면 주민등록증이나 국문 운전면허증으로 인증 가능하다. 만약 영문으로 입력했다면 여권 또는 영문 운전면허증을 반드시 준비하자. 얼굴 사진과 이름을 한 번에 확인 가능한 신분증이  권장된다.
  • 웹캠이 필수다. 별도의 웹캠이 없다면 가급적 15인치 이상의 대형 노트북 사용을 권장한다.
  • 시험 화면과 응시자 얼굴이 모두 실시간으로 감독관에게 전송된다. 인터넷 회선 속도와 연결 감도를 반드시 사전 점검해야 한다.
  • 8080/tcp, 4505/tcp, 4506/tcp 포트가 열려있어야 한다. 방화벽 이슈가 있는지 꼭 확인해보자.
  • 현재는 오직 1대의 모니터만 사용 가능하다. 노트북에 외장 모니터를 연결하는 것은 허용되지 않는다.
  • 내 경우에는 노트북 거치대와 블루투스 키보드, 터치패드 사용이 허용되었다.
  • 체크 과정에서 소요되는 시간은 주어진 시험 시간(120분)에 영향을 주지 않으므로 편안한 마음으로 진행하자.

시험 진행 환경 및 주의사항

실제 시험은 아래와 같은 UI 환경에서 진행된다. 이 내용은 2022년 8월, 쿠버네티스 v1.24 환경 기준으로 업데이트 된 내용임을 밝힌다.

새로 개편된 CKA 시험의 ExamUI 환경 (출처: Linux Foundation)

  • 응시자는 PSI Bridge Secure Browser를 통해 리눅스 기반의 VM에 원격 접속하여 시험을 치른다. 원격 응시 가능한 시스템 사양은 여기서 확인할 수 있다.
  • PSI Bridge Secure Browser 상단의 -, + 버튼으로 VM 화면의 글자 크기를 조정 가능하다. 이밖에 시험 화면 조정을 위한 방법도 함께 숙지하면 좋다.
  • VM에 포함된 터미널(Terminal)을 이용하여 문제 풀이를 진행한다.
  • 오픈북 용도로 VM에 포함된 브라우저(Firefox)를 이용할 수 있다. 오직 지정된 경로의 문서들만 이용 가능하다. 이밖의 다른 웹사이트 접속은 막혀있다. 번역본 문서 열람이 허가되지 않는 경우도 있었다고 하니 영문 문서에 익숙해지는 것이 좋다. 대신 이제는 한 번에 여러 탭으로 여러 문서를 동시에 참고할 수 있다.
  • 사전에 정리해 둔 북마크는 더 이상 사용할 수 없다. 미리 초기화 된 VM에 접속해서 시험을 치르므로 어쩔 수 없는 부분이다.
  • 시험용 VM의 터미널에서 복사/붙여넣기 단축키는 Ctrl+SHIFT+C, Ctrl+SHIFT+V 를 이용해야 한다. 이 단축키는 오직 터미널 안에서만 동작한다. 터미널 바깥에서는 Ctrl+C, Ctrl+V 를 이용한다. 단축키가 잘 듣지 않을 때엔 마우스 오른클릭을 이용하는 것이 좋다.
  • VM 내 브라우저(Firefox)에서 터미널로 복사-붙여넣기를 할 때 “Unsafe Paste” 경고가 뜬다. 이 경고는 그냥 무시해도 된다. 터미널의 Edit > Preferences > General 에서 Show unsafe paste dialog 옵션을 찾아 해제하면 경고가 뜨지 않는다.
  • 시험 화면의 우측 상단에 메모장(notepad) 기능이 있지만, 이전과 달리 VM 화면과 메모장 사이의 텍스트 복사 기능이 막혀있으므로 쓸 이유가 거의 없다.
  • 대신 VM에 포함되어 있는 텍스트 편집기(Mousepad)를 이용하자. 공식 문서의 샘플 YAML을 여기로 복사해서 편집한 뒤, 터미널의 vi 또는 vim 화면에 붙여넣는 식으로 활용할 수 있다.
  • VM 화면의 우측 상단에 보면 여러 개의 작업공간(Workspace)을 만들어 전환할 수 있는 버튼이 있다. 이걸 잘 활용하면 문서 참고용 Firefox 화면, YAML 편집 화면, 터미널 화면을 각각 넓게 구성해서 쓸 수 있다.
  • 각 문제마다 kubectl config set-context <컨텍스트명> 형태로 문제를 수행할 클러스터를 지정하도록 되어 있다. 이전 문제와 같은 클러스터에서 작업하게 되더라도 실수를 줄이는 차원에서 꼭 다시 실행해주자.
  • 2022년 8월 기준으로 시험용 클러스터의 OS는 Ubuntu 20.04로 지정되어 있다. 따라서 클러스터 설치 또는 업데이트 과제 수행시 패키지 관리를 apt로 해야 한다.
  • 각 문제마다 참고할 만한 공식 문서 링크가 함께 첨부되어 있다. 그러나 큰 도움은 되지 않으므로 https://kubernetes.io/docs/에서 필요한 문서를 직접 검색하는 것이 좋다.
  • 감독관과는 오직 채팅으로만 대화할 수 있다.

 

시험 준비 방법

리눅스 CLI 환경과 편집기에 적응하기

CKA 시험은 실제 구동되는 쿠버네티스 클러스터 환경에 직접 접속해서 문제를 해결하는 구성을 갖고 있다. 따라서 리눅스의 CLI 환경, 그리고 CLI를 통해 직접 사용 가능한 텍스트 편집기의 기초 사용법에 먼저 익숙해져야 한다. 리눅스 경험이 부족했던 내 경우에는 공부 기간 중 방송통신대학교에서 UNIX시스템 과목 수강을 병행하면서 파일 및 디렉터리 관리, 그리고 텍스트 탐색 및 편집 방법을 우선적으로 익혔다. 이 과정이 없었다면 이후의 학습 진행은 불가능했을 것이다.

CLI 환경에서의 텍스트 편집기는 vi 또는 vim을 주로 사용하게 된다. 이에 대한 사용법은 아래 블로그 포스팅들을 참고하여 익혔다.

컨테이너 기초 다지기

쿠버네티스는 컨테이너 오케스트레이션을 구현한 기술이다. 따라서 컨테이너와 도커, 네트워크에 대한 사전 지식이 필요하다.

내 경우에는 도커/쿠버네티스 온라인 부트캠프에서 조경민 매니저님께서 진행하신 도커 강의와, Eric Han님의 기술 블로그가 무척 큰 도움이 되었다. 만약 도커가 처음이라면, 아래 Eric Han님의 두 포스팅을 참고하면 좋다. 시간이 걸리더라도 차근차근 읽어보자.

도커를 통해 컨테이너 기반의 간단한 애플리케이션 배포를 직접 시험해보고 싶은 경우를 위해 예전에 연재했던 블로그 포스팅들도 함께 공유한다.

모두가 아는 '그 강의'로 시작하기

CKA 시험 후기를 찾아보면 반드시 언급되는 강의가 있다. 모두가 알고 모두가 추천하는 그 강의, 바로 Mumshad Mannambeth의 Certified Kubernetes Administrator (CKA) with Practice Tests다. 실제 수강해보니 그 명성 답게 유익한 강의였다.

이 강의는 쿠버네티스의 핵심 컨셉은 물론 클러스터의 주요 리소스들에 대한 기초적인 운용 방법을 명료하게 안내해준다. 커리큘럼이 체계적으로 잘 정비되어 있고, 영상 강의 내용을 복기할 수 있는 간편한 실습 환경도 함께 겸비하고 있다. KodeKloud를 통해 수십 가지 유형의 클러스터 실습 환경을 제공하며, 실제 시험 문제와 유사한 구성을 갖춘 Mock Exams  Lightning Labs도 포함되어 있다. 할인가 기준 2만 원 미만의 가격이 믿기지 않을 정도다.

아는 내용이라고 건너뛰지 말고 가급적 하나하나 찬찬히 들여다보길 권한다. 빽빽하게 구성된 커리큘럼 특성상 중간에 대충 넘겨짚고 넘어갔다가 나중에 어려움을 겪을 수 있다. 또한 강의 영상에서 한글 자막이 지원되지 않으므로 영어 독해 및 청해 능력이 필요하다. 영문 자막도 자동 생성 기반이어서 때때로 부정확한 내용이 출력될 수 있다는 점에 유의하자.

배운 것을 내 언어로 정리하기

모든 공부의 과정이 대체로 그렇듯이, 초반의 기초 지식을 익히는 시간이 가장 지루하고 힘들다. 그러나 이 단계를 잘 넘겨서 내것으로 소화해야 이후에 익혀야 할 정보량에 압도되지 않는다. 특히 클러스터의 주요 구성요소들에 대한 개괄적인 이해가 있어야 최근 시험에서 비중이 높아진 트러블슈팅 상황에도 빠르게 대처할 수 있다.

이 블로그에서는 쿠버네티스의 기초 구성요소에 대해 그동안 공부하고 익힌 내용을 kubernetes 태그에 모아두고 있다. 어디선가 얻은 내용을 단순 요약하기보단 시간이 걸리더라도 부족하게나마 내 언어로 정리하기 위해 애썼다. 지난한 과정이었지만, 덕분에 실습 단계에서도 내게 필요한 정보를 빠르게 캐치하여 배움을 수월하게 이어갈 수 있었다.

비록 자격증 시험의 모든 범위를 다루고 있진 않지만, 입문 과정에서 조금이라도 도움이 될 수 있으리라 생각되어 작성글 목록을 공유한다. 앞서 소개한 Mumshad의 강의에서도 이 내용들을 대부분 다루고 있다.

실습, 그리고 또 실습하기

터미널에서 직접 클러스터를 다루며 평가받는 시험이므로 반복적인 실습이 반드시 필요하다.

위에서 소개한 유데미 강의를 수강했다면 Mock Exams  Lightning Labs를 꼭 진행해보자. 문제를 풀어나갈 시험 환경이 어떤 형태로 구성되는지, 어떠한 문제 유형을 다루게 되는지 미리 적응할 수 있는 좋은 기회다. 실제로 경험해보니, 2022년 2월 기준으로 Mock Exam 2 Mock Exam 3의 난이도가 실제 시험에서 중간 또는 낮은 난이도의 문제들과 수준이 비슷했다. 틀리는 문제 없이, 넉넉한 여유 시간을 두고 풀 수 있을 때까지 반복 연습하는 것을 권한다. 높은 난이도의 문제를 대비하려면 아래에서 소개할 killer.sh를 이용하는게 좋다.

유데미 강의 없이 시험을 준비할 경우, 실습환경을 직접 구성해보는 것도 가능하다. 아래의 깃허브 리포지터리를 참고하자.

killer.sh 시뮬레이터 도전하기

CKA 시험을 등록하면 killer.sh 에서 문제 풀이 실습을 해볼 수 있는 무료 세션 2회분이 제공된다. 지금까지 배우고 연습한 것을 총정리한다는 마음으로 도전해보자.

이름부터 살벌한 시뮬레이터, killer.sh 접속 화면

많은 후기글에서 소개된 것처럼 killer.sh의 난이도는 상당히 높다. 그러나 대개는 하나의 문제 안에서 이것저것 해결해야 할 사항이 많거나, 일반적인 자격증 관련 강의에서 잘 다루지 않는 리소스 및 제약사항을 이용해야 하기에 까다로운 경우들에 속했다. 이를테면 podAntiAffinity를 이용하여 DaemonSet처럼 동작하는 Deployment를 구현하는 식이다. 실제로 경험해보니 시간만 충분하다면 쿠버네티스 공식 문서를 참고하며 풀어나갈 수 있는 문제들이었다.

killer.sh의 시뮬레이터는 리소스 디자인 및 배포, 정보 탐색, 클러스터 문제 해결 등 다양한 부문에서 빠른 시간 안에 실력을 점검하고 보완하기 좋은 구성을 갖췄다. 그러니 1회차에는 시간 제한에 얽매이지 말고 모든 문제들을 직접 스스로 풀어본 뒤, 2회차에서 시간 내 완료에 도전해보길 권한다. 나는 시험 전날 2회차를 진행하면서 25개 중 21개의 문제를 120분 안에 해결했고, 다음날 시험 과정에서 아무런 어려움을 겪지 않았다.

시험에 유용한 팁 소개

kubectl 단축어와 자동 완성기능 이용하기

2022년 들어 기존 시험 환경에 응시자의 편의를 위한 요소들이 새로 추가되었다.

  • kubectl에 대한 단축어(alias) k를 모든 클러스터에서 바로 사용할 수 있다.
  • kubectl 명령에 대한 셸 자동완성(Bash autocompletion) 기능도 바로 사용할 수 있다.
  • YAML 또는 JSON 작업을 위한 jq, 그밖에 tmux와 curl, wget, man이 기본 지원된다.

vim 설정파일 추가하기

아래 내용은 2022년 7월 전후로 시험 환경에 기본 적용된 사항이다. 그러나 만약을 대비하여 설정 방법을 남겨둔다.

시험 특성상 대부분의 문제 풀이 과정에서 YAML 파일을 편집하게 된다. 따라서 시험이 시작되면 처음 1분을 에디터 환경 편집에 할애하면 좋다. vim 기준으로 시험 과정에서 내가 사용한 설정값은 다음과 같다.

# tab을 2칸으로 설정
set tabstop=2

# tab 사용시 발생하는 공백을 띄어쓰기(스페이스)로 채움
set expandtab

# shift(>, >>, <, << 등)를 2칸으로 설정
set shiftwidth=2

위 내용을 외워서 과제 수행용 노드에 ~/.vimrc 파일로 저장해 두면 편집 작업이 한결 수월해진다.

kubectl의 달인이 되기

17개 내외의 문제를 해결하기에 120분의 시간은 조금 빡빡한 편이다. 조금이라도 시간을 절약하려면 가능한 한 많은 리소스 작업을 kubectl 명령 만으로 해결해낼 수 있어야 한다.

시험에서 다루는 리소스들 가운데 멀티 컨테이너 파드와 PV, PVC, 그리고 NetworkPolicy 정도를 제외하면 대부분 kubectl을 이용하여 빠르게 생성할 수 있다. 또한 --dry-run=client -o yaml 플래그와 결합하면 쿠버네티스 공식 문서 없이도 필요한 리소스의 기본 골격을 바로 뽑아서 편집할 수 있게 된다. 쿠버네티스 자격 시험에서 시간 관리의 성패는 결국 kubectl을 얼마나 빠르게 잘 활용하느냐에 달려 있다.

kubectl Cheat Sheet를 반드시 참고하자. 실제로 몇몇 문제는 여기에 기재된 명령어 만으로 바로 해결이 가능한 경우도 있었다.

JSONPath 익히기

CKA 시험에는 클러스터/노드/리소스 관련 특정 정보를 찾아 양식에 맞게 가공하여 제출하는 문제가 반드시 출제된다. kubectl get <리소스+리소스명> -o json 명령으로 받아온 출력물을 뒤져서 답안을 한땀한땀 써내려 가는 것은 촉박한 시험 환경에선 무척 수고로운 일이다.

이럴 때 내게 필요한 정보만 가공해서 빠르게 출력시키는 수단으로 JSONPath를 익혀두면 도움이 된다. 내 경우에는 시험 중에 특정 리소스의 정보를 찾아 주어진 조건대로 정렬해서 파일로 제출하는 형태의 문제를 자주 만났는데, 이걸 익혀둔 덕분에 정말 많은 시간과 노력을 절약할 수 있었다.

아래의 공식 문서에서 kubectl 명령과 JSONPath를 어떻게 결합하여 쓸 수 있는지 확인할 수 있다. 보다 디테일한 사용 방법 또한 다른 포스팅에서 정리하여 두었으니 함께 참고하면 도움이 될 것이다.

실수 줄이기

긴장도가 높은 환경에서 시간 제한을 두고 문제를 풀다 보면 의도치 않게 실수가 생길 수도 있다. 아래의 체크리스트를 반드시 떠올리자.

  1. 내 리소스가 올바른 클러스터(컨텍스트)에 만들어졌는가?
  2. 내 리소스가 올바른 네임스페이스에 만들어졌는가?
  3. 내 리소스가 문제에 제시된 대로 잘 동작하고 있는가?
  4. 내 리소스의 이름에 오탈자는 없는가?
  5. 파일로 제출하는 답안의 경우, 해당 파일에 필요한 내용이 올바르게 들어가 있는가?

알아두면 좋은 핵심 문제 유형

etcd 스냅샷 생성 및 복구

지정된 클러스터의 마스터 노드 etcd 백업 및 복원 방법을 반드시 익혀두자. 배점도 크기 때문에 놓치면 눈물 난다. 나는 etcdctl API의 버전 3 기준으로 CA인증서, 서버인증서 및 키파일 경로를 포함하여 snapshot 생성하고 복원하는 명령어 전체를 매뉴얼 없이 바로 입력 가능하도록 연습했다.

클러스터 노드 업그레이드

마스터 또는 워커 노드의 업그레이드 절차를 숙지하자. 공식 문서에 방법이 상세하게 안내되어 있으므로 참고하여 차근차근 진행하면 된다. 특히 업그레이드 과정 중간에 노드의 drain과 cordon, uncordon 절차를 반드시 따라야 한다.

파드 간 네트워크 구성

Service와 Ingress, 그리고 NetworkPolicy를 이용한 파드 간 네트워크 구성을 반드시 실습해보기 바란다. 이 유형은 위에서 소개한 유데미 강의 만으로는 커버되지 않으므로 killer.sh 또는 직접 구성한 클러스터를 통해 실습하는 것이 좋다. 내 경우에는 아래의 공식 문서에서 많은 도움을 얻었다.

로그 스트리밍용 사이드카(Sidecar) 컨테이너 구현

emptyDir 또는 hostPath 유형의 공유 볼륨을 이용하여 로깅 에이전트 기능을 하는 사이드카(Sidecar) 컨테이너 구현도 꼭 연습해보자. 이를 위해서는 멀티 컨테이너 파드를 구성하는 방법, 그리고 이 컨테이너들이 함께 공유하는 볼륨 설정법을 알아야 한다. 아래의 공식 문서와 블로그 포스팅을 각각 참고하자.

트러블슈팅(Troubleshooting)

2020년 9월부터 트러블슈팅이 CKA 시험에서 가장 큰 채점 비중(30%)을 차지하게 되었다. 66% 이상의 점수를 획득해야 하는 시험 구조상, 트러블슈팅 문제를 반드시 준비해야만 합격을 기대할 수 있다.

CKA 과정에서 다루게 되는 트러블슈팅의 유형은 크게 네 가지로 나뉜다.

  1. 애플리케이션(파드/컨테이너) 구동 문제
  2. 컨트롤 플레인 구성 요소의 구동 문제
  3. 워커 노드의 구동 상태 확인 및 복원 문제
  4. 네트워크 문제

2022년 2월 기준으로, 내 경우에는 위의 1, 2, 3번 유형에 해당하는 트러블슈팅 문제를 모두 경험했다. 특히 컨트롤 플레인 관련 트러블이 해결되지 않으면 이어지는 2개 정도의 문제가 연이어 해결 불가능한 구조로 출제되었다. 따라서 각 유형 별로 문제의 근원을 탐지하는 방법을 반드시 학습해 두어야 한다. 유데미 강의 또는 killer.sh에서 트러블슈팅을 실습해 볼 수 있으며, 아래의 공식 문서들 또한 문제 해결에 도움이 된다.

반응형

'DevOps' 카테고리의 다른 글

k8s Architecture  (0) 2023.06.15
Iaas, paas, saas 차이  (0) 2019.12.18
CentOS 에서 yum-config-manager: command not found  (0) 2019.09.02
centos 7 virtualbox guest additions 해결및 공유폴더설정완료  (0) 2019.08.26
Devops roadmap  (0) 2019.06.25
반응형

출처 : 쿠버네티스 | 쿠버네티스 아키텍처 :: 쉽지않은 개발 블로그 (tistory.com)

 

쿠버네티스 | 쿠버네티스 아키텍처

쿠버네티스를 정리함에 있어서 기본적으로 쿠버네티스가 내부적으로 어떻게 동작하는지에 대해서 알아보기 위해 정리하는 시간을 가지게 되었습니다. 쿠버네티스 구성 쿠버네티스는 다음과

no-easy-dev.tistory.com

 

너무 깔끔하게 잘 정리되어 있어 퍼옵니다. 

정리를 잘 하려면 역시 명확한 이해가 필요하다!!!

 

 

쿠버네티스를 정리함에 있어서 기본적으로 쿠버네티스가 내부적으로 어떻게 동작하는지에 대해서 알아보기 위해 정리하는 시간을 가지게 되었습니다.

 

쿠버네티스 구성

쿠버네티스는 다음과 같이 크게 Master Node 2가지로 구성됩니다.

 

 

위의 그림처럼 사용자는 kubectl이라는 것을 이용하여 쿠버네티스 클러스터와 통신을 하게 됩니다.

클러스터 내의 Master는 쿠버네티스의 설정 환경을 저장하고 전체 클러스터를 관리하는 역할을 맡고 있고, 각 Node들에서는 쿠버네티스 위에서 동작하는 워크로드들이 실행되게 됩니다.

 

그렇다면 좀 더 자세하게 Master에서는 어떻게 해서 위에서 설명한 역할들을 수행하고 있고 마찬가지로 Node에서는 어떻게 워크로드들이 실행되게 되는지 알아보겠습니다.

 

쿠버네티스 기본 개념

Master와 Node에 대해서 알기 전에 쿠버네티스의 기본 개념에 대해서 알고 넘어가도록 하겠습니다.

 

쿠버네티스의 기본 개념은 desired state(원하는 상태)라는 개념입니다.

원하는 상태라 함은 관리자가 바라는 환경을 의미하고, 좀 더 구체적으로는 어떤 서비스가 얼마나 많이 서버에 떠있으면 좋을지?
몇 번 포트로 서비스하기를 원하는지 등을 나타냅니다.

 

기본적으로 쿠버네티스틑 내가 원하는 상태(Desired State) 현재 상태(Current State)를 비교하고, 만약 원하는 상태와 현재 상태가 다르다면 현재 상태를 원하는 상태로 변경하는 기능을 수행합니다.

즉, 쿠버네티스는 항상 우리가 원하는 상태로 현재 상태를 유지한다고 생각하면 될 것 같습니다.

 

 

그렇다면 이제부터는 어떻게 위와 같은 기능들이 수행되는지 알아보도록 하겠습니다.

 

Master

위에서 Master는 쿠버네티스의 설정 환경을 저장하고 전체 클러스터를 관리하는 역할을 맡고 있다고 설명하였습니다.

쿠버네티스는 MSA(Microservices Architecture) 형태로 설계되어 Master 내부에는 다음과 같이 나뉘어 있습니다.

 

 

위의 그림처럼 Master 내부에는 Api Server, Controller, Scheduler, etcd라는 것들이 존재합니다.

 

그렇다면 어떻게 동작하게 되는지 간단한 예시를 통해 알아보도록 하겠습니다.

 

Api Server

우리는 현재 아무것도 올라가 있지 않은 쿠버네티스 클러스터에 파이썬 애플리케이션을 올리는 요청을 보냈다고 가정을 하겠습니다.

요청을 보내게 되면 다음과 같이 진행되는 것을 알 수 있습니다.

 

 

  1. 관리자는 Python App을 띄우도록 하는 Yaml파일을 작성하여 kubectl를 이용하여 쿠버네티스 클러스터에 요청을 하게 됩니다.
  2. 우리가 보낸 요청은 Api Server가 받게 되고 etcd라는 key, value저장소에 어떤 상태가 되어야 하는지를 저장합니다.
앞으로도 계속 나오겠지만 쿠버네티스의 모든 요청들은 Api Server을 통해서 수행되게 됩니다.

 

etcd는 key, value저장소입니다.

https://www.redhat.com/ko/topics/containers/what-is-etcd

쿠버네티스 클러스터의 모든 상태에 대한 정보를 저장하고 있습니다.

 

Controller

Controller는 위에서 말씀드렸던 Desired State를 유지하기 위해 지속적으로 변경사항이 있는지 확인하게 됩니다.

 

 

  1. Controller는 etcd에 저장되어있는 내용을 지속적으로 확인하고 있습니다.
  2. 위의 그림처럼 확인된 내용과 현재 상태가 다를 경우 위에서 설명한 Desired State를 유지하기 위한 조치를 취하게 됩니다.
Controller에는 각 워크로드들에 대한 컨트롤러가 존재하여 각각 모니터링을 하게 됩니다.
따라서 위의 그림에서처럼 Pod가 띄워져야 한다는 상태는 Pod Controller가 확인하여 현재 상태와 비교하게 되는 것입니다.

 

Scheduler

Scheduler는 위의 Controller에서 새로운 워크로드(Pod)를 띄워야 한다고 했을 때 어떤 Node에 띄워야 하는지를 결정하게 됩니다.

 

 

위 그림처럼 새로운 서비스를 띄위기에 가장 효율적인 Node에 띄워지도록 지정하게 됩니다.

 

 

여기까지 각 Api Server, Controller, Scheduler, etcd를 통해서 Master에서는 쿠버네티스의 설정 환경을 저장하고 전체 클러스터를 관리하는 역할을 수행하게 됩니다.

 

Node

그럼 다음으로는 실제 워크로드들을 실행하게 되는 Node에 대해서 알아보도록 하겠습니다.

 

 

각 Node들에는 기본적으로 Kube-Proxy와 Kubelet 그리고 컨테이너 런타임이 존재합니다. 

그리고 현재는 컨테이너 런타임으로 Docker를 사용하고 있는것을 그림을 통해 확인 할 수 있습니다.

 

Kubelet

Kubelet은 파드에서 컨테이너가 확실하게 동작하도록 관리합니다.

컨트롤 플레인(Master)에서 노드에 작업을 요청하는 경우 Kubelet이 이 작업을 실행합니다.

 

Kube-Proxy

노드로 들어오거는 네트워크 트래픽을 적절한 컨테이너로 라우팅하고, 로드밸런싱등 노드로 들어오고 나가는 네트워크 트래픽을 프록시하고, 노드와 마스터간의 네트워크 통신을 관리합니다.

 

 

위의 과정들을 다시한번 정리해 본다면 다음과 같습니다.

 

 

위의 그림을 통해서 Pod하나를 띄우는 과정에서도 쿠버네티스 내부의 여러개의 마이크로 서비스들이 각자의 역활을 수행하여 동작한다는것을 확인할 수 있습니다.

 

 

반응형
반응형

출처: https://wnsgml972.github.io/network/network_cloud-computing.html

 

Iaas, paas, saas 차이를 너무 잘 정리해 놓은 글이 있어 보관차원에서 퍼옵니다.

 

IaaS, PaaS, SaaS란 무엇인가?

정리

  • 클라우드 컴퓨팅이 도입되면서 최근에 자주 들을 수 있는 용어입니다.
  • IT 인프라의 여러 필요한 구성 요소 중 예전에는 모두 사용자가 관리해야만 했지만, 이제는 일정 부분을 클라우드에서 내려받는 형태가 많이 도입되었습니다.
  • 얼마만큼 사용자가 관리하고 얼마만큼 클라우드에서 제공받는가에 따라 다음과 같이 네 가지로 나누어져 있습니다.
  • 위의 그림에서 보이는 데로 노란색의 You manage는 사용자가 관리해야 할 부분이고, 흰색의 Managed by vendor는 기업(클라우드)에서 관리해주는 부분입니다.

 

Packaged Software

그림에서 보이는 것과 같이 직접 인프라와 플랫폼, 어플리케이션까지 모두 구성하여 관리하는 모델을 의미합니다.

정리

  • 물리적인 장치, 하드웨어(CPU, RAM, Storage, Network device 등등)을 모두 직접 구매해야 합니다.
  • 직접 OS를 설치해야 합니다.
  • 네트워크 환경을 직접적으로 구성해야 합니다.
  • 서버 관리를 직접적으로 해야 합니다. (트래픽, 프로지버닝 등등)
  • 이런 모든 것을 직접 사용자가 다 준비해야 하기 때문에 매우 큰 시간과 돈을 소비하게 됩니다.

 

IaaS(Infrastructure as a service)

Infrastructure 레벨을 제공하는 서비스를 의미합니다. 위에 보이는 것과 같이 사용자는 OS를 직접 올리고 그 상위 계층만 구성하면 되는 모델입니다.

정리

  • 우리가 자주 사용하는 가상 호스팅(VM Hosting)과 비슷하나 처음에 말했다시피, 가상 호스팅은 우리가 직접 장비를 사서 그 장비의 한에서 자원을 할당하고 구성해야 하지만, IaaS는 기업이 준비해놓은 환경에서 우리가 선택할 수 있다는 점에서 차이가 있습니다.
  • 일반적으로 적은 OS가 지원됩니다. (아마존은 일부 Linux와 Windows Server 제공)
  • 고객은 OS와 어플리케이션을 직접 관리해야 합니다.
  • 관리 측면에서 개발자와 인프라 관리자의 역할을 분담시킬 수 있습니다.

장점

  • 고객은 가상 서버 하위의 레벨에 대해서는 고려할 필요가 없다는 장점이 있습니다.

단점

  • 그러나 역설적으로 IT 부서(특히, 운영부서)에서 느끼는 매우 큰 단점은 바로 가상 서버 하위의 레벨에 대해서는 전혀 고객이 접근하거나 컨트롤할 수 없습니다.
  • 결국, 가상 서버 하위의 레벨에 대해서 고려할 필요가 없는 사용자가 쓰기에 적합한 모델입니다.

예시

AWS의 EC2

  • AWS의 EC2를 이용하면 우리는 물리적인 서버와 Network, Storage 등등을 직접 구매하거나 준비하지 않아도 원하는 OS를 깔아 서버로 사용할 수 있습니다.
  • AWS의 EC2는 사용자가 원하는 OS를 고르고 그에 해당하는 스펙을 선택하기만 하면, 모든 관리를 아마존에서 해주는 것입니다. OS를 제공한다는 느낌이긴 하지만, 선택권을 주고 OS의 종류나 다양한 자원들을 사용자가 선택하므로 대표적인 IasS라고 불리고 있습니다.

제가 이번에 만든 오픈소스 Mosquitto를 이용한 MQTT Broker를 아마존의 EC2에 올려서 사용하고 있는데 매우 편리합니다.
1년간은 프리티어로 사용할 수 있으니 관심 있으신 분은 한번 해보시는 게 좋은 것 같습니다.

사용자

  • AWS 처럼 직접 기업이 클라우드를 운영하고 사용자인 우리가 서비스를 받는 AWS EC2 같은 것이 이에 해당합니다.

제공자

  • 직접 클라우드를 구성할 수 있는 OpenStack이라는 오픈 소스도 IaaS에 해당합니다. 서비스를 제공 받는 입장이 아닌 제공하는 인프라를 구성할 수 있는 오픈 소스입니다.
  • OpenStack에 관한 게시글은 다음 포스팅에 다루도록 하겠습니다.

 

PaaS(Platform as a service)

개발자가 응용 프로그램을 작성할 수 있도록 플랫폼 및 환경을 제공하는 모델입니다.

정리

  • 운영 팀이 인프라를 모니터링할 필요가 없습니다.
  • 사용자는 OS, Server 하드웨어, Network 등등을 고려할 필요가 없습니다.
  • 사용자는 어필리케이션 자체에만 집중할 수 있습니다. 즉 개발자는 빠르게 어플리케이션을 개발하고 서비스 가능하게 할 수 있습니다.
  • IaaS와 헷갈릴 수 있는데 아마존과 같은 서비스가 VM을 제공하는 IaaS라면, PaaS는 node.js, Java와 같은 런타임을 미리 깔아놓고, 거기에 소스코드를 넣어서 돌리는 구조입니다. 다시 한번 얘기하면 우리는 소스코드만 적어서 빌드 하는 것이고, 컴파일은 클라우드에서 하여 결과만 가져오는 거라고 생각하시면 됩니다.

장점

  • PaaS의 경우 이미 설치된 미들웨어 위에 코드만 돌리면 되기 때문에, 아무래도 관리가 매우 편리합니다.
  • 가장 이상적인 어플리케이션 플랫폼 관점의 클라우드 모델로 업계에 받아들여지고 있습니다.

단점

  • 이것도 IaaS와 마찬가지로 하나의 인프라를 기반으로 개발할 수 있다는 것 자체가 장점이자 단점이 될 수 있습니다.
  • PaaS는 기본적으로 어플리케이션과 플랫폼이 함께 제공됩니다. 어플리케이션이 플랫폼에 종속되어 개발되기 때문에 다른 플랫폼으로의 이동이 어려울 수도 있습니다.

예시

  • PaaS의 제공 업체로는 Heroku, Google App Engine, IBM Bluemix, OpenShift, SalesForce가 있습니다.

 

SaaS(Software as a service)

설치할 필요도 없이 클라우드를 통해 제공되는 SW입니다.

정리

  • 위의 그림에서 보이는 것처럼 모든 것을 기업(클라우드)에서 제공함으로 사용자는 별도의 설치나 부담이 필요 없이 SW를 사용할 수 있습니다.
  • SaaS는 소비 관점에서 제공되는 IT 방식의 서비스로 정리할 수 있습니다. 구독의 방식으로 돈을 벌거나 트래픽 기반으로 돈을 벌 수 있습니다.

장점

  • Public Cloud에 있는 SW를 웹 브라우저로 불러와 언제 어디서나 사용할 수 있습니다.
  • 사용자는 웹만 접속하면 되기 때문에 사용하기 매우 쉽고, 최신 SW 업데이트를 빠르게 제공받을 수 있습니다. 사실상 기업 입장에서도 클라우드에 SW가 있기 때문에 따로 업데이트를 하지 않아도 접속한 사용자는 최신 SW를 사용하게 될 수 있습니다.

단점

  • 단점으로는 SaaS의 특성상 반드시 인터넷에 접속할 수 있어야만 사용할 수 있고, 외부의 데이터 노출에 대한 위험이 있습니다.

예시

  • 예로는 웹 메일, 구글 클라우드, 네이버 클라우드, MS오피스365, 드롭박스 등이 있습니다.

 

결과

  • 정리하자면 위의 그림과 같이 한 단어로 host, build, consume으로 표현이 가능합니다.
반응형
반응형

CentOS 에서 yum-config-manager: command not found 에러가 날 경우

$ yum install yum-utils

해서 설치하고 나서 하면 됨.

반응형
반응형

 

로컬pc : macosx

virtualbox 사용중 공유폴더가 필요하여 설치하려는데 도저히 설정이 안되서 미친 구글링함

결론적으로는 

#1. 확장판 설치

#2. 공유폴더 설정

하면

 

아래순서 그대로 했음(당연히 centos 설치한 vm에서 진행했고, root 계정으로 진행함 )

1. centos 설치하자 마자 업데이트

  $yum update

  $reboot

  재부팅 되면

  $yum update kernel

  $reboot

  재부팅 되면

   $yum groupinstall "Development tools"

   $yum install kernel-devel (이건 반복이긴 한디... 어쨋든 수행함 )

2.Install VirtualBox Guest Additions(확장판 설치)

  $cd /mnt

  $mkdir cdrom && mount /dev/cdrom /mnt/cdrom

  $cd cdrom && ./VBoxLinuxAdditions.run

 

3. 공유폴더 설정

  해당 vm 에서 [설정>공유폴더>  ].

 

[root@vm ~]# mkdir /vm_share_dir

[root@vm ~]# mount -t vboxsf virtualbox_share /vm_share_dir

 ( virtualbox_share 는 버츄얼박스 공유폴더 설정명 )

### 마운트 되었는지 확인 ####

[root@vm ~]# mount

......

 vm_share_dir on /vm_share_dir type vboxsf (rw)`

반응형
반응형

너무 다양한 데브옵스의 세계... 점점 더 지도가 넓어지고 있다... 난 어디?

기본적인 devops engineer 스펙은 예로 들면 아래 정도 될거 같다.

- 기초 : 리눅스 관리, 파이썬, AWS 또는 다른 클라우드 플랫폼
- 구성 : 테라폼(Terraform) 또는 앤서블(Ansible)
- 버전 관리 : 깃(Git)과 깃허브(GitHub)
- 패키징 : 도커(Docker)
- 배포 : 젠킨스(Jenkins)
- 실행 : 아마존 ECS와 쿠버네티스
- 모니터링 : ELK 스택

(원문보기: http://www.itworld.co.kr/news/118329#csidx2c57a1a5dded950a27572aea7ea3a1b  )

누군가가 전체 로드맵을 잘 정리해서 퍼왔다... 음...

출처 : https://github.com/kamranahmedse/developer-roadmap

 

kamranahmedse/developer-roadmap

Roadmap to becoming a web developer in 2019. Contribute to kamranahmedse/developer-roadmap development by creating an account on GitHub.

github.com

 

 

반응형
반응형

 docker-compose up 실행시 아래와 같은 에러가 발생하여 삽질을 하였다.

ERROR: The Compose file './docker-compose.yml' is invalid because:

Invalid top-level property "manager". Valid top-level sections for this Compose file are: version, services, networks, volumes, secrets, configs, and extensions starting with "x-".

You might be seeing this error because you're using the wrong Compose file version. Either specify a supported version (e.g "2.2" or "3.3") and place your service definitions under the `services` key, or omit the `version` key and place your service definitions at the root of the file to use version 1.

For more on the Compose file format versions, see https://docs.docker.com/compose/compose-file/

설명처럼 version 을 소수점으로 변경도 해보고, 이런 저런 별짓을 다해봤지만 ...

결론은 띄어쓰기 문제였다.

yaml 파일에서  같은 레벨의 띄어쓰기가 맞지않아서 에러가 나는 거였음... 

위 에러날때 동급의 항목이 같은 띄어쓰기로 되어 있는지 , 더 앞칸으로 되어 있는건 아닌지 확인해 보면 해결될듯함

 

 

 

반응형

'DevOps' 카테고리의 다른 글

centos 7 virtualbox guest additions 해결및 공유폴더설정완료  (0) 2019.08.26
Devops roadmap  (0) 2019.06.25
docker - swarm/compose/service/stack  (0) 2019.06.07
Docker Error  (0) 2019.06.05
Docker 명령어 정리  (2) 2019.03.21
반응형
이름 역할 명령어
compose 여러 컨테이너로 구성된 도커 애플리케이션을 관리(주로 단일 호스트) docker-compose
swarm 클러스터 구축 및 관리 (주로 멀티 호스트) docker swarm
service swarm에서 클러스터 안의 서비스(컨테이너 하나 이상의 집합)를 관리 docker service
stack swarm에서 여러개의 서비스를 합한 전체 애플리케이션을 관리 docker stack

 

반응형

'DevOps' 카테고리의 다른 글

Devops roadmap  (0) 2019.06.25
ERROR: The Compose file './docker-compose.yml' is invalid because  (0) 2019.06.12
Docker Error  (0) 2019.06.05
Docker 명령어 정리  (2) 2019.03.21
쿠버네티스 기존 리소스 수정  (0) 2019.02.08
반응형

ERROR: Get https://registry-1.docker.io/v2/: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)

도커 이미지 pull 등을 실행시 위와 같은 에러가 발생시에는 우선 도커 로긴이 제대로 되었는지 확인을 먼저 해본다.

나같은 경우는 docker compose up  실행시 위와 같은 에러가 발생하여 , 도커 로긴을 해보니 도커 로긴 자체가 현재 안되는 상황이었다.

 

-->10분 후 다시 로긴을 해보니 정상적으로 로긴 처리 완료 되었고 위의 메세지는 더이상 발생하지 않음

 

반응형
반응형

출처: [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
쿠버네티스 기존 리소스 수정  (0) 2019.02.08
쿠버네티스 명령어 #6  (0) 2019.01.31
쿠버네티스 구조  (0) 2019.01.10

+ Recent posts