[INFRA] Git Submodule을 사용하여 AWS EC2에 위치한 설정을 관리하도록 변경

[zeus6768]

#725

개요

• 현재 코드잽은 EC2에 도커 컴포즈를 구성하여 서버를 구축했습니다.
• compose.yml, nginx.conf, application.yml 등의 설정 파일이 변경될 때마다 서버에 접속해야 합니다.

요구사항

• 변경 내역을 추적할 필요가 있습니다.
• 우테코 캠퍼스 네트워크를 벗어나도 작업할 수 있어야 합니다.
• 프로젝트와 프로젝트 설정 파일을 하나의 IDE에서 관리해서 생산성을 높일 수 있습니다.

체크리스트

• private 저장소 collaborators 추가
• 각 설정 파일이 올바른지 확인
  • compose.yml
  • spring/application.yml
  • promtail/promtail-config.yml
  • nginx/nginx.conf
• 다음의 파일들이 backend_cd.yml workflow의 Compose 환경변수 주입 작업으로 생성된 .env 파일을 올바르게 참조하는지 확인
  • spring/application.yml
  • promtail/promtail-config.yml
• 프로젝트 저장소의 Secret과 private 저장소의 secret이 일치하는지 확인
  • Develop Environments Secret → private/develop/secret
  • Production Environments Secret → private/production/secret

[zeus6768]

Git Submodule 이란?

Git submodule 공식문서를 참고했습니다.

주요 명령어

git submodule update --remote --merge: pull과 같음. 서브모듈 업데이트 및 변경내역 반영.

서브모듈 작업 전에는 위 명령어를 실행해야 합니다. 그래야 upstream의 변경내역을 가졀 수 있으니깐요.

알아야 하는 내용

서브모듈 디렉토리는 git에서 다른 영역으로 관리합니다.

서브모듈 저장소에 변경이 생기면 본 저장소에도 변경 내역으로 감지됩니다.

서브모듈 디렉토리의 파일이 보이지는 않고, 서브모듈 디렉토리의 커밋 해시값 변경만 감지됩니다.

작업 방식

서브모듈 저장소는 효율을 위해 pr 없이 push합니다.

다만 작업원래 작업 방식대로 작업 전에 본 저장소에서 issue를 발행하고, 작업에 대해 본 저장소에서 PR을 작성합니다.

서브모듈 저장소에 변경이 생기면 본 저장소에도 변경 내역으로 감지됩니다.

서브모듈 디렉토리의 파일이 보이지는 않고, 서브모듈 디렉토리의 커밋 해시값 변경만 감지됩니다.

[zeus6768]

Private 저장소

[email protected] 계정으로 생성한 Github 저장소에요.

공개 저장소에 저장할 경우 보안 문제가 생길 수 있는 데이터를 저장해요..

Read & Write 권한을 얻으려면 Collaborator 초대를 받아야 해요.

다음과 같이 브랜치를 구성했어요. 브랜치마다 용도가 달라요.

• main 브랜치: 개발, 운영 환경에서 쓰이는 compose, promtail, nginx 설정
• develop 브랜치: Develop 환경의 Git Environment Secret
• production 브랜치: Production 환경의 Git Environment Secret
• global 브랜치: 2024-code-zap 저장소의 Secret

AS-IS

다음과 같이 저장소 secret들이 등록되어 있어요.

이 secret들은 쓰기만 가능하고, 읽을 수 없다는 문제가 있어요.

TO-BE

Global Secret | 2024-code-zap-private에서 해당 secret들을 확인할 수 있어요.

Private repository global 브랜치의 secret == public repository secret 입니다.

또, 다음과 같이 환경별로 등록된 secret들도 확인할 수 있어요.

Develop Secret | 2024-code-zap-private

Production Secret | 2024-code-zap-private

[zeus6768]

작업 방식 변경

1. Secret을 변경하는 경우

1. Public 저장소에서 이슈 발행 (원래 하던거)
2. Private 저장소의 develop 또는 production 브랜치에서 secret 파일 수정 및 Push
3. Public 저장소의 Settings에서 secret 변경
4. Public 저장소에서 Pull Request (원래 하던거)

2. 서버 구성을 변경하는 경우

1. Public 저장소에서 이슈 발행 (원래 하던거)
2. Private 저장소의 main 브랜치에서 작업 후 push
3. Public 저장소에서 Pull Request (원래 하던거)

3. 팁

Private 저장소에 push 되는 작업마다 PR을 작성할 필요 없어요.

인프라 작업을 위해 private 저장소에 여러 번의 push를 해도 돼요.

Public 저장소 입장에서는 private 저장소에서 몇 번의 변경이 일어났든, 서브모듈 디렉토리의 해시값만 변경된 것으로 추적돼요.

[zeus6768]

Spring yml 파일 위치 변경

스프링 yml 파일들을 모두 main/resource 디렉토리로 이동했어요.

AS-IS

TO-BE

변경 후에 아주 좋아지는 점이 두 개 있어요.

1. SSH 접속으로 서버마다 yml 파일을 수정할 필요가 없어요.
2. java -jar 명령어로 서버를 실행할 때 yml 파일 위치를 명시하지 않아도 돼요.

# compose.yml

## AS-IS
  spring:
    entrypoint: [
      "java", "-jar",
      "-Dspring.config.location=/app/application-prod.yml,/app/application-db/yml,/app/application-actuator.yml,/app/application-swagger.yml",
      "-Dspring.profiles.active=${SPRING_PROFILE}",
      "/app/code-zap.jar"
    ]

## TO-BE
  spring:
    entrypoint: [
      "java", "-jar",
      "-Dspring.profiles.active=${SPRING_PROFILE}",
      "/app/code-zap.jar"
    ]

다음의 블로그 글을 참고해서 구성했어요.

[zeus6768]

환경변수 주입

개발 환경과 운영 환경에서 같은 설정을 사용하고, 환경에 따라 값만 달라지게 구성했어요.

application-cors.yml을 예로 들어볼게요.

cors:
  allowed-origins: ${ALLOWED_ORIGINS}
  allowed-origins-patterns: ${ALLOWED_ORIGINS_PATTERNS}

여기에 주입되는 ALLOWED_ORIGINS와 ALLOWED_ORIGINS_PATTERNS는 개발 환경과 운영 환경에서 다를 거에요.

이런 값들은 private 저장소 각 브랜치의 ENV_VARIABLES라는 secret을 통해 주입돼요.

# backend_cd.yml
      - name: Compose 환경변수 주입
        working-directory: ${{ secrets.PROJECT_PATH }}
        run: ${{ secrets.ENV_VARIABLES }}

각 저장소에 가서 어떤 값이 주입되는지 확인해볼까요?

Develop Secret | 2024-code-zap-private

Production Secret | 2024-code-zap-private

다음과 같은 스크립트가 무슨 뜻인지 궁금하죠?

cat <<EOF > .env
(변수들)
EOF

위 스크립트는 (변수들)을 출력해서 .env 파일로 저장하는 기능을 해요.

여러 줄을 한 번에 출력하고 파일로 만들기 위해 저런 명령어를 사용했어요.

또, .env 라는 이름의 파일로 만든 이유가 있어요.

도커 컴포즈는 명시하지 않아도 compose.yml과 같은 폴더 내의 .env라는 파일을 참조해요.

그래서 다음과 같은 설정이 가능해요.

# compose.yml
  spring:
    environment:
      TZ: ${TZ}
      SPRING_PROFILE: ${SPRING_PROFILE}
      MYSQL_READER_URL: ${MYSQL_READER_URL}
      MYSQL_WRITER_URL: ${MYSQL_WRITER_URL}
      MYSQL_USER: ${MYSQL_USER}
      MYSQL_PASSWORD: ${MYSQL_PASSWORD}
      ALLOWED_ORIGINS: ${ALLOWED_ORIGINS}
      ALLOWED_ORIGINS_PATTERNS: ${ALLOWED_ORIGINS_PATTERNS}

SPRING_PROFILE, MYSQL_READER_URL 등의 변수가 모두 .env에 저장되어있기 때문이죠!