How to address IaC shortcomings – Part 5?
A previous article discussed a resolution to IaC shortcomings for declaring
resources with configuration not yet supported by an IaC repository. This
article discusses another scenario where IaC does not suffice and some actions
are usually taken outside via pipeline automations and management portal usage.
We discuss the naming of app services that must be put behind an application
gateway for traffic consolidation and restricting direct access to the app
services.
Creating
custom names for your Azure resources can be:
1.
For usage from WWW:
Step 1.
Make sure that your Azure resource has public IP connectivity to begin with,
otherwise internal names is outlined in the section “For usage in vnet”.
Step 2.
Specify an
A record in your domain provider
with the
following values:
Hostname:
<just the hostname part of the default name for your public Azure resource,
for eg. App1.azurewebsites.net will have a hostname app1>
IP: The
public ip address from Step 1
Domain
Name: <cradle>.company.com
AppID :
<CostCenterAppId>
User:
<your msid>
Admin:
AZU_DSI_AZURE_ADMINS
Do not
select Force flag or PTR record.
Click
Continue
Step 3.
Specify a CNAME record if you want to reach resources behind the domain you
just specified. Note that domains like projectapps.com instead of company.com
will force you to create a new A record. If you are not sure whether you want
to create an A record or a CNAME record, visit the custom domains feature of
your Azure resource, select the “All other domain services” from add custom
domain page and enter any domain you like. It will show you two records that
you need to have, one of which is an A record or a CNAME record and the other
is a TXT record. The TXT record is useful only for validation and once the domain
is verified, you can even remove the TXT record. Notice that we are indeed
doing the same thing with Steps.2 and 4 in our Optum domain provider.
Step 4.
Specify the TXT record in the domain provider with the following values.
Hostname:
asuid <this is a reserved name>
Type: TXT
VALUE:
<domain-identifier-from-the-Azure resource>
You could
additionally specify a TXT record with the following values, to improve
validation because Azure and external providers might have different validation
schemes:
Hostname:
asverify<this is a reserved name>
TYPE: TXT
VALUE:
<default-public-name-that-the-Azure-resource-was-created-with>
At present,
you don’t need to create any more DNS records.
Step 5.
Validate the records you have added. Go to: https://dnslookup.online or any toolbox that generates a DIG output and
specify the name you have just created in a fully-qualified manner. Wait for
the report to show up. Remember that records can take up anywhere from say 1 to
48 hours to fully propagate.
2.
For usage in VNet:
Names
associated with IP addresses do not always need to be registered to nameservers
that participate in universal www name resolutions. This is where an Azure DNS
resource helps to resolve names. It is also capable of conditionally forwarding
dns queries from a virtual network to on-premises DNS servers and other target
DNS servers.
To create
an internal name resolution, you will need an A record and a TXT record.
Step 1. Go
to Azure DNS from the Azure Portal search bar and create a DNS resource in the
same subscription and resource group as the resources you are naming. The name
of the DNS resource will be the domain name you want to give to your resource.
Step 2.
Create an A record / CNAME record as decided by Step 3 in preceding section.
Create the
A record with the following value:
Hostname:
just the name of the resource without the domain qualifier. The domain name is
added automatically.
TYPE: A
VALUE:
<default-public-name-that-the-Azure-resource-was-created-with>
Step 3:
Create a TXT record with the following value:
Hostname:
asuid <reserved name>
TYPE: TXT
VALUE:
<domain-identifier-from-the-Azure-Resource>
Step 4:
Create another TXT record with the following value:
Hostname:
asverify <reserved name>
TYPE: TXT
VALUE:
<default-public-name-that-the-Azure-resource-was-created-with>
Step 5.
Validate the records you have added. Go to: https://dnslookup.online or any toolbox that generates a DIG output and
specify the name you have just created in a fully qualified manner. Wait for
the report to show up. Remember that records can take up anywhere from say 1 to
48 hours to fully propagate.
At present,
you don’t need to create any more DNS records.
A note for
application gateway and app services:
Initially
the A record is registered for app service and the custom name setup for the
resource by verifying in the portal.
Then the A record is modified to take the address of the app gateway.
No comments:
Post a Comment