소스 호스팅 툴 비교(CI-소스 관리 측면)
github vs aws codecommit
- 호스팅 및 가용성:
- AWS CodeCommit : AWS 인프라와 통합되어 있어서 다른 AWS 서비스와의 통합이 쉽습니다.
- 가격:
- AWS CodeCommit: AWS에서 제공하는 서비스 중 하나로, 요금 체계는 다른 AWS 서비스와 통합되어 있으며 사용한 리소스에 따라 청구된다.
- GitHub: 개인 사용자 및 오픈소스의 경우 완전 무료
- 통합:
- AWS CodeCommit: 다른 AWS 서비스와 통합이 쉽고, AWS Lambda, AWS CodePipeline, AWS CodeBuild 등을 사용하여 CI/CD 파이프라인을 설정할 수 있다. → 결국 AWS에 종속되어야한다.
- GitHub: 다양한 CI/CD 도구와 통합할 수 있으며, GitHub Actions를 사용하여 CI/CD 파이프라인을 설정할 수 있다.
- 보안:
- AWS CodeCommit: AWS의 보안 및 규정 준수 기능을 활용하여 코드를 안전하게 보호할 수 있으며, AWS Identity and Access Management (IAM)을 사용하여 액세스를 제어할 수 있다.
- GitHub: GitHub는 OAuth 및 투명한 보안 정책을 사용하여 보안을 강화하고, 레포지토리에 대한 액세스를 제어하는 권한 모델을 제공한다. → codecommit 보다 귀찮더라도 가능
- 커뮤니티:
- AWS CodeCommit: 주로 기업에서만 사용하기때문에 크게 활성화되어있지 않음
- GitHub: 개발자 및 오픈 소스 커뮤니티에 광범위하게 사용되며, 수많은 공개 및 비공개 프로젝트가 GitHub을 이용하고 있습니다.
- 기능:
- AWS CodeCommit의 경우 Github의 고급 기능은 사용할 수 없다.
간단 정리
| 통합의 편리성 | 가격 | 커뮤니티 활성화 | 소스 관리의 기능 측면 | |
| github | 편리하지 않으나 다른 Tool과 통합할 수 있음 | 개인, 오픈소스용 무료 | 최고! | 최고! |
| aws codecommit | AWS에 종속적 | 자체는 무료이나 사용한 aws 리소스에 대한 청구 | refer할게 많진 않은듯 | github의 고급 기능은 사용하지 못한다. |
내가 돈많은 다른 중소기업의 CI환경을 구축해주는거라면 aws codecommit을 고려해볼수도 있겠다.
배우는 입장인 나는 확장성이 좋은 github를
CI/CD Tool 비교
Jenkins vs Gitlab vs TeamCity
- Jenkins:
- 오픈 소스이다.
- 어떤 플랫폼에도, 어떤 빌드 타겟 환경에도 대응할 수 있다.
- 무료로 사용 가능하며 커뮤니티가 많이 활성화 되어있다.
- Jenkins는 초기 설정과 관리가 다소 복잡할 수 있으며, 스크립트 빌드 작업을 해야할 수도 있다.
- GitLab CI/CD:
- GitLab CI/CD는 GitLab 코드 저장소와 직접 통합된 내장 CI/CD 도구입니다.
- GitLab 코드 저장소와 CI/CD 파이프라인이 하나의 통합된 플랫폼에서 관리되므로 설정이 비교적 간단하다.
- GitLab의 프리미엄 및 엔터프라이즈 버전에서 추가적인 기능과 지원이 제공된다.
- CD
- TeamCity:
- Intellij를 서비스하는 JetBrains에서 개발했으며 UX,UI, 빌드환경 구성이 사용자 친화적이다.
- 무료 버전도 있으며 상용버전인 프로페셔널 버전이 100개의 빌드, 빌드에이전트가 3개이하는 상업용으로 사용해도 무료이다.
찾아본 결과 Jenkins의 유연성과 확장성이 맘에들어 slow beginning learning curve의 특성을 가진 것 같지만 Jenkins를
TeamCity라는 CI 툴의 존재를 알게된 값진 서칭 시간이였다. TeamCity의 경우도 고려해볼 수 있긴 하겠다.
배포 관련 Tool 비교
CI/CD 툴, 예를들어 젠킨스가 자동 빌드를 해주면 그것을 배포하는 Tool이 필요한데, 도커도커도커 도커가사용된다.
사실 도커를 대신할 Tool을 찾아 장단점을 비교하는 것은 어리석다는 생각이 들어서 도커와 도커 허브를 비교하고, 쿠버네티스를 채택할지 말지에 대한 의사결정을 해보려한다.
도커 vs 도커허브
도커
도커는 기본적으로 애플리케이션(웹앱 등)과 해당 애플리케이션이 실행되기위한 환경과 라이브러리 종속성 등을 컨테이너로 패키징하여 배포할 수 있도록 도와준다.
도커 허브
도커 허브는 이렇게 컨테이너화된 이미지를 다른 환경, 혹은 팀원과 공유하기 편하도록 설계되어있으며, 이미지의 버전관리, 환경별 다른 버전 배포가 가능하다.
컨테이너란?
도커에 대해서 알아보는 도중 여기서 잠깐 컨테이너라는 개념에 대해서 찾아보고 학습했다. 컨테이너란 애플리케이션과 해당 종속성을 하나의 패키지로 묶어서 효율적으로 실행, 이동 및 관리할 수 있도록 묶은 이미지이다. aws의 AMI와 비슷한 개념이라는 생각이 들었다. 컨테이너의 특징을 알아보
독립성
컨테이너 별로 독립적이고 환경적인 요소가 컨테이너 밖과 격리되어 있어 애플리케이션 빌드를 준비하는 시간을 줄일 수 있다.
이식성
앱과 모든 종속성을 포함하고 있어 어떤 환경에서든 앱이 실행될 수 있도록 한다.
개발 환경, 테스트 환경, 스테이징 환경 및 프로덕션 환경 간의 이동이 간편하다.
경량화
컨테이너는 가상 머신(Virtual Machine, VM)과 비교하여 상대적으로 가벼우며, 호스트 시스템과 리소스를 효율적으로 공유할 수 있다.
회사다닐 적에 Virtual Box를 사용해서 리눅스 서버, 윈도우 클라이언트, 내 본체 OS에서 어댑터를 서버와 클라이언트 사이에 붙이는 작업을 진행했는데, 컴퓨터가 아무리좋아도 느려지긴 하더라.. VM 싫어!
도커 vs 도커 허브 결과는?
플랫폼 별로 다른 배포 버전이 필요하거나 플랫폼별로 개발되는 속도와 버전이 상이한 경우 무조건 도커허브를 사용해야 할 것 같다.
나의 경우는 도커만으로도 충분하겠지만 도커가 더 유리한건 설정 속도밖에 없어보이니까
학습을 위해서 도커허브를
쿠버네티스를 사용해야할까?
kubernetis : 컨테이너 오케스트레이션 및 관리 플랫폼으로, 여러 개의 컨테이너를 효율적으로 배포, 확장, 관리하고 자동으로 관리할 수 있도록 하는 도구이다.
(사람들이 k8s라고 부르는데 왜냐하면 KubernetiS 에서 K,S 빼고 uberneti 글자수가 8개라서 그렇단다.. 얼척없어)
여러 환경간에 앱 배포의 일관성을 유지할 수 있도록 돕고, 트래픽 변동에 대비하는 스케일링을 적용하기 용이하다. 즉 고가용성 구현 및 로드 밸런싱에 용이하다. (aws 공부할때 봤던 개념이라 반갑네)
쉽게 얘기하면 버전별, 플랫폼별 각각의 배포를 하는 상황에서 관리상의 이점이 생긴다.
또, 트래픽 부하를 알아서 해결해주기위해 트래픽 분산 알고리즘, cpu 사용량에 따른 서버 가용영역의 증감을 알아서 해주겠다는 뜻 (물론 설정해줘야겠지만!)
나의 경우는 우선 단일 컨테이너 만 사용해서 배포할거니까 현재 쿠버네티스를 고려할 필요는 없어보인다.
필요하다거나 학습을 위해 나중에 고려하기로 결정 쿠버네티스는...
Github - Jenkins - Docker Hub 로 배포적 자유를 일궈보자!
