azure

루트 도메인, Azure Front Door (CDN) 인증서 등록, 트러블 슈팅기

Hyonsok

2024년 3월 29일 — 3 min read

1.요구사항

루트 도메인에 Azure Front Door(CDN)를 사용하도록 처리해야 하는 과제가 주어졌습니다. 기존에 서브도메인을 CDN 처리할때는 채 10분도 걸리지 않았었던터라 가볍게 생각하였는데 뜻밖의 난관을 여러번 겪게 되었습니다.

2.첫번째 난관

루트 도메인의 경우 @ 레코드를 변경해야 합니다. 하지만 이 DNS 레코드는 중요하기 때문에 기본적으로 사용자가 처리할 수 없게 막혀있습니다. 호스팅업체에 문의해서 대리수행을 요청해야 합니다. 그렇게 되면 24/365 서비스의 중단을 필수적으로 거치게 됩니다. 어쩔수 없죠. 중단시간을 최소화 해야 합니다.

3.두번째 난관

서브도메인의 경우 Azure에서 제공하는 인증서를 적용하여 https 요청을 처리했었는데 루트 도메인은 자체 인증서를 사용해야 합니다. 기 구입한 SSL 인증서를 보니 Azure에서 요구하는 pkcs12 포맷이 아닙니다. 변환이 필요합니다. ㅠㅠ

openssl pkcs12 -inkey 키파일 -in 인증파일 -export -out xxx.pfx

4.세번째 난관

Azure Front Door에서 사용자가 등록한 자체 SSL 인증서에 접근하기 위해서는 Azure Key Vault 자원 생성도 필요하네요. 자원 종속성을 회피하고 싶은데 ... ㅠㅠ Service Principal도 별도로 만들어줘야 하네요. 나원참.

5.완료

결국 1시간이 걸려 루트도메인으로 Azure Front Door CDN 세팅을 완료했습니다. 잘 돌아가는 것을 보니 감개무량하네요. -,.-;

6.또다른 난관 (ㅠㅠ)

[Terraform 튜토리얼 1-6] 중복 없애다 망한 썰 – DRY 원칙, 정말 항상 맞을까?

개발자라면 한 번쯤 들어봤을 말, "Don't Repeat Yourself", 줄여서 DRY 원칙. 이건 소프트웨어 개발에서 아주 중요한 원칙이에요. 중복을 줄이면 버그도 줄고, 유지 보수도 쉬워지고, 코드도 깔끔해지죠. 그런데… Terraform 같은 IaC 세계에서도 DRY가 무조건 좋을까요? 🤔 DRY가 뭔데? DRY 원칙의 핵심은 딱 하나: "같은 걸 반복해서 쓰지 마." * 상수 값, 로직, 설정

[Terraform 튜토리얼 1-5] 선언형 vs 명령형: Terraform은 왜 선언형인가?

Terraform을 쓰다 보면 종종 듣게 되는 말이 하나 있어요: Terraform은 "선언형(Declarative)" 도구다. 그런데 이게 도대체 무슨 뜻일까요? "명령형(Imperative)"이랑은 뭐가 다르고, 왜 Terraform은 선언형일까요? 🧠 선언형과 명령형, 개념부터 정리 구분 선언형 (Declarative) 명령형 (Imperative) 핵심 개념 무엇이 되어야 하는지만 선언 어떻게 할지를 하나하나 명령 예시 “난 스테이크 먹을래” “고기

[Terraform 튜토리얼 1-4] 모듈이 정리가 안 될 땐, 응집도(Cohesion)를 의심하라

인프라를 코드로 관리할 때, 좋은 모듈을 만드는 핵심 개념 중 하나가 바로 응집도(Cohesion)입니다. 이 단어가 좀 낯설게 느껴질 수 있지만, 사실 우리는 매일 응집도가 높은 시스템 속에서 살고 있어요. ✅ 응집도란? 하나의 모듈이 하나의 책임 또는 기능에만 집중하는 정도 응집도가 높은 모듈은 말 그대로 한 가지 일에만 집중합니다. 그래서

[Terraform 튜토리얼 1-3] 내부는 감추고, 필요한 것만 보여줘 – 캡슐화란?

Encapsulation, 캡슐화라고 하면 뭔가 개발자스럽고 어려워 보이죠? 객체지향 프로그래밍 할 때나 듣던 단어 같고요. 그런데 이 개념은, Terraform 같은 Infrastructure as Code(IaC)에서도 아주 중요합니다. 이번 글에서는 "캡슐화가 무엇이고", "왜 필요한지", 그리고 "Terraform에서는 어떻게 쓰이는지"를 쉽게 풀어보겠습니다. ✅ 캡슐화, 한 마디로 뭐야? “필요한 것만 보이게 하고, 나머지는 숨기는 것”