Ett samlat versionsskifte för automation
Broadcom presenterade den 18 september en samlad genomgång av säkerhets- och kompatibilitetsförändringarna i programmeringsverktygen för VMware Cloud Foundation 9.1.1. De berör VCF SDK för Java och Python, VCF PowerCLI samt vSphere-providern för Terraform. Gemensamt för förändringarna är att äldre körmiljöer rensas bort samtidigt som beroenden och integrationsytor moderniseras.
Det är verifierade produktförändringar, inte bara en rekommendation om framtida uppgradering. VCF SDK 9.1.1 publicerades med build 25714914 den 3 september och VCF PowerCLI 9.1.1 med build 25718932 den 10 september. Terraform-providern 2.17.0 kom den 1 september och följdes av 2.17.1 den 14 september. Septemberutgåvorna blir därmed ett sammanhängande skifte som kan träffa flera delar av samma automationskedja samtidigt.
Detta är en annan nyhet än Data Services Manager 9.1.1. DSM-releasen handlar om databasdrift, klusteröverskridande hög tillgänglighet, tenant-isolering och krypterad backup. Här ligger fokus i stället på de verktyg och körmiljöer som används för att programmera, konfigurera och automatisera VCF.
Java 17 blir ny lägstanivå
VCF SDK för Java kräver nu minst Java 17. Broadcom anger stöd för LTS-versionerna 17, 21 och 25. Organisationer som fortfarande kör integrationsjobb, egna portaler eller äldre byggagenter på Java 8 eller 11 kan alltså inte behandla SDK-uppdateringen som ett vanligt biblioteksbyte. Själva körmiljön måste först lyftas och applikationen regressionsprovas.
SOAP-modulerna för vSphere och vSAN använder dessutom Apache CXF 4.1.7. Den versionen för in korrigeringar för kända sårbarheter och anpassning till Jakarta EE 10, Spring 6 och Spring Boot 3. Säkerhetsvinsten är tydlig, men namnrymds- och beroendeförändringar i moderna Java-ramverk kan synliggöra antaganden i äldre kod. Kontrollera därför beroendeträdet, inte bara om projektet kompilerar.
Pythonstödet flyttas till 3.10–3.14
VCF SDK för Python 9.1.1 stöder Python 3.10 till och med 3.14. Broadcom skriver också att kompatibilitet inte garanteras när en Pythonversion har nått slutet av sin officiella livscykel. Det är särskilt relevant för virtuella miljöer som skapades för flera år sedan och sedan återanvänts i schemalagda jobb.
Utgåvan korrigerar samtidigt typinformationen i pyVmomi. Bland annat hanteras namnkollisioner bättre, arv från vmodl.MethodFault rättas och så kallade spökklasser tas bort. Det bör ge bättre statisk analys och säkrare kodkomplettering, men kan också göra att fel som tidigare passerade i CI nu upptäcks. Ett strikt typkontrollerat projekt bör därför testas med exakt den pyVmomi-version som ska användas i produktion.
PowerCLI och Image Builder kräver modernare värdar
VCF PowerCLI 9.1.1 fortsätter den gemensamma versionslinjen för VMware-modulerna, men Image Builder-delen höjer kraven. Stöd för Python 3.7, 3.8 och 3.9 tas bort, Python 3.14 tillkommer och miniminivån för PowerShell Core blir 7.0.13. Äldre Windows PowerShell-baserade byggvärdar behöver därmed inventeras särskilt; att ett vanligt PowerCLI-skript fungerar betyder inte automatiskt att en Image Builder-pipeline gör det.
Utgåvan innehåller också konkreta rättningar. Certifikatets kontrollsumma hanteras korrekt i Open-VMConsoleWindow, diagnostiken har förbättrats och ett fel där New-NetworkAdapter kunde skapa en ogiltig MAC-adress har korrigerats. För miljöer som automatiserar konsolåtkomst, felsökning eller nätverkskort är detta skäl att både uppgradera och återköra befintliga tester.
Terraform får fler administrativa ytor
VMware vSphere Provider 2.17.0 utökar vad som kan hanteras deklarativt. Bland nyheterna finns resurser för SSO-användare och grupper, nätverksprotokollprofiler och IP-pooler, stöd för datastore_path samt möjlighet att driftsätta OVF- och OVA-paket till datastore-kluster. Även attribut för VM-mappar har lagts till.
Version 2.17.1 följde kort därefter med en korrigering som markerar product_key som känsligt samt uppdateringar av gRPC- och Go-beroenden. Om versionslåset ännu pekar på 2.17.0 bör teamet bedöma om 2.17.1 ska bli målversionen innan planfiler skapas och godkänns. Provideruppgraderingen bör granskas genom terraform init -upgrade och en sparad plan i isolerad miljö innan den når produktion.
Praktisk migreringsplan för driftteam
Börja med en faktisk inventering. Sök igenom byggagenter, jump hosts, schemalagda jobb, containers och interna utvecklingsmiljöer efter installerad Java-, Python- och PowerShell-version. Koppla sedan varje körmiljö till de skript och tjänster den exekverar. Det är lätt att missa en gammal Python-tolk som bara används av ett nattligt rapportjobb eller en Java 11-runtime inbakad i en containerbild.
Skapa därefter en separat testmatris för Java 17 eller senare, Python 3.10–3.14 och PowerShell Core 7.0.13 eller senare. Lås versionsnummer för SDK, PowerCLI-moduler och Terraform-provider så att testresultatet går att upprepa. Kör både positiva funktionsprov och avsiktliga fel: utgångna certifikat, otillräckliga rättigheter, ogiltiga nätverksvärden och avbrutna API-anrop.
Kontrollera också hemlighetshanteringen. Terraform-rättningen kring product_key visar varför känsliga värden inte får hamna i terminalutskrifter, planartefakter eller CI-loggar. Rotera exponerade nycklar, begränsa åtkomst till state-filer och verifiera att loggmaskering fortfarande fungerar efter uppgraderingen.
Slutligen bör utrullningen ske stegvis med en dokumenterad återställningsväg. Separera uppgraderingen av körmiljö från uppgraderingen av klientbibliotek när det är möjligt. Då blir det enklare att avgöra om ett fel kommer från Java eller Python, ett SDK-anrop, en PowerCLI-modul eller en ändrad Terraform-provider.
LabOps IT:s bedömning
Vår bedömning är att VCF 9.1.1 gör automationsplattformen sundare, men att den operativa risken ligger i kombinationen av flera samtidiga golvhöjningar. Var och en av förändringarna är hanterbar. Tillsammans kan de påverka samma pipeline från utvecklarens lokala miljö, via CI-agenten, till driftens jump host.
Prioritera därför inte bara de mest synliga PowerCLI-skripten. Den största sannolikheten för avbrott finns ofta i sällan körda hjälpskript, äldre containerbilder och integrationsservrar som saknar tydligt ägarskap. Organisationer med versionslåsta beroenden, automatiska regressionstester och tydlig inventering bör kunna genomföra bytet kontrollerat. Miljöer där verktyg installerats manuellt över tid bör planera en sanering innan VCF 9.1.1-verktygen införs brett.