GitOps for k8s
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
Daniel Holbach b5c374ed7c add empty changelog entries for the upcoming release 2 years ago
.circleci Remove the helm prefix from helm-op version 2 years ago
.github Add first attempt at a pull request template. 2 years ago
api Split off SortedImageInfos to enforce constraint 2 years ago
apis/helm.integrations.flux.weave.works Annotate resources caused by a FluxHelmRelease 2 years ago
bin Build and upload Windows binary of fluxctl 2 years ago
chart Bump Helm chart version - includes Flux v1.7.0 and Flux Helm Operator v0.2.1 2 years ago
checkpoint Factor checkpoint so it can be used by helm-op too 2 years ago
cluster Include initContainers in images to fetch 2 years ago
cmd Put some trace logging into the cache refresh code 2 years ago
daemon Allow multiple config paths within a git repo 2 years ago
deploy Reduce memcache logging by default 2 years ago
deploy-helm Bump helm-op version in deploy-helm 2 years ago
docker Remove the helm prefix from helm-op version Fix #1320 2 years ago
errors Downgrade non-specific errors to application-level 2 years ago
event Omit changes that aren't, in auto-releases 2 years ago
git Reduce releaser test verbiage 2 years ago
guid Make new subscriptions kick old subscriptions 3 years ago
http Update UpStream to register as V10 2 years ago
image Change image cache expiry to adaptive scheme 2 years ago
integrations Purge release if install fails If a chart is broken, Tiller will reserve the name and mark the release as failed. If at a later time the chart is fixed, helm-op can't install it anymore because the release name is in use. Purging the release after each failed install allows helm-op to keep retrying the installation. 2 years ago
internal_docs Document the Helm chart release process 2 years ago
job Break dependencies among git, job, event packages 2 years ago
metrics Standardize http metrics, to flux_request_duration 3 years ago
policy Remove spurious ServicesWithPolicies 2 years ago
registry Avoid timeouts by testing with a stable image repo 2 years ago
release Add a test for releasing initContainers 2 years ago
remote Remove spurious ServicesWithPolicies 2 years ago
resource Verify releases with a model comparison 2 years ago
site fix wrong link to using.md from helm-get-started.md 2 years ago
ssh Generate keys in a separate tmpfs volume 2 years ago
sync Allow multiple config paths within a git repo 2 years ago
test Keep current-context 2 years ago
update Exclude locked workloads for container type release 2 years ago
.gitignore Basic integration tests 2 years ago
CHANGELOG-helmop.md add empty changelog entries for the upcoming release 2 years ago
CHANGELOG.md add empty changelog entries for the upcoming release 2 years ago
CODE_OF_CONDUCT.md Move code of conduct into its own file. 2 years ago
CONTRIBUTING.md add note about where to find GH issues as first-time contributor 2 years ago
DCO docs: steal CONTRIBUTING.md and DCO docs from scope, modify slightly 2 years ago
Gopkg.lock Use dep v0.4.1 to generate Gopkg.lock 2 years ago
Gopkg.toml Update go-k8s-portforward to latest version to provide kubectl auth plugins for GKE, AWS, to support managed clusters. 2 years ago
LICENSE Initial commit 4 years ago
Makefile Build and upload Windows binary of fluxctl 2 years ago
README.md Move code of conduct into its own file. 2 years ago
flux.go Allow colons in the name component of resource IDs 2 years ago
lint Basic circle.yml, respecting Glide etc. 4 years ago
resourceid_test.go Allow colons in the name component of resource IDs 2 years ago

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 an 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:

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>.

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!