Skip to content

One container scheduler configuration for all four use cases

Heroku did a great job with this, letting application developers care about nothing else than a git push.

We're clearly moving towards containerization but we need a layer above that to make it simpler (don't have to think about it) and reusable accross the software development lifecycle.

Right now you have four uses cases where you want to run an app:

  1. IDE: with .koding.yml
  2. CI: with .gitlab-ci.yml
  3. Deploy: with https://about.gitlab.com/2016/03/22/gitlab-8-6-released/
  4. Review apps: https://gitlab.com/gitlab-org/gitlab-ce/issues/20255

We want one configuration that you can use for all four use cases. It should be based on a container scheduler configuration. With that you can do all four use cases in the cloud and locally with local container schedulers such as Localkube and Minimesos.

To run an app you need the following if you use Kubentes via Redspread:

  1. Dockerfile
  2. *.ctr - optional container file, there can be any number
  3. pod.yaml - pod file, there can be only one per directory
  4. rc.yaml - replication controller file, there can be only one per directory
  5. /.k2e - holds arbitrary Kubernetes objects, such as services and secrets

Organizations bundling stacks without embracing container schedulers:

  1. Heroku: buildpacks https://elements.heroku.com/buildpacks
  2. Koding: stacks http://www.koding.com/docs/creating-an-aws-stack and http://www.koding.com/docs/database-vm-schema-setup
  3. Travis: 4 environments https://docs.travis-ci.com/user/ci-environment/
  4. Circle: 1 environment https://circleci.com/docs/environment

If you want to do deployment you have to make assumptions about the container scheduler. Even more so now that people move to microservices. The options are:

If you need a configuration anyway for deployment why not reuse it for the browser IDE and CI? We could leverage localkube for that.

We would want to:

  1. Store container scheduler credentials in GitLab
  2. Make it easy to create the files for the container scheduler configuration (like the buttons we have for adding a readme or .gitlab-ci.yml file)
  3. Allow to create IDE environments on container schedulers too instead of only AWS
  4. Make it simple to autoscale GitLab Runners on the container scheduler
  5. Include a container scheduler deploy plugin by default

We can start with Kubernetes but we're also fine starting on Mesosphere or any of the other container schedulers we want to support.

/cc @dzaporozhets @JobV @ayufan