📚 오늘 공부한 내용
1. Docker를 실제 Production 환경에서 사용할 때 유념할 점
- Docker volumes
- Host volume은 보통 개발 시 소스 코드를 바로 container 안으로 마운트하기 위함이다.
- 내용이 지속성 있게 유지가 되도록 Production에서는 named volumes을 사용한다.
- Docker Container는 read-only로 사용한다. 내용을 바꿔야 한다면 실행 중인 컨테이너를 수정해서는 안 된다.
- 이미지를 새로 빌드하고 다시 컨테이너들을 새로 론치해야 한다.
- 그래서 자동화가 중요해진다.
- 다수의 Docker Container들을 다수의 호스트들에서 실행이 필요하다.
2. 관리해야 하는 서버의 수가 늘어나 발생하는 이슈를 어떻게 해결할 수 있을까?
1) 문서화
- 지금 서비스 상황과 셋업 방법 문서화
- 다양한 문제 발생 시 해결 방법 문서화 (트러블 슈팅)
- 문서를 현재 상황에 맞게 업데이트하는 게 중요
- 매뉴얼하게 관리하는 것이기 때문에 몇백 대의 서버를 일일이 관리한다는 것은 불가능
2) 코드
- Infrastructure As Code (DevOps 엔지니어가 알아야 하는 기술)
- 문서 대신 코드로 관리하는 것으로 요즈음 많이 사용하는 방법
- 다양한 툴들이 존재한다. ex) chef, puppet, ansible, Terraform
- 정보의 누락이 적고, 자동화를 해 주기 때문에 서버를 하나씩 로그인하는 게 아니라 하나의 커맨드에서 다수의 서버에 전파해서 실행하는 게 가능하다는 장점이 있다.
- 배우는 데 어려움이 있고 설치 시 소프트웨어 충돌이 일어나면 도움이 안 된다.
3) Virtual Machine
- 소프트웨어 충돌 해결을 위해 VM을 사용한다. 분리된 환경을 제공해 주기 때문이다.
- VM이 전반적으로 리소스 소비가 크고 느리다.
- 결정적으로는 특정 VM 벤더 혹은 클라우드에 종속되어 버린다.
4) Docker
- 모든 소프트웨어를 Docker Image로 만들면 어디서든 동작한다는 장점이 있고, VM에 비해 리소스 낭비가 적고 실행 시간이 빠르다.
- 또한 Image를 통해 버전을 관리하고 배포하기 때문에 문제 시 롤백이 용이하다.
- 오픈 소스라 클라우드나 특정 업체에 Lock-in 이슈가 없다.
- 다만 Docker Container의 수가 늘어나면서 관리가 힘들다는 점이 유일한 단점이다.
3. Container Orchestration
- 다수의 Container를 관리하고자 만들어진 것이
Container Orchestration이다. - 오케스트라의 지휘자가 있는 것처럼 효율적으로 관리하자는 의미에서 해당 이름이 붙여졌다.
- 한 클러스트 안에 DB, Web Service, Backend 등 다양한 서비스들이 공존하는데 이는 자원 요청을 받아 마스터가 자원을 할당한다.
- 배포, 스케일링, 네트워크, 인사이트 해 주는 다양한 기능을 제공한다.
1) 소프트웨어 배포
- 서비스 이미지를 Container로 배포
- 이상이 감지되면 이전 안정 버전으로 롤백.
- 예를 들어 v1에서 v2로 배포되는 경우 모니터링을 하다 이상 현상이 감지되면 다시 v1으로 롤백한다.
2) 스케일링
- 특정 서비스의 Container 수를 쉽게 늘리고 줄이는 것. (탄력적)
- 이때 서버의 utilization도 고려해야 한다. (놀고 있는 서버가 없도록 해야 함.)
3) 네트워크
- 서비스가 다수의 컨테이너로 나누어지면서 그를 대표하는 Load Balancer를 만들어 주어야 한다.
- 서비스들 간에 서로를 쉽게 찾을 수 있어야 한다.
4) 인사이트
- 만약 서버 2의 F가 다운되면 서버 3에서 이를 재실행해야 하고, F 로드밸런서 정보도 이에 맞게 수정되어야 한다. 이렇게 노드/컨테이너 문제를 자동으로 해결해 준다. (재난 관리)
- Logging/Analytics 등 기능 제공.
- 전체 서비스를 시각화하거나 문제 분석 해 준다.
5) Tool
- Mesos
- Marathon
- DEIS
- Rancher
- Nomad
- Docker Swarm
- K8s (중심) -> 모든 클라우드 업체들이 관련 서비스를 내고 있다. EKS, AKS, GKE
4. Kubernetes (K8s)
- 가장 많이 사용되는 Container Orchestration 시스템이다.
- 사용 회사와 커뮤니티 활동이 굉장히 많고 활발하다.
- K8s 위에 기능을 추가한 Container Orchestration 툴이 존재한다.
- 확장성이 좋아서 다양한 환경에서 사용된다.
- 머신러닝: Kubeflow
- CI/CD: Tekton
- Service Mesh: Istio
- Serverless: Kubeless
- 다수의 서버에 컨테이너 기반 프로그램을 실행하고 관리한다. 보통 Docker와 K8S는 같이 사용된다.
- Pod: 같은 디스크와 네트워크를 공유하는 1 개 이상의 컨테이너들의 집합이다.
1) Architecture
Master Node
-Node는 물리 서버이거나 가상 서버Master는 클러스터를 관리해 주는 역할 수행- 클러스터는 노드 + 1의 집합
Kubelet이라는 마스터와 통신하는 에이전트- Master 안에는 여러 프로세스들이 돌고 있다.
- API SERVER: kube-apiserver (Web UI, kubectl, API)
- Scheduler: Pods 생성과 할당 (노드들의 상황을 고려 utilization)
- Controller Manager: 전체 상황을 모니터링하고 fault tolerance를 보장
- Master는 High availability가 중요하다.
✍ Kubectl 커맨드 라인 툴
kubectl run hello-minikubekubectl cluster-info: 클러스터의 상황 확인kubectl get node: 노드들이 어떻게 세팅되어 있는지
✍ Pod란 무엇인가?
K8s사용자가 사용하는 가장 작은 빌딩 블록이다.- 보통은 하나의
Container로 구성되어 있으며 하나보다 많은 경우helper container가 같이 사용된다.Pod는 네트워크 주소를 갖는self-contained server- yml, yaml 파일에서
kind: Pod로 입력한다.- kind 값으로는
POD,Service,ReplicaSet,Deployment가 올 수 있다.
🔎 어려웠던 내용 & 새로 알게 된 내용
1. 마이크로 서비스란?
- 웹 서비스를 다수의 작은 서비스들로 구현하는 방식이다.
- 각 서비스들은 팀 단위로 원하는 언어/기술로 개발하는 자율성을 가진다.
- 각 서비스들은 계약 관계로 지켜야 하는 책임이 있고 서비스 정보를 등록해야 한다.
- 모듈식 특성으로 하여 유연성, 확장성 및 개발 노력 감소를 달성할 수 있기 때문에 인기가 높아졌다.
- 마이크로서비스의 특징
- 느슨한 결합
- 독립적으로 배포 가능한 구성 요소
- 자동화된 배포
- 분산 데이터 및 언어 제어
- 유지 보수 용이성
- 쉽게 테스트 가능
- 비즈니스 또는 조직의 필요와 능력을 중심으로 구성
- 각 서비스는 보통 소규모 팀이 소유
✍ 회고
📚 쏘카 airflow 도입기
📚 버킷플레이스 airflow 도입기
- 만들어진 Docker Image를 어떻게 배포하고 스케일할 것인가, docker-compose를 통해 Multi-Container 관리를 배우기
- K8s를 사용해 Container 배포하기(실습 환경 설정, kubectl 사용, 개념 이해), 네트워크 관련해서 외부와 연결하기, 스케일 아웃하기
- 강의에서 공부를 해 두면 좋을 것 같다는 부분을 기재해 두었다. 기회가 생기면 조금 더 상세하게 공부해 보고 싶다고 생각했다.
송의 개발 LOG