시작하기 전,,,

글로벌 소프트웨어캠퍼스와 교보 DTS가 함께 진행하는 챌린지입니다

👉신나는 강의 바로 드가자~

4/28 36일차

월요일 싫어
싫어 너무 싫어~ 오늘 sqld 신청날~ 공부언제하지~

오전

저번주에 한것들 복습 해주시고
시험 신청때문에 금방 쉬는시간이였음

1. 도커 네트워크

• 저번주에도 했지만 컨테이너에서 ip를 순차적으로 받기때문에 재 시작할때 변경 될 수 있음
• 그리고 내부에 있는 컨테이너 이기때문에 직통으로 연결이 안되서 호스트 ip로 변환되서 나간다
• 호스트와 연결하는 브리지가 있음
  
• 브리지는 자동 생성되면 docker0이며 추가로 생성할 수 있으며 커스텀 할 수 있음
  
• brctil 연결 되는 것을 확인
  

1.NAPT

• 저번에 포트포워딩할때 잠시 나왔던 것인데 ip와 포트 번호까지 변화하는 것
• 호스트 ip로 들어와서 컨테이너로 가기위해서는 포트번호가 필요하기 때문에 사용
• 순서
  1. 컨테이너가 외부로 나가기 위해 브리지를 통해 호스트로감 -> ip 192.168.130.1
  2. 호스트에서 나갈때 ip 테이블를 통해 ip를 호스트 ip로 변환 -> ip 192.168.130.100
  3. 서버 도착하고 응답할때 목적지 ip -> ip 192.168.130.100:8080
  4. 호스트 랜카드에 도착 -> ip 192.168.130.100:8080
  5. ip 테이블에서 -> ip 192.168.130.1:80
• 구성해보기
  1. 포트 지정하고 컨테이너 생성 2개생성
     
  2. curl 로 2개가 같은 내용이여서 수정
     
  3. 외부로 연결
     
  4. 규칙 확인
     
  5. 컨테이너를 정지하면 ip를 반납하는데 자동으로 변경된다
     

2.브리지 custom

• docker0가 아닌 새로운 브리지를 생성할 수 있음
• 수동으로 ip 범위 지정 가능
• 지정하지 않으면 default 값으로 지정
• 생성 --driver bridge
  
• 해당 브리지에 컨테이너 연결
  

3.호스트 네트워크

• 컨테이너에 있는 ip를 호스트 ip와 동일하게 생성하는것
• 그래서 포트가 없이도 바로 사용가능
• 생성 --net host로 설정
  

4.논 네트워크

• 네트워크를 사용하지않는것, 외부 접근을 안하는것
  

5.컨테이너 네트워크

• --net other_container_name을 지정하여 다른 컨테이너와 넷 네임스페이스 환경 공유
• ip고정하는 방법, 컨테이너의 안에서 컨테이너의 ip를 지정하여 사용하는 것
  

오후

2. 컨테이너 간의 통신 link

• --link 를 사용
• 동일 호스트 간의 docker 컨테이너를 link를 통해 통신 가능
• 한 호스트 상에 여러 컨테이너가 동작하는 경우, 컨테이너의 alias를 통해 서로 다른 컨테이너 접속
• /etc/hosts 를 통해 확인가능
• 동일한 브리지를 통해서만 통신 가능
• 보안 요구 사항으로 통신을 차단
• 생성 2개의 컨테이너 DB(이름만 db임), web
  
• ping으로 연결 확인
  
• 컨테이너가 종료 되고 ip가 바뀌어도 자동으로 변경
  

3. 컨테이너 간의 통신 netalias

• --netalias를 사용
• 특정 호스트 이름을 통해 여러 개의 컨테이너에 접근 가능
• 컨테이너 2개의를 생성해서 나눠서 트래픽 이동하도록 하는것
• 무조건 custom 브리지를 사용해야한다.
• 생성 2개의 컨테이너
  
• ping으로 서로 번갈아가며 사용 50:50 무조건은 아니고 그냥 좀 나눠지는 느낌
  

4. 도커 이미지 관리

• Registry: 서비스 push, pull하는 것
• Repository: 저장공간, 이미지 저장소
• images: 파일
• container: 프로세스 이미지를 실행하는곳
• tag: 버전, 실행 환경
• Dcoker Hub(http://hub.docker.com): github처럼 이미지를 관리하는 리포지토리 서비스 사이트
• docker image ls 이미지 목록 조회
  
• docker image inspect: 상세정보 출력
• docker image login
  1. 허브에서 회원가입, bash에서 로그인
     
  • bash로그인
    
  2. 필수는 아니지만 push 할때등에 필요하다.
  3. bash에는 로그인이라고하기보단 로그인 정보를 저장해두는것 자동 로그인 push함
     
  4. push등을 로그인이 필요한 명령이 있으면 자동 로그인하는것 하지만 정보가 암호화 되는것은 아님
• docker image push: 파일을 허브에 내보내는것, 동일한 파일은 push 할 수 없음, tag를 새로 지정해도 파일 자체는 동일한 파일이기때문에 목록엔 보여도 실제로는 된것은 아님
  
• docker image pull: 허브로부터 이미지를 다운받는 것
  
• docker image tag: 위에서 push할때 쓴것처럼 복제가 ㄴㄴ, 이름을 새롭게 붙이는 것, 이미지가 새롭게 변경된것은 아님
  
• docker image search: 허브에 공개되어있는 이미지를 검색하는 것인데 실시간이 아니라 잘안씀
• docker image rm: 이미지를 삭제하는것, df를 이용하여 공간을 확인하고 부족하면 삭제, 사용하지 않는 것만 삭제 가능, -f 옵션이면 삭제 가능
  
• docker image prune: 사용하지 않는 이미지, 컨테이너, 네트워크 일괄 삭제
  

4. 도커 이미지 생성

5. 컨테이너 기반 이미지 생성

• 컨테이너에 실행할 파일들을 설치 및 생성하고 컨테이너로 만든다음 이미지로 생성

• docker image commit

• 생성

  1. 임시 컨테이너 생성, 업데이트 nginx설치
     
  2. 출력화면 넣기
     
  3. 커밋해서이미지 생성
     
  4. push 하고 로컬에 있는 이미지 제거
     
  • 허브에 있는 것 확인
    
  5. 허브에서 이미지 다운받아서 사용해보기
     

• docker container export: 가동중인 컨테이너의 디렉토리, 파일들을 모아 tar 형태의 아카이브 파일로 생성

• docker image import: 위에서 tar로 생성한 파일을 image로 변환

• 순서

  1. 컨테이너 생성
  2. 생성 tar로 만들기
     
  3. tar확인
     
  4. tar를 다른 호스트로 송신
     
  5. 다른 호스트에서 확인 tar을 이미지로
     
  6. 컨테이너로 만들어봄 근데 naginx로 만들어서 실행할 프로세스가 없어서 추가 명령어를 넣음
     

• docker image save: docker image를 tar파일로 저장
  

  • 송신하고
    

• docker image load: tar로 만든 이미지를 다시 이미지로 생성
  

• 위와 다른점은 이미지였던것과 컨테이너를 tar로 만든것의 차이점이라서 구조가 다음

6. Dockerfile를 빌드해서 생성

• 코드를 작성하고 빌드한것을 이미지로 생성
• Dockerfile: 도커에서 인프라 구성을 기술한 파일
• 내용(명령)
• build 방법
  1. Dockerfile를 생성
  2. Docker build -t testimage(빌드해서 생성할 이미지명) -f Dockerfile(빌드할 Dockerfile명) .(파일 경로)
     
  3. 그럼 생성이다!
     

이후

오늘은 너무 졸려서 서서 했는데 서서도 졸리드라,,
월요일은 역시 힘들어
점심은 싸다분식에서 냉면먹음

4/29 37일차

오늘은 비가 왜이리 많이 오는거야~
덥다가 비오다가 덥다가~ 저번에 산불났을때 많이좀 오지 금방 멈추게!

오전

오늘은 화요일~ 왜 아직 화요일~ 집에 가고싶은 화요일~

1. Dockerfile build

• 어제 한번 만들어본것 그걸 오늘 개념, 명령 등 더 배우는 것
• 명령 종류
• Dockerfile에서는 명령이 실행 될때마다 이미지를 중첩해가며 결과적으로 하나의 이미지로 생성하는것이다.
  1. 베이스 이미지 -> 이미지 1
  2. 이미지 1 + 사용할 프로그램 -> 이미지 2
  3. 이미지 2 + 추가 파일 -> 이미지 3
  4. 이미지 3 + 작업 -> 이미지 4가 결과 이미지가 로 하나만 보이게 되는것
• 물론 4번까지 안갈수도 더 갈수도 있지만 이런 형태로 생성 된다고 생각하면 될듯

이미지 용량줄이기

• 배포를 가볍고 빠르게 하게 하기 위해서
• 경량화된 이미지를 베이스로 사용 -> silm alpine, busybox
• 필요없는 파일은 삭제 -> 필요한 프로그램 설치후 불필요해진 것들을 삭제
• 삭제할때는 동일한 명령안에서 지워야한다. 명령이 바뀌면 이미지가 생성되기때문에 지울수가 없음
• 경량화 안한 빌드파일
  
• 경량화 안한 이미지
  
• 경량화한 빌드파일
  
• 경량화한 이미지
  

오후

2. Dockerfile build 명령

1. RUN

• 이미지 생성과정에서 애플리케이션/미들 웨어를 설치, 환경 설정을 위한 명령 등을 정의한 것
• shell 형식(/bin/sh -c 을 사용해서 명령한것과 동일, 변경하려면 정의해주고 사용)
• RUN apt-get update && apt-get install -y nginx 같이 사용
• &&, || 등 비교연산자를 쓰려면 shell를 사용 -> &&은 선행과 후행 모두 실행하기 위해서, || 하나만 성공하기 위해서
• exec 형식은 잘안씀 RUN ["/bin/bash","c"] 이런식으로 대괄호 사용
• 차이점
  
• 실행 과정
  

2. CMD, ENTRYPOINT

• 이미지에서 생성되는 것이 아닌 컨테이너를 생성했을때 수행될 작업
• 하나만 기술 가능하며 여러개 기술하면 마지막 명령만 수행
• exec형태를 많이씀
• CMD ["nginx", "-g", "daemon off"] 이런식
• ENTRYPOINT도 동일함
• 두개를 같이 많있는데 ENTRYPOINT의 인수를 CMD에 작성해서 사용
  
• 실행과정 확인
  
• 컨테이너 실행할때 CMD 변경가능
  

3. ONBUILD

• ONBUILD이 선언된 이미지에서 tar을 풀어서 생성하는 것이 아닌 선언된 이미지가 다른 이미지의 베이스가 되었을때 사용 되는 명령이다!
• 좀어려움 쓰면서도 뭔말인지 모르겠는데
• 베이스 이미지 + ONBUILD -> 이때는 tar파일을 풀지 않고 존재만함 이미지 1 -> 이미지1(베이스 이미지) + 작업 -> 이미지 2가 되었을때 ONBUILD으로 tar파일이 풀림!
• 이유 베이스 이미지와 추가되는 파일을 따로 합쳐서 이미지를 생성 -> 개발자들에 의해서 추가 되는 부분을 다시 이미지로 빌드하기 위해서 편의를 위해
• 실행했을때 문제없이 실행 이미지 1 생성
  
• 이미지 1 베이스 이미지로 실행
  

4. STOPSIGNA, HEALTHCHECK

• STOPSIGNA: 컨테이터를 종료방법에 대한 시그널 설정
• HEALTHCHECK: 컨테이너 안의 프로세스가 정상적으로 작동하고 잇는지 확인, 컨테이너가 실행중이라고 정상인 것은 아니다.
• 실행 정상 확인
  
• 비정상 확인
  

5. ENV

• 컨테이터가 실행되면 컨테이너 내부에서 사용할수 있는 변수
• 컨테이너 생성하면서 변경, 추가도 가능 --env로
• key=value형식으로 한번에 여러개 변수 설정도 가능
  
• 세부 사항에도 나옴 inspect
  
• 컨테이너 실행하고 나옴
  
• 컨테이너 생성 실행할때도 변경가능
  

6. WORKDIR

• 컨테이너가 실행할때 작업 시작 디렉토리
• 기본은 /root지만 설정하면 변경됨
• 이것도 컨테이너 생성하면서 변경 가능 --workdir
• 실행 실행 실시간 확인 --progress=plain
  

7. USER

• 컨테이너 내부에서의 사용자 설정
  
• whoami로 실시간 확인
  

8. LABEL

• 기능ㄴㄴ 이미지에대한 설명 추가적으로 작성한것, inspect로 확인가능
  
• 세부사항에 작성되어있음
  

9. EXPOSE

• 컨테이너의 공개 포트 지정
• 컨테이너 생성할때 -p 같음
  

10. SHELL

• 잘안씀, 선언 안하면 /bin/sh 본쉘
• 본쉘 < 배쉬쉘
• 실행
  
• 기록으로 다른것 확인
  

11. ADD, COPY

• 둘다 파일을 추가하는 것은 같음
• ADD: 호스트 외에 외부에서도 가져올 수 있음, 근데 SCP FTP는 안되고 wget, curl처럼 하는 것은 된다고
• 그리고 원격지에서 받아온것은 압축되어있으면 해제는 안되지만, 호스트에 있는 파일은 풀어서 추가해준다고
  
• 컨테이너에서 확인
  
• COPY: 호스트에 있는것을 복사하는 것만 가능

12. VOLUME

• 컨테이너 내부의 영구적인 저장공간을 지정하는 것임
• 자동볼륨 생성이라 잘안씀 -> 이름이 랜덤으로 16진수로 작성되기 때문에
• 확인
  
• 자동볼륨 생성
  

13. ARG

• ENV가 컨테이너에서 사용하는 변수였다면 이미지를 빌드할때 사용되는 변수다
• 그래서 이미지 빌드할때만 사용되서 컨테이너에는 안들어감
  
• 이미지 생성할때 지정 가능
  

그외

• docker image history: 리눅스 명령어와 똑같음 이미지 빌드중 어던 명령 실행하는지 확인 가능

3. multi-stage builds 멀티스테이지 빌드

• 서비스 제공 환경을 최소화하기 위해 사용하는 것
• 일반적인 빌드로 하면 기계어하기 전의 데이터들이 남아있음 -> 결국 필요한건 기계어한 파일만 있으면 되기때문에 -> 아닌 파일들은 다 제거
• 생성
  1. 파일 미리 준비
     
  2. 이미지 생성
     
  3. 컨테이너 생성
     
  4. 이번엔 멀티스테이지로 불필요한 데이터 지우는것
     
  5. 용량 차이 확인
     

실습 파이썬 파일 실행하기

1. 파이썬을 베이스
   
2. 이미지 생성
   
3. 컨테이너 생성해서 연결
   

4. 도커 자원 할당

• 저번에 잠깐 한건데
• 자원을 독점하거나 서비스의 원할한 성능을 보장하기 위해서 사용하는 것
• cpu, 메모리 등 여러 자원에 할당 가능
• 할당하면 유연성이 떨어지고 보장성이 올라간다

1. 메모리 사용량 제한 할당

• --memory= 최대 메모리 설정 -> 꽉차도 종료 되진 않음
  
• --memory-swap 가상메모리까지 설정한것 -> 최대메모리와 동일하면 메모리량이 없으므로 바로 종료됨
  
• --oom-kill-disable true면 부족해도 종료되지않음
  

2. cpu 사용량 제한 할당

• 기본적으로 cpu 사용량은 무제한이지만 그렇게 되면 독점할 수도 잇음
• 그래서 pinned? 암튼 콕찝어서 정해준다 그러면 똑같은 것을 계속 사용하기때문에 캐쉬가 저장되어 더 빠르게 실행
• -- cpuset-cpus cpu 지정
  
• --cpus %으로 할당량 지정 타율처럼 1이 100임
  
• --cpu-shares: 가중치를 지정하는것 경합할때 어디가 더많있는것을 지정한것 기본값이 1024
  
• 가중치 2:1로
  

3. Block I/O(디스크) 사용량 제한 할당

• 이것도 기본적으로 제한이 없지만 독점하면 기능 저하되니까
• 그리고 물리 디스크의성능에따라 또 달라지긴 함
• --device-write-bps /dev/sda:1mp 수정속도를 1mb 로 지정한것 읽기read도 있음
  
• 10mb를 받는데 10초 정도 걸림
  

이후

실습이 진짜 많아!
내일 가서 언제 다 사진 넣지,,ㅋㅋㅋ

맞음 나 오늘 사과게임 105점함ㅋ
점심은 타코벨갔음

4/30 38일차

오늘 추워서 잠을 못잤어!
4월 말인데 왜 아직도 밤에 춥지?

오전

어제 자원 할당하는거 남아서 더하지요

1. 도커 자원 할당

1. 시스템 ulimit 자원 제한

• ulimit -a 제한 최대치 확인
  
• 컨테이너에 주어지는 cpu 시간을 초단위로 제한
• 컨테이너가 종료되지않으면 hard limit 시간 후 강제 종료 시그널을 전달하여 할당 안되게 만듬
  
• nofile: 컨테이너 내부에서 동시에 열수 잇는 파일 설명자의 최대 수를 정의
  
• nproc: 컨테이너 내부에서 사용할수 있는 최대 프로세스의 수 지정 넘어가면 자종 종료
  

모니터링

• docker system events: 도커 데몬에 어떤 일이 일어나고 있는지 실시간 스트림 로그 출력
  
• docker container stats: 실행 중인 모든컨테이너의 자원 사용량을 실시간 스트림으로 출력 (--no-stream이면 1회)
  
• docker system df: 사용하고 있는 이미지, 컨테이너, 볼륨의 총 수, 크기 등을 출력, RECLAIMABLE는 삭제햇을때 반환 크기
  
• cAdvisor: 저번에 한번 본건데 구글에서 만든 모니터링 도구, web에서 시각화로 확인 가능

오후

• 지금까지는 도커 엔진 기능을 배운것
  1. 이미지 생성 commit, build
  2. 컨테이너 생성 프로세스, 저장공간, 네트워크 브리지넷 등
• 이걸 다 조합해서 쓰는게 도커 컴포즈?

2. 도커 컴포즈

• docker compose: 여러개의 컨테이너를 코드를 통해 관리하는 도구
  
• YAML:
  • 컨테이너 실행 방법 등을 작성
  • 데이터형식의 한 종류
  • 읽기 쉽게 직렬화
  • 들여쓰기를 통해 계층 표시
  • 동일한 parents를 가지는 값은 들여쓰기 크기가 동일해야함!
  • 리스트 처럼 key[], key: - val1 \n -val2
  • 맵처럼 map 키값 구분해서 사용할 수 있음 java의 맵처럼
  • 두개를 합쳐서도 가능
    
• YAML파일 편하게 보기위해서 수정
  
• Docker compose version: 요즘은 안쓴다 왜냐면 다 3버전이기때문에 필요없음
• vscode 연결 하기
  1. vscode에서 yaml 설치, remote-ssh설치
  2. 리모트익스프롤러? 에서 + 눌러서 포트포워드해서 연결
  3. 하고 나오면 된거

1. Docker compose build, image

• 이미지를 생성하는 것과 동일하다.
• Dockerfile의 경로를 작성해줘야함 /dir 까지 정도
• dockerfile: 파일명이 다를때 작성
• image: 이미지를 미리 생성되어 있을때 이미지만 넣고 실행
• image를 먼저 생성하고 하는것을 더많이씀 왜냐면 build까지하면 시간이 너무 오래걸리고 그걸또 hub에 넣기도 해야하니까
• environment: 컨테이너 내부에서 사용할 환경 변수, 이미지 생성할때 처럼 env_file: 해서 설정도 가능

2. Docker compose restart, depens_on

• restart: 종료시 재시작을 하는 방법, 재시작 횟수도 정의 가능
  • no: 수동으로 재시작할때 까지 재시작 안함 기본값
  • always: 수동으로 컨테이너를 종료하기 전까지는 자동으로 재시작
  • on-failure: 비정상 종료될경우 재시작
• depens_on: 컨테이너간의 의존성 작성, 서로 시작과 종료를 지정하기 위해 -> web 컨테이너 전에 db 컨테이너가 먼저 생성되어야하니 의존성을 설정 해서 db 컨테이너가 먼저 생성되도록
• container_name: 생성되는 컨테이너 이름, 설정안하면 자동으로 생성되서 스킾가능, yaml파일 있는디렉토리 명 + 설정 이름
• labels: 전과 동일하게 설명, 메세지 넣어두는곳 기능 ㄴㄴ

3. Docker compose cap_add, cap_drop, command, healthcherck

• cap_add, cap_drop: 컨테이너가 호스트에게 어디까지의 권한을 가질수 잇는지
  • add: 추가
  • drop: 제거
• command: 이미지의 CMD와 같음, 컨테이너 실행시 실행할 명령
• healthcherck: 컨테이너 서비스 상태 확인

4. Docker compose volumes, Top-level volumes

• 난 이게 좀 어려웠는데
• 위에서 들여쓰기로 계층 표시한다고 했잖음
• 들여쓰기 없는 volumes -> docker vloume create 같은것 즉 로컬에 볼륨 생성
• db: 안에 volumes: 을 작성해둔것이면 docker run -v db-data:/var/lib/mysql 과 같은것 즉 컨테이너에서 로컬 볼륨을 마운트

4. Docker compose networks, port, expose

• networks: 각 컨테이너가 통신하기 우해 연결할 네트워크, 브리지 생성, 여러개씩 생성가능한다 그럼 여러 가상랜카드가 생길 것
• 이것도 볼륨처럼 top-level이 있음
• port: 컨테이너가 노출할 컨테이너의 포트 번호 -p 옵션과 같음 그리고 :를 시간으로 인식해서 "8080:80"처럼 ""을줘야함
• expose: 같은 호스트간 연결을 위한 것

3. Docker compose 명령어

• 일단 명령어 작성하는 위치는 yaml이 있는 디렉토리에서 실행해야함
• 그 위치에 없으면 경로까지 지정해줘야하는데 귀찮으니까!
• docker-compose up: 관련된 컨테이너 생성 -> 실행 까지 run 기능
• docker-compose down: 관련된 컨테이너 종료 -> 삭제 --rm 기능
• docker-compose start/stop/restart: 시작, 종료, 재시작
• docker-compose kill: 강제 종료
• docker-compose pause/ unpause: 일시정지, 재가동
• docker-compose ps: 관련된 컨테이너 상태 확인

4. 실습 2개

• 물론 다 되어있는걸 읽기만 했지만
• flask, redis를 이용한 사이트 저번에 파이썬파일 있는것 포함한 것 빌드부터 하는것
  1. yaml 실행
     
  2. ps 확인
     
  3. curl 연결확인
     
  4. 컨테이너 bind mount, 하면 로컬에 저장소를 연결해서 실시간으로 수정도 가능
     
  5. 
• wordpress, mysql를 사용해 블로그 만들기
  1. 테스트 컨테이너 생성
     
  2. yaml 실행 -> 네트워크 생성, 현재 디렉토리, 볼륨, 컨테이너, 실행순서 db - wordpress
     
  3. 확인 ps
     
  4. 윈도우에서 연결 포트포워드 해서
     
  5. 글작성
     
  6. 볼륨때문에 컨테이너랑 삭제해도 다시 생성하면 글이 그대로 있음
     
  7. 삭제할때 볼륨까지 같이 삭제 --volume
     

5. 도커 스원

• 하나의 호스트 머신을 여러개를 묶어서 사용하는게 스웜swarm
• scale up: 부족하면 큰걸로 갈아타는것 과거
• scale out: 부족하면 추가해서 사용해 여러개를 묶어서
• 도커의 기본 기능임

6. 서버 오케스트레이션

• 서버 오케스트레이션: 여러 대의 서버(노드)와 여러 개의 서비스(컨테이너)를 편리하고 효율적으로 관리해주는것
• 스케쥴링: 어디서 실해할지 지정해주는것, 컨테이너를 가장 효쥴적으로 서비스 할수 있는 노드에 배포해주는것
• 클러스터링: 여러 개의 서버를 하나의 서버처럼 사용할 수 있는 것
• 서비스 디스커버리: 컨테이너가 어느 노드에서 실행되는지 알필요 없는것
• 로킹+모니터링: 여러 노드를 사용하니까 여러곳에서 로그가 나오니 한번에 모아서 확인는 것 ELK, prometheus(성능모니터링도구) -> E: 로그 검색, L: 로그 수집, K:시각화

7. 노드 구성하기

• 노드 = 호스트(서버?)
• 매니저 노드: 워커 노드를 관리하는 것, 부하 분산, 가용성을 위해 이중화 권장
• 워커 노드: 컨테이너가 실행, 매니저 노드가 관리하는 노드
• 구성하기
  1. 호스트 3개 준비
  2. 도커 엔진 설치(우린 다되어있음)
  3. 매니저 노드에서 스웜 클러스터를 생성 -> 하면 클러스터 토큰이 나옴
     
  4. 토큰을 워커 노드에 입력하면 됨
     
  5. 조인된것 확인
     

8. 서비스 구성

• 서비스: 동일한 이미지로 실행되는 노드의 집합
• task: 작업이 할당되는 컨테이너
• REPLICAS: 작업중인 노드 수
• DESIRED STATE: 원하는 상태
• CURRENT STATE: 현재 상태 두 상태를 같이 만들려고 함
• 실행하기
  1. service 실행하기 설정안하면 task 1개만 잡음, 그리고 지정안하면 랜덤하게감
     
  2. service ls로 확인 서비스 확인, ps로 실행중인 컨테이너 확인, 해당 노드가서 containr ps 로 확인가능
     
  3. rm으로 서비스 종료
  4. --replicas로 task 여러개 사용
     
  5. 확인, 두개이상이면 같은 노드에 실행안함, 분산해서 실행
     
  6. 하나를 강제로 종료 -> 자동으로 다시 실행
     

9. 롤링 업데이트

• 업데이트할때 모두를 종료하면 다운타임이 생기기 때문에 이를 방지하기 위해
• task를 하나씩 업데이트 하는것 -> 1,2,3 있으면 1만 업데이트해서 1만 멈춘상태에서 2,3은 계속 서비스, 1이끝나면 1,3 서비스 2업데이트 이런식으로 하는 것

이후

오늘 사과게임 115점인분이 나오셨다,, 나는 다시 사과게임을 한ㄷ,, 악!
점심은 핵밥으로 덮밥 먹음

5/1 39일차

와 5월 1일! 나도 나도 쉬고싶어!!!!
왜 어째서 난 근로자가 아닌거야!
비도와!! 쉣!

오전

• 어제 롤링 업데이트 확인을 못해봐서 오늘 해봤음!
  
• 오늘부터 쿠버네티스!

1. 쿠버네티스

• 도커는 이미지생성, 컨테이너 생성 이였다
• 도커와 쿠버네티스는 서로 다른 것이며 서로 런타임 호환안되기 때문에 호환시켜주는 cri가 있어야함
• 쿠버네티스에서 원래는 자기들이 지원해주는게 있었는데 도커가 더 작아지니까 안해줘서 도커쪽에서 해주기 시작함
• 쿠버네티스는 컨테이너를 컨테이너를 배포하고 관리하는 소프트웨어 유지관리
• 여러 노드를 하나인 것처럼 클러스터링 해서 애플리케이션을 실행하는것
• 물리적인 호스트를 사용하여 인프라를 추상화하여 개발 및 운영, 배포 관리를 단순화 시킴
• kubernetes = k8s 같은거임 k3s 미니쿠베? 는 경량화 된것
• 기본 동작
  1. 필요한 컨테이너 이미지들을패키지로 만들어 이미지 레지스트리(저장소,hub)에 push
  2. 서비스 디스크립션(YAML포멧)에서 컨테이너 이미지와 복제본의 수, 클라이언트에서 제공하기위한 정보를 정의
  3. 마스터 노드은 각 워커 노드의 자원의 정보와 서비스들간의 의존성을 고려해 스코어링을 해서 컨테이너 배치를 스케줄링함
  4. 서비스 실행을 선정된 워커 노드의 kubelet에 요청하면 kubelet은 container runtime인 docker를 실행한다.
  5. docker에서 필요한 이미지를 pull해서 컨테이너 실행
  6. 쿠버네티스는 모니터링하면서 컨테이너가 디스크립션과 일치하는지 지속적으로 확인함
• 장점
  • 애플리케이션의 배포 단순화: 클러스터를 구성하는서버는 알필요가 없으고, 개발자가 직접 배포도 가능
  • 높은 하드웨어 활용도: 최적의 노드를 찾아서 컨테이너 실행
  • 지속적인 상태 확인: 모니터링을해서 장애발생시 다른 노드에서 자동실행, 사람이 즉각 대응 요구 ㄴㄴ
  • 오토 스케일링: 요구사항에 따라 자동으로 확장 및 축소 가능
• 도구 종류
  1. kubeadm
     • 우리가 쓸거임
     • 공식 제공해주는 클러스터 생성/관리
     • 최근부터 고가용성 구성 가능 홀수개로 만듬
  2. kubesparay
     • 오픈 소스 프로젝트
     • 레드헷쪽
  3. Rancher
     • suse
     • 멀티 클러스터 관리 도구

오후

2. 실습환경 구성

• 쿠버네티스 설치부터
• 리눅스 우분투 사용
• 설치 최소 사항 2gb 메모리, 2코어 cpu
  1. 먼저 우린 3개의 노드를 구성 1개 마스터 2개 워커
     
  2. 요구사항 최소사항 확인
     • swap을 사용안하니까 swapon && cat /etc/fstab
     • swapoff -a && sed -i '/swap/s/^/#/' /etc/fstab
       
     • 방화벽 해제 원래 있어야하는데 우리는 귀찮으니까 그냥 해제 ufw disable
       
     • iptables확인하고 제어할수 있도록 br_netfilter 모듈을 로드하고 네트워크 파라미터 설정
       
  3. 마스터 노드부터 고정 ip, 호스트네임 변경
  4. 도커 설치 -> 쿠버네티스에선 컨테이서 생성을 못하니
  5. kubeadm(생산관리), kubelet(데몬), kubectl(제어) 패키지로 설치 업데이트 못하게 홀드
     
  6. cri-dockerd 설치 -> 도커를 사용안하면 필요없지만 쿠버네티스에서 도커를 실행하기 위해선 필요
  7. cgroupfs를 컨테이너 런타임 kubelet로 제어할 수 있도록 구성 -> systemd를 사용해야하는데 최신버전은 되어잇으니 안해도댐
     
     여기까지 다 똑같음! 그래서 마스터 노드를 복제해서 워커노드 1,2를 만들어 -> 그리고 그것들도 각각 ip, 호스트네임 변경 ㄱㄱ
     
  8. 마스터 노드에서 kubeadm init으로 클러스터 생성 원클러스터
     • kubeadm init --cri-socket=unix:///var/run/cri-dockerd.sock
       
     • 나오는 토큰 조인 키를 스크립트로 저장
       
  9. root 사용자가 쿠버네티스 클러스터의 api 접근할 수 있도록 인증하기 위해 변수 설정
     • export KUBECONFIG=/etc/kubernetes/admin.conf -> .bashrc
       
  10. pod(컨테이너)가 서로 통신할 수 있도록 CNI 기반 pod 네트워크 추가 기능 구성 칼리코?
      • curl https://raw.githubusercontent.com/projectcalico/calico/v3.25.0/manifests/calico.yaml -O
  11. 클러스터 구성 확인 -> 1 node 클러스터 구성 끝
      • kubectl get nodes
      • kubectl get pods --all-namespaces = kubectl get pods -A
        
  12. 아까 만든 스크립트를 각 워커 노드 1, 2로 보내줌 -> 그리고 스크립트 실행 그럼 조인 완료
      
      - 근데 이미지가 pull이 안되서 오류났음 그래서 각각 이미지를 새로 설치
      - docker pull docker.io/calico/cni:v3.25.0
      - docker pull docker.io/calico/node:v3.25.0
  13. 마스터 노드에서 다시 구성 확인하면 3개 다나옴
• kubectl delete nodes worker2 노드 제거하기
  
• 노드 다시 추가
  1. 토큰은 다시 생성해줘야함(유효기간이 있음)
     • kubeadm token create --print-join-command -> 이러면 다시 조인 키를 새로 생성해줌
       
  2. 그리고 삭제햇던 노드에서는 처음에 연결된 클러스터가 있다면 캐시? 라고 해야하나 암튼 연결을 삭제한다고해도 내용이 남아있을 수 있어서 그 내용을 삭제
     • kubeadm reset --cri-socket=unix:///var/run/cri-dockerd.sock 리셋
       
     • 그리고 아까 스크립트 실행하듯 다시 ㄱㄱ
       

이후

ㅋㅋㅋㅋㅋ 오늘 사과게임 대회 열자고 했는데 바로 내일 하기로함
우린 망했어,, 최고령 팀이야!
점심은 비와서 역전 우동먹음

5/2 40일차

오늘은 금요일~ 신나는 금요일 오늘 쉬면 다음주 화요일까지 4일쉬어~

오전

1. 쿠버네티스 주요 컴포넌트

• 기본 동작
  1. 이미지를 빌드해서 docker hub에 푸시
  2. 쿠버네티스 명령어 실행해서 api서버로 요청하고 클러스터에 새로운 레플리케이션 컨트롤러 오브젝트 생성
  3. 레플리케이션 컨트롤러는 새 파트를 생성하고 스케줄러가 워커 노드 중 하나에 스케줄링
  4. 해당 워커 노드의 kubelet는 파드가 스케줄링 된걸 확인
  5. 이미지가 로컬에 없으면 hub에서 pull하기
  6. 이미지 다운하고 kocer로 컨테이너 생성하고 실행
• etcd
  1. key value 저장소 DB
  2. 모든 데이터를 저장하는 곳으로 데이터를 조회가능
  3. 안정적이지만 쿠버네티스 운영하려면 여러개 의 마스터 서브에 분산해서 실행하고 주기적으로 데이터를 etcd에 백업하는것을 권장
  4. 이중화를 하는것이 좋음 데이터를 계속 조회하면서 사용하고 저장해야하기 때문에 하나면 사고나면 위험
• kube-apiserver
  1. api를 사용할 수 있도록 하는 컴포넌트
  2. 통신하여 여러곳에 확인하는 것
  3. 요청이 유효한지 검증, 인증 권한 확인 등 을 한다.
  4. 여러 컴포넌트와 통신을 연결하여 요청, 응답을 전달하는 위치
     
• kube-scheduler
  1. 클러스터에서 자원을 할당이 가능한 노드를 스코어링해서 파드를 실행하도록 선정
  2. 스코어링: 최적의 노드를 선택하다록 하는 것
• kube-controller-manager
  1. 쿠버네티스의 파드들을 관리하는 컨트롤러를 구동하는 컴포넌트
  2. 컨테이너 실행하는 언어로 런타임을 실행함
  3. 실행항하는곳으로 배포, 실행, 셀프힐링등은 못함
  
• 파드 생성 절차

1. kubectl로 create pod api 를 호출
2. server에서 요청이 유효한지 검사, etcd에 저장
3. etcd가 결과 리턴
4. server에서 스케줄러를 호출
5. 스케줄러는 pod를 실행할 위치를 결정하고 리턴
6. server는 pod 실행할 위치를 리턴받고 etcd에 기록
7. etcd과 저장했다고 리턴
8. server는 해당 노드에 있는 kubelet를 호출
9. kubelet는 docker api를 이용해서 컨테이너 생성
10. kubelet는 api를 호출해서 pod 상태를 업데이트
11. server는 etcd에 상태를 저장 및 유지

오후

2. 쿠버네티스 노드

• kubelet
  1. 클러스터의 각 노드에서 실행되는 에이전ㅌ
  2. 런타임의 언어로 해석해서 일시킴
  3. 정의된 파드 스펙을 받아서 컨테이너가 해당 파드 스펙에 따라 정상적으로 동작하도록 직접 관리
  4. 생성되지 않은 컨테이너는 관리 ㄴㄴ
• kube-proxy
  1. 클러스터의 각 노드에서 실행되는 가상 네트워크를 설정하고 관리하는 네트워크 프록시
• 컨테이너 런타임
  1. kubelet에서 컨테이너를 실행되는 언어
  2. 우리는 docker를 사용

3. 오브젝트, 컨트롤러

• 자원이 바라는 상태 desired state를 정의하고 현재 상태가 일치하도록 컨트롤러가 오브젝트의 생성/삭제를 함
• 오브젝트: 파드, 서비스, 볼륨, 네임스페이스
• 컨트롤러: 레플리카세트(파드관리), 디플로이먼트(많이 씀), 스테이트풀셋, 데몬셋, 잡
• 오브젝트를 구성하는 필드
  1. status: 쿠버네티스 시스템과 컴포넌트에 의해 제공, 업데이트된 오브젝트의 현재 상태
  2. spec: 생성될때 리소스의 원하는 특징,상태 선언하는것
• 선언적 API: 컨테이너가 어떤 상태이길 원하는지 쿠버네티스에 설정하면 지속적으로 컨테이너 상태를 확인해서 선언한 상태로 맞춘다

4. YAML

• 클러스터의 오브젝트나 컨트롤러가 어떤 상태여야하는지 템플릿을 사용하는데 YAML형식을 많이 사용
• 도커에서 이미지 생성할때와 같은 느낌~
  • apiversion: 쿠버네티스api 버전 명시
  • kind: 오브젝트, 컨트롤러 종류 명시 pod 같은것
  • metadata: 이름, uid 등 오브젝트의 식별 정보
  • spec: 원하는 상태 명시
• 아니 자동완성이 안되는 거임,, 왜안되나했더니 설치를 해야한데
  • apt install -y bash-completion 설치하고 뭐뭐하니 자동완성 가능

5. 네임스페이스

• 도커에서 네임스페이스랑 조금 뭔가 다른 느낌
• 구분을 지어두는것 논리적으로 구분된 가상 클러스터 라고 생각
• 접근 가능한곳 접근하게 하는것, 공간을 나눈것으로 보면 될듯
  • default: 기본 네임스페이스
  • kube-system: 시스템에서 생성한 오브젝트를 위한 네임스페이스
  • kube-publec: 클러스터안에 모든 사용자가 읽기 권한으로 접근 가능한 네임스페ㅣ스
  • kube-node-lease: 클러스터가 스케일링 될때 노드 하트비트(상태를 보내는것)의 성능을 향상 시키는것
• 네임스페이스 변경
  • kube-system으로 변경하는것 --namespace 사용
    
  • 지정하는것
    
  • 기본으로 바꾸는것 "", default 사용
    
  • 제거
    

6. 파드

• 컨테이너를 포장하는 느낌
• 컨테이너 단위로 실행하는 것이 아닌 파드로 포장해서 파드로 실행하는 것
• 쿠버네티스에서 실행, 배포하는 단위
• 단일 또는 강하게 결합된 리소스를 공유하는 컨테이너로 구성
• 각각의 다른 일을 하는 컨테이너를 묶지 않음
  • ex) wordpress와 db를 묶지않는 것처럼 동일한 일을 하는 것이 아니까 서로 통신을 해서 연결가능한것을 묶지는 않음
• 보조 컨테이너가 들어가 있음 웹서버라고 하면, 웹컨테이너, 로그 컨테이너, 볼륨컨테이너, 통신컨테이너 등으로
• 그리고 동일한 ip를 사용하기위해 ip만 가지고 같은파드에 있는 컨테이너들에게 ip를 통신에 동일한 ip를 가지게 할 수 있음 그럼 ip가 고정인거임 대신 ip를 가지고있는 컨테이너는 일을 안함 종료 되지많안게 하는 것
• 그래서 ip는 다 똑같으니 포트로 구분해서 들어간다
• YAML파일로 하는데 들여쓰기로 구별하는걸 꼭 생각해야함
• 구성
  1. name: 이름 설정 식별 정보 유일해야함
  2. labels: 오브젝트를 식별하는 레이블 설정 유일 ㄴㄴ 그룹으로 검색도 가능하게 검색할때 속성으로만 검색하듯이
  3. containers.name: 컨테이너 이름 설정
  4. containers.image: 컨테이너에서 사용할 이미지
  5. containers.ports.containerport: 연결할때 사용할 포트
  6. containers: 설정할때 여러개를 설정할수 있음
     
     
• 종료하기
  
• 상태 확인
  • initaialized: 초기화한 컨테이너가 성공적으로 시작 완료
  • ready: 파드가 요청을 처리할 수 있는 상태
  • containersready: 파드 안의 모든 컨테이너의 준비 상태
  • podscheduled: 스케줄이 완료되었늕 ㅣ여부
  • unschedulable: 자원의 부족이나 다른 제약사아으로 지금 당장 파드를 스케줄을 할 수 없는 상태
• 환경 변수
  
• 확인
  
  
• 실습
  1. 컨테이너 2개 생성
     
  2. 변수 적용확인
     
• liveness probe
  • 컨테이너가 살아 잇는지 확인하는것
  • 진단을 실패하면 종료하고 재시작 정책에 따라 컨테이너 재시작
  • spec.restartpolicy를 통해 선언
  • 재시작 정책 (always가 기본값)
    • always: 재시작하는것
      
    • 재시작하는것 확인
      
• radiness probe
  • 컨테이너가 실행된 후 실제로 서비스를 응답하는지 확인 하는 것
  • 위와 다르게 실행하고 확인하는 것임
  • 전제를 안된다고 생각하고 실행하기 때문에 처음실행할때부터 확인
• 실패해보기
  
  
• 자원 리소스 할당
  • 리소스 할당 도커와 같은 느낌으로 자원 할당하는 것
  • 최소 자원 할당량, 최대 사용 제안 할당 설정하는 것
  • 노드의 상황을 실시간을 고려하는것은 아님
  • cpu
    1. 네임스페이스 만들기
       
    2. 사용가능한 자원 확인
       
    3. 실행하고 워커에서 확인
       
       
    4. 실패하는것도 해보기
       
    5. 실패이유
       
  • memory
    1. 네임스페이스 만들기
       
    2. 사용가능한 자원 확인
       
    3. 워커에서 확인
       
    4. 실패한것도 해보기
       
• pause container
  • 항상 자동으로 실행, 실행되고 컨테이너가 실행된다.
    
  • 컨테이너의 부모 컨테이너로, 기본 인프라 환경(자식 컨테이너가 사용할)을 제공하는 것
  • pause 컨테이너가 죽으면 다죽는거야~
    
• static pod
  • 위에서 중요한 컴포너트 들을 실행하는 파드들
  • api server, etcd 등 쿠버네티스를 실행할때 필요한 것들인데 다 파드로 구성 되어있는데 파드를 실행하기 위해서는 애들은이 필요한것처럼 계란이먼저냐 닭이 먼저냐 라는 것
  • 그래서 얘들은 노드위치를 고정해서 실행하는 것으로!
  • /etc/kubernetes/manifests 에위치한다 그래서 이곳에 위치하면 자동으로 런타임해서 실행, 스케쥴링도 안감! 노드가 정해져있으니까!
    
    

이후

점심 뭐먹었지?!
ㅋㅋㅋ 대회하는데 우리팀 왜 2등함? 어케 했음?ㅋㅋㅋㅋ
삼촌들과 조카,, 조카님 커피 못사드렸네,, 까비,,

8주차 후기

이제 쿠버네티스 배우는 중!
벌써 2달이나 지났고 12주 정도 남았는데 시간이 생각보다 빨리가네 다끝나면 아쉬울것 같기도 하다
강사님은 다다음주? 까지 하고 다음 강사님으로 바뀌고 AWS배운다고하는데 벌써 아쉽당 다 아쉬워!
게임대회도 갑자기 하는데 왤케 웃긴지 ㅋㅋㅋㅋㅋㅋㅋㅋㅋ
다음엔 강사님이랑 매니저님도 껴서 같이하자고 해야지!
끝!