Deployment(디플로이먼트)는 ReplicaSet을 관리하는 controller 이다. 또한 ReplicaSet에서는 지원하지 않았던 업데이트에 관한 설정까지도 지원하여 더욱 안정적으로 container들의 운영이 가능하다. 직접 Deployment를 생성해보며 어떻게 사용하는지 살펴보자. (혹시 ReplicaSet에 대해 아직 모른다면 이전 글을 확인바란다.) Deployment 생성 및 동작방식 위의 예제 yaml 파일을 보면 한가지 발견할 수 있는 점이 있다. 그렇다! ReplicaSet을 생성할때와 kind가 바뀐 것 빼고는 완전히 동일하다. Deployment가 결국 ReplicaSet을 관리하는 controller이기 때문인데, 하나씩 살펴보자. kind는 당연하게도 `De

ReplicaSet(레플리카셋)은 관리하는 Pod를 원하는 갯수만큼 유지시켜주는 역할을 하는 controller 이다. 동작방식 ReplicaSet은 지속적으로 상태를 체크하여 원하는 갯수만큼의 Pod를 유지하고자 한다. 따라서 동작방식은 굉장히 간단하며 결국 아래와 같은 두가지 상황에 따라 동작방식이 정해진다. Pod 갯수가 부족할때 - ReplicaSet이 관리하고자 하는 Pod의 갯수보다 실제 동작중인 Pod의 갯수가 부족하다면 부족한 만큼 추가적인 Pod를 생성하여 갯수를 맞춘다. 예) ReplicaSet이 3개의 Pod를 관리하는 도중 어떠한 이유로 인해 Pod의 갯수가 2개로 줄었다면 ReplicaSet이 추가적인 Pod 한개를 생성해 3개로 유지한다. Pod 갯수가 초과할때 - ReplicaSet이 관리하고자 하는 Pod의 갯수를 실제 동작중인 Pod의 갯수가 초과한다면 초과된 갯수만큼 Pod를 종료하여 없앤다. 예)

Controller 이전 포스트에서 Pod의 개념과 배포 방법에 대해 알아보았다. 하지만 일반적으로 Pod를 직접 배포해서 사용하는 경우는 거의 없다고 봐도 무방한데 이유는 그렇게 되면 배포된 모든 Pod를 개발자가 직접 관리해 줘야 하기 때문이다. 우리가 Kubernetes라는 container orchestration tool 을 사용하는 이유 중 하나는 수많은 container 들을 쉽게 관리하기 위해서인데, Pod를 일일이 배포해서 직접 관리를 한다면 그냥 container를 우리가 배포하여 운영하는 것과 전혀 차이가 없다. 그래서 Kubernetes 에서는 Controller 라는 개념으로 Pod의 배포와 관리를 도와 준다. 필요에 따라 다양한 Controller들이 있는데 이번 글에서는 종류와 역할에 대해서

Pod란 Kubernetes 에서 배포할 수 있는 가장 작은 단위이며, 한개 또는 여러개의 container 들의 묶음 이라고 생각하면 된다. 즉 Kubernetes cluster 내에 container를 배포하기 위해서는 container 별로 배포를 하는것이 아닌 Pod라는 단위로 container들을 묶어서 배포를 할 수 있다. 물론 Pod에 대해 처음 공부하려는 사람이라면 위의 말이 이해하기 쉽지 않을 것이다. 걱정말고 직접 예제와 함께 Pod를 생성해보며 개념과 특징들에 대해 알아본 뒤 위의 정의에 대해 다시한번 읽어 보면 좋을 것 같다. Pod 생성 예제와 함께 Pod에 대해 알아보기 위해 제일 먼저 생성하는 방법에 대해 알아보자. 기본적으로 Kubernetes 의 Object 생성은 kubectl 을 이용하는 방법과 yaml 파일을 이용하는 방법이 있다. kubectl을 이용하는 방법은 편리하긴 하지만 Kubernetes clus

쿠버네티스(Kubernetes)를 사용하기 위해 가장 먼저 해야할 일은 클러스터(cluster) 구축이다. 클러스터란 Control plane과 노드(node)들의 집합이며 쿠버네티스 운영의 가장 큰 단위라고 생각하면 되겠다. 한개의 클러스터에 서로 연관없는 서비스들을 다양하게 운영한다면 관리나 실수의 문제가 생길 여지가 높으므로 일반적으로 각각의 서비스 운영은 각각의 클러스터를 구축하여 운영하는 것이 일반적이다. minikube 위에서 설명한 클러스터를 구축하는 방법에는 여러가지가 있다. 그 중 local 환경에 가장 쉽게 클러스터를 구축할수 있게해주는 도구인 minikube에 대해서 살펴보겠다. 설치 전 준비사항 Docker 설치 - minikube에서는 minikube를 설치 및 사용하기 위한 환경으로 Docker를 가장 추천한다. 따라서 minikube 설치 전에 Docker를 반드시 설치하여 사용하는 것이 좋다. **k

쿠버네티스는 여러개의 components 들로 구성되어 있으며 각각의 역할에 따라 구분되어진다. 실제로 쿠버네티스를 사용 하기 전 어떻게 동작되는지 이해한다면 쿠버네티스를 사용하는데 많은 도움이 될 것이다. 아래의 그림과 함께 하나하나씩 살펴보겠다. Kubernetes components 출처: https://kubernetes.io/docs/concepts/overview/components 쿠버네티스는 크게 두 부분으로 나눌 수 있으며 각각 위의 그림 왼쪽박스에 있는 Control Plain과 오른쪽의 Node(일반적으로 worker node 라고 불림)이다. (참고: Node 라는 용어는 application이 돌아가는 하나의 machine 이라고 생각하면 된다.

쿠버네티스를 처음 접하는 개발자들의 진입장벽을 없애고자 하는 목적으로 개념과 사용방법들에 대해 최대한 쉽게 글을 써보려한다. 먼저 쿠버네티스란 무엇인지부터 살펴보겠다. 쿠버네티스(Kubernetes)란? 쿠버네티스(Kubernetes)는 containerized application 을 관리 해주는 오픈소스 플랫폼이다. 쉽게 말해보면 요즘 많은 곳에서 사용하는 기술인 container 를 하나하나 일일이 개발자가 직접 관리 하는게 아니라, 쿠버네티스에게 어떤 방식으로 관리를 해라라고 지시만 내리면 실제 관리는 쿠버네티스가 담당하는 방식이다. 여기에서 얘기한 관리에는 배포방식, scailing, network 등등 굉장하게 다양한 기능들이 포함된다. 따라서 쿠버네티스는 container orchestration 이라고 불리며 Kubernetes 이름의 "K"와 "s" 사이에 8글자가 있어 K8s 라고도 불린다.

Terraform dynamic blocks Terraform 을 이용해서 resource 들을 생성하다보면 종종 사용하게 되는게 resource 내부의 configuration block 이다. 이런 block 들은 한개만 사용될 수도 있지만 경우에 따라서는 여러개를 설정해서 사용하는 경우도 있을 것이고, 한개도 필요 없는 경우도 있을 것이다. 이런 다양한 경우를 좀 더 유연하게 컨트롤 할 수 있게 해주기 위해 dynamic block 이 사용된다. (0.12 버전부터 지원) 예제와 함께 사용법에 대해 알아보자. 사용법 예제 코드를 살펴보며 사용법에 대해 익혀보자. main.tf terraform.tfvars variables.tf terraform.tfvars 파일에서 `ingre

Terraform cloud Terraform cloud란 이름 그대로 Terraform 의 운영환경을 cloud 를 통해 관리할 수 있도록 해주는 서비스다. 예를 들어 Server 를 cloud 환경에서 운영할 수 있도록 해주는 AWS, GCP 같은 서비스라고 생각하면 된다. Terraform cloud 는 Terraform 의 실행환경과 state 를 관리해주기 때문에, 따로 Terraform 을 위한 instance 를 운영하거나 state 관리를 위해 remote 저장소를 사용하는 일은 하지 않도록 도와준다. 즉 Terraform 사용자는 Terraform 운영은 모두 Terraform cloud에 맡기고, Terraform code 를 통해 infrastructure 를 구축하는 일에 집중할 수 있게된다. 그렇다면 어떻게 Terraform cloud 를 사용하면 되는지 살펴보자.

Workspace 일반적으로 서버 개발자들은 목적에 따라 여러개의 환경을 구성하여 서버를 구축한다. (일반적인 예가 dev, staing, production 으로 서버를 각각 구축하여 운영하는 것이다.) 따라서 Terraform 으로 서버 환경을 구축하기 위해서는 이 부분에 대한 고려가 필요한데, 다양한 방법이 있지만 그 중 하나가 Terraform CLI 에서 제공하는 workspace다. workspace란 단어 그대로 구축하고자 하는 서버 환경에 따라 workspace 를 나누어서 각 서버의 상태를 관리하겠다는 뜻이다. 즉 3개의 서버 환경이 구성되어 있고 3개의 workspace 를 만들어서 각각 infrastructure 를 구성하였다면, 총 3개의 상태파일(.tfstate)이 각각 생성되어 관리가 될 것이다. 예제와 함께 사용법에 대해 더 쉽게 알아보자. 예제 코드 먼저 workspace 테스트를 위해 사용할 코드

Module publishing 내가 만든 module 을 혼자 사용하는 것도 좋지만 전세계 사람들과 함께 공유하여 사용한다면 어떨까? 잘 만든 module 을 통해 다른 Terraform 개발자들이 Infrastructure 를 구성하도록 도와줄 수 있다면 아주 멋진 일이 될 것이다. 그렇다면 어떻게 다른 개발자들에게 공유할 수 있을까? Terraform 에서는 Terraform registry 에 누구나 쉽게 자신이 만든 module 을 publish 할 수 있게 해준다. Publish 된 module 은 전세계 개발자들이 누구나 쉽게 검색하여 사용이 가능하다. Module publish 요구사항 Module 을 publish 하기 위해서는 몇가지 따라야 할 요구사항이 필요하다. GitHub - 개발한 module 을 public Terraform registry 에 배포

Module 만들기 이전 포스트 에서 module 을 사용하는 방법에 대해 알아보았으니, 이번에는 module 을 직접 만들어 보겠다. 아래 그림처럼 AWS 의 public, private subnet 을 가지는 VPC 를 구성하는 module 을 만들어보자. AWS vpc example 출처는 이고, web server 나 database server 의 구축은 생략하고 VPC 만 mod

Modules Module 이란? Module 은 한개 또는 여러개의 .tf 또는 .tf.json 파일들로 구성되어 있으며, module 에 따라 한개 또는 여러개의 resource 들을 포함한다. module 내의 파일들은 한개의 directory 에 모두 위치한다. module 은 쉽게 생각하면 일종의 library 라고 할 수 있을 것 같다. 여러 기능들을 포함하고 있는 library 를 만들어서 사용하는 곳에서 원하는 기능들을 사용하듯이, 여러 resource 들을 포함하고 있는 module 을 만들어서 원하는 곳에서 원하는 resource 들을 생성하거나, 필요한 정보를 가져올 수도 있다. module 은 크게 두가지로 나눌 수 있다. Root module - Terraform command 를 수행하는 directory 에 있는 파일들로 구성된 module 을 Root module 이라고 한다. **C

Local values Local values 란 모듈내에서 사용할 수 있는 값이다. 간단하므로 예제와 함께 살펴보자. 선언 방법 locals block 을 통해 선언할 수 있으며, block 안에 다양한 type 의 variables 를 선언할 수 있다. 예제에서는 date, common_tags 두개를 선언하였고 각각 string, object type 으로 선언해주었다. 선언 시 다른 local values, resource attributes, varialbes 를 사용하여 선언하는 것도 가능하다. 사용 방법 선언 방법처럼 사용 방법도 굉장히 간단하다. local. 으로 선언한 local value 를 사용할 수 있다. 위의 예제를 살펴보면 awsiamuser.example1, awsiamuser.example2 의 resource 에서 동일한 tag 값을 가지기 위해

Output values Output values 란 모듈에서 제공하는 값이며, 다른 모듈에서 그 값을 다양하게 사용하여 Infrastructure 구성에 도움을 준다. 모듈의 return value 라고 생각하면 쉬울 것 같다. 선언 방법 예제와 함께 선언 방법에 대해 알아보자. Output values 는 보통 outputs.tf 파일을 생성하여 선언하며 (물론 파일 이름은 개발자 자유이다) output block 을 통해 생성할 수 있다. output 의 이름은 다른 것들과 마찬가지로 다른 output 의 이름과 중복 되어서는 안된다. 사용할 수 있는 Arguments 에 대해서 살펴보자. value를 제외한 모든 Arguments 는 optional 이므로 사용하지 않아도 문제는 없다. value - output 으로 사용할 값을 명시해준다. string, number, list 등등 다양한 type

Input variables Input variables 란 모듈에 제공되는 변수이며, 모듈의 source code 의 변경 없이 모듈을 customize 할 수 있도록 해준다. 쉽게 생각해서 일반적인 프로그래밍을 생각한다면 함수에 전달되는 전달 인자라고 보면 될 것 같다. 선언 방법 예제와 함께 선언 방법에 대해 알아보자. 위의 예제처럼 variable block 을 통해 Input variables 를 선언할 수 있고, "iamusername" 처럼 variable 의 이름을 지정 해 줄 수 있다. variables 의 이름은 value 를 할당하거나 다른곳에서 참조를 할때 사용이 되며, 다른 variable 의 이름과 중복이 되어서는 안된다. 각각의 Arguments 에 대해서 알아보자. 모든 Arguments 는 optional 이므로 사용하지 않아도 문제는 없다. default - variable 의

Data sources Data source 는 Terraform 을 사용하지 않고 만든 infrastructure resource 또는 다른 곳에서 사용중인 Terraform code 를 통해 만들어진 resource 의 Data 를 가져오는데 사용된다. 각각의 provider 들은 resource 와 함께 data source 도 제공하고 있다. Data source 문법 예제를 통해 어떻게 사용하는지 알아보자. 코드의 첫번째 라인처럼 data block 을 통해 원하는 type 의 data 를 가져올 수 있다. 예제 코드에서는 username 이 fooname 인 awsiamuser 의 data 를 가져오도록 하였고 foo 라는 이름을 붙혀줬다. 이처럼 data 를 가져오기 위해서는 data block 안에 정보들(Arguments)을 명시해줘야 하는데, 이 Arguments 에 대한 내용은 각각의 Pr

Resource Meta-Arguments 이전 포스트 에서 resource block 안에서 사용할 수 있는 Arguments 란 무엇인지 알아 보았다. 각각의 resource 들은 해당 resource 를 생성하기 위해 각기 다른 Arguments 를 선언할 수 있다. 하지만 이렇게 각기 다른 Arguments 외에 모든 resource 가 공통적으로 사용 할 수 있는 Arguments 가 있는데, 이걸 Meta-Arguments 라고 부른다. 이번 포스트에서는 이 Meta-Arguments 의 종류와 사용법에 대해서 알아보겠다. 1. depends_on depends_on 이란 이름 그대로 특정 resource 에 dependency 를 설정해 줄때 사

Resource Resource 는 Terraform 의 가장 중요한 구성요소 중 하나이다. Resource 를 선언함으로써 virtual networks, compute instance 등 다양한 infrastructure 를 생성할 수 있다. 바로 실습을 하며 어떻게 사용하는지 알아보자! 쉽게 배울 수 있다. Resource 문법 간단한 예제를 통해 resource 문법에 대해 알아보자. 위의 간단한 예제에서 보이듯이 resource 라는 block 을 만들어서 원하는 resource 를 생성할 수 있다. Type, Name "awsiamuser" 라고 선언된 부분은 resource type 에 해당되는 부분으로 예제에서는 AWS 의 IAM User 를 생성하겠다는 뜻이다. 이 resource type 은 어떤 provider 를 사용하냐에 따라 사용할 수 있는 type 들이 달라진다. (각 provider 의

Provider Provider 란 infrastructure 의 type 이라고 생각하면 될 것 같다. 쉬운 예로 AWS, GCP, Azure 가 각각 provider 라고 생각하면 된다. 물론 다른 provider 들도 굉장히 많다. 여기에서 다양한 provider 들을 확인해 볼 수 있다. 이런 provider 들에 대해 더 자세히 알아보고 싶다면, 여기에서 확인할 수 있다. 이 Site는 Terraform registry 라는 곳인데, 여기에 다양한 Provider 와 Module (Library 라고 생각하면 된다. 추후 해당 내용에 대해 포스팅 하겠다.) 이 등록되어 있고, 해당 내용에 대해 확인할 수 있다. 자! 그럼 이제 드디어! Provider 를 사용하는