Skip to content

Latest commit

 

History

History
113 lines (81 loc) · 11.7 KB

migrate-appgateway.md

File metadata and controls

113 lines (81 loc) · 11.7 KB

Migrating to Availability Zones Enabled Application Gateway

The frontend and backend application gateways deployed in CFT do not support availability zones.
Enabling availability zones on the existing application gateways will require downtime as the resources will be destroyed and recreated. The process below details the steps taken to replace the existing application gateways with new availablity zones enabled gateways without application downtime.

Traffic flow overview

Network flow diagram

Validate Button

Migration steps

NOTE: A change request is required for Production implementation

1. Create AZ-enabled frontend/backend application gateway resources

  • Identify available IP addresses (in the same appgw subnet as the existing gateways) for the new frontend and backend application gateways. Take note some environments (demo, perftest and aat) have two backend application gateway and will require 3 IP addresses in total

  • Update the environment .tfvars file and add values for the below variables

    frontend_agw_private_ip_address = "<frontend ip address>"
    backend_agw_private_ip_address = ["<backend ip address>"]

    See sbox example

  • Create Azure DevOps pipeline stages for the new frontendappgateway and backendappgateway components
    See sbox pipeline stages example

  • Run azure-platform-terraform pipeline plan and confirm the terraform plans for the new appgateway components are correct.
    Also confirm there are no changes in the terraform plans for the existing cftapps_cluster_lb and cftapps_cluster_lb_backend appgateway components

  • Run the azure-platform-terraform pipeline apply to create the new frontendappgateway and backendappgateway components

2. Create Azure Firewall and Palo Alto entries

Azure Firewall

  • Update the environment .tfvars configuration file and add an entry for the new frontendappgateway
    See sbox example
    Note:
    • name: Append -2 suffix to the environment name (though sbox example shown uses a -test suffix)
    • palo_ips: IP address for the new frontendappgateway. Specify same values for both uksouth and ukwest
    • index: Pick the next available number

Panorama

See Example Panorma PR

After merging PR for the changes above, confirm the hmcts.hub-terraform-hub-dmz pipeline run complete successfully without errors for the Azure Firewall and the `hmcts.hub-panorama-terraform pipeline run completes successfully without errors for Panorama

  • Confirm the following were created in Azure Firewall in both uksouth and ukwest
    • A public IP address associated with the regional Azure firewall
    • A destination NAT NAT rule collection entry translating inbound traffic (from Azure Front Door) to the newly created public IP to `frontendappgateway' private IP address
  • You now need to push out the panorama changes on the panoramas themselves.

3. Test frontendappgateway traffic routing

Prior to switching over traffic to the new application gateways, test the frontendappgateway by switching a single frontend application to route FrontDoor traffic through the new gateway

  • In the environment .tfvars configuration file, identify a suitable frontend application to use for testing. Speak to application team where necessary to make them aware of testing
  • Update the backend domain of the application above to the DNS name of the Azure Firewall public IP address created for the frontendappgateway.
    See Example PR
  • After PR merge and pipeline run completed, test connection to the Front Door URL for the application and confirm working as normal
  • Temporarily enable frontendappgateway diagnostics settings access logs and confirm application traffic for the switched applications can be seen in the logs (Note: It may take a few minutes before log entries start appearing)

4. Switchover FrontDoor traffic routing and Private DNS to new gateways

  • In the environment .tfvars configuration file, for each application whose backend domain points to theDNS name of the Azure Firewall public IP address of the existing frontend application gateway (Note: some applications such as APIM do not go via the application gateway), update the backend domain to DNS name of the Azure Firewall public IP address created for the new frontendappgateway

  • In the environment backend_lb_configuration.yaml file, for each gateway (some environments have two), update the private_ip_address to point to the new backendappgateway private iP address
    See Example PR

  • After merging PR for the changes above, confirm the Azure Platform Terraform and Azure Platform Terraform Global pipelines run complete successfully without errors

  • Confirm applications switched over are accessible as normal

  • Check applications traffic can be seen in the access logs for both frontend and backend application gateways

  • Disable previously-enabled application gateway access logs

5. Cleanup old application gateway resources

Application Gateway

  • Run azure-platform-terraform pipeline destroy with ONLY the old application gateways <env>_cftapps_cluster_lb and <env>_cftapps_cluster_backend_lb and Precheck stages selected

    Example destroy pipeline stages selection

    Validate Button

  • Confirm pipeline run completes successfully without errors and confirm the old application gateways and associated resources have been removed

Application Gateway Pipeline

  • Update the Azure DevOps pipeline configuration and remove the pipeline stages for the <env>_cftapps_cluster_lb and <env>-cftapps_cluster_lb_backend gateways (See Example PR)

Azure Firewall

  • Update the environment .tfvars configuration file with the changes below
    • Remove the new entry earlier created for the new frontend application gateway
    • Update the entry for the existing frontend application gateway and change the palo_ips to the new frontend application gateway
    • After merging PR for the changes above, confirm the hmcts.rdo-terraform-hub-dmz pipeline run complete successfully without errors

Panorama

See Example PR

After merging PR for the changes above, confirm the hmcts.rdo-terraform-hub-dmz pipeline run completes successfully without errors

Note: If the pipeline run above errors during removal of the Azure Firewall public IP address (see example error), manually remove the public IP address and re-run the pipeline