젠킨스를 사용한 지속적 배포 환경 구축기
2024.02.03
목차
• 젠킨스란?
• CD 다이어그램
• 파이프라인
젠킨스란?
젠킨스는 지속적인 통합(Continuous Integration, CI)과 지속적인 배포(Continuous Deployment, CD)를 위한 오픈소스 자동화 도구입니다.
• 지속적인 통합(Continuous Integration): CI는 개발자들이 코드를 공유 저장소에 푸시(push)할 때마다 자동으로 코드를 빌드하고 테스트하는 접근 방식을 의미합니다. 이를 통해 코드 통합의 복잡성을 줄이고, 버그를 빠르게 찾아 해결하는 것이 가능해집니다.
• 지속적인 배포(Continuous Deployment): CD는 CI가 끝난 후에 이어지는 과정으로, 빌드와 테스트가 성공적으로 완료되면 자동으로 프로덕션 환경에 배포하는 것을 의미합니다.
젠킨스는 이러한 CI/CD 프로세스를 자동화하고, 다양한 플러그인과 함께 사용할 수 있습니다. 또한 젠킨스는 파이프라인을 통해 작업의 실행 흐름을 세부적으로 설정하고 관리할 수 있습니다. 파이프라인은 프로젝트 빌드, 테스트 실행, 배포 등 여러 작업을 하나의 워크플로우로 연결하고 이를 자동화합니다.
CD 다이어그램
젠킨스 서버는 도커를 통해 이미지를 생성합니다. 그리고 생성한 이미지에 tag를 붙여 Harbor에 이미지를 push합니다. Docker Hub 대신 Harbor 선택한 이유는 Docker Hub는 private 레파지토리를 생성을 한개 초과하면 plan을 구매해야 하지만 Harbor는 오픈소스이기에 여러개의 private 레파지토리를 생성할 수 있는 점이 있습니다.
그리고 62서버로 접근하여 내부의 쉘 스크립트를 실행합니다. 해당 쉘 스크립트에는 Harbor 에서 Lastest tag가 붙어있는 이미지를 가져옵니다. 기존에 62서버에서 실행되고 있던 도커 이미지를 중단시키고 가져온 최신 이미지를 실행하여 배포 작업을 완료합니다.
파이프라인
pipeline { agent any stages { stage('Clone repository') { steps { git branch: 'develop', credentialsId: 'giantgiant', url: 'https://github.com/giantstep-corp/gims-frontend-next.git' } } stage('Build Docker image') { steps { script { // docker-compose 명령어로 이미지 생성 sh "docker compose build development" } } } stage('Push Docker image to Docker Hub') { steps { script { // 로컬 이미지 이름 def localImageName = "gims-frontend-development" // 레지스트리, 프로젝트, 이미지 이름, 태그를 조합한 완전한 이미지 이름 def imageNameWithTag = "10.0.2.63:32280/frontend/gims-development:${env.BUILD_NUMBER}" // 로컬 이미지에 새로운 태그 추가 sh "docker tag ${localImageName} ${imageNameWithTag}" // 이미지를 Harbor 레지스트리로 푸시 docker.withRegistry('http://10.0.2.63:32280', 'harbor-credentials') { def dockerImage = docker.image(imageNameWithTag) dockerImage.push() } } } } stage('SSH and Run Script') { steps { sshagent(credentials: ['gx-server01']) { // 원격 서버의 주소와 실행할 스크립트를 사용합니다. sh ''' [ -d ~/.ssh ] || mkdir ~/.ssh && chmod 0700 ~/.ssh ssh-keyscan -t rsa,dsa 10.0.2.62 >> ~/.ssh/known_hosts ssh -vvv gx-server01@10.0.2.62 bash /home/gx-server01/app/gims_client_front/deploy.sh ''' } } } } }
저희 레파지토리는 private이기 때문에 브랜치를 clone하기 위해 접근할 때 깃허브에서 발급한 토큰이 필요합니다. 그리고 ssh를 통해 62서버에 접근할 때도 키가 필요합니다.
그래서 젠킨스에서 제공하는 기능인 Credentials을 활용해서 파이프라인 코드에 토큰을 직접 기재하지 않도록 하였습니다. 이로 인해 가져갈 수 있는 이점이 있습니다.
• 보안
- 파이프라인에서는 credential의 ID만 참조하여 사용하게 됩니다. 이 ID는 토큰 값 자체가 아니기 때문에 외부에 노출되더라도 토큰을 악용할 수 없습니다.
• 유지보수
- 토큰 값이 변경될 경우, 파이프라인 코드에 직접 적어둔 토큰 값을 일일이 찾아서 수정해야 합니다. 하지만 젠킨스의 credentials 기능을 사용하면, 토큰 값을 한 곳에서 관리할 수 있어 변경이 필요할 경우 한 번에 수정할 수 있습니다.
• 재사용성
- 젠킨스의 credentials 기능을 사용하면, 한 번 설정한 토큰을 여러 파이프라인에서 재사용할 수 있습니다. 이는 중복된 코드를 줄이고 코드의 재사용성을 높여줍니다.