Przeglądasz dokumentację Apigee Edge.
Otwórz dokumentację Apigee X. Informacje
Każda organizacja ma unikalny cykl tworzenia oprogramowania (SDLC). Często konieczne jest synchronizowanie i dostosowywanie wdrożenia serwera proxy interfejsu API do tych samych procesów, które są obecnie używane do programowania, testowania i wdrażania innych aplikacji.
Usługi interfejsów API udostępniają narzędzia i interfejsy API typu REST, które umożliwiają integrację wdrażania serwerów proxy interfejsów API i zarządzania nimi z SDLC organizacji. Typowym zastosowaniem interfejsu API REST jest pisanie skryptów lub kodu, które automatycznie wdrażają serwery proxy interfejsu API lub migrują serwery proxy interfejsu API z jednego środowiska do innego w ramach większego zautomatyzowanego procesu, który wdraża lub migruje też inne aplikacje. Usługi API nie mają w tym przypadku żadnych założeń dotyczących SDLC (ani żadnej innej osoby). Ujawniają natomiast funkcje atomowe, które mogą koordynować Twój zespół programistów, aby zautomatyzować i zoptymalizować cykl tworzenia interfejsu API.
Dokumentacja interfejsów API usług API znajduje się w dokumentacji API. Zapoznaj się z informacjami o interfejsie API dla początkujących.
Obejrzyj ten film, aby poznać środowiska interfejsów API i cykl ich tworzenia.
Środowiska
Każda organizacja w Apigee Edge ma co najmniej 2 środowiska wdrożenia dostępne dla serwerów proxy interfejsów API: „test” i „prod”. Różnice między tymi 2 środowiskami jest dowolne – każde środowisko jest po prostu identyfikowane przez inny zestaw adresów sieciowych (adresów URL). Celem jest udostępnienie domeny, w której możesz tworzyć i weryfikować serwery proxy API, zanim interfejs API zostanie udostępniony deweloperom zewnętrznym.
Możesz użyć tych środowisk do synchronizacji tworzenia serwerów proxy API przetwarzanych za pomocą SDLC. Każde środowisko jest definiowane za pomocą adresu sieciowego, co umożliwia rozdzielenie ruchu między serwery proxy interfejsu API, nad którymi pracujesz, a tymi, do których aplikacje uzyskują dostęp w czasie działania. Adresy sieciowe dostępne dla każdego środowiska są zdefiniowane w zestawie VirtualHosts dostępnych w tym środowisku.
Dla ruchu przychodzącego protokół TLS/SSL jest automatycznie włączony w każdym środowisku. W każdym środowisku są wstępnie zdefiniowane 2 hosty VirtualHost: default i secure. Wartość domyślna określa adres HTTP, a zabezpieczona – adres HTTP/S ze wstępnie skonfigurowanym protokołem TLS/SSL po stronie serwera. W konfiguracji serwera proxy interfejsu API wskazujesz, na których hostach wirtualnych ma nasłuchiwać ProxyEndpoint.
Gdy awansujesz do wersji produkcyjnej, zwykle wyłączasz HTTP, usuwając VirtualHost default z konfiguracji serwera proxy interfejsu API.
Na przykład poniższy ProxyEndpoint nasłuchuje HTTP i HTTPS.
<HTTPProxyConnection> <BasePath>/v0/weather</BasePath> <Properties/> <VirtualHost>default</VirtualHost> <VirtualHost>secure</VirtualHost> </HTTPProxyConnection>
Jeśli usuniesz VirtualHost default z konfiguracji ProxyEndpoint, utworzysz serwer proxy interfejsu API, który nasłuchuje tylko przez HTTPS, a nie HTTP.
<HTTPProxyConnection> <BasePath>/v0/weather</BasePath> <Properties/> <VirtualHost>secure</VirtualHost> </HTTPProxyConnection>
Aby sprawdzić, które hosty wirtualne są dostępne w danym środowisku, wybierz Środowiska w głównym menu interfejsu zarządzania.
Środowiska umożliwiają również segregację danych i zasobów. Możesz na przykład skonfigurować różne pamięci podręczne w środowisku testowym i produkcyjnym, do których mają dostęp tylko serwery proxy interfejsu API działające w tym środowisku. Dodatkowo klucze interfejsu API wydane w środowisku testowym nie są prawidłowe w środowisku produkcyjnym i odwrotnie.
Wdrażanie w środowiskach serwerów proxy interfejsów API
Po utworzeniu serwera proxy interfejsu API musisz wybrać środowisko, w którym będziesz pracować. Możesz utworzyć nowy serwer proxy interfejsu API w wersji produkcyjnej, ale nie jest to zalecane, ponieważ możesz ujawnić programistom interfejs API, zanim będzie gotowy. Ogólnie zacznij od utworzenia serwera proxy interfejsu API w test, który po przetestowaniu zostanie awansowany na prod.
Więcej informacji znajdziesz w opisie wdrażania.
Programowanie iteracyjne w fazie testów
Gdy korzystasz z serwera proxy interfejsu API, usługi API zapisują iteracje konfiguracji jako wersje. Podczas wdrażania serwera proxy interfejsu API wybierasz konkretną wersję do wdrożenia. Zwykle wdrażana jest ostatnia wersja. W razie potrzeby przywracany jest numer poprzedniej wersji. Możesz wybrać, gdzie chcesz wdrożyć te wersje. Możesz na przykład zmienić wersję na produkcyjną, aby umożliwić deweloperom rozpoczęcie pracy z Twoim interfejsem API. Możesz jednocześnie iterować wiele wersji w ramach testu, dodając funkcje lub dostrajając zasady. Następnie możesz wdrożyć nową wersję w środowisku produkcyjnym, zastępując istniejącą wersję w tym środowisku. Dzięki tej metodzie w czasie pracy programisty zawsze możesz udostępnić deweloperom opublikowaną wersję swojego interfejsu API.
Awansowanie do produkcji
Gdy serwer proxy interfejsu API zostanie w pełni wdrożony i przetestowany, może zostać awansowany na „prod”. Wersja testowanego serwera proxy interfejsu API będzie używana do zastąpienia wersji serwera proxy interfejsu API wdrożonego w środowisku produkcyjnym.
Usługi interfejsu API umożliwiają płynne wdrażanie serwerów proxy interfejsów API, minimalizując wpływ procedury wdrożenia na aplikacje i użytkowników.
Wdrożenie skryptów
Interfejs zarządzania Apigee Edge umożliwia wdrażanie serwerów proxy interfejsu API na potrzeby produkcji bezpośrednio z konstruktora serwerów proxy interfejsów API. Jednak w wielu sytuacjach wymagania dotyczące bezpieczeństwa, niezawodności i spójności wymagają stosowania procedur wdrażania skryptów przez zespoły programistyczne. W tym celu możesz napisać kod i skrypty, które wywołują interfejs API typu REST ujawniany przez usługi interfejsu API.
Zasoby środowiska
Aby uzyskać dodatkową kontrolę podczas awansowania, zalecamy iterowanie tylko testowanych serwerów proxy interfejsów API i wprowadzanie jak najmniejszej liczby zmian w serwerach proxy API wdrożonych w środowisku produkcyjnym.
Aby to zrobić, musisz upewnić się, że niektóre zasoby powiązane z każdym środowiskiem są skonfigurowane w taki sposób, aby mogły pozostać statyczne w konfiguracji serwera proxy interfejsu API.
- Docelowe adresy URL: serwery proxy interfejsu API często wywołują różne adresy URL backendu podczas testów i produkcji. Za pomocą konfiguracji serwera docelowego możesz tworzyć niezależne od środowiska konfiguracje docelowego punktu końcowego. Zobacz Równoważenie obciążenia między serwerami backendu.
- Pamięci podręczne i mapy klucz/wartość: oba zasoby trwałości są ograniczone do środowiska. Upewnij się, że są używane konwencje nazewnictwa, aby umożliwić serwery proxy interfejsu API do przechowywania danych bez konieczności wprowadzania zmian w konfiguracji podczas promocji. Przeczytaj artykuł o tworzeniu i edytowaniu pamięci podręcznej środowiska.
- Cele objaśnienia usługi: objaśnienia usługi mogą używać różnych wartości docelowych w zależności od środowiska, jeśli na przykład wywołanie usługi w środowisku testowym korzysta z usługi demonstracyjnej. Zapoznaj się z zasadami dotyczącymi objaśnień usługi.
Aby konfiguracje serwera proxy interfejsu API były zależne od środowiska, możesz też używać instrukcji warunkowych. Instrukcja warunkowa utworzona za pomocą zmiennej environment.name może służyć do oceny bieżącego środowiska przed wyegzekwowaniem zasady lub przed przekierowaniem do adresu URL w backendzie.
Więcej informacji znajdziesz w artykule o wdrażaniu.