2

Intro:

I am trying to run a few WP-CLI commands for maintenance as a part of my release process on my production sites. I can execute the following commands against the docker-compose file below successfully.

  • docker-compose run wp-cli_collinmbarrett-com core update
  • docker-compose run wp-cli_collinmbarrett-com plugin update --all
  • docker-compose run wp-cli_collinmbarrett-com theme update --all
  • docker-compose run wp-cli_collinmbarrett-com db optimize

I have a plugin (WP-Sweep) installed on the site that adds its own WP-CLI command. When I try to run this command, it fails.

docker-compose run wp-cli_collinmbarrett-com sweep --all
/usr/local/bin/docker-entrypoint.sh: exec: line 15: sweep: not found

In a non-dockerized setup, I have verified that the WP-Sweep command for WP-CLI works successfully.

Question:

How can I run plugin-installed WP-CLI commands when running in a containerized environment with Docker Compose? Do I need to somehow make the WP-CLI container aware of the installed plugins other than having a shared volume?

My docker-compose.yml:

version: "3.7"

services:
  wp_collinmbarrett-com:
    image: wordpress:fpm-alpine
    restart: always
    networks:
      - reverse-proxy
      - collinmbarrett-com
    depends_on:
      - mariadb_collinmbarrett-com
    volumes:
      - collinmbarrett-com_files:/var/www/html

  mariadb_collinmbarrett-com:
    image: mariadb:latest
    restart: always
    networks:
      - collinmbarrett-com
    volumes:
      - collinmbarrett-com_data:/var/lib/mysql

  wp-cli_collinmbarrett-com:
    image: wordpress:cli
    networks:
      - collinmbarrett-com
    volumes:
      - collinmbarrett-com_files:/var/www/html

networks:
  reverse-proxy:
    external:
      name: wp-host_reverse-proxy
  collinmbarrett-com:

volumes:
  collinmbarrett-com_files:
  collinmbarrett-com_data:

Full config on GitHub.

Collin Barrett
  • 2,441
  • 5
  • 32
  • 53
  • DId you ever figure a workaround for this? Re the installing of the sweep plugin, i suspect you need to download the plugin zip to the container. The wp-cli assumes the plugin is available via the wp-cli package list which i guess sweep isn't. – emeraldjava Dec 22 '20 at 15:40
  • 1
    I didn't. Maybe so. It's not really a need I have any more, but would love to hear of a working solution regardless. – Collin Barrett Dec 22 '20 at 15:44

1 Answers1

0

Not answering directly to your command needs (I didn't tried yet), but I wanted to share with you all the configurations I'm using in hope it helps you.

My docker-compose.yml has:

services:
...
  # Mysql container
  db:
...
  # Wordpress container
  wp:  
...
  wpcli:
    image: wordpress:cli
    user: "33:33"
    volumes:
      # necessary to write to the filesys
      - ./php-config/phar.ini:/usr/local/etc/php/conf.d/phar.ini
      - wp_app:/var/www/html
      - /tmp/wp-temp:/tmp/wp-temp
    environment:
      HOME: /tmp/wp-temp
      WORDPRESS_DB_HOST: db
      WORDPRESS_DB_USER: $WORDPRESS_DB_USER
      WORDPRESS_DB_PASSWORD: $WORDPRESS_DB_PASSWORD
      WORDPRESS_DB_NAME: $WORDPRESS_DB_NAME
    depends_on:
      - db
      - wp
volumes:
  wp_app: {}
...

Please note that as mentioned on Running as an arbitrary user section in https://hub.docker.com/_/wordpress:

When running WP-CLI via the cli variants of this image, it is important to note that they're based on Alpine, and have a default USER of Alpine's www-data, whose UID is 82 (compared to the Debian-based WordPress variants whose default effective UID is 33), so when running wordpress:cli against an existing Debian-based WordPress install, something like --user 33:33 is likely going to be necessary (possibly also something like -e HOME=/tmp depending on the wp command invoked and whether it tries to use ~/.wp-cli)

You will need to define WP-CLI user as www-data with user id and group id = 33. This is why I defined user: "33:33". Also, the command might need to download temporary content, so I defined a HOME environment setting. Please also note that HOME mapped in your Host should also be assigned with user 33:33 ownership ids, otherwise WP CLI can't write to the filesys.

Also, PHP.ini in the WPCLI image has the setting phar.readonly as On, so you need to override it. I've add a specific ./php-config/phar.ini file that has that override:

phar.readonly = Off

To execute a plugin installation I do, on my docker-compose.yml folder, the following command:

docker-compose run --rm wpcli plugin install wp-mail-smtp  --force --allow-root

Please note that --force --allow-root are optional.