Ta strona została przetłumaczona przez Cloud Translation API.

Zmiany w Edge for Private Cloud w wersji 4.53.01

Omówienie zmian

Wersja 4.53.01 Edge for Private Cloud wprowadza wiele zmian, które zwiększają bezpieczeństwo platformy i zawierają zaktualizowane wersje wymaganego oprogramowania i bibliotek. Zmiany te dotyczą tych typów zasad:

Zasady weryfikacji OAS (specyfikacji OpenAPI)
Zasady obsługujące zapytania JSONPath
Zasady wywołań Java, które korzystają z wycofanych bibliotek.
OpenLDAP
Zmiany dostawcy kryptografii

Możesz też użyć narzędzia do wykrywania zmian, aby zidentyfikować zmiany w serwerach proxy, przepływach współdzielonych lub innych artefaktach w klastrze, które mogą spowodować zakłócenia w wyniku tej aktualizacji.

Szczegółowy opis zmian

W tej sekcji opisujemy zmiany wprowadzone w wersji 4.53.01, które mogą zakłócić Twoje przepływy pracy w trakcie uaktualniania lub po nim. Omówiono również metody identyfikowania potencjalnych obszarów problemowych oraz sposoby łagodzenia skutków problemów lub ich obejścia.

Zasady weryfikacji OAS (specyfikacji OpenAPI)

Kontekst

Zasady weryfikacji OAS weryfikują żądania lub odpowiedzi przychodzące pod kątem reguł zdefiniowanych w specyfikacji OpenAPI 3.0 (JSON lub YAML). W wersji Edge for Private Cloud 4.53.01 wprowadziliśmy ulepszenia zasad OAS (OpenAPI Specification), które koncentrują się na bardziej rygorystycznej i dokładniejszej weryfikacji treści odpowiedzi interfejsu API.

Zmiany

W wersji 4.53.01 Edge for Private Cloud wprowadziliśmy 2 ważne zmiany w sposobie, w jaki zasady OAS weryfikują odpowiedzi interfejsu API. Zapewniają one lepsze dopasowanie do specyfikacji OpenAPI:

Scenariusz 1:
- Wcześniejsze działanie: jeśli specyfikacja OpenAPI wymagała treści odpowiedzi, ale rzeczywista odpowiedź z zasad docelowych lub nadrzędnych nie zawierała treści, zasady nie zgłaszały tego jako błędu weryfikacji.
- Obecne działanie: w tej sytuacji zasady będą teraz prawidłowo zwracać błąd weryfikacji (np. defines a response schema but no response body found), co oznacza niezgodność między oczekiwaną a rzeczywistą odpowiedzią.
Scenariusz 2:
- Wcześniejsze działanie: jeśli specyfikacja OpenAPI wyraźnie wskazywała, że nie oczekiwano treści odpowiedzi, ale rzeczywista odpowiedź z zasad docelowych lub nadrzędnych zawierała treść, zasady nie powodowały błędu.
- Obecne działanie: w tym scenariuszu zasady spowodują błąd (np. No response body is expected but one was found), co zapewni, że odpowiedzi będą ściśle zgodne z określonym schematem.

Łagodzenie

Za pomocą narzędzia do wykrywania zmian lub ręcznie sprawdź, które serwery proxy lub przepływy współdzielone mogą zostać objęte uaktualnieniem. Wyszukaj wszystkie serwery proxy, w przypadku których występuje jeden z tych warunków:

Zasady weryfikacji OAS są skonfigurowane z tagiem Source ustawionym na response.
Zasada weryfikacji OAS sprawdza odpowiedź z innej zasady, która generuje odpowiedź.

Jeśli używasz tego narzędzia, wygeneruje ono dane wyjściowe w tym formacie:

Organizacja	Środowisko	Nazwa artefaktu	Typ artefaktu	Wersja	Nazwa zasady	Typ zasady	Rodzaj wpływu	Pole dotyczące wpływu	Pewność wpływu	Dokumentacja
org2	dla programistów	proxy2	proxy	4	oas-validateresponse	OASValidation	oas_content_type_handling	Source=calloutresponse	Średni	Zasady weryfikacji OAS
org1	produkcyjne	proxy3	sharedflow	1	oas-spec-validation	OASValidation	oas_content_type_handling	Source=response	Średni	Zasady weryfikacji OAS

Szczegółowe wyjaśnienie kolumn w tabeli wyjściowej znajdziesz w sekcji Interpretowanie wyników narzędzia.

Gdy zidentyfikujesz serwer proxy lub wspólny przepływ, upewnij się, że odpowiedź i specyfikacja OAS są zgodne pod względem obecności lub braku treści odpowiedzi. Aby sprawdzić wzorce ruchu, możesz użyć standardowego śledzenia Apigee. Jeśli usługa docelowa zwraca odpowiedź z przerwami, użyj innych zasad, aby zweryfikować odpowiedź, zanim zostanie ona przekazana do zasady weryfikacji OAS.

Jeśli plik specyfikacji OAS definiuje treść odpowiedzi, odpowiedź z zasad docelowych lub nadrzędnych musi zawsze ją zawierać.
Jeśli plik specyfikacji OAS nie definiuje treści odpowiedzi, zasady docelowe lub nadrzędne nie mogą jej wysyłać.

Przed próbą przejścia na Private Cloud 4.53.01 zaktualizuj w razie potrzeby zasady weryfikacji OAS lub docelowe zachowanie. Aby zminimalizować ryzyko przerw w działaniu podczas uaktualniania klastra produkcyjnego, najpierw zweryfikuj zidentyfikowane przepływy pracy w środowiskach nieprodukcyjnych.

Ścieżka JSON

Kontekst

W wersji Edge for Private Cloud 4.53.01 wprowadzono zmiany w sposobie używania wyrażeń ścieżki JSON w różnych zasadach. Wyrażenia JSONPath można stosować w zasadach takich jak zasady ExtractVariable, zasady RegularExpressionProtection czy maskowanie danych, aby analizować zawartość JSON lub przechowywać wartości w zmiennych. Wyrażenia JSONPath można też stosować w ogólnym szablonie wiadomości, aby dynamicznie zastępować zmienne wartościami podczas wykonywania serwera proxy. Nowe wyrażenia i formaty JSONPath są zgodne z najnowszymi standardami wyrażeń JSON.

Zmiany

Sprawdź istniejące proxy interfejsu API lub współdzielone przepływy pod kątem zasad, które wykorzystują wyrażenia JSONPath. Dotyczy to m.in. zasad Extract Variables, Regular Expression Protection i wszelkich zasad z szablonem wiadomości korzystającym z JSONPath.

Poniższy plik JSON służy do wyjaśnienia zmian:

{
  "store": {
    "book": [
      {"category": "reference", "author": "Nigel Rees", "price": 8.95},
      {"category": "fiction", "author": "Evelyn Waugh", "price": 12.99},
      {"category": "fiction", "author": "Herman Melville", "price": 8.99}
    ],
    "bicycle": {
      "color": "red",
      "book": [
        {"author": "Abc"}
      ]
    }
  }
}

Zmiana działania symbolu wieloznacznego [*] w JSONPath w przypadku wartości obiektów
Zmieniliśmy działanie symbolu wieloznacznego [*], gdy jest on używany do uzyskiwania dostępu do wszystkich bezpośrednich wartości obiektu JSON. Wcześniej funkcja $.object[*] zwracała wartości bezpośrednie zawarte w jednym obiekcie JSON. W zaktualizowanych bibliotekach dane wyjściowe to teraz tablica zawierająca te wartości.

Na przykład: $.store[*].
Poprzednie działanie:
```
{
  "bicycle": {
    "color": "red",
    "book": [{"author": "Abc"}]
  },
  "book": [
    {"price": 8.95, "category": "reference", "author": "Nigel Rees"},
    {"price": 12.99, "category": "fiction", "author": "Evelyn Waugh"},
    {"price": 8.99, "category": "fiction", "author": "Herman Melville"}
  ]
}
```
Obecne działanie:
```
[
  [
    {"category": "reference", "author": "Nigel Rees", "price": 8.95},
    {"category": "fiction", "author": "Evelyn Waugh", "price": 12.99},
    {"category": "fiction", "author": "Herman Melville", "price": 8.99}
  ],
  {
    "color": "red",
    "book": [{"author": "Abc"}]
  }
]
```
Działanie:
Zmień wyrażenie JSONPath, aby kierować na obiekt nadrzędny (np. $.store), i w ten sposób bezpośrednio kierować na wcześniej pobrane elementy.
Kropka na końcu ścieżki (.) w JSONPath powoduje błąd
Wyrażenia JSONPath podlegają bardziej rygorystycznej weryfikacji. Wcześniej ścieżki kończące się nieprawidłową kropką na końcu (np. $.path.to.element.) były cicho ignorowane, a zapytanie nadal zwracało wynik, jeśli pasował poprzedni prawidłowy segment ścieżki. W nowej wersji takie nieprawidłowe ścieżki są prawidłowo identyfikowane jako nieprawidłowe i powodują błąd.

Na przykład: $.store.book.
Poprzednie działanie:
```
[
  {"price":8.95,"category":"reference","author":"Nigel Rees"},
  {"price":12.99,"category":"fiction","author":"Evelyn Waugh"},
  {"price":8.99,"category":"fiction","author":"Herman Melville"}
]
```
Obecne działanie:
```
ERROR: com.jayway.jsonpath.InvalidPathException - Path must not end with a '.' or '..'
```
Wszystkie dotychczasowe zasady, które używają wyrażeń JSONPath z niezamierzoną kropką na końcu, będą teraz zwracać błąd InvalidPathException.
Działanie:
Usuń kropkę z końca każdego wyrażenia JSONPath, które się nią kończy. Na przykład zmień $.store.book. na $.store.book.
Zmiana struktury danych wyjściowych (..) rekurencyjnego przeszukiwania JSONPath
W przypadku użycia operatora (..) (rekurencyjne przeszukiwanie) do znajdowania wszystkich wystąpień nazwanego elementu wyniki są zwracane w inny sposób. Wcześniej wszystkie znalezione elementy były spłaszczane do jednej listy. Zaktualizowane biblioteki zwracają teraz listę list, zachowując oryginalną strukturę grup, w których znaleziono elementy, zamiast jednej płaskiej listy.

Na przykład: $..book
Poprzednie działanie:
```
[
  {"price":8.95,"category":"reference","author":"Nigel Rees"},
  {"price":12.99,"category":"fiction","author":"Evelyn Waugh"},
  {"price":8.99,"category":"fiction","author":"Herman Melville"},
  {"author":"Abc"}
]
```
Obecne działanie:
```
[
  [
    {"category":"reference","author":"Nigel Rees","price":8.95},
    {"category":"fiction","author":"Evelyn Waugh","price":12.99},
    {"category":"fiction","author":"Herman Melville","price":8.99}
  ],
  [
    {"author":"Abc"}
  ]
]
```
Działanie:
Zaktualizuj logikę przetwarzania podrzędnego, aby uwzględnić nową strukturę zagnieżdżonej tablicy. Prawdopodobnie musisz przejść przez zewnętrzną tablicę JSONArray, a potem przez każdą wewnętrzną tablicę JSONArray, aby uzyskać dostęp do poszczególnych elementów.
Indeksowanie JSONPath po wybraniu wielu elementów lub zastosowaniu filtra zwraca pustą tablicę
Zmiana w działaniu występuje, gdy indeks (np. [0]) jest stosowany bezpośrednio po selektorze wielu elementów (np. [*]) lub filtrze ([?(condition)]). Wcześniej takie wyrażenia próbowały wybrać element o określonym indeksie z połączonych wyników. W nowej wersji te wyrażenia będą zwracać pustą tablicę ([]).

Na przykład: $.store.book[*][0]
Poprzednie działanie:
```
{"category": "reference", "price": 8.95, "author": "Nigel Rees"}
```
Obecne działanie:
```
[]
```
Działanie:
Jeśli musisz odfiltrować, a następnie pobrać konkretny element z odfiltrowanego zbioru, przetwórz odfiltrowaną tablicę zwróconą przez JSONPath, np. $..book[?(@.category == 'fiction')], a następnie pobierz [0] z poprzedniego wyniku.
Zmiana danych wyjściowych ujemnego wycinania tablicy JSONPath
W nowej wersji zmodyfikowano działanie wycinania tablicy z użyciem indeksów ujemnych (np. [-2:], [-1:]). Wcześniej podczas stosowania ujemnego wycinka do tablicy (wskazującego elementy od końca tablicy) stara wersja nieprawidłowo zwracała tylko jeden element z tego wycinka. Nowa wersja prawidłowo zwraca listę (tablicę) zawierającą wszystkie elementy, które mieszczą się w określonym zakresie ujemnym.

Na przykład $.store.book[-2:]
Poprzednie działanie:
```
{"price":12.99,"category":"fiction","author":"Evelyn Waugh"}
```
Obecne działanie:
```
[
  {"category":"fiction","author":"Evelyn Waugh","price":12.99},
  {"category":"fiction","author":"Herman Melville","price":8.99}
]
```
Działanie:
Logika przetwarzania podrzędnego musi zostać zaktualizowana, aby iterować po zwróconej tablicy JSON i uzyskać żądane dane wyjściowe.
JSONPath stricter preceding dot
Wymagania dotyczące składni elementów, do których uzyskuje się dostęp bezpośrednio z katalogu głównego, są bardziej rygorystyczne. Gdy do elementów uzyskuje się dostęp bezpośrednio z katalogu głównego bez poprzedzającej kropki (np. $propertyelement), taka składnia jest teraz traktowana jako błąd i uniemożliwia wdrożenie serwera proxy.

Na przykład $store.
```
{
  "bicycle": {
    "color": "red",
    "book": [{"author": "Abc"}]
  },
  "book": [
    {"price": 8.95, "category": "reference", "author": "Nigel Rees"},
    {"price": 12.99, "category": "fiction", "author": "Evelyn Waugh"},
    {"price": 8.99, "category": "fiction", "author": "Herman Melville"}
  ]
}
```
Obecne działanie:
Proxy will fail to deploy.
Działanie:

Zmień JSONPath, aby zawierał kropkę: $.propertyName (np. $.store). Dzięki temu prawidłowo określisz i pobierzesz wartość.
Dynamiczne wyrażenia JSONPath
Zwróć szczególną uwagę na zasady, w których wyrażenie JSONPath jest podawane przez zmienną (np. {myJsonPathVariable} lub {dynamicPath}). Wartość tych zmiennych również musi być sprawdzana pod kątem potencjalnych zmian w zachowaniu opisanych powyżej.

Łagodzenie

Zidentyfikuj wszystkie proxy lub współdzielone przepływy, na które może mieć wpływ uaktualnienie, korzystając z narzędzia do wykrywania zmian lub ręcznie sprawdzając proxy interfejsu API pod kątem opisanych wzorców. Jeśli użyjesz tego narzędzia, w wyniku zobaczysz informacje o serwerze proxy lub wspólnym przepływie, na który ma wpływ problem, odpowiednie zasady i problematyczne ścieżki JSON, jak pokazano w przykładzie poniżej:

Organizacja	Środowisko	Nazwa artefaktu	Typ artefaktu	Wersja	Nazwa zasady	Typ zasady	Rodzaj wpływu	Pole dotyczące wpływu	Pewność wpływu	Dokumentacja
org1	dla programistów	proxy1	proxy	4	EV-ExtractRequestParams	ExtractVariables	Zmiana działania symbolu wieloznacznego [*] w JSONPath w przypadku wartości obiektów	$.store[*]	Wysoki	Zmiana działania symbolu wieloznacznego [*] w JSONPath w przypadku wartości obiektów
org2	produkcyjne	proxy2	sharedflow	1	EV-ExtractResponseParams	ExtractVariables	Kropka na końcu ścieżki JSONPath powoduje teraz błąd	$.store.book.	Wysoki	Kropka na końcu ścieżki JSONPath powoduje błąd
org3	dla programistów	proxy3	proxy	3	SC-FetchUserProfile	ServiceCallout	Zmiana struktury danych wyjściowych rekurencyjnego przeszukiwania JSONPath (..)	$..book	Wysoki	Zmiana struktury danych wyjściowych rekurencyjnego przeszukiwania JSONPath (..)
org4	produkcyjne	proxy4	sharedflow	2	RF-InvalidAuthToken	RaiseFault	Indeksowanie JSONPath po wybraniu wielu elementów lub filtrowaniu zwraca teraz pustą tablicę	$.store.book[*][0]	Wysoki	Indeksowanie JSONPath po wybraniu wielu elementów lub zastosowaniu filtra zwraca pustą tablicę
org5	test	proxy5	proxy	6	SC-FetchProfileDetails	ServiceCallout	Zmiana danych wyjściowych w przypadku ujemnego wycinania tablicy JSONPath	$.store.book[-2:]	Wysoki	Zmiana danych wyjściowych ujemnego wycinania tablicy JSONPath
org6	produkcyjne	proxy6	proxy	2	ML-LogRequestDetails	MessageLogging	JSONPath Stricter Preceding Dot	$store	Wysoki	JSONPath stricter preceding dot
org7	test	proxy7	proxy	5	RF-InvalidTokenDetails	RaiseFault	Dynamiczne wyrażenia JSONPath	myJsonPathVariable	Średni	Dynamiczne wyrażenia JSONPath

Szczegółowe wyjaśnienie kolumn w tabeli wyników powyżej znajdziesz w sekcji Interpretowanie wyników narzędzia.

Aby temu zapobiec, konieczna jest kompleksowa strategia. Ten proces obejmuje wybór odpowiedniej ścieżki aktualizacji i zastosowanie niezbędnej poprawki do wykrytych wyrażeń JSONPath.

Wybierz metodę ścieżki uaktualnienia, która najbardziej Ci odpowiada:

Migracja bez przestojów
Ta strategia polega na pozyskaniu co najmniej jednego nowego środowiska, do którego można podłączyć oddzielne węzły procesora wiadomości. Węzły procesora wiadomości można skonfigurować tak, aby instalowały wersję 4.53.01 i miały serwery proxy z nowoczesnymi wyrażeniami JSONPath. Można ich używać podczas uaktualniania, a po jego zakończeniu można je wycofać. Ta strategia jest bezproblemowa, ale wymaga tymczasowego pozyskania dodatkowych węzłów procesora wiadomości, aby zapewnić płynne przejście na nową wersję. Szczegóły poniżej:
- Utwórz nowe środowisko i dodaj do niego nowe węzły procesora wiadomości w wersji 4.53.01.
- Prześlij pakiet proxy dla proxy, których dotyczy problem, do nowego środowiska i zastosuj niezbędne poprawki opisane w sekcji dotyczącej rozwiązania oraz wdróż zaktualizowany pakiet proxy w nowym środowisku.
- Przekieruj ruch do nowego środowiska i wycofaj wdrożenie odpowiednich serwerów proxy ze starego środowiska.
- Uaktualnij węzły oryginalnego procesora wiadomości do wersji 4.53.01. Wdróż w środowisku pierwotnym proxy, które zawierają poprawki dotyczące JSONPath.
- Przekieruj ruch z powrotem do starego środowiska, w którym procesory wiadomości działają w wersji 4.53.01, a serwer proxy jest zmodernizowany pod kątem nowych wyrażeń jsonpath.
- Usuń i wycofaj nowe środowisko oraz powiązane z nim węzły.
Przerwa i przejście na wyższą wersję
Ta strategia polega na wywoływaniu przestojów w przypadku serwerów proxy interfejsu API za pomocą nieprawidłowych wyrażeń JSONPath. Nie wymaga to zakupu dodatkowych węzłów procesora wiadomości, ale powoduje zakłócenia w ruchu interfejsu API w przypadku proxy, których dotyczy problem.
- Zidentyfikuj serwery proxy, których dotyczy problem, wraz z zasadami, których naruszają, i wygeneruj nową wersję dla wszystkich serwerów proxy, których dotyczy problem.
- Wprowadź niezbędne poprawki, wdrażając poprawki opisane w sekcji dotyczącej rozwiązywania problemów w nowej wersji proxy. Nie wdrażaj jeszcze tej wersji.
- Zaplanuj przerwę w działaniu serwera proxy lub serwerów proxy, które mają wpływ na działanie usługi.
- Uaktualnij wszystkie procesory wiadomości do wersji Edge dla chmury prywatnej 4.53.01. Pamiętaj, że istniejące serwery proxy mogą nie działać na nowo uaktualnionych procesorach wiadomości.
- Gdy wszystkie procesory wiadomości zostaną zaktualizowane do wersji 4.53.01 Edge dla chmury prywatnej , wdróż nowo utworzoną wersję serwera proxy z poprawionym wyrażeniem JSONPath.
- wznowić ruch na takich serwerach proxy.
Przeprojektuj proxy przed uaktualnieniem
Przed uaktualnieniem do wersji Edge for Private Cloud 4.53.01 możesz przeprojektować sam serwer proxy. Zamiast korzystać z konkretnych wyrażeń ścieżki JSON, możesz uzyskać ten sam wynik, używając innej metody.

Jeśli na przykład używasz zasady Extract Variable Policy ze ścieżką JSON, możesz zastąpić ją zasadą Javascript, która wyodrębnia podobne dane, zanim przejdziesz na nowszą wersję. Po zakończeniu przekształcania możesz przywrócić w serwerze proxy ścieżki JSON w nowszych formatach.

Zmiany w zasadzie JavaCallout

Kontekst

W wersjach Edge for Private Cloud 4.53.00 i starszych znajdował się katalog o nazwie deprecated ($APIGEE_ROOT/edge-message-processor/lib/deprecated), który zawierał wiele bibliotek JAR. Te biblioteki były dostępne do użycia w kodzie Java w zasadach JavaCallout i mogły być używane przez Twój niestandardowy kod Java bezpośrednio lub pośrednio.

Zmiany

Katalog deprecated został usunięty w Edge w chmurze prywatnej w wersji 4.53.01. Jeśli Twój kod Java korzysta z takich bibliotek, serwery proxy używające takich wywołań Java przestaną działać po uaktualnieniu procesorów wiadomości do wersji 4.53.01. Aby uniknąć takich awarii, przed uaktualnieniem procesorów wiadomości do wersji 4.53.01 wykonaj poniższe czynności.

Łagodzenie

Sprawdź zasady wywołania Java i powiązane z nimi pliki JAR za pomocą narzędzia do wykrywania zmian lub ręcznie. Sprawdź, czy któreś z zasad odwołują się do bibliotek znajdujących się w katalogu „deprecated” obecnych procesorów wiadomości.

Jeśli do wykrywania powyższych problemów używasz narzędzia udostępnionego przez Apigee, wygeneruje ono raport podobny do tego w tabeli poniżej . Dotyczy to w szczególności zasad, które odwołują się do plików JAR znajdujących się w katalogu $APIGEE_ROOT/edge-message-processor/lib/deprecated starszych wersji Edge for Private Cloud.

Narzędzie wygeneruje raporty w tym formacie:

Organizacja	Środowisko	Nazwa artefaktu	Typ artefaktu	Wersja	Nazwa zasady	Typ zasady	Rodzaj wpływu	Pole dotyczące wpływu	Pewność wpływu	Dokumentacja
org1	Brak	Brak	org-level-jar	Brak	Brak	java-callout	wykryto wycofaną bibliotekę w przypadku `simple-javacallout-o1-jar-1.jar`	['Wykryto użycie klasy `org.apache.commons.io.FileUtils` z `commons-io-2.5.jar`, 'Wykryto użycie klasy `org.apache.commons.io.input.XmlStreamReaderException` z `commons-io-2.5.jar`']	Wysoki	Zmiany w JavaCallout
org3	env3	Brak	env-level-jar	Brak	Brak	java-callout	wykryto wycofaną bibliotekę w przypadku `fat-javacallout-e3-jar-1.jar`	['Wykryto użycie klasy `org.apache.http.impl.auth.NTLMSchemeFactory` z `httpclient-4.5.2.jar`']	Wysoki	Zmiany w JavaCallout
org1	env1	p1	proxy-level-jar	1	Brak	java-callout	wykryto wycofaną bibliotekę w przypadku `simple-javacallout-p1-jar-1.jar`	['Wykryto użycie klasy `org.apache.commons.lang3.builder.ToStringBuilder` z `commons-lang3-3.4.jar`', 'Wykryto użycie klasy `org.apache.commons.lang3.Validate` z `commons-lang3-3.4.jar`']	Wysoki	Zmiany w JavaCallout

Szczegółowe wyjaśnienie kolumn w tabeli wyników powyżej znajdziesz w sekcji Interpretowanie wyników narzędzia.

Po zidentyfikowaniu takich wycofanych bibliotek możesz zastosować jedną z tych metod , aby rozwiązać problem.
- Umieszczanie zasobów (zalecane, jeśli masz niewielką liczbę plików JAR lub bibliotek z wycofanego katalogu, do których odwołują się pliki JAR Java-Callout).
  - Prześlij zidentyfikowane wycofane pliki JAR jako zasób na wybranym poziomie: wersji proxy interfejsu API, środowiska lub organizacji.
  - Przeprowadź aktualizację oprogramowania Apigee w zwykły sposób.
- Ręczne umieszczanie (zalecane, jeśli masz dużą liczbę plików JAR lub bibliotek, do których odwołują się pliki JAR Java-Callout).
  - W każdym węźle procesora wiadomości utwórz nowy katalog o nazwie external-lib w ścieżce $APIGEE_ROOT/data/edge-message-processor/.
  - Skopiuj zidentyfikowane pliki JAR do tego katalogu external-lib z katalogu, który jest już nieaktualny: cp $APIGEE_ROOT/edge-message-processor/lib/deprecated/some.jar $APIGEE_ROOT/data/edge-message-processor/external-lib/some.jar
  - Sprawdź, czy katalog i pliki JAR są czytelne dla użytkownika Apigee: chown -R apigee:apigee $APIGEE_ROOT/data/edge-message-processor/external-lib
  - Przeprowadź aktualizację oprogramowania Apigee w zwykły sposób.

Zmiana OpenLDAP

Kontekst

OpenLDAP można używać w Edge Private Cloud zarówno do uwierzytelniania, jak i autoryzacji. W Edge for Private Cloud 4.53.01 oprogramowanie OpenLDAP dostarczane przez Apigee zostało uaktualnione z wersji 2.4 do 2.6.

Zmiany

W OpenLDAP 2.6 względna nazwa wyróżniająca (RDN) jest ograniczona do około 241 bajtów/znaków. To ograniczenie jest nieprzekraczalne i nie można go zmienić.

Wpływ

W przypadku wpisów z nadmiernie dużymi nazwami RDN występują błędy replikacji lub importu.
Próba utworzenia podmiotów, takich jak organizacje, środowiska, role niestandardowe, uprawnienia itp., może spowodować wyświetlenie komunikatu o błędzie: "message": "[LDAP: error code 80 - Other]".
Dotyczy to wszystkich nazw wyróżniających w LDAP Apigee, które mają więcej niż 241 bajtów. Takie nazwy wyróżniające uniemożliwią pomyślne uaktualnienie oprogramowania Apigee OpenLDAP. Zanim będzie można kontynuować uaktualnianie, należy zastosować strategie ograniczania ryzyka związane z tymi elementami.

W LDAP Apigee długie nazwy wyróżniające są zwykle powiązane z uprawnieniami, ponieważ powstają przez połączenie wielu elementów. Takie wpisy uprawnień są szczególnie podatne na problemy z uaktualnianiem.

Na przykład

dn: cn=@@@environments@@@*@@@applications@@@*@@@revisions@@@*@@@debugsessions,ou=resources,cn=businessuser,ou=userroles,o=orgname,ou=organizations,dc=apigee,dc=com

Zwykle nazwy organizacji, środowiska i roli mają taką długość, że nazwy względne w LDAP są mniejsze niż 241 bajtów.

Łagodzenie

Przed uaktualnieniem do wersji 4.53.01:

Poniższe kroki pomogą Ci sprawdzić, czy w istniejącym klastrze LDAP 2.4 występują długie nazwy RDN.

1. Wyodrębnij dane LDAP

Użyj polecenia ldapsearch, aby znaleźć nazwę wyróżniającą (dn) i przekierować dane wyjściowe do pliku:

ldapsearch -o ldif-wrap=no -b "dc=apigee,dc=com" -D "cn=manager,dc=apigee,dc=com" -H ldap://:10389 -LLL -x -w LDAP_PASSWORD dn > /tmp/DN.ldif

Upewnij się, że plik DN.ldif zawiera wpisy LDAP.

2. Identyfikowanie długich nazw RDN

Narzędzie do wykrywania zmian używa wygenerowanego pliku LDIF do identyfikowania nazw RDN LDAP przekraczających 241 bajtów/znaków.

Narzędzie wygeneruje raporty w tym formacie:

Organizacja	Środowisko	Nazwa artefaktu	Typ artefaktu	Wersja	Nazwa zasady	Typ zasady	Rodzaj wpływu	Pole dotyczące wpływu	Pewność wpływu	Dokumentacja
Brak	Brak	cn=`really-long-name`,ou=userroles,o=edge-platform,ou=organizations,dc=apigee,dc=com	plik LDIF	Brak	Brak	Brak	Ldap RDN exceeds 241 chars	cn=`really-long-name`	Wysoki	Zmiana OpenLDAP

Szczegółowe wyjaśnienie kolumn w tabeli wyników znajdziesz w sekcji Interpretowanie wyników narzędzia.

Jeśli powyższe polecenie nie wygeneruje żadnych danych wyjściowych, oznacza to, że żadne nazwy RDN w obecnej konfiguracji LDAP nie przekraczają 241 bajtów/znaków. Możesz kontynuować uaktualnianie.

Jeśli powyższe polecenie wygeneruje dane wyjściowe, oznacza to, że istnieją nazwy RDN przekraczające 241 bajtów/znaków. W przypadku takich elementów przed przejściem na Edge for Private Cloud 4.53.01 wykonaj czynności opisane w kroku 3.

3. Obsługa długich nazw RDN

Jeśli w kroku 2 otrzymasz dane wyjściowe, oznacza to, że istnieją nazwy RDN przekraczające 241 bajtów/znaków. Wykonaj poniższe czynności:

Sprawdź wpisy LDAP, które przekraczają 241 bajtów.

Jeśli głównym powodem długości nazwy RDN jest nazwa roli niestandardowej, aplikacji, produktu interfejsu API lub innych elementów, przejdź na używanie alternatywnego elementu o krótszej nazwie.
Jeśli głównym powodem długiego RDN jest nazwa organizacji lub środowiska, musisz przenieść się do innej organizacji lub środowiska o krótszej nazwie.

Powtarzaj powyższe kroki, aż w LDAP nie będzie już względnych nazw wyróżniających dłuższych niż 241 bajtów. Gdy osiągniesz ten stan, przeprowadź uaktualnienie wersji chmury prywatnej w zwykły sposób.

Zmiany dostawcy kryptografii

Kontekst

Ta zmiana została przeniesiona z wersji 4.53.00 Edge for Private Cloud. W Edge for Private Cloud 4.53.00 wewnętrzny dostawca kryptografii został zaktualizowany z Bouncy Castle (BC) do Bouncy Castle FIPS (BCFIPS), aby umożliwić obsługę FIPS.

Zmiany

Jeśli zasady JavaCallout opierają się na używaniu oryginalnego dostawcy BC, zwłaszcza w przypadku korzystania z funkcji zabezpieczeń, które zostały wzmocnione w dostawcy BCFIPS (np. używanie wspólnej pary kluczy do szyfrowania i podpisywania), takie zasady JavaCallout będą wymagać modernizacji. Zasady JavaCallout, które próbują wczytać dostawcę kryptografii Bouncy Castle za pomocą nazwy BC, mogą się nie powieść, ponieważ domyślny dostawca uległ zmianie. Takie zasady korzystające z dostawcy BC mogą później przestać działać. Wszystkie niestandardowe implementacje korzystające ze starego dostawcy BC nie będą już dostępne i będą wymagać sprawdzenia i ponownego wdrożenia.

Łagodzenie

Zalecanym obejściem jest użycie dostawcy BCFIPS. Niestandardowe implementacje JavaCallout, które korzystały ze starego dostawcy, będą wymagać sprawdzenia i ponownej implementacji przy użyciu dostawcy Bouncy Castle FIPS, do którego można uzyskać dostęp za pomocą ciągu znaków „BCFIPS”.

Narzędzie do wykrywania zmian

Opracowaliśmy narzędzie do wykrywania zmian, które identyfikuje proxy Apigee, zasady i współdzielone przepływy, na które może mieć wpływ przejście na Edge for Private Cloud w wersji 4.53.01. To narzędzie generuje raport zawierający szczegółowe informacje o wdrożonych serwerach proxy, przepływach współdzielonych i OpenLDAP, na które mają wpływ zmiany. Zawiera też wskazówki dotyczące konkretnych przewodników i strategii związanych z identyfikowanymi serwerami proxy lub przepływami współdzielonymi.

Wymagania wstępne

Do uruchomienia tego narzędzia wymagana jest maszyna oparta na systemie RHEL.
Aby skrypty narzędzia mogły działać, na hostowanej maszynie wirtualnej musi być zainstalowane i prawidłowo skonfigurowane środowisko JRE 8.
Narzędzie wymaga prawidłowego punktu końcowego (adresu URL) serwera zarządzania oraz prawidłowych danych logowania administratora do uwierzytelniania i pobierania danych.
Narzędzie wymaga dostępu do wyznaczonego katalogu roboczego (np./tmp) w celu wyodrębniania pakietów, generowania logów i przechowywania danych wyjściowych. Sprawdź, czy w tym katalogu jest wystarczająco dużo miejsca na dysku i czy masz odpowiednie uprawnienia do odczytu i zapisu.
Narzędzie wymaga pliku LDIF używającego polecenia ldapsearch w sekcji OpenLDAP change - Extract LDAP data, aby wykrywać długie nazwy RDN o długości ponad 241 znaków lub bajtów.

Uruchamianie narzędzia

Po spełnieniu wszystkich wymienionych powyżej wymagań wstępnych pobierz narzędzie, podając nazwę użytkownika i hasło z Apigee, których używasz do uzyskiwania dostępu do repozytorium Apigee. Po pobraniu wyodrębnij pobrane archiwum.

curl -u uName:pWord https://software.apigee.com/apigee/change-detector/change-detector-for-4.53.01_1.0.0.zip -o /tmp/change-detector-for-4.53.01_1.0.0.zip

unzip /tmp/change-detector-for-4.53.01_1.0.0.zip

Po zakończeniu pobierania możesz uruchomić to polecenie, aby zobaczyć wszystkie dostępne opcje narzędzia:

./change-detector --help

Aby uruchomić narzędzie, użyj tego polecenia i zastąp symbole zastępcze swoimi informacjami:

export APIGEE_PASSWORD=[your_password]
./change-detector --username [your_username] --mgmt-url [MGMT url]

Aby wykryć duże wpisy LDAP RDN, uruchom to polecenie:

./change-detector --username [your_username] --mgmt-url [MGMT url] --ldif-file [LDIF_file]

Narzędzie generuje dane wyjściowe w formacie JSON lub CSV, które można bezpośrednio wykorzystać lub zaimportować do narzędzia czytelnego dla człowieka, takiego jak Arkusze Google.

Interpretowanie wyników narzędzia

Organizacja

Wskazuje nazwę organizacji, w której znajduje się artefakt. W przypadku zmiany OpenLDAP będzie to None.

Środowisko

określone środowisko (np. deweloperskie, testowe, produkcyjne) w organizacji; W przypadku zmiany OpenLDAP będzie to None.

W przypadku zmian w wywołaniu Java, jeśli Artifact Type=env-level-jar, to pole będzie miało wartość None.

Nazwa artefaktu

To pole zawiera nazwę serwera proxy lub wspólnego przepływu. W przypadku zmiany OpenLDAP to pole zawiera encję LDAP RDN.

W przypadku zmian w wywołaniu Java, jeśli Artifact Type=env-level-jar lub org-level-jar, to pole będzie miało wartość None.

Typ artefaktu

W przypadku zmian w OAS i JSON ta kolumna określa typ artefaktu, serwera proxy lub przepływu udostępnionego.
W przypadku zmiany wywołania Java ta kolumna zawiera szczegółowe informacje o miejscu lub poziomie, na którym przesłano plik JAR. Zasoby (pliki JAR) mogą być przechowywane na jednym z 3 poziomów: org-level, env-level, proxy-level.
W przypadku zmiany OpenLDAP to pole wskazuje plik LDIF użyty w narzędziu.

Wersja

Wskazuje wdrożoną wersję odpowiedniego serwera proxy lub przepływu współdzielonego. W przypadku zmiany OpenLDAP będzie to None.

Nazwa zasady

Nazwa konkretnej zasady, która została zidentyfikowana jako potencjalny problem. W przypadku zmiany OpenLDAP będzie to None.

Typ zasady

Wskazuje typ zasady. W przypadku zmiany OpenLDAP będzie to None.

Rodzaj wpływu

To pole opisuje konkretny typ zmiany wykrytej w przepływie proxy lub przepływie współdzielonym.
W przypadku zmiany wywołania Java Callout, wykrywania zmian związanych z wywołaniami Java Callout narzędzie wskazuje wywołanie Java Callout, które odwołuje się do plików JAR znajdujących się w katalogu $APIGEE_ROOT/edge-message-processor/lib/deprecated starszych wersji Edge dla chmury prywatnej, w sposób opisany w tej kolumnie.

deprecated library detected for NAME_OF_THE_AFFECTED_JAVA_CALLOUT_JAR

W przypadku zmiany OpenLDAP to pole wskazuje, czy RDN jakiegokolwiek elementu LDAP przekroczył 241 bajtów lub znaków.

Pole wpływu

W przypadku zmiany OAS to pole zawiera nazwę zmiennej używanej w tagu Źródło zasad.
W przypadku zmiany w pliku JSON to pole zawiera dokładne wyrażenie JSONPath lub element, który został oznaczony jako potencjalny problem.
W przypadku zmiany wywołania Java Callout to pole zawiera szczegółowe informacje o dokładnych klasach i nazwie odpowiedniego pliku JAR (znajdującego się w katalogu $APIGEE_ROOT/edge-message-processor/lib/deprecated starszych wersji chmury prywatnej), które są używane lub do których odwołuje się dotknięty plik JAR wywołania Java Callout. Jeśli nie zostaną podjęte odpowiednie działania, po uaktualnieniu do wersji 4.53.01 wystąpią błędy.

 ['Detected use of class CLASS_NAME_1 from JAR_NAME_1',
    Detected use of class CLASS_NAME_2 from JAR_NAME_2', 
  .. , .. , ]

W przypadku zmiany OpenLDAP to pole zawiera RDN jednostki LDAP, które przekraczają 241 bajtów lub znaków.

Pewność wpływu

To pole określa poziom pewności, z jakim narzędzie wykryło dany element. Wartości w tej kolumnie mogą być wysokie lub średnie (w przyszłości mogą zostać dodane kolejne wartości).

Wartość Wysoka oznacza, że narzędzie wykryło bardzo wysokie prawdopodobieństwo, że po uaktualnieniu do wersji 4.53.01 element spowoduje awarię aplikacji. Wartość Średni oznacza, że narzędzie nie ma pewności co do wykrycia i do podjęcia decyzji potrzebne są dodatkowe strategie (np. przechwytywanie śladu w celu obserwowania rozwiązanych zmiennych podczas wykonywania proxy).
Wykrycia związane ze zmianami w JavaCallout i OpenLDAP będą zawsze miały wartość High (Wysoka) w kolumnach pewności wpływu.

Dokumentacja

Ta kolumna zawiera hiperlink do dokumentacji Apigee (odpowiednich sekcji tego artykułu), która wyjaśnia problem i sposoby jego rozwiązania.