Rancher quick start load balancer issue

Hi,

I want to demo rancher and thought I’d use the quick start documentation. I ran into an issue with the load balancer.

Components version

Rancher	v0.32.0
Cattle	v0.75.0
User Interface	v0.40.0
Rancher Compose	beta/latest

Hosts OS: centos 7
Docker version: 1.8.1

Exported configuration

docker-compose.yml

wplb:
  ports:
  - 80:80
  restart: always
  tty: true
  image: rancher/load-balancer-service
  links:
  - wp:wp
  stdin_open: true
mydb:
  restart: always
  environment:
    MYSQL_ROOT_PASSWORD: pass1
  tty: true
  image: mysql
  stdin_open: true
wp:
  restart: always
  tty: true
  image: wordpress
  links:
  - mydb:mysql
  stdin_open: true

rancher-compose.yml

wplb:
  scale: 1
  load_balancer_config:
    name: wplb config
mydb:
  scale: 1
wp:
  scale: 2

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.

http://192.168.60.13/wp-login.php?redirect_to=http%3A%2F%2F192.168.60.13%2Fwp-admin%2F&reauth=1

192.168.60.13 = load balancer IP

Is this an issue between keyboard and chair or something else? :wink:

Any help appreciated.

Bob

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.

Here’s an article one of our bloggers wrote on setting up a scalable Wordpress… It uses GlusterFS for the shared files: http://rancher.com/setting-up-a-scalable-and-highly-available-wordpress-environment-with-rancher-and-docker/

@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).

This doesn’t help with the media files though.

@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 :+1:

Hello vincent,

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.

Bjørnar

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):
mywordpress:
  tty: true
  image: wordpress
  links:
    - database:mysql
  stdin_open: true

wordpresslb:
  ports:
    - "80:80"
  tty: true
  image: rancher/load-balancer-service
  links:
    - mywordpress:mywordpress
  stdin_open: true

database:
  environment:
    - MYSQL_ROOT_PASSWORD=pass1
  tty: true
  image: mysql
  stdin_open: true
  • Unable to login in the wp-admin section. Becomes a redirect_to / reauth loop for some reason. Deleting cookies makes no difference.

In the end I can only login when scaling down from 2 to 1.

Seems to be fixed in v1.1.2 and this code:

File: docker-compose.yml:

wordpress-lb:
  ports:
  - 80:80
  tty: true
  image: rancher/load-balancer-service
  links:
  - wordpress:wordpress
  stdin_open: true
wordpress:
  domainname: wordpress.internal
  tty: true
  image: wordpress:latest
  links:
  - database:mysql
  stdin_open: true
database:
  environment:
    MYSQL_ROOT_PASSWORD: pass1
  tty: true
  image: mysql:latest
  stdin_open: true

File: rancher-compose.yml:

wordpress-lb:
  scale: 1
  load_balancer_config:
    lb_cookie_stickiness_policy:
      cookie: wp-sticky
      domain: wordpress.internal
    haproxy_config: {}
  health_check:
    port: 42
    interval: 2000
    unhealthy_threshold: 3
    strategy: recreate
    response_timeout: 2000
    healthy_threshold: 2
wordpress:
  scale: 2
database:
  scale: 1

Don’t forget to set the IP-adress of the load balancer in /etc/hosts to wordpress.internal!

Hi,

This is another “me too” post.

I just ran into the problem with the Quickstart example not working due to the session problem.

I too suggest that you modify your example to something that will actually work to avoid confusing first-time users.

R.