If I go throught the creation/start steps with only 1 wordpress container: no problem.
If I scale up (+1) wordpress containers or restart from scratch choosing 2 wordpress containers in the GUI, I can get the wordpress web page, I can go trough the site creation, I can verify the wordpress schema and tables have been created, but login in is not possible, I’m redirected to the login page without errors.
You’re not doing anything wrong but horizontally scaling an application isn’t as simple as clicking the +1 button unless it’s really designed for that.
In this case Wordpress is really designed to run on a single server, so their Docker image doesn’t do anything about the default PHP session storage being files on local disk. You login and it succeeds, a session is created, written to disk and its ID returned in a cookie. Then the next request comes in and the balancer sends it to the other container(s), which have no session file for that ID, so it has no idea who you are and sends you back to the login page.
I haven’t done PHP in several years but there are hooks you can implement to store the session into something shared like the database or memcached. Back then we wrote our own implementation and I think it required patching PHP to get all the hooks that were needed but I’m pretty sure there are prepackaged PHP extensions (or Wordpress plugins) that do this now.
Once you fix that you’ll have something that almost appears to work but is in fact still totally broken. Now you’ll be able to login but will have the exact same problem with all the uploaded media, theme, etc files that are stored on local disk of only the container you hit while uploading them. I think there are plugins to store those in services like S3, or you can use a shared filesystem like an NFS mount or GlusterFS so all containers have access to the same files. This would work to share the default file-based sessions too.
@alena pointed out that you could use the load balancer stickiness policy feature (with the PHPSESSID cookie) to address the login/session problem.
I would still suggest storing them somewhere actually shared (like the MySQL server that WordPress already depends on) but stickiness would mostly work (if a container goes down any sessions that live on it go with it).
@vincent, thanks a lot for the detailed answer. I’ll check out the GlusterFS article: that’s a proper solution. I’ll give it a shot with a NFS share first though. For my demo purposes I’ll go with a stateless app we developed internally. It’ll be a use case at the same time.
Once more, thank you very much for taking the time to answer in great detail. Much appreciated
Sorry for bumping this topic, but I think you should know. Recently, I too ran into this issue when following the quickstart guide. You might want to tweak the suggested scale setting for wordpress in the guide so as to not confuse newcomers with an example that isn’t working quite right.
There are more issues with the WordPress quick start based on the compose-files:
The docker-compose.yml seems to be invalid. Errors like this: Service 'wordpresslb' configuration key 'links' contains an invalid type, it should be an array.
This is a working version (instead of a PR on Github):