NextPDF Gotenberg — rozruch i wykrywanie

W skrócie

Most nie ma mechanizmu automatycznego wykrywania. Budujesz go jako zwykłą usługę, której przez konstruktor jawnie przekazujesz obiekt wartości konfiguracji oraz współpracowników Hypertext Transfer Protocol (HTTP) zdefiniowanych przez PHP Standard Recommendation (PSR). Ten pakiet nie dostarcza żadnego service providera, bundle’a ani rozszerzenia kontenera i sam nie odczytuje żadnej zmiennej środowiskowej. W tym kontekście „wykrywanie” oznacza sposób, w jaki framework hosta dostarcza tych współpracowników. Ta odpowiedzialność należy do frameworka, a nie do tego pakietu.

Jak most jest wykrywany

Nie jest wykrywany automatycznie. Budujesz go samodzielnie. GotenbergBridge wymaga czterech argumentów i przyjmuje trzy opcjonalne:

• Wymagane: GotenbergConfig, klient PSR-18, fabryka żądań PSR-17 oraz fabryka strumieni PSR-17.
• Opcjonalne: logger PSR-3, polityka bezpieczeństwa Hypertext Markup Language (HTML) (ustawiona domyślnie na politykę rdzenia NextPDF) oraz fabryka odpowiedzi PSR-17.

Fabryka odpowiedzi aktywuje transport z przypinaniem opartym na cURL. Jeśli ją dostarczysz, most użyje transportu z przypinaniem, gdy ma co przypiąć (rozwiązane adresy lub skonfigurowane przypięcia SubjectPublicKeyInfo (SPKI)). Jeśli ją pominiesz, zawsze używany jest wstrzyknięty klient PSR-18. Pełny kontrakt argumentów znajdziesz w /integrations/gotenberg/configuration/.

Sekwencja rozruchu

Nie ma kroku rejestracji. Cykl życia wygląda tak:

1. Host rozwiązuje klienta PSR-18 oraz fabryki PSR-17. Odpowiada za to kontener hosta, a nie pakiet.
2. Aplikacja buduje GotenbergConfig z własnego źródła konfiguracji. GotenbergConfig::fromArray() przyjmuje tablicę w notacji snake_case i podstawia wartości domyślne w miejsce wartości nieprawidłowych. Zweryfikuj źródło na ścieżce rozruchu, aby brakująca wartość Uniform Resource Locator (URL) powodowała błąd podczas rozruchu, a nie przy każdej konwersji.
3. Aplikacja buduje GotenbergBridge z konfiguracją i współpracownikami.
4. Pierwsze wywołanie konwersji uruchamia walidację adresu URL, kontrolę pod kątem server-side request forgery (SSRF), kontrolę nazwy pliku oraz samo żądanie. Podczas budowy nie jest wykonywana żadna praca; most pozostaje bezczynny, dopóki go nie wywołasz.

Powiązania kontenera

Ten pakiet nie dostarcza żadnych powiązań kontenera. Aby można było wstrzykiwać most, zarejestruj go w kontenerze aplikacji hosta w następujący sposób:

• Powiąż GotenbergConfig z własnym źródłem konfiguracji.
• Powiąż klienta PSR-18 oraz fabryki PSR-17 z wybranymi implementacjami.
• Powiąż GotenbergBridge jako usługę, która otrzymuje te zależności.

Automatyczne łączenie zależności, publikowanie konfiguracji oraz rejestracja service providera lub bundle’a po stronie frameworka należą do dedykowanych pakietów integracji z frameworkami, a nie do tego pakietu. Ten pakiet jest z założenia niezależny od frameworka. Zależy wyłącznie od interfejsów PSR, więc działa z dowolnym kontenerem.

Kolejność rozwiązywania konfiguracji

Pakiet sam nie odczytuje żadnej konfiguracji. Kolejność rozwiązywania jest taka, jaką zaimplementuje Twoja aplikacja, zanim wywoła GotenbergConfig::fromArray() lub konstruktor. Typowa kolejność to zmienne środowiskowe, następnie opublikowany plik konfiguracyjny, a na końcu wartości domyślne z kodu. Ta kolejność jest kontraktem Twojej aplikacji, a nie tego pakietu. Pakiet definiuje natomiast wartość domyślną dla każdego pola, które pomija tablica przekazana do fromArray(): pusty adres URL interfejsu programowania aplikacji (API), 30-sekundowy limit czasu, limit rozmiaru 50 MiB, pusty klucz API oraz puste listy przypięć.

Diagnostyka

Dwa wbudowane sygnały potwierdzają, że zależności zostały poprawnie połączone:

• isAvailable() waliduje adres URL bez ruchu sieciowego, następnie wysyła żądanie HEAD do <apiUrl>/health i zgłasza dostępność, gdy status jest niższy niż 500. W razie dowolnego niepowodzenia nie rzuca wyjątku, tylko zwraca false. Wywołuj ją w ramach kontroli gotowości.
• Próbna konwersja małego, sprawdzonego dokumentu potwierdza poprawność całej ścieżki od początku do końca. Obejmuje to żądanie wieloczęściowe do <apiUrl>/forms/libreoffice/convert oraz walidację odpowiedzi.

Zobacz także

• /integrations/gotenberg/integration/ — sterowanie potokiem NextPDF za pośrednictwem usługi.
• /integrations/gotenberg/install/ — instalacja pakietu i usługi.
• /integrations/gotenberg/configuration/ — pełny kontrakt konstruktora i konfiguracji.
• /integrations/gotenberg/overview/ — przebieg konwersji i model zależności.