Edge dla chmury prywatnej w wersji 4.17.01
Apigee udostępnia skrypty testowe, których możesz użyć do sprawdzenia instalacji.
Przeprowadzanie testów weryfikacyjnych
Każdy krok procesu testowania poprawności zwraca kod odpowiedzi HTTP 20X w przypadku pomyślnego testu.
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=sysAdminPword
Jeśli ją pominiesz, pojawi się prośba o podanie hasła.
Domyślnie narzędzie apigee-validate tworzy na routerze hosta wirtualnego, który używa portu 59001. Jeśli ten port nie jest otwarty na routerze, możesz opcjonalnie uwzględnić w pliku konfiguracji właściwość VHOST_PORT, aby ustawić port. Na przykład:
VHOST_PORT=9000 - Następnie skrypt wykonuje te czynności:
- Tworzy organizację i powiązuje ją z podem.
- Tworzy środowisko i wiąże z nim procesor komunikatów.
- Tworzy hosta wirtualnego.
- Importuje prosty serwer proxy kontroli stanu i wdraża aplikację w środowisku „test”.
- Zaimportuj serwer proxy SmartDocs.
- wykonuje test, aby upewnić się, że 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.
Uwaga: jeśli podczas testowania i rozwiązywania problemów wystąpią błędy, skontaktuj się z zespołem pomocy Apigee i podaj dziennik błędów.
Weryfikowanie instalacji poda
Po zainstalowaniu Apigee Analytics zalecamy wykonanie tych podstawowych, ale ważnych czynności weryfikacyjnych:
- Sprawdź, czy serwer zarządzania znajduje się w centralnym POD. Na serwerze zarządzania uruchom to polecenie CURL:
> curl -u sysAdminEmail:password http://localhost:8080/v1/servers?pod=central
Powinny wyświetlić się dane wyjściowe w tej postaci:
[ {
"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-4da1-b59b-23e3ef092f34"
} ] - Sprawdź, czy router i procesor komunikatów znajdują się w podzie bramy. Na serwerze zarządzania uruchom to polecenie CURL:
> curl -u sysAdminEmail:password http://localhost:8080/v1/servers?pod=gateway
Zobaczysz dane wyjściowe podobne do tych z poda centralnego, ale dotyczące routera i procesora komunikatów. - Sprawdź, czy Postgres znajduje się w podzie analitycznym. Na serwerze zarządzania uruchom to polecenie CURL:
> curl -u sysAdminEmail:password http://localhost:8080/v1/servers?pod=analytics
Zobaczysz dane wyjściowe podobne do tych dla poda centralnego, ale dotyczące Postgres.