You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Simplify infrastructure deployment with Bicep parameters and rename global resource group (#793)
### Summary & Motivation
Replace inline Bicep parameter strings with structured .bicepparam files
to simplify deployment scripts and improve maintainability. This
eliminates manual parameter string construction and makes parameter
management cleaner.
- Add main-cluster.bicepparam file that reads all parameters from
environment variables
- Update deploy-cluster.sh to use `bicep build-params` command
- Export all variables instead of constructing inline parameter strings
- Rename global resource group from `pxp-stage` to `pxp-stage-global` to
clarify these are globally shared resources
- Rename all resource group variables to explicitly distinguish
`CLUSTER_RESOURCE_GROUP_NAME` vs `GLOBAL_RESOURCE_GROUP_NAME`
- Generate revision suffix in shell script using random hex to avoid
Bicep newGuid() what-if validation limitations
- Upgrade all Bicep modules to latest stable API versions
- Remove unsupported softDeletePolicy from Container Registry
- Suppress false positive BCP318 warnings in role assignment modules
- Display DNS configuration instructions during Plan phase
- Fix spelling errors in appGateway module name and issue templates
- Fix bug from previous change where database migration comments were
deleted across different self-contained systems
### Downstream projects
1. **Create new global resource group and move resources**
The global resource group has been renamed from
`{uniquePrefix}-{environment}` to `{uniquePrefix}-{environment}-global`
(e.g., `ppdemo-stage` → `ppdemo-stage-global`) for better clarity.
Resources keep their original names (e.g., `ppdemo-stage`).
- Create the new resource group `{uniquePrefix}-{environment}-global` in
Azure Portal
- Move these 5 resources using "Move to another resource group":
- Azure Container Registry (e.g., `ppdemostage`)
- Application Insights (e.g., `ppdemo-stage`)
- Log Analytics workspace (e.g., `ppdemo-stage`)
- Application Insights Smart Detection (action group)
- Smart detector alert rule (e.g., `ppdemo-stage-failure-anomalies`)
2. **Update self-contained system version exports**
In `cloud-infrastructure/cluster/deploy-cluster.sh`, update the resource
group variable name in your self-contained system version export (all
downstream projects have at least one self-contained system beyond
Account Management and Back Office):
```diff
-export YOUR_SELF_CONTAINED_SYSTEM_VERSION=$(get_active_version
"your-self-contained-system-api" $RESOURCE_GROUP_NAME)
+export YOUR_SELF_CONTAINED_SYSTEM_VERSION=$(get_active_version
"your-self-contained-system-api" $CLUSTER_RESOURCE_GROUP_NAME)
```
3. **Add revisionSuffix parameter to container app modules**
In `cloud-infrastructure/cluster/main-cluster.bicep`, add the
`revisionSuffix` parameter to your self-contained system container app
modules:
```diff
userAssignedIdentityName: yourSelfContainedSystemIdentityName
ingress: true
+ revisionSuffix: revisionSuffix
environmentVariables: yourSelfContainedSystemEnvironmentVariables
```
4. **(Optional) Migrate custom API keys and secrets to bicepparam**
Only needed if you have custom API keys, client secrets, or service
configurations beyond standard PlatformPlatform.
In `cloud-infrastructure/cluster/deploy-cluster.sh`, ensure custom
secrets are exported:
```diff
+export YOUR_CUSTOM_API_KEY
+export YOUR_CUSTOM_CLIENT_SECRET
```
In `cloud-infrastructure/cluster/main-cluster.bicepparam`, add entries
for custom parameters that were in the inline DEPLOYMENT_PARAMETERS
string:
```diff
+param yourCustomApiKey = readEnvironmentVariable('YOUR_CUSTOM_API_KEY')
+param yourCustomClientSecret =
readEnvironmentVariable('YOUR_CUSTOM_CLIENT_SECRET')
```
### Checklist
- [x] I have added tests, or done manual regression tests
- [x] I have updated the documentation, if necessary
ACTIVE_ACCOUNT_MANAGEMENT_VERSION=$(get_active_version "account-management-api"$RESOURCE_GROUP_NAME)# The version from the API is use for both API and Workers
45
-
ACTIVE_BACK_OFFICE_VERSION=$(get_active_version "back-office-api"$RESOURCE_GROUP_NAME)# The version from the API is use for both API and Workers
export ACCOUNT_MANAGEMENT_VERSION=$(get_active_version "account-management-api"$CLUSTER_RESOURCE_GROUP_NAME)# The version from the API is use for both API and Workers
40
+
export BACK_OFFICE_VERSION=$(get_active_version "back-office-api"$CLUSTER_RESOURCE_GROUP_NAME)# The version from the API is use for both API and Workers
46
41
47
-
az extension add --name application-insights --allow-preview true
# When initially creating the Azure Container App with SSL and a custom domain, we need to run the deployment three times (see https://github.com/microsoft/azure-container-apps/tree/main/docs/templates/bicep/managedCertificates):
58
-
# 1. On the initial run, the deployment will fail, providing instructions on how to manually create DNS TXT and CNAME records. After doing so, the workflow must be run again.
59
-
# 2. The second time, the DNS will be configured, and a certificate will be created. However, they will not be bound together, as this is a two-step process and they cannot be created in a single deployment.
60
-
# 3. The third deployment will bind the SSL Certificate to the Domain. This step will be triggered automatically.
64
+
# When initially creating the Azure Container App with SSL and a custom domain, the deployment may fail if DNS records are not configured.
65
+
# With bindingType: 'Auto' (API version 2025-07-01), certificates are created and bound in a single deployment.
66
+
# If the deployment fails, ensure DNS records are properly configured:
67
+
# - A TXT record: asuid.<domain> with the customDomainVerificationId value
68
+
# - A CNAME record: <domain> pointing to the container app's default domain
61
69
if [[ "$*"==*"--apply"* ]]
62
70
then
63
71
RED='\033[0;31m'
64
72
RESET='\033[0m'# Reset formatting
65
73
66
74
cleaned_output=$(echo "$output"| sed '/^WARNING/d'| sed '/^\/home\/runner\/work\//d')
67
75
# Check for the specific error message indicating that DNS Records are missing
68
-
if [[ $cleaned_output==*"InvalidCustomHostNameValidation"* ]] || [[ $cleaned_output==*"FailedCnameValidation"* ]]|| [[ $cleaned_output==*"-certificate' under resource group '$RESOURCE_GROUP_NAME' was not found"* ]];then
69
-
# Get details about the container apps environment. Although the creation of the container app fails, the verification ID on the container apps environment is consistent across all container apps.
70
-
env_details=$(az containerapp env show --name $RESOURCE_GROUP_NAME --resource-group $RESOURCE_GROUP_NAME)
71
-
76
+
if [[ $cleaned_output==*"InvalidCustomHostNameValidation"* ]] || [[ $cleaned_output==*"FailedCnameValidation"* ]];then
77
+
# Get details about the container apps environment to provide DNS configuration instructions
78
+
env_details=$(az containerapp env show --name $CLUSTER_RESOURCE_GROUP_NAME --resource-group $CLUSTER_RESOURCE_GROUP_NAME)
79
+
72
80
# Extract the customDomainVerificationId and defaultDomain from the container apps environment
# If the domain was not configured during the first run and we didn't receive any warnings about missing DNS entries, we trigger the deployment again to complete the binding of the SSL Certificate to the domain.
87
-
if [[ "$IS_DOMAIN_CONFIGURED"=="false" ]] && [[ "$DOMAIN_NAME"!="" ]];then
88
-
echo"Running deployment again to finalize setting up SSL certificate for $DOMAIN_NAME"
0 commit comments