Page MenuHomePhabricator

Provide production jessie image with node 4.2; use this for service-runner build command
Closed, InvalidPublic

Description

The service-runner build functionality uses a jessie docker image to compile dependencies for deploy repositories. Now that production is switching to a Node 4.2 backport we should switch to a jessie image that is using the precise packages we are using in production.

The simplest approach should be to layer on top of the regular jessie image, by

  • configuring the Wikimedia repository, and
  • running apt-get update & upgrade, followed by an installation of nodejs.

Alternatively, we could build a complete image from scratch using the wikimedia mirror of jessie. Given the large overlap with production I'm not sure that it would be worth the effort. @MoritzMuehlenhoff, @fgiunchedi, @faidon, @mobrovac, @Eevans, @Pchelolo: Any thoughts on this?

Event Timeline

GWicke raised the priority of this task from to High.
GWicke updated the task description. (Show Details)
GWicke updated the task description. (Show Details)Jan 11 2016, 4:40 PM
GWicke set Security to None.
Pchelolo added a comment.EditedJan 11 2016, 5:24 PM

@GWicke We already support alternative node versions in docker build script. See T114399 (resolved by this PR), so the easiest way to resolve this task is to add node version config to RESTBase config and other services configs as we switch them to 4.2

We already support alternative node versions in docker build script.

+1. While the service-runner's docker script uses the version provided by nvm, I'd say this leaves enough flexibility so that service-runner isn't tied to our apt repo.

My concern with using the nvm version is that it opens up some chance of binary dependency disagreements between the build environment & what we run in production. Building binary dependencies against the exact node & other library versions as used in production avoids this risk.

Given the relatively small effort involved, I think creating a WMF Jessie image is worth it. It should also be useful for CI and mediawiki-containers. We could make that the default target used by service-runner, with upstream jessie and ubuntu still supported if desired.

My concern with using the nvm version is that it opens up some chance of binary dependency disagreements between the build environment & what we run in production. Building binary dependencies against the exact node & other library versions as used in production avoids this risk.

4.2.0 is marked as stable in nvm so I doubt that this will present a real issue in practice.

4.2.0 is marked as stable in nvm so I doubt that this will present a real issue in practice.

I agree that it's unlikely, but given the limited effort involved & the high stakes I think it's worth ruling out any incompatibilities.

GWicke lowered the priority of this task from High to Medium.Oct 12 2016, 10:30 PM
GWicke edited projects, added Services (later); removed Services.
GWicke added a subscriber: yuvipanda.

@yuvipanda, IIRC you mentioned that you were working on a WMF Jessie image. Do you have a pointer to this?

There's a 'docker-registry.tools.wmflabs.org/wikimedia-jessie' you can pull. I think at some point @Joe might be working on having this be served from production.

(No guarantees are made about the stability of that docker image, but I'll notify you in case we change it)

Pchelolo closed this task as Invalid.Jul 31 2019, 10:11 PM

We're updating to k8s and not running node 4 anymore.