이번 포스팅을 하기 위해서 정말 많은 VM을 만들고 부셔봤고, VM도 여러가지 이미지를 사용했다. 그 과정에서 알게 된 것도 있고, 여러가지 개념도 혼재 되는 것 같아 이쯤에서 한 번쯤 정리하고 넘어가고자 한다. 물론 AWS나 GCP, Azure에서 제공하는 Kubernetes를 사용할 수도 있지만, 기본적으로 구축할 줄알아야 나중에 그 걸 쓸 수 있다고 생각한다. 따라서 일단 아주 간단하게 on-premise 환경으로 VM을 구성해본다. 최대한 GUI는 배제하도록 할 것이고, 되도록이면 스크립트로 해결하려고 한다. kubespray를 사용하는 이유는 Ansible과도 최대한 친해지기 위해서다. 그럼 시작해보자. VM을 만들기 위해 Vagrant를 설치해야 한다. Vagrant가 뭔지는 구글링 하면 바로..
Kubespray를 이용하여 쿠버네티스를 설치하는 가이드 Ansible의 playbook과 inventory 설정으로 Kubernetes 클러스터 설치 Kubernetes는 3개의 노드로 구성하기로함(control-pannel, kube-node(2)) OS : Linux ubuntu 22.04 ansible을 이용하므로 모든 vm끼리는 ssh 통신이 되어야 함. 1. ssh key 생성 및 복사 ssh-keygen 명령어를 터미널에서 날리게 되면 prompt에 물어보는게 너무 많은데 이런거 매번 엔터치기 귀찮으니까 한방에 키 생성 ssh-keygen -t rsa -N '' -f ~/.ssh/id_rsa &1 shell script에 IP 정보를 미리 입력해 놓는다. 이렇게 해놓으면 굳이 계속해서 IP를..
resource "local_file" "hello_world" { count = 5 content = "hello_world" filename = "${path.module}/hello_world_${count.index}.txt" } 일반적이랑 반복문이랑 다르게 count의 반복할 횟수를 입력함 그리고 그 때 반복변수는 count.index에 0부터 1씩 증가하면서 저장됨 리스트에 저장된 파일을 반복 variable "names" { type = list(string) default = [ "a", "b", "c" ] } resource "local_file" "hello" { count = length(var.names) content = "hello_${count.index}" filename =..
입력 변수는 필요한 속성 값을 정의해 자주 사용되는 것들이나 일괄적으로 관리하기 위해 사용함 기본 형식은 다음과 같음 variable "image_id" { type = string } variable은 코드내에서 var. 으로 참조됨. variable "password" { default = "p@ssw0rd" sensitive = true } resource "local_file" "hello_world" { content = var.password filename = "${path.module}/hello_world.txt" } sensitive를 true로 설정하게 되면 출력에서 변수값이 감춰짐. 비밀번호나 key값에 유용할듯 그러나 terraform.state는 그대로 저장되니까 주의하도록!!
테라폼으로 정의되지 않은 외부 리소스 또는 저장된 정보를 테라폼 내에서 참조할 때 사용 사용 가능한 메타인수는 다음과 같음 depends_on: 종속성 선언 count: 여러 데이터 소스 for_each: map, set 타입의 데이터 배열의 값을 기준으로 여러 리소스 생성 provider: 동일한 provider가 다수 정의 되어있을 때 사용 lifecycle: 수명주기관리 data "local_file" "hello" { filename = "${path.module}/hello.txt" } resion 내에서 사용 가능한 가용영역 목록 가져오는 방법은 다음과 같다. # Declare the resource data "aws_availability_zones" "available" { state = ..
테라폼의 기본적인 수정주기를 개발자가 의도적으로 변경하는 메타인수다. 해당 메타 인수 내에는 다음의 선언이 가능함 crate_before_destroy: 리소스 수정 시 신규리소스를 우선 생성하고 기존거 삭제 prevent_destroy: 이 리소스는 삭제 안되게 함 ignore_changes: 리소스 요소에 선언된 인수의 변경사항을 무시 precondition: 리소스 요소에 선언된 인수의 조건은 검증 postcondition: Plan과 Apply 이후의 결과를 속성 값으로 검증 create_before_destroy 클라우드의 이미지가 변경되는 경우 사용 리소스의 구분이 사용자가 지정한 특정 이름이나 ID인 경우 기존 리소스에 할당되어 있기 때문에 이는 실패함 삭제 후 생성될때 리소스에 대한 삭제 ..