Testowanie instalacji

Edge for Private Cloud w wersji 4.18.05

Apigee udostępnia skrypty testowe, których możesz używać do weryfikowania instalacji.

Przeprowadzanie testów weryfikacyjnych

Każdy etap procesu weryfikacji powoduje zwrócenie kodu odpowiedzi HTTP 20X, jeśli test przebiegł pomyślnie.

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. Aby wywołać skrypty testowe, uruchom polecenie konfiguracji w węźle serwera zarządzania: 
    /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 podanie hasła.

    Domyślnie narzędzie apigee-validate tworzy w routerze hosta wirtualnego z portem 59001. Jeśli ten port nie jest otwarty w routerze, możesz opcjonalnie uwzględnić w pliku konfiguracji właściwość VHOST_PORT, aby ustawić port. Na przykład:

    VHOST_PORT=9000
  3. Następnie skrypt wykona te działania:
    • Tworzy organizację i wiąże ją z podem.
    • Tworzy środowisko i wiąże procesor wiadomości ze środowiskiem.
    • Tworzy hosta wirtualnego.
    • Importuje prosty serwer proxy kontroli stanu i wdraża aplikację w środowisku „testowym”.
    • Importuje serwer proxy SmartDokumentacja.
    • 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 przeprowadzenia testów.

Zweryfikuj instalację poda

Po zainstalowaniu Apigee Analytics zalecamy wykonanie podstawowych, ale też ważnych etapó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 mieć postać:

    [ {
  "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 podach bramy. Na serwerze zarządzania uruchom to polecenie curl: 
     curl -u sysAdminEmail:password http://localhost:8080/v1/servers?pod=gateway

    Wyświetlane dane wyjściowe są podobne do centralnego poda, ale dotyczące routera i procesora wiadomości.

  3. Sprawdź, czy Postgres znajduje się w POD w Statystykach. 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 centralnego PODA, ale dotyczące Postgres.