리액티브 프로그래밍은 본질적으로 함수적이면서 선언적이다. 즉, 순차적으로 수행되는 작업 단계를 나타낸 것이 아니라 데이터가 흘러가는 파이프라인이나 스트림을 포함한다. 그리고 이런 리액티브 스트림은 데이터 전체를 사용할 수 있을 때까지 기다리지않고 사용 가능한 데이터가

스테이트풀 파드 복제하기 여러 개의 파드 레플리카를 실행하면서 개별 스토리지 볼륨을 사용하는 파드를 가지려면 어떻게 해야 할까? 스테이트풀셋은 애플리케이션의 인스턴스가 각각 안정적인 이름과 상태를 가지며 개별적으로 취급돼야 하는 애플리케이션에 알맞게 만들어졌다. 스

쿠버네티스 클러스터에서 실행되는 애플리케이션을 업데이트 하는 방법과 쿠버네티스가 어떻게 무중단 업데이트 프로세스로 전환하는 데 도움을 주는지 살펴보자 쿠버네티스는 레플리카셋 기능을 활용하는 디플로이먼트 리소스를 제공해 선언적인 애플리케이션 업데이트를 가능하게 한다.디플

이 장에서는 특정 파드와 컨테이너 메타데이터를 컨테이너로 전달하는 방법과 컨테이너 내에서 실행 중인 애플리케이션이 쿠버네티스 API 서버와 통신해 클러스터에 배포된 리소스 정보를 얻는 것이 얼마나 쉬운지, 더 나아가 이런 리소스를 생성하거나 수정하는 방법을 알아보자.D

지금까지 실습 과정에서 실행한 애플리케이션에는 어떠한 종류의 설정 데이터도 전달할 필요가 없었다. 거의 모든 애플리케이션은 빌드된 애플리케이션 자체에 포함하지 말아야 하는 설정(배포된 인스턴스별로 다른 세팅, 외부 시스템 액세스를 위한 자격증명 등)이 필요하다. 쿠버네

앞의 세 개 장에서 파드와 레플리케이션컨트롤러, 레플리카셋, 데몬셋, 잡 서비스와 같은 파드와 상호작용하는 쿠버네티스 리소스를 소개했다. 이제 파드 내부로 다시 돌아가 컨테이너가 어떻게 외부 디스크 스토리지에 접근하는지, 어떻게 컨테이너 간에 스토리지를 공유하는지를 살

서비스 소개 쿠버네티스의 서비스는 동일한 서비스를 제공하는 파드 그룹에 지속적인 단일 접점을 만들려고 할 때 생성하는 리소스다. 각 서비스는 서비스가 존재하는 동안 절대 바뀌지 않는 ip주소와 포트가 있다. 클라이언트는 해당 ip와 포트로 접속한 다음 해당 서비스를

파드를 수동으로 생성, 감독, 관리하는 방법을 배웠지만 실환경에서는 배포한 애플리케이션이 자동으로 실행되고 수동적인 개입 없이도 안정적인 상태로 유지되길 원할 것이다.이렇게 하기위해 파드를 직접 생성하는 일은 거의 없을 것이다. 대신 레플리케이션컨트롤러 또는 디플로이먼

파드: 쿠버네티스에서 컨테이너 실행 파드소개 파드는 함께 배치된 컨테이너 그룹이며 쿠버네티스의 기본 빌딩 블록이다. 컨테이너를 개별적으로 배포하기보다는 컨테이너를 가진 파드를 배포하고 운영한다. 일반적으로 파드는 하나의 컨테이너만 포함되지만, 파드의 핵심 사항은 파

도커를 사용한 컨테이너 이미지 생성, 실행, 공유하기도커 설치와 "Hello world" 컨테이너 실행쿠버네티스에 배포할 간단한 node.js 애플리케이션 생성하기격리된 컨테이너로 실행하기 위해 애플리케이션을 컨테이너 이미지로 패키징하기이미지 기반의 컨테이너 실행하기누

액추에이터는 아주 간단한 방식으로 모니터링 및 관리 도구를 제공하는 라이브러리다.서비스 상태를 확인하는 다양한 모니터링 정보에 액세스할 수 있는 일련의 REST 엔드포인트를 구성하고 노출한다. 즉, 스프링 엑추에이터는 서비스 상태를 이해하고 관리하는 데 용이한 운영용

빌드/배포 파이프라인 인 액션 O-stock 서비스의 빌드/배포 파이프라인을 구현하는 데 사용할 다양한 기술을 먼저 그림으로 살펴보자 깃허브 : 소스 코드에 대한 소스 제어 저장소다 깃허브를 빌드 프로세스에 통합하는 다양한 웹훅과 강력한 REST 기반 API를 제공

AWS 서비스를 관리하는 통합도구 AWS CLI (명령줄 인터페이스) 설치( https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html 참고)쿠버네티스 클러스터와 통신하고 상호 작

빌드/배포 파이프라인 아키택처 마이크로서비스 빌드/배포 파이프라인 구축과 관련된 부분과 단계를 보자. 빌드/배포 프로세스는 네 가지 핵심 패턴을 기반으로 한다. 지속적 통합/지속적 전달 : 애플리케이션 코드가 커밋되고 배포될 때만 빌드하고 테스트하지 않는다. 즉,

OAuth2는 애플리케이션이 사용자에게 자격 증명 공유를 강요하지 않고 사용자를 인증하고 권한을 부여할 수 있도록 다양한 메커니즘을 제공하는 유연한 권한부여 프레임워크다. 이러한 인증 메커니즘을 인증 그랜트라고한다.OAuth2에는 클라이언트 애플리케이션이 사용자를 인증

마이크로서비스는 본질적으로 분산되어 있기 때문에 문제가 발생한 위치를 디버깅하는 것은 매우 번거로운 작업이다. 분산된 서비스의 특징은 여러 서비스와 물리 머신, 다양한 데이터 저장소에 걸쳐 단일 또는 복수 트랜잭션을 추적한 후 정확히 상황을 종합하려고 노력해야 한다는

스프링 클라우드 스트림 스프링 클라우드 스트림은 경량 메시지 처리 기능을 마이크로서비스에 쉽게 통합하는 기술이며, 애플리케이션에서 발생하는 비동기 이벤트를 사용하는 지능형 마이크로서비스를 구축할 수 있다. 또한 RabbitMQ와 카프카 같은 메시지 브로커와 마이크로서

OAuth2 OAuth2의 주요 목적은 사용자 요청을 수행하기 위해 여러 서비스를 호출할 때, 요청을 처리하는 모든 서비스에 자격증명을 제시하지 않고도 각 서비스에서 사용자를 인증하는 것이다. OAuth2를 사용하면 그랜트 라는 인증 체계를 통해 REST 기반의 서비

서비스 게이트웨이는 서비스 클라이언트와 호출되는 서비스 사이에서 중개 역할을 하고, 서비스 게이트웨이가 관리하는 하나의 URL로 통신한다. 또한 서비스 클라이언트 호출에서 보낸 경로를 분해하고 서비스 클라이언트가 호출하려는 서비스를 결정한다.정적 라우팅 : 서비스 게이

클라이언트 측 회복성 소프트웨어 패턴들은 에러나 성능 저하로 원격 자원이 실패할 때 원격 자원의 클라이언트가 고장나지 않게 보호하는데 중점을 둔다네 가지 클라이언트 회복성 패턴을 살펴보자아래 사진은 마이크로서비스에 대한 서비스 소비자와 마이크로서비스 사이에 어떻게 위치