프로젝트 4주차
2024-03-03 ~ 06
Vue.js (4)
Vue 프론트엔드 CI/CD를 위한 AWS EC2와 GitHub Action
Vue.js로 구현한 프론트엔드의 CI/CD를 위해서 AWS EC2와 Github Actions를 사용 예정이다.
처음 하는 작업이라서 이를 위해 자료 조사를 진행했고, 실제 작업은 역할 분담을 하여 팀원이 별도로 진행했다.
✏️ 학습 내용
1. 자료 조사
1) Vue 프론트엔드 CI/CD를 구축하기 위해 AWS EC2와 GitHub Actions를 사용하는 방법
2) Docker 사용 여부 결정
Vue 프론트엔드 CI/CD를 구축하기 위해 AWS EC2와 GitHub Actions를 사용하는 방법
1) AWS EC2 인스턴스 설정:
- AWS Management Console에 로그인하고 EC2 서비스로 이동합니다.
- 인스턴스를 생성하고 필요한 사양과 운영 체제를 선택합니다. (운영체제 선택, 웹 서버 설치, 필요한 소프트웨어 및 의존성 설치 등)
- 인스턴스에 필요한 보안 그룹 및 키 페어를 설정합니다.
AWS EC2 인스턴스를 설정하는 방법은 다음과 같습니다:
1. AWS 콘솔에 로그인: 먼저, AWS 콘솔에 로그인하여 EC2 서비스로 이동합니다.
2. 인스턴스 생성: EC2 대시보드에서 "인스턴스 시작" 버튼을 클릭하여 인스턴스 생성 프로세스를 시작합니다.
3. AMI 선택: Amazon Machine Image(AMI)를 선택합니다. AMI는 인스턴스의 기본 운영 체제와 소프트웨어 구성을 정의하는 템플릿입니다. 원하는 운영 체제(예: Amazon Linux, Ubuntu, Windows 등)와 버전을 선택합니다.
4. 인스턴스 유형 선택: 인스턴스 유형은 인스턴스의 하드웨어 성능과 용량을 결정합니다. 프론트엔드 애플리케이션의 요구 사항에 맞는 적절한 인스턴스 유형을 선택합니다. 예를 들어, 일반용 인스턴스, 컴퓨팅 최적화 인스턴스, 메모리 최적화 인스턴스 등이 있습니다.
5. 인스턴스 설정: 인스턴스의 세부 사항을 구성합니다. 이 단계에서는 인스턴스의 네트워크 설정, 보안 그룹, 스토리지 등을 정의합니다. 프론트엔드 애플리케이션에 필요한 포트를 열고, 필요한 스토리지 용량과 유형을 선택합니다.
6. 키 페어 생성: 인스턴스에 연결하기 위해 키 페어를 생성합니다. 키 페어는 SSH를 통해 인스턴스에 접속할 때 사용됩니다. 키 페어를 생성하고 다운로드하여 안전한 장소에 보관합니다.
7. 인스턴스 시작: 인스턴스 생성 설정을 검토하고 "시작" 버튼을 클릭하여 인스턴스를 시작합니다.
8. 접속: 인스턴스가 시작되면 SSH 클라이언트를 사용하여 인스턴스에 접속합니다. 키 페어 파일을 사용하여 SSH 접속을 설정합니다.
추천하는 EC2 인스턴스 설정은 프론트엔드 애플리케이션의 요구 사항에 따라 달라질 수 있습니다. 그러나 몇 가지 일반적인 추천 사항은 다음과 같습니다:
- 보안 그룹 구성: 인스턴스에 접근할 수 있는 IP 주소 범위를 제한하는 보안 그룹을 설정합니다. 필요한 포트만 열고, SSH 접근을 위한 포트는 제한적으로 설정하여 보안을 강화합니다.
- 스토리지 구성: 프론트엔드 애플리케이션에 필요한 스토리지 용량과 유형을 선택합니다. 예를 들어, EBS(Elastic Block Store) 볼륨을 사용하여 데이터를 저장하거나, Amazon S3 등의 스토리지 서비스를 활용할 수 있습니다.
- 모니터링 및 로깅 설정: CloudWatch와 같은 AWS의 모니터링 및 로깅 서비스를 사용하여 인스턴스의 성능 및 로그를 모니터링하고 관리합니다.요한 경우 CloudWatch 에이전트를 설치하여 세부적인 모니터링을 구성할 수도 있습니다.
- 스케일링 옵션: 프론트엔드 애플리케이션의 트래픽이 예측할 수 없이 증가하는 경우, Auto Scaling 그룹을 설정하여 자동으로 인스턴스를 확장하고 축소할 수 있습니다.
이러한 설정을 통해 EC2 인스턴스를 프론트엔드 애플리케이션에 적합하게 구성할 수 있습니다. 그러나 구체적인 요구 사항과 상황에 따라 설정이 달라질 수 있으므로 필요에 맞게 조정해야 합니다.
참고 :
2) Vue 프로젝트, GitHub 레포지토리 설정:
- 로컬에서 Vue 프로젝트를 생성하고 개발을 진행합니다.
- 프로젝트를 Git 저장소에 업로드 (소스 커밋)하고, 브랜치를 관리하여 개발 작업을 진행합니다.
3) GitHub Actions 워크플로우 설정:
깃허브 액션을 사용하여 CI/CD 워크플로우를 작성합니다. 워크플로우는 .github/workflows 디렉토리에 yaml 파일로 저장됩니다. 워크플로우는 소스 코드 변경 사항을 감지하고, 필요한 빌드, 테스트, 배포 작업을 수행합니다.
- GitHub 저장소에서 Actions 탭으로 이동합니다.
- 워크플로우 파일(.yml)을 생성하고 필요한 작업을 정의합니다.
- 워크플로우 파일에 AWS EC2 인스턴스에 연결하여 배포하는 작업을 추가합니다.
깃허브(GitHub) 액션 워크플로우를 설정하는 자세한 방법에 대해 알려드리겠습니다. 아래 단계를 따라 진행하면 됩니다:
1. 깃허브 저장소에서 저장소 홈페이지로 이동합니다.
2. 저장소 홈페이지에서 상단 탭 중 "Actions"를 클릭합니다.
3. "New workflow" 버튼을 클릭하여 새로운 워크플로우를 생성합니다.
4. 워크플로우 파일을 작성하기 위해 ".github/workflows" 디렉토리를 생성합니다.
5. 생성한 디렉토리 내에 워크플로우 파일을 작성합니다. 파일은 YAML 형식으로 작성되어야 합니다.
6. 워크플로우 파일에는 이벤트 트리거, 작업 단계, 작업 등을 정의합니다.
- 이벤트 트리거: 워크플로우를 실행시킬 이벤트를 정의합니다. 예를 들어, push, pull_request 등이 있습니다.
- 작업 단계: 워크플로우의 각 단계를 정의합니다. 각 단계는 한 개 이상의 작업으로 구성됩니다.
- 작업: 워크플로우에서 수행할 실제 작업을 정의합니다. 예를 들어, 코드 빌드, 테스트, 배포 등이 있습니다.
7. 워크플로우 파일 작성이 완료되면 저장하고 커밋합니다.
8. 작성한 워크플로우가 깃허브 저장소에 푸시되면 자동으로 워크플로우가 실행됩니다.
위의 단계를 따라 워크플로우를 설정하면 됩니다. 워크플로우 파일 작성에 대한 자세한 내용은 깃허브 공식 문서를 참고하시면 도움이 될 것입니다.
참고 :
4) 빌드 및 테스트 단계
- 워크플로우에서 빌드 단계를 정의하고, 필요한 빌드 도구를 사용하여 프론트엔드 애플리케이션을 빌드합니다.
- 테스트 단계에서는 적절한 테스트 도구를 선택하고 테스트 스크립트를 실행합니다.
빌드 및 테스트 단계에 대해 자세히 설명해 드리겠습니다.
1. 빌드(Build) 단계:
- 빌드 단계는 소스 코드를 컴파일하거나 필요한 리소스를 준비하는 단계입니다.
- 일반적으로 프로그래밍 언어에 따라 해당 언어의 컴파일러 또는 빌드 도구를 사용하여 빌드 작업을 수행합니다.
- 프로젝트의 언어, 프레임워크, 빌드 도구에 따라 빌드 설정이 달라질 수 있습니다. 예를 들어, Java 프로젝트의 경우 Maven이나 Gradle과 같은 빌드 도구를 사용할 수 있습니다.
- 프로젝트 루트 디렉토리에 있는 빌드 도구 설정 파일 (예: pom.xml, build.gradle)을 편집하여 필요한 빌드 단계를 정의합니다.
- 빌드 단계에서는 소스 코드의 구문 검사, 의존성 관리, 패키지 설치 등을 수행할 수 있습니다.
- 빌드 도구는 필요한 종속성을 자동으로 다운로드하고, 빌드 결과물을 생성합니다.
- 빌드가 성공적으로 완료되면 실행 가능한 애플리케이션 또는 배포에 필요한 파일이 생성됩니다.
2. 테스트(Test) 단계:
- 테스트 단계는 빌드된 애플리케이션의 품질을 확인하기 위해 수행되는 작업입니다. 빌드된 애플리케이션을 실제로 실행하여 기능적인 동작을 검증합니다.
- 다양한 테스트 도구와 프레임워크를 사용하여 자동화된 테스트를 실행하고 테스트 결과를 분석합니다. 다양한 테스트 도구와 프레임워크를 사용할 수 있으며, 각 테스트 도구는 자체적인 설정 파일이나 어노테이션을 사용하여 테스트를 정의합니다.
- 일반적으로 단위 테스트, 통합 테스트, 시스템 테스트 등 다양한 종류의 테스트를 작성하고 수행합니다.
- 테스트 단계에서는 예상되는 결과와 실제 결과를 비교하여 테스트의 성공 여부를 확인합니다. 코드의 기능적인 동작, 예외 상황 처리, 성능 등을 검증합니다.
- 테스트가 성공적으로 완료되면 코드의 신뢰성을 높일 수 있고, 잠재적인 버그를 발견하여 수정할 수 있습니다.
- 테스트 도구는 테스트 커버리지, 코드 커버리지 등의 보고서를 생성하여 테스트 결과를 시각적으로 확인할 수 있도록 지원합니다.
빌드 및 테스트 단계는 소프트웨어 개발과정에서 중요한 부분이며, 자동화하여 효율적으로 수행하는 것이 좋습니다. 자세한 구현 방법은 사용하는 언어, 프레임워크, 도구에 따라 다를 수 있습니다. 해당 기술 스택에 맞는 빌드 도구와 테스트 도구를 선택하고, 해당 도구의 문서와 가이드를 참고하여 구체적인 설정 및 실행 방법을 확인하시면 됩니다.
이러한 빌드 및 테스트 단계는 주로 CI/CD (Continuous Integration/Continuous Delivery) 파이프라인에서 자동화하여 실행됩니다. CI/CD 도구 (예: Jenkins, Travis CI, GitHub Actions)를 사용하면 소스 코드가 변경될 때마다 자동으로 빌드 및 테스트를 수행할 수 있습니다.
프로젝트의 특정 언어, 프레임워크, 빌드 도구, 테스트 도구에 따라 더 구체적인 설정 방법이 달라질 수 있습니다. 해당 기술 스택의 문서와 가이드를 참고하여 빌드 및 테스트 설정을 자세히 확인하시면 도움이 될 것입니다.
참고 :
5) AWS EC2 배포 설정:
워크플로우에서 배포 단계를 정의하고, EC2 인스턴스에 빌드된 애플리케이션을 배포합니다. 배포 스크립트를 작성하여 EC2 인스턴스에 접속하고 필요한 파일을 전송하고, 웹 서버를 재시작하거나 업데이트된 파일을 서비스하는 등의 작업을 수행합니다.
- AWS EC2 인스턴스에 SSH로 접속합니다.
- 필요한 의존성을 설치하고 Vue 프로젝트를 빌드합니다.
- 웹 서버 설정을 구성하고 Vue 프로젝트를 배포합니다.
AWS EC2 배포 설정에 대해 자세히 설명해 드리겠습니다.
AWS EC2는 클라우드 상에서 가상 서버를 생성하고 관리할 수 있는 서비스입니다. EC2를 사용하여 애플리케이션을 배포하기 위해 다음과 같은 단계를 수행할 수 있습니다:
1. EC2 인스턴스 생성:
- AWS 콘솔 또는 AWS CLI를 사용하여 EC2 인스턴스를 생성합니다.
- 인스턴스 유형, 운영 체제, 스토리지 등을 선택하고, 보안 그룹 및 SSH 키 페어 등의 구성을 설정합니다.
2. 애플리케이션 빌드:
- 애플리케이션의 소스 코드를 빌드합니다. 이 단계에서는 애플리케이션의 의존성을 설치하고 필요한 리소스를 준비합니다.
- 빌드 도구 (예: Maven, Gradle)를 사용하여 빌드 스크립트를 실행하고 실행 가능한 파일 또는 배포에 필요한 파일을 생성합니다.
3. AMI 생성:
- 애플리케이션을 실행하기 위한 Amazon Machine Image (AMI)를 생성합니다.
- AMI는 EC2 인스턴스를 생성하는 데 사용되며, 애플리케이션 및 환경 설정이 포함된 이미지입니다.
4. 인스턴스 시작:
- AMI를 기반으로 EC2 인스턴스를 시작합니다.
- EC2 인스턴스에는 애플리케이션을 실행하기 위한 운영 체제, 환경 변수, 네트워크 설정 등이 포함됩니다.
5. 로드 밸런서 구성 (선택 사항):
- 로드 밸런서를 사용하여 여러 EC2 인스턴스에 트래픽을 분산시킬 수 있습니다.
- 로드 밸런서를 구성하여 고가용성 및 확장성을 제공할 수 있습니다.
6. 보안 그룹 및 네트워크 구성:
- 보안 그룹을 설정하여 인스턴스에 대한 액세스 제어 및 네트워크 보안을 구성합니다.
- 필요한 경우 VPC (Virtual Private Cloud)를 설정하여 네트워크 환경을 구성할 수 있습니다.
7. 애플리케이션 배포:
- EC2 인스턴스에 애플리케이션을 배포합니다.
- SSH를 사용하여 인스턴스에 연결하고, 배포 파일을 업로드하거나 Git 또는 소스 코드 관리 도구를 통해 소스 코드를 가져옵니다.
- 애플리케이션의 실행 파일이나 필요한 파일을 인스턴스에 복사하고, 실행 스크립트를 실행하여 애플리케이션을 실행합니다.
이와 같은 방법으로 AWS EC2를 사용하여 애플리케이션을 배포할 수 있습니다. 실제로는 프로젝트의 특정 요구사항과 기술 스택에 따라 추가적인 구성 및 설정이 필요할 수 있습니다. AWS EC2의 상세한 사용 방법과 설정은 AWS 공식 문서를 참고하시면 도움이 됩니다.
참고 :
6) 워크플로우 실행 및 모니터링
- 워크플로우를 실행하여 변경 사항을 감지하고 CI/CD 작업이 수행되는지 확인합니다.
- 깃허브 액션의 워크플로우 실행 기록을 모니터링하여 성공 또는 오류를 확인할 수 있습니다.
- 생략할 수 있습니다.
워크플로우 실행 및 모니터링에 대해 자세히 설명해 드리겠습니다.
1. 워크플로우 실행:
- 워크플로우 실행을 위해 AWS Step Functions 서비스를 사용할 수 있습니다. Step Functions은 서버리스 워크플로우 오케스트레이션 서비스로, 간단한 JSON 기반의 상태 머신 언어를 사용하여 워크플로우를 정의하고 실행할 수 있습니다.
- Step Functions 콘솔 또는 AWS SDK를 사용하여 워크플로우를 생성하고 실행합니다.
- 워크플로우 정의는 상태 및 상태 전이로 구성되며, 각 상태는 AWS Lambda 함수, AWS Batch 작업, AWS Glue 작업 등과 같은 다양한 AWS 리소스를 호출할 수 있습니다.
2. 워크플로우 모니터링:
- AWS Step Functions 콘솔을 통해 워크플로우의 실행 상태를 모니터링할 수 있습니다. 콘솔에서는 워크플로우 실행의 진행 상황, 각 상태의 성공 또는 실패 여부, 실행 시간 등을 확인할 수 있습니다.
- 워크플로우 실행 로그를 CloudWatch Logs에 저장하고 모니터링할 수도 있습니다. CloudWatch Logs는 워크플로우 실행 중 발생하는 로그를 중앙에서 수집하고 분석할 수 있는 서비스입니다.
- 상태 전이에서 예외가 발생한 경우, Step Functions은 해당 예외를 캡처하고 알림을 보낼 수 있습니다. 예를 들어, SNS 알림을 구성하여 워크플로우 실행 중 예외가 발생할 때 알림을 받을 수 있습니다.
3. 워크플로우 재시작:
- 워크플로우 실행 중에 문제가 발생하거나 중단된 경우, Step Functions을 사용하여 워크플로우를 재시작할 수 있습니다. 재시작은 이전 상태에서 워크플로우를 다시 시작하고, 이전 상태 이후의 상태 전이를 건너뛰게 됩니다. 이를 통해 워크플로우의 오류 복구와 예외 처리가 가능합니다.
4. 상태 전이 추적:
- 워크플로우 실행 중에 각 상태 전이가 어떻게 진행되는지 추적하고 싶은 경우, AWS X-Ray를 사용할 수 있습니다. X-Ray는 애플리케이션의 분산 추적 및 디버깅을 제공하는 서비스로, 워크플로우의 각 단계에서 발생하는 지연, 예외 및 성능 문제를 식별할 수 있습니다.
AWS Step Functions을 사용하여 워크플로우를 실행하고 모니터링하는 방법에 대해 알려드렸습니다. 실제로는 워크플로우의 구성에 따라 추가적인 설정이 필요할 수 있으며, AWS 공식 문서를 참고하시면 더 자세한 내용을 확인하실 수 있습니다.
참고 :
- https://docs.aws.amazon.com/ko_kr/glue/latest/dg/running_monitoring_workflow.html
- https://experienceleague.adobe.com/docs/campaign/automation/workflows/monitoring-workflows/monitor-workflow-execution.html?lang=ko
- https://experienceleague.adobe.com/docs/campaign-standard/using/managing-processes-and-data/executing-a-workflow/monitoring-workflow-execution.html?lang=ko
이렇게 설정하면 GitHub Actions를 사용하여 Vue 프로젝트의 변경 사항을 감지하고 자동으로 빌드 및 배포할 수 있습니다. AWS EC2를 사용하여 프론트엔드 애플리케이션을 호스팅하고 지속적인 통합 및 배포를 구현할 수 있습니다. 자세한 내용은 AWS 및 GitHub Actions 공식 문서를 참조하시면 도움이 될 것입니다.
📌 EC2와 GitHub Actions를 함께 사용하는 경우 장점
1. 확장성: EC2는 클라우드 기반의 가상 서버이므로 필요에 따라 인스턴스의 수를 조정하여 애플리케이션을 확장할 수 있습니다. GitHub Actions는 클라우드에서 실행되므로 별도의 인프라 구성 없이 확장 가능한 CI/CD 워크플로우를 구성할 수 있습니다.
2. 유연성: EC2 인스턴스에는 다양한 운영 체제와 소프트웨어를 설치하고 구성할 수 있습니다. 이를 통해 프론트엔드 애플리케이션을 실행하기에 적합한 환경을 구성할 수 있습니다. GitHub Actions는 YAML 파일을 사용하여 워크플로우를 정의하므로 필요한 빌드, 테스트, 배포 작업을 자유롭게 구성할 수 있습니다.
3. 자동화: GitHub Actions를 사용하면 소스 코드 변경 사항을 감지하고 자동으로 빌드, 테스트, 배포 작업을 수행할 수 있습니다. 이를 통해 개발자는 반복적이고 번거로운 작업을 수동으로 수행하지 않아도 되며, 프로젝트의 품질과 배포 속도를 향상시킬 수 있습니다.
4. 통합성: GitHub Actions는 GitHub과의 강력한 통합을 제공합니다. GitHub 리포지토리와 연동하여 소스 코드 변경 사항을 감지하고 워크플로우를 실행할 수 있습니다. 또한, GitHub의 이슈, 풀 리퀘스트, 코드 리뷰 등과 연계하여 프로젝트의 전반적인 관리를 용이하게 할 수 있습니다.
5. 비용 효율성: EC2는 사용한 만큼 비용을 지불하는 페이-퍼-유즈 모델을 채택하고 있습니다. 따라서 필요한 시간 동안만 EC2 인스턴스를 사용하고, GitHub Actions는 무료로 제공되는 한도 내에서 사용할 수 있으므로 비용을 절감할 수 있습니다.
위의 장점들로 인해 EC2와 GitHub Actions를 함께 사용하면 프론트엔드 애플리케이션의 개발, 빌드, 테스트, 배포 과정을 자동화하고 효율적으로 관리할 수 있습니다.
📌 참고한 자료들
- https://velog.io/@zinukk/AWS-EC2와-Github-Actions로-프론트엔드-CICD-구축하기-1
- https://velog.io/@cataiden/ci-cd-with-github-actions-and-aws-codedeploy
- https://blog.bespinglobal.com/post/github-action-으로-ec2-에-배포하기/
- https://iamjooon2.tistory.com/m/25
- 뤼튼 질의응답
- https://soda-dev.tistory.com/99
https://velog.io/@xxell-8/GitHub-Pages를-통한-배포-docs-폴더를-활용한-Vue.js-수동-배포
📌 CI/CD 관련 자료
- https://www.redhat.com/ko/topics/devops/what-cicd-pipeline
- https://gitlab-docs.infograb.net/16.7/ee/development/cicd/index.html
- https://www.redhat.com/ko/topics/devops/what-is-ci-cd
- https://techscene.tistory.com/entry/CICD-가이드-지속가능한-개발의-꽃
- https://www.jetbrains.com/ko-kr/teamcity/ci-cd-guide/ci-cd-pipeline/
Docker 사용 여부 결정
📌 깃허브 레포지토리에 프론트엔드 소스 코드만 포함되어 있다면 도커 사용할 필요가 없을까?
만약 깃허브 레포지토리에는 프론트엔드 소스 코드만 포함되어 있다면, Docker를 사용할 필요가 없을 수 있습니다. Docker는 주로 애플리케이션과 그에 필요한 종속성을 컨테이너화하여 효율적으로 배포하고 실행하는 데 사용됩니다. 하지만 프론트엔드 개발은 주로 클라이언트 측에서 실행되며, 종속성이나 실행 환경에 대한 복잡성이 상대적으로 적을 수 있습니다.
프론트엔드 소스 코드는 주로 정적 파일(HTML, CSS, JavaScript)로 구성되며, 이는 웹 브라우저에서 직접 실행됩니다. 따라서 개발 환경에 대한 종속성을 최소화하고, 간단한 웹 서버를 사용하여 프론트엔드 애플리케이션을 실행할 수 있습니다. 이 경우에는 Docker를 사용하지 않고도 프론트엔드를 개발 및 배포할 수 있습니다.
하지만 프론트엔드 애플리케이션에 백엔드 API와의 통신이 필요하거나, 특정 환경에서의 일관성을 유지해야 하는 경우에는 Docker를 사용하는 것이 유용할 수 있습니다. 또한 여러 개발자가 협업하고, 프론트엔드와 백엔드가 함께 배포되어야 하는 경우에도 Docker를 사용하여 개발 환경을 표준화하고 배포 프로세스를 간소화할 수 있습니다.
도커를 사용하여 개발 환경을 표준화하고 배포 프로세스를 간소화하는 방법은 다음과 같습니다:
1. 이미지 기반의 개발 환경 구성: 도커를 사용하여 개발 환경을 이미지로 정의합니다. 이 이미지에는 애플리케이션의 종속성, 라이브러리, 실행 환경 등이 포함됩니다. 개발 팀의 모든 구성원은 동일한 이미지를 사용하여 개발 환경을 구축할 수 있으므로 개발 환경의 표준화가 이루어집니다.
2. 도커 컴포즈를 사용한 환경 구성: 도커 컴포즈는 멀티 컨테이너 애플리케이션을 정의하고 관리하는 도구입니다. 도커 컴포즈 파일을 사용하여 개발 환경에 필요한 여러 컨테이너를 정의하고 실행할 수 있습니다. 이를 통해 개발 환경의 구성을 단순화하고 표준화할 수 있습니다.
3. 배포용 이미지 생성: 개발이 완료되면 도커 이미지를 생성하여 애플리케이션을 배포합니다. 이미지에는 애플리케이션 및 그에 필요한 종속성이 포함되어 있으므로, 배포 환경에서 동일한 이미지를 사용하여 일관된 실행 환경을 구축할 수 있습니다.
4. 스케일링 및 관리 용이성: 도커를 사용하면 애플리케이션의 스케일링과 관리가 용이해집니다. 도커 컨테이너는 가볍고 빠르게 생성되고 제거될 수 있으며, 컨테이너 오케스트레이션 도구를 사용하여 여러 컨테이너를 관리할 수 있습니다. 이를 통해 애플리케이션의 확장성과 유연성을 높일 수 있습니다.
5. 환경 일관성 유지: 도커를 사용하면 개발, 테스트, 스테이징, 프로덕션 등 다양한 환경에서 일관성을 유지할 수 있습니다. 동일한 이미지와 환경 구성을 사용하여 각 환경에서 애플리케이션을 배포하고 실행할 수 있으므로, 버그나 호환성 문제를 사전에 파악할 수 있습니다.
이러한 방법들을 사용하여 도커를 활용하면 개발 환경의 표준화와 배포 프로세스의 간소화를 달성할 수 있습니다. 일관된 개발 환경과 효율적인 배포를 통해 개발 팀은 생산성을 향상시킬 수 있고, 애플리케이션의 유지 보수 및 관리도 용이해집니다.
📌 프론트엔드와 백엔드 API 통신이 필요하다면 도커를 사용하는 것을 권장하지만, 안 써도 되긴 한다.
프론트엔드만으로 구성된 깃허브 레포지토리와 백엔드만으로 구성된 깃허브 레포지토리가 있고, 프론트엔드에서는 백엔드 API와의 통신이 필요하다면, 프론트엔드의 CI/CD를 위해 도커를 사용하는 것이 좋습니다. 도커를 사용하면 다음과 같은 이점을 얻을 수 있습니다:
1. 환경 일관성: 도커는 애플리케이션을 컨테이너로 패키징하므로, 프론트엔드 애플리케이션과 백엔드 API 간의 통신을 일관된 환경에서 테스트하고 실행할 수 있습니다. 동일한 도커 이미지를 사용하여 개발, 테스트, 스테이징, 프로덕션 환경에서 일관성 있는 실행 환경을 유지할 수 있습니다.
2. 휴대성: 도커 컨테이너는 가볍고 이식성이 뛰어나기 때문에, 로컬 개발 환경에서도 동일한 환경을 구성할 수 있습니다. 프론트엔드 개발자는 도커 이미지를 사용하여 로컬에서 애플리케이션을 실행하고 테스트할 수 있습니다.
3. 확장성: 도커 컨테이너는 쉽게 확장할 수 있습니다. 프론트엔드의 CI/CD 파이프라인에서 도커를 사용하면, 필요한 경우 여러 개의 도커 컨테이너를 생성하여 병렬로 테스트하거나 배포할 수 있습니다.
4. 버전 관리: 도커 이미지는 버전 관리가 용이합니다. 도커 파일을 사용하여 이미지를 정의하고, 이미지의 변경 사항을 커밋하고 태그를 지정할 수 있습니다. 이를 통해 프론트엔드 애플리케이션의 버전을 관리하고, 롤백이 필요한 경우 이전 버전으로 쉽게 전환할 수 있습니다.
위의 이유로 도커를 사용하면 프론트엔드의 CI/CD를 효율적으로 관리할 수 있습니다. 그러나 도커 없이도 CI/CD를 구성하는 것은 가능합니다. 다만, 도커를 사용하면 개발 환경의 표준화와 일관성을 유지하며, 배포 과정을 간소화할 수 있기 때문에 추천드립니다. 도커를 활용하면 개발자들 사이의 협업도 원활해지고, 애플리케이션의 배포 및 관리가 간편해집니다.
📌 도커를 사용하면 발생할 수 있는 문제점이나 단점
도커를 사용하면 많은 이점이 있지만, 일부 제한 사항과 문제점도 고려해야 합니다. 도커를 사용할 때 발생할 수 있는 주요 문제점과 단점은 다음과 같습니다:
1. 학습 곡선: 도커는 기존의 가상화 기술과는 다른 개념을 가지고 있기 때문에 처음 사용하는 경우 학습 곡선이 있을 수 있습니다. 도커의 개념과 명령어, 이미지 및 컨테이너 관리 방법 등을 익히는 데 시간과 노력이 필요할 수 있습니다.
2. 자원 사용: 도커는 가상화를 통해 애플리케이션을 실행하므로 호스트 시스템의 자원을 일부 사용합니다. 따라서 도커를 실행하는 호스트 시스템이 충분한 자원(메모리, 디스크 공간 등)을 가지고 있어야 합니다. 자원 부족으로 인해 성능 저하나 충돌이 발생할 수 있습니다.
3. 보안 취약성: 도커는 컨테이너 간에 격리를 제공하지만, 완벽한 보안을 보장하지는 않습니다. 악의적인 사용자가 컨테이너 내부로 침투하여 호스트 시스템이나 다른 컨테이너에 영향을 줄 수 있습니다. 따라서 적절한 보안 조치(예: 이미지 업데이트, 보안 패치 적용)를 취해야 합니다.
4. 이미지 크기: 도커 이미지는 애플리케이션과 그에 필요한 종속성을 포함하므로, 이미지 크기가 크고 디스크 공간을 차지할 수 있습니다. 특히 큰 규모의 애플리케이션의 경우 이미지 크기가 커지는 경향이 있습니다. 큰 이미지 크기는 이미지를 다운로드하거나 전송하는 데 시간이 오래 걸릴 수 있습니다.
5. 버전 관리: 도커 이미지의 버전 관리는 중요한 측면입니다. 이미지의 업데이트와 관리를 철저히 해야 합니다. 올바르지 않은 버전 관리는 호환성 문제를 야기할 수 있으며, 이미지의 불필요한 증가와 용량 낭비를 초래할 수 있습니다.
이러한 문제점과 단점은 도커를 사용할 때 고려해야 할 사항입니다. 적절한 관리와 보안 조치를 취하고, 성능 및 자원 사용에 대한 모니터링을 수행하여 도커를 효과적으로 활용할 수 있습니다.
2. 진행
타팀원이 진행했다.
☁️ 소감
Vue.js 프론트엔드 CI/CD를 위해 AWS EC2와 GitHub Action에 대해 자료를 찾아보고 공부했다. 그런데 시간적 여유와 다른 팀원과의 협업을 고려하여 내가 진행하진 못 했다. 아쉽긴 하지만 완성을 위해선 괜찮았다. 다음에 도전해보고 싶다.
'Data Engineering > grepp 데브코스 : 프로젝트' 카테고리의 다른 글
| 최종 팀플 (5) Vue.js (0) | 2024.05.14 |
|---|---|
| 최종 팀플 (4+) 디자인 링크 (0) | 2024.05.09 |
| Vue.js (3) 학습 내용 정리 (0) | 2024.05.07 |
| Vue.js (2) 프로젝트 진행 (0) | 2024.05.06 |
| Vue.js (1) 학습 자료, 기본 학습 (0) | 2024.05.03 |
