Skip to content
GitLab Next
  • Menu
Projects Groups Snippets
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • GitLab GitLab
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 43,837
    • Issues 43,837
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
    • Requirements
  • Merge requests 1,403
    • Merge requests 1,403
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages & Registries
    • Packages & Registries
    • Package Registry
    • Container Registry
    • Infrastructure Registry
  • Monitor
    • Monitor
    • Metrics
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Code review
    • Insights
    • Issue
    • Repository
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • GitLab.org
  • GitLabGitLab
  • Issues
  • #29253
Closed
Open
Created Jun 05, 2019 by Grzegorz Bizon@grzesiek💡Maintainer

Use OpenFaaS as GitLab Serverless runtimes

Description

This is an issue about the next iteration of GitLab Serverless Runtimes. Previous iteration ➡ https://gitlab.com/gitlab-org/gitlab-ce/issues/58305.

Problem

At this moment we are reusing an existing Node runtime from Project Riff and have our own Ruby runtime that we support.

We would like to add more runtimes, and as per https://gitlab.com/gitlab-org/gitlab-ce/issues/58305#note_157384486 OpenFaaS runtimes (from openfaas-incubator project) could be viable candidates to use with GitLab serverless.

Our constraints / requirements:

Most important one:

  1. Runtimes should be decoupled. One should be able to use OpenFaaS Runtimes, GitLab Runtimes or write their own easily.

Then:

  1. We build runtimes in the CI environment, using Kaniko. We can't depend on Docker Engine
  2. We want to decouple runtimes in a way that they are as much platform-agnostic as they can be
  3. We build runtimes using gitlabktl and we want to continue doing so
  4. We push resulting images to GitLab Container Registry and want to continue doing so
  5. We do not want to rely on STDIN/STDOUT communication between a function and a HTTP server
  6. We want to make it possible to easily install native libraries dependencies ➡ gitlab-ce#62520
  7. Runtimes provide a "FaaS" interface allowing the user to only write a single function (or method) and the runtime takes care of converting it to the compatible Docker image
  8. Support for custom runtimes for when users cannot find a compatible one for them
  9. ... more TBD

Nice to have:

  1. Large set of maintained runtimes for various languages
  2. The interface for creating your own runtime should be very easy for someone to implement when they want a custom runtime
  3. Runtime logic should probably be written in Bash as this is more universal than a runtime that is written in a different language
  4. Runtimes should be well unit tested
Edited Sep 12, 2019 by Daniel Gruesso
Assignee
Assign to
Time tracking