다음을 통해 공유


Azure의 Red Hat Enterprise Linux에 대한 플랫폼 자동화 고려 사항

이 문서에서는 Azure에서 RHEL(Red Hat Enterprise Linux)에 대한 자동화를 관리하는 방법을 설명합니다. 일관되고 안정적인 환경을 달성하는 데 사용할 수 있는 Azure 에코시스템 내의 다양한 도구에 대한 디자인 고려 사항, 디자인 권장 사항 및 옵션을 설명합니다. 이 문서에서는 다양한 고객 시나리오, 비즈니스 요구 사항, 운영 사례 및 기술 완성도에 맞는 지침을 제공합니다.

개요

Azure 랜딩 존용 RHEL을 자동화하는 경우 RH-IS(Red Hat Infrastructure Standard) 및 연결된 RH-ISAM(Red Hat 인프라 표준 채택 모델)을 사용하여 Azure 랜딩 존 수명 주기 관리를 조정합니다. 시스템을 표준화하여 솔루션을 위한 신뢰할 수 있는 기반을 제공합니다. RH-IS는 소프트웨어 구성 요소 및 구성의 기본 집합을 구성하는 표준 운영 환경을 정의합니다. RH-ISAM, DevOps 또는 Git 작업 원칙 집합, ARM 템플릿(Azure Resource Manager 템플릿), Terraform, Azure CLI 및 Azure PowerShell을 통해 이러한 구성 요소 및 구성을 시스템에 적용할 수 있습니다.

다양한 작업을 자동화할 수 있습니다. 예를 들어 자동화를 사용하여 다음을 수행할 수 있습니다.

  • 구성 요소를 프로비전합니다.
  • 시스템을 관리합니다.
  • 플랫폼 진화를 수행합니다.
  • 인프라 작업을 통합합니다.
  • 애플리케이션 및 워크로드 수명 주기를 구성합니다.

IaC(Infrastructure as Code) 및 코드로 구성을 통해 이러한 작업을 구현할 수 있습니다. 오류를 줄이고 안정성을 높이려면 구성을 정의하고 테스트합니다. 대량 마이그레이션 속도를 높이기 위해 프로비저닝을 자동화합니다. 자동화된 구성은 구성 드리프트를 줄이고 시스템이 올바르게 작동하는지 확인합니다.

디자인 고려 사항

IdM(Red Hat Identity Management)은 RHEL 시스템에 대한 ID 저장소, 인증 정책 및 권한 부여 정책을 관리하는 데 사용할 수 있는 중앙 집중식 통합 플랫폼을 제공합니다. 하이브리드 시나리오에서는 가상 사설망 또는 Azure ExpressRoute를 통해 기존 Red Hat IdM 인프라를 확장할 수 있습니다. 이 구성은 온-프레미스 환경을 Azure 내의 RHEL 랜딩 존과 연결합니다. 하이브리드 클라우드 ID 시나리오를 지원하려면 워크로드를 Microsoft Entra와 통합할 수 있도록 온-프레미스 환경을 Azure로 확장합니다. 자세한 내용은 Microsoft Entra 인증을 참조하세요.

대체 ID 관리 솔루션으로 RHEL에 가입하여 Windows Server Active Directory로 외부 트러스트를 만들거나 기존 Windows Server Active Directory 포리스트에 직접 조인할 수 있습니다. 자세한 내용은 WINDOWS Server Active Directory와 RHEL 시스템 직접 통합을 참조 하세요.

Red Hat Satellite 는 관리되는 RHEL 시스템에 전달되는 콘텐츠의 단일 원본입니다. 위성에는 Red Hat 패키지 및 패치와 애플리케이션 개발 팀이 개발하는 비 Microsoft 패키지 및 사용자 지정 패키지도 포함됩니다. 위성은 보안 또는 성능 위험을 인식하는 구성의 예측 분석을 제공하는 Red Hat Insights의 게이트웨이 역할을 합니다. 미리 구성된 RHEL 종량제 이미지를 배포하는 경우 종량제 이미지에 기본 제공되는 업데이트 도구인 Azure용 Red Hat 업데이트 인프라를 활용할 수 있습니다.

Red Hat Ansible Automation Platform 디자인 고려 사항

RED Hat AAP(Ansible Automation Platform)는 기술 워크플로 및 되풀이 작업을 표준화하는 데 도움이 됩니다. AAP를 사용하여 워크플로를 오케스트레이션하고, 새 시스템에 대한 프로세스를 프로비전하고, 되풀이 작업 작업을 만들 수 있습니다. 복잡성을 줄이려면 하나의 일반적인 자동화 플랫폼 및 언어를 사용합니다. 완전히 자동화된 워크플로는 애플리케이션 혁신을 가속화하고 온-프레미스 환경 및 클라우드 환경에서 대량 워크로드 마이그레이션을 간소화합니다.

플랫폼 자동화 전략인 RHEL의 이점은 다음과 같습니다.

  • 새로운 시스템에는 대규모 프로비저닝이 완전히 자동화되어 대량 마이그레이션 속도가 향상됩니다.

  • 물리적 시스템 및 가상 시스템에서 테스트된 시스템의 구성 및 애플리케이션 설치의 균일성이 향상되었습니다.

  • 패치 관리를 즉시 사용할 수 있기 때문에 지속적인 업데이트입니다.

  • 새로운 애플리케이션 및 워크로드를 제공하는 표준화되고 간소화된 플랫폼입니다. 직원들은 향상된 혁신을 제공할 수 있는 추가 시간을 가지고 있습니다.

다음을 구현할 수 있습니다.

  • 온-프레미스 인프라, 클라우드 인프라 또는 둘 다를 통한 자체 관리형 AAP 인스턴스입니다. RHEL 배포 또는 Red Hat OpenShift Container Platform 배포를 사용할 수 있습니다.

  • 퍼블릭 클라우드의 자체 관리형 AAP 인스턴스입니다.

  • 퍼블릭 클라우드의 관리되는 AAP 인스턴스입니다.

자체 관리형 Red Hat AAP 온-프레미스 또는 클라우드

온-프레미스, 클라우드 또는 하이브리드 인프라에서 자체 관리 모드로 Microsoft Azure에 Red Hat AAP를 배포하여 다음과 같은 이점을 얻습니다.

  • 아키텍처 및 크기 조정: 자동화 플랫폼을 지원하는 이상적인 아키텍처를 결정합니다. RHEL 인프라 또는 OpenShift 운영자 배포를 기반으로 아키텍처를 기반으로 할 수 있습니다. 플릿 크기 및 요구 사항에 따라 컨트롤러, 실행 노드 및 프라이빗 자동화 허브 인스턴스의 수와 인스턴스 크기를 선택합니다. 아키텍처, 디자인, 구성 및 규모에 대한 자세한 내용은 Red Hat AAP 계획 가이드를 참조하세요.

  • Azure 구성: 조직의 Azure 디자인 및 구성에 맞게 자동화 아키텍처를 최적화합니다.

  • 자동화 메시 지원: AAP 자동화 메시 기능을 사용하여 기존 네트워크를 사용하여 피어 투 피어 연결을 설정하는 하이브리드 클라우드 노드에 자동화 워크로드를 분산합니다. 보안 디자인 조건 및 네트워크 토폴로지에 따라 위치에 홉 노드를 배치합니다.

  • 자동화 허브 아키텍처: 프라이빗 자동화 허브 인스턴스의 크기 조정 및 배치를 위해 자동화 허브 아키텍처를 최적화합니다. 자동화 실행 리소스에 근접한 실행 환경 원본에 대한 보안 자동화 콘텐츠 배달 및 액세스를 향상시키기 위해 구성을 최적화합니다. 자동화 소비자가 액세스할 수 있는 Ansible 콘텐츠 컬렉션 및 버전을 선택할 수 있습니다.

Azure의 관리형 또는 자체 관리형 Red Hat AAP

Microsoft Azure 의 Red Hat AAP는 다음과 같은 이점을 제공하는 관리되는 애플리케이션 또는 자체 관리형 애플리케이션을 통해 사용할 수 있습니다.

  • 사용 편의성으로 인한 ROI(신속한 투자 수익률): Azure Marketplace에서 직접 Azure에 AAP를 배포할 수 있습니다. 이 관리형 솔루션은 배포 직후에 활성화되며 몇 분 안에 Azure 리소스 관리를 자동화할 수 있습니다. Red Hat은 인프라를 관리하므로 엔터프라이즈에 중요한 다른 시스템에 대해 자유롭게 생각할 수 있습니다.

  • 간소화된 통합: Azure의 AAP는 Azure 서비스와 통합됩니다. Microsoft와 Red Hat은 Azure용 Ansible 컬렉션을 개발하고 보안을 테스트했기 때문에 최소한의 설정이 필요하고 최대 지원을 받을 수 있습니다. 하이브리드 클라우드 자동화 전략의 일환으로 Azure의 AAP를 사용하여 하이브리드 클라우드, 사물 인터넷 및 에지 배포에서 관리 및 자동화를 통합합니다.

  • 기존 커밋된 Azure 지출: Microsoft와 함께 기존 커밋된 지출을 사용하여 Azure에서 Red Hat AAP를 구매할 수 있습니다. 전체 조직의 팀이 구성 요소를 원활하게 배포, 구성 및 자동화할 수 있도록 커밋된 지출을 사용합니다. 통합 청구는 하나의 청구서와 비용에 대한 전체 가시성을 얻는 것을 의미합니다.

  • 클라우드를 넘어서는 자동화: AZURE의 AAP를 사용하여 Microsoft Azure 클라우드에 애플리케이션을 배포한 다음 인프라 간에 확장할 수 있습니다. Azure 및 하이브리드 클라우드 환경에서 애플리케이션을 배포, 실행 및 크기 조정합니다.

  • 지원: Red Hat과 Microsoft는 일관된 보안 중심 작업을 보장하기 위해 Azure에서 AAP를 빌드하기 위해 파트너로 협력했습니다. Red Hat은 IT 팀이 자동화 전략을 제공하는 데 집중할 수 있도록 애플리케이션을 관리, 서비스 및 지원합니다.

관리 모드에 대한 기타 고려 사항

관리되는 애플리케이션이 되도록 관리 모드에서 Azure에 AAP를 설치할 수 있습니다. Red Hat은 기본 Azure 리소스와 해당 리소스에서 실행되는 소프트웨어를 모두 관리합니다. 해당 인프라는 Azure 테넌트에서 실행됩니다.

관리되는 애플리케이션 리소스 그룹은 테넌트 내의 다른 리소스 그룹과 별개입니다. Red Hat은 다른 테넌트 리소스에 대한 가시성 없이 관리되는 애플리케이션 리소스 그룹에만 액세스할 수 있습니다.

자세한 내용은 Azure 관리형 애플리케이션 개요를 참조하세요.

관리 모드의 Azure의 AAP는 다음 리소스 그룹을 사용합니다.

  • 테넌트에 있는 새 또는 기존 리소스 그룹입니다. 이 리소스 그룹에는 Azure 관리되는 애플리케이션 배포에서 AAP를 참조하는 단일 리소스가 포함됩니다. Red Hat은 지원, 유지 관리 및 업그레이드를 수행하기 위해 관리되는 앱에 액세스할 수 있습니다. 하지만 Red Hat은 리소스 그룹을 관리하지 않습니다.

  • Azure에서 AAP를 운영하는 데 필요한 인프라의 대부분을 포함하는 다중 테넌트 MRG(관리되는 리소스 그룹) 입니다. Red Hat 테넌트와 테넌트는 이 다중 테넌트 리소스 그룹을 공유합니다. Red Hat에는 모든 관리 권한이 있습니다. 리소스 그룹에 대한 읽기 전용 액세스 권한이 있습니다.

  • AKS(Azure Kubernetes Service) 노드 풀 리소스 그룹(NPRG). Microsoft에는 AKS 배포에 대한 NPRG가 필요합니다. NPRG에는 AKS가 작동하는 데 사용하는 리소스가 포함되어 있습니다. 이 리소스 그룹은 배포할 때 만들어집니다. Red Hat은 이 리소스 그룹을 관리하지 않습니다. 자세한 내용은 Microsoft AKS 설명서를 참조 하세요.

관리 모드에서 Azure의 AAP의 경우 다음 요소도 고려합니다.

  • Azure에 AAP를 설치할 때 배포가 공용인지 프라이빗인지를 선택하면 사용자가 AAP 사용자 인터페이스에 액세스할 수 있는 방법에 영향을 줍니다.

  • 퍼블릭 또는 프라이빗 배포를 선택하든 관계없이 자동화하려는 리소스가 포함된 프라이빗 네트워크로 AAP에서 아웃바운드 통신을 위한 네트워크 피어링을 구성해야 합니다. Azure의 AAP에서 프라이빗 Azure 가상 네트워크로의 네트워크 피어링을 구성할 수 있으며, Azure를 사용한 전송 라우팅이 있는 온-프레미스 네트워크 또는 다중 클라우드 네트워크로 연결할 수 있습니다.

자체 관리 모드에 대한 기타 고려 사항

자체 관리 모드의 Azure의 AAP는 관리되는 AAP와 동일한 많은 이점을 제공합니다. 그러나 관리 모드가 AKS 클러스터 내에서 실행되는 경우 자체 관리 모드 자동화 플랫폼 리소스는 VM(가상 머신) 기반입니다.

자체 관리 모드에서 Azure의 AAP의 경우 다음 요소를 고려합니다.

  • 이벤트 기반 Ansible은 Azure의 자체 관리형 제품에 포함됩니다. 이벤트 기반 자동화를 사용하면 수동 작업을 줄이고 혁신에 중점을 둔 효율적인 IT 환경을 제공할 수 있습니다. 이벤트 기반 Ansible은 이벤트를 처리하고, 적절한 응답을 결정한 다음, 자동화된 작업을 실행하여 이벤트를 수정합니다.

  • 구독은 100개의 활성 관리 노드 증분에서 사용할 수 있습니다. 퍼블릭 제품 또는 프라이빗 제품에서 사용할 수 있습니다.

  • 자체 관리 모드에서 Azure의 AAP를 뒷받침하는 VM 리소스는 전적으로 Azure Marketplace 이미지 또는 Azure Marketplace 이미지와 고객 관리형 이미지의 혼합으로 구성됩니다.

디자인 권장 사항

Azure 랜딩 존용 RHEL 플랫폼을 운영하는 경우 Red Hat 자동화 허브에서 Red Hat 인증 콘텐츠 및 유효성이 검사된 콘텐츠 컬렉션을 사용합니다. 다음 컬렉션에는 자동화 프레임워크에서 중요한 역할이 있습니다.

  • redhat.rhel_idm

    • IdM 기본 VM을 구성합니다.
    • IdM 복제본을 구성합니다.
    • IDM과 RHEL 클라이언트를 통합하고 구성합니다.
  • redhat.satellite, redhat.satellite_operationsredhat.rhel_system_roles

    • 위성 및 캡슐을 배포합니다.
    • 위성 개체 및 설정을 만들고 구성합니다.
    • RHEL 시스템을 프로비전 및 구성합니다.
  • ansible.*, ansible.controllerinfra.controller_configuration

    • AAP를 구성합니다.
    • AAP 작업 템플릿 및 설정을 만들고 구성합니다.

Azure 용 Ansible 컬렉션에는 다음과 같은 Azure 리소스 유형을 심문, 관리 및 자동화하는 데 사용할 수 있는 250개 이상의 모듈이 포함되어 있습니다.

  • AKS.
  • 애플리케이션 보안 그룹입니다.
  • Azure Container Registry입니다.
  • Azure 데이터베이스 서비스.
  • Azure Key Vault
  • Azure SQL Database.
  • Azure Virtual Machines.
  • Microsoft Entra ID.
  • 네트워킹.
  • 스토리지.

핵심 플랫폼 인프라 배포

핵심 플랫폼 인프라를 효과적으로 배포하고 Azure 랜딩 존 모델에서 RHEL 플랫폼을 지원하기 위한 개념과 프로세스를 설정합니다.

자세한 내용은 다음을 참조하세요.

  • 플랫폼 자동화 고려 사항에 대한 Azure 랜딩 존 디자인 지침입니다.

  • 개발 수명 주기. 자동화를 사용하여 랜딩 존을 만드는 방법에 대한 주요 디자인 고려 사항 및 권장 사항을 살펴봅니다. 이 지침에서는 리포지토리, 분기, 자동화된 빌드, 배포 및 롤백 전략에 대해 설명합니다.

  • IaC. IaC를 통해 Azure 랜딩 존을 구현하는 이점에 대해 살펴봅니다. 코드 구조, 도구 및 기술과 관련된 고려 사항에 대해 알아봅니다.

  • 환경. 여러 환경을 사용하여 더 빠른 속도와 빈도로 코드를 빌드, 테스트 및 릴리스하는 방법을 알아봅니다. 이 접근 방식은 배포 작업을 최대한 간단하게 만들어 줍니다.

  • 테스트 기반 개발. 단위 테스트를 사용하여 새 기능의 품질을 개선하고 Azure 랜딩 존 코드 베이스를 개선하는 방법을 알아봅니다.

필수 소스 코드 관리 도구가 있고 이전 섹션에서 설정한 소스 코드 관리 프로세스가 있는 경우 자동화를 구현할 수 있습니다. 핵심 인프라를 배포하고 Azure 랜딩 존 모델에 대한 RHEL 플랫폼을 지원하는 코드로 IaC 또는 구성과 함께 Ansible 자동화 코드를 개발합니다. greenfield 배포의 경우 전체 환경 구현을 위해 다음 작업을 자동화할 수 있습니다. 브라운필드 배포의 경우 사용 사례에 필요한 작업만 자동화할 수 있습니다.

  • Azure 리소스 그룹을 만듭니다.
  • 가상 네트워크를 만듭니다.
  • 서브넷을 만듭니다.
  • 네트워크 보안 그룹을 만듭니다.
  • 자동화된 Red Hat Image Builder를 통해 Azure용 RHEL 8.x 및 9.x 골든 이미지를 만듭니다.
  • IdM 기본 VM(사전 위성 프로비전)을 만듭니다. 구성을 통해 IdM 기본 VM을 코드로 구성합니다.
  • 위성 VM(사전 위성 프로비전)을 만듭니다. 구성을 통해 위성을 코드로 구성합니다.
  • 캡슐 VM(위성 프로비전)을 만듭니다. 코드로 구성을 통해 캡슐을 구성합니다.
  • IdM 복제본 VM(위성 프로비저닝)을 만듭니다. 구성을 통해 IdM 복제본을 코드로 구성합니다.
  • 다음을 포함하여 AAP 인프라(위성 프로비저닝)를 만듭니다.
    • 자동화 컨트롤러 VM.
    • 실행 노드 VM.
    • 홉 노드 VM(선택 사항).
    • Automation 허브 VM.
    • 이벤트 기반 Ansible VM(사용하도록 설정된 경우).
    • Azure Database for PostgreSQL 서버 및 컨트롤러, 허브 및 이벤트 기반 Ansible 구성 요소에 필요한 데이터베이스입니다. 고가용성 또는 재해 복구 Azure Database for PostgreSQL 구성에는 복제 전달, 로그 전달 또는 Crunchy Postgres를 통한 추가 자동화가 필요합니다.
  • 부하 분산 장치(애플리케이션 게이트웨이)를 만듭니다.
    • 캡슐 VM의 프런트 엔드
    • AAP 컨트롤러 VM의 프런트 엔드
    • Automation 허브 VM의 프런트 엔드
  • 애플리케이션 보안 그룹을 만듭니다.
    • IdM 인프라
    • AAP 인프라
    • 위성 또는 캡슐 인프라

RHEL 시스템 수명 주기 관리

핵심 플랫폼 인프라가 준비되면 RHEL 애플리케이션 및 워크로드 수명 주기에 대한 자동화를 구현할 수 있습니다. 다음 워크플로에서는 개발 수명 주기 파이프라인에 대한 자동화 구현 예제를 설명합니다.

  1. errata 필터 종료 날짜를 업데이트하고 위성에 콘텐츠를 게시합니다.

  2. CV(콘텐츠 뷰) 및 CCV(복합 콘텐츠 뷰)를 개발로 승격합니다.

  3. 위성 호스트 그룹에서 RHEL 개발 테스트 시스템을 배포합니다. 자동화된 Red Hat Image Builder를 통한 Azure용 RHEL 8.x 및 9.x 골든 이미지는 위성에서 Azure 컴퓨팅 리소스로 정의됩니다.

  4. 애플리케이션 통신 경로를 기반으로 Azure 네트워크 보안 그룹을 업데이트하거나 만듭니다.

  5. 다중 계층 애플리케이션 스택에 대한 추가 계층화된 보안을 제공하도록 Azure 애플리케이션 보안 그룹을 업데이트하거나 만듭니다.

  6. RHEL 개발 시스템을 업데이트하고 위성 개발 CV 또는 CCV에서 원하는 애플리케이션을 배포하고 구성합니다.

    • 간단한 애플리케이션 스택을 위해 단일 RHEL 인스턴스에 배포합니다.
    • 다중 계층 애플리케이션 스택에 대한 여러 RHEL 인스턴스에 배포합니다.
    • 애플리케이션 스택을 구성합니다.
  7. 애플리케이션 테스트 프레임워크를 실행합니다.

    • 테스트가 실패하면 문제 해결 및 분석에 도움이 되도록 OnCall 자동화 관리에 알립니다. 자동화 워크플로를 종료합니다. RHEL 테스트 시스템은 사후 분석 실패 분석을 위해 계속 배포됩니다.
    • 테스트가 성공하면 단계를 계속합니다.
  8. CV 및 CCV를 QA(품질 보증)로 승격합니다.

  9. RHEL 개발 테스트 시스템을 삭제합니다.

수명 주기 파이프라인의 후속 단계는 개발 수명 주기 단계와 약간 다릅니다. 개발 단계에서만 초기 콘텐츠 게시 및 초기 CV 및 CCV 승격을 개발에 사용합니다. 다음 예제에서는 QA, 사전 프로덕션 및 프로덕션 파이프라인과 같은 비개발 수명 주기 파이프라인에 대한 자동화 워크플로를 설명합니다.

  1. 위성 호스트 그룹에서 RHEL QA 테스트 시스템을 배포합니다. 자동화된 Red Hat Image Builder를 통한 Azure용 RHEL 8.x 및 9.x 골든 이미지는 위성에서 Azure 컴퓨팅 리소스로 정의됩니다.

  2. 애플리케이션 통신 경로를 기반으로 Azure 네트워크 보안 그룹을 업데이트하거나 만듭니다.

  3. 다중 계층 애플리케이션 스택에 대한 추가 계층화된 보안을 제공하도록 Azure 애플리케이션 보안 그룹을 업데이트하거나 만듭니다.

  4. RHEL QA 시스템을 업데이트하고, 위성 QA의 CV 또는 CCV에서 원하는 애플리케이션을 배포하고 구성합니다.

    • 간단한 애플리케이션 스택을 위해 단일 RHEL 인스턴스에 배포합니다.
    • 다중 계층 애플리케이션 스택에 대한 여러 RHEL 인스턴스에 배포합니다.
    • 애플리케이션 스택을 구성합니다.
  5. 애플리케이션 테스트 프레임워크를 실행합니다.

    • 테스트가 실패하면 문제 해결 및 분석에 도움이 되도록 OnCall 자동화 관리에 알립니다. 자동화 워크플로를 종료합니다. RHEL 테스트 시스템은 사후 분석 실패 분석을 위해 계속 배포됩니다.
    • 테스트가 성공하면 단계를 계속합니다.
  6. CV 및 CCV를 프로덕션으로 승격합니다.

  7. RHEL QA 테스트 시스템을 삭제합니다.

Azure 네이티브 도구에 대한 기타 디자인 고려 사항

Azure Automation

빈번하고 시간이 오래 걸리며 오류가 발생하기 쉬운 관리 작업을 자동화하려면 Azure Automation에서 프로세스 자동화 기능을 사용할 수 있습니다. 이 기능을 사용하면 비즈니스 가치를 더하는 작업에 집중할 수 있습니다. 프로세스 자동화는 오류를 줄이고 효율성을 높여 운영 비용을 낮춥니다. 자세한 내용은 Automation 개요를 참조하세요.

프로세스 자동화는 엔드투엔드 프로세스를 배포, 구성 및 관리해야 하는 Azure 서비스 및 Red Hat과 같은 다른 파트너 시스템의 통합을 지원합니다. 이 기능을 사용하여 그래픽 PowerShell 및 Python Runbook을 작성할 수도 있습니다.

리소스 관리, VM 시작 및 중지, Azure 내부 및 Azure 외부에서 유지 관리 작업 처리와 같은 광범위한 자동화 작업에 Runbook을 사용할 수 있습니다. 자세한 내용은 Azure Automation 계정 인증 개요Azure Automation의 Runbook을 참조하세요.

다음 표에서는 지원되는 Runbook 형식에 대해 설명합니다.

Runbook 형식 설명
PowerShell Windows PowerShell 스크립팅을 기반으로 하는 텍스트 Runbook입니다. 지원되는 버전은 PowerShell 7.2(GA) 및 PowerShell 5.1(GA)입니다. PowerShell 상위 제품은 더 이상 PowerShell 7.1을 지원하지 않습니다. 장기 지원 버전 PowerShell 7.2에서 Runbook을 만드는 것이 좋습니다.
PowerShell 워크플로 Windows PowerShell 워크플로 스크립팅을 기반으로 하는 텍스트 Runbook입니다.
Python Python 스크립팅을 기반으로 하는 텍스트 Runbook입니다. 지원되는 버전은 Python 3.8(GA) 및 Python 3.10(미리 보기)입니다. Python 부모 제품은 더 이상 Python 2.7을 지원하지 않습니다. 장기 지원 버전에서 Runbook을 만드는 것이 좋습니다.
그래픽 Windows PowerShell을 기반으로 하고 Azure Portal의 그래픽 편집기에서 완전히 만들고 편집한 그래픽 Runbook입니다.
그래픽 PowerShell 워크플로 Windows PowerShell 워크플로를 기반으로 하고 Azure Portal의 그래픽 편집기에서 완전히 만들고 편집한 그래픽 Runbook입니다.

웹후크를 사용하여 요청을 수행하고 Azure Logic Apps, Azure Functions, IT 서비스 관리 제품 또는 서비스, DevOps 또는 모니터링 시스템을 통해 자동화를 트리거하여 지속적인 업데이트 및 작업을 보장합니다.

Azure Arc는 클라우드 컴퓨팅의 상당한 발전을 나타내며 Azure 기능을 온-프레미스, 다중 클라우드 및 에지 환경으로 확장하는 통합 관리 플랫폼을 제공합니다. Azure Arc는 VM 확장 프레임워크를 통해 Azure Automation 서비스와 통합되어 하이브리드 Runbook 작업자 역할을 배포하고 업데이트 관리, 변경 내용 추적 및 인벤토리 기능에 대한 온보딩을 간소화합니다.

Azure Arc 에코시스템을 보여 주는 다이어그램

자세한 내용은 Azure Arc에 기존 Linux 서버 연결을 참조 하세요.

ARM 템플릿

ARM 템플릿을 통한 IaC는 Azure 리소스를 배포하고 관리하는 일관된 선언적 방법을 제공합니다. ARM 템플릿을 사용하여 JSON 형식으로 애플리케이션에 필요한 인프라를 정의합니다. ARM 템플릿은 idempotent입니다. 즉, 동일한 템플릿을 여러 번 배포하고 동일한 상태에서 동일한 리소스 종류를 가져올 수 있습니다.

자세한 내용은 ARM 템플릿 설명서를 참조 하세요.

JSON 예시

{ 

  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#", 
  "contentVersion": "1.0.0.0", 
  "parameters": { 
    "location": { 
      "type": "string", 
      "defaultValue": "[resourceGroup().location]" 
    }, 
    "storageAccountName": { 
      "type": "string", 
      "defaultValue": "[format('toylaunch{0}', uniqueString(resourceGroup().id))]" 
    } 
  }, 
  "resources": [ 
    { 
      "type": "Microsoft.Storage/storageAccounts", 
      "apiVersion": "2021-06-01", 
      "name": "[parameters('storageAccountName')]", 
      "location": "[parameters('location')]", 
      "sku": { 
        "name": "Standard_LRS" 
      }, 
      "kind": "StorageV2", 
      "properties": { 
        "accessTier": "Hot" 
      } 
    } 
  ] 
}  

Bicep 도메인별 언어를 사용하여 JSON 구문의 복잡성을 줄이고 Azure를 접하는 사용자의 학습 곡선을 최소화할 수 있습니다. Bicep은 JSON을 사용하는 ARM 템플릿에 비해 투명한 추상화이며 Bicep은 JSON 템플릿 기능을 유지합니다. 배포하는 동안 Bicep 명령줄 인터페이스는 Bicep 파일을 JSON을 사용하는 ARM 템플릿으로 변환합니다.

이 섹션의 예제에서는 Bicep 파일과 해당하는 JSON 템플릿 간의 차이를 보여 줍니다. 두 예제 모두 스토리지 계정을 배포합니다.

Bicep 예제

param location string = resourceGroup().location 
param storageAccountName string = 'toylaunch${uniqueString(resourceGroup().id)}' 
 

resource storageAccount 'Microsoft.Storage/storageAccounts@2021-06-01' = { 
  name: storageAccountName 
  location: location 
  sku: { 
    name: 'Standard_LRS' 
  } 
  kind: 'StorageV2' 
  properties: { 
    accessTier: 'Hot' 
  } 
} 

Azure DevOps

Azure DevOps는 프로젝트 관리, CI/CD(지속적인 통합 및 지속적인 업데이트) 서비스 및 클라우드 및 온-프레미스 환경 모두에 대한 소스 코드 리포지토리를 제공하는 포괄적인 개발 도구 집합입니다. 이러한 기능을 Azure Test Plans, Azure Artifacts, Logic Apps 및 Azure Functions와 결합하여 최신 소프트웨어 프로젝트의 원활한 협업, 개발 및 제공을 용이하게 할 수 있습니다.

Azure Boards

Azure Boards는 클라우드 소프트웨어 개발 및 프로젝트 관리를 위한 Agile 방법론을 지원합니다. 자세한 내용은 Azure Boards 설명서Azure Boards 구성 및 사용자 지정을 참조하세요.

Azure Boards를 최대한 활용하려면 팀이 스크럼, Kanban 및 스크럼반과 같은 도구와 기능을 사용하는 방법과 구성 및 사용자 지정에 대한 종속성을 이해합니다.

다음 표에서는 프로젝트를 구조화할 때 고려해야 하는 기본 항목을 요약하여 설명합니다.

프로젝트 수준 팀 수준
정의하려는 팀 수 제품 백로그를 사용하여 작업을 계획하고 우선 순위를 지정하는 방법
포트폴리오 관리 보기를 지원하기 위해 영역 경로를 구성하는 방법 버그를 요구 사항으로 추적하거나, 버그를 작업으로 추적하거나, 버그를 전혀 사용하지 않는지 여부
필드 사용자 지정 작업을 사용하여 시간과 용량을 추적하는지 여부
사용자 지정 작업 항목 유형 포트폴리오 백로그 수준을 사용하는 방법
포트폴리오 백로그 사용자 지정 포트폴리오 백로그 수준을 사용하는 방법
워크플로 사용자 지정 진행률, 상태 및 위험을 상위 관리에 알리는 방법

Azure Pipelines

Azure Pipelines는 쉽게 사용할 수 있는 일관되고 품질이 좋은 코드로 프로젝트 빌드를 자동화하는 빠르고 쉽고 안전한 방법을 제공합니다.

Azure Pipelines:

  • 모든 언어 또는 플랫폼에서 작동합니다.
  • 동시에 다양한 유형의 대상에 배포합니다.
  • Azure 배포와 통합됩니다.
  • Windows, Linux 또는 Mac 머신에서 빌드합니다.
  • GitHub와 통합됩니다.
  • 오픈 소스 프로젝트에서 작동합니다.

자세한 내용은 Azure Policy 설명서를 참조하세요.

조직의 요구 사항에 따라 Azure Pipelines의 네 가지 핵심 아키텍처 중 하나를 선택할 수 있습니다.

Azure Repos

Azure Repos는 두 가지 유형의 버전 제어인 Git 버전 제어 및 중앙 집중식 버전 제어를 제공합니다.

코드에 액세스하려면 개발 환경을 Azure Repos에 연결합니다. 다음을 통해 코드를 공유합니다.

자세한 내용은 Azure Repos Git 설명서Team Foundation 버전 제어 설명서를 참조하세요.

릴리스 파이프라인 및 Azure Artifacts 원본 사용

개발자는 Azure Artifacts를 사용하여 PyPI, Maven Central 및 NuGet.org 같은 피드 및 공용 레지스트리에서 다양한 유형의 패키지를 게시하고 사용할 수 있습니다. Azure Pipelines와 함께 Azure Artifacts를 사용하여 빌드 및 파이프라인 아티팩트 게시, 패키지 배포 또는 파이프라인의 다양한 단계에서 파일을 통합하여 애플리케이션을 빌드, 테스트 또는 배포할 수 있습니다.

자세한 내용은 다음을 참조하세요.

Azure Policy와 Azure DevOps 통합

Azure Policy는 Azure 환경 내의 리소스에 직접 적용되지만 해당 원칙과 거버넌스는 Azure DevOps 사례에 간접적으로 영향을 줄 수 있습니다. 예를 들어 Azure Policy는 다음과 같은 영향을 줄 수 있습니다.

  • CI/CD 파이프라인의 규정 준수: 규정 준수 검사를 파이프라인에 통합할 수 있습니다. 예를 들어 Azure DevOps를 통해 배포하는 인프라가 Azure Policy에서 정의하는 정책을 준수하는지 확인합니다.

  • 환경 일관성: Azure Policy를 사용하여 특정 구성 또는 리소스 유형을 적용하여 Azure DevOps를 통해 배포하는 환경이 일관되고 규정을 준수하도록 합니다.

  • 보안 및 거버넌스: 정책은 Azure DevOps Projects가 관리하는 리소스에 보안 표준 및 거버넌스 사례를 적용할 수 있습니다. 이 규정은 개발 수명 주기에 조직 및 규제 표준 준수를 포함하도록 보장합니다.

Azure Policy를 Azure DevOps와 효과적으로 통합하려면 Azure Policy 규정 준수 데이터 및 감사 기능을 사용하여 DevOps 사례를 알릴 수 있습니다. Azure Policy를 통해 적용하는 조직 정책에 맞게 파이프라인 또는 IaC 정의를 조정합니다.

이 통합을 통해 Azure DevOps를 통해 배포하고 관리하는 리소스가 항상 회사의 거버넌스 표준을 준수할 수 있습니다. Azure 환경에서 보안, 일관성 및 비용 관리를 향상하려면 이 방법을 사용합니다.

다음 단계