Specify and issue a more container-centric approach for deployment (in documentation)

[ShadowJonathan]

One barrier I currently see for entry to deploying mastodon is the fact that documentation and default deployment techniques go for a VM-based approach. While this was probably the best way to deploy applications 7 years ago, my opinion is that mastodon should replace or update this approach with an (additional or supplemental) documentation as to how to deploy mastodon in a containerized environment.

Containerizing applications reduces the application requirements to 4 simple vectors: memory, CPU, permanent storage, and network port ingress. Orchestration software such as kubernetes can abstract this even more and bring in more resilient and environment-agnostic approaches to deploying applications, but I want to focus on containerization real quick.

What I envision is that mastodon can be deployed very easily on someone's DIY refurbished desktop server, so to speak, and all they'd need to do is simply install docker one way or another, and not go through dependency hell to fine-tune a server to work for this particular use-case, but "simply deploy" a container, give it some memory, some disk space allocation, optionally a database (also deployed into a container) and a reverse proxy (likewise), and not conflict with the rest of the system. Also allowing atomic upgrades and downgrades in mastodon versioning.

This is my illustration as to why containers can have an advantage over specialized VM installations, I know opinions might differ, but I at least think it's worth a try to focus on packaging mastodon (while still leaving heaps of customization through the use of customization files imported via mounts) to be used within containers, allowing it to easily survive, with minimal upkeep, with less technical skill required, lowering the barrier for entry for new instances to join, and allowing existing instances to keep existing for longer for less.

[nightpool]

Mastodon originally promoted its Docker images as the main installation method, but we found through our experience that container-based deployments were a very error prone and difficult method for novice sysadmins and led to a lot of avoidable errors. While we still provide Docker images and container configuration files for experienced sysadmins who prefer them, I don't think it's likely that we're ever going to go back to recommending it as a primary method of deployment.

…

On Sun, Jul 12, 2020, 10:33 AM Jonathan de Jong ***@***.***> wrote: One barrier I currently see for entry to deploying mastodon is the fact that documentation and default deployment techniques go for a VM-based approach. While this was probably the best way to deploy applications 7 years ago, my opinion is that mastodon should replace or update this approach with an (additional or supplemental) documentation as to how to deploy mastodon in a containerized environment. Containerizing applications reduces the application requirements to 4 simple vectors: memory, CPU, permanent storage, and network port ingress. Orchestration software such as kubernetes can abstract this and bring in more resilient and agnostic approaches to deploying applications, but I want to focus on containers real quick. What I envision is that mastodon can be deployed very easily on someone's DIY refurbished desktop server, so to speak, and all they'd need to do is simply install docker one way or another, and not go through dependency hell to fine-tune a server to work for this particular use-case, but "simply deploy" a container, give it some memory, some disk space allocation, optionally a database (also deployed into a container) and a reverse proxy (likewise), and not conflict with the rest of the system. Also allowing atomic upgrades and downgrades in mastodon versioning. This was my case as to why containers can have an advantage over specialized VM installations, I know opinions might differ, but I at least think it's worth a try to focus on packaging mastodon (while still leaving heaps of customization through the use of customization files imported via mounts) to be used within containers, allowing it to easily survive, with minimal upkeep, with less technical skill required, lowering the barrier for entry for new instances to join, and existing instances to keep existing. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#793>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABZCV42LZ5R3FJNA72HJDTR3HJT5ANCNFSM4OX3IV5A> .

[ShadowJonathan]

Well, currently I cannot find any docker deployment documentation at all, sorry for my emphasis, but I think that providing (or writing) such documentation, or at least comprehensive reference documentation (on mount locations, ports, and env variables (I've seen some of this, but I don't know if all variables would apply to a container)) would suffice to help people start with trying out.

(That's why I made this issue in the first place, because I could not find that documentation, I may have done it on a bit of a whim while being sleep-deprived, so sorry if my language is a bit odd or blunt)

[Utopiah]

I also find that surprising.

I understand that newcomers have better success through another method and that it is pragmatic to put it on first.

Yet, providing an image https://hub.docker.com/r/tootsuite/mastodon without an actual documentation for it is very surprising. I'd argue a single sentence at the bottom of a page would let experts find the image then its documentation. For now, they end up here then will look for unofficial blog post or random docker-compose files (rather than https://github.com/mastodon/mastodon/blob/main/docker-compose.yml !) or an unofficial documentation fork https://github.com/McKael/mastodon-documentation/blob/master/Running-Mastodon/Docker-Guide.md (which btw seems quite outdated).

[egypturnash]

When I set up my instance back in 2017, I did a local install on my Mac for purposes of easy hacking, and ended up following the Docker installation directions on the remote server.

When updates needed to happen, the local installation has generally been complete dependency hell. I usually have to spend several days wrangling with the local update and wondering why the @#$% "charlock_holmes" is refusing to compile this time. The Docker installation, by contrast, is a breeze - I just sync my changes via git, take the server down, recompose, do the migration, and it's done.

Today I decided that I am donewith dependency hell and went looking for the Docker guides for help getting that running on my Mac's local copy, and they are nowhere to be found. I am thinking about how many new admins followed the directions to do a manual installation on their remote machine and how much dependency hell they are in for now that they're updating to 4.0.2, and I am kind of aghast.

[klogdog]

" I don't think it's likely that we're ever going to go back to recommending it as a primary method of deployment."

Many modern systems use Docker as a primary method of deployment. The fact that "container-based deployments were a very error prone and difficult method for novice sysadmins and led to a lot of avoidable errors." makes me very suspicious of the circumstances.

What made them error prone? What made them difficult for novices? Docker is very easy to use. It has only become easier as time goes by.