Existe vantagem em uma instalação Docker?

Instalação
1

Sei que a documentação e muitos tópicos aqui sugerem que o Docker é o único (bom) caminho a seguir, mas eu queria saber o raciocínio. Eu tenho uma caixa Debian Amazon Lightsail de US$ 3,50/mês e o Discourse rodando em 20 minutos. Usei o rbenv para instalar o Ruby 3.2.2, e o resto foi fácil. Achei que o Discourse não segue as convenções do Rails, como por que existe um ./config/discourse.conf e GlobalSetting em vez do config/environments/production.rb especificando esses valores - é isso que as imagens Docker acabam criando (também sidekiq.yml sem valores de produção)?

Existe alguma vantagem em rodar isso no Docker? Estou imaginando se estou perdendo alguma coisa…

2

A versão bem curta é que, se você não estiver usando a instalação padrão, não poderemos oferecer nenhuma assistência aqui. Há muitas coisas que podem dar errado se você se desviar desse caminho.

4 curtidas
3

Entendi, sim, sistemas operacionais diferentes e tal. Já tem alguém perguntando como fiz - vou postar aqui caso precise.

É preciso Ruby 3.2.x (através do rbenv, para não depender do sistema operacional), Node v16.19.x/npm 8.19.x e PostgreSQL (provavelmente qualquer versão acima da 11).

  1. Criei um arquivo .ruby-version, que especificava a versão do ruby que instalei (3.2.2).
  2. Executei bundle e todas as gems foram compiladas sem problemas.
  3. Dentro do próprio PostgreSQL, tive que configurar o banco de dados:
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;

Fiquei surpreso que o database.yml não aceita variáveis de production (isso parece muito anti-convenção do Rails). Todas as configurações de banco de dados estavam em config/discourse.conf, juntamente com os valores de SMTP. Preenchi esses campos.

Em seguida, executei as migrações do banco de dados:

bundle exec rails db:migrate

Tudo funcionou bem e as migrações foram bem-sucedidas.

  1. Em config/sidekiq.yml, após a seção development, adicionei:
production:
  :concurrency: 2
  :queues:
    - [critical, 2]
    - [default, 1]
    - [low]
    - [ultra_low]
  1. Em seguida, editei lib/tasks/assets.rake, por volta da linha 151, adicionei:
harmony: true,

para que ficasse assim:

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

E instalei os seguintes pacotes npm:

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

Em seguida, compilei os assets:

RAILS_ENV=production bundle exec rake assets:precompile

E pronto! Agora isso deve funcionar:

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

Isso inicia o sidekiq e o servidor web puma.

(muito mais barato e com mais controle, ou seja, já estou usando Ruby 3.2.2). A maior parte do tempo foi contornando as peculiaridades (como procurar valores de production onde não deveriam estar). Mas, fora isso, foi bem rápido!

2 curtidas
4

Isso é bastante impressionante. O problema, como mencionado, é que se você encontrar um problema que quebre seu site. Você potencialmente ficará preso com um número muito limitado da comunidade em geral que pode ajudá-lo a consertar as coisas. Portanto, o maior risco/desvantagem é um tempo de inatividade potencialmente longo a catastrófico que pode exigir uma reinstalação completa.

Quanto mais tempo um site fica inativo, maior a perda de reputação e de membros que seu site pode sofrer.

Se você está apenas experimentando e não depende realmente de um site de produção estável. Então, você não está arriscando muito, a não ser tempo.

1 curtida