[배포 및 인프라] 해보자 배포 [6] - Git Submodule을 사용하여 민감한 정보를 관리하기

 

 

 

 

이전 글에서 애플리케이션을 데이터베이스와 연동할 때 환경변수를 통해서 민감한 정보를 관리했습니다.

이번에는 환경변수 대신 Git Submodule이라는 기능을 통해서 이러한 정보를 관리해 보도록 하겠습니다.

 

 

 

 

 

 

🧐 Git Submodule

깃 공식 문서에는 다음과 같이 설명되어 있습니다.

프로젝트를 수행하다 보면 다른 프로젝트를 함께 사용해야 하는 경우가 종종 있다.
함께 사용할 다른 프로젝트는 외부에서 개발한 라이브러리라던가 내부 여러 프로젝트에서 공통으로 사용할 라이브러리일 수 있다.
이런 상황에서 자주 생기는 이슈는 두 프로젝트를 서로 별개로 다루면서도 그 중 하나를 다른 하나 안에서 사용할 수 있어야 한다는 것이다.
Atom 피드를 제공하는 웹사이트를 만드는 것을 예로 들어보자.
Atom 피드를 생성하는 코드는 직접 작성하지 않고 라이브러리를 가져다 쓰기로 한다.
라이브러리를 사용하려면 CPAN이나 Ruby gem 같은 라이브러리 관리 도구를 사용하여 Shared 라이브러리 형태로 쓰거나 직접 라이브러리의 소스코드를 프로젝트로 복사해서 사용할 수 있다.
우선 Shared 라이브러리를 사용하기에는 문제가 있다.
프로젝트를 사용하는 모든 환경에 라이브러리가 설치되어 있어야 하고 라이브러리를 프로젝트에 맞게 약간 수정해서 사용하고 배포하기가 어렵다.
또한, 라이브러리 소스코드를 직접 프로젝트에 포함시키는 경우에는 라이브러리 Upstream 코드가 업데이트됐을 때 Merge 하기가 어렵다.
Git의 서브모듈은 이런 문제를 다루는 도구다.
Git 저장소 안에 다른 Git 저장소를 디렉토리로 분리해 넣는 것이 서브모듈이다.
다른 독립된 Git 저장소를 Clone 해서 내 Git 저장소 안에 포함할 수 있으며 각 저장소의 커밋은 독립적으로 관리한다.

공식문서에서는 민감한 정보를 관리하는 경우 사용한다는 내용은 없으나, Private Repository에 보안상 민감한 정보를 올려둔 후, 이를 실제 프로젝트 Repository 내부에서 사용하도록 함으로써 민감한 정보를 관리할 수 있습니다.

 

 

 

 

 

 

 

 

 

 

🧐 Submodule로 사용할 레포지토리 생성

우선 민감정보를 관리할 Private Repository를 하나 생성해 주도록 하겠습니다.

최초 커밋을 하나 만들어주기 위해 Add a README file도 체크해 주었습니다.

 

 

 

 

해당 레포지토리 주소를 복사합니다.

 

 

 

 

 

 

 

 

 

 

🧐 기존 Repository에서 Submodule 추가

위와 같이 우선 서브모듈을 추가할 메인 레포지토리로 이동합니다.

이곳에서 위에서 새로 만들어준 Repository를 서브모듈로 추가해주면 되는데요, 지금부터 진행하도록 하겠습니다.

 

 

 

 

 

서브모듈을 추가할 때는 다음과 같은 명령어를 사용합니다.

git submodule add [서브모듈로 사용할 Repository 주소]

git submodule add https://github.com/shin-mallang/secure-submodule-test.git

기본적으로 서브모듈은 서브모듈로 사용할 레포지토리의 이름으로 디렉토리를 생성합니다.

위에서는 secure-submodule-test로 디렉토리가 생성되었으며, 내부에 해당 레포지토리가 가진 README.md 가 가져와진 것을 알 수 있습니다.

 

 

또한 .gitmodules 라는 파일이 만들어진 것을 알 수 있는데요, 한번 살펴보겠습니다.

위 파일은 생성된 서브모듈 디렉토리와 서브모듈 URL의 매핑 정보를 담은 설정파일입니다.

 

.gitmodules 파일도 형상관리의 대상이며, 따라서 다른 파일들과 마찬가지로 Push하고 Pull 할 수 있습니다.

 

이제 지금까지 설정한 정보를 커밋하고 Push해 보도록 하겠습니다.

git add .
git commit -m "서브모듈 추가"
git push origin main

 

 

이제 레포지토리로 들어가서 확인해 보도록 하겠습니다.

다음과 같이 잘 설정된 것을 알 수 있습니다.

 

 

 

 

 

 

 

 

 

 

📕 메인 Repository에서 Submodule 내용 변경

만약 메인 Repository에서 Submodule 디렉토리 내의 파일을 변경하면 어떻게 될까요?

예시는 다음과 같습니다.



위와 같이 서브모듈 디렉토리에 mallang.txt라는 파일을 추가했습니다.

과연 어떻게 될까요?

 

 

정답은 아무 일도 일어나지 않는다입니다.

서브모듈의 디렉토리는 메인 레포지토리의 관리대상이 아니기 때문인데요, git status를 쳐보면 다음과 같은 화면을 볼 수 있습니다.

(이제 mallang.txt 파일을 다시 지워주세요 😊)

 

 

 

 

 

 

 

 

 

 

 

 

 

 

🧐 Submodule에 민감한 정보 설정하기

메인 레포지포리에서 서브모듈을 추가해 주었으니, 이제 원래 하려던 Submodule을 통해 민감한 정보를 관리하는 과정으로 넘어가도록 하겠습니다.

우선 Submodule로 사용하는 private Repository에 다음과 같은 파일들을 생성합니다.

 

 

 

 

⚙️ application.yml

spring:
  profiles:
    active: dev

my-env:  # 공통으로 적용된다.
  first: ${FIRST_MALLANG_ENV}
  second: ${SECOND_MALLANG_ENV}

 

 

 

⚙️ application-dev.yml

spring:
  datasource:
    url: jdbc:h2:mem:testdb;MODE=MySQL
    driver-class-name: org.h2.Driver
    username: sa
    password:

 

 

 

 

⚙️ application-prod.yml

spring:
  datasource:
    driver-class-name: ${RDS_DRIVER}
    url: ${RDS_URL}
    username: ${RDS_USERNAME}
    password: ${RDS_PASSWORD}

 

 

 

 

이제 이들을 Commit & Push 해줍니다.

위와 같이 서브모듈로 사용할 레포지토리에 설정 파일들이 추가되었습니다.

 

 

서브모듈 레포지토리의 커밋을 살펴보겠습니다.

즉 가장 최근에 반영한 커밋의 해시값이 81c8e17인 것을 알 수 있습니다.

 

 

 

그러나 메인 레포지토리에서는 아직 반영이 안 된 것을 알 수 있습니다.

 

 

 

 

이제 이들을 메인 레포지토리에서 사용할 수 있도록 설정해주도록 하겠습니다.

 

우선 메인 레포지토리의 파일 경로로 돌아와서 다음 명령어를 통해 서브모듈의 변경사항을 가져옵니다.

git submodule update --remote

 

그리고 메인 레포지토리에서 참조하는 서브모듈의 기록을 업데이트 시켜주겠습니다.

git add .
git commit -m "서브모듈 최신화"
git push origin main

 

 

이제 다시 메인 레포지토리로 돌아가면 아래와 같이 서브모듈이 최신화된 것을 확인할 수 있습니다.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

🧐 Submodule의 설정파일 사용하기

이제 이어서 애플리케이션의 기존 설정 정보는 모두 지우고, 서브모듈의 설정정보를 사용하도록 수정하겠습니다.

우선 기존에 가진 설정 정보를 모두 제거합니다.

 

제거이후

 

 

 

이제 빌드 시 서브모듈의 설정정보들을 가져오도록 build.gradle 파일을 수정하도록 하겠습니다.

 

다음 코드를 추가합니다.

processResources.dependsOn('copySecret')

tasks.register('copySecret', Copy) {
    from './서브모듈 디렉토리 경로'
    include "application*.yml"  // 복사할 파일들
    into 'src/main/resources'  // 복사 위치
}

 

⚙️ build.gradle

plugins {
    // ... 생략
}

// ... 생략

tasks.named('test') {
    useJUnitPlatform()
}

processResources.dependsOn('copySecret')

tasks.register('copySecret', Copy) {
    from './secure-submodule-test' // 서브모듈 디렉토리 경로
    include "application*.yml"  // 복사할 파일들
    into 'src/main/resources'  // 복사 위치
}

 

 

이제 빌드를 하게되면 서브모듈이 가진 설정파일들이 메인 프로젝트의 src/main/resources 경로에 복사됩니다.

 

이제 변경된 사항들을 Commit & Push하도록 하겠습니다.

git add .
git commit -m "기존 프로젝트 설정정보 제거 & 서브모듈 설정정보 사용"
git push origin main

 

 

 

 

이제 EC2에 접속해서 작성한 쉘 스크립트를 실행하여 실제 애플리케이션을 실행해 보도록 하겠습니다.

실행 로그를 보면 실패했다는 것을 알 수 있는데요, 설정정보가 복사되지 않은 것 같습니다.

한번 확인해 보겠습니다.

예상대로 설정되지 않은 것을 알 수 있습니다.

 

 

 

 

 

이유는 프로젝트 pull 시 서브모듈까지 가져오지 않는다는 것이 문제인데요, 이를 해결하기 위해서는 다음 명령어를 실행해주어야 합니다.

git submodule update

 

 

즉 이를 쉘 스크립트에 추가해주도록 하겠습니다.

echo " 🐳   서브모듈의 설정파일을 가져옵니다.\n"

git submodule update

 

 

 

⚙️ bapo.sh

#!/bin/sh

PROJECT_PATH=/home/ubuntu/mallang-projects
PROJECT_NAME=bapo-test
PORT=8080
BUILD_PATH=build/libs
JAR_NAME=jwp-shopping-order.jar


echo "\n 🐳   [$PROJECT_PATH/$PROJECT_NAME] 경로로 이동합니다.\n"

cd $PROJECT_PATH/$PROJECT_NAME

echo " 🐳   최신 코드를 PULL 합니다!\n"

git pull

echo " 🐳   서브모듈의 설정파일을 가져옵니다.\n"

git submodule update

echo " 🐳   프로젝트를 새롭게 빌드합니다.\n"

./gradlew clean build

echo " 🐳   [$PORT] 번 포트를 사용하는 애플리케이션을 찾습니다...\n"

PID=$(lsof -i :$PORT -t)

if [ -z $PID ]; then
	echo " 🎉   실행중인 애플리케이션이 없어서 곧바로 실행합니다.\n"

else
	echo " ❌   실행중인 애플리케이션이 있어서 이를 종료합니다. [PID = $PID]\n"
	kill -15 $PID
fi

echo " 🐳   애플리케이션을 실행하는데 필요한 환경변수를 세팅합니다.\n"

export FIRST_MALLANG_ENV="mallang1"
export SECOND_MALLANG_ENV=1234
export SPRING_PROFILES_ACTIVE="prod"
export RDS_DRIVER="com.mysql.cj.jdbc.Driver"
export RDS_URL="jdbc:mysql://[DB용 EC2의 프라이빗 IPv4 주소]:3306/bapo_test"
export RDS_USERNAME="mallang"
export RDS_PASSWORD="1234"

echo " 🎉   애플리케이션 실행합니다~ 🎉\n"

nohup java -jar $PROJECT_PATH/$PROJECT_NAME/$BUILD_PATH/$JAR_NAME &

 

 

 

또한 EC2 서버에 설정된 파일은 서브모듈 설정 이전에 생성된 파일이므로 다음 명령어를 최초 1회 실행시켜주어야 합니다.

git submodule init

 

 

 

 

 

 

 

이제 배포 스크립트를 실행합니다.

스크립트를 실행하면, git submodule update로 인해 다음과 같이 깃허브 인증이 필요하게 됩니다.

 

 

 

 

 

 

 

 

 

 

 

🧐 EC2에서 Private Repository에 대한 인증 문제 해결하기

우선 애플리케이션을 배포할 ec2 ssh에 접속한 후에 ssh-keygen -t rsa 명령어를 사용해 key를 생성합니다.

(나중에 sudo를 통해 ssh 주소를 사용하는 git을 사용할 일이 있다면 sudo ssh-keygen -t rsa 로 작성해주어야 합니다.)

(Enter ~~ 에 대해서는 모두 그냥 엔터만 입력합니다)

 

 

 

cat ~/.ssh/id_rsa.pub 명령어를 통해 생성된 키를 확인한 후, 이를 github 계정에 등록해주어야 합니다.

(만약 sudo를 통해 Key를 생성했다면, sudo su 를 먼저 입력한 이후, 위 명령어를 입력해야 보입니다.)

위를 복사한 뒤 깃허브에 접속합니다.

 

 

 

 

 

우측 상단 프로필 사진을 클릭한 뒤, Settings로 이동합니다.

 

 

 

 

 

SSH and GPG keys -> New SSH key를 클릭합니다.

 

 

 

 

 

 

Title은 임의로 작성해주시고, Key에 방금 전에 복사한 내용을 붙여넣어줍니다.

이후 Add SSH key를 통해 생성합니다.

 

 

 

 

이제 기존 https 방식을 사용하던 submodule의 주소를 ssh로 변경해주어야 합니다.

방법은 다음과 같습니다.

 

먼저 로컬로 돌아가 .gitmodules 파일에 들어갑니다.

url을 보면 https 를 사용하고 있는 것을 알 수 있는데요, 이를 SSH 로 바꿔주겠습니다.

 

 

 

 

우선 서브모듈의 Repository로 들어갑니다.

이후 Code -> SSH 를 클릭한 뒤 나오는 주소를 복사합니다.

 

기존 .gitmodules에 존재하는 url을 지운 뒤 위 ssh 주소를 붙여넣어줍니다.

이제 이를 커밋해주면, 설정이 모두 끝났습니다.

 

 

다시 ec2로 돌아와서 배포 스크립트를 실행합니다.

 

 

 

 

 

 

 

🧐 실행하기

정상적으로 실행된 것을 알 수 있습니다.

 

 

확인 겸 "/members"로 요청을 한번 보내보도록 하겠습니다.

 

모두 잘 작동하는 것을 알 수 있습니다.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

🧐 참고 - 최초 클론 시 서브모듈까지 모두 가져오는 방법

테스트해보기 위해 EC2 서버에 존재하는 기존의 프로젝트를 제거하고, 다시 clone받도록 하겠습니다.

우선 EC2 서버에 존재하는 기존의 프로젝트 코드를 모두 제거하였습니다.

 

 

서브모듈까지 clone하는 방법은 다음과 같습니다.

git clone --recurse-submodules {project_url}

 

 

 

즉 위 명령어는 아래 세 명령어를 합친 것이라 볼 수 있습니다.

git clone {project_url}
git submodule init
git submodule update

 

 

 

 

 

 

 

 

 

 

 

 

🧐 주의점

서브모듈의 내용을 수정했을 때, 반드시 서브 모듈의 커밋을 메인 커밋보다 먼저 해야 합니다.

 

 

 

 

 

 

 

 

 

 

 

🧐 git submodule update와 git submodule update  --remote의 차이 

update 뒤에 --remote 를 붙여준다면, 현재 서브모듈 원격저장소에 저장되어있는 상태를 내 로컬로 가져오게 됩니다.
만약 이것이 없다면 현재 작업 중인 commit 이 참조하고 있는 서브모듈의 상태를 내 로컬로 가져오게 됩니다.

 

따라서 일반적인 경우 EC2 서버에서는 --remote 옵션을 빼주고 실행하며,

실제 브랜치에서 코드를 작성하고 설정파일을 업데이트 하려는 경우 git submodule update --remote를 통해 서브모듈의 최신 버전을 가져온 후, 이를 커밋해주는 작업이 필요합니다.

 

 

 

 

 

 

 

 

 

 

 

🧐 마무리

이렇게 해서 서브모듈을 통해 민감한 정보를 관리하는 방법을 알아보았습니다.

서브모듈을 사용할 때, Private Repository 를 사용한다면 환경변수를 굳이 사용하지 않아도 되지만, 

혹시라도(휴먼 에러 등..?) private repository가 노출될 수도 있기 때문에 저는 무서워서 사용할 것 같네요.. ㅠㅠ😭

 

그럼 다음과 같은 질문을 할 수 있을 것 같습니다.

"환경변수 쓸거면 Submodule을 사용하는 이유가 없지 않나요??"

어느정도 동의합니다만, 여러 프로젝트에서 동일한 설정 정보등을 사용할 때, 관리가 용이하다는 장점이 있을 것 같습니다.

 

이제 다음 글부터는 CI/CD를 적용해 보도록 할텐데요, 우선 상대적으로 쉽다는 Github Action을 먼저 적용해 본 이후에, Jenkins도 적용해 보도록 하겠습니다.

(시작하기 시리즈에 맞게, 정말 설치하고 맛만 보는 정도로만 진행할 것 같습니다.. 저도 잘 모르기에..😭)

 

 

 

 

 

 

 

 

 

 

📚 Reference

https://git-scm.com/book/ko/v2/Git-%EB%8F%84%EA%B5%AC-%EC%84%9C%EB%B8%8C%EB%AA%A8%EB%93%88

Git - 서브모듈

https://jujeol-jujeol.github.io/2021/07/12/git-submodule-%EC%A0%81%EC%9A%A9%ED%95%98%EA%B8%B0/

[git] git submodule 적용하기

https://hudi.blog/git-submodule/

Git Submodule 알아보기

https://tecoble.techcourse.co.kr/post/2021-07-31-git-submodule/

git submodule로 중요한 정보 관리하기

https://my-codinglog.tistory.com/30

[Git] git submodule을 이용하여 중요한 정보 숨기기

https://prolog.techcourse.co.kr/studylogs/3571

우아한테크코스 학습로그 저장소