Open mvasin opened 6 years ago
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:
$ 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 | abc@example.com | 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:
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.
Are there news on this? It would really be a good choice to do it!
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).
@tianon Yeah, turned out to be a different issue. Thanks.
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-cli
in 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:
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:
/srv/wordpress_a/html:/var/www/html
/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-cli
in 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.yaml
file 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
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.
Please keep the discussion respectful.
The solution is to migrate to this: https://hub.docker.com/r/bitnami/wordpress
could not we just post here a dockerfile, which is FROM wordpress and adds a CLI installation to the image, then using that?
There is also problem we did not mentioned here before when running cli from other container.
In the old days for the cli it was enough to know the path for the wp installation folder, so multiple wp installations could be handled by simply using the default path or the --path switch of the cli. So we may think that using docker volumes creatively and allowing the necessary network connectivity we can still use one cli container for multiple wp docker containers.
However there is a trap, which makes this thing more painfully what it seems:
The newer wp docker images do not write the db info and credentials to wp-config.php, instead just write environment variable references to the wp-config.php. This means, that cli can not get that information by simply reading the pointed wp folders wp-config.php. If the cli is running in other container, it is impossible for it to get the values those env variables. The only way is, to set the same env variables redundantly in the cli container too. So we must manage multiple sets of environment variables and spin up the cli image every time with different set of the environment variables, because pointing to a wp installation folder is not enough anymore
WHY in 2024 isn't wp-cli included in the latest official wordpress docker image, is beyond comprehension.
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 hackingwp-config.php
withsed
andawk
is not pretty and error-prone compared to a bunch ofWP-CLI
commands likeWP-CLI
doesn't take too much space, and it's become essential. I propose to:WP-CLI
in all official WordPress images,WP-CLI
image,docker-entrypoint.sh
usingWP-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.