Thank you to Hicham Mourad and Scott Harwell for co-authoring this blog.
Introduction
In this blog series we will discuss the deployment of Red Hat Ansible Automation Platform on Microsoft Azure, specifically focusing on the deployment access types and what that means for accessing Red Hat Ansible Automation Platform on Azure after deployment completion.
Deployment Access Types
First let’s start by discussing the different deployment access types.
During deployment, Red Hat Ansible Automation Platform on Azure will present an option called “Access” that determines how you will access the user interfaces.
Access Selection at Deploy Time
|
Deployment Type |
Details |
|
Public |
Public deployments allow ingress to the user interfaces over the public internet. Upon deployment, a domain name is issued to the Red Hat Ansible Automation Platform on Azure instance, and users will be able to navigate to the domain to login. This is the easiest approach to deploy because there is no configuration required to access Red Hat Ansible Automation Platform on Azure. Public Access Architecture Diagram below |
Public Access Architecture Diagram
|
Deployment Type |
Details |
|
Private |
Private deployments omit access from the public internet. When deployed, Red Hat Ansible Automation Platform on Azure will reside in an isolated Azure VNET with no access from external sources or even other Azure devices. Organizations that select this option will have to configure network peering in order to access Red Hat Ansible Automation Platform on Azure via the URLs that are created as part of the deployment process. Once peering and routing are configured, then users can access Red Hat Ansible Automation Platform on Azure through a VM on a connected Azure subnet, or directly if your organization has transit routing setup between Azure and your local network. Note: No two Azure networking configurations are the same. Your organization will need to work with your Azure administrators in order to properly connect the private access deployment to allow user access. Private Access Architecture Diagram below |
Private Access Architecture Diagram
Note: Regardless of the deployment model for UI access, network peering is required for Red Hat Ansible Automation Platform on Azure to access resources that reside on private networks on Azure networks, or where transit routing between Azure and your on-premises network(s) exists. Red Hat Ansible Automation Platform on Azure requires peering for outbound communication to perform automations against devices on your Azure network(s) and connected on-prem or multi-cloud networks.
With the knowledge of the deployment access types, let’s dive into how to deploy Red Ansible Automation Platform on Azure.
Deploying Red Hat Ansible Automation Platform on Azure
We’ll start by walking through the deployment steps of Red Hat Ansible Automation Platform on Microsoft on Azure.
Start by navigating to the Azure Marketplace, and selecting the “Private Products” menu option. Select the catalog item titled “Red Hat Ansible Automation Platform on Azure”
Once you select the catalog tile, you have two screens to complete, and then the deployment will begin. The first screen is a form for input about how Red Hat Ansible Automation Platform on Azure will install into your Azure subscription.
You need to either create a resource group, or provide one that’s already available. This is the resource group where the managed application object of your deployment will reside.
The region field is required and indicates what region the deployment will install to.
The administrator password is also provided here, and will be the password for the “admin” user of both the automation controller and the private automation hub user interfaces.
The deployment will create a “Managed Resource Group” that the publisher of Red Hat Ansible Automation Platform on Azure - in this case Red Hat - has access to in order to perform any management and support tasks against the deployment. The name of the managed resource group is autogenerated, but you do have the ability to change this if needed.
The “Access” field indicates how the UI interfaces and APIs for automation controller and private automation hub will be accessible after deployment. The “Access” field has two options, “Public” and “Private”.
Public indicates that the UI interfaces and APIs for automation controller and private automation hub are accessible via the public internet. These endpoints are protected with Azure Application Gateway and Web Application Firewall. This option is useful for organizations that do not want to configure network peering or want a more turn-key deployment model.
Private indicates that the UI interfaces and APIs for automation controller and private automation hub are only accessible via Azure private networks through network peering. This isolates Red Hat Ansible Automation Platform on Azure from public internet access.
Different organizations choose the access type that works best for them based on their organizational networking policies and Azure networking acumen.
Once the deployment is complete, access information will be available in the managed application record that has been created for the deployment. Navigate to the “Outputs and Parameters” option in the “Settings” section to see the URLs for both automation controller and the private automation hub.
If you’ve selected “Public” for your access method, simply visit the URL to access the corresponding UI.
Log in using “admin” and the administrator password you provided earlier and you're good to go. You may then configure users from within the platform or configure SSO with Azure AD or other identity providers (IDP) .
So.. that was easy! But what if you chose “Private” access? If so, then there are further steps to complete to access the UIs for automation controller and private automation hub.
In a subsequent blog post we will review how to access the UIs for Red Hat Ansible Automation Platform on Azure if you select “Private” access. If you do, you have a few options to leverage to access the UIs.
- An Azure hosted virtual machine (VM)
- Azure VPN or Direct Connect
- SSH Tunnel
What can I do next?
Here are a few resources to get started:
- To learn more about Red Hat Ansible Automation Platform on Azure, visit the following site.
- Try a hands-on self-paced lab of Red Hat Ansible Automation Platform on Azure.
- Visit other hands-on self-paced lab(s) on Red Hat Ansible Automation Platform.
- Check out the Red Hat Ansible Automation Platform on Azure documentation.
- Would you like to receive updates on Red Hat Ansible Automation Platform on Azure? Sign up here.
Acknowledgements
執筆者紹介
Scott Harwell is a Principal Product Manager at Red Hat for Ansible on Clouds. His focus is the delivery of Ansible Automation Platform offerings on hyperscaler cloud vendors such as Microsoft Azure and AWS. Prior to joining Red Hat, Scott held product management, development, and consulting roles for Oracle, AST Corporation, Tech Machine, and Volvo. Scott is a cloud enthusiast with experience and certifications across many cloud providers. He is passionate about automation and likes to find creative ways to improve IT, technical, and business processes.
類似検索
Master modern hybrid cloud security and scale with Red Hat updates
F5 BIG-IP Virtual Edition is now validated for Red Hat OpenShift Virtualization
Technically Speaking | Platform engineering for AI agents
Technically Speaking | Driving healthcare discoveries with AI
チャンネル別に見る
自動化
テクノロジー、チームおよび環境に関する IT 自動化の最新情報
AI (人工知能)
お客様が AI ワークロードをどこでも自由に実行することを可能にするプラットフォームについてのアップデート
オープン・ハイブリッドクラウド
ハイブリッドクラウドで柔軟に未来を築く方法をご確認ください。
セキュリティ
環境やテクノロジー全体に及ぶリスクを軽減する方法に関する最新情報
エッジコンピューティング
エッジでの運用を単純化するプラットフォームのアップデート
インフラストラクチャ
世界有数のエンタープライズ向け Linux プラットフォームの最新情報
アプリケーション
アプリケーションの最も困難な課題に対する Red Hat ソリューションの詳細
仮想化
オンプレミスまたは複数クラウドでのワークロードに対応するエンタープライズ仮想化の将来についてご覧ください