Compare commits

..

No commits in common. "a80d553d09e79d0eefb2f4545b20fc3a10298199" and "c8411e848c2355c48d5a85fa08eb71bab32a1704" have entirely different histories.

View File

@ -26,15 +26,10 @@ This repository dockerizes it for easier deployment.
## In the Wild
`cofe.rocks` is always managed by this script.<br/>
My own instance is managed by this script.
Take a look at [hosted/pleroma](/hosted/pleroma) if you get stuck or need some inspiration.
Additionally it's known to run on (in no particular order):
- social.interhop.org
- social.technodruide.ca
- toot.poto.cafe
Does your instance use pleroma-docker?<br/>
Does your instance use pleroma-docker?
Let me know and I'll add you to this list.
## Docs
@ -64,53 +59,55 @@ For other problems related to this script, contact me or open an issue :)
- Profit!
Hint:
You can also use normal `docker-compose` commands to maintain your setup.<br/>
You can also use normal `docker-compose` commands to maintain your setup.
The only command that you cannot use is `docker-compose build` due to build caching.
### Configuration
All the pleroma options that you usually put into your `*.secret.exs` now go into `config.exs`.<br/>
`.env` stores config values that need to be known at orchestration/build time.<br/>
All the pleroma options that you usually put into your `*.secret.exs` now go into `config.exs`.
`.env` stores config values that need to be known at orchestration/build time.
Documentation for the possible values is inside of that file.
### Updates
Run `./pleroma.sh build` again and start the updated image with `./pleroma.sh up`.<br/>
Run `./pleroma.sh build` again and start the updated image with `./pleroma.sh up`.
You don't need to stop your pleroma server for either of those commands.
### Maintenance
Pleroma maintenance is usually done with mix tasks.<br/>
You can run these tasks in your running pleroma server using `./pleroma.sh mix [task] [arguments...]`.<br/>
For example: `./pleroma.sh mix pleroma.user new sn0w ...`<br/>
Pleroma maintenance is usually done with mix tasks.
You can run these tasks in your running pleroma server using `./pleroma.sh mix [task] [arguments...]`.
For example: `./pleroma.sh mix pleroma.user new sn0w ...`
If you need to fix bigger problems you can also spawn a shell with `./pleroma.sh enter`.
### Customization
Add your customizations (and their folder structure) to `custom.d/`.<br/>
They will be copied into the right place when the container starts.<br/>
You can even replace/patch pleromas code with this, because the project is recompiled at startup if needed.
Add your customizations (and their folder structure) to `custom.d/`.
They will be copied into the right place when the container starts.
You can even replace/patch pleromas code with this,
because the project is recompiled at startup if needed.
In general: Prepending `custom.d/` to pleromas customization guides should work all the time.<br/>
In general: Prepending `custom.d/` to pleromas customization guides should work all the time.
Check them out in the [pleroma documentation](https://docs.pleroma.social/small_customizations.html#content).
For example: A custom thumbnail now goes into `custom.d/` + `instance/static/instance/thumbnail.jpeg`.
### Patches
Works exactly like customization, but we have a neat little helper here.<br/>
Works exactly like customization, but we have a neat little helper here.
Use `./pleroma.sh mod [regex]` to mod any file that ships with pleroma, without having to type the complete path.
### My instance is up, how do I reach it?
To reach Gopher or SSH, just uncomment the port-forward in your `docker-compose.yml`.
To reach HTTP you will have to configure a "reverse-proxy".<br/>
Older versions of this project contained a huge amount of scripting to support all kinds of reverse-proxy setups.<br/>
This newer version tries to focus only on providing good pleroma tooling.<br/>
To reach HTTP you will have to configure a "reverse-proxy".
Older versions of this project contained a huge amount of scripting to support all kinds of reverse-proxy setups.
This newer version tries to focus only on providing good pleroma tooling.
That makes the whole process a bit more manual, but also more flexible.
You can use Caddy, Traefik, Apache, nginx, or whatever else you come up with.<br/>
You can use Caddy, Traefik, Apache, nginx, or whatever else you come up with.
Just modify your `docker-compose.yml` accordingly.
One example would be to add an [nginx server](https://hub.docker.com/_/nginx) to your `docker-compose.yml`:
@ -134,13 +131,13 @@ Then take a look at [the pleroma nginx example](https://git.pleroma.social/plero
Using apache would work in a very similar way (see [Apache Docker Docs](https://hub.docker.com/_/httpd) and [the pleroma apache example](https://git.pleroma.social/pleroma/pleroma/blob/develop/installation/pleroma-apache.conf)).
The target that you proxy to is called `http://server:4000/`.<br/>
The target that you proxy to is called `http://server:4000/`.
This will work automagically when the proxy also lives inside of docker.
If you need help with this, or if you think that this needs more documentation, please let me know.
Something that cofe.rocks uses is simple port-forwarding of the `server` container to the host's `127.0.0.1`.<br/>
From there on, the natively installed nginx server acts as a proxy to the open internet.<br/>
Something that cofe.rocks uses is simple port-forwarding of the `server` container to the host's `127.0.0.1`.
From there on, the natively installed nginx server acts as a proxy to the open internet.
You can take a look at cofe's [compose yaml](/hosted/pleroma/src/branch/master/docker-compose.yml) and [proxy config](/hosted/pleroma/src/branch/master/proxy.xconf) if that setup sounds interesting.
### Attribution