Testowanie instalacji

Edge for Private Cloud w wersji 4.19.01

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:

  1. Zainstaluj apigee-validate w węźle serwera zarządzania: 
    /opt/apigee/apigee-service/bin/apigee-service apigee-validate install
  2. 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
  3. 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:

  1. 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:

  1. 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"
} ]
  2. 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.

  3. 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.