Automazione del tema

Sviluppatore
1

Ciao a tutti, sono nuovo qui :slight_smile:
Sto eseguendo una versione Dockerizzata di bitnami Discourse (l’ultima) su un cluster Kubernetes, sembra davvero un ottimo progetto. Tuttavia, sto riscontrando un problema nel tentativo di automatizzare l’installazione di un tema. Essenzialmente, ho bisogno di creare, distribuire, eseguire e configurare questa immagine Docker da una CICD, in modo che al primo accesso tutto sia pronto. Per quanto riguarda le configurazioni, c’è l’installazione del tema personalizzato. Per quanto ho potuto capire da diversi forum e documentazioni, non esiste un modo nativo per installarlo programmaticamente, ho trovato solo una guida clicca per clicca (correggimi se sbaglio per favore).

La mia prima idea è stata quella di aggiungere i file del tema “manualmente” nel file system di Discourse tramite k8s, ma per quanto posso vedere Discourse gestisce i suoi file in modo strano, rinominandoli secondo la propria logica interna e rendendo impossibile la previsione.

Guardando più nel dettaglio ho trovato questa ottima cli chiamata discourse_theme, il problema qui è che avrei comunque bisogno di generare prima una chiave API da Discourse, altrimenti non può funzionare (di nuovo… correggimi se sbaglio).
Quindi, alla fine, ho un paio di domande:
innanzitutto, esiste un modo diverso/nativo per installare programmaticamente un tema in Discourse che mi è sfuggito?
e d’altra parte, esiste un modo per ottenere una chiave API da Discourse da uno script?
e alla fine, qualcuno conosce qualche trucco di Kubernetes per aggirare questo tipo di problema?

Molte grazie in anticipo
cordiali saluti

2

Questo è supportato quando si utilizza il nostro metodo di installazione ufficiale: Install a Theme programatically

1 Mi Piace
3

Penso che l’unica soluzione sia creare un’immagine che includa i plugin desiderati, caricarla su un repository Docker, avviarla con le variabili d’ambiente appropriate e, a un certo punto, vedere che il database è stato migrato e gli asset precompilati e caricati su S3 (almeno) alla prima esecuzione dell’immagine. Potresti voler eseguire la migrazione una volta con SKIP_POST_DEPLOYMENT_MIGRATIONS impostato mentre la vecchia immagine è in esecuzione e poi di nuovo dopo che la nuova immagine è stata avviata e le vecchie sono state arrestate con SKIP_POST_DEPLOYMENT_MIGRATIONS disattivato o eseguire il task rake db:ensure_post_migrations.

Puoi eseguire un task rake in una delle tue immagini in esecuzione, qualcosa come

         rake api_key:create_master['descrizione della chiave']

Quanto sopra potrebbe essere sufficiente per farti progredire un po’. Ho gestito istanze Kubernetes per clienti su GCP e AWS in passato. Non ero mai stato completamente soddisfatto di come funzionasse (funzionava perfettamente dal punto di vista del cliente, semplicemente non era molto elegante dal mio, ma non era così inelegante da darmi la pena di correggerlo, né!). Non ho molto altro da offrire qui, ma non esitare a contattarmi direttamente se hai bisogno di ulteriore aiuto.

1 Mi Piace