Azure Automation 이해
Azure에는 프로세스를 자동화하는 여러 방법이 있습니다. Azure Functions와 Logic Apps는 모두 서버리스 워크로드를 사용하는 Azure 서비스입니다. 두 서비스 모두 복잡한 작업을 실행하는 단계의 컬렉션인 워크플로를 생성합니다. 예를 들어 SharePoint 목록에 항목을 만들 때 Azure SQL Database의 테이블을 채우도록 논리 앱을 만들 수 있습니다. 이러한 서비스에 대한 자세한 설명은 이 과정의 범위를 벗어납니다.
자동화를 더 완벽하게 제어하고 세분화하기 위해 Azure Automation에서는 프로세스 자동화, 구성 관리, Azure 플랫폼 옵션(예: 역할 기반 액세스 제어 및 Microsoft Entra ID)과의 완전한 통합을 허용하고 Azure 및 온-프레미스 리소스를 관리할 수 있습니다.
Azure Automation의 고유한 이점 중 하나는 Azure 또는 온-프레미스 VM에서 리소스를 관리할 수 있다는 것입니다. 예를 들어 비용 절감을 위해 사용해야 하는 경우를 제외하고는 일반적으로 VM이 다운 상태로 유지되는 경우 하이브리드 Runbook 이라는 기능을 사용하여 VM을 시작하는 스크립트를 실행하고, VM에서 SQL Server 백업을 시작하며, 마지막으로 VM을 종료하는 기능이 Azure Automation에 있습니다.
또 다른 일반적인 시나리오는 부실 데이터 또는 오래된 데이터를 제거하거나 SQL 데이터베이스를 다시 인덱싱하는 등 주기적인 유지 관리 작업에 Azure Automation을 사용하는 것입니다.
Azure Automation 구성 요소
Azure Automation에서는 자동화 및 구성 관리 활동을 모두 지원합니다. 여기서는 자동화 구성 요소를 중점적으로 살펴보지만, Automation을 사용하여 서버 업데이트 및 필요한 상태 구성을 관리할 수도 있습니다. 자동화된 작업을 실행하는 데 사용해야 하는 Azure Automation의 구성 요소는 다음과 같습니다.
Runbook - Runbook은 Azure Automation의 실행 단위입니다. Runbook은 PowerShell, PowerShell 스크립트 또는 Python 스크립트를 기반으로 하는 그래픽 runbook 이라는 세 가지 유형 중 하나로 정의할 수 있습니다. PowerShell runbook은 Azure SQL 리소스를 관리하는 데 가장 일반적으로 사용됩니다.
모듈 - Azure Automation에서는 runbook에서 실행 중인 PowerShell 또는 Python 코드의 실행 컨텍스트를 정의합니다. 코드를 실행하려면 지원 모듈을 가져와야 합니다. 예를 들어
Get-AzSqlDatabasePowerShell cmdlet을 실행해야 하는 경우 Az.SQL PowerShell 모듈을 Automation 계정에 가져와야 합니다.자격 증명 - 런타임 시 Runbook 및 구성에서 사용할 수 있는 중요한 정보를 안전하게 저장합니다.
일정 - 일정은 runbook에 연결되고 특정 시간에 runbook을 트리거합니다.
Azure policy
그룹 정책 또는 GPO는 보안을 관리하고 조직의 Windows Server 환경에서 일관성을 제공하기 위해 오랜 기간 동안 Windows 서버 관리자가 사용해 왔습니다. 그룹 정책의 몇 가지 예로는 암호 복잡성 강제 적용, 공유 네트워크 드라이브 매핑 및 네트워크 프린터 구성 등이 있습니다.
Azure Policy에는 Automation 계정에 대한 다양한 보안 표준을 준수하도록 설정하고 유지하는 데 도움이 되는 이니셔티브 정의가 포함되어 있습니다. Azure Resource Manager에서도 유사한 기능을 사용할 수 있습니다. 이 정책에는 Azure 구독에 관한 거버넌스 수준이 있습니다. 정책은 Azure 리소스에 대한 규칙과 제어를 강제 적용할 수 있습니다. 이를 사용하는 방법에 대한 몇 가지 예로는 리소스를 배포할 수 있는 영역 제한, 명명 표준 강제 적용 또는 리소스 크기 컨트롤 등이 있습니다. Azure에서는 사용할 수 있는 많은 예제 정책을 제공하거나 JSON을 사용하여 사용자 지정 정책을 정의할 수 있습니다.
정책은 관리 그룹(함께 관리되는 구독 그룹), 구독, 리소스 그룹 또는 개별 리소스와 같은 특정 범위로 할당됩니다. 가장 일반적인 정책은 구독 또는 리소스 그룹 수준에서 적용됩니다. 간혹 정책 세트라고도 하는 이니셔티브라는 구조를 사용하여 개별 정책을 그룹화할 수 있습니다. 정책에는 개별 리소스, 리소스 그룹, 구독 또는 관리 그룹(함께 관리되는 구독 그룹) 또는 지정된 테넌트의 모든 구독에서 정의할 수 있는 할당 범위가 있습니다.
Azure Policy를 구현하는 방법의 또 다른 예로는 리소스 태깅이 있습니다. 아래에 설명된 Azure 태그는 키-값 쌍으로 된 Azure 리소스에 대한 메타데이터를 저장하고, 지정된 리소스의 환경 유형(테스트, QA 또는 프로덕션)이나 비용 센터를 강조 표시하는 데 일반적으로 사용됩니다. 모든 리소스에 환경 및 비용 센터에 대한 태그를 요구하는 정책은 오류를 초래하고 필요한 태그가 없는 Azure 리소스의 배포를 차단합니다.
Azure 구독 및 태그
조직은 예산 관리, 보안 또는 리소스 격리를 비롯한 여러 이유로 다양한 구독을 사용합니다. 한 가지 예로 내부 및 고객 연결 리소스가 모두 있는 조직이 있습니다. 내부 리소스는 한 구독에 있고 고객 리소스는 다른 구독에 존재할 수 있으므로 청구를 쉽게 분리하고 내부 리소스를 격리할 수 있습니다. 이러한 구독은 관리 그룹에서 함께 관리할 수 있습니다. 관리 그룹을 사용하면 구독 간에 정책 및 규정 준수를 관리할 수 있습니다.
태그는 Azure 리소스를 더 명확하게 설명하기 위해 사용되는 메타데이터일 뿐입니다. 이러한 태그는 key:value 쌍으로 저장되며 Azure 리소스와 연관된 Azure Portal에 표시됩니다. 태그는 리소스와 연결되어 있으므로 PowerShell 또는 Azure CLI 명령을 사용하는 경우 태그를 기준으로 명령을 필터링할 수 있습니다. 따라서 SQL 쿼리의 WHERE 절과 같이 생각할 수 있습니다. 기본 예제는 다음과 같습니다.
$rg=(get-AzResourceGroup)
$rg=($rg|where-object {($_.tags['Use'] -ne 'Internal')}).ResourceGroupName
이 코드 샘플의 두 번째 줄에서 'Use'라는 태그를 기준으로 리소스 그룹 목록이 필터링되고 해당 태그에 'Internal' 값이 없는 리소스 그룹만 반환됨을 확인할 수 있습니다. 태그는 Azure Portal에서 적용하거나 PowerShell, Azure CLI 또는 배포 프로세스의 일부로 프로그래밍 방식으로 적용할 수 있습니다. 태그는 구독, 리소스 그룹 또는 개별 리소스 수준에서도 적용할 수 있습니다. 태그는 언제든지 수정할 수 있습니다. Azure에서는 Azure 리소스마다 최대 15개의 태그를 적용하도록 지원합니다.
태그는 Azure 청구 정보에도 포함되어 있으므로 비용 센터별로 태그를 지정하면 관리에서 Azure 요금을 훨씬 더 쉽게 세분화할 수 있습니다. 태그는 모든 Azure 리소스의 블레이드의 개요 섹션에 있습니다. Azure Portal을 사용하여 리소스에 태그를 추가하려면 태그를 선택하고 태그의 키와 값을 입력합니다. 리소스에 태그를 적용한 후 저장을 선택합니다.
PowerShell 또는 CLI도 사용하여 태그를 추가할 수 있습니다. 다음은 PowerShell 예입니다.
$tags = @{"Dept"="Finance"; "Status"="Normal"}
$resource = Get-AzResource -Name demoStorage -ResourceGroup demoGroup
New-AzTag -ResourceId $resource.id -Tag $tags
다음은 Azure CLI 예입니다.
az resource tag --tags 'Dept=IT' 'Environment=Test' -g examplegroup -n examplevnet `
--resource-type "Microsoft.Network/virtualNetworks"
태그를 사용하면 고객이 Azure 리소스 및 관리 계층 구조를 분류할 수 있습니다.
참고
태그는 일반 텍스트로 저장됩니다. 태그에 중요한 값을 추가하지 마세요. 중요한 값은 비용 보고서, 태그 분류, 배포 기록, 내보낸 템플릿 및 모니터링 로그를 비롯한 많은 방법을 통해 노출될 수 있습니다.