The GitOps Kubernetes operator
Branch: master
Clone or download
squaremo Merge pull request #1751 from weaveworks/build/clarify-azure-key-prov…
…enance

Document source of Azure SSH host key
Latest commit d1b097e Feb 19, 2019
Permalink
Type Name Latest commit message Commit time
Failed to load latest commit information.
.circleci Add makefile target for verifying generated code Nov 5, 2018
.github Add tag filter for chart-* to GitGHub workflow Jan 23, 2019
api Actually return the SyncError for controllers Nov 22, 2018
bin Bump to kubeyaml 0.5.1 to fix (F)HR updating Nov 13, 2018
chart Update chart change log for v0.6.3 Feb 14, 2019
checkpoint making compiling work on raspberry pi's Oct 26, 2018
cluster Filter locked and ignore resources during release Feb 19, 2019
cmd Merge pull request #1680 from captncraig/patch-1 Feb 13, 2019
daemon Take ignore policy into account while fetching Feb 19, 2019
deploy-helm Merge pull request #1712 from yinzara/feature/skip-dep-up Feb 8, 2019
deploy Bump flux image in reference manifest Feb 13, 2019
docker Document source of Azure SSH host key Feb 19, 2019
errors Downgrade non-specific errors to application-level Feb 15, 2018
event Fix typo: should be ReleaseContainersSpec instead of ReleaseImageSpec Nov 14, 2018
git Allow $HOME when invoking git Jan 9, 2019
guid Make new subscriptions kick old subscriptions Dec 14, 2016
http Add events for container release Nov 6, 2018
image Include parsed string in error for ParseRef() Sep 28, 2018
integrations Use release name from HelmRelease in errors Feb 15, 2019
internal_docs Update doc on release process Nov 14, 2018
job Break dependencies among git, job, event packages Apr 3, 2018
metrics Standardize http metrics, to flux_request_duration Feb 2, 2017
policy Remove spurious ServicesWithPolicies Aug 20, 2018
registry Merge pull request #1694 from alanjcastonguay/aks-credentials-for-acr Feb 12, 2019
release Fix tests Nov 6, 2018
remote Merge pull request #1472 from weaveworks/promo-notifs-2 Nov 8, 2018
resource Verify releases with a model comparison May 24, 2018
site Inform about side-effects of repositories.yaml Feb 15, 2019
ssh Generate keys in a separate tmpfs volume Mar 14, 2018
sync Move sync error tracking to Cluster Oct 26, 2018
test Keep current-context Oct 31, 2017
update Filter locked and ignore resources during release Feb 19, 2019
.gitignore Basic integration tests Oct 31, 2017
CHANGELOG-helmop.md Add changelog entry for Helm operator v0.6.0 Feb 6, 2019
CHANGELOG.md Refine changelog entry for Flux v1.10.1 Feb 13, 2019
CODE_OF_CONDUCT.md Move code of conduct into its own file. Sep 21, 2018
CONTRIBUTING.md Remote last traces of `linting` Jan 17, 2019
DCO docs: steal CONTRIBUTING.md and DCO docs from scope, modify slightly Aug 28, 2018
Gopkg.lock Make port forward label selector configurable Feb 11, 2019
Gopkg.toml Bump go-k8s-portforward to version 1.0.2 Jan 14, 2019
LICENSE Initial commit Jul 7, 2016
MAINTAINERS Add Slack handles to MAINTAINERS Oct 5, 2018
Makefile Add PATH quoting in `make test` Jan 15, 2019
README.md add tutorial which discusses automation, annotations, locks Jan 18, 2019
flux.go Allow colons in the name component of resource IDs Aug 9, 2018
resourceid_test.go Allow colons in the name component of resource IDs Aug 9, 2018

README.md

Flux

We believe in GitOps:

  • You declaratively describe the entire desired state of your system in git. This includes the apps, config, dashboards, monitoring and everything else.
  • What can be described can be automated. Use YAMLs to enforce conformance of the system. You don't need to run kubectl, all changes go through git. Use diff tools to detect divergence between observed and desired state and get notifications.
  • You push code not containers. Everything is controlled through pull requests. There is no learning curve for new devs, they just use your standard git PR process. The history in git allows you to recover from any snapshot as you have a sequence of transactions. It is much more transparent to make operational changes by pull request, e.g. fix a production issue via a pull request instead of making changes to the running system.

Flux is a tool that automatically ensures that the state of a cluster matches the config in git. It uses an operator in the cluster to trigger deployments inside Kubernetes, which means you don't need a separate CD tool. It monitors all relevant image repositories, detects new images, triggers deployments and updates the desired running configuration based on that (and a configurable policy).

The benefits are: you don't need to grant your CI access to the cluster, every change is atomic and transactional, git has your audit log. Each transaction either fails or succeeds cleanly. You're entirely code centric and don't need new infrastructure.

Deployment Pipeline

CircleCI GoDoc

What Flux does

Flux is most useful when used as a deployment tool at the end of a Continuous Delivery pipeline. Flux will make sure that your new container images and config changes are propagated to the cluster.

Features

Its major features are:

Relation to Weave Cloud

Weave Cloud is a SaaS product by Weaveworks that includes Flux, as well as:

  • a UI and alerts for deployments: nicely integrated overview, all Flux operations just a click away.
  • full observability and insights into your cluster: Instantly start using monitoring dashboards for your cluster, hosted 13 months of history, use a realtime map of your cluster to debug and analyse its state.

If you want to learn more about Weave Cloud, you can see it in action on its homepage.

Get started with Flux

Get started by browsing through the documentation below:

Integrations

As Flux is Open Source, integrations are very straight-forward. Here are a few popular ones you might want to check out:

Community & Developer information

We welcome all kinds of contributions to Flux, be it code, issues you found, documentation, external tools, help and support or anything else really.

Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting a Flux project maintainer, or Alexis Richardson <alexis@weave.works>. Please refer to our code of conduct as well.

To familiarise yourself with the project and how things work, you might be interested in the following:

Getting Help

If you have any questions about Flux and continuous delivery:

Your feedback is always welcome!