wordpress
wordpress copied to clipboard
docker-library
Include WP-CLI in all WordPress images
For a while now, WP-CLI has become the official way to manage WordPress from scripts / command line.
But if you glance through docker-entrypoint.sh, the current way of installing WordPress and hacking wp-config.php with sed and awk is not pretty and error-prone compared to a bunch of WP-CLI commands like
wp core download
wp config set
wp core install
WP-CLI doesn't take too much space, and it's become essential. I propose to:
- include
WP-CLIin all official WordPress images, - deprecate the stand-alone
WP-CLIimage, - refactor
docker-entrypoint.shusingWP-CLI.
It will show the community the relevant way of managing WordPress from the command line, and will make it easier to actually use the image later on. It will also solve #256.
Having the same problem. It would be nice to be included in WP image.
While it is a great tool, it is not included in the image for a number of reasons:
- it is not the canonical way to install wordpress (https://codex.wordpress.org/Installing_WordPress)
- it cannot be removed; some users won't need it
- the cli image can be used to manage a wp installation in another container
$ docker run --name some-mysql -e MYSQL_ROOT_PASSWORD=my-secret-pw -d mysql:5.7 2bc33cf6d0f63ddd04ab46af874aac441377d9878ed3de303354e6a53ce82a2f $ docker run --name some-wordpress --link some-mysql:mysql -p 8080:80 -d -e WORDPRESS_DB_PASSWORD=my-secret-pw wordpress dc783a30d5a4e546e74f0b9c3a04312c1b7d107208dd0fc97aea1770ee100454 $ docker run -it --rm \ > --volumes-from some-wordpress \ > --network container:some-wordpress \ > wordpress:cli user list Error: The site you have requested is not installed. Run `wp core install` to create database tables. $ # ran through setup in browser $ docker run -it --rm --volumes-from some-wordpress --network container:some-wordpress wordpress:cli user list +----+------------+--------------+-----------------+---------------------+---------------+ | ID | user_login | display_name | user_email | user_registered | roles | +----+------------+--------------+-----------------+---------------------+---------------+ | 1 | asdf | asdf | [email protected] | 2018-06-22 21:42:02 | administrator | +----+------------+--------------+-----------------+---------------------+---------------+
- https://codex.wordpress.org/Installing_WordPress DOES contain the suggestion to use wp-cli:
Installing through wp-cli wp-cli is a great command line tool with which you can easily install and update WordPress and themes and extensions.
-
Most users need it (those kind of users who mess with Docker, most of them), and it’s tiny so it doesn’t really matter.
-
WP-CLI can be used from WordPress image or anyone can craft a their own WP-CLI-only image if they desire so.
The fact that WP-CLI and WP images are based on different distribution is troublesome as linked issues show.
Including WP-CLI will make wp so much more programmatically manageable.
Personally, I use it for managing users, roles, and plugin activation/dectivation from CLI. I agree that:
- It's a small utility in comparison to WP.
- Having to deploy a separate container just for this - by me it's an overkill.
- As part as WP containers build and automation I don't like the idea that to activate plugins (from CLI) - I need to run another container ... just because the wp-cli is missing
Yes, I also found it very useful! And I think that is lightweight and really is not intrusive for people that not use it.
Any updates on this? Are there any plans to include wp-cli in WordPress docker images?
I too am interested to see. Currently using a variant just to get CLI running. Feels like this should be baked in.
I also agree. I feel like anyone who's using Docker to manage WordPress installations is very, very likely to use CLI too.
I also anticipated this being built in. Considering the barrier to entry is understanding and using Docker, WP CLI would be a justifiable inclusion for devops workflows.
An issue with relying on the current wordpress:cli image for this functionality is that, as explained here, the CLI image is based on Alpine whereas the WordPress Apache images are based on Debian, resulting in differing uid's, preventing the CLI from doing basic things like downloading & installing a new plugin.
A possible solution to this would be to use one of the Alpine WordPress images, but apparently using one of these would require you also spin up a separate Apache container, which I expect most people aren't interested in doing.
There shouldn't be anything stopping the CLI image from running as an arbitrary user, ala docker run ... --user 33:33 wordpress:cli wp ... (https://github.com/docker-library/docs/tree/master/wordpress#running-as-an-arbitrary-user).
I have created some images which include wp-cli and some other nice stuff.
Currently only for php-fpm because I'm lazy to make the other ones (I will do it soon ).
https://github.com/ivandotv/docker-wordpress-image
What is the point of running wp-cli in wordpress container? The point of containers is to run one service per container, you can use Dockerfile defined below and just mount /var/www/html to this container, then execute your commands. More advanced setup can be seen here https://github.com/project-wordpress/wpdev
FROM wordpress:cli-php7.4
USER root
COPY wait-for-it.sh /usr/local/bin/wait-for-it
RUN chown www-data:www-data /usr/local/bin/wait-for-it && \
chmod +x /usr/local/bin/wait-for-it
COPY entrypoint.sh /usr/local/bin/entrypoint.sh
RUN chown www-data:www-data /usr/local/bin/entrypoint.sh && \
chmod +x /usr/local/bin/entrypoint.sh
RUN mkdir /backups && chown www-data:www-data /backups
USER www-data
WORKDIR /backups
RUN mkdir ~/.wp-cli && echo "path: /var/www/html" > ~/.wp-cli/config.yml
ENTRYPOINT ["entrypoint.sh"]
What is the point of running
wp-cliin wordpress container?
wp-cli is not really a service (ie. it does not run in the background), but just tool to manage your WordPress instance.
Sure you can start a new container with wp-cli, plug it to your wordpress /var/www/html and run your commands, but having it bundled with your WordPress container is a lot easier, especially if you're using docker-compose or Kubernetes and do not want to manage your containers manually.
For reference, a lot of apps have their CLI either part of the project itself (NextCloud, Symfony based apps, etc...) or are added to their containers for convenience.
If some are interested, I also developed for my company a docker container based on the WP official images and which adds wp-cli with several other libraries like memcached and LDAP support : https://github.com/Monogramm/docker-wordpress
and do not want to manage your containers manually
So why bundle wp-cli? Installation is more vulnerable, official docker images are make so to be minimal. Also other points that are valid from 2nd reply:
- it is not the canonical way to install wordpress (https://codex.wordpress.org/Installing_WordPress)
- it cannot be removed; some users won't need it
- the cli image can be used to manage a wp installation in another container
and do not want to manage your containers manually
So why bundle
wp-cli?
When I say "manage your containers manually", I mean to manually create new containers with wp-cli to manage a Wordpress instance. Having wp-cli in the container can allow you to manage your instance without creating a new container.
Installation is more vulnerable, official docker images are make so to be minimal. Also other points that are valid from 2nd reply:
- it is not the canonical way to install wordpress (https://codex.wordpress.org/Installing_WordPress)
- it cannot be removed; some users won't need it
- the cli image can be used to manage a wp installation in another container
I agree with you on those, though regarding the last point, it's usually easier to have each WP instance use their own wp-cli, and I think maybe better if you want to run wp-cli operations on several WP instances at the same time.
Anyway, I do not mind WP's decision to keep their container minimal. I just think that having another container based on official WP which adds wp-cli (what we did in our containers) is simpler than a having a "wp-cli only" container that you need to plug to the correct wordpress instance everytime you need it...
What about bundling that minimal wp-cli that really runs a service? The entrypoint just blocks forever, and then its a real service - API. Is that a solution? For me it looks clear and gives a lot of space for running some pre-installs or pre-checks, or even a cronjob that performs updates automatically.
It would make sense for a cronjob purpose , but otherwise it would be more problematic since you would need to stop the container first before switching to another WP instance...
need to stop the container first before switching to another WP instance...
I don't get the point, can you explain with use case?
need to stop the container first before switching to another WP instance...
I don't get the point, can you explain with use case?
It's as you mentioned before: the cli image can be used to manage a wp installation in another container.
To do that with the container, you need to mount the /var/www/html of the WP instance you want to manage to your wp-cli container:
docker run -it --rm \
--volumes-from some-wordpress \
--network container:some-wordpress \
wordpress:cli user list
So if you have 2 wordpress containers, A & B, respectively with the following volumes:
- WP_A:
/srv/wordpress_a/html:/var/www/html - WP_B:
/srv/wordpress_b/html:/var/www/html
If you have a single wp-cli container, with a volume mounted to WP A (/srv/wordpress_a/html:/var/www/html), you will need to stop it first, change the volume to WP B (/srv/wordpress_b/html:/var/www/html) before managing your WP B instance.
Or, you need to mount volumes from all your WP instances to wp-cli container and always execute commands with --path to WP files you want to manage.
In that case, it's probably easier to just have a wp-cli container for each of your WP instances...
But if you have wp-cli in each wordpress instance, you have to do the same (change your command)?
But if you have
wp-cliin each wordpress instance, you have to do the same (change your command)?
No you don't. That's the big advantage. When wp-cli is bundled with Wordpress, wp-cli will use the default path, which corresponds to the current WordPress instance.
If you're using docker-compose, you can just run the following command:
docker-compose exec my_wordpress_with_cli wp user list
And just replace the my_wordpress_with_cli with the name of the WP instance you want to manage.
So you have a lot of wordpress sites in one docker-compose.yaml file if i understand that correctly?
Are you using named volumes or host binding?
So you have a lot of wordpress sites in one
docker-compose.yamlfile if i understand that correctly?
Well, that's not my use case, I usually only have one WordPress at the time, but this is the use case for the point you mentioned.
Are you using named volumes or host binding?
Why this would be relevant ?
@madmath03
With this command you can still connect to all stacks if you have consistent naming, just change $NAME
NAME=wpdev && docker run -it \
--volumes-from="${NAME}_wordpress_1" \
--network="${NAME}_default" \
wordpress:cli-php7.4 \
\
/bin/bash -c "wp core update"
Success: WordPress is up to date.
Or if you have non-consistent naming place .env file in your docker-compose.yaml folder, docker-compose will read it automatically:
---------- 420 buk 345233 236 Jan 26 14:06 .env
---------- 420 buk 345233 124 Jan 26 14:06 docker-compose.yaml
# .env
NETWORK_NAME=mynetwork
WORDPRESS_CONTAINER=mycontainer
# docker-compose.yaml
networks:
test:
name: $NETWORK_NAME
services:
wordpress:
container_name: $WORDPRESS_CONTAINER
networks:
- test
mysql:
networks:
- test
And then run:
source .env && \
docker run -it \
--volumes-from="${WORDPRESS_CONTAINER}" \
--network="${NETWORK_NAME}" \
wordpress:cli-php7.4 \
\
/bin/bash -c "wp core update"
Success: WordPress is up to date.
To use name in networks you have to use docker-compose >= 3.4
Also, keep in mind:
Values in the shell take precedence over those specified in the .env file. If you set TAG to a different value in your shell, the substitution in image uses that instead
- See https://docs.docker.com/v17.12/compose/environment-variables/#set-environment-variables-with-docker-compose-run
Or use labels :)
@madmath03
It's as you mentioned before: the cli image can be used to manage a wp installation in another container.
This is not a viable solution and the community has told you this in multiple different ways. The wp-cli is the only SANE way to manage wordpress in a Docker environment, period.
Well, that's not my use case, I usually only have one WordPress at the time, but this is the use case for the point you mentioned.
Your use case is irrelevant.
And just replace the my_wordpress_with_cli with the name of the WP instance you want to manage.
Also not effective. Not everyone has docker-compose installed, or even uses Docker with OCI containers to begin with. This is a hack, and not a good one at that.
People are repeatedly telling you that the "other container solution" is not effective, doesn't fit the general use case of wordpress in a standalone container, and that wp-cli is not optional or arbitrary. Furthermore the excuses for why it's not included are absolutely nonsensical - if you're that concerned about the size of the container, make a "minimal" tag that doesn't include it, which is actually the idiom that many containers use in the first place.
@madmath03
Yet another reason why your second container hack isn't viable, straight from the documentation itself:
NOTE: Since March 2021, WordPress images use a customized wp-config.php that pulls the values directly from the environment variables defined above (see wp-config-docker.php in docker-library/wordpress#572 and docker-library/wordpress#577). As a result of reading environment variables directly, the cli container also needs the same set of environment variables to properly evaluate wp-config.php.