It can be tricky to share binaries between containers like this. Volumes probably aren't the mechanism you're looking for.
If you look at the Docker Hub page for the php
image you can see that php:7.4-apache
is an alias for (currently) php:7.4.15-apache-buster
, where "Buster" is the name of a Debian release. You can then search on https://packages.debian.org/ to discover that Debian has a prepackaged wkhtmltopdf package. You can install this using a custom Dockerfile:
FROM php:7.4-apache
RUN apt-get update
&& DEBIAN_FRONTEND=noninteractive
apt-get install --assume-yes --no-install-recommends
wkhtmltopdf
# COPY ...
# Base image provides EXPOSE, CMD
Then your docker-compose.yml
file needs to build this image:
version: '3.8'
services:
web:
build: .
# no image:, volumes:, or command: override
Just in terms of the mechanics of sharing binaries like this, you can run into trouble where a binary needs a shared library that's not present in the target container. The apt-get install
mechanism handles this for you. There are also potential troubles if a container has a different shared-library ecosystem (especially Alpine-based containers), or using host binaries from a different operating system.
The Compose file you show mixes several concepts in a way that doesn't really work. A named volume is always a directory, so trying to mount that over the /bin/wkhtmltopdf
file in the second container causes the error you see. There's a dependency issue for which container starts up first and gets to create the volume. A container only runs a single command, and if you have both entrypoint:
and command:
then the command gets passed as extra arguments to the entrypoint (and if the entrypoint is an sh -c ...
invocation, effectively ignored).
If you really wanted to try this approach, you should make web: {depends_on: [wkhtmltopdf]}
to force the dependency order. The second container should mount the volume somewhere else, it probably shouldn't have an entrypoint:
, and it should do something like command: cp -a /bin/wkhtmltopdf /export
. (It will exit immediately once this cp
finishes, but that shouldn't matter.) The first container can then mount the volume on, say, /usr/local/bin
, and not specially set command:
or entrypoint:
. There will still be a minor race condition (you're not guaranteed the cp
command will complete before Apache starts) but it probably wouldn't be a practical problem.
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…