Dela via

Kom igång med säkra uppgraderingsmetoder

  • Artikel

Översikt

Den här artikeln beskriver hur du uppgraderar säkerhetsuppgraderingar i Azure Operator Service Manager (AOSM). Den här funktionsuppsättningen gör det möjligt för en slutanvändare att på ett säkert sätt utföra komplexa uppgraderingar av CNF-arbetsbelastningar som finns på Azure Operator Nexus, i enlighet med kraven för partner-ISSU, där så är tillämpligt. Leta efter framtida artiklar i dessa tjänster för att utöka SUP-funktioner.

Introduktion

En viss nätverkstjänst som stöds av Azure Operator Service Manager består av en till många containerbaserade nätverksfunktioner (CNFs) som med tiden kräver programuppdateringar. För varje uppdatering är det nödvändigt att köra en till många helm-åtgärder, uppgradera beroende nätverksfunktionsprogram (NfApps), i en viss ordning, på ett sätt som minst påverkar nätverkstjänsten. I Azure Operator Service Manager representerar safe upgrade practices en uppsättning funktioner som kan automatisera de CNF-åtgärder som krävs för att uppdatera en nätverkstjänst på Azure Operator Nexus.

  • SNS Reput Update – Kör helm-uppgraderingsåtgärden för alla NfApps i NFDV.
  • Nexus Platform – Stöd för SNS-beräkningsåtgärder på Nexus-plattformsmål.
  • Tidsgränser för åtgärden – Möjlighet att ange tidsgränser för driften för varje NfApp-åtgärd.
  • Synkrona åtgärder – Möjlighet att köra en seriell NfApp-åtgärd i taget.
  • Pausa vid fel – Baserat på flagga anger du felbeteende till återställning endast den senaste NfApp-åtgärden.
  • Testverifiering med ett diagram – Köra en helm-teståtgärd efter en skapande eller uppdatering.
  • Omstrukturerat SNS-reput – Förbättrade metoder, lägger till uppdateringsordning och rensningskontroll.

Uppgraderingsmetod

Om du vill uppdatera en befintlig Azure Operator Service Manager-platsnätverkstjänst (SNS) kör operatorn en begäran om uppdatering av dataflöde mot den distribuerade SNS-resursen. Om SNS innehåller CNFs med flera NfApps, aktiveras begäran över alla NfApps som definierats i nätverksfunktionsdefinitionsversionen (NFDV). Som standard, i den ordning, som de visas, eller valfritt i den ordning som definieras av Parametern UpdateDependsOn.

För varje NfApp har begäran om uppdatering av reput stöd för att öka en helm-diagramversion, lägga till/ta bort helm-värden och/eller lägga till/ta bort NfApps. Tidsgränser kan anges per NfApp, baserat på kända tillåtna körningar, men NfApps kan bara bearbetas i serieordning, en efter en. Uppdatering av reput implementerar följande bearbetningslogik:

  • NfApps bearbetas efter antingen updateDependsOn-ordning eller i den sekventiella ordning de visas.
  • NfApps med parametern "applicationEnabled" inställd på att inaktivera hoppas över.
  • NFApps som distribueras, men som inte refereras till av den nya NFDV:n, tas bort.
  • NFApps som är vanliga mellan gamla och nya NFDV uppgraderas.
  • NFApps som bara finns i den nya NFDV:n installeras.

För att säkerställa resultat stöds NfApp-testning med helm, antingen helm-uppgradering före/efter-tester eller fristående helm-tester. För fel före/efter tester respekteras atomparametern. Med atomic/true återställs det misslyckade diagrammet. Med atomic/false körs ingen återställning. För fristående helm-tester har parametern rollbackOnTestFailure vi respekterat. Med rollbackOnTestFailure/true återställs det misslyckade diagrammet. Med rollbackOnTestFailure/false körs ingen återställning.

Förutsättningar

När du planerar för en uppgradering med Hjälp av Azure Operator Service Manager måste du uppfylla följande krav före uppgraderingskörningen för att optimera den tid som ägnas åt uppgraderingen.

  • Registrera uppdaterade artefakter med hjälp av utgivar- och/eller designerarbetsflöden.

    • Publisher, store, network service design (NSDg) och network function design group (NFDg) är statiska och behöver inte ändras.
      • Ett nytt artefaktmanifest behövs för att lagra de nya diagrammen och bilderna. Mer information finns i registreringsdokumentationen för information om hur du laddar upp nya diagram och bilder.
    • Ny NFDV- och nätverkstjänstdesignversion (NSDV) behövs under befintlig NFDg och NSDg.
      • Vi går igenom grundläggande ändringar av NFDV i avsnittet steg för steg.
      • Ny NSDV krävs endast om en ny version av konfigurationsgruppsschemat (CGS) introduceras.
    • Vid behov, nya CGS.
      • Krävs om en uppgradering introducerar nya exponerade konfigurationsparametrar.

  • Skapa uppdaterade artefakter med operatorarbetsflödet.

    • Om det behövs skapar du nya konfigurationsgruppsvärden (CGV:er) baserat på nya CGS.
    • Återanvänd och skapa nyttolast genom att bekräfta befintliga plats- och platsnätverkstjänstobjekt.

  • Uppdatera mallar för att säkerställa att uppgraderingsparametrar anges baserat på förtroende för uppgraderingen och önskat felbeteende.

    • Inställningar som används för produktion kan utelämna information om fel, medan inställningar som används för felsökning eller testning kan välja att exponera informationen.

Uppgraderingsprocedur

Följ följande process för att utlösa en uppgradering med Azure Operator Service Manager.

Skapa ny NFDV-resurs

För nya NFDV-versioner måste det vara i ett giltigt SemVer-format, där endast högre inkrementella värden för uppdateringar av korrigeringar och mindre versioner tillåts. En lägre NFDV-version tillåts inte. Med en CNF som distribueras med NFDV 2.0.0 kan den nya NFDV vara av version 2.0.1 eller 2.1.0, men inte 1.0.0 eller 3.0.0.

Uppdatera nya NFDV-parametrar

Helm-diagramversioner kan uppdateras eller Helm-värden kan uppdateras eller parametriseras efter behov. Nya NfApps kan också läggas till där de inte fanns i distribuerad version.

Uppdatera NFDV för önskad NfApp-order

UpdateDependsOn är en NFDV-parameter som används för att ange ordningen på NfApps under uppdateringsåtgärder. Om UpdateDependsOn inte tillhandahålls används serieordning av CNF-program som visas i NFDV.

Uppdatera NFDV för önskat uppgraderingsbeteende

Se till att ange önskade CNF-programtimeouter, atomparametern och parametern rollbackOnTestFailure. Det kan vara användbart att ändra dessa parametrar över tid när mer förtroende uppnås i uppgraderingen.

Utfärda SNS-reput

När registreringen är klar skickas reput-åtgärden. Beroende på antalet, storleken och komplexiteten hos NfApps kan det ta lite tid att slutföra reput-åtgärden (flera timmar).

Granska resultat från reput

Om dataflödet rapporterar ett lyckat resultat är uppgraderingen klar och användaren bör verifiera tjänstens tillstånd och tillgänglighet. Om dataflödet rapporterar ett fel följer du stegen i avsnittet återställning av uppgraderingsfel för att fortsätta.

Återförsöksprocedur

I fall där en uppdatering av ett reput misslyckas kan följande process följas för att försöka utföra åtgärden igen.

Diagnostisera misslyckad NfApp

Lös rotorsaken till NfApp-fel genom att analysera loggar och annan felsökningsinformation.

Hoppa över slutförda diagram manuellt

När du har åtgärdat den misslyckade NfApp-åtgärden, men innan du försöker utföra ett nytt uppgraderingsförsök, bör du överväga att ändra parametern applicationEnablement för att påskynda återförsöksbeteendet. Den här parametern kan anges som false, där en NfApp ska hoppas över. Den här parametern kan vara användbar om en NfApp inte kräver någon uppgradering.

Utfärda SNS-reput retry (upprepa tills det lyckas)

Som standard försöker reput-reput NfApps i den deklarerade uppdateringsordningen, såvida de inte hoppas över med hjälp av flaggan applicationEnablement.

Så här använder du applicationEnablement

I NFDV-resursen finns egenskapen applicationEnablement of type enum under deployParametersMappingRuleProfile, som tar värden: Okänd, Aktiverad eller inaktiverad. Den kan användas för att exkludera NfApp-åtgärder under NF-distributionen.

Publisher-ändringar

För egenskapen applicationEnablement har utgivaren två alternativ: ange antingen ett standardvärde eller parameterisera det.

Exempel på NFDV

NFDV används av utgivaren för att ange standardvärden för applicationEnablement.

{ 
      "location":"<location>", 
      "properties": {
      "networkFunctionTemplate": {
        "networkFunctionApplications": [
          {
            "artifactProfile": {
              "helmArtifactProfile": { 
                "var":"var"
              },
              "artifactStore": {
                "id": "<artifactStore id>"
              }
            },
            "deployParametersMappingRuleProfile": {
              "helmMappingRuleProfile": {
                "releaseNamespace": "{deployParameters.role1releasenamespace}",
                "releaseName": "{deployParameters.role1releasename}"
              },
              "applicationEnablement": "Enabled"
            },
            "artifactType": "HelmPackage",
            "dependsOnProfile": "null",
            "name": "hellotest"
          },
          {
            "artifactProfile": {
              "helmArtifactProfile": {
                 "var":"var"
              },
              "artifactStore": {
                "id": "<artifactStore id>"
              }
            },
            "deployParametersMappingRuleProfile": {
              "helmMappingRuleProfile": {
                "releaseNamespace": "{deployParameters.role2releasenamespace}",
                "releaseName": "{deployParameters.role2releasename}"
              },
              "applicationEnablement": "Enabled"
            },
            "artifactType": "HelmPackage",
            "dependsOnProfile": "null",
            "name": "hellotest1"
          }
        ],
        "nfviType": "AzureArcKubernetes"
      },
      "description": "null",
      "deployParameters": {"type":"object","properties":{"role1releasenamespace":{"type":"string"},"role1releasename":{"type":"string"},"role2releasenamespace":{"type":"string"},"role2releasename":{"type":"string"}},"required":["role1releasenamespace","role1releasename","role2releasenamespace","role2releasename"]},
      "networkFunctionType": "ContainerizedNetworkFunction"
    }
}

Exempel på en CGS-resurs (Configuration Group Schema)

CGS används av utgivaren för att kräva att variablerna roleOverrideValues tillhandahålls av Operator vid tidpunkten. Dessa roleOverrideValues kan innehålla icke-dedfault-inställningar för applicationEnablement.

{
  "type": "object",
  "properties": {
    "location": {
      "type": "string"
    },
    "nfviType": {
      "type": "string"
    },
    "nfdvId": {
      "type": "string"
    },
    "helloworld-cnf-config": {
      "type": "object",
      "properties": {
        "role1releasenamespace": {
          "type": "string"
        },
        "role1releasename": {
          "type": "string"
        },
        "role2releasenamespace": {
          "type": "string"
        },
        "role2releasename": {
          "type": "string"
        },
        "roleOverrideValues1": {
          "type": "string"
        },
        "roleOverrideValues2": {
          "type": "string"
        }
      },
      "required": [
        "role1releasenamespace",
        "role1releasename",
        "role2releasenamespace",
        "role2releasename",
        "roleOverrideValues1",
        "roleOverrideValues2"
      ]
    }
  },
  "required": [
    "nfviType",
    "nfdvId",
    "location",
    "helloworld-cnf-config"
  ]
}

Operatorändringar

Operatorer ärver standardprogramAktiveringsvärden som definierats av NFDV. Om applicationEnablement parametriseras i CGS måste det skickas via egenskapen deploymentValues vid körning.

Exempel på cgv-resurs (Configuration Group Value)

CGV används av operatorn för att ange variablerna roleOverrideValues vid tidpunkten. RoleOverrideValues innehåller en icke-dedfault-inställning för applicationEnablement.

{
  "location": "<location>",
  "nfviType": "AzureArcKubernetes",
  "nfdvId": "<nfdv_id>",
  "helloworld-cnf-config": {
    "role1releasenamespace": "hello-test-releasens",
    "role1releasename": "hello-test-release",
    "role2releasenamespace": "hello-test-2-releasens",
    "role2releasename": "hello-test-2-release",
    "roleOverrideValues1": "{\"name\":\"hellotest\",\"deployParametersMappingRuleProfile\":{\"applicationEnablement\":\"Enabled\",\"helmMappingRuleProfile\":{\"releaseName\":\"override-release\",\"releaseNamespace\":\"override-namespace\",\"helmPackageVersion\":\"1.0.0\",\"values\":\"\",\"options\":{\"installOptions\":{\"atomic\":\"true\",\"wait\":\"true\",\"timeout\":\"30\",\"injectArtifactStoreDetails\":\"true\"},\"upgradeOptions\":{\"atomic\":\"true\",\"wait\":\"true\",\"timeout\":\"30\",\"injectArtifactStoreDetails\":\"true\"}}}}}",
    "roleOverrideValues2": "{\"name\":\"hellotest1\",\"deployParametersMappingRuleProfile\":{\"applicationEnablement\" : \"Enabled\"}}"
  }
}

Exempel på NF ARM-mall

NF ARM-mallen används av operatorn för att skicka variablerna roleOverrideValues som anges av CGV till resursprovidern (RP). Operatorn kan ändra inställningen applicationEnablement i CGV efter behov och skicka samma NF ARM-mall igen för att ändra beteendet mellan iterationer.

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {
    "nameValue": {
      "type": "string",
      "defaultValue": "HelloWorld"
    },
    "locationValue": {
      "type": "string",
      "defaultValue": "eastus"
    },
    "nfviTypeValue": {
      "type": "string",
      "defaultValue": "AzureArcKubernetes"
    },
    "nfviIdValue": {
      "type": "string"
    },
    "config": {
      "type": "object",
      "defaultValue": {}
    },
    "nfdvId": {
      "type": "string"
    }
  },
  "variables": {
    "deploymentValuesValue": "[string(createObject('role1releasenamespace', parameters('config').role1releasenamespace, 'role1releasename',parameters('config').role1releasename, 'role2releasenamespace', parameters('config').role2releasenamespace, 'role2releasename',parameters('config').role2releasename))]",
    "nfName": "[concat(parameters('nameValue'), '-CNF')]",
    "roleOverrideValues1": "[string(parameters('config').roleOverrideValues1)]",
    "roleOverrideValues2": "[string(parameters('config').roleOverrideValues2)]"
  },
  "resources": [
    {
      "type": "Microsoft.HybridNetwork/networkFunctions",
      "apiVersion": "2023-09-01",
      "name": "[variables('nfName')]",
      "location": "[parameters('locationValue')]",
      "properties": {
        "networkFunctionDefinitionVersionResourceReference": {
          "id": "[parameters('nfdvId')]",
          "idType": "Open"
        },
        "nfviType": "[parameters('nfviTypeValue')]",
        "nfviId": "[parameters('nfviIdValue')]",
        "allowSoftwareUpdate": true,
        "configurationType": "Open",
        "deploymentValues": "[string(variables('deploymentValuesValue'))]",
        "roleOverrideValues": [
          "[variables('roleOverrideValues1')]",
          "[variables('roleOverrideValues2')]"
        ]
      }
    }
  ]
}

Stöd för i tjänstuppgraderingar

Azure Operator Service Manager stöder där det är möjligt i tjänstuppgraderingar, en uppgraderingsmetod som avancerar en distributionsversion utan att avbryta tjänsten. Möjligheten att uppgradera en viss tjänst utan avbrott är dock en funktion i själva tjänsten. Kontakta tjänsteutgivaren ytterligare för att förstå uppgraderingsfunktionerna i tjänsten.

Framåtblickande mål

Azure Operator Service Manager fortsätter att utöka funktionsuppsättningen Säker uppgraderingspraxis och öka förbättringarna i erbjudna uppdateringstjänster. Följande funktioner är för närvarande under övervägande för framtida tillgänglighet:

  • Förbättra kontrollen för uppgraderingsalternativ – Exponera parametrar mer effektivt.
  • Hoppa över NfApp vid ingen ändring – Hoppa över bearbetning av NfApps där inga ändringar resulterar.
  • Kör NFDV Rollback On Failure – Baserat på flagga återställer du alla slutförda NfApps vid fel.
  • Arbeta asynkront – Möjlighet att köra flera NfApp-åtgärder åt gången.
  • Ladda ned bilder – Möjlighet att förinläsa bilder till edge-lagringsplatsen.
  • Måldiagram för validering – Möjlighet att endast köra ett helm-test på en specifik NfApp.