Skip to main content

Installera komponenterna

Driftsättningen av Simplitics PDQ-plattform hanteras genom en modulär, containerbaserad arkitektur som säkerställer hög flexibilitet över olika miljöer. Den innehåller en strikt definierad startsekvens och centraliserad metadatakontroll via Active Metadata Engine (AME).

De centrala verktygen som driftsätts är AME, INGEST, DLS och DWA, tillsammans med stödjande komponenter som Developer UI och Caddyserver.

Förutsättningar för Driftsättning och Infrastrukturinställning​

PDQ-plattformens komponenter driftsätts som Docker-containers och kan köras på vilken containerbaserad miljö som helst, inklusive vilken molnleverantör eller lokal installation som helst.

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 databas som stöds)

Kontrollera värden innan du börjar:

docker --version
docker compose version

VM och Kärnberoenden​

Driftsättning börjar vanligtvis på en VM (t.ex. EC2 Ubuntu 22.04) förberedd med följande konfiguration:

  1. Diskinställning: En extra disk (t.ex. /datadrive) måste skapas och monteras (t.ex. med mklabel gpt och mkfs.xfs). Denna disk används för Docker data root.
  2. Docker-konfiguration: Docker engine, CLI och plugins måste installeras. Filen /etc/docker/daemon.json måste redigeras för att definiera data root ("data-root": "/datadrive/docker") och konfigurera roterande loggar ("max-size": "10m", "max-file": "3").
  3. Komponentplaceringsstrategi:
    • AME och DLS: Kör nära varandra i samma region som repository-databasen.
    • DWA: Helst i samma region som databasen.
    • INGEST-agenter: Helst distribuerade nära datakällan för att minimera nätverksdataöverföring.

Driftsättning av Centrala PDQ-verktyg (Tjänsteorkestrering)​

Komponenterna hanteras av systemd servicefiler som upprätthåller en strikt, linjär beroendekedja med hjälp av Requires= och After= direktiv.

Korrekt Sekventiell Startordning:​

  1. simplitics-ui.service (Bastjänst, kräver endast 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 behöver installatören endast aktivera och starta den sista tjänsten i kedjan (simplitics-ingest.service).

1. Active Metadata Engine (AME) Driftsättning​

  • Säkerhetsisolering: Alla mappade portar i ame-compose.yml filen måste tas bort. AME-tjänster måste isoleras till det interna Docker-nätverket för att förhindra extern åtkomst.
  • API-kommunikation: AME är den centrala API-hubben som tillhandahåller all konfiguration och instruktioner till INGEST, DLS och DWA.

2. INGEST (Data Importer) Driftsättning​

  • Driftsättningsmodell: INGEST körs som en container (en per källanslutning) och fungerar som en agent som kan driftsättas var som helst, behöver endast en API-anslutning tillbaka till AME.
  • Container-start: Initieras med källsystemnamnet som en runtime-parameter (t.ex. command: -n <SOURCESYSTEMNAME> -f teams.yaml).
  • Teams/API-integration: Kräver Azure AD App-registrering, klienthemligheter och konfigurering av AME-anslutningen via API-endpoint /api/v3/ingest/connection/for/:sourcesystem med APIAuthMethod satt till "OAuth 2.0".

3. DLS (Data Lake Service) Driftsättning​

  • Container-skalning: DLS körs som flera containers (minimum 6) som använder workers som kan skala baserat på virtuell kapacitet.
  • Funktionalitetsdriftsättning: Konfigurationsdetaljer (filstruktur, rawZonePath, targetMethod) driftsätts via API-anrop till AME med endpoint /api/v3.1/sourcefiles/:sourceFilename.
  • Streaming-konfiguration: Högpresterande streaming för stora XML/JSON-filer aktiveras genom att sätta useForSplittingRecords till 1 på en specifik hierarkinivå via en backend-API-uppdatering.

4. DWA (Data Warehouse Automation) Driftsättning​

  • Driftsättningsplats: DWA körs som flera containers (minimum 4) och bör helst vara i samma region som databasen.
  • Konfigurationsdriftsättning: Förlitar sig på tre huvudsakliga metadata-inputs, skickade via API/DevUI:
    1. Target Model-definitioner (objekt, nycklar, relationer).
    2. Källbeskrivning (från DLS).
    3. Källa-till-Mål Mappningar (LOGIC), inklusive attribut och filtrering.
  • Orkestrering: DWA använder API:er för att beskriva källan, skapa ett runtime-schema och logga framsteg.

Konfiguration efter installation​

När stacken kör, öppna Settings i Developer 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äkerhets- och Åtkomstdriftsättning (Caddyserver)​

Implementeringen av Caddyserver kräver specifik nätverks- och säkerhetskonfiguration:

  1. DNS-krav: PDQ-maskinen måste använda ett Fully Qualified Domain Name (FQDN).
  2. Brandväggsöppning: Portarna 80 och 443 måste vara tillgängliga på servern, men endast inifrån kundens miljö (inte offentligt tillgängliga).
  3. Nytt nätverk: Ett nytt Docker-nätverk (t.ex. xx_caddynet) måste skapas.
  4. Entra (Azure AD) Autentisering: Kräver:
    • App-registrering (t.ex. sp-pdq-caddy-demo) med en Redirect URI som inkluderar FQDN och HTTPS-port (t.ex. https://{dns_name}:{port}/auth/oauth2/azure/authorization-code-callback).
    • Definiera Entra-grupper (pdq_web_admins, pdq_web_developers, pdq_web_viewers) och uppdatera App-registreringen för att inkludera ett gruppanspråk för att hämta användarbehörigheter.

Underhålls- och Uppgraderingsrutiner​

  • Allmän felsökning: Den vanliga lösningen för infrastrukturproblem (t.ex. VM-krasch) är att stoppa och starta den virtuella maskinen från molnportalen.
  • Container-omstart: Om problemen kvarstår, 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. Uppdatera Compose-filerna för att referera till den nya release-taggen (t.ex. Xx:release_v25.6.1), och utför en manuell pull för att hämta de nya imagesen.
  • Återkryptering av hemligheter: Efter en uppgradering som involverar krypterade hemligheter, utför en GET-förfrågan för att hämta den okrypterade konfigurationen och skicka omedelbart POST svaret tillbaka till AME API-endpointen (t.ex. /api/v3/ingest/connection/for/{sourcesystem}) för att utlösa krypteringsprocessen.

Driftsättning som en Digital Fabriksproduktionslinje: Att driftsätta PDQ är som att sätta upp en komplex, självhanterande digital fabrik. AME fungerar som ritningsarkiv och centrala kommandocentral, definierar varje maskins syfte via API:er. Varje arbetare (INGEST, DLS, DWA) är en specialiserad containeriserad enhet, startad i en strikt, linjär sekvens (produktionslinjens uppstart) för att förhindra kaos. Användningen av containers säkerställer att fabriksgolvet kan installeras var som helst (vilket moln som helst). Caddyserver fungerar som den säkra portvakten, säkerställer att endast autentiserad personal (Entra ID-användare) kan komma åt kommandocentralen och interna system, skyddar hela operationen från extern störning.