도커와 쿠버네티스
- DevOps 를 해야 하는 이유
소프트웨어의 개발과 운영의 합성
빨리 개발하고 배포하기 위해 한다!
DevOps 하면 도커 / 쿠버네티스 라는 도구가 보통 사용되지만, DevOps 는 도구를 사용하는 것이 아니라 하나의 철학, 방법론이다.
서비스의 빠른 개발, 배포라는 목표가 필요할 때 하나의 방법으로 도구를 사용하는 것이지 다짜고짜 도구를 쓴다고 해서 좋은 것이 아니다.
Git 도 DevOps 에서 중요한 도구다.
소스 관리의 표준으로 자리잡음.
DevOps 를 한다
→ 좋은 도구를 잘 사용해서 자동화, 측정, 공유, 축적 → 효율을 증가시킨다.
- 서버 관리 방법의 역사
자체 서버를 운영 → 설정 관리 도구가 등장 → 가상 머신 등장 → 클라우드 등장 → paaS 등장 → 도커 등장 → 도커를 더 잘 관리하려고 쿠버네티스 등장 → 서비스메시 등장
- 자체 서버 운영
서버 주문, 설치, CPU, 메모리, 하드디스크 조립, 네트워크 연결, OS 설치, 방화벽 설정 등등
서버 설정에 많은 노력과 시간이 필요
- 클라우드
AWS, 구글 클라우드, Azure 등등
하드웨어 파편화 문제를 해결
가상화된 환경만으로 아키텍처 구성이 가능해짐
이미지를 기반으로 한 다수의 서버 상태 관리
상태 관리에 대한 새로운 접근으로 매우 편리해짐
그러나 서버 운영의 문제는 여전히 남아있음
- paaS
서버를 운영하는 것은 복잡하고 어렵다
잘 구성해놓은 곳에 소스 코드만으로 배포
일반화된 프로비저닝 방법을 제공
프로비저닝 과정에 개입할 수 없음
but 애플리케이션을 paaS 방식에 맞게 작성해야 하고 서버에 원격으로 접속하거나 파일 시스템을 사용하거나 서버 패키지를 설치할 수 없다는 문제가 있음.
그럼에도 애플리케이션 배포에 대한 새로운 패러다임을 가져왔다고 할 수 있다.
- 도커
도커가 등장하고 서버관리/개발 방식이 완전히 바뀌게 됨.
다양한 서버 애플리케이션을 도커 컨테이너로 만들 수 있고 어디서든 돌아간다!
가상머신처럼 독립적으로 실행되고 가상머신보다 쉽고 빠르고 효율적이다.
도커가 가져온 변화
→ 클라우드 이미지보다 관리하기 쉬움
→ 다른 프로세스와 격리되어 가성머신처럼 사용하지만 성능저하가 거의 없다.
→ 복잡한 기술을 몰라도 사용 가능
→ 이미지 빌드 기록이 남음
→ 코드와 설정으로 관리하여 재현 및 수정 가능
→ 오픈소스이기에 특정 회사 기술에 종속적이지 않음
⇒ 모든 것을 컨테이너화 하기 시작함
컨테이너가 많아지니까 또 관리의 어려움이 발생함
→ 복잡한 컨테이너 환경을 효과적으로 관리하기 위해 “컨테이너 오케스트레이션” 이라는 도구가 등장
→ 서버 별 용량, 성능에 따라 자동으로 새로운 앱을 배정하면서 관리함
→ 각 앱의 배포 버전도 관리해줌
이러한 컨테이너 오케스트레이션 도구는 굉장히 많이 만들어졌는데, 이 중 하나가 바로 쿠버네티스다!
- 쿠버네티스
컨테이너를 쉽게 빠르게 배포/확장하고 관리를 자동화해주는 오픈소스 플랫폼
앱을 만들고 서버 노드에 배정하고 서버에 문제가 생기거나 앱에 문제가 생기면 새로운 서버에 다시 배정하고 버전이 업데이트 되었는데 에러가 발생하면 이전 버전으로 되돌려서 서버에서 요청받게 하는 일련의 과정을 본래 사람이 했었는데, 쿠버네티스는 위의 모든 관리를 알아서 해준다!
개발 환경을 넘어서 운영 환경에서도 사용 가능한 컨테이너 관리 도구!
- DevOps 역할
조직이 소프트웨어 제품과 서비스를 빠른 시간에 개발 및 배포하도록 함
서비스를 배포하고 지원 + 모니터링
배포 파이프라인 구성
자주, 더 빠르게 릴리스
- 10주 DevOps 스터디 (1회 이상 서비스 배포경험 필요)
1주 : Terraform 을 이용하여 AWS VPC 만들기
2주 : 도커(컨테이너)로 서버 관리하기
3주 : 자동 빌드 & 자동 배포 (CI/CD)
4주 : 배포 알림 / 채팅 봇 만들기
5주 : 쿠버네티스와 함께하는 컨테이너 오케스트레이션
6주 : AWS EKS 본격 설정
7주 : 모니터링
8주 : 로그 수집
9주 : 배포 최적화
10주 : 서비스메시 (+보안)