Använda DevOps och CI/CD för att publicera API:er
GÄLLER FÖR: Alla API Management-nivåer
Med det strategiska värdet av API:er i företaget har det blivit en viktig aspekt av API-utveckling att använda Tekniker för kontinuerlig integrering (CI) och distribution (CD). I den här artikeln beskrivs de beslut du behöver fatta för att anta DevOps-principer för hantering av API:er.
API DevOps består av tre delar:
Varje del av API DevOps-pipelinen beskrivs nedan.
API-definition
En API-utvecklare skriver en API-definition genom att ange en specifikation, inställningar (till exempel loggning, diagnostik och serverdelsinställningar) och principer som ska tillämpas på API:et. API-definitionen innehåller den information som krävs för att etablera API:et på en Azure API Management-tjänst. Specifikationen kan baseras på en standardbaserad API-specifikation (till exempel WSDL, OpenAPI eller GraphQL) eller definieras med hjälp av ARM-API:erna (Azure Resource Manager) (till exempel en ARM-mall som beskriver API:et och åtgärderna). API-definitionen ändras över tid och bör betraktas som "källkod". Se till att API-definitionen lagras under källkodskontroll och har lämplig granskning innan du implementerar den.
Det finns flera verktyg som hjälper dig att skapa API-definitionen:
- Azure APIOps Toolkit tillhandahåller ett arbetsflöde som bygger på ett git-källkodskontrollsystem (till exempel GitHub eller Azure Repos). Den använder en extraktor för att skapa en API-definition som sedan tillämpas på en API Management-måltjänst av en utgivare. APIOps stöder REST- och GraphQL-API:er just nu.
- Verktyget dotnet-apim konverterar en välformulerad YAML-definition till en ARM-mall för senare distribution. Verktyget fokuserar på REST-API:er.
- Terraform är ett alternativ till Azure Resource Manager för att konfigurera resurser i Azure. Du kan skapa en Terraform-konfiguration (tillsammans med principer) för att implementera API:et på samma sätt som en ARM-mall skapas.
Du kan också använda IDE-baserade verktyg för redigeringsprogram som Visual Studio Code för att skapa de artefakter som krävs för att definiera API:et. Det finns till exempel över 30 plugin-program för redigering av OpenAPI-specifikationsfiler på Visual Studio Code Marketplace. Du kan också använda kodgeneratorer för att skapa artefakterna. Med CADL-språket kan du enkelt skapa byggstenar på hög nivå och sedan kompilera dem till ett standard-API-definitionsformat som OpenAPI.
API-godkännande
När API-definitionen har skapats skickar utvecklaren API-definitionen för granskning och godkännande. Om du använder ett Git-baserat källkodskontrollsystem (till exempel GitHub eller Azure Repos) kan sändningen göras via pull-begäran. En pull-begäran informerar andra om ändringar som har föreslagits i API-definitionen. När godkännandegrindarna har bekräftats sammanfogar en godkännare pull-begäran till huvudlagringsplatsen för att ange att API-definitionen kan distribueras till produktion. Processen för pull-begäran ger utvecklaren möjlighet att åtgärda eventuella problem som påträffas under godkännandeprocessen.
Både GitHub och Azure Repos tillåter att godkännandepipelines konfigureras som körs när en pull-begäran skickas. Du kan konfigurera godkännandepipelines för att köra verktyg som:
- API-specifikationslinters, till exempel Spectral, för att säkerställa att definitionen uppfyller DE API-standarder som krävs av organisationen.
- Identifiering av icke-bakåtkompatibla ändringar med hjälp av verktyg som openapi-diff.
- Verktyg för säkerhetsgranskning och utvärdering. OWASP har en lista över verktyg för säkerhetsgenomsökning.
- Automatiserade API-testramverk.
Kommentar
Azure-API:er måste följa en strikt uppsättning riktlinjer som du kan använda som utgångspunkt för dina egna API-riktlinjer. Det finns en Spectral-konfiguration för att framtvinga riktlinjerna.
När de automatiserade verktygen har körts granskas API-definitionen av det mänskliga ögat. Verktyg fångar inte alla problem. En mänsklig granskare ser till att API-definitionen uppfyller organisationens kriterier för API:er, inklusive efterlevnad av riktlinjer för säkerhet, sekretess och konsekvens.
API-publikation
API-definitionen publiceras till en API Management-tjänst via en versionspipeline. Vilka verktyg som används för att publicera API-definitionen beror på vilket verktyg som används för att skapa API-definitionen:
- Om du använder Azure APIOps Toolkit innehåller verktygslådan en utgivare som skriver API-definitionen till måltjänsten.
- Om du använder dotnet-apim representeras API-definitionen som en ARM-mall. Uppgifter är tillgängliga för Azure Pipelines och GitHub Actions för att distribuera en ARM-mall.
- Om du använder Terraform distribuerar CLI-verktyg API-definitionen på din tjänst. Det finns uppgifter tillgängliga för Azure Pipelines och GitHub Actions.
Kan jag använda andra källkodskontroll- och CI/CD-system?
Ja. Processen som beskrivs fungerar med alla källkodskontrollsystem (även om APIOps kräver att källkodskontrollsystemet är git-baserat ). På samma sätt kan du använda valfri CI/CD-plattform så länge den kan utlösas av en incheckning och köra kommandoradsverktyg som kommunicerar med Azure.
Bästa praxis
Det finns ingen branschstandard för att konfigurera en DevOps-pipeline för publicering av API:er, och inget av de verktyg som nämns fungerar i alla situationer. Vi ser dock att de flesta situationer omfattas av en kombination av följande verktyg och tjänster:
- Azure Repos lagrar API-definitionerna på en git-lagringsplats .
- Azure Pipelines kör processerna för automatiserat API-godkännande och API-publicering.
- Azure APIOps Toolkit innehåller verktyg och arbetsflöden för publicering av API:er.
Vi har sett störst framgång i kunddistributioner och rekommenderar följande metoder:
- Konfigurera antingen GitHub eller Azure Repos för ditt källkodskontrollsystem. Det här valet avgör även ditt val av pipeline runner. GitHub kan använda Azure Pipelines eller GitHub Actions, medan Azure Repos måste använda Azure Pipelines.
- Konfigurera en Azure API Management-tjänst för varje API-utvecklare så att de kan utveckla API-definitioner tillsammans med API-tjänsten. Använd förbrukningen eller utvecklar-SKU:n när du skapar tjänsten.
- Använd principfragment för att minska den nya principen som utvecklare behöver skriva för varje API.
- Använd namngivna värden och serverdelar för att säkerställa att principerna är allmänna och kan tillämpas på alla API Management-instanser .
- Använd Azure APIOps Toolkit för att extrahera en fungerande API-definition från utvecklartjänsten.
- Konfigurera en API-godkännandeprocess som körs på varje pull-begäran. Processen för API-godkännande bör omfatta identifiering av icke-bakåtkompatibla ändringar, lintning och automatiserad API-testning.
- Använd Azure APIOps Toolkit-utgivaren för att publicera API:et till din API Management-tjänst för produktion.
Mer information om hur du konfigurerar och kör en CI/CD-distributionspipeline med APIOps finns i Automatiserade API-distributioner med APIOps i Azure Architecture Center.
Referenser
- Azure DevOps Services innehåller Azure Repos och Azure Pipelines.
- Azure APIOps Toolkit tillhandahåller ett arbetsflöde för API Management DevOps.
- Spectral tillhandahåller en linter för OpenAPI-specifikationer.
- openapi-diff tillhandahåller en icke-bakåtkompatibel ändringsdetektor för OpenAPI v3-definitioner.