New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

install composer in php image #344

Closed
mathroc opened this Issue Dec 5, 2016 · 20 comments

Comments

Projects
None yet
@mathroc
Copy link
Contributor

mathroc commented Dec 5, 2016

#177 was closed when the composer image was merged but I still think composer should be included inside the official php image (or at least installed more easily)

I think that because I still have a 2 main issues when using https://hub.docker.com/_/composer/ :

  • I might not have the same version of php than the composer image have (php version constraints can be specified in composer.json)
  • I might not have the same php extensions installed (composer can check for installed extension but it's not useful if it's not checked in the image where the code is gonna run)

does docker-library/official-images#2290 means composer won't be added into _/php ?

@arubacao

This comment has been minimized.

Copy link

arubacao commented Dec 5, 2016

I don't think that they will add composer to the official image. composer shouldn't be added to a production container after all.

Its a two liner to add composer to your development docker image:

RUN apt-get update && \
    apt-get install -y --no-install-recommends git zip

RUN curl --silent --show-error https://getcomposer.org/installer | php
@SmoshySmosh

This comment has been minimized.

Copy link

SmoshySmosh commented Dec 5, 2016

I don't think this is a good idea. As @arubacao said, you should not add composer to a production container. Feel free to correct me if I'm wrong on this, but these are meant to be a boilerplate (or starting point) for a bare bones container that you can feel safe running in production.

My advice is to run composer install locally before building the container. This is what I do before I build my containers, that way I can use the same containers for development that I use for deployments.

@mathroc

This comment has been minimized.

Copy link
Contributor

mathroc commented Dec 6, 2016

composer shouldn't be added to a production container after all.

correct, I'm not in favor of installing it by default, however I'm not comfortable with this "2 liner". I have something like that in a lot of project and that's a lot of copy and paste. and it's usually more than 2 lines if you care about oauth token, cache & which version of composer you want to install

My advice is to run composer install locally before building the container. This is what I do before I build my containers, that way I can use the same containers for development that I use for deployments.

I'd like to have a Dockerfile like that to build production image:

FROM php:xxx-alpine

WORKDIR /scripts/

ADD composer.json /scripts/
ADD composer.lock /scripts/

RUN apk add --no-cache --virtual .composer-runtime-deps git && \
    docker-php-composer-install --version=1.2.3 && \
    composer install --no-dev --optimize-autoloader && \
    rm $(which composer) && \
    apk del .composer-runtime-deps

ADD src/ /scripts/src/

note: I don't care that much about shipping composer inside the production image. besides shipping 1.6M I don't see the harm: if an attacker could execute composer what would prevent him to install composer if it's not here already ?
and what when you are using other images like node, are you manually removing npm before shipping ? apt-get/apk ? pecl ?

@arubacao

This comment has been minimized.

Copy link

arubacao commented Dec 6, 2016

It's not an security issue.
By the time of shipping your container everything should already be in place. Therefore you'd never run an composer, npm or whatever command.

You can do all things mentioned (oauth token, cache & which version) either through the composer installer, composer itself and in extra files. If its 2 or 3 lines in the end doesn't matter. It's always a lean and quick setup.

But if that's still to much, why not build your own base image? As I mentioned earlier - and independent from my opinion on the composer usage - I don't think that they will add composer to the official image.
Cheers

@mathroc

This comment has been minimized.

Copy link
Contributor

mathroc commented Dec 6, 2016

By the time of shipping your container everything should already be in place. Therefore you'd never run an composer, npm or whatever command.

of course, I'm running composer inside the Dockerfile, and the image is built on Gitlab CI. I could remove it at the end of the build, it just does not seems necessary so I wrote that because I was not sure if by "composer shouldn't be added to a production container after all." you meant it was unnecessary or an issue to ship it into production image

You can do all things mentioned (oauth token, cache & which version) either through the composer installer, composer itself and in extra files. If its 2 or 3 lines in the end doesn't matter. It's always a lean and quick setup.

well maybe I'm not doing it right but it's closer to 10 lines and it become an issue when it almost the same across a lot of projects

But if that's still to much, why not build your own base image? As I mentioned earlier - and independent from my opinion on the composer usage - I don't think that they will add composer to the official image.

well, seing #177 I thought it could be useful to others too. If it's officially off I'll have to give that a go but it's gonna be a PITA to automatically keep that up to date for each version of the php images (and not to forget to use custom image instead of the default ones)

@arubacao

This comment has been minimized.

Copy link

arubacao commented Dec 6, 2016

If it's officially off I'll have to give that a go but it's gonna be a PITA to automatically keep that up to date for each version of the php images (and not to forget to use custom image instead of the default ones)

I don't know what PITA means, but this cannot be a problem. I feel like there is at least one extension or configuration that needs to be added for every project, the vanilla image therefore isn't sufficient for most projects. Appending composer to your custom image or not doesn't make any difference.

of course, I'm running composer inside the Dockerfile, and the image is built on Gitlab CI.

Gitlab is absolutely brilliant!
I'd like to suggest you a different approach. You don't need to run composer inside the Dockerfile.
Instead install composer within the testing (& build) stage of your pipeline.
Here is an official documentation of how you could do it: https://docs.gitlab.com/ce/ci/examples/php.html

The flow would look something like:

  1. Testing stage:
  • Pull vanilla php image or your custom base php image from a private registry
  • execute a script (s. ci/docker_install.sh in doc) with installs composer and e.g. xdebug.
  • install composer dependencies including dev
  • run tests
  1. Build stage:
  • Pull vanilla php image or your custom base php image from a private registry
  • execute a script and install only composer
  • install production dependencies with composer
  • build an artifact
  1. Build/Release production image:
  • grab artifact from previous build
  • build & tag production image
  • push to registry
  1. Deploy
  • Deploy your new version to production/development/staging

The gitlab docs are pretty extensive and provide tons of information and inspiration.

Cheers

@mallorydxw

This comment has been minimized.

Copy link

mallorydxw commented Dec 6, 2016

Most languages available on Docker Registry come with some means of managing dependencies, whether it's part of the upstream distribution or a third-party tool:

  • The node image contains npm
  • The ruby and jruby images contain gem (an official part of Ruby) and bundle (a third-party tool)
  • The golang image includes the go get tool
  • The python image contains pip (a third-party tool)

It would be nice if the php image could follow suit.

@tianon

This comment has been minimized.

Copy link
Member

tianon commented Dec 10, 2016

@tomdxw while all good comparisons, the tools noted are either included directly in the upstream distribution (npm, gem, go get, pip), are officially supported/recommended by upstream (npm, gem, pip), or are practically 100% ubiquitous in the community (bundle)

The difference here, and the reason I'm still -1 on including composer by default in the PHP image itself is that it doesn't fit any of those descriptions (yet). It's gaining a lot of popularity, but it's not currently included or officially recommended by PHP upstream and it's not really ubiquitous in the community yet.

The reason the composer image was created is that @alcohol (from composer upstream) was willing to create and maintain it, and it being a separate dedicated image is something that's easy to do right now without waiting for an official recommendation from PHP upstream (possibly deprecating it in the future if the situation changes and composer becomes an official PHP-upstream-recommended tool).

So to summarize, the composer image does not mean that composer will never be included in the PHP image directly, but it does allow for an image that includes composer by default to exist in the official images in the meantime. Hopefully this helps clarify the situation a little better. 😄

@mathroc

This comment has been minimized.

Copy link
Contributor

mathroc commented Dec 12, 2016

The difference here, and the reason I'm still -1 on including composer by default in the PHP image itself is that it doesn't fit any of those descriptions (yet). It's gaining a lot of popularity, but it's not currently included or officially recommended by PHP upstream and it's not really ubiquitous in the community yet.

For what I can see it is the de-facto standard. I don't think twice about using composer when starting a new project and I believe this is the most developers. of course there is projects not using composer. at least existing projects that didn't use composer and have not yet (or chosen not to — eg: wordpress) move to composer and probably a few new projects too.
discussion about deprecating pear in favor of composer on internal : http://externals.io/thread/276 <= it's not an official recommendation from PHP upstream (and maybe never will) but it shows that it's a candidate
and on phptherightway.com

So to summarize, the composer image does not mean that composer will never be included in the PHP image directly, but it does allow for an image that includes composer by default to exist in the official images in the meantime. Hopefully this helps clarify the situation a little better. 😄

@tianon yes it does :)

from what I understand those are the costs of including composer by default:

  • added maintenance / support : I'm happy to help here
  • size / deploying it in production : not sure if someone think this is really an issue / can be avoided
  • unofficial / not ubiquitous

@tianon am I correct that the third is your main concern ? you seem to think that composer is at least a very popular dependency manager for PHP. so I don't understand how including composer (or provide better support for it) can be an issue. do you mind sharing your opinion on this ?

also, how do you draw the line between ubiquitous in the community or not ?

thank you

@mathroc

This comment has been minimized.

Copy link
Contributor

mathroc commented Dec 20, 2016

@mathroc This is as bad idea as including nano to the container. If you need nano — install one.

is it a bad idea to include nano because not everybody use it, or because there's already vi ?

It will cost me 10 x 1,7M = 17M additional disk space (in worst case).

nope, docker does not duplicate images for each running container, so even with 10 running container you would only have 1.7M more. and if you do care, my first PR was about adding a script to install composer (à la docker-php-ext-install) not adding composer itself because not everybody want to have it installed and maybe not the same version of composer either

As @tomdxw pointed out, many languages from DockerHub come with a package manager, BUT composer is not the same for PHP as npm is for node: composer is a relatively new tool in PHP world, and many projects written in PHP are not using it.

Of course, nobody thinks every projects is using composer. I believe that a lot of them does and that this "lot" is enough for it to be useful to include composer in the official image. obviously this belief is based on my experiences and what I can see from open source projects I'm interested in, your mileage may vary.
Do you mean that composer is not used enough yet ? not mature enough ? I looked for statistics about composer usage but couldn't find anything compelling so far

@mathroc and you can always fork this repo (or create docker image based on this one) and maintain your own one with a composer in it. It might be helpful for many PHP projects.

I could but that would not be really easy to automatically keep those images up to date with each tag from library/php. If you have example of such setup I'd love to learn about it

Not every business keeps up with trends

and would including composer be a problem for those businesses ?

@alcohol

This comment has been minimized.

Copy link

alcohol commented Dec 21, 2016

Regarding composer/packagist statistics, there are some very rudimentary ones available at https://packagist.org/statistics. Also, Jordi posts some stats about php version stuff every year based on data from packagist access logs: https://seld.be/notes/php-versions-stats-2016-2-edition

@kuborgh-mspindelhirn

This comment has been minimized.

Copy link

kuborgh-mspindelhirn commented May 22, 2017

@tjomamokrenko Can you explain the context for the stats you pulled in? I dont see how the fact that there is still a world with a lot of php 5.4 is relevant for a container that does no longer support that version anyway.
Official php docker images can be used from php 5.5 upward.

I think the major question is: Do we want the php images to be used directly, or are we all fine with duplicating Dockerfiles with "project specific" stuff from one project to the next one?

Looking at the number of extensions I need for some projects vs. others I think having a Dockerfile with project specific stuff cannot be avoided completly. Thats why I am fine with keeping this image as small and minimal as possible.

tl&dr -1 from me too

@jeesus

This comment has been minimized.

Copy link

jeesus commented Dec 12, 2017

@arubacao Nice workflow you have there. What about cases where composer install takes over 10 minutes? That's a 2x10 minutes for testing & building. A rather long time when you need to run tests several times a day?!

@arubacao

This comment has been minimized.

Copy link

arubacao commented Dec 12, 2017

@jeesus Thx :)
I do it a little different nowadays. I build a composer cache in my PHP base image for the corresponding project. A 10 mins composer install only takes 20 secs with cache :)

@tianon

This comment has been minimized.

Copy link
Member

tianon commented Dec 22, 2017

Closing given that Composer is still not included in PHP's upstream distribution nor their official recommendations (and doesn't seem likely to be in the near future), and given that the Composer project now officially maintains a set of images (https://hub.docker.com/_/composer/) which stem from this one and add Composer. 👍 ❤️

If those images are not sufficient for your use case, I'd recommend reading their source in order to copy or adjust them for your needs! Additionally, it's likely worth trying to make the case to PHP upstream that PECL ought to be complimented (or even replaced) by Composer in the official distribution. 👍

@Mohammadtrabelsi

This comment has been minimized.

Copy link

Mohammadtrabelsi commented Feb 10, 2018

RUN curl -sS https://getcomposer.org/installer | php -- --install-dir=/usr/local/bin --filename=composer
RUN composer --version

And you will see the latest composer version:

Do not run Composer as root/super user! See https://getcomposer.org/root for details
Composer version 1.6.3 2018-01-31 16:28:17

@alcohol

This comment has been minimized.

Copy link

alcohol commented Feb 12, 2018

The above comment from @Mohammadtrabelsi is not the recommended way to install Composer programmatically, see instead: https://getcomposer.org/doc/faqs/how-to-install-composer-programmatically.md

Or, if your Docker version is recent enough (>=17.05), use a multistage build and copy Composer from one of our official images (example uses latest but you can target a specific version too):

COPY --from=composer:latest /usr/bin/composer /usr/bin/composer

9034725985 added a commit to kusl/symfonydemo that referenced this issue Aug 10, 2018

@rogervila

This comment has been minimized.

Copy link

rogervila commented Aug 27, 2018

Any news on this question?

Please, reopen the bug.

@yosifkit

This comment has been minimized.

Copy link
Member

yosifkit commented Aug 27, 2018

@rogervila, Please see reason for closing above: #344 (comment)

@mabez

This comment has been minimized.

Copy link

mabez commented Oct 20, 2018

RUN php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');"
RUN php -r "if (hash_file('SHA384', 'composer-setup.php') === '93b54496392c062774670ac18b134c3b3a95e5a5e5c8f1a9f115f203b75bf9a129d5daa8ba6a13e2cc8a1da0806388a8') { echo 'Installer verified'; } else { echo 'Installer corrupt'; unlink('composer-setup.php'); } echo PHP_EOL;"
RUN php composer-setup.php --install-dir=/bin --filename=composer
RUN php -r "unlink('composer-setup.php');"

As like the doc

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment