i386/perl Docker 镜像 - 轩辕镜像

Note: this is the "per-architecture" repository for the i386 builds of the perl official image -- for more information, see "Architectures other than amd64?" in the official images documentation and "An image's source changed in Git, now what?" in the official images FAQ.

Quick reference

• Maintained by:
  the Perl Community

• Where to get help:
  the Docker Community Slack, Server Fault, Unix & Linux, or Stack Overflow

Supported tags and respective Dockerfile links

• 5.42.0-bookworm, 5.42-bookworm, 5-bookworm, bookworm, stable-bookworm

• 5.42.0-bullseye, 5.42-bullseye, 5-bullseye, bullseye, stable-bullseye

• 5.42.0-slim-bookworm, 5.42-slim-bookworm, 5-slim-bookworm, slim-bookworm, stable-slim-bookworm

• 5.42.0-slim-bullseye, 5.42-slim-bullseye, 5-slim-bullseye, slim-bullseye, stable-slim-bullseye

• 5.42.0-threaded-bookworm, 5.42-threaded-bookworm, 5-threaded-bookworm, threaded-bookworm, stable-threaded-bookworm

• 5.42.0-threaded-bullseye, 5.42-threaded-bullseye, 5-threaded-bullseye, threaded-bullseye, stable-threaded-bullseye

• 5.42.0-slim-threaded-bookworm, 5.42-slim-threaded-bookworm, 5-slim-threaded-bookworm, slim-threaded-bookworm, stable-slim-threaded-bookworm

• 5.42.0-slim-threaded-bullseye, 5.42-slim-threaded-bullseye, 5-slim-threaded-bullseye, slim-threaded-bullseye, stable-slim-threaded-bullseye

• 5.40.3-bookworm, 5.40-bookworm

• 5.40.3-bullseye, 5.40-bullseye

• 5.40.3-slim-bookworm, 5.40-slim-bookworm

• 5.40.3-slim-bullseye, 5.40-slim-bullseye

• 5.40.3-threaded-bookworm, 5.40-threaded-bookworm

• 5.40.3-threaded-bullseye, 5.40-threaded-bullseye

• 5.40.3-slim-threaded-bookworm, 5.40-slim-threaded-bookworm

• 5.40.3-slim-threaded-bullseye, 5.40-slim-threaded-bullseye

• 5.38.5-bookworm, 5.38-bookworm

• 5.38.5-bullseye, 5.38-bullseye

• 5.38.5-slim-bookworm, 5.38-slim-bookworm

• 5.38.5-slim-bullseye, 5.38-slim-bullseye

• 5.38.5-threaded-bookworm, 5.38-threaded-bookworm

• 5.38.5-threaded-bullseye, 5.38-threaded-bullseye

• 5.38.5-slim-threaded-bookworm, 5.38-slim-threaded-bookworm

• 5.38.5-slim-threaded-bullseye, 5.38-slim-threaded-bullseye

• 5.43.6-bookworm, 5.43-bookworm, devel-bookworm

• 5.43.6-bullseye, 5.43-bullseye, devel-bullseye

• 5.43.6-slim-bookworm, 5.43-slim-bookworm, devel-slim-bookworm

• 5.43.6-slim-bullseye, 5.43-slim-bullseye, devel-slim-bullseye

• 5.43.6-threaded-bookworm, 5.43-threaded-bookworm, devel-threaded-bookworm

• 5.43.6-threaded-bullseye, 5.43-threaded-bullseye, devel-threaded-bullseye

• 5.43.6-slim-threaded-bookworm, 5.43-slim-threaded-bookworm, devel-slim-threaded-bookworm

• 5.43.6-slim-threaded-bullseye, 5.43-slim-threaded-bullseye, devel-slim-threaded-bullseye

Quick reference (cont.)

• Where to file issues:
  [***]

• Supported architectures: (more info)
  amd64, arm32v5, arm32v7, arm64v8, i386, mips64le, ppc64le, riscv64, s390x

• Published image artifact details:
  repo-info repo's repos/perl/ directory (history)
  (image metadata, transfer size, etc)

• Image updates:
  official-images repo's library/perl label
  official-images repo's library/perl file (history)

• Source of this description:
  docs repo's perl/ directory (history)

What is Perl?

Perl is a high-level, general-purpose, interpreted, dynamic programming language. The Perl language borrows features from other programming languages, including C, shell scripting (sh), AWK, and sed.

***.org/wiki/Perl

!logo

How to use this image

Create a Dockerfile in your Perl app project

dockerfile
FROM i386/perl:5.34
COPY . /usr/src/myapp
WORKDIR /usr/src/myapp
CMD [ "perl", "./your-daemon-or-script.pl" ]

Then, build and run the Docker image:

console
$ docker build -t my-perl-app .
$ docker run -it --rm --name my-running-app my-perl-app

Run a single Perl script

For many simple, single file projects, you may find it inconvenient to write a complete Dockerfile. In such cases, you can run a Perl script by using the Perl Docker image directly:

console
$ docker run -it --rm --name my-running-script -v "$PWD":/usr/src/myapp -w /usr/src/myapp i386/perl:5.34 perl your-daemon-or-script.pl

Coexisting with Debian's /usr/bin/perl

The perl binary built for this image is installed in /usr/local/bin/perl, along with other standard tools in the Perl distribution such as prove and perldoc, as well as cpanm for installing CPAN modules. Containers running this image will also have their PATH enviroment set like /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin to ensure that this perl binary will be found first in normal usage.

As this official image of Docker is built using the buildpack-deps image (or debian:slim for :slim variants,) this image also contains a /usr/bin/perl as supplied by the Debian project. This is needed for the underlying dpkg/apt) package management tools to work correctly, as docker-perl cannot be used here due to different configuration (such as @INC and installation paths, as well as other differences like whether -Dusethreads is included or not.)

See also Perl/docker-perl#26 for an extended discussion.

Signal handling behavior notice

As Perl will run as PID 1 by default in containers (unless an ENTRYPOINT is set,) special care needs to be ***ed when expecting to send signals (particularly SIGINT or SIGTERM) to it. For example, running

console
$ docker run -it --name sleeping_beauty --rm i386/perl:5.34 perl -E 'sleep 300'

and doing on another terminal,

console
$ docker exec sleeping_beauty kill 1

will not stop the perl running on the sleeping_beauty container (it will keep running until the sleep 300 finishes.) To do so, one must set a signal handler like this:

console
$ docker run -it --name quick_nap --rm i386/perl:5.34 perl -E '$SIG{TERM} = sub { $sig++; say "recv TERM" }; sleep 300; say "waking up" if $sig'

so doing docker exec quick_nap kill 1 (or the simpler docker stop quick_nap) will immediately stop the container, and print recv TERM in the other terminal. Note that the signal handler does not stop the perl process itself unless it calls a die or exit; in this case, perl will continue and print waking up after it receives the signal.

If your Perl program is expected to handle signals and fork child processes, it is encouraged to use an init-like program for ENTRYPOINT, such as dumb-init or tini (the latter is available since Docker 1.13 via the docker run --init flag.)

See also Signals in perlipc as well as Perl/docker-perl#44.

COPY and WORKDIR behavior in Debian Bookworm based images (Perl >= 5.38)

As our Perl images are based on the standard buildpack-deps and debian images, these inherit the new merged-usr root filesystem layout introduced in Debian 12 (Bookworm) which may affect certain build contexts that COPY their own bin, sbin, or lib directories into a WORKDIR /. Users are encouraged to set WORKDIR explicitly to a path other than / as much as possible, such as the /usr/src/app shown here in the examples, though as of current release our images now default to WORKDIR /usr/src/app.

See also Perl/docker-perl#140 for further information.

Example: Creating a reusable Carton image for Perl projects

Suppose you have a project that uses Carton to manage Perl dependencies. You can create a i386/perl:carton image that makes use of the ONBUILD instruction in its Dockerfile, like this:

dockerfile
FROM i386/perl:5.34

RUN cpanm Carton \
    && mkdir -p /usr/src/app
WORKDIR /usr/src/app

ONBUILD COPY cpanfile* /usr/src/app
ONBUILD RUN carton install

ONBUILD COPY . /usr/src/app

Then, in your Carton project, you can now reduce your project's Dockerfile into a single line of FROM i386/perl:carton, which may be enough to build a stand-alone image.

Having a single i386/perl:carton base image is useful especially if you have multiple Carton-based projects in development, to avoid "boilerplate" coding of installing Carton and/or copying the project source files into the derived image. Keep in mind, though, about certain things to *** when using the Perl image in this way:

• This kind of base image will hide the useful bits (such as theCOPY/RUN above) in the image, separating it from more specific Dockerfiles using the base image. This might lead to confusion when creating further derived images, so be aware of how ONBUILD triggers work and plan appropriately.
• There is the cost of maintaining an extra base image build, so if you're working on a single Carton project and/or plan to publish it, then it may be more preferable to derive directly from a versioned perl image instead.

Image Variants

The i386/perl images come in many flavors, each designed for a specific use case.

i386/perl:<version>

This is the defacto image. If you are unsure about what your needs are, you probably want to use this one. It is designed to be used both as a throw away container (mount your source code and start the container to start your app), as well as the base to build other images off of.

Some of these tags may have names like bookworm or bullseye in them. These are the suite code names for releases of Debian and indicate which release the image is based on. If your image needs to install any additional packages beyond what comes with the image, you'll likely want to specify one of these explicitly to minimize breakage when there are new releases of Debian.

This tag is based off of buildpack-deps. buildpack-deps is designed for the average user of Docker who has many images on their system. It, by design, has a large number of extremely common Debian packages. This reduces the number of packages that images that derive from it need to install, thus reducing the overall size of all images on your system.

i386/perl:<version>-slim

This image does not contain the common packages contained in the default tag and only contains the minimal packages needed to run i386/perl. Unless you are working in an environment where only the i386/perl image will be deployed and you have space constraints, we highly recommend using the default image of this repository.

License

View license information for the software contained in this image.

As with all Docker images, these likely also contain other software which may be under other licenses (such as Bash, etc from the base distribution, along with any direct or indirect dependencies of the primary software being contained).

Some additional license information which was able to be auto-detected might be found in the repo-info repository's perl/ directory.

As for any pre-built image usage, it is the image user's responsibility to ensure that any use of this image complies with any relevant licenses for all software contained within.