help debug docker recipe of deploying Wordpress website

[pedro.de.marco]

WordPress, Docker & phpMyAdmin Setup – Web Development

www.jjwdesign.com

I'm kind of new with "docker"
When I run the machine (containers ...) I ran to some problems.
One of them was the problem that I was not able to upload images to the "local website" and here I tried to fix it by fixing the file permissions.
The first time I ran the command in the running wordpress container, then added the following line to the docker-compose.yml
command: chown -R www-data:www-data /var/www/html/wp-content/uploads
After reloading the system, I get the following error in the terminal:
wp-localcopy1_wordpress_1 exited with code 0
and there's no website on port 8080.
When I commented the line, it began to work.
However I have another problem.
I'm unable to download themes. Even if the file permission are fixed.
When I try to, I get the error that demands FTP password, which the wordpress has not provided me with one.
Helps appreciated.

 

[gvisoc]

Hi.

Sorry for the late reply. Can you post the whole docker-compose.yml file? That way I can reproduce to begin with.

 

[gvisoc]

For now, following the post is allowing me to upload images with no problem, and also was able to install JetPack from the "Add new Plugin" screen.

Without knowing a bit more the actual plugin you're trying to install, and what modifications may have you done to your docker-compose.yml file, I can't reproduce your issues.

 

[pedro.de.marco]

Hello and thanks for your reply. Today I started running the setup, I thought it would be a good idea to delete the created "docker networks". So I started to stop and remove the whole running containers and docker networks.
sudo docker network prune
Now the setup is not working.
sudo docker-compose up
Creating network "wp-local-test-zero_mynet" with the default driver Starting wp-local-test-zero_db_1 ... error ERROR: for wp-local-test-zero_db_1 Cannot start service db: network e0201ea69f1b4c38194c34acfc49e1e2c7e542dae7c7b2947de6b74bfbace53c not found ERROR: for db Cannot start service db: network e0201ea69f1b4c38194c34acfc49e1e2c7e542dae7c7b2947de6b74bfbace53c not found ERROR: Encountered errors while bringing up the project.
Note: I have previously, successfully changed the DB name, username, passwords and it worked, with above bugs.
Edit: After this post, I rebooted the system and I still get the above mentioned error.
When running:
sudo docker network ls
I see a few networks. I'm unable to remove them simply by "docker network rm <network> " command
NETWORK ID NAME DRIVER SCOPE 67a0fdd09fb9 bridge bridge local 046ad4f5d62f host host local 06cc4ef3ea41 none null local
I assume the setup is trying to find a docker related network that it should have created it in the first place, or there are 3 running networks that I'm failing to stop. lol. I don't know what happened. any suggestions appreciated before I reinstall docker.

EDIT 2:
I tried the " -a " option as some online search suggested.
sudo docker container ls -a
And what a mess. A long list of containers that do not appear in a normal "container ls" command. I manually removed them all. Then ran the docker-compose.YML (the setup) again. now back to point zero.

EDIT 3:
I ran the setup and here we are again. Without the chmod wordpress is unable to upload image to the site.
then I added the following line to the end of docker-compose.yml:
command: chown -R www-data:www-data /var/www/html/wp-content/
and again the error:
sudo docker-compose up [sudo] password for sage: Starting wp-local-test-zero_db_1 ... done Starting wp-local-test-zero_phpmyadmin_1 ... done Recreating wp-local-test-zero_wordpress_1 ... done Attaching to wp-local-test-zero_db_1, wp-local-test-zero_phpmyadmin_1, wp-local-test-zero_wordpress_1 db_1 | 2022-05-19 13:58:03+00:00 [Note] [Entrypoint]: Entrypoint script for MySQL Server 5.7.37-1debian10 started. phpmyadmin_1 | AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 172.18.0.3. Set the 'ServerName' directive globally to suppress this message db_1 | 2022-05-19 13:58:03+00:00 [Note] [Entrypoint]: Switching to dedicated user 'mysql' phpmyadmin_1 | AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 172.18.0.3. Set the 'ServerName' directive globally to suppress this message db_1 | 2022-05-19 13:58:03+00:00 [Note] [Entrypoint]: Entrypoint script for MySQL Server 5.7.37-1debian10 started. phpmyadmin_1 | [Thu May 19 13:58:04.030698 2022] [mpm_prefork:notice] [pid 1] AH00163: Apache/2.4.52 (Debian) PHP/8.0.15 configured -- resuming normal operations phpmyadmin_1 | [Thu May 19 13:58:04.030780 2022] [core:notice] [pid 1] AH00094: Command line: 'apache2 -D FOREGROUND' db_1 | 2022-05-19T13:58:03.742533Z 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server option (see documentation for more details). db_1 | 2022-05-19T13:58:03.745000Z 0 [Note] mysqld (mysqld 5.7.37) starting as process 1 ... db_1 | 2022-05-19T13:58:03.749712Z 0 [Note] InnoDB: PUNCH HOLE support available db_1 | 2022-05-19T13:58:03.749747Z 0 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins db_1 | 2022-05-19T13:58:03.749757Z 0 [Note] InnoDB: Uses event mutexes db_1 | 2022-05-19T13:58:03.749765Z 0 [Note] InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier db_1 | 2022-05-19T13:58:03.749772Z 0 [Note] InnoDB: Compressed tables use zlib 1.2.11 db_1 | 2022-05-19T13:58:03.749781Z 0 [Note] InnoDB: Using Linux native AIO db_1 | 2022-05-19T13:58:03.750278Z 0 [Note] InnoDB: Number of pools: 1 db_1 | 2022-05-19T13:58:03.750443Z 0 [Note] InnoDB: Using CPU crc32 instructions db_1 | 2022-05-19T13:58:03.753047Z 0 [Note] InnoDB: Initializing buffer pool, total size = 128M, instances = 1, chunk size = 128M db_1 | 2022-05-19T13:58:03.769836Z 0 [Note] InnoDB: Completed initialization of buffer pool db_1 | 2022-05-19T13:58:03.773576Z 0 [Note] InnoDB: If the mysqld execution user is authorized, page cleaner thread priority can be changed. See the man page of setpriority(). db_1 | 2022-05-19T13:58:03.786812Z 0 [Note] InnoDB: Highest supported file format is Barracuda. db_1 | 2022-05-19T13:58:03.811229Z 0 [Note] InnoDB: Creating shared tablespace for temporary tables db_1 | 2022-05-19T13:58:03.811458Z 0 [Note] InnoDB: Setting file './ibtmp1' size to 12 MB. Physically writing the file full; Please wait ... db_1 | 2022-05-19T13:58:03.884411Z 0 [Note] InnoDB: File './ibtmp1' size is now 12 MB. db_1 | 2022-05-19T13:58:03.885707Z 0 [Note] InnoDB: 96 redo rollback segment(s) found. 96 redo rollback segment(s) are active. db_1 | 2022-05-19T13:58:03.885729Z 0 [Note] InnoDB: 32 non-redo rollback segment(s) are active. db_1 | 2022-05-19T13:58:03.886527Z 0 [Note] InnoDB: 5.7.37 started; log sequence number 14804964 db_1 | 2022-05-19T13:58:03.886681Z 0 [Note] InnoDB: Loading buffer pool(s) from /var/lib/mysql/ib_buffer_pool db_1 | 2022-05-19T13:58:03.887016Z 0 [Note] Plugin 'FEDERATED' is disabled. db_1 | 2022-05-19T13:58:03.891522Z 0 [Note] InnoDB: Buffer pool(s) load completed at 220519 13:58:03 db_1 | 2022-05-19T13:58:03.896239Z 0 [Note] Found ca.pem, server-cert.pem and server-key.pem in data directory. Trying to enable SSL support using them. db_1 | 2022-05-19T13:58:03.896262Z 0 [Note] Skipping generation of SSL certificates as certificate files are present in data directory. db_1 | 2022-05-19T13:58:03.896269Z 0 [Warning] A deprecated TLS version TLSv1 is enabled. Please use TLSv1.2 or higher. db_1 | 2022-05-19T13:58:03.896277Z 0 [Warning] A deprecated TLS version TLSv1.1 is enabled. Please use TLSv1.2 or higher. db_1 | 2022-05-19T13:58:03.896985Z 0 [Warning] CA certificate ca.pem is self signed. db_1 | 2022-05-19T13:58:03.897039Z 0 [Note] Skipping generation of RSA key pair as key files are present in data directory. db_1 | 2022-05-19T13:58:03.897601Z 0 [Note] Server hostname (bind-address): '*'; port: 3306 db_1 | 2022-05-19T13:58:03.898007Z 0 [Note] IPv6 is available. db_1 | 2022-05-19T13:58:03.898031Z 0 [Note] - '::' resolves to '::'; db_1 | 2022-05-19T13:58:03.898083Z 0 [Note] Server socket created on IP: '::'. db_1 | 2022-05-19T13:58:03.899904Z 0 [Warning] Insecure configuration for --pid-file: Location '/var/run/mysqld' in the path is accessible to all OS users. Consider choosing a different directory. db_1 | 2022-05-19T13:58:03.920484Z 0 [Note] Event Scheduler: Loaded 0 events db_1 | 2022-05-19T13:58:03.920761Z 0 [Note] mysqld: ready for connections. db_1 | Version: '5.7.37' socket: '/var/run/mysqld/mysqld.sock' port: 3306 MySQL Community Server (GPL) wp-local-test-zero_wordpress_1 exited with code 0 wp-local-test-zero_wordpress_1 exited with code 0 wp-local-test-zero_wordpress_1 exited with code 0 wp-local-test-zero_wordpress_1 exited with code 0 wp-local-test-zero_wordpress_1 exited with code 0 wp-local-test-zero_wordpress_1 exited with code 0 wp-local-test-zero_wordpress_1 exited with code 0 wp-local-test-zero_wordpress_1 exited with code 0 ^CGracefully stopping... (press Ctrl+C again to force)

 

[gvisoc]

Hi

Sorry for the delay. With the unmodified docker-compose I am able to upload images and plugins. The error you are experiencing is not in the container, so the chown line is not fixing anything (and maybe is breaking something inside).

If you have any problem with permissions or ownership, you need to fix them in the host machine (your OS). This is because the docker-compose is mapping the subdirectory ./wordpress to the /var/www/html directory of your container (see line 39 of your docker-compose). Therefore, all the images and plugins you are trying to upload need to be able to be written in the ./wordpress subdirectory of your working directory, by the container.

My guess is that the problem is, either:

1. that you are not part of the docker group and hence your containers have somehow trouble writing on your home directory,
2. or that you ran some commands with sudo when you didn't need to, and now ./wordpress belongs to root and hence no one can write into there without sudo.

Try the following:

1. Remove that line in the docker-compose file (use the docker-compose.yml of the article, unmodified)
2. Check that your user is part of the docker group. That should grant write permissions to docker containers in your directories. Check that your machine verifies this: https://docs.docker.com/engine/install/linux-postinstall/
3. Check that ./wordpress belongs to you, and not to root. Sometimes an unnecessary sudo can cause a lot of trouble like this. If that is the case, chown it to back to your user. Do not chown it to www-data, as the users and groups on your host machine are not mapped in any way to the container (coincidentally root is, but because root has the same guid in all linux machines and therefore always matches).

 

[gvisoc]

Realising that you run your docker commands with sudo.

The thing is that, the more I think of it, the more I suspect that your wordpress directory may belong to root because you used sudo docker-compose up

In a working installation of docker where I don't need to issue docker commands with sudo (following the link in point #2, these are the ownerships and permissions of both mapped directories docker and wordpress:

Both docker and wordpress are created by the container, so that all the permissions and user groups need to be in place so that the wordpress process can write into your hosts' wordpress directory.

If you ran the command with sudo, but the container, internally, runs the wordpress process (apache, probably) under a user other than root, that may cause write problems. And the thing is that such process is ran by a user with ID 33 and a group ID that coincidentally matches to my local group "tape": that folk is definitely not root.

Try to do the post-installation steps linked on the previous post, step #2, clean all yoru containers to start over from a clean docker network, and run docker-compose up without sudo (unmodified docker-compose.yml).

 

[gvisoc]

Another finding: inside the container that is created by the vanilla (unmodified) docker-compose,yml, all those files are already belonging to www-data.

The line in the following screenshot opens a /bin/bash interpreter inside the container that is running wordpress. It's like doing SSH into the container, but the elephant docker way

Therefore my comment that such chown line on the docker-compose file is not needed / won't solve anything.

This shows 2 things:

• As I was saying, the container's www-data doesn't map to your host's www-data (it maps to 33 and tape in my case)
• It reinforces my feeling that the problem is on your host machine's filesystem.

 

[pedro.de.marco]

In the documentations of docker, it was mentioned that you might not like to de-sudo the docker bc from the linux security perspective no docker image has the right to run without sudo bc it can do nasty stuff if you don't know what's in it. But in this case there is no other users and only I have access to the local device so it's ok to remove the sudo though i did not want to do it. So I did and after reboot the problem persists and I'm prompted for the FTP account , same as before.
However thank you very much.
I really need this local setup bc it would be my way of running the server and I really need the local network speed rather than the slow cheap hosts.

 

[gvisoc]

What the docker documentation says is that beware that the docker group has the same permissions as the sudoers. The practical benefits of issuing sudo before the docker commands are that (i) it gives you a moment to think, as it asks for the password, and (ii) in corporate environments, sudoed operations get audited.

I'm afraid the permissions/ownership problem will persist until you fix them manually. This, however, it's too complicated to consider unless you have anything valuable on the mapped filesystem. If that is not the case, which is what I assume (as you had problems that prevented you to progress), the easiest way forward is to tear everything down and recreate all the containers, to start anew.

You can do that by:

1. Run docker-compose down: that will remove the containers and networks. No need to remove them with docker one by one
2. Delete the subdirectories the containers had created (on the top of my head, wordpress, docker). It may ask you for sudo.

After that, again docker-compose up without sudo.

 

[pedro.de.marco]

docker network rm 4569a73e7769
Error response from daemon: bridge is a pre-defined network and cannot be removed

I'm trying. I ran:

docker network prune
/path $ docker-compose down
#it was done in project folder with YAML file.
docker network ls
docker network rm [dock-net-name]

it appears that only one network was brought down. And shouldn't all these docker networks be automatically removed by reboot? is there any way around this?
then I got then I still see 4 networks.
Then I remembered to :

docker container ls
docker container stop [only-one-container-that-was-still-running]
# then
docker container ls
# nothing
docker container ls -a
# 3 containers appeared. then I stopped and removed them.
docker container stop [cont-names]
docker network ls
docker network rm [cont-names]
docker network ls

Some networks survive all these rm commands :/
Now let's run again.
Yep. the problem persists. It asks me for FTP account, and yes, all the problem persists.
Now here's my question. Does docker become a pain in the A$$ when using it a little bit complicated?
Before finding this docker-compse file and this setup, I used docker in a very simple form, just like a VPS. All the applications in one container, then after the contained is built, it's saved as an image so I can work on it later. Everything on one image, one project, one website, simple. And I used to build the images from a bare linux image. May be I should do this again. In this case, I will install mysql , phpmyadmin and wordpress all in one container and see how it works.

Cheers.

 

[gvisoc]

Please do just docker compose down. You brought up the appliance with docker compose, both network and containers, and docker compose can tear it down (both network and containers). You don't need to go down the hard path and do docker compose's work yourself.

Sometimes who puts together the images is opinionated in the assumption on whether or not you should / would / will use docker with or without sudo. As I said, I can't reproduce your problem in my system, where I can run (and I run) docker without sudo. Everything works as expected by default, untouched.

Anyway, if the scope of your work is at the application level, and putting all it in an image as if it was a VM works for you, go for it.

Docker compose is more to create testing environments where you can explore what would happen when bringing down separate containers. It's not even how things get deployed to production when working with containers, it's not production-ready. Using it may not add any value to you, in that case it'd be fine not using it.