Giter VIP home page Giter VIP logo

orkestra's Introduction

Orkestra

Latest version Gitter

Orkestra is an Open Source Continuous Integration / Continuous Deployment server as a library running on Kubernetes.
It leverages Kubernetes concepts such as Jobs or Secrets, and configuration as code in Scala to take the most of compile time type safety and compatibility with Scala or Java libraries.

Key features:

  • Configured completely via code which can be version controlled
  • Fully scalable
  • Highly Available
  • Extendable via any Scala/Java libraries

Quick start

Requirements

Installation

project/plugins.sbt:

addSbtPlugin("tech.orkestra" % "sbt-orkestra" % "<latest version>")

build.sbt:

lazy val orkestra = orkestraProject("orkestra", file("orkestra"))
  .settings(
    libraryDependencies ++= Seq(
      "tech.orkestra" %%% "orkestra-github" % orkestraVersion, // Optional Github plugin
      "tech.orkestra" %%% "orkestra-cron" % orkestraVersion, // Optional Cron plugin
      "tech.orkestra" %% "orkestra-lock" % orkestraVersion // Optional Lock plugin
    )
  )

Simple example

Given the above installation, here is a minimal project with one job:

orkestra/src/main/scala/orkestra.scala:

import tech.orkestra._
import tech.orkestra.Dsl._
import tech.orkestra.board._
import tech.orkestra.job._
import tech.orkestra.model._

// We extend OrkestraServer to create the web server
object Orkestra extends OrkestraServer {
  // Configuring the UI
  lazy val board = deployFrontendJobBoard
  // Configuring the jobs
  lazy val jobs = Set(deployFrontendJob)
  
  // Creating the job and configuring UI related settings
  lazy val deployFrontendJobBoard = JobBoard[() => Unit](JobId("deployFrontend"), "Deploy Frontend")()
  // Creating the job from the above definition (this will be compiled to JVM)
  lazy val deployFrontendJob = Job(deployFrontendJobBoard) { implicit workDir => () =>
    println("Deploying Frontend")
  }
}

This example is described in Jobs & Boards.

See example projects

Deployment on Kubernetes with Minikube

We provide some basic Kubernetes Deployment in kubernetes-dev that you can use to deploy on a dev environment.
Assuming that you are in one of the example projects (or in your own project), here is how to deploy on Kubernetes with Minikube:

minikube start --memory 4096              # Start Minikube
eval `minikube docker-env`                # Make docker use the docker engine of Minikube
sbt orkestraJVM/Docker/publishLocal       # Publish the docker artifact
kubectl apply -f ../kubernetes-dev        # Apply the deployment to Kubernetes
kubectl proxy                             # Proxy the Kubernetes api

Visit Orkestra on http://127.0.0.1:8001/api/v1/namespaces/orkestra/services/orkestra:http/proxy.
You can troubleshoot any deployment issue with minikube dashboard.

More on how to configure the deployment in Config.

Documentation

Find all the documentation on https://orkestra.tech:

Talks and articles:

Origins of Orkestra

DriveTribe

Orkestra has been created at DriveTribe by its Scala backend team that had to do DevOps. Obsessed by functional programming they decided to apply the same paradigm to their DevOps.

Related projects

Contributing

Contributions to Orkestra are more than welcomed! See CONTRIBUTING.md for all the information and getting help.

orkestra's People

Contributors

dbuschman7 avatar hamishdickson avatar joan38 avatar juliasklyar avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

orkestra's Issues

API facade

Motivation

Currently the API is a bit scattered. Users need to import types from many packages and get exposed to the internal organisation of Orkestra.
That means if we move a type of package it would be a breaking change.

Proposed change

Create a package object that would contain type aliases to the main types needed.
Acting as a facade for the API users would just need, for simple usecases, to:

import tech.orkestra._

Thanks

Add pagination on the run history

Motivation

The pagination is already part of the backend API but nothing is done on the frontend side.
It is currently requesting 50 runs.

Proposed change

Load more as we scroll the UI

Setup a CI

Motivation

Although Orkestra is a CI/CD tool we currently have no CI/CD for the project itself, which is hilarious right?

Proposed change

Setup a CI to check PRs

Refactor the Secrets utility to be extendable

Motivation

The current Secret management utility object suffers from multiple flaws:

  1. It's not thread safe since https://github.com/Orkestra-Tech/orkestra/blob/master/orkestra-core/src/main/scala/tech/orkestra/utils/Secrets.scala#L4 is mutable without any atomicity.
  2. Is working with env var only and we might want to use something like HashiCorp Vault instead of the Kubernetes Env var Secrets.

Proposed change

Implementing a trait LogObfuscator as replacement of the Secrets object that would be responsible to obfuscate log and would be expected as input to the creation of a Job.
We would provide a default thread safe implementation for Kubernetes Env var Secrets and people would be free to implement one for any other sensible data provider that should not be logged.

This was one found on the spot, please tell me if you have a better idea.

Thanks

Add ability to limit the size of run history

Motivation

Currently the entire run history is kept in Elasticsearch.
We probably would like to bound the history in time or number of entries so that we don't have an ever growing set of data.

Proposed change

Open to proposals

Better example app

I cannot get a simple string parameter to show up in the client UI , could you upgrade the example to demonstrate the feature.

broken links

the links at the documentation section of the readme are broken

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.