환경 이해
배포 워크플로를 사용하면 배포 프로세스의 단계를 자동화할 수 있습니다. 여러 개별 환경에서 단계를 실행해야 하는 경우가 있습니다. 완구 회사에서 프로덕션 환경에 변경 내용을 배포하기 전에 코드 변경 내용을 검토하려고 합니다.
이 단원에서는 GitHub Actions의 환경에서 고유한 프로세스를 지원하는 방법에 관해 알아봅니다.
여러 환경이 있는 이유는 무엇인가요?
배포 프로세스는 사용 중인 리소스를 포함한 Azure 리소스를 변경합니다. 리소스를 변경하면 배포하는 변경 내용이 예상과 다르게 작동할 수 있으므로 위험이 있습니다. 변경 내용으로 인해 현재 설정이 중단될 수도 있습니다.
문제가 발생할 위험을 최소화하려면 변경 내용을 프로덕션 환경에 배포하기 전에 안전한 방법으로 시험해 보는 것이 좋습니다. 위험을 최소화하려면 비프로덕션 환경에 변경 내용을 배포합니다.
많은 조직에서는 여러 비프로덕션 환경을 구축하여 변경 내용을 프로덕션 환경에 릴리스하기 전에 이러한 환경에 점진적으로 배포합니다. 각 비프로덕션 환경마다 수행하는 목적이 다르며, 특정 품질 기준을 충족해야 다음 환경으로 진행할 수 있습니다. 테스트 실패와 같은 문제가 발생 하면 배포가 중지됩니다. 배포가 각 환경을 따라 진행함에 따라 변경 사항에 대한 신뢰도가 증가합니다.
일반적인 환경은 다음과 같습니다.
개발: 개발 환경은 일반적으로 개발자가에서 변경 내용을 시험해 보고 작업을 빠르게 반복하는 데 사용됩니다.
개발 환경에는 팀 멤버가 아이디어를 쉽게 시험해 볼 수 있도록 최소의 컨트롤이 포함되어 있는 경우가 많습니다. 개발 환경을 사용하여 리소스에 대한 특정 구성 설정을 테스트하거나, 안전한 방식으로 백 엔드 데이터베이스를 사용하여 새 웹 사이트를 설정하는 방법을 확인할 수 있습니다. 성공하지 못한 아이디어가 제거되기 때문에 이러한 변경 내용과 평가판은 배포 프로세스에서 진행되지 않을 수 있습니다.
일부 팀에서는 팀원들이 새 기능에 대한 작업을 하는 동안 서로에게 방해가 되지 않도록 각 팀원마다 별도의 개발 환경을 설정할 수도 있습니다.
개발 환경을 샌드박스 환경이라고도 합니다.
테스트: 테스트 환경은 변경 내용에 대해 수동 또는 자동화된 테스트를 실행하도록 설계되었습니다.
연속 통합 프로세스에서 테스트 환경을 사용할 수 있습니다. 테스트 환경에 대한 변경 내용을 배포한 후 그에 대해 자동화된 테스트를 실행할 수 있습니다. 모든 자동화된 테스트에 통과하면 변경 내용을 프로젝트의 기본 분기에 통합할 수 있습니다. 자동화된 테스트는 일반적으로 새로 배포된 리소스의 정책 위반과 같은 항목과 함께 코어 시스템 기능을 점검합니다.
성능 및 보안 테스트와 같은 특정 유형의 테스트에 대한 테스트 전용 환경을 만들 수도 있습니다.
통합: 통합 환경에서는 다른 시스템과의 통합 지점을 테스트할 수 있습니다.
통합 환경에서 엔드투엔드 트랜잭션을 시뮬레이션할 수 있습니다. 이러한 테스트는 보통 자동으로 실행되지만 많은 조직에서는 이 환경에 대한 수동 테스트도 수행합니다.
통합 환경을 SIT(시스템 통합 테스트) 환경이라고도 합니다.
사용자 승인 테스트: UAT(사용자 승인 테스트) 환경은 수동 유효성 검사에 사용되며, 일반적으로 개발자가 아닌 비즈니스 관련자가 수행합니다. 수동 유효성 검사에서는 한 사람이 솔루션을 진행하고 예상대로 작동하는지 확인하고 필요한 비즈니스 요구 사항을 충족하는지 확인합니다. 그런 다음 배포를 계속할 수 있도록 변경 내용을 승인합니다.
사전 프로덕션: 사전 프로덕션 환경은 리소스 SKU 및 구성이 동일한 프로덕션 환경의 미러인 경우가 많습니다. 변경 내용이 적용되는 중과 그 후에 프로덕션 배포가 어떻게 동작하는지 확인 하기 위한 최종 검사로 사용됩니다. 프로덕션 배포 시 가동 중지 시간을 예측할 수 있는지 여부를 확인하는 데 사용할 수도 있습니다.
프로덕션 전의 환경을 ‘스테이징’ 환경이라고도 합니다.
프로덕션: 프로덕션 환경은 애플리케이션의 최종 사용자가 사용하는 환경입니다. 안전하게 보호하고 최대한 가동 및 실행하고자 하는 라이브 환경입니다.
일부 조직에는 프로덕션 환경이 여러 개 있을 수 있습니다. 예를 들어 여러 지리적 지역에 프로덕션 환경이 있거나 여러 고객 그룹에게 서비스를 제공하고 있을 수 있습니다.
데모: 팀이 최종 사용자에게 애플리케이션을 표시하거나, 교육에 사용하거나, 영업 팀이 잠재 고객에게 특정 기능을 표시하는 데모 환경을 만들 수도 있습니다. 각기 다른 용도로 사용되는 여러 데모 환경을 만들 수도 있습니다. 데모 환경은 일반적으로 가상의 고객 데이터를 포함하는 프로덕션 환경의 축소 복제본입니다.
조직의 환경
이러한 환경의 여러 변형이 있을 수 있습니다. 몇 가지 환경만 사용하는 조직도 있고, 훨씬 많은 환경을 사용하는 조직도 있습니다. 사용하는 환경의 수와 유형은 배포하는 솔루션, 솔루션을 빌드하는 팀의 규모, 워크 로드의 중요도에 따라 달라집니다.
하나의 환경이 앞에 나열된 여러 환경의 역할을 수행하는 경우도 있습니다. 일부는 동시에, 일부는 순차적으로 여러 환경에 배포하는 복잡한 워크플로가 있을 수 있습니다. 일부 조직에서는 더 이상 사용 되지않는 환경을 자동으로 삭제하거나 프로비저닝을 해제하고 나중에 필요할 때 다시 배포합니다.
조직이 환경 목록으로 선택하는 것과 관계없이, 배포 워크플로를 따라 진행되면서 변경 내용의 신뢰도를 높이는 것이 목표입니다. 변경 사항이 품질 요구 사항을 충족하지 않는 경우 해당 변경 사항을 체인 내 모든 후속 환경에 배포하는 작업을 중지할 수 있습니다.
완구 회사에서 웹 사이트에 대한 기본 환경 집합으로 시작하기로 결정했습니다. 프로덕션 환경 외에도 ‘Test’라는 비프로덕션 환경을 만듭니다.
Bicep 코드를 테스트 환경에 배포하고 이에 대한 몇 가지 기본 테스트를 실행하도록 워크플로를 업데이트합니다. 이 작업이 완료되면 프로덕션 환경에 배포할 수 있습니다.
워크플로 환경
GitHub Actions에도 환경의 개념이 있습니다. Azure에 보유한 환경을 나타내는 GitHub Actions 환경을 만듭니다. YAML 파일에서 워크플로를 정의할 때 특정 환경에 작업을 연결할 수 있습니다. 환경을 사용하여 워크플로에서 몇 가지 추가 기능을 가져옵니다.
보호 규칙
GitHub Actions의 환경에는 보호 규칙이 구성되어 있을 수 있습니다. 환경이 워크플로의 작업에서 사용될 때마다 GitHub Actions는 작업 실행이 시작되기 전에 이러한 규칙이 충족되었는지 확인합니다.
예를 들어 프로덕션 환경에서 수동 검토를 구성할 수 있습니다. 프로덕션 배포가 시작되기 전에 지정된 검토자에게 메일 알림이 전송됩니다. 승인자는 배포가 시작되기 전에 정책과 절차를 준수했는지 수동으로 확인할 수 있습니다. 예를 들어 승인자는 배포를 승인하기 전에 사전 프로덕션 환경에서 모든 것이 제대로 작동하는지 확인할 수 있습니다.
또한 자동화된 검사를 실행하여 변경 내용이 들어오는 분기를 확인할 수 있습니다. 변경 내용이 기본 분기에 없는 경우 프로덕션 환경에 배포되지 않도록 GitHub를 구성할 수 있습니다.
비밀
GitHub Actions를 사용하면 특정 환경에서만 사용할 수 있는 비밀을 저장할 수 있습니다. 이 모듈의 뒷부분에서 비밀 관리에 관해 자세히 알아봅니다.
배포 기록
GitHub Actions는 환경에 대한 배포 기록을 추적합니다. 이 기록을 통해 환경에서 시간이 지남에 따라 발생하는 상황을 쉽게 추적할 수 있습니다. 리포지토리의 커밋에 대한 배포를 추적할 수도 있습니다. 이 기능은 배포에 문제가 발생하여 문제를 일으킨 변경 사항을 파악해야 하는 경우에 유용할 수 있습니다.
환경 만들기
GitHub 웹 인터페이스를 사용하여 환경을 만들 수 있습니다.
워크플로가 존재하지 않는 환경을 참조하는 경우 GitHub Actions는 자동으로 워크플로를 만듭니다. 새 환경에는 보호 규칙이 구성되지 않으므로 이 기능은 GitHub 리포지토리의 보안에 영향을 줄 수 있습니다. 보안을 완전히 제어할 수 있도록 GitHub 웹 인터페이스를 통해 환경을 직접 만드는 것이 가장 좋습니다.
환경에 배포 작업 연결
배포 워크플로 정의에서 environment 속성을 사용하여 환경을 참조할 수 있습니다.
jobs:
deploy:
environment: Test
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
예제에서 deploy 작업은 Test 환경에 연결됩니다.
Azure에 대한 환경 및 연결
여러 환경을 사용 하는 경우 각 환경을 다른 환경과 독립적으로 만들어야 합니다. 예를 들어, 개발 환경의 웹 사이트는 프로덕션 환경 내에서 데이터베이스에 액세스할 수 없습니다.
동일한 워크플로가 배포 워크플로에도 적용됩니다. 각 환경에 대해 별도의 워크로드 ID를 만들어야 합니다. 이 사례에 따라 다른 보호 계층을 추가하여 비프로덕션 배포가 프로덕션 환경에 영향을 주지 않도록 합니다.
워크로드 ID에는 해당 환경에서 사용하는 구독 및 리소스 그룹에만 배포할 특정 권한이 할당되어야 합니다.
중요
배포하려는 각 환경에 대해 별도의 워크로드 ID를 사용합니다. 워크로드 ID에만 해당 환경에 배포하는 데 필요한 최소 권한을 부여합니다.
Azure에서 환경을 분리하는 것도 좋습니다. 최소한 각 환경마다 별도의 리소스 그룹을 만들어야 합니다. 대부분의 경우 각 환경마다 별도의 Azure 구독을 만드는 것이 좋습니다. 그러면 각 환경의 구독 내에서 여러 리소스 그룹을 만들 수 있습니다.
사용자와 워크로드 ID가 액세스해야 하는 환경에만 액세스할 수 있도록 Azure 역할 할당을 적용합니다. 그리고 프로덕션 환경에 대한 액세스를 소수의 사용자 및 해당 환경의 배포 워크로드 ID로 제한해야 합니다.
환경에 대한 페더레이션 자격 증명
워크로드 ID가 배포 워크플로에서 Azure에 연결되면 페더레이션 자격 증명을 사용하여 비밀이나 키 없이 안전하게 인증합니다. 이 학습 경로의 이전 모듈에서, 페더레이션 자격 증명은 Git 리포지토리의 기본 분기에서 배포할 때 배포 워크플로에 대한 액세스 권한을 부여했습니다.
워크플로 내의 환경에 배포하는 경우 해당 환경으로 범위가 지정된 페더레이션 자격 증명을 사용해야 합니다.
이 모듈에서 워크플로는 여러 작업을 포함하며, 그 중 상당수는 Azure에 연결하고 배포합니다. 일부 작업은 환경을 사용하며 일부는 그렇지 않습니다. 따라서 각 워크로드 ID에 대해 두 개의 페더레이션 자격 증명을 만듭니다. 하나는 환경으로 범위가 지정되고 다른 하나는 기본 분기로 범위가 지정됩니다.