API-Proxys mithilfe der API bereitstellen

<ph type="x-smartling-placeholder"></ph> Sie sehen die Dokumentation zu Apigee Edge.
Gehen Sie zur Apigee X-Dokumentation.
Weitere Informationen

Jede Organisation hat einen eigenen Lebenszyklus für die Softwareentwicklung. Häufig ist es notwendig, um die API-Proxy-Bereitstellung mit den Prozessen für Back-End-Dienste zu synchronisieren und abzustimmen.

Die in diesem Thema gezeigten Edge API-Methoden können verwendet werden, um den API-Proxy zu integrieren in den SDLC Ihres Unternehmens integrieren. Diese API wird häufig verwendet, um Skripts oder Code zu schreiben die API-Proxys bereitstellen oder API-Proxys von einer Umgebung in eine andere migrieren, ein umfassender automatisierter Prozess, der auch andere Anwendungen bereitstellt und migriert.

Die Edge API macht keine Annahmen über Ihren SDLC (oder das von jemand anderem). Stattdessen werden atomare Funktionen verfügbar gemacht, die von Ihrem Entwicklungsteam zur Automatisierung koordiniert werden können. und optimieren Sie Ihren API-Entwicklungszyklus.

Vollständige Informationen finden Sie unter Edge APIs.

Um die Edge API zu verwenden, müssen Sie sich bei Ihren Aufrufen authentifizieren. Sie können dazu eine der folgenden Methoden:

  • OAuth2 (nur Public Cloud)
  • SAML (öffentliche und private Cloud)
  • Basic Auth (nicht empfohlen; öffentliche und private Cloud)

In diesem Thema geht es um die APIs für die Verwaltung von API-Proxys.

Video: In diesem kurzen Video erfahren Sie, wie Sie eine API bereitstellen.

Mit der API interagieren

Die folgenden Schritte führen Sie durch einfache Interaktionen mit den APIs.

APIs in Ihrer Organisation auflisten

Sie können mit der Auflistung aller API-Proxys in Ihrer Organisation beginnen. (Denken Sie daran, Einträge für EMAIL:PASSWORD und ORG_NAME. Anweisungen finden Sie unter Verwenden Sie die Edge API.

curl -u EMAIL:PASSWORD \
  https://api.enterprise.apigee.com/v1/o/ORG_NAME/apis

Beispielantwort:

[ "weatherapi" ]

API abrufen

Sie können die Methode GET auf jedem API-Proxy in Ihrer Organisation aufrufen. Dieser Aufruf gibt eine Liste alle verfügbaren Versionen des API-Proxys.

curl -u EMAIL:PASSWORD -H "Accept: application/json" \
  https://api.enterprise.apigee.com/v1/o/ORG_NAME/apis/weatherapi

Beispielantwort:

{
  "name" : "weatherapi",
  "revision" : [ "1" ]
}

Das einzige Detail, das von dieser Methode zurückgegeben wird, ist der Name des API-Proxys sowie die zugehörigen revision mit einer verknüpften Nummer. API-Proxys bestehen aus einem Bundle von Konfigurationen Dateien. Überarbeitungen sind ein einfacher Mechanismus zum Verwalten von Konfigurationsaktualisierungen während der Iteration. Überarbeitungen werden fortlaufend nummeriert, sodass Sie eine Änderung durch Bereitstellung rückgängig machen können. eine frühere Version Ihres API-Proxys. Sie können auch eine Version eines API-Proxys im Produktionsumgebung erstellt, während im Test weiterhin neue Versionen dieses API-Proxys erstellt werden zu verbessern. Wenn Sie bereit sind, können Sie die höhere Version Ihres API-Proxys aus der Testumgebung über die vorherige Version des API-Proxys in der Produktumgebung.

In diesem Beispiel gibt es nur eine Version, da der API-Proxy gerade erstellt wurde. Als API sich im Lebenszyklus der iterativen Konfiguration und Bereitstellung befindet, die Versionsnummer wird durch Ganzzahlen erhöht. Mit direkten API-Aufrufen für die Bereitstellung können Sie optional den Versionsnummer des API-Proxys. Manchmal möchten Sie bei geringfügigen Änderungen erhöhen Sie die Überarbeitung.

API-Überarbeitung abrufen

Die API-Version, z. B. api.company.com/v1, sollte sich stark ändern. sehr selten. Wenn Sie die API-Version erhöhen, erfahren Entwickler, dass es die von der API offengelegte externe Schnittstelle erheblich verändert hat.

Die API-Proxy-Version ist eine erhöhte Nummer, die mit einem API-Proxy verknüpft ist. Konfiguration. API-Dienste verwalten Überarbeitungen Ihrer Konfigurationen, damit Sie eine wenn etwas schiefgeht. Standardmäßig wird die Version eines API-Proxys automatisch Er wird jedes Mal erhöht, wenn Sie einen API-Proxy mithilfe der API API-Proxy importieren importieren. Wenn Sie die Version eines API-Proxys nicht erhöhen möchten, verwenden Sie die Methode Update API Proxy Revision verwenden. Wenn Sie Maven für die Bereitstellung nutzen, verwenden Sie die clean oder update-Optionen, wie im Maven-Plug-in beschrieben. lesen.

Sie können beispielsweise die Methode GET für API-Proxy-Version 1 aufrufen, um eine Detailansicht zu erhalten.

curl -u EMAIL:PASSWORD -H "Accept:application/json" \
  https://api.enterprise.apigee.com/v1/o/ORG_NAME/apis/weatherapi/revisions/1

Beispielantwort

{
  "configurationVersion" : {
    "majorVersion" : 4,
    "minorVersion" : 0
  },
  "contextInfo" : "Revision 1 of application weatherapi, in organization {org_name}",
  "createdAt" : 1343178905169,
  "createdBy" : "andrew@apigee.com",
  "lastModifiedAt" : 1343178905169,
  "lastModifiedBy" : "andrew@apigee.com",
  "name" : "weatherapi",
  "policies" : [ ],
  "proxyEndpoints" : [ ],
  "resources" : [ ],
  "revision" : "1",
  "targetEndpoints" : [ ],
  "targetServers" : [ ],
  "type" : "Application"
}

Diese API-Proxy-Konfigurationselemente sind in der API-Proxy-Konfigurationsreferenz ausführlich dokumentiert.

API für eine umgebung

Sobald Ihr API-Proxy für den Empfang und die Weiterleitung von Anfragen konfiguriert ist, können Sie ihn bereitstellen. auf eine oder mehrere Umgebungen. Normalerweise iterieren Sie API-Proxys in test und dann, wenn Sie bereit sind, Sie die API-Proxy-Version auf prod hochstufen. Häufig werden Sie feststellen, API-Proxys in der Testumgebung zu überprüfen, da Sie viel weniger tun werden Iterationen in der Produktumgebung.

Ein API-Proxy kann erst aufgerufen werden, wenn er in einer Umgebung bereitgestellt wurde. Sobald Sie die API-Proxy-Version für die Produktion bereitgestellt haben, können Sie die prod-URL dann extern veröffentlichen zu entwickeln.

Umgebungen auflisten

Jede Organisation in Apigee Edge hat mindestens zwei Umgebungen: test und prod. Die die Unterscheidung ist willkürlich. Ziel ist es, Ihnen einen Bereich zur Verfügung zu stellen, in dem Sie überprüfen können, ob Ihr API-Proxy bevor Sie sie für externe Entwickler freigeben.

Jede Umgebung ist eigentlich nur eine Netzwerkadresse, sodass Sie den Traffic zwischen den API-Proxys, an denen Sie arbeiten, und solche, auf die Anwendungen zur Laufzeit zugreifen.

Umgebungen bieten auch die Trennung von Daten und Ressourcen. Sie können beispielsweise verschiedene Caches in Test und Produktion, auf die nur API-Proxys zugreifen können, die in diesem zu verbessern.

Umgebungen in einem Organisation

curl -u EMAIL:PASSWORD \
  https://api.enterprise.apigee.com/v1/o/ORG_NAME/environments

Beispielantwort:

[ "test", "prod" ]

Deployments analysieren

Eine Bereitstellung ist eine Version eines API-Proxys, der in einer Umgebung bereitgestellt wurde. Eine API Proxy mit dem Status Bereitgestellt ist über das Netzwerk unter den in den <VirtualHost>-Element für diese Umgebung.

API-Proxys bereitstellen

API-Proxys können erst aufgerufen werden, wenn sie bereitgestellt wurden. API-Dienste stellen RESTful APIs zur Verfügung die den Bereitstellungsprozess steuern.

In einer Umgebung kann jeweils nur eine Version eines API-Proxys bereitgestellt werden. Dementsprechend Das Deployment der bereitgestellten Version muss aufgehoben werden. Sie können festlegen, ob das neue Bundle bereitgestellt wird als neue Überarbeitung übergeben oder ob die vorhandene Überarbeitung überschrieben wird.

Sie sehen sich die Dokumentation zu Apigee Edge an.
Sehen Sie sich die Apigee X-Dokumentation an.
info

Heben Sie zuerst die Bereitstellung der vorhandenen Version auf. Geben Sie den Umgebungsnamen und die Versionsnummer API-Proxy, dessen Bereitstellung Sie aufheben möchten:

curl -X DELETE \
  https://api.enterprise.apigee.com/v1/o/ORG_NAME/environments/ENV_NAME/apis/API_NAME/revisions/REVISION_NUMBER/deployments \
  -u EMAIL:PASSWORD

Stellen Sie dann die neue Version bereit. Die neue Version des API-Proxys muss bereits vorhanden sein:

curl -X POST -H "Content-type:application/x-www-form-urlencoded" \
  https://api.enterprise.apigee.com/v1/o/ORG_NAME/environments/ENV_NAME/apis/API_NAME/revisions/REVISION_NUMBER/deployments \
  -u EMAIL:PASSWORD

Nahtlose Bereitstellung (keine Ausfallzeiten)

Verwenden Sie den Parameter override, um die Gefahr von Ausfallzeiten während der Bereitstellung zu minimieren für die Bereitstellungsmethode und legen Sie dafür true fest.

Sie können nicht eine Version eines API-Proxys über einer anderen bereitstellen. Die erste muss immer Bereitstellung aufgehoben. Wenn Sie override auf true setzen, geben Sie an, dass eine Überarbeitung eines API-Proxys sollte über die aktuell bereitgestellte Version bereitgestellt werden. Das Ergebnis ist, dass der Die Bereitstellungssequenz wird umgekehrt: Die neue Version wird bereitgestellt. abgeschlossen ist, wurde die Bereitstellung der bereits bereitgestellten Version aufgehoben.

Im folgenden Beispiel wird der Wert override festgelegt, indem er als Formularparameter übergeben wird:

curl -X POST -H "Content-type:application/x-www-form-urlencoded" \
  https://api.enterprise.apigee.com/v1/o/ORG_NAME/e/ENV_NAME/apis/API_NAME/revisions/REVISION_NUMBER/deployments" \
  -d "override=true" \
  -u EMAIL:PASSWORD

Sie können die Bereitstellung weiter optimieren, indem Sie den Parameter delay festlegen. Die Der Parameter delay gibt ein Zeitintervall in Sekunden an, vor dem der vorherige Das Deployment der Überarbeitung sollte aufgehoben werden. Dies hat zur Folge, dass laufende Transaktionen der abgeschlossen werden muss, bevor die Bereitstellung der Transaktion durch den API-Proxy aufgehoben wird. Mitlesen bei was mit override=true und dem Parameter delay geschieht:

  • Revision 1 verarbeitet Anfragen.
  • Version 2 wird parallel bereitgestellt.
  • Wenn Version 2 vollständig bereitgestellt ist, wird neuer Traffic an Version 2 gesendet. Keine neuen Zugriffe an Revision 1 gesendet.
  • Revision 1 verarbeitet jedoch möglicherweise noch vorhandene Transaktionen. Wenn Sie die Einstellung delay (z. B. 15 Sekunden), geben Sie der Überarbeitung 1 15 Sekunden Zeit, die Verarbeitung vorhandener Transaktionen abzuschließen.
  • Nach dem Verzögerungsintervall wird die Bereitstellung von Version 1 aufgehoben.
curl -X POST -H "Content-type:application/x-www-form-urlencoded" \
  https://api.enterprise.apigee.com/v1/o/ORG_NAME/e/ENV_NAME/apis/API_NAME/revisions/REVISION_NUMBER/deployments?delay=15" \
  -d "override=true" \
  -u EMAIL:PASSWORD
Suchparameter Beschreibung
override

Der Standardwert ist false (normales Bereitstellungsverhalten: Bereitstellung der vorhandenen Version wurde aufgehoben) wird die neue Version bereitgestellt.

Legen Sie true fest, um das normale Bereitstellungsverhalten zu überschreiben und eine nahtlose Bereitstellung. Die vorhandene Version bleibt bereitgestellt, während die neue Version ebenfalls bereitgestellt wird. bereitgestellt. Wenn die neue Version bereitgestellt wird, wird die Bereitstellung der alten Version aufgehoben. Verwenden in zusammen mit dem Parameter delay zum Steuern des Aufhebens der Bereitstellung erfolgt.

delay

Damit die Transaktionsverarbeitung für die vorhandene Überarbeitung abgeschlossen werden kann, bevor diese abgeschlossen wird. und eliminieren Sie die Möglichkeit von 502 Bad Gateway oder 504 Gateway Timeout errors: Legen Sie für diesen Parameter die Anzahl der Sekunden fest, für die das Aufheben der Bereitstellung erfolgen soll. mit Verspätung. Die Anzahl der Sekunden, die Sie festlegen können, ist unbegrenzt und es gibt keine Auswirkungen auf die Leistung, wenn eine große Anzahl von Sekunden festgelegt wird. Während der Verzögerung sind keine neuen an die alte Version gesendet wird.

Der Standardwert ist 0 Sekunden (null). Wenn override auf „true“ gesetzt und delay gleich 0 ist, wird die Bereitstellung der vorhandenen Version sofort nach der neuen Version bereitgestellt ist. Negative Werte werden wie 0 Sekunden (Null) behandelt.

Wenn override=true zusammen mit einem delay, HTTP-5XX verwendet wird während der Bereitstellung reagieren können. Dies liegt daran, dass beide API-Proxy-Versionen die gleichzeitig bereitgestellt werden, wobei die Bereitstellung der älteren Version nach der Verzögerung aufgehoben wird.

Alle Bereitstellungen einer API ansehen Überarbeitete Version

Manchmal ist es notwendig, eine Liste aller derzeit bereitgestellten Versionen einer API abzurufen Proxy.

curl https://api.enterprise.apigee.com/v1/o/ORG_NAME/apis/weatherapi/revisions/1/deployments \
  -u EMAIL:PASSWORD
{
  "aPIProxy" : "weatherapi",
  "environment" : [ {
    "configuration" : {
      "basePath" : "",
      "steps" : [ ]
    },
    "name" : "test",
    "server" : [ {
      "status" : "deployed",
      "type" : [ "message-processor" ],
      "uUID" : "90096dd1-1019-406b-9f42-fbb80cd01200"
    }, {
      "status" : "deployed",
      "type" : [ "message-processor" ],
      "uUID" : "7d6e2eb1-581a-4db0-8045-20d9c3306549"
    }, {
      "status" : "deployed",
      "type" : [ "router" ],
      "uUID" : "1619e2d7-c822-45e0-9f97-63882fb6a805"
    }, {
      "status" : "deployed",
      "type" : [ "router" ],
      "uUID" : "8a5f3d5f-46f8-4e99-b4cc-955875c8a8c8"
    } ],
    "state" : "deployed"
  } ],
  "name" : "1",
  "organization" : "org_name"
}

Die Antwort oben enthält viele Attribute, die für die interne Apigee-Infrastruktur spezifisch sind. Edge Sie können diese Einstellungen nur ändern, wenn Sie Apigee Edge lokal verwenden.

Die in der Antwort enthaltenen wichtigen Attribute sind organization. environment, aPIProxy, name und state. Von Durch Überprüfen dieser Eigenschaftswerte können Sie bestätigen, dass eine bestimmte Revision eines API-Proxys die in einer Umgebung bereitgestellt werden.

Alle Bereitstellungen ansehen in der Testumgebung

Sie können auch den Bereitstellungsstatus für eine bestimmte Umgebung (einschließlich der Version Nummer des aktuell bereitgestellten API-Proxys) mithilfe des folgenden Aufrufs:

curl -u EMAIL:PASSWORD
  https://api.enterprise.apigee.com/v1/o/ORG_NAME/environments/test/deployments

Dies gibt für jede in der Testumgebung bereitgestellte API dasselbe Ergebnis wie oben zurück.

Alle Bereitstellungen in der Organisation

Um eine Liste aller derzeit bereitgestellten Versionen aller API-Proxys in allen Umgebungen abzurufen, verwenden Sie die folgende API-Methode:

curl https://api.enterprise.apigee.com/v1/o/ORG_NAME/deployments \
  -u EMAIL:PASSWORD

Dies gibt das gleiche Ergebnis wie oben für alle API-Proxys zurück, die in allen Umgebungen bereitgestellt werden.

Da die API RESTful ist, können Sie einfach die Methode POST zusammen mit einem JSON- oder XML-Code verwenden. Nutzlast für dieselbe Ressource verwenden, um einen API-Proxy zu erstellen.

Für Ihren API-Proxy wird ein Profil generiert. Die Standarddarstellung eines API-Proxys befindet sich in JavaScript Object Notation (JSON). Unten sehen Sie die Standard-JSON-Antwort auf die obige Anfrage POST: wodurch ein API-Proxy namens weatherapi erstellt wurde. Eine Beschreibung jedes Elements im Profil folgt:

{
  "configurationVersion" : {
    "majorVersion" : 4,
    "minorVersion" : 0
  },
  "contextInfo" : "Revision 1 of application weatherapi, in organization {org_name}",
  "createdAt" : 1357172145444,
  "createdBy" : "you@yourcompany.com",
  "displayName" : "weatherapi",
  "lastModifiedAt" : 1357172145444,
  "lastModifiedBy" : "you@yourcompany.com",
  "name" : "weatherapi",
  "policies" : [ ],
  "proxyEndpoints" : [ ],
  "resources" : [ ],
  "revision" : "1",
  "targetEndpoints" : [ ],
  "targetServers" : [ ],
  "type" : "Application"
}

Das generierte API-Proxy-Profil zeigt die vollständige Struktur einer API. Proxy:

  • APIProxy revision: Die sequenziell nummerierte Iteration des API-Proxys Konfiguration gemäß den API-Diensten
  • APIProxy name: der eindeutige Name des API-Proxys
  • ConfigurationVersion: Version der API-Dienste, an die der API-Proxy Konfiguration entspricht
  • CreatedAt: Zeitpunkt, zu dem der API-Proxy generiert wurde, formatiert als UNIX-Zeit
  • CreatedBy: E-Mail-Adresse des Apigee Edge-Nutzers, der die API erstellt hat Proxy
  • DisplayName: Ein nutzerfreundlicher Name für den API-Proxy.
  • LastModifiedAt: Zeitpunkt, zu dem der API-Proxy generiert wurde, formatiert als UNIX Mal
  • LastModifiedBy: E-Mail-Adresse des Apigee Edge-Nutzers, der die API erstellt hat Proxy
  • Policies: eine Liste der Richtlinien, die diesem API-Proxy hinzugefügt wurden
  • ProxyEndpoints: Eine Liste mit benannten ProxyEndpunkte
  • Resources: eine Liste der Ressourcen (JavaScript, Python, Java, XSLT), die für in diesem API-Proxy ausgeführt werden
  • TargetServers: eine Liste benannter Zielserver, die mit dem Management API), die in erweiterten Konfigurationen zum Zweck des Load-Balancings verwendet wird
  • TargetEndpoints: eine Liste mit benannten TargetEndpunkte

Beachten Sie, dass viele Elemente der API-Proxy-Konfiguration, die mit dem einfachen POST erstellt wurde, sind leer. In den folgenden Themen erfahren Sie, wie Sie den Schlüssel hinzufügen und konfigurieren Komponenten eines API-Proxys.

Informationen zu diesen Konfigurationselementen finden Sie auch in der Referenz zur API-Proxy-Konfiguration.

Scripting für die API

Das Dokument Verwendung der Beispiel-API-Proxys, die auf GitHub verfügbar sind, Shell-Scripts bereitstellen, die das Apigee-Bereitstellungstool umschließen. Wenn aus irgendeinem Grund können Sie das Bereitstellungstool von Python nicht verwenden, dann können Sie die API direkt aufrufen. Beide Ansätze sind die in den Beispielskripts unten berücksichtigt werden.

Bereitstellungstool zusammenfassen

Prüfen Sie zuerst, ob das Python-Bereitstellungstool in Ihrer lokalen Umgebung verfügbar sind.

Erstellen Sie dann eine Datei mit Ihren Anmeldedaten. Die von Ihnen geschriebenen Bereitstellungsskripts werden können Sie die Anmeldedaten für Ihr Konto zentral verwalten. In der API Plattformbeispiel, diese Datei heißt setenv.sh.

#!/bin/bash

org="Your ORG on enterprise.apigee.com"
username="Your USERNAME on enterprise.apigee.com"

# While testing, it's not necessary to change the setting below
env="test"
# Change the value below only if you have an on-premise deployment
url="https://api.enterprise.apigee.com"
# Change the value below only if you have a custom domain
api_domain="apigee.net"

export org=$org
export username=$username
export env=$env
export url=$url
export api_domain=$api_domain

Die Datei oben macht alle Ihre Einstellungen für die Shell-Skripts verfügbar, die die Bereitstellung verpacken. .

Erstellen Sie nun ein Shell-Skript, das diese Einstellungen importiert und verwendet, um das Bereitstellungstool aufzurufen. Ein Beispiel finden Sie unter <ph type="x-smartling-placeholder"></ph> Apigee API-Plattformbeispiele)

#!/bin/bash

source path/to/setenv.sh

echo "Enter your password for the Apigee Enterprise organization $org, followed by [ENTER]:"

read -s password

echo Deploying $proxy to $env on $url using $username and $org

path/to/deploy.py -n {api_name} -u $username:$password -o $org -h $url -e $env -p / -d path/to/apiproxy

Erstellen Sie außerdem ein Skript zum Aufrufen und Testen der API, um Ihnen die Arbeit zu erleichtern. folgt:

#!/bin/bash

echo Using org and environment configured in /setup/setenv.sh

source /path/to/setenv.sh

set -x

curl "http://$org-$env.apigee.net/{api_basepath}"

API direkt aufrufen

Es kann nützlich sein, einfache Shell-Skripte zu schreiben, die den Prozess des Hochladens und Bereitstellung von API-Proxys.

Das folgende Skript ruft die Verwaltungs-API direkt auf. Er hebt die Bereitstellung der vorhandenen Der API-Proxy, den Sie aktualisieren, erstellt im Verzeichnis /apiproxy eine ZIP-Datei. der Ihre Proxy-Konfigurationsdateien enthält, und lädt dann den Konfiguration.

#!/bin/bash

#This sets the name of the API proxy and the basepath where the API will be available
api=api

source /path/to/setenv.sh

echo Delete the DS_store file on OSX

echo find . -name .DS_Store -print0 | xargs -0 rm -rf
find . -name .DS_Store -print0 | xargs -0 rm -rf

echo "Enter your password for the Apigee Enterprise organization $org, followed by [ENTER]:"

read -s password

echo Undeploy and delete the previous revision

# Note that you need to explicitly update the revision to be undeployed.
# One benefit of the Python deploy tool is that it manages this for you.

curl -k -u $username:$password "$url/v1/o/$org/e/$env/apis/$api/revisions/1/deployments" -X DELETE

curl -k -u $username:$password -X DELETE "$url/v1/o/$org/apis/$api/revisions/1"

rm -rf $api.zip

echo Create the API proxy bundle and deploy

zip -r $api.zip apiproxy

echo Import the new revision to $env environment 

curl -k -v -u $username:$password "$url/v1/o/$org/apis?action=import&name=$api" -T $api.zip -H "Content-Type: application/octet-stream" -X POST

echo Deploy the new revision to $env environment 

curl -k -u $username:$password "$url/v1/o/$org/e/$env/apis/$api/revisions/1/deployments" -X POST