CODEWITHSUNDEEP
dockerdocker-image
Btc Sources
Btc Sources

Reputation: 2061

Who to know if an official docker image is X based

I want to deploy a PHP container using the official image.

After that, I need to install imagick, so I need to install libmagickwand-dev as well using apt-get first.

AFAIK, PHP image can be based on another image, and I would need it to be e.g. Ubuntu based to be able to use apt-get.

If my host has apt-get, I know it would be available, but if I run this image on Docker for MacOS I may not have it.

How can I know if and official image is based on another I need, like this case?

I would like to thank any other comment in relation with what I've exposed, in order to make it clear to me or point out a mistake.

My dockerfile looks like:

# Backend Image - https://hub.docker.com/_/php/
FROM php:7.2-apache

# Imagick
RUN apt-get update && apt-get install -y libmagickwand-dev
RUN pecl install imagick-3.4.3 \
    && docker-php-ext-enable imagick

Upvotes: 0

Views: 67

Answers (1)

erik258
erik258

Reputation: 16304

It's a good start. Let me go through your concerns one by one and then I'll offer some advice.

AFAIK, PHP image can be based on another image, and I would need it to be e.g. Ubuntu based to be able to use apt-get.

Official PHP images are built from a variety of base distributions (https://hub.docker.com/_/php/ lists them). From there I can see that 7.2-apache is probably based on debian stretch - a great choice that will provide apt. You can see how those images are built from their Dockerfiles, which are also linked in that section to github.

If my host has apt-get, I know it would be available, but if I run this image on Docker for MacOS I may not have it.

Just to be clear, the big benefit of docker is that it doesn't matter what operating system the host is running, as long as it has docker. The components available in the image are defined only by the image on which it was based and the dockerfile that built it - in other words, if you base your dockerfile on some distribution - like debian-stretch - that includes apt, then you'll have that version and everything that comes with it, anywhere you build the image or run it. OSX, Windows, Debian, Ubuntu, CoreOS, Centos - doesn't matter. That's a big reason docker is huge - handling dependencies that tie codebases to operating systems is actually quite a challenge and docker makes it go away completely.

Actually, OSX doesn't have the required kernel support for native docker, and can't run linux ELF executables locally anyway, so Docker for Mac uses osx-native virtualization to create a nearly invisible linux instance and the docker executable on the osx end takes care of proxying to the linux layer. But this happens transparently to the user.

How can I know if and official image is based on another I need, like this case?

By looking at the docker file linked to in the dockerhub library page. In your case, that's https://github.com/docker-library/php/blob/master/7.2/stretch/apache/Dockerfile which shows its based on stretch-slim/ . Debian stretch-slim is a wonderful fit for docker because its lightweight and doesn't include a bunch of stuff irrelevant for docker containers.

So, what you're doing looks good and you're getting started pretty well.

I did want to mention one thing that you might want to consider. The way apt works, it downloads a lot of package metadata locally when you apt-get update . Unless you remove it in the same RUN command that creates it, those index files will be in the layer created by that RUN command; even if you remove them in a subsequent layer, the space they take up will still be part of the image.

So when you do this: 

RUN apt-get update && apt-get install -y libmagickwand-dev
RUN pecl install imagick-3.4.3 \
    && docker-php-ext-enable imagick

You end up with an image that's bigger than it needs to be. That's why the canonical invocation of apt for docker usually looks more like it does in the upstream image you're using:

RUN apt-get update && apt-get install -y \
        $PHPIZE_DEPS \
        ca-certificates \
        curl \
        xz-utils \
    --no-install-recommends && rm -r /var/lib/apt/lists/*

the && rm -r /var/lib/apt/lists/* removes the package metadata once its no longer needed *in the same RUN command that created it * so at runtime it's not shipped with the image. That's why you have to apt-get update again. Surely you're already aware you'd have to do that anyway for an up-to-date package repository index. So in short, adding the && rm ... at the end of your apt line above, would be good practice, and will work with what you have now.

Upvotes: 1

Related Questions