[Devops] Stage 정리

1. 개요

1) Devops란 무엇인가

Devops는 소프트웨어를 서비스 시의 고통과 책임감을 공유하는 것이다.

기존 개발자는 빨리, 많은 새 기능을 추가하길 원하고 운영자는 리스크에 대한 부담때문에 가능한 적은 수의 새 기능을 원한다. 이런 불일치로 인해 Devops가 탄생하였다.

목표는 소스코드로부터 소프트웨어 제품까지에 이르는 디지털 파이프라인 구축하는 것이다.

[필요한 기본 기술 (평생 학습해야 하지만)]

• Linux
• Python
• AWS

2. Configure

코드를 실행시킬 인프라스트럭쳐를 빌드하는 단계이다.

이 단계에서 필요한 것은 IaC이다.

대시보드를 이용한 버튼클릭에 비해 IaC가 가지는 장점은 아래와 같다.

1. 실수 방지 (휴먼 에러)
2. 버전 관리 가능
3. 재사용 가능
4. validation 가능

• Terraform 을 추천하는 이유

  • 제일 트렌디하고 사용하는 기업이 많음
  • 배우기 쉬움
  • cross-platform

• Terraform과 Ansible 비교

  • Terraform과 CloudFormation은 프로비저닝 도구
  • Ansible은 그렇게 프로비저닝된 인프라를 Config 하는 도구

• Immutable Deployments

  • Immutable Deployments는 배포된 인프라스트럭쳐를 절대 변경하지 않는다는 것
  • 배포된 VM(혹은 컨테이너)의 패치나 설정변경을 하는게 아닌 이미 패치, 설정이 완료된 VM으로 새롭게 배포하는 방식이 대세가 될 것이다.
  • 따라서 Ansible과 같은 Configuration도구보다 Terraform 과 같은 Provisioning 도구의 이용률이 높아질 것이다.
  • Immutable Deployments는 모든 VM의 SSH 접근을 막는게 가능해져 보안성 향상에도 좋다.

3. Version

모든 프로덕션 자원들은 버전관리 되어야 한다. 운영 환경에 영향을 주는 모든 것들은 버전 저장소에 저장되어야 하고 추적, 리뷰, 변경관리가 가능해야 한다.

• Git이 다른 도구 (SVN)와 차별화 되는 점

  • '분산' 소스 코드 컨트롤 시스템
  • 내가 코드 수정을 하는 동안 다른 사람이 수정하지 못하도록 락을 걸 필요가 없다. 나는 원본의 복사본에서 작업을 하고 작업이 완료 되면 변경 부분만 master에 merged 된다. 개발 중 에러가 발생하면 삭제하고 다시 원본을 카피 해올 수도 있다.
  • 이런 특징 덕분에 여러 팀이 코드 수정을 동시에 안전하게 진행할 수 있다.

• Devops엔지니어라면 Git에 대해서 완벽히 이해하고 설명할 수 있어야 한다. (최신 기술보다)

  • [ 작업자 ] 원본의 저장소에 Fork 하기
  • [ 작업자 ] Fork 된 저장소를 Clone, Remote add (나의 원격 저장소에 추가)
  • [ 작업자 ] branch 생성하기
  • [ 작업자 ] 실제 작업하기 (코딩, 문서 등)
  • [ 작업자 ] 작업된 내역 업로드 하기 add, commit, push
  • [ 작업자 ] GitLab - New Merge Request
  • [ 승인자 ] GitLab - New Merge Request 확인하기
  • [ 승인자 ] 작업자에게 코멘트 남기고 Master 에 병합하기
  • [ 승인자 ] Master에 병합한것 취소 하기 (Revert)
  • [ 작업자 ] 승인자가 Master에 병합이후, fork를 원본 저장소의 내용으로 동기화 하기
  • [ 작업자 ] 업로드한 branch 삭제하기

4. Package

• Docker
  • 운영체제 수준 가상화. 동일한 운영체제 내에서 프로세스를 격리 시키는 방법
  • 도커의 이점
    • Process Isolation
      • 프로세스 수준의 격리 덕분에 한 컨테이너의 장애가 다른 컨테이너, 호스트에 영향을 주지 않는다. 보안적으로도 컨테이너에서 호스트 OS로 침투하는게 굉장히 어렵기 때문에 안정적이다.
    • Deployment
      • dependency isolation을 가능하게 한다. 각각의 컨테이너는 자신만의 라이브러리들과 패키지들을 가진다. 덕분에 한 OS에서 여러 종속성을 가진 소프트웨어들을 실행하고 관리할 수 있다.
    • Runtime Management
      • 파이썬이나 자바등 사용 언어에 따라서 로깅 방식이 다르고 모니터링 포인트가 다르다. 도커를 이용하면 단일 지점 관리 인터페이스를 이용할 수 있다. 한 곳에서 모니터링, 로깅, 서비스 컨트롤을 할 수 있는 것이다.

5. Deploy

배포의 어려움은 환경의 차이에서 발생한다. 개발과 운영 환경의 차이.

그러므로 '소스코드'만 배포하는 것이 아닌 실행환경 전체를 배포해야 한다. 개발에서 정상적으로 동작하던 환경 전체를 배포하는 것. 이것이 immutable deployment이고 배포 후에 겪는 문제들을 방지한다.

• 배포와 개발의 컨피그(DB 커넥션 정보, 계정정보, S3 버킷 로케이션 등) 차이 문제 해결

  • 컨피그는 외부 솔루션에 저장 후 환경변수로 머신에 전달하는 방식으로 구현해야 한다.

• Don’t “fix” your prod machines, fix your dev and redeploy.

• Jenkins

  • 설치, 유지보수가 어렵지만 가장 대중적으로 사용되는 오픈소스 배포 도구
  • Jenkinsfile로 배포 파이프라인 역시 코드로 관리할 수 있다.

6. Run

컨테이너는 docker run 명령어 만으로 실행 가능하지만 이렇게 컨테이너를 직접 관리하는 방법은 좋은 방법이 아니다.

• 컨테이너가 죽는다면?
• 로드에 따라 컨테이너 수를 늘려야 한다면?
• 배포 시에 제로 다운타임을 가져야 한다면?
• 전체 마이크로서비스의 가시성을 확보하고 싶다면?
• CI/CD 파이프라인이 빨리 밸류를 전달하게 하고 싶다면?

Docker-compose 는 운영환경에서 사용은 부적절하고 개인용도의 배포나 테스트, 프로토타입 제작에만 사용하도록 한다.

• 컨테이너 오케스트레이션 툴
  • Kubernetes : private datacenter나 일부 클라우드에서는 유일한 오케스트레이션 툴
    • 배포, 스케일링, 컨테이너 애플리케이션 관리의 자동화를 제공하는 오픈소스
  • AWS ECS : AWS에서 제공하는 관리형 컨테이너 서비스. 맥도날드 등 일부 대기업에서도 도입하였고 대부분의 기업 규모에서 충분한 기능 제공

7. Monitor

모니터링은 운영에서 빠질 수 없는 중요한 단계다. 모니터링은 팀에게 필요한 피드백을 제공하고 팀은 어플리케이션에서 추가 작업이 필요한 부분을 찾을 수 있다.

모니터링은 크게 인프라스트럭쳐 모니터링, 어플리케이션 모니터링, 네트워크 모니터링 등이 있다.

인프라스트럭쳐 모니터링 도구 : Prometheus, Nagios, Zabbix

어플리케이션 모니터링(APM) : Datadog, Splunk

네트워크 모니터링(NMS) : Cacti, ntop, Wireshark