스토리지 및 데이터베이스 구성
배포 프로세스의 일부로 데이터베이스 또는 스토리지 서비스에 연결해야 하는 경우가 많습니다. 이 연결은 데이터베이스 스키마를 적용하거나, 데이터베이스 테이블에 일부 참조 데이터를 추가하거나, 일부 Blob을 업로드하는 데 필요할 수 있습니다. 본 단원에서는 데이터 및 스토리지 서비스를 사용할 수 있도록 워크플로를 확장하는 방법에 대해 알아봅니다.
워크플로에서 데이터베이스 구성
많은 데이터베이스에는 데이터베이스에 포함된 데이터의 구조를 나타내는 ‘스키마’가있습니다. 배포 워크플로에서 데이터베이스에 스키마를 적용하는 것이 좋습니다. 이 방법은 솔루션에 필요한 모든 것이 함께 배포되도록 할 수 있습니다. 또한 스키마를 적용할 때 문제가 있는 경우 워크플로에 오류가 표시되므로 문제를 해결하고 다시 배포할 수 있습니다.
Azure SQL을 사용하는 경우 데이터베이스 서버에 연결하고 SQL 스크립트를 통해 명령을 실행하여 데이터베이스 스키마를 적용해야 합니다. 이러한 명령은 데이터 평면 작업입니다. 워크플로는 데이터베이스 서버에 인증한 다음 스크립트를 실행해야 합니다. GitHub Actions는 Azure SQL 데이터베이스 서버에 연결하고 명령을 실행할 수 있는 azure/sql-action 작업을 제공합니다.
일부 다른 데이터 및 스토리지 서비스는 데이터 플레인 API를 사용하여 구성할 필요가 없습니다. 예를 들어 Azure Cosmos DB로 작업하는 경우 ‘컨테이너’에 데이터를 저장합니다. Bicep 파일 내에서 바로 컨트롤 플레인을 사용하여 컨테이너를 구성할 수 있습니다. 마찬가지로 Bicep 내에서 Azure Storage BLOB 컨테이너의 측면 대부분을 배포하고 관리할 수도 있습니다. 다음 연습에서는 Bicep에서 BLOB 컨테이너를 만드는 방법의 예제를 확인할 수 있습니다.
데이터 추가
많은 솔루션은 데이터베이스 또는 스토리지 계정에 참조 데이터를 추가해야 작동합니다. 워크플로에서 이 데이터를 추가하는 것이 좋습니다. 즉, 워크플로가 실행된 후 환경이 완전히 구성되어 사용할 준비가 된 것입니다.
특히 비프로덕션 환경의 경우 데이터베이스에 샘플 데이터를 두는 것도 유용합니다. 샘플 데이터를 통해 테스터와 해당 환경을 사용하는 다른 사람들이 솔루션을 즉시 테스트할 수 있습니다. 이 데이터에는 샘플 제품 또는 가짜 사용자 계정과 같은 데이터가 포함될 수 있습니다. 일반적으로 프로덕션 환경에 이러한 데이터를 추가하지 않는 것이 좋습니다.
데이터를 추가하는 데 사용하는 방식은 사용하는 서비스에 따라 달라집니다. 다음은 그 예입니다.
- Azure SQL 데이터베이스에 데이터를 추가하려면 스키마 구성과 마찬가지로 스크립트를 실행해야 합니다.
- Azure Cosmos DB에 데이터를 삽입해야 하는 경우 일부 사용자 지정 스크립트 코드를 작성해야 할 수 있는 데이터 플레인 API에 액세스해야 합니다.
- Blob을 Azure Storage Blob 컨테이너에 업로드하려면 AzCopy 명령줄 애플리케이션, Azure PowerShell 또는 Azure CLI를 비롯한 워크플로 스크립트의 다양한 도구를 사용할 수 있습니다. 이러한 각 도구는 자동으로 Azure Storage에 대해 인증하는 방법과 데이터 플레인 API에 연결하여 BLOB를 업로드하는 방법을 파악합니다.
Idempotence
배포 워크플로 및 코드형 인프라의 특성 중 하나는 부작용 없이 반복적으로 재배포할 수 있어야 한다는 것입니다. 예를 들어 이미 배포한 Bicep 파일을 재배포하는 경우 Azure Resource Manager는 제출한 파일을 Azure 리소스의 기존 상태와 비교합니다. 변경 내용이 없으면 Resource Manager는 아무 작업도 수행하지 않습니다. 작업을 반복적으로 재실행하는 기능을 ‘Idempotence’라고 합니다. 스크립트 및 기타 워크플로 단계가 멱등원인지 확인하는 것이 좋습니다.
데이터 서비스는 상태를 유지하기 때문에 Idempotence는 데이터 서비스와 상호 작용할 때 특히 중요합니다. 워크플로에서 데이터베이스 테이블에 샘플 사용자를 삽입한다고 가정해 보겠습니다. 주의하지 않으면 워크플로를 실행할 때마다 새로운 샘플 사용자가 만들어집니다. 이 결과는 원하는 것이 아닐 수 있습니다.
Azure SQL 데이터베이스에 스키마를 적용할 때 DACPAC 파일이라고도 하는 데이터 패키지를 사용하여 스키마를 배포할 수 있습니다. 워크플로는 소스 코드에서 DACPAC 파일을 빌드하고 애플리케이션과 마찬가지로 워크플로 아티팩트를 만듭니다. 그런 다음 워크플로의 배포 단계에서 DACPAC 파일을 데이터베이스에 게시합니다.
DACPAC 파일이 배포되면 데이터베이스의 대상 상태를 패키지에 정의된 상태와 비교하여 Idempotence 방식으로 작동합니다. 대부분의 경우 도구가 자동으로 처리하므로 Idempotence 원칙을 따르는 스크립트를 작성할 필요가 없습니다. Azure Cosmos DB 및 Azure Storage의 일부 도구도 올바르게 작동합니다.
그러나 Azure SQL 데이터베이스 또는 Idempotence 방식으로 자동으로 작동하지 않는 다른 스토리지 서비스에서 샘플 데이터를 만들 때는 데이터가 이미 존재하지 않는 경우에만 데이터를 만들도록 스크립트를 작성하는 것이 좋습니다.
이전 버전의 배포 워크플로를 재실행하는 등의 방식으로 배포를 롤백해야 하는지 여부도 고려해야 합니다. 데이터를 롤백하는 것은 복잡해질 수 있으므로 롤백을 허용해야 하는 경우 솔루션이 어떻게 작동할지 신중하게 고려합니다.
네트워크 보안
경우에 따라 일부 Azure 리소스에 네트워크 제한을 적용할 수 있습니다. 이러한 제한은 다음과 같이 리소스의 데이터 플레인에 대한 요청에 대한 규칙을 시행할 수 있습니다.
- 이 데이터베이스 서버는 지정된 IP 주소 목록에서만 액세스할 수 있습니다.
- 이 스토리지 계정은 특정 가상 네트워크 내에 배포된 리소스에서만 액세스할 수 있습니다.
데이터베이스 서버에 연결하기 위해 인터넷에 아무 것도 필요하지 않은 것처럼 보일 수 있으므로 네트워크 제한은 데이터베이스에서 많이 사용됩니다.
그러나 네트워크 제한으로 인해 배포 워크플로가 리소스의 데이터 평면에서도 작동하기 어려울 수 있습니다. GitHub 호스팅 실행기를 사용하는 경우 해당 IP 주소를 미리 쉽게 알 수 없어 대규모 IP 주소 풀에서 할당될 수 있습니다. 또한 GitHub 호스팅 실행기는 사용자 고유의 가상 네트워크에 연결할 수 없습니다.
데이터 평면 작업을 수행하는 데 도움이 되는 작업 중 일부를 통해 이러한 문제를 해결할 수 있습니다. 예를 들어 azure/sql-action 작업은 다음과 같습니다.
azure/sql-action 작업을 사용하여 Azure SQL 논리 서버 또는 데이터베이스로 작업하는 경우 워크로드 ID
를 사용하여 Azure SQL 논리 서버의 컨트롤 플레인에 연결합니다. 실행기가 IP 주소에서 서버에 액세스할 수 있도록 방화벽을 업데이트합니다(
). 그러면 실행을 위해 DACPAC 파일 또는 스크립트를 성공적으로 제출할 수 있습니다(
). 그런 다음 작업이 완료되면 방화벽 규칙이 자동으로 제거됩니다.
다른 상황에서는 이와 같은 예외를 만들 수 없습니다. 이러한 상황에서는 가상 머신 또는 제어하는 다른 컴퓨팅 리소스에서 실행되는 자체 호스팅 실행기를 사용하는 것이 좋습니다. 필요한 방식으로 이 실행기를 구성할 수 있습니다. 알려진 IP 주소를 사용할 수도 있고, 사용자의 가상 네트워크에 연결할 수도 있습니다. 이 모듈에서는 자체 호스팅 실행기에 관해 토론하지 않지만, 모듈의 요약 페이지에서 자세한 정보에 대한 링크를 제공합니다.
배포 워크플로
다음 연습에서는 배포 워크플로를 업데이트하여 새 작업을 추가하면서 웹 사이트의 데이터베이스 구성 요소를 빌드하고, 데이터베이스를 배포하고, 시드 데이터를 추가합니다.
