고급 Terraform 모듈을 사용하여 Oracle Cloud Infrastructure Kubernetes Engine(OKE) 배포

소개

이 자습서는 Oracle Cloud Infrastructure Kubernetes Engine(OKE) 자동화 시리즈의 두 번째 자습서로, 첫 번째 Terraform을 사용하여 Oracle Cloud Infrastructure Kubernetes Engine 클러스터 생성의 기본 개념을 기반으로 합니다. 이 문서에서는 Oracle Cloud Infrastructure(OCI)에서 확장 가능하고 탄력적이며 커스터마이징이 가능한 환경을 프로비저닝하기 위한 고급 자동화 및 모듈식 설계를 도입하여 OKE 배포를 한 단계 업그레이드합니다.

Oracle 엔지니어 및 고객을 위해 설계된 이 가이드를 통해 기본 Terraform 구성을 모든 배포 크기에 맞게 조정할 수 있는 구조화되고 재사용 가능한 모듈로 변환할 수 있습니다. Terraform(커뮤니티 버전)과 Jenkins 및 Oracle CLI(명령행 인터페이스)가 결합된 코드형 인프라(IaC) 원칙을 활용하여 OKE 클러스터, 해당 구성 및 자동화된 테스트를 위한 single-click 프로비저닝 솔루션을 제공합니다.

이 자습서에서는 다음 네 가지 주요 영역을 중점적으로 다룹니다.

  1. 모듈식 설계 및 자동화: VCN, OKE 클러스터, 배스천 호스트와 같은 핵심 구성요소에 재사용 가능한 모듈을 빌드하고, 호환성을 위한 버전 지정을 통해 관리를 간소화하고 코드 재사용을 촉진합니다.
  2. 동적 구성: 일관되고 반복 가능한 배포를 위해 단일 코드베이스에서 환경별 설정(dev, test, prod)을 관리합니다.
  3. 고급 노드 풀: 특수 구성, 호환 가능한 OKE 이미지, 지능형 워크로드 배치용 레이블을 사용하여 리소스 사용량 및 비용을 최적화합니다.
  4. 완벽한 CI/CD 통합: 효율적인 one-click 배포를 위해 Terraform, Jenkins 및 OCI CLI를 통합하는 파이프라인을 사용하여 OKE 프로비저닝 및 업데이트를 자동화합니다.

이 설명서에 설명된 아키텍처는 계층형 네트워크 토폴로지를 사용하여 안전하고 확장 가능한 기반을 만듭니다. 제어 플레인, 작업자 노드 및 로드 밸런서 트래픽을 분리하여 모든 규모의 엔터프라이즈 워크로드에 대한 유연성을 보장합니다. 네트워킹, 클러스터 및 노드 풀을 포함하여 이러한 환경 프로비저닝을 완전히 자동화하는 동시에 솔루션을 사용자 정의하고 필요에 맞게 확장할 수 있는 도구를 제공하는 방법을 설명합니다.

이 사용지침서에서는 Kubernetes, 네트워킹 및 IaC 원칙에 대한 이해와 Terraform, OCI CLI 및 Jenkins와 같은 도구에 대한 실무 지식을 가정합니다. 결국 OCI에 복원성, 고성능, 확장성 OKE 환경을 배포할 수 있는 기술을 갖추게 되며, 이를 특정 요구 사항에 맞게 유연하게 조정할 수 있습니다.

Oracle Cloud Infrastructure Kubernetes Engine(OKE) 개요

Oracle Cloud Infrastructure Kubernetes Engine(OKE)은 관리형 서비스이지만 미션 크리티컬 워크로드를 성공적으로 실행하려면 고의적이고 잘 구조화된 아키텍처 접근 방식이 필요합니다. 기본 설정에서 확장 가능한 엔터프라이즈급 환경으로 전환하려면 신중한 계획과 Terraform과 같은 코드형 인프라(IaC) 도구를 사용해야 합니다.

OKE는 확장성, 보안 및 운영 효율성을 보장하기 위해 모듈화 및 자동화가 매우 중요합니다. 기업은 구조화된 모듈 및 자동화 도구를 활용하여 일관성을 갖춘 미션 크리티컬 워크로드를 배포 및 관리하고, 수동 오류를 줄이고, 시장 출시 시간을 가속화할 수 있습니다.

다음 다이어그램은 계층형 네트워크 토폴로지, 전용 API 엔드포인트 및 보안 액세스 제어를 강조 표시하는 OKE 아키텍처를 보여줍니다.

OKE 구조

아키텍처에 대한 자세한 예는 Oracle 설명서를 참조하십시오.

아키텍처 고려 사항
확장 가능한 OKE 환경 구축에는 최소한 다음과 같은 주요 기술 과제 해결이 포함됩니다.

주요 설계 요소
이 모듈식 솔루션은 계층형 네트워크 아키텍처를 기반으로 구축되어 OKE에서 엔터프라이즈 워크로드를 위한 안전하고 확장 가능한 기반을 제공합니다.

OKE용 모듈식 Terraform 자동화 구축

flat Terraform 구성을 structured로 변환하는 모듈식 설계는 반복 가능하고 확장 가능한 환경을 만드는 데 필수적입니다. 이 접근 방식은 팀 간 호환성 및 협업을 위한 버전 지정을 통해 기업 규모의 조직, 코드 재사용성 및 유지 관리 용이성을 개선합니다.

변환 프로세스: 플랫에서 구조화된 모듈로

첫번째 튜토리얼에 설명된 플랫 모듈부터는 다음과 같이 코드를 모듈식 디자인으로 리팩터링합니다.

  1. 디렉토리 재구성: 하위 모듈(vcn, oke, bastion)을 생성하고 리소스를 해당 폴더로 구성합니다.
  2. 주요 원칙 적용:
    • 구조 및 논리: 자체 포함된 디렉토리(예: modules/vcn, modules/oke, modules/bastion)에서 리소스를 캡슐화하고 모놀리식 코드를 main.tf, variables.tf 및 outputs.tf로 분할하여 가독성 및 유지 관리를 지원합니다.
    • 입력/출력 및 버전 지정: 원활한 데이터 플로우 및 호환성을 위해 variables.tf에서 입력을 정의하고, outputs.tf에 출력을 노출하고, Terraform 모듈 버전 지정(source의 version 제약 조건)을 사용합니다.
    • 조정: 루트 모듈 레벨에서 count과 같은 조건부 논리를 처리하여 하위 모듈이 리소스에 집중되도록 합니다.

디렉토리 구조: 플랫 대 모듈식

플랫 모듈: 일부 파일에 있는 모든 리소스가 포함된 단일 모놀리식 디렉토리입니다. 개념 증명은 간단하지만 복잡성이 증가함에 따라 관리가 불가능해집니다.

플랫 모듈 구조

구조화된 모듈: 각 리소스 그룹(VCN, OKE, 배스천)은 자체 모듈 디렉토리에 있습니다. 루트 모듈은 종속성 및 최상위 레벨 구성을 조정합니다.

고급 모듈 구조

예제 모듈

왜 모듈인가?

모듈 조정 - 루트 main.tf

루트 main.tf는 순서가 지정된 방식으로 세 가지 키 모듈(modules/vcn, modules/oke 및 modules/bastion)의 배포를 조정합니다. 각 모듈은 구성 플래그(is_vcn_created, is_oke_created, is_bastion_created)를 기반으로 조건부로 호출되므로 배치 유연성이 제공됩니다. 아래는 전체 main.tf를 자세히 설명하지 않고 키 모듈 논리를 강조 표시하는 단순화된 버전의 통합관리 플로우입니다.

통합관리 플로우:

  1. VCN 모듈(modules/vcn):
    • VCN(가상 클라우드 네트워크) 및 관련 서브넷(예: Kubernetes API 및 작업자 노드용 프라이빗 서브넷, 로드 밸런서 및 배스천용 퍼블릭 서브넷)을 프로비전합니다.
    • is_vcn_created에 의해 제어됩니다. 사용으로 설정된 경우 VCN을 생성하고, 그렇지 않은 경우 기존 VCN을 가정합니다(사용된 서브넷 OCID를 제공해야 함).
    • 예제 코드 조각: 
         module "vcn" {
       count = var.is_vcn_created ? 1 : 0  
       source = "./modules/vcn?ref=v1.0.0"  # Specify the module version  
       # Key variables: compartment_id, vcn_cidr_block, subnet configs, ...  
   }
  2. OKE 모듈(modules/oke):
    • 제어 플레인 및 선택적 관리 노드 풀을 포함하여 OCI OKE(Kubernetes Engine) 클러스터를 배치합니다.
    • 서브넷 ID에 대한 VCN 모듈에 따라 달라집니다. is_oke_created 및 is_vcn_created가 true인 경우에만 호출됩니다.
    • 예제 코드 조각: 
         module "oke" {
       count = var.is_oke_created && var.is_vcn_created ? 1 : 0  
       source = "./modules/oke?ref=v1.0.0"  # Specify the module version   
       # Key variables: vcn_id, subnet IDs, k8 version, node pool config, ...  
   }
  3. 배스천 모듈(modules/bastion):
    • 개인 리소스에 대한 보안 SSH 액세스를 위한 배스천 호스트를 만듭니다.
    • 공용 서브넷 ID에 대한 VCN 모듈에 따라 달라집니다. is_bastion_created 및 is_vcn_created가 true인 경우에만 호출됩니다.
    • 예제 코드 조각: 
         module "bastion" {
       count = var.is_bastion_created && var.is_vcn_created ? 1 : 0  
       source = "./modules/bastion?ref=v1.0.0"  # Specify the module version   
       # Key variables: bastion_subnet_id, SSH keys, parameters...  
   }

      주요 참고 사항:

    • 모듈 종속성: VCN 모듈(예: module.vcn[0].vcn_id)의 출력이 OKE 및 배스천 모듈에 입력으로 전달되어 명확한 종속성 체인을 보장합니다.
    • 구성 로직: 간소화된 매개변수 맵(예: node_pool_param, bastion_params)은 구성 및 가독성을 간소화합니다.
    • 버전 지정: source에서 버전 제약 조건을 사용하면 모듈이 올바른 버전과 테스트된 버전으로 배치되어 호환성이 보장됩니다.

OKE에 대한 모듈식 Terraform 구조를 설정한 후 다음 단계는 배포를 자동화하는 것입니다. 자동화를 통해 일관성을 보장하고, 수동 오류를 줄이고, 프로비저닝 프로세스를 가속화하고, 새로운 기능 및 서비스를 신속하게 제공함으로써 시장 출시 시간(TTM)을 직접 개선할 수 있습니다.

자동화 옵션

Terraform CLI, OCI Resource Manager(ORM), OCI CLI, Ansible OCI 모듈, Helm 등 여러 도구로 OKE 배포를 자동화할 수 있습니다. 그러나 이 가이드는 Terraform CLI 및 OCI Resource Manager(ORM)라는 Oracle Cloud Infrastructure(OCI)의 코드형 인프라(IaC) 접근 방식을 중점적으로 다룹니다.

두 도구 모두 동일한 선언적 HashiCorp 구성 언어(HCL)를 활용하지만 운영 모델마다 다릅니다.

각 옵션을 자세히 살펴보겠습니다.

옵션 1: Terraform CLI를 사용하여 OKE 리소스 배치

Terraform CLI는 로컬 환경을 완벽하게 제어해야 하는 경우에 적합합니다. 공유 백엔드를 사용하여 상태 파일을 관리하고 효과적으로 협업할 수 있는 개별 개발자나 소규모 팀에 가장 적합합니다. 이식성을 통해 로컬, VM, 컨테이너, OCI CloudShell 또는 Jenkins와 같은 CI/CD 러너 등 모든 시스템에서 실행할 수 있습니다. 그러나 이러한 유연성에는 상태 파일 관리 및 팀 구성원 간에 일관된 로컬 설정 보장과 같은 책임이 있습니다.

시작하려면 Terraform 작업 디렉토리에 Terraform CLI 소스 코드 패키지 다운로드 및 압축 해제를 수행합니다. 이 패키지에는 main.tf, terraform.tfvars 샘플 및 자세한 모듈 구성(oke_advanced_module.zip 다운로드)이 포함됩니다.

Terraform CLI를 통한 OKE 배포에는 변수 및 네트워킹 구성부터 OKE 클러스터, 노드 풀 및 배스천 호스트 설정에 이르는 7가지 주요 작업이 포함됩니다. 다음은 Terraform CLI를 사용하여 OKE 환경을 프로비전하고 확인하는 자세한 단계입니다.

작업 1.1: Terraform 변수 구성

terraform.tfvars 파일을 tenancy_ocid, 영역, compartment_ocid 및 network_compartment_ocid와 같은 환경별 세부정보로 업데이트합니다. 리소스 만들기를 제어하려면 다음 플래그를 사용으로 설정합니다.

작업 1.2: 네트워킹 구성

VCN 및 해당 서브넷에 대한 CIDR 블록 정의:

작업 1.3: OKE 클러스터 구성

작업 1.4: 노드 풀 구성

작업 1.5 배스천 호스트 구성

작업 1.6: Terraform 명령 실행

다음 명령을 실행하여 기반 구조를 배치합니다.

	terraform init
	terraform plan
	terraform apply

terraform apply가 완료되면 OKE 클러스터가 프로비전됩니다.

작업 1.7: 확인

  1. OCI 콘솔로 이동하여 클러스터 구성을 확인합니다.
  2. 완료되면 terraform destroy를 실행하여 리소스를 정리합니다.

Jenkins CI/CD 파이프라인을 사용하여 OKE 배포 자동화
OKE 배포를 DevOps 파이프라인에 통합하기 위해 Terraform CLI를 선택하는 것이 좋습니다. Terraform을 사용하여 Oracle Cloud Infrastructure Kubernetes Engine Cluster 생성에 자세히 설명된 Oracle의 접근 방식은 Bash 스크립팅을 사용하여 프로세스를 조정합니다. 이 워크플로우는 자동 실행을 위해 Jenkins 파이프라인에 통합할 수 있습니다.

옵션 2: OCI Resource Manager로 OKE 자동화

OCI Resource Manager(ORM)는 인프라 배포를 위한 관리형 클라우드 네이티브 솔루션이 필요할 때 이상적인 선택입니다. 특히 보안, 중앙 집중식 상태 관리 및 거버넌스가 중요한 협업적인 엔터프라이즈 환경에 적합합니다. ORM의 주요 이점은 OCI 내에서 전체 배포 수명 주기를 처리하여 상태 파일을 안전하게 저장하고 충돌을 방지한다는 것입니다. 따라서 로컬에서 공유 백엔드를 설정하거나 관리할 필요가 없습니다. 또한 ORM은 Oracle Cloud와의 긴밀한 통합을 통해 IAM(Identity and Access Management)과 같은 OCI 네이티브 기능을 활용하여 보안 및 제어를 강화할 수 있습니다.

이 사용지침서에서는 OCI Resource Manager(ORM)와 OCI CLI, Bash를 결합하고 이를 Jenkins CI/CD 파이프라인에 통합하여 드리프트 감지, 보안 상태 관리, 호환성을 위한 버전 지정을 통한 팀 협업과 같은 추가 DevOps 기능을 갖춘 완전한 one-click 자동화 플로우를 제공합니다.

OCI Resource Manager 흐름
다음 다이어그램은 7단계로 구성된 ORM 워크플로를 보여줍니다.
ORM 워크플로우

  1. 소스 구성: IaC 구성의 원본(예: OCI Object Storage, GitHub, Zip 파일)을 정의합니다.
  2. Terraform Template: The infrastructure is defined using Terraform.
  3. OCI Resource Manager: ORM은 Terraform 템플릿을 사용하고 프로비저닝 프로세스를 관리합니다.
  4. 스택 생성: ORM은 템플리트를 사용하여 OCI 리소스 스택을 생성합니다.
  5. 계획: 수행할 작업을 요약하는 계획을 생성합니다.
  6. 적용: 계획을 기반으로 리소스를 프로비전닝합니다.
  7. 삭제: 더 이상 필요하지 않을 때 리소스를 프로비전 해제합니다.

ORM(OCI Resource Manager)의 새 모듈을 사용하여 OKE 클러스터를 배치하려면 먼저 ORM용 고급 모듈을 다운로드합니다. oke_advanced_module_orm.zip. 이 버전은 ORM에 대해 사전 구성되어 있으며 변수는 REPLACE_WITH_YOUR_OWN_VARIABLE_VALUE과 같은 일반 자리 표시자로 설정됩니다.

작업 2.1: 소스 구성

리전, 네트워킹 CIDR 및 플래그와 같은 환경별 세부정보로 variables.tf를 업데이트하여 리소스 생성(VCN, OKE 클러스터, 노드 풀, 배스천 호스트)을 제어합니다.

다음 Bash 스크립트는 ORM 리소스 소스 zip 파일을 생성합니다.

소스 디렉토리(~/oke_advanced_module_orm)에서 stackconfig.zip라는 파일이 모든 terraform 리소스 정의를 포함하는지 확인합니다.

작업 2.2: OCI Resource Manager 스택 생성

OCI CLI를 사용하여 ORM 스택을 생성합니다. 아래 스크립트는 프로세스를 단순화합니다.

Bash 스크립트: create_new_oke_stack.sh.

	#!/bin/bash
	
	# Load environment variables (e.g., COMPARTMENT_ID, STACK_NAME, etc.)
	source "./env-vars"

	# Create the Oracle Resource Manager stack and capture the OCID
	stack_output=$(oci resource-manager stack create \
	--compartment-id "$COMPARTMENT_ID" --display-name "$STACK_NAME" \
	--description "$STACK_DESCRIPTION" --config-source "$CONFIG_SOURCE")

	# Extract the OCID of the newly created stack and display it
	STACK_OCID=$(echo "$stack_output" | jq -r '.data.id')

	echo "Stack OCID: $STACK_OCID"

작업 2.3: 스택 계획 작업 실행

적용하기 전에 Plan 작업을 실행하여 변경사항을 확인합니다. 이 건식 실행은 인프라 변경에 대한 투명성을 제공합니다.

Bash 스크립트: create_oke_stack_plan_job.sh

	#!/bin/bash

	# Load environment variables (e.g., STACK_OCID)
	source "./env-vars"

	# Create a plan job for the specified stack
	plan_job_output=$(oci resource-manager job create-plan-job \
		--stack-id "$STACK_OCID")

	# Extract the OCID of the plan job and check for errors
	PLAN_JOB_OCID=$(echo "$plan_job_output" | jq -r '.data.id')
	if [[ -z "$PLAN_JOB_OCID" ]]; then
		echo "Error: Failed to retrieve plan job OCID." >&2
		exit 1
	fi

	echo "Plan job OCID: $PLAN_JOB_OCID"

태스크 2.4: 지원 직무 생성

Apply 작업을 사용하여 OKE 클러스터 및 연관된 리소스(예: 노드 풀)를 프로비전합니다.

Bash 스크립트: create_oke_stack_apply_job.sh

	#!/bin/bash

	# Load environment variables (e.g., STACK_OCID, EXEC_PLAN_STRATEGY)
	source "./env-vars"

	# Create an apply job for the specified stack
	apply_job_output=$(oci resource-manager job create-apply-job \
		--stack-id "$STACK_OCID" \
		--execution-plan-strategy "$EXEC_PLAN_STRATEGY")

	# Extract the OCID of the apply job and check for errors
	APPLY_JOB_OCID=$(echo "$apply_job_output" | jq -r '.data.id')
	if [[ -z "$APPLY_JOB_OCID" ]]; then
		echo "Error: Failed to retrieve apply job OCID." >&2
		exit 1
	fi

	echo "Apply job OCID: $APPLY_JOB_OCID"

작업 2.5: 삭제 작업 실행

환경이 더 이상 필요하지 않을 때 Destroy 작업을 실행하여 리소스를 정리합니다.

Bash 스크립트: create_oke_stack_destroy_job.sh

	#!/bin/bash

	# Load environment variables (e.g., STACK_OCID, EXEC_PLAN_STRATEGY)
	source "./env-vars"

	# Create an  jotroy for the specified stack
	apply_job_output=$(oci resource-manager job create-destroy-job \
		--stack-id "$STACK_OCID"  \
		--execution-plan-strategy "$EXEC_PLAN_STRATEGY")

	# Extract the OCID of the destroy job and check for errors
	DESTROY_JOB_OCID=$(echo "$apply_job_output" | jq -r '.data.id')
	if [[ -z "$DESTROY_JOB_OCID" ]]; then
		echo "Error: Failed to retrieve destroy job OCID." >&2
		exit 1
	fi

	echo "Apply job OCID: $DESTROY_JOB_OCID"

Jenkins 및 OCI Resource Manager로 OKE 자동화

엔드투엔드 프로비저닝 프로세스를 자동화하는 Jenkins 파이프라인을 만들었습니다(작업 2.1–2.4). 파이프라인은 OCI CLI를 사용하여 Bash 스크립트를 실행하여 ORM과 상호 작용합니다.

아래 이미지는 처음 네 개의 작업에 대한 one-click 자동화를 보여줍니다. 단순성을 위해 destroy 단계는 포함되지 않습니다.

OKEJenkinsPipeline

파이프라인에는 소스 구성, ORM 스택 생성, 계획 생성, 리소스 프로비저닝(provisioning) 및 선택적 리소스 프로비저닝(deprovisioning)이 포함됩니다.

다음 단계:

OKE 프로비저닝에 Terraform을 사용하면 일관성, 자동화 및 확장성이 보장됩니다. 모듈식 설계는 OCI Resource Manager 및 CI/CD 파이프라인과 결합되어 배포를 더 간단하고 쉽게 유지 관리할 수 있습니다. 다음 자습서에서는 모니터링, 보안 및 운영 준비에 대한 모범 사례를 다룹니다. 이러한 기반을 기반으로 모듈을 Oracle AIOps로 확장하고, AI 애플리케이션을 위한 엔드투엔드 OKE 청사진을 만들고, AI 기반 관찰 기능을 통한 로깅 분석이 이상 징후를 감지하고 컨테이너 플랫폼 보안을 강화하는 방법을 시연합니다.

승인

추가 학습 자원

docs.oracle.com/learn에서 다른 랩을 탐색하거나 Oracle Learning YouTube 채널에서 더 많은 무료 학습 콘텐츠에 액세스하세요. 또한 education.oracle.com/learning-explorer를 방문하여 Oracle Learning Explorer가 되십시오.

제품 설명서는 Oracle Help Center를 참조하십시오.