C'è un vantaggio in un'installazione Docker?

Installazione
1

So che la documentazione e molti thread qui suggeriscono che Docker sia l’unica (buona) strada da percorrere, ma volevo conoscere le motivazioni. Ho preso una macchina Debian su Amazon Lightsail da $3,50/mese e ho installato Discourse in 20 minuti. Ho usato rbenv per installare Ruby 3.2.2 e il resto è stato facile. Ho scoperto che Discourse non segue le convenzioni di Rails, ad esempio perché esiste un ./config/discourse.conf e GlobalSetting invece di config/environments/production.rb che specifica questi valori - è questo che le immagini Docker finiscono per creare (anche sidekiq.yml che non ha valori di produzione)?

C’è un vantaggio nell’eseguire questo su Docker? Mi chiedo se mi stia perdendo qualcosa…

2

La versione molto breve è che se non si utilizza l’installazione standard, non possiamo offrirvi assistenza qui. Ci sono troppe cose che possono andare storte se ci si discosta da quel percorso.

4 Mi Piace
3

Capito, sì, sistemi operativi diversi e altro. Qualcuno ha già chiesto come ho fatto, posterò qui nel caso.

È necessario Ruby 3.2.x (tramite rbenv, così non si dipende dal sistema operativo), Node v16.19.x/npm 8.19.x e PostgreSQL (probabilmente qualsiasi versione sopra la 11).

  1. Ho creato un file .ruby-version, che specificava la versione di ruby che ho installato (3.2.2).
  2. Ho eseguito bundle e tutte le gem sono state compilate senza problemi.
  3. All’interno di PostgreSQL stesso, ho dovuto configurare il database:
CREATE DATABASE discourse;
CREATE USER discourse WITH password 'fA....';
GRANT ALL PRIVILEGES ON DATABASE discourse TO discourse;
\c discourse
GRANT ALL ON SCHEMA public TO discourse;

Mi ha sorpreso che database.yml non accetti variabili production (questo sembra molto anti-convenzione Rails). Tutte le impostazioni del database erano in config/discourse.conf, insieme ai valori SMTP. Li ho compilati.

Quindi ho eseguito le migrazioni del database:

bundle exec rails db:migrate

Tutto ha funzionato bene e le migrazioni sono andate a buon fine.

  1. In config/sidekiq.yml, dopo la sezione development, ho aggiunto:
production:
  :concurrency: 2
  :queues:
    - [critical, 2]
    - [default, 1]
    - [low]
    - [ultra_low]
  1. Quindi modifica lib/tasks/assets.rake, intorno alla riga 151, aggiungi:
harmony: true,

così diventa:

  uglified, map =
    Uglifier.new(
      comments: :none,
      harmony: true,
      source_map: {
        filename: File.basename(from),
        output_filename: File.basename(to),
      },
    ).comp

E installa i seguenti pacchetti npm:

npm install terser
npm install -g uglify-js@"<3"

Quindi compila gli asset:

RAILS_ENV=production bundle exec rake assets:precompile

Ed ecco fatto! Ora questo dovrebbe funzionare:

 bundle exec sidekiq -e production -C config/sidekiq.yml
 bundle exec puma --config config/puma.rb -e production

Questo avvia sidekiq e il server web puma.

(molto più economico e con più controllo, cioè ho già Ruby 3.2.2 in esecuzione). La maggior parte del tempo è stata dedicata a superare le stranezze (come la ricerca dei valori production dato che non erano dove dovevano essere). Ma a parte questo, è stato abbastanza veloce!

2 Mi Piace
4

È piuttosto impressionante. Il problema, come accennato, è che se si verifica un problema che manda in crash il tuo sito. Potresti rimanere bloccato con un numero molto limitato di membri della community che potrebbero essere in grado di aiutarti a risolvere i problemi. Quindi il rischio/svantaggio maggiore è un potenziale downtime prolungato o catastrofico che potrebbe richiedere una reinstallazione completa.

Più a lungo un sito rimane inattivo, maggiore sarà la perdita di reputazione e di membri che il tuo sito potrebbe subire.

Se stai solo sperimentando e non dipendi realmente da un sito di produzione stabile. Allora non rischi molto, solo tempo.

1 Mi Piace