Closed francescor closed 5 years ago
Ciao in particolare quali sono i tuoi dubbi? Se vedi il compose utilizza postgres, mongodb, solr e redis. Mi sembra che mongodb non sia utilizzato. L'unica cosa di cui ti devi sincerare prima di mettere in produzione questo compose e' la persistenza dei dati. Questo puo' essere fatto in due modi: 1. bind di cartelle dell tuo filel system (cosa che ti consiglio solo se usi una distro linux) oppure tramite volumi. Basta creare un volume per salvare i dati dei db che ti interessano e fare un backup di questi volumi / riutilizzarli in caso di restart della applicazione.
Se mi dai maggiori dettagli possiamo lavorare a un fork del progetto per la tua esigenza e poi magari fare un pull request se lo riteniamo utile alla community.
ckan:
container_name: ckan
image: daf-ckan:1.0.0
links:
- db
- solr
- redis
ports:
- "5000:5000"
environment:
- CKAN_SITE_URL=http://localhost:5000
- DB_PORT_5432_TCP_ADDR=db
- SOLR_PORT_8983_TCP_ADDR=solr
- REDIS_PORT_6379_TCP_ADDR=redis
db:
container_name: db
image: ckan/postgresql:latest
solr:
container_name: solr
image: daf-ckan-solr:1.0.0
redis:
container_name: redis
image: redis:latest
mongodb:
container_name: mongo
image: bitnami/mongodb:latest
ports:
- "27017:27017"
environment:
- MONGODB_ROOT_PASSWORD=mongo
- MONGODB_USERNAME=ckan
- MONGODB_PASSWORD=ckan
- MONGODB_DATABASE=ckan
sì, la persistenza dei dati non è un problema, ed il s.o. tutto linux (ci mancherebbe). Da sistemista, il mio ruolo in questo setup sarebbe principalmente quello di tenere aggiornato il sistema operativo oltre a ckan stesso, postgres, ... Vedo, nel setup i "latest", quindi il rebuild ed il deploy di un nuovo container si prenda le ultime versioni, ma la migrazione dei dati? Certo potrei andare ad aggiornare entro il container, ma mi pare aggiungerei complicazione rispetto ad un setup ordinario in un container dedicato linux. (produzione, nel mio contesto, significa almeno 4/6 anni, con notevoli volumi ed accessi) Insomma, mi pare che se di produzione si tratta, sia piu indicata una installazione ordinaria (magari fatta con ricetta ansible).
Ok sicuramente ha senso:
Una domanda, ma tutte questi servizi li metteresti on premises o in cloud? ma tutti sulla stessa macchina ?
Adesso stiamo lavorando ad una evoluzione del container quindi si abbiamo intenzione di mantenere questa repo anche con alcune novità in sviluppo. Tra l'altro il docker vi elimina molti problemi che abbiamo incontrato durante l'installazione dei vari plugin.
Grazie per i riscontri. La produzione la metteremmo in un container dedicato entro proxmox in hetzner (o un'istanza di amazon dedicata), con il suo solr e mongo, per il postgres probabilmente iniziamo con una versione locale, per poi spostarci in un postgres carrozzato condiviso con altri servizi qualora il postgres locale arranchi. Si, trovare risolti i problemi di installazione è sicuramente un enorme aiuto. Non è che possiamo pensare ad una ricetta ansible per chi ha esigenze come la nostra? Contribuirei volentieri anche io (ed i miei colleghi)
Il lavoro sul docker dovrebbe partire questa settimana, per ansible sarebbe un lavoro utilissimo ma al momento non abbiamo risorse quindi sarebbe molto utile. Potreste impostare il lavoro con delle pull request.
Grazie mille
Chiuso per inattività.
vorremmo mettere in produzione il docker, ma abbiamo timori sul mantenimento di questo setup docker rispetto ad una installazione ordinaria: quanto praticabile/conveniente pensate sia mantenere aggiornato il software (ckan) entro il docker?