Wdrażanie proxy interfejsu API za pomocą interfejsu API

Przeglądasz dokumentację Apigee Edge.
Przejdź do Dokumentacja Apigee X.
informacje.

Każda organizacja ma swój własny cykl tworzenia oprogramowania (SDLC). Często konieczne jest do synchronizowania i wyrównywania wdrożenia serwera proxy interfejsu API z procesami używanymi przez usługi backendu.

Zaprezentowane w tym temacie metody interfejsu API Edge mogą służyć do integracji serwera proxy interfejsu API. do SDLC organizacji. Typowym zastosowaniem tego interfejsu API jest pisanie skryptów lub kodu które wdrażają serwery proxy API lub przenoszą takie serwery z jednego środowiska do innego w ramach większy zautomatyzowany proces, który wdraża lub przenosi też inne aplikacje.

Edge API nie przyjmuje żadnych założeń dotyczących Twojego SDLC (ani w tym przypadku cudzych danych). ujawniają funkcje atomowe, które mogą być koordynowane przez zespół programistów w celu automatyzacji. i optymalizować cykl tworzenia interfejsów API.

Pełne informacje znajdziesz w artykule na temat interfejsów Edge API.

Aby używać interfejsu Edge API, musisz uwierzytelnić się w wywołaniach. Możesz to zrobić za pomocą: jedną z tych metod:

Ten temat koncentruje się na zestawie interfejsów API do zarządzania serwerami proxy interfejsów API.

Film: obejrzyj ten krótki film, aby dowiedzieć się, jak wdrożyć interfejs API.

Interakcje z interfejsem API

Poniżej znajdziesz instrukcje, jak w prosty sposób korzystać z interfejsów API.

Wyświetlanie listy interfejsów API w organizacji

Możesz zacząć od wyświetlenia listy wszystkich serwerów proxy interfejsu API w organizacji. (Pamiętaj o zastąpieniu wpisy dla EMAIL:PASSWORD i ORG_NAME. Instrukcje znajdziesz w materiałach na temat Użycie interfejsu Edge API

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

Przykładowa odpowiedź:

[ "weatherapi" ]

Uzyskiwanie interfejsu API

Możesz wywołać metodę GET na dowolnym serwerze proxy interfejsu API w organizacji. To wywołanie zwraca listę wszystkich dostępnych wersji serwera proxy interfejsu API.

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

Przykładowa odpowiedź:

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

Jedynym szczegółem zwróconym przez tę metodę jest nazwa serwera proxy interfejsu API oraz powiązane wersja, która ma przypisany numer. Serwery proxy interfejsu API składają się z pakietu konfiguracji . Wersje zapewniają prosty mechanizm do zarządzania aktualizacjami konfiguracji podczas ich iteracji. Wersje są kolejno numerowane, co pozwala cofnąć zmianę przez wdrożenie poprzedniej wersji serwera proxy interfejsu API. Możesz też wdrożyć wersję serwera proxy interfejsu API w w środowisku produkcyjnym, a jednocześnie nadal tworzyć nowe wersje tego serwera proxy interfejsu API w ramach testu dla środowiska. Gdy wszystko będzie gotowe, możesz promować nowszą wersję serwera proxy interfejsu API z poziomu w środowisku testowym w porównaniu z poprzednią wersją serwera proxy API w środowisku produkcyjnym.

W tym przykładzie jest tylko 1 wersja, ponieważ serwer proxy interfejsu API został właśnie utworzony. Jako interfejs API serwer proxy przechodzi przez cykl życia konfiguracji iteracyjnej i wdrożenia, numer wersji przyrostów o liczby całkowite. Korzystając z bezpośrednich wywołań interfejsu API do wdrożenia, możesz opcjonalnie zwiększyć numer wersji serwera proxy API. Czasami po wprowadzeniu drobnych zmian możesz nie chcieć zwiększyć wersję.

Pobieranie wersji interfejsu API

Wersja interfejsu API (np. api.company.com/v1) powinna się bardzo zmienić. niezbyt często. Zwiększając wersję interfejsu API, informujesz programistów, że muszą znacząco zmieniła się podpis interfejsu zewnętrznego udostępnianego przez interfejs API.

Wersja serwera proxy interfejsu API jest zwiększoną liczbą powiązaną z serwerem proxy interfejsu API. konfiguracji. Usługi interfejsu API zachowują wersje konfiguracji, dzięki czemu możesz przywrócić w razie problemów. Domyślnie wersja serwera proxy interfejsu API jest automatycznie zwiększana za każdym razem, gdy importujesz serwer proxy interfejsu API przy użyciu interfejsu API Import an proxy API. Jeśli nie chcesz zwiększać wersji serwera proxy interfejsu API, użyj metody Update Wersja serwera proxy interfejsu API. Jeśli do wdrożenia używasz Maven, użyj instrukcji clean lub Opcje update zgodnie z opisem we wtyczce Maven Readme.

Możesz na przykład wywołać metodę GET na serwerze proxy interfejsu API w wersji 1, aby uzyskać widok szczegółowy.

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

Przykładowa odpowiedź

{
  "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"
}

Szczegółowo opisujemy te elementy konfiguracji serwera proxy interfejsów API w dokumentacji konfiguracji serwera proxy interfejsu API.

Wdrożenie interfejsu API w środowisko

Gdy serwer proxy interfejsu API zostanie skonfigurowany do prawidłowego odbierania i przekazywania żądań, możesz go wdrożyć w co najmniej 1 środowisku. Zwykle wykonujesz iterację na serwerach proxy interfejsu API w test, a gdy wszystko będzie gotowe, Promujesz wersję serwera proxy interfejsu API do prod. Często okazuje się, że takich reklam jest znacznie więcej, wersji serwera proxy interfejsu API w środowisku testowym, głównie dlatego, że w środowisku produkcyjnym.

Nie można wywołać serwera proxy interfejsu API, dopóki nie zostanie on wdrożony w środowisku. Po wdrożyłeś(-aś) wersję serwera proxy interfejsu API w wersji prod, możesz następnie opublikować adres URL prod na zewnątrz dla programistów.

Jak wyświetlić listę środowisk

Każda organizacja w Apigee Edge ma co najmniej 2 środowiska: test i prod. jest dowolne. Celem jest udostępnienie Ci obszaru do sprawdzania, czy serwer proxy interfejsu API działa prawidłowo, zanim udostępnisz ją deweloperom zewnętrznym.

Każde środowisko jest w rzeczywistości po prostu adresem sieciowym, co pozwala na rozdzielanie ruchu pomiędzy Serwery proxy interfejsów API, nad którymi pracujesz, i te, do których aplikacje uzyskują dostęp w czasie działania.

Środowiska zapewniają również segregację danych i zasobów. Możesz na przykład skonfigurować różne pamięci podręczne w trybie testowym i produkcyjnym, do których dostęp mają tylko serwery proxy interfejsu API uruchamiane dla środowiska.

Wyświetl środowiska w organizacja

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

Przykładowa odpowiedź

[ "test", "prod" ]

Poznaj wdrożenia

Wdrożenie to wersja serwera proxy interfejsu API, który został wdrożony w środowisku. Interfejs API serwer proxy w stanie wdrożony jest dostępny przez sieć pod adresami określonymi w elementu <VirtualHost> dla tego środowiska.

Wdrażanie serwerów proxy interfejsu API

Serwery proxy interfejsu API nie mogą być wywoływane, dopóki nie zostaną wdrożone. Usługi API ujawniają interfejsy API typu REST które zapewniają kontrolę nad procesem wdrożenia.

W danym momencie można wdrożyć w środowisku tylko jedną wersję serwera proxy interfejsu API. Dlatego należy wycofać wdrożoną wersję. Możesz decydować o tym, czy nowy pakiet zostanie wdrożony jako nową wersję, czy też zastąpi obecną.

Wyświetlasz dokumentację Apigee Edge.
Otwórz dokumentację Apigee X.
informacje.

Najpierw wycofaj wdrożenie istniejącej wersji. Podaj nazwę środowiska i numer wersji serwer proxy interfejsu API, który chcesz wycofać:

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

Następnie wdróż nową wersję. Nowa wersja serwera proxy interfejsu API musi już istnieć:

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

Bezproblemowe wdrażanie (zero przestojów)

Aby zminimalizować ryzyko przestojów podczas wdrażania, użyj parametru override. metody wdrożenia i ustaw ją na true.

Nie można wdrożyć jednej wersji serwera proxy interfejsu API na innej. Pierwszą wartością musi być zawsze wycofano wdrożenie. Ustawiając override na true, wskazujesz 1 wersję serwera proxy interfejsu API należy wdrożyć w obecnie wdrożonej wersji. W rezultacie sekwencja wdrażania jest odwrócona – nowa wersja jest wdrażana, a po wdrożeniu zakończono, już wdrożona wersja została wycofana.

Poniższy przykład pokazuje wartość override, przekazując ją jako parametr formularza:

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

Aby jeszcze bardziej zoptymalizować wdrażanie, ustaw parametr delay. Parametr delay określa przedział czasu (w sekundach), przed którym poprzedni należy wycofać wdrożenie wersji. Transakcje w trakcie wyświetlania mają przedział czasu w który trzeba ukończyć, zanim serwer proxy interfejsu API przetworzy transakcję. Obserwujesz co się dzieje z parametrem override=true i zestawem parametrów delay:

  • Wersja 1 obsługuje żądania.
  • Wersja 2 jest wdrażana równolegle.
  • Po pełnym wdrożeniu wersji 2 nowy ruch jest wysyłany do wersji 2. Brak nowego ruchu wysłano do wersji 1.
  • Jednak wersja 1 może nadal przetwarzać istniejące transakcje. Poprzez ustawienie wartości delay (np. 15 sekund), nadajesz wersji 1 15 sekund do zakończenia przetwarzania istniejących transakcji.
  • Po upływie interwału opóźnienia wdrożenie wersji 1 zostanie wycofane.
.
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
Parametr zapytania Opis
override

Wartość domyślna to false (normalne działanie po wdrożeniu: istniejąca wersja została wycofana, i wdrożona jest nowa wersja).

Ustaw jako true, aby zastąpić normalne działanie wdrożenia i zapewnić bezproblemowe lub wdrożenia. Istniejąca wersja pozostaje wdrożona, gdy jest też wdrażana nowa wersja została wdrożona. Po wdrożeniu nowej wersji stara wersja zostaje wycofana. Użyj w łączenie z parametrem delay, aby kontrolować moment wycofania wdrożenia ma miejsce.

delay

Aby umożliwić zakończenie przetwarzania transakcji na istniejącej wersji, zanim zostanie ona nie wdrożono i wyeliminują możliwość 502 Bad Gateway lub 504 Gateway Timeout errors – ustaw ten parametr na taką liczbę sekund, jaka ma być wycofywana z wdrożenia opóźniony. Nie ma ograniczeń co do liczby sekund, jaką można ustawić. ustawienie dużej liczby sekund może mieć negatywny wpływ na wydajność. W trakcie opóźnienia nie pojawią się żadne nowe ruch jest kierowany do starej wersji.

Wartość domyślna to 0 (0) sekund. Gdy zasada override ma wartość Prawda i delay wynosi 0, istniejąca wersja jest wycofana natychmiast po nowej wersja jest wdrożona. Wartości ujemne są traktowane jako 0 (0) sekund.

Gdy używasz pola override=true razem z delay, HTTP 5XX podczas wdrażania. Dzieje się tak, ponieważ obie wersje serwera proxy API wdrażana jednocześnie, a starsza wersja została wycofana po opóźnieniu.

Wyświetlanie wszystkich wdrożeń interfejsu API Wersja

Czasami konieczne jest pobranie listy wszystkich obecnie wdrożonych wersji interfejsu API serwera 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"
}

Powyższa odpowiedź zawiera wiele właściwości specyficznych dla wewnętrznej infrastruktury Apigee Edge. Nie możesz zmienić tych ustawień, chyba że korzystasz z Apigee Edge lokalnie.

Ważne właściwości zawarte w odpowiedzi to organization, environment, aPIProxy, name i state. Według sprawdzając wartości właściwości, możesz potwierdzić, że konkretna wersja serwera proxy interfejsu API wdrożone w środowisku.

Zobacz wszystkie wdrożenia w środowisko testowe

Możesz też pobrać stan wdrożenia dla określonego środowiska (w tym wersji aktualnie wdrożonego serwera proxy interfejsu API) za pomocą tego wywołania:

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

Zwracany jest taki sam wynik jak powyżej dla każdego interfejsu API wdrożonego w środowisku testowym

Wyświetl wszystkie wdrożenia w organizacja

Aby pobrać listę wszystkich obecnie wdrożonych wersji wszystkich serwerów proxy interfejsu API we wszystkich środowiskach, użyj następującej metody interfejsu API:

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

Zwracany jest taki sam wynik jak powyżej w przypadku wszystkich serwerów proxy interfejsów API wdrożonych we wszystkich środowiskach.

Ponieważ interfejs API jest typu REST, możesz po prostu użyć metody POST w połączeniu z kodem JSON lub XML dla tego samego zasobu w celu utworzenia serwera proxy interfejsu API.

Zostanie wygenerowany profil serwera proxy interfejsu API. Domyślna reprezentacja serwera proxy interfejsu API to JSON (JavaScript Object Notation). Poniżej znajdziesz domyślną odpowiedź JSON na powyższe żądanie POST: w wyniku czego utworzono serwer proxy API o nazwie weatherapi. Opis każdego elementu w profilu następujące:

{
  "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"
}

Wygenerowany profil serwera proxy interfejsu API przedstawia pełną strukturę interfejsu API serwer proxy:

  • APIProxy revision: sekwencyjna numerowana iteracja serwera proxy interfejsu API konfiguracja zgodna z obsługą usług interfejsu API
  • APIProxy name: unikalna nazwa serwera proxy interfejsu API
  • ConfigurationVersion: wersja usług interfejsu API, do której używany jest serwer proxy interfejsu API. konfiguracja jest zgodna
  • CreatedAt: czas wygenerowania serwera proxy interfejsu API w formacie czasu UNIX
  • CreatedBy: adres e-mail użytkownika Apigee Edge, który utworzył interfejs API serwer proxy
  • DisplayName: przyjazna dla użytkownika nazwa serwera proxy interfejsu API
  • LastModifiedAt: czas wygenerowania serwera proxy interfejsu API w formacie UNIX godzina
  • LastModifiedBy: adres e-mail użytkownika Apigee Edge, który utworzył interfejs API serwer proxy
  • Policies: lista zasad, które zostały dodane do tego serwera proxy interfejsu API.
  • ProxyEndpoints: lista nazwanych ProxyEndpoints
  • Resources: lista zasobów (JavaScript, Python, Java i GTIN) dostępnych dla zostanie wykonane w tym serwerze proxy interfejsu API
  • TargetServers: lista nazwanych serwerów docelowych (możesz ją utworzyć przy użyciu funkcji API zarządzania) używany w zaawansowanych konfiguracjach do równoważenia obciążenia
  • TargetEndpoints: lista nazwanych punktów końcowych TargetEndpoints

Pamiętaj, że wiele elementów konfiguracji serwera proxy interfejsu API utworzonych za pomocą prostego POST metoda powyżej jest pusta. W poniższych tematach dowiesz się, jak dodać i skonfigurować klucz komponentów serwera proxy API.

Możesz też zapoznać się z informacjami o tych elementach konfiguracji w dokumentacji konfiguracji serwera proxy interfejsu API.

Skrypty kierowane do interfejsu API

W sekcji Korzystanie z przykładowych serwerów proxy interfejsu API dostępne w GitHubie zawierają skrypty powłoki, które opakowują narzędzie do wdrażania Apigee. Jeśli z jakiegoś powodu nie możesz użyć narzędzia do wdrażania w Pythonie, możesz bezpośrednio wywołać interfejs API. Oba podejścia co pokazujemy w przykładowych skryptach poniżej.

Pakowanie narzędzia do wdrażania

Najpierw upewnij się, że narzędzie do wdrażania w języku Python jest w środowisku lokalnym.

Następnie utwórz plik, w którym będziesz przechowywać swoje dane logowania. Napisane przez Ciebie skrypty wdrożenia zostaną zaimportowane te ustawienia, ułatwiając centralne zarządzanie danymi logowania na konto. W interfejsie API Przykładowy plik z platformy – ten plik nazywa się 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

Powyższy plik udostępnia wszystkie ustawienia skryptom powłoki, które zapakują wdrożenie .

Teraz utwórz skrypt powłoki, który importuje te ustawienia i używa ich do wywoływania narzędzia do wdrażania. (Oto przykład: Przykłady platform Apigee API).

#!/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

Aby ułatwić sobie życie, utwórz skrypt do wywoływania i testowania interfejsu API, następujące:

#!/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}"

Bezpośrednie wywoływanie interfejsu API

Może być przydatne napisanie prostych skryptów powłoki, które automatyzują proces przesyłania wdrażanie serwerów proxy API.

Poniższy skrypt bezpośrednio wywołuje interfejs API do zarządzania. Wycofuje wdrożenie istniejącej wersji aktualizujesz serwer proxy interfejsu API, tworząc plik ZIP z katalogu /apiproxy zawierające pliki konfiguracji serwera proxy, a następnie przesyła, importuje i wdraża konfiguracji.

#!/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