원글 페이지 : 바로가기
0. 들어가면서 앞선 과정을 통해 우리는 DNS 를 구축하여 사이트의 접근성을 높였으며 HTTPS 프로토콜을 사용하여 사이트의 보안성을 확보하였습니다. 상기한 작업을 통해 기초적인 배포 작업은 완수했다고 생각합니다. 그러나 소프트웨어 개발 생명주기(SDLC)의 대부분은 유지보수에 있는 것처럼, 유지보수적 측면에서의 편의성을 위해 추가적으로 해줘야할 작업이 있습니다. 그것은 바로 “CI/CD 파이프라인” 구축입니다. CI/CD에 대해서 살펴보기 전에, 현재 우리는 애플리케이션에서 버그 발생 시 로컬에서 디버그 실시 후 수동으로 명령어를 입력해 배포하거나 혹은 FileZila 와 같은 오픈소스 FTP[각주:1] 클라이언트를 사용해 직접 배포해줘야합니다. 물론 그 과정에서 일일이 chown, chmod 등을 통해 권한을 임시로 변경하거나 부여해주는 번거로운 작업이 동반됩니다. 심지어 형상 관리를 위해 깃에 대한 푸쉬도 따로 진행되어야 합니다. 그리고 이 과정은 유지보수 작업이 진행될 때마다 반복되어야 함으로 여간 번잡스럽지 않을 수 없습니다. 이런 과정을 혁신적으로 단축시켜주는 것이 바로 “CI/CD 파이프라인” 입니다. 본 고에서는 CI/CD 파이프라인 관련 개념들과 빌드 자동화 도구인 Jenkins 설치 방법에 대해 소개하고자 합니다. 주요 개념 CI, CD, 빌드, Jenkins 1. CI / CD 란? CI / CD 는 소프트웨어 개발과 배포 과정을 자동화하는 것을 의미합니다. 이는 소프트웨어 개발 주기를 단축하고 품질을 높이는 데 중요한 역할을 수행하는 과정입니다. 출처: REDHAT 통상적으로 CI / CD 는 git의 push -> CI -> CD 의 과정으로 동작합니다. 1.1. CI(Continuous Integration; 지속적 통합) 1.1.1. CI의 개념 CI는 문자 그대로 개발자들이 작업한 코드를 자주 통합하는 개발 방식입니다. 각 통합은 자동화된 빌드와 테스트 프로세스를 통해 검증됩니다. cf) 빌드(Build)란? 소스 코드를 실행 가능한 애플리케이션으로 변환하는 과정 코드 컴파일, 의존성 해결, 단위 테스트, 패키징 등을 포함하는 과정 Maven, Gradle, Ant 등 빌드 도구를 통해 자동화 가능 1.1.2. CI의 목표 CI를 실시하는 이유는 아래와 같습니다. 첫째, 문제를 조기에 발견할 수 있기 때문입니다. 작은 코드 변경 사항 발생 시마다 빌드 -> 테스트 과정을 수행하여 통합 과정에서 발생 가능한 문제를 조기에 발견하고 해결할 수 있습니다. 둘째, 지속적인 코드 품질 유지가 가능하기 때문입니다. 각 코드 변경 사항이 기존 코드와 잘 통합되는지 확인함에 따라 코드 품질의 유지가 지속적으로 이루어집니다. 1.1.3. CI의 과정 1) 코드 변경 사항 푸시 개발자가 유지보수한 코드를 형상 관리 시스템(ex. Git)에 푸시 2) 빌드 실시 CI 서버(Jenkins)가 푸시된 코드를 감지 후 자동으로 빌드 시작(빌드 도구 사용) 본 과정에서 코드 컴파일과 패키징 포함 3) 테스트 실시 빌드 완료 후 단위 테스트, 통합 테스트, 테스트 스크립트 실행 본 과정을 통해 코드의 기능이 예상대로 동작하는지 확인 4) 결과 피드백 콘솔 등을 통해 테스트 결과가 즉시 피드백됨 만약 실패 시 개발자는 즉시 문제 해결 후 다시 푸시 cf) CI 와 GitHub 의 충돌 확인의 차이점 CI 에 대해서 살펴보던 중 1차적으로 Git에서 충돌 여부를 감지하는데 왜 굳이 빌드를 통해 코드를 또 테스트하는지 의문이 들었습니다. 두 기능의 차이점은 하단의 표와 같습니다. GitHub 충돌 확인 CI 주 목적 코드 병합 가능 여부 확인 코드 기능 검증 및 통합 검사 방법 파일 수준에서의 충돌 확인 빌드, 단위 테스트, 통합 테스트 확인 범위 코드 병합 가능 여부 코드 기능 및 통합 상태 즉, 깃에서는 단순히 파일의 충돌 여부만을 체크해줄 뿐 해당 코드가 제대로 작동하는지는 확인할 수 없기 때문에 CI에서 빌드 및 테스트 과정을 통해 이를 확인한 뒤에 병합하는 과정을 거치는 것입니다. 2.1. CD(Continuous Deployment; 지속적 배포) 2.1.1. CD의 개념 빌드와 테스트를 거친 코드를 배포 가능한 상태로 만든 후(Continuous Delivery) 자동으로 운영 환경에 배포하는(Continuous Deployment) 과정입니다. CD는 주로 배포 과정과 관련되어 있습니다. 이상으로 CI/CD 의 개념을 간략하게 살펴봤다면 다음으로는 Jenkins를 통한 CI 자동화 구현 과정을 소개하겠습니다. 2. Jenkins 기반의 CI 구축 Jenkins를 통해 CI를 실시하는 과정은 크게 아래와 같습니다. prestep. Jenkins 및 관련 도구 설치 1. 빌드 트리거 설정 2. 빌드 스텝 설정 3. 테스트 스텝 설정 본격적으로 구축 과정에 돌입하기에 앞서 Jenkins 에 대해 간략하게 알아보도록 하겠습니다. 2.1. Jenkins 란? Jenkins는 Java로 제작된 오픈소스 CI/CD툴[각주:2]입니다. 젠킨스와 같은 빌드 자동화 도구들이 나타나기 전에 개발자들은 특정 시간에 커밋을 반영한 빌드를 실행하는 방식이 일반적이었다고 합니다. 그러나 빌드 자동화 도구들이 등장함으로써 개발자들의 시간을 절약하고 개발 생산성까지 높일 수 있었습니다. 출처: https://velog.io/@rnqhstlr2297/Jenkins-%EA%B0%9C%EB%85%90%EA%B3%BC-%EC%82%AC%EC%9A%A9 Prestep. Jenkins 및 관련 도구 설치 1). Java 설치 관련 사항 앞서 말씀드린대로 젠킨스는 자바 기반의 툴이기 때문에 당연하게도 자바 설치가 선행되어야 합니다. 아마 AWS EC2를 통해 배포 작업을 실시하면서 JAVA를 설치하셨을텐데 젠킨스에서 요구하는 자바 버전은 11 이상의 버전이기 때문에 1.8 버전을 사용중이시라면 11 또는 17버전으로 재설치하시기를 추천드립니다. (저도 1.8 버전을 사용중이었으나 젠킨스를 사용하기위해 11버전으로 재설치하였습니다.) jenkins가 지원하는 Java 버전에 대한 정보는 하단의 링크를 참고하시길 바랍니다. https://www.jenkins.io/doc/book/platform-information/support-policy-java/ 2). 시스템에 젠킨스 저장소 키 추가 젠킨스 설치 전 젠킨스 패키지 저장소의 공개 키를 시스템에 추가하여 젠킨스 패키지의 안전한 설치 및 업데이트가 보장되어야 합니다. 하단의 명령어를 통해 저장소 키를 추가할 수 있습니다. wget -q -O – https://pkg.jenkins.io/debian/jenkins.io.key | sudo apt-key add – 3). 패키지 저장소 주소 추가 sudo sh -c ‘echo deb http://pkg.jenkins.io/debian-stable binary/ > /etc/apt/sources.list.d/jenkins.list’ 4). 업데이트 및 설치 sudo apt-get update
sudo apt-get install jenkins 5). 젠킨스 실행 sudo systemctl start jenkins 6). 젠킨스 상태 확인 sudo systemctl status jenkins 위 명령어 실행 후 하단과 같이 Active 상태가 나와야 합니다(참고 사진입니다). 7). 젠킨스 포트 변경 젠킨스는 기본적으로 8080번 포트를 사용하고 있습니다. 그러나 아파치 톰캣 등 8080번 포트를 먼저 사용하는 경우가 많기 때문에 저는 9090번 포트로 변경해주었습니다. 젠킨스의 설정 파일은 크게 /usr/lib/systemd/system/jenkins.service 와 /etc/default/jenkins 파일이 있습니다. jenkins.service는 리눅스 배포판에서 젠킨스를 서비스로 관리하기 위한 설정 파일이고 /etc/default/jenkins는 젠킨스의 환경 변수 설정에 주로 사용되는 설정 파일입니다. 젠킨스의 버전에 따라 설정 파일 사용 방식이 다를 수 있으나 기본적으로 두 파일의 설정들을 모두 적절하게 설정하는 것을 추천합니다. 먼저 /usr/lib/systemd/system/jenkins.service에서 포트 번호를 변경하겠습니다. sudo vi /usr/lib/systemd/system/jenkins.service 해당 설정 파일에서 Environment=”JENKINS_PORT=9090″ Jenkins 포트 번호를 8080에서 9090으로 수정합니다. 변경 사항을 저장한 뒤 /etc/default/jenkins에서도 포트 번호를 수정합니다. sudo vi /etc/default/jenkins 해당 파일에서는 아래와 같이 설정함으로써 포트 번호 변경 작업이 완료되었습니다. HTTP_PORT=9090 이후로는 젠킨스의 인터페이스를 통해 접근할 수 있습니다. 8). 젠킨스 접속 먼저 http://www.도메인:9090 으로 접속합니다. 이후 하단의 명령어를 실행해 얻은 초기 비밀번호를 입력 후 sudo cat /var/lib/jenkins/secrets/initialAdminPassword Install suggested plugins 클릭하여 설치 후 계정을 생성합니다. 이후 빌드 시간을 한국 시간에 맞춰 수행하기 위해 타임존을 설정합니다. 설정 방법은 아래와 같습니다. jenkins 관리 > (최하단)Script Console > 하기한 코드 입력 > 실행 System.setProperty(‘org.apache.commons.jelly.tags.fmt.timeZone’, ‘Asia/Seoul’) 이로써 젠킨스 설치 작업이 완료되었습니다. 글이 길어지는 관계로 이후의 구축 과정은 다음글에 이어서 작성하겠습니다. 다음글에서는 본격적으로 젠킨스를 통해 GitHub와 연동하여 CI 프로세스를 구축하는 과정을 소개하겠습니다. 참고자료 https://artist-developer.tistory.com/24 https://velog.io/@songyaeji/CICD-2-%EC%9A%B0%EB%B6%84%ED%88%AC%EC%97%90-%EC%A0%A0%ED%82%A8%EC%8A%A4-%EC%84%A4%EC%B9%98%ED%95%98%EA%B8%B0 https://velog.io/@dev-hongs/linux%EC%97%90-jenkins-%EC%84%A4%EC%B9%98 https://velog.io/@dev-hongs/linux%EC%97%90-jenkins-%EC%84%A4%EC%B9%98 파일 전송 프로토콜(File Transfer Protocol)의 약자로 TCP/IP 네트워크상에서 컴퓨터들이 파일을 교환하기 위해 개발된 통신 규약 [본문으로] 이외에도 CircleCI와 JetBrains의 TeamCity, 마이크로소프트의 Azure DevOps 등이 존재 [본문으로]