Aktualizowanie Apigee Edge w wersji 4.52.02 lub 4.53.00 do wersji 4.53.01

Apigee obsługuje uaktualnianie Edge for Private Cloud bezpośrednio z wersji 4.52.02 lub 4.53.00 do wersji 4.53.01. Na tej stronie dowiesz się, jak przeprowadzać takie uaktualnienia.

Omówienie zgodnych ścieżek uaktualniania znajdziesz w macierzy zgodności uaktualnień w przypadku wersji Edge dla chmury prywatnej.

Kto może przeprowadzić aktualizację

Osoba przeprowadzająca aktualizację powinna być tą samą osobą, która pierwotnie zainstalowała Edge, lub osobą z uprawnieniami roota.

Po zainstalowaniu pakietów RPM Edge każdy może je skonfigurować.

Które komponenty musisz zaktualizować

Musisz zaktualizować wszystkie komponenty Edge. Edge nie obsługuje konfiguracji zawierającej komponenty z wielu wersji.

Aktualizowanie wymagań wstępnych

W tej wersji rozwiązaliśmy kilka problemów z bezpieczeństwem. Te ulepszenia zabezpieczeń są niezbędne, ale wprowadzają pewne zmiany, które nie są wstecznie kompatybilne. Oznacza to, że uaktualnienie będzie wymagać dodatkowych czynności, aby zapewnić brak przerw w działaniu usługi w trakcie uaktualniania i po nim. Więcej informacji znajdziesz w tym artykule. Przeczytaj go dokładnie, zanim uaktualnisz starsze wersje chmury prywatnej do wersji 4.53.01.

Przed uaktualnieniem Apigee Edge sprawdź, czy spełniasz te wymagania wstępne:

• Utwórz kopię zapasową wszystkich węzłów
  Ze względów bezpieczeństwa przed aktualizacją zalecamy utworzenie pełnej kopii zapasowej wszystkich węzłów. Aby utworzyć kopię zapasową, wykonaj procedurę odpowiednią dla Twojej wersji Edge.

  Dzięki temu będziesz mieć plan awaryjny na wypadek, gdyby aktualizacja do nowej wersji nie działała prawidłowo. Więcej informacji o kopiach zapasowych znajdziesz w artykule Kopia zapasowa i przywracanie.

• Sprawdź, czy Edge jest uruchomiony
  Sprawdź, czy Edge jest uruchomiony podczas procesu aktualizacji, używając polecenia:

  /opt/apigee/apigee-service/bin/apigee-all status

• Sprawdź wymagania wstępne dotyczące Cassandry
  

  Jeśli wcześniej przeprowadzono uaktualnienie ze starszej wersji Edge dla chmury prywatnej do wersji 4.52.02, a teraz planujesz uaktualnienie do wersji 4.53.01, upewnij się, że wykonano wymagane czynności po uaktualnieniu w przypadku Cassandry. Te czynności są opisane w dokumentacji uaktualnienia do wersji 4.52.02, a także w sekcji Wymagania wstępne dotyczące uaktualnienia systemu Cassandra. Jeśli nie masz pewności, czy te czynności zostały wykonane podczas poprzedniej aktualizacji, wykonaj je ponownie, zanim przejdziesz do aktualizacji do wersji 4.53.01.

• Konfigurowanie kluczy i certyfikatów dostawcy tożsamości w Edge for Private Cloud 4.53.01
  

  W Edge for Private Cloud w wersji 4.53.01 klucze i certyfikaty dostawcy tożsamości używane w komponencie apigee-sso są teraz konfigurowane za pomocą magazynu kluczy. Musisz wyeksportować używany wcześniej klucz i certyfikat do magazynu kluczy. Przed zaktualizowaniem komponentu logowania jednokrotnego wykonaj szczegółowe czynności opisane w sekcji Czynności związane z aktualizacją logowania jednokrotnego Apigee ze starszych wersji.

• Wymagania dotyczące Pythona
  Przed rozpoczęciem uaktualniania upewnij się, że na wszystkich węzłach, w tym na węzłach Cassandry, jest zainstalowany Python 3.

Specjalne kroki, które należy wykonać podczas uaktualniania

Aby uaktualnić Edge dla chmury prywatnej do wersji 4.53.01, wykonaj określone czynności związane z uaktualnianiem niektórych programów. Wymagane czynności zależą od aktualnej wersji. W tabeli poniżej znajdziesz różne programy wymagające dodatkowych czynności. Postępuj zgodnie ze szczegółowymi instrukcjami dotyczącymi każdego z nich. Po wykonaniu niezbędnych czynności wróć do głównej procedury uaktualniania, aby kontynuować proces uaktualniania.

Po wykonaniu odpowiednich czynności w zależności od wersji wróć do głównej procedury uaktualniania, aby kontynuować.

Automatyczne propagowanie ustawień usługi

Jeśli jakiekolwiek właściwości zostały ustawione przez edycję plików .properties w /opt/apigee/customer/application, te wartości zostaną zachowane po aktualizacji.

Wymagana aktualizacja do OpenLDAP 2.6

Poniżej znajdziesz szczegółową procedurę uaktualniania usługi LDAP w Apigee Edge dla chmury prywatnej z starszej wersji OpenLDAP 2.4 do OpenLDAP 2.6. Ta aktualizacja jest wymagana w przypadku aktualizacji do Apigee Edge Private Cloud w wersji 4.53.01 i nowszych. Uaktualnienie dotyczy wszystkich topologii wdrożenia LDAP Apigee: pojedynczego serwera, aktywnego-pasywnego i aktywnego-aktywnego (wielu serwerów głównych).

Wymagania wstępne i kwestie do rozważenia

• Pamiętaj, że podczas procesu uaktualniania protokołu LDAP interfejsy API zarządzania, a w konsekwencji interfejs Apigee, będą całkowicie niedostępne we wszystkich regionach. Wszystkie zadania administracyjne, takie jak zarządzanie użytkownikami, rolami, aplikacjami i organizacjami, nie będą działać i należy je wstrzymać. Nie będzie to miało wpływu na przetwarzanie ruchu serwera proxy interfejsu API. Zanim przejdziesz dalej z uaktualnianiem LDAP, wyłącz wszystkie serwery zarządzania brzegowego i interfejs brzegowy.

• Kopia zapasowa ma kluczowe znaczenie: pełna i zweryfikowana kopia zapasowa dotychczasowych danych LDAP jest niezbędna. Kontynuowanie bez prawidłowej kopii zapasowej spowoduje nieodwracalną utratę danych. Kopię zapasową należy utworzyć, gdy usługa LDAP jest nadal uruchomiona, aby uzyskać spójny zrzut danych LDAP w danym momencie. Aby przeprowadzić aktualizację, musisz utworzyć kopię zapasową. Bez kopii zapasowej nie będzie można przeprowadzić uaktualnienia ani przywrócić poprzedniej wersji, ponieważ proces uaktualniania obejmuje usunięcie danych LDAP.

Przygotowanie i instalacja (wszystkie serwery LDAP)

Czynności opisane w tej sekcji (kroki 2–5) są identyczne w przypadku wszystkich topologii wdrożenia LDAP. Te działania należy wykonać na każdym serwerze, na którym jest zainstalowany komponent apigee-openldap, niezależnie od jego roli.

1. Zanim przejdziesz dalej z aktualizacją LDAP, wyłącz wszystkie serwery edge-management-server i edge-ui.

   apigee-service edge-management-server stop
   apigee-service edge-ui stop

2. Tworzenie kopii zapasowej dotychczasowych danych LDAP

   Przed wprowadzeniem jakichkolwiek zmian wykonaj pełną kopię zapasową bieżących danych LDAP ze wszystkich serwerów LDAP. Spowoduje to utworzenie bezpiecznego punktu przywracania.

   • Uruchom polecenie tworzenia kopii zapasowej. To działanie tworzy w katalogu /opt/apigee/backup/openldap archiwum kopii zapasowej z sygnaturą czasową.

     apigee-service apigee-openldap backup

   • Uzyskaj łączną liczbę rekordów: zapisz liczbę rekordów w katalogu na potrzeby weryfikacji po uaktualnieniu (liczba rekordów powinna być taka sama na wszystkich serwerach LDAP). To jest test sprawdzający.

     # 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. Zatrzymywanie LDAP i czyszczenie katalogów danych

   Tę czynność należy wykonać na wszystkich serwerach LDAP. Jest to obowiązkowe ze względu na zmianę wersji głównej i zasadnicze różnice strukturalne. Czysty katalog zapewnia brak konfliktów. Gdy wszystkie serwery LDAP zostaną zatrzymane, zaczną występować zakłócenia w działaniu interfejsów Management API i interfejsu użytkownika.

   • Zatrzymaj usługę LDAP.

     apigee-service apigee-openldap stop

   • Trwale usuń stare katalogi danych i konfiguracji LDAP.

     rm -rf /opt/apigee/data/apigee-openldap/*

4. Instalowanie i konfigurowanie nowej wersji LDAP

   Na wszystkich serwerach LDAP użyj standardowych skryptów Apigee, aby pobrać i zainstalować nową wersję komponentu.

   • Zainstaluj nowy komponent LDAP: skrypt aktualizacji odczytuje plik konfiguracyjny i instaluje nowy pakiet apigee-openldap.

     /opt/apigee/apigee-setup/bin/update.sh -c ldap -f /opt/silent.conf

   • Sprawdź nową wersję LDAP: po zakończeniu instalacji ponownie załaduj profil i sprawdź, czy nowa wersja LDAP jest prawidłowo zainstalowana.

     source ~/.bash_profile
     ldapsearch -VV
     Expected output:
     ldapsearch: @(#) $OpenLDAP: ldapsearch 2.6.7

5. Zatrzymaj LDAP na wszystkich serwerach przed przywróceniem danych

   To kluczowy etap synchronizacji. Przed przywróceniem kopii zapasowej musisz się upewnić, że nowo zainstalowana usługa LDAP jest zatrzymana na wszystkich serwerach. Na każdym serwerze LDAP wykonaj te polecenia:

   apigee-service apigee-openldap stop
   rm -rf /opt/apigee/data/apigee-openldap/ldap/*

6. Przywracanie danych LDAP

   Strategia polega na przywróceniu kopii zapasowej na pierwszym aktywnym serwerze. Ten serwer będzie wtedy działać jako źródło informacji, replikując dane na inne serwery w konfiguracji wieloserwerowej.

   1. Określ pierwszy aktywny serwer do przywrócenia

      • W przypadku konfiguracji z jednym serwerem: jest to jedyny serwer LDAP. Możesz przejść od razu do następnego kroku.
      • W przypadku konfiguracji aktywnej i pasywnej oraz aktywnej i aktywnej: na każdym serwerze LDAP uruchom to polecenie diagnostyczne:

        grep -i '^olcSyncrepl:' /opt/apigee/data/apigee-openldap/slapd.d/cn=config/olcDatabase*\ldif
        Note:
        -If this command returns output, the server is a passive server.
        -If it returns no output, the server is the active server.

   2. Przywracanie danych z kopii zapasowej

      Zanim przejdziesz dalej, sprawdź, czy krok 5 został pomyślnie wykonany na wszystkich serwerach LDAP.

      • Na pierwszym aktywnym serwerze, który został zidentyfikowany powyżej, przejdź do katalogu kopii zapasowych.

        cd /opt/apigee/backup/openldap

      • Uruchom polecenie restore. Zdecydowanie zalecamy podanie dokładnej sygnatury czasowej kopii zapasowej z kroku 2, aby zapobiec przywróceniu niechcianej lub starszej wersji.

        # To restore a specific backup (recommended):
        apigee-service apigee-openldap restore 2025.08.11,23.34.00
        
        # To restore the latest available backup by default:
        apigee-service apigee-openldap restore

      • Po pomyślnym zakończeniu procesu przywracania uruchom usługę LDAP na pierwszym aktywnym serwerze.

        apigee-service apigee-openldap start

7. Uruchamianie pozostałych serwerów LDAP

   Jeśli masz konfigurację z wieloma serwerami, na każdym z serwerów LDAP uruchom usługę:

   apigee-service apigee-openldap start

8. Ostateczna weryfikacja

   Ostatnim krokiem jest sprawdzenie, czy uaktualnienie zostało przeprowadzone prawidłowo i czy dane są spójne w całym klastrze LDAP.

   • Uruchom polecenie weryfikacji na wszystkich serwerach LDAP. Liczba rekordów powinna być identyczna na wszystkich serwerach i musi być zgodna z liczbą zarejestrowaną w kroku 2.

   # Note: Replace 'YOUR_PASSWORD' with your 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, uaktualnienie LDAP zostanie zakończone. Możesz teraz uruchomić edge-management-server i edge-ui oraz inne komponenty zależne zgodnie ze standardową procedurą aktualizacji w Twojej organizacji.

Wymagana aktualizacja do wersji Cassandra 4.0.18

Apigee Edge for Private Cloud 4.53.01 zawiera uaktualnienie Cassandry do wersji 4.0.18.

Uaktualnienia i wycofywanie

• Uaktualnienie z Cassandra 3.11.X do Cassandra 4.0.X to prosty proces. Cassandra 4.0.X, wydana z Edge for Private Cloud 4.53.00, jest zgodna z komponentami środowiska wykonawczego i zarządzania Private Cloud 4.52.02.
• Bezpośrednie wycofanie w miejscu z Cassandry 4.0.X do wersji 3.11.X nie jest możliwe. Cofanie zmian za pomocą replik lub kopii zapasowych to złożona procedura, która może wiązać się z przestojem lub utratą danych. Rozwiązywanie problemów i przechodzenie na wyższą wersję Cassandry (4.0.X) jest lepsze niż przywracanie poprzedniej wersji.
• Przed rozpoczęciem uaktualniania zapoznaj się z procedurami wycofywania. Uwzględnienie niuansów wycofywania zmian podczas uaktualniania ma kluczowe znaczenie dla zapewnienia dostępności odpowiednich ścieżek wycofywania.

Pojedyncze centrum danych

Uaktualnienie bazy danych Cassandra z wersji 3.11.X do 4.0.X w ramach jednego centrum danych jest bezproblemowe, ale wycofanie zmian jest złożone i może spowodować przestój oraz utratę danych. W przypadku obciążeń produkcyjnych zdecydowanie zalecamy dodanie nowego centrum danych z co najmniej węzłami Cassandra dostępnymi w nowym centrum danych przed rozpoczęciem uaktualniania. Umożliwi to wycofanie zmian w Cassandrze bez utraty danych i przerwania ruchu API. To dodatkowe centrum danych można wyłączyć po zakończeniu uaktualnienia lub osiągnięciu punktu kontrolnego 2.

Jeśli dodanie nowego centrum danych nie jest możliwe, ale nadal chcesz mieć możliwość wycofania zmian, do przywrócenia Cassandry w wersji 3.11.X konieczne będą kopie zapasowe. Ta metoda wiąże się jednak z przestojem i utratą danych.

Wiele centrów danych

Korzystanie z wielu centrów danych z Edge dla chmury prywatnej w wersji 4.52.02 zapewnia większą elastyczność w przypadku wycofywania zmian podczas uaktualniania do Edge dla chmury prywatnej w wersji 4.53.00.

• Wycofywanie zmian zależy od tego, czy co najmniej 1 centrum danych działa w starszej wersji Cassandry (3.11.X).
• Jeśli cały klaster Cassandra zostanie uaktualniony do wersji 4.0.X, nie można przywrócić wersji 3.11.X. Musisz nadal używać nowszej wersji Cassandry z innymi komponentami chmury prywatnej w wersji 4.53.00 lub 4.52.02.

Zalecana metodologia uaktualniania

1. Uaktualniaj po jednym centrum danych Cassandra: zacznij od uaktualniania poszczególnych węzłów Cassandra w jednym centrum danych. Zanim przejdziesz do następnego centrum danych, przeprowadź uaktualnienie wszystkich węzłów Cassandra w jednym centrum danych.
2. Wstrzymaj i sprawdź: po uaktualnieniu jednego centrum danych wstrzymaj proces, aby upewnić się, że klaster chmury prywatnej, a zwłaszcza uaktualnione centrum danych, działa prawidłowo.
3. Pamiętaj: możesz przywrócić poprzednią wersję Cassandry tylko wtedy, gdy masz co najmniej 1 centrum danych, w którym nadal działa starsza wersja.
4. Wymagające szybkiego działania: możesz wstrzymać proces na krótki czas (zalecamy kilka godzin), aby sprawdzić funkcjonalność, ale nie możesz pozostawać w stanie mieszanym w nieskończoność. Dzieje się tak, ponieważ niejednolity klaster Cassandra (z węzłami w różnych wersjach) ma ograniczenia operacyjne.
5. Dokładne testowanie: przed uaktualnieniem następnego centrum danych Apigee zdecydowanie zaleca przeprowadzenie kompleksowych testów wydajności i funkcjonalności. Po uaktualnieniu wszystkich centrów danych nie będzie można przywrócić wcześniejszej wersji.

Cofanie zmian jako proces dwuetapowy

1. Punkt kontrolny 1: stan początkowy, w którym wszystkie komponenty mają wersję 4.52.02. Pełne wycofanie jest możliwe, o ile co najmniej jedno centrum danych Cassandra pozostanie w starszej wersji.
2. Punkt kontrolny 2: po zaktualizowaniu wszystkich węzłów Cassandra we wszystkich centrach danych. Możesz wrócić do tego stanu, ale nie możesz przywrócić punktu kontrolnego 1.

Przykład

Rozważ klaster z 2 centrami danych:

1. Stan początkowy: węzły Cassandra w obu centrach danych mają wersję 3.11.X. Wszystkie pozostałe węzły są w wersji Edge for Private Cloud 4.52.02. Załóżmy, że w każdym centrum danych są 3 węzły Cassandra.
2. Uaktualnij DC-1: uaktualnij po kolei 3 węzły Cassandra w DC-1.
3. Wstrzymaj i sprawdź: wstrzymaj działanie klastra, zwłaszcza DC-1, aby upewnić się, że działa on prawidłowo (sprawdź wydajność i funkcjonalność). Możesz przywrócić stan początkowy, korzystając z węzłów Cassandra w DC-2. Pamiętaj, że ze względu na ograniczenia klastra Cassandra z mieszanymi wersjami wstrzymanie musi być tymczasowe.
4. Uaktualnij DC-2: uaktualnij pozostałe 3 węzły Cassandra w DC-2. Stanie się on nowym punktem przywracania.
5. Uaktualnij inne komponenty: uaktualnij węzły zarządzania, środowiska wykonawczego i analityczne w zwykły sposób we wszystkich centrach danych, po jednym węźle i jednym centrum danych naraz. Jeśli pojawią się problemy, możesz przywrócić stan z kroku 4.

Wymagania wstępne uaktualnienia Cassandra

1. Cały klaster działa i jest w pełni funkcjonalny z Cassandrą w wersji 3.11.16.
2. Strategia kompresji jest ustawiona na LeveledCompactionStrategy (jest to warunek wstępny aktualizacji do wersji 4.52.02).

3. Sprawdź, czy każdy z poniższych kroków został wykonany w ramach wstępnego uaktualnienia Cassandra 3.11 w Edge for Private Cloud w wersji 4.52.02.

   • Polecenie post_upgrade zostało wykonane na każdym węźle Cassandra podczas poprzedniego uaktualnienia.
   • Podczas poprzedniego uaktualnienia w całym klastrze Cassandra zostało wykonane polecenie drop_old_tables.

Jeśli nie masz pewności, czy polecenia post_upgrade i drop_old_tables zostały wykonane w Cassandrze 3.11 podczas korzystania z Edge for Private Cloud 4.52.02, możesz je ponownie uruchomić przed uaktualnieniem do wersji 4.53.01.

Krok 1. Przygotuj się do uaktualnienia

Poniższe czynności są dodatkowe w stosunku do standardowych plików, które zwykle tworzysz, np. standardowego pliku konfiguracyjnego Apigee umożliwiającego uaktualnianie komponentów.

1. Tworzenie kopii zapasowej Cassandra za pomocą Apigee.
2. Zrób migawki maszyn wirtualnych węzłów Cassandra (jeśli to możliwe).
3. Sprawdź, czy port 9042 jest dostępny ze wszystkich komponentów Edge for Private Cloud, w tym serwera zarządzania, procesora wiadomości, routera, Qpid i Postgres, do węzłów Cassandra, jeśli nie jest jeszcze skonfigurowany. Więcej informacji znajdziesz w sekcji Wymagania dotyczące portów.

Krok 2. Uaktualnij wszystkie węzły Cassandra

Wszystkie węzły Cassandra należy aktualizować pojedynczo w każdym centrum danych, po jednym centrum danych naraz. Między uaktualnieniami węzłów w centrum danych odczekaj kilka minut, aby mieć pewność, że zaktualizowany węzeł został w pełni uruchomiony i dołączył do klastra, zanim przejdziesz do uaktualniania kolejnego węzła w tym samym centrum danych.

Po uaktualnieniu wszystkich węzłów Cassandra w centrum danych odczekaj trochę czasu (od 30 minut do kilku godzin), zanim przejdziesz do węzłów w następnym centrum danych. W tym czasie dokładnie sprawdź zaktualizowane centrum danych i upewnij się, że wskaźniki funkcjonalne i wydajnościowe klastra Apigee są nienaruszone. Ten krok jest kluczowy, aby zapewnić stabilność centrum danych, w którym Cassandra została uaktualniona do wersji 4.0.X, a pozostałe komponenty Apigee działają w wersji 4.52.02.

1. Aby uaktualnić węzeł Cassandra, uruchom to polecenie:

   /opt/apigee/apigee-setup/bin/update.sh -c cs -f configFile

2. Po zaktualizowaniu węzła uruchom w nim to polecenie, aby przeprowadzić weryfikację przed kontynuowaniem:

   /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra validate_upgrade -f configFile

3. Powyższe polecenie zwróci wynik podobny do tego:

   Cassandra version is verified - [cqlsh 6.0.0 | Cassandra 4.0.18 | CQL spec 3.4.5 | Native protocol v5] 
   Metadata is verified

4. Uruchom to polecenie post_upgrade na węźle Cassandra:

   /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra post_upgrade

5. Aby odbudować indeksy na węźle Cassandra, uruchom te polecenia narzędzia nodetool:

   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms api_products api_products_organization_name_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms app_credentials app_credentials_api_products_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms app_credentials app_credentials_organization_app_id_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms app_credentials app_credentials_organization_name_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms app_end_user app_end_user_app_id_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms apps apps_app_family_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms apps apps_app_id_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms apps apps_app_type_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms apps apps_name_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms apps apps_organization_name_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms apps apps_parent_id_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms apps apps_parent_status_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms apps apps_status_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms maps maps_organization_name_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_10_access_tokens oauth_10_access_tokens_app_id_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_10_access_tokens oauth_10_access_tokens_consumer_key_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_10_access_tokens oauth_10_access_tokens_organization_name_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_10_access_tokens oauth_10_access_tokens_status_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_10_request_tokens oauth_10_request_tokens_consumer_key_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_10_request_tokens oauth_10_request_tokens_organization_name_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_10_verifiers oauth_10_verifiers_organization_name_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_10_verifiers oauth_10_verifiers_request_token_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_20_access_tokens oauth_20_access_tokens_app_id_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_20_access_tokens oauth_20_access_tokens_client_id_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_20_access_tokens oauth_20_access_tokens_refresh_token_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_20_authorization_codes oauth_20_authorization_codes_client_id_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_20_authorization_codes oauth_20_authorization_codes_organization_name_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index devconnect companies companies_name_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index devconnect companies companies_organization_name_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index devconnect companies companies_status_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index devconnect company_developers company_developers_company_name_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index devconnect company_developers company_developers_developer_email_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index devconnect company_developers company_developers_organization_name_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index devconnect developers developers_email_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index devconnect developers developers_organization_name_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index devconnect developers developers_status_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index cache cache_entries cache_entries_cache_name_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index audit audits audits_operation_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index audit audits audits_requesturi_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index audit audits audits_responsecode_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index audit audits audits_timestamp_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index audit audits audits_user_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis a_name
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis a_org_name
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_a_active_rev
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_a_def_index_template
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_a_def_method_template
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_a_latest_rev
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_a_name
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_a_uuid
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_base_url
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_is_active
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_is_latest
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_name
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_org_name
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_rel_ver
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_rev_num
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 method m_a_name
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 method m_api_uuid
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 method m_ar_uuid
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 method m_base_url
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 method m_name
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 method m_org_name
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 method m_r_name
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 method m_r_uuid
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 method m_res_path
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 method m_rev_num
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 resource r_a_name
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 resource r_api_uuid
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 resource r_ar_uuid
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 resource r_base_url
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 resource r_name
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 resource r_org_name
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 resource r_res_path
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 resource r_rev_num
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 schemas s_api_uuid
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 schemas s_ar_uuid
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 security sa_api_uuid
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 security sa_ar_uuid
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 template t_a_name
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 template t_a_uuid
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 template t_entity
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 template t_name
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 template t_org_name
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 template_auth au_api_uuid
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index dek keys usecase_index

   Jeśli korzystasz z zarabiania, uruchom też te polecenia ponownego tworzenia indeksów związane z przestrzeniami kluczy zarabiania:

   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint limits limits_created_date_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint limits limits_id_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint limits limits_org_id_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint limits limits_updated_date_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint suspended_developer_products suspended_developer_products_created_date_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint suspended_developer_products suspended_developer_products_currency_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint suspended_developer_products suspended_developer_products_dev_id_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint suspended_developer_products suspended_developer_products_id_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint suspended_developer_products suspended_developer_products_limit_id_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint suspended_developer_products suspended_developer_products_org_id_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint suspended_developer_products suspended_developer_products_prod_id_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint suspended_developer_products suspended_developer_products_reason_code_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint suspended_developer_products suspended_developer_products_sub_org_id_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint invitations invitations_company_id_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint invitations invitations_created_at_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint invitations invitations_developer_id_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint invitations invitations_lastmodified_at_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint invitations invitations_org_id_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index taurus triggers triggers_env_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index taurus triggers triggers_job_id_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index taurus triggers triggers_org_id_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index taurus job_details job_details_job_class_name_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index taurus job_details job_details_job_group_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index taurus job_details job_details_job_name_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index taurus org_triggers org_triggers_org_id_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index taurus triggers_suite triggers_suite_group_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index taurus triggers_suite triggers_suite_name_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index taurus triggers_suite triggers_suite_suite_id_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index notification notification_service_item notification_service_item_org_id_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index notification notification_service_item notification_service_item_status_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index notification notification_service_black_list_item notification_service_black_list_item_org_id_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index notification notification_service_black_list_item notification_service_black_list_item_to_email_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index notification notification_email_template_item notification_email_template_item_name_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index notification notification_email_template_item notification_email_template_item_org_id_idx

Krok 3. Uaktualnij wszystkie węzły zarządzania

Uaktualnij wszystkie węzły zarządzania we wszystkich regionach pojedynczo:

/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile

Krok 4. Uaktualnij wszystkie węzły środowiska wykonawczego

Uaktualnij kolejno wszystkie węzły Router i Message Processor we wszystkich regionach:

/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile

Krok 5. Uaktualnij wszystkie pozostałe komponenty Edge for Private Cloud w wersji 4.53.01

Uaktualnij wszystkie pozostałe węzły edge-qpid-server i edge-postgres-server we wszystkich regionach pojedynczo.

Wymagana aktualizacja do Zookeepera w wersji 3.8.4

Ta wersja Edge for Private Cloud zawiera uaktualnienie do Zookeepera 3.8.4. W ramach tej aktualizacji wszystkie dane Zookeepera zostaną przeniesione do Zookeepera 3.8.4.

Przed uaktualnieniem Zookeepera zapoznaj się z przewodnikiem po konserwacji Zookeepera. Większość systemów produkcyjnych Edge korzysta z klastra węzłów Zookeeper rozproszonych w wielu centrach danych. Niektóre z tych węzłów są skonfigurowane jako węzły głosujące, które biorą udział w wyborach lidera ZooKeepera, a pozostałe są skonfigurowane jako węzły obserwujące. Więcej informacji znajdziesz w artykule Informacje o liderach, obserwatorach, głosujących i podążających za liderem. Węzły głosujące wybierają lidera, a następnie same stają się węzłami podrzędnymi.

Podczas procesu aktualizacji może wystąpić chwilowe opóźnienie lub błąd zapisu w Zookeeperze, gdy węzeł główny zostanie zamknięty. Może to mieć wpływ na operacje zarządzania, które zapisują dane w Zookeeperze, takie jak operacja wdrażania serwera proxy, oraz zmiany w infrastrukturze Apigee, takie jak dodawanie lub usuwanie procesora wiadomości itp. Podczas uaktualniania Zookeepera zgodnie z poniższą procedurą nie powinno to mieć wpływu na interfejsy API środowiska wykonawczego Apigee (chyba że te interfejsy API środowiska wykonawczego wywołują interfejsy API zarządzania).

Ogólnie proces uaktualniania polega na utworzeniu kopii zapasowej każdego węzła. Następnie uaktualniamy wszystkie węzły obserwatorów i węzły podążające, a na końcu węzeł lidera.

Tworzenie kopii zapasowej

Utwórz kopię zapasową wszystkich węzłów Zookeepera, aby w razie potrzeby można było przywrócić poprzednią wersję. Pamiętaj, że przywrócenie spowoduje przywrócenie Zookeepera do stanu, w jakim był w momencie tworzenia kopii zapasowej. Uwaga: wszystkie wdrożenia lub zmiany infrastruktury w Apigee od czasu utworzenia kopii zapasowej (których informacje są przechowywane w Zookeeperze) zostaną utracone podczas przywracania.

  /opt/apigee/apigee-service/bin/apigee-service apigee-zookeeper backup

Jeśli używasz maszyn wirtualnych i masz taką możliwość, możesz też tworzyć migawki lub kopie zapasowe maszyn wirtualnych, aby w razie potrzeby przywrócić je lub cofnąć zmiany.

Określanie lidera, obserwatorów i osób obserwujących

Uwaga: w przykładowych poleceniach poniżej użyto narzędzia nc do wysyłania danych do Zookeepera. Możesz też używać innych narzędzi do wysyłania danych do Zookeepera.

1. Jeśli nie jest zainstalowany na węźle ZooKeeper, zainstaluj nc:

     sudo yum install nc

2. Uruchom to polecenie nc na węźle, gdzie 2181 to port ZooKeeper:

     echo stat | nc localhost 2181

   Powinny pojawić się dane wyjściowe podobne do tych:

     Zookeeper version: 3.8.4-5a02a05eddb59aee6ac762f7ea82e92a68eb9c0f, built on 2022-02-25 08:49 UTC
     Clients:
      /0:0:0:0:0:0:0:1:41246[0](queued=0,recved=1,sent=0)
     
     Latency min/avg/max: 0/0.2518/41
     Received: 647228
     Sent: 647339
     Connections: 4
     Outstanding: 0
     Zxid: 0x400018b15
     Mode: follower
     Node count: 100597

   W wierszu Mode w danych wyjściowych węzłów powinna być widoczna wartość observer, leader lub follower (oznaczająca głosującego, który nie jest liderem) w zależności od konfiguracji węzła. Uwaga: w przypadku samodzielnej instalacji Edge z jednym węzłem ZooKeeper wartość Mode jest ustawiona na standalone.

3. Powtórz kroki 1 i 2 na każdym węźle ZooKeeper.

Uaktualnianie Zookeepera na węzłach obserwatora i węzłach podrzędnych

Uaktualnij Zookeepera na każdym z węzłów obserwatora i węzłów podrzędnych w ten sposób:

1. Pobierz i uruchom program bootstrap Edge for Private Cloud 4.53.01 zgodnie z opisem w artykule Aktualizowanie do wersji 4.53.01 na węźle z zewnętrznym połączeniem internetowym. Proces ten będzie się prawdopodobnie różnić w zależności od tego, czy węzeł ma zewnętrzne połączenie z internetem, czy instalacja jest przeprowadzana w trybie offline.
2. Uaktualnij komponent Zookeeper:

     /opt/apigee/apigee-setup/bin/update.sh -c zk -f <silent-config-file>

   Uwaga: jeśli na tych węzłach są zainstalowane inne komponenty (np. Cassandra), możesz je teraz też uaktualnić (np. za pomocą profilu cs,zk) lub zrobić to później. Apigee zaleca, aby najpierw uaktualnić Zookeepera i upewnić się, że klaster działa prawidłowo, zanim uaktualnisz inne komponenty.
3. Powtórz powyższe kroki na każdym węźle obserwatora i węźle podrzędnym Zookeepera.

Wyłączanie lidera

Po uaktualnieniu wszystkich węzłów obserwujących i śledzących wyłącz węzeł główny. Na węźle oznaczonym jako lider uruchom to polecenie:

  /opt/apigee/apigee-service/bin/apigee-service apigee-zookeeper stop

Pamiętaj, że podczas tego zdarzenia, zanim zostanie wybrany nowy lider, mogą wystąpić chwilowe opóźnienia lub błędy zapisu w Zookeeperze. Może to mieć wpływ na operacje, które zapisują dane w Zookeeperze, takie jak wdrażanie serwerów proxy lub zmiany w infrastrukturze Apigee, np. dodawanie lub usuwanie procesorów wiadomości itp.

Sprawdź, czy nowy lider został wybrany.

Wykonaj czynności opisane w sekcji Identyfikowanie lidera, obserwatorów i obserwujących powyżej, aby sprawdzić, czy po zatrzymaniu dotychczasowego lidera został wybrany nowy lider spośród obserwujących. Pamiętaj, że lider mógł zostać wybrany w innym centrum danych niż obecny lider.

Uaktualnij najlepszy wariant

Wykonaj czynności opisane w sekcji Uaktualnianie Zookeepera na węzłach obserwatora i węzłach podrzędnych powyżej.

Gdy stary węzeł lidera zostanie uaktualniony, sprawdź stan klastra i upewnij się, że jest w nim węzeł lidera.

Uaktualnienie Nginx 1.26 w routerze brzegowym

Uaktualnienie Edge dla chmury prywatnej do wersji 4.53.01 z poprzednich wersji nie powoduje automatycznego uaktualnienia oprogramowania Nginx do najnowszej wersji (1.26.x). Ma to zapobiec przypadkowym efektom ubocznym w czasie działania programu, które mogą być spowodowane zmianami opisanymi w artykule Zmiany w Nginx 1.26 w Apigee Edge 4.53.01. Po weryfikacji w środowiskach o niższym poziomie możesz ręcznie uaktualnić Nginx z wersji 1.20.x do 1.26.x. Aby przeprowadzić uaktualnienie ręcznie:

1. Sprawdź, czy węzeł routera brzegowego ma najnowszą wersję oprogramowania 4.53.01.

   /opt/apigee/apigee-service/bin/apigee-service edge-router version

2. Sprawdzanie i weryfikowanie aktualnie używanej wersji Nginx

   /opt/nginx/sbin/nginx -V

   Jeśli używasz starszej wersji Nginx, możesz wykonać te czynności, aby zaktualizować Nginx do wersji 1.26.X na węźle routera.

3. Zatrzymywanie procesu routera brzegowego w węźle routera

   /opt/apigee/apigee-service/bin/apigee-service edge-router stop

4. Uaktualnianie oprogramowania nginx w węźle routera

   dnf update apigee-nginx

5. Sprawdź, czy wersja Nginx została zaktualizowana.

   /opt/nginx/sbin/nginx -V

6. Uruchamianie procesu routera na węźle

   /opt/apigee/apigee-service/bin/apigee-service edge-router start

7. Powtórz ten proces na każdym węźle routera, po kolei.

Wymagane uaktualnienie do Postgres 17

Ta wersja Edge zawiera uaktualnienie do Postgresa 17. W ramach tej aktualizacji wszystkie dane Postgres zostaną przeniesione do Postgres 17.

Większość systemów produkcyjnych Edge korzysta z 2 węzłów Postgres skonfigurowanych pod kątem replikacji typu master-standby. Podczas procesu aktualizacji, gdy węzły Postgres są wyłączone na czas aktualizacji, dane analityczne są nadal zapisywane w węzłach Qpid. Po zaktualizowaniu węzłów Postgres i przywróceniu ich do trybu online dane analityczne są przesyłane do tych węzłów.

Sposób przeprowadzenia aktualizacji Postgresa zależy od tego, jak skonfigurowano przechowywanie danych na węzłach Postgresa:

• Jeśli używasz lokalnego przechowywania danych na potrzeby węzłów Postgres, musisz zainstalować nowy węzeł rezerwowy Postgres na czas uaktualnienia. Po zakończeniu uaktualniania możesz wycofać nowy węzeł rezerwowy Postgres.

  Dodatkowy węzeł rezerwowy Postgres jest wymagany, jeśli z jakiegokolwiek powodu musisz wycofać aktualizację. Jeśli musisz wycofać aktualizację, nowy węzeł rezerwowy Postgres stanie się po wycofaniu węzłem głównym Postgres. Dlatego podczas instalowania nowego węzła rezerwowego Postgres powinien on znajdować się na węźle, który spełnia wszystkie wymagania sprzętowe serwera Postgres, zgodnie z definicją w sekcji Wymagania dotyczące instalacji w Edge.

  W konfiguracji Edge z 1 lub 2 węzłami, czyli w topologiach używanych do prototypowania i testowania, masz tylko 1 węzeł Postgres. Możesz bezpośrednio aktualizować te węzły Postgres bez konieczności tworzenia nowego węzła Postgres.

• Jeśli używasz pamięci sieciowej dla węzłów Postgres, zgodnie z zaleceniami Apigee, nie musisz instalować nowego węzła Postgres. W procedurach poniżej możesz pominąć kroki, które dotyczą instalowania i późniejszego wycofywania nowego węzła rezerwowego Postgres.

  Przed rozpoczęciem procesu aktualizacji wykonaj migawkę sieciową magazynu danych używanego przez Postgres. Jeśli podczas aktualizacji wystąpią błędy i konieczne będzie wycofanie zmian, możesz przywrócić węzeł Postgres z tej migawki.

Instalowanie nowego węzła rezerwowego Postgres

Ta procedura tworzy serwer rezerwowy Postgres na nowym węźle. Zainstaluj nowy serwer zapasowy Postgres dla istniejącej wersji Edge (4.52.02 lub 4.53.00), a nie dla wersji 4.53.01.

Aby przeprowadzić instalację, użyj tego samego pliku konfiguracji, którego użyto do zainstalowania bieżącej wersji Edge.

Aby utworzyć nowy węzeł rezerwowy Postgres:

1. Na bieżącym serwerze głównym Postgresa zmień plik /opt/apigee/customer/application/postgresql.properties, aby ustawić ten token: Jeśli ten plik nie istnieje, utwórz go:

   conf_pg_hba_replication.connection=host replication apigee existing_standby_ip/32 trust\ \nhost replication apigee new_standby_ip/32 trust

   gdzie existing_standby_ip to adres IP bieżącego serwera rezerwowego Postgres, a new_standby_ip to adres IP nowego węzła rezerwowego.

2. Uruchom ponownie apigee-postgresql na masterze Postgresa:

   /opt/apigee/apigee-service/bin/apigee-service apigee-postgresql restart

3. Sprawdź, czy nowy węzeł rezerwowy został dodany, wyświetlając plik /opt/apigee/apigee-postgresql/conf/pg_hba.conf na węźle głównym. W tym pliku powinny się znajdować te wiersze:

   host replication apigee existing_standby_ip/32 trust
   host replication apigee new_standby_ip/32 trust

4. Zainstaluj nowy serwer rezerwowy Postgres:
   1. Edytuj plik konfiguracyjny, którego użyto do zainstalowania bieżącej wersji Edge, aby określić następujące elementy:

      # IP address of the current master:
      PG_MASTER=192.168.56.103
      # IP address of the new standby node
      PG_STANDBY=192.168.56.102

   2. Wyłącz SELinux zgodnie z opisem w artykule Instalowanie narzędzia Edge apigee-setup.

   3. Jeśli korzystasz obecnie z Edge w wersji 4.52.02:

      1. Pobierz plik Edge bootstrap_4.52.02.sh do /tmp/bootstrap_4.52.02.sh :

         curl https://software.apigee.com/bootstrap_4.52.02.sh -o /tmp/bootstrap_4.51.00.sh

      2. Zainstaluj narzędzie Edge apigee-service i zależności:

         sudo bash /tmp/bootstrap_4.52.02.sh apigeeuser=uName apigeepassword=pWord

      Jeśli korzystasz obecnie z Edge w wersji 4.53.00:

      1. Pobierz plik Edge bootstrap_4.53.00.sh do:/tmp/bootstrap_4.53.00.sh

         curl https://software.apigee.com/bootstrap_4.53.00.sh -o /tmp/bootstrap_4.53.00.sh

      2. Zainstaluj narzędzie Edge apigee-service i zależności:

         sudo bash /tmp/bootstrap_4.53.00.sh apigeeuser=uName apigeepassword=pWord

   4. Użyj apigee-service, aby zainstalować narzędzie apigee-setup:

      /opt/apigee/apigee-service/bin/apigee-service apigee-setup install

   5. Zainstaluj Postgres:

      /opt/apigee/apigee-setup/bin/setup.sh -p ps -f configFile

   6. Na nowym węźle rezerwowym uruchom to polecenie:

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

      Sprawdź, czy jest w trybie gotowości.

Przeprowadzanie aktualizacji Postgres w miejscu

Krok wstępny

Zanim przeprowadzisz uaktualnienie Postgres w miejscu, wykonaj te czynności na hoście głównym i zapasowym, 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

Przeprowadź uaktualnienie w miejscu

Aby przeprowadzić aktualizację w miejscu do Postgresa 17, wykonaj te czynności:

1. Uaktualnianie bazy danych PostgreSQL na hoście master

   /opt/apigee/apigee-setup/bin/update.sh -c ps -f /opt/silent.conf

2. Uruchom polecenie konfiguracji na hoście master:

   apigee-service apigee-postgresql setup -f /opt/silent.conf

3. Uruchom polecenie konfiguracji na hoście master:

   apigee-service apigee-postgresql configure

4. Uruchom ponownie hosta głównego:

   apigee-service apigee-postgresql restart

5. Skonfiguruj go jako mastera:

   apigee-service apigee-postgresql setup-replication-on-master -f /opt/silent.conf

6. Sprawdź, czy host główny został uruchomiony:

   apigee-service apigee-postgresql wait_for_ready

7. Zatrzymaj tryb gotowości:

   apigee-service apigee-postgresql stop

8. Uaktualnij tryb czuwania.

   Uwaga: jeśli ten krok zakończy się błędem lub nie powiedzie, można go zignorować. update.sh spróbuje uruchomić serwer rezerwowy z nieprawidłową konfiguracją. Jeśli instalacja Postgres została uaktualniona do wersji 17, można zignorować ten błąd.

   /opt/apigee/apigee-setup/bin/update.sh -c ps -f /opt/silent.conf

9. Sprawdź, czy tryb gotowości został zatrzymany:

   apigee-service apigee-postgresql stop

10. Usuń starą konfigurację gotowości:

    rm -rf /opt/apigee/data/apigee-postgresql/

11. Skonfiguruj replikację na serwerze rezerwowym:

    apigee-service apigee-postgresql setup-replication-on-standby -f /opt/silent.conf

12. Usuń wiersz conf/postgresql.conf+max_locks_per_transaction=30000 z pliku /opt/apigee/customer/application/postgresql.properties zarówno na hoście głównym, jak i na hoście rezerwowym. Ten wiersz został dodany w kroku wstępnym.

Po zakończeniu tej procedury tryb gotowości zostanie uruchomiony.

Wyłączanie węzła Postgres

Po zakończeniu aktualizacji wycofaj nowy węzeł rezerwowy:

1. Sprawdź, czy serwer Postgres 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. Pobierz identyfikator UUID nowego węzła rezerwowego, uruchamiając to polecenie curl na nowym węźle rezerwowym:

   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"

3. Zatrzymaj nowy węzeł rezerwowy, uruchamiając to polecenie na nowym węźle rezerwowym:

   /opt/apigee/apigee-service/bin/apigee-all stop

4. Na węźle głównym Postgresa zmień /opt/apigee/customer/application/postgresql.properties, aby usunąć nowy węzeł rezerwowy z conf_pg_hba_replication.connection:

   conf_pg_hba_replication.connection=host replication apigee existing_standby_ip/32 trust

5. Uruchom ponownie apigee-postgresql na masterze Postgres:

   /opt/apigee/apigee-service/bin/apigee-service apigee-postgresql restart

6. Sprawdź, czy nowy węzeł rezerwowy został usunięty, wyświetlając plik /opt/apigee/apigee-postgresql/conf/pg_hba.conf na węźle głównym. W tym pliku powinna być tylko ta linia:

   host replication apigee existing_standby_ip/32 trust

7. Usuń identyfikator UUID węzła rezerwowego z ZooKeepera, wykonując to wywołanie interfejsu API zarządzania Edge na węźle serwera zarządzania:

   curl -u sysAdminEmail:password -X DELETE http://ms_IP:8080/v1/servers/new_standby_uuid

Czynności do wykonania po uaktualnieniu Postgres

Po dużej aktualizacji Postgresa wewnętrzne statystyki Postgresa są usuwane. Te statystyki pomagają planerowi zapytań Postgres w wykorzystaniu optymalnych indeksów i ścieżek do wykonywania zapytań.

PostgreSQL może stopniowo odbudowywać statystyki w miarę wykonywania zapytań i działania demona autovacuum. Jednak do czasu ponownego utworzenia statystyk zapytania mogą być wykonywane wolniej.

Aby rozwiązać ten problem, wykonaj polecenie ANALYZE na wszystkich tabelach w bazie danych na głównym węźle Postgres. Możesz też uruchomić polecenie ANALYZE w przypadku kilku tabel naraz.

Kroki aktualizacji logowania jednokrotnego Apigee ze starszych wersji

W Edge for Private Cloud w wersji 4.53.01 klucze i certyfikaty dostawcy tożsamości używane w komponencie apigee-sso są teraz konfigurowane za pomocą magazynu kluczy. Musisz wyeksportować używany wcześniej klucz i certyfikat do magazynu kluczy, skonfigurować go, a następnie przeprowadzić aktualizację logowania jednokrotnego w zwykły sposób.

1. Określ istniejący klucz i certyfikat używane do konfigurowania dostawcy tożsamości:

   1. Pobierz certyfikat, wyszukując wartość SSO_SAML_SERVICE_PROVIDER_CERTIFICATE w pliku konfiguracji instalacji logowania jednokrotnego lub wysyłając zapytanie do komponentu apigee-sso o conf_login_service_provider_certificate.

      Użyj tego polecenia na węźle logowania jednokrotnego, aby wysłać zapytanie do apigee-sso o ścieżkę certyfikatu dostawcy tożsamości. W danych wyjściowych poszukaj wartości w ostatnim wierszu.

      apigee-service apigee-sso configure -search conf_login_service_provider_certificate

   2. Pobierz klucz, wyszukując wartość SSO_SAML_SERVICE_PROVIDER_KEY w pliku konfiguracji instalacji SSO lub wysyłając zapytanie do komponentu apigee-sso o wartość conf_login_service_provider_key.

      Aby wysłać zapytanie do apigee-sso o ścieżkę klucza dostawcy tożsamości, użyj tego polecenia w węźle logowania jednokrotnego. W danych wyjściowych poszukaj wartości w ostatnim wierszu.

      apigee-service apigee-sso configure -search conf_login_service_provider_key

2. Wyeksportuj klucz i certyfikat do magazynu kluczy:
   1. Wyeksportuj klucz i certyfikat do magazynu kluczy PKCS12:

      sudo openssl pkcs12 -export -clcerts -in <certificate_path> -inkey <key_path> -out <keystore_path> -name <alias>

      Parametry:

      • certificate_path: ścieżka do pliku certyfikatu pobranego w kroku 1a.
      • key_path: Ścieżka do pliku klucza prywatnego pobranego w kroku 1b.
      • keystore_path: Ścieżka do nowo utworzonego magazynu kluczy zawierającego certyfikat i klucz prywatny.
      • alias: alias używany w przypadku pary kluczy i certyfikatów w magazynie kluczy.

      Więcej informacji znajdziesz w dokumentacji OpenSSL.

   2. (Opcjonalnie) Wyeksportuj klucz i certyfikat z PKCS12 do magazynu kluczy JKS:

      sudo keytool -importkeystore -srckeystore <PKCS12_keystore_path> -srcstoretype PKCS12 -destkeystore <destination_keystore_path> -deststoretype JKS -alias <alias>

      Parametry:

      • PKCS12_keystore_path: ścieżka do magazynu kluczy PKCS12 utworzonego w kroku 2a, zawierającego certyfikat i klucz.
      • destination_keystore_path: Ścieżka do nowego magazynu kluczy JKS, do którego zostaną wyeksportowane certyfikat i klucz.
      • alias: alias używany w przypadku pary kluczy i certyfikatów w magazynie kluczy JKS.

   Więcej informacji znajdziesz w dokumentacji narzędzia keytool.

3. Zmień właściciela wyjściowego pliku magazynu kluczy na użytkownika „apigee”:

   sudo chown apigee:apigee <keystore_file>

4. Dodaj te właściwości w pliku konfiguracji logowania jednokrotnego Apigee i zaktualizuj je, podając ścieżkę do pliku magazynu kluczy, hasło, typ magazynu kluczy i alias:

   # Path to the keystore file
   SSO_SAML_SERVICE_PROVIDER_KEYSTORE_PATH=${APIGEE_ROOT}/apigee-sso/source/conf/keystore.jks
   
   # Keystore password
   SSO_SAML_SERVICE_PROVIDER_KEYSTORE_PASSWORD=Secret123  # Password for accessing the keystore
   
   # Keystore type
   SSO_SAML_SERVICE_PROVIDER_KEYSTORE_TYPE=JKS  # Type of keystore, e.g., JKS, PKCS12
   
   # Alias within keystore that stores the key and certificate
   SSO_SAML_SERVICE_PROVIDER_KEYSTORE_ALIAS=service-provider-cert 

5. Zaktualizuj oprogramowanie Apigee SSO na węźle SSO w zwykły sposób, używając tego polecenia:

   /opt/apigee/apigee-setup/bin/update.sh -c sso -f /opt/silent.conf

Nowy interfejs Edge

W tej sekcji znajdziesz informacje dotyczące interfejsu Edge. Więcej informacji znajdziesz w artykule Nowy interfejs Edge dla chmury prywatnej.

Instalowanie interfejsu Edge

Po zakończeniu wstępnej instalacji zalecamy zainstalowanie interfejsu Edge, który jest ulepszonym interfejsem użytkownika dla deweloperów i administratorów Apigee Edge for Private Cloud.

Pamiętaj, że interfejs Edge wymaga wyłączenia uwierzytelniania podstawowego i używania IDP, takiego jak SAML lub LDAP.

Więcej informacji znajdziesz w artykule Instalowanie nowego interfejsu Edge.

Aktualizacja za pomocą mTLS Apigee

Aby zaktualizować Apigee mTLS , wykonaj te czynności:

• Odinstalowywanie Apigee mTLS
• Ponownie zainstaluj Apigee mTLS.

Cofanie aktualizacji

Jeśli aktualizacja się nie powiedzie, możesz spróbować rozwiązać problem, a następnie ponownie wykonać polecenie update.sh. Aktualizację możesz uruchamiać wielokrotnie. Będzie ona kontynuowana od miejsca, w którym została ostatnio przerwana.

Jeśli niepowodzenie wymaga przywrócenia poprzedniej wersji aktualizacji, szczegółowe instrukcje znajdziesz w sekcji Przywracanie wersji 4.53.01.

Informacje o aktualizacji logowania

Domyślnie narzędzie update.sh zapisuje informacje w dzienniku w tych miejscach:

/opt/apigee/var/log/apigee-setup/update.log

Jeśli osoba uruchamiająca narzędzie update.sh nie ma dostępu do tego katalogu, zapisuje dziennik w katalogu /tmp jako plik o nazwie update_username.log.

Jeśli dana osoba nie ma dostępu do elementu /tmp, narzędzie update.sh nie będzie działać.

Aktualizacja bez przestojów

Aktualizacja bez przestojów, czyli aktualizacja krocząca, umożliwia zaktualizowanie instalacji Edge bez wyłączania Edge.

Aktualizacja bez przestoju jest możliwa tylko w przypadku konfiguracji z 5 węzłami lub większej.

Kluczem do uaktualniania bez przestojów jest usuwanie poszczególnych routerów z systemu równoważenia obciążenia pojedynczo. Następnie zaktualizuj router i wszystkie inne komponenty na tym samym komputerze co router, a potem dodaj router z powrotem do systemu równoważenia obciążenia.

1. Zaktualizuj maszyny w odpowiedniej kolejności dla Twojej instalacji, zgodnie z opisem w sekcji Kolejność aktualizacji maszyn.
2. Gdy nadejdzie czas aktualizacji routerów, wybierz dowolny router i spraw, aby był niedostępny, zgodnie z opisem w sekcji Włączanie i wyłączanie dostępności serwera (procesora wiadomości lub routera).
3. Zaktualizuj wybrany router i wszystkie inne komponenty Edge na tym samym komputerze co router. Wszystkie konfiguracje Edge pokazują router i procesor wiadomości na tym samym węźle.
4. Spraw, aby router był ponownie dostępny.
5. Powtórz kroki od 2 do 4 w przypadku pozostałych routerów.
6. Kontynuuj aktualizację na pozostałych maszynach w instalacji.

Przed aktualizacją i po niej wykonaj te czynności:

• Na połączonym węźle routera i procesora wiadomości:
  • Przed aktualizacją wykonaj te czynności:
    1. Spraw, aby router był niedostępny.
    2. Spraw, aby procesor wiadomości był niedostępny.
  • Po aktualizacji wykonaj te czynności:
    1. Umożliwienie dostępu do procesora wiadomości.
    2. Spraw, aby router był osiągalny.
• W przypadku pojedynczych węzłów routera:
  • Przed aktualizacją spraw, aby router był niedostępny.
  • Po aktualizacji spraw, aby router był dostępny.
• Na pojedynczych węzłach procesora wiadomości:
  • Przed aktualizacją spraw, aby procesor wiadomości był niedostępny.
  • Po aktualizacji spraw, aby procesor wiadomości był dostępny.

Używanie pliku konfiguracji w trybie cichym

Do polecenia aktualizacji musisz przekazać plik konfiguracji cichej. Plik konfiguracji cichej instalacji powinien być taki sam jak ten, którego użyto do zainstalowania Edge for Private Cloud w wersji 4.52.02 lub 4.53.00.

Aktualizacja do wersji 4.53.01 na węźle z zewnętrznym połączeniem internetowym

Aby zaktualizować komponenty Edge na węźle:

1. Jeśli istnieją, wyłącz wszystkie zadania cron skonfigurowane do wykonywania operacji naprawy w Cassandrze, dopóki aktualizacja nie zostanie ukończona.
2. Zaloguj się w węźle jako root, aby zainstalować pakiety RPM Edge.
3. Wyłącz SELinux zgodnie z opisem w artykule Instalowanie narzędzia Edge apigee-setup.
4. Jeśli instalujesz na AWS, wykonaj te yum-configure-managerpolecenia:

   yum update rh-amazon-rhui-client.noarch
   sudo yum-config-manager --enable rhui-REGION-rhel-server-extras rhui-REGION-rhel-server-optional

5. Jeśli korzystasz obecnie z wersji Edge 4.52.02 lub 4.53.00:

   1. Pobierz plik Edge bootstrap_4.53.01.sh do /tmp/bootstrap_4.53.01.sh:

      curl https://software.apigee.com/bootstrap_4.53.01.sh -o /tmp/bootstrap_4.53.01.sh

   2. Zainstaluj narzędzie apigee-service Edge 4.53.01 i zależności, wykonując to polecenie:

      sudo bash /tmp/bootstrap_4.53.01.sh apigeeuser=uName apigeepassword=pWord

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

      Domyślnie instalator sprawdza, czy masz zainstalowaną Javę 1.8. Jeśli nie, instalator zainstaluje go za Ciebie.

      Użyj opcji JAVA_FIX, aby określić sposób obsługi instalacji Javy. JAVA_FIX przyjmuje te wartości:

      • I: zainstaluj OpenJDK 1.8 (domyślnie);
      • C: kontynuuj bez instalowania Javy.
      • Q: Zrezygnuj. W przypadku tej opcji musisz samodzielnie zainstalować Javę.
   3. Użyj narzędzia apigee-service, aby zaktualizować narzędzie apigee-setup, jak pokazano w tym przykładzie:

      /opt/apigee/apigee-service/bin/apigee-service apigee-setup update

   4. Zaktualizuj narzędzie apigee-validate na serwerze zarządzającym, jak pokazano w tym przykładzie:

      /opt/apigee/apigee-service/bin/apigee-service apigee-validate update

   5. Zaktualizuj narzędzie apigee-provision na serwerze zarządzającym, jak pokazano w tym przykładzie:

      /opt/apigee/apigee-service/bin/apigee-service apigee-provision update

   6. Uruchom narzędzie update na węzłach, wykonując to polecenie:

      /opt/apigee/apigee-setup/bin/update.sh -c component -f configFile

      Wykonaj te czynności w kolejności opisanej w sekcji Kolejność aktualizacji maszyn.

      Gdzie:

      • component to komponent Edge, który ma zostać zaktualizowany. Możliwe wartości:
        • cs: Cassandra
        • edge: wszystkie komponenty Edge z wyjątkiem interfejsu Edge: serwer zarządzania, procesor wiadomości, router, serwer QPID, serwer Postgres
        • ldap: OpenLDAP
        • ps: postgresql
        • qpid: qpidd
        • sso: Apigee SSO (jeśli masz zainstalowane logowanie jednokrotne)
        • ue: nowy interfejs Edge
        • ui: klasyczny interfejs Edge
        • zk: Zookeeper
      • configFile to ten sam plik konfiguracji, którego użyto do zdefiniowania komponentów Edge podczas instalacji w wersji 4.52.02 lub 4.53.00.

      Możesz uruchomić update.sh na wszystkich komponentach, ustawiając component na „all”, ale tylko wtedy, gdy masz profil instalacji Edge all-in-one (AIO). Na przykład:

      /opt/apigee/apigee-setup/bin/update.sh -c all -f ./sa_silent_config

   7. Jeśli jeszcze tego nie zrobiono, ponownie uruchom komponenty interfejsu Edge na wszystkich węzłach, na których działają:

      /opt/apigee/apigee-service/bin/apigee-service [edge-management-ui|edge-ui] restart

   8. Przetestuj aktualizację, uruchamiając narzędzie apigee-validate na serwerze zarządzającym zgodnie z opisem w sekcji Testowanie instalacji.

Jeśli później zdecydujesz się wycofać aktualizację, wykonaj procedurę opisaną w sekcji Wycofywanie wersji 4.53.01.

Aktualizacja do wersji 4.53.01 z lokalnego repozytorium

Jeśli węzły brzegowe znajdują się za zaporą lub w inny sposób nie mają dostępu do repozytorium Apigee przez internet, możesz przeprowadzić aktualizację z lokalnego repozytorium lub kopii repozytorium Apigee.

Po utworzeniu lokalnego repozytorium Edge możesz zaktualizować Edge z lokalnego repozytorium na 2 sposoby:

• Utwórz plik .tar repozytorium, skopiuj go na węzeł, a następnie zaktualizuj Edge z pliku .tar.
• Zainstaluj serwer WWW na węźle z lokalnym repozytorium, aby inne węzły mogły uzyskać do niego dostęp. Apigee udostępnia serwer WWW Nginx, ale możesz też używać własnego serwera WWW.

Aby zaktualizować z lokalnego repozytorium w wersji 4.53.01:

1. Utwórz lokalne repozytorium 4.53.01 zgodnie z opisem w sekcji „Tworzenie lokalnego repozytorium Apigee” w artykule Instalowanie narzędzia apigee-setup Edge.
2. Aby zainstalować apigee-service z pliku .tar:
   1. Na węźle z lokalnym repozytorium użyj tego polecenia, aby spakować lokalne repozytorium w jeden plik .tar o nazwie /opt/apigee/data/apigee-mirror/apigee-4.53.01.tar.gz:

      /opt/apigee/apigee-service/bin/apigee-service apigee-mirror package

   2. Skopiuj plik .tar do węzła, w którym chcesz zaktualizować Edge. Możesz na przykład skopiować go do katalogu /tmp na nowym węźle.
   3. Na nowym węźle rozpakuj plik do katalogu /tmp:

      tar -xzf apigee-4.53.01.tar.gz

      To polecenie tworzy nowy katalog o nazwie repos w katalogu zawierającym plik .tar. Na przykład /tmp/repos.

   4. Zainstaluj narzędzie Edge apigee-service i zależności z /tmp/repos:

      sudo bash /tmp/repos/bootstrap_4.53.01.sh apigeeprotocol="file://" apigeerepobasepath=/tmp/repos

      Zwróć uwagę, że w tym poleceniu podajesz ścieżkę do katalogu repozytoriów.

3. Aby zainstalować apigee-service za pomocą serwera WWW Nginx:
   1. Skonfiguruj serwer WWW Nginx zgodnie z opisem w sekcji „Instalowanie z repozytorium za pomocą serwera WWW Nginx” w artykule Instalowanie narzędzia apigee-setup Edge.
   2. Na węźle zdalnym pobierz plik Edge bootstrap_4.53.01.sh do /tmp/bootstrap_4.53.01.sh:

      /usr/bin/curl http://uName:pWord@remoteRepo:3939/bootstrap_4.53.01.sh -o /tmp/bootstrap_4.53.01.sh

      gdzie uName:pWord to nazwa użytkownika i hasło ustawione wcześniej dla repozytorium, a remoteRepo to adres IP lub nazwa DNS węzła repozytorium.

   3. Na węźle zdalnym zainstaluj narzędzie Edge apigee-setup i zależności:

      sudo bash /tmp/bootstrap_4.53.01.sh apigeerepohost=remoteRepo:3939 apigeeuser=uName apigeepassword=pWord apigeeprotocol=http://

      gdzie uName:pWord to nazwa użytkownika i hasło repozytorium.

4. Użyj narzędzia apigee-service, aby zaktualizować narzędzie apigee-setup, jak pokazano w tym przykładzie:

   /opt/apigee/apigee-service/bin/apigee-service apigee-setup update 

5. Zaktualizuj narzędzie apigee-validate na serwerze zarządzającym, jak pokazano w tym przykładzie:

   /opt/apigee/apigee-service/bin/apigee-service apigee-validate update

6. Zaktualizuj narzędzie apigee-provision na serwerze zarządzającym, jak pokazano w tym przykładzie:

   /opt/apigee/apigee-service/bin/apigee-service apigee-provision update

7. Uruchom narzędzie update na węzłach w kolejności opisanej w sekcji Kolejność aktualizacji maszyn:

   /opt/apigee/apigee-setup/bin/update.sh -c component -f configFile

   Gdzie:

   • component to komponent Edge, który ma zostać zaktualizowany. Zwykle aktualizujesz te komponenty:
     • cs: Cassandra
     • edge: wszystkie komponenty Edge z wyjątkiem interfejsu Edge: serwer zarządzania, procesor wiadomości, router, serwer QPID, serwer Postgres
     • ldap: OpenLDAP
     • ps: postgresql
     • qpid: qpidd
     • sso: Apigee SSO (jeśli masz zainstalowane logowanie jednokrotne)
     • ue Nowy interfejs Edge
     • ui: klasyczny interfejs Edge
     • zk: Zookeeper
   • configFile to ten sam plik konfiguracji, którego użyto do zdefiniowania komponentów Edge podczas instalacji w wersji 4.52.02 lub 4.53.00.

   Możesz uruchomić update.sh na wszystkich komponentach, ustawiając component na „all”, ale tylko wtedy, gdy masz profil instalacji Edge all-in-one (AIO). Na przykład:

   /opt/apigee/apigee-setup/bin/update.sh -c all -f /tmp/sa_silent_config

8. Jeśli jeszcze tego nie zrobiono, uruchom ponownie komponenty interfejsu na wszystkich węzłach, na których są one uruchomione:

   /opt/apigee/apigee-service/bin/apigee-service [edge-management-ui|edge-ui] restart

9. Przetestuj aktualizację, uruchamiając narzędzie apigee-validate na serwerze zarządzającym zgodnie z opisem w sekcji Testowanie instalacji.

Jeśli później zdecydujesz się wycofać aktualizację, wykonaj procedurę opisaną w sekcji Wycofywanie wersji 4.53.01.

Kolejność aktualizacji maszyny

Kolejność aktualizowania maszyn w instalacji Edge jest ważna:

• Przed zaktualizowaniem innych komponentów musisz zaktualizować wszystkie węzły LDAP. Aby zaktualizować LDAP, musisz wykonać specjalne czynności.
• Musisz zaktualizować wszystkie węzły Cassandra i ZooKeeper. Jeśli przechodzisz na wyższą wersję z 4.52.02, wykonaj specjalne czynności, aby zaktualizować bazę danych Cassandra. W przypadku wersji 4.52.02 lub 4.53.00 musisz wykonać specjalne czynności, aby uaktualnić Zookeepera.
• Aby zaktualizować wszystkie serwery zarządzania oraz procesory routera i wiadomości, musisz użyć opcji -c edge.
• Wszystkie węzły Postgres musisz uaktualnić, wykonując specjalne czynności opisane w sekcji Uaktualnianie Postgres.
• Musisz zaktualizować komponenty edge-qpid-server i edge-postgres-server we wszystkich centrach danych.
• Musisz uaktualnić wszystkie węzły Qpid.
• Musisz uaktualnić węzły interfejsu Edge, a także węzły nowego interfejsu Edge i logowania jednokrotnego(jeśli dotyczy).
• Nie ma osobnego kroku aktualizacji zarabiania. Jest on aktualizowany po określeniu opcji krawędzi –c.

Samodzielna licencja na 1 węzeł

Aby uaktualnić konfigurację 1-węzłową do wersji 4.53.01:

1. Zaktualizuj wszystkie komponenty:

   /opt/apigee/apigee-setup/bin/update.sh -c all -f configFile

2. (Jeśli zainstalowano apigee-adminapi) zaktualizuj narzędzie apigee-adminapi:

   /opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update

Samodzielna licencja na 2 węzły

Zaktualizuj te komponenty w przypadku 2-węzłowej instalacji autonomicznej:

Listę topologii Edge i liczbę węzłów znajdziesz w sekcji Topologie instalacji.

1. Zaktualizuj LDAP na maszynie 1:

   /opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile

2. Zaktualizuj systemy Cassandra i ZooKeeper na maszynie 1:

   /opt/apigee/apigee-setup/bin/update.sh -c cs,zk -f configFile

3. Zaktualizuj komponenty Edge na maszynie 1:

   /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile

4. Zaktualizuj Postgres na maszynie 2:

   /opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile

5. Zaktualizuj komponenty Edge na maszynie 1:

   /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile

6. Zaktualizuj Qpid na maszynie 2:

   /opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile

7. Zaktualizuj interfejs na maszynie 1:

   /opt/apigee/apigee-setup/bin/update.sh -c ui -f configFile

8. (Jeśli zainstalowano apigee-adminapi) Zaktualizuj narzędzie apigee-adminapi na komputerze 1:

   /opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update

9. (Jeśli masz zainstalowane Apigee SSO) Zaktualizuj Apigee SSO na komputerze 1:

   /opt/apigee/apigee-setup/bin/update.sh -c sso -f sso_config_file

   gdzie sso_config_file to plik konfiguracji utworzony podczas instalacji logowania jednokrotnego.

10. Uruchom ponownie komponent interfejsu Edge na komputerze 1:

    /opt/apigee/apigee-service/bin/apigee-service edge-ui restart

Uaktualnienie 5 węzłów

Zaktualizuj te komponenty w przypadku instalacji 5-węzłowej:

Listę topologii Edge i liczbę węzłów znajdziesz w sekcji Topologie instalacji.

1. Zaktualizuj LDAP na maszynie 1:

   /opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile

2. Zaktualizuj systemy Cassandra i ZooKeeper na maszynach 1, 2 i 3:

   /opt/apigee/apigee-setup/bin/update.sh -c cs,zk -f configFile

3. Zaktualizuj komponenty Edge na maszynach 1, 2 i 3:

   /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile

4. Zaktualizuj Postgres na maszynie 4:

   /opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile

5. Aktualizacja Postgres na maszynie 5:

   /opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile

6. Zaktualizuj komponenty Edge na maszynach 4 i 5:

   /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile

7. Zaktualizuj Qpid na maszynie 4:

   /opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile

8. Aktualizacja Qpid na maszynie 5:

   /opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile

9. Zaktualizuj interfejs Edge:
   • Klasyczny interfejs: jeśli używasz klasycznego interfejsu, zaktualizuj komponent ui na komputerze 1, jak pokazano w tym przykładzie:

     /opt/apigee/apigee-setup/bin/update.sh -c ui -f configFile

   • Nowy interfejs Edge: jeśli masz zainstalowany nowy interfejs Edge, zaktualizuj komponent ue na odpowiednim urządzeniu (może to nie być urządzenie 1):

     /opt/apigee/apigee-setup/bin/update.sh -c ue -f /opt/silent.conf

10. (Jeśli zainstalowano apigee-adminapi) Zaktualizuj narzędzie apigee-adminapi na komputerze 1:

    /opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update

11. (Jeśli masz zainstalowane Apigee SSO) Zaktualizuj Apigee SSO na komputerze 1:

    /opt/apigee/apigee-setup/bin/update.sh -c sso -f sso_config_file

    gdzie sso_config_file to plik konfiguracji utworzony podczas instalacji logowania jednokrotnego.

12. Uruchom ponownie komponent interfejsu:
    • Klasyczny interfejs: jeśli korzystasz z klasycznego interfejsu, uruchom ponownie komponent edge-ui na komputerze 1, jak pokazano w tym przykładzie:

      /opt/apigee/apigee-service/bin/apigee-service edge-ui restart

    • Nowy interfejs Edge: jeśli masz zainstalowany nowy interfejs Edge, uruchom ponownie komponent edge-management-ui na odpowiednim komputerze (może to nie być komputer 1):

      /opt/apigee/apigee-service/bin/apigee-service edge-management-ui restart

Uaktualnianie klastra 9-węzłowego

Zaktualizuj te komponenty w przypadku instalacji klastrowej z 9 węzłami:

Listę topologii Edge i liczbę węzłów znajdziesz w sekcji Topologie instalacji.

1. Zaktualizuj LDAP na maszynie 1:

   /opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile

2. Zaktualizuj systemy Cassandra i ZooKeeper na maszynach 1, 2 i 3:

   /opt/apigee/apigee-setup/bin/update.sh -c cs,zk -f configFile

3. Zaktualizuj komponenty Edge na maszynach 1, 4 i 5 (serwer zarządzania, procesor wiadomości, router) w tej kolejności:

   /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile

4. Aktualizacja Postgresa na maszynie 8:

   /opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile

5. Zaktualizuj Postgres na maszynie 9:

   /opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile

6. Zaktualizuj komponenty Edge na maszynach 6, 7, 8 i 9 w tej kolejności:

   /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile

7. Zaktualizuj Qpid na maszynach 6 i 7:

   /opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile

8. Zaktualizuj nowy interfejs (ue) lub klasyczny interfejs (ui) na komputerze 1:

   /opt/apigee/apigee-setup/bin/update.sh -c [ui|ue] -f configFile

9. (Jeśli zainstalowano apigee-adminapi) Zaktualizuj narzędzie apigee-adminapi na komputerze 1:

   /opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update

10. (Jeśli masz zainstalowane Apigee SSO) Zaktualizuj Apigee SSO na komputerze 1:

    /opt/apigee/apigee-setup/bin/update.sh -c sso -f sso_config_file

    gdzie sso_config_file to plik konfiguracji utworzony podczas instalacji logowania jednokrotnego.

11. Uruchom ponownie komponent interfejsu:
    • Klasyczny interfejs: jeśli korzystasz z klasycznego interfejsu, uruchom ponownie komponent edge-ui na komputerze 1, jak pokazano w tym przykładzie:

      /opt/apigee/apigee-service/bin/apigee-service edge-ui restart

    • Nowy interfejs Edge: jeśli masz zainstalowany nowy interfejs Edge, uruchom ponownie komponent edge-management-ui na odpowiednim komputerze (może to nie być komputer 1):

      /opt/apigee/apigee-service/bin/apigee-service edge-management-ui restart

Uaktualnienie klastra składającego się z 13 węzłów

Zaktualizuj te komponenty w przypadku instalacji klastrowej z 13 węzłami:

Listę topologii Edge i liczbę węzłów znajdziesz w sekcji Topologie instalacji.

1. Zaktualizuj LDAP na maszynach 4 i 5:

   /opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile

2. Zaktualizuj systemy Cassandra i ZooKeeper na maszynach 1, 2 i 3:

   /opt/apigee/apigee-setup/bin/update.sh -c cs,zk -f configFile

3. Zaktualizuj komponenty Edge na maszynach 6, 7, 10 i 11 w tej kolejności:

   /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile

4. Aktualizacja Postgresa na maszynie 8:

   /opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile

5. Zaktualizuj Postgres na maszynie 9:

   /opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile

6. Zaktualizuj komponenty Edge na maszynach 12, 13, 8 i 9 w tej kolejności:

   /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile

7. Zaktualizuj Qpid na maszynach 12 i 13:

   /opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile

8. Zaktualizuj nowy interfejs (ue) lub klasyczny interfejs (ui) na maszynach 6 i 7:

   /opt/apigee/apigee-setup/bin/update.sh -c [ui|ue] -f configFile

9. (Jeśli zainstalowano apigee-adminapi) Zaktualizowano narzędzie apigee-adminapi na komputerach 6 i 7:

   /opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update

10. (Jeśli masz zainstalowane Apigee SSO) Zaktualizuj Apigee SSO na maszynach 6 i 7:

    /opt/apigee/apigee-setup/bin/update.sh -c sso -f sso_config_file

    gdzie sso_config_file to plik konfiguracji utworzony podczas instalacji logowania jednokrotnego.

11. Uruchom ponownie komponent interfejsu:
    • Klasyczny interfejs: jeśli używasz klasycznego interfejsu, uruchom ponownie komponent edge-ui na maszynach 6 i 7, jak pokazano w tym przykładzie:

      /opt/apigee/apigee-service/bin/apigee-service edge-ui restart

    • Nowy interfejs Edge: jeśli masz zainstalowany nowy interfejs Edge, uruchom ponownie komponent edge-management-ui na maszynach 6 i 7:

      /opt/apigee/apigee-service/bin/apigee-service edge-management-ui restart

Uaktualnianie klastra składającego się z 12 węzłów

Zaktualizuj te komponenty w przypadku instalacji klastrowej z 12 węzłami:

Listę topologii Edge i liczbę węzłów znajdziesz w sekcji Topologie instalacji.

1. Aktualizowanie LDAP:
   1. Maszyna 1 w centrum danych 1

      /opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile

   2. Komputer 7 w centrum danych 2

      /opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile

2. Zaktualizuj Cassandra i ZooKeeper:
   1. Maszyny 1, 2 i 3 w centrum danych 1:

      /opt/apigee/apigee-setup/bin/update.sh -c cs,zk -f configFile

   2. Na maszynach 7, 8 i 9 w centrum danych 2:

      /opt/apigee/apigee-setup/bin/update.sh -c cs,zk -f configFile

3. Aktualizowanie komponentów Edge:
   1. Na maszynach 1, 2 i 3 w centrum danych 1:

      /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile

   2. Na maszynach 7, 8 i 9 w centrum danych 2

      /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile

4. Zaktualizuj Postgres:
   1. Maszyna 6 w centrum danych 1

      /opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile

   2. Urządzenie 12 w centrum danych 2

      /opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile

5. Aktualizowanie komponentów Edge:
   1. Maszyny 4, 5, 6 w centrum danych 1

      /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile

   2. Maszyny 10, 11, 12 w centrum danych 2

      /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile

6. Update qpidd:
   1. Maszyny 4 i 5 w centrum danych 1
      1. Zaktualizuj qpidd na maszynie 4:

         /opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile

      2. Zaktualizuj qpidd na maszynie 5:

         /opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile

   2. Maszyny 10 i 11 w centrum danych 2
      1. Zaktualizuj qpidd na maszynie 10:

         /opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile

      2. Zaktualizuj qpidd na maszynie 11:

         /opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile

7. Zaktualizuj nowy interfejs (ue) lub klasyczny interfejs (ui):
   1. Maszyna 1 w centrum danych 1:

      /opt/apigee/apigee-setup/bin/update.sh -c [ui|ue] -f configFile

   2. Komputer 7 w centrum danych 2:

      /opt/apigee/apigee-setup/bin/update.sh -c [ui|ue] -f configFile

8. (Jeśli zainstalowano narzędzie apigee-adminapi) Zaktualizowano narzędzie apigee-adminapi:
   1. Maszyna 1 w centrum danych 1:

      /opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update

   2. Komputer 7 w centrum danych 2:

      /opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update

9. (Jeśli masz zainstalowane Apigee SSO) zaktualizuj Apigee SSO:
   1. Maszyna 1 w centrum danych 1:

      /opt/apigee/apigee-setup/bin/update.sh -c sso -f sso_config_file

   2. Komputer 7 w centrum danych 2:

      /opt/apigee/apigee-setup/bin/update.sh -c sso -f sso_config_file

   gdzie sso_config_file to plik konfiguracji utworzony podczas instalacji logowania jednokrotnego.

10. Uruchom ponownie nowy interfejs Edge (edge-management-ui) lub klasyczny interfejs Edge (edge-ui) na komputerach 1 i 7:

    /opt/apigee/apigee-service/bin/apigee-service [edge-ui|edge-management-ui] restart

W przypadku konfiguracji niestandardowej

Jeśli masz niestandardową konfigurację, zaktualizuj komponenty Edge w tej kolejności:

1. LDAP
2. Cassandra
3. Opiekun zwierząt
4. Serwer zarządzania
5. procesor komunikatów
6. Router
7. Postgres
8. Edge, czyli profil „-c edge” na wszystkich węzłach w kolejności: węzły z serwerem Qpid, serwer Edge Postgres.
9. qpidd
10. Interfejs Edge (klasyczny lub nowy)
11. apigee-adminapi
12. Logowanie jednokrotne Apigee

Po zakończeniu aktualizacji uruchom ponownie komponent interfejsu Edge na wszystkich komputerach, na których jest on zainstalowany.