Convert Figma logo to code with AI

fluxcd logoflux

Successor: https://github.com/fluxcd/flux2

6,897
1,080
6,897
0

Top Related Projects

17,333

Declarative Continuous Deployment for Kubernetes

4,565

Jenkins X provides automated CI+CD for Kubernetes with Preview Environments on Pull Requests using Cloud Native pipelines from Tekton

1,500

Deploy workloads from Git to large fleets of Kubernetes clusters

20,922

Pulumi - Infrastructure as Code in any programming language 🚀

Quick Overview

Flux is a GitOps-based continuous delivery tool for Kubernetes. It automates the deployment of applications by synchronizing the desired state defined in a Git repository with the actual state in a Kubernetes cluster. Flux enables declarative, version-controlled infrastructure and application management.

Pros

  • Automated synchronization between Git and Kubernetes cluster
  • Supports multi-tenancy and multi-cluster deployments
  • Integrates well with existing CI/CD pipelines
  • Provides built-in monitoring and alerting capabilities

Cons

  • Steep learning curve for teams new to GitOps principles
  • Limited support for non-Kubernetes environments
  • Can be complex to set up and configure for large-scale deployments
  • Requires careful management of Git repositories to avoid conflicts

Getting Started

To get started with Flux, follow these steps:

  1. Install the Flux CLI:
curl -s https://fluxcd.io/install.sh | sudo bash
  1. Bootstrap Flux on your cluster:
flux bootstrap github \
  --owner=<your-github-username> \
  --repository=<your-repository-name> \
  --path=clusters/my-cluster \
  --personal
  1. Create a simple Kubernetes deployment in your Git repository:
apiVersion: apps/v1
kind: Deployment
metadata:
  name: podinfo
  namespace: default
spec:
  replicas: 2
  selector:
    matchLabels:
      app: podinfo
  template:
    metadata:
      labels:
        app: podinfo
    spec:
      containers:
      - name: podinfo
        image: stefanprodan/podinfo:5.0.3
  1. Commit and push the changes to your Git repository. Flux will automatically detect the changes and apply them to your cluster.

  2. Verify the deployment:

kubectl get deployments

For more detailed instructions and advanced usage, refer to the Flux documentation.

Competitor Comparisons

17,333

Declarative Continuous Deployment for Kubernetes

Pros of Argo CD

  • User-friendly web UI for visualizing and managing deployments
  • Supports multi-tenancy and RBAC out of the box
  • Offers automated sync policies and health checks for applications

Cons of Argo CD

  • Requires more resources to run compared to Flux
  • Can be more complex to set up initially
  • Limited native support for Helm chart dependencies

Code Comparison

Argo CD Application manifest:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: myapp
spec:
  destination:
    namespace: default
    server: https://kubernetes.default.svc
  project: default
  source:
    path: kustomize-guestbook
    repoURL: https://github.com/argoproj/argocd-example-apps.git
    targetRevision: HEAD

Flux HelmRelease manifest:

apiVersion: helm.fluxcd.io/v1
kind: HelmRelease
metadata:
  name: myapp
  namespace: default
spec:
  releaseName: myapp
  chart:
    git: https://github.com/example/repo
    path: charts/myapp
    ref: master
  values:
    replicaCount: 2

Both Argo CD and Flux are popular GitOps tools for Kubernetes, with Argo CD offering a more feature-rich UI and built-in multi-tenancy support, while Flux provides a lighter-weight solution with native Helm integration. The choice between them often depends on specific project requirements and team preferences.

4,565

Jenkins X provides automated CI+CD for Kubernetes with Preview Environments on Pull Requests using Cloud Native pipelines from Tekton

Pros of jx

  • Provides a complete CI/CD solution with built-in Jenkins integration
  • Offers automated environment promotion and version control
  • Includes a CLI tool for easier management and interaction

Cons of jx

  • Steeper learning curve due to its comprehensive feature set
  • Requires more resources to run compared to Flux
  • May be overkill for simpler projects or smaller teams

Code Comparison

jx:

pipeline:
  agent:
    image: golang:1.12.7
  stages:
    - name: CI Build and push snapshot
      steps:
      - sh: make linux
      - sh: docker build -t ${DOCKER_REGISTRY}/${ORG}/${APP_NAME}:${PREVIEW_VERSION} .
      - sh: docker push ${DOCKER_REGISTRY}/${ORG}/${APP_NAME}:${PREVIEW_VERSION}

Flux:

---
apiVersion: helm.fluxcd.io/v1
kind: HelmRelease
metadata:
  name: podinfo
  namespace: default
spec:
  releaseName: podinfo
  chart:
    git: https://github.com/stefanprodan/podinfo
    ref: 3.2.0
    path: charts/podinfo

The jx example shows a pipeline definition with stages and steps, while the Flux example demonstrates a HelmRelease resource for declarative GitOps deployments.

1,500

Deploy workloads from Git to large fleets of Kubernetes clusters

Pros of Fleet

  • Supports multi-cluster management out of the box
  • Integrates seamlessly with Rancher ecosystem
  • Offers a simpler, more opinionated approach to GitOps

Cons of Fleet

  • Less mature and smaller community compared to Flux
  • Limited customization options for advanced use cases
  • Fewer integrations with external tools and services

Code Comparison

Fleet configuration example:

apiVersion: fleet.cattle.io/v1alpha1
kind: GitRepo
metadata:
  name: my-app
  namespace: fleet-default
spec:
  repo: https://github.com/example/my-app
  paths:
  - manifests

Flux configuration example:

apiVersion: source.toolkit.fluxcd.io/v1beta2
kind: GitRepository
metadata:
  name: my-app
  namespace: flux-system
spec:
  interval: 1m
  url: https://github.com/example/my-app
  ref:
    branch: main

Both Fleet and Flux use YAML configurations to define Git repositories for GitOps. Fleet's configuration is more concise, while Flux offers more granular control over sync intervals and branch selection. Fleet's approach aligns with its simpler, opinionated design, while Flux provides more flexibility for complex scenarios.

20,922

Pulumi - Infrastructure as Code in any programming language 🚀

Pros of Pulumi

  • Supports multiple programming languages (Python, TypeScript, Go, etc.) for infrastructure as code
  • Offers a more flexible and powerful approach to infrastructure management
  • Provides better integration with existing development workflows and tools

Cons of Pulumi

  • Steeper learning curve, especially for those new to programming
  • Requires more setup and configuration compared to Flux's GitOps approach
  • May introduce more complexity in infrastructure management

Code Comparison

Flux (YAML):

apiVersion: source.toolkit.fluxcd.io/v1beta1
kind: GitRepository
metadata:
  name: podinfo
  namespace: flux-system
spec:
  interval: 1m
  url: https://github.com/stefanprodan/podinfo

Pulumi (Python):

import pulumi
import pulumi_kubernetes as k8s

repo = k8s.helm.v3.Release("podinfo",
    chart="podinfo",
    repository_opts=k8s.helm.v3.RepositoryOptsArgs(
        repo="https://stefanprodan.github.io/podinfo"
    )
)

Summary

Flux focuses on GitOps and Kubernetes-native continuous delivery, while Pulumi offers a more general-purpose infrastructure as code solution. Flux is easier to adopt for teams already using Kubernetes, while Pulumi provides more flexibility and language options but with a steeper learning curve.

Convert Figma logo designs to code with AI

Visual Copilot

Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.

Try Visual Copilot

README

Flux v1

This repository contains the source code of Flux Legacy (v1).

Flux v1 has reached end of life and has been replaced by fluxcd/flux2 and its controllers entirely.

If you consider using Flux, please take a look at https://fluxcd.io/flux/get-started to get started with v2.

If you are on Flux Legacy, please follow the migration guide. If you need hands-on help migrating, you can contact one of the companies listed here.

History

Flux was initially developed by Weaveworks and made open source in 2016. Over the years the community around Flux & GitOps grew and in 2019 Weaveworks decided to donate the project to CNCF.

After joining CNCF, the Flux project has seen massive adoption by various organisations. With adoption came a wave of feature requests that required a major overhaul of Flux monolithic code base and security stance.

In April 2020, the Flux team decided to redesign Flux from the ground up using modern technologies such as Kubernetes controller runtime and Custom Resource Definitions. The decision was made to break Flux functionally into specialised components and APIs with a focus on extensibility, observability and security. These components are now called the GitOps Toolkit.

In 2021, the Flux team launched Flux v2 with many long-requested features like support for multi-tenancy, support for syncing an arbitrary number of Git repositories, better observability and a solid security stance. The new version made it possible to extend Flux capabilities beyond its original GitOps design. The community rallied around the new design, with an overwhelming number of early adopters and new contributions, Flux v2 gained new features at a very rapid pace.

In 2022, Flux v2 underwent several security audits, and its code base and APIs became stable and production ready. Having a dedicated UI for Flux was the most requested feature since we started the project. For v2, Weaveworks launched a free and open source Web UI for Flux called Weave GitOps, which made Flux and the GitOps practices more accessible.

Today Flux is an established continuous delivery solution for Kubernetes, trusted by organisations around the world. Various vendors like Amazon AWS, Microsoft Azure, VMware, Weaveworks and others offer Flux as-a-service to their users. The Flux team is very grateful to the community who supported us over the years and made Flux what it is today.