MSA 가 가능하지만 복잡 | - Monolitic 주력
MSA 가 가능하지만 복잡 | MSA 최적화 | | 배포 자동화 | CI/CD(Jenkins, Git) | CI/CD(CodeCommit, Code Pipeline) | GitOps(CodeCommit, Flux) | | 모니터링(지표,로그,추적) | Route, Switch, Hub | CloudWatch | Promethus, Grafana, Fluentd, Fluend Bit, Cloudwatch Container Insight, Xray | | 모니터링(지표,로그,추적) | Route, Switch, Hub | VPC | Promethus, Grafana, Fluentd, Fluend Bit, Cloudwatch Container Insight, Xray | | Security(인증/인가) | Window AD, 자체개발 | IAM | 인증: IAM 인가: RBAC |
서버(물리 개념) Vs 인스턴스(서비스)
- 물리 환경에서는 서버는 인스턴스를 여러 개를 돌릴수 있는데, 클라우드 환경은 mirco-Service 를 지향
- 인스턴스가 하나의 서비스, 하나의 서버로 개념을 매칭
On-Premise Vs Cloud
- 서비스를 제공함에 있어 사용하는 IT 자원을 누가 관리하느냐의 차이
- On-Premise : 서비스를 공급하는 서비스 제공자가 직접 IT 자원을 관리하는 주체가 됨
- Cloud : 서비스를 공급하는 제공자는 IT 자원을 사용만 할 뿐, 대부분의 IT 자원 관리는 클라우드 서비스 제공자로부터 제공받음
- 서비스에 필요한 인프라를 직접 보유하지 않고, 필요할 때만 사용하기 위한 기술
Monolitic Vs MSA
Monolitics: 소프트웨어의 모든 구성요소가 한 프로젝트에 통합 되어 있는 형태MSA: 아키텍처는 하나의 큰 애플리케이션을 여러 개의 작은 애플리케이션으로 쪼개어 변경과 조합이 가능하도록 만든 형태
AWS 의 CI/CD
Code Commit: AWS에서 호스팅하는 Git 기반의 완전관리형 소스 제어 서비스 (버전 제어 서비스)- 클라우드에서 자산을 비공개로 저장하고 관리하는 데에 사용
- 기존 코드를 Github 에서 AWS CodeCommit 으로 마이그레이션
Code Build: 애플리케이션 코드를 빌드하기 위한 지속적 통합 서비스- 소스 코드를 컴파일하는 단계부터 테스트 실행하여 배포 준비가 된 소프트웨어 패키지를 생성
Code Deploy: Amazon EC2, AWS Lambda 및 온프레미스 인스턴스 같은 다양한 컴퓨팅 서비스에 대한 소프트웨어 배포를 자동화하는 완전관리형 배포 서비스- 코드를 EC2 서버에 배포
Code Pipeline: 소프트웨어 배포에 필요한 단계를 모델링, 시각화 및 자동화하는 데 사용할 수 있는 완전관리형 지속적 전달 서비스- 코드를 지속적으로 제공하는 파이프 라인을 구축
GitOps는 애플리케이션의 배포와 운영에 관련된 모든 요소들을 Git에서 관리(Operation) 하는 것
-
Kubernetes Manifest 파일을 Git에서 관리하고, 배포할때에도 Git에 저장된 Manifest로 클러스터에 배포
-
GitOps 원칙
- 선언형 배포 작업 정의서
-
선언적(declarative) : 명령들의 집합이 아닌, 사실(fact)들의 집합으로 구성되어 있음
-
GitOps에서 배포는 선언형으로 정의되어야 한다. (사용자가 배포의 원하는 상태를 선언적으로 정의)
- 쿠버네티스 리소스를 생성할 때 'kubectl run mypod ...'와 같이 명령형으로 생성할 수도 있고
- YAML 파일을 생성하여 'kubectl apply -f ....'와 같이 선언형으로도 생성할 수 있다.
GitOps는 선언형으로 배포 방식을 정의한다.
-
배포 작업 정의서가 선언형으로 되어 있으면,
- 더 쉽게 배포 가능
- 문제 발생시 롤백 용이
- 장애 등으로 인해 손상된 배포 환경을 자가 치유하기 유리
-
- Git을 이용한 배포 버전 관리
- Git에 모든 배포에 관련된 정보가 정의되어 있어야 하며, 각 버전이 Git 저장소에 기록이 되어 있어야 함
- 이를 통해 사용자는 이전 버전으로 롤백을 하거나 새로운 버전으로 업그레이드 가능
- Git에 모든 배포에 관련된 정보가 정의되어 있어야 하며, 각 버전이 Git 저장소에 기록이 되어 있어야 함
- 변경 사항 운영 반영 자동화
- 사용자는 Git 저장소에 선언형 정의서를 저장하게 되면, 실제 배포가 일어나는 작업은 자동으로 이루어져야 함
- 변화(코드 수정)가 발생할 때마다 자동으로 시스템에 적용
- 클러스터에 배포할 때 가격증명이 필요하지 않아야 함
- 사용자는 Git 저장소에 선언형 정의서를 저장하게 되면, 실제 배포가 일어나는 작업은 자동으로 이루어져야 함
- 자가 치유 및 이상 탐지
- 사용자가 원하는 배포 상태 (desired state)를 작성하게 되면 실제 배포 환경이 그에 맞게 유지되고 있는지 책임지는 것 또한 배포 주체(deploy operator)가 됨
- 따라서, 시스템 상태가 선언되고 버전 제어 하에 유지되었을 때, 배포가 실패하게되면 → 사용자에게 경고할 수 있는 시스템을 마련해야 함
- 사용자가 원하는 배포 상태 (desired state)를 작성하게 되면 실제 배포 환경이 그에 맞게 유지되고 있는지 책임지는 것 또한 배포 주체(deploy operator)가 됨
- 선언형 배포 작업 정의서
-
GitOps Repository : GitOps Pipeline 을 설계할 때에는,
Git Repository 를 최소 두 개 이상사용 권장App Repository: App 소스 코드와 배포를 위한 Manifest 파일배포 환경 구성용 Repository: 배포 환경에 대한 모든 Manifest (모니터링, 서비스, Message Queue 등) 가 어떤 버전으로, 어떻게 구성되어 있는지를 포함
-
GitOps 배포 전략
-
Push Type: Git Repo 가 변경되었을 때 파이프라인을 실행시키는 구조- 배포 환경의 개수에 영향을 받지 않으며,
- 접속 정보를 추가하거나 수정하는 것만으로도 간단하게 배포 환경 추가 및 변경 가능
- 아키텍처가 쉬어 많은 곳에서 사용하고 있으나, 보안 정보가 외부로 노출될 수 있는 단점 존재
- Push 기반 배포 전략은 Jenkins, CircleCI, Travis CI 와 같은 널리 사용되는 CI/CD 도구로 구현됨
-
Pull Type: 배포하려는 클러스터에 위치한 별도의 오퍼레이터가 배포역할을 대신함-
해당 오퍼레이터는 Git Repo 의 Manifest 와 배포 환경을 지속적으로 비교하다가
→ 차이가 발생할 경우
→ Git Repo 의 Manifest 를 기준으로 클러스터를 유지시켜 줌
-
Push Type 과 달리 오퍼레이터가 App 과 동일한 환경에서 동작중 → 보안 정보가 외부에 노출되지 않고 실행할 수 있음
-
-
-
GitOps 구현 소프트웨어 종류
- GitOps는 특정 소프트웨어나 프로덕트가 아닌 철학 혹은 방법론에 가까움
Flux: GitOps를 실제 구현한 오픈소스- Git에 정의된 kubernetes 리소스(Service, Deployment 등)의 상태를 자동으로 대상 kubernetes에 반영해 주는 도구
- Argo
오케스트레이션 Tool 로서
- Kubernetes
- AWS ECS
- Docker Swarm
- …
등이 있고, Open Source 인 Kubernetes 가 선두를 차지하게 됨
Kubernetes 를 가져와 각 회사에 따라 Customize 한 것
- AWS → EKS
- Azure → AKS
- RedHat → Openshift