Wikimedia Cloud Services team/EnhancementProposals/Decision record T330102 What buildpacks to allow and include for toolforge build service beta

From Wikitech

Origin task: phab:T330102

Date of the decision: 2022-11-22

People in the decision meeting:

Meeting notes (Google Doc)

Decision taken

Option 1 with some modifications, as in allowing all the official buildpacks, but only supporting the Python one.

Rationale

  • It's the fastest for us, and does not block us from taking any other decision in the future (ex. allowing external buildpacks, continue growing our own, ....)

Problem

For the toolforge build service Beta ({T267374}) we have to decide what buildpacks do we allow (that means allow and test).

Some definitions first:

    • Note:** Build and build__er__ images are different
  • Application image -> This one is the product, it's built by the builder image, by running the buildpacks on top of the build image, and copying the result over to the run image.
  • Builder image -> This one defines what run and build image to use, and which buildpacks to include (ties the run+build to buildpacks, it's the one that builds the final application image)
  • run + build image -> This ones defines the image the code will be build with and run in (ex. decides which OS will be running), this is sometimes called stack
  • buildpacks -> Scripts that will build and prepare the app image (run at build time, define the tooling to build, how to run it, are tied to the build and run image through the OS)

There's three things to decide here, and they are bound to each other (so not easy to decide separately):

  • The buildpacks to use
  • The build+run image to use
  • The builder image to use

There's some upstream built builders, run and build images, and buildpacks from different organizations:

  • Paketo
  • Heroku
  • Google
  • Us (wikimedia cloud services)

Some details:

Current house-made buildpacks:

  • Languages:
    • Python
  • Build tools:
    • pip + uwsgi
  • Http Servers:
    • uwsgi
  • Base OS: Debian
  • Community buildpacks: Our own community! :)
  • Allows to install packages: limited (not tested), through our own script

Upstream **officially supported** buildpacks:

  • Packeto:
    • Languages:
      • Go, Java, Node.js, PHP, Python, Ruby, Static files, .Net
    • Build tools:
    • Http servers:
      • Nginx
      • Httpd
      • Your own (through procfile, ex. gunicorn, uwsgi, node, ...)
    • Base OS: Ubuntu
    • Community buildpacks: They all are, paketo is an Open Source project
    • Allows to install packages: no, we have to build our own buildpack (might be able to cross-use the heroku one)


  • Google Cloud Buildpacks
    • Languages:
      • Go, Java, Node.js, PHP, Python, Ruby, .Net
    • Http Servers:
      • Your own (through procfile)
    • Base OS: Ubuntu
    • Community buildpacks: None (you have to find your own)
    • Allows to install packages: no, we have to build our own buildpack (might be able to cross-use the heroku one)

Constraints and risks

  • A first subset of them have to be decided before the beta, with the possibility of expanding them after.
  • We have to be able to restrict to some extent the buildpacks allowed so it's not easy to break the terms of usage of toolforge (only open-source software).
  • We have to be able to support a set of common language build flows, with best practices and how-to's
  • We will probably have to maintain the selected choice for a long time
  • We might want to change direction after/during the Beta/Alpha/RC stages
  • For the multistack buildpacks, we might have to maintain our own builder image


Options

Option 1

Use our own builder with a subset of the selected upstream buildpacks, starting with Heroku Python one, decide after which ones to continue supporting.

Pros:

  • Upstream maintained buildpacks
  • Upstream maintained run and build image
  • Shared best practices with upstream platforms
  • Users might be familiar with other providers, ease to move between them when needed
  • Wide support of languages, build tools, and web servers
  • We can limit which buildpacks to put in the builder
  • Possibility to add selected non-official buildpacks

Cons:

  • Not Debian
  • We have to maintain our own builder image


Option 2

Use upstream builder with included official buildpacks.

Pros:

  • Upstream maintained buildpacks
  • Upstream maintained run and build image
  • Shared best practices with upstream platforms
  • Users might be familiar with other providers, ease to move between them when needed
  • Wide support of languages, build tools, and web servers

Cons:

  • Not debian
  • No control on which buildpacks are included or not
  • No possibility to add selected non-official buildpacks


Option 3

Support our builder + buildpacks, and upstream builders too

Pros:

  • Debian based buildpacks if wanted
  • Minimal difference with current code setup (no need to change anything)
  • Upstream maintained buildpacks and stacks
  • Shared best practices with upstream platforms
  • Users might be familiar with other providers, ease to move between them when needed (for the ones that did not use our buildpacks)
  • Wide support of languages, build tools, and web servers

Cons:

  • Maintain our own buildpacks for each of the langs we want to support
  • Maintain our own base run and build images (debian)
  • Maintain our own builder image
  • No control on which buildpacks are included or not (due to upstream builders)
  • No possibility to add selected non-official buildpacks (due to non-compatibility of our build+run image with upstream buildpacks)

Option 4

Support our builder + buildpacks, and limited upstream buildpacks

Pros:

  • Debian based buildpacks if wanted
  • Minimal difference with current code setup (no need to change anything)
  • Upstream maintained buildpacks and stacks
  • Shared best practices with upstream platforms
  • Users might be familiar with other providers, ease to move between them when needed (for the ones that did not use our buildpacks)
  • Wide support of languages, build tools, and web servers
  • Control on which buildpacks are included or not
  • Possibility to add selected non-official buildpacks

Cons:

  • Maintain our own buildpacks for each of the langs we want to support
  • Maintain our own base run and build images (debian)
  • Maintain our own builder image
Retrieved from "https://wikitech.wikimedia.org/w/index.php?title=Wikimedia_Cloud_Services_team/EnhancementProposals/Decision_record_T330102_What_buildpacks_to_allow_and_include_for_toolforge_build_service_beta&oldid=2136055"