Techniczne informacje o produkcie - ADONIS 19

Przegląd​

Począwszy od wersji ADONIS 19, produkt jest dostarczany klientom korzystającym z instalacji lokalnych (on-premise) w pełni skonteneryzowanej formie. To istotny krok w kierunku poprawy skalowalności, przenośności i elastyczności operacyjnej. Dzięki nowoczesnemu modelowi dostarczania, który korzysta z kontenerów, ADONIS może być wdrażany bardziej efektywnie w nowoczesnych środowiskach IT, przy zachowaniu funkcjonalności dostępnych we wcześniejszych wersjach systemu.

Architektura​

W wersji ADONIS 19 aplikacja jest dystrybuowana jako zestaw obrazów kontenerów zgodnych ze standardem OCI. Podejście to zachowuje funkcjonalną architekturę poprzednich wersji ADONIS, jednocześnie umożliwiając elastyczny i nowoczesny model wdrożenia.

Główne komponenty aplikacji działają jako dwa oddzielne kontenery:

• kontener serwera WWW

• kontener serwera aplikacji

Odpowiednie obrazy są udostępniane poprzez rejestr zgodny ze standardem OCI.

ADONIS obsługuje dwa warianty wdrożenia:

• Wdrożenie Kubernetes - przy użyciu dostarczonego pakietu Helm (Helm chart)

• Wdrożenie Docker Compose - przy użyciu dostarczonej konfiguracji Compose

Oba warianty wdrożenia orkiestrują te same dwa skonteneryzowane komponenty aplikacji. Kubernetes oferuje zaawansowane możliwości orkiestracji ze specjalistycznymi typami zasobów, funkcjami integracji oraz ogólnie architekturę klastrów klasy enterprise, natomiast Docker Compose zapewnia prostszą konfigurację dla środowisk, które nie wymagają pełnych możliwości Kubernetes.

Baza danych ADONIS jest zazwyczaj obsługiwana poza klastrem Kubernetes lub środowiskiem Docker. Klienci nadal niezależnie zarządzają istniejącym serwerem bazy danych.

Wdrożenie Kubernetes​

Poniższy diagram ilustruje sposób wdrożenia ADONIS 19 w środowisku Kubernetes. Komponenty aplikacji działają w dedykowanej przestrzeni nazw (namespace), natomiast wspierające komponenty infrastruktury są zazwyczaj dostarczane w innych przestrzeniach nazw.

Wymagania wstępne dla Kubernetes​

Klaster Kubernetes, w którym będzie działał ADONIS, musi zapewniać:

• kontroler Ingress lub kontroler Gateway API do kierowania ruchem użytkowników końcowych

• StorageClass do udostępniania (provisioning) woluminów trwałych (persistent volumes)

  • parametr allowVolumeExpansion=true jest wysoce zalecany

Zaleca się, aby klaster zapewniał również:

• cert-manager do automatyzacji obslugi certyfikatów TLS dla Ingress lub HTTPRoute

• ClamAV udostępniający punkt końcowy TCP do skanowania złośliwego oprogramowania podczas przesyłania i pobierania plików

Szczegóły architektoniczne​

Przestrzeń nazw ADONIS​

Komponenty aplikacji ADONIS działają we własnej przestrzeni nazw i składają się z:

• HttpRoute / Ingress - pełniący rolę punktu wejścia dla ruchu zewnętrznego do przestrzeni nazw ADONIS

• warstwa serwera WWW - serwer WWW jest udostępniany przez serwis Kubernetes i korzysta z woluminu trwałego do przechowywania lokalnych logów

• warstwa serwera aplikacji - serwer aplikacji działa jako oddzielne wdrożenie z własnym serwisem i trwałym magazynem danych dla indeksu wyszukiwania pełnotekstowego oraz lokalnych logów

Inne przestrzenie nazw​

Komponenty na poziomie klastra wspierające wdrożenie ADONIS:

• kontroler Ingress / kontroler Gateway API - do kierowania ruchem zewnętrznym

• StorageClass - używana do udostępniania (provisioning) woluminów trwałych

• cert-manager (opcjonalny) - do automatyzacji certyfikatów TLS

• ClamAV (opcjonalny) - do skanowania złośliwego oprogramowania

Zachowanie podczas wdrożenia​

• Zarowno wdrożenia serwera WWW, jak i serwera aplikacji obsługują skalowanie pionowe poprzez ustawianie żądań i limitów zasobów (CPU i pamięć).

• Począwszy od Kubernetes w wersji 1.35, żądania i limity można dostosowywać na poziomie poda bez przestoju.

• Każde wdrożenie używa jednej repliki; ADONIS 19 nie obsługuje skalowania poziomego z wieloma replikami.

• Lokalne logi są wymagane do umożliwienia tworzenia Pakietu Informacji Pomocniczych (SIP) w aplikacji, który jest niezbędny do uzyskania wsparcia technicznego.

Zewnętrzna baza danych​

ADONIS korzysta z zewnętrznej bazy danych PostgreSQL lub MSSQL, która działa poza klastrem Kubernetes i jest zarządzana niezależnie.

Wdrożenie Docker Compose​

Poniższy diagram ilustruje sposób wdrożenia ADONIS 19 na jednym hoście przy użyciu narzędzi kompatybilnych z Docker Compose, takich jak Docker lub Podman.

W tym wariancie kontenery serwera WWW i serwera aplikacji ADONIS działają na tej samej maszynie. Trwałe dane są przechowywane z użyciem woluminów Docker, a dostęp zewnętrzny jest zazwyczaj zapewniany przez odwrotny serwer proxy (reverse proxy).

Szczegóły architektoniczne​

Stos ADONIS Docker Compose​

Stos Compose składa sie z:

• odwrotnego serwera proxy (np. nginx) - obsługuje przychodzące żądania HTTP(S) i przekazuje je do serwera WWW ADONIS

• kontenera serwera WWW

• kontenera serwera aplikacji

• woluminów - używanych do przechowywania lokalnych logów i indeksu wyszukiwania pełnotekstowego

Zachowanie podczas wdrożenia​

• Zarówno serwer WWW, jak i serwer aplikacji działają na jednym hoście.

• Woluminy kontenerów zapewniają trwałość logów i danych indeksu wyszukiwania.

• Skalowanie jest ograniczone do konfiguracji jednowęzłowej; wdrożenie z wieloma replikami lub w formie rozproszonej nie jest obsługiwane.

• Lokalne logi przechowywane w woluminach umożliwiają tworzenie Pakietu Informacji Pomocniczych (SIP) dla wsparcia technicznego.

Zewnętrzna baza danych​

ADONIS korzysta z zewnętrznej bazy danych PostgreSQL lub MSSQL, która zazwyczaj działa poza hostem Docker i jest zarządzana niezależnie.

Rejestr i aktualizacje​

ADONIS 19 jest dystrybuowany w formacie opartym na kontenerach. Dostarczane są następujące artefakty wydania.

Obrazy kontenerów​

Aplikacja ADONIS jest dystrybuowana jako zestaw obrazów kontenerów, w tym:

• obraz serwera WWW - zapewnia interfejs webowy i obsługuje żądania HTTP(S)

• obraz serwera aplikacji - realizuje logikę aplikacji ADONIS i operacje backendowe

Helm Charts​

W przypadku wdrożeń opartych na Kubernetes, ADONIS dostarcza Helm chart dla każdej wydanej wersji ADONIS. Pakiet ten definiuje zasoby Kubernetes i parametry konfiguracyjne wymagane do uruchomienia komponentów ADONIS w środowisku skonteneryzowanym.

W zestawie znajduje się pakiet nadrzędny (umbrella chart), który definiuje pełne wdrożenie ADONIS.

Umbrella chart zawiera centralny plik values.yaml, który określa:

• odniesienia do obrazów kontenerów

• ustawienia zasobów

• konfiguracje serwisów

• parametry specyficzne dla środowiska

Wartości te można dostosować do środowiska docelowego.

Helm chart zawiera wyłącznie konfigurację wdrożenia, taką jak:

• definicje obrazów kontenerów

• specyfikacje zasobów Kubernetes

• parametry konfiguracyjne

Helm chart nie zawiera ani nie ładuje wstępnie danych aplikacji.

Dane aplikacji są przechowywane trwale w skonfigurowanej bazie danych i dlatego nie ulegają zmianie podczas wdrażania, aktualizację ani ponowne wdrożenie Helm chart. Zapewnia to, że wdrożenia pozostają bezstanowe na warstwie aplikacji, a trwałe dane są zarządzane niezależnie poprzez bazę danych i skonfigurowane trwałe magazyny.

Dystrybucja artefaktów​

Rejestr kontenerów​

Wszystkie obrazy kontenerów i Helm charts są dystrybuowane przez oficjalny rejestr zgodny z OCI, zarządzany przez BOC.

• Klienci otrzymują zaproszenie e-mail do rejestracji w rejestrze.

• Dostęp do rejestru jest zabezpieczony uwierzytelnianiem i kontrolą dostępu opartą na rolach.

• Po rejestracji klienci mogą samodzielnie zarządzać swoimi danymi dostępowymi (np. kluczami dostępu lub tokenami).

Dane te mogą być używane do bezpiecznego uwierzytelnienia i pobierania wymaganych artefaktów ADONIS z rejestru za pomocą:

• środowisk uruchomieniowych kontenerów (np. Docker, containerd, Podman)

• środowisk Kubernetes

• potoków CI/CD lub narzędzi do automatyzacji wdrożeń

Środowiska izolowane (air-gapped)​

Obrazy kontenerów mogą być replikowane (mirroring) do wewnętrznych rejestrów w celu obsługi środowisk z ograniczonym dostępem lub izolowanych od internetu.

Przykłady wewnętrznych rozwiązań rejestrów:

• JFrog Artifactory

• Harbor

• Nexus Repository

Aktualizacje​

Aktualizacje obrazów kontenerów i Helm charts odbywają się zgodnie ze standardowym procesem wydawania i utrzymania ADONIS. Nowe wersje obrazów są publikowane w rejestrze OCI w ramach oficjalnych wydań produktu, aktualizacji konserwacyjnych lub poprawek bezpieczeństwa.

Klienci są informowani o nowych wydaniach za pośrednictwem standardowych kanałów komunikacji (takich jak informacje o wydaniach i komunikaty dla klientów). Zaktualizowane obrazy można następnie pobrać z rejestru i wdrożyć zgodnie z wewnętrznymi procedurami wdrożeniowymi i aktualizacyjnymi klienta.

Klienci zachowują pełną kontrolę nad terminem wdrażania aktualizacji w swoich środowiskach.

Wymagania systemowe​

Wymagania klienckie​

Wymagania dotyczące oprogramowania dla klienta webowego ADONIS pozostają niezmienione w porównaniu z poprzednimi wersjami ADONIS.

Obsługiwane przeglądarki​

Zaleca się korzystanie z najnowszych wersji przeglądarek, aby zapewnić pełną funkcjonalność i bezpieczeństwo.

Wymagania serwerowe​

Środowisko uruchomieniowe kontenerów​

ADONIS 19 obsługuje środowiska uruchomieniowe kontenerów zgodne z OCI na architekturze AMD64 (x86_64).Obsługiwane są lub oczekuje się działania następujących platform:

Platforma Status Kubernetes (x86_64) Obsługiwana Docker i Docker Compose (x86_64) Obsługiwana Inne platformy zgodne z Kubernetes (x86_64) Oczekiwana zgodność Inne środowiska uruchomieniowe OCI (x86_64) Oczekiwana zgodność

BOC Group obsługuje ADONIS we własnym środowisku SaaS przy użyciu Kubernetes oraz stosuje Docker i Docker Compose do wewnętrznego tworzenia oprogramowania, testowania i walidacji. Środowiska te są zatem w pełni zwalidowane.

Platformy sklasyfikowane jako „oczekiwana zgodność" nie są indywidualnie testowane ani walidowane, ale oczekuje się, że będą działać poprawnie, jeśli spełniają odpowiednie standardy Kubernetes i OCI.

System operacyjny​

ADONIS 19 moze dzialac na nowoczesnych dystrybucjach Linux obslugujacych Kubernetes lub Docker/containerd, takich jak:

• Ubuntu

• Debian

• Red Hat Enterprise Linux (RHEL)

• SUSE Linux Enterprise Server (SLES)

Oczekuje się, że każda nowoczesna dystrybucja Linux zdolna do uruchomienia wybranego środowiska uruchomieniowego kontenerów będzie zgodna.

Kubernetes i narzędzia wdrożeniowe​

ADONIS 19 może działać na nowoczesnych dystrybucjach Linux obsługujących Kubernetes lub Docker/containerd, takich jak:

Baza danych​

ADONIS wymaga zewnętrznej bazy danych do przechowywania wszystkich trwałych danych repozytorium. Wymagania dotyczące bazy danych pozostają niezmienione w porównaniu z poprzednią wersją ADONIS. Jako punkt odniesienia można stosować obsługiwane bazy danych dla ADONIS 17.

Trwałe magazynowanie danych​

Trwałe magazynowanie danych jest wymagane dla indeksu wyszukiwania pełnotekstowego oraz plików logów aplikacji. Magazynowanie jest zazwyczaj realizowane przy użyciu Kubernetes Persistent Volumes (PV) i Persistent Volume Claims (PVC), skonfigurowanych za pomocą dostarczonego Helm chart.

Sieć​

Obrazy kontenerów są dystrybuowane przez rejestr zgodny z OCI i dostępne przez HTTPS.

Typowe wymagania sieciowe obejmują:

ADONIS jest zazwyczaj udostępniany przez kontroler Kubernetes Ingress, kontroler Gateway API lub zewnętrzny odwrotny serwer proxy.

Kontener serwera WWW ADONIS udostępnia port 8080 i nie obsługuje samodzielnie terminacji połączeń HTTPS.

W celu uzyskania zaszyfrowanego dostępu (HTTPS) terminacja TLS musi być realizowane przez komponent Ingress/gateway w Kubernetes lub przez odwrotny serwer proxy w wdrożeniach Docker Compose.

Wymagania sprzętowe​

Ogólne zasady​

Wymagania sprzętowe dla ADONIS 19 działającego w kontenerach są ogólnie porównywalne z poprzednimi wdrożeniami opartymi na Windows. Jako punkt wyjścia można stosować zalecenia dotyczące doboru sprzętu z ADONIS 17.

Typowe zasoby komponentów​

Poniższe wartości przedstawiają typowe wymagania dotyczące CPU i pamięci dla każdego kontenera ADONIS.

Rzeczywiste zużycie zasobów zależy od czynników takich jak:

• liczba jednoczesnych użytkowników

• rozmiar i złożoność repozytorium

• aktywność modelowania i raportowania

• wzorce obciążenia aplikacji

Przykładowa konfiguracja zasobów​

Poniższe wartości pokazują, jak typowe wymiarowanie ADONIS można odwzorować na ustawienia zasobów Kubernetes. Są one oparte na zalecanych wartościach podanych powyżej i powinny być dostosowane do rzeczywistego obciążenia.

Kontener serwera WWW​

Kontener serwera aplikacji​

Konfiguracja i instalacja wdrożenia​

Podejście do konfiguracji​

Konfiguracja ADONIS 19 opiera sie na dwoch uzupelniajacych sie mechanizmach.

Ustawienia i konfiguracja przechowywane w aplikacji​

Te ustawienia są zarządzane indywidualnie przez użytkowników lub centralnie przez Administrację ADONIS. Są przechowywane w bazie danych ADONIS.

Przykłady:

• konfiguracja uwierzytelniania

• administracja uprawnieniami

• ustawienia REST API

• preferencje na poziomie aplikacji

Ustawienia i konfiguracja odczytywane ze srodowiska​

Te ustawienia są odczytywane przez aplikację ze środowiska uruchomieniowego.

We wcześniejszych wersjach ADONIS takie ustawienia były przechowywane w plikach .properties lub .conf w katalogach serwera aplikacji (np. server.conf) lub aplikacji webowej (np. adoxx_web.properties).

W ADONIS 19 aplikacja jest dystrybuowana jako obrazy kontenerów dla serwera aplikacji i serwera WWW. Ponieważ kontenery mają charakter efemeryczny, konfiguracja oparta na plikach nie jest już obsługiwana.

Zamiast tego cała konfiguracja specyficzna dla wdrożenia jest teraz przekazywana przez zmienne środowiskowe:

• Kubernetes: zmienne są definiowane w pliku values.yaml i przekazywane do kontenerów podczas wdrażania Helm chart.

• Docker: zmienne są definiowane w docker-compose.yml i stosowane przy uruchamianiu kontenerów.

Konfiguracja serwera aplikacji​

Właściwości konfiguracyjne serwera aplikacji są dostarczane jako zmienne środowiskowe za pomocą:

• pliku Helm values.yaml (wdrożenia Kubernetes), lub

• pliku docker-compose.yml (wdrożenia Docker)

Wszystkie zmienne serwera aplikacji mają prefiks ADOXX_.

Poniższe przykłady pokazują, jak skonfigurować nazwę bazy danych oraz porty procesów aworker.

Kubernetes:

axx:
  aserver:
    env:
      - name: ADOXX_SERVER_DBNAME
        value: adonis19
      - name: ADOXX_SERVER_PORTS
        value: 5432,5432
  ...

Docker:

...
  aserver:
    image: adonis.image/aserver
    container_name: aserver
    ...
    environment:
      - ADOXX_SERVER_DBNAME=adonisdb
      - ADOXX_SERVER_PORTS=54321,54322
      ...

Konfiguracja serwera WWW​

Właściwości konfiguracyjne serwera WWW są również dostarczane jako zmienne środowiskowe za pomocą pliku values.yaml (Kubernetes) lub docker-compose.yml (Docker).

Zmienne serwera WWW mają prefiks AXW_PROPERTIES_.

Poniższe przykłady pokazują, jak skonfigurować, z którego serwera aplikacji i z których procesów aworker ma korzystać serwer WWW, oraz jak zwiększa się maksymalny rozmiar plików logów REST do 300 MB.

Kubernetes:

axx:
  ...
  webserver:
    env:
      - name: AXW_PROPERTIES_aservers
        value: AS1:adonis.host
      - name: AXW_PROPERTIES_aworkers
        value: AS1:54321,AS1:54322
      - name: AXW_PROPERTIES_axw_logger_appender_rest_maxfilesize
        value: 300MB
...

Docker:

...
  webserver:
    image: adonis.image/webserver
    container_name: webserver
    ...
    environment:
      - AXW_PROPERTIES_aservers=AS1:adonis.host
      - AXW_PROPERTIES_aworkers=AS1:54321,AS1:54322
      - AXW_PROPERTIES_axw_logger_appender_rest_maxfilesize=300MB
      ...

Szczegółowa dokumentacja opcji konfiguracyjnych zostanie dostarczona w oficjalnej dokumentacji ADONIS 19.

Przyklad konfiguracji Kubernetes​

Poniższy przykład pliku values.yaml przedstawia minimalną konfigurację wdrożenia ADONIS z:

• jedną instancją serwera aplikacji

• wieloma procesami aworker

• ustawieniami połączenia z bazą danych

• konfiguracją logowania

• parametrami środowiska uruchomieniowego

Definiuje zmienne środowiskowe dla komponentów serwera aplikacji (aserver) i serwera WWW (webserver), wraz z ustawieniami zasobów i opcjonalnymi funkcjami takimi jak poczta e-mail i punkty końcowe cyklu życia, stanowiąc dane wejściowe dla wdrożenia opartego na Kubernetes za pomocą Helm.

axx:
  aserver:
    env:
    - name: ADOXX_SERVER_DBNAME
      value: adonis19
    - name: ADOXX_SERVER_DBTYPE
      value: PostgreSQL
    - name: ADOXX_SERVER_DBPORT
      value: 5432
    - name: ADOXX_SERVER_DBHOST
      value: postgres.company.com
    - name: ADOXX_SERVER_WEBTIERAUTH_TRUSTED_HOSTS
      value: 127.0.0.*
    - name: ADOXX_LOG_MODE
      value: MIXED
    resources:
      limits:
        memory: 4096Mi
      requests:
        cpu: 500m
        memory: 2048Mi
    workerConf:
      count: 2
  instance:
    name: adonis19
  webserver:
    env:
    - name: AXW_PROPERTIES_mail_enabled
      value: 'true'
    - name: AXW_PROPERTIES_mail_server
      value: smtp.company.com 
    - name: AXW_PROPERTIES_mail_server_port
      value: '25'
    - name: AXW_PROPERTIES_mail_sender
      value: ADONIS <no-reply@company.com>
    - name: AXW_PROPERTIES_mail_reply_to
      value: no-reply@company.com
    - name: JAVA_OPTS
      value: -Xms512m -Xmx2048m
    - name: AXW_PROPERTIES_base_url
      value: https://adonis19.company.com
    - name: AXW_PROPERTIES_lifecycleops_endpoint_enable
      value: 'true'
    - name: AXW_PROPERTIES_axw_logger_console_enabled
      value: 'true'
    - name: AXW_PROPERTIES_axw_logger_root_level
      value: INFO
    httpRoute:
      hostnames:
      - adonis19.company.com
    resources:
      limits:
        memory: 4096Mi
      requests:
        cpu: 100m
        memory: 2048Mi

Przykład konfiguracji Docker Compose​

Ta konfiguracja Docker Compose wdraża ADONIS z:

• jedną instancją serwera aplikacji

• dwoma portami aworker

• połączeniem z zewnętrzną bazą danych

• logowaniem opartym na lokalnych woluminach

• współdzieloną siecią mostkową (bridge network)

services:
 aserver:
    image: <boc-registry>/adonis/aserver:19.0.0
    container_name: aserver
    user: root
    ports:
      - 54321:54321
      - 54322:54322
    environment:
      - ADOXX_SERVER_PORTS=40180
      - ADOXX_SERVER_DBNAME=<adbname>
      - ADOXX_SERVER_DBTYPE=<PostgreSQL/SQLServer>
      - ADOXX_SERVER_DBHOST=<hostname/IPaddress>
#      - ADOXX_SERVER_DBPORT=5432 (for PostgreSQL)
      - ADOXX_SERVER_WEBTIERAUTH_TRUSTED_HOSTS=*.*.*.*
      - ADOXX_LOG_MODE=MIXED
      - TZ=Europe/Vienna
    volumes:
      - ./logs/aserver:/aserver/logs
    shm_size: "300mb"
    networks:
      aserver_webserver:

 webserver:
    image: <boc-registry>/adonis/webserver:19.0.0
    container_name: webserver
    user: root
    ports:
      - 8888:8080
    environment:
      - JAVA_OPTS=-Xms512m -Xmx2048m -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=*:8000
      - AXW_PROPERTIES_aworkers=AS1:54321,AS1:54322
      - AXW_PROPERTIES_aservers=AS1:aserver
      - AXW_PROPERTIES_axw_logger_console_enabled=true
      - AXW_PROPERTIES_axw_webserver_debug_enabled=false
      - AXW_PROPERTIES_axw_logger_root_level=INFO
      - AXW_PROPERTIES_base_url=https://adonis19.company.com
      - AXW_PROPERTIES_lifecycleops_endpoint_enable=true
      - AXW_PROPERTIES_mail_enabled=true
      - AXW_PROPERTIES_mail_server=smtp.company.com
      - AXW_PROPERTIES_mail_server_port=25
      - AXW_PROPERTIES_mail_sender=ADONIS <no-reply@company.com>
      - AXW_PROPERTIES_mail_reply_to=no-reply@company.com
      - TZ=Europe/Vienna
    volumes:
      - ./logs/webserver:/tomcat/logs
    networks:
      aserver_webserver

networks:
  aserver_webserver:
    driver: bridge
    enable_ipv6: true

Uwierzytelnianie i integracja z systemami tożsamości​

Uwierzytelnianie w ADONIS jest obsługiwane na poziomie warstwy aplikacji webowej i jest niezależne od podstawowego systemu operacyjnego. Aplikacja webowa obsługuje historycznie działanie na wielu platformach, w tym Linux, Solaris i Windows.

Uwierzytelnianie LDAP i SAML​

Uwierzytelnianie LDAP i SAML nie jest naruszane przez migrację do wdrożenia opartego na Linuksie i kontenerach.

Komunikacja z systemami tożsamości odbywa się przy użyciu standardowych protokołów sieciowych (LDAP, HTTP, HTTPS), które są niezależne od systemu operacyjnego.

Istniejące konfiguracje LDAP lub SAML mogą być ponownie używane bez zmian specyficznych dla systemu operacyjnego.

Wpływ na konfigurację​

Ponieważ uwierzytelnianie jest obsługiwane w aplikacji webowej i opiera się na komunikacji niezależnej od systemu operacyjnego, przejście na wdrożenie skonteneryzowane nie wprowadza żadnych zmian funkcjonalnych dla obsługiwanych mechanizmów uwierzytelniania.

Wymagane mogą być jedynie dostosowania specyficzne dla środowiska (np. nazwy hostów lub ustawienia sieciowe).

Aktualizacja z ADONIS 16.x/17.x do ADONIS 19​

Niniejszy przewodnik zawiera ogólny przegląd migracji z ADONIS 16.x/17.x do ADONIS 19.

Podkreśla główne koncepcje, kluczowe zmiany architektoniczne i niezbędne etapy migracji.

Główne zmiany koncepcyjne w ADONIS 19​

Następuje istotna zmiana techniczna: serwer aplikacji ADONIS 19 nie działa już w systemie Windows – serwer aplikacji jest teraz kontenerem opartym na Linuksie i zgodnym ze standardem OCI.

Przebieg migracji opisany w tym przewodniku​

Poniższa lista podsumowuje ogólny przebieg migracji opisany w tym przewodniku (w sekcji Proces aktualizacji):

1. Eksportuj ustawienia komponentów, zatrzymaj stare usługi ADONIS 16.x/17.x i wykonaj kopię zapasową niezbędnych wartości konfiguracyjnych.

2. Kontynuuj korzystanie z istniejącej bazy danych i przeprowadź aktualizację schematu w miejscu po wykonaniu kopii zapasowej.

3. Wdróż ADONIS 19 przy użyciu Kubernetes (Helm) lub Docker Compose i skonfiguruj wszystkie wartości na poziomie wdrożenia jako zmienne środowiskowe na podstawie wcześniej zapisanych wartości.

4. Wykonaj zadania poinstalacyjne w aplikacji (aktualizuj bibliotekę, migruj ustawienia, uruchom skrypty).

Spośród tych kroków, 1, 2 i 4 mają podobny charakter do poprzednich przewodników aktualizacji ADONIS, natomiast krok 3 wprowadza nowy model wdrożenia opartego na kontenerach.

Wymagania wstępne​

Przed rozpoczęciem migracji upewnij się, że spełnione są następujące warunki.

Wymagania systemowe i środowiskowe:

• Dostępne musi być obsługiwane środowisko uruchomieniowe (Kubernetes lub Docker Compose).

• Dla obu kontenerów ADONIS 19 muszą być dostępne wystarczające zasoby (CPU, pamięć, magazyn).

• Więcej informacji znajdziesz w sekcji Wymagania systemowe.

Wymagania dotyczące bazy danych i kopii zapasowych:

• Istniejąca baza danych ADONIS (SQL Server lub PostgreSQL) musi być dostępna ze środowiska uruchomieniowego.

• Przed wprowadzeniem jakichkolwiek zmian należy utworzyć kopię zapasową bazy danych.

Dostęp i dane uwierzytelniające:

• Dostęp administracyjny do starego środowiska ADONIS 16.x/17.x.

• Dane uwierzytelniające do wdrożenia dla Kubernetes lub Docker Compose.

• Dane uwierzytelniające do bazy danych z wystarczającymi uprawnieniami do połączenia z bazą danych ADONIS i uruchomienia skryptu aktualizacji schematu ADONIS 19.

• Dane uwierzytelniające do rejestru kontenerów w celu uwierzytelnienia do rejestru kontenerów BOC i opcjonalnie do rejestru kontenerów organizacji.

Obrazy kontenerów i pakiet instalacyjny:

Z rejestru kontenerów BOC:

• Obrazy kontenerów OCI dla:

• serwera aplikacji

• serwera WWW

• Manifesty wdrożenia:

• values.yaml (Kubernetes)

• docker-compose.yml (Docker)

Z pakietu instalacyjnego (do pobrania):

• Plik biblioteki (jeśli używasz Biblioteki Aplikacji ADONIS BPMS)

• Skrypt aktualizacji bazy danych

• Skrypt migracji (jeśli aktualizujesz z ADONIS 16.x)

Biblioteka aplikacji dla ADONIS 19:

• Możesz od razu zacząć, jeśli używasz domyślnej biblioteki (ADONIS BPMS Application Library).

• Skontaktuj się ze swoim konsultantem ADONIS, jeśli używasz innej biblioteki aplikacji.

Proces aktualizacji​

Poniższe sekcje opisują główne etapy migracji w kolejności, w jakiej powinny być realizowane. Stanowią ogólny zarys tego, co należy zrobić – od zamknięcia starego systemu po wdrożenie ADONIS 19 i wykonanie końcowych zadań w aplikacji.

Eksport ustawień komponentów​

Najpierw należy wyeksportować ustawienia komponentów ze starego środowiska ADONIS 16.x/17.x:

• Wyeksportuj ustawienia komponentów teraz, aby można je było ponownie zaimportować po aktualizacji biblioteki aplikacji.

• Wyeksportuj wszystkie ustawienia naraz lub wybierz te, które chcesz zachować.

Zatrzymanie usług​

Po wyeksportowaniu ustawień komponentów stare środowisko ADONIS 16.x/17.x można zatrzymać:

• Zatrzymaj usługę serwera aplikacji ADONIS na obecnym hoście.

• Zatrzymaj usługę Tomcat obsługującą istniejącą aplikację webową ADONIS 16.x/17.x.

• Jeśli jest wdrożone rozwiązanie monitorujące, tymczasowo je wyłącz.

Kopia zapasowa danych specyficznych dla wdrożenia​

Następnie wykonaj kopię zapasową danych specyficznych dla wdrożenia ze starego środowiska ADONIS 16.x/17.x. Informacje te będą potrzebne później podczas konfigurowania ADONIS 19.

• Wykonaj kopię zapasową plików konfiguracyjnych zawierających wartości specyficzne dla środowiska (np. nazwa bazy danych, porty, ustawienia hosta/IP, dostosowane parametry), takich jak server.conf i adoxx_web.properties.

• Przechowaj wszystkie pliki kopii zapasowej w dostępnym miejscu, aby móc przenieść odpowiednie wartości do zmiennych środowiskowych w ADONIS 19.

Aktualizacja schematu bazy danych​

Zaktualizuj istniejącą bazę danych ADONIS do schematu ADONIS 19:

• Utwórz kopię zapasową bazy danych teraz, jeśli jeszcze tego nie zrobiłeś.

• Uruchom skrypt aktualizacji bazy danych ADONIS 19 dla swojego systemu baz danych (SQL Server lub PostgreSQL).

Przygotowanie środowiska uruchomieniowego​

Postępuj zgodnie z krokami dla wybranej platformy orkiestracji:

Wdrożenie Kubernetes​

Przygotuj środowisko Kubernetes:

• Utwórz lub wybierz przestrzeń nazw dla ADONIS.

• Upewnij się, że wymagane StorageClasses są dostępne dla woluminów trwałych.

• Upewnij się, że dostępny jest kontroler Ingress lub kontroler Gateway API. Helm chart obsługuje zarówno Ingress, jak i HTTPRoute.

Wdrożenie Docker Compose​

Przygotuj środowisko Docker:

• Upewnij się, że dostępne jest środowisko uruchomieniowe kontenerów (np. Docker, containerd, Podman)

• Przygotuj woluminy Docker dla logów i indeksu wyszukiwania.

• Upewnij się, że dostępny jest odwrotny serwer proxy do terminacji HTTPS.

Przygotowanie konfiguracji (values.yaml lub docker-compose.yml)​

Przygotuj konfigurację zmiennych środowiskowych:

• Dodaj ustawienia połączenia z bazą danych.

• Skonfiguruj porty robocze (aworker ports), zaufane hosty i parametry specyficzne dla środowiska – przenieś odpowiednie wartości z plików kopii zapasowej konfiguracji (takich jak server.conf i adoxx_web.properties).

• Dla Kubernetes: wprowadź wartości w values.yaml.

• Dla Docker: wprowadź wartości w docker-compose.yml.

Wdrozenie ADONIS 19​

Postępuj zgodnie z krokami dla wybranej platformy orkiestracji:

Kubernetes​

Wdróż ADONIS 19 do środowiska Kubernetes przy użyciu dostarczonego Helm chart i obrazów kontenerów OCI:

• Upewnij się, że ostateczny plik values.yaml jest dostępny do wdrożenia.

• Uruchom polecenie helm install, aby wdrożyć pakiet do wyznaczonej przestrzeni nazw.

• Helm chart wdroży kontenery serwera aplikacji i serwera WWW wraz ze wszystkimi wymaganymi zasobami Kubernetes (Services, Ingress itp.).

Docker Compose​

Wdróż ADONIS 19 do środowiska Docker przy użyciu dostarczonej konfiguracji Docker Compose:

• Upewnij się, że ostateczny plik docker-compose.yml jest dostępny w roboczym katalogu.

• Uruchom docker-compose up -d, aby pobrać obrazy OCI i zainicjować usługi.

Weryfikacja wdrozenia​

Po wdrożeniu ADONIS 19 sprawdź, czy środowisko działa poprawnie:

• Upewnij się, że wszystkie kontenery (pody Kubernetes lub usługi Docker) uruchomiły się pomyślnie.

• Przejdź pod adres URL ADONIS, aby potwierdzić, że aplikacja jest dostępna.

• Sprawdź logi za pośrednictwem woluminów trwałych lub logów kontenerów.

Zadania poinstalacyjne​

Po uruchomieniu ADONIS 19 wykonaj pozostałe zadania w Administracji ADONIS 19:

• Zaktualizuj bibliotekę aplikacji.

• Ponownie zaimportuj ustawienia komponentów wyeksportowane ze starego środowiska ADONIS 16.x/17.x.

• Jeśli aktualizujesz z ADONIS 16.x, uruchom skrypt migracji 17.0 - repo.js, aby dostosować zawartość repozytorium do nowej metody.

Kontrole końcowe​

Przeprowadź końcowe kontrole, aby upewnić się, że ADONIS 19 działa w pełni prawidłowo:

• Sprawdź, czy użytkownicy mają dostęp do ADONIS zgodnie z oczekiwaniami.

• Potwierdź, że zawartość repozytorium jest dostępna i wyświetla się poprawnie.

• Uruchom standardowe operacje (np. modelowanie, raportowanie, wyszukiwanie) w ADONIS, aby zweryfikować podstawową funkcjonalność.

• Opcjonalnie zintegruj wdrożenie z rozwiązaniem monitorującym.

Odinstalowanie ADONIS 16.x/17.x​

Po pełnym uruchomieniu ADONIS 19 stare środowisko ADONIS 16.x/17.x można usunąć:

• Odinstaluj serwer aplikacji ADONIS 16.x/17.x przez panel sterowania.

• Usuń aplikację webową ADONIS 16.x/17.x z Apache Tomcat.

Gotowe! Aktualizacja do ADONIS 19 jest zakończona.

Bezpieczeństwo​

Prawa dostępu i uprawnienia​

Obrazy kontenerów ADONIS nie wymagają uprawnień roota.

Wszystkie procesy wewnątrz kontenerów działają pod predefiniowanym użytkownikiem bez uprawnień roota (ADO).

Nie są wymagane żadne dodatkowe uprawnienia na poziomie hosta ani podwyższone uprawnienia Kubernetes.

Zasada minimalnego obrazu​

Obrazy kontenerów ADONIS stosują podejście distroless (minimalne obrazy bez pełnej dystrybucji systemowej).

Zbędne komponenty i narzędzia systemu operacyjnego są usuwane, co zmniejsza powierzchnię ataku i egzekwuje zasadę minimalizmu.

Zasoby klastra​

Wdrożenie ADONIS nie wymaga uprzywilejowanych kontenerów ani globalnych zasobów Kubernetes. W szczególności:

• brak trybu uprzywilejowanego

• brak NodePorts

• brak Kubernetes Operators

• brak uprawnień na poziomie całego klastra

Umożliwia to wdrożenie w restrykcyjnych klastrach korporacyjnych z rygorystycznymi politykami bezpieczeństwa.

Przestrzenie nazw i izolacja zasobów​

Wszystkie wymagane zasoby Kubernetes mogą być wdrożone i obsługiwane wyłącznie w jednej przestrzeni nazw.

Wspiera to izolację na poziomie przestrzeni nazw, kontrolę dostępu opartą na rolach (RBAC) i organizacyjne ramy bezpieczeństwa.

Uprawnienia do magazynowania​

Trwałe magazynowanie jest wymagane tylko dla określonych komponentów, takich jak indeks wyszukiwania pełnotekstowego i logi aplikacji.

Wymagane Persistent Volumes i Persistent Volume Claims są definiowane przez Helm chart i nie wymagają podwyższonych uprawnień klastra.

Dostęp jest ograniczony do kontenerów serwera aplikacji i serwera WWW ADONIS.

Operacje​

Skalowanie​

Horizontal Pod Autoscaling (HPA) nie jest obsługiwany w ADONIS 19.

Skalowanie odbywa się zatem przede wszystkim poprzez skalowanie pionowe, przez dostosowanie zasobów CPU i pamięci przypisanych do kontenerów aplikacji.

Dostarczone Helm charts obsługują wdrażanie wielu instancji serwera aplikacji. Podobnie jak w poprzednich wersjach ADONIS, uruchamianie dwóch lub więcej serwerów aplikacji jest obsługiwane i zalecane dla wysokiej dostępności.

Alokacja zasobów powinna być wymiarowana zgodnie z:

• oczekiwanym obciążeniem

• liczbą jednoczesnych użytkowników

• ogólnym poziomem użytkowania systemu

Logowanie i monitorowanie​

Logowanie​

Zarówno kontenery serwera WWW, jak i serwera aplikacji zapisują w logach informacje o zdarzeniach systemowych i błędach.

Aby umożliwić tworzenie Pakietu Informacji Wsparcia (Suppport Information Package - SIP) w ADONIS, pliki logów są zapisywane w trwałym magazynie. Dla tych logów wymagany jest dedykowany wolumin trwały.

SIP jest wymagany do wsparcia i rozwiązywania problemów.

Oprócz logowania opartego na plikach, ADONIS wyprowadza logi również przez standardowe strumienie logowania kontenerów (stdout/stderr).

Umożliwia to integrację z zewnętrznymi rozwiązaniami do logowania, takimi jak centralne zbieracze logów, platformy SIEM lub jeziora danych.

Przechowywanie i retencja logów​

Pliki logów są przechowywane na skonfigurowanym woluminie trwałym.

Retencja, rotacja i zachowanie rollover (przełączanie plików) mogą być konfigurowane poprzez ustawienia logowania.

Efektywny okres retencji zależy od:

• konfiguracji logowania

• infrastruktury klienta

• organizacyjnych polityk operacyjnych

Poziomy logowania​

ADONIS używa następujących poziomów logowania:

Poziomy logowania działają tak samo jak w poprzednich wersjach ADONIS opartych na Windows (ADONIS 17 i wcześniejsze).

Konfiguracja logowania​

Zachowanie logowania można konfigurować przy użyciu zmiennych środowiskowych dostarczanych przez:

• values.yaml (Kubernetes)

• docker-compose.yml (Docker)

Konfigurowalne parametry obejmują:

• poziom logowania

• maksymalny rozmiar pliku

• maksymalną historię

• całkowite limity rozmiaru logów

Szczegółowe informacje o dostępnych parametrach zostały opisane w sekcji konfiguracji.

Ochrona danych w logach​

Wrażliwe wartości i dane osobowe zapisywane w logach są pseudonimizowane w miarę możliwości.

Zachowanie to jest spójne z wcześniejszymi wersjami ADONIS.

Format wyjściowy logów​

Ogólna struktura danych wyjściowych logów pozostaje w dużej mierze spójna z poprzednimi wersjami.

Wprowadzono pewne korekty w celu poprawy spójności między różnymi typami logów.

Szczegółowy schemat zostanie zawarty w oficjalnej dokumentacji ADONIS 19.

Monitorowanie​

Monitorowanie logów​

ADONIS nie zapewnia wbudowanego stosu logowania.

Oczekuje się, że klienci zintegrują logi ADONIS z istniejącą infrastrukturą obserwowalności (observability) lub monitorowania.

ADONIS wspiera to przez:

• wyprowadzanie logów przez standardowe mechanizmy logowania kontenerów (stdout/stderr)

• kompatybilność z popularnymi agentami zbierania logów (np. Fluent Bit)

• przekazywanie logów do systemów takich jak OpenSearch, Elasticsearch lub podobnych platform

W środowiskach Kubernetes logi kontenerów są zazwyczaj przechowywane tymczasowo na węźle i zbierane przez komponent przetwarzający logi przed przekazaniem do centralnego systemu logowania organizacji.

Metryki i monitorowanie operacyjne można integrować z istniejącymi narzędziami, takimi jak Prometheus, Grafana lub inne korporacyjne platformy monitorowania.

Mechanizmy monitorowania​

ADONIS zapewnia wbudowane mechanizmy monitorowania dla kontroli stanu platformy.

Dostarczane obrazy kontenerów zawierają funkcjonalność używaną dla Kubernetes liveness i readiness probes.

Bardziej szczegółowe informacje zostaną dostarczone w oficjalnej dokumentacji ADONIS 19.

Licencjonowanie​

Istniejące licencje ADONIS pozostają ważne dla wszystkich aktualnych scenariuszy użytkowania.

Model wdrożenia – oparty na Windows lub na kontenerach – nie wpływa na obowiązujące warunki licencyjne.

Wsparcie i cykl życia​

Wprowadzenie skonteneryzowanego modelu wdrożenia nie zmienia istniejących zasad wsparcia ADONIS ani polityk cyklu życia produktu.

Wszystkie warunki wsparcia, usługi konserwacyjne i zasady cyklu życia nadal obowiązują tak samo jak w przypadku poprzednich wersji ADONIS.