perl

Estimated reading time: 5 minutes

Perl is a high-level, general-purpose, interpreted, dynamic programming language.

GitHub repo: https://github.com/Perl/docker-perl

Library reference

This content is imported from the official Docker Library docs, and is provided by the original uploader. You can view the Docker Hub page for this image at https://hub.docker.com/images/perl

Supported tags and respective Dockerfile links

Quick reference

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.

wikipedia.org/wiki/Perl

logo

How to use this image

Create a Dockerfile in your Perl app project

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

Then, build and run the Docker image:

$ 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:

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

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 perl:carton image that makes use of the ONBUILD instruction in its Dockerfile, like this:

FROM perl:5.26

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

ONBUILD COPY cpanfile* /usr/src/myapp
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 perl:carton, which may be enough to build a stand-alone image.

Having a single 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 consider 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 perl images come in many flavors, each designed for a specific use case.

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.

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.

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 perl. Unless you are working in an environment where only the 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.

Rate this page:

 
1
 
0