README ¶
tf-azurerm-module_collection-application_gateway
Overview
This module uses a public module to deploy Application Gateway.
Notes:
-
claranet/app-gateway/azurerm
public module - version7.7.2
does not provide ability supportBasic
sku for Application Gateway. It just supportsStandard SKU
. This means, that public IP address associated with the Application Gateway needs to be withStandard
SKU as well. Forazurerm_public_ip
resource, Availability Zones are only supported with a Standard SKU and in select regions at this time(as of 04/09/2024). Standard SKU Public IP Addresses that do not specify a zone are not zone-redundant by default. Hence creating Application Gateway is not possible inWest US
region at this time(as of 04/09/2024). The suppored regions can be found here Reference documentation: https://registry.terraform.io/providers/hashicorp/azurerm/latest/docs/resources/public_ip -
During deployment of Application Gateway, there was error below:
Original Error: Code="ApplicationGatewaySubnetInboundTrafficBlockedByNetworkSecurityGroup" Message="Network security group xxx blocks incoming internet traffic on ports 65200 - 65535 to subnet xxx
In order to fix this error, the
network security group rule
is added to thensg
for thesubnet
where Application Gateway is deployed.{ name = "AllowVnetInBound" priority = 100 direction = "Inbound" access = "Allow" protocol = "*" source_port_range = "*" destination_port_ranges = ["65200-65535"] source_address_prefix = "*" destination_address_prefix = "*" }
Reference documentation:
-
Can we deploy Application Gateway with
private IP address
only, without giving it apublic IP address
? Yes. There are additional features available along with just providing theprivate IP address
only. The features are mentioned here. However since these features are in private/public preview, they will not be available on Azure government cloud(as of 04/16/2024). -
Why is there need of having
public IP address
along withprivate IP address
for Application Gateway deployment?
Application Gateway v2 currently supports the following combinations:
- Private IP address and public IP address
- Public IP address only
- Private IP address only (preview)
It is discussed in question above as to why Private IP address only (preview)
can not be considered yet. For Private IP address and public IP address
combination there are certain restrictions:
- All Application Gateways v2 deployments must contain public facing frontend IP configuration to enable communication to the Gateway Manager service tag.
- Network Security Group associations require rules to allow inbound access from GatewayManager and Outbound access to Internet.
- When introducing a default route (0.0.0.0/0) to forward traffic anywhere other than the Internet, metrics, monitoring, and updates of the gateway result in a failed status.
Point number 1 answers the question. For references check these documenation links:
-
https://learn.microsoft.com/en-us/azure/application-gateway/configuration-frontend-ip
-
When creating Application Gateway, what is the need of adding specifc rules on network security group attached to the subnet in which Application Gateway resides?
Point number 2 and 3 in answer of the above question, help answering this question. More documentation references can be found [here](https://learn.microsoft.com/en-us/azure/application-gateway/configuration-infrastructure#network-security-groups)
- We can user
private links + private endpoints
to make Application Gateway privately accessible. What is the difference in the two mechanisms(using a private IP vs using private links)? Private Link allows you to extend private connectivity to Application Gateway via a Private Endpoint in the following scenarios:
- VNet in the same or different region from Application Gateway
- VNet in the same or different subscription from Application Gateway
- VNet in the same or different subscription and the same or different Microsoft Entra tenant from Application Gateway
If any of the features below are applicable/needed we should be using `private links + private endpoints`. `private IP` deployment will not be useful for these scenarios.
References can be found here:
1. https://learn.microsoft.com/en-us/azure/application-gateway/private-link
2. https://learn.microsoft.com/en-us/azure/application-gateway/private-link-configure?tabs=portal
Pre-Commit hooks
.pre-commit-config.yaml file defines certain pre-commit
hooks that are relevant to terraform, golang and common linting tasks. There are no custom hooks added.
commitlint
hook enforces commit message in certain format. The commit contains the following structural elements, to communicate intent to the consumers of your commit messages:
- fix: a commit of the type
fix
patches a bug in your codebase (this correlates with PATCH in Semantic Versioning). - feat: a commit of the type
feat
introduces a new feature to the codebase (this correlates with MINOR in Semantic Versioning). - BREAKING CHANGE: a commit that has a footer
BREAKING CHANGE:
, or appends a!
after the type/scope, introduces a breaking API change (correlating with MAJOR in Semantic Versioning). A BREAKING CHANGE can be part of commits of any type. footers other than BREAKING CHANGE: may be provided and follow a convention similar to git trailer format. - build: a commit of the type
build
adds changes that affect the build system or external dependencies (example scopes: gulp, broccoli, npm) - chore: a commit of the type
chore
adds changes that don't modify src or test files - ci: a commit of the type
ci
adds changes to our CI configuration files and scripts (example scopes: Travis, Circle, BrowserStack, SauceLabs) - docs: a commit of the type
docs
adds documentation only changes - perf: a commit of the type
perf
adds code change that improves performance - refactor: a commit of the type
refactor
adds code change that neither fixes a bug nor adds a feature - revert: a commit of the type
revert
reverts a previous commit - style: a commit of the type
style
adds code changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc) - test: a commit of the type
test
adds missing tests or correcting existing tests
Base configuration used for this project is commitlint-config-conventional (based on the Angular convention)
If you are a developer using vscode, this plugin may be helpful.
detect-secrets-hook
prevents new secrets from being introduced into the baseline. TODO: INSERT DOC LINK ABOUT HOOKS
In order for pre-commit
hooks to work properly
- You need to have the pre-commit package manager installed. Here are the installation instructions.
pre-commit
would install all the hooks when commit message is added by default except forcommitlint
hook.commitlint
hook would need to be installed manually using the command below
pre-commit install --hook-type commit-msg
To test the resource group module locally
- For development/enhancements to this module locally, you'll need to install all of its components. This is controlled by the
configure
target in the project'sMakefile
. Before you can runconfigure
, familiarize yourself with the variables in theMakefile
and ensure they're pointing to the right places.
make configure
This adds in several files and directories that are ignored by git
. They expose many new Make targets.
- THIS STEP APPLIES ONLY TO MICROSOFT AZURE. IF YOU ARE USING A DIFFERENT PLATFORM PLEASE SKIP THIS STEP. The first target you care about is
env
. This is the common interface for setting up environment variables. The values of the environment variables will be used to authenticate with cloud provider from local development workstation.
make configure
command will bring down azure_env.sh
file on local workstation. Devloper would need to modify this file, replace the environment variable values with relevant values.
These environment variables are used by terratest
integration suit.
Service principle used for authentication(value of ARM_CLIENT_ID) should have below privileges on resource group within the subscription.
"Microsoft.Resources/subscriptions/resourceGroups/write"
"Microsoft.Resources/subscriptions/resourceGroups/read"
"Microsoft.Resources/subscriptions/resourceGroups/delete"
Then run this make target to set the environment variables on developer workstation.
make env
- The first target you care about is
check
.
Pre-requisites
Before running this target it is important to ensure that, developer has created files mentioned below on local workstation under root directory of git repository that contains code for primitives/segments. Note that these files are azure
specific. If primitive/segment under development uses any other cloud provider than azure, this section may not be relevant.
- A file named
provider.tf
with contents below
provider "azurerm" {
features {}
}
- A file named
terraform.tfvars
which contains key value pair of variables used.
Note that since these files are added in gitignore
they would not be checked in into primitive/segment's git repo.
After creating these files, for running tests associated with the primitive/segment, run
make check
If make check
target is successful, developer is good to commit the code to primitive/segment's git repo.
make check
target
- runs
terraform commands
tolint
,validate
andplan
terraform code. - runs
conftests
.conftests
make surepolicy
checks are successful. - runs
terratest
. This is integration test suit. - runs
opa
tests
Requirements
Name | Version |
---|---|
terraform | <= 1.5.5 |
azurerm | ~> 3.77 |
random | ~> 3.6 |
Providers
No providers.
Modules
Name | Source | Version |
---|---|---|
app_gateway | claranet/app-gateway/azurerm | 7.7.2 |
Resources
No resources.
Inputs
Name | Description | Type | Default | Required |
---|---|---|---|---|
app_gateways | Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. | map(object({ |
n/a | yes |
Outputs
Name | Description |
---|---|
appgw_backend_address_pool_ids | List of backend address pool Ids. |
appgw_backend_http_settings_ids | List of backend HTTP settings Ids. |
appgw_backend_http_settings_probe_ids | List of probe Ids from backend HTTP settings. |
appgw_custom_error_configuration_ids | List of custom error configuration Ids. |
appgw_frontend_ip_configuration_ids | List of frontend IP configuration Ids. |
appgw_frontend_port_ids | List of frontend port Ids. |
appgw_gateway_ip_configuration_ids | List of IP configuration Ids. |
appgw_http_listener_frontend_ip_configuration_ids | List of frontend IP configuration Ids from HTTP listeners. |
appgw_http_listener_frontend_port_ids | List of frontend port Ids from HTTP listeners. |
appgw_http_listener_ids | List of HTTP listener Ids. |
appgw_id | The ID of the Application Gateway. |
appgw_name | The name of the Application Gateway. |
appgw_nsg_id | The ID of the network security group from the subnet where the Application Gateway is attached. |
appgw_nsg_name | The name of the network security group from the subnet where the Application Gateway is attached. |
appgw_public_ip_address | The public IP address of Application Gateway. |
appgw_public_ip_domain_name | Domain Name part from FQDN of the A DNS record associated with the public IP. |
appgw_public_ip_fqdn | Fully qualified domain name of the A DNS record associated with the public IP. |
appgw_redirect_configuration_ids | List of redirect configuration Ids. |
appgw_request_routing_rule_backend_address_pool_ids | List of backend address pool Ids attached to request routing rules. |
appgw_request_routing_rule_backend_http_settings_ids | List of HTTP settings Ids attached to request routing rules. |
appgw_request_routing_rule_http_listener_ids | List of HTTP listener Ids attached to request routing rules. |
appgw_request_routing_rule_ids | List of request routing rules Ids. |
appgw_request_routing_rule_redirect_configuration_ids | List of redirect configuration Ids attached to request routing rules. |
appgw_request_routing_rule_rewrite_rule_set_ids | List of rewrite rule set Ids attached to request routing rules. |
appgw_request_routing_rule_url_path_map_ids | List of URL path map Ids attached to request routing rules. |
appgw_ssl_certificate_ids | List of SSL certificate Ids. |
appgw_subnet_id | The ID of the subnet where the Application Gateway is attached. |
appgw_subnet_name | The name of the subnet where the Application Gateway is attached. |
appgw_url_path_map_default_backend_address_pool_ids | List of default backend address pool Ids attached to URL path maps. |
appgw_url_path_map_default_backend_http_settings_ids | List of default backend HTTP settings Ids attached to URL path maps. |
appgw_url_path_map_default_redirect_configuration_ids | List of default redirect configuration Ids attached to URL path maps. |
appgw_url_path_map_ids | List of URL path map Ids. |