Apigee udostępnia skrypty testowe, których możesz użyć do zweryfikowania instalacji.
Przeprowadzanie testów weryfikacyjnych
Każdy krok procesu testowania w ramach weryfikacji zwraca kod odpowiedzi HTTP 20X dla udanego żądania test.
Aby uruchomić skrypty testowe:
- Zainstaluj
apigee-validate
w węźle serwera zarządzania:/opt/apigee/apigee-service/bin/apigee-service apigee-validate install
- Uruchom polecenie konfiguracji w węźle serwera zarządzania, aby wywołać skrypty testowe:
/opt/apigee/apigee-service/bin/apigee-service apigee-validate setup -f configFile
Plik configFile musi zawierać tę właściwość:
APIGEE_ADMINPW=SYS_ADMIN_PASSWORD
Jeśli go pominiesz, pojawi się prośba o podanie hasła.
Domyślnie narzędzie
apigee-validate
tworzy hosta wirtualnego w routerze który korzysta z portu 59001. Jeśli ten port nie jest otwarty w routerze, opcjonalnie możesz dodać parametr właściwośćVHOST_PORT
w pliku konfiguracyjnym do ustawienia portu. Na przykład:VHOST_PORT=9000
- Następnie skrypt wykonuje te działania:
- Tworzy organizację i wiąże ją z podem.
- Tworzy środowisko i wiąże ze środowiskiem procesor wiadomości.
- Tworzy hosta wirtualnego.
- Importuje prosty serwer proxy kontroli stanu i wdraża aplikację w „test” dla środowiska.
- Importuje serwer proxy SmartDocuments.
- Przeprowadza test, aby sprawdzić, czy wszystko działa zgodnie z oczekiwaniami.
Pomyślny test zwraca odpowiedź HTTP 20x.
Aby usunąć organizację, środowisko i inne artefakty utworzone przez skrypty testowe:
- Uruchom to polecenie:
/opt/apigee/apigee-service/bin/apigee-service apigee-validate clean -f configFile
Gdzie configFile to ten sam plik, który został użyty do uruchomienia testów.
Zweryfikuj instalację poda
Po zainstalowaniu Apigee Analytics zaleca wykonanie tych czynności podstawowych, ale ważnych kroków weryfikacji:
- Sprawdź, czy serwer zarządzania znajduje się w centralnym podze. Na serwerze zarządzania uruchom
to polecenie
curl
:curl -u sysAdminEmail:password http://localhost:8080/v1/servers?pod=central
Dane wyjściowe powinny wyglądać tak:
[ { "internalIP" : "192.168.1.11", "isUp" : true, "pod" : "central", "reachable" : true, "region" : "dc-1", "tags" : { "property" : [ ] }, "type" : [ "application-datastore", "scheduler-datastore", "management-server", "auth-datastore", "apimodel-datastore", "user-settings-datastore", "audit-datastore" ], "uUID" : "d4bc87c6-2baf-4575-98aa-88c37b260469" }, { "externalHostName" : "localhost", "externalIP" : "192.168.1.11", "internalHostName" : "localhost", "internalIP" : "192.168.1.11", "isUp" : true, "pod" : "central", "reachable" : true, "region" : "dc-1", "tags" : { "property" : [ { "name" : "started.at", "value" : "1454691312854" }, ... ] }, "type" : [ "qpid-server" ], "uUID" : "9681202c-8c6e-4242-b59b-23e3ef092f34" } ]
- Sprawdź, czy router i procesor wiadomości znajdują się w PODNO bramy. Uruchom na serwerze zarządzania
to polecenie
curl
:curl -u sysAdminEmail:password http://localhost:8080/v1/servers?pod=gateway
Dane wyjściowe są podobne do danych wyjściowych centralnego poda, ale w przypadku routera i procesora wiadomości.
- Sprawdź, czy Postgres znajduje się w POD analitycznych. Na serwerze zarządzania uruchom następujące polecenia
Polecenie
curl
:curl -u sysAdminEmail:password http://localhost:8080/v1/servers?pod=analytics
Dane wyjściowe są podobne do danych przekazywanych przez centralny POD, ale w przypadku Postgres.