Study

앞서 알아보았던 Service 중 외부 요청을 처리하기 위한 것에는 NodePort가 있었다. NodePort는 클러스터 내의 모든 노드에 특정 포트를 오픈시켜 외부로부터 접근할 수 있도록 하는 서비스이다. 이러한 방식으로 클러스터 내부 네트워크로 접근하는 방식에는 사실 몇가지 애로사항이 존재한다. 포트 사용 문제 NodePort는 각 서비스별로 하나의 포트를 고정으로 사용한다. NodePort 기본 정의에 따라 30000~32767 사이의 포트만 지정해줄 수 있다. SSL 인증서 사용 불가 이러한 애로사항을 해결해주기 위해 LoadBalancer 서비스를 사용할 수 있다. 하지만 LoadBalancer는 Public Cloud에 많이 의존하게 되는 것부터 노출시킬 서비스에 대해 각각 IP주소를 가진다는..

데이터모델링의 이해 데이터 모델링 설계과정에서 시스템의 중요한 개념을 논리적인 데이터 모델로 구성하는 작업 물리적인 데이터베이스 모델 구현부터 시스템 데이터베이스 반영과정을 포함 단순히 데이터를 다루는 것이외에도 시스템의 구체적인 흐름을 정의하는데에도 영향을 끼침 정보시스템을 구축하기 위한 데이터 관점의 업무 분석 기법 현실세계의 데이터에 대해 약속된 표기법으로 표현하는 과정 데이터베이스를 구축하기 위한 분석/설계의 과정 데이터 모델링의 3단계 개념적 데이터 모델링 높은 추상화 수준, 포괄적인 수준의 모델링 논리적 데이터 모델링 Key, 속성, 관계를 표현, 재사용성 높음 물리적 데이터 모델링 물리적인 성격을 고려해 설계 데이터 모델링의 3요소 Thing (어떤 것) Attributes (속성) Rela..

Helm kubernetes의 패키지 매니저, 배포하는 환경에 따라 설정값을 따로 정의해서 배포할 수 있도록 패키지 매니저 역할을 한다. Helm에서 패키지는 ‘Chart’라고 하며, chart는 kubernetes 애플리케이션의 리소스 정의로 이루어진다. Helm을 통해 Chart를 설치하는 과정은 Chart가 정의된 helm repo를 추가하고, 해당 repo를 통해 install한다. Helm 아키텍쳐 Helm 아키텍쳐의 구성요소에는 쿠버네티스 클러스터, Helm 클라이언트, Helm Chart Repository가 있다. Helm 클라이언트가 Chart Repository로부터 Chart를 다운로드받고, 이 Chart를 기반으로 쿠버네티스 클러스터의 API 서버와 통신해 Chart를 적용하게 된다..

이번에는 간단한 프로젝트를 Github Actions를 통해 CI/CD 파이프라인을 구성하고 테스트해보도록 한다. 초기 세팅 먼저, 테스트에 사용할 Repository를 하나 생성해준다. 이 Repository를 clone해주고, 내용을 추가한다. 이번에는 따로 코드를 작성하지 않고, Spring 프로젝트를 하나 가져와서 추가해주었다. GitHub - spring-projects/spring-petclinic: A sample Spring-based application A sample Spring-based application. Contribute to spring-projects/spring-petclinic development by creating an account on GitHub. gith..

Github Actions Github Repository를 기반으로 빌드/테스트/배포의 Workflow를 자동화할 수 있는 CI/CD 도구 다른 CI/CD 도구들과 비교했을 때, Github Actions는 딱 Github 플랫폼 하나에서만 모든 CI/CD 과정을 처리할 수 있다는 점이 존재하며, Github이 Workflow를 처리할 수 있는 환경을 자체적으로 제공하기 때문에 Jenkins와 같이 따로 처리환경을 생성하지 않고도 간단하게 사용할 수 있다는 점이 장점으로 존재한다. Github Actions 단위 개념 Workflow Github Actions에서의 최상위 개념으로, 자동화시켜놓은 작업의 전체 과정/흐름이다. 각 Repository의 최상단에서 .github/workflows 디렉토리 ..

컨테이너 설정파일을 관리하는 방법으로는 컨테이너 이미지를 빌드할때에 복사하거나, 컨테이너를 실행했을 때에 외부 호스트에서 파일을 연결해주는 방법이 있다. 쿠버네티스에서는 ConfigMap 리소스를 통해 설정파일을 관리하는 방법을 제공한다. ConfigMap 컨테이너의 환경설정 값을 저장하기 위한 리소스로 키-값 쌍의 데이터를 저장한다. ConfigMap에는 주로 Application의 설정값, 컨테이너의 환경변수, 설정파일과 같은 데이터를 저장한다. 아래는 ConfigMap을 정의하는 Manifest이다. apiVersion: v1 kind: ConfigMap metadata: name: nginx-config data: NGINX_PORT: "8080" NGINX_SERVER_NAME: "my-ngin..

이번에는 쿠버네티스에서 데이터를 저장하는 Volume을 정리해보도록 한다. Volume 컨테이너가 데이터를 저장하고 공유하는 방식을 제공하는 객체, 기존 컨테이너에서의 Volume과 유사하나 더 유연하게 사용할 수 있다. 이전의 Service를 정리했을때에 알아보았듯이 컨테이너는 일시적인 특성을 가져 일반적으로 컨테이너가 삭제되면 컨테이너에 저장된 내용들이 휘발되는 점이 존재한다. 특히나 데이터베이스와 같은 리소스는 파드나 컨테이너가 삭제되더라도 내부의 데이터를 보존을 해주어야하는데, 여기서 Volume을 사용하게 된다. 쿠버네티스에서 제공하는 Volume의 종류는 아래와 같다. emptyDir hostPath PV/PVC emptyDir 파드 내에서만 지속되는 컨테이너의 임시적인 데이터를 저장하기 위한..

Service 파드 집합에서 실행중인 Application을 네트워크 서비스로 노출시키는 방법, 네트워크 추상화를 제공해 동적으로 할당된 파드에 접근할 수 있는 리소스이다. Service의 목적 왜 이런 리소스가 필요할까? 서비스 리소스가 필요한 이유를 일반적인 상황을 통해서 알아볼 수 있다. 웹 Application을 구동시키는 클러스터를 운영하고 있다고 가정해보자. 그리고 이 Application이 Deployment나 StatefulSet을 통해 여러 파드로 분산되어 실행되고 있다고 할 때, 일부 파드가 재생성되는 상황을 생각해보자. 파드가 영구적이지 않은 특성(일회성)을 가짐에 따라, 클러스터의 상황에 따라 언제든지 다른 노드들로 옮겨질 가능성이 존재한다. 이렇게 다른 노드로 옮겨져 생성되면, 매..