[CI/CD] Jenkins를 활용하여 CI/CD 구축하기 2 - CD 구축

[CI/CD] Jenkins를 활용하여 CI/CD 구축하기 1 - Jenkins 설치 및 CI 구축

 

이전 글에서 Jenkins에 대해 간단히 알아보고 이를 활용해 개인 프로젝트를 위한 CI를 구축하는 과정을 진행하였다. 이번 글에서는 이어서 CD를 구축하는 방법을 알아보도록 하겠다.

 

 

SSH Plugin 설치

---

CI 과정이 성공적으로 완료되면 프로젝트 빌드 결과물(jar 파일)을 프로젝트가 운영될 EC2 서버에 실행해야 한다. 이를 위해서는 Jenkins 빌드 과정에서 SSH를 통해 해당 EC2 서버에 접속해야 한다.

 

Jenkins에서는 해당 과정을 위한 SSH 플러그인을 제공하는데, 그 중에서 우리는 "SSH Agent"라는 플러그인을 사용할 것이다.

 

플러그인 설치

Jenkins에서 플러그인을 추가로 설치하고 싶다면 아래와 같이 진행하면 된다.

• Jenkins 관리 -> Plugins -> Avaiable plugins -> 원하는 플러그인 이름 검색 및 설치

설치 후 아래와 같은 화면이 뜬다면 설치가 성공적으로 완료된 것이고 이제 해당 플러그인을 사용할 수 있다.

 

 

운영 서버로 배포

---

AWS EC2 접속 정보 설정

보통 EC2 서버에 접속하기 위해서는 터미널에서 아래와 같은 명령어를 사용한다.

$ ssh -i {pem_key_이름}.pem {ec2_username}@{ec2_public_DNS}

 

여기서 pem key는 EC2 인스턴스를 생성할 때 만들었던 private key이다. Jenkins 서버에서 EC2 서버로 접속할 때도 위의 명령어를 통해 접속해야 하기 때문에, 해당 key를 Jenkins에 등록해야 한다.

 

1. Jenkins 관리 -> Credentials

 

2. (global) 클릭 -> Add Credential

 

 

3. SSH Username with private key 선택

 

 

이후 아래와 같이 ID, EC2 Username, 그리고 private key를 입력할 수 있는 화면이 나온다. 

 

private key는 pem 키 정보를 입력해주면 된다. 터미널에서 아래의 명령어를 사용하면 key 정보를 얻을 수 있다.

$ cat {aws_pem_key_이름}.pem

아래의 형태로 key 정보가 나오는데, 이를 그대로 복사하여 위의 private key를 입력하는 공간에 그대로 붙여넣으면 된다.

-----BEGIN RSA PRIVATE KEY-----
...
-----END RSA PRIVATE KEY-----

 

 

마지막으로 맨 아래의 "Create" 버튼을 클릭하면 아래와 같이 private key가 credentials로 등록된 것을 확인할 수 있다.

 

 

Script 수정

이전에 CI 구축 과정에서 작성했던 script에 배포 기능을 추가로 작성했다.

pipeline {
    agent any

    environment {
        EC2_USER = credentials('ec2-user')
        EC2_HOST = credentials('ec2-host')
        JAR_FILE = '/var/jenkins_home/workspace/give-me-con/build/libs/give-me-con-*.jar'
    }

    stages {
        stage("Add Properties") {
            steps {
                script{
                    withCredentials([file(credentialsId: 'app-aws', variable: 'awsProperties'),
                                     file(credentialsId: 'app-client', variable: 'clientProperties'),
                                     file(credentialsId: 'app-gcp', variable: 'gcpProperties'),
                                     file(credentialsId: 'app-jwt', variable: 'jwtProperties'),
                                     file(credentialsId: 'app-oauth', variable: 'oauthProperties'),
                                     file(credentialsId: 'app-payment', variable: 'paymentProperties'),
                                     file(credentialsId: 'gcp-credential', variable: 'gcpCredential'),
                                     file(credentialsId: 'app-env', variable: 'env')]) {

                        sh '''
                            cp -f ${awsProperties} src/main/resources/application-aws.yml
                            cp -f ${clientProperties} src/main/resources/application-client.yml
                            cp -f ${gcpProperties} src/main/resources/application-gcp.yml
                            cp -f ${jwtProperties} src/main/resources/application-jwt.yml
                            cp -f ${oauthProperties} src/main/resources/application-oauth.yml
                            cp -f ${paymentProperties} src/main/resources/application-payment.yml
                            cp -f ${gcpCredential} src/main/resources/gcp_credential.json
                            cp -f ${env} .env
                        '''
                    }
                }
            }
        }

        stage('Build') {
            steps {
                sh './gradlew clean build'
            }
        }

        stage('Deploy') {
            steps {
                sshagent(credentials: ['aws-key']) {
                    sh '''
                        ssh -o StrictHostKeyChecking=no ${EC2_USER}@${EC2_HOST} uptime
                        scp ${JAR_FILE} ${EC2_USER}@${EC2_HOST}:/home/${EC2_USER}/app/give-me-con/build/libs
                        ssh -t ${EC2_USER}@${EC2_HOST} ./app/deploy.sh
                    '''
                }
            }
        }
    }
}

• Deploy 과정은 앞서 설치한 SSH Agent 플러그인을 사용해 진행했다. 그리고 credentials로 저장한 private key를 ID를 통해 불러올 수 있도록 설정했다.
• sshagent step에서는 ssh를 통해 EC2 서버에 접속하는 명령어들을 작성하였다.
  1. 먼저, 운영 서버로 바로 접속할 수 있도록 StrictHostKeyChecking을 비활성화 시킨 상태로 ssh 접속을 진행한다.
  2. 이후 scp를 통해 빌드된 jar 파일을 운영 서버로 전송시킨다.
  3. 마지막으로, ssh를 통해 운영 서버 안에서 미리 작성해둔 deploy.sh를 실행하여 해당 파일을 실행한다.

이렇게 수정한 Jenkinsfile을 GitHub repo에 push하므로써 script 수정은 마무리하였다. 이제 마지막으로 Jenkins 빌드를 다시 실행하면 아래와 같이 "Checkout SCM" -> "Add Properties" -> "Build" -> "Deploy" 순서대로 CI/CD 과정이 완료된 것을 확인할 수 있다.

 

 

GitHub Webhook 등록

---

지금까지 Jenkins에서 CI/CD 과정을 진행하는 pipeline을 구성하였다. 하지만, 이 과정은 우리가 Jenkins에서 직접 빌드를 실행해야만 진행된다. 완전한 CI/CD를 위해서는 Jenkins 빌드 실행까지 자동화되는 환경을 구축해야 하는데, 여기서는 GitHub 프로젝트 repository에서 새로운 내용이 push 혹은 merge될 경우 자동으로 Jenkins 빌드가 실행되도록 만들어볼 것이다.

 

Jenkins 설정

먼저, Jenkins에서 만든 빌드 item의 메인 화면으로 돌아가 왼쪽의 "구성" 버튼을 클릭한 뒤, 설정 화면에서 "GitHub hook trigger for GITScm Polling" 이라는 항목에 체크한 후, 설정을 저장하자.

 

GitHub 설정

이제 GitHub repository에서 Webhook 설정을 진행해야 한다. 먼저, 브라우저로 GitHub에 접속 후, 프로젝트 repository 화면의 상단에 있는 "Settings"를 클릭하자.

 

그 다음, 왼쪽에 있는 메뉴 중 "Webhooks"를 선택하고 우측 상단에 나오는 "Add webhook" 버튼을 클릭하자.

 

그러면 아래와 같이 Webhook 등록 화면이 나오는데, 다음과 같이 정보를 입력한 뒤 맨 아래의 "Add webhook" 버튼을 클릭해 등록하자.

• Payload URL: http://{Jenkins_도메인}/github-webhook/
• Content type: application/json
• Which events would you like to trigger this webhook? - "Just the push event" 선택

 

이렇게 GitHub에서 Webhook 등록이 완료되었다.

 

이제 해당 repository에 새로운 내용이 push되거나 PR이 merge될 경우, GitHub에서 Webhook을 날려 Jenkins CI/CD 과정이 자동으로 실행된다.

 

현재 프로젝트 repository는 public으로 열어둔 상태이기 때문에, 별도의 GitHub 인증 과정 없이도 Webhook이 잘 동작한다. 만약, 인증 절차가 필요한 경우라면 GitHub에서 access token을 생성해 Jenkins에 credential을 추가해주어야 한다.

GitHub 인증 과정은  이 글에서 자세하게 확인할 수 있다.

 

 

참고

---

[DevOps] Jenkins를 통한 CI/CD 구축기 2편 (Backend CI/CD 구축)

젠킨스(Jenkins) GitHub Webhooks 연동