hometown/docker-compose.yml

134 lines
3.5 KiB
YAML
Raw Normal View History

version: '3'
services:
db:
2016-10-25 12:21:48 +01:00
restart: always
image: postgres:14-alpine
Dockerfile update (#1270) While Docker isn't officially supported by Hometown, leaving the Mastodon 3.5.5 Docker configuration in place with the new 4.0.2 code is a bad idea. At minimum, you'll have a stale Node install that's months behind on security updates. There are some minor tweaks to the default configuration, but they're flagged by comments so they're easy to revert or modify as necessary. # Running Hometown on Docker I'll by typing up my own longer blog post in due time, but there's no harm dropping a cheat sheet here. By following this outline, I was able to upgrade a Hometown 1.0.8 install to 1.1.0 with nothing worse than a minute or two of downtime. My configuration uses the GitHub repository as its source, rather than images drawn from DockerHub. I like to tweak and fiddle with my setup, especially the themes, and I'm happy to sacrifice some disk space for the privilege. ## Installing from Scratch This is by far the easiest approach, you just follow [one of](https://gist.github.com/TrillCyborg/84939cd4013ace9960031b803a0590c4) the [existing guides](https://sleeplessbeastie.eu/2022/05/02/how-to-take-advantage-of-docker-to-install-mastodon/) for running Mastodon via Docker, pause after you've set up `.env.production`, add any Hometown-specific features to it [as per the Wiki](https://github.com/hometown-fork/hometown/wiki), then resume what the guide says to do. If you're enabling ElastiSearch, the second of the two guides has some additional actions you'll need to do, plus be aware of [this bug](https://github.com/mastodon/mastodon/issues/18625) in Mastodon which can quietly block ES from working at all. ## Upgrading from Hometown 1.0.8 Here's how I accomplished this. I committed any leftover changes, then ran these commands from the non-Docker instructions in the root of my local Hometown repository: ``` git remote update git checkout v4.0.2+hometown-1.1.0 ``` This "wiped out" my customizations, but as I committed them all to a branch I can reconstruct them later via diffs. I then ran: ``` sudo docker-compose build ``` to build the new image. The old image will continue running in the background, as per usual. I like adding `2>&1 | less` to the end and mashing `PgDn`, as if a compilation error happens it almost invariably requires scrolling back a few screens to find the issue. If the build succeeded, we're almost clear to start the dangerous portion. If you're running on the cloud, now would be a great time to take a snapshot. Whatever the case, you should back up the existing database. If you haven't changed the defaults from the Dockerfile, then ``` sudo docker exec -it hometown_db_1 pg_dump -U postgres -Fc postgres > hometown.db.dump ``` should do the trick. If you have changed the defaults, you may need to use `sudo docker ps` to figure out the name of the PostgreSQL image to swap in place of "hometown_db_1", then browse through `.env.production` to extract the username to place after `-U` and the database name to place after `-Fc`. The Hometown docs don't say how to restore the database should the process go South, but after reading a manpage or two I think the magic words are roughly ``` sudo docker exec -it hometown_db_1 pg_restore -U postgres --clean --if-exists -d postgres < hometown.db.dump ``` Now we're ready for the scary "you could destroy everything" part. All the earlier commands are trivial to roll back, but after this point any delay could cause data corruption. As per the Hometown docs, run the pre-deployment database migrations. ``` sudo docker-compose run -e SKIP_POST_DEPLOYMENT_MIGRATIONS=true -e RAILS_ENV=production --rm web bundle exec rails db:migrate ``` where `web` is the name of the webserver image in `docker-compose.yml`. The docs state you should precompile all assets next, but I'm 95% sure they were already built when you ran `sudo docker-compose build`. If you're paranoid and want to be absolutely sure precompilation is done, then at this stage run: ``` sudo docker-compose run -e RAILS_ENV=production --rm web bundle exec rails assets:precompile ``` Here, the Hometown docs say you should run the post-deployment migrations. In Docker-ese: ``` sudo docker-compose run -e RAILS_ENV=production --rm web bundle exec rails db:migrate ``` Finally, we need to stop the old images and spin up the new ones. Run: ``` sudo docker-compose up -d ``` and give Docker some time to finish rotating. A quick `sudo docker ps` should confirm the new images are booting up, and in a short while (10-15 seconds for the teeny-tiny instance I manage) you should be back to fully functional.
2023-01-17 22:39:09 +00:00
shm_size: 512mb # 256MB is much too small, yet this is probably small enough to avoid OOMs even with 2GB RAM
networks:
- internal_network
healthcheck:
test: ['CMD', 'pg_isready', '-U', 'postgres']
volumes:
- ./postgres14:/var/lib/postgresql/data
environment:
- 'POSTGRES_HOST_AUTH_METHOD=trust'
redis:
2016-10-25 12:21:48 +01:00
restart: always
2022-08-27 16:40:46 +01:00
image: redis:7-alpine
networks:
- internal_network
healthcheck:
test: ['CMD', 'redis-cli', 'ping']
volumes:
- ./redis:/data
Dockerfile update (#1270) While Docker isn't officially supported by Hometown, leaving the Mastodon 3.5.5 Docker configuration in place with the new 4.0.2 code is a bad idea. At minimum, you'll have a stale Node install that's months behind on security updates. There are some minor tweaks to the default configuration, but they're flagged by comments so they're easy to revert or modify as necessary. # Running Hometown on Docker I'll by typing up my own longer blog post in due time, but there's no harm dropping a cheat sheet here. By following this outline, I was able to upgrade a Hometown 1.0.8 install to 1.1.0 with nothing worse than a minute or two of downtime. My configuration uses the GitHub repository as its source, rather than images drawn from DockerHub. I like to tweak and fiddle with my setup, especially the themes, and I'm happy to sacrifice some disk space for the privilege. ## Installing from Scratch This is by far the easiest approach, you just follow [one of](https://gist.github.com/TrillCyborg/84939cd4013ace9960031b803a0590c4) the [existing guides](https://sleeplessbeastie.eu/2022/05/02/how-to-take-advantage-of-docker-to-install-mastodon/) for running Mastodon via Docker, pause after you've set up `.env.production`, add any Hometown-specific features to it [as per the Wiki](https://github.com/hometown-fork/hometown/wiki), then resume what the guide says to do. If you're enabling ElastiSearch, the second of the two guides has some additional actions you'll need to do, plus be aware of [this bug](https://github.com/mastodon/mastodon/issues/18625) in Mastodon which can quietly block ES from working at all. ## Upgrading from Hometown 1.0.8 Here's how I accomplished this. I committed any leftover changes, then ran these commands from the non-Docker instructions in the root of my local Hometown repository: ``` git remote update git checkout v4.0.2+hometown-1.1.0 ``` This "wiped out" my customizations, but as I committed them all to a branch I can reconstruct them later via diffs. I then ran: ``` sudo docker-compose build ``` to build the new image. The old image will continue running in the background, as per usual. I like adding `2>&1 | less` to the end and mashing `PgDn`, as if a compilation error happens it almost invariably requires scrolling back a few screens to find the issue. If the build succeeded, we're almost clear to start the dangerous portion. If you're running on the cloud, now would be a great time to take a snapshot. Whatever the case, you should back up the existing database. If you haven't changed the defaults from the Dockerfile, then ``` sudo docker exec -it hometown_db_1 pg_dump -U postgres -Fc postgres > hometown.db.dump ``` should do the trick. If you have changed the defaults, you may need to use `sudo docker ps` to figure out the name of the PostgreSQL image to swap in place of "hometown_db_1", then browse through `.env.production` to extract the username to place after `-U` and the database name to place after `-Fc`. The Hometown docs don't say how to restore the database should the process go South, but after reading a manpage or two I think the magic words are roughly ``` sudo docker exec -it hometown_db_1 pg_restore -U postgres --clean --if-exists -d postgres < hometown.db.dump ``` Now we're ready for the scary "you could destroy everything" part. All the earlier commands are trivial to roll back, but after this point any delay could cause data corruption. As per the Hometown docs, run the pre-deployment database migrations. ``` sudo docker-compose run -e SKIP_POST_DEPLOYMENT_MIGRATIONS=true -e RAILS_ENV=production --rm web bundle exec rails db:migrate ``` where `web` is the name of the webserver image in `docker-compose.yml`. The docs state you should precompile all assets next, but I'm 95% sure they were already built when you ran `sudo docker-compose build`. If you're paranoid and want to be absolutely sure precompilation is done, then at this stage run: ``` sudo docker-compose run -e RAILS_ENV=production --rm web bundle exec rails assets:precompile ``` Here, the Hometown docs say you should run the post-deployment migrations. In Docker-ese: ``` sudo docker-compose run -e RAILS_ENV=production --rm web bundle exec rails db:migrate ``` Finally, we need to stop the old images and spin up the new ones. Run: ``` sudo docker-compose up -d ``` and give Docker some time to finish rotating. A quick `sudo docker ps` should confirm the new images are booting up, and in a short while (10-15 seconds for the teeny-tiny instance I manage) you should be back to fully functional.
2023-01-17 22:39:09 +00:00
# disabled, as there are open issues related to it plus ES chews RAM and CPU
# es:
# restart: always
# image: docker.elastic.co/elasticsearch/elasticsearch:7.17.4
# environment:
# - "ES_JAVA_OPTS=-Xms512m -Xmx512m -Des.enforce.bootstrap.checks=true"
# - "xpack.license.self_generated.type=basic"
# - "xpack.security.enabled=false"
# - "xpack.watcher.enabled=false"
# - "xpack.graph.enabled=false"
# - "xpack.ml.enabled=false"
# - "bootstrap.memory_lock=true"
# - "cluster.name=es-mastodon"
# - "discovery.type=single-node"
# - "thread_pool.write.queue_size=1000"
# networks:
# - internal_network
# healthcheck:
# test: ["CMD-SHELL", "curl --silent --fail localhost:9200/_cluster/health || exit 1"]
# volumes:
# - ./elasticsearch:/usr/share/elasticsearch/data
# ulimits:
# memlock:
# soft: -1
# hard: -1
# nofile:
# soft: 65536
# hard: 65536
# ports:
# - '127.0.0.1:9200:9200'
web:
2016-11-24 22:46:27 +00:00
build: .
Dockerfile update (#1270) While Docker isn't officially supported by Hometown, leaving the Mastodon 3.5.5 Docker configuration in place with the new 4.0.2 code is a bad idea. At minimum, you'll have a stale Node install that's months behind on security updates. There are some minor tweaks to the default configuration, but they're flagged by comments so they're easy to revert or modify as necessary. # Running Hometown on Docker I'll by typing up my own longer blog post in due time, but there's no harm dropping a cheat sheet here. By following this outline, I was able to upgrade a Hometown 1.0.8 install to 1.1.0 with nothing worse than a minute or two of downtime. My configuration uses the GitHub repository as its source, rather than images drawn from DockerHub. I like to tweak and fiddle with my setup, especially the themes, and I'm happy to sacrifice some disk space for the privilege. ## Installing from Scratch This is by far the easiest approach, you just follow [one of](https://gist.github.com/TrillCyborg/84939cd4013ace9960031b803a0590c4) the [existing guides](https://sleeplessbeastie.eu/2022/05/02/how-to-take-advantage-of-docker-to-install-mastodon/) for running Mastodon via Docker, pause after you've set up `.env.production`, add any Hometown-specific features to it [as per the Wiki](https://github.com/hometown-fork/hometown/wiki), then resume what the guide says to do. If you're enabling ElastiSearch, the second of the two guides has some additional actions you'll need to do, plus be aware of [this bug](https://github.com/mastodon/mastodon/issues/18625) in Mastodon which can quietly block ES from working at all. ## Upgrading from Hometown 1.0.8 Here's how I accomplished this. I committed any leftover changes, then ran these commands from the non-Docker instructions in the root of my local Hometown repository: ``` git remote update git checkout v4.0.2+hometown-1.1.0 ``` This "wiped out" my customizations, but as I committed them all to a branch I can reconstruct them later via diffs. I then ran: ``` sudo docker-compose build ``` to build the new image. The old image will continue running in the background, as per usual. I like adding `2>&1 | less` to the end and mashing `PgDn`, as if a compilation error happens it almost invariably requires scrolling back a few screens to find the issue. If the build succeeded, we're almost clear to start the dangerous portion. If you're running on the cloud, now would be a great time to take a snapshot. Whatever the case, you should back up the existing database. If you haven't changed the defaults from the Dockerfile, then ``` sudo docker exec -it hometown_db_1 pg_dump -U postgres -Fc postgres > hometown.db.dump ``` should do the trick. If you have changed the defaults, you may need to use `sudo docker ps` to figure out the name of the PostgreSQL image to swap in place of "hometown_db_1", then browse through `.env.production` to extract the username to place after `-U` and the database name to place after `-Fc`. The Hometown docs don't say how to restore the database should the process go South, but after reading a manpage or two I think the magic words are roughly ``` sudo docker exec -it hometown_db_1 pg_restore -U postgres --clean --if-exists -d postgres < hometown.db.dump ``` Now we're ready for the scary "you could destroy everything" part. All the earlier commands are trivial to roll back, but after this point any delay could cause data corruption. As per the Hometown docs, run the pre-deployment database migrations. ``` sudo docker-compose run -e SKIP_POST_DEPLOYMENT_MIGRATIONS=true -e RAILS_ENV=production --rm web bundle exec rails db:migrate ``` where `web` is the name of the webserver image in `docker-compose.yml`. The docs state you should precompile all assets next, but I'm 95% sure they were already built when you ran `sudo docker-compose build`. If you're paranoid and want to be absolutely sure precompilation is done, then at this stage run: ``` sudo docker-compose run -e RAILS_ENV=production --rm web bundle exec rails assets:precompile ``` Here, the Hometown docs say you should run the post-deployment migrations. In Docker-ese: ``` sudo docker-compose run -e RAILS_ENV=production --rm web bundle exec rails db:migrate ``` Finally, we need to stop the old images and spin up the new ones. Run: ``` sudo docker-compose up -d ``` and give Docker some time to finish rotating. A quick `sudo docker ps` should confirm the new images are booting up, and in a short while (10-15 seconds for the teeny-tiny instance I manage) you should be back to fully functional.
2023-01-17 22:39:09 +00:00
image: tootsuite/mastodon:v4.0.2
restart: always
env_file: .env.production
command: bash -c "rm -f /mastodon/tmp/pids/server.pid; bundle exec rails s -p 3000"
networks:
- external_network
- internal_network
healthcheck:
# prettier-ignore
test: ['CMD-SHELL', 'wget -q --spider --proxy=off localhost:3000/health || exit 1']
ports:
- '127.0.0.1:3000:3000'
depends_on:
- db
- redis
# - es
volumes:
- ./public/system:/mastodon/public/system
streaming:
build: .
Dockerfile update (#1270) While Docker isn't officially supported by Hometown, leaving the Mastodon 3.5.5 Docker configuration in place with the new 4.0.2 code is a bad idea. At minimum, you'll have a stale Node install that's months behind on security updates. There are some minor tweaks to the default configuration, but they're flagged by comments so they're easy to revert or modify as necessary. # Running Hometown on Docker I'll by typing up my own longer blog post in due time, but there's no harm dropping a cheat sheet here. By following this outline, I was able to upgrade a Hometown 1.0.8 install to 1.1.0 with nothing worse than a minute or two of downtime. My configuration uses the GitHub repository as its source, rather than images drawn from DockerHub. I like to tweak and fiddle with my setup, especially the themes, and I'm happy to sacrifice some disk space for the privilege. ## Installing from Scratch This is by far the easiest approach, you just follow [one of](https://gist.github.com/TrillCyborg/84939cd4013ace9960031b803a0590c4) the [existing guides](https://sleeplessbeastie.eu/2022/05/02/how-to-take-advantage-of-docker-to-install-mastodon/) for running Mastodon via Docker, pause after you've set up `.env.production`, add any Hometown-specific features to it [as per the Wiki](https://github.com/hometown-fork/hometown/wiki), then resume what the guide says to do. If you're enabling ElastiSearch, the second of the two guides has some additional actions you'll need to do, plus be aware of [this bug](https://github.com/mastodon/mastodon/issues/18625) in Mastodon which can quietly block ES from working at all. ## Upgrading from Hometown 1.0.8 Here's how I accomplished this. I committed any leftover changes, then ran these commands from the non-Docker instructions in the root of my local Hometown repository: ``` git remote update git checkout v4.0.2+hometown-1.1.0 ``` This "wiped out" my customizations, but as I committed them all to a branch I can reconstruct them later via diffs. I then ran: ``` sudo docker-compose build ``` to build the new image. The old image will continue running in the background, as per usual. I like adding `2>&1 | less` to the end and mashing `PgDn`, as if a compilation error happens it almost invariably requires scrolling back a few screens to find the issue. If the build succeeded, we're almost clear to start the dangerous portion. If you're running on the cloud, now would be a great time to take a snapshot. Whatever the case, you should back up the existing database. If you haven't changed the defaults from the Dockerfile, then ``` sudo docker exec -it hometown_db_1 pg_dump -U postgres -Fc postgres > hometown.db.dump ``` should do the trick. If you have changed the defaults, you may need to use `sudo docker ps` to figure out the name of the PostgreSQL image to swap in place of "hometown_db_1", then browse through `.env.production` to extract the username to place after `-U` and the database name to place after `-Fc`. The Hometown docs don't say how to restore the database should the process go South, but after reading a manpage or two I think the magic words are roughly ``` sudo docker exec -it hometown_db_1 pg_restore -U postgres --clean --if-exists -d postgres < hometown.db.dump ``` Now we're ready for the scary "you could destroy everything" part. All the earlier commands are trivial to roll back, but after this point any delay could cause data corruption. As per the Hometown docs, run the pre-deployment database migrations. ``` sudo docker-compose run -e SKIP_POST_DEPLOYMENT_MIGRATIONS=true -e RAILS_ENV=production --rm web bundle exec rails db:migrate ``` where `web` is the name of the webserver image in `docker-compose.yml`. The docs state you should precompile all assets next, but I'm 95% sure they were already built when you ran `sudo docker-compose build`. If you're paranoid and want to be absolutely sure precompilation is done, then at this stage run: ``` sudo docker-compose run -e RAILS_ENV=production --rm web bundle exec rails assets:precompile ``` Here, the Hometown docs say you should run the post-deployment migrations. In Docker-ese: ``` sudo docker-compose run -e RAILS_ENV=production --rm web bundle exec rails db:migrate ``` Finally, we need to stop the old images and spin up the new ones. Run: ``` sudo docker-compose up -d ``` and give Docker some time to finish rotating. A quick `sudo docker ps` should confirm the new images are booting up, and in a short while (10-15 seconds for the teeny-tiny instance I manage) you should be back to fully functional.
2023-01-17 22:39:09 +00:00
image: tootsuite/mastodon:v4.0.2
restart: always
env_file: .env.production
command: node ./streaming
networks:
- external_network
- internal_network
healthcheck:
# prettier-ignore
test: ['CMD-SHELL', 'wget -q --spider --proxy=off localhost:4000/api/v1/streaming/health || exit 1']
ports:
- '127.0.0.1:4000:4000'
depends_on:
- db
- redis
sidekiq:
build: .
Dockerfile update (#1270) While Docker isn't officially supported by Hometown, leaving the Mastodon 3.5.5 Docker configuration in place with the new 4.0.2 code is a bad idea. At minimum, you'll have a stale Node install that's months behind on security updates. There are some minor tweaks to the default configuration, but they're flagged by comments so they're easy to revert or modify as necessary. # Running Hometown on Docker I'll by typing up my own longer blog post in due time, but there's no harm dropping a cheat sheet here. By following this outline, I was able to upgrade a Hometown 1.0.8 install to 1.1.0 with nothing worse than a minute or two of downtime. My configuration uses the GitHub repository as its source, rather than images drawn from DockerHub. I like to tweak and fiddle with my setup, especially the themes, and I'm happy to sacrifice some disk space for the privilege. ## Installing from Scratch This is by far the easiest approach, you just follow [one of](https://gist.github.com/TrillCyborg/84939cd4013ace9960031b803a0590c4) the [existing guides](https://sleeplessbeastie.eu/2022/05/02/how-to-take-advantage-of-docker-to-install-mastodon/) for running Mastodon via Docker, pause after you've set up `.env.production`, add any Hometown-specific features to it [as per the Wiki](https://github.com/hometown-fork/hometown/wiki), then resume what the guide says to do. If you're enabling ElastiSearch, the second of the two guides has some additional actions you'll need to do, plus be aware of [this bug](https://github.com/mastodon/mastodon/issues/18625) in Mastodon which can quietly block ES from working at all. ## Upgrading from Hometown 1.0.8 Here's how I accomplished this. I committed any leftover changes, then ran these commands from the non-Docker instructions in the root of my local Hometown repository: ``` git remote update git checkout v4.0.2+hometown-1.1.0 ``` This "wiped out" my customizations, but as I committed them all to a branch I can reconstruct them later via diffs. I then ran: ``` sudo docker-compose build ``` to build the new image. The old image will continue running in the background, as per usual. I like adding `2>&1 | less` to the end and mashing `PgDn`, as if a compilation error happens it almost invariably requires scrolling back a few screens to find the issue. If the build succeeded, we're almost clear to start the dangerous portion. If you're running on the cloud, now would be a great time to take a snapshot. Whatever the case, you should back up the existing database. If you haven't changed the defaults from the Dockerfile, then ``` sudo docker exec -it hometown_db_1 pg_dump -U postgres -Fc postgres > hometown.db.dump ``` should do the trick. If you have changed the defaults, you may need to use `sudo docker ps` to figure out the name of the PostgreSQL image to swap in place of "hometown_db_1", then browse through `.env.production` to extract the username to place after `-U` and the database name to place after `-Fc`. The Hometown docs don't say how to restore the database should the process go South, but after reading a manpage or two I think the magic words are roughly ``` sudo docker exec -it hometown_db_1 pg_restore -U postgres --clean --if-exists -d postgres < hometown.db.dump ``` Now we're ready for the scary "you could destroy everything" part. All the earlier commands are trivial to roll back, but after this point any delay could cause data corruption. As per the Hometown docs, run the pre-deployment database migrations. ``` sudo docker-compose run -e SKIP_POST_DEPLOYMENT_MIGRATIONS=true -e RAILS_ENV=production --rm web bundle exec rails db:migrate ``` where `web` is the name of the webserver image in `docker-compose.yml`. The docs state you should precompile all assets next, but I'm 95% sure they were already built when you ran `sudo docker-compose build`. If you're paranoid and want to be absolutely sure precompilation is done, then at this stage run: ``` sudo docker-compose run -e RAILS_ENV=production --rm web bundle exec rails assets:precompile ``` Here, the Hometown docs say you should run the post-deployment migrations. In Docker-ese: ``` sudo docker-compose run -e RAILS_ENV=production --rm web bundle exec rails db:migrate ``` Finally, we need to stop the old images and spin up the new ones. Run: ``` sudo docker-compose up -d ``` and give Docker some time to finish rotating. A quick `sudo docker ps` should confirm the new images are booting up, and in a short while (10-15 seconds for the teeny-tiny instance I manage) you should be back to fully functional.
2023-01-17 22:39:09 +00:00
image: tootsuite/mastodon:v4.0.2
2016-10-25 12:21:48 +01:00
restart: always
env_file: .env.production
command: bundle exec sidekiq
depends_on:
- db
- redis
networks:
- external_network
- internal_network
volumes:
- ./public/system:/mastodon/public/system
2022-01-26 17:08:49 +00:00
healthcheck:
test: ['CMD-SHELL', "ps aux | grep '[s]idekiq\ 6' || false"]
2022-01-26 17:08:49 +00:00
## Uncomment to enable federation with tor instances along with adding the following ENV variables
## http_proxy=http://privoxy:8118
## ALLOW_ACCESS_TO_HIDDEN_SERVICE=true
# tor:
# image: sirboops/tor
# networks:
# - external_network
# - internal_network
#
# privoxy:
# image: sirboops/privoxy
# volumes:
# - ./priv-config:/opt/config
# networks:
# - external_network
# - internal_network
networks:
external_network:
internal_network:
internal: true