Public Cloud TechDocs Updates

[ThibaultBC]

As part of making Azure available for public cloud Ministry users, we need to make the following updates to TechDocs:

• [x] Draft a list of the technical information we want to add in support to Azure customers
• [x] Re-design the article / menu hierarchy to separate AWS and Azure documentation
• [x] Re-organize the article / menu to include cloud-agnostic information (ie. Getting Started, Provision a Project Set, etc.)

Once the technical documentation has been drafted, it can be reviewed by members of the DevOps team, in addition to involving Pilar in the review, before it is officially published.

Acceptance Criteria

Generated by Zenhub AI

• [x] Scenario: Drafting a list of technical information for Azure customers

  • Given the need to add technical information for Azure users
  • When the TechDocs team drafts a list of topics to cover
  • Then the list should be comprehensive and relevant to Azure users

• [x] Scenario: Redesigning article/menu hierarchy for AWS and Azure separation

  • Given the need to separate AWS and Azure documentation
  • When the TechDocs team redesigns the article/menu hierarchy
  • Then the new structure should clearly differentiate between AWS and Azure content

• [x] Scenario: Reorganizing articles for cloud-agnostic information

  • Given the need to include cloud-agnostic information in the documentation
  • When the TechDocs team reorganizes the article/menu hierarchy
  • Then the new structure should include sections for cloud-agnostic content, such as Getting Started and Provisioning a Project Set

• [ ] Scenario: Review of technical documentation by DevOps team and Pilar

  • Given the need to review the drafted technical documentation
  • When the DevOps team and Pilar review the documentation
  • Then their feedback should be incorporated into the final version before publication

[AErmie]

In the Tech Docs, we need to include a section of "be ware" for issues/challenges that could be experienced.

VNet Integration

One example is the issue with VNet Integration (with an App Service or Web App), and the AppServiceLink / serviceAssociationLinks remaining (after deleting the App Service), and therefore not being able to delete the associated Subnet.

AzAPI Terraform Provider (using azapi_update_resource)

Another example is if the end-users are using Terraform and in particular the AzAPI provider. The issue with this, per the note on the azapi_update_resource page, states:

This resource is used to add or modify properties on an existing resource. When delete azapi_update_resource, no operation will be performed, and these properties will stay unchanged. If you want to restore the modified properties to some values, you must apply the restored properties before deleting.

This means, changes to the azapi_update_resource resource may appear to apply changes (ie. remove properties/configurations previous added), but this doesn't actually apply those changes in Azure.

Private Endpoint DNS

We need to let the end-users know that when they create a Private Endpoint, a DNS A-record will be automatically created in ~10 minutes.

Access to Private Endpoint Resources

Some resources have been configured to restrict/deny public access (ie. Azure Cache for Redis, Azure SQL Database, CosmosDB, MariaDB servers, MySQL Flexible Servers, PostgreSQL Flexible Servers, Key Vault). To access and work with these specific resources, you need to use either Azure Bastion or Azure Virtual Desktop (AVD) from within the VNet.

[AErmie]

TechDocs file/folder hierarchy has been re-structured, along with initial Azure documentation written.

• Currently in the public-cloud-techdocs repo, under the azure-placeholder branch.

Ready for peer review and publishing.