Mastodon: Running with docker prebuilt image from Docker Hub

[Shywim]

I can't make it run.
If I run docker run -D gargron/mastodon it instantly exists. If I run docker run -dit gargron/mastodon I'm left with a irb shell that make the container stop when I run 1 command inside...

I'm not an expert on Docker, but I already ran some containers from others projects and I did not run into problems like here, docker logs give me nothing since it seems nothing is run inside the containers actually so either I'm missing something or documentation is lacking.

---

• [x] I searched or browsed the repo’s other issues to ensure this is not a duplicate.

[mbirth]

Yes, please provide a self-contained ready-to-run Docker image which can be configured via Docker-parameters (ENV variables and/or config files in mountable folders).

[skhameneh]

I'd like to help with this; at first glance it looks like multiple services are configured on the same local filesystem in source.

Might be able to spin 3 instances of the image, each for a different service - for the time being.
Ideally, there would be 3 images generated and pushed to the docker hub for each service; the docker-compose.yml would reference each image corresponding their service.

[mbirth]

@skhameneh I think it would be better to have 1 Docker image with e.g. Supervisord running all needed processes. Having 3 separate docker containers just makes upgrading to a newer version more difficult.

[skhameneh]

@mbirth docker-compose pull makes upgrades all the same. Docker is all about containerizing services so they can be scaled and load balanced as needed.

I have no interest in scaling resources for sidekik and streaming when my only need is another web instance.

[skhameneh]

You also have more resource insight per layer when they're containerized.

[mbirth]

@skhameneh I was more thinking of people wanting to easily run an instance on e.g. their Synology without having to spool up 3 containers and linking them.

[ineffyble]

The repo docker-compose.yml reveals how the single container is currently used: https://github.com/tootsuite/mastodon/blob/master/docker-compose.yml

The Dockerfile doesn't include an ENTRYPOINT, so running a new container with the image, without a command, will fail.

The Docker methodology is "one process per container" - the current set up doesn't really violate that - you create three containers from the same image, with a different service in each.

With regards to upgrading - as has been mentioned, most tools designed for management/orchestration (from simple ones like docker-compose to advanced like Kubernetes) usually let you define a stack of containers, referencing the latest version of the image from a registry, and pull the latest versions together.

To get the Hub image working right now, you could:

• Use docker-compose, and make a docker-compose.yml file very similar to the repo one (in fact, just taking out the build keys and substituting an image key would do it.
• Use plain docker, by using docker run and providing one of the service commands (to run rails/puma, or nodejs/streaming, or sidekiq)
• Use another orchestration service like Kubernetes which are configured similar to compose

[skhameneh]

@mbirth see https://github.com/tootsuite/mastodon/issues/1222#issuecomment-292695647

There is no reason not to separate each our into their own containers. It wouldn't break any existing scenarios.

[skhameneh]

I've found that the public image will run, it just doesn't have a designated service for docker to recognize health. If you set TTY/Interactive it will keep the image alive and the image listens on port 3000 and 4000.

Below is a link to a gist of my (barely anything) progress, I've got more work to do and some of the environment values are likely duplicates of default values. So far haproxy isn't detecting a response from either active port (still getting 503's). This could be a mix of things, for all I know the Mastodon server might need a restart after haproxy is pointing to it (to hit itself on its own public URL). If anyone has more insight, that would be great.

https://gist.github.com/skhameneh/62d0c9d6093ffa6a67f7cea358ac11df
(note: most users will want to expose port 3000/4000, I use haproxy to access the container's private ports, this is used for the likes of load balancing and vhosts)

[skhameneh]

Update my gist above is now working; it expects nginx or haproxy to direct :80 -> 3000 and :80/api/v1/streaming -> 4000.

It's very hacky, but it does work with a one click deploy for Docker.

[ashfurrow]

@Shywim did you ever get this working?

[ashfurrow]

No updates for a few weeks, so I'm going to close this issue. If it's still a problem, please let us know so we can re-open. Thanks again!