otland
feat: run TFS in docker using docker-compose.yaml
All is described in docker/README.md.
It's docker configuration made using docker-compose.yaml.
It starts TFS, MariaDB and phpMyAdmin inside containers.
You can connect to it from Tibia Client using URL http://127.0.0.1:8080.
It creates account with e-mail tfs@tfs and password tfs.
On account are characters GOD and 1 for each vocation.
MariaDB runs on port 3307, not 3306, to do not require to shutdown local MySQL/MariaDB. You can access it using login root and password root.
phpMyAdmin runs on port 8081, you can access it using http://127.0.0.1:8081/
EDIT: To make it possible to login, these 2 PRs must be merged:
- https://github.com/otland/forgottenserver/pull/4957
- https://github.com/otland/forgottenserver/pull/4958
This code 'works' without these PRs, but TFS won't listen on 8080 (HTTP), so to login into account in Tibia Client, you would need to setup acc. maker and use different login URL.
restart: on-failure should be unless-stopped on all containers, an if you are going to add container names they also should be on all services.
Edit: also its docker compose and not docker-compose with the newest docker version and the plugin, docker-compose is outdated.
@gesior phpmyadmin and mariadb are still missing the
restartattribute
Maybe I'm missing something, but how mariadb/phpmyadmin can restart by itself?
TFS can restart by some /shutdown talkaction or restart every 24 hours to execute server save or server crash.
MariaDB could restart on real system (ex. Ubuntu) by auto-updates, but Docker does not run systemd, including auto-updates.
I'm developing local docker dev env. Not some cloud prod env, as nobody will every try to use TFS inside docker on prod.. for sure not using my Dockerfile/docker-compose.yaml.
For example when a power outage occurs. Right now only the tibia server would start again but not the database.
I'm developing local docker dev env. Not some cloud prod env, as nobody will every try to use TFS inside docker on prod.. for sure not using my
Dockerfile/docker-compose.yaml.
That's really a stupid reason not to add it tho, also it works like that for your local env too
For example when a power outage occurs.
Maybe. What will happen to MariaDB data in case of power outage with OTS online writing to it? Will it stay in sync or require manual restart/reset? We are still talking about MariaDB running with data stored inside container, not on some external volume!
Do we fix any real problem? Or you just report some cloud theoretical problems, that does not occur on local PC?
That's really a stupid reason not to add it tho, also it works like that for your local env too
Can I test it somehow? I like to fix problems, but real problems, that can be reproduced somehow.
I got simple scenario that this PR fixes:
Run docker compose up -> you can login into TFS with Tibia Client 13.10.
How can I test power outage scenario? As @yesits-me said. There are a lot of people trying to stall PRs for no real reason.
I got Bluetooth power control (on/off) between UPS and PC with less that millisecond cut-out time, which drives my UPS and half of home electricity off pretty often (when it turns it on at the wrong ms of the 50Hz sine cycle, making it draw more than 10A). Can I test this power outage somehow? How many restarts of PC will it take? 1? more? Do I have to make real power outage to PC or I can run some docker command to reproduce it?
EDIT: Anyway, as this part of README.md says ( https://github.com/otland/forgottenserver/pull/4959/files#diff-da8fcbe728a9172b578e5d754f8e2df214c658c4321f610e63dd68bea828ab49R17 ):
Database data is not stored outside docker container. Every `docker compose down`, it resets a database to state from `docker/data.sql`. If you want to add more accounts/characters, put them in that `.sql` file.
It also applies if you turn off docker desktop. When you have restart: unless-stopped it restarts itself (atleast i am pretty sure it does). I am not trying to stall this, I am just saying it doesnt make sense to have it on the server but not on the database.