Page MenuHomePhabricator

Create a Perl Docker image for use on the Toolforge Kubernetes cluster
Open, Needs TriagePublic

Description

Requested in https://lists.wikimedia.org/pipermail/cloud/2019-January/000517.html

We may be able to make a smaller base image by making sure that we install local::lib and carton.

Our Docker containers tend to implement opinionated patterns for deploying and running code. It would be good to get feedback from actual Perl webservice authors on options for this. Examples:

  • Same as grid engine default: run $HOME/public_html/*.pl files as CGI scripts
  • Run a FastCGI app from $HOME/www/perl/src
  • Run a PSGI app from $HOME/www/perl/src using uWSGI (similar to our Python2 and Python3 defaults)
  • PSGI run under Starman
  • ...

Event Timeline

bd808 created this task.Jan 22 2019, 5:24 AM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJan 22 2019, 5:24 AM
seth added a subscriber: seth.Feb 5 2019, 11:18 PM

i'd like to test somehow, which perl-modules are missing.

one answer in the mailing list was

webservice --backend=kubernetes TYPE shell will get you into a shell.

but that gave me just a message:
type must be one of golang,jdk8,nodejs,php5.6,php7.2,python,python2,ruby2,tcl

(however, i guess, i just need the debian package libhtml-template-perl for the perl module HTML::Template.)

bd808 added a comment.Feb 6 2019, 12:26 AM

type must be one of golang,jdk8,nodejs,php5.6,php7.2,python,python2,ruby2,tcl

We do not have any image at all for Perl yet, so that explains your failure with webservice --backend=kubernetes perl shell.

(however, i guess, i just need the debian package libhtml-template-perl for the perl module HTML::Template.)

Have you used any project local package manager (something that does not need root permissions) with your Perl projects in the past? I think our ideal solution would be something similar Python's venv or PHP's Composer which would allow each tool to install the 3rd party libraries it needs without us needing to place the union of all possible modules used by tools in the Perl Docker image itself. Ideally we would just be installing a core Perl runtime and the libraries/tools needed for local package management and then letting each tool maintainer install the extras their tool needs.

seth added a comment.Feb 9 2019, 9:04 AM

I've used CPAN locally at the old toolserver (ran by DaB.). Since there is labs, I just asked for some packages, and the admins installed them. For me this is an easy way.

In my opinion local package managing systems are a PITA. It's better to have centralized and centrally managed _system_ package bundles, where one can be sufficiently sure that everything works together.
All perl modules I use are packed for debian already, e.g.,
sudo apt-get install libcgi-pm-perl libdatetime-format-strptime-perl libhtml-template-perl libwww-perl
They are installed at the 'normal' labs server already.

I'm not used to work with docker images. I understand that those docker images should be small, because every tool get's its own image, right? So if it would be possible to install system packages in that container, that would be great, maybe something such as https://perlmaven.com/distributing-perl-script-using-docker?