maiorano84
commented
6 years ago I was able to bring it down even more (81.3MB) with the following:
FROM alpine:latest
ENV PAGER=more
RUN apk add --update curl ruby ruby-libs ruby-rdoc ruby-irb ruby-bigdecimal php7 php7-ctype php7-json php7-phar php7-mysqli mysql-client gzip rsync openssh
RUN curl https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar > /usr/local/bin/wp \
&& chmod +x /usr/local/bin/wp \
&& gem install wordmove
WORKDIR /var/www/html/
RUN adduser -S wordmove
USER wordmove
ENTRYPOINT ["wordmove"]This removes the dependency on the ruby:alpine image, but it doesn't appear as stable as the other build I had earlier. This one may require more testing.
@pioneerskies Per an earlier conversation we had, I tested out the latest version of Wordmove through Docker. Everything appears to function as expected.
I'm not sure how far along you got with an Alpine image, but here is something I whipped up, and I hope it helps for an alternative approach that you might consider:
This was built with the following command:
docker build -t wordmove .All examples listed below will refer to this image as "wordmove" for the purposes of this demo.
While this is much lighter (119MB as opposed to 606MB), this image functions a little differently than the original. Rather than opening up a bash shell and running indefinitely, it's instead designed as a throwaway container that is responsible simply for standard push/pull/init/(etc.) commands.
A full example in Windows Powershell looks like the following:
docker run -v ~/.ssh:/home/wordmove/.ssh -v ${pwd}:/var/www/html --rm --network=host wordmove pull -e dev --allNote the two volume mounts for both .ssh access, as well as the current working directory as the project root. Specifying --network=host is not required, but can be useful if the local mysql is to be accessed over localhost.
A stripped-down example would look like the following if network and .ssh specifications are unnecessary:
docker run -v ${pwd}:/var/www/html --rm wordmove pull -e dev --allI'm not sure if this is the approach you would like to take, as I'm sure there are some benefits to running the process as a long-lived container. The above examples are all a bit verbose as well, which I'm not sure is something you're keen on.
In that case, supporting a long-running container with the above configuration would look something like this:
docker run -v ~/.ssh:/home/wordmove/.ssh -v ${pwd}:/var/www/html --network=host --entrypoint=/bin/sh -dit --name=deploy wordmoveRunning commands against the container would look like this:
docker exec deploy wordmove pull -e dev --allLet me know your thoughts!