ExpediaGroup / Flyte
Projects that are alternatives of or similar to Flyte
Table of contents
Overview
Flyte binds together the tools you use into easily defined, automated workflows. It is a request-based, decoupled automation engine which allows you to define flows to enable integrated behaviour across these disparate tools.
Flyte has chat-ops enabling integrations for Slack, as well as some other out-of-the-box integrations. These integrations, or packs can be added to and extended easily by using Flyte's RESTful API.
Some of the applications already in use include chat-ops based inventory management, host/container administration and orchestration, and deployment of applications into Kubernetes.
Automation is done using flows which essentially take form of "if this happens in system A, then do this in system B". For example you could create a flow that triggers sending an email to a team's email if their app's deployment has failed, or create a deployment pipeline triggered from an instant chat message.
How it works
The Flyte-API acts as the orchestrator and is backed by a (MongoDB) database server in which Flows, Packs references and Datastore entries are stored. Before continuing with the high level architecture diagram, lets introduce some of the key concepts of Flyte:
-
Flows are a list of steps that define a particular use case - for example triggering the deploy of an app when a user types the message "deploy foo-app 1.2.0" in a particular chat room. Each step in a flow consists of:
- An Event that triggers it (e.g. an instant message being observed in a particular chat room).
- A Criteria that must be satisfied for the step to run (e.g: message matches certain regex).
- An Action to be executed if the criteria matches.
You can find more info about flows here.
-
Packs are self-contained apps that are responsible for executing flow actions and sending events to the flyte-api. For instance, flyte-slack-pack consumes events/messages from a slack channel but also sends messages via Slack.
-
DataStores are basically configuration properties shared between flows. For instance, list of environments, urls, etc.
How are flows executed
- Packs consume events from external services - for example, a Slack message from a specific channel.
- Packs transform these external events to flyte events before pushing them to Flyte-API.
- Flyte-API receives an event and triggers any flow which is listening to that event.
- This flow execution will create an action and flyte-api will store it in its database.
- Packs will poll for new actions to Flyte-API.
- Flyte-API will assign an action to a pack.
- Pack will execute the action and return the result as a new event, which will trigger the next step in our current flow or a different one.
Flyte-API / Flyte Pack interaction: The Flyte Pack queries Flyte-API which returns a response.
Getting Started
Check out the Quick Start documentation to get started on building new flows or custom packs.
Running
The are a number of ways to run flyte and its mongo db.
Note that the default mongo host and port for flyte is localhost:27017 (this value can be changed using the
FLYTE_MGO_HOST env variable).
The port number can be overridden, see Configuration
Once running, flyte will be available on http://localhost:8080 (TLS disabled), or http://localhost:8443 (TLS enabled).
From Source
Pre-req: must have modules installed and Go 1.11 or higher.
Build & run:
make run
Command starts mongo docker container and flyte go executable in the background. Output is written to flyte.out file.
or manually...
go test ./... -tags="integration acceptance" //remove tags if only want to run unit tests
docker run -d -p 27017:27017 --name mongo mongo:latest
go build && ./flyte
Using Docker
make docker-run
or manually...
docker run -d -p 27017:27017 --name mongo mongo:latest
docker build -t flyte:latest .
docker run -p 8080:8080 -e FLYTE_MGO_HOST=mongo -d --name flyte --link mongo:mongo flyte:latest
Running the tests
Acceptance Tests
For acceptance tests:
go test ./... -tags=acceptance
These will start a disposable docker mongo container and flyte on randomly available TCP ports. If mongo can't be started (e.g docker is not available in the path), tests will be skipped and won't fail the build.
Acceptance tests will not run when building flyte in docker.
The tests can be run in an IDE by running the test suite in "acceptance_test.go".
Integration Tests
For integration tests:
go test ./... -tags=integration
For the mongo db integration tests, which are slower running:
go test ./... -tags=db
To run both:
go test ./... -tags="integration db"
Please note that both unit and integration tests will run using the above command/s.
Postman
There are a number of postman files in postman folder that can be used to test running flyte
More resources
Contributing
Please read CONTRIBUTING.md for details on our code of conduct, and the process for submitting pull requests to us.
License
This project is licensed under the Apache License License - see the LICENSE file for details