Skip to main content

Installera och säkra plattformen

PDQ-plattformen driftsätts som en modulär uppsättning Docker-containrar, med en strikt definierad startsekvens och centraliserad metadatakontroll via Active Metadata Engine (AME). Det finns ingen PDQ-specifik runtime under: allt som kan köra containrar kan köra plattformen.

De centrala verktygen som driftsätts är AME, INGEST, DLS och DWA, tillsammans med Config UI och Caddy.

Var varje komponent hör hemma​

Driftsättningen handlar om effektivitet och decentralisering där det lönar sig:

  • INGEST-agenter placeras helst nära datakällan — lokalt eller i ett separat moln — för att minimera dataöverföringen.
  • DWA placeras helst i samma region som måldatabasen.
  • AME och DLS körs så nära varandra som möjligt, i samma region som repository-databasen.

Förutsättningar och infrastruktur​

Systemkrav​

MinimumRekommenderat
Docker Engine20.10+24.0+
RAM8 GB16 GB
CPU4 kärnor8 kärnor
Lagring100 GB500 GB
DatabasDeladDedikerad instans (SQL Server, PostgreSQL eller annan motor som stöds)

Verifiera värden innan du börjar:

docker --version
docker compose version

VM och grundberoenden​

Driftsättningen börjar normalt på en VM — en EC2-instans med Ubuntu 22.04 är referensplattformen — förberedd så här:

  1. Diskuppsättning: Skapa och montera en extra disk (till exempel /datadrive), med mklabel gpt och mkfs.xfs. Disken används som Dockers data root.
  2. Docker-installation: Installera Docker-motorn, CLI:t, containerd.io och de plugins som krävs.
  3. Data root och loggning: Redigera eller skapa /etc/docker/daemon.json för att definiera data root ("data-root": "/datadrive/docker") och konfigurera roterande loggar ("max-size": "10m", "max-file": "3").

Tjänsteorkestrering och startordning​

Komponenterna hanteras av systemd-tjänstefiler som upprätthåller en strikt, linjär beroendekedja via Requires= och After=, så att en tjänst startar bara om den föregående lyckades.

Startordningen som krävs är:

  1. simplitics-ui.service (bastjänst, kräver bara Docker)
  2. simplitics-ame.service (Active Metadata Engine — startar efter UI)
  3. simplitics-dls.service (Data Lake Service — startar efter AME)
  4. simplitics-dwa.service (Data Warehouse Automation — startar efter DLS)
  5. simplitics-ingest.service (Data Importer — startar efter DWA)

För att starta hela stacken: aktivera och starta bara den sista tjänsten i kedjan (simplitics-ingest.service).

1. Active Metadata Engine (AME)​

  • Säkerhetsisolering: Ingen komponent får publicera en mappad port. Ta bort varje portmappning ur Compose-filerna — ame-compose.yml inräknad — så att alla tjänster ligger på det interna Docker-nätverket och bara Caddy är exponerad. Se Nätverksexponering nedan.
  • API-kommunikation: AME är det centrala API-navet och serverar all konfiguration och alla instruktioner till INGEST, DLS och DWA.

2. INGEST (Data Importer)​

  • Driftsättningsmodell: INGEST körs som en container, en per källanslutning, och fungerar som en agent som kan placeras var som helst — den behöver bara en API-anslutning tillbaka till AME.
  • Containerstart: Startas med källsystemets namn som körtidsparameter, till exempel command: -n <SOURCESYSTEMNAME> -f teams.yaml.
  • Teams/API-integration: Kräver en Azure AD-appregistrering, klienthemligheter och att AME-anslutningen konfigureras via /api/v3/ingest/connection/for/:sourceSystem med APIAuthMethod satt till "OAuth 2.0".
SFTP-värdnycklar verifieras inte

En SFTP-källa i INGEST accepterar automatiskt den värdnyckel servern presenterar, så serverns identitet kontrolleras inte. Begränsa nätverksvägen till SFTP-värden, och lita inte på transporten ensam för att avgöra vilken maskin som svarade. Se Arbeta med Ingest.

3. DLS (Data Lake Service)​

  • Containerskalning: DLS körs som flera containrar — minst sex — med workers som skalar med tillgänglig kapacitet.
  • Funktionalitetsdriftsättning: Konfiguration (filstruktur, rawZonePath, targetMethod) driftsätts via API-anrop till AME på /api/v3.2/sourcefiles/:sourceFilename.
  • Streaming-konfiguration: Högpresterande streaming för stora XML/JSON-filer aktiveras genom att sätta useForSplittingRecords till 1 på en hierarkinivå, via en backend-uppdatering.

4. DWA (Data Warehouse Automation)​

  • Placering: DWA körs som flera containrar — minst fyra — helst i samma region som måldatabasen.
  • Konfiguration: Vilar på tre metadatainmatningar, som skickas via API:et eller Config UI:
    1. Målmodelldefinitioner (objekt, nycklar, relationer)
    2. Källbeskrivning (från DLS)
    3. Käll-till-mål-mappningar (LOGIC), inklusive attribut och filtrering
  • Orkestrering: DWA använder API:er för att beskriva källan, skapa ett körtidsschema och logga förloppet.

Konfiguration efter installation​

När stacken kör, öppna Settings i Config UI och sätt de installationsomfattande värdena innan den första laddningen:

  • Installation name och Data platform — målmotorn som SQL-generatorn skriver för (Snowflake, Databricks, SQL Server, Synapse, Fabric eller PostgreSQL).
  • Compute warehouse / workspace — den beräkningsresurs plattformen kör mot.
  • Global naming conventions — kolumnprefix, skiftläge för tabellnamn, mellanrum i tabellnamn och suffix för objektnyckel. Dessa tillämpas av SQL-generatorn på varje genererat objekt, så sätt dem innan du genererar måltabeller.
  • Verified file encodings — de kodningar DLS accepterar för inkommande källfiler.

Settings, General i PDQ: installation och plattform, beräkningsresurser, globala namnkonventioner och verifierade filkodningar

Dashboard bekräftar att stacken är igång och nåbar: den räknar konfigurerade system, källfiler, fält, mappningar och modeller, och ritar flödet från ände till ände över INGEST, DLS och DWA.

PDQ dashboard: sammanfattningsrutor ovanför plattformsflödet från ände till ände

Säkerhet och åtkomst​

Caddy ligger framför plattformen och hanterar TLS-terminering, API-åtkomst och inloggningsflödet.

Nätverksexponering​

Endast port 443 är öppen, och bara på Caddy. Ingen annan port är exponerad, på någon komponent.

  1. DNS: PDQ-maskinen måste använda ett Fully Qualified Domain Name (FQDN).
  2. Brandvägg: Port 443 måste vara tillgänglig på servern, men endast inifrån kundens miljö — inte offentligt.
  3. Nätverk: Skapa ett nytt Docker-nätverk, till exempel xx_caddynet.
  4. Portmappningar: Varje mappad port måste tas bort ur varje komponents Compose-fil. Komponenterna pratar med varandra över det interna Docker-nätverket; ingenting utom Caddy svarar utifrån.

Entra (Azure AD)-autentisering​

  1. Appregistrering — skapa en appregistrering (till exempel sp-pdq-caddy-demo) med en Redirect URI som bär FQDN och HTTPS-port: https://{dns_name}:{port}/auth/oauth2/azure/authorization-code-callback.
  2. Gruppanspråk — definiera tre Entra-grupper (pdq_web_admins, pdq_web_developers, pdq_web_viewers) och uppdatera tokenkonfigurationen så att användarens tilldelade grupper skickas med som ett gruppanspråk.
  3. Behörigheter — ge administratörsmedgivande för User.Read och GroupMember.Read.All.

Rollmappning​

Installatören mappar rollerna vid installationen, genom att sätta GUID:t för Entra-gruppen som värde på varje intern grupp — authp/admin och authp/user.

Rollerna sträcker sig över två gränssnitt, vilket konsolens egen rolltabell inte framgår av på egen hand:

RollConfig UIDataOps-konsolen
adminSkrivAllt, inklusive omstart, hoppa över, trigga och redigera
developerSkrivEndast läsa — inga admin-åtgärder
readerIngen skrivrättEndast läsa

En developer har alltså full skrivrätt där plattformen konfigureras, och ingen möjlighet att ingripa i en pågående laddning. En reader kan inte skriva någonstans.

Underhåll och uppgraderingar​

  • Allmän felsökning: Den vanliga lösningen för infrastrukturproblem, som en VM-krasch, är att stoppa och starta den virtuella maskinen från molnportalen.
  • Container-omstart: Om problemen kvarstår, gå till /datadrive/configs och kör docker compose down följt av docker compose up -d för alla komponenter (AME, UI, DLS, DWA, INGEST, TOOLS).
  • Uppgraderingar: Stoppa alla Docker-tjänster först. Uppdatera komponenternas Compose-filer att peka på image-taggen för den version du uppgraderar till — produktversionen, till exempel 3.2. Datumbaserade nummer som 25.6.1 är inte produktversioner. Utför sedan en manuell pull för att hämta de nya imagesen.

Hemligheter efter en uppgradering​

Öppna varje anslutning efter en uppgradering och spara den på nytt.

En lagrad hemlighet återanvänds aldrig, så lösenord, nycklar och eventuell client_secret måste anges på nytt vid varje sparning — se Credentials. Det finns ingen omkrypteringsrutin, och det finns ingenting att återställa: hemligheter lagras aldrig okrypterat.

Hämta inte en anslutning med GET och posta tillbaka den

Att hämta en anslutning och posta tillbaka den krypterar inte om den. Den krypterar det redan krypterade värdet en gång till och lämnar en fungerande anslutning obrukbar.

En nedladdad Show JSON-förhandsvisning innehåller en levande hemlighet

Show JSON-förhandsvisningen renderar anslutningen som den kommer att skickas, hemligheter inkluderade. Behandla en nedladdad kopia som en autentiseringsuppgift.