Helm-optieparameters gebruiken om verwijdering bij installatiefouten te voorkomen
SNS-implementaties (Site Network Service) kunnen mislukken omdat een onderliggende NF-implementatie (Network Function) niet correct kan worden geïnstalleerd. Azure Operator Service Manager (AOSM) verwijdert standaard mislukte implementaties uit het beoogde Kubernetes-cluster om resources te behouden. Helm install
fouten vereisen vaak dat de resources op het cluster blijven bestaan om fouten op te sporen. In dit artikel wordt beschreven hoe u de NF ARM-sjabloon bewerkt om dit gedrag te overschrijven door de helm install --atomic
parameter in te stellen op false.
Vereisten
- U moet uw NF naar AOSM hebben ge onboardd met behulp van de Az CLI AOSM-extensie. In dit artikel wordt verwezen naar de mapstructuur en bestanden die door de CLI worden uitgevoerd en worden voorbeelden op basis van CLI weergegeven
- Helm-installatiefouten kunnen complex zijn. Foutopsporing vereist technische kennis van verschillende technologieën naast domeinkennis van uw NF
- Werkkennis van Helm
- Werkende kennis van Kubernetes- en kubectl-opdrachten
- Werkende kennis van het ophalen en pushen van artefacten naar Azure Container Registry
- U hebt de
Contributor
roltoewijzingen nodig voor de resourcegroep die het beheerde artefactarchief van de AOSM bevat - Een geschikte IDE, zoals Visual Studio Code
- De ORAS CLI
Belangrijk
Het wordt sterk aanbevolen dat u hebt getest dat een helm install
van uw Helm-pakket slaagt in uw met Arc verbonden Kubernetes-doelomgeving voordat u een implementatie uitvoert met behulp van AOSM.
Overschrijven --atomic
voor één Helm-grafiek NF
In deze sectie wordt uitgelegd hoe u een NF overschrijft --atomic
die bestaat uit één Helm-grafiek.
De NF BICEP-sjabloon zoeken en bewerken
Navigeer naar de
nsd-cli-output
map, open deartifacts
map en open het<nf-arm-template>.bicep
bestand.<nf-arm-template>
is geconfigureerd in het NSD-invoerbestand van de Az AOSM CLI-extensie. U kunt bevestigen dat u het juiste bestand hebt door te vergelijken met de volgende voorbeeldsjabloon voor een fictieve netwerkfunctie van Contoso in containers (CNF).@secure() param configObject object var resourceGroupId = resourceGroup().id var identityObject = (configObject.managedIdentityId == '') ? { type: 'SystemAssigned' } : { type: 'UserAssigned' userAssignedIdentities: { '${configObject.managedIdentityId}': {} } } var nfdvSymbolicName = '${configObject.publisherName}/${configObject.nfdgName}/${configObject.nfdv}' resource nfdv 'Microsoft.Hybridnetwork/publishers/networkfunctiondefinitiongroups/networkfunctiondefinitionversions@2023-09-01' existing = { name: nfdvSymbolicName scope: resourceGroup(configObject.publisherResourceGroup) } resource nfResource 'Microsoft.HybridNetwork/networkFunctions@2023-09-01' = [for (values, i) in configObject.deployParameters: { name: '${configObject.nfdgName}${i}' location: configObject.location identity: identityObject properties: { networkFunctionDefinitionVersionResourceReference: { id: nfdv.id idType: 'Open' } nfviType: 'AzureArcKubernetes' nfviId: (configObject.customLocationId == '') ? resourceGroupId : configObject.customLocationId allowSoftwareUpdate: true configurationType: 'Open' deploymentValues: string(values) } }]
Zoek de naam van de netwerkfunctietoepassing door naar de
cnf-cli-output
map te navigeren, denfDefinition
map te openen en de waarde te kopiëren van de enige vermelding in de matrix networkFunctionApplications in denfdv
resource. Bevestig dat u de juiste waarde hebt door het volgende fictieve BICEP-codefragment van Contoso te vergelijken. In dit geval isContoso
de naam van de netwerkfunctietoepassing.resource nfdv 'Microsoft.Hybridnetwork/publishers/networkfunctiondefinitiongroups/networkfunctiondefinitionversions@2023-09-01' = { parent: nfdg name: nfDefinitionVersion location: location properties: { deployParameters: string(loadJsonContent('deployParameters.json')) networkFunctionType: 'ContainerizedNetworkFunction' networkFunctionTemplate: { nfviType: 'AzureArcKubernetes' networkFunctionApplications: [ { artifactType: 'HelmPackage' name: 'Contoso'
Bewerk de sjabloon om de standaard-helm-installatieoptie
--atomic
te overschrijven door de volgende configuratie toe te voegen aan denfResource
eigenschappen in de NF ARM-sjabloon:roleOverrideValues: ['{"name": "Contoso-one", "deployParametersMappingRuleProfile": {"applicationEnablement": "Enabled", "helmMappingRuleProfile": {"options": {"installOptions": {"atomic": "false"}},{"upgradeOptions": {"atomic": "false"}}}}}']
Controleer of u deze bewerking correct hebt aangebracht door het volgende codefragment van het contoso-voorbeeld NF te vergelijken
resource nfResource 'Microsoft.HybridNetwork/networkFunctions@2023-09-01' = [for (values, i) in configObject.deployParameters: {
name: '${configObject.nfdgName}${i}'
location: configObject.location
identity: identityObject
properties: {
networkFunctionDefinitionVersionResourceReference: {
id: nfdv.id
idType: 'Open'
}
nfviType: 'AzureArcKubernetes'
nfviId: (configObject.customLocationId == '') ? resourceGroupId : configObject.customLocationId
allowSoftwareUpdate: true
configurationType: 'Open'
deploymentValues: string(values)
roleOverrideValues: [
'{"name":"Contoso-one","deployParametersMappingRuleProfile":{"helmMappingRuleProfile":{"options":{"installOptions":{"injectArtifactStoreDetails":"true", "atomic": "false"},"upgradeOptions":{"injectArtifactStoreDetails":"true","atomic": "false"}}}}}'
]}}]
Bouw de bewerkte ARM-sjabloon en upload deze naar de Artefact Store
Navigeer naar de
nsd-cli-output/artifacts
map die is gemaakt met deaz aosm nsd build
opdracht en bouw de ARM-sjabloon voor de netwerkfunctie op basis van het BICEP-bestand dat is gegenereerd door de CLI.bicep build <nf-name>.bicep
Genereer tokenreferenties van het artefactmanifest dat in de
az aosm nsd publish
opdracht is gemaakt.Belangrijk
U moet het artefactmanifest gebruiken dat in de
az aosm nsd publish
opdracht is gemaakt. De NF ARM-sjabloon wordt alleen gedeclareerd in dat manifest, dus alleen het bereiktoewijzingstoken dat door dit manifest wordt gegenereerd, kunt u de NF ARM-sjabloon pushen (of ophalen) naar de Artifact Store.az rest --method POST --url 'https://management.azure.com/subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.HybridNetwork/publishers/<publisher>/artifactStores/<artifact-store>/artifactManifests/<artifactManifest>/listCredential?api-version=2023-09-01'
Meld u aan bij de door AOSM beheerde ACR. De door AOSM beheerde ACR-naam vindt u in het overzicht van de Artefact Store-resource in de Azure-portal. De gebruikersnaam en het wachtwoord vindt u in de uitvoer van de vorige stap.
oras login <aosm-managed-acr-name>.azurecr.io --username <username> --password <scope map token>
Gebruik ORAS om de ARM-sjabloon voor netwerkfuncties te uploaden naar de AOSM managed Azure Container Registry (ACR). De
<arm-template-version>
artefacttag moet een1.0.0
indeling hebben. De<arm-template-name>
en<arm-template-version>
moeten overeenkomen met de waarden in het artefactmanifest dat in deaz aosm nsd publish
opdracht is gemaakt.
Overschrijven --atomic
voor een NF-grafiek met meerdere helmen
Veel complexe NF's zijn opgebouwd uit meerdere Helm-grafieken. Deze NF's worden uitgedrukt in de versie van de netwerkfunctiedefinitie (NFDV) met meerdere netwerkfunctietoepassingen en worden geïnstalleerd met meerdere helm install
opdrachten: één per Helm-grafiek.
Het proces voor het overschrijven --atomic
van een multi-helm NF is hetzelfde als voor één Helm NF, afgezien van de bewerking die is aangebracht in de ARM-sjabloon.
De fictieve multi-helm NF, Contoso-multi-helm, bestaat uit drie Helm-grafieken. De NFDV heeft drie netwerkfunctietoepassingen. Eén netwerkfunctietoepassing wordt toegewezen aan één Helm-grafiek. Voor deze netwerkfunctietoepassingen is een naameigenschap ingesteld op Contoso-one
, Contoso-two
respectievelijk Contoso-three
. Hier volgt een voorbeeldfragment van de NFDV die deze netwerkfunctie definieert.
resource nfdv 'Microsoft.Hybridnetwork/publishers/networkfunctiondefinitiongroups/networkfunctiondefinitionversions@2023-09-01' = {
parent: nfdg
name: nfDefinitionVersion
location: location
properties: {
deployParameters: string(loadJsonContent('deployParameters.json'))
networkFunctionType: 'ContainerizedNetworkFunction'
networkFunctionTemplate: {
nfviType: 'AzureArcKubernetes'
networkFunctionApplications: [
{
artifactType: 'HelmPackage'
name: 'Contoso-one'
...
},
{
artifactType: 'HelmPackage'
name: 'Contoso-two'
...
},
{
artifactType: 'HelmPackage'
name: 'Contoso-three'
...
}]
}
}
}
De --atomic
parameter kan onafhankelijk van elkaar worden overschreven voor elk van deze netwerkfunctietoepassingen. Hier volgt een voorbeeld van een NF BICEP-sjabloon die wordt overschreven --atomic
voor Contoso-one
false
en Contoso-two
, maar wordt ingesteld atomic
op waar voor Contoso-three
.
resource nfResource 'Microsoft.HybridNetwork/networkFunctions@2023-09-01' = [for (values, i) in configObject.deployParameters: {
name: '${configObject.nfdgName}${i}'
location: configObject.location
identity: identityObject
properties: {
networkFunctionDefinitionVersionResourceReference: {
id: nfdv.id
idType: 'Open'
}
nfviType: 'AzureArcKubernetes'
nfviId: (configObject.customLocationId == '') ? resourceGroupId : configObject.customLocationId
allowSoftwareUpdate: true
configurationType: 'Open'
deploymentValues: string(values)
roleOverrideValues: [
'{"name":"Contoso-one","deployParametersMappingRuleProfile":{"helmMappingRuleProfile":{"options":{"installOptions":{"injectArtifactStoreDetails":"true", "atomic": "false"},"upgradeOptions":{"injectArtifactStoreDetails":"true","atomic": "false"}}}}}'
'{"name":"Contoso-two","deployParametersMappingRuleProfile":{"helmMappingRuleProfile":{"options":{"installOptions":{"injectArtifactStoreDetails":"true", "atomic": "false"},"upgradeOptions":{"injectArtifactStoreDetails":"true","atomic": "false"}}}}}'
'{"name":"Contoso-three","deployParametersMappingRuleProfile":{"helmMappingRuleProfile":{"options":{"installOptions":{"injectArtifactStoreDetails":"true", "atomic": "false"},"upgradeOptions":{"injectArtifactStoreDetails":"true","atomic": "false"}}}}}'
]}}]
Volgende stappen
U kunt nu de SNS-implementatie opnieuw proberen. U kunt de implementatie opnieuw verzenden via ARM, BICEP of de AOSM REST API. U kunt de mislukte SNS ook verwijderen via het SNS-overzicht van Azure Portal en opnieuw implementeren volgens de quickstart van de operator, waarbij u de quickstart-NF-parameters vervangt door de parameters voor uw netwerkfunctie. De Helm-releases die in het Kubernetes-cluster zijn geïmplementeerd, worden niet verwijderd bij een fout. Foutopsporing in SNS-implementatie beschrijft een toolkit voor het opsporen van veelvoorkomende helm-installatiefouten.