Wordpress: Confronted with wordpress installation process every time container is recreated.

[Leopere]

What's actually broken here.

I need to either have a full list of environment variables that will make the WordPress setup screen go away after the initial setup so that I'm no longer confronted by it. The other option is if it's persistently stored somehow so that I can stop being bothered by it. The current information and example in the gist link below contains my configuration and errors in my attempt to make the wp-config.php be stored statically on the host operating system in our staging environment.

Seems that it's near impossible to get a proper container setup where you can just volume exactly what you need and destroy the entire container properly like you're supposed to.

Static content I'm currently storing

wp-content/
wp-config.php

These are my only volumes because what I was trying to do as I was trying to make it so that the very helpful scripts in this container could keep doing their jobs. I was trying to avoid even adding wp-config.php because I could tell that the script was modifying it with my environment variables.

Slight rant

The problem is that there doesn't seem to be a single example on the Readme for this project that establishes a truly ephemeral container. There doesn't seem to be documentation supporting situations where your content is stored elsewhere ( like the database ) and any filesystem data can be stuck in an external volume.

If there is sufficient information to support a Docker best practice example it's not very clear where these points are in the Readme. As a result I've seen most people storing their entire WordPress installation externally to the container which basically reduces the entire container to simply a LAMP stack with WordPress dependencies and a volume with WordPress in it. Ideally we should have an example that supports the most advantages provided by docker. By this I'm suggesting something that will easily transition from a local mom & pop shop host at home WordPress installation to a full scale deployment in a docker stack or Kubernetes cluster.

My configuration currently

I've posted my Dockerfile docker-compose.yml excerpt and the docker logs output in this https://gist.github.com/ link.

[yosifkit]

If you are providing a complete wp-config.php file via a single file bind mount, then you cannot provide WORDPRESS_DB_PASSWORD, WORDPRESS_DB_HOST, or WORDPRESS_DB_USER and should instead just embed them in your file, otherwise it will cause the sed to fail (since it tries to rename the file and can't because it is a bind mount).

Also, your ADD line does not work since that directory is declared as a volume in the WordPress image: https://github.com/docker-library/wordpress/blob/59f3b513af128d12da1403721e4f9be8d882ec54/php7.2/apache/Dockerfile#L44

[Leopere]

@yosifkit thanks for your reply, I've changed this stuff since posting this issue. I was actually hoping with the Dockerfile add was to have it be possible to insert the config from the developer side but you're right it ended up conflicting.

My goal is to make it so that the developers can make changes to the environment on their machine before it gets pushed to the group's staging server. Then eventually have those changes be ported into production.

I'm seeing a lot of ways that WordPress makes this impossible like things that aren't only stored in the filesystem but are customized inside of the SQL database so now you'll have to write complex SQL queries to port the changes from the dev environment to the production environment without clobbering your production data.

[Leopere]

What file needs to be changed or set in order to make the settings declared in /wp-admin/install.php or whatever other files to make it stop asking me to install WordPress every single time I re-launch this container? Running a docker diff seems to make nothing obvious. It just shows that these files below changed.

docker diff stagingcompose_wordpress_1
C /run/apache2
A /run/apache2/apache2.pid
C /tmp

I'm also making the MariaDB's backend persistent across re-deploys so I can't begin to imagine why this is happening.

[martinvirtel]

@chamunks if you mount /var/www/html to a directory in your local file system, the install will persist there. E.g. docker run -v /tmp/wordpress-html:/var/www/html wordpress

[Leopere]

@martinvirtel thats kind of part of the issue you should really only need to mount things like wp-plugins and wp-content but instead you have to mount the entire WP installation.

[tianon]

You probably need to include the configuration file too (which mounting
everything will achieve)

[Leopere]

Right, yes, I forgot to include that in my reply my apologies.

On Fri, May 18, 2018 at 2:27 PM Tianon Gravi [e-mail]
wrote:

You probably need to include the configuration file too (which mounting
everything will achieve)

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/docker-library/wordpress/issues/292#issuecomment-390293125,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABBNVqDeUdtxYRNu7fGtXkMWaSpTB86Rks5tzxKWgaJpZM4S6Lum
.

[eduwass]

@chamunks I only have volumes for plugins/themes + one for the database, everything else I set via env vars.

Here's my docker-compose.yml:

version: '3.3'

services:
  wordpress:
    depends_on:
     - db
    image: wordpress:latest
    ports:
     - "80:80"
    restart: always
    environment:
     WORDPRESS_DB_HOST: db:3306
     WORDPRESS_DB_USER: wordpress
     WORDPRESS_DB_PASSWORD: wordpress
     WORDPRESS_DEBUG: 1
    volumes:
    - "./wp-content/plugins/:/var/www/html/wp-content/plugins/"
    - "./wp-content/themes/:/var/www/html/wp-content/themes/"
    - "./.htaccess:/var/www/html/.htaccess"

  db:
    image: mysql:5.7
    command: mysqld --sql_mode=""
    volumes:
     - ./.dbdata:/var/lib/mysql
    restart: always
    environment:
     MYSQL_ROOT_PASSWORD: somewordpress
     MYSQL_DATABASE: wordpress
     MYSQL_USER: wordpress
     MYSQL_PASSWORD: wordpress
    volumes:
      - "./dump.sql:/docker-entrypoint-initdb.d/dump.sql"

[Leopere]

@eduwass do you have this in production? What's your full deployment cycle instructions I've been desperately wanting to enable web developers that I work with the ability to modify a dev instance of our WordPress sites to no avail using Docker.

I really don't think that it's professional to modify a live deployed site and Docker would enable this if WordPress wasn't designed for a completely different time. Also is there a specific reason you went with MySQL rather than MariaDB?

[eduwass]

@chamunks I just use it locally for development, then push the changes to the remote server using Git. I keep the docker-compose.yml in the repo so it's easy for other people in the team to boot the whole stack up with just a docker-compose up.

In case I need to push DB changes, I'll use wp-sync-db to do the sync between environments.

This has basically been my workflow for a while and I haven't had any problems.

No particular reason for MySQL vs MariaDB.

Good luck my friend!

[cjmielke]

@Leopere did you ever find a way to kill the setup? I'm having this problem too while trying to simply migrate the install, and it's frustrating

[chrisbloemker]

@cjmielke what do you mean kill the setup? I'm assuming you're not talking about docker-compose down on the stack..

[Leopere]

@cjmielke sorry no I didn't find a way to kill the setup I just ended up spinning up a dedicated DigitalOcean VPS for just the Wordpress itself because I needed progress more than I needed Docker however I really would think that some kind of solution does need to be found here. Deploying PHP applications needs to suck less. Anyone who develops PHP however thinks this is a perfectly sane and normal way to live life.

[Leopere]

@cjmielke / @chrisbloemker basically the issue that I'm having is that the Docker container installs a fresh copy of Wordpress if there isn't a fresh copy in your data volume /var/www/html as mentioned by @martinvirtel earlier on. However if you do this then you're stuck with basically a pumped up Nginx/Variant container called WordPress.

True statelessness should have Plugins be in their own separate data volume and configs in their own. Then the Env Vars should be installed opportunistically on container start and then Wordpress should do its own checks against the config and adjust for whatever changes might've happened against its own data. However this is sadly not seemingly a possibility because of how PHP is just not designed for this. You're supposed to install this behemoth once and then hope that no one manages to knock its security over somehow thus warranting a completely fresh install as you can never really eliminate an infection.

Sadly this being the problem that it is basically has me believing that WordPress basically just shouldn't be a thing anymore and someone should replace it rather than continuing to beat a dead horse.

[yosifkit]

Glad you have something worked out; sorry that the image does not work the way you expect.

[cjmielke]

I changed the docker-compose recommendation to map /var/www/html as a volume instead of the separate subdirectories. To rescue the "state" from the prior container I did a docker cp. Works now. This appears to be the procedure required for any migrations. Wordpress must be marking a file somewhere in its installed directory, which is not mounted as persistent in the sample compose file.

[Leopere]

@yosifkit ah it works mostly the way I wanted it to I just couldn't figure out why it kept kicking me back into the installer when you redeploy the container if you don't volume the entire /var/www/html directory.