GitHub 라벨 또는 태그로 Azure API Container에 CI/CD 적용하기

브랜치를 푸시하거나, 라벨을 붙이거나, 태그를 추가할 경우
GitHub Action을 이용하여 Azure API Container에 자동으로 배포하는 방법을 공유합니다.

 

 

 

 

저희 팀에서는 변형된 Git flow 전략으로 버전 관리를 하고 있습니다

그중 QA 브랜치만 다루도록 하겠습니다.

 

 

🌠 목차
✅ CI/CD에서 원하는 동작
✅ GitHub Action workflow 생성
✅ Azure 배포 프로세스의 이해 ⭐️⭐️⭐️
✅ 만약 안되는 부분이 있다면
✅ 회고

 

CI/CD에서 원하는 동작

---

QA 브랜치에 PR을 만들고 "QA"라벨을 추가하면 자동 CI/CD가 되도록 구현하려고 한다.

 

 

 

GitHub Action workflow 생성

---

workflow 파일 코드

name: Trigger auto deployment for heroines-qa-api

# When this action will be executed
on:
  pull_request:                  #  Pull Request 이벤트에 대해 워크플로우가 트리거됨
    types: [labeled]             # 그중에서도 라벨이 추가될 때만

  # Automatically trigger it when detected changes in repo
  push:
    branches:                   # qa 브랜치에 푸시가 되었가나,  
      - qa
    tags:                       # QA 태그가 붙거나,
      - QA
    paths:
      - '**'
      - '.github/workflows/heroines-qa-api-AutoDeployTrigger-1cb86b57-8b3a-403e-8699-b788c8702b1b.yml'

  # Allow manual trigger
  workflow_dispatch:

jobs: # 작업을 실행할 때 라벨 중 QA 태그가 붙었거나, 푸시가 있거나, work_dispatch 실행했으면 조건 실행 
  build-and-deploy:
    if: |
      github.event_name == 'pull_request' && github.event.label.name == 'QA' ||
      github.event_name == 'push' ||
      github.event_name == 'workflow_dispatch' ||
      startsWith(github.ref, 'refs/tags/QA')
    runs-on: ubuntu-latest
    permissions:
      id-token: write # This is required for requesting the OIDC JWT Token
      contents: read # Required when GH token is used to authenticate with private repo

    steps:
      - name: Checkout to the branch
        uses: actions/checkout@v2

      - name: Azure Login
        uses: azure/login@v1
        with:
          client-id:
          tenant-id:
          subscription-id: 

      - name: Build and push container image to registry
        uses: azure/container-apps-deploy-action@v2
        with:
          appSourcePath:
          dockerfilePath: 
          registryUrl: 
          registryUsername: 
          registryPassword:
          containerAppName: 
          resourceGroup: 
          imageToBuild: 
          _buildArgumentsKey_: 

        if: always()

 

 

Azure 배포 프로세스의 이해

---

 

공식문서를 대충 읽어보고 구현에만 집중해서 정확하지 않을 수 있습니다. 잘못된 내용이라면 댓글 부탁드립니다.

 

Azure API container 배포 이용하기

Azure API Container 서비스에서 CD기능을 기본적으로 제공한다.

단, 푸시에 관련해서만 가능한 것으로 확인된다.

pull_request 방식은 다른 방식을 federated identity crdential Subject라면서 안된다.

 

이것 때문에 삽질을 열심히 했다..

 

복붙 아닙니다

 

 

또다른 방법 Azure Active Directory 앱 설정하기

1. 모든 서비스 검색: azure active directory 

2. 좌측 탭: 앱등록 클릭

3. 상단 새 등록 버튼 클릭

4. 이름 할당 및 이 조직 디렉터리의 계정만(기본 디렉터리만 - 단일 테넌트) 생성
5. 리디렉션은 생략

6. 생성 

아래 ID를 필히 기억하자!!

• 애플리케이션 ID : 깃헙 시크릿매니저 등록용
• 개체 ID : Azure 구독 등록용
• 디렉터리 ID: 깃헙 시크릿매니저 등록용

6. 좌측 API 사용권한 클릭

7. 권한추가 클릭

8. azure service Management 클릭

9. 권한추가

 

 

여기까지 따라오면 잘한 것!

 

10. 다시 모든 서비스 검색: 구독으로 이동

11. 마이크로 스폰서십 클릭

12. 좌측 액세스 제어(IAM) 클릭

13. 상단 추가 클릭 -> 역할 할당 추가

14. 권한 부여 

 

⚠️ 여기서 정말 삽질한 부분 2가지가 있다. 삽질을 하다가 이글까지 흘러온 개발자라면 아래를 놓치지 말 것.

권한 부여를 위에 6번에서 생성한 앱을 등록해야 한다.

검색할 때 개체 ID로 검색해야 한다.(개체 아이디 없으면 애플리케이션 ID, 디렉터리 ID로 검색)

구성원 검색이라는 말이 Azure 사용자인 줄 알았는데 앱이라니

그리고 다른 곳에서는 개체 ID가 아닌 애플리케이션 ID를 넣으면 된다고 했는데,

계속 안 떠서 설마.. 하고 개체 ID 넣었는데 검색이 되었다...

 

15. 권한 부여 방법: 구성원 - "기여자" 선택 -> 구성원 선택 -> 개체 ID로 검색 -> 할당

 

 

 

결과 확인

 

만약 안 되는 부분이 있다면

---

올바른 디렉터리(테넌트) 확인

• 디렉터리 일치 여부:
  서비스 프린시플(앱 등록)이 생성된 Azure Active Directory와 현재 역할 할당을 진행하는 디렉터리가 동일한지 확인
  Azure Portal 오른쪽 상단에 표시되는 디렉터리 이름이 맞는지, 필요하다면 상단의 디렉터리 전환 메뉴에서 올바른 디렉터리로 전환

Enterprise Applications에서 Object ID 확인

• Enterprise Applications에서 서비스 프린시플 찾기:
  1. Azure Portal 좌측 메뉴에서 "Azure Active Directory" > "Enterprise Applications"로 이동
  2. "모든 애플리케이션(All applications)" 목록에서 해당 서비스 프린시플을 찾기
• Object ID 복사:
  3. 해당 애플리케이션을 클릭한 후, 개요(Overview) 페이지에서 객체 ID(Object ID)를 복사

검색 필터 및 보기 옵션 조정

• 필터 확인:
  역할 할당 선택 창 상단에 있는 필터(예: “모두 보기”, “서비스 주체”, “사용자”) 옵션을 “서비스 주체” 또는 “모두 보기”로 변경

권한 및 생성 상태 확인

• 앱 등록 상태 확인:
  앱 등록에서 해당 애플리케이션이 정상적으로 생성되었는지, 그리고 Enterprise Applications에도 나타나는지 재확인
• 추가 생성:만약 계속 보이지 않는다면, 앱 등록을 다시 한번 확인하고, 필요시 새 앱 등록을 만들어 동일한 과정을 진행해 볼 수 있음

 

회고

---

당초 계획했던 기능 개발이 일정보다 빨리 완료되어,

CTO님의 업무를 자진해서 맡았다가 중간에 살짝 도전적이었던 순간들이 있었다.

이전 Azure DB 관련 이슈로 인해 인프라 작업에 대한 부담감이 있었지만,

이번 기회를 통해 Azure 시스템을 직접 다루면서 그동안의 심리적 장벽을 조금이나마 허물 수 있었다.

특히 새로운 방식으로 CI/CD를 구현하면서 기술적 성장을 체감할 수 있었다.

문제 해결 과정에서는 시스템 전반을 단계별로 분석하고 이슈 발생 지점을 추적하는 체계적인 접근 방식을 취했다.

처음 세운 가설이 실제 원인과 일치하여 신속한 문제 해결이 가능했고,

이를 통해 기술적 직관력과 문제 해결 능력이 한층 성장했음을 느낄 수 있었다.

 

 

 

글 잼나게 보셨으면 좋아요 눌러주고 가세요

관심받는 거 좋아합니다