목록분류 전체보기 (56)

Provider테라폼은 terraform 바이너리 파일을 시작으로 로컬 환경이나 배포 서버와 같은 원격 환경에서 원하는 대상을 호출하는 방식으로 실행된다. 이때 호출되는 대상은 프로바이더가 제공하는 API를 호출해 상호작용 하게 된다. 즉, 테라폼이 대상과의 상호작용을 할 수 있도록 하는 것을 프로바이더라 한다. 각 프로바이더의 API 구현은 서로 다르지만, 테라폼의 고유 문법으로 동일한 동작을 수행하도록 구현되어 있다. 프로바이더는 플러그인 형태로 테라폼에 결합되어 대상이 되는 클라우드, SaaS, 기타 서비스 API를 사용해 동작을 수행한다. 각 프로바이더는 테라폼이 관리하는 리소스 유형과 데이터 소스를 사용할 수 있도록 연결한다. 그렇기 때문에 테라폼은 프로바이더 없이는 어떤 종류의 인프라와 서비스..

Terraform 조건식테라폼에서의 조건식은 삼항 연산자 형태를 갖는다. ? : 조건식의 각 조건은 비교 대상의 형태가 다르면 테라폼 실행 시 조건 비교를 위해 형태를 추론하여 자동으로 변환되는데, 혼란이 발생할 수 있기 때문에 명시적인 형태로 작성하는 편이 좋다.var.example ? tostring(12) : "hello" # 권장var.example ? "12" : "hello" # 권장 count와 조건식을 결합하여 사용하는 경우 특정 조건에 따라 리소스 생성 여부를 선택하는 방식으로 작성할 수 있다.variable "enable_file" { default = true}resource "local_file" "foo" { count = var.enable_file ? 1 : 0..

Helm?헬름은 The Package Manager for Kubernetes, 즉 쿠버네티스의 패키지 관리를 위한 툴이다. 여기서 패키지란, Helm Charts를 패키징한 것을 의미한다. 여기서 차트란 쿠버네티스의 리소스 yaml 파일을 템플릿화하여 메타 정보 파일 등을 압축한 파일을 뜻한다. 템플릿이란 쿠버네티스 환경에서 특정 프로그램을 실행시킬 수 있도록 해주는 리소스인 Deployment 혹은 Service 등을 포함하는 일종의 리소스 모음을 의미한다.Helm Chart StructureHelm의 공식문서를 살펴보면 헬름 차트는 이와 같은 구조를 갖는다. 구조에서 확인할 수 있는 각 파일 및 폴더는 다음과 같은 역할을 한다. templates/ 디렉토리는 template 파일을 보관하기 위한 디..

Terraform 반복문list 형태의 값 목록이나 Key-Value 형태의 문자열 집합인 데이터가 있는 경우 반복문을 통해 관리할 수 있다. 또한, 단순한 자료구조뿐만 아니라 리소스 내에 생성된 블록에 대한 것도 반복문을 통해 코드의 중복 없이 동적으로 생성이 가능하다.count리소스 또는 모듈 블록에 count값이 정수인 인수가 포함된 경우 선언된 정수 값만큼 리소스나 모듈을 생성하게 된다.count에서 생성되는 참조값은 count.index이며, 반복하는 경우 0부터 1씩 증가해 인덱스가 부여된다. main.tf를 아래와 같이 작성해보자.resource "local_file" "abc" { count = 5 content = "abc" filename = "${path.module}..

Terraform initterraform init 명령어는 테라폼 구성 파일이 있는 작업 디렉토리를 초기화하는데 사용한다. 이 작업을 실행하는 디렉토리를루트 모듈이라고 부른다. 테라폼에서의 모듈이란?테라폼이 실행되는 디렉토리를 모듈이라고 부른다. 모듈에는 테라폼 코드 정의를 위한 tf 또는 tf.json 확장자의 파일과 tfvars 같은 변수를 정의하는 파일이 포함된다. 일반적으로 기본 작업 디렉토리의 정의된 파일 집합을 루트 모듈이라고 부른다. 루트 모듈은 다른 모듈을 호출해 해당 루트 모듈이 구성하는 리소스 구성을 포함시킬 수 있고, 이렇게 호출되는 모듈을 자식 모듈이라고 한다. 테라폼을 시작하는데 사용되는 첫 번째 명령어로 테라폼에서 사용되는 프로바이더, 모듈 등의 지정된 버전에 맞춰 루트 모듈을..

k8s Storage컨테이너 환경에서는 별도 설정을 하지 않으면 데이터는 호스트 노드의 임시 디스크에 보관된다. 컨테이너를 삭제하면 임시 디스크에 있는 데이터는 저장되지 않고 컨테이너와 함께 삭제된다. 이러한 문제를 쿠버네티스에서는 Pod와 데이터를 분리해서 영구 볼륨이라는 별도의 추상화된 리소스로 해결한다.쿠버네티스 볼륨을 구성하는 주요 리소스로 Persistent Volume (영구볼륨), PVC (Persistent VolumeClaim, 영구볼륨 요청자), Storage Class가 있다. 클러스터 관리자와 사용자(개발자)의 역할에 따라 쿠버네티스 볼륨에 관련된 작업이 서로 다르다. 클러스터 관리자는 클라우드 서비스 제공업자, 상용 혹은 오픈소스 솔루션 중에서 원하는 성능과 기능을 제공하는 스토리..

AWS Load Balancer Controller?AWS Load Balancer Controller는 Kubernetes 클러스터를 위한 AWS Elastic Load Balancer를 관리하는 add-on이다. 따라서 별도로 AWS Load Balancer Controller를 추가 설치하여 로드 밸런서를 관리하는 것이다.그림과 같이 클러스터 내부에 다수의 Pod가 존재하고 연결을 위해 AWS ELB를 구성했다고 가정해보자. 이 상황에서 AWS Load Balancer Controller는 Control Plane과 상호 작용하여 대상 Pod의 정보를 확인하고 이벤트를 모니터링 하는 것으로 클러스터 내부의 Pod 정보를 취득할 수 있다. 그리고 AWS ELB로 해당 Pod 정보를 프로비저닝하여 타겟..

Amazon VPC CNI 소개Amazon EKS는 Amazon VPC CNI 플러그인을 통해 클러스터 네트워킹 환경을 구성한다. CNI는 Container Network Interface의 약자로 컨테이너 간 네트워킹을 제어하는 표준이라는 의미를 가진다. 참고로 Kubernetes의 경우 kubenet이라는 자체 CNI가 존재하지만 기능적 측면에서 제약이 많아 외부 플러그인을 주로 사용한다. Amazon VPC CNI는 AWS VPC와 자연스럽게 연계되어 네트워킹 환경을 구성할 수 있다. 이로 인해 다양한 VPC 서비스와 통합이 가능하다. Pod와 Node의 IP를 동일한 대역으로 할당할 수 있으며 이로 인해 통신에 대한 오버헤드가 거의 발생하지 않는다.Assign IP Address on Pod노드에..

OSI 7 Layer User Mode 레벨에서의 OSI 7계층은 각각 Application Layer, Presentation Layer, Session Layer가 존재한다. User Mode 레벨에서의 계층의 전송 단위는 Data로 표현되며, 호스트(PC 혹은 노트북)가 주요 장비라고 볼 수 있다.Application Layer사용자와 가장 밀접한 계층으로 인터페이스 역할응용 프로세스 간의 정보 교환을 담당ProtocolHTTPFTPPresentation Layer데이터 형식을 설정한다송신자에게서 온 데이터를 해석하기 위한 Application Layer 데이터 부호화수신자 측에서 데이터의 압축을 풀수 있는 방식으로 데이터 압축데이터의 암호화 및 복호화ProtocolJPEGMPEGSession La..

SRP (Single Responsibility Principle): 단일 책임 원칙"어떤 클래스를 변경해야 하는 이유는 오직 하나뿐이어야 한다."- 로버트 C. 마틴위의 그림과 같이 Man 클래스에 의존하고 있는 다양한 클래스들이 존재한다고 생각해 보자. 그림에서부터 확인이 가능하듯 Man 클래스에 부과된 역할과 책임이 너무 많기 때문에 남성의 표정이 그리 밝지 않다. 어느 날, 여자친구와 헤어질 경우 Man 클래스는 챙길 일 없는 기념일과 사랑한다고 말할 대상이 사라져 힘들어하게 된다. 거기다 여자친구와 결별한 영향이 부모님과 직장 상사에게 까지 영향이 미칠 수 있다. 이렇듯 한 클래스에 너무 많은 책임이 집중될 경우 발생할 수 있는 악영향과 관리의 어려움을 예방하기 위해 책임을 분리하라는 것이 단일..