Mirrors/ProxMenux
1
0
Fork 0
mirror of https://github.com/MacRimi/ProxMenux.git synced 2026-11-02 10:52:22 +00:00
Code Issues Packages Projects Releases Wiki Activity

Merge pull request #486 from jcastro/docs/review-oci-manager

Browse Source 
docs: review OCI manager documentation in all seven translations
This commit is contained in:
MacRimi
2026-10-18 13:34:03 +02:00
committed by GitHub
parent dd62e5ce7d fc5884cdc1
commit 3ee8f8cd58
59 changed files with 15774 additions and 281 deletions
Download Patch File Download Diff File Expand all files Collapse all files
web/messages/it/docs/oci-manager/architecture.json
+171
View File
@@ -0,0 +1,171 @@
{
"meta": {
"title": "Come viene adattata un’immagine OCI | ProxMenux",
"description": "Dal repository dell’immagine e dal suo file Compose a un modello verificabile, un piano di distribuzione e un LXC nativo di Proxmox VE, senza Docker al suo interno."
},
"header": {
"title": "Come viene adattata un’immagine OCI",
"description": "Dal repository dell’immagine e dal suo file Compose a un modello verificabile, un piano di distribuzione e un LXC nativo, senza installare Docker al suo interno.",
"section": "OCI manager Apps"
},
"sections": [
{
"id": "pipeline",
"title": "Il processo di adattamento",
"blocks": [
{
"mermaid": {
"chartCode": "flowchart LR\n A[\"{{repo}}\"] --> B[\"Compose + README\"]\n B --> C[\"{{converter}}\"]\n C --> D[\"{{template}}\"]\n D --> E{\"{{blockers}}\"}\n E -- \"{{no}}\" --> F[\"{{review}}\"]\n F --> D\n E -- \"{{yes}}\" --> G[\"{{plan}}\"]\n G --> H[\"pct create\"]\n H --> I[\"{{lxc}}\"]",
"labels": {
"repo": "Repository dell’immagine",
"converter": "Convertitore",
"template": "Modello JSON",
"blockers": "Nessun requisito bloccante?",
"no": "No",
"yes": "Sì",
"review": "Revisione / overlay",
"plan": "Piano di distribuzione",
"lxc": "LXC nativo"
}
}
},
{
"p": "Il convertitore legge l’immagine e il file Compose pubblicati dal progetto e genera un modello JSON. Se alcuni requisiti non possono ancora essere adattati e impediscono l’installazione, il modello viene revisionato prima della pubblicazione nel catalogo. Un file di modifiche verificate, chiamato overlay, risolve questi problemi. Solo i modelli senza requisiti bloccanti vengono proposti per l’installazione."
}
]
},
{
"id": "template",
"title": "Cosa conserva il modello",
"blocks": [
{
"cards": {
"items": [
{
"icon": "archive",
"title": "Identità dell’immagine",
"body": "Repository, tag ad aggiornamento continuo, architettura, digest risolto e revisione di origine."
},
{
"icon": "braces",
"title": "Contratto del container",
"body": "Entrypoint, Cmd, ambiente, utente, directory di lavoro, segnale di arresto, porte e volumi."
},
{
"icon": "layers",
"title": "Adattamento a Proxmox VE",
"body": "Risorse, sicurezza, punti di mount, dispositivi, sysctls, controlli di stato e adattamenti necessari per ciascuno, con la relativa motivazione."
},
{
"icon": "shield",
"title": "Compatibilità",
"body": "Chiavi supportate, requisiti non adattati che impediscono l’installazione e stato di ogni verifica."
}
]
}
}
]
},
{
"id": "sources",
"title": "OCI fornisce il processo, Compose l’ambiente",
"blocks": [
{
"table": {
"headers": [
"Origine",
"Esempio",
"Risultato nativo"
],
"rows": [
[
"Metadati OCI",
"<code>Entrypoint</code>, <code>Cmd</code>, <code>User</code>",
"Proxmox VE li importa durante la creazione del CT"
],
[
"Docker Compose",
"<code>environment</code>, <code>volumes</code>, <code>devices</code>",
"Voci dell’ambiente LXC, <code>mpN</code> e <code>devN</code>"
],
[
"Profilo ProxMenux",
"GPU, controllo di stato, credenziali",
"Domande e adattamenti verificati"
],
[
"Utente",
"VMID, storage, rete",
"Il contratto dell’istanza"
]
]
}
}
]
},
{
"id": "install",
"title": "Cosa succede durante l’installazione",
"blocks": [
{
"steps": {
"items": [
{
"title": "Risolvere il riferimento",
"body": "Viene interrogato il registro, viene scelta l’architettura dell’host e viene fissato il digest esatto a cui punta il tag ad aggiornamento continuo."
},
{
"title": "Scaricare e verificare",
"body": "Skopeo scarica l’immagine come archivio OCI. Prima di creare qualsiasi risorsa, ogni livello viene verificato rispetto al suo digest e decompresso. Se il download è danneggiato, viene ripetuto una volta prima di interrompere l’installazione."
},
{
"title": "Creare il filesystem",
"body": "<code>pct create</code> crea il rootfs a partire dall’archivio e conserva i metadati ufficiali del processo dell’immagine."
},
{
"title": "Collegare le risorse",
"body": "Vengono applicati i volumi, la rete, l’ambiente, i dispositivi e i profili di sicurezza dichiarati."
},
{
"title": "Console",
"body": "L’output della console del container viene conservato sull’host. La console di Proxmox VE apre una shell se l’immagine ne include una."
},
{
"title": "Verificare",
"body": "Al primo avvio si attende che il container riceva un indirizzo e che il servizio risponda. In caso di errore, l’installazione non viene indicata come riuscita."
},
{
"title": "Registrare la configurazione",
"body": "La configurazione effettiva viene salvata nel contratto dell’istanza usato per gli aggiornamenti e le ricreazioni."
}
]
}
}
]
},
{
"id": "example",
"title": "Esempio: un’immagine con /config e /downloads",
"intro": "Una definizione Compose comune e la configurazione Proxmox VE che ne deriva. I percorsi attesi dall’applicazione non cambiano.",
"blocks": [
{
"codeGrid": {
"items": [
{
"title": "Docker Compose",
"code": "image: lscr.io/linuxserver/example:latest\nenvironment:\n - PUID=1000\n - PGID=1000\nvolumes:\n - config:/config\n - /srv/downloads:/downloads\nports:\n - 8080:8080"
},
{
"title": "/etc/pve/lxc/VMID.conf (estratto)",
"code": "entrypoint: /init\nmp0: local-lvm:vm-VMID-disk-1,mp=/config,backup=1,size=8G\nmp1: /srv/downloads,mp=/downloads\nnet0: name=eth0,bridge=vmbr0,ip=dhcp,type=veth\nlxc.environment.runtime: PUID=1000\nlxc.environment.runtime: PGID=1000"
}
]
}
},
{
"p": "<code>mp0</code> è un secondo disco appartenente al container, denominato <code>vm-VMID-disk-N</code> sullo storage selezionato. Viene montato in <code>/config</code> e, con <code>backup=1</code>, incluso nel backup del container. <code>mp1</code> non crea alcun disco: monta la directory dell’host <code>/srv/downloads</code> in <code>/downloads</code> all’interno dell’LXC. La porta 8080 non viene mappata: l’LXC ha un proprio indirizzo e il servizio risponde su quello."
}
]
}
]
}
web/messages/it/docs/oci-manager/custom-image.json
+278
View File
@@ -0,0 +1,278 @@
{
"meta": {
"title": "Installare un’immagine non presente nel catalogo | ProxMenux",
"description": "Adatta un’immagine OCI da un file Compose, un URL, un comando docker run o un riferimento all’immagine e verifica cosa può riprodurre ProxMenux prima di installarla."
},
"header": {
"title": "Installa un’immagine non presente nel catalogo",
"description": "L’immagine viene adattata dal suo file Compose, da un comando docker run o dal solo riferimento. Il risultato viene mostrato per la revisione prima di creare qualsiasi LXC.",
"section": "OCI manager Apps"
},
"sections": [
{
"id": "intro",
"blocks": [
{
"calloutInfo": {
"title": "Lo stesso convertitore e lo stesso installer",
"body": "L’opzione <strong>Installa un’immagine non presente nel catalogo</strong> usa il convertitore e l’installer dei modelli del catalogo. La differenza è che il contratto viene generato al momento dalla definizione fornita e verificato prima di creare qualsiasi LXC."
}
}
]
},
{
"id": "sources",
"title": "Come viene descritta l’immagine",
"intro": "La prima schermata chiede come viene descritta l’immagine. Quattro opzioni forniscono una definizione da adattare, una quinta usa solo il nome dell’immagine e altre tre leggono un oci-compose già scritto.",
"blocks": [
{
"table": {
"headers": [
"Opzione",
"Cosa legge"
],
"rows": [
[
"Incolla il file Compose nel terminale",
"Incolla il contenuto YAML nel terminale e termina con Ctrl+D."
],
[
"Leggi il file Compose da questo host",
"Un percorso sul nodo, <code>/root/docker-compose.yml</code> per impostazione predefinita. Il file deve esistere e non superare 256 KiB."
],
[
"Scarica il file Compose da un indirizzo",
"Un indirizzo <code>http://</code> o <code>https://</code> che fornisce il contenuto YAML grezzo. Vengono scaricati al massimo 256 KiB."
],
[
"Incolla il comando docker run nel terminale",
"Il comando pubblicato dal progetto. Vengono adattati porte, ambiente, volumi, dispositivi, capability, utente, memoria condivisa e le altre opzioni supportate."
],
[
"Solo il riferimento all’immagine, senza file Compose",
"Un riferimento come <code>ghcr.io/user/application:latest</code>. Viene interrogato il registro e vengono conservati i metadati OCI dell’immagine."
],
[
"Incolla un oci-compose nel terminale",
"Incolla il JSON nel terminale e termina con Ctrl+D. Non viene convertito: viene verificato e installato così come è scritto."
],
[
"Leggi un oci-compose da questo host",
"Un file JSON sul nodo, <code>/root/oci-compose.json</code> per impostazione predefinita, di massimo 2 MiB."
],
[
"Scarica un oci-compose da un indirizzo",
"Un indirizzo <code>http://</code> o <code>https://</code> che fornisce il file JSON. Vengono scaricati al massimo 2 MiB."
]
]
}
},
{
"figure": {
"src": "/oci-manager/custom-source-menu.png",
"alt": "Menu per scegliere come descrivere un’immagine non presente nel catalogo",
"caption": "Modi per descrivere un’immagine non presente nel catalogo."
}
}
]
},
{
"id": "reference-only",
"title": "Cosa fornisce il solo riferimento all’immagine",
"intro": "L’immagine contiene i metadati del processo, ma non tutto l’ambiente che normalmente aggiunge un file Compose.",
"blocks": [
{
"table": {
"headers": [
"Letto dall’immagine",
"Non presente nell’immagine",
"Conseguenza"
],
"rows": [
[
"<code>Entrypoint</code>, <code>Cmd</code>, <code>User</code>, <code>WorkingDir</code> e l’ambiente incorporato",
"Variabili presenti solo nella documentazione",
"Vengono aggiunte durante l’installazione o con Modifica"
],
[
"Volumi dichiarati dall’immagine",
"Directory dell’host indicate solo nel file Compose",
"I percorsi aggiuntivi vengono inseriti prima dell’installazione"
],
[
"Porte <code>EXPOSE</code>",
"L’URL, il protocollo o il controllo funzionale del servizio",
"Vengono confermati la porta e il metodo di verifica del servizio"
],
[
"Architetture e digest nel registro",
"Dispositivi, privilegi o dipendenze esterne",
"Non vengono abilitati senza una definizione che li richieda"
]
]
}
}
]
},
{
"id": "review",
"title": "Verifica prima di installare",
"intro": "Dopo aver adattato la definizione, ProxMenux mostra come l’ha interpretata prima di chiedere VMID, risorse o storage.",
"blocks": [
{
"steps": {
"items": [
{
"title": "Analizza",
"body": "Vengono letti servizi, immagine, porte, percorsi, ambiente, dispositivi, sicurezza e controllo di stato."
},
{
"title": "Interroga il registro",
"body": "L’immagine deve esistere nel registro e vengono elencate le architetture pubblicate. Per un registro privato viene usato l’account salvato per quel registro."
},
{
"title": "Elenca ciò che non viene applicato",
"body": "Vengono elencati label, reti Docker, impostazioni Swarm e altre chiavi che non hanno effetto su un LXC."
},
{
"title": "Blocca le opzioni senza equivalente sicuro",
"body": "Le chiavi senza un equivalente sicuro compaiono in <strong>Opzioni senza equivalente</strong> e impediscono di proseguire con l’installazione. Non vengono ignorate senza avviso."
},
{
"title": "Richiedi i segreti",
"body": "Le variabili il cui nome indica una password, un token o una chiave vengono richieste come dati sensibili durante l’installazione."
}
]
}
},
{
"figure": {
"src": "/oci-manager/custom-review.png",
"alt": "Riepilogo di come ProxMenux ha interpretato il file Compose",
"caption": "Riepilogo mostrato prima che l’installer chieda VMID e risorse."
}
},
{
"p": "Dopo aver accettato il riepilogo, il flusso è quello del catalogo: nome, modalità predefinita o avanzata, VMID, CPU, memoria, rete, avvio con il nodo, percorsi persistenti e aggiuntivi, dispositivi compatibili e riepilogo finale."
}
]
},
{
"id": "examples",
"title": "Esempi di input",
"blocks": [
{
"codeGrid": {
"items": [
{
"title": "Compose",
"code": "services:\n app:\n image: ghcr.io/example/app:latest\n ports:\n - \"8080:8080\"\n volumes:\n - ./config:/config\n - /srv/media:/media\n environment:\n TZ: Europe/Madrid"
},
{
"title": "docker run",
"code": "docker run -d \\\n --name app \\\n -p 8080:8080 \\\n -e TZ=Europe/Madrid \\\n -v app-config:/config \\\n -v /srv/media:/media \\\n ghcr.io/example/app:latest"
}
]
}
}
]
},
{
"id": "oci-compose",
"title": "Un oci-compose scritto a mano",
"intro": "Un oci-compose è il file JSON da cui viene installata un’applicazione. Il catalogo ne conserva uno per ogni applicazione. Lo stesso formato può essere scritto a mano e installato con questa opzione.",
"blocks": [
{
"p": "In un file scritto a mano l’autore decide immagine, porte, variabili, volumi e domande dell’installazione. ProxMenux completa il resto durante la lettura. Il formato può esprimere ciò che Compose non prevede: il testo di una domanda, una password generata all’installazione, un profilo GPU, il proprietario di ciascun volume, il controllo del primo avvio o le credenziali mostrate alla fine."
},
{
"steps": {
"items": [
{
"title": "Verifica",
"body": "I file con errori non vengono installati. Ogni errore indica il campo interessato; se il JSON non è valido, vengono segnalate riga e colonna."
},
{
"title": "Rivedi",
"body": "Un file valido mostra cosa installa: immagine, indirizzo web, porte, percorsi persistenti, variabili richieste dall’installer e file che verranno scritti."
},
{
"title": "Installa",
"body": "L’installazione è la stessa delle applicazioni del catalogo, con impostazioni predefinite o avanzate."
}
]
}
},
{
"calloutWarning": {
"title": "Un file che determina i privilegi",
"body": "Un oci-compose stabilisce cosa viene montato nel container e con quali privilegi. La revisione lo mostra prima dell’installazione: installa solo file provenienti da fonti attendibili."
}
},
{
"p": "Il <readmeLink>README del motore OCI</readmeLink> descrive il formato blocco per blocco con due esempi completi. Anche il record di un’installazione può essere letto nello stesso modo: viene usato solo il modello originale, senza alcuna delle risposte di quell’installazione."
}
]
},
{
"id": "private-registries",
"title": "Immagini in registri privati",
"intro": "Un’immagine in un registro privato, come un pacchetto privato su GitHub o un repository privato su Docker Hub, viene letta con un account salvato in ProxMenux.",
"blocks": [
{
"steps": {
"items": [
{
"title": "Il registro nega l’accesso all’immagine",
"body": "Quando il registro indica che l’immagine richiede un account, la revisione propone di accedere a quel registro e legge di nuovo l’immagine."
},
{
"title": "Accedi",
"body": "Un nome utente e una password o un token autorizzato a scaricare l’immagine. Il registro li verifica e vengono salvati solo se accettati."
},
{
"title": "Installa e mantieni aggiornato",
"body": "L’account viene usato per scaricare l’immagine durante l’installazione e anche per aggiornamenti, Modifica, Ricrea, watchdog e ricerca degli aggiornamenti del Monitor, su qualsiasi nodo del cluster."
}
]
}
},
{
"p": "<strong>Account dei registri</strong>, nel menu principale di OCI manager Apps, elenca gli account salvati per registro e utente, senza mostrarne i segreti. Da ogni account puoi verificare, scaricare o installare un’immagine e aggiornare o rimuovere le credenziali."
},
{
"list": {
"items": [
"GitHub (<code>ghcr.io</code>): l’utente è l’account GitHub e la password è un token di accesso personale con il permesso <code>read:packages</code>.",
"Docker Hub (<code>docker.io</code>): l’utente è l’account Docker Hub e la password è un token di accesso con permesso di lettura.",
"Altri registri, anche con una porta propria come <code>registry.example.com:5000</code>: nome utente e password o token forniti da quel registro."
]
}
},
{
"calloutInfo": {
"title": "Dove vengono salvati gli account",
"body": "In <code>/etc/pve/priv/proxmenux/registry-auth.json</code>, leggibile solo da root, nella stessa cartella in cui Proxmox conserva le password degli storage. <code>/etc/pve</code> è condiviso tra tutti i nodi del cluster, quindi un account aggiunto su un nodo viene usato su tutti. Il backup dell’host include il file e la disinstallazione di ProxMenux lo rimuove da tutti i nodi."
}
}
]
},
{
"id": "limits",
"title": "Definizioni che non vengono installate",
"blocks": [
{
"list": {
"items": [
"Un Dockerfile senza immagine pubblicata: prima occorre creare l’immagine e pubblicarla in un registro OCI.",
"Un file Compose con più servizi: viene bloccato perché questa opzione installa un solo servizio per container, anche se più servizi usano la stessa immagine.",
"<code>configs</code>, segreti esterni o formati di dispositivi che non possono essere adattati senza ambiguità.",
"Sostituzioni della shell come <code>$(command)</code>: occorre inserire direttamente il valore risultante.",
"Opzioni <code>docker run</code> non riconosciute e <code>--env-file</code>: usa invece un file Compose con valori espliciti."
]
}
}
]
}
]
}
web/messages/it/docs/oci-manager/hardware.json
+392
View File
@@ -0,0 +1,392 @@
{
"meta": {
"title": "Dispositivi e accelerazione | ProxMenux",
"description": "Come OCI manager Apps passa GPU, NVIDIA, Coral, USB, FUSE e altri dispositivi a un contenitore OCI come risorse native Proxmox VE convalidate."
},
"header": {
"title": "Dispositivi e accelerazione",
"description": "I dispositivi GPU, NVIDIA, Coral, USB, FUSE e a blocchi diventano risorse native convalidate Proxmox VE del contenitore.",
"section": "OCI manager Apps"
},
"sections": [
{
"id": "principle",
"title": "Il dispositivo di cui l'applicazione ha bisogno, non l'intero host",
"blocks": [
{
"p": "Un dispositivo richiesto dal file Compose o dal profilo dell’applicazione viene configurato come voce <code>devN</code> specifica o come montaggio LXC. Richiedere una GPU, un dispositivo USB o un acceleratore Coral non rende il container privilegiato."
},
{
"flow": {
"nodes": [
{
"label": "Inventario host",
"detail": "/dev/dri/renderD128\nGID 993 · Intel"
},
{
"label": "ProxMenux",
"detail": "produttore e\npermessi verificati"
},
{
"label": "LXC",
"detail": "stesso dispositivo\nGID effettivo"
}
]
}
}
]
},
{
"id": "origin",
"title": "Da dove proviene la richiesta del dispositivo",
"blocks": [
{
"table": {
"headers": [
"Fonte",
"Cosa si legge",
"Cosa fa l'installatore"
],
"rows": [
[
"Docker Compose",
"<code>devices</code>, <code>group_add</code>, <code>deploy.resources</code> e NVIDIA richieste",
"Ogni esigenza diventa una richiesta di dispositivo mostrata per la revisione"
],
[
"Profilo del catalogo",
"Il supporto effettivo dell’applicazione per GPU, Coral, OpenCL, USB o FUSE",
"Solo le opzioni convalidate per quell'immagine sono offerte"
],
[
"Metadati e documentazione dell’immagine",
"VA-API, Selkies, mod LinuxServer o runtime NVIDIA",
"Vengono aggiunte le variabili documentate e la preparazione"
],
[
"Selezione utente",
"CPU solo, Intel/AMD, OpenCL, NVIDIA o un dispositivo opzionale",
"La selezione viene memorizzata nel contratto di istanza"
]
]
}
},
{
"calloutWarning": {
"title": "I dispositivi rilevati non vengono collegati automaticamente",
"body": "Viene creato un inventario dell’host, ma solo i dispositivi dichiarati dal file Compose o da un profilo compatibile sono offerti e allegati. Una GPU, USB dongle o Coral presente sull'host non è esposto ad ogni LXC."
}
}
]
},
{
"id": "identify",
"title": "Come viene identificato il dispositivo host",
"intro": "Prima della modifica del LXC, il dispositivo viene letto sull'host e abbinato al profilo scelto.",
"blocks": [
{
"table": {
"headers": [
"Tipo",
"Identità",
"Validazione"
],
"rows": [
[
"Intel/AMD DRM",
"<code>/dev/dri/renderD*</code> e <code>/sys/class/drm/NODE/device/vendor</code>",
"Un dispositivo a caratteri con il fornitore <code>0x8086</code> (Intel) o <code>0x1002</code> (AMD)"
],
[
"AMD OpenCL",
"Il nodo di rendering, più <code>/dev/kfd</code> quando il profilo ne ha bisogno",
"Esistenza, tipo, fornitore, autorizzazioni e compatibilità dichiarata"
],
[
"AMD ROCm",
"Il nodo di rendering, <code>/dev/kfd</code> e la generazione indicata dal driver di calcolo in <code>/sys/class/kfd/kfd/topology/nodes/*/properties</code>",
"Una generazione per cui l’immagine ROCm dell’applicazione include kernel di calcolo — le GPU RDNA2 indicate e quelle più recenti — viene proposta così com’è. Le altre GPU di queste famiglie, come Radeon 680M e 780M, sono proposte come sperimentali e non sono mai preselezionate: ROCm non le supporta ufficialmente, l’applicazione le presenta come la generazione della rispettiva famiglia (<code>HSA_OVERRIDE_GFX_VERSION</code>) e l’installatore chiede conferma prima di scaricare l’immagine più grande. Una GPU precedente, come la grafica integrata di un Ryzen 5000U, non viene proposta e Immich mantiene il riconoscimento sulla CPU."
],
[
"NVIDIA",
"<code>nvidia-smi</code> e <code>nvidia-container-cli</code>",
"GPU, UUID, bus PCI, versione driver, Toolkit, nodi <code>/dev/nvidia*</code>, binari e librerie"
],
[
"Coral PCIe/M.2",
"<code>/dev/apex_N</code> e il suo collegamento in <code>/sys/dev/char/MAJOR:MINOR</code>",
"Nodo a caratteri, numeri major/minor, proprietario, GID e permessi"
],
[
"USB e seriale",
"<code>/dev/ttyUSB*</code>, <code>/dev/ttyACM*</code> o <code>/dev/bus/usb/BBB/DDD</code>",
"Nodo di carattere; per USB anche produttore, prodotto e seriale quando sysfs li pubblica"
],
[
"KVM, TUN, FUSE, video e SCSI generici",
"<code>/dev/kvm</code>, <code>/dev/net/tun</code>, <code>/dev/fuse</code>, <code>/dev/videoN</code> o <code>/dev/sgN</code>",
"Percorso supportato, tipo nodo e permessi effettivi"
],
[
"Unità ottica",
"<code>/dev/srN</code>",
"Un dispositivo a blocchi"
]
]
}
}
]
},
{
"id": "install",
"title": "Cosa succede durante l'installazione",
"blocks": [
{
"steps": {
"items": [
{
"title": "Il modello offre i suoi profili",
"body": "Ad esempio solo CPU, Intel/AMD VA-API, AMD OpenCL, Intel OpenCL o NVIDIA. Le opzioni appartengono all'immagine, non a un menu comune."
},
{
"title": "Viene scelto un profilo",
"body": "Definisce i nodi del dispositivo, ambiente, mod o runtime di cui l'applicazione ha bisogno."
},
{
"title": "Si propone un percorso",
"body": "Per DRM, <code>/dev/dri/renderD128</code>, che può essere modificato su un host con diversi nodi di rendering. Per USB o seriale, viene selezionato il nodo specifico."
},
{
"title": "Validazione",
"body": "Esistenza, tipo, fornitore consentito, autorizzazioni e GID sono controllati. Un errore blocca l'operazione."
},
{
"title": "Il contratto è scritto",
"body": "Percorso, modalità, GID, accesso scrittura e profilo sono registrati per aggiornamenti e ricreazioni."
},
{
"title": "Collega e verifica",
"body": "<code>pct set</code> aggiunge l'ingresso <code>devN</code> e l'accesso viene quindi controllato all'interno del LXC. Le immagini LinuxServer vengono anche controllate come utente <code>abc</code>."
}
]
}
}
]
},
{
"id": "config",
"title": "Come appare nella configurazione LXC",
"intro": "Valori illustrativi: <code>dev0</code> e <code>dev1</code> sono gli slot liberi assegnati da Proxmox VE; <code>renderD128</code>, <code>apex_0</code> e il GID dipendono dall’hardware del nodo.",
"blocks": [
{
"codeGrid": {
"items": [
{
"title": "Intel/AMD VA-API",
"code": "dev0: path=/dev/dri/renderD128,mode=0660,gid=993,deny-write=0"
},
{
"title": "Coral PCIe/M.2",
"code": "dev0: path=/dev/apex_0,mode=0660,gid=GID,deny-write=0"
},
{
"title": "Un dispositivo USB specifico",
"code": "dev0: path=/dev/bus/usb/003/004,mode=0660,gid=GID,deny-write=0"
},
{
"title": "AMD OpenCL",
"code": "dev0: path=/dev/dri/renderD128,mode=0660,gid=GID,deny-write=0\ndev1: path=/dev/kfd,mode=0660,gid=GID,deny-write=0"
}
]
}
},
{
"p": "Il GID è letto con <code>stat</code> sull'host e scritto all'ingresso <code>devN</code>; i gruppi <code>render</code> e <code>video</code> non si presume abbiano un numero fisso. Il dispositivo mantiene lo stesso percorso <code>/dev</code> all'interno del LXC, dove i propri meccanismi dell'applicazione lo cercano."
}
]
},
{
"id": "profiles",
"title": "Profili che un’immagine può offrire",
"blocks": [
{
"table": {
"headers": [
"Profilo",
"Configurazione risultante",
"Offerto quando"
],
"rows": [
[
"Intel/AMD VA-API",
"Nodo di rendering <code>/dev/dri</code>",
"L'applicazione supporta l'accelerazione video"
],
[
"OpenCL",
"Nodo di rendering, <code>/dev/kfd</code> quando necessario e mod ufficiale",
"L'immagine o il profilo lo documentano"
],
[
"NVIDIA",
"Dispositivi driver e librerie dell'host",
"L’host dispone di un driver funzionante e di NVIDIA Container Toolkit"
],
[
"Coral",
"<code>/dev/apex_0</code> o il bus USB",
"Il profilo dichiara il supporto Coral (Frigate)"
],
[
"USB, seriale, FUSE",
"Un singolo dispositivo, un albero convalidato o una funzione LXC",
"Il contratto lo chiede"
]
]
}
}
]
},
{
"id": "nvidia",
"title": "NVIDIA",
"blocks": [
{
"calloutWarning": {
"title": "Requisito del nodo: NVIDIA Container Toolkit",
"body": "Un driver funzionante su Proxmox VE non è sufficiente per dare un NVIDIA GPU ad un'immagine OCI. OCI manager Apps utilizza <code>nvidia-container-cli</code>, dal NVIDIA Container Toolkit, per identificare i dispositivi e per ottenere i binari e le librerie che corrispondono al driver caricato."
}
},
{
"p": "L’<nvidiaLink>installatore NVIDIA di ProxMenux</nvidiaLink> installa NVIDIA Container Toolkit dal repository ufficiale NVIDIA insieme al driver. Controlla i quattro pacchetti, convalida <code>nvidia-container-cli</code> e registra il risultato nel registro delle modifiche di <auditLink>Audit & Report</auditLink>."
},
{
"p": "Questi due comandi sull'host mostrano se il driver e il Toolkit sono disponibili:"
},
{
"shell": {
"code": "nvidia-smi -L\nnvidia-container-cli --version"
}
},
{
"p": "Su un host dove il driver è stato installato con altri mezzi, il Toolkit è installato dal repository ufficiale stabile:"
},
{
"shell": {
"code": "apt-get update\napt-get install -y --no-install-recommends ca-certificates curl gnupg2\n\ncurl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey \\\n | gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg\n\ncurl -s -L https://nvidia.github.io/libnvidia-container/stable/deb/nvidia-container-toolkit.list \\\n | sed 's#deb https://#deb [signed-by=/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g' \\\n > /etc/apt/sources.list.d/nvidia-container-toolkit.list\n\napt-get update\napt-get install -y nvidia-container-toolkit libnvidia-container-tools"
}
},
{
"p": "L’inventario utilizzato da OCI manager Apps è l'output di:"
},
{
"shell": {
"code": "nvidia-container-cli list --device all --libraries --binaries --firmwares --ipcs"
}
},
{
"calloutInfo": {
"title": "La configurazione di runtime Docker non è coinvolta",
"body": "I container sono LXC nativi e non usano un demone Docker, quindi <code>nvidia-ctk runtime configure --runtime=docker</code> non interviene: ProxMenux interroga direttamente <code>nvidia-container-cli</code> e configura dispositivi e montaggi LXC. I comandi e le piattaforme supportate sono mantenuti nella <toolkitLink>guida di installazione di NVIDIA Container Toolkit</toolkitLink>."
}
},
{
"cards": {
"items": [
{
"icon": "cpu",
"title": "Inventario dal driver",
"body": "<code>nvidia-container-cli</code> elenca i nodi del dispositivo, i binari, il firmware e le librerie del driver installato."
},
{
"icon": "refresh",
"title": "Nessuna versione fissa",
"body": "Il modello non nomina i file della libreria. Il profilo viene generato dall'host corrente."
},
{
"icon": "shield",
"title": "Montaggi in sola lettura",
"body": "Le librerie ospitanti sono montate in sola lettura invece di essere copiate nel contenitore."
},
{
"icon": "hardDrive",
"title": "Modifiche dei driver",
"body": "Dopo che un driver cambia l'inventario viene generato nuovamente prima dell'avvio dei LXC colpiti."
}
]
}
},
{
"code": {
"title": "Risultati NVIDIA (semplificati)",
"code": "devN: path=/dev/nvidia0,...\ndevN: path=/dev/nvidiactl,...\ndevN: path=/dev/nvidia-uvm,...\nlxc.mount.entry: HOST_LIBRARY CONTAINER_LIBRARY none ro,bind,create=file 0 0"
}
},
{
"p": "Passare solo <code>/dev/nvidia0</code> non è sufficiente. I componenti user-space del driver caricato sono montati in sola lettura e <code>nvidia-smi</code> poi funziona all'interno del LXC per confrontare GPU, UUID, PCI bus e versione con l'inventario host."
}
]
},
{
"id": "usb",
"title": "USB, seriale e USB Coral",
"blocks": [
{
"calloutWarning": {
"title": "Numerazione USB può cambiare",
"body": "Un percorso come <code>/dev/bus/usb/003/004</code> può cambiare quando il dispositivo viene ricollegato o l'host si riavvia. Il profilo registra il fornitore, il prodotto e la serie quando sono disponibili, ma un nuovo indirizzo del bus non viene rimappato automaticamente."
}
},
{
"p": "Una periferica è data dal suo nodo specifico: <code>/dev/ttyUSB0</code>, <code>/dev/ttyACM0</code>, <code>/dev/apex_0</code> o <code>/dev/bus/usb/BBB/DDD</code>. Passare l'intero <code>/dev</code> non è accettato. Coral è offerto solo a applicazioni il cui profilo lo dichiara."
}
]
},
{
"id": "trees",
"title": "Alberi dei dispositivi e funzionalità LXC",
"blocks": [
{
"table": {
"headers": [
"Richiesta",
"Configurazione risultante",
"Ambito"
],
"rows": [
[
"<code>/dev/dvb</code>, <code>/dev/snd</code> o <code>/dev/bus/usb</code>",
"Ogni nodo di carattere dell'albero ottiene il proprio ingresso <code>devN</code> con la modalità host e GID",
"Solo l'albero richiesto, non il resto di <code>/dev</code>"
],
[
"<code>/dev/fuse</code>",
"Il nodo e, quando il profilo ne ha bisogno, la funzione <code>fuse=1</code>",
"FUSE da solo non rende disponibili i montaggi agli altri LXC"
],
[
"<code>/dev/net/tun</code>",
"Un ingresso <code>devN</code> nello stesso percorso all'interno del LXC",
"La configurazione VPN o di rete rimane nell’applicazione"
],
[
"<code>/dev/kvm</code>",
"Una voce valida <code>devN</code>",
"Offerto solo quando il contratto lo chiede"
]
]
}
}
]
},
{
"id": "security",
"title": "Conferma per livello di rischio",
"blocks": [
{
"p": "Dispositivi concreti, privilegio facoltativo, privilegio richiesto, allentamento di AppArmor o seccomp e accesso al namespace PID host sono trattati come casi separati, non sotto una generica etichetta privilegiata. Ogni opzione con un rischio viene spiegata e confermata durante l'installazione."
}
]
}
]
}
web/messages/it/docs/oci-manager/index.json
+213
View File
@@ -0,0 +1,213 @@
{
"meta": {
"title": "OCI manager Apps | ProxMenux",
"description": "Esegui immagini OCI ufficiali come container LXC nativi di Proxmox VE, con dati persistenti, accesso ai dispositivi, applicazioni composte da più container e aggiornamenti transazionali."
},
"header": {
"title": "OCI manager Apps",
"description": "Le immagini OCI ufficiali vengono eseguite come container LXC nativi di Proxmox VE. L’immagine rimane quella pubblicata dal manutentore; ProxMenux ricrea l’ambiente che Docker Compose avrebbe predisposto intorno ad essa.",
"section": "OCI manager Apps"
},
"sections": [
{
"id": "model",
"blocks": [
{
"calloutInfo": {
"title": "Un’immagine OCI, un LXC nativo",
"body": "Nei container non viene eseguito Docker Engine. Proxmox VE importa il filesystem dell’immagine e i suoi metadati OCI. L’applicazione diventa il processo principale di un LXC nativo, gestito con gli stessi strumenti degli altri container del nodo."
}
},
{
"flow": {
"nodes": [
{
"label": "Origine",
"detail": "Immagine OCI\nCompose e documentazione"
},
{
"label": "ProxMenux",
"detail": "Contratto JSON\nvalidazione e pianificazione"
},
{
"label": "Proxmox VE",
"detail": "LXC nativo\nvolumi e dispositivi"
}
],
"caption": "Si usa l’applicazione originale: il suo ambiente viene descritto in modo dichiarativo e riprodotto."
}
}
]
},
{
"id": "where",
"title": "Dove si trova",
"intro": "Sul nodo Proxmox, come root, apri <strong>OCI manager Apps (Technology Preview)</strong> dal menu principale di ProxMenux. La prima schermata offre:",
"blocks": [
{
"list": {
"items": [
"<strong>Cerca applicazioni</strong>: cerca per nome nell’intero catalogo.",
"<strong>Tutte le applicazioni</strong>: mostra il catalogo completo e il numero di applicazioni.",
"<strong>Gestisci le applicazioni OCI installate</strong>: aggiorna, modifica, rimuovi o recupera le applicazioni già installate.",
"<strong>Account dei registri</strong>: gestisci gli account usati per installare e aggiornare immagini da registri privati.",
"<strong>Installa un’immagine non presente nel catalogo</strong>: adatta un file Compose, un comando <code>docker run</code> o un riferimento a un’immagine.",
"Le categorie del catalogo, ciascuna con il numero di applicazioni."
]
}
},
{
"figure": {
"src": "/oci-manager/main-menu.png",
"alt": "Schermata principale di OCI manager Apps con ricerca, catalogo completo, gestione delle applicazioni, immagini fuori catalogo e categorie.",
"caption": "Schermata principale di OCI manager Apps."
}
},
{
"p": "Selezionando un’applicazione vengono mostrati la descrizione, l’immagine usata e due modalità di installazione. <strong>Installa con le impostazioni predefinite</strong> chiede solo le scelte essenziali: storage, posizione dei dati, indirizzo e avvio. <strong>Installa con le impostazioni avanzate</strong> presenta tutte le decisioni in ordine: VMID e risorse, storage per ogni percorso, bridge di rete e dispositivi."
},
{
"p": "Le applicazioni provate sul campo mostrano <strong>Verificato</strong> in questa schermata e un ✓ negli elenchi, sia per i test del laboratorio ProxMenux sia per quelli della community."
}
]
},
{
"id": "beta",
"title": "Perché mantiene l’etichetta Technology Preview",
"blocks": [
{
"p": "OCI manager Apps mantiene l’etichetta <strong>Technology Preview</strong> assegnata da Proxmox VE ai container applicativi creati da immagini OCI, il cui supporto è stato introdotto in Proxmox VE 9.1. L’etichetta riguarda la tecnologia su cui si basa OCI manager Apps, non il motore di ProxMenux: il comportamento di questi container può ancora cambiare tra le versioni di Proxmox VE. Rimarrà finché Proxmox VE non considererà stabile tale supporto."
},
{
"p": "Il motore di OCI manager Apps viene testato nel laboratorio ProxMenux: installazione, aggiornamento, modifica, ricreazione, backup, ripristino, migrazione e watchdog. Ogni applicazione viene verificata separatamente. Quelle provate sul campo mostrano <strong>Verificato</strong> e un ✓ negli elenchi."
}
]
},
{
"id": "translation",
"title": "Come Docker descrive i requisiti e come li realizza OCI manager Apps",
"blocks": [
{
"table": {
"headers": [
"Requisito",
"Come lo esprime Docker",
"Come lo realizza OCI manager Apps"
],
"rows": [
[
"Eseguire l’applicazione",
"<code>image</code>, <code>entrypoint</code>, <code>command</code>",
"Il rootfs OCI e il processo principale dell’LXC"
],
[
"Conservare la configurazione",
"<code>volumes: /config</code>",
"Un volume persistente <code>mpN</code> incluso nel backup, oppure una directory dell’host."
],
[
"Rendere accessibile il servizio",
"<code>ports</code>",
"Un indirizzo proprio per l’LXC e l’URL di accesso al servizio."
],
[
"Usare l’hardware",
"<code>devices</code>, <code>group_add</code>",
"Voci <code>devN</code> con il GID effettivo dell’host e un profilo validato."
],
[
"Collegare le dipendenze",
"<code>networks</code>, <code>depends_on</code>",
"Un bridge di rete privato, indirizzi fissi, ordine di avvio e controlli di stato."
],
[
"Aggiornare",
"Scaricare con <code>pull</code> e ricreare",
"Un nuovo rootfs che mantiene lo stesso contratto di persistenza."
]
]
}
}
]
},
{
"id": "kept",
"title": "Cosa viene conservato e cosa cambia",
"blocks": [
{
"cards": {
"items": [
{
"icon": "archive",
"title": "Conservato",
"body": "L’immagine ufficiale, i percorsi interni, l’ambiente, il processo di avvio e la documentazione d’uso."
},
{
"icon": "boxes",
"title": "Adattato",
"body": "L’ambiente di esecuzione: rete, persistenza, dispositivi, permessi e dipendenze utilizzano i meccanismi LXC nativi di Proxmox VE."
},
{
"icon": "shield",
"title": "Senza equivalente",
"body": "Un’opzione Compose senza un equivalente sicuro viene segnalata come requisito bloccante. I modelli con requisiti bloccanti non vengono proposti per l’installazione e le opzioni sensibili richiedono conferma durante la procedura."
},
{
"icon": "refresh",
"title": "Registrato",
"body": "Il digest dell’immagine, le risorse, i percorsi, la rete, i dispositivi e l’appartenenza a uno stack vengono salvati nel contratto dell’istanza. Aggiornamenti e ricreazioni riproducono tale contratto."
}
]
}
}
]
},
{
"id": "pages",
"title": "Pagine di questa sezione",
"blocks": [
{
"next": {
"items": [
{
"label": "Come viene adattata un’immagine OCI",
"href": "/docs/oci-manager/architecture",
"tail": "Dall’immagine e dal suo file Compose a un LXC nativo."
},
{
"label": "Installare un’immagine non presente nel catalogo",
"href": "/docs/oci-manager/custom-image",
"tail": "Un file Compose, un comando docker run o un riferimento a un’immagine."
},
{
"label": "Dati, percorsi e rete",
"href": "/docs/oci-manager/storage-network",
"tail": "Volumi del container, directory dell’host, mount con rclone e indirizzi."
},
{
"label": "Dispositivi e accelerazione",
"href": "/docs/oci-manager/hardware",
"tail": "GPU, NVIDIA, Coral, USB e altri dispositivi."
},
{
"label": "Applicazioni con più container",
"href": "/docs/oci-manager/stacks",
"tail": "Applicazione, database e cache in LXC coordinati."
},
{
"label": "Installazione, aggiornamento e modifica",
"href": "/docs/oci-manager/lifecycle",
"tail": "Il contratto dell’istanza e le sue operazioni."
},
{
"label": "In ProxMenux Monitor",
"href": "/docs/oci-manager/monitor",
"tail": "Versioni, aggiornamenti, output della console e terminale."
}
]
}
}
]
}
]
}
web/messages/it/docs/oci-manager/lifecycle.json
+499
View File
@@ -0,0 +1,499 @@
{
"meta": {
"title": "Installare, aggiornare e modificare | ProxMenux",
"description": "Il contratto di istanza di un contenitore OCI e le operazioni che lo utilizzano: aggiornamento, modifica, rimozione, recupero di un'operazione interrotta e recupero dopo un ripristino su questo o un altro host."
},
"header": {
"title": "Installare, aggiornare e modificare",
"description": "Ogni istanza conserva un contratto riproducibile, così il suo rootfs può essere sostituito senza perdere la configurazione o i dati persistenti.",
"section": "OCI manager Apps"
},
"sections": [
{
"id": "contract",
"title": "Il contratto di istanza",
"blocks": [
{
"p": "Dopo l'installazione, la configurazione effettiva viene salvata in <code>/usr/local/share/proxmenux/oci/instances/VMID/oci-compose.json</code>. Non è una copia del file Compose originale: è il contratto riproducibile del LXC presente su questo host."
},
{
"code": {
"code": "instances/\n└── 105/\n └── oci-compose.json\n ├── image and resolved digest\n ├── resources and network\n ├── environment (secrets protected)\n ├── container disks and host directories\n ├── hardware profile and devices\n ├── console log and terminal mode\n └── stack membership and lifecycle"
}
},
{
"p": "Una copia del contratto si trova nel contenitore, in <code>/.proxmenux/oci-record.json</code>, ed è leggibile solo dall'utente root del contenitore. Il backup del contenitore include quindi sempre il contratto in uso in quel momento. Una seconda copia si trova in <code>/etc/pve/priv/proxmenux/oci</code>, condiviso da tutti i nodi del cluster e leggibile solo da root dell'host. Entrambe le copie vengono scritte dopo ogni installazione, aggiornamento e modifica."
}
]
},
{
"id": "manage",
"title": "Gestisci le applicazioni OCI installate",
"intro": "Questa opzione della schermata principale elenca le istanze registrate con la relativa applicazione e immagine. Prima di ogni azione, ciascuna istanza viene confrontata con il proprio contratto; un CT che non corrisponde più al proprio record non viene né modificato né eliminato. Lo stesso aggiornamento e lo stesso editor sono disponibili nella scheda Aggiornamenti di <monitorLink>ProxMenux Monitor</monitorLink>.",
"blocks": [
{
"table": {
"headers": [
"Opzione",
"Che cosa cambia",
"Che cosa viene conservato"
],
"rows": [
[
"Aggiorna l’immagine mantenendo la configurazione salvata",
"Il rootfs viene sostituito dall'immagine attualmente pubblicata dal canale salvato",
"Contratto, dischi container, directory host, rete e dispositivi"
],
[
"Modifica risorse, rete, percorsi e GPU",
"L’editor si apre con il contratto attuale; il CT viene ricreato con le modifiche",
"I dati dei dischi container e delle directory host"
],
[
"Watchdog: riavviare l'applicazione quando si blocca",
"Determina se l'applicazione viene riavviata quando si arresta da sola. Non viene ricreato nulla",
"L'intera installazione; solo la scelta viene salvata nel contratto"
],
[
"Rimuovi: elimina l'applicazione e i suoi container",
"Il LXC, o ogni membro di uno stack, e i loro contratti vengono eliminati",
"Directory dell’host, con il loro contenuto"
]
]
}
},
{
"p": "Per un'applicazione con più contenitori, il menu offre <strong>Aggiorna tutti i contenitori dell'applicazione</strong>, <strong>Modifica percorsi e dispositivi aggiuntivi</strong>, <strong>Ricrea tutti i contenitori con la configurazione salvata</strong>, il watchdog e la rimozione. Modifica aggiunge o rimuove percorsi e dispositivi aggiuntivi del contenitore applicativo senza ricreare nulla e, in Immich, cambia il componente che esegue il riconoscimento. Ricrea ricostruisce ogni contenitore dall'immagine usata per installarlo, senza cercarne una più recente."
},
{
"figure": {
"src": "/oci-manager/manage-menu.png",
"alt": "Elenco delle applicazioni OCI installate e delle opzioni di aggiornamento, modifica e rimozione",
"caption": "Gestione delle applicazioni OCI installate."
}
}
]
},
{
"id": "update",
"title": "Un aggiornamento transazionale",
"blocks": [
{
"mermaid": {
"chartCode": "sequenceDiagram\n participant U as {{user}}\n participant P as ProxMenux\n participant R as {{registry}}\n participant X as Proxmox VE\n U->>P: {{update}}\n P->>R: {{resolve}}\n R-->>P: digest\n P->>P: {{verify}}\n P->>X: {{backup}}\n P->>X: {{import}}\n P->>X: {{reapply}}\n X-->>P: healthcheck\n alt {{healthy}}\n P-->>U: {{commit}}\n else {{failure}}\n P->>X: Rollback\n P-->>U: {{restored}}\n end",
"labels": {
"user": "Utente",
"registry": "Registro OCI",
"update": "Aggiorna istanza",
"resolve": "Risolvere il tag",
"verify": "Verifica archivio e controlli preliminari",
"backup": "Arresta e salva un backup del CT",
"import": "Importa il nuovo rootfs",
"reapply": "Applicare nuovamente il contratto",
"healthy": "integro",
"failure": "guasto",
"commit": "Contratto pubblicato con il nuovo digest",
"restored": "Precedente istanza ripristinata"
}
}
},
{
"list": {
"items": [
"Se il registro restituisce ancora il digest installato, non viene scaricato nulla e l’istanza rimane invariata.",
"La nuova immagine viene verificata livello per livello prima di arrestare il CT. Un download danneggiato viene ripetuto una seconda volta; un’immagine già nella cache che non supera la verifica viene scaricata di nuovo.",
"Le impostazioni modificate in Proxmox VE dopo l’installazione (memoria, swap, core, limite e priorità della CPU, avvio con il nodo) vengono conservate e incluse nel nuovo contratto.",
"L'interfaccia LAN che la suite Arr e le applicazioni multi-container aggiungono (<code>net1</code>) e l'ordine di avvio (<code>startup</code>) sono restituiti al nuovo contenitore come sono.",
"Qualsiasi altra differenza tra il CT e il suo contratto interrompe l’aggiornamento prima che il CT venga arrestato."
]
}
},
{
"flow": {
"nodes": [
{
"label": "Prima",
"detail": "rootfs A\n/config mp0\ndirectory host /media"
},
{
"label": "Aggiornamento",
"detail": "sostituisce solo\nil rootfs"
},
{
"label": "Dopo",
"detail": "rootfs B\n/config mp0\ndirectory host /media"
}
]
}
},
{
"p": "Prima di arrestare qualsiasi cosa, l’operazione verifica lo spazio necessario al backup: i dati in uso nei volumi inclusi, più un margine. Il backup viene scritto accanto al record dell’applicazione, sul disco di sistema dell’host. Se lo spazio non basta, il menu richiede un altro storage dell’host che supporti i backup: il backup viene creato lì ed eliminato al termine dell’operazione. La scelta viene memorizzata per l’applicazione, anche per gli aggiornamenti pianificati. Se nessuno storage ha spazio sufficiente, l’operazione viene rifiutata e l’applicazione resta invariata. Anche lo spazio per la nuova immagine viene verificato prima del download."
}
]
},
{
"id": "recovery",
"title": "Recuperare un'operazione interrotta",
"intro": "L’aggiornamento e la modifica usano una transazione persistente. Se il processo, il terminale o il nodo subisce un’interruzione dopo l’arresto del CT, l’operazione non viene considerata conclusa.",
"blocks": [
{
"steps": {
"items": [
{
"title": "Indicatore di operazione in sospeso",
"body": "Aprendo Gestisci le applicazioni OCI installate, lo stato salvato indica che la sostituzione non è mai stata pubblicata."
},
{
"title": "Visualizza stato",
"body": "Mostra la fase raggiunta senza cambiare contenitori o dati."
},
{
"title": "Ripristina l’installazione precedente",
"body": "Ripristina il backup nativo verificato eseguito prima della sostituzione e il contratto precedente."
},
{
"title": "Stacks come unità",
"body": "Per un'applicazione multicontainer, ogni membro viene recuperato dallo stesso punto di transazione, non solo quello selezionato."
}
]
}
},
{
"calloutWarning": {
"title": "Le directory dell’host sono escluse dal rollback",
"body": "Il backup comprende il rootfs e i dischi del contenitore inclusi nella copia. Una directory dell’host non viene riportata allo stato precedente, perché altri LXC potrebbero usarne i dati."
}
}
]
},
{
"id": "watchdog",
"title": "Watchdog: riavviare un’applicazione che si arresta",
"intro": "Proxmox non ha una politica di riavvio: quando termina il processo di un contenitore applicativo, il contenitore resta arrestato. Con il watchdog attivo, un’applicazione che si arresta da sola viene riavviata. Per un’applicazione OCI svolge il ruolo di <code>restart: unless-stopped</code> in un file Compose.",
"blocks": [
{
"table": {
"headers": [
"Cosa succede?",
"Con il watchdog attivo"
],
"rows": [
[
"L'applicazione si blocca o il suo processo termina",
"Il contenitore viene riavviato entro pochi secondi"
],
[
"Viene fermato o spento da Proxmox, dal Monitor o con <code>pct</code>",
"Resta arrestato finché qualcuno non lo avvia"
],
[
"Un backup, una migrazione o un'operazione ProxMenux sta lavorando su di esso",
"Niente è fatto fino a che non finisce"
],
[
"Era già arrestato all’avvio dell’host",
"Resta arrestato; lo decide <strong>Avvia con Proxmox</strong>"
],
[
"Continua ad arrestarsi subito dopo l’avvio",
"Per un’applicazione che si arresta pochi secondi dopo l’avvio o che non si avvia, vengono effettuati cinque tentativi, con attese di 30 secondi, 1, 2 e 5 minuti tra un tentativo e l’altro. Poi viene lasciata arrestata e viene inviata una notifica"
]
]
}
},
{
"p": "L’installatore lo chiede in entrambe le modalità e propone il valore dichiarato nella ricetta dell’applicazione. In seguito si può cambiare da <strong>Gestisci le applicazioni OCI installate</strong> o con l’interruttore <strong>Watchdog</strong> del contenitore in <monitorLink>ProxMenux Monitor</monitorLink>; vale per tutti i contenitori di un’applicazione con più contenitori. Un unico servizio dell’host, <code>proxmenux-oci-watchdog.service</code>, sorveglia tutte le applicazioni che lo hanno richiesto; la sua installazione compare nella scheda Modifiche di Audit & Report."
},
{
"calloutInfo": {
"title": "Ciò che l’host non può distinguere",
"body": "Il codice di uscita dell’applicazione non raggiunge l’host: un’uscita regolare e un arresto anomalo risultano quindi indistinguibili e in entrambi i casi l’applicazione viene riavviata, come con <code>always</code> e <code>unless-stopped</code> in Docker. Un arresto richiesto fuori da Proxmox, con <code>lxc-stop</code> o <code>systemctl</code>, non lascia un’attività di arresto e viene interpretato come un arresto spontaneo."
}
}
]
},
{
"id": "restore",
"title": "Backup, ripristino e un altro host",
"intro": "Un backup creato con vzdump o Proxmox Backup Server include il contenitore, i dischi del contenitore selezionati per il backup e la copia del suo contratto. Ciò che l’installazione conserva sull’host non vi è incluso. <strong>Gestisci le applicazioni OCI installate</strong> rileva i contenitori ripristinati su un host privo del loro contratto, dopo una nuova installazione di Proxmox o su un altro host, e propone di registrarli di nuovo.",
"blocks": [
{
"steps": {
"items": [
{
"title": "Ripristinare i contenitori in Proxmox",
"body": "Dall'archivio di backup, con l'ID originale o con uno qualsiasi libero. Un'applicazione multi-container ha bisogno di tutti i suoi contenitori."
},
{
"title": "Apri Gestisci applicazioni OCI installate",
"body": "Vengono elencati i contenitori ripristinati e viene proposto il recupero. Il pulsante <strong>Recupera</strong> nella scheda Aggiornamenti di <monitorLink>ProxMenux Monitor</monitorLink> apre lo stesso recupero."
},
{
"title": "Controllare prima di cambiare",
"body": "Il recupero verifica che l’host disponga di tutto ciò che serve a ciascuna applicazione. Se un’applicazione non può essere recuperata interamente, viene lasciata invariata e viene indicato il motivo."
},
{
"title": "Registra e avvia",
"body": "Il contratto viene registrato su questo host e gli elementi che l’installazione vi conservava vengono riscritti. L’avvio delle applicazioni viene chiesto separatamente: rispondi No se i contenitori originali sono ancora in esecuzione su un altro host."
}
]
}
},
{
"figure": {
"src": "/oci-manager/restore-offer.png",
"alt": "Finestra di dialogo che elenca i contenitori ripristinati e ne propone il recupero",
"caption": "Il recupero offerto quando si apre Gestione applicazioni OCI installate."
}
},
{
"table": {
"headers": [
"Ciò che l’host conservava",
"Dopo il recupero"
],
"rows": [
[
"Contratto dell’istanza",
"Registrato dalla copia presente nel contenitore, verificata rispetto alla configurazione ripristinata da Proxmox"
],
[
"Rete privata di un'applicazione multicontainer",
"Creato nuovamente con lo stesso ponte e sottorete; gli indirizzi fissi dei contenitori non cambiano"
],
[
"Ordine di avvio di un’applicazione con più contenitori",
"L’hookscript delle dipendenze e il suo contratto vengono reinstallati; gli snippet vengono abilitati nello storage <code>local</code> se nessuno storage li supporta"
],
[
"Sysctl di rete e file del monitor dell’host",
"Scritto di nuovo in <code>/etc/pve/proxmenux</code>"
],
[
"Runtime NVIDIA",
"L’hook di un contenitore non privilegiato viene reinstallato. Un contenitore privilegiato riceve i file del driver di questo host al posto di quelli dell’host di origine"
],
[
"Montaggio Rclone",
"L’hookscript e i programmi che rendono disponibile il mount vengono riscritti, con le stesse viste sull’host"
],
[
"Regola del firewall host di un monitor host",
"Viene chiesto di nuovo, per la sua porta web e la sottorete del bridge su questo host"
],
[
"<code>lost+found</code> di ogni disco restaurato",
"Viene rimosso se vuoto; il ripristino lo crea e alcune applicazioni non si avviano se è presente tra i loro dati"
],
[
"Dischi ripristinati su un altro storage",
"Il contratto viene aggiornato con lo storage su cui si trovano ora"
]
]
}
},
{
"p": "Un container ripristinato con un ID diverso conserva la propria applicazione. Il contratto, il log della console, i parametri sysctl di rete, lo hookscript del montaggio Rclone e l’ordine di avvio di un’applicazione composta da più container vengono registrati usando gli ID assegnati ai container su questo host."
},
{
"table": {
"headers": [
"Cosa ferma un recupero",
"Cosa fare"
],
"rows": [
[
"Manca un contenitore di un'applicazione multi-container",
"Ripristina anche quello; l’applicazione viene recuperata per intero"
],
[
"La sottorete privata è già utilizzata su questo host",
"Il recupero è annullato e nulla è cambiato: gli indirizzi dei contenitori sono fissi e non vengono spostati in un'altra subnet"
],
[
"Una directory host non esiste",
"Montare o crearlo con i suoi dati; un backup del contenitore non include directory host"
],
[
"Un dispositivo non esiste su questo host",
"Collegarlo o rimuoverlo dal contenitore in Proxmox"
],
[
"Un'applicazione con NVIDIA su un host senza driver",
"Installa il driver NVIDIA e il Container Toolkit"
],
[
"Il backup è stato fatto prima che la copia del contratto esistesse",
"Il contenitore rimane come un normale LXC e non viene offerto di nuovo"
]
]
}
},
{
"calloutInfo": {
"title": "Un contenitore che ritorna",
"body": "Un contenitore ripristinato su se stesso da un backup precedente, riportato a uno snapshot o rientrato da un altro nodo porta il contratto dello stato in cui si trova. Se viene selezionato per un’operazione e il suo contratto differisce da quello dell’host, l’operazione non parte e viene proposto il recupero del contenitore."
}
},
{
"figure": {
"src": "/oci-manager/restore-result.png",
"alt": "Risultato del recupero con la rete privata, l’ordine di avvio e i contenitori registrati",
"caption": "Il risultato di un recupero, passo dopo passo."
}
}
]
},
{
"id": "remove",
"title": "Rimozione di un'applicazione OCI",
"blocks": [
{
"p": "Prima della conferma viene creato un riepilogo dalla configurazione effettiva: i contenitori da rimuovere, i dati eliminati insieme a loro, la rete privata liberata e le directory dell’host conservate. La conferma è impostata su <strong>No</strong> per impostazione predefinita, perché i dati dei dischi eliminati non possono essere recuperati in seguito."
},
{
"table": {
"headers": [
"Risorsa",
"Alla rimozione",
"Motivo"
],
"rows": [
[
"rootfs e dischi del contenitore",
"Eliminati",
"Essi appartengono solo al contenitore"
],
[
"Directory host",
"Tenuto, con il suo contenuto",
"Altre applicazioni possono utilizzarlo"
],
[
"File host del contenitore",
"Eliminati",
"Il log della console, i parametri sysctl di rete, l’hookscript del mount Rclone e la registrazione nella scheda App di ProxMenux Monitor non servono ad altri contenitori"
],
[
"File condivisi da più installazioni",
"Eliminato con l'ultima installazione che li utilizza",
"Il file del monitor dell’host e l’hookscript delle dipendenze delle applicazioni con più contenitori"
],
[
"Contratto dell’istanza",
"Eliminato dopo una rimozione di successo",
"Non vi è più associato alcun CT"
],
[
"Ponte privato di una pila",
"Rilasciato con lo stack",
"Non ha più membri da collegare"
],
[
"Rete condivisa dalla suite Arr",
"Rilasciato con l'ultima applicazione della suite",
"Ogni applicazione della suite è indipendente e viene rimossa da sola"
],
[
"Un singolo membro di una pila",
"Non rimosso da solo",
"L'intera applicazione viene rimossa, quindi nessun stack viene lasciato incompleto"
],
[
"Un contenitore su un altro nodo del cluster",
"Non rimosso",
"I suoi file di registrazione e host sono sul nodo dove è stato installato: viene rimosso lì, dopo la migrazione indietro"
]
]
}
},
{
"figure": {
"src": "/oci-manager/remove-summary.png",
"alt": "Riepilogo di rimozione con i container, i dati e le directory host interessate",
"caption": "Il sommario di rimozione, costruito dalla configurazione reale."
}
}
]
},
{
"id": "archives",
"title": "Immagini scaricate e spazio host",
"blocks": [
{
"p": "L’archivio OCI serve a costruire il rootfs; il CT in esecuzione non lo legge. Dopo un’installazione o un aggiornamento, gli archivi scaricati durante l’operazione vengono elencati con le loro dimensioni e ne viene proposta l’eliminazione. Eliminarli libera spazio senza influire sul contenitore o sui suoi dati."
},
{
"calloutInfo": {
"title": "Gli aggiornamenti non hanno bisogno dell'archivio",
"body": "Senza l'archivio, un aggiornamento risolve il canale salvato e scarica il nuovo digest. Con esso, un archivio viene riutilizzato solo quando il suo riferimento e l'integrità corrispondono a ciò che è richiesto."
}
}
]
},
{
"id": "registry",
"title": "Registro e pulizia",
"blocks": [
{
"p": "Aprendo <strong>Gestisci le applicazioni OCI installate</strong>, vengono prima rimossi i resti dei contenitori che non esistono su alcun nodo del cluster: il record conservato come cronologia dopo l’eliminazione dall’interfaccia Proxmox e i file sull’host lasciati da una rimozione. Un record con un’operazione incompleta viene conservato, perché il relativo backup potrebbe ancora servire. Volumi e directory dell’host non vengono mai eliminati per deduzione."
}
]
},
{
"id": "cluster",
"title": "In un cluster: migrazione e elevata disponibilità",
"intro": "Un contenitore OCI è un normale LXC Proxmox: può essere migrato o gestito da HA come gli altri, con gli stessi limiti. Ciò che gli serve per avviarsi viene conservato dove ogni nodo del cluster può trovarlo.",
"blocks": [
{
"table": {
"headers": [
"Parte",
"Su un altro nodo del cluster"
],
"rows": [
[
"Registro della console",
"Il contenitore crea <code>/var/log/proxmenux/oci</code> prima di avviarsi, su qualunque nodo lo esegua. Ogni nodo conserva il log degli avvii eseguiti su quel nodo."
],
[
"Sysctl di rete e monitor dell’host",
"Tenuto in <code>/etc/pve/proxmenux</code>, che ogni nodo del cluster condivide, quindi un contenitore migrato li trova."
],
[
"Dischi del contenitore",
"Proxmox li sposta con il contenitore. HA richiede che i dati siano disponibili sul nodo di destinazione tramite storage condiviso o una configurazione di replica supportata."
],
[
"directory e dispositivi host",
"Valgono le stesse regole degli altri LXC: una directory dell’host deve esistere sul nodo di destinazione ed essere contrassegnata come condivisa, e una GPU, un Coral o una NPU deve essere presente su quel nodo."
],
[
"Record ProxMenux",
"Il contratto resta sul nodo in cui l’applicazione è stata installata e ogni nodo legge la copia conservata in <code>/etc/pve/priv/proxmenux/oci</code>. Dopo la migrazione, un’applicazione con un solo contenitore viene registrata sul nodo di destinazione quando si apre <strong>Gestisci le applicazioni OCI installate</strong> o si avvia un’operazione su di essa. Per un’applicazione con più contenitori viene proposto il recupero, perché la rete privata deve essere creata su quel nodo."
]
]
}
},
{
"calloutWarning": {
"title": "Non per alta disponibilità",
"body": "Un'applicazione multicontainer raggiunge i suoi membri attraverso un ponte privato del nodo su cui è stato installato, quindi i suoi membri rimangono su quel nodo. Un monitor host, come Glances in modalità host o Netdata, monitora il nodo su cui corre; spostandolo monitorerebbe un altro nodo."
}
},
{
"p": "Quando si recupera l’applicazione, un backup ripristinato fuori dal cluster riceve i file di <code>/etc/pve/proxmenux</code> usati dal contenitore."
}
]
},
{
"id": "channel",
"title": "Un rolling tag non è un aggiornamento incustodito",
"blocks": [
{
"p": "Il catalogo installa il rolling tag pubblicato dal manutentore, ma il digest effettivo viene risolto e registrato e cambia solo con un aggiornamento esplicito, dotato di controlli preliminari e rollback. <monitorLink>ProxMenux Monitor</monitorLink> confronta il digest installato con quello pubblicato dal registro e segnala, anche con una notifica, la disponibilità di una nuova immagine."
}
]
}
]
}
web/messages/it/docs/oci-manager/monitor.json
+213
View File
@@ -0,0 +1,213 @@
{
"meta": {
"title": "Contenitori OCI in ProxMenux Monitor | ProxMenux",
"description": "Ciò che ProxMenux Monitor mostra per un contenitore installato da OCI manager Apps: versioni di applicazione e immagine, nuove immagini, uscita console e terminale Proxmox VE."
},
"header": {
"title": "In ProxMenux Monitor",
"description": "Un contenitore installato da OCI manager Apps appare in VMs & LXCs come qualsiasi altro LXC. Il suo modal legge il record di installazione: versioni di applicazione e immagine, nuove immagini, uscita console e terminale.",
"section": "OCI manager Apps"
},
"sections": [
{
"id": "intro",
"blocks": [
{
"calloutInfo": {
"title": "Il record è la fonte",
"body": "OCI manager Apps sa cosa ha installato e da dove viene. Il Monitor legge quel record di installazione invece di interrogare il container, quindi i dati sono gli stessi se il contenitore è in esecuzione o interrotto."
}
},
{
"table": {
"headers": [
"Scheda",
"Quali cambiamenti per un contenitore OCI"
],
"rows": [
[
"Stato",
"Un commutatore <strong>Watchdog</strong> sotto Start al boot: l'applicazione viene riavviata quando si ferma da sola"
],
[
"App",
"L'applicazione è identificata dal record, e gli aggiornamenti sono tracciati dall'immagine"
],
[
"Aggiornamenti",
"L'immagine viene aggiornata o l'applicazione modificata, con lo stesso flusso del menu OCI"
],
[
"Montaggi",
"Dischi del container e directory dell’host, con il relativo utilizzo"
],
[
"Log",
"Solo per contenitori OCI: l'uscita della console dell'applicazione"
]
]
}
}
]
},
{
"id": "app",
"title": "App",
"intro": "La scheda <appLink>App</appLink> offre l'applicazione installata come rilevamento, con il nome, il logo, la porta e lo schema del record. Registrandolo si apre l'editor con il metodo <strong>Immagine OCI (installata da ProxMenux)</strong>, che non ha bisogno di configurazione.",
"blocks": [
{
"cards": {
"items": [
{
"icon": "boxes",
"title": "Applicazione",
"body": "La versione dell'applicazione all'interno dell'immagine, letta dall'immagine stessa: il suo ambiente o la sua etichetta <code>org.opencontainers.image.version</code>. È informativo."
},
{
"icon": "archive",
"title": "Immagine",
"body": "La data di creazione e digest dell'immagine installata. L'aggiornamento si decide qui: il digest installato viene confrontato con quello che il registro pubblica oggi per lo stesso tag."
}
]
}
},
{
"list": {
"items": [
"Quando il registro pubblica un nuovo digest, la scheda mostra <strong>Nuova immagine</strong> con la sua data e digest, anche se la versione dell'applicazione al suo interno non è cambiata: una ricostruzione su una base aggiornata è un aggiornamento.",
"Quando i digest coincidono, la scheda mostra <strong>Versione</strong>.",
"La scheda si collega al repository dell'immagine: il suo progetto GitHub, o la sua pagina Hub Docker per un'immagine ufficiale.",
"Il collegamento di accesso utilizza l'indirizzo LAN del contenitore, anche per il membro principale di un'applicazione multi-container, che ha un secondo indirizzo sulla sua rete privata.",
"Il pulsante <strong>Aggiorna dati</strong> rilegge il record dell’installazione e il registro delle immagini. Non vengono proposte opzioni per cercare o registrare altre applicazioni: il container contiene esattamente l’applicazione descritta nel suo record."
]
}
},
{
"figure": {
"src": "/oci-manager/monitor-app-tab.png",
"alt": "Scheda App di un contenitore OCI con la versione dell'applicazione, l'immagine e il link del repository",
"caption": "Scheda app di un contenitore installato da OCI manager Apps."
}
},
{
"p": "Il controllo viene eseguito una volta al giorno con i controlli di aggiornamento del Monitor e <strong>Aggiorna dati</strong> lo esegue subito. Una nuova immagine viene inviata come notifica attraverso i canali configurati in <notificationsLink>Notifiche</notificationsLink>. L'aggiornamento viene applicato dalla scheda Aggiornamenti."
}
]
},
{
"id": "updates",
"title": "Aggiornamenti",
"intro": "Per un contenitore installato da OCI manager Apps la scheda Aggiornamenti mostra l'applicazione con la sua immagine installata e, quando il registro pubblica una, la nuova immagine, nello stesso formato di qualsiasi altra applicazione. Gli strumenti di aggiornamento di pacchetti e applicazioni di un normale LXC non appaiono.",
"blocks": [
{
"table": {
"headers": [
"Pulsante",
"Che cosa si apre"
],
"rows": [
[
"Aggiornamento",
"L’aggiornamento di <lifecycleLink>Gestisci applicazioni OCI installate</lifecycleLink> per questo container, nel terminale di Monitor. Può essere eseguito anche senza una nuova immagine; in quel caso non cambia nulla. In un’applicazione composta da più container aggiorna tutti i membri."
],
[
"Modifica",
"L'editor dell'applicazione (risorse, rete, percorsi e GPU). In un'applicazione multi-container aggiunge o rimuove i percorsi e i dispositivi aggiuntivi del contenitore di applicazione e, in Immich, cambia ciò che esegue il riconoscimento."
],
[
"Recupera",
"Sostituisce l'aggiornamento quando un'operazione sul contenitore è stata interrotta e apre il suo recupero."
],
[
"Recupera (container ripristinato)",
"Mostrato per un container ripristinato da un backup che non ha un contratto su questo host, sotto <strong>Applicazione OCI ripristinata</strong>. Apre il <lifecycleLink>recupero</lifecycleLink> nel terminale di Monitor; Aggiorna e Modifica compaiono dopo la registrazione."
]
]
}
},
{
"p": "Modifiche esterne, directory dell’host e applicazioni composte da più container vengono gestite come nel menu OCI. Per queste applicazioni, pulsanti e opzioni compaiono solo nel container principale. Gli altri membri mostrano la propria immagine, una nota che rimanda al principale per gli aggiornamenti e un pulsante per aprirlo. Alla chiusura del terminale vengono riletti l’immagine, il record e i montaggi."
},
{
"table": {
"headers": [
"Opzione",
"Comportamento"
],
"rows": [
[
"Conserva il backup eseguito prima dell'aggiornamento",
"Ogni aggiornamento esegue il backup del container per ripristinarlo se l'aggiornamento non riesce. Con questa opzione, lo stesso backup viene mantenuto nello storage scelto e compare tra i backup del CT; su Proxmox Backup Server viene scritto un backup prima dell'aggiornamento."
],
[
"Aggiornamenti pianificati",
"L’immagine viene aggiornata all’ora scelta solo se il registro ne pubblica una nuova, con la possibilità di attendere che abbia 1, 3, 7 o 14 giorni. Un container modificato al di fuori di ProxMenux viene saltato e segnalato."
]
]
}
}
]
},
{
"id": "logs",
"title": "Log",
"intro": "La scheda Logs appare solo per i contenitori installati da OCI manager Apps, tra Mounts e Backups. Mostra l'uscita standard e l'errore del processo principale dell'immagine, la stessa uscita mostra <code>docker logs</code> per un contenitore Docker.",
"blocks": [
{
"list": {
"items": [
"L'output viene mantenuto sull'host in <code>/var/log/proxmenux/oci/VMID.console.log</code> (mode 0600), dal primo avvio e attraverso riavviamenti, in modo da poter essere letto con il contenitore fermato.",
"Il file viene ruotato a 10 MB, mantenendo tre copie compresse (<code>/etc/logrotate.d/proxmenux-oci</code>).",
"Ogni avvio del contenitore è contrassegnato nell'uscita. La scheda mostra l'output dall'ultimo avvio per impostazione predefinita; <strong>Cronologia completa</strong> mostra anche quelli precedenti.",
"Quando l'applicazione viene rimossa, la sua uscita viene rimossa con essa.",
"Vengono mostrate le ultime 100, 500 o 1000 righe. Mentre il container è in esecuzione, le nuove righe sono seguite in tempo reale; scorrere verso l’alto mette in pausa il seguito e <strong>Segui</strong> lo riprende.",
"Un filtro mostra solo le linee che contengono un testo e <strong>Scarica</strong> salva le linee caricate.",
"I codici a colori sono rimossi e una linea che una barra di avanzamento ridisegna è mostrata nel suo stato finale.",
"La scheda legge il file a ogni apertura; non usa una copia in cache."
]
}
},
{
"calloutInfo": {
"title": "credenziali di primo avviamento",
"body": "Le immagini che stampano una password generata sul loro primo inizio lo lasciano in questa uscita, come fa <code>docker logs</code>. L'installatore lo legge da lì per mostrarlo nel suo riassunto."
}
},
{
"figure": {
"src": "/oci-manager/monitor-logs-tab.png",
"alt": "Scheda di log con l'uscita della console di un contenitore OCI, il selettore della linea, il filtro e il pulsante seguente",
"caption": "Uscita console di un contenitore OCI."
}
}
]
},
{
"id": "terminal",
"title": "Console Proxmox VE",
"blocks": [
{
"p": "Un'immagine OCI esegue il proprio processo come PID 1 e nessun servizio di login, quindi la console predefinita di un LXC aprirebbe un terminale in cui nulla risponde. I contenitori installati da OCI manager Apps sono creati con <code>cmode: shell</code>: la console Proxmox VE apre una shell con <code>lxc-attach</code>, l'equivalente di <code>docker exec</code>, con l'applicazione in esecuzione intatta."
},
{
"list": {
"items": [
"La shell è quella assegnata a root nell’immagine da <code>/etc/passwd</code>. Se root non ha una shell o l’immagine non ne include alcuna, viene mantenuta la console predefinita.",
"La shell viene eseguita come root all'interno del contenitore, senza una password. Chi può aprirlo è deciso dal permesso <code>VM.Console</code> di Proxmox VE.",
"Il terminale del Monitor entra nel contenitore con <code>pct enter</code>, che funziona allo stesso modo."
]
}
}
]
},
{
"id": "mounts",
"title": "Montaggi",
"blocks": [
{
"p": "La scheda <mountsLink>Mounts</mountsLink> elenca i dischi container e le directory host del contenitore. L'uso di un disco contenitore su blocco di archiviazione come LVM-thin è letto dal filesystem del disco, che è montato solo all'interno del contenitore."
}
]
}
]
}
web/messages/it/docs/oci-manager/stacks.json
+404
View File
@@ -0,0 +1,404 @@
{
"meta": {
"title": "Applicazioni multicontainer | ProxMenux",
"description": "Come OCI manager Apps trasforma un'applicazione con il suo database e la cache in LXCs nativi coordinati: piano, rete privata, gancio di dipendenza, convalida e aggiornamenti transazionali."
},
"header": {
"title": "Applicazioni con più container",
"description": "Un'applicazione con il suo database, la cache e altri servizi diventa diversi LXC nativi coordinati, installati e aggiornati come uno.",
"section": "OCI manager Apps"
},
"sections": [
{
"id": "intro",
"blocks": [
{
"calloutInfo": {
"title": "Un'applicazione per l'utente, diversi LXC per Proxmox VE",
"body": "Una definizione multi-container è una voce del catalogo. L'installatore crea un LXC nativo per servizio e mantiene esplicite le proprie dipendenze. Immich, Nextcloud, Paperless-ngx e Tandoor sono installati in questo modo."
}
},
{
"mermaid": {
"chartCode": "flowchart LR\n C[\"Docker Compose\"] --> O[\"{{plan}}\"]\n O --> A[\"{{app}}<br/>{{appNet}}\"]\n O --> D[\"{{db}}<br/>{{private}}\"]\n O --> R[\"{{cache}}<br/>{{private}}\"]\n V1[(\"config\")] --> A\n V2[(\"database\")] --> D\n V3[(\"cache\")] --> R\n D --> A\n R --> A",
"labels": {
"plan": "Piano di stack",
"app": "Applicazione LXC",
"appNet": "LAN + privato",
"db": "PostgreSQL LXC",
"cache": "Valkey LXC",
"private": "privato"
}
}
}
]
},
{
"id": "plan",
"title": "1. Il piano, prima che esista un contenitore",
"blocks": [
{
"p": "Nessun LXC viene creato mentre la definizione Compose viene interpretata. Un piano completo arriva prima, con ogni membro, immagine, VMID, rete, percorso, segreto, ordine e controllo sanitario. Se il piano non è coerente, l'installazione non inizia."
},
{
"table": {
"headers": [
"Elemento di piano",
"Contenuto",
"Controllato prima di creare qualcosa"
],
"rows": [
[
"Membri",
"Applicazione principale, database, cache, machine learning e altre dipendenze",
"VMID unici, ruoli noti e esattamente un membro principale"
],
[
"Immagini",
"Riferimento rolling, architettura e digest risolto di ogni servizio",
"Tutte esistono, supportano l’architettura e superano il controllo di integrità OCI"
],
[
"Rete",
"Ponte privato, subnet, indirizzo fisso per servizio e accesso LAN per il membro principale",
"Nessuna collisione con ponti o sottorete esistenti e nessun indirizzo ripetuto"
],
[
"Persistenza",
"Dischi dei container, directory dell’host, proprietari e backup",
"Nessun percorso sovrapposto, deposito disponibile e permessi dichiarati"
],
[
"Segreti",
"password del database, chiavi dell'applicazione e credenziali iniziali",
"Generati una volta e forniti solo ai membri che li usano"
],
[
"Ciclo di vita",
"Ordine di inizio, ordine di arresto e un controllo sanitario per membro",
"L'applicazione principale inizia l'ultima e si ferma prima"
]
]
}
}
]
},
{
"id": "create",
"title": "2. Creazione, membro per membro",
"blocks": [
{
"steps": {
"items": [
{
"title": "Prenota ogni VMID",
"body": "L'inventario Proxmox VE e il registro delle istanze sono controllati. Un CT esistente non è adottato e un contratto che appartiene ancora ad un'altra istanza non viene riutilizzato."
},
{
"title": "Preparare ogni immagine",
"body": "Tutte le immagini vengono risolte, scaricate e verificate prima che venga creato il primo contenitore."
},
{
"title": "Creare ogni rootfs",
"body": "I metadati OCI ufficiali sono importati, e l'identità di istanza ProxMenux e il ruolo membro sono aggiunti."
},
{
"title": "Rete privata",
"body": "Viene creato un ponte e una subnet e ogni membro riceve il suo indirizzo fisso; solo il membro principale riceve anche l'interfaccia LAN."
},
{
"title": "Persistenza",
"body": "Ogni database e configurazione ottiene il proprio disco contenitore; solo i dati destinati ad essere condivisi utilizzano directory host."
},
{
"title": "Ambiente",
"body": "Vengono scritti endpoint interni, segreti condivisi e variabili di servizio. L'applicazione raggiunge le sue dipendenze nei loro indirizzi privati riservati."
},
{
"title": "Registrazione",
"body": "Ogni membro registra la sua configurazione nativa, le modifiche rootfs che gli aggiornamenti devono riprodurre e la sua relazione con lo stack."
}
]
}
}
]
},
{
"id": "checks",
"title": "3. Avviare e controllare ogni contenitore",
"intro": "Un LXC creato non significa un servizio pronto. Le dipendenze iniziano in ordine e ognuno passa un controllo specifico al suo servizio.",
"blocks": [
{
"table": {
"headers": [
"Servizio",
"Controllo",
"Cosa mostra"
],
"rows": [
[
"PostgreSQL",
"<code>pg_isready</code> nel CT con l'host previsto, l'utente e il database",
"Il server accetta le connessioni per il database configurato"
],
[
"Redis / Valkey",
"<code>redis-cli</code> o <code>valkey-cli</code> <code>PING</code> contro il suo indirizzo privato",
"Il broker ascolta e risponde"
],
[
"Machine learning Immich",
"HTTP <code>GET /ping</code>, oltre a un controllo del runtime GPU selezionato",
"Il servizio risponde e l’accelerazione richiesta non è passata alla CPU"
],
[
"Nextcloud",
"<code>GET /status.php</code> con <code>installed=true</code>, <code>maintenance=false</code> e <code>needsDbUpgrade=false</code>",
"Inizializzazione terminata senza migrazione in sospeso"
],
[
"Paperless-ngx / Tandoor",
"HTTP sull'indirizzo LAN e vera porta del servizio",
"Il frontend e le sue dipendenze servono l'applicazione"
],
[
"Applicazione principale",
"Il punto finale del suo modello, ad esempio <code>/api/server/ping</code> in Immich",
"L'intero stack funziona attraverso l'applicazione che utilizza le dipendenze"
]
]
}
},
{
"calloutWarning": {
"title": "In esecuzione non significa funzionante",
"body": "Lo stato in esecuzione dice solo che esiste il processo LXC. Se il servizio offre un controllo migliore, viene utilizzato un controllo exec o HTTP con un timeout. Se un membro si ferma o non supera la verifica, lo stack non viene dichiarato installato."
}
}
]
},
{
"id": "hook",
"title": "4. Il gancio di dipendenza",
"blocks": [
{
"p": "Il gancio è impostato solo sul contenitore principale di uno stack dipendente. Proxmox VE mantiene lo script come snippet e lo gestisce come <code>hookscript</code> di quel CT. La ricetta dello stack non è scritta nello script: vive in un contratto privato separato."
},
{
"codeGrid": {
"items": [
{
"title": "Configurazione principale CT",
"code": "hookscript: local:snippets/proxmenux-stack-dependencies.sh"
},
{
"title": "Contratto privato (esempio)",
"code": "/etc/pve/priv/proxmenux-stack-VMID.json\n{\n \"schema\": 1,\n \"stack\": \"immich\",\n \"dependencies\": [\n {\"vmid\": 107, \"label\": \"PostgreSQL\", \"healthcheck\": {...}},\n {\"vmid\": 108, \"label\": \"Valkey\", \"healthcheck\": {...}},\n {\"vmid\": 106, \"label\": \"Machine Learning\", \"healthcheck\": {...}}\n ]\n}"
}
]
}
},
{
"snippet": {
"summary": "Fonte completa di proxmenux-stack-dependencies.sh",
"pathCode": "local:snippets/proxmenux-stack-dependencies.sh",
"snippetCode": "stackDependencyHook"
}
},
{
"p": "Lo script è lo stesso per ogni stack. VMID, nomi, tipi di controllo e timeout provengono dal contratto privato <code>/etc/pve/priv/proxmenux-stack-VMID.json</code> di ogni stack."
},
{
"steps": {
"items": [
{
"title": "Proxmox VE chiama pre-start",
"body": "Prima dell'avvio principale di CT, il gancio viene eseguito con il VMID e la fase del ciclo di vita."
},
{
"title": "Un blocco per stack",
"body": "<code>flock</code> su <code>/run/lock/proxmenux-stack-VMID.lock</code> previene due sequenze di avvio contemporaneamente."
},
{
"title": "Il contratto viene letto e convalidato",
"body": "Uno schema noto, dipendenze numeriche, etichette, un exec, http o controllo in esecuzione e un timeout positivo sono necessari."
},
{
"title": "Dipendenze in ordine",
"body": "Ogni CT deve esistere; se è fermo viene avviato, se è già in esecuzione non viene riavviato."
},
{
"title": "Attendi che il servizio sia pronto",
"body": "Il controllo viene eseguito ogni due secondi, e il CT è confermato anche di essere ancora in esecuzione."
},
{
"title": "Il principale CT inizia",
"body": "Quando ogni dipendenza è pronta, pre-start termina e Proxmox VE avvia l'applicazione."
}
]
}
},
{
"calloutInfo": {
"title": "Il gancio non ferma le dipendenze",
"body": "Le fasi post-start, pre-stop e post-stop non fanno nulla. Arrestare il CT principale lascia in esecuzione PostgreSQL, Redis, Valkey o il machine learning. L’hook ordina l’avvio; non trasforma diversi LXC in un unico processo."
}
},
{
"table": {
"headers": [
"Tipo",
"Esempio",
"Avvii successivi"
],
"rows": [
[
"stack dipendente",
"Immich, Nextcloud, applicazione con PostgreSQL",
"L’hook del CT principale avvia le dipendenze e attende che siano pronte."
],
[
"Suite di applicazione",
"Suite Arr",
"Nessun membro principale: ogni LXC segue il proprio <code>onboot</code>"
],
[
"Applicazione singola",
"Jellyfin",
"Proxmox VE avvia direttamente LXC"
]
]
}
}
]
},
{
"id": "stack-checks",
"title": "5. Controlla sullo stack nel suo complesso",
"blocks": [
{
"list": {
"items": [
"Ogni VMID esiste, è unico e mantiene l'identità di istanza prevista.",
"Ogni contratto appartiene allo stesso stack, mantiene il suo ruolo e la sua configurazione nativa registrata.",
"Il membro principale è l’ultimo in <code>start_order</code> e il primo in <code>stop_order</code>.",
"Nessun membro, volume o adattamento rootfs manca.",
"Il gancio punta al snippet ufficiale, il suo contenuto è invariato e il suo contratto corrisponde alla ricetta stack.",
"Le immagini e i digest osservati corrispondono agli archivi OCI preparati.",
"Dispositivi, profili GPU, montaggi, segreti ed endpoint corrispondono ancora ai contratti.",
"Quando tutte le dipendenze superano i controlli, l’endpoint dell’applicazione principale verifica l’integrazione fra i membri."
]
}
}
]
},
{
"id": "manage",
"title": "Gestione di uno stack installato",
"intro": "In <strong>Gestisci applicazioni OCI installate</strong>, qualsiasi membro porta all’intero stack. Il menu offre <strong>Aggiorna tutti i container dell’applicazione</strong>, <strong>Modifica percorsi e dispositivi aggiuntivi</strong>, <strong>Ricrea tutti i container con la configurazione salvata</strong> e <strong>Rimuovi: elimina l’applicazione e i suoi container</strong>. Ricrea ricostruisce ogni container dall’immagine originale tramite il digest salvato, senza cercarne una più recente, seguendo gli stessi passaggi di un aggiornamento. È disponibile per gli stack aggiornabili.",
"blocks": [
{
"steps": {
"items": [
{
"title": "Qualsiasi membro",
"body": "Il contratto dei membri nomina il VMID principale e l'elenco completo dei membri."
},
{
"title": "Lo stack è riproducibile",
"body": "Identità, contratti, gancio, adattamenti e una ripetizione coordinata per quella ricetta sono convalidati."
},
{
"title": "Immagini prima",
"body": "L'applicazione non viene fermata fino a quando ogni digest è stato risolto, scaricato e verificato."
},
{
"title": "Arresta i componenti e crea un backup dell'insieme",
"body": "I backup nativi verificati sono presi con lo stack fermato, quindi l'applicazione e i database appartengono allo stesso momento."
},
{
"title": "Aggiornare e controllare ogni membro",
"body": "Adattamento, rete, montaggi, segreti e dispositivi vengono applicati nuovamente prima del controllo di integrità di ciascun membro."
},
{
"title": "Pubblica o recupera tutto",
"body": "I nuovi contratti sono pubblicati solo quando ogni membro passa. Se uno fallisce, ogni membro viene ripristinato."
}
]
}
},
{
"table": {
"headers": [
"Modifica",
"Quali cambiamenti",
"Cosa viene conservato"
],
"rows": [
[
"Percorsi e dispositivi aggiuntivi",
"Vengono aggiunti o rimossi dal contenitore di applicazione, che si riavvia. Nulla è ricostruito",
"I dati dell'applicazione, il suo database e gli altri contenitori"
],
[
"Che cosa esegue il riconoscimento (Immich)",
"Il contenitore di apprendimento automatico prende l'immagine e i dispositivi del CPU o di un GPU dell'host. L'intera applicazione viene interrotta e aggiornata, come in un aggiornamento",
"La cache del modello, la libreria e il database. Se qualcosa fallisce, i contenitori precedenti e la scelta precedente vengono ripristinati"
]
]
}
},
{
"calloutWarning": {
"title": "Una pila senza un replay coordinato non è aggiornata",
"body": "Se la preparazione di uno stack non può essere riprodotta, l'aggiornamento viene rifiutato prima che lo stack venga interrotto. L'applicazione continua a funzionare come è."
}
}
]
},
{
"id": "failure",
"title": "6. Quando qualcosa fallisce",
"blocks": [
{
"p": "Durante un'installazione, un errore si ferma e rimuove i contenitori incompleti che l'operazione ha creato, e il ponte privato se l'operazione l'ha creata. Una pila non viene pubblicata come valida fino al termine dell'intera sequenza."
},
{
"p": "Un aggiornamento è transazionale: tutte le immagini sono preparate prima, poi lo stack si ferma, viene eseguito e verificato il backup di ogni membro, e solo allora è sostituito ogni rootfs. I membri iniziano uno per uno con il loro controllo sanitario; se uno fallisce, ogni membro viene ripristinato dalla stessa serie di backup, quindi il database e l'applicazione non appartengono mai a momenti diversi."
},
{
"mermaid": {
"chartCode": "flowchart LR\n P[\"{{prepare}}\"] --> S[\"{{stop}}\"]\n S --> B[\"{{backup}}\"]\n B --> R[\"{{replace}}\"]\n R --> H{\"{{healthy}}\"}\n H -- \"{{yes}}\" --> C[\"{{commit}}\"]\n H -- \"{{no}}\" --> X[\"{{rollback}}\"]",
"labels": {
"prepare": "Preparare ogni immagine",
"stop": "Stop, primo membro principale",
"backup": "Backup verificato di ogni CT",
"replace": "Sostituisci il rootfs",
"healthy": "Tutti funzionanti?",
"yes": "Sì",
"no": "No",
"commit": "Pubblica i contratti",
"rollback": "Ripristinare ogni membro"
}
}
}
]
},
{
"id": "not-assumed",
"title": "Che cosa uno stack non include",
"blocks": [
{
"list": {
"items": [
"Una suite installata in un unico flusso, come la suite Arr, non è uno stack dipendente: i suoi contenitori non hanno ordine di partenza tra di loro.",
"La rete privata non sostituisce l'autenticazione, TLS o la configurazione di ogni applicazione.",
"Il backup di un LXC non contiene il ponte, il gancio o i contratti del resto dello stack.",
"Prowlarr, Sonarr o Radarr non ricevono indici, profili o fornitori da ProxMenux."
]
}
}
]
}
]
}
web/messages/it/docs/oci-manager/storage-network.json
+305
View File
@@ -0,0 +1,305 @@
{
"meta": {
"title": "Dati, percorsi e rete | ProxMenux",
"description": "Come OCI manager Apps conserva i dati di un container OCI: dischi del container, directory dell’host, mount con rclone, indirizzi e reti private."
},
"header": {
"title": "Dati, percorsi e rete",
"description": "Cosa risiede nel rootfs, cosa viene conservato quando lo si sostituisce, come si condividono i dati tra container e come ciascuno ottiene il proprio indirizzo.",
"section": "OCI manager Apps"
},
"sections": [
{
"id": "intro",
"blocks": [
{
"calloutInfo": {
"title": "La persistenza si decide prima di creare l’LXC",
"body": "I volumi dichiarati dall’immagine e dal suo file Compose vengono letti prima di creare il container. Ogni percorso da conservare dopo un aggiornamento diventa un punto di mount indipendente dal rootfs. In questo modo, il rootfs contiene solo ciò che appartiene all’immagine e può essere sostituito."
}
}
]
},
{
"id": "questions",
"title": "Cosa chiede l’installer",
"intro": "Il modello fornisce i percorsi necessari all’applicazione. Ciascuno viene collocato su un disco del container o in una directory dell’host; prima del riepilogo si possono aggiungere altri percorsi.",
"blocks": [
{
"steps": {
"items": [
{
"title": "Percorsi necessari",
"body": "Vengono elencati <code>/config</code>, <code>/data</code>, librerie, download e tutti i volumi dichiarati dall’applicazione."
},
{
"title": "Posizione",
"body": "Ogni percorso viene collocato su un disco del container o in una directory già esistente sull’host."
},
{
"title": "Storage e dimensione",
"body": "Viene creato un disco del container su uno storage Proxmox VE con la dimensione indicata. L’installazione predefinita usa <code>local-lvm</code>; quella avanzata chiede lo storage di ogni percorso subito prima della dimensione e propone quello del rootfs. Il disco appare come <code>vm-VMID-disk-N</code> e viene collegato come <code>mpN</code>."
},
{
"title": "Directory dell’host",
"body": "La directory dell’host viene indicata tramite il suo percorso. Se non esiste, viene creata e assegnata all’utente dell’host a cui viene mappato quello del container."
},
{
"title": "Percorsi aggiuntivi",
"body": "Prima dell’installazione si possono aggiungere altre coppie formate da un percorso o volume dell’host e dal relativo percorso nel container."
},
{
"title": "Riepilogo",
"body": "La mappatura completa viene mostrata prima della creazione del CT e salvata nel contratto dell’istanza."
}
]
}
}
]
},
{
"id": "options",
"title": "Le due posizioni persistenti",
"blocks": [
{
"table": {
"headers": [
"Proprietà",
"Disco del container",
"Directory dell’host"
],
"rows": [
[
"Nella configurazione",
"<code>mpN: STORAGE:vm-VMID-disk-N,mp=/config,backup=1,size=16G</code>",
"<code>mpN: /mnt/oci-shared/media,mp=/data/media</code>"
],
[
"Backup del container (vzdump)",
"Incluso con <code>backup=1</code>",
"Non incluso"
],
[
"Dimensione",
"Fissa; si aumenta ridimensionando il punto di mount",
"Lo spazio libero del filesystem o del dataset dell’host"
],
[
"Altri container",
"Montato solo dal container a cui appartiene",
"La stessa directory può essere montata in più container"
],
[
"Snapshot e ripristino",
"Gestiti da Proxmox VE insieme al CT",
"Gestiti sullo storage dell’host"
],
[
"Rimozione dell’applicazione",
"Eliminato con il container",
"Conservato con il suo contenuto"
],
[
"Spostamento del CT su un altro nodo",
"Si sposta con il CT",
"Lo stesso percorso deve esistere sull’altro nodo"
]
]
}
},
{
"p": "Il rootfs è riservato ai binari e al contenuto dell’immagine. Un aggiornamento o una ricreazione lo sostituisce senza toccare nessuno dei due tipi di punto di mount."
}
]
},
{
"id": "example",
"title": "Esempio: un container con entrambe le posizioni",
"blocks": [
{
"code": {
"title": "Jellyfin installato come CT 151 su local-lvm (estratto)",
"code": "rootfs: local-lvm:vm-151-disk-0,size=8G\n# Container disk, part of the CT backup\nmp0: local-lvm:vm-151-disk-1,mp=/config,backup=1,size=16G\n\n# Host directory, outside the CT backup\nmp1: /mnt/oci-shared/media,mp=/data/media"
}
},
{
"p": "Un aggiornamento o una ricreazione sostituisce solo il rootfs: <code>mp0</code> conserva utenti, librerie e impostazioni, mentre <code>mp1</code> continua a mostrare gli stessi contenuti multimediali. Il ripristino del backup del CT recupera <code>/config</code>; se necessario, la directory dei contenuti multimediali viene ripristinata dal backup dello storage dell’host."
},
{
"flow": {
"nodes": [
{
"label": "Contratto",
"detail": "/config"
},
{
"label": "Posizione",
"detail": "Disco del container\no directory dell’host"
},
{
"label": "LXC",
"detail": "Sempre /config\nper l’applicazione"
}
],
"caption": "L’applicazione vede il percorso dichiarato dall’immagine; cambia solo dove viene memorizzato."
}
}
]
},
{
"id": "shared",
"title": "Una directory dell’host, più container",
"blocks": [
{
"mermaid": {
"chartCode": "flowchart TB\n H[\"{{host}}<br/>/mnt/oci-shared/media\"]\n H --> Q[\"qBittorrent<br/>/data\"]\n H --> J[\"Jellyfin<br/>/data\"]\n H --> R[\"Radarr / Sonarr<br/>/data\"]\n Q -. \"{{config}}\" .-> QV[(\"/config mpN\")]\n J -. \"{{config}}\" .-> JV[(\"/config mpN\")]\n R -. \"{{config}}\" .-> RV[(\"/config mpN\")]",
"labels": {
"host": "Directory dell’host",
"config": "Configurazione propria"
}
}
},
{
"p": "Ogni container conserva la propria configurazione sul suo disco. La libreria o i download si trovano in un’unica directory dell’host, montata nello stesso percorso interno in tutti i container. Così il percorso in cui scrive un’applicazione è lo stesso da cui legge un’altra."
}
]
},
{
"id": "rclone",
"title": "Storage cloud tramite l’applicazione rclone",
"intro": "Oltre all’installazione, la scheda di rclone nel catalogo offre <strong>Abilita un mount in un container OCI rclone esistente</strong>. Viene montato un remote già creato e autorizzato nell’interfaccia web di rclone, che viene poi reso disponibile sull’host. Gli altri container possono usarlo come una directory dell’host.",
"blocks": [
{
"steps": {
"items": [
{
"title": "Container e remote",
"body": "Il VMID del container rclone, il nome esatto del remote e, facoltativamente, un percorso al suo interno."
},
{
"title": "Nome del mount e cache",
"body": "Il nome del mount e la modalità della cache VFS: <code>off</code>, <code>minimal</code>, <code>writes</code> o <code>full</code> (predefinita)."
},
{
"title": "Viste pubblicate",
"body": "Una radice comune, <code>/mnt/oci-shared</code> per impostazione predefinita, contiene una vista in lettura e scrittura in <code>/mnt/oci-shared/remotes/NAME</code> e una in sola lettura in <code>/mnt/oci-shared/remotes-ro/NAME</code>."
},
{
"title": "Attivazione",
"body": "Dopo la conferma, il CT viene arrestato, vengono configurati il suo comando di avvio e un hookscript di Proxmox VE, quindi viene riavviato. L’operazione attende che entrambe le viste siano montate sull’host."
}
]
}
},
{
"calloutInfo": {
"title": "Se il mount non viene attivato",
"body": "Viene ripristinata la configurazione precedente del container, che viene quindi riavviato. In questo modo, se l’attivazione fallisce, rclone resta com’era."
}
}
]
},
{
"id": "network",
"title": "Indirizzi e reti",
"intro": "Un’applicazione con un solo container ha bisogno di un indirizzo. Un’applicazione con più container richiede anche una rete stabile tra i suoi componenti.",
"blocks": [
{
"cards": {
"items": [
{
"icon": "network",
"title": "Applicazione con un solo container",
"body": "Si sceglie il bridge di rete e si imposta DHCP oppure un indirizzo fisso in formato CIDR. L’LXC ha un proprio indirizzo e il riepilogo mostra gli URL completi dei servizi."
},
{
"icon": "waypoints",
"title": "Applicazione con più container",
"body": "Viene individuata una sottorete libera e creato un bridge privato persistente. Ogni componente — applicazione, database e cache — riceve un indirizzo fisso su quella rete."
}
]
}
},
{
"flow": {
"nodes": [
{
"label": "LAN",
"detail": "Indirizzo raggiungibile\nsolo per il servizio principale"
},
{
"label": "LXC principale",
"detail": "Web / API\nLAN + rete privata"
},
{
"label": "Rete privata",
"detail": "PostgreSQL · Valkey · ML\nindirizzi fissi"
}
],
"caption": "Le dipendenze comunicano sulla rete privata e non hanno un indirizzo sulla LAN."
}
},
{
"p": "Il contratto dello stack conserva bridge, sottorete, indirizzi e relazioni tra i servizi. L’aggiornamento dell’applicazione riutilizza la stessa topologia per tutti i componenti. ProxMenux Monitor apre il container principale al suo indirizzo LAN, non a quello della rete privata."
}
]
},
{
"id": "ownership",
"title": "Proprietà di file e directory",
"blocks": [
{
"list": {
"items": [
"Le nuove directory vengono create con UID e GID a cui viene mappato l’LXC non privilegiato.",
"Il proprietario delle directory esistenti non viene modificato ricorsivamente.",
"Socket, file di sistema e percorsi sensibili non vengono proposti come directory generiche dell’host."
]
}
}
]
},
{
"id": "backup",
"title": "Cosa contiene un backup del container",
"blocks": [
{
"table": {
"headers": [
"Elemento",
"Nel backup vzdump del CT",
"Dove viene conservato"
],
"rows": [
[
"Rootfs OCI",
"Sì",
"Nel backup del CT; può anche essere ricreato dall’immagine e dal contratto"
],
[
"Disco del container con <code>backup=1</code>",
"Sì",
"Il backup del CT"
],
[
"Directory dell’host",
"No",
"Il backup dello storage dell’host"
],
[
"Contratto dell’istanza",
"Sì, la copia conservata nel CT",
"<code>/.proxmenux/oci-record.json</code> nel CT; le copie aggiuntive dell’host e del cluster sono conservate separatamente"
],
[
"Applicazione con più container",
"Ogni componente nel proprio backup",
"I backup di tutti i componenti, più il contratto dello stack e il suo bridge di rete sull’host"
]
]
}
}
]
}
]
}