Wycofaj Apigee Edge 4.54.00

Jeśli podczas aktualizacji do Edge 4.54.00 wystąpi błąd, możesz przywrócić komponent, który go spowodował, a następnie spróbować ponownie przeprowadzić aktualizację.

Możesz przywrócić Edge 4.54.00 do dowolnej z tych wersji głównych:

  • Wersja 4.53.00
  • Wersja 4.53.01

Więcej informacji znajdziesz w artykule Proces publikowania wersji Apigee Edge.

Kolejność wycofywania

Wycofywanie zmian w komponentach powinno odbywać się w odwrotnej kolejności niż ich uaktualnianie. Typowa ogólna kolejność wycofywania zmian w chmurze prywatnej 4.54.00 wygląda tak:

  • Przywróć poprzednią wersję Cassandra, Zookeeper.
  • Przywróć Qpid, inne komponenty związane z analizą i Postgres.
  • Wycofanie zmian w interfejsie
  • Wycofaj LDAP.
  • Wycofaj serwer zarządzania.
  • Wycofaj routery i procesory komunikatów.

Załóżmy na przykład, że wszystkie routery i procesory wiadomości, wszystkie serwery zarządzania, LDAP i kilka węzłów interfejsu zostały uaktualnione z wersji 4.53.00 (lub) 4.53.01 do wersji 4.54.00 i chcesz przywrócić poprzednią wersję. W takim przypadku:

  • Cofanie uaktualnionych węzłów interfejsu
  • Wycofaj zmiany w węzłach LDAP
  • Przywracanie węzłów serwera zarządzania po kolei
  • Wycofaj wszystkie platformy RMP po kolei

Kto może przywrócić poprzednią wersję

Użytkownik, który przywraca poprzednią wersję, powinien być tym samym użytkownikiem, który pierwotnie zaktualizował Edge, lub użytkownikiem działającym jako root.

Domyślnie komponenty Edge działają jako użytkownik „apigee”. W niektórych przypadkach komponenty Edge mogą być uruchamiane jako różni użytkownicy. Jeśli na przykład router musi mieć dostęp do portów uprzywilejowanych, takich jak te poniżej 1000, musisz uruchomić router jako root lub jako użytkownik z dostępem do tych portów. Możesz też uruchomić jeden komponent jako jeden użytkownik, a inny komponent jako inny użytkownik.

Wycofanie zmian w systemie Cassandra

Gdy na określonym węźle zostanie przeprowadzona poważna aktualizacja Cassandry, Cassandra modyfikuje schemat danych przechowywanych na tym węźle. W związku z tym bezpośrednie przywrócenie w miejscu nie jest możliwe.

Scenariusze wycofania

W tabeli poniżej znajdziesz podsumowanie strategii wycofywania, których możesz używać:

Scenariusz Strategia wycofywania
Pojedyncze centrum danych, niektóre węzły Cassandra zostały uaktualnione Korzystanie z kopii zapasowych
Wiele centrów danych, niektóre węzły w jednym centrum danych zostały uaktualnione Odbuduj na podstawie istniejącego kontrolera domeny
Wiele centrów danych, wszystkie węzły Cassandra w niektórych centrach danych zostały uaktualnione Odbuduj na podstawie istniejącego kontrolera domeny
Wiele centrów danych, węzły Cassandra ostatniego centrum danych są uaktualniane Spróbuj dokończyć uaktualnienie. Jeśli nie jest to możliwe, przywróć 1 kontroler domeny za pomocą kopii zapasowej. Odbuduj pozostałe kontrolery domeny z przywróconego kontrolera domeny.

Uwagi ogólne

Jeśli rozważasz przywrócenie poprzedniej wersji, pamiętaj o tych kwestiach:

  • Cofanie zmian w Cassandrze podczas uaktualniania: jeśli podczas uaktualniania Cassandry napotkasz problemy, możesz rozważyć cofnięcie zmian. Postępuj zgodnie ze strategiami wycofywania opisanymi w tym artykule, w zależności od stanu podczas procesu uaktualniania.
  • Cofanie zmian za pomocą kopii zapasowych: kopie zapasowe utworzone w Cassandrze w wersji 5.0.X nie są zgodne z kopiami zapasowymi Cassandry w wersji 4.0.X. Aby przywrócić Cassandrę za pomocą przywracania kopii zapasowej, przed próbą uaktualnienia musisz utworzyć kopie zapasowe Cassandry 4.0.X.

Wycofywanie zmian w systemie Cassandra za pomocą ponownego tworzenia

Wymagania wstępne

  • Używasz klastra Edge dla chmury prywatnej w wersji 4.53.00/4.53.01 w wielu centrach danych.
  • Uaktualniasz bazę danych Cassandra z wersji 4.0.X do 5.0.X i występują problemy.
  • W klastrze masz co najmniej 1 w pełni funkcjonalne centrum danych, które nadal działa w starszej wersji Cassandry (Cassandra 4.0.X).

Ta procedura opiera się na przesyłaniu strumieniowym danych z istniejącego centrum danych. Może to potrwać znaczną ilość czasu, w zależności od ilości danych przechowywanych w Cassandra. Podczas wycofywania zmian musisz być gotowy na przekierowanie ruchu w czasie działania z tego centrum danych.

Najważniejsze kroki

  1. Wybierz jedno centrum danych (częściowo lub w pełni zaktualizowane), do którego chcesz przywrócić poprzednią wersję. Przekieruj ruch w czasie działania do innego działającego centrum danych.
  2. Zidentyfikuj węzeł początkowy w centrum danych i zacznij od jednego z nich.
  3. zatrzymać, odinstalować i wyczyścić węzeł Cassandra.
  4. Zainstaluj starszą wersję Cassandra na węźle i skonfiguruj ją zgodnie z potrzebami.
  5. Usuń dodatkowe konfiguracje, które zostały dodane wcześniej.
  6. Powtórz powyższe kroki dla wszystkich węzłów źródłowych w centrum danych, jeden po drugim.
  7. Powtórz powyższe kroki dla wszystkich pozostałych węzłów Cassandra w centrum danych, jeden po drugim.
  8. Odbuduj węzły z istniejącego funkcjonalnego centrum danych, jeden po drugim.
  9. Uruchom ponownie wszystkie komponenty edge-* w centrum danych, które są połączone z Cassandrą.
  10. Przetestuj i przekieruj ruch z powrotem do tego centrum danych.
  11. Powtórz te czynności w przypadku każdego centrum danych, po kolei.

Szczegółowy opis działań

  1. Wybierz jedno centrum danych, w którym wszystkie lub niektóre węzły Cassandra zostaną uaktualnione. Przekieruj cały ruch proxy środowiska wykonawczego i ruch związany z zarządzaniem z tego centrum danych, gdy węzły Cassandra w tym centrum danych są przywracane. Sprawdź, czy po wykonaniu polecenia nodetool ring na węzłach wszystkie węzły Cassandry są w stanie UN (Up/Normal). Jeśli niektóre węzły nie działają, rozwiąż problem i przywróć je, zanim przejdziesz dalej.

    Zobacz ten przykład:

    /opt/apigee/apigee-cassandra/bin/nodetool status
Datacenter: dc-1
================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address      Load       Tokens       Owns (effective)  Host ID                               Rack
UN  DC1-1IP1  456.41 KiB  1            100.0%            78fc4ddd-2ed9-4a8c-98a2-63a38c2f1920  ra-1
UN  DC1-1IP2  870.93 KiB  1            100.0%            160db01a-64ab-43a7-b9ea-3b7f8f66d52b  ra-1
UN  DC1-1IP3  824.08 KiB  1            100.0%            21d61543-d59e-403a-bf5d-bfe7f664baa6  ra-1
Datacenter: dc-2
================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address      Load       Tokens       Owns (effective)  Host ID                               Rack
UN  DC2-1IP1   802.08 KiB  1            100.0%            583e0576-336d-4ce7-9729-2ae74e0abde2  ra-1
UN  DC2-1IP2   844.4 KiB   1            100.0%            fef794d5-f4c2-4a4e-bb05-9adaeb4aea4b  ra-1
UN  DC2-1IP3   878.12 KiB  1            100.0%            3894b3d9-1f5a-444d-83db-7b1e338bbfc9  ra-1

    Możesz uruchomić nodetool describecluster na węzłach, aby poznać bieżący stan całego klastra. Na przykład poniżej przedstawiamy instancję klastra z 2 centrami danych, w którym wszystkie węzły DC-1 działają w wersji 4 Cassandry, a wszystkie węzły DC-2 – w wersji 3:

    # On nodes where Cassandra is upgraded
/opt/apigee/apigee-cassandra/bin/nodetool describecluster
Cluster Information:
    Name: Apigee
    Snitch: org.apache.cassandra.locator.PropertyFileSnitch
    DynamicEndPointSnitch: enabled
    Partitioner: org.apache.cassandra.dht.RandomPartitioner
    Schema versions:
        2eadcd74-0245-309a-9992-3625afa70038: [DC-1-IP1, DC-1-IP2, DC-1-IP3]
        129dc15e-198e-3c11-b64c-701044a3a1ad: [DC-2-IP1, DC-2-IP2, DC-2-IP3]

Stats for all nodes:
    Live: 6
    Joining: 0
    Moving: 0
    Leaving: 0
    Unreachable: 0

Data Centers:
    dc-1 #Nodes: 3 #Down: 0
    dc-2 #Nodes: 3 #Down: 0

Database versions:
    5.0.8: [DC-1-IP1:7000, DC-1-IP2:7000, DC-1-IP3:7000]
    4.0.13: [DC-2-IP1:7000, DC-2-IP2:7000, DC-2-IP3:7000]

Keyspaces:
    system_schema -> Replication class: LocalStrategy {}
    system -> Replication class: LocalStrategy {}
    auth -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
    cache -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
    devconnect -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
    dek -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
    user_settings -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
    apprepo -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
    kms -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
    identityzone -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
    audit -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
    analytics -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
    keyvaluemap -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
    counter -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
    apimodel_v2 -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
    system_distributed -> Replication class: SimpleStrategy {replication_factor=3}
    system_traces -> Replication class: SimpleStrategy {replication_factor=2}
    system_auth -> Replication class: SimpleStrategy {replication_factor=1}

# On nodes where Cassandra is not upgraded
/opt/apigee/apigee-cassandra/bin/nodetool describecluster
Cluster Information:
    Name: Apigee
    Snitch: org.apache.cassandra.locator.PropertyFileSnitch
    DynamicEndPointSnitch: enabled
    Partitioner: org.apache.cassandra.dht.RandomPartitioner
    Schema versions:
        2eadcd74-0245-309a-9992-3625afa70038: [DC-1-IP1, DC-1-IP2, DC-1-IP3]
        129dc15e-198e-3c11-b64c-701044a3a1ad: [DC-2-IP1, DC-2-IP2, DC-2-IP3]
  2. Zidentyfikuj węzły nasion w centrum danych: zapoznaj się z sekcją Jak zidentyfikować węzły nasion w dodatku. Wykonaj te czynności na jednym z węzłów początkowych:
  3. Zatrzymaj, odinstaluj i wyczyść dane z węzła Cassandra. Wybierz pierwszy węzeł początkowy w wersji 5 Cassandry w tym centrum danych. Przestań. 
    # Stop Cassandra service on the node
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra stop

# Uninstall Cassandra software
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra uninstall

# Wipe out Cassandra data
rm -rf /opt/apigee/data/apigee-cassandra
  4. Zainstaluj na węźle starszą wersję oprogramowania Cassandra i skonfiguruj niektóre ustawienia. Uruchom plik bootstrap Edge dla chmury prywatnej w wersji 4.53.00/4.53.01. 
    5. # Download bootstrap of 4.53.00
curl https://software.apigee.com/bootstrap_4.53.00.sh -o /tmp/bootstrap_4.53.00.sh -u uName:pWord

# Execute bootstrap of 4.53.00
sudo bash /tmp/bootstrap_4.53.00.sh apigeeuser=uName apigeepassword=pWord
  5. Utwórz lub zmodyfikuj plik /opt/apigee/customer/application/cassandra.properties.
  6. Dodaj do pliku tę zawartość: ipOfNode to adres IP węzła, którego Cassandra używa do komunikacji z innymi węzłami Cassandra: 
    conf_jvm_options_custom_settings=-Dcassandra.replace_address=ipOfNode -Dcassandra.allow_unsafe_replace=true
  7. Upewnij się, że plik należy do użytkownika apigee i jest przez niego możliwy do odczytu: 
    chown apigee:apigee /opt/apigee/customer/application/cassandra.properties
  8. Zainstaluj i skonfiguruj system Cassandra:
    9. # Install cassandra version 4.0.X
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra install
# Setup cassandra while passing standard configuration file
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra setup -f configFile
# Ensure Cassandra version is correct and service is running
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra version
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra status
  9. Sprawdź, czy węzeł został uruchomiony. Sprawdź to polecenie na tym węźle i innych węzłach w klastrze. Węzeł powinien zgłosić stan „UN” (Up/Normal): 
    /opt/apigee/apigee-cassandra/bin/nodetool status
  10. Usuń z pliku /opt/apigee/customer/application/cassandra.properties dodatkowe konfiguracje dodane wcześniej.
  11. Powtórz kroki od 3 do 10 na wszystkich węzłach początkowych Cassandry w centrum danych, jeden po drugim.
  12. Powtórz kroki 3–10 na wszystkich pozostałych węzłach Cassandra w centrum danych, jeden po drugim.
  13. Przebuduj wszystkie węzły w centrum danych z centrum danych, w którym działa starsza wersja Cassandry. Wykonaj ten krok po kolei na każdym węźle: 
    /opt/apigee/apigee-cassandra/bin/nodetool rebuild -dc <name of working DC>

    Ta procedura może zająć trochę czasu. W razie potrzeby możesz dostosować streamingthroughput. Sprawdź stan ukończenia operacji w nodetool netstats.

  14. (Opcjonalnie) Jeśli dane nie są odbudowywane, wykonaj polecenie naprawy w węźle Cassandra. 
    /opt/apigee/apigee-cassandra/bin/nodetool -h node-IP repair -pr
  15. Uruchom ponownie wszystkie komponenty edge-* w centrum danych, jeden po drugim: 
    /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
/opt/apigee/apigee-service/bin/apigee-service edge-router restart
/opt/apigee/apigee-service/bin/apigee-service edge-management-server restart
/opt/apigee/apigee-service/bin/apigee-service edge-qpid-server restart
/opt/apigee/apigee-service/bin/apigee-service edge-postgres-server restart
  16. Zweryfikuj i przekieruj ruch z powrotem do tego centrum danych. Przeprowadź w tym centrum danych weryfikację ruchu w środowisku wykonawczym i interfejsów API zarządzania Google Analytics, a następnie zacznij przekierowywać do niego ruch serwera proxy i interfejsu API zarządzania Google Analytics.
  17. Powtórz powyższe kroki w przypadku każdego centrum danych, które chcesz przywrócić.

Przywracanie bazy danych Cassandra za pomocą kopii zapasowej

Wymagania wstępne

  1. Uaktualniasz bazę danych Cassandra z wersji 4.0.X do wersji 5.0.X i podczas tego procesu wystąpiły problemy.
  2. Masz kopie zapasowe węzła, który chcesz przywrócić. Kopia zapasowa została utworzona przed próbą uaktualnienia z wersji 4.0.X do 5.0.X.

Kroki

  1. Wybierz węzeł, do którego chcesz wycofać zmiany. Jeśli przywracasz wszystkie węzły w centrum danych za pomocą kopii zapasowych, zacznij od węzłów źródłowych. Zapoznaj się z sekcją Jak identyfikować węzły początkowe w dodatku.

  2. Zatrzymaj, odinstaluj i wyczyść węzeł Cassandra:

    # Stop Cassandra service on the node
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra stop

# Uninstall Cassandra software
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra uninstall

# Wipe Cassandra data
rm -rf /opt/apigee/data/apigee-cassandra

  3. Zainstaluj starsze oprogramowanie Cassandra w węźle i skonfiguruj je:

    • Uruchom plik bootstrap dla Edge dla chmury prywatnej w wersji 4.53.00/4.53.01:
      • # Download bootstrap for 4.53.00
curl https://software.apigee.com/bootstrap_4.53.00.sh -o /tmp/bootstrap_4.53.00.sh -u uName:pWord

# Execute bootstrap for 4.53.00
sudo bash /tmp/bootstrap_4.53.00.sh apigeeuser=uName apigeepassword=pWord
    • Utwórz lub zmodyfikuj plik /opt/apigee/customer/application/cassandra.properties:
      • conf_jvm_options_custom_settings=-Dcassandra.replace_address=ipOfNode -Dcassandra.allow_unsafe_replace=true
    • Upewnij się, że plik należy do użytkownika apigee i jest możliwy do odczytu:
      • chown apigee:apigee /opt/apigee/customer/application/cassandra.properties
    • Zainstaluj i skonfiguruj system Cassandra:
      • # Install Cassandra version 4.0.X
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra install

# Set up Cassandra with the standard configuration file
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra setup -f configFile

# Verify Cassandra version and check service status
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra version
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra status

    Sprawdź, czy węzeł został uruchomiony. Sprawdź to polecenie na tym i innych węzłach w klastrze. Węzły powinny zgłaszać, że ten węzeł jest w stanie „UN”:

    /opt/apigee/apigee-cassandra/bin/nodetool status

  4. Zatrzymaj usługę Cassandra i przywróć kopię zapasową. Więcej informacji znajdziesz w dokumentacji dotyczącej tworzenia i przywracania kopii zapasowych:

    # Stop Cassandra service on the node
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra stop

# Wipe the data directory in preparation for restore
rm -rf /opt/apigee/data/apigee-cassandra/data

# Restore the backup taken before the upgrade attempt
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra restore backupFile

  5. Po przywróceniu kopii zapasowej usuń dodatkowe konfiguracje:

    Usuń z pliku /opt/apigee/customer/application/cassandra.properties konfigurację dodaną wcześniej.

  6. Uruchom usługę Cassandra w węźle:

    /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra start

  7. Powtórz te czynności na każdym węźle Cassandra, który chcesz przywrócić z kopii zapasowych, po kolei.

  8. Po przywróceniu wszystkich węzłów Cassandra uruchom ponownie wszystkie komponenty edge-*, jeden po drugim:

    /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
/opt/apigee/apigee-service/bin/apigee-service edge-router restart
/opt/apigee/apigee-service/bin/apigee-service edge-management-server restart
/opt/apigee/apigee-service/bin/apigee-service edge-qpid-server restart
/opt/apigee/apigee-service/bin/apigee-service edge-postgres-server restart

Optymalizacje kopii zapasowych (opcja zaawansowana)

Podczas przywracania kopii zapasowych możesz zminimalizować (lub wyeliminować) utratę danych, jeśli masz dostępne repliki zawierające najnowsze dane. Jeśli repliki są dostępne, po przywróceniu kopii zapasowej uruchom naprawę przywróconego węzła.

Dodatek

Jak identyfikować węzły początkowe

W dowolnym węźle Cassandra w centrum danych uruchom to polecenie:

/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra configure -search conf_cassandra_seeds

Polecenie wygeneruje kilka wierszy. Sprawdź ostatni wiersz danych wyjściowych. Adresy IP wymienione w ostatnim wierszu to węzły początkowe. W przykładzie poniżej DC-1-IP1, DC-1-IP2, DC-2-IP1 i DC-2-IP2 to adresy IP węzłów źródłowych:

Found key conf_cassandra_seeds, with value, "127.0.0.1", in /opt/apigee/apigee-cassandra/token/default.properties

Found key conf_cassandra_seeds, with value, 127.0.0.1, in /opt/apigee/apigee-cassandra/token/application/cassandra.properties

Found key conf_cassandra_seeds, with value, "DC-1-IP1, DC-1-IP2, DC-2-IP1, DC-2-IP2", in /opt/apigee/token/application/cassandra.properties
apigee-configutil: apigee-cassandra: # OK

Przywracanie ZooKeeper

Przywróć

W przypadku konieczności wycofania zmian:

  1. Najpierw wykonaj kroki wycofania w przypadku obserwatorów i osób obserwujących. Informacje o wybieraniu obserwatorów i obserwowanych znajdziesz w artykule Identyfikowanie lidera, obserwowanych i obserwatorów.
  2. Pobierz i uruchom program rozruchowy wersji, do której chcesz wrócić – 4.53.00 lub 4.53.01. Proces będzie się prawdopodobnie różnić w zależności od tego, czy węzeł ma zewnętrzne połączenie z internetem, czy też instalujesz go offline.
  3. Zatrzymaj ZooKeepera, jeśli jest uruchomiony w węźle: 
      /opt/apigee/apigee-service/bin/apigee-service apigee-zookeeper stop
  4. Odinstaluj istniejący ZooKeeper: 
      /opt/apigee/apigee-service/bin/apigee-service apigee-zookeeper uninstall
  5. Zainstaluj ZooKeepera w zwykły sposób: 
      /opt/apigee/apigee-setup/bin/setup.sh -p zk -f <silent-config-file>
  6. Po przywróceniu wszystkich węzłów podrzędnych i obserwatorów przywróć węzeł główny, wykonując kroki 2–5 na węźle głównym.
  7. Po przywróceniu wszystkich węzłów sprawdź stan klastra i upewnij się, że jest w nim węzeł lidera.

Przywróć kopię zapasową

Zapoznaj się z artykułem Przywracanie z kopii zapasowej.

Wycofaj Qpid

Aby wycofać zmiany do poprzedniej wersji, pobierz plik bootstrap.sh dla wersji, do której chcesz wycofać zmiany. Aby przywrócić wersję 4.53.00/4.53.01, pobierz bootstrap_4.53.00.sh.

Aby przywrócić Qpid, wykonaj te czynności na wszystkich hostach Qpid:

  1. Zatrzymaj istniejącego brokera Qpid: 
    apigee-service apigee-qpidd stop
  2. Zastosuj zaporę sieciową, aby zablokować ruch przychodzący na porcie brokera 5672 ze wszystkich procesorów komunikatów. Możesz zastosować tę zaporę sieciową na poziomie instancji węzła Qpid lub innego zewnętrznego komponentu zapory sieciowej/sieci.

    Zalecamy wykonanie tego samego kroku w przypadku wszystkich adresów IP procesorów komunikatów. Aby na przykład za pomocą IPTables odrzucić żądania przychodzące z adresów IP procesora komunikatów do węzła Qpid na porcie 5672, możesz użyć takiego polecenia:

    iptables -A INPUT -p tcp --dport 5672 -s MESSAGE_PROCESSOR_IP -j DROP
  3. Uruchom ponownie brokera Qpid, aby usunąć istniejące wiadomości, jeśli takie są: 
    apigee-service apigee-qpidd start
  4. Upewnij się, że istniejące kolejki są puste. Aby to sprawdzić, zaloguj się w portalu zarządzania Qpid: 
    http://QPID_NODE_IP:8090
  5. Po sprawdzeniu, czy kolejki są puste, zatrzymaj i odinstaluj Qpid: 
    /opt/apigee/apigee-service/bin/apigee-service apigee-qpidd stop
/opt/apigee/apigee-service/bin/apigee-service apigee-qpidd uninstall
  6. Usuń katalog danych Qpid: 
    rm -r APIGEE_ROOT/data/apigee-qpidd
  7. Ponownie zainstaluj brokera Qpid: 
    /opt/apigee/apigee-setup/bin/setup.sh -p qs -f configFile
  8. Po ponownym zainstalowaniu brokera Qpid usuń ustawienia zapory sieciowej i wyświetl listę wszystkich istniejących ustawień za pomocą tych poleceń: 
    iptables -F
iptables -L

Wycofaj zmiany w Postgres

Aby przejść z wersji 4.54.00 na wersję 4.53.00 lub 4.53.01, musisz cofnąć aktualizację Postgresa oraz komponentów Edge.

Aby wycofać aktualizację Postgres podczas aktualizowania Postgres w konfiguracji master-standby:

  • Awansuj nowy węzeł rezerwowy na mastera Postgres. Nowa instancja główna Postgres będzie w tej samej wersji co poprzednia instalacja Edge.
  • Skonfiguruj stary węzeł rezerwowy jako węzeł rezerwowy nowego węzła głównego. Stary węzeł rezerwowy będzie w tej samej wersji co poprzednia instalacja Edge.
  • Zarejestruj nowe węzły nadrzędne i rezerwowe w grupach analitycznych i konsumenckich.

Po zakończeniu przywracania stary węzeł główny nie będzie już potrzebny. Następnie możesz wycofać stary węzeł główny.

Zanim zaczniesz

Zanim cofniesz wersję Postgresa 18 do 17/14, wykonaj te czynności na nowym i starym hostu rezerwowym, aby zaktualizować właściwość max_locks_per_transaction na apigee-postgresql:

  1. Jeśli nie ma takiego pliku, utwórz go /opt/apigee/customer/application/postgresql.properties.
  2. Zmień własność tego pliku na apigee: 
    sudo chown apigee:apigee /opt/apigee/customer/application/postgresql.properties
  3. Dodaj do pliku tę właściwość: 
    conf/postgresql.conf+max_locks_per_transaction=30000
  4. Skonfiguruj apigee-postgresql: 
    apigee-service apigee-postgresql configure
  5. Uruchom ponownie apigee-postgresql: 
    apigee-service apigee-postgresql restart

Szczegółowa procedura wycofywania

  1. Sprawdź, czy nowy węzeł Postgres w trybie gotowości jest uruchomiony: 
    /opt/apigee/apigee-service/bin/apigee-all status

    Jeśli Postgres nie jest uruchomiony, uruchom go:

    /opt/apigee/apigee-service/bin/apigee-all start
  2. Upewnij się, że usługa Postgres została zatrzymana na starym węźle głównym i starym węźle rezerwowym: 
    /opt/apigee/apigee-service/bin/apigee-all status

    Jeśli Postgres działa, zatrzymaj go: 

    /opt/apigee/apigee-service/bin/apigee-service edge-postgres-server stop  
/opt/apigee/apigee-service/bin/apigee-service apigee-postgresql stop
  3. Jeśli jest zainstalowany, uruchom Qpid na starym węźle rezerwowym: 
    /opt/apigee/apigee-service/bin/apigee-service edge-qpid-server start
  4. Awansuj nowy węzeł rezerwowy na mastera Postgres:
    1. Awansuj nowy węzeł rezerwowy na nowy węzeł główny: 
      apigee-service apigee-postgresql promote-standby-to-master old_master_IP

      Jeśli pojawi się prośba, wpisz hasło Postgres dla użytkownika „apigee”, które domyślnie brzmi „postgres”.

    2. Zmodyfikuj plik konfiguracyjny użyty do zainstalowania bieżącej wersji Edge, aby określić te elementy: 
      # IP address of the new master:
PG_MASTER=new_standby_IP
# IP address of the old standby node
PG_STANDBY=old_standby_IP
    3. Skonfiguruj nowy master:
      /opt/apigee/apigee-service/bin/apigee-service apigee-postgresql setup-replication-on-master -f configFile
  5. Jeśli stary węzeł rezerwowy został już uaktualniony do nowszej wersji, musisz najpierw obniżyć wersję oprogramowania Apigee na starym węźle rezerwowym. Jeśli starsza wersja jest nadal na starym węźle rezerwowym, możesz pominąć ten krok i przejść do kroku 6.
    1. Zatrzymaj Postgres na starym węźle rezerwowym: 
      apigee-service apigee-postgresql stop
apigee-service edge-postgres-server stop
    2. Odinstaluj Postgres ze starego węzła rezerwowego: 
      apigee-service apigee-postgresql uninstall
apigee-service edge-postgres-server uninstall
apigee-service edge-analytics uninstall
    3. Usuń katalog danych Postgres ze starego węzła rezerwowego: 
      cd /opt/apigee/data/apigee-postgresql/pgdata
rm -rf *
    4. Pobierz i uruchom starszą wersję programu startowego (w wersji Apigee, do której chcesz wrócić) na starym węźle rezerwowym. Konkretne czynności mogą się różnić w zależności od tego, czy używasz instalacji internetowej czy offline. Uruchomienie starszej wersji programu Apigee bootstrap spowoduje skonfigurowanie repozytoriów yum ze starszą wersją danych Apigee.
    5. Skonfiguruj komponenty Postgres na starym węźle rezerwowym: 
      /opt/apigee/apigee-setup/bin/setup.sh -p ps -f configFile
    6. Sprawdź, czy komponenty Postgres na starym węźle rezerwowym zostały przywrócone do starszej wersji: 
      apigee-service apigee-postgresql version
apigee-service edge-postgres-server version
  6. Odbuduj stary węzeł rezerwowy:
    1. Edytuj plik konfiguracyjny, którego użyto do zainstalowania bieżącej wersji Edge, aby określić: 
      # IP address of the new master:
PG_MASTER=new_standby_IP
# IP address of the old standby node
PG_STANDBY=old_standby_IP
    2. Usuń katalog danych na starym węźle rezerwowym: 
      cd /opt/apigee/data/apigee-postgresql/pgdata
rm -rf *
    3. Zmień konfigurację starego węzła rezerwowego, aby stał się węzłem rezerwowym nowego węzła głównego: 
      /opt/apigee/apigee-service/bin/apigee-service apigee-postgresql setup-replication-on-standby -f configFile
    4. Upewnij się, że Postgres działa na starym węźle rezerwowym: 
      /opt/apigee/apigee-service/bin/apigee-all status

      Jeśli Postgres nie działa, uruchom go:

      /opt/apigee/apigee-service/bin/apigee-service edge-postgres-server start
  7. Sprawdź, czy nowy węzeł rezerwowy został dodany, wyświetlając plik /opt/apigee/apigee-postgresql/conf/pg_hba.conf na nowym węźle głównym.
  8. Aby wyświetlić bieżące informacje o analityce i grupie konsumentów, uruchom to polecenie na serwerze zarządzającym: 
    curl -u sysAdminEmail:password http://ms_IP:8080/v1/analytics/groups/ax

    To polecenie zwraca nazwę grupy analitycznej w polu name i nazwę grupy konsumentów w polu name w sekcji consumer-groups. Zwraca też identyfikatory UUID starych węzłów głównych i rezerwowych Postgres w polu postgres-server i w polu datastores. Powinny się wyświetlić dane wyjściowe w tej postaci: 

    {
  "name" : "axgroup-001",
  "properties" : {
  },
  "scopes" : [ "VALIDATE~test", "sgilson~prod" ],
  "uuids" : {
    "qpid-server" : [ "8381a053-433f-4382-bd2a-100fd37a1592", "4b6856ec-ef05-498f-bac6-ef5f0d5f6521" ],
    "postgres-server" : [
      "ab1158bd-1d59-4e2a-9c95-24cc2cfa6edc:27f90844-efab-4b32-8a23-8f85cdc9a256"
    ]
  },
  "consumer-groups" : [ {
    "name" : "consumer-group-001",
    "consumers" : [ "8381a053-433f-4382-bd2a-100fd37a1592", "4b6856ec-ef05-498f-bac6-ef5f0d5f6521" ],
    "datastores" :
      [ "ab1158bd-1d59-4e2a-9c95-24cc2cfa6edc:27f90844-efab-4b32-8a23-8f85cdc9a256" ],
      "properties" : {     }
    }
  ],
  "data-processors" : {
  }
}
  9. Pobierz adres UUID starego węzła głównego, uruchamiając na nim to polecenie curl: 
    curl -u sysAdminEmail:password http://node_IP:8084/v1/servers/self

    Na końcu danych wyjściowych powinien pojawić się identyfikator UUID węzła w formacie:

    "type" : [ "postgres-server" ],
"uUID" : "599e8ebf-5d69-4ae4-aa71-154970a8ec75"
  10. Powtórz poprzedni krok, aby uzyskać adresy IP starego węzła rezerwowego i nowego węzła głównego.
  11. Usuń stare węzły główne i rezerwowe z grupy konsumentów: 
    curl -u sysAdminEmail:password -X DELETE \
  "http://ms_IP:8080/v1/analytics/groups/ax/axgroup-001/consumer-groups/consumer-group-001/datastores/masterUUID,standbyUUID" -v

    Gdzie axgroup-001 i consumer-group-001 to domyślne nazwy grup analitycznych i konsumenckich. masterUUID,standbyUUID są w tej samej kolejności, w jakiej pojawiły się powyżej, gdy wyświetlałeś(-aś) aktualne informacje o analityce i grupach konsumentów. Może być konieczne określenie ich jako standbyUUID,masterUUID.

    Właściwość datastores dla consumer-groups powinna być teraz pusta.

  12. Usuń stare węzły nadrzędne i rezerwowe z grupy analityki: 
    curl -u sysAdminEmail:password -X DELETE \
  "http://ms_IP:8080/v1/analytics/groups/ax/axgroup-001/servers?uuid=masterUUID,standbyUUID&type=postgres-server" -v

    Właściwość postgres-server w sekcji uuids powinna być teraz pusta.

  13. Zarejestruj nowe węzły główne i rezerwowe PG w grupach analitycznych i konsumenckich:
    curl -u sysAdminEmail:password -X POST -H "Content-Type: application/json" -d ''
  "http://ms_IP:8080/v1/analytics/groups/ax/axgroup-001/servers?uuid=masterUUID,standbyUUID&type=postgres-server" -v
curl -u sysAdminEmail:password -X POST -H "Content-Type:application/json" -d ''
  "http://ms_IP:8080/v1/analytics/groups/ax/axgroup-001/consumer-groups/consumer-group-001/datastores?uuid=masterUUID,standbyUUID" -v
  14. Sprawdź grupę statystyk: 
    curl -u sysAdminEmail:password http://ms_IP:8080/v1/analytics/groups/ax

    W grupie analitycznej i grupie konsumentów powinny być widoczne identyfikatory UUID nowych węzłów głównych i węzłów gotowości.

  15. Ponownie uruchom serwer zarządzania Edge: 
    /opt/apigee/apigee-service/bin/apigee-service edge-management-server restart
  16. Uruchom ponownie wszystkie serwery Qpid: 
    /opt/apigee/apigee-service/bin/apigee-service edge-qpid-server restart
  17. Uruchom ponownie wszystkie serwery Postgres: 
    /opt/apigee/apigee-service/bin/apigee-service edge-postgres-server restart
  18. Sprawdź stan replikacji, uruchamiając te skrypty na obu serwerach. Aby zapewnić prawidłową replikację, system powinien wyświetlać identyczne wyniki na obu serwerach:

    Na nowym węźle głównym uruchom:

    /opt/apigee/apigee-service/bin/apigee-service apigee-postgresql postgres-check-master

    Sprawdź, czy jest to urządzenie główne. Na starym węźle rezerwowym uruchom:

    /opt/apigee/apigee-service/bin/apigee-service apigee-postgresql postgres-check-standby

    Sprawdź, czy jest w trybie gotowości.

  19. Po wysłaniu kilku żądań do interfejsu API powtórz poprzedni krok, aby upewnić się, że węzły są zsynchronizowane.
  20. Wycofaj stary węzeł główny Postgres:

    Możesz też odinstalować Qpid ze starego węzła głównego i zainstalować go na nowym węźle głównym. Po odinstalowaniu Qpid możesz wycofać stary węzeł główny.

Wycofywanie nowego interfejsu Edge

Apigee Edge dla chmury prywatnej w wersji 4.54.00 zastępuje klasyczny interfejs użytkownika (edge-ui) nowym interfejsem Edge (edge-management-ui). Ponieważ komponent interfejsu zmienia się w wersji 4.54.00, przywrócenie wersji 4.53.00 lub 4.53.01 wymaga odinstalowania edge-management-ui i ponownego zainstalowania poprzedniego profilu interfejsu:

  • Klasyczny interfejs (edge-ui): ponownie zainstaluj profil ui.
  • Nowy interfejs Edge (edge-ui i edge-management-ui): ponownie zainstaluj profile ui i ue w odpowiednich węzłach.

Aby przywrócić interfejs na węźle:

  1. Zatrzymaj i odinstaluj nowy interfejs Edge w wersji 4.54.00, a następnie zainstaluj poprzednią wersję, aby przywrócić stan sprzed aktualizacji:
    1. Zatrzymaj i odinstaluj interfejs New Edge w wersji 4.54.00:edge-management-ui 
      /opt/apigee/apigee-service/bin/apigee-service edge-management-ui stop
/opt/apigee/apigee-service/bin/apigee-service edge-management-ui uninstall
/opt/apigee/apigee-service/bin/apigee-service edge-management-ui-static uninstall
    2. Uruchom plik bootstrap dla Apigee Edge dla chmury prywatnej w wersji 4.53.00/4.53.01: 
      # Download bootstrap for 4.53.00
curl https://software.apigee.com/bootstrap_4.53.00.sh -o /tmp/bootstrap_4.53.00.sh -u uName:pWord

# Execute bootstrap for 4.53.00
sudo bash /tmp/bootstrap_4.53.00.sh apigeeuser=uName apigeepassword=pWord
    3. Przywróć poprzednią wersję apigee-setup z 4.54.00: 
      # Uninstall apigee-setup
/opt/apigee/apigee-service/bin/apigee-service apigee-setup uninstall

# Install apigee-setup
/opt/apigee/apigee-service/bin/apigee-service apigee-setup install
  2. Przywróć konfiguracje interfejsu w wersji 4.53.00 lub 4.53.01:
    • Jeśli masz kopię zapasową pliku konfiguracji instalacji dyskretnej z instalacji w wersji 4.53.00 lub 4.53.01, użyj tego pliku kopii zapasowej do procedury przywracania. W przeciwnym razie w pliku konfiguracji cichej w wersji 4.54.00 przywróć lub usuń znacznik komentarza właściwości interfejsu użytkownika w wersji 4.53.00 lub 4.53.01, które zostały usunięte lub zmienione w komentarz podczas uaktualniania. Więcej informacji znajdziesz w sekcji dotyczącej uaktualnienia interfejsu.
    • Jeśli podczas uaktualniania usunięto plik /opt/apigee/customer/application/ui.properties, przywróć go z katalogu kopii zapasowej: 
      cp -rf /opt/apigee/backup/ui/customer/application/ui.properties /opt/apigee/customer/application/
chown apigee:apigee /opt/apigee/customer/application/ui.properties
  3. Ponownie zainstaluj i skonfiguruj poprzednią wersję interfejsu:
    • Wróć do interfejsu klasycznego (edge-ui):
      1. Zainstaluj i skonfiguruj interfejs klasyczny (w przypadku uwierzytelniania podstawowego nie są wymagane żadne dodatkowe czynności): 
        /opt/apigee/apigee-setup/bin/setup.sh -p ui -f configFile
      2. Jeśli logowanie jednokrotne jest włączone, skonfiguruj je w klasycznym interfejsie (najpierw upewnij się, że apigee-sso jest uruchomione): 
        /opt/apigee/apigee-service/bin/apigee-service edge-ui configure-sso -f configFile
    • Wycofanie do wersji 4.53.00 lub 4.53.01 nowego interfejsu Edge (edge-management-ui i Shoehorn edge-ui):
      1. Upewnij się, że w pliku konfiguracji instalacji dyskretnej ustawiono EDGEUI_ENABLE_UNIFIED_UI=y, a następnie zainstaluj i skonfiguruj profile ui i ue: 
        /opt/apigee/apigee-setup/bin/setup.sh -p ui -f configFile
/opt/apigee/apigee-setup/bin/setup.sh -p ue -f configFile
      2. Jeśli logowanie jednokrotne jest włączone, skonfiguruj je w obu komponentach interfejsu (najpierw upewnij się, że usługa apigee-sso jest uruchomiona): 
        /opt/apigee/apigee-service/bin/apigee-service edge-ui configure-sso -f configFile
/opt/apigee/apigee-service/bin/apigee-service edge-management-ui configure-sso -f configFile
  4. Sprawdź stan i wersję przywróconego interfejsu:
    • W klasycznym interfejsie (edge-ui): 
      /opt/apigee/apigee-service/bin/apigee-service edge-ui status
/opt/apigee/apigee-service/bin/apigee-service edge-ui version
    • W przypadku interfejsu New Edge (edge-management-ui): 
      /opt/apigee/apigee-service/bin/apigee-service edge-management-ui status
/opt/apigee/apigee-service/bin/apigee-service edge-management-ui version

Przywracanie OpenLDAP

Ta sekcja zawiera szczegółowy przewodnik po przywracaniu Symas OpenLDAP 2.6.10 w Edge dla chmury prywatnej 4.54.00 do OpenLDAP 2.4.46 (Edge dla chmury prywatnej 4.53.00) lub Symas OpenLDAP 2.6.7 (Edge dla chmury prywatnej 4.53.01). Musisz przywrócić cały klaster LDAP, używając prawidłowej kopii zapasowej LDAP sprzed uaktualnienia.

Głównym celem jest przywrócenie całego klastra LDAP do spójnego stanu ze znanej, prawidłowej kopii zapasowej. Ta procedura jest taka sama we wszystkich scenariuszach: pojedynczy serwer, aktywny-aktywny i aktywny-pasywny.

Zanim zaczniesz

  • Niezgodność kopii zapasowej: użyj kopii zapasowej sprzed uaktualnienia z OpenLDAP 2.4.46 (Edge dla chmury prywatnej 4.53.00) lub Symas OpenLDAP 2.6.7 (Edge dla chmury prywatnej 4.53.01) utworzonej za pomocą apigee-service apigee-openldap backup przed próbą uaktualnienia. Kopie zapasowe utworzone po uaktualnieniu są niezgodne i nie można ich używać.
  • Przerwa w działaniu interfejsu Management API: podczas przywracania LDAP interfejsy Management API będą niedostępne, co może mieć wpływ na zadania administracyjne. Zanim przejdziesz do przywracania LDAP, wyłącz wszystkie instancje edge-management-server i edge-ui.
  • Ryzyko utraty danych: kontynuowanie bez prawidłowej, zgodnej kopii zapasowej może spowodować nieodwracalną utratę danych.
  • Prawidłowa kopia zapasowa: wymagana jest prawidłowa kopia zapasowa LDAP sprzed uaktualnienia.
  • Kopia zapasowa plików silent.conf: zachowaj kopie zapasowe plików silent.conf z poprzedniej i bieżącej wersji, aby zapobiec pomieszaniu konfiguracji podczas procedur aktualizacji i przywracania.
  • Kolejność wycofywania: przed wycofaniem OpenLDAP wykonaj procedury wycofywania dla Cassandra, ZooKeeper, Qpid, PostgreSQL, apigee-sso i interfejsu Edge.

Procedura wycofywania

  1. Wyłącz serwer zarządzania i interfejs: przed przywróceniem LDAP wyłącz wszystkie instancje edge-management-server i edge-ui: 
    apigee-service edge-management-server stop
apigee-service edge-ui stop
  2. Zapisz bieżącą liczbę wpisów LDAP (przed zatrzymaniem LDAP): pobierz łączną liczbę rekordów ze wszystkich serwerów LDAP, zastępując YOUR_PASSWORD bieżącym hasłem menedżera LDAP. (Liczba rekordów musi być taka sama na wszystkich serwerach LDAP). 
    # Note: Replace 'YOUR_PASSWORD' with your current LDAP manager password.
ldapsearch -o ldif-wrap=no -b "dc=apigee,dc=com" -D "cn=manager,dc=apigee,dc=com" -H ldap://:10389 -LLL -x -w 'YOUR_PASSWORD' | wc -l
  3. Zatrzymaj i odinstaluj nową wersję LDAP 2.6: zatrzymaj usługę apigee-openldap i usuń jej konfigurację oraz katalogi danych. Aby zapewnić spójność, wykonaj ten krok na wszystkich serwerach LDAP, po jednym węźle w klastrze: 
    apigee-service apigee-openldap stop
apigee-service apigee-openldap uninstall
rm -rf /opt/apigee/data/apigee-openldap/*
  4. Zainstaluj poprzednią wersję LDAP 2.4.46 lub 2.6.7:
    • Instalowanie starej wersji LDAP: 
      /opt/apigee/apigee-setup/bin/setup.sh -p ld -f /opt/silent.conf
    • Sprawdź wersję LDAP: 
      source ~/.bash_profile
ldapsearch -VV

# Expected output if rolled back to 4.53.00:
ldapsearch: @(#) $OpenLDAP: ldapsearch 2.4.46

# Expected output if rolled back to 4.53.01:
ldapsearch: @(#) $OpenLDAP: ldapsearch 2.6.7
    • Powtórz poprzednie podkroki w kroku 4 na każdym węźle LDAP, po kolei.
  5. Wyczyść dane resztkowe: na wszystkich serwerach LDAP po kolei zatrzymaj nowo zainstalowaną usługę i wyczyść jej katalog danych, aby przygotować się do przywrócenia z kopii zapasowej: 
    apigee-service apigee-openldap stop
rm -rf /opt/apigee/data/apigee-openldap/*
  6. Przywróć dane LDAP: w przypadku konfiguracji z jednym serwerem przejdź bezpośrednio do kroku 6b. W przypadku konfiguracji z wieloma serwerami przejdź do kroku 6a.
    1. Określ aktywny serwer LDAP: przed przywróceniem danych LDAP określ aktywny serwer (dostawcę), uruchamiając to polecenie: 
      grep -i '^olcSyncrepl:' /opt/apigee/data/apigee-openldap/slapd.d/cn=config/olcDatabase*.ldif
    2. Przywróć dane LDAP (przed przywróceniem upewnij się, że krok 5 został wykonany na wszystkich serwerach):
      • Na pojedynczym lub aktywnym serwerze LDAP (określonym w kroku 6a) przejdź do katalogu kopii zapasowych i przywróć kopię zapasową sprzed uaktualnienia (np. 2025.07.28,13.59.00, lub pomiń sygnaturę czasową, jeśli kopia zapasowa sprzed uaktualnienia jest najnowszą kopią zapasową w katalogu): 
        cd /opt/apigee/backup/openldap

# To restore a specific backup, provide the timestamp as shown below:
apigee-service apigee-openldap restore 2025.07.28,13.59.00

# Note: If no timestamp is provided, the latest available backup will be restored by default:
apigee-service apigee-openldap restore

# It is recommended to specify the backup explicitly to avoid restoring an unintended version.
      • Uruchom usługę apigee-openldap: 
        apigee-service apigee-openldap start
  7. Uruchom pozostałe serwery LDAP: jeśli masz konfigurację z wieloma serwerami, uruchom usługę na każdym z pozostałych serwerów LDAP: 
    apigee-service apigee-openldap start
  8. Weryfikacja końcowa:
    • Sprawdź, czy wycofanie zmian zakończyło się powodzeniem i czy dane są spójne w całym klastrze LDAP.
    • Uruchom polecenie weryfikacji na wszystkich serwerach LDAP, zastępując YOUR_PASSWORD bieżącym hasłem menedżera LDAP. Liczba rekordów musi być identyczna na wszystkich serwerach i musi odpowiadać liczbie zarejestrowanej w kroku 2: 
      # Note: Replace 'YOUR_PASSWORD' with your current LDAP manager password.
ldapsearch -o ldif-wrap=no -b "dc=apigee,dc=com" -D "cn=manager,dc=apigee,dc=com" -H ldap://:10389 -LLL -x -w 'YOUR_PASSWORD' | wc -l
    • Gdy potwierdzisz, że dane są prawidłowe i spójne, uruchom edge-management-server, edge-ui i inne zależne komponenty zgodnie ze standardową procedurą organizacji.

Wycofaj komponenty brzegowe

Komponenty ze wspólnym kodem

Poniższe komponenty Edge mają wspólny kod. Dlatego, aby wycofać dowolny z tych komponentów na węźle, musisz wycofać wszystkie te komponenty, które znajdują się na tym węźle:

  • edge-management-server (serwer zarządzania)
  • edge-message-processor (procesor komunikatów)
  • edge-router (router)
  • edge-postgres-server (serwer Postgres)
  • edge-qpid-server (serwer Qpid)

Jeśli na przykład na węźle masz zainstalowane serwer zarządzania, router i procesor wiadomości, aby cofnąć zmiany w jednym z nich, musisz cofnąć zmiany we wszystkich trzech.

Aby przywrócić poprzednią wersję główną lub pomocniczą, wykonaj te czynności na każdym węźle, który hostuje komponent:

  1. Pobierz plik bootstrap.sh dla wersji, do której chcesz wrócić:

    • Aby przywrócić wersję 4.53.00/4.53.01, pobierz bootstrap_4.53.00.sh/bootstrap_4.53.01.sh
  2. Zatrzymaj komponent, który chcesz wycofać:
    1. Aby przywrócić poprzednią wersję dowolnego komponentu ze wspólnym kodem w węźle, musisz zatrzymać je wszystkie, jak pokazano w tym przykładzie: 
      /opt/apigee/apigee-service/bin/apigee-service edge-management-server stop
/opt/apigee/apigee-service/bin/apigee-service edge-router stop
/opt/apigee/apigee-service/bin/apigee-service edge-message-processor stop
/opt/apigee/apigee-service/bin/apigee-service edge-qpid-server stop
/opt/apigee/apigee-service/bin/apigee-service edge-postgres-server stop
    2. Aby przywrócić inny komponent w węźle, zatrzymaj tylko ten komponent: 
      /opt/apigee/apigee-service/bin/apigee-service component stop
  3. Jeśli wycofujesz Monetization, odinstaluj go ze wszystkich węzłów serwera zarządzania i procesora komunikatów: 
    /opt/apigee/apigee-service/bin/apigee-service edge-mint-gateway uninstall
  4. Odinstaluj komponent, aby wycofać zmiany na węźle:
    1. Aby wycofać dowolny komponent ze wspólnym kodem na węźle, musisz odinstalować wszystkie komponenty, odinstalowując grupę komponentów edge-gateway i apigee-cassandra-client, jak pokazano w tym przykładzie: 
      /opt/apigee/apigee-service/bin/apigee-service edge-gateway uninstall
       
      /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra-client uninstall
    2. Aby wycofać zmiany w Nginx: 
      ### Find the apigee-nginx RPM
rpm -qa | grep -i "apigee-nginx"

### Remove the apigee-nginx RPM
dnf remove apigee-nginx-1.30.x
    3. Aby wycofać zmiany w dowolnym innym komponencie na węźle, odinstaluj tylko ten komponent, jak pokazano w tym przykładzie: 
      /opt/apigee/apigee-service/bin/apigee-service component uninstall

      Gdzie component to nazwa komponentu.

    4. Aby przywrócić router brzegowy, musisz usunąć zawartość pliku /opt/nginx/conf.d i odinstalować grupę komponentów edge-gateway: 
      cd /opt/nginx/conf.d
rm -rf *
  5. Odinstaluj wersję 4.54.00 aplikacji apigee-setup: 
    /opt/apigee/apigee-service/bin/apigee-service apigee-setup uninstall
  6. Zainstaluj wersję 4.53.00 narzędzia apigee-service i jego zależności. Ten przykład instaluje wersję 4.53.00 narzędzia apigee-service: 
    sudo bash /tmp/bootstrap_4.53.00.sh apigeeuser=uName apigeepassword=pWord

    gdzie uName i pWord to nazwa użytkownika i hasło otrzymane od Apigee. Jeśli pominiesz pWord, pojawi się prośba o jego podanie.

    Jeśli pojawi się błąd, upewnij się, że w kroku 1 został pobrany plik bootstrap.sh.

  7. Zainstaluj apigee-setup: 
    /opt/apigee/apigee-service/bin/apigee-service apigee-setup install
  8. Zainstaluj starszą wersję komponentu: 
    /opt/apigee/apigee-setup/bin/setup.sh -p component -f configFile

    Gdzie component to komponent do zainstalowania, a configFile to plik konfiguracji starszej wersji.

  9. Jeśli przywracasz Qpid, wyczyść iptables: 
    sudo iptables -F
  10. Powtórz ten proces dla każdego węzła, który hostuje komponent, który chcesz wycofać.

Wycofaj mTLS

Aby wycofać aktualizację mTLS, wykonaj te czynności na wszystkich hostach:

  1. Zatrzymaj Apigee: 
    apigee-all stop
  2. Zatrzymaj mTLS: 
    apigee-service apigee-mtls uninstall
  3. Ponowna instalacja mTLS: 
    apigee-service apigee-mtls install
apigee-service apigee-mtls setup -f /opt/silent.conf