¿Hay alguna ventaja en una instalación de Docker?

Instalación
1

Sé que la documentación y muchos hilos aquí sugieren que Docker es la única (buena) forma de avanzar, pero quería saber el razonamiento. Conseguí una caja Debian de Amazon Lightsail por $3.50/mes y tuve Discourse funcionando en 20 minutos. Usé rbenv para instalar Ruby 3.2.2, y el resto fue fácil. Descubrí que Discourse tampoco sigue las convenciones de Rails, como por qué existe un ./config/discourse.conf y GlobalSetting en lugar de config/environments/production.rb especificando estos valores, ¿es esto lo que las imágenes de Docker terminan creando (también sidekiq.yml sin valores de entorno de producción)?

¿Hay alguna ventaja en ejecutar esto en Docker? Me pregunto si me estoy perdiendo algo…

2

La versión muy breve es que si no está utilizando la instalación estándar, no podemos ofrecerle ninguna ayuda aquí. Hay demasiadas cosas que pueden salir mal si se desvía de ese camino.

4 Me gusta
3

Entendido, sí, diferentes sistemas operativos y demás. Ya hay alguien preguntando cómo lo hice, publicaré aquí por si acaso.

Se necesita Ruby 3.2.x (a través de rbenv, para no depender del sistema operativo), Node v16.19.x/npm 8.19.x y PostgreSQL (probablemente cualquier versión superior a 11).

  1. Creé un archivo .ruby-version que especificaba la versión de Ruby que instalé (3.2.2).
  2. Ejecuté bundle y todos los gems se compilaron sin problemas.
  3. Dentro de PostgreSQL, tuve que configurar la base de datos:
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;

Me sorprendió que database.yml no aceptara variables de production (esto parece muy contrario a la convención de Rails). Todas las configuraciones de la base de datos estaban en config/discourse.conf, junto con los valores SMTP. Los completé.

Luego ejecuté las migraciones de la base de datos:

bundle exec rails db:migrate

Todo funcionó bien y las migraciones fueron exitosas.

  1. En config/sidekiq.yml, después de la sección development, añadí:
production:
  :concurrency: 2
  :queues:
    - [critical, 2]
    - [default, 1]
    - [low]
    - [ultra_low]
  1. Luego edité lib/tasks/assets.rake, alrededor de la línea 151, y añadí:
harmony: true,

para que se vea así:

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

E instalé los siguientes paquetes npm:

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

Luego compilé los assets:

RAILS_ENV=production bundle exec rake assets:precompile

¡Y listo! Ahora esto debería funcionar:

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

Esto pone en marcha sidekiq y el servidor web puma.

(Mucho más barato y con más control, es decir, ya tengo Ruby 3.2.2 funcionando). La mayor parte del tiempo se dedicó a solucionar las peculiaridades (como buscar los valores de production donde no debían estar). Pero aparte de eso, ¡fue bastante rápido!

2 Me gusta
4

Eso es bastante impresionante. El problema, como se mencionó, es que si te encuentras con un problema que rompe tu sitio. Potencialmente te quedas atascado con un número muy limitado de la comunidad en general que podría ayudarte a solucionar las cosas. Por lo tanto, el mayor riesgo/desventaja es un tiempo de inactividad potencial, desde prolongado hasta catastrófico, que puede requerir una reinstalación completa.

Cuanto más tiempo permanezca caído un sitio, mayor será la pérdida de reputación y de miembros que tu sitio pueda experimentar.

Si solo estás experimentando y no dependes realmente de un sitio de producción estable. Entonces no estás arriesgando mucho, solo tiempo.

1 me gusta