Testowanie instalacji

Edge dla chmury prywatnej w wersji 4.19.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:

  1. Zainstaluj apigee-validate w węźle serwera zarządzania: 
    /opt/apigee/apigee-service/bin/apigee-service apigee-validate install
  2. Uruchom polecenie konfiguracji na 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 nie podasz, pojawi się prośba o hasło.

    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 dodać do pliku konfiguracji właściwość VHOST_PORT, aby ustawić port. Na przykład:

    VHOST_PORT=9000
  3. 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”.
    • Importuje 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:

  1. Uruchom to polecenie: 
    /opt/apigee/apigee-service/bin/apigee-service apigee-validate clean -f configFile

    configFile to ten sam plik, który został użyty do przeprowadzenia testów.

Weryfikowanie instalacji poda

Po zainstalowaniu Apigee Analytics zalecamy wykonanie tych podstawowych, ale ważnych czynności weryfikacyjnych:

  1. 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 pojawić się dane wyjściowe w takiej 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-4242-b59b-23e3ef092f34"
} ]
  2. 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 centralnego poda, ale dotyczące routera i procesora komunikatów.

  3. 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 z centralnego poda, ale dotyczące Postgres.