Skip to content

Instantly share code, notes, and snippets.

@dholbach

dholbach/flux2-website-docs.diff

Created April 27, 2021 13:56
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save dholbach/1a3b8da305825e75eee0e0407b04d39f to your computer and use it in GitHub Desktop.
Save dholbach/1a3b8da305825e75eee0e0407b04d39f to your computer and use it in GitHub Desktop.
Download ZIP
Raw
flux2-website-docs.diff
diff -ruN docs/cmd/_index.md /home/daniel/dev/website/content/en/docs/cmd/_index.md
--- docs/cmd/_index.md 1970-01-01 01:00:00.000000000 +0100
+++ /home/daniel/dev/website/content/en/docs/cmd/_index.md 2021-04-23 15:19:36.082198586 +0200
@@ -0,0 +1,4 @@
+---
+title: 'Flux CLI'
+weight: 65
+---
diff -ruN docs/components/helm/controller.md /home/daniel/dev/website/content/en/docs/components/helm/controller.md
--- docs/components/helm/controller.md 2021-02-23 15:51:02.403798514 +0100
+++ /home/daniel/dev/website/content/en/docs/components/helm/controller.md 2021-04-23 15:19:36.082198586 +0200
@@ -1,9 +1,13 @@
-# Helm Controller
+---
+title: Helm Controller
+linkTitle: Overview
+weight: 1
+---
The Helm Controller is a Kubernetes operator, allowing one to declaratively manage Helm chart
releases with Kubernetes manifests.
-![](../../_files/helm-controller.png)
+![](/img/helm-controller.png)
The desired state of a Helm release is described through a Kubernetes Custom Resource named `HelmRelease`.
Based on the creation, mutation or removal of a `HelmRelease` resource in the cluster,
diff -ruN docs/components/helm/.gitignore /home/daniel/dev/website/content/en/docs/components/helm/.gitignore
--- docs/components/helm/.gitignore 1970-01-01 01:00:00.000000000 +0100
+++ /home/daniel/dev/website/content/en/docs/components/helm/.gitignore 2021-04-23 16:01:30.408839426 +0200
@@ -0,0 +1,2 @@
+api.md
+helmreleases.md
diff -ruN docs/components/helm/_index.md /home/daniel/dev/website/content/en/docs/components/helm/_index.md
--- docs/components/helm/_index.md 1970-01-01 01:00:00.000000000 +0100
+++ /home/daniel/dev/website/content/en/docs/components/helm/_index.md 2021-04-23 15:19:36.082198586 +0200
@@ -0,0 +1,4 @@
+---
+linkTitle: Helm Controller
+weight: 40
+---
\ No newline at end of file
diff -ruN docs/components/image/controller.md /home/daniel/dev/website/content/en/docs/components/image/controller.md
--- docs/components/image/controller.md 2021-03-23 14:03:54.212170697 +0100
+++ /home/daniel/dev/website/content/en/docs/components/image/controller.md 2021-04-23 15:19:36.082198586 +0200
@@ -1,4 +1,9 @@
-# Image reflector and automation controllers
+---
+title: Image reflector and automation controllers
+linkTitle: Overview
+weight: 1
+---
+
The image-reflector-controller and image-automation-controller work together to update a Git
repository when new container images are available.
@@ -8,8 +13,6 @@
- The image-automation-controller updates YAML files based on the latest images scanned, and commits
the changes to a given Git repository.
-![](../../_files/image-update-automation.png)
-
Links:
- Source code [fluxcd/image-reflector-controller](https://github.com/fluxcd/image-reflector-controller)
diff -ruN docs/components/image/.gitignore /home/daniel/dev/website/content/en/docs/components/image/.gitignore
--- docs/components/image/.gitignore 1970-01-01 01:00:00.000000000 +0100
+++ /home/daniel/dev/website/content/en/docs/components/image/.gitignore 2021-04-23 16:01:30.408839426 +0200
@@ -0,0 +1,5 @@
+automation-api.md
+imagepolicies.md
+imagerepositories.md
+imageupdateautomations.md
+reflector-api.md
diff -ruN docs/components/image/_index.md /home/daniel/dev/website/content/en/docs/components/image/_index.md
--- docs/components/image/_index.md 1970-01-01 01:00:00.000000000 +0100
+++ /home/daniel/dev/website/content/en/docs/components/image/_index.md 2021-04-23 15:19:36.082198586 +0200
@@ -0,0 +1,4 @@
+---
+linkTitle: Image Automation Controllers
+weight: 60
+---
\ No newline at end of file
diff -u ~/dev/flux2/docs/components/index.md content/en/docs/components/_index.md
--- /home/daniel/dev/flux2/docs/components/index.md 2021-04-13 13:59:41.082084193 +0200
+++ content/en/docs/components/_index.md 2021-04-23 15:19:36.082198586 +0200
@@ -1,4 +1,8 @@
-# GitOps Toolkit components
+---
+title: "GitOps Toolkit components"
+linkTitle: "Toolkit Components"
+weight: 50
+---
The GitOps Toolkit is the set of APIs and controllers that make up the
runtime for Flux v2. The APIs comprise Kubernetes custom resources,
@@ -7,7 +11,7 @@
You can use the toolkit to extend Flux, and to build your own systems
for continuous delivery. The [the source-watcher
-guide](../dev-guides/source-watcher/) is a good place to start.
+guide](../gitops-toolkit/source-watcher/) is a good place to start.
A reference for each component and API type is linked below.
diff -ruN docs/components/kustomize/controller.md /home/daniel/dev/website/content/en/docs/components/kustomize/controller.md
--- docs/components/kustomize/controller.md 2020-11-04 15:29:45.087588507 +0100
+++ /home/daniel/dev/website/content/en/docs/components/kustomize/controller.md 2021-04-23 15:19:36.082198586 +0200
@@ -1,10 +1,15 @@
-# Kustomize Controller
+---
+title: Kustomize Controller
+linkTitle: Overview
+weight: 1
+---
+
The kustomize-controller is a Kubernetes operator,
specialized in running continuous delivery pipelines for infrastructure and
workloads defined with Kubernetes manifests and assembled with Kustomize.
-![](../../_files/kustomize-controller.png)
+![](/img/kustomize-controller.png)
Features:
diff -ruN docs/components/kustomize/_index.md /home/daniel/dev/website/content/en/docs/components/kustomize/_index.md
--- docs/components/kustomize/_index.md 1970-01-01 01:00:00.000000000 +0100
+++ /home/daniel/dev/website/content/en/docs/components/kustomize/_index.md 2021-04-23 15:19:36.082198586 +0200
@@ -0,0 +1,4 @@
+---
+linkTitle: Kustomize Controller
+weight: 20
+---
\ No newline at end of file
diff -ruN docs/components/notification/controller.md /home/daniel/dev/website/content/en/docs/components/notification/controller.md
--- docs/components/notification/controller.md 2020-11-04 15:29:45.087588507 +0100
+++ /home/daniel/dev/website/content/en/docs/components/notification/controller.md 2021-04-23 15:19:36.082198586 +0200
@@ -1,8 +1,13 @@
-# Notification Controller
+---
+title: Notification Controller
+linkTitle: Overview
+weight: 1
+---
+
The Notification Controller is a Kubernetes operator, specialized in handling inbound and outbound events.
-![](../../_files/notification-controller.png)
+![](/img/notification-controller.png)
The controller handles events coming from external systems (GitHub, GitLab, Bitbucket, Harbor, Jenkins, etc)
and notifies the GitOps toolkit controllers about source changes.
diff -ruN docs/components/notification/_index.md /home/daniel/dev/website/content/en/docs/components/notification/_index.md
--- docs/components/notification/_index.md 1970-01-01 01:00:00.000000000 +0100
+++ /home/daniel/dev/website/content/en/docs/components/notification/_index.md 2021-04-23 15:19:36.082198586 +0200
@@ -0,0 +1,4 @@
+---
+linkTitle: Notification Controller
+weight: 50
+---
\ No newline at end of file
diff -ruN docs/components/source/controller.md /home/daniel/dev/website/content/en/docs/components/source/controller.md
--- docs/components/source/controller.md 2020-11-04 15:29:45.087588507 +0100
+++ /home/daniel/dev/website/content/en/docs/components/source/controller.md 2021-04-23 15:19:36.082198586 +0200
@@ -1,10 +1,15 @@
-# Source Controller
+---
+title: Source Controller
+linkTitle: Overview
+weight: 1
+---
+
The main role of the source management component is to provide a common interface for artifacts acquisition.
The source API defines a set of Kubernetes objects that cluster admins and various automated operators can
interact with to offload the Git and Helm repositories operations to a dedicated controller.
-![](../../_files/source-controller.png)
+![](/img/source-controller.png)
Features:
diff -ruN docs/components/source/_index.md /home/daniel/dev/website/content/en/docs/components/source/_index.md
--- docs/components/source/_index.md 1970-01-01 01:00:00.000000000 +0100
+++ /home/daniel/dev/website/content/en/docs/components/source/_index.md 2021-04-23 15:19:36.082198586 +0200
@@ -0,0 +1,4 @@
+---
+linkTitle: Source Controller
+weight: 10
+---
\ No newline at end of file
diff -u ~/dev/flux2/docs/core-concepts/index.md content/en/docs/concepts.md
--- /home/daniel/dev/flux2/docs/core-concepts/index.md 2021-03-17 12:23:17.425045780 +0100
+++ content/en/docs/concepts.md 2021-04-23 16:01:30.408839426 +0200
@@ -1,7 +1,14 @@
-# Core Concepts
-
-!!! note "Work in progress"
- This document is a work in progress.
+---
+title: "Core Concepts"
+linkTitle: "Core Concepts"
+weight: 10
+description: >
+ Core Concepts of Flux v2
+---
+
+{{% alert color="warning" title="Work in progress" %}}
+This document is a work in progress.
+{{% /alert %}}
These are some core concepts in Flux.
@@ -28,7 +35,8 @@
All sources are specified as Custom Resources in a Kubernetes cluster, examples
of sources are `GitRepository`, `HelmRepository` and `Bucket` resources.
-For more information, take a look at [the source controller documentation](../components/source/controller.md).
+For more information, take a look at [the source controller
+documentation]({{< relref "./components/source/controller.md" >}}).
## Reconciliation
@@ -42,11 +50,12 @@
The kustomization represents a local set of Kubernetes resources that Flux is supposed to reconcile in the cluster. The reconciliation runs every one minute by default but this can be specified in the kustomization. If you make any changes to the cluster using `kubectl edit` or `kubectl patch`, it will be promptly reverted. You either suspend the reconciliation or push your changes to a Git repository.
-For more information, take a look at [this documentation](../components/kustomize/kustomization.md).
+For more information, take a look at [this
+documentation]({{< relref "./components/kustomize/kustomization.md" >}}).
## Bootstrap
The process of installing the Flux components in a complete GitOps way is called a bootstrap. The manifests are applied to the cluster, a `GitRepository` and `Kustomization` are created for the Flux components, and the manifests are pushed to an existing Git repository (or a new one is created). Flux can manage itself just as it manages other resources.
The bootstrap is done using the `flux` CLI `flux bootstrap`.
-For more information, take a look at [the documentation for the bootstrap command](../cmd/flux_bootstrap.md).
+For more information, take a look at [the documentation for the bootstrap command](./cmd/flux_bootstrap.md).
diff -u ~/dev/flux2/docs/contributing/index.md content/en/contributing.md
--- /home/daniel/dev/flux2/docs/contributing/index.md 2021-03-17 12:23:17.425045780 +0100
+++ content/en/contributing.md 2021-04-27 15:41:10.565881209 +0200
@@ -1,109 +1,50 @@
-# Contributing
-
-Flux is [Apache 2.0 licensed](https://github.com/fluxcd/flux2/blob/main/LICENSE) and
-accepts contributions via GitHub pull requests. This document outlines
-some of the conventions on to make it easier to get your contribution
-accepted.
-
-We gratefully welcome improvements to issues and documentation as well as to
-code.
-
-## Certificate of Origin
-
-By contributing to this project you agree to the Developer Certificate of
-Origin (DCO). This document was created by the Linux Kernel community and is a
-simple statement that you, as a contributor, have the legal right to make the
-contribution.
-
-We require all commits to be signed. By signing off with your signature, you
-certify that you wrote the patch or otherwise have the right to contribute the
-material by the rules of the [DCO](DCO):
-
-`Signed-off-by: Jane Doe <jane.doe@example.com>`
+---
+title: CONTRIBUTING
+---
-The signature must contain your real name
-(sorry, no pseudonyms or anonymous contributions)
-If your `user.name` and `user.email` are configured in your Git config,
-you can sign your commit automatically with `git commit -s`.
-
-## Communications
-
-For realtime communications we use Slack: To join the conversation, simply
-join the [CNCF](https://slack.cncf.io/) Slack workspace and use the
-[#flux-dev](https://cloud-native.slack.com/messages/flux-dev/) channel.
-
-To discuss ideas and specifications we use [Github
-Discussions](https://github.com/fluxcd/flux2/discussions).
-
-For announcements we use a mailing list as well. Simply subscribe to
-[flux-dev on cncf.io](https://lists.cncf.io/g/cncf-flux-dev)
-to join the conversation (there you can also add calendar invites
-to your Google calendar for our [Flux
-meeting](https://docs.google.com/document/d/1l_M0om0qUEN_NNiGgpqJ2tvsF2iioHkaARDeh6b70B0/view)).
-
-## Understanding Flux and the GitOps Toolkit
-
-If you are entirely new to Flux and the GitOps Toolkit,
-you might want to take a look at the [introductory talk and demo](https://www.youtube.com/watch?v=qQBtSkgl7tI).
+# Contributing
-This project is composed of:
+This document <https://github.com/fluxcd/community/blob/main/CONTRIBUTING.md> defines the contribution process for the Flux project and community.
+These guidelines apply to all git repositories in the `fluxcd` GitHub org, however each repository may specify additional contribution processes.
-- [flux2](https://github.com/fluxcd/flux2): The Flux CLI
-- [source-manager](https://github.com/fluxcd/source-controller): Kubernetes operator for managing sources (Git and Helm repositories, S3-compatible Buckets)
-- [kustomize-controller](https://github.com/fluxcd/kustomize-controller): Kubernetes operator for building GitOps pipelines with Kustomize
-- [helm-controller](https://github.com/fluxcd/helm-controller): Kubernetes operator for building GitOps pipelines with Helm
-- [notification-controller](https://github.com/fluxcd/notification-controller): Kubernetes operator for handling inbound and outbound events
-- [image-reflector-controller](https://github.com/fluxcd/image-reflector-controller): Kubernetes operator for scanning container registries
-- [image-automation-controller](https://github.com/fluxcd/image-automation-controller): Kubernetes operator for patches container image tags in Git
+## Welcome
-### Understanding the code
+We gratefully welcome all kinds of contributions, including code, issues, documentation, external tools, advocacy and community work.
+All members of the Flux community, including contributors, are expected to uphold the Flux community [Values](https://github.com/fluxcd/community/blob/main/GOVERNANCE.md#values) and [Code of Conduct](https://github.com/fluxcd/community/blob/main/GOVERNANCE.md#code-of-conduct).
-To get started with developing controllers, you might want to review
-[our guide](https://toolkit.fluxcd.io/dev-guides/source-watcher/) which
-walks you through writing a short and concise controller that watches out
-for source changes.
+## Communication
-### How to run the test suite
+As a contributor we want to invite you to join the discussions in a variety of forums laid out in <https://github.com/fluxcd/community/blob/main/README.md#communication>.
+All contributions – code or non-code – should follow the steps outlined in the [Proposal Process](https://github.com/fluxcd/community/blob/main/GOVERNANCE.md#proposal-process).
-Prerequisites:
+## Semantic Versioning
-* go >= 1.16
-* kubectl >= 1.18
-* kustomize >= 3.1
+The Flux project and community git repositories maintain a strong commitment to clear communication about backwards compatibility.
+For this reason, all code contributions must follow the Semantic Versioning 2.0.0 Specification (SemVer) per <https://semver.org/>, so that users can trust compatibility based on version scheme.
-You can run the unit tests by simply doing
+## Certificate of Origin
-```bash
-make test
-```
+Developer Certificate of Origin (DCO) commit signoff is required for all new code contributions.
+This is automatically checked by the [Probot: DCO](https://github.com/probot/dco/) integration across all `fluxcd` GitHub org repositories.
-## Acceptance policy
+Commit signoff is a simple statement that you, as a contributor, have the legal right to make the contribution.
+See `git help commit`:
-These things will make a PR more likely to be accepted:
+> The meaning of a signoff depends on the project, but it typically certifies that committer has the rights to submit this work under the same license and agrees to a Developer Certificate of Origin (see <http://developercertificate.org/> for more information).
-- a well-described requirement
-- tests for new code
-- tests for old code!
-- new code and tests follow the conventions in old code and tests
-- a good commit message (see below)
-- all code must abide [Go Code Review Comments](https://github.com/golang/go/wiki/CodeReviewComments)
-- names should abide [What's in a name](https://talks.golang.org/2014/names.slide#1)
-- code must build on both Linux and Darwin, via plain `go build`
-- code should have appropriate test coverage and tests should be written
- to work with `go test`
+### CLI
-In general, we will merge a PR once one maintainer has endorsed it.
-For substantial changes, more people may become involved, and you might
-get asked to resubmit the PR or divide the changes into more than one PR.
+When signing commits with `git commit -s`, signoff is drawn automatically from your `user.name` and `user.email` git configs.
+If you choose to manually add a signoff line to your commit message, it must be properly formatted and match your commit information. For example, when using the GitHub [private email option](https://docs.github.com/en/free-pro-team@latest/github/setting-up-and-managing-your-github-user-account/setting-your-commit-email-address) you must set your git config email accordingly.
+For those who wish to ensure this is always done in your CLI, consider implementing something like [this gist](https://gist.github.com/scottrigby/0c043c0bfbbdb5949e2d824fc3adeaa4).
-### Format of the Commit Message
+### Browser
-For the GitOps Toolkit controllers we prefer the following rules for good commit messages:
+For contributions made with the GitHub UI — including [applying suggested changes](https://docs.github.com/en/free-pro-team@latest/github/collaborating-with-issues-and-pull-requests/incorporating-feedback-in-your-pull-request) — the [scottrigby/dco-gh-ui](https://github.com/scottrigby/dco-gh-ui) browser extension is recommended.
+This pre-fills GitHub's commit textareas with a properly formatted signoff from your configured name and email.
+Otherwise, you will need to be sure to do so manually.
-- Limit the subject to 50 characters and write as the continuation
- of the sentence "If applied, this commit will ..."
-- Explain what and why in the body, if more than a trivial change;
- wrap it at 72 characters.
+## Thank You
-The [following article](https://chris.beams.io/posts/git-commit/#seven-rules)
-has some more helpful advice on documenting your work.
+[Contributors](https://github.com/fluxcd/community/blob/main/GOVERNANCE.md#contributors) are crucial to ensuring the Flux project continues to fairly represent community interests.
+Thank you for all that you do.
diff -u ~/dev/flux2/docs/dev-guides/debugging.md content/en/docs/gitops-toolkit/debugging.md
--- /home/daniel/dev/flux2/docs/dev-guides/debugging.md 2021-02-23 15:51:02.403798514 +0100
+++ content/en/docs/gitops-toolkit/debugging.md 2021-04-23 15:19:36.082198586 +0200
@@ -1,4 +1,9 @@
-# Advanced debugging
+---
+title: "Advanced debugging"
+linkTitle: "Advanced debugging"
+weight: 20
+---
+
This guide covers more advanced debugging topics such as collecting
runtime profiling data from GitOps Toolkit components.
@@ -9,7 +14,7 @@
## Pprof
-The [GitOps Toolkit components](../components/index.md) serve [`pprof`](https://golang.org/pkg/net/http/pprof/)
+The [GitOps Toolkit components](../components/_index.md) serve [`pprof`](https://golang.org/pkg/net/http/pprof/)
runtime profiling data on their metrics HTTP server (default `:8080`).
### Endpoints
@@ -26,7 +31,7 @@
To collect a profile, port-forward to the component's metrics endpoint
and collect the data from the [endpoint](#endpoints) of choice:
-```console
+```sh
$ kubectl port-forward -n <namespace> deploy/<component> 8080
$ curl -Sk -v http://localhost:8080/debug/pprof/heap > heap.out
```
diff -u ~/dev/flux2/docs/dev-guides/source-watcher.md content/en/docs/gitops-toolkit/source-watcher.md
--- /home/daniel/dev/flux2/docs/dev-guides/source-watcher.md 2021-03-24 16:24:36.508966641 +0100
+++ content/en/docs/gitops-toolkit/source-watcher.md 2021-04-23 15:19:36.082198586 +0200
@@ -1,4 +1,9 @@
-# Watching for source changes
+---
+title: "Watching for source changes"
+linkTitle: "Watching for source changes"
+weight: 10
+---
+
In this guide you'll be developing a Kubernetes controller with
[Kubebuilder](https://github.com/kubernetes-sigs/kubebuilder)
@@ -94,7 +99,7 @@
The source-watcher should log the revision:
-```console
+```sh
New revision detected {"gitrepository": "flux-system/test", "revision": "4.0.0/ab953493ee14c3c9800bda0251e0c507f9741408"}
Extracted tarball into /var/folders/77/3y6x_p2j2g9fspdkzjbm5_s40000gn/T/test292235827: 123 files, 29 dirs (32.603415ms)
Processing files...
@@ -110,7 +115,7 @@
The source-watcher should log the new revision:
-```console
+```sh
New revision detected {"gitrepository": "flux-system/test", "revision": "4.0.1/113360052b3153e439a0cf8de76b8e3d2a7bdf27"}
```
diff -u ~/dev/flux2/docs/faq/index.md content/en/docs/faq/_index.md
--- /home/daniel/dev/flux2/docs/faq/index.md 2021-03-08 10:21:34.465914604 +0100
+++ content/en/docs/faq/_index.md 2021-04-23 15:19:36.082198586 +0200
@@ -1,4 +1,11 @@
-# Frequently asked questions
+---
+title: "Frequently asked questions"
+linkTitle: "FAQ"
+weight: 100
+description: >
+ Frequently asked questions regarding Flux v2
+---
+
## Kustomize questions
@@ -161,11 +168,12 @@
- `--load_restrictor` is set to `LoadRestrictionsNone`, so it allows loading files outside the dir containing `kustomization.yaml`.
- `--reorder` resources is done in the `legacy` mode, so the output will have namespaces and cluster roles/role bindings first, CRDs before CRs, and webhooks last.
-!!! hint "`kustomization.yaml` validation"
- To validate changes before committing and/or merging, [a validation
- utility script is available](https://github.com/fluxcd/flux2-kustomize-helm-example/blob/main/scripts/validate.sh),
- it runs `kustomize` locally or in CI with the same set of flags as
- the controller and validates the output using `kubeval`.
+{{% alert color="info" title="kustomization.yaml validation" %}}
+To validate changes before committing and/or merging, [a validation
+utility script is available](https://github.com/fluxcd/flux2-kustomize-helm-example/blob/main/scripts/validate.sh),
+it runs `kustomize` locally or in CI with the same set of flags as
+the controller and validates the output using `kubeval`.
+{{% /alert %}}
## Helm questions
@@ -174,7 +182,7 @@
Misconfiguring the `HelmRelease.spec.chart`, like a typo in the chart name, version or chart source URL
would result in a "HelmChart is not ready" error displayed by:
-```console
+```sh
$ flux get helmreleases --all-namespaces
NAMESPACE NAME READY MESSAGE
default podinfo False HelmChart 'default/default-podinfo' is not ready
@@ -183,7 +191,7 @@
In order to get to the root cause, first make sure the source e.g. the `HelmRepository`
is configured properly and has access to the remote `index.yaml`:
-```console
+```sh
$ flux get sources helm --all-namespaces
NAMESPACE NAME READY MESSAGE
default podinfo False failed to fetch https://stefanprodan.github.io/podinfo2/index.yaml : 404 Not Found
@@ -192,7 +200,7 @@
If the source is `Ready`, then the error must be caused by the chart,
for example due to an invalid chart name or non-existing version:
-```console
+```sh
$ flux get sources chart --all-namespaces
NAMESPACE NAME READY MESSAGE
default default-podinfo False no chart version found for podinfo-9.0.0
diff -u ~/dev/flux2/docs/get-started/index.md content/en/docs/get-started.md
--- /home/daniel/dev/flux2/docs/get-started/index.md 2021-01-20 14:38:16.146323583 +0100
+++ content/en/docs/get-started.md 2021-04-23 16:01:30.408839426 +0200
@@ -1,9 +1,16 @@
-# Get started with Flux v2
-
-!!! note "Basic knowledge"
- This guide assumes you have some understanding of the core concepts and have read the introduction to Flux.
- The core concepts used in this guide are [GitOps](../core-concepts/index.md#gitops),
- [Sources](../core-concepts/index.md#sources), [Kustomization](../core-concepts/index.md#kustomization).
+---
+title: "Get Started with Flux v2"
+linkTitle: "Get Started"
+weight: 20
+description: >
+ Get started with Flux v2
+---
+
+{{% alert color="info" title="Basic knowledge" %}}
+This guide assumes you have some understanding of the core concepts and have read the introduction to Flux.
+The core concepts used in this guide are [GitOps](../concepts/#gitops),
+[Sources](../concepts/#sources), [Kustomization](../concepts/#kustomization).
+{{% /alert %}}
In this tutorial, you will deploy an application to a kubernetes cluster with Flux
and manage the cluster in a complete GitOps manner.
@@ -52,14 +59,14 @@
Binaries for **macOS**, **Windows** and **Linux** AMD64/ARM are available for download on the
[release page](https://github.com/fluxcd/flux2/releases).
-To configure your shell to load `flux` [bash completions](../cmd/flux_completion_bash.md) add to your profile:
+To configure your shell to load `flux` [bash completions](./cmd/flux_completion_bash.md) add to your profile:
```sh
# ~/.bashrc or ~/.bash_profile
. <(flux completion bash)
```
-[`zsh`](../cmd/flux_completion_zsh.md), [`fish`](../cmd/flux_completion_fish.md), and [`powershell`](../cmd/flux_completion_powershell.md) are also supported with their own sub-commands.
+[`zsh`](./cmd/flux_completion_zsh.md), [`fish`](./cmd/flux_completion_fish.md), and [`powershell`](./cmd/flux_completion_powershell.md) are also supported with their own sub-commands.
## Install Flux components
@@ -91,10 +98,11 @@
--personal
```
-!!! hint "Multi-arch images"
- The component images are published as [multi-arch container images](https://docs.docker.com/docker-for-mac/multi-arch/)
- with support for Linux `amd64`, `arm64` and `armv7` (e.g. 32bit Raspberry Pi)
- architectures.
+{{% alert color="info" title="Multi-arch images" %}}
+The component images are published as [multi-arch container images](https://docs.docker.com/docker-for-mac/multi-arch/)
+with support for Linux `amd64`, `arm64` and `armv7` (e.g. 32bit Raspberry Pi)
+architectures.
+{{% /alert %}}
The bootstrap command creates a repository if one doesn't exist,
commits the manifests for the Flux components to the default branch at the specified path,
@@ -139,14 +147,16 @@
```
If you prefer GitLab, export `GITLAB_TOKEN` env var and
-use the command [flux bootstrap gitlab](../guides/installation.md#gitlab-and-gitlab-enterprise).
+use the command [flux bootstrap
+gitlab]({{< relref "./guides/installation.md#gitlab-and-gitlab-enterprise" >}}).
-!!! hint "Idempotency"
- It is safe to run the bootstrap command as many times as you want.
- If the Flux components are present on the cluster,
- the bootstrap command will perform an upgrade if needed.
- You can target a specific Flux [version](https://github.com/fluxcd/flux2/releases)
- with `flux bootstrap --version=<semver>`.
+{{% alert color="info" title="Idempotency" %}}
+It is safe to run the bootstrap command as many times as you want.
+If the Flux components are present on the cluster,
+the bootstrap command will perform an upgrade if needed.
+You can target a specific Flux [version](https://github.com/fluxcd/flux2/releases)
+with `flux bootstrap --version=<semver>`.
+{{% /alert %}}
## Clone the git repository
@@ -277,9 +287,10 @@
service/podinfo ClusterIP 10.100.149.126 <none> 9898/TCP,9999/TCP 108s
```
-!!! tip
- From this moment forward, any changes made to the podinfo
- Kubernetes manifests in the master branch will be synchronised with your cluster.
+{{% alert color="info" %}}
+From this moment forward, any changes made to the podinfo
+Kubernetes manifests in the master branch will be synchronised with your cluster.
+{{% /alert %}}
If a Kubernetes manifest is removed from the podinfo repository, Flux will remove it from your cluster.
If you delete a `Kustomization` from the fleet-infra repository, Flux will remove all Kubernetes objects that
@@ -296,4 +307,4 @@
two approaches in the repositories listed below.
1. [https://github.com/fluxcd/flux2-kustomize-helm-example](https://github.com/fluxcd/flux2-kustomize-helm-example)
-2. [https://github.com/fluxcd/flux2-multi-tenancy](https://github.com/fluxcd/flux2-multi-tenancy)
\ No newline at end of file
+2. [https://github.com/fluxcd/flux2-multi-tenancy](https://github.com/fluxcd/flux2-multi-tenancy)
diff -ruN docs/gitops-toolkit/_index.md /home/daniel/dev/website/content/en/docs/gitops-toolkit/_index.md
--- docs/gitops-toolkit/_index.md 1970-01-01 01:00:00.000000000 +0100
+++ /home/daniel/dev/website/content/en/docs/gitops-toolkit/_index.md 2021-04-23 15:19:36.082198586 +0200
@@ -0,0 +1,5 @@
+---
+title: "Dev Guides"
+linkTitle: "Dev Guides"
+weight: 70
+---
diff -u ~/dev/flux2/docs/guides/faq-migration.md content/en/docs/migration/faq-migration.md
--- /home/daniel/dev/flux2/docs/guides/faq-migration.md 2021-03-08 10:21:34.465914604 +0100
+++ content/en/docs/migration/faq-migration.md 2021-04-23 15:19:36.086198633 +0200
@@ -1,3 +1,9 @@
+---
+title: FAQ
+linkTitle: FAQ
+weight: 100
+---
+
## Flux v1 vs v2 questions
### What does Flux v2 mean for Flux?
diff -u ~/dev/flux2/docs/guides/flux-v1-automation-migration.md content/en/docs/migration/flux-v1-automation-migration.md
--- /home/daniel/dev/flux2/docs/guides/flux-v1-automation-migration.md 2021-04-23 11:44:58.749345065 +0200
+++ content/en/docs/migration/flux-v1-automation-migration.md 2021-04-23 15:19:36.086198633 +0200
@@ -1,5 +1,9 @@
-<!-- -*- fill-column: 100 -*- -->
-# Migrating image update automation to Flux v2
+---
+title: "Migrating image update automation to Flux v2"
+linkTitle: "Migrate from Flux v1 image update automation"
+weight: 20
+---
+
"Image Update Automation" is a process in which Flux makes commits to your Git repository when it
detects that there is a new image to be used in a workload (e.g., a Deployment). In Flux v2 this
@@ -369,9 +373,10 @@
image: ghcr.io/stefanprodan/podinfo:5.0.0
```
-!!! warning
- A YAML file may have more than one manifest in it, separated with
- `---`. Be careful to account for each manifest in a file.
+{{% alert color="info" color="warning" %}}
+A YAML file may have more than one manifest in it, separated with
+`---`. Be careful to account for each manifest in a file.
+{{% /alert %}}
You may wish to try migrating the automation of just one file or manifest and follow it through to
the end of the guide, before returning here to do the remainder.
@@ -422,9 +427,10 @@
interval: 5m0s
```
-!!! hint
- If you are using the same image repository in several manifests, you only need one
- `ImageRepository` object for it.
+{{% alert color="info" title="Note" %}}
+If you are using the same image repository in several manifests, you only need one
+`ImageRepository` object for it.
+{{% /alert %}}
##### Using image registry credentials for scanning
diff -u ~/dev/flux2/docs/guides/flux-v1-migration.md content/en/docs/migration/flux-v1-migration.md
--- /home/daniel/dev/flux2/docs/guides/flux-v1-migration.md 2021-03-08 10:21:34.465914604 +0100
+++ content/en/docs/migration/flux-v1-migration.md 2021-04-23 15:19:36.086198633 +0200
@@ -1,20 +1,29 @@
-# Migrate from Flux v1 to v2
+---
+title: "Migrate from Flux v1 to v2"
+linkTitle: "Migrate from Flux v1"
+weight: 10
+card:
+ name: migration
+ weight: 10
+---
This guide walks you through migrating from Flux v1 to v2.
-Read the [FAQ](faq-migration.md) to find out what differences are between v1 and v2.
+Read the [FAQ]({{< relref "/faq-migration" >}}) to find out what differences are between v1 and v2.
-!!! info "Automated image updates"
- The image automation feature is under development in Flux v2.
- Please consult the [roadmap](../roadmap/index.md) for more details.
-
-!!! info "Feature parity"
- "Feature parity" does not mean Flux v2 works exactly the same as v1 (or is
- backward-compatible); it means you can accomplish the same results, while
- accounting for the fact that it's a system with a substantially different
- design.
- This may at times mean that you have to make adjustments to the way your
- current cluster configuration is structured. If you are in this situation
- and need help, please refer to the [support page](https://fluxcd.io/support/).
+{{% alert color="info" title="Automated image updates" %}}
+The image automation feature is under development in Flux v2.
+Please consult the [roadmap]({{< relref "../roadmap/_index.md" >}}) for more details.
+{{% /alert %}}
+
+{{% alert color="info" title="Feature parity" %}}
+"Feature parity" does not mean Flux v2 works exactly the same as v1 (or is
+backward-compatible); it means you can accomplish the same results, while
+accounting for the fact that it's a system with a substantially different
+design.
+This may at times mean that you have to make adjustments to the way your
+current cluster configuration is structured. If you are in this situation
+and need help, please refer to the [support page](https://fluxcd.io/support/).
+{{% /alert %}}
## Prerequisites
@@ -60,14 +69,16 @@
repository. The Git repository created during bootstrap can be used
to define the state of your fleet of Kubernetes clusters.
-For a detailed walk-through of the bootstrap procedure please see the [installation guide](installation.md).
+For a detailed walk-through of the bootstrap procedure please see the [installation
+guide]({{< relref "../guides/installation.md" >}}).
-!!! warning "`flux bootstrap` target"
- `flux bootstrap` should not be run against a Git branch or path
- that is already being synchronized by Flux v1, as this will make
- them fight over the resources. Instead, bootstrap to a **new Git
- repository, branch or path**, and continue with moving the
- manifests.
+{{% alert color="info" color="warning" title="'flux bootstrap' target" %}}
+`flux bootstrap` should not be run against a Git branch or path
+that is already being synchronized by Flux v1, as this will make
+them fight over the resources. Instead, bootstrap to a **new Git
+repository, branch or path**, and continue with moving the
+manifests.
+{{% /alert %}}
After you've installed Flux v2 on your cluster using bootstrap,
you can delete the Flux v1 from your clusters and move the manifests from the
@@ -75,10 +86,11 @@
## In-place migration
-!!! warning
- For production use we recommend using the **bootstrap** procedure (see the [Gitops migration](#gitops-migration) section above),
- but if you wish to install Flux v2 in the
- same way as Flux v1 then follow along.
+{{% alert color="info" color="warning" %}}
+For production use we recommend using the **bootstrap** procedure (see the [Gitops migration](#gitops-migration) section above),
+but if you wish to install Flux v2 in the
+same way as Flux v1 then follow along.
+{{% /alert %}}
### Flux read-only mode
@@ -103,14 +115,15 @@
fluxctl sync --k8s-fwd-ns flux
```
-!!! hint "Uninstall Flux v1"
- Before you proceed, scale the Flux v1 deployment to zero
- or delete its namespace and RBAC.
+{{% alert color="info" title="Uninstall Flux v1" %}}
+Before you proceed, scale the Flux v1 deployment to zero
+or delete its namespace and RBAC.
+{{% /alert %}}
If there are YAML files in your `deploy` dir that are not meant to be
applied on the cluster, you can exclude them by placing a `.sourceignore` in your repo root:
-```console
+```sh
$ cat .sourceignore
# exclude all
/*
@@ -123,8 +136,9 @@
Install Flux v2 in the `flux-system` namespace:
-```console
+```sh
$ flux install \
+ --arch=amd64 \
--network-policy=true \
--watch-all-namespaces=true \
--namespace=flux-system
@@ -142,7 +156,7 @@
Register your Git repository and add the deploy key with read-only access:
-```console
+```sh
$ flux create source git app \
--url=ssh://git@github.com/org/app \
--branch=main \
@@ -165,9 +179,9 @@
Configure the reconciliation of the `deploy` dir on your cluster:
-```console
+```sh
$ flux create kustomization app \
- --source=app \
+ --source=GitRepository/app \
--path="./deploy" \
--prune=true \
--interval=10m
@@ -179,7 +193,8 @@
✔ applied revision main/5302d04c2ab8f0579500747efa0fe7abc72c8f9b
```
-If your repository contains secrets encrypted with Mozilla SOPS, please read this [guide](mozilla-sops.md).
+If your repository contains secrets encrypted with Mozilla SOPS, please read this
+[guide]({{< relref "../guides/installation.md" >}}).
Pull changes from Git and apply them immediately:
@@ -217,9 +232,10 @@
patchFile: flux-patch.yaml
```
-!!! hint "Uninstall Flux v1"
- Before you proceed, delete the Flux v1 namespace
- and remove the `.flux.yaml` from your repo.
+{{% alert color="info" title="Uninstall Flux v1" %}}
+Before you proceed, delete the Flux v1 namespace
+and remove the `.flux.yaml` from your repo.
+{{% /alert %}}
Install Flux v2 in the `flux-system` namespace:
@@ -242,7 +258,7 @@
```sh
flux create kustomization app \
- --source=GitRepository/app \
+ --source=app \
--path="./overlays/prod" \
--prune=true \
--interval=10m
@@ -250,7 +266,7 @@
Check the status of the Kustomization reconciliation:
-```console
+```sh
$ flux get kustomizations app
NAME REVISION SUSPENDED READY
app main/5302d04c2ab8f0579500747efa0fe7abc72c8f9b False True
@@ -280,13 +296,14 @@
```
For more details, read the guides on how to configure
-[notifications](notifications.md) and [webhooks](webhook-receivers.md).
+[notifications]({{< relref "../guides/notifications.md" >}}) and
+[webhooks]({{< relref "../guides/webhook-receivers.md" >}}).
### Flux debugging
Check the status of Git operations:
-```console
+```sh
$ kubectl -n flux-system get gitrepositories
NAME READY MESSAGE
app True Fetched revision: main/5302d04c2ab8f0579500747efa0fe7abc72c8f9b
@@ -295,7 +312,7 @@
Check the status of the cluster reconciliation with kubectl:
-```console
+```sh
$ kubectl -n flux-system get kustomizations
NAME READY STATUS
app True Applied revision: main/5302d04c2ab8f0579500747efa0fe7abc72c8f9
@@ -304,7 +321,7 @@
Suspend a reconciliation:
-```console
+```sh
$ flux suspend kustomization app
► suspending kustomization app in flux-system namespace
✔ kustomization suspended
@@ -312,7 +329,7 @@
Check the status with kubectl:
-```console
+```sh
$ kubectl -n flux-system get kustomization app
NAME READY STATUS
app False Kustomization is suspended, skipping reconciliation
@@ -320,7 +337,7 @@
Resume a reconciliation:
-```console
+```sh
$ flux resume kustomization app
► resuming Kustomization app in flux-system namespace
✔ Kustomization resumed
diff -u ~/dev/flux2/docs/guides/helm-operator-migration.md content/en/docs/migration/helm-operator-migration.md
--- /home/daniel/dev/flux2/docs/guides/helm-operator-migration.md 2021-04-23 11:44:58.749345065 +0200
+++ content/en/docs/migration/helm-operator-migration.md 2021-04-23 15:19:36.086198633 +0200
@@ -1,4 +1,12 @@
-# Migrate to the Helm Controller
+---
+title: "Migrate to the Helm Controller"
+linkTitle: "Migrate from the Helm Operator"
+weight: 30
+card:
+ name: migration
+ weight: 20
+---
+
This guide will learn you everything you need to know to be able to migrate from the [Helm Operator](https://github.com/fluxcd/helm-operator) to the [Helm Controller](https://github.com/fluxcd/helm-controller).
@@ -101,7 +109,7 @@
With the new [`flux` CLI](../cmd/flux.md) it is now possible to create and/or generate the Custom Resources mentioned earlier. To generate the YAML for a `HelmRepository` and `HelmRelease` resource, you can for example run:
-```console
+```sh
$ flux create source helm podinfo \
--url=https://stefanprodan.github.io/podinfo \
--interval=10m \
@@ -854,7 +862,7 @@
Helm Controller depends on [Source Controller](../components/source/controller.md), you can install both controllers
and manager Helm releases in a declarative way without GitOps.
-For more details please see this [answer](../faq/index.md#can-i-use-flux-helmreleases-without-gitops).
+For more details please see this [answer]({{< relref "/faq.md#can-i-use-flux-helmreleases-without-gitops" >}}).
### I have another question
diff -ruN docs/guides/helmreleases.md /home/daniel/dev/website/content/en/docs/guides/helmreleases.md
--- docs/guides/helmreleases.md 2021-04-23 11:44:58.749345065 +0200
+++ /home/daniel/dev/website/content/en/docs/guides/helmreleases.md 2021-04-23 15:19:36.082198586 +0200
@@ -1,4 +1,11 @@
-# Manage Helm Releases
+---
+title: "Manage Helm Releases"
+linkTitle: "Manage Helm Releases"
+weight: 20
+card:
+ name: tasks
+ weight: 30
+---
The [helm-controller](../components/helm/controller.md) allows you to
declaratively manage Helm chart releases with Kubernetes manifests.
@@ -50,11 +57,11 @@
The `url` can be any HTTP/S Helm repository URL.
-!!! hint "Authentication"
- HTTP/S basic and TLS authentication can be configured for private
- Helm repositories. See the [`HelmRepository` CRD docs](../components/source/helmrepositories.md)
- for more details.
-
+{{% alert color="info" title="Authentication" %}}
+HTTP/S basic and TLS authentication can be configured for private
+Helm repositories. See the [`HelmRepository` CRD docs](../components/source/helmrepositories.md)
+for more details.
+{{% /alert %}}
### Git repository
Charts from Git repositories can be released by declaring a
@@ -107,10 +114,11 @@
The above example only includes the `charts` directory of the
repository and omits all other files.
-!!! hint "Authentication"
- HTTP/S basic and SSH authentication can be configured for private
- Git repositories. See the [`GitRepository` CRD docs](../components/source/gitrepositories.md)
- for more details.
+{{% alert color="info" title="Authentication" %}}
+HTTP/S basic and SSH authentication can be configured for private
+Git repositories. See the [`GitRepository` CRD docs](../components/source/gitrepositories.md)
+for more details.
+{{% /alert %}}
### Cloud Storage
@@ -232,11 +240,12 @@
(i.e. `>=4.0.0 <5.0.0`). It is only taken into account for `HelmRelease`
resources that reference a `HelmRepository` source.
-!!! hint "Advanced configuration"
- The `HelmRelease` offers an extensive set of configurable flags
- for finer grain control over how Helm actions are performed.
- See the [`HelmRelease` CRD docs](../components/helm/helmreleases.md)
- for more details.
+{{% alert color="info" title="Advanced configuration" %}}
+The `HelmRelease` offers an extensive set of configurable flags
+for finer grain control over how Helm actions are performed.
+See the [`HelmRelease` CRD docs](../components/helm/helmreleases.md)
+for more details.
+{{% /alert %}}
## Refer to values in `ConfigMap` and `Secret` resources
@@ -270,18 +279,20 @@
a single flat value. Defaults to `None` when omitted, which results
in the values getting merged at the root.
-!!! hint "Note"
- The `targetPath` supports the same formatting as you would supply
- as an argument to the `helm` binary using `--set [path]=[value]`.
- In addition to this, the referred value can contain the same
- value formats (e.g. `{a,b,c}` for a list).
- You can read more about the available formats and limitations in
- the [Helm documentation](https://helm.sh/docs/intro/using_helm/#the-format-and-limitations-of---set).
-
-!!! warning "`TargetPath` and JSON values"
- When using `TargetPath` in combination with a JSON string, the
- [limitations are the same as while using `helm`](https://github.com/helm/helm/issues/5618),
- and require you to escape the full JSON string (including `=`, `[`, `,`, `.`).
+{{% alert color="info" title="Note" %}}
+The `targetPath` supports the same formatting as you would supply
+as an argument to the `helm` binary using `--set [path]=[value]`.
+In addition to this, the referred value can contain the same
+value formats (e.g. `{a,b,c}` for a list).
+You can read more about the available formats and limitations in
+the [Helm documentation](https://helm.sh/docs/intro/using_helm/#the-format-and-limitations-of---set).
+{{% /alert %}}
+
+{{% alert color="info" title="TargetPath and JSON values" color="warning" %}}
+When using `TargetPath` in combination with a JSON string, the
+[limitations are the same as while using `helm`](https://github.com/helm/helm/issues/5618),
+and require you to escape the full JSON string (including `=`, `[`, `,`, `.`).
+{{% /alert %}}
## Refer to values in `ConfigMaps` generated with Kustomize
@@ -355,10 +366,11 @@
name: podinfo-values-2mh2t8m94h
```
-!!! hint "Note"
- Stale `ConfigMaps`, previously generated by Kustomize, will be
- removed from the cluster by kustomize-controller if
- [pruning](../components/kustomize/kustomization/#garbage-collection) is enabled.
+{{% alert color="info" title="Note" %}}
+Stale `ConfigMaps`, previously generated by Kustomize, will be
+removed from the cluster by kustomize-controller if
+[pruning](../components/kustomize/kustomization/#garbage-collection) is enabled.
+{{% /alert %}}
## Refer to values inside the chart
@@ -388,7 +400,7 @@
If the `spec.chart.spec.valuesFiles` doesn't exists inside the chart, helm-controller will not be able to
fetch the chart. To determine why the `HelmChart` fails to produce an artifact, you can inspect the status with:
-```console
+```sh
$ kubectl get helmcharts --all-namespaces
NAME READY STATUS
mongodb False failed to locate override values file: values-prod.yaml
@@ -426,7 +438,7 @@
namespace: default
```
-![helm-controller alerts](../_files/helm-controller-alerts.png)
+![helm-controller alerts](/img/helm-controller-alerts.png)
## Configure webhook receivers
@@ -466,7 +478,7 @@
Find the URL with:
-```console
+```sh
$ kubectl -n flux-system get receiver/helm-podinfo
NAME READY STATUS
@@ -487,7 +499,8 @@
* Source controller pulls the changes into the cluster and updates the `HelmChart` version
* Helm controller is notified about the version change and upgrades the release
-!!! hint "Note"
- Besides Harbor, you can define receivers for **GitHub**, **GitLab**, **Bitbucket**
- and any other system that supports webhooks e.g. Jenkins, CircleCI, etc.
- See the [Receiver CRD docs](../components/notification/receiver.md) for more details.
+{{% alert color="info" title="Note" %}}
+Besides Harbor, you can define receivers for **GitHub**, **GitLab**, **Bitbucket**
+and any other system that supports webhooks e.g. Jenkins, CircleCI, etc.
+See the [Receiver CRD docs](../components/notification/receiver.md) for more details.
+{{% /alert %}}
diff -ruN docs/guides/image-update.md /home/daniel/dev/website/content/en/docs/guides/image-update.md
--- docs/guides/image-update.md 2021-04-23 11:44:58.749345065 +0200
+++ /home/daniel/dev/website/content/en/docs/guides/image-update.md 2021-04-23 15:19:36.082198586 +0200
@@ -1,4 +1,12 @@
-# Automate image updates to Git
+---
+title: "Automate image updates to Git"
+linkTitle: "Automate image updates to Git"
+weight: 80
+card:
+ name: tasks
+ weight: 20
+---
+
This guide walks you through configuring container image scanning and deployment rollouts with Flux.
@@ -10,9 +18,10 @@
- checkout a branch, commit and push the changes to the remote Git repository
- apply the changes in-cluster and rollout the container image
-!!! warning "Alpha version"
- Note that the image update feature is currently alpha,
- see the [roadmap](../roadmap/index.md) for more details.
+{{% alert color="info" title="Alpha version" color="warning" %}}
+Note that the image update feature is currently alpha,
+see the [roadmap]({{< relref "../roadmap/" >}}) for more details.
+{{% /alert %}}
For production environments, this feature allows you to automatically deploy application patches
(CVEs and bug fixes), and keep a record of all deployments in Git history.
@@ -56,11 +65,12 @@
## Install Flux
-!!! hint "Enable image automation components"
- If you bootstrapped Flux before without the `--components-extra=` argument, you need to add
- `--components-extra=image-reflector-controller,image-automation-controller` to your
- bootstrapping routine as image automation components are not installed by default.
-
+{{% alert color="info" title="Enable image automation components" %}}
+If you bootstrapped Flux before without the `--components-extra=` argument, you need to add
+`--components-extra=image-reflector-controller,image-automation-controller` to your
+bootstrapping routine as image automation components are not installed by default.
+{{% /alert %}}
+
Install Flux with the image automation components:
```sh
@@ -78,11 +88,12 @@
Flux components to the default branch at the specified path. It then configures the target cluster to
synchronize with the specified path inside the repository.
-!!! hint "GitLab and other Git platforms"
- You can install Flux and bootstrap repositories hosted on GitLab, BitBucket, Azure DevOps and
- any other Git provider that support SSH or token-based authentication.
- When using SSH, make sure the deploy key is configured with write access.
- Please see the [installation guide](installation.md) for more details.
+{{% alert color="info" title="GitLab and other Git platforms" %}}
+You can install Flux and bootstrap repositories hosted on GitLab, BitBucket, Azure DevOps and
+any other Git provider that support SSH or token-based authentication.
+When using SSH, make sure the deploy key is configured with write access.
+Please see the [installation guide](installation.md) for more details.
+{{% /alert %}}
## Deploy a demo app
@@ -119,7 +130,7 @@
Print the podinfo image deployed on your cluster:
-```console
+```sh
$ kubectl get deployment/podinfo -oyaml | grep 'image:'
image: ghcr.io/stefanprodan/podinfo:5.0.0
```
@@ -161,9 +172,10 @@
name: regcred
```
-!!! hint "Storing secrets in Git"
- Note that if you want to store the image pull secret in Git, you can encrypt
- the manifest with [Mozilla SOPS](mozilla-sops.md) or [Sealed Secrets](sealed-secrets.md).
+{{% alert color="info" title="Storing secrets in Git" %}}
+Note that if you want to store the image pull secret in Git, you can encrypt
+the manifest with [Mozilla SOPS](mozilla-sops.md) or [Sealed Secrets](sealed-secrets.md).
+{{% /alert %}}
Create an `ImagePolicy` to tell Flux which semver range to use when filtering tags:
@@ -190,15 +202,17 @@
range: 5.0.x
```
-!!! hint "semver ranges"
- A semver range that includes stable releases can be defined with
- `1.0.x` (patch versions only) or `>=1.0.0 <2.0.0` (minor and patch versions).
- If you want to include pre-release e.g. `1.0.0-rc.1`,
- you can define a range like: `^1.x-0` or `>1.0.0-rc <2.0.0-rc`.
-
-!!! hint "Other policy examples"
- For policies that make use of CalVer, build IDs or alphabetical sorting,
- have a look at [the examples](../components/image/imagepolicies.md#examples).
+{{% alert color="info" title="semver ranges" %}}
+A semver range that includes stable releases can be defined with
+`1.0.x` (patch versions only) or `>=1.0.0 <2.0.0` (minor and patch versions).
+If you want to include pre-release e.g. `1.0.0-rc.1`,
+you can define a range like: `^1.x-0` or `>1.0.0-rc <2.0.0-rc`.
+{{% /alert %}}
+
+{{% alert color="info" title="Other policy examples" %}}
+For policies that make use of CalVer, build IDs or alphabetical sorting,
+have a look at [the examples](../components/image/imagepolicies.md#examples).
+{{% /alert %}}
Commit and push changes to main branch:
@@ -216,7 +230,7 @@
Wait for Flux to fetch the image tag list from GitHub container registry:
-```console
+```sh
$ flux get image repository podinfo
NAME READY MESSAGE LAST SCAN
podinfo True successful scan, found 13 tags 2020-12-13T17:51:48+02:00
@@ -224,7 +238,7 @@
Find which image tag matches the policy semver range with:
-```console
+```sh
$ flux get image policy podinfo
NAME READY MESSAGE
podinfo True Latest image tag for 'ghcr.io/stefanprodan/podinfo' resolved to: 5.0.3
@@ -303,14 +317,14 @@
In a couple of seconds, Flux will push a commit to your repository with
the latest image tag that matches the podinfo policy:
-```console
+```sh
$ git pull && cat clusters/my-cluster/podinfo-deployment.yaml | grep "image:"
image: ghcr.io/stefanprodan/podinfo:5.0.3 # {"$imagepolicy": "flux-system:podinfo"}
```
Wait for Flux to apply the latest commit on the cluster and verify that podinfo was updated to `5.0.3`:
-```console
+```sh
$ watch "kubectl get deployment/podinfo -oyaml | grep 'image:'"
image: ghcr.io/stefanprodan/podinfo:5.0.3
```
@@ -489,7 +503,7 @@
Find the URL with:
-```console
+```sh
$ kubectl -n flux-system get receiver/podinfo
NAME READY STATUS
@@ -500,10 +514,11 @@
Fill the form "Webhook URL" by composing the address using the receiver
LB and the generated URL `http://<LoadBalancerAddress>/<ReceiverURL>`.
-!!! hint "Note"
- Besides DockerHub, you can define receivers for **Harbor**, **Quay**, **Nexus**, **GCR**,
- and any other system that supports webhooks e.g. GitHub Actions, Jenkins, CircleCI, etc.
- See the [Receiver CRD docs](../components/notification/receiver.md) for more details.
+{{% alert color="info" title="Note" %}}
+Besides DockerHub, you can define receivers for **Harbor**, **Quay**, **Nexus**, **GCR**,
+and any other system that supports webhooks e.g. GitHub Actions, Jenkins, CircleCI, etc.
+See the [Receiver CRD docs](../components/notification/receiver.md) for more details.
+{{% /alert %}}
## Incident management
@@ -591,10 +606,11 @@
work in order to configure the ImageRepository resource credentials. Here are
some common examples for the most popular cloud provider docker registries.
-!!! warning "Workarounds"
- The examples below are intended as workaround solutions until native
- authentication mechanisms are implemented in Flux itself to support this in
- a more straightforward manner.
+{{% alert color="info" title="Workarounds" color="warning" %}}
+The examples below are intended as workaround solutions until native
+authentication mechanisms are implemented in Flux itself to support this in
+a more straightforward manner.
+{{% /alert %}}
### AWS Elastic Container Registry
@@ -707,16 +723,17 @@
--docker-password="$(</token/ecr-token)"
```
-!!! hint "Using IAM Roles for Service Accounts (IRSA)"
- If using IRSA, make sure the role attached to the service account has
- readonly access to ECR. The AWS managed policy
- `arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryReadOnly` can be attached
- to the role.
+{{% alert color="info" title="Using IAM Roles for Service Accounts (IRSA)" %}}
+If using IRSA, make sure the role attached to the service account has
+readonly access to ECR. The AWS managed policy
+`arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryReadOnly` can be attached
+to the role.
+{{% /alert %}}
Since the cronjob will not create a job right away, after applying the manifest,
you can manually create an init job using the following command:
-```console
+```sh
$ kubectl create job --from=cronjob/ecr-credentials-sync -n flux-system ecr-credentials-sync-init
```
@@ -734,11 +751,12 @@
#### Using access token [short-lived]
-!!! note "Workload Identity"
- Please ensure that you enable workload identity for your cluster, create a GCP service account that has
- access to the container registry and create an IAM policy binding between the GCP service account and
- the Kubernetes service account so that the pods created by the cronjob can access GCP APIs and get the token.
- Take a look at [this guide](https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity)
+{{% alert color="info" title="Workload Identity" %}}
+Please ensure that you enable workload identity for your cluster, create a GCP service account that has
+access to the container registry and create an IAM policy binding between the GCP service account and
+the Kubernetes service account so that the pods created by the cronjob can access GCP APIs and get the token.
+Take a look at [this guide](https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity)
+{{% /alert %}}
The access token for GCR expires hourly.
Considering this limitation, one needs to ensure the credentials are being
@@ -825,7 +843,7 @@
Since the cronjob will not create a job right away, after applying the manifest,
you can manually create an init job using the following command:
-```console
+```sh
$ kubectl create job --from=cronjob/gcr-credentials-sync -n flux-system gcr-credentials-sync-init
```
@@ -841,13 +859,14 @@
#### Using a JSON key [long-lived]
-!!! warning "Less secure option"
- From [Google documentation on authenticating container registry](https://cloud.google.com/container-registry/docs/advanced-authentication#json-key)
- > A user-managed key-pair that you can use as a credential for a service account.
- > Because the credential is long-lived, it is the least secure option of all the available authentication methods.
- > When possible, use an access token or another available authentication method to reduce the risk of
- > unauthorized access to your artifacts. If you must use a service account key,
- > ensure that you follow best practices for managing credentials.
+{{% alert color="info" title="Less secure option" color="warning" %}}
+From [Google documentation on authenticating container registry](https://cloud.google.com/container-registry/docs/advanced-authentication#json-key)
+> A user-managed key-pair that you can use as a credential for a service account.
+> Because the credential is long-lived, it is the least secure option of all the available authentication methods.
+> When possible, use an access token or another available authentication method to reduce the risk of
+> unauthorized access to your artifacts. If you must use a service account key,
+> ensure that you follow best practices for managing credentials.
+{{% /alert %}}
A Json key doesn't expire, so we don't need a cronjob,
we just need to create the secret and reference it in the ImagePolicy.
@@ -932,8 +951,9 @@
#### Using Static Credentials [long-lived]
-!!! info
- Using a static credential requires a Secrets management solution compatible with your GitOps workflow.
+{{% alert color="info" %}}
+Using a static credential requires a Secrets management solution compatible with your GitOps workflow.
+{{% /alert %}}
Follow the official Azure documentation for [Creating an Image Pull Secret for ACR](https://docs.microsoft.com/en-us/azure/container-registry/container-registry-auth-kubernetes).
@@ -945,5 +965,6 @@
It is also possible to create [Repository Scoped Tokens](https://docs.microsoft.com/en-us/azure/container-registry/container-registry-repository-scoped-permissions).
-!!! warning
- Repository Scoped Tokens are in preview and do have limitations.
+{{% alert color="info" %}}
+Note that this feature is in preview and does have limitations.
+{{% /alert %}}
diff -ruN docs/guides/_index.md /home/daniel/dev/website/content/en/docs/guides/_index.md
--- docs/guides/_index.md 1970-01-01 01:00:00.000000000 +0100
+++ /home/daniel/dev/website/content/en/docs/guides/_index.md 2021-04-23 15:19:36.082198586 +0200
@@ -0,0 +1,5 @@
+---
+title: "User Guides"
+linkTitle: "Guides"
+weight: 40
+---
diff -ruN docs/guides/installation.md /home/daniel/dev/website/content/en/docs/guides/installation.md
--- docs/guides/installation.md 2021-04-23 11:44:58.749345065 +0200
+++ /home/daniel/dev/website/content/en/docs/guides/installation.md 2021-04-23 15:19:36.082198586 +0200
@@ -1,4 +1,12 @@
-# Installation
+---
+title: "Installation"
+linkTitle: "Installation"
+weight: 10
+card:
+ name: tasks
+ weight: 10
+---
+
This guide walks you through setting up Flux v2 (hereafter: "Flux") to
manage one or more Kubernetes clusters.
@@ -47,6 +55,7 @@
Using the `flux bootstrap` command you can install Flux on a
Kubernetes cluster and configure it to manage itself from a Git
repository.
+
If the Flux components are present on the cluster, the bootstrap
command will perform an upgrade if needed. The bootstrap is
idempotent, it's safe to run the command as many times as you want.
@@ -84,10 +93,11 @@
`--private-key-file=<path/to/private.key>`.
This option can also be used if no SSH agent is available on your machine.
-!!! hint "Bootstrap options"
- There are many options available when bootstrapping Flux, such as installing a subset of Flux components,
- setting the Kubernetes context, changing the Git author name and email, enabling Git submodules, and more.
- To list all the available options run `flux bootstrap git --help`.
+{{% alert color="info" title="Bootstrap options" %}}
+There are many options available when bootstrapping Flux, such as installing a subset of Flux components,
+setting the Kubernetes context, changing the Git author name and email, enabling Git submodules, and more.
+To list all the available options run `flux bootstrap git --help`.
+{{% /alert %}}
If your Git server doesn't support SSH, you can run bootstrap for Git over HTTPS:
@@ -152,11 +162,12 @@
--personal
```
-!!! hint "Deploy key"
- The bootstrap command creates an SSH key which it stores as a secret in the
- Kubernetes cluster. The key is also used to create a deploy key in the GitHub
- repository. The new deploy key will be linked to the personal access token used
- to authenticate. **Removing the personal access token will also remove the deploy key.**
+{{% alert color="info" title="Deploy key" %}}
+The bootstrap command creates an SSH key which it stores as a secret in the
+Kubernetes cluster. The key is also used to create a deploy key in the GitHub
+repository. The new deploy key will be linked to the personal access token used
+to authenticate. **Removing the personal access token will also remove the deploy key.**
+{{% /alert %}}
Run the bootstrap for a repository owned by a GitHub organization:
@@ -234,10 +245,11 @@
--path=clusters/my-cluster
```
-!!! hint "Authentication"
- When providing the `--ssh-hostname`, a read-only (SSH) deploy key will be added
- to your repository, otherwise your GitLab personal token will be used to
- authenticate against the HTTPS endpoint instead.
+{{% alert color="info" title="Authentication" %}}
+When providing the `--ssh-hostname`, a read-only (SSH) deploy key will be added
+to your repository, otherwise your GitLab personal token will be used to
+authenticate against the HTTPS endpoint instead.
+{{% /alert %}}
Run the bootstrap for a repository owned by a GitLab (sub)group:
@@ -268,7 +280,7 @@
List all container images:
-```console
+```sh
$ flux install --export | grep ghcr.io
image: ghcr.io/fluxcd/helm-controller:v0.8.0
@@ -465,9 +477,10 @@
## Upgrade
-!!! note "Patch versions"
- It is safe and advised to use the latest PATCH version when upgrading to a
- new MINOR version.
+{{% alert color="info" title="Patch versions" %}}
+It is safe and advised to use the latest PATCH version when upgrading to a
+new MINOR version.
+{{% /alert %}}
Update Flux CLI to the latest release with `brew upgrade fluxcd/tap/flux` or by
downloading the binary from [GitHub](https://github.com/fluxcd/flux2/releases).
@@ -507,10 +520,11 @@
flux check
```
-!!! hint "Automated upgrades"
- You can automate the components manifest update with GitHub Actions
- and open a PR when there is a new Flux version available.
- For more details please see [Flux GitHub Action docs](https://github.com/fluxcd/flux2/tree/main/action).
+{{% alert color="info" title="Automated upgrades" %}}
+You can automate the components manifest update with GitHub Actions
+and open a PR when there is a new Flux version available.
+For more details please see [Flux GitHub Action docs](https://github.com/fluxcd/flux2/tree/main/action).
+{{% /alert %}}
### Terraform upgrade
@@ -565,6 +579,7 @@
flux uninstall --namespace=infra --keep-namespace
```
-!!! hint
- Note that the `uninstall` command will not remove any Kubernetes objects
- or Helm releases that were reconciled on the cluster by Flux.
+{{% alert color="info" %}}
+Note that the `uninstall` command will not remove any Kubernetes objects
+or Helm releases that were reconciled on the cluster by Flux.
+{{% /alert %}}
diff -ruN docs/guides/monitoring.md /home/daniel/dev/website/content/en/docs/guides/monitoring.md
--- docs/guides/monitoring.md 2021-03-01 11:28:47.064690928 +0100
+++ /home/daniel/dev/website/content/en/docs/guides/monitoring.md 2021-04-23 15:19:36.082198586 +0200
@@ -1,4 +1,12 @@
-# Monitoring
+---
+title: "Monitoring with Prometheus"
+linkTitle: "Monitoring with Prometheus"
+weight: 50
+card:
+ name: tasks
+ weight: 40
+---
+
This guide walks you through configuring monitoring for the Flux control plane.
@@ -41,20 +49,21 @@
Control plane dashboard [http://localhost:3000/d/gitops-toolkit-control-plane](http://localhost:3000/d/gitops-toolkit-control-plane/gitops-toolkit-control-plane):
-![](../_files/cp-dashboard-p1.png)
+![](/img/cp-dashboard-p1.png)
-![](../_files/cp-dashboard-p2.png)
+![](/img/cp-dashboard-p2.png)
Cluster reconciliation dashboard [http://localhost:3000/d/gitops-toolkit-cluster](http://localhost:3000/d/gitops-toolkit-cluster/gitops-toolkit-cluster-stats):
-![](../_files/cluster-dashboard.png)
+![](/img/cluster-dashboard.png)
If you wish to use your own Prometheus and Grafana instances, then you can import the dashboards from
[GitHub](https://github.com/fluxcd/flux2/tree/main/manifests/monitoring/grafana/dashboards).
-!!! hint
- Note that the toolkit controllers expose the `/metrics` endpoint on port `8080`.
- When using Prometheus Operator you should create a `PodMonitor` object for each controller to configure scraping.
+{{% alert color="info" %}}
+Note that the toolkit controllers expose the `/metrics` endpoint on port `8080`.
+When using Prometheus Operator you should create a `PodMonitor` object for each controller to configure scraping.
+{{% /alert %}}
```yaml
apiVersion: monitoring.coreos.com/v1
diff -ruN docs/guides/mozilla-sops.md /home/daniel/dev/website/content/en/docs/guides/mozilla-sops.md
--- docs/guides/mozilla-sops.md 2021-04-13 13:59:41.082084193 +0200
+++ /home/daniel/dev/website/content/en/docs/guides/mozilla-sops.md 2021-04-26 10:22:40.434994656 +0200
@@ -1,4 +1,9 @@
-# Manage Kubernetes secrets with Mozilla SOPS
+---
+title: "Manage Kubernetes secrets with Mozilla SOPS"
+linkTitle: "Mozilla SOPS"
+weight: 70
+---
+
In order to store secrets safely in a public or private Git repository, you can use
Mozilla's [SOPS](https://github.com/mozilla/sops) CLI to encrypt
@@ -118,10 +123,11 @@
gpg --import ./clusters/cluster0/.sops.pub.asc
```
-!!! hint
- The public key is sufficient for creating brand new files.
- The secret key is required for decrypting and editing existing files because SOPS computes a MAC on all values.
- When using solely the public key to add or remove a field, the whole file should be deleted and recreated.
+{{% alert color="info" %}}
+The public key is sufficient for creating brand new files.
+The secret key is required for decrypting and editing existing files because SOPS computes a MAC on all values.
+When using solely the public key to add or remove a field, the whole file should be deleted and recreated.
+{{% /alert %}}
## Configure the Git directory for encryption
@@ -146,9 +152,10 @@
`encrypted_regex` helps encrypt the `data` and `stringData` fields for Secrets.
You may wish to add other fields if you are encrypting other types of Objects.
-!!! hint
- Note that you should encrypt only the `data` or `stringData` section. Encrypting the Kubernetes
- secret metadata, kind or apiVersion is not supported by kustomize-controller.
+{{% alert color="info" title="Hint" %}}
+Note that you should encrypt only the `data` or `stringData` section. Encrypting the Kubernetes
+secret metadata, kind or apiVersion is not supported by kustomize-controller.
+{{% /alert %}}
## Encrypt secrets
@@ -170,9 +177,9 @@
You can now commit the encrypted secret to your Git repository.
-!!! hint
- Note that you shouldn't apply the encrypted secrets onto the cluster with kubectl.
- SOPS encrypted secrets are designed to be consumed by kustomize-controller.
+{{% alert color="info" title="Hint" %}}
+Note that you shouldn't apply the encrypted secrets onto the cluster with kubectl. SOPS encrypted secrets are designed to be consumed by kustomize-controller.
+{{% /alert %}}
### Using various cloud providers
@@ -182,7 +189,7 @@
keys to the `kustomize-controller` service account of the `flux-system` namespace for
kustomize-controller to be able to fetch keys from KMS.
-#### AWS
+#### AWS
Enabled the [IAM OIDC provider](https://eksctl.io/usage/iamserviceaccounts/) on your EKS cluster:
@@ -373,8 +380,9 @@
name: sops-gpg
```
-!!! hint
- You can generate the above manifests using `flux create <kind> --export > manifest.yaml`.
+{{% alert color="info" title="Hint" %}}
+You can generate the above manifests using `flux create <kind> --export > manifest.yaml`.
+{{% /alert %}}
Assuming a team member wants to deploy an application that needs to connect
to a database using a username and password, they'll be doing the following:
diff -ruN docs/guides/notifications.md /home/daniel/dev/website/content/en/docs/guides/notifications.md
--- docs/guides/notifications.md 2021-04-13 13:59:41.082084193 +0200
+++ /home/daniel/dev/website/content/en/docs/guides/notifications.md 2021-04-23 15:19:36.086198633 +0200
@@ -1,4 +1,12 @@
-# Setup Notifications
+---
+title: "Setup Notifications"
+linkTitle: "Setup Notifications"
+weight: 30
+card:
+ name: tasks
+ weight: 50
+---
+
When operating a cluster, different teams may wish to receive notifications about
the status of their GitOps pipelines.
@@ -77,7 +85,7 @@
To verify that the alert has been acknowledge by the notification controller do:
-```console
+```sh
$ kubectl -n flux-system get alerts
NAME READY STATUS AGE
@@ -92,7 +100,7 @@
This includes kustomize build and validation errors,
apply errors and health check failures.
-![error alert](../_files/slack-error-alert.png)
+![error alert](/img/slack-error-alert.png)
When the verbosity is set to `info`, the controller will alert if:
@@ -101,7 +109,7 @@
* a dependency is delaying the execution
* an error occurs
-![info alert](../_files/slack-info-alert.png)
+![info alert](/img/slack-info-alert.png)
## Git commit status
@@ -116,7 +124,7 @@
In GitHub the commit status set by notification-controller will result in a green checkmark or red cross next to the commit hash.
Clicking the icon will show more detailed information about the status.
-![commit status GitHub overview](../_files/commit-status-github-overview.png)
+![commit status GitHub overview](/img/commit-status-github-overview.png)
Receiving an event in the form of a commit status rather than a message in a chat conversation has the benefit
that it closes the deployment loop giving quick and visible feedback if a commit has reconciled and if it succeeded.
@@ -130,12 +138,13 @@
to reconcile the new commit. After this is done the kustomize-controller sends an event to the notification-controller
with the result and the commit hash it reconciled. Then notification-controller can update the correct commit and repository
when receiving the event.
-![commit status flow](../_files/commit-status-flow.png)
+![commit status flow](/img/commit-status-flow.png)
-!!! hint "Limitations"
- The git notification providers require that a commit hash present in the meta data
- of the event. There for the the providers will only work with `Kustomization` as an
- event source, as it is the only resource which includes this data.
+{{% alert color="info" title="Limitations" %}}
+The git notification providers require that a commit hash present in the meta data
+of the event. There for the the providers will only work with `Kustomization` as an
+event source, as it is the only resource which includes this data.
+{{% /alert %}}
First follow the [get started guide](../../get-started) if you do not have a Kubernetes cluster with Flux installed in it.
You will need a authentication token to communicate with the API. The authentication method depends on
@@ -248,7 +257,7 @@
| GitHub | GitLab |
| ------------- | ------------- |
-| ![commit status GitHub successful](../_files/commit-status-github-success.png) | ![commit status GitLab successful](../_files/commit-status-gitlab-success.png) |
+| ![commit status GitHub successful](/img/commit-status-github-success.png) | ![commit status GitLab successful](/img/commit-status-gitlab-success.png) |
Generate error
@@ -273,7 +282,7 @@
| GitHub | GitLab |
| ------------- | ------------- |
-| ![commit status GitHub failure](../_files/commit-status-github-failure.png) | ![commit status GitLab failure](../_files/commit-status-gitlab-failure.png) |
+| ![commit status GitHub failure](/img/commit-status-github-failure.png) | ![commit status GitLab failure](/img/commit-status-gitlab-failure.png) |
### Status changes
diff -ruN docs/guides/sealed-secrets.md /home/daniel/dev/website/content/en/docs/guides/sealed-secrets.md
--- docs/guides/sealed-secrets.md 2021-04-23 11:44:58.749345065 +0200
+++ /home/daniel/dev/website/content/en/docs/guides/sealed-secrets.md 2021-04-23 15:19:36.086198633 +0200
@@ -1,4 +1,9 @@
-# Sealed Secrets
+---
+title: "Sealed Secrets"
+linkTitle: "Sealed Secrets"
+weight: 60
+---
+
In order to store secrets safely in a public or private Git repository, you can use
Bitnami's [sealed-secrets controller](https://github.com/bitnami-labs/sealed-secrets)
@@ -102,7 +107,7 @@
Verify that the sealed-secrets controller has created the `basic-auth` Kubernetes Secret:
-```console
+```sh
$ kubectl -n default get secrets basic-auth
NAME TYPE DATA AGE
@@ -152,8 +157,9 @@
crds: CreateReplace
```
-!!! hint
- You can generate the above manifests using `flux create <kind> --export > manifest.yaml`.
+{{% alert color="info" %}}
+You can generate the above manifests using `flux create <kind> --export > manifest.yaml`.
+{{% /alert %}}
Once the sealed-secrets controller is installed, the admin fetches the
public key and shares it with the teams that operate on the fleet clusters via Git.
diff -ruN docs/guides/sortable-image-tags.md /home/daniel/dev/website/content/en/docs/guides/sortable-image-tags.md
--- docs/guides/sortable-image-tags.md 2021-04-23 11:44:58.749345065 +0200
+++ /home/daniel/dev/website/content/en/docs/guides/sortable-image-tags.md 2021-04-23 15:19:36.086198633 +0200
@@ -1,5 +1,9 @@
-<!-- -*- fill-column: 100 -*- -->
-# How to make sortable image tags to use with automation
+---
+title: "How to make sortable image tags to use with automation"
+linkTitle: "Sortable image tags to use with automation"
+weight: 90
+---
+
Flux v2 does not support selecting the lastest image by build time. Obtaining the build time needs
the container config for each image, and fetching that is subject to strict rate limiting by image
diff -ruN docs/guides/webhook-receivers.md /home/daniel/dev/website/content/en/docs/guides/webhook-receivers.md
--- docs/guides/webhook-receivers.md 2020-11-04 15:29:45.087588507 +0100
+++ /home/daniel/dev/website/content/en/docs/guides/webhook-receivers.md 2021-04-23 15:19:36.086198633 +0200
@@ -1,4 +1,9 @@
-# Setup Webhook Receivers
+---
+title: "Setup Webhook Receivers"
+linkTitle: "Setup Webhook Receivers"
+weight: 40
+---
+
The GitOps toolkit controllers are by design **pull-based**.
In order to notify the controllers about changes in Git or Helm repositories,
@@ -70,9 +75,10 @@
branch: master
```
-!!! hint "Authentication"
- SSH or token based authentication can be configured for private repositories.
- See the [GitRepository CRD docs](../components/source/gitrepositories.md) for more details.
+{{% alert color="info" title="Authentication" %}}
+SSH or token based authentication can be configured for private repositories.
+See the [GitRepository CRD docs](../components/source/gitrepositories.md) for more details.
+{{% /alert %}}
## Define a Git repository receiver
@@ -106,16 +112,17 @@
name: webapp
```
-!!! hint "Note"
- Besides GitHub, you can define receivers for **GitLab**, **Bitbucket**, **Harbor**
- and any other system that supports webhooks e.g. Jenkins, CircleCI, etc.
- See the [Receiver CRD docs](../components/notification/receiver.md) for more details.
+{{% alert color="info" title="Note" %}}
+Besides GitHub, you can define receivers for **GitLab**, **Bitbucket**, **Harbor**
+and any other system that supports webhooks e.g. Jenkins, CircleCI, etc.
+See the [Receiver CRD docs](../components/notification/receiver.md) for more details.
+{{% /alert %}}
The notification controller generates a unique URL using the provided token and the receiver name/namespace.
Find the URL with:
-```console
+```sh
$ kubectl -n flux-system get receiver/webapp
NAME READY STATUS
diff -ruN docs/_index.md /home/daniel/dev/website/content/en/docs/_index.md
--- docs/_index.md 1970-01-01 01:00:00.000000000 +0100
+++ /home/daniel/dev/website/content/en/docs/_index.md 2021-04-23 15:19:36.082198586 +0200
@@ -0,0 +1,40 @@
+---
+title: "Flux Documentation"
+linkTitle: "Docs"
+weight: 0
+menu:
+ main:
+ weight: 10
+description: >
+ Flux v2 Documentation.
+layout: docsportal_home
+cards:
+- name: concepts
+ title: "Understand the basics"
+ description: "Learn about Flux and its fundamental concepts."
+ button: "Learn Concepts"
+ button_path: "/docs/concepts"
+- name: get started
+ title: "Try Flux"
+ description: "Follow our guide to getting started with Flux."
+ button: "View Guide"
+ button_path: "/docs/get-started"
+- name: tasks
+ title: "Learn how to use Flux"
+ description: "Look up common tasks and how to perform them using a short sequence of steps."
+ button: "View Tasks"
+ button_path: "/docs/guides"
+- name: migration
+ title: "Understand Migration Paths"
+ description: "Something migration"
+ button: "View Migration"
+ button_path: "/docs/migration"
+- name: contribute
+ title: Contribute to Flux
+ description: Anyone can contribute, whether you're new to the project or you've been around a long time.
+ button: Contribute to the docs
+ button_path: /docs/contribute
+- name: about
+ title: About the documentation
+ description: This website contains documentation for the current version of Flux.
+---
diff -ruN docs/index.md /home/daniel/dev/website/content/en/docs/index.md
--- docs/index.md 2021-03-23 14:03:54.216170746 +0100
+++ /home/daniel/dev/website/content/en/docs/index.md 1970-01-01 01:00:00.000000000 +0100
@@ -1,101 +0,0 @@
-# Flux v2
-
-Flux is a tool for keeping Kubernetes clusters in sync with sources of
-configuration (like Git repositories), and automating updates to
-configuration when there is new code to deploy.
-
-Flux version 2 ("Flux v2") is built from the ground up to use Kubernetes'
-API extension system, and to integrate with Prometheus and other core
-components of the Kubernetes ecosystem. In version 2, Flux supports
-multi-tenancy and support for syncing an arbitrary number of Git
-repositories, among other long-requested features.
-
-Flux v2 is constructed with the [GitOps Toolkit](components/index.md),
-a set of composable APIs and specialized tools for building Continuous
-Delivery on top of Kubernetes.
-
-## Who is Flux for?
-
-Flux helps
-
-- **cluster operators** who automate provision and configuration of clusters;
-- **platform engineers** who build continuous delivery for developer teams;
-- **app developers** who rely on continuous delivery to get their code live.
-
-The [GitOps Toolkit](components/index.md) is for **platform
-engineers** who want to make their own continuous delivery system, and
-have requirements not covered by Flux.
-
-## What can I do with Flux?
-
-Flux is based on a set of Kubernetes API extensions ("custom
-resources"), which control how git repositories and other sources of
-configuration are applied into the cluster ("synced").
-For example, you create a `GitRepository` object to mirror
-configuration from a Git repository, then a `Kustomization` object to
-sync that configuration.
-
-Flux works with Kubernetes' role-based access control (RBAC), so you
-can lock down what any particular sync can change. It can send
-notifications to Slack and other like systems when configuration is
-synced and ready, and receive webhooks to tell it when to sync.
-
-The `flux` command-line tool is a convenient way to bootstrap the
-system in a cluster, and to access the custom resources that make up
-the API.
-
-![overview](_files/gitops-toolkit.png)
-
-## Where do I start?
-
-!!! hint "Get started with Flux v2!"
- Following this [guide](get-started/index.md) will just take a couple of minutes to complete:
- After installing the `flux` CLI and running a couple of very simple commands,
- you will have a GitOps workflow setup which involves a staging and a production cluster.
-
-If you should need help, please refer to our **[Support page](https://fluxcd.io/support/)**.
-
-## More detail on what's in Flux
-
-Features:
-
-- Source configuration from Git and Helm repositories, and
- S3-compatible buckets (e.g., Minio)
-- Kustomize and Helm support
-- Event-triggered and periodic reconciliation
-- Integration with Kubernetes RBAC
-- Health assessment (clusters and workloads)
-- Dependency management (infrastructure and workloads)
-- Alerting to external systems (webhook senders)
-- External events handling (webhook receivers)
-- Automated container image updates to Git (image scanning and patching)
-- Policy-driven validation (OPA, Kyverno, admission controllers)
-- Seamless integration with Git providers (GitHub, GitLab, Bitbucket)
-- Interoperability with workflow providers (GitHub Actions, Tekton, Argo)
-- Interoperability with Cluster API (CAPI) providers
-
-## Community
-
-Need help or want to contribute? Please see the links below. The Flux project is always looking for
-new contributors and there are a multitude of ways to get involved.
-
-- Getting Started?
- - Look at our [Get Started guide](https://toolkit.fluxcd.io/get-started/) and give us feedback
-- Need help?
- - First: Ask questions on our [GH Discussions page](https://github.com/fluxcd/flux2/discussions)
- - Second: Talk to us in the #flux channel on [CNCF Slack](https://slack.cncf.io/)
- - Please follow our [Support Guidelines](https://fluxcd.io/support/)
- (in short: be nice, be respectful of volunteers' time, understand that maintainers and
- contributors cannot respond to all DMs, and keep discussions in the public #flux channel as much as possible).
-- Have feature proposals or want to contribute?
- - Propose features on our [GH Discussions page](https://github.com/fluxcd/flux2/discussions)
- - Join our upcoming dev meetings ([meeting access and agenda](https://docs.google.com/document/d/1l_M0om0qUEN_NNiGgpqJ2tvsF2iioHkaARDeh6b70B0/view))
- - [Join the flux-dev mailing list](https://lists.cncf.io/g/cncf-flux-dev).
- - Check out [how to contribute](contributing/index.md) to the project
-
-### Events
-
-Check out our **[events calendar](https://fluxcd.io/community/#talks)**,
-both with upcoming talks you can attend or past events videos you can watch.
-
-We look forward to seeing you with us!
diff -ruN docs/internal/release.md /home/daniel/dev/website/content/en/docs/internal/release.md
--- docs/internal/release.md 2021-03-23 14:03:54.216170746 +0100
+++ /home/daniel/dev/website/content/en/docs/internal/release.md 1970-01-01 01:00:00.000000000 +0100
@@ -1,139 +0,0 @@
-# Flux release procedure
-
-The Flux Go modules and the GitOps Toolkit controllers are released by following the [semver](https://semver.org) conventions.
-
-Repositories subject to semver releases:
-
-1. [fluxcd/pkg](https://github.com/fluxcd/pkg)
- - modules: `apis/meta`, `runtime`, various utilities
- - dependencies: `k8s.io/*`, `sigs.k8s.io/controller-runtime`
-1. [fluxcd/source-controller](https://github.com/fluxcd/source-controller)
- - modules: `api`
- - dependencies: `github.com/fluxcd/pkg/*`
-1. [fluxcd/kustomize-controller](https://github.com/fluxcd/kustomize-controller)
- - modules: `api`
- - dependencies: `github.com/fluxcd/source-controller/api`, `github.com/fluxcd/pkg/*`
-1. [fluxcd/helm-controller](https://github.com/fluxcd/helm-controller)
- - modules: `api`
- - dependencies: `github.com/fluxcd/source-controller/api`, `github.com/fluxcd/pkg/*`
-1. [fluxcd/image-reflector-controller](https://github.com/fluxcd/image-reflector-controller)
- - modules: `api`
- - dependencies: `github.com/fluxcd/pkg/*`
-1. [fluxcd/image-automation-controller](https://github.com/fluxcd/image-automation-controller)
- - modules: `api`
- - dependencies: `github.com/fluxcd/source-controller/api`, `github.com/fluxcd/image-reflector-controller/api`, `github.com/fluxcd/pkg/*`
-1. [fluxcd/notification-controller](https://github.com/fluxcd/notification-controller)
- - modules: `api`
- - dependencies: `github.com/fluxcd/pkg/*`
-1. [fluxcd/flux2](https://github.com/fluxcd/flux2)
- - modules: `manifestgen`
- - dependencies: `github.com/fluxcd/source-controller/api`, `github.com/fluxcd/kustomize-controller/api`, `github.com/fluxcd/helm-controller/api`, `github.com/fluxcd/image-reflector-controller/api`, `github.com/fluxcd/image-automation-controller/api`, `github.com/fluxcd/notification-controller/api`, `github.com/fluxcd/pkg/*`
-1. [fluxcd/terraform-provider-flux](https://github.com/fluxcd/terraform-provider-flux)
- - dependencies: `github.com/fluxcd/flux2/pkg/manifestgen`
-
-## Release procedure
-
-### Go packages
-
-The Go packages in [fluxcd/pkg](https://github.com/fluxcd/pkg) are dedicated modules,
-each module has its own set of dependencies and release cycle.
-
-Release procedure for a package:
-
-1. Checkout the `main` branch and pull changes from remote.
-1. Run `make release-<package name> VER=<next semver>`.
-
-### Controllers
-
-A toolkit controller has a dedicated module for its API, the API module
-has its own set of dependencies.
-
-Release procedure for a controller and its API:
-
-1. Checkout the `main` branch and pull changes from remote.
-1. Create a `api/<next semver>` tag and push it to remote.
-1. Create a new branch from `main` i.e. `release-<next semver>`. This
- will function as your release preparation branch.
-1. Update the `github.com/fluxcd/<NAME>-controller/api` version in `go.mod`
-1. Add an entry to the `CHANGELOG.md` for the new release and change the
- `newTag` value in ` config/manager/kustomization.yaml` to that of the
- semver release you are going to make. Commit and push your changes.
-1. Create a PR for your release branch and get it merged into `main`.
-1. Create a `<next semver>` tag for the merge commit in `main` and
- push it to remote.
-1. Confirm CI builds and releases the newly tagged version.
-
-### Flux
-
-Release procedure for Flux:
-
-1. Checkout the `main` branch and pull changes from remote.
-1. Create a `<next semver>` tag form `main` and push it to remote.
-1. Confirm CI builds and releases the newly tagged version.
-
-## Upgrade Kubernetes modules
-
-Flux has the following Kubernetes dependencies:
-
-- `k8s.io/api`
-- `k8s.io/apiextensions-apiserver`
-- `k8s.io/apimachinery`
-- `k8s.io/cli-runtime`
-- `k8s.io/client-go`
-- `sigs.k8s.io/controller-runtime`
-
-**Note** that all `k8s.io/*` packages must the have the same version in `go.mod` e.g.:
-
-```
- k8s.io/api v0.20.2
- k8s.io/apiextensions-apiserver v0.20.2
- k8s.io/apimachinery v0.20.2
- k8s.io/cli-runtime v0.20.2
- k8s.io/client-go v0.20.2
-```
-
-The specialised reconcilers depend on:
-
-- kustomize-controller: `sigs.k8s.io/kustomize/api`
-- image-automation-controller: `sigs.k8s.io/kustomize/kyaml`
-- helm-controller: `helm.sh/helm/v3`
-
-**Note** that the `k8s.io/*` version must be compatible with both `kustomize/api` and `helm/v3`.
-If there is a breaking change in `client-go` we have to wait for Kustomize and Helm to upgrade first.
-
-Upgrade procedure:
-
-`fluxcd/pkg`:
-
-1. Update the `k8s.io/*` version in `pkg/apis/meta/go.mod`
-1. Release the `apis/meta` package
-1. Update `apis/meta` version in `pkg/runtime/go.mod`
-1. Update the `k8s.io/*` version in `pkg/runtime/go.mod`
-1. Update `sigs.k8s.io/controller-runtime` version in `pkg/runtime/go.mod`
-1. Release the `runtime` package
-
-`fluxcd/source-controller`:
-
-1. Update the `github.com/fluxcd/pkg/apis/meta` version in `source-controller/api/go.mod` and `source-controller/go.mod`
-1. Update the `k8s.io/*` version in `source-controller/api/go.mod` and `source-controller/go.mod`
-1. Update the `sigs.k8s.io/controller-runtime` version in `source-controller/api/go.mod` and `source-controller/go.mod`
-1. Update the `github.com/fluxcd/pkg/runtime` version in `source-controller/go.mod`
-1. Release the `api` package
-
-`fluxcd/<kustomize|helm|notification|image-automation>-controller`:
-
-1. Update the `github.com/fluxcd/source-controller/api` version in `controller/api/go.mod` and `controller/go.mod`
-1. Update the `github.com/fluxcd/pkg/apis/meta` version in `controller/api/go.mod` and `controller/go.mod`
-1. Update the `k8s.io/*` version in `controller/api/go.mod` and `controller/go.mod`
-1. Update the `github.com/fluxcd/pkg/runtime` version in `controller/go.mod`
-1. Release the `api` package
-
-`fluxcd/flux2`:
-
-1. Update the `github.com/fluxcd/*-controller/api` version in `flux2/go.mod` (automated with [GitHub Actions](../../.github/workflows/update.yaml))
-1. Update the `github.com/fluxcd/pkg/*` version in `flux2/go.mod`
-1. Update the `k8s.io/*` and `github.com/fluxcd/pkg/runtime` version in `flux2/go.mod`
-
-`fluxcd/terraform-provider-flux`:
-
-1. Update the `github.com/fluxcd/flux2` version in `terraform-provider-flux/go.mod` (automated with [GitHub Actions](https://github.com/fluxcd/terraform-provider-flux/blob/main/.github/workflows/update.yaml))
diff -ruN docs/README.md /home/daniel/dev/website/content/en/docs/README.md
--- docs/README.md 2021-04-27 15:32:27.481285692 +0200
+++ /home/daniel/dev/website/content/en/docs/README.md 1970-01-01 01:00:00.000000000 +0100
@@ -1,17 +0,0 @@
-# Flux v2 Documentation
-
-The documentation for `flux2` has moved to this repository: <https://github.com/fluxcd/website>.
-
-[The Website's README](https://github.com/fluxcd/website/#readme) has information on how to
-
-- modify and extend documentation
-- run the site <https://fluxcd.io> locally
-- publish changes
-
-and where all the individual pieces of content come from.
-
-It will be easier for us to maintain a coherent web presences (and merge all of Flux documentation) in one central repository. This was partly discussed in <https://github.com/fluxcd/flux2/discussions/367>.
-
-## toolkit.fluxcd.io
-
-For historical reasons we are keeping a `_redirects` file in this directory. It defines how redirects from the old site `toolkit.fluxcd.io` to our new website <https://fluxcd.io> work. Changes to this file need to be merged and a manual build triggered in the Netlify App.
diff -ruN docs/_redirects /home/daniel/dev/website/content/en/docs/_redirects
--- docs/_redirects 2021-04-27 15:32:27.481285692 +0200
+++ /home/daniel/dev/website/content/en/docs/_redirects 1970-01-01 01:00:00.000000000 +0100
@@ -1,18 +0,0 @@
-# individual rules
-/core-concepts https://fluxcd.io/docs/concepts 301!
-/contributing https://fluxcd.io/contributing 301!
-/install.sh https://fluxcd.io/install.sh 301!
-
-# refer to https://github.com/fluxcd/flux2/discussions/367
-/dev-guides/* https://fluxcd.io/docs/gitops-toolkit/:splat 301!
-
-
-# this is how things looked in the navbar anyway..?
-/guides/faq-migration https://fluxcd.io/docs/migration/faq-migration 301!
-/guides/flux-v1-automation-migration https://fluxcd.io/docs/migration/flux-v1-automation-migration 301!
-/guides/flux-v1-migration https://fluxcd.io/docs/migration/flux-v1-migration 301!
-/guides/helm-operator-migration https://fluxcd.io/docs/migration/helm-operator-migration 301!
-
-
-# catch all
-/* https://fluxcd.io/docs/:splat 301!
diff -u ~/dev/flux2/docs/roadmap/index.md content/en/docs/roadmap/_index.md
--- /home/daniel/dev/flux2/docs/roadmap/index.md 2021-03-17 12:23:17.425045780 +0100
+++ content/en/docs/roadmap/_index.md 2021-04-23 15:19:36.086198633 +0200
@@ -1,10 +1,17 @@
-# Roadmap
-
-!!! hint "Production readiness"
- The Flux custom resource definitions which are at `v1beta1` and `v2beta1`
- and their controllers are considered stable and production ready.
- Going forward, breaking changes to the beta CRDs will be accompanied by a conversion mechanism.
- Please see the [Migration and Suport Timetable](../migration/timetable.md) for our commitment to end users.
+---
+title: "Roadmap"
+linkTitle: "Roadmap"
+weight: 90
+description: >
+ Roadmap for Flux v2
+---
+
+{{% alert color="info" title="Production readiness" %}}
+The Flux custom resource definitions which are at `v1beta1` and `v2beta1`
+and their controllers are considered stable and production ready.
+Going forward, breaking changes to the beta CRDs will be accompanied by a conversion mechanism.
+Please see the [Migration and Suport Timetable](../migration/timetable.md) for our commitment to end users.
+{{% /alert %}}
The following components (included by default in [flux bootstrap](../guides/installation.md#bootstrap))
are considered production ready:
@@ -47,8 +54,6 @@
### Flux read-only feature parity
-[= 100% "100%"]
-
Flux v2 read-only is ready to try. See the [Getting
Started](https://toolkit.fluxcd.io/get-started/) how-to, and the
[Migration
@@ -60,9 +65,11 @@
Goals
-- <span class="check-bullet">:material-check-bold:</span> [Offer a migration guide for those that are using Flux in read-only mode to synchronize plain manifests](https://toolkit.fluxcd.io/guides/flux-v1-migration/)
-- <span class="check-bullet">:material-check-bold:</span> [Offer a migration guide for those that are using Flux in read-only mode to synchronize Kustomize overlays](https://toolkit.fluxcd.io/guides/flux-v1-migration/)
-- <span class="check-bullet">:material-check-bold:</span> [Offer a dedicated component for forwarding events to external messaging platforms](https://toolkit.fluxcd.io/guides/notifications/)
+State | Item
+----- | ----
+:heavy_check_mark: | [Offer a migration guide for those that are using Flux in read-only mode to synchronize plain manifests](https://toolkit.fluxcd.io/guides/flux-v1-migration/)
+:heavy_check_mark: | [Offer a migration guide for those that are using Flux in read-only mode to synchronize Kustomize overlays](https://toolkit.fluxcd.io/guides/flux-v1-migration/)
+:heavy_check_mark: | [Offer a dedicated component for forwarding events to external messaging platforms](https://toolkit.fluxcd.io/guides/notifications/)
Non-Goals
@@ -84,8 +91,6 @@
### Flux image update feature parity
-[= 100% "100%"]
-
Image automation is available as a prerelease. See [this
guide](https://toolkit.fluxcd.io/guides/image-update/) for how to
install and use it.
@@ -114,8 +119,6 @@
### Helm v3 feature parity
-[= 100% "100%"]
-
Helm support in Flux v2 is ready to try. See the [Helm controller
guide](https://toolkit.fluxcd.io/guides/helmreleases/), and the [Helm
controller migration
@@ -145,4 +148,4 @@
- [x] <span style="color:grey">Implement support for Helm charts from Git</span>
- [x] <span style="color:grey">Implement support for referring to an alternative chart values file</span>
- [x] <span style="color:grey">Stabilize API</span>
-- [x] <span style="color:grey">[Create a migration guide for Helm Operator users](../guides/helm-operator-migration.md)</span>
+- [x] <span style="color:grey">[Create a migration guide for Helm Operator users](../migration/helm-operator-migration.md)</span>
diff -ruN docs/use-cases/azure.md /home/daniel/dev/website/content/en/docs/use-cases/azure.md
--- docs/use-cases/azure.md 2021-04-23 11:44:58.749345065 +0200
+++ /home/daniel/dev/website/content/en/docs/use-cases/azure.md 2021-04-26 10:22:40.434994656 +0200
@@ -1,4 +1,7 @@
-# Using Flux on Azure
+---
+title: Using Flux on Azure
+linkTitle: Azure
+---
## AKS Cluster Options
@@ -13,8 +16,9 @@
Using `--network-plugin=azure --network-policy=calico` has been tested to work properly.
This issue only affects you if you are using `--network-policy` on AKS, which is not a default option.
-!!! warning
- AKS `--network-policy` is currently in Preview
+{{% alert color="warning" %}}
+AKS `--network-policy` is currently in Preview
+{{% /alert %}}
### AAD Pod-Identity
@@ -32,10 +36,11 @@
Use Flux's `HelmRepository` and `HelmRelease` object to manage the aad-pod-identity installation
from a bootstrap repository and keep it up to date.
-!!! note
- As an alternative to Helm, the `--enable-aad-pod-identity` flag for the `az aks create` is currently in Preview.
- Follow the Azure guide for [Creating an AKS cluster with AAD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity)
- if you would like to enable this feature with the Azure CLI.
+{{% alert %}}
+As an alternative to Helm, the `--enable-aad-pod-identity` flag for the `az aks create` is currently in Preview.
+Follow the Azure guide for [Creating an AKS cluster with AAD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity)
+if you would like to enable this feature with the Azure CLI.
+{{% /alert %}}
### Cluster Creation
@@ -50,9 +55,10 @@
--name="my-cluster"
```
-!!! info
- When working with the Azure CLI, it can help to set a default `location`, `group`, and `acr`.
- See `az configure --help`, `az configure --list-defaults`, and `az configure --defaults key=value`.
+{{% alert color="info" %}}
+When working with the Azure CLI, it can help to set a default `location`, `group`, and `acr`.
+See `az configure --help`, `az configure --list-defaults`, and `az configure --defaults key=value`
+{{% /alert %}}
## Flux Installation for Azure DevOps
@@ -118,11 +124,12 @@
Using a machine-user also has the benefit of being able to be read-only or
restricted to specific repositories if this is needed.
-!!! note
- Unlike `git`, Flux does not support the
- ["shorter" scp-like syntax for the SSH protocol](https://git-scm.com/book/en/v2/Git-on-the-Server-The-Protocols#_the_ssh_protocol)
- (e.g. `ssh.dev.azure.com:v3`).
- Use the [RFC 3986 compatible syntax](https://tools.ietf.org/html/rfc3986#section-3) instead: `ssh.dev.azure.com/v3`.
+{{% alert color="info" %}}
+Unlike `git`, Flux does not support the ["shorter" scp-like syntax for the SSH
+protocol](https://git-scm.com/book/en/v2/Git-on-the-Server-The-Protocols#_the_ssh_protocol)
+(e.g. `ssh.dev.azure.com:v3`).
+Use the [RFC 3986 compatible syntax](https://tools.ietf.org/html/rfc3986#section-3) instead: `ssh.dev.azure.com/v3`.
+{{% /alert %}}
If you wish to use Git over HTTPS, then generate a personal access token and supply it as the password:
@@ -219,6 +226,7 @@
If you want to use Managed Identities, install or enable [AAD Pod Identity](#aad-pod-identity).
You may need to update your Flux install to include additional components:
+
```sh
flux install \
--components-extra="image-reflector-controller,image-automation-controller" \
diff -ruN docs/use-cases/gh-actions-manifest-generation.md /home/daniel/dev/website/content/en/docs/use-cases/gh-actions-manifest-generation.md
--- docs/use-cases/gh-actions-manifest-generation.md 2021-04-23 11:44:58.753344929 +0200
+++ /home/daniel/dev/website/content/en/docs/use-cases/gh-actions-manifest-generation.md 2021-04-27 14:56:07.542430928 +0200
@@ -1,4 +1,7 @@
-# GitHub Actions Manifest Generation
+---
+title: GitHub Actions Manifest Generation
+linkTitle: GitHub Actions Manifest Generation
+---
This example implements "build-time" manifest generation on GitHub Actions.
@@ -71,8 +74,9 @@
The entry point for these examples begins at `.github/workflows/` in any GitHub source repository where your YAML manifests are stored.
-!!! warning "`GitRepository` source only targets one branch"
- While this first example operates on any branch (`branches: ['*']`), each `Kustomization` in Flux only deploys manifests from **one branch or tag** at a time. Understanding this is key for managing large Flux deployments and clusters with multiple `Kustomizations` and/or crossing several environments.
+{{% alert color="warning" title="GitRepository source only targets one branch" %}}
+While this first example operates on any branch (`branches: ['*']`), each `Kustomization` in Flux only deploys manifests from **one branch or tag** at a time. Understanding this is key for managing large Flux deployments and clusters with multiple `Kustomizations` and/or crossing several environments.
+{{% /alert %}}
First add this directory if needed in your repositories. Find the example below in context, and read on to understand how it works: [01-manifest-generate.yaml].
@@ -119,8 +123,9 @@
echo ::set-output name=VERSION::${VERSION}
```
-!!! note "When migrating to Flux v2"
- Users will find that [some guidance has changed since Flux v1]. Tagging images with a `GIT_SHA` was a common practice that is no longer supported by Flux's Image Automation. A newer alternative is adding timestamp or build number in [Sortable image tags], preferred by the `image-automation-controller`.
+{{% alert title="When migrating to Flux v2" %}}
+Users will find that [some guidance has changed since Flux v1](https://github.com/fluxcd/flux2/discussions/802#discussioncomment-320189). Tagging images with a `GIT_SHA` was a common practice that is no longer supported by Flux's Image Automation. A newer alternative is adding timestamp or build number in [Sortable image tags]({{< relref "../guides/sortable-image-tags/" >}}), preferred by the `image-automation-controller`.
+{{% /alert %}}
Next we call out to a shell script `update-k8s.sh` taking one argument, the Git SHA value from GitHub:
@@ -263,8 +268,9 @@
From the Actions marketplace, [Build and push Docker images] provides the heavy lifting in this example. Flux has nothing to do with building images, but we include this still — as some images will need to be built for our use in these examples.
-!!! hint "`ImageRepository` can reflect both branches and tags"
- This example builds an image for any branch or tag ref and pushes it to Docker Hub. (Note the omission of `branches: ['*']` that was in the prior example.) GitHub Secrets `DOCKERHUB_USERNAME` and `DOCKERHUB_TOKEN` are used here to authenticate with Docker Hub from within GitHub Actions.
+{{% alert title="ImageRepository can reflect both branches and tags" %}}
+This example builds an image for any branch or tag ref and pushes it to Docker Hub. (Note the omission of `branches: ['*']` that was in the prior example.) GitHub Secrets `DOCKERHUB_USERNAME` and `DOCKERHUB_TOKEN` are used here to authenticate with Docker Hub from within GitHub Actions.
+{{% /alert %}}
We again borrow a [Prepare step] from Kustomize Controller's own release workflow. Find the example below in context, [02-docker-build.yaml], or copy it from below.
@@ -340,8 +346,9 @@
It is recommended to follow these examples as they are written for better understanding, then later change and adapt them for your own release practices and environments.
-!!! note "`GitRepository` source only targets one branch"
- Since Flux uses one branch per Kustomization, to trigger an update we must write to a `deploy` branch or tag. Even when new app images can come from any branch (eg. for Dev environments where any latest commit is to be deployed) the YAML manifests to deploy will be sourced from just one branch.
+{{% alert title="GitRepository source only targets one branch" %}}
+Since Flux uses one branch per Kustomization, to trigger an update we must write to a `deploy` branch or tag. Even when new app images can come from any branch (eg. for Dev environments where any latest commit is to be deployed) the YAML manifests to deploy will be sourced from just one branch.
+{{% /alert %}}
It is advisable to protect repository main and release branches with eg. branch policies and review requirements, as through automation, these branches can directly represent the production environment.
@@ -433,8 +440,9 @@
The `jsonnet-render` step is borrowed from another source, again find it on [GitHub Actions Marketplace][actions/jsonnet-render] for more information. For Tanka users, there is also [letsbuilders/tanka-action] which describes itself as heavily inspired by `jsonnet-render`.
-!!! note "The `EndBug/add-and-commit` action is used again"
- This time, with the help of `rake.sh`, our change is staged into a different target branch. This is the same `deploy` branch, regardless of which branch or tag the build comes from; any configured push event can trigger this workflow to trigger an update to the deploy branch.
+{{% alert title="The EndBug/add-and-commit action is used again" %}}
+This time, with the help of `rake.sh`, our change is staged into a different target branch. This is the same `deploy` branch, regardless of which branch or tag the build comes from; any configured push event can trigger this workflow to trigger an update to the deploy branch.
+{{% /alert %}}
```bash
#!/bin/bash
@@ -1256,7 +1264,7 @@
[example 10.2 jsonnet]: https://github.com/kingdonb/any_old_app/blob/release/0.10.2/manifests/example.jsonnet
[examples 0.10.2-all]: https://github.com/kingdonb/any_old_app/releases?after=0.10.2-alpha5
[example 10.2 configmap]: https://github.com/kingdonb/any_old_app/blob/release/0.10.2/manifests/examples/configMap.yaml
-[anguslees/kustomize-libsonnet]: (https://github.com/anguslees/kustomize-libsonnet)
+[anguslees/kustomize-libsonnet]: https://github.com/anguslees/kustomize-libsonnet
[kubecfg yaml parser]: https://github.com/bitnami/kubecfg/blob/master/lib/kubecfg.libsonnet#L25
[bitnami-labs/kube-libsonnet]: https://github.com/bitnami-labs/kube-libsonnet
[example 10.3 jsonnet]: https://github.com/kingdonb/any_old_app/blob/release/0.10.3/manifests/example.jsonnet
diff -ruN docs/use-cases/helm.md /home/daniel/dev/website/content/en/docs/use-cases/helm.md
--- docs/use-cases/helm.md 2021-04-23 11:44:58.753344929 +0200
+++ /home/daniel/dev/website/content/en/docs/use-cases/helm.md 2021-04-27 11:56:49.326727393 +0200
@@ -1,4 +1,7 @@
-# Flux for Helm Users
+---
+title: Flux for Helm Users
+linkTitle: Helm
+---
Welcome Helm users!
We think Flux's Helm Controller is the best way to do Helm according to GitOps principles, and we're dedicated to doing what we can to help you feel the same way.
@@ -51,7 +54,7 @@
Instead these commands create Custom Resource *files*, which are committed to version control as instructions only (note: you may use the `--export` flag to manage any file edits with finer grained control before pushing to version control).
Separately, the Flux Helm Controller software agent automatically reconciles these instructions with the running state of your cluster based on your configured rules.
-Lets check out what the Custom Resoruce instruction files look like:
+Lets check out what the Custom Resource instruction files look like:
```yaml
# /flux/boot/traefik/helmrepo.yaml
diff -ruN docs/use-cases/_index.md /home/daniel/dev/website/content/en/docs/use-cases/_index.md
--- docs/use-cases/_index.md 1970-01-01 01:00:00.000000000 +0100
+++ /home/daniel/dev/website/content/en/docs/use-cases/_index.md 2021-04-23 15:19:36.086198633 +0200
@@ -0,0 +1,5 @@
+---
+title: Use Cases
+linkTitle: Use Cases
+weight: 45
+---
\ No newline at end of file
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment