별로 길게 안적었어요

인스턴스를 어느 사이즈로 고를까? 디스크 사이즈는 어떻게 할까? 내가 골라준 인스턴스, 리소스들을 쿠버네티스를 어떻게 다룰까? 노드당 pod 비율을 어떻게 할까? 이런 전반적인 Resource에 대해서 다룬 chapter이다. 쿠버네티스는 pod의 limit을 정해둘 수가 있고,(yaml 파일의 resources 항목을 채우면 된다.) 스케줄러는 pod의 크기와, 클러스터의 여유공간을 비교해, 적절한 위치에 pod를 배치시킨다. 이런 클러스터 조율이라는게 늘 그렇듯이 저자 또한 자신의 Rule of thumb을 설파한다. - Container를 작게 유지해라 - 노드당 pod limit이 있기 때문에 너무 큰 인스턴스는 자원낭비이며, 동시에 너무 작은 인스턴스는 os 크기 등의 overhead가 있다. ..

chapter 4는 쿠버네티스가 뭘 어떻게 실행하는지 살짝 맛만 보여주고 넘어가는 챕터다. 쿠버네티스에 혀끝만 살짝 닿게 만들고 chapter 5에서 다시 이론 수업으로 돌아가버린다. 이 책의 가장 큰 특징이며, 장점이자 단점은, 여러가지를 전부 다 한번씩 맛보여 주고 싶어 한다는 점 같다. 입문서적이라 덜 자세하게 쓰려고 하며, 전문적인 내용을 한번씩 다 보려주려다 보니까. 처음 접하는 사람에게는, 어? 이거 다 이해 안됬고, 뭔소리 하는지 전혀 모르겠는데 여기서 넘어가도 되나? 싶은 생각이 들어 혼란이 오게끔 만든다. Deployment 1페이지 -> Pods 1페이지 -> ReplicaSet 1페이지 -> Service Resource 순으로 저자가 만들어 놓은 어플리케이션을 돌려보는 과정을 거치지..

2. First Steps with Kubernetes 나는 처음에 Docker만 사용할 줄 알고, kubernetes는 이름만 들어본 정도여서, 처음에는 Docker랑 상관없는 별개의 Container system이 기능만 다양해진 거라고 생각했다. 그래서 유료 강의들, 책 앞부분에 항상 docker container에 대해서 다루는 걸 보면서, "아, docker보다는 쿠버네티스에 대해서 다뤄주지..." 같은 멍청한 생각을 했었다. Kubernetes는 Docker, 혹은 다른 Container 시스템을 사용해서 돌아가는, Container를 대신 다뤄주는 시스템이다.(kubernetes가 별개로 컨테이너 시스템을 갖춘것이 아니다.) 그래서 처음에는 docker에서 쓰는 명령어를 거의 안쓰니까 손대기..

어느 책이나 시작 지점은 늘 그 책을 관통하는 주제나, history를 기록해 놓곤 한다. 이 책의 경우, 1) 클라우드의 발전으로 인해 computing 자원을 사는 것이 아닌 빌리는 것을, { 웹서비스를 한다 = 서버를 사서 소프트웨어를 올린다 에서, 웹서비스를 한다 = 하드웨어를 빌린다. 로 바꾼 클라우드 기술. } 2) DevOps에 대해, { CAMS 란 : Culture, Automation, Measurement, Sharing - by John Willis : The influential DevOps writer } 3) docker를 필두로한 컨테이너 기술에 대해 { 하드웨어를 추상화해서 하드웨어와 소프트웨어를 디커플링 시키는 컨테이너 기술들. VM은 container에 비해 perfor..

chapter 2는 AWS 비교적 단순한 형태만을 사용해 web 서버를 구축하는 것이었기에, 따라하기만 하면 되는 챕터 였다. 코드의 깃허브 주소다. 대부분이 따라입력해 본거고, 2~3개 정도의 명령어가 책에는 옛날 버전으로 되어 있기에 새 버전으로 변경해준 것이 전부인 상태다 https://github.com/sts2885/devops_study GitHub - sts2885/devops_study Contribute to sts2885/devops_study development by creating an account on GitHub. github.com 아무튼 챕터 2 최종 목표인 LB와 ASG를 연결해서 Hello world를 띄워 봤다. 와~ git checkout으로 이 시점 commit으..

"책 내용을 다 정리하는 것이 아니라, 읽고 나서 생각했던 점을 적는 짧은 리뷰" 구조 #키워드 { 내용 } #문제점 : 개발자가 코드를 만든후, 운영팀에게 대충 던져 놓고 간다. { 공감이 정말정말 크게 되는 문장 같았다. 이상적이지 않게도, dev 와 ops는 서로 Adversarial한 관계이기 때문에, 책에서 나온 삽화 처럼 개발자가 코드 만들어서 벽 너머로 던지면, 서버에서 코드 실행 ⇒ 안되는 구조를 실제로도 띄게 된다. dev : 인터넷 안돼. 내 pc에선 된다니까? 니가 만든 인프라가 문제잖아? ops : 아니 인터넷 연결 해놨다고, 니 코드가 문제라니까? 실제로 우리 회사에서 수도 없이 많이 일어나는 일이다. 서로 싸우느라 고객에게 양질의 서비스가 제공되는건 어느새 뒷전이 된다. 그 무엇..