Why main install docs don't use Docker?

Hey, Falco from discourse.org here :wave:.

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.


I agree. Or at least a script or something.


Hey Falco! Sorry for not seeing this earlier.

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)


I spend sometimes quite a lot of time reverse engineering various Docker-only installations to really understand what is working, what is not and how to troubleshoot that.


I had a nice example of this few days ago on IRC - for some reason Elastic Search could not be contacted. It took a while to figure out how actually ES is reached (hostname was es).

I’d like to install a Mastodon instance using Docker, but am struggling to get a working database connection. Same issue as reported here: Docker Install - Can't setup the database

More details on the issue I'm seeing
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- `connection'
	14: from /opt/mastodon/vendor/bundle/ruby/2.7.0/gems/activerecord- `retrieve_connection'
	13: from /opt/mastodon/vendor/bundle/ruby/2.7.0/gems/activerecord- `retrieve_connection'
	12: from /opt/mastodon/vendor/bundle/ruby/2.7.0/gems/activerecord- `connection'
	11: from /opt/mastodon/vendor/bundle/ruby/2.7.0/gems/activerecord- `checkout'
	10: from /opt/mastodon/vendor/bundle/ruby/2.7.0/gems/activerecord- `acquire_connection'
	 9: from /opt/mastodon/vendor/bundle/ruby/2.7.0/gems/activerecord- `try_to_checkout_new_connection'
	 8: from /opt/mastodon/vendor/bundle/ruby/2.7.0/gems/activerecord- `checkout_new_connection'
	 7: from /opt/mastodon/vendor/bundle/ruby/2.7.0/gems/activerecord- `new_connection'
	 6: from /opt/mastodon/vendor/bundle/ruby/2.7.0/gems/activerecord- `postgresql_connection'
	 5: from /opt/mastodon/vendor/bundle/ruby/2.7.0/gems/activerecord- `new'
	 4: from /opt/mastodon/vendor/bundle/ruby/2.7.0/gems/activerecord- `initialize'
	 3: from /opt/mastodon/vendor/bundle/ruby/2.7.0/gems/activerecord- `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’m following these instructions: https://www.howtoforge.com/how-to-install-mastodon-social-network-with-docker-on-ubuntu-1804/ and the failure comes here:

docker-compose run --rm web rails db:migrate

Any tips would be appreciated.

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.

PostgreSQL database cannot be reached using a local UNIX socket.

Few unsolicited guesses what can be wrong:

  1. PostgreSQL server not running
  2. PostgreSQL server not reachable via the UNIX socket
  3. Mastodon needs to be told to use TCP/IP connection to the database
1 Like