⚡ Artifact repository
📌 CI/CD 과정에서 부딪힌 난제
🔷 이번 프로젝트의 배포 단계는 EC2 인스턴스를 이용한다.
docker compose기술을 활용, 각 DB의 공식 이미지와 dockerfile로 구성된 커스텀 이미지를 이용하여 컨테이너를 빌드한다.Jenkins pipeline을 활용하여 빌드 및 테스팅, 배포를 모두 자동화시킨다.
🔷 문제는 빌드와 배포 과정에 포함되는 파일들!
- 암호, api 키 등 민감한 정보들이 담긴 파일은
Git은 물론이고 배포 과정에서 어떤 서버든 절대 드러나선 안된다. Node_Module등 빌드 및 라이브러리 관련 파일들을 모두 포함한 채로 관리하기에는 사이즈가 너무 크기 때문에 파이프라인에 올릴 때는 제외되어야 한다.
.gitignore를 통해Git에 올라가지 않도록 관리되고 있는 파일들이 대부분 그렇다.
- 하지만 빌드 및 배포가 진행되려면 이 친구들이 존재해야하고... 그렇다고 예민한 정보들을 넣어두고 배포할 수도 없는 상황.
📌 4가지 선택지
- 이에 대한 해답으로 4가지 방법을 알게 되었다.
🔷 환경 변수 또는 시크릿 파일 사용
- 민감한 설정이나 비밀번호와 같은 정보는 환경 변수나
GitLab Secret과 같은 기능을 사용하여 관리할 수 있다. CI/CD 파이프라인이 실행될 때, 이러한 변수들을 환경에 주입하여 사용할 수 있다.
🔷 템플릿 파일 사용
- 기본적인
docker-compose.yml파일을 저장소에 포함시키고, 필요한 비밀 정보는 템플릿 형식으로 남겨두어, CI/CD 파이프라인이 실행될 때 템플릿을 실제 값으로 대체하는 방식을 사용할 수 있다.
🔷 프라이빗 서브모듈 사용
- 설정 파일들을 별도의 비공개 Git 서브모듈로 관리하고, CI/CD 파이프라인에서 이 서브모듈을 체크아웃하는 방법도 있다. 이 경우 서브모듈의 접근 권한을 관리하여 보안을 유지할 수 있다.
🔷 아티팩트 저장소 사용
- CI/CD 파이프라인에서 필요한 파일들을 아티팩트 저장소에 업로드하고, 파이프라인에서는 이 저장소로부터 파일을 가져와 사용하는 방법도 있다.
🤔 나는 여기서 네번째 방식인 아티팩트 저장소 사용을 선택했다.
why?
-
환경 변수 또는 시크릿 파일 사용을 고려하기에는 변수화 시켜야 할 것들이 너무나도 많았고 docker compose 기술을 사용하는 만큼, 각 변수를 빌드 시에 어떻게 적용해야할지도 난관이었다.
-
탬플릿 파일 사용 역시 위와 마찬가지의 사유. 그리고 프로젝트의 효율적인 빌드를 위해 뺐던 개발 설정 및 라이브러리 파일 등을 탬플릿으로 넣을 수가 없었다.
-
프라이빗 서브모듈은 민감한 정보를 관리하는데 도움을 주나, 엄연히 개발 단계에서의 이야기이고 완전한 빌드를 통해 배포를 할 때에는 도움이 되지 않는다.
-
아티팩트 저장소는
EC2인스턴스 환경에 설치되어있는docker를 통해 편하게container로 열 수 있으며, 민감한 정보에 대한 타인의 접근을 막는데 용이하다. 어떤 저장소는 심지어 웹에서 관리할 수있는 기능까지 제공하니 내가 만들어두면 이쪽에 대한 지식이 전무한 팀원도 무엇이 들어있는지 알 수 있다. -
이미 EC2 인스턴스로 파이프라인 및 계정, 각종 환경 설정을 구축해둔 상태이기 때문에 아티팩트 저장소 지정을 위한 사전 작업들을 거의 모두 생략할 수 있다.
이러한 점들을 고려했을 때 가장 이상적인 선택지는 아티팩트 저장소였다.
📌 Artifact repository란?
🔷 소프트웨어 개발에서 생성된 바이너리 파일, 라이브러리, 설정 파일 등을 저장, 공유, 관리하기 위한 중앙 집중식 저장 공간
-
아티팩트 저장소를 통해 개발자는 필요한 의존성을 쉽게 찾아서 사용할 수 있고, 빌드 및 배포 과정을 효율적으로 관리할 수 있다.
-
대표적인 아티팩트 저장소로는
Maven Central,JFrog Artifactory,Nexus Repository와 같은 서비스가 있다. -
프로젝트의 안정성과 재사용성을 높이는 데 큰 역할을 한다.
나는 이 중에서 Sonatype Nexus Repository를 사용하기로 했다.
📌 Sonatype Nexus Repository 사용하기
🤔 왜? Nexus Repository를 선택했나요?
1. 중앙 집중식 종속성 관리
- 프로젝트에 필요한 라이브러리나 플러그인과 같은 종속성을 중앙 저장소에서 관리함으로써, 모든 개발자가 동일한 버전의 종속성을 사용하도록 보장한다. 이는 빌드의 일관성을 유지하는 데 도움이 된다.
2. 빌드 아티팩트 공유
- 빌드 과정에서 생성된 아티팩트(예: JAR, WAR 파일 등)를 Nexus에 저장함으로써, 다른 프로젝트나 팀원 간에 쉽게 공유할 수 있다. 이는 특히 대규모 프로젝트나 여러 프로젝트 간 의존성이 있는 경우 유용하다.
3. 보안 및 접근 제어
Nexus Repository Manager는 저장된 아티팩트에 대한 세밀한 접근 제어와 보안 정책을 제공한다. 이를 통해 비공개 라이브러리나 중요한 구성 파일을 안전하게 관리할 수 있다.
❗ 접근 제어와 보안 정책을 제공하긴하지만 사실 환경별 구성 파일이나 암호화된 비밀 정보 같은 중요한 설정 파일을 Nexus에 저장하는 것은 드문 경우라고 한다. 이러한 유형의 파일은 종종 보안이 중요한 정보를 포함하고 있어, 보다 전문화된 비밀 관리 시스템(예:
HashiCorp Vault,AWS Secrets Manager)을 사용하여 관리하는 것이 좋다. 내가 사용한 이유는 이 서비스의 배포가 일회성이고 기간 또한 매우 한정적이며, 치명적일 정도로 중요한 정보는 이미 다른 방식으로 암호화 되어있기 때문이다.
🦠 Nexus Repository Manager OSS Docker 컨테이너 실행
1. Docker 이미지 다운로드 및 실행
Sonatype에서 공식적으로 제공하는Nexus Repository Manager OSSDocker 이미지를 사용하여 컨테이너를 실행힌다.- EC2 인스턴스에 SSH로 접속한 후 다음 명령어를 실행한다.
docker run -d -p 8081:8081 --name nexus sonatype/nexus3- 이 명령어는
Nexus Repository Manager를 백그라운드에서 실행하며, 호스트의 8081 포트와 컨테이너의 8081 포트를 연결한다.
2. 도메인 설정
- 도메인을
Nexus Repository Manager에 연결하기 위해, EC2 인스턴스에 설정된 DNS 또는 도메인 이름 시스템에 해당 도메인이 EC2 인스턴스의 IP 주소를 가리키도록 설정해야 한다. 이 작업은 도메인을 관리하는 DNS 설정 페이지에서 진행할 수 있다.
도메인 설정은 이미 이전에 완료했으므로 이곳에서는 넘어간다.
3. Nexus 접근
- 설정이 완료되면, 웹 브라우저를 통해
http://설정한도메인이름(혹은 localhost):8081로Nexus Repository Manager에 접근할 수 있다.
4. Jenkins 파이프라인과의 통합
Jenkins파이프라인에서Nexus Repository Manager OSS를 사용하기 위해, 빌드 스크립트 내에서 Nexus 저장소에 접근하는 부분을 구성해야 한다. 이는 빌드 아티팩트를 저장하거나, 필요한 의존성을 Nexus로부터 가져오는 작업에 해당힌다.
이 단계는 다음에 다룬다.
웹 브라우저를 통해 접근하면 이런 화면이 뜬다.
로그인 시 기본 admin 계정은 아이디 admin 에 비밀번호 admin123이다.
💡 필자처럼 localhost가 아니라 따로 등록한 도메인을 통해 저장소를 파는 경우 password가 기본 계정의 패스워드가 아닐 수도 있다.
- 로컬 환경에서 설치했을 때 password 찾기
sudo cat /nexus-data/admin.password- docker image로 빌드했을 때 password 찾기
docker exec -it 컨테이너이름orID cat /nexus-data/admin.password❗ 처음 로그인을 하면 외부에서의 access 권한 승인에 대해 물어본다. 외부 access를 막는 것으로 설정해야 보안 상 안전하다.
💡 첫 로그인 이후에 비밀번호를 변경하게 도와준다.
레퍼지토리 생성, 파일 넣기, 파이프라인 연동 등은 다음에 다룬다.
