> For the complete documentation index, see [llms.txt](https://ssosso.gitbook.io/study/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://ssosso.gitbook.io/study/os-and-infra-and-system/devops/docker-kubernetes-devops/4.md).
# 4일차
## 4일차
*
### 도커 시큐리티
#### 도커 호스트 서버안전
* 도커 데몬은 root 권한으로 실행
* 도커 데몬은 신뢰할 수 있는 사용자만 접근 가능해야함
* REST API는 UNIX 소켓파일 TCP로 사용한다는 것을 기억
* 도커 호스트 서버에 **어드민 관리 도구르 실행 하지마라**
#### 컨테이너가 해킹당하면
* 컨테이너에서 실향되는 프로세스는 다른 컨테이너의 프로세스에 영향을 줄 수 없음
* 컨테이너는 자신만의 네트워크 스택을 갖음
* 브릿지
#### 컨테이너가 폭주하면
* 컨테이너는 **메모리, CPU, I/O 자원을 공유**함
* 컨테이너는 **호스트 서버 모든 자원을 소진할 수 없음**
* 서버의 다운 염려는 없음.. 이건 스펙에 관한..
* 볼륨 바인딩해서 사용하는 경우 -> 100 프로 다쓰는 경우 .. 죽일려고 해도 안죽거나 반응이 느림...
* 격리 수준을 높이고 싶다면 -> vm 과 같이 쓰거나.. 등등 활용, 전략 방안 필요
* `특히 I/O와 디스크 용량의 소진 케이스 조심` -> 애초에 디스크를 크게 사용하게...
* Kernal panic과 DoS 방지
#### 도커 이미지 안전
* 도커 이미지는 안전한 위치에 저장 되어야 하며 `체크섬`을 가져야 한다
* 배포전에 보안패치를 빌드해야 한다
* 이미지 -> 온빌드
* 도커허브 이미지 -> 영속적이지 않음.. 바뀔수 있고, 해킹의 위험이 있긴함...
* CI 서버에 이미지를 넣고, 빌드해서 재생성하는 작업이 필요
* `--privieged` 사용하지 않음
#### 도커 시큐리티 스캐닝
* DTR에 애드온 되어 이미지 보안 취약점을 스캔해서 알려줌 -> 유료툴
* 도커 벤치
* 도커 호스트와 컨테이너에 대한 보안 취약점을 체크
* 오픈소스
#### 도커 벤치
*
```bash
# 도커 벤치 다운
$ git clone https://github.com/docker/docker-bench-security
# 폴더 이동
$ cd docker-bench-security
# 실행
$ docker-compose run --rm docker-bench-security
```
#### 마이크로 서비스
* 작은 서비스를 결합해서 하나의 응용프로그램을 만드는 아키텍처 스타일
* 이때 작은 서비스는 독립적인 비즈니스 로직
* 자동화된 배포
* 최소한의 중심적인 관리 체계
* 작은 서비스는 각각다른 프로그래밍 언어, 스토리지 구현 가능
* 클라우드 컴퓨팅이일반화
* 스케일링에 대한 중요성이 증가
* 시스템 큐모가 커지면서 복잡성도 증가
* 심플, 개발요구사항에 특화되어 있음
* 개별 팀에서 독립적인 개발/배포가 가능
* 각각의 마이크로 서비스는 다른 프로그래밍언어, 개발 도구로 개발 할 수 있음
* 각각의 마이크로 서비스는 서로 다른 저장소를 갖음
* 고속개발에 최적화 - DevOps
**서비스 개범위를 어떻게 설정?**
* 얼마나 작아야, 어느정도 범위에서 나누어야..
* 용어의 문제 / Cloud Native ?
* DDD
* 도메인 주도 설계
* 도메인 -> 특정 업종, 비즈니스, 현업의 경험/지식
* 현실문제 해결. 현신을 잘 반영하는 것이 좋은 소프트웨어를 만드는 지름길...
* 도메인 분석 ==> 도메인 내업무 or 문제를 정의하고 이를 모델로 표현하는 일
* **도메인 전문가와 SW 개발자가 모두 이해할 수 있는 보편전 언어** 를 사용해야 한다.
**Bounded Contest**
* 도메인주도 설계 의 패턴, 큰조직이나 모델을 설계하는 방식
* 큰 모델을 독립적으로 동작하는 Context로 구분
* Context 는 다른 Context상호 작용함
#### 모놀리틱과 마이크로서비스
#### SOA와 마이크로 서비스
* 개념적으로 비슷
* ESB / API 게이트웨이
**MSA 문제점**
* 레거시 프로젝트
* moby project
* 운영이슈 : devops
* 중복이슈 : 코드/데이터
* miniservice
* 복잡도 : 서비스가 많아지므로..
* 분산이슈
* Actor Model
* Akka 라이브러리
* Java, Scala, JVM 동작
#### RESTful API 디자인 가이드 라인
* 주요용어
* 리소스 : 객체나 관련 있는 데이터 집합, 리소스를 대상으로 처리가 이루어짐
* 콜렉션 리소스의 집합
* URL: 리소스에 대한 경로, 처리가 일어나는 것을 의미
* API Endpoint
* /getAllEmployees -> 워스트
* **GET /companies/3/employees** -> 베스트 프랙티스
* HTTP 메서드
* GET, POST, PUT, DELETE
* PUT /companies/3/employees/john
* HTTP 응답코드
* 2xx: 성공
* 3xx: 리다이렉트
* 4xx: 클라이언트
* 5xx: 서버 에러
* versioning
* ex) api.yourservice.com/v1/xxx
#### GraphQL
* API 대한 쿼리 언어
*
* 페이스북, 페이팔
#### 카오스 엔지니어링
운영환경에서 치명적인 장애를 발생시키는 부분을 실험을 통해 찾아서 해결하는 방식\
넷플릭스 카오스 엔지니어링 원칙
* 정상상태 행동에 관한 가설 구축
* 현실 세계의 문제 시도하기
* 실제 프로덕션 환경에서 실험하기
* 자동화를 통한 지속적 실험
* 폭발 반경 최소화
### 사례로 보는 DevOps
* DevOpsDay 컨퍼런스
* 개발 운영 빠르게 대응
* 목적 : 제품을 배포하는 것 (CD)
* 배포 파이프라인을 전영역으로 확대하는 것
#### Agile과 DevOps는 뭐가 다른가
* 애자일을 통해 자주 배포하면 Ops는 병목현상이 일어난다
* 애자일은 개발에서 운영으로 소프트웨어를 남겨주는것을 완료로 본다면 DevOps는 운영을 포괄한다
* 본질은 다르지 않다. 시작점이 다르기 때문에 강조하는 부분이 다를 뿐... **지향점은 같다**
#### 사람들은 왜 DevOps에 열광하나
* A/B 테스트
* 시각자료에 의한 실질적인 데이터 분석
#### Pipeline
*
* 블루오션 : Jenkins / Pipeline / grovvy script
* 9 매트릭스
* 배포주기 얼마나 자주 새로운 코드를 배포하는가
* 변경량 : 배포될 때 새롭게 추가되는 코드나 스토리 개수
* Lead Time == Cycle Time : 새로운 코드가 개발되어 운영 까지 적용되는 데 걸치는 시간
* 실패할 배포율
* MTTR
* 고객이 발생한 티켓수
* 사용자 수 변경분 : 새로 가입한 사용자 수
* 가용분
* 응답시간
#### TDI (Test Driven Infrastructure)
* 인프라 스트럭처를 코드로 보고, 코드를 테스트 하는 것 처럼 테스트 코드를 작성하는 기법
* document
* Test : 실행결과를 확인 할 수 있는 테스트 코드 작성
* Script :
* version : 스크립트에 대한 버전 관리
* Continuous
**DevOps 가치는**
* 시장에 대안 빠른 대응
* 조직효율성 증대
### DevOps 사례
* 다양한 기업들이 현재 사용중
* facebook -> development and deployment at Facebook
* 엔지니어는 공통 코드베이스에서 일한다
* 머지, 브랜치 없음
* 테스트를 전담하는 별도 Q/A팀은 없다
* 새로운코드는 하루에 2번 릴리즈 된다
* Deployment Pipeline
* 쿠팡
*
* JARVIS (빌드배포시스템)
### DevOps를 위해 필요한것들
* 자동화
* 프로비저닝, 디플로이, 테스트 자동화
* 문화
* 크로스 펑션팀, 하나의 팀
* 개인
* 프로그래밍 능력
* 자동화를 위한 스크립팅 및 프로그래밍이 필요
### DevOps 환경을 위한 도구
* Code : 형상관리 - 깃
* Build : 지속적인 통합 (CI) - 메이븐
* Test : 자동화된 테스트 (Automated Test) - ?
* Package : 패키징도구, 패키지 저장소 - 레지스트리
* Release : 배포 자동화 - 깃랩, 젠킨스
* Configure
* 설정관리 - 쿠버, 도커
* 인프라 자동화 (Infra Structure as code)
* 모니터 : 성능 모니터링 - ELK
#### 프로비저닝 도구
* vagrant
* chef
* puppet
* docker
#### 오케스트레이션
* Panamax
* 도커 컨테이너 도구
* Template 개념, 편리한 UI
* 레이어 정의 기능이 있었음
* github 기반, Ruby
* spotify / helios
* 도커 이미지, 컨테이너 라이프사이클 관리
* Java, CLI 기반
* Job 단위로 처리, **스케쥴링 X -> 치명적 단점**
* github.com/spotify/helios
* client -> Master -> Zookeeper <- agent
* d4 개발
* **Scaffold**
* Kubernetes 기반의 CLI 배포도구
* 로컬/리모트 k8s 클러스터 지원
* 리눅스 맥지원
* 빌드 파이프라인 지원 : 빌드,푸시, 디플로이
* 빌드 -> 푸시 -> 디플로이
* 쿠베 대용으로도 가능
* 자동 배포, 개발만 하면 됨
* Rancher
* 컨테이너 인프라스트럭처 관리 도구 -> 컨테이너 OS
* 멀티호스트 네트워킹 : 프라이빗+퍼블릿 프로바이더
* 컨테이너 로드밸런싱 : HA Proxy 기반
* 스토리지 서비스 : 도커 1.9 볼륨 호환
* 서비스디스커버리 : 분산 DNS 기반, 헬스체크
* 서비스 업그레이드 : 툴링 업데이트
* 리소스 관리 : 리소스 모니터링 및 스케줄링
* 사용자 관리 : LDAP 연동
* **멀티오케스트레이션 엔진 : Cattle, k8s, Swarm**
* Docker CLI
* rancher-compose : rancher-compose.yml
* Rancher UI
* 주요컨셉
* Service : 어플리케이션
* Stacks :
* docker-compose 프로젝트와 유사
* 서비스 그룹
* Catalog : 어플리케이션 템플릿
* Rancher certified, community-catalog, private catalog
* **Ansible**
* python 기반
* 오픈소스
* Ansible Tower는 상용
* 코딩없이 YAML 형식으로 할일을 정의하기 떄문에 이해가 쉬움
* 에이전트를 설치하지 않고 호스트에 SSH로 접속 할 수 만 있으면 적용 가능
* 다양한 모듈이 제공되어 작업을 정의하기 쉽다
* 플레이북 -> 앤서블을 어떻게 실행할지를 정의하는 YAML 파일
* 배포시스템 구축 가능 (카카오 사례 참고)
#### rancher 실습
```bash
# 가상머신 생성
$ docker-machine create -d virtualbox rancher-host
# 가상머신 접속
$ eval $(docker-machine env rancher-host)
# rancher 컨테이너 생성 및 실행
$ docker run -d --restart=always -p 8080:8080 rancher/server:stable
# 다른 가상머신 생성
$ docker-machine create -d virtualbox rancher-node1
# rancher agent 설치
# 인프라스트럭처 -> hosts -> add hosts -> custom
$ docker run -d --privileged -v ~~~ curl 키 확인
```