git에서 좀 더 발전해서 ci/cd생김 개발자가 테스트하고 빌드하고 임의로 다운받고 클라우드로 받은다음 deploy하는데 이걸 매번하면 귀찮다.

자동으로 테스트하고 자동으로 빌드도 하는 과정.

이전에는 빌드만 먼저하고 테스트서버에서 확인하고 문제 없으면 운영서버에 배포하고. 그 빌드를 여러곳에서 배포.

배포만 하면 서버가 몰리면 다운될 수 있다. 내가 다른일을 하고 있으면 다운된 걸 모를 수 있으니 모니터링도 추가한다.

각각 서비스에 따라 커지게 되면 microservice로 분리하는 과정을 거치게 된다.

여러가지 프로세스가 필요하게 되고 이걸 잘 관리하는게 데브옵스의 역할이고 도커와 쿠버네티스가 제일 많이 쓰인다.

어떤 기술이 있는지 알아보고 어떤 문제를 해결하는지 이해하고 적절한 시기에 적용한다.

(너무 빠르면 오버 엔지니어링, 너무 늦으면 기술 부채)

서버를 관리 한다는 것

자체 서버 운영

• 서버 주문 > 서버 설치 > CPU, 메모리, 하드 조립> 네트워크 연결 > OS 설치 > 계정 설정 > 방화벽 설치
  • 서버를 설정하기 위해 많은 노력과 시간 필요
  • 성능이 좋은 걸 미리 구매하고 효율적인 사용을 위해 여러 어플리케이션 설치

node.js를 서버 관리한다 치면(자체서버에)

처음에 시스템 유저, 환경변수, 방화벽 설정 그리고 노드 js설치하려면 dependencies설치하고 그제서야 노드 설치. 다음 소스 깃으로 받고 패키지 인스톨 하고 관련 설정하고 디비가 있으면 마이그레이션 하고 여러개 서버가 있으면 프록시 서버를 설정해주고나서야 실행이 가능해진다.

이젠엔 서버관리시 코드가 아닌 문서로 관리했는데 그럼 문서를 다른 사람이 읽거나 하기 어려워서 한명이나 관리하던 그룹들이 계속 관리했는데 코드로 관리하면 그런 단점이 약간 사라졌다.

가상머신만 있으면 일단 뜨긴 뜬다. 가상머신은 돌아가는 걸 보장해준다. 하나의 서버에 가상머신 여러개 해서 쓸 수 있다.

클라우드

• AWS, Google Cloud, Azure, …
• 하드웨어 파편화 문제 해결
• 가상화된 환경만으로 아키텍쳐 구성 가능해짐
• 이미지 기반으로한 다수의 서버 상태 관리
  • 상태관리에 대한 새로운 접근
  • 서버 운영의 문제는 여전히 남아있음.
• 마치 전기를 사용하듯 편리

PaaS

• Heroku, Netlify, AWS Elastic Beanstalk, Google Cloud App Engine,…
• 서버를 운영하는 것은 복잡학 ㅗ어렵다.
• 소스코드만으로 배포 가능
• 일반화된 프로비저닝 방법 제공
  • 프로비저닝 과정에 개입할 수 없음.
  • 예) 헤로쿠의 buildpacks
• Pas는 서버운영의 은탄?

도커의 등장

• 컨테이너 : 격리된 환경에서 작동하는 프로세스
• 리눅스 커널의 여러 기술 사용
• 하드웨어 가상화 기술보다 가벼움
• 이미지 단위로 프로세스 실행환경을 구성

vm은 가상머신에서 쓰는 (가상 OS에서 쓰는 ) 메모리나 cpu점유율이 있는데 도커는 전혀 그런게 없다.

도커가 가져온 변화

• 클라우드 이미지보다 관리하기 쉬움
• 다른 프로세스와 격리되어 가상머신처럼 사용하지만 성능저하(거의) 없음.
• 복잡한 기술(namespace, cgroups, network,…)를 몰라도 사용 가능
• 이미지 빌드 기록이 남음
• 코드와 설정으로 관리 > 재현 및 수정 가능
• 오픈소스 > 특정회사 기술에 종속적이지 않음.

위 예시는 도커 본격적 도입하면 도커 4개의 앱이 있고 3개씩 띄워둠.

도커는 사이즈가 커지면 관리가 어려울 수 있다.

도커가 해결한 건 코드 만들고 컨테이너 형식으로 빌드하고 어떤 서버에 배포하는건 도커가 해주는데 배포 한 이후에 복잡해졌다.

실행까지는 도커가 편하게 해줬는데 배포하는건

첫번쨰 서버에 접속하고 도커 stop하고 run하면 서버 실행이 각각 하나씩 된다.

이러면 매번 하나하나 접속해야 해서 불편하다.

도커 그 이후?

서비스 검색은 어떻게 하나?

프록시 서버는 서버의 뒷단에 웹서버 한대가 있다. 사용자는 프록시 서버에 접속하는데 여기에 웹서버 하나를 더 추가하면(사용자가 많아지면) 사용자가 하나 더 바라보게

그럼 기존엔 서버하나 보던걸 2개 보게 되서 좋긴한데 한땀한땀 다 설정해야된다.

LoadBalancer fh 아이피 설정 추가해주고 이런 과정 필요

각 주소 따라 보내기도 가능한데(nginx)들어가서 저거를 자동으로 해줄 수 없을까?

서비스 이상, 부하가 일어나면 모니터링을 어떻게

할까?

모를 수 있다.

App1은 한대는 죽었지만 2대 살아서 잘 되는 거처럼 보이지만 모니터링을 안하면 모를 수 도 있다.

그래서 컨테이너 오케스트레이션 이라는 도구가 나왔다.

컨테이너 오케스트레이션

서버가 죽는데 서버를 새로 띄워주는 프로그램 짜다 보니 이 도구가 생겼고

컨테이너 오케스트레이션은 위 예시 서버가 3대 있는데 클러스터라는 개념이 있고 마스터로 묶어둠. 배포해주라 하면 알아서 배포해주고 자세히는 몰라도 되지만 1000대 ,2000대가 되도 알아서 배포해준다.

서버를 더 띄우고 싶으면 저기 서버부분을 2->3으로만 밖면 서버를 한대 더 띄운다. 만약 3대중 한대가 문제면 다른 서버를 띄워준다.

그리고 여유가 가장 많은 서버에 띄워주는 것도 개발자가 하던 일을 컨테이너 오케스트레이션이 자동으로 해주게 된다.

만약 서버가 띄울 공간이 없으면 서버를 만들어서 띄운다.

그리고 v1(버전1을)쓰다가 v2로 바꿀일이 있어서(배포라던지 다른 이유로) v2로 바꾸고 쓰고 v1로 다시 돌아가려면 이곳도한 버젼만 바꿔주면 된다.

서비스 등록도

매번 ip를 손으로 등록했어야 하지만 오케스트레이션은 ip가 생길때마다 자동으로 중앙에서 저장해준다.

볼륨을 붙이는 경우에도(디렉토리 확장하는 경우에도) nfs가 되던 ebs가 되던 구글 클라우드가 됐건 설정만 하면 오케스트레이션에 자동으로 붙여주면 된다.

도커가 나오니까 서버 관리자 측에서 편해졌는데 서버 컨테이너를 하나하나 관리하기 어렵고 그래서 오케스트레이션이 나오게 되었다.

그리고 다양한 오케스트레이션이 나왔었는데 이 경우는 다른 오케스트레이션을 쓰려면 쓸때마다 그 기술스택을 공부해야한다. 현재는 쿠버네티스가 대세로 자리잡게 되었다.

쿠버네티스

• 컨테이너를 쉽고 빠르게 배포/확장하고 관리를 자동화해주는 오픈소스 플랫폼.

• 1주일에 20억개의 컨테이너 생성하는 구글이 컨테이너 배포시스템으로 쓰던 brog를 기반으로 만든 오픈소스

오픈소스: google, redhat, huawai,vmware,microsoft,ibm,intel… 등 유명한 회사는 다 있다.

• 쿠버네티스는 무한한 확장성으로 리눅스 명령어를 실제 입력하진 않음. 리눅스를 잘 몰라도 쿠버네티스만 알아도 서버관리가 가능해졌다.

그리고 사실상의 표준이 되어서(모든회사에서 공통적으로 써서) 이거만 알아도 돌아가게 된다.

도커도 쿠버네티스 지원을 안하다가 지원을 하게 됨.

아까 위의 타 경쟁사들도 껍데기만 다를 뿐 쿠버네티스로 다 바뀌였다.

CNCF

어떻게 하면 클라우드에 적합하게 개발할 수 있나.

이 모든것들이 다 쿠버네티스에서 돌아간다.

컨테이너 오케스트레이션의 사실상의 표준(de facto)

cloud native의 핵심 역할

• 도커는 각 앱마다 필요한 환경을 컨테이너로 관리하는 프로그램
• 쿠버네티스는 각 컨테이너의 배포를 중앙관리하는 프로그램

쿠버네티스 안에서 도커가 돌고 있는거고 배포의 역할을 도커가 한다.

배포프로세스 개선(2차개선)

배포 프로세스 고민

• 배포를 더 자주 할 수 있을까? -> 더 작은 단위로 자주 배포하자.

• 배포를 더 빠르게 할 수 있을 까? -> 소스를 푸시하면 자동으로 배포하자
• 배포를 더 많이 할 수 있을까? -> Test서버를 늘리자
• 배포를 더 자유롭게 할 수 있을 까? -> 배포 권한을 확대하자.

그 전에는 깃에 올리면 빌드와 배포가 하나까지 이어져서

도커는 배포하면 무조건 빌드함.

도커 이미지가 커밋 이미지마다 다 생김. 필요할때마다 배포하면 됨(2번기능이 끝나면 2번 배포) 이미 빌드된 배포이미지를 배포하면 된다.

2차개선의 장점

• 모든 브랜치는 자동으로 빌드되어 도커이미지로 만들어짐
  • 바로 배포 가능한 도커이미지가 항시 대기중
• 테스트, QA를 하기 위해서 여러개의 서버 중 원하는 서버를 사용하고 완료되면 종료
  • 누가 몇번 서버에서 어떤 브랜치 테스트중인지 젠킨스에서 확인

• 진행중인 테스트를 기다리지 않고 여러개의 테스트를 동시 진행 및 배포

  • 테스트 서버 2대 > 5대

새로운 문제점

• 테스트 서버를 관리해야하는 불편함(1번 서버로그인 테스트, 2번 결제테스트..)

• 사용하지 않는 테스트 서버의 자원 낭비(0~8시 종료)
• 테스트 몰릴 경우 여전히 기다려야하는 문제
• 가끔 배포화면 입력 실수
• 테스트 완료한 서버회수가 늦어짐
• 젠킨스는 괜찮았지만 획기적인 개선이 어려움.

그래서 GitOps를 도입했다.

깃을 설정하는 옵션을 배포하는 설정을 배포한다 보면 된다.

처음에 배포하면 이미지 만드는데 배포용 깃에 또 푸쉬해줌.

그럼 ArgoCD가 읽어서 쿠버네티스에 만들어줌.

이게 거의 무제한으로 바뀜

클라우드는 사용하고 싶은 만큼 사용 가능하기 떄문

DevOps 역할

• 서비스를 배포하고 지원+ 모니터링
• 배포 파이프라인 구성
• 더 자주 더 빠른 릴리스
• Cloud(AWS, Google Cloud, Azure,…)/Cloud native
• 컨테이너(Docker, Kubernetes,…)
• 보안 Network, IAM, Service Mesh,…
• 장애 대응
• IAC - 테라폼,…
• SRE -SLI, SLO,…
• 외부서비스 - DataDog, NewRelic,…

https://roadmap.sh/ https://roadmap.sh/devops

덤) 10주 실전압축 DevOps스터디(1회 이상 배포 경험 필)