Github Actions

기존 배포방식의 문제점

---

AWS의 EC2 인스턴스를 사용하여 서비스를 배포하고 관리하는 과정에서, FileZilla를 통해 빌드 파일을 직접 인스턴스에 복사한 후, Putty로 SSH를 이용하여 인스턴스에 접속, 실행하는 방식을 사용해 왔다. 이러한 수동 배포 방식을 사용한 결과 다음과 같은 문제점들을 발견하게 되었다.

1. 배포 과정의 번거로움: 매번 파일을 전송하고, 서버에 접속하여 실행하는 과정은 시간이 많이 소요되며 번거롭다.

2. 실수의 가능성: 수동으로 진행되는 모든 과정은 실수를 발생시킬 가능성이 높다. 파일을 잘못 전송하거나, 실행 명령어를 잘못 입력하는 등의 실수가 서비스 중단으로 이어지기도 했다.

 

이러한 문제점들은 불필요한 추가 작업을 요구했고, 따라서 자동화 배포의 필요성을 느끼게 되었다.

 

CI/CD

---

 

자동화 배포를 적용하기 전에, CI/CD에 대한 개념을 이해해야 한다.

한 프로젝트에 여러 개발자가 참여하는 경우, 코드 안정성 유지는 프로젝트 성패를 좌우할 수 있다. 환경 변수 변경, 비즈니스 로직 수정, Git 충돌 등 다양한 문제가 발생할 수 있다. 이러한 문제들을 해결하기 위한 방법론으로 등장한 것이 바로 CI/CD이다.

 

CI(Continuous Integration)

CI, 즉 지속적 통합은 여러 개발자가 공동으로 작업하는 프로젝트에서 발생할 수 있는 코드 불일치를 최소화하는 개념이다. CI를 통해 애플리케이션의 변경 사항이 반영될 때마다 자동 빌드 및 테스트가 진행되어 잘못된 코드 공유를 방지하고 코드의 신뢰성을 높인다. (애초에 테스트를 통과하지 못하면 빌드 파일이 만들어 질 수 없기 때문에)

 

CD(Continuous Deployment)

CD는 지속적 배포를 의미하며, 프로젝트 변경 사항을 자동으로 배포하는 과정이다. CD를 통해 개발자는 변경 사항을 수동으로 배포하는 번거로움 없이, 지속적으로 안정적인 서비스를 제공할 수 있다.

 

CI/CD의 중요성

CI/CD는 개발과 운영의 간극을 줄이는 DevOps 문화의 핵심 요소이다. 이는 소프트웨어 개발 라이프사이클을 자동화하여, 더 빠르고, 더 안정적으로 소프트웨어를 제공하는 것을 목표로 한다.

 

🤯 DevOps란?

근본적으로 더 우수한 품질의 소프트웨어를 더 신속하게 전달하기 위한 소프트웨어 개발 프로세스이자 조직 문화적 변화를 가리킨다. 이를 위해 개발 팀과 IT 운영 팀의 활동을 자동화하고 통합한다. 이전엔 개별적으로, 즉 각자 작업하곤 했다. DevOps는 빈번하고 혁신적인 새로운 기능과 중단 없는 성능 및 가용성에 대한 소프트웨어 사용자의 끊임없이 증가하는 요구사항을 충족시키는 것이다. 즉 DevOps는 개발(Dev)과 운영(Ops)의 조화를 강조하는 문화, 움직임, 또는 관행이다. 그 목적은 개발과 운영 팀 간의 장벽을 제거하고 협업을 통해 소프트웨어 개발 및 배포 프로세스를 더 빠르고, 효율적으로 만드는 데 있다.

🤓 DevOps 등장 배경

이전까지만 해도, 광범위한 변경사항을 개발하고 코드 베이스에 통합하기 위해 많은 시간을 소요해야만 했다. 심지어 코드 테스트를 위해 수 개월을 더 사용해야 했다. 결과적으로 소프트웨어 릴리스 사이엔 수 개월 심지어 몇 년이 걸렸고, 릴리스 간의 여러 중요 패치나 버그 수정사항의 경우도 이와 마찬가지였다. (폭포수 방법론)

개발 속도를 빠르게 하고 품질을 향상시키기 위해 개발 팀은 애자일 소프트웨어 개발 방법론을 채택하기 시작했고, 이는 선형이 아니라 반복적이며 빈번한 업데이트에 집중한다. 이들 방법 중 가장 중요한 것은 지속적 통합 및 지속적 딜리버리 또는 CI/CD이다. 

* 애자일: 소규모 기능 단위로 빠르게 개발하고 적용을 반복하는 개발 방법

애자일 방법론과 CI/CD가 소프트웨어 개발 속도와 유연성을 향상시켰지만, 소프트웨어를 실제 사용자에게 제공하는 데 있어 IT 운영과 관련된 활동(ex: 수용성 테스트, 관리, 모니터링 등)이 새로운 병목 지점으로 부각되었다. 이는 개발된 소프트웨어의 신속한 배포와 운영에 장애를 초래했다.

DevOps는 이러한 문제를 해결하기 위해 등장했다. 애자일 방법론의 원칙을 소프트웨어 개발 뿐 아니라 IT 운영 전반에 적용하여, 개발과 운영 팀 간의 장벽을 허물고 긴밀한 협업을 촉진한다. 이를 통해 개발된 소프트웨어는 더 빠르게 고객에게 제공될 수 있고, 품질과 안정성을 유지하면서 지속적으로 개선될 수 있다.

😎 DevOps와 CI/CD 사이의 관계

이 두 개념은 소프트웨어 개발 및 배포 프로세스를 자동화하고 최적화하는 데 중점을 두고 있으며, 더 빠르고, 더 안정적이며, 더 자주 소프트웨어를 제공하는 것을 목표로 한다. DevOps는 팀 간의 소통과 협력을 강화하고, 작업 자동화와 통합을 통해 소프트웨어의 품질과 배포 속도를 개선하려는 목적을 가지고 있다.

CI/CD는 DevOps의 기술적 실행 방법 중 하나이다. DevOps 문화 내에서 CI/CD는 개발과 운영의 연속적인 협력과 통합을 가능하게 하는 핵심 요소이다. CI/CD를 통해 코드 변경사항의 자동 통합, 테스트, 배포가 가능해지며 이는 DevOps의 목표인 더 빠른 소프트웨어 제공과 품질 향상을 실현할 수 있게한다.

즉 CI/CD와DevOps는 서로를 보완하는 관계이다. 이들은 조직이 더 빠르고 자주, 더 높은 품질의 소프트웨어를 고객에게 제공할 수 있도록 돕는다.

 

https://www.ibm.com/kr-ko/topics/devops

DevOps란? | IBM

 

1. 자동화된 테스트: CI에서는 코드 변경 사항마다 자동화된 테스트가 수행되어, 실수나 버그를 조기에 발견하고 수정할 수 있다. 이는 개발자가 매 PR 리뷰 때마다 테스트 코드를 직접 실행하는 수고를 덜어준다.

2. 배포 자동화: CD를 통해 개발된 기능이나 수정 사항이 자동으로 배포되므로, 배포 과정에서 실수를 줄이고 배포 속도를 향상시킨다.

3. 지속적 피드백과 개선: CI/CD 파이프라인을 통해 지속적으로 피드백을 받으며, 이를 바탕으로 소프트웨어를 지속적으로 개선할 수 있다.

 

Github Actions

---

Github Actions는 쉽게 말해서 Github 내에서 직접 실행되는 CI/CD 도구이다. 이는 소프트웨어 개발 라이프사이클에 필요한 자동화된 워크플로우를 구성하여, 코드 변경 사항에 대한 빌드, 테스트, 배포 등을 자동으로 수행한다.

 

• 이벤트 기반 트리거: Github Actions는 Github에서 발생하는 이벤트(ex: push, pull request)에 반응하여 워크플로우를 실행한다. 이를 통해 개발 과정에서 발생하는 반복 작업을 자동화하고, 개발 및 배포 속도를 높인다.
• 직접적 통합: Github Repository와의 직접적 통합으로, 별도의 CI/CD 툴(ex: Jenkins, Circle CI, Travis CI)을 설치하거나 구성할 필요 없이 바로 사용이 가능하다.

 

Github Actions CI

[Github Actions를 사용한 CI 환경 구축]

 

 

현재 사용하고 있는 프로젝트 Repository이다. 프로젝트는 Maven을 기반으로 하기 때문에 Java with Maven을 선택했다. (현재 workflow가 실패했기 때문에 위와 같은 화면이 보인다.)

 

1. Github Repository 로 이동해서 Actions 탭에서 새로운 Workflow 를 추가
자주 사용되는 언어나 프레임워크는 이미 제공되는게 있기 때문에 검색해서 선택만 하면 된다.

 

2. Configure 버튼을 누르면 기본적으로 제공되는 maven.yml 파일이 제공된다.

현재 main branch에 push나 pull request 이벤트가 발생하면 워크플로우가 실행되도록 설정했다.

maven, java17을 기반하고 있으므로 해당 사항을 yml 파일에 반영해 준다.

 

Github Actions CD

[Github Actions를 사용한 CD 환경 구축]

 

 

🚀 Trouble Shooting: GitHub Actions를 통한 배포 자동화 과정에서의 설정 파일 문제 해결

 

배경
최근까지 수동 배포 방식을 사용하며, Spring Boot 애플리케이션의 중요 설정 정보들(예: RDS DB 패스워드, URL 등)을 application.yml 파일에 저장해왔다. 이 방식은 Spring Boot가 빌드 시 application.yml을 인식할 수 있어 문제가 없었다.

문제 발생
그러나 GitHub Actions를 도입하여 배포 과정을 자동화하면서 문제가 발생했다. 자동화된 배포 과정에서는 GitHub에 올라간 파일들을 기반으로 빌드가 진행되는데, .gitignore에 의해 application.yml 파일이 제외되어 있었기 때문에, 중요한 설정 정보를 인식할 수 없는 상황이 발생했다. 그렇다 해서 중요한 보안 정보를 포함한 application.yml을 직접 GitHub에 업로드하는 것은 보안상으로 매우 위험한 행위이다.

해결 과정
이 문제를 해결하기 위해, 중요한 보안 정보를 외부에서 주입받을 수 있도록 환경 변수를 활용하는 방식으로 전환하기로 결정했다. 이를 위해 다음과 같은 절차를 따랐다.