Konfigurace aplikace

[mduda100871]

Zdravím,

mám otázku ohledně konfigurace API.

V dokumentaci/návodu na instalaci je uvedeno, že konfigurace se nachází v souboru application.conf a tento soubor aplikace předpokládá na relativní cestě v podadresáři ~/.altoEditorApp v domácím adresáři uživatele pod kterým aplikace běží.

Je možné přetěžovat jednotlivé konfigurační property ve více konfiguračních souborech, tzn. vlastně něco jako merge konfigurací z různých fragmentů konfiguračních souborů budˇ na definovaných cestách, nebo předaných jako parametr JVM? Něco co lze dělat třeba ve Springu?

Nebo musím i při minimální změně (třeba jen jedna hodnota u nějaké property) aplikaci předhodit kompletní (byť jen třeba v minimalistické verzi) konfiguraci v jednom souboru pokaždé na stejné cestě?

Jde mi i o to, že konfigurace umožňuje vytvářet dopředu neznámé množství obsluhovaných instancí K7, což celkem komplikuje např. vytváření konfigurace když aplikaci chci uzavřít do kontejneru a spustit jako pod.

Pak chci totiž v docker-compose.yml ovládat konfiguraci prostřednictvím proměnných prostředí, takže si vytvářím interní šablonu konfigurace, kde hodnoty jednotlivých propert jsou nahrazené proměnnými prostředí (které jsou pak expandovány).

Tyto proměnné prostředí mají nastavené nějaké defaultní hodnoty v Dockerfile, a jsou zakomponovány při sestavení obrazu. Následně pak jejich konkrétní hodnotu nastavím v docker-compose.yml, jak jsem uvedl výše, podle reálného nasazení do produkce.

A nechce se mi moc mountovat tu konfiguraci jako volume, pokud bych měl možnost to plně ovládat pomocí proměnných prostředí a jejich expanzí v konfigurační šabloně. Ale pokud to jinak nepůjde...

Případně bych asi problém počtu obsluhovaných instancí K7 řešil dynamickou změnou konfigurace v docker-entrypoint.sh ještě před spuštěním samotné aplikace v kontejneru.

MD

[mduda100871]

Ještě upřesnění ke konfiguraci zanoření:

application.(objectStore|dataStreamStore).pattern=xx

je pro jednoúrovňové zanoření.

Nicméně naše repozitáře mají dvě úrovně zanoření, takže předpokládám, že (analogicky, jako to má akubra) nastavení bude vypadat takto:

application.(objectStore|dataStreamStore).pattern=xx|xx

Je můj předpoklad správný?

MD

[mduda100871]

Oprava předchozího dotazu - oddělovač zanoření není |, ale /.

Takže application.(objectStore|dataStreamStore).pattern=xx/xx.

[mduda100871]

Tak už nad tím sedím kolik hodin a nejsem prostě schopen donutit aplikaci něco smysluplného dělat/fungovat.

Co funguje:

• jádro běží, načte konfigurace minimálně co se týká databáze (vidím aktivní konexe proti postgresu, inicializaci databáze jsem udělal),
• jsem schopen se přihlásit proti keycloaku z klienta, dostanu role (vidím je v konzoli prohlížeče).

A tím to asi končí.

Naprosto mi uniká, co mám jako uživatel nebo kurátor (obě role mám přidělené a nakonfigurované v konfiguraci jádra) v rozhraní dělat, jak vybrat nějaké dokumenty k editaci atd. - prostě s tím nelze nic dělat.

Mimochodem, musí se přidělené role spojit s nějakou akcí v samotném jádru příslušné instance K7? Nikde jsem o tom nenašel žádnou zmínku, ale tak nějak předpokládám, že jádro K7 musí editor na základě role nějak autorizovat k nějaké akci...nebo ne?

Když sleduji konzoli prohlížeče, tak to na mě působí tak, že jádro editoru naprosto ignoruje nastavení příslušné instance Krameria u které chci alto editovat.

Očesal jsem konfiguraci na naprosté minimum, nic nepomáhá.

Co PŘESNĚ má být např. za hodnotu v proměnné application.keycloak.url= v případě, že keycloak běží na jiném url (bez auth/) než jádro příslušné instance K7, kde chci editovat?

Zjistil jsem totiž, že když v této propertě je url opravdu keycloaku (v našem případě je jiné, než je jádro K7, což je logická a žádoucí situace), tak jádro editoru vrací status 401, protože podle všeho pospojuje url keycloaku s hodnotou z property application.keycloak.userInfoUrl="/search/api/client/v7.0/user", která ale samozřejmě neexistuje, takže jádro editoru nedostane žádné informace (např. ty přidělené role) o uživateli a na konzoli vyhazuje chybovou hlášku.

Když do property application.keycloak.url= naopak uložím url jádra K7, tak to začne fungovat. Takže minimálně ve jménech těch proměnných je nějaký zavádějící chaos.

Tady je moje aktuální konfigurace jádra editoru se kterou jsem schopen se přihlásit (není tam to url keycloaku, ale jádra K7 jak jsem popisoval výše), jádro editoru si nestěžuje, že nemá autorizační atributy, ale tím jakákoliv další použitelnost končí:

application {
    version=1.5
    jdbc {
        url="jdbc:postgresql://10.118.0.89:5432/altodb"
        username=altoEditor
        password=XXX
    }
    permission {
        editor = roleAdm_AltoEditor_Editor
        curator = roleAdm_AltoEditor_Curator
    }
    keycloak {
        url = "https://kramerius-test.lib.cas.cz"
    }
    objectStore {
        pattern = xx/xx/xx
        path = /srv/akubra-data/objectStore
    }
    dataStreamStore {
        pattern = xx/xx/xx
        path = /srv/akubra-data/datastreamStore
    }
}

krameriusInstances=k7
krameriusInstance {
    k7 {
        title=K7
        type=prod
        url="https://kramerius-test.lib.cas.cz"
    }
}

processor {
    pero {
        exec="python3"
        arg="/opt/python/Pero/pero-ocr.py"
        key=XXX
    }
}

Náš keycloak ale sedí na jiném url (kramerius-test-login.lib.cas.cz), takže správně by konfigurace dle logiky názvů těch konfiguračních proměnných měla vypadat takto:

application {
    version=1.5
    jdbc {
        url="jdbc:postgresql://10.118.0.89:5432/altodb"
        username=altoEditor
        password=XXX
    }
    permission {
        editor = roleAdm_AltoEditor_Editor
        curator = roleAdm_AltoEditor_Curator
    }
    keycloak {
        url = "https://kramerius-test-login.lib.cas.cz"
    }
    objectStore {
        pattern = xx/xx/xx
        path = /srv/akubra-data/objectStore
    }
    dataStreamStore {
        pattern = xx/xx/xx
        path = /srv/akubra-data/datastreamStore
    }
}

krameriusInstances=k7
krameriusInstance {
    k7 {
        title=K7
        type=prod
        url="https://kramerius-test.lib.cas.cz"
    }
}

processor {
    pero {
        exec="python3"
        arg="/opt/python/Pero/pero-ocr.py"
        key=XXX
    }
}

Ale to je nefunkční.

Konfigurace klienta je pak tato:

{
  "login": "KNAV",
  "instance": "k7",
  "defaultLang": "cs",
  "deployPath": "",
  "clientBaseUrl": "https://kramerius-test-alto-editor.lib.cas.cz/api",
  "authBaseUrl": "https://kramerius-test.lib.cas.cz/search/api/client/v7.0",
  "keycloak": {
                "loginType": "form",
                "logoutUrl": "/login"
  }

}

Zde bych např. čekal, že proměnná authBaseUrl bude url kde sedí keycloak, ale to je zase v rozporu s tou pokračující cestou, protože to vede na jádro K7. Jak je to tedy správně?

V dokumentaci mi například naprosto chybí popis toho, jak se vlastně klient ovládá, jak začít, co ověřit, jak načíst nějaká data k práci atd.

Jsem totálně v koncích a dost zoufalý. A to si dovolím tvrdit, že jsem dost ostřílený z instalací K7 a Keycloku, ale toto je opravdu tragédie, i po stránce dokumentace, je mi líto :/

Prosím o nějakou reakci, případně navrhuji online setkání s demonstrací, protože sepisování tady je poměrně neefektivní v této situaci.

MD

[mduda100871]

Další otázka. Je možné nastavit v konfiguraci alto klienta název aplikačního klienta pod kterým se přistupuje ke keycloaku?

Defaultně to používá krameriusClient, ale u naší ostré instance K7 se klient jmenuje např. KrameriusClient - obecně se ale klient může jmenovat teoreticky jakkoliv, takže pokud je jméno klienta natvrdo zadrátované v kódu, je to špatné....

[SykoraLukas]

untovat tu konfi

Zdravím,

mám otázku ohledně konfigurace API.

V dokumentaci/návodu na instalaci je uvedeno, že konfigurace se nachází v souboru application.conf a tento soubor aplikace předpokládá na relativní cestě v podadresáři ~/.altoEditorApp v domácím adresáři uživatele pod kterým aplikace běží.

Je možné přetěžovat jednotlivé konfigurační property ve více konfiguračních souborech, tzn. vlastně něco jako merge konfigurací z různých fragmentů konfiguračních souborů budˇ na definovaných cestách, nebo předaných jako parametr JVM? Něco co lze dělat třeba ve Springu?

Nebo musím i při minimální změně (třeba jen jedna hodnota u nějaké property) aplikaci předhodit kompletní (byť jen třeba v minimalistické verzi) konfiguraci v jednom souboru pokaždé na stejné cestě?

Jde mi i o to, že konfigurace umožňuje vytvářet dopředu neznámé množství obsluhovaných instancí K7, což celkem komplikuje např. vytváření konfigurace když aplikaci chci uzavřít do kontejneru a spustit jako pod.

Pak chci totiž v docker-compose.yml ovládat konfiguraci prostřednictvím proměnných prostředí, takže si vytvářím interní šablonu konfigurace, kde hodnoty jednotlivých propert jsou nahrazené proměnnými prostředí (které jsou pak expandovány).

Tyto proměnné prostředí mají nastavené nějaké defaultní hodnoty v Dockerfile, a jsou zakomponovány při sestavení obrazu. Následně pak jejich konkrétní hodnotu nastavím v docker-compose.yml, jak jsem uvedl výše, podle reálného nasazení do produkce.

A nechce se mi moc mountovat tu konfiguraci jako volume, pokud bych měl možnost to plně ovládat pomocí proměnných prostředí a jejich expanzí v konfigurační šabloně. Ale pokud to jinak nepůjde...

Případně bych asi problém počtu obsluhovaných instancí K7 řešil dynamickou změnou konfigurace v docker-entrypoint.sh ještě před spuštěním samotné aplikace v kontejneru.

MD

Dobrý den, v aplikaci je vše sloučené do jednoho konfiguračního souboru jako to má aplikace ProArc. Načítání instancí Krameria je řešeno dynamicky, tedy kvůli změně s nemusí restartovat aplikace. Pokud aplikaci zabalíte do dockeru, je potřeba vytáhnout config, ale lépe celou složky .altoEditorApp jako volume mimo docker, právě kvůli možnosti editace souboru.

[SykoraLukas]

Oprava předchozího dotazu - oddělovač zanoření není |, ale /.

Takže application.(objectStore|dataStreamStore).pattern=xx/xx.

Ano, funguje tato varianta. Jenom upozorním, že aplikace má svůj objectStore objektů, nepoužívá objectStore Krameria. Data se do AltoEditoru posílají z Kramerius Admin klienta a AltoEditor si stahuje a ukládá jen věci, které potřebuje.

Důvodem je, že Alto Editor verzuje datastream Alto, ale v Krameriovi je vždy jen jedna aktuální verze. Proto má Alto Editor svůj storage objektů.

[mduda100871]

Ano, funguje tato varianta. Jenom upozorním, že aplikace má svůj objectStore objektů, nepoužívá objectStore Krameria. Data se do AltoEditoru posílají z Kramerius Admin klienta a AltoEditor si stahuje a ukládá jen věci, které potřebuje.

Aha, no to by ale opravdu chtělo zmínit v dokumentaci (Nebo to tam někde je? Já to nenašel...), minimálně tedy u popisu jednotlivých konfiguračních parametrů. Takto je to zavádějící, protože když chci pracovat s daty Krameria, pak logický předpoklad vede k tomu, že se to musí napojit na repozitář Krameria - což byl i můj předpoklad, tedy chybný, ale díky tomu, že jsem neměl k dispozici vysvětlující popis.

[SykoraLukas]

Omlouvám se, doplním to tam. K ostatním komentářům se budu dnes postupně vyjadřovat a doplňovat do konfigurace (kde bude nutné).

[mduda100871]

Data se do AltoEditoru posílají z Kramerius Admin klienta a AltoEditor si stahuje a ukládá jen věci, které potřebuje.

A jak přesně se to z admin klienta posílá do AltoEditoru? Musí se někde v jádře K7 nastavit nějaká properta, která tuto funkčnost aktivuje? nebo nějak jinak?

[SykoraLukas]

Mělo by to být obdobné jako pro ProArc viz https://github.com/ceskaexpedice/kramerius-admin-client/wiki/Instalace-a-konfigurace#p%C5%99%C3%ADklad-konfigurace. Už jsem psal @pavel-stastny, aby to do dokumentace doplnili (Toto řešil on s @pkudela).

V K7 Admin klientovi se z úrovně strany aktivuje možnost Editace objektu v aplikaci AltoEditor

[mduda100871]

Hmm, tak nevím co je ještě špatně, nicméně i po přidání konfigurace do konfiguračního souboru admin klienta, nevidím možnost editovat v alto editoru:

Je podmínkou tam mít i tu sekci pro proarc? To by ale nedávalo žadný smysl...

[SykoraLukas]

@pavel-stastny můžeš se na to podívat?

[mduda100871]

Tak už to snad ožilo, nakonec se můj dohad o potřebnosti sekce pro proarc ukázal jako správný - dnes mi to @pavel-stastny potvrdil.

Když jsem to do konfigurace admin klienta doplnil, tak už vidím položku [Editovat] v nabídce.

Dokonce se mi tedy už podařilo načíst i data do editoru a uložit:

Tak teď to celé nějak ustabilizuji a budeme u nás testovat dál...

MD

[SykoraLukas]

Díky za info. Připravuji novou verzi, která bude řešit ten zmatek v klíčích keycloaku a bude nový endpoint, který bude ukazovat, zda je vše správně nakonfigurováno a AltoEditor má připojen všechny potřebné komponenty.

[mduda100871]

Jen mi tedy není jasná jedna věc. Abych mohl editovat tu textovou vrstvu, musím to celé vyvolat z admin klienta. Znamená to tedy, že privilegovaní uživatelé, kteří budou externě dělat opravy, budou muset mít přístup do admin klienta prakticky odkudkoliv z internetu?

Pokud ano, mám s tím velký problém...