I’m curious why the main install docs for Mastodon default to installing directly on the server, and requiring quite a lot of commands from the admin, instead of using a docker install which should require less interactions, and leaving less space for typos and wrong or missing dependencies.
The main issue is that we’ve found Docker container setups to be unfriendly for newbie sysadmins. We used to recommend Docker as the primary installation method, but we had lots of problems with people running docker-compose down and destroying volumes, people having problems with finding logs and setting up init systems, and lots of issues of that sort. In the end, we decided that most entry-level sysadmins are better suited by a native installation guide like this one, that works better with the existing body of Unix how-to tutorials, like the ones hosted by DigitalOcean and Linode. Docker installs are still supported and available, they’re just not the main focus of our installation guides.
I will fully admit that many of the issues stem from us, the primary maintainers, not being super familiar with Docker ourselves and also not having the resources (at the time) to invest in a tooling system to make Docker more newbie-friendly, like Discourse has been able to. Some more minor issues: we were reliant on a lot of community patches to maintain the more complicated parts our Docker configuration, and there were a lot of arguments over “best practices” that we weren’t able to resolve ourselves due to our unfamiliarity. This also caused more subtle issues: one contributor would do things one way, and then someone would come with a patch to do things a completely different way, and the conflict between the two approaches wouldn’t be apparent to us until it caused issues down the line.
None of these are insurmountable problems, but ultimately we had a lot more success and a lot fewer tragic issues guiding newbies towards the native install route, and allowing those with more complex setups to choose Docker if they were already comfortable with it.
(Also, re: “at least have a script”, I’m not sure I agree that “require less interactions” is a good quality in an installation guide, especially for a system as complex as Mastodon. A working Mastodon install has a lot of moving parts: Sidekiq, Postgres, Redis, Webpack, etc, and I think it’s good for sysadmins to at least have a basic, high-level understanding of how all of these parts fit together, instead of having them abstracted away behind a single “install mastodon” command)
Traceback (most recent call last):
16: from /opt/mastodon/lib/tasks/db.rake:53:in `block (3 levels) in <top (required)>'
15: from /opt/mastodon/vendor/bundle/ruby/2.7.0/gems/activerecord-220.127.116.11/lib/active_record/connection_handling.rb:90:in `connection'
14: from /opt/mastodon/vendor/bundle/ruby/2.7.0/gems/activerecord-18.104.22.168/lib/active_record/connection_handling.rb:118:in `retrieve_connection'
13: from /opt/mastodon/vendor/bundle/ruby/2.7.0/gems/activerecord-22.214.171.124/lib/active_record/connection_adapters/abstract/connection_pool.rb:1033:in `retrieve_connection'
12: from /opt/mastodon/vendor/bundle/ruby/2.7.0/gems/activerecord-126.96.36.199/lib/active_record/connection_adapters/abstract/connection_pool.rb:382:in `connection'
11: from /opt/mastodon/vendor/bundle/ruby/2.7.0/gems/activerecord-188.8.131.52/lib/active_record/connection_adapters/abstract/connection_pool.rb:538:in `checkout'
10: from /opt/mastodon/vendor/bundle/ruby/2.7.0/gems/activerecord-184.108.40.206/lib/active_record/connection_adapters/abstract/connection_pool.rb:814:in `acquire_connection'
9: from /opt/mastodon/vendor/bundle/ruby/2.7.0/gems/activerecord-220.127.116.11/lib/active_record/connection_adapters/abstract/connection_pool.rb:853:in `try_to_checkout_new_connection'
8: from /opt/mastodon/vendor/bundle/ruby/2.7.0/gems/activerecord-18.104.22.168/lib/active_record/connection_adapters/abstract/connection_pool.rb:874:in `checkout_new_connection'
7: from /opt/mastodon/vendor/bundle/ruby/2.7.0/gems/activerecord-22.214.171.124/lib/active_record/connection_adapters/abstract/connection_pool.rb:830:in `new_connection'
6: from /opt/mastodon/vendor/bundle/ruby/2.7.0/gems/activerecord-126.96.36.199/lib/active_record/connection_adapters/postgresql_adapter.rb:48:in `postgresql_connection'
5: from /opt/mastodon/vendor/bundle/ruby/2.7.0/gems/activerecord-188.8.131.52/lib/active_record/connection_adapters/postgresql_adapter.rb:48:in `new'
4: from /opt/mastodon/vendor/bundle/ruby/2.7.0/gems/activerecord-184.108.40.206/lib/active_record/connection_adapters/postgresql_adapter.rb:223:in `initialize'
3: from /opt/mastodon/vendor/bundle/ruby/2.7.0/gems/activerecord-220.127.116.11/lib/active_record/connection_adapters/postgresql_adapter.rb:692:in `connect'
2: from /opt/mastodon/vendor/bundle/ruby/2.7.0/gems/pg-1.2.3/lib/pg.rb:58:in `connect'
1: from /opt/mastodon/vendor/bundle/ruby/2.7.0/gems/pg-1.2.3/lib/pg.rb:58:in `new'
/opt/mastodon/vendor/bundle/ruby/2.7.0/gems/pg-1.2.3/lib/pg.rb:58:in `initialize': could not connect to server: No such file or directory (PG::ConnectionBad)
Is the server running locally and accepting
connections on Unix domain socket "/var/run/postgresql/.s.PGSQL.5432"?
I’ve self-hosted Discourse forums for years and absolutely count on the fact that Sidekiq, Postgres, Redis etc are neatly packaged by Docker by the Discourse team. It’s vital to me that I get the same consistent setup that all other Discourse instances have.
A big time-saver for the Discourse devs, too, otherwise they’d really struggle to offer their support to all the different possible machine/OS/environment setups people are using out there!
Thanks for your honest explanation @nightpool, and I understand the issues. However, I hope that in time, Mastadon can get closer to a one-script Docker setup, as this would radically reduce the barrier to entry for time-pressed admins like me.
If I solve the problems I’ve been having with the db, I’ll aim to contribute the fixes back via a pull request.