Arhitektuur

Seega: rdc käib sinu tööjaamal, renet serveritel ja nad suhtlevad SSH-ühenduse kaudu. Rediacc kogu arhitektuur toetub sellele jagamisele. See leht käsitleb, kuidas kaks tööriista jagavad vastutust, kuidas adapteri tuvastamine suunab olekut, kuidas turvamudel välja näeb ja kuidas konfiguratsioon on struktureeritud.

Täispinu ülevaade

Liiklus voolab internetist läbi pöördproksi isoleeritud Dockeri daemonitesse, millest igaüks on tagatud krüpteeritud salvestusega:

Täispinu arhitektuur

Iga repositoorium saab oma Dockeri daemoni, loopback-IP-alamvõrgu (/26 = 64 IP-d) ja LUKS-krüpteeritud BTRFS-köite. Marsruudi server avastab töötavad konteinerid kõigist daemonitest ja edastab marsruutimiskonfiguratsiooni Traefik’ile.

Kahe tööriista arhitektuur

Rediacc kasutab kaht binaari, mis töötavad koos SSH kaudu:

Kahe tööriista arhitektuur

rdc töötab sinu tööjaamal (macOS, Linux või Windows). See loeb sinu kohalikku konfiguratsiooni, ühendub kaugmasinatega SSH kaudu ja kutsub välja renet’i käsud.
renet töötab kaugserveris root-õigustega. See haldab LUKS-krüpteeritud kettapilte, isoleeritud Dockeri daemaneid, teenuste orkestreerimist ja pöördproksi konfiguratsiooni.

Iga käsk, mille sa kohalikult kirjutad, tõlgitakse SSH-kutseks, mis täidab renet’i kaugmasinas. Sul pole kunagi vaja käsitsi SSH kaudu serveritesse sisse logida.

Operaatorikeskseks rusikareeglitest vaata rdc vs renet. Samuti saad kasutada rdc ops kohaliku VM-klastri käivitamiseks testimiseks, vaata Eksperimentaalsed VM-id.

Konfiguratsioon

Kogu CLI olek salvestatakse ~/.config/rediacc/ alla tasasel JSON-konfiguratsioonifailides.

Kogu olek elab tööjaamal konfiguratsioonifailis (nt ~/.config/rediacc/rediacc.json).

Otsesed SSH-ühendused masinatega
Väliseid teenuseid ei nõuta
Vaikimisi konfiguratsioon luuakse automaatselt CLI esimesel kasutamisel. Nimetatud konfiguratsioonid luuakse käsuga rdc config init <name>
Valikuline krüpteeritud konfiguratsiooni sünkroonimine salvestab sama faili konfiguratsioonisalves, meeskonnapõhiselt piiritletuna

Kasutaja rediacc

Kui käivitad rdc machine setup, loob renet kaugserverisse süsteemikasutaja nimega rediacc:

UID: 7111
Shell: /sbin/nologin (ei saa SSH kaudu sisse logida)
Eesmärk: Omab repositooriumi faile ja käivitab Rediaccfile’i funktsioone

Kasutajale rediacc ei pääse otse SSH kaudu ligi. Selle asemel ühendub rdc SSH-kasutajana, mille sa seadistad (nt deploy), ja renet täidab repositooriumi toiminguid käsuga sudo -u rediacc /bin/sh -c '...'. See tähendab:

Sinu SSH-kasutajal on vaja sudo õigusi
Kõik repositooriumi andmed kuuluvad kasutajale rediacc, mitte sinu SSH-kasutajale
Rediaccfile’i funktsioonid (up(), down()) käivitatakse kasutajana rediacc

See eraldamine tagab, et repositooriumi andmetel on ühtne omandiõigus olenemata sellest, milline SSH-kasutaja seda haldab.

Dockeri isoleerimine

Iga repositoorium saab oma isoleeritud Dockeri daemoni. Kui repositoorium ühendatakse, käivitab renet pühendatud dockerd protsessi unikaalse pistikupesaga:

Dockeri isoleerimine

/var/run/rediacc/docker-{networkId}.sock

Näiteks repositoorium, mille võrgu ID on 2816, kasutab:

/var/run/rediacc/docker-2816.sock

See tähendab:

Erinevate repositooriumide konteinerid ei näe üksteist
Igal repositooriumil on oma pildivahemälu, võrgud ja köited
Hosti Dockeri daemon (kui see on olemas) on täielikult eraldatud

Rediaccfile’i funktsioonidel on automaatselt DOCKER_HOST seatud õigele pistikupesale.

Kui AI agent siseneb repositooriumisse käsuga rdc term connect <repo>, kehtib sama isoleerimine: seanss töötab väheste õigustega kasutajana rediacc (UID 7111), eraldiseisvas ühenduspunkt-nimeruumis, kusjuures DOCKER_HOST on piiratud selle ühe repo daemoni pistikupesaga. Fork-esmane töövoog ühendab selle käitusaegse isoleerimise CoW-kloonimise primitiiviga: agent tegutseb ülesandekohase fork’i peal, mitte grand (tootmis) repositooriumides. Täieliku liivakastimudeli, ülekatte semantika ja arendaja vastutuse piiri väliste teenuste volituste osas vaata AI agendi ohutus ja turvamehhanismid.

Daemoni teekava paigutus

Dockeri andmed ja konfiguratsioon salvestatakse repositooriumi ühenduspunkti sisse, hoides iga daemoni täielikult isoleerituna hostist ja teistest repositooriumidest.

Repo-kohane paigutus:

{datastore}/mounts/{guid}/.rediacc/docker/data/    # Dockeri andmejuur
{datastore}/mounts/{guid}/.rediacc/docker/config/  # Dockeri konfiguratsioon

Iseseisev paigutus (daemonid, mis pole repositooriumi ühenduspunktiga seotud):

{datastore}/standalone/{N}/.rediacc/docker/data/
{datastore}/standalone/{N}/.rediacc/docker/config/

Jagatud käitusaegne tee (muutumatu):

/run/rediacc/docker-{N}.sock

See ühtne paigutus kõrvaldab kirjutuskaitstud/kirjutatavate ühenduspunktide konfliktid, mis tekkisid siis, kui daemoni teed olid jaotatud hosti failisüsteemi ja krüpteeritud köite vahel. Nii repo-kohased kui ka iseseisvad daemonid järgivad sama kataloogistruktuuri, nii et tööriistad ja diagnostika töötavad mõlemal juhul identselt.

LUKS-krüpteerimine

Repositooriumid on LUKS-krüpteeritud kettapildid, mis on salvestatud serveri andmesalvestile (vaikimisi: /mnt/rediacc). Iga repositoorium:

Omab juhuslikult genereeritud krüpteerimisvõtmelauset (“volitust”)
Salvestatakse failina: {datastore}/repos/{guid}.img
Ühendatakse cryptsetup kaudu, kui sellele pääsetakse ligi

Volitus salvestatakse sinu konfiguratsioonifailis, kuid mitte kunagi serveris. Ilma volituseta ei saa repositooriumi andmeid lugeda. Kui automaatne käivitamine on lubatud, salvestatakse serverisse teisene LUKS-võtmefail, et võimaldada automaatset ühendamist käivitumisel.

Andmesalvestuse taustasüsteemid

Andmesalv on masinapõhine salvestuspesa, mis hoiab repositooriumi pilte. Sellel on kaks taustasüsteemi, mis valitakse datastore init ajal:

Kohalik (vaikimisi): silmus-toetatud BTRFS-failisüsteem masina enda kettal. Repositooriumi pildid on selle sees LUKS-krüpteeritud failid; fork on üksainus cp --reflink=always. See on taustasüsteem, mida kasutab iga ühemasinaline juurutus, ja see ei vaja midagi peale serveri enda ketta.
Ceph RBD: andmesalv elab RBD-pildil, mis on kaardistatud välisest Ceph-klastrist, koos lihtsa BTRFS-iga selle peal (LUKS-kihti sellel tasandil pole, kuna Ceph-sõlmed ei ava kunagi LUKS-i). Fork ja kirjutuskaitstud mitme kliendi arhitektuur kasutavad RBD enda copy-on-write primitiive (hetktõmmis, kaitse, kloon) ja RADOS-nimeruume üürnikupõhise isoleerimise jaoks.

Mõlemad taustasüsteemid näitavad kõigele nende kohal sama repositooriumi mudelit, nii et repo-käsud, varukoopiad ja fork’id töötavad identselt. Erinevus seisneb selles, kus baidid elavad ja millist copy-on-write mehhanismi fork kasutab (BTRFS-reflink versus RBD-kloon). Vaata Masina ülesseadmine, kuidas iga taustasüsteemi initsialiseerida, ja Serveri viide renet-tasandi andmesalve käskude jaoks.

Kubernetese repositooriumid

Docker-repode kõrval saab masin majutada klastreid. Rediacc säilitab repo mentaliteedi, pöörates tavapärase objektimudeli ümber: klaster on konteiner ja Kubernetese repo on selle sees olev nimeruum.

Klastri olek (k3s-i andmekataloog sõlme kohta) elab andmesalve-toetatud copy-on-write pildifailides, üks sõlme kohta, nii et klaster forkib ja migreerub pildikogumina.
Kubernetese repo on nimeruum <repo> pluss selle köited. Püsivad köited on eraldi copy-on-write üksused (RBD-pildid Cephis või väikesed andmesalve pildifailid kohaliku PV-provisioneerija kaudu), mitte kunagi kataloogid ühe läbipaistmatu klastripildi sees. See eraldus on see, mis teeb repo-põhised fork’id sõltumatult copy-on-write’iks.
KUBECONFIG süstitakse DOCKER_HOST analoogina ja renet kube ümbris rakendab manifeste up()-ist samamoodi nagu renet compose käitab Dockerit.

Terve klastri kloonimine ja ümberpaigutamine elavad käskudes rdc cluster fork ja rdc cluster migrate. See on eristav võimekus: forkida või liigutada töötav klaster, sealhulgas selle andmed, teise masinasse või andmekeskusesse lühikese ülemineku ajaga. Vaata juhendit Kubernetes täieliku mudeli, käskude ja mõõdetud ülemineku numbrite jaoks.

Konfiguratsioonistuktuur

Iga konfiguratsioon on JSON-fail, mis on salvestatud ~/.config/rediacc/ alla. Vaikimisi konfiguratsioon on rediacc.json; nimetatud konfiguratsioonid kasutavad nime failinimena (nt production.json). Väljad on grupeeritud eesmärgi järgi: resources hoiab juurutusi, credentials hoiab saladusi, account hoiab pilve vaikeväärtusi, infra hoiab TLS/DNS seadeid ja encryption hoiab välja-kohast puhkeoleku olekut. Tippnivoo schemaVersion: 2 diskriminaator kinnitab edasisuunalise ühilduvuse.

{
  "schemaVersion": 2,
  "id": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
  "version": 47,
  "defaults": {
    "language": "en",
    "machine": "prod-1",
    "nextNetworkId": 2880,
    "universalUser": "rediacc"
  },
  "credentials": {
    "ssh": {
      "privateKey": "-----BEGIN OPENSSH PRIVATE KEY-----\n...\n-----END OPENSSH PRIVATE KEY-----",
      "publicKey": "ssh-ed25519 AAAA...",
      "knownHosts": "..."
    },
    "cfDnsApiToken": "cf-token-xxxxxxxxxxxx"
  },
  "resources": {
    "machines": {
      "prod-1": {
        "ip": "203.0.113.50",
        "user": "deploy",
        "port": 22,
        "datastore": "/mnt/rediacc",
        "knownHosts": "203.0.113.50 ssh-ed25519 AAAA..."
      }
    },
    "storages": {
      "backblaze": {
        "provider": "b2",
        "vaultContent": { "...": "..." }
      }
    },
    "repositories": {
      "webapp": {
        "repositoryGuid": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
        "credential": "base64-encoded-random-passphrase",
        "networkId": 2816
      }
    }
  },
  "infra": {
    "certEmail": "admin@example.com",
    "cfDnsZoneId": "..."
  },
  "encryption": {
    "mode": "plaintext"
  }
}

Põhigrupid:

Grupp	Sisu
`schemaVersion`	Diskriminaator (praegu `2`). Laadijad lükkavad tundmatud versioonid tagasi.
`id` / `version`	Muutumatu UUID + monotoonne loendur; kasutatakse optimistliku lukustamise jaoks kaugel konfiguratsioonisalves.
`defaults.*`	Mitte-tundlikud käitusaegse vaikeväärtused (`machine`, `language`, `pruneGraceDays`, `universalUser`, `nextNetworkId`).
`credentials.ssh`	Sisseehitatud SSH-võtmepaar + `knownHosts`. Asendab pärandit `ssh.privateKeyPath` (enam pole failiteede kaudsust; sisu lahendatakse laadimisajal ja salvestatakse sisse).
`credentials.cfDnsApiToken`	Cloudflare DNS-01 ACME token.
`credentials.masterPasswordVerifier`	Esineb ainult siis, kui `encryption.mode === "master-password"`.
`resources.machines.*`	SSH-ühenduse üksikasjad masina kohta.
`resources.storages.*`	rclone-ühilduv välisvaru varukoopiate volitused.
`resources.repositories.*`	Repo-kohane GUID + LUKS-volitus + SSH-võti liivakastis isoleeritud agendi juurdepääsuks.
`infra.acmeCertCache.*`	Vahemällu talletatud Traefik acme.json, gzip+base64, domeeni järgi võtmestatud.
`encryption.mode`	`"plaintext"` (vaikimisi) või `"master-password"`.
`encryption.encryptedFields`	Krüpteeritud puhul: pointeri järgi AES-GCM-ploki kaart (`/resources/repositories/webapp/credential` → `{ciphertext, nonce, tag}`). Üks avamise viip seansi kohta dekrüpteerib välju lugemisel.
`remote`	Esineb ainult siis, kui konfiguratsioon on sünkroonitud krüpteeritud konfiguratsioonisalvega; vaata Krüpteeritud konfiguratsioonisalv.

Redigeeri turvaliselt CLI-ga, mitte vim-iga:

# Pointeri-aadressiga ühe välja redigeerimised (teadmisväravaga tundlike teede jaoks)
rdc config field set --pointer /resources/machines/prod-1/port --new 2222
rdc config field set --pointer /credentials/cfDnsApiToken --current "$OLD" --new "$NEW"

# Täisredaktor redakteeritud JSONC projektsiooniga (ainult inimestele)
rdc config edit

# Kirjutuskaitstud JSONC dump, ohutu skriptide ja agentide jaoks
rdc config edit --dump

# Vaata iga muudatust + keeldumist + paljastamist auditi logis
rdc config audit log --since 24h
rdc config audit verify

CLI viide: rdc config field set · rdc config edit · rdc config audit log · rdc config audit verify

See fail sisaldab tundlikke andmeid (SSH-privaatvõtmed, LUKS-volitused, Cloudflare tokenid). See salvestatakse õigustega 0600 (ainult omanik saab lugeda ja kirjutada). Ära jaga seda ega lisa versioonihaldusesse. Kui mõni rdc käsk seda loeb, redakteeritakse tundlikud väljad vaikimisi: lihttekst ilmub ainult koos --reveal-iga interaktiivsel inimese TTY-l.

Ümbrik v2 ja serveripoolne jõustamine

Kui konfiguratsioon sünkroonitakse krüpteeritud konfiguratsioonisalvega, mähib CLI iga tundliku välja välja-kohasesse HMAC-sidemesse ja kannab need kohustused lihtteksti ümbrikku. Server näeb ainult kuueteistkümnendarvude kokkuvõtteid: mitte kunagi väärtusi: kuid saab jõustada teadmisväravaid igal kirjutusel:

Eeltingimuse kontroll: PUT /configs/<id> puhul esitab klient kokkuvõtted, mida ta väidab teadvat muudetavate teede kohta. Server võrdleb salvestatud ümbriku kohustistega. Lahknevus: 409 precondition_failed koos mismatchedPaths. Null-teadmine: server ei näe kunagi lihtteksti.
Anti-allagradeerimine: uus ümbrik peab siduma iga tundliku tee, mida eelmine ümbrik sidus. Agent ei saa teed kohustistest eemaldada tulevase eeltingimuse vältimiseks.
Ümbriku versiooni kinnitamine: server lükkab tagasi ümbrikud, millel puudub envelopeVersion: 2, koos 400 unsupported_envelope_version. Kahekordset vastuvõtmise akent pole.
Välja-kohane krüpteerimine puhkeolekus (CLI-poolne): kui encryption.mode === "master-password", muutub iga saladus individuaalseks AES-GCM-plokiks, mis on võtmestatud peaparooliga. Lugemisel ei käivita see viipa, välja arvatud siis, kui käsk tegelikult puudutab saladust (nii jääb rdc machine list viipadeta).

Kohustuse võti (FCK) tuletatakse klientide poolel CEK-ist via HKDF-SHA256(ikm=CEK, salt=fckSalt, info="rediacc-config-fck-v1") konfiguratsioonipõhise soolaga. fckSalt pööramine tühistab kõik eelmised kohustused, sundides täielikku ümberarvutamist: kasulik CEK pööramisel.