Install Packages in Alpine Docker

using apk packages that were installed in a builder image in an other image

A second FROM statement in a Dockerfile completely resets the image to the new base image. Nothing is carried over. The only way to get something from an earlier stage is the COPY --from=... statement.

If you need some packages in your final image, you should install them in the final image. Copying them from an earlier stage will be a difficult, since you'll need to know what files the package installed.

In your case, you should install the packages in the alpine image. Then they'll also be available in the final image you make, that you base on the alpine image.

Docker - Installing packages on Alpine distro that aren't available in the Alpine repository

Sometimes the packages have different names between distros. In your case the package that provides those header files is alsa-lib-dev.

You can check by yourself by comparing the package contents on their site.

https://pkgs.alpinelinux.org/contents?file=&path=&name=alsa-lib-dev&branch=v3.9&repo=main&arch=x86_64

https://packages.ubuntu.com/bionic/amd64/libasound2-dev/filelist

Can't install Python package on Alpine Docker anymore

You are trying to use the python (alias) library instead of python3.

Try to use apk update && apk upgrade && apk add python3 instead.

Should we install package updates for Alpine base image in Docker?

Should I expect any newer package version to be available in the index for particular OS version 3.14?

Yes.

apk -U upgrade will indeed update the package index and upgrade to the latest packages. The reason that nothing is installed is most probably that the base Alpine image version used is already updated with the latest packages in Dockerhub.

As an experiment, I have tried this with a very old Alpine version, 3.7. apk -U upgrade did upgrade musl and musl-utils, by bumping them one version - from 1.1.18-r3 to 1.1.18-r4:

$ sudo docker run -it alpine:3.7
Unable to find image 'alpine:3.7' locally
3.7: Pulling from library/alpine
5d20c808ce19: Pull complete 
Digest: sha256:8421d9a84432575381bfabd248f1eb56f3aa21d9d7cd2511583c68c9b7511d10
Status: Downloaded newer image for alpine:3.7
/ # apk -U upgrade
fetch http://dl-cdn.alpinelinux.org/alpine/v3.7/main/x86_64/APKINDEX.tar.gz
fetch http://dl-cdn.alpinelinux.org/alpine/v3.7/community/x86_64/APKINDEX.tar.gz
(1/2) Upgrading musl (1.1.18-r3 -> 1.1.18-r4)
(2/2) Upgrading musl-utils (1.1.18-r3 -> 1.1.18-r4)
Executing busybox-1.27.2-r11.trigger
OK: 4 MiB in 13 packages

The fact that only two packages were upgraded and by a single revision implies that the 3.7 base image is already updated with the latest packages for this distribution (besides these two). This makes sense, because when there are security fixes to packages, you'd want them to be broadcast to all affected images as fast as possible. If the fix is for a severe issue, it is likely it will be back-ported to all affected Alpine versions.

When there are security updates to packages, they are done "in place", and the old package version is replaced with the new one, so when you update the package index of your image, you'd get the new package version. The old package version is then no longer available for download.

All in all, using apk -U upgrade to keep your images up to date sounds like a solid advice.

Can't install package on alpine though I can see it in the ui

You should use the official PHP 7 Alpine image on DockerHub.

Then, per the image documentation, use the docker-php-ext-install command in your Dockerfile:

FROM php:7-fpm-alpine
RUN apk update \
  && apk add libmcrypt-dev \
  && docker-php-ext-install mcrypt mysqli pdo_mysql \
  && rm /var/cache/apk/*

This may initially look a little strange, but it works and is the officially supported Docker approach.

We provide the helper scripts docker-php-ext-configure,
docker-php-ext-install, and docker-php-ext-enable to more easily
install PHP extensions.

DockerHub - PHP

apk python packages not installing in Alpine Docker Image

Alpine installed python pacakges using this path /usr/lib/python3.7/site-packages, just run the command inside the container and you will see the package is installed. All you need to add this path to the python search path.

RUN apk add --no-cache cython3
ENV PYTHONPATH /usr/lib/python3.7/site-packages

PYTHONPATH

Augment the default search path for module files. The format is the
same as the shell’s PATH: one or more directory pathnames separated by
os.pathsep (e.g. colons on Unix or semicolons on Windows).
Non-existent directories are silently ignored.

In addition to normal directories, individual PYTHONPATH entries may
refer to zipfiles containing pure Python modules (in either source or
compiled form). Extension modules cannot be imported from zipfiles.

The default search path is installation dependent, but generally
begins with prefix/lib/pythonversion (see PYTHONHOME above). It is
always appended to PYTHONPATH.

An additional directory will be inserted in the search path in front
of PYTHONPATH as described above under Interface options. The search
path can be manipulated from within a Python program as the variable
sys.path.

python envvar PYTHONPATH

update:

To work with pip installation you need to use -m.

When called with -m module-name, the given module is located on the
Python module path and executed as a script.

python3-cmdline

you can test

RUN apk add --no-cache cython3
ENV PYTHONPATH /usr/lib/python3.7/site-packages
RUN python -m pip install requests
RUN python -m pip list
#import test
RUN python -c "import requests"

---

Related Topics