소년스튜디오

본 챕터는 OINLY WRML 에 관한 내용이므로 스킵한다.

바디 정보 Content-Type 요청 또는 응답의 BODY 데이터 타입을 기술. Content-Length 바디의 크기를 byte 단위로 기술한다. 드물게, utf-8 처리를 제대로 하지 않아 한글을 자소단위로 처리하여 Content-Length 를 잘못 구성하는 라이브러리도 존재 하므로 오류 발생시 이 부분도 고려. Location 새로 생성한 리소스의 URI 를 나타낸다. Content-Location 과는 다르다! 조건부 요청 GET, POST, DELETE 는 리소스에 대한 변경을 수행하며, 서버는 조건부 수행을 지원해야 한다. Last-Modified 리소스의 마지막 변경 시점을 나타낸다. Last-Modified 와 관련하여 아래의 조건식을 사용할 수 있다. If-Unmodified-Sinc..

HTTP 요청 메서드 REST API 리소스 모델에서 각 메소드는 고유한 의미를 가진다. GET - 리소스 상태의 표현 HEAD - 메타데이터 조회 PUT - 새 리소스 생성 또는 갱신 DELETE - 자식 리소스 제거 POST - 새 리소스 생성 또는 컨트롤러 실행 세부 규칙 터널링 금지 터널링이란 원래 의도와 맞지 않게 HTTP 를 사용하는 행위를 뜻한다. GET 리소스의 상태 표현을 조회한다. HEAD 응답 헤더(메타데이터)를 조회한다. 바디가 없다. PUT 리소스 삽입, 갱신 을 위해 사용한다. 변경한 값을 갖는 메시지 바디를 포함할 수 있다. POST 새로운 리소스 생성 시 사용한다. 새 메시지를 나타내는 메시지 바디를 포함할 수 있다. 컨트롤러 리소스를 실행할 수 있다. DELETE 오직 특정..

URI 형태 마지막 슬래시(/) 를 포함하지 않는다. 가독성을 높이기 위해 하이픈(-)을 사용한다. 밑줄(_)은 사용하지 않는다. 소문자를 사용한다. 확장자는 사용하지 않는다. URI 경로 도큐먼트 이름 - 단수 명사. 컬렉션, 스토어 이름 - 복수 명사. 컨트롤러 이름은 동사(구). 변하는 부분은 유일한 값으로 대체. CRUD 는 포함하지 않는다.

웹 아키텍쳐의 제약사항 클라이언트/서버 클라이언트와 서버의 역할을 명백히 분리한다. 균일한 인터페이스 인터페이스는 일관성 있게 분리되어야 한다. 자원 식별 - 요청 자체만으로 대상 자원을 식별할 수 있다 ( ex: uri ). 기술을 통한 자원 처리 - 요청에 포함된 메타데이터를 비롯한 자원에 대한 기술만으로 대상을 충분히 수정하거나 삭제할 수 있다. 자기 서술적 메시지 - 메시지는 자신을 어떻게 처리할 지에 대한 충분한 정보를 제공한다. HATEOAS - 클라이언트의 동작을 위해 별도의 하드코딩이 필요 없으며, 응답 또는 문서 만으로 모든 동작을 기술할 수 있다. 계층 시스템 - 보안, 부하 분산, 응답 속도 개선등의 목적으로 네트워크의 중간 매체를 이용하되, 사용자는 이를 인지하지 못하도록 배치할 수..

클러스터를 구성하는 container가 생성 즉시 가용상태가 된다고 보장할 수 없다. 어떤 container는 만듬과 동시에 가용할 수도 있고, 어떤 container는 일정 시간이 경과해야 가용할 수 도 있다. 또 다른 container는 초기에는 거짓으로 가용한것 처럼 보여주므로 일정 시간 이후 부터 가용성을 확인해야 할 수도 있다. k8s는 가용성을 판별하기 위한 readinessProbe와 무분별한 rollout 진행을 막기 위한 minReadySeconds 설정 등을 제공하고 있다. rollout 레벨 minReadySeconds를 지정하면 새 pod 생성 후 해당 시간만큼 rollout을 중지한다. 어떤 pod가 초기화 하는데 t 시간이 반드시 필요하다면 그만큼을 minReadySeconds로..

본 챕터에서 다룰 내용 : 1. 롤링 업데이트란? 2. 지시적 업데이트 3. 선언적 업데이트 4. 롤아웃 제어 업데이트 전략 어플리케이션은 변하기 마련이고, 이에 따라 이미 배포한 파드도 업데이트가 필요하다. 일반적인 운영 환경이라면 두가지 시나리오를 생각해 볼 수 있다. 재생성 (=Recreate) 삭제 후 교체한다. 1) 기존 운영중인 파드를 모두 내리고 2) 새로운 파드를 동시에 생성한다. 이 방법은 상대적으로 깔끔하다. 데이터가 꼬일 일도 없고, 사용자가 새로고침 할 때 마다 다른 버젼의 서비스로 접속하는 혼선을 원칙적으로 차단한다. 하지만 이 방식은 결정적으로 다운타임이 발생한다. 요즘의 "무중단" 트랜드와는 맞지 않다. 블루 그린 디플로이먼트 1) 먼저 새로운 파드를 모두 생성하고 2) 서비스..

글 쓰기에 앞서... 이 스터디 시리즈는 불과 넉 달 전까지 도커조차 쓸 줄 몰랐던 글쓴이가 엉겁결에 쿠버네티스 인 액션 스터디에 참가하면서 자신이 공부한 것을 정리한 내용이다. 따라서 책 내용뿐만 아니라 자신이 이해한 나름대로의 해석을 같이 포함하고 있다. 전체적인 맥락은 책과 통하지만, 부분 부분 책이 포함하고 있지 않은 내용도 담고 있다. 아울러 글 전개 순서는 책의 순서가 아닌, 글쓴이가 참가한 스터디의 진행 순서를 따름을 원칙으로 한다. 출처 명시가 되어있지 않은 것은 (이미 공개 중인) 쿠버네티스 인 액션 영문판과 직접 제작한 자원임을 밝힌다. 본 챕터에서는 1. 쿠버네티스를 소개하고 왜 쿠버네티스 같은 도구가 필요하게 되었는지 2. 컨테이너 기술이란 무엇이며 가상화와 어떻게 다른지 3. 어떻..