Omówienie opcji architektury wdrażania

Przy początkowym udostępnieniu, w Oracle Cloud Infrastructure są wdrażane wszystkie instancje Oracle Content Management. Jest to architektura zapewniająca wysoką dostępność z użyciem wielu domen dostępności w jednym regionie geograficznym. W domenach tych jest wykorzystywane rozwiązanie Oracle Container Engine for Kubernetes (OKE) z elastycznie skalowalnymi klasterami Kubernetes.

  • Domeny dostępności — Domena dostępności to centrum danych (jedno lub większa ich liczba) zlokalizowane w danym regionie. Domeny dostępności są wzajemnie odizolowane oraz są odporne na awarie — prawdopodobieństwo jednoczesnej awarii jest niemal zerowe. Ponieważ domeny dostępności nie współdzielą infrastruktury fizycznej (takiej jak systemy zasilania czy chłodzenia) ani wewnętrznej sieci domeny dostępności, awaria dotykająca jednej domeny dostępności nie ma wpływu na pozostałe domeny. Domeny dostępności, występujące w danym regionie, są połączone szerokopasmową siecią, cechującą się małymi opóźnieniami. To przewidywalne, szyfrowane połączenie między domenami dostępności umożliwia tworzenie bloków niezbędnych do zapewnienia zarówno wysokiej dostępności, jak i zdolności przywracania poprawnego stanu po awarii.
  • Domena awaryjna — Domena awaryjna jest to zgrupowanie sprzętu i infrastruktury w domenie dostępności. Każda domena dostępności zawiera trzy domeny awaryjne. Korzystając z domen awaryjnych, można rozdzielać instancje, tak aby nie rezydowały na tym samym sprzęcie w jednej domenie dostępności. Dzięki temu, awarie sprzętu lub działania konserwacyjne, które oddziałują na jedną domenę awaryjną, nie mają wpływu na instancje w innych domenach awaryjnych. Podczas uruchamiania można opcjonalnie określić domenę awaryjną dla nowej instancji albo zezwolić systemowi na dokonanie wyboru.

W przypadku wdrożenia domyślnego, OKE automatycznie tworzy klastery (lub węzły) obejmujące domeny dostępności. Wszystkie serwisy i zasoby są synchronizowane z poszczególnymi domenami dostępności. Jeśli jedna domena dostępności przestanie działać, OKE zacznie automatycznie przekierowywać cały przychodzący ruch do działających domen dostępności. Dzięki temu użytkownicy nie doświadczą wyłączenia usługi w czasie przywracania niedziałającej domeny awaryjnej.
Przykład architektury zapewniającej wysoką dostępność

Zachęcamy do korzystania z naszej opcji Harmonogram uaktualnienia pozwalającej kontrolować, kiedy instancja zostanie uaktualniona do nowego wydania Oracle Content Management. W większości przypadków dla instancji obsługującej ruch produkcyjny oraz instancji, która ten ruch może przejąć w razie awarii, powinna być używana opcja opóźnionego uaktualnienia. Dla instancji przewidzianych do celów rozwojowych i do testowania powinna być używana opcja natychmiastowego uaktualnienia. Taka kombinacja ustawień udostępnia pełny cykl wydania, zapewniając odporność i stabilność kodu oraz dając czas na rozwiązanie ewentualnych problemów, które mogłyby mieć wpływ na ruch produkcyjny. Opcję "Harmonogram uaktualnienia" ustawia się podczas tworzenia instancji Oracle Content Management.

Więcej niż wysoka dostępność

Podczas gdy usługa z wysoką dostępnością ma na celu zapewnienie wysokiego wskaźnika bezustannego działania i dostępności, to jednak wielu klientów ma dodatkowe wymagania, które można spełnić za pomocą innych architektur. Te dodatkowe architektury, nadal przynoszące korzyści wynikające ze standardowej wysokiej dostępności Oracle Cloud Infrastructure i OKE, mogą być konstruowane w celu zapewnienia obsługi procesów rozwojowych (nawet przejmowania awaryjnego obejmującego więcej niż jeden region) lub korzystania z prywatnych, wysokowydajnych połączeń. Aby ustalić, która architektura spełnia konkretne wymagania, trzeba ustalić procesy rozwojowe w swojej firmie, akceptowalny czas odtwarzania awaryjnego (RTO) oraz akceptowalny poziom utraty danych w czasie (RPO).

  • Akceptowalny czas odtwarzania awaryjnego (RTO - Recovery Time Objective) — Jest to czas, w ciągu którego należy przywrócić funkcjonalność aplikacji po wystąpieniu awarii. Celem jest pomiar czasu, w którym trzeba przywrócić poprawne działanie po awarii. Zazwyczaj im bardziej krytyczna aplikacja, tym mniejsza wartość RTO.
  • Akceptowalny poziom utraty danych w czasie (RPO - Recovery Point Objective) — Akceptowalny poziom utraty danych w oknie czasowym, który jest tolerowany przez aplikacje. RPO określa, jak wiele danych mogą utracić aplikacje w razie awarii.

Instancja prywatna z użyciem usługi Oracle Cloud Infrastructure FastConnect

Niektórzy klienci mogą także wymagać dodatkowej wydajności lub dodatkowych zabezpieczeń, które mogą nie być dostępne przy użyciu publicznego Internetu. Można wówczas skorzystać z usługi Oracle Cloud Infrastructure FastConnect zapewniającej bardziej wydajne, odporne i bezpieczne połączenie z instancją Oracle Content Management. Ten typ połączenia jest często używany przez klientów, którzy chcą ograniczyć dostęp do wewnętrznych sieci lub chcą mieć możliwie najlepsze, niezawodne połączenie.

Zamierzając utworzyć taką instancję, trzeba skonfigurować usługę Oracle Cloud Infrastructure FastConnect i wykonać kilka wymaganych czynności wstępnych. FastConnect zapewnia dedykowane, prywatne, szerokopasmowe połączenia, które są bardziej niezawodne i spójne niż połączenia internetowe.

Zob. Tworzenie instancji prywatnej za pomocą Oracle Cloud Infrastructure FastConnect.

Proces rozwojowy

Termin ten odnosi się do procesu realizowanego przez organizację w celu stworzenia i wdrożenia nowej funkcjonalności i zawartości dla Oracle Content Management. Może obejmować wiele środowisk, przez które nowa funkcjonalność i zawartość muszą przejść, zanim zostaną zatwierdzone dla środowisk wysokiego poziomu i produkcji. Typowa konfiguracja uwzględnia środowiska do tworzenia, testowania, gromadzenia i — na koniec — produkcji. Potrzeby konkretnej organizacji mogą się jednak różnić.

Klienci, którzy do obsługi procesów rozwojowych chcą wykorzystywać wiele instancji, powinni udostępnić dodatkowe instancje (zgodnie z opisem w tym dokumencie), lecz nie muszą ustawiać przed nimi zapory aplikacji internetowych (WAF), ponieważ dostęp do tych instancji będzie uzyskiwany bezpośrednio. Po opracowaniu zawartości w jednej z instancji, można za pomocą narzędzia CLI z zestawu OCE Toolkit przenieść tę zawartość z jednej instancji Oracle Content Management do drugiej.

Uwaga:

Tworząc dodatkową instancję, która nie będzie obsługiwać ruchu produkcyjnego, trzeba — aby nie płacić za zduplikowane zasoby — oznaczyć ją jako niepodstawową. Opłaty za instancje podstawowe są naliczane na podstawie łącznej liczby zasobów w danej instancji. Opłaty za instancje niepodstawowe są naliczane na podstawie jednego bloku zasobów na miesiąc (na przykład 5 000 zasób i — mając usługę "Wideo plus" — 250 zasobów "Wideo plus") bez względu na łączną liczbę replikowanych zasobów. Więcej informacji jest dostępnych pod hasłem Oracle PaaS and IaaS Universal Credits Service Descriptions.

Propagację zmian można przeprowadzić za pomocą poleceń z zestawu OCE Toolkit, używając ich do tworzenia serwisów i zarządzania cyklem ich życia w instancjach rozwojowych, testowych i produkcyjnych. Zmian w serwisach można dokonać na serwerze produkcyjnym, a następnie przekazać te zmiany do środowisk testowego i produkcyjnego. Ten zestaw narzędzi opartych na wierszu polecenia można także wprowadzić do swoich środowisk skryptowych w celu zarządzania swoimi wdrożeniami. Korzystając z narzędzi CLI, można tworzyć nowe elementy, takie jak zasoby i składniki czy aktualizacje istniejącej zawartości.

Zob. Konfigurowanie wdrożenia T2P (Test to Production).

Implementowanie regionu tworzenia kopii zapasowej

Jeśli organizacja chce używać regionu tworzenia kopii zapasowej w celu zapewnienia ciągłości dostarczania publicznej zawartości serwisu w razie awarii, należy skonfigurować zaporę sieciową aplikacji internetowych (WAF) i sporządzić w tym regionie kopię zapasową zawartości.

Kopia zapasowa może być w tym samym regionie geograficznym, w którym znajduje się instancja główna, lub w innym regionie. Tworzenie kopii zapasowej w innym regionie zapewnia większą ochronę przed utratą danych lub brakiem dostępności.

Uwaga:

Obecnie Oracle Content Management obsługuje przez WAF tylko serwisy publiczne. Jeśli serwis wymaga identyfikacji, dostęp do niego musi być uzyskiwany bezpośrednio z domeny źródłowej.

Poniżej przedstawiono przykład, jak wygląda architektura:

Przykład konfiguracji WAF

Tworzenie kopii zapasowej może zająć trochę czasu, szczególnie jeśli istnieje wiele serwisów i zasobów; dlatego zalecamy tworzenie kopii zapasowej po godzinach pracy. W zależności od ilości zmian zawartości dokonanych w instancji, należy określić, czy kopie zapasowe mają być tworzone codziennie czy rzadziej, na przykład raz w tygodniu.

Gdy jest implementowany region tworzenia kopii zapasowej, należy użyć usługi Oracle Cloud Infrastructure Web Application Firewall do przekierowania ruchu do instancji głównej (aktywnej); w przypadku awarii instancja główna jest przełączana do instancji kopii zapasowej (rezerwowej).

Uwaga:

Tworząc instancję zapasową, trzeba ją oznaczyć jako instancję drugorzędną, dzięki czemu nie będą naliczane opłaty za zduplikowane zasoby. Za instancje główne i drugorzędne są naliczane opłaty na podstawie różnych stawek.

Po utworzeniu instancji głównej należy — aby zaimplementować region tworzenia kopii zapasowej — wykonać następujące czynności:

  1. Utworzyć nową instancję Oracle Content Management.

    Udostępniając tę instancję, która będzie obsługiwać tylko ruch produkcyjny w przypadku awarii regionu podstawowego, należy pamiętać o oznaczeniu jej jako niepodstawowej, aby uniknąć podwójnego fakturowania za zawarte w niej zasoby. Ponieważ instancja ta może stać się instancją produkcyjną, powinna być także ustawiona dla niej opcja opóźnione uaktualnienie, aczkolwiek musi być uwzględniona w tym samym harmonogramie uaktualniania co region podstawowy — pozwoli to uniknąć problemów podczas przełączania ruchu między regionem podstawowym a zapasowym.

    Jeśli kopia zapasowa ma być tworzona w regionie innym niż region instancji głównej, utworzyć kopię zapasową w regionie drugorzędnym.

  2. Skonfigurować zaporę aplikacji internetowych (WAF) za pomocą usługi Oracle Cloud Infrastructure Web Application Firewall.
  3. Za pomocą zestawu OCE Toolkit przenieść wszystkie serwisy i zasoby z instancji podstawowej do zapasowej:
    1. Zduplikować repozytoria, kanały i założenia systemowe dot. lokalizacji, które istnieją w instancji podstawowej i zapasowej.
    2. Utworzyć instancję obliczeniową VM (o ile wcześniej tego nie zrobiono)..
    3. Zainstalować OCE Toolkit w instancji obliczeniowej VM i skonfigurować go do używania identyfikacji IDCS.
    4. Zarejestrować podstawową i zapasową instancję Oracle Content Management.
    5. Przetransferować serwisy i ich zasoby z instancji głównej do instancji zapasowej.
  4. Sprawdzić, czy dane będą poprawnie poddawane replikacji. Wprowadzić kilka zmian (mniej niż pięć) w instancji głównej, w tym zmiany w poszczególnych typach obiektów, ponownie utworzyć kopię zapasową danych za pomocą zestawu OCE Toolkit, po czym potwierdzić, że zmiany są dokładnie odzwierciedlane w instancji zapasowej.
  5. Zsynchronizować wszystkich użytkowników, którzy mogą potrzebować dostępu do interfejsu użytkownika instancji zapasowej w przypadku, gdy instancja główna będzie niedostępna. Na przykład (jako minimum) trzeba zsynchronizować administratorów.

    Uwaga:

    Instancja zapasowa jest przeznaczona tylko do testowania lub do zapewnienia ciągłości dostępności serwisu publicznego w razie awarii; nie jest przeznaczona do zapewniania możliwości współtworzenia lub dostępu do serwisów wymagających identyfikacji.
  6. Sprawdzić, czy system działa zgodnie z oczekiwaniami, gdy region główny ulegnie awarii:
    1. Wyłączyć instancję główną.
    2. Przełączyć do źródła WAF, aktualizując założenie systemowe WAF, tak aby ruch był kierowany do instancji zapasowej.
    3. Gdy zmiany w założeniu systemowym WAF zostaną przekazane, potwierdzić, że wszystkie środowiska użytkowników działają w instancji zapasowej zgodnie z oczekiwaniami.
  7. Ponownie włączyć instancję główną, aktualizując założenie systemowe WAF, tak że ponownie będzie wskazywana instancja główna, po czym potwierdzić, że instancja główna działa zgodnie z oczekiwaniami, gdy przejmuje pierwotną odpowiedzialność za zarządzanie zawartością i dostarczanie do użytkownika końcowego.

Web Application Firewall — konfiguracja

Aby zaimplementować region tworzenia kopii zapasowej, trzeba wykonać kilka czynności związanych ze skonfigurowaniem i włączeniem usługi WAF (Web Application Firewall):

  1. Tworzenie założenia systemowego WAF
  2. Wysyłanie certyfikatu SSL i klucza
  3. Tworzenie źródła drugorzędnego
  4. Publikowanie zmian
  5. Aktualizowanie konfiguracji DNS
  6. Konfigurowanie usługi WAF w instancjach

Jeśli trzeba się przełączyć z instancji głównej do instancji drugorzędnej, można to zrobić poprzez zaktualizowanie założenia systemowego WAF.

Tworzenie założenia systemowego WAF

Aby skonfigurować założenie systemowe WAF, należy:

  1. Zalogować się do aplikacji Oracle Cloud jako administrator konta Cloud. Nazwę konta oraz dane logowania można znaleźć w e-mailu powitalnym.
  2. W konsoli Infrastructure, w lewym górnym rogu, kliknąć na ikonie Ikona "Menu nawigacyjne" (aby otworzyć menu nawigacyjne), następnie wybrać opcję Tożsamość i bezpieczeństwo, po czym wybrać z obszaru Web Application Firewall opcję Założenia systemowe.
  3. Wybrać przedział, w którym ma zostać utworzone założenie systemowe WAF.
  4. Nacisnąć przycisk Utwórz założenie systemowe WAF.
  5. Aby utworzyć założenie systemowe WAF, podać następujące szczegóły:
    • Nazwa: Podać unikatową nazwę założenia systemowego (na przykład cross_site_WAF). Należy unikać podawania informacji poufnych.
    • Domena główna: Podać w pełni kwalifikowaną nazwę domeny dla aplikacji (na przykład oce.example.com). To jest adres URL, którego będą używali użytkownicy do uzyskiwania dostępu do aplikacji. Adres ten będzie kierował do głównej lub drugorzędnej instancji Oracle Content Management.
    • Dodatkowe domeny: Opcjonalnie podać wszelkie poddomeny, dla których mają być zastosowane założenia systemowe.
    • Nazwa źródła: Podać unikatową nazwę głównego źródła (na przykład primary_salesdocuments1).
    • URI: Podać publicznie dostępny punkt końcowy (URI) instancji głównej (na przykład salesdocuments1-myaccount.cec.ocp.oraclecloud.com).
  6. Nacisnąć przycisk Utwórz założenie systemowe WAF.

Wysyłanie certyfikatu SSL i klucza

Aby wysłać certyfikat SSL i klucz, należy:

  1. Podczas wyświetlania założenia systemowego WAF nacisnąć przycisk Ustawienia (po lewej stronie).
  2. Na karcie Ustawienia ogólne nacisnąć przycisk Edytuj.
  3. W oknie dialogowym "Edycja ustawień":
    1. Wybrać opcję Włącz obsługę HTTPS, dzięki czemu komunikacja między przeglądarką i aplikacją internetową będzie szyfrowana.
    2. Wybrać opcję Wyślij lub wklej certyfikat i klucz prywatny.
    3. W obszarze Wysyłanie źródła certyfikatów przeciągnąć lub wybrać plik bądź wybrać opcję Tekst i wkleić poprawny certyfikat SSL w formacie PEM. Trzeba także dołączyć certyfikaty pośrednie (pierwszy musi być certyfikat domeny głównej).
    4. W obszarze Wysyłanie źródła prywatnego klucza przeciągnąć lub wybrać plik bądź wybrać opcję Tekst i wkleić poprawny klucz prywatny w formacie PEM. Klucz prywatny nie może być chroniony hasłem.
    5. Jeśli jest używany certyfikat samodzielnie podpisany, wybrać opcję Certyfikat samodzielnie podpisany, aby w przeglądarce było wyświetlane ostrzeżenie SSL.
    6. Aby cały ruch HTTP był automatycznie przekierowywany do HTTPS, wybrać opcję Przekieruj z HTTP do HTTPS.
    7. Nacisnąć przycisk Zapisz zmiany. Aktualizacja ta pojawi się w obszarze "Nieopublikowane zmiany".

Tworzenie źródła drugorzędnego

Aby utworzyć źródło drugorzędne, należy:

  1. Kliknąć na karcie Grupy źródeł.
  2. Na karcie Grupy źródeł nacisnąć przycisk Edytuj.
  3. Nacisnąć przycisk Dodatkowe źródło.
  4. Podać następujące szczegóły:
    • Nazwa: Podać unikatową nazwę drugorzędnego źródła (na przykład secondary_salesdocuments1).
    • URI: Podać publicznie ukierunkowany punkt końcowy (URI) instancji drugorzędnej (na przykład salesdocuments2-myaccount.cec.ocp.oraclecloud.com).
    • Port HTTP Port: Podać port HTTP, na którym będzie nasłuchiwać instancja drugorzędna. Port domyślny: 80.
    • Port HTTPS: Podać port, który będzie używany dla zabezpieczonego połączenia HTTP z instancją drugorzędną. Port domyślny: 443.
  5. Aby utworzyć drugorzędne źródło, nacisnąć przycisk Zapisz zmiany. Aktualizacja ta pojawi się w obszarze "Nieopublikowane zmiany".

Publikowanie zmian

Aby opublikować wprowadzone zmiany, należy:

  1. Po lewej stronie nacisnąć przycisk Nieopublikowane zmiany.
  2. Nacisnąć przycisk Publikuj wszystko.
  3. W oknie dialogowym "Publikacja zmian" nacisnąć przycisk Publikuj wszystko.

    Ukończenie aktualizacji może zająć trochę czasu.

Aktualizowanie konfiguracji DNS

Konfigurację DNS można zaktualizować za pomocą CNAME swojej strefy, tak aby żądania od klientów internetowych były kierowane do usługi WAF. CNAME można zleźć, otwierając utworzone założenie systemowe WAF. Wartość CNAME przedstawia podstawową domenę (w wersji z łącznikami stanowiącymi separatory) w domenie OCI, na przykład oce-example-com.o.waas.oci.oraclecloud.net.

Jeśli jest używana poddomena cec.ocp.oraclecloud.com, użytkownik musi zarejestrować zlecenie SR z prośbą do Asysty Technicznej Oracle o przeprowadzenie aktualizacji DNS.

Konfigurowanie usługi WAF w instancjach

Aby skonfigurować usługę WAF w instancjach, należy:

  1. W konsoli Infrastructure, w lewym górnym rogu, kliknąć na ikonie Ikona "Menu nawigacyjne" (aby otworzyć menu nawigacyjne), po czym wybrać kolejno opcje Usługi dla programistów i Content Management.
  2. Aby wyświetlić szczegóły instancji, kliknąć na instancji głównej.
  3. Wybrać opcję Konfiguracja WAF.
  4. W oknie dialogowym "Konfiguracja WAF" wybrać wcześniej utworzone założenie systemowe WAF.

    Zostanie wyświetlona nazwa przedziału instancji. Jeśli założenie systemowe WAF jest w innym przedziale, nacisnąć przycisk Zmień przedział, po czym wybrać właściwy przedział.

  5. Nacisnąć przycisk Zapisz zmiany.

    Na liście działań jest widoczny postęp wprowadzania aktualizacji do instancji. Po zakończeniu aktualizacji, patrząc na szczegóły instancji, będzie można dostrzec główną domenę WAF.

  6. Powtórzyć etapy od 2 do 5 dla instancji drugorzędnej.

Przełączanie źródła WAF

Jeśli trzeba zmienić źródło WAF z instancji głównej na instancję drugorzędną (lub odwrotnie) w celach testowych lub wykonania kopii zapasowej, można to zrobić, aktualizując założenie systemowe dot. usługi WAF.

Oracle Content Management

Aby przełączyć źródło WAF, należy:

  1. Zalogować się do aplikacji Oracle Cloud jako administrator konta Cloud. Nazwę konta oraz dane logowania można znaleźć w e-mailu powitalnym.
  2. W konsoli Infrastructure, w lewym górnym rogu, kliknąć na ikonie Ikona "Menu nawigacyjne" (aby otworzyć menu nawigacyjne), następnie wybrać opcję Tożsamość i bezpieczeństwo, po czym wybrać z obszaru Web Application Firewall opcję Założenia systemowe.
  3. Otworzyć założenie systemowe WAF, które zostało utworzone dla instancji, po czym nacisnąć przycisk Ustawienia (z lewej strony).
  4. Kliknąć na karcie Grupy źródeł, po czym nacisnąć przycisk Edytuj.
  5. Ustawić źródło, do którego ma nastąpić przełączenie jako źródła domyślnego, po czym nacisnąć przycisk Zapisz zmiany. Aktualizacja ta pojawi się w obszarze "Nieopublikowane zmiany".
  6. Po lewej stronie nacisnąć przycisk Nieopublikowane zmiany.
  7. Nacisnąć przycisk Publikuj wszystko.
  8. W oknie dialogowym "Publikacja zmian" nacisnąć przycisk Publikuj wszystko.

    Ukończenie aktualizacji może zająć trochę czasu. Gdy zostanie to wykonane, ruch do aplikacji będzie kierowany do wybranego źródła.

Należy pamiętać, że przekierowanie poprzez WAF jest przeznaczone tylko do testowania lub do zapewnienia ciągłości dostępności serwisu publicznego w razie awarii. Użytkownicy muszą uzyskiwać dostęp do serwisów wymagających identyfikacji lub do interfejsu użytkownika Oracle Content Management w sposób bezpośredni.

Konfigurowanie wdrożenia T2P (Test to Production)

Ten model zasadniczo ma na celu zapewnienie testów i równowagi niezbędnej do działania wysoce dostępnego środowiska oraz przezroczystego zarządzania aplikacjami przechodzącymi z instancji testowej do pośredniej, a następnie do produkcyjnej.

We wdrożeniu są tworzone dedykowane instancje, umożliwiające oddzielenie środowisk programowania, testowania i produkcyjnego.

  1. Utworzyć trzy instancje Oracle Content Management, używając następujących ustawień:
    • Programistyczna — typ instancji: niepodstawowa; harmonogram uaktualnienia: natychmiastowe uaktualnienie
    • Testowa — typ instancji: niepodstawowa; harmonogram uaktualnienia: natychmiastowe uaktualnienie
    • Produkcyjna — typ instancji: podstawowa; harmonogram uaktualnienia: opóźnione uaktualnienie

    Ustawiając instancje programistyczną i testową jako niepodstawowe uzyskuje się pewność, że wszystkie zawarte w nich zasoby nie będą podlegać podwójnemu fakturowaniu.

    Ustawiając instancje programistyczną i testową na natychmiastowe uaktualnienie (gdy tylko będzie dostępne nowe wydanie Oracle Content Management), umożliwia się sprawdzenie uaktualnienia w tych instancjach w celu uzyskania pewności, że uaktualnienie nie zakłóci żadnych już wdrożonych serwisów. W wypadku znalezienia jakichkolwiek błędów, należy je zgłosić do Asysty Technicznej Oracle, dzięki czemu zostaną one naprawione, zanim opóźnione uaktualnienie zostanie zastosowane (jedno wydanie później) dla instancji produkcyjnej.

  2. Utworzyć w instancjiprogramistycznej repozytoria, kanały, założenia systemowe dot. lokalizacji, witryny i zasoby.
  3. Zduplikować w instancjach testowej i produkcyjnej repozytoria, kanały i założenia systemowe dot. lokalizacji.
  4. Utworzyć instancję obliczeniową VM (o ile wcześniej tego nie zrobiono)..
  5. Zainstalować OCE Toolkit w instancji obliczeniowej VM i skonfigurować go do używania identyfikacji IDCS.
  6. Zarejestrować źródłowe i docelowe instancje Oracle Content Management.
  7. Przetransferować serwisy i ich zasoby z instancji źródłowej do docelowej.
  8. Sprawdzić, czy dane są poprawnie replikowane. Wprowadzić kilka zmian (mniej niż pięć) w instancji głównej, w tym zmiany w poszczególnych typach obiektów, po czym potwierdzić, że zmiany są dokładnie odzwierciedlane w instancji tworzenia kopii zapasowej.
  9. Zsynchronizować użytkowników, którzy potrzebują dostępu do instancji drugorzędnych. Na przykład (jako minimum) trzeba zsynchronizować administratorów i programistów.

Więcej informacji dotyczących zestawu OCE Toolkit jest dostępnych w rozdziale Propagate Changes from Test to Production with OCE Toolkit w podręczniku Building Sites with Oracle Content Management.

Instalowanie zestawu OCE Toolkit w instancji obliczeniowej VM

Chcąc utworzyć wdrożenie T2P (Test to Production), trzeba zainstalować w instancji obliczeniowej VM zestaw OCE i skonfigurować go do używania identyfikacji IDCS.

W instancji obliczeniowej VM należy:

  1. Zalogować się jako użytkownik OPC.
  2. Skonfigurować NodeJS:
    1. Zainstalować NodeJS jako użytkownik root: 
      sudo -s
cd /usr/local
wget https://nodejs.org/dist/v12.16.2/node-v12.16.2-linux-x64.tar.xz
tar xf node-v12.16.2-linux-x64.tar.xz
exit
    2. Dodać NodeJS do zmiennej środowiskowej PATH jako użytkownik opc, po czym ponownie załadować profil: 
      vi ~/.bash_profile
--- add :/usr/local/node-v12.16.2-linux-x64/bin to the PATH -- e.g:
PATH=$PATH:$HOME/.local/bin:$HOME/bin:/usr/local/node-v12.16.2-linux-x64/bin
source ~/.bash_profile
    3. Przetestować NPM i NodeJS: 
      [opc@ocivm2pm ~]$ npm --version
6.14.4
[opc@ocivm2pm ~]$ node --version
v12.16.2
  3. Skonfigurować OCE Toolkit:
    1. OCE Toolkit obsługuje połączenie przez aplikację IDCS i dlatego nie trzeba wywoływać Chromium w celu przeprowadzenia identyfikacji. Ustawić flagę pomijania tego pobierania: 
      export PUPPETEER_SKIP_CHROMIUM_DOWNLOAD=true
    2. Zainstalować OCE Toolkit jako użytkownik opc: 
      wget https://github.com/oracle/content-and-experience-toolkit/archive/master.zip
unzip master.zip
rm master.zip
cd content-and-experience-toolkit-master/sites/
npm install
    3. Przetestować instalację: 
      [opc@ocivm2pm sites]$ ./node_modules/.bin/cec --version
20.4.1
    4. Dodać dowiązania symboliczne do binariów cec jako użytkownik root: 
      sudo -s
ln -s /home/opc/content-and-experience-toolkit-master/sites/node_modules/.bin/cec /usr/local/bin/cec
exit
    5. Przetestować, że można jako użytkownik opc uruchamiać cec z dowolnego miejsca: 
      cd
[opc@ocivm2pm ~]$ cec --version
20.4.1
    6. Przygotować folder źródłowy cec, po czym zainstalować cec w tym folderze. Zostanie utworzone drzewo źródła (z pakietem package.json) i przeprowadzona instalacja npm, podczas której do drzewa źródła zostaną pobrane zależności. 
      cd
mkdir cec
cd cec
cec install
  4. Skonfigurować IDCS i zarejestrować swoje instancje, postępując zgodnie z instrukcjami ze strony aplikacji IDCS.

Rejestrowanie serwerów źródłowych i docelowych

Szczegóły połączenia dla instancji źródłowej i docelowej można zarejestrować, używając poniższego polecenia. Na przykład synchronizując zawartość testową z wdrożeniem produkcyjnym, można mieć instancję rozwojową (DEV), pośrednią (TEST) i produkcyjną (PROD).

cec register-server DEV -e http://server:port -u username -p password
cec register-server TEST -e http://server:port -u username -p password
cec register-server PROD -e http://server:port -u username -p password
  • Pierwszą wartością (na przykład DEV, TEST, PROD) jest nazwa serwera, używana do identyfikacji punktu końcowego instancji. Wartością tą może być dowolna nazwa.
  • Wartością opcji -e jest serwer i port, tworzące adres URL, za pomocą którego uzyskuje się dostęp do instancji.
  • Wartością opcji -u jest nazwa użytkownika. Musi to być użytkownik, który może uzyskiwać dostęp do serwisów i zasobów w instancji źródłowej i który będzie ich właścicielem w instancji docelowej.
  • Wartością opcji -p jest hasło użytkownika.

Uwaga:

Można przekazać --keyfile, aby zaszyfrować hasło zapisane w pliku.

Transferowanie serwisów firmowych

Serwisy firmowe można przetransferować, używając następującego polecenia:

cec transfer-site SiteName -s DEV -d TEST -r RepositoryName -l LocalizationPolicyName
  • Pierwszą wartością (SiteName) jest nazwa transferowanego serwisu.
  • Wartością -s jest nazwa wcześniej zarejestrowanej instancji źródłowej.
  • Wartością -d jest nazwa wcześniej zarejestrowanej instancji docelowej.
  • Wartością -r jest repozytorium w instancji docelowej, do której jest transferowany serwis. Opcja ta jest wymagana tylko do transferowania nowych serwisów firmowych do instancji docelowej.
  • Wartością -l jest założenie systemowe dot. lokalizacji w instancji docelowej, które ma zostać zastosowane do transferowanego serwisu. Opcja ta jest wymagana tylko do transferowania nowych serwisów firmowych do instancji docelowej.

Jeśli jest aktualizowany serwis w instancji docelowej, nie trzeba określać repozytorium ani założenia systemowego dot. lokalizacji.

Więcej informacji jest dostępnych w rozdziale Propagate Changes from Test to Production with OCE Toolkit w podręczniku Building Sites with Oracle Content Management.