Kanji
・클라우드 엔지니어 / 프리랜서 ・1993년생 ・에히메현 출신 / 도쿄도 시부야구 거주 ・AWS 경력 5년 프로필 상세
목차
공식 사용자 가이드에 따르면 AWS CodePipeline은 다음과 같이 정의됩니다.
<인용문> AWS CodePipeline은 소프트웨어를 출시하는 데 필요한 단계를 모델링, 시각화 및 자동화하는 데 사용할 수 있는 지속적인 전달 서비스입니다. 소프트웨어 릴리스 프로세스의 다양한 단계를 빠르게 모델링하고 구성할 수 있습니다. CodePipeline은 소프트웨어 변경 사항을 지속적으로 릴리스하는 데 필요한 단계를 자동화합니다.
출처: AWS CodePipeline이란 무엇입니까?- AWS CodePipeline
공식 사용자 가이드에 따르면 AWS CodeCommit은 다음과 같이 정의됩니다.
<인용문> AWS CodeCommit은 자산을 비공개로 저장하고 관리하는 데 사용할 수 있는 Amazon Web Services에서 호스팅하는 버전 제어 서비스입니다. (문서, 소스 코드, 바이너리 파일 등)을 클라우드에 저장합니다.
출처: AWS CodeCommit이란 무엇입니까?- AWS CodeCommit
공식 사용자 가이드에 따르면 AWS CodeBuild는 다음과 같이 정의됩니다.
<인용문> AWS CodeBuild는 클라우드의 완전 관리형 빌드 서비스입니다. CodeBuild는 소스 코드를 컴파일하고, 단위 테스트를 실행하고, 배포할 준비가 된 아티팩트를 생성합니다. CodeBuild를 사용하면 자체 빌드 서버를 프로비저닝, 관리 및 확장할 필요가 없습니다. 널리 사용되는 프로그래밍 언어와 Apache Maven, Gradle 등과 같은 빌드 도구를 위한 사전 패키지된 빌드 환경을 제공합니다. CodeBuild에서 빌드 환경을 사용자 지정하여 자체 빌드 도구를 사용할 수도 있습니다.CodeBuild는 최대 빌드 요청을 충족하도록 자동으로 확장됩니다.
출처: AWS CodeBuild란 무엇입니까?- AWS CodeBuild
공식 사용자 가이드에 따르면 AWS CodeDeploy는 다음과 같이 정의됩니다.
<인용문> CodeDeploy는 Amazon EC2 인스턴스, 온프레미스 인스턴스, 서버리스 Lambda 함수 또는 Amazon ECS 서비스에 대한 애플리케이션 배포를 자동화하는 배포 서비스입니다.
다음을 포함하여 거의 무제한에 가까운 다양한 애플리케이션 콘텐츠를 배포할 수 있습니다.
출처: CodeDeploy란 무엇입니까?- AWS CodeDeploy
공식 홈페이지에 따르면 GitHub는 다음과 같이 정의되어 있습니다.
<인용문> GitHub는 사용자의 아이디어에서 영감을 얻은 개발 플랫폼입니다.GitHub에 소스 코드를 호스팅함으로써, 오픈 소스 프로젝트부터 비즈니스 용도에 이르기까지 수백만 명의 다른 개발자와 함께 코드를 검토하고, 프로젝트를 관리하고, 소프트웨어를 함께 개발할 수 있습니다.
출처: GitHub Japan |GitHub
CI/CD 파이프라인으로 관리되는 리소스의 후보에는 애플리케이션 소스 코드, 코드형 인프라(IaC), 애플리케이션 구축 및 배포에 필요한 구성 파일이 포함됩니다.이러한 리소스를 사용하여 배포된 애플리케이션과 인프라는 개발뿐만 아니라 운영 중에도 CI/CD 파이프라인을 통해 코드로 관리되어야 합니다.개발자와 운영자의 기술과 운영을 고려하여 CI/CD 파이프라인에서 관리하는 리소스를 코드로 관리할 수 있는지 고려하세요.예를 들어 CI/CD 파이프라인 관리에서 다음 사례를 제외하는 것이 좋습니다.
CI/CD 파이프라인으로 관리되는 코드 리소스는 AWS CodeCommit 또는 GitHub와 같은 리포지토리 서비스에서 관리됩니다.AWS CodeCommit, AWS CodePipeline, AWS CodeBuild, AWS CodeDeploy는 AWS에서 제공하는 서비스로, 기존에 코드 리소스 관리를 위한 리포지토리 서비스가 없는 경우 AWS CodeCommit이 첫 번째 후보가 됩니다.그러나 아래와 같이 AWS CodeCommit은 2024년 7월 25일부터 신규 고객 수락을 중단합니다.
<인용문> 신중한 검토 끝에 2024년 7월 25일부터 AWS CodeCommit 신규 고객 접수를 중단하기로 결정했습니다. AWS CodeCommit을 사용하는 기존 고객은 평소와 같이 서비스를 계속 사용할 수 있습니다.AWS는 AWS CodeCommit의 보안, 가용성 및 성능에 계속 투자할 예정이지만 새로운 기능을 도입할 계획은 없습니다.
출처(일본어 번역): AWS CodeCommit 리포지토리를 다른 Git 공급자로 마이그레이션하는 방법 |AWS DevOps 및 개발자 생산성 블로그
향후 AWS CodeCommit을 언제 사용할 수 없게 될지는 불확실하므로 아직 AWS CodeCommit을 사용하고 있지 않다면 다른 리포지토리 서비스를 통해 코드 리소스를 관리하는 것이 좋습니다.데이터베이스에 비해 마이그레이션 난이도는 그리 높지 않지만, 한 서비스를 사용하기 시작하면 다른 서비스로 마이그레이션하기 어려울 수 있습니다.내부 규칙, 사용 가능한 기능, 보안 요구 사항 및 향후 전망을 고려하여 신중하게 서비스를 선택하십시오.
CI/CD 파이프라인을 사용하여 동일한 코드가 여러 환경이나 리소스에 배포되는 경우가 있습니다.
이러한 문제를 해결하기 위해 다음과 같은 방법을 사용할 수 있습니다.
각 방법은 아래에 설명되어 있습니다.
GitHub Flow 또는 git-flow와 같은 브랜치 전략을 채택하면 개발, 스테이징, 프로덕션 등 여러 환경에 대해 서로 다른 브랜치를 사용할 수 있습니다.예를 들어 프로덕션용 기본 분기, 스테이징용 개발 분기, 개발용 기능 분기를 사용할 수 있습니다.이 경우 각 브랜치에 대한 업데이트로 트리거된 CI/CD 파이프라인을 실행하고 각 환경에 배포할 수 있습니다.기능 분기는 개발자가 자유롭게 이름을 지정하고 사용할 수 있으므로 CI/CD 파이프라인의 동적 실행이 필요합니다.예를 들어 AWS Prescriptive Guidance에는 다음 패턴이 도입되었습니다.
AWS Service Catalog 및 AWS CodePipeline을 사용하여 Gitflow 환경에 핫픽스 솔루션을 배포하기 위한 동적 파이프라인 관리 자동화 - AWS 규정 지침
브랜치의 내용을 확인하면 어떤 코드가 어떤 환경에 배포되었는지 쉽게 알 수 있다는 장점이 있습니다.
단점은 브랜치가 늘어날수록 CI/CD 파이프라인도 늘어나 관리가 복잡해진다는 점이다.또한 브랜치 흐름이 복잡해지는 경향이 있기 때문에 Git 숙련도가 낮은 개발자에게는 브랜치 관리가 어려울 수 있습니다.
이 방법은 단일 분기를 사용하여 여러 환경이나 리소스에 배포합니다.예를 들어, 메인 브랜치가 업데이트되면 동일한 코드를 개발, 스테이징, 프로덕션 환경에 한꺼번에 배포할 수 있습니다.
장점은 브랜치 수가 줄어들어 CI/CD 파이프라인 관리가 더 쉬워진다는 것입니다.
단점은 동일한 코드가 모든 환경에 한꺼번에 배포되기 때문에 스테이징 및 프로덕션에 배포하기 전에 테스트를 위해 개발 환경에 배포하는 등의 단계적 배포를 수행하기 어렵다는 점입니다.
애플리케이션 자원보다는 보안이나 모니터링 서비스 등의 인프라 자원을 배치할 때 이 방법을 사용하는 것이 좋습니다.
이 방법은 수동 작업을 사용하여 빌드/배포 아티팩트를 재사용하고 여러 환경 또는 리소스에 배포합니다.예를 들어 개발 환경에 배포된 애플리케이션의 빌드 아티팩트를 재사용하고 이를 스테이징 또는 프로덕션 환경에 배포할 수 있습니다.이 방법을 사용하면 CI/CD 파이프라인을 실행한 후 작업을 수동으로 실행하여 필요한 환경이나 리소스에 배포할 수 있습니다.
장점은 빌드/배포 아티팩트를 재사용하여 동일한 코드를 여러 환경이나 리소스에 배포할 수 있다는 것입니다.또한 작업을 동시에 실행하는 데 필요한 만큼만 CI/CD 파이프라인을 준비하면 되므로 CI/CD 파이프라인 수를 줄일 수 있습니다.
단점은 CI/CD 파이프라인을 실행하고 빌드/배포 아티팩트를 생성한 후 작업을 수동으로 실행해야 하므로 단계적 배포에 필요한 작업량이 늘어날 수 있다는 것입니다.
CI/CD 파이프라인 메커니즘을 얼마나 구축하느냐에 따라 매우 다양한 CI/CD 파이프라인을 구축할 수 있습니다.
CI/CD 파이프라인에서 리소스를 관리하는 데 사용되는 주요 도구는 다음과 같습니다.
이러한 배포 및 빌드/정적 분석 도구를 사용하면 CI/CD 파이프라인에서 관리하는 리소스에 대해 배포, 빌드 및 정적 분석을 수행할 수 있습니다.
참고: 이러한 도구가 빌드/배포 프로세스를 자동화한다고 해서 도구를 배울 필요가 없다는 의미는 아닙니다. 운영 중 매개변수 파일을 변경하는 절차를 수립하면 도구 학습 비용을 줄일 수 있지만, 개발 중에는 단순히 CI/CD 파이프라인을 통해서가 아닌 문제 해결을 위해 자체 환경에서 빌드/배포해야 할 수도 있으므로 도구에 대한 학습이 필요합니다.개발자의 기술 세트와 운영 요구 사항을 고려하여 CI/CD 파이프라인에서 사용할 도구를 선택합니다.
도구가 결정되면 CI/CD 파이프라인의 단계를 고려하세요.
단계를 고려하는 방법은 준비 중입니다.
CI/CD 파이프라인에 사용할 도구가 결정되면 해당 도구에서 관리하는 리소스, 해당 관리자 및 배포 대상을 결정합니다.예를 들어 AWS CLI(CloudFormation)를 사용하여 AWS 리소스를 배포하는 경우 다음과 같이 구성합니다.
구성할 때 어느 팀이 어떤 리소스를 관리하고 어디에 배포하는지 명확히 하는 것이 중요합니다.각 관리 리소스에 대해 다음 섹션 “4. 저장소 분할 단위”에서 이를 관리할 저장소를 고려하세요.
CI/CD 파이프라인에서 관리하는 리소스를 코드 저장소로 분할하는 방법을 고려하세요.세분화 관점에는 다음이 포함됩니다.
기본적으로 “1. 기능”으로 세분화하면 “2. 관리자”와 “4. 라이프사이클”로 동시에 세분화할 수도 있습니다.필요한 경우 “1. 기능” 내에서 “4. 라이프사이클”을 더 세분화하는 것을 고려해보세요.예를 들어, 네트워크 방화벽을 세분화할 때 초기 구축 시에만 배포되는 리소스와 운영 시 배포되는 리소스로 나누어 방화벽 자체가 삭제되는 위험을 방지할 수 있습니다.여기에서는 “관리 리소스”를 더 자세히 구성합니다.
“3. 배포 대상”은 앞서 설명한 “1. 여러 환경/리소스에 배포하는 방법”의 결과를 기반으로 분할하는 방법을 고려합니다.예를 들어 GuardDuty의 경우 다음과 같이 공유 계정과 각 환경 계정별로 분류할 수 있습니다.
분할된 각 코드 저장소에 대한 CI/CD 파이프라인을 구축할 때 각 CI/CD 파이프라인에 대한 권한을 설정합니다.먼저 각 관리자에게 부여할 수 없는 권한을 구성한 다음 권한을 추가로 제한하는 것을 고려하세요.예를 들어 플랫폼팀, 개발팀, 운영팀 3개의 팀이 있는 경우 다음과 같이 권한을 설정할 수 있습니다.
CI/CD 파이프라인 권한을 너무 세밀하게 제한하지 않는 것이 중요합니다.권한을 너무 많이 제한하면 CI/CD 파이프라인에 실행하는 데 필요한 권한이 부족하여 배포가 실패할 수 있습니다.또한 풀 요청이나 승인 단계를 통해 CI/CD 파이프라인 자체의 실행을 제한할 수 있으므로 내부 사기에 대한 대책으로 권한을 엄격하게 제한하는 것은 권장되지 않습니다.제한하는 경우 다음 AWS 관리형 정책을 사용하여 필요한 권한을 부여하는 것이 좋습니다.
AWS 관리형 정책 - AWS 관리형 정책