From d2bf08811c2e2d6512de73ad10daa7fada5f5ad1 Mon Sep 17 00:00:00 2001 From: Stefan Prodan Date: Thu, 17 Aug 2023 12:32:40 +0300 Subject: [PATCH 1/7] Add install, upgrade, uninstall docs Co-authored-by: Kingdon Barrett Co-authored-by: mehak151 <66996176+mehak151@users.noreply.github.com> Signed-off-by: Stefan Prodan --- content/en/flux/installation/_index.md | 190 ++++++++++++++++++++++ content/en/flux/installation/uninstall.md | 46 ++++++ content/en/flux/installation/upgrade.md | 96 +++++++++++ 3 files changed, 332 insertions(+) create mode 100644 content/en/flux/installation/_index.md create mode 100644 content/en/flux/installation/uninstall.md create mode 100644 content/en/flux/installation/upgrade.md diff --git a/content/en/flux/installation/_index.md b/content/en/flux/installation/_index.md new file mode 100644 index 000000000..b1097fb76 --- /dev/null +++ b/content/en/flux/installation/_index.md @@ -0,0 +1,190 @@ +--- +title: "Flux installation" +linkTitle: "Installation" +description: "How to install the Flux CLI and the Flux controllers." +weight: 30 +--- + +The Flux project is comprised of a command-line tool (the FLux CLI) and a series +of [Kubernetes controllers](/flux/components/). + +To install Flux, first you'll need to download the `flux` CLI. +Then using the CLI, you can deploy the Flux controllers on your clusters +and configure your first GitOps delivery pipeline. + +## Prerequisites + +The person performing the Flux installation must have +**cluster admin rights** for the target Kubernetes cluster. + +The Kubernetes cluster should match one of the following versions: + +| Kubernetes version | Minimum required | +|--------------------|------------------| +| `v1.25` | `>= 1.25.0` | +| `v1.26` | `>= 1.26.0` | +| `v1.27` | `>= 1.27.1` | +| `v1.28` and later | `>= 1.28.0` | + +{{% alert color="info" title="Kubernetes EOL" %}} +Note that Flux may work on older versions of Kubernetes e.g. 1.19, +but we don't recommend running [EOL versions](https://endoflife.date/kubernetes) +in production nor do we offer support for these versions. +{{% /alert %}} + +## Install the Flux CLI + +The Flux CLI is available as a binary executable for all major platforms, +the binaries can be downloaded from GitHub +[releases page](https://github.com/fluxcd/flux2/releases). + +{{< tabpane text=true >}} +{{% tab header="Homebrew" %}} + +With [Homebrew](https://brew.sh) for macOS and Linux: + +```sh +brew install fluxcd/tap/flux +``` + +{{% /tab %}} +{{% tab header="bash" %}} + +With [Bash](https://www.gnu.org/software/bash/) for macOS and Linux: + +```sh +curl -s https://fluxcd.io/install.sh | sudo bash +``` + +{{% /tab %}} +{{% tab header="yay" %}} + +With [yay](https://github.com/Jguer/yay) (or another [AUR helper](https://wiki.archlinux.org/title/AUR_helpers)) for +Arch Linux: + +```sh +yay -S flux-bin +``` + +{{% /tab %}} +{{% tab header="nix" %}} + +With [nix-env](https://nixos.org/manual/nix/unstable/command-ref/nix-env.html) for NixOS: + +```sh +nix-env -i fluxcd +``` + +{{% /tab %}} +{{% tab header="Chocolatey" %}} + +With [Chocolatey](https://chocolatey.org/) for Windows: + +```powershell +choco install flux +``` + +{{% /tab %}} +{{< /tabpane >}} + +To configure your shell to load `flux` [bash completions](/flux/cmd/flux_completion_bash/) add to your profile: + +```sh +. <(flux completion bash) +``` + +[`zsh`](/flux/cmd/flux_completion_zsh/), [`fish`](/flux/cmd/flux_completion_fish/), +and [`powershell`](/flux/cmd/flux_completion_powershell/) +are also supported with their own sub-commands. + +A container image with `kubectl` and `flux` is available on DockerHub and GitHub: + +* `docker.io/fluxcd/flux-cli:` +* `ghcr.io/fluxcd/flux-cli:` + +## Install the Flux controllers + +The recommend way of installing Flux on Kubernetes clusters is by using the bootstrap procedure. + +### Bootstrap with Flux CLI + +The `flux bootstrap` command deploys the Flux controllers on Kubernetes cluster(s) +and configures the controllers to sync the cluster(s) state from a Git repository. +Besides installing the controllers, the bootstrap command pushes the Flux manifests +to the Git repository and configures Flux to update itself from Git. + +![bootstrap](/flux/img/flux-bootstrap-diagram.png) + +If the Flux controllers are present on the cluster, the bootstrap command will perform +an upgrade if needed. Bootstrap is idempotent, it's safe to run the command as many times as you want. + +After running the bootstrap command, any operation on the cluster(s) (including Flux upgrades) +can be done via Git push, without the need to connect to the Kubernetes API. + +#### Bootstrap providers + +Flux integrates with popular Git providers to simplify the +initial setup of deploy keys and other authentication mechanisms: + +* [GitHub](./bootstrap/github.md) +* [GitLab](./bootstrap/gitlab.md) +* [Bitbucket](./bootstrap/bitbucket.md) +* [AWS CodeCommit](./bootstrap/aws-codecommit.md) +* [Azure DevOps](./bootstrap/azure-devops.md) +* [Google Cloud Source](./bootstrap/google-cloud-source.md) + +If your Git provider is not in the above list, +please follow the [generic bootstrap procedure](./bootstrap/generic-git-server.md) +which works with any Git server. + +#### Bootstrap configuration + +Various configuration options are available at bootstrap time such as: + +* [Installing optional components](configuration/optional-components.md) +* [Enforcing tenant isolation on shared clusters](configuration/multitenancy.md) +* [Using workload identity on AWS, Azure and GCP](configuration/workload-identity.md) + +Please see the [bootstrap configuration](configuration/_index.md) section for more examples +on how to customize Flux. + +### Bootstrap with Terraform + +The bootstrap procedure can be implemented with Terraform using the Flux provider published on +[registry.terraform.io](https://registry.terraform.io/providers/fluxcd/flux). + +The provider offers a Terraform resource called +[flux_bootstrap_git](https://registry.terraform.io/providers/fluxcd/flux/latest/docs/resources/bootstrap_git) +that can be used to bootstrap Flux in the same way the Flux CLI does it. + +For more details on how to use the Terraform provider +please see the [Flux docs on registry.terraform.io](https://registry.terraform.io/providers/fluxcd/flux/latest/docs). + +### Dev install + +For testing purposes you can install the Flux controllers +without storing their manifests in a Git repository. + +Install with `flux`: + +```sh +flux install +``` + +Install with `kubectl`: + +```sh +kubectl apply -f https://github.com/fluxcd/flux2/releases/latest/download/install.yaml +``` + +Install with `helm`: + +```sh +helm install -n flux-system flux oci://ghcr.io/fluxcd-community/charts/flux2 +``` + +{{% alert color="danger" title="Helm support" %}} +Please note that the Helm charts are maintained by +the [fluxcd-community](https://github.com/fluxcd-community/helm-charts) on +a best effort basis with no guarantees around release cadence. +{{% /alert %}} diff --git a/content/en/flux/installation/uninstall.md b/content/en/flux/installation/uninstall.md new file mode 100644 index 000000000..41297eca1 --- /dev/null +++ b/content/en/flux/installation/uninstall.md @@ -0,0 +1,46 @@ +--- +title: Flux uninstall +linkTitle: Uninstall +description: "How to uninstall the Flux controllers" +weight: 50 +--- + +No matter which [installation](_index.md) method you've used to deploy the +Flux controllers on a cluster, you can uninstall them using the Flux CLI. + +The uninstallation procedure removes only the Flux components, without touching +reconciled namespaces, tenants, cluster addons, workloads, Helm releases, etc. + +Please note that uninstalling Flux by any other means e.g. deleting the deployments +and namespace with **kubectl is not supported**. + +## Uninstall with Flux CLI + +You can uninstall the Flux controllers running on a cluster with: + +```sh +flux uninstall +``` + +The above command performs the following operations: + +- deletes Flux components (deployments and services) +- deletes Flux network policies +- deletes Flux RBAC (service accounts, cluster roles and cluster role bindings) +- removes the Kubernetes finalizers from Flux custom resources +- deletes Flux custom resource definitions and custom resources +- deletes the namespace where Flux was installed + +If you've installed Flux in a namespace that you wish to preserve, you +can skip the namespace deletion with: + +```sh +flux uninstall --namespace=flux-system --keep-namespace +``` + +{{% alert color="info" title="Reinstall" %}} +Note that the `uninstall` command will not remove any Kubernetes objects +or Helm releases that were reconciled on the cluster by Flux. +It is safe to uninstall Flux and rerun the bootstrap, any existing workloads +will not be affected. +{{% /alert %}} diff --git a/content/en/flux/installation/upgrade.md b/content/en/flux/installation/upgrade.md new file mode 100644 index 000000000..143d71c05 --- /dev/null +++ b/content/en/flux/installation/upgrade.md @@ -0,0 +1,96 @@ +--- +title: Flux upgrade +linkTitle: Upgrade +description: "Upgrade the Flux CLI and controllers" +weight: 40 +--- + +Flux can be upgrade from any `v2.x` release to any other `v2.x` release (the latest patch version). +For more details about supported versions and upgrades please see the Flux [release documentation](/flux/releases/). + +## Flux CLI upgrade + +Running `flux check --pre` will tell you if a newer Flux version is available. + +Update the Flux CLI to the latest release using a [package manager](/flux/installation/) or by +downloading the binary from [GitHub releaases](https://github.com/fluxcd/flux2/releases). + +Verify that you are running the latest version with: + +```sh +flux --version +``` + +## Flux controllers upgrade + +The Flux controllers have the capability to upgrade themselves if they were installed using the +[bootstrap procedure](flux/installation/bootstrap/). + +### Upgrade with Git + +To upgrade the Flux controllers with Git, you can generate the new Kubernetes manifests using the +Flux CLI and push them to the Git repository where bootstrap was run. + +Note that this procedure **does not require direct access** to the Kubernetes cluster where Flux is installed. + +Assuming you've bootstrapped with `--path=/clusters/my-cluster`, you can update the manifests in Git with: + +```shell +git clone https://// +cd +flux install --export > ./clusters/my-cluster/flux-system/gotk-components.yaml +git add -A && git commit -m "Update $(flux -v) on my-cluster" +git push +``` + +Wait for Flux to detect the changes or, tell it to do the upgrade immediately with: + +```sh +flux reconcile ks flux-system --with-source +``` + +{{% 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](/flux/flux-gh-action.md). +{{% /alert %}} + +### Upgrade with Flux CLI + +If you've used the [bootstrap](/flux/installation/bootstrap/) procedure to deploy Flux, +then rerun the bootstrap command for each cluster using the same arguments as before: + +```sh +flux bootstrap github \ + --owner=my-github-username \ + --repository=my-repository \ + --branch=main \ + --path=clusters/my-cluster \ + --personal +``` + +The above command will clone the repository, it will update the components manifest in +`/flux-system/gotk-components.yaml` and it will push the changes to the remote branch. + +Verify that the controllers have been upgrade with: + +```sh +flux check +``` + +### Upgrade with Terraform + +If you've used the [Terraform Provider](https://github.com/fluxcd/terraform-provider-flux/) to bootstrap Flux, +then update the provider to the [latest version](https://github.com/fluxcd/terraform-provider-flux/releases) +and run `terraform apply`. + +The upgrade performed with Terraform behaves in the same way as the [upgrade with Flux CLI](#upgrade-with-flux-cli). + +### Upgrade with kubectl + +If you've installed Flux directly on the cluster with kubectl, +then rerun the command using the latest manifests from GitHub releases page: + +```sh +kubectl apply --server-side -f https://github.com/fluxcd/flux2/releases/latest/download/install.yaml +``` From f81dc813af4f31e9acd20c2f8647f4ce371cf3b7 Mon Sep 17 00:00:00 2001 From: Stefan Prodan Date: Thu, 17 Aug 2023 12:33:35 +0300 Subject: [PATCH 2/7] Add bootstrap guides Signed-off-by: Stefan Prodan --- .../en/flux/img/flux-bootstrap-diagram.png | Bin 0 -> 28405 bytes .../en/flux/installation/bootstrap/_index.md | 6 + .../installation/bootstrap/aws-codecommit.md | 65 ++++++++ .../installation/bootstrap/azure-devops.md | 90 +++++++++++ .../flux/installation/bootstrap/bitbucket.md | 135 ++++++++++++++++ .../bootstrap/generic-git-server.md | 114 +++++++++++++ .../en/flux/installation/bootstrap/github.md | 150 ++++++++++++++++++ .../en/flux/installation/bootstrap/gitlab.md | 132 +++++++++++++++ .../bootstrap/google-cloud-source.md | 40 +++++ 9 files changed, 732 insertions(+) create mode 100644 content/en/flux/img/flux-bootstrap-diagram.png create mode 100644 content/en/flux/installation/bootstrap/_index.md create mode 100644 content/en/flux/installation/bootstrap/aws-codecommit.md create mode 100644 content/en/flux/installation/bootstrap/azure-devops.md create mode 100644 content/en/flux/installation/bootstrap/bitbucket.md create mode 100644 content/en/flux/installation/bootstrap/generic-git-server.md create mode 100644 content/en/flux/installation/bootstrap/github.md create mode 100644 content/en/flux/installation/bootstrap/gitlab.md create mode 100644 content/en/flux/installation/bootstrap/google-cloud-source.md diff --git a/content/en/flux/img/flux-bootstrap-diagram.png b/content/en/flux/img/flux-bootstrap-diagram.png new file mode 100644 index 0000000000000000000000000000000000000000..36c9cb32716ee9830fed14b64fd09b68d8a69da9 GIT binary patch literal 28405 zcmd3NXH-*P({Dr(G)fUjP?~^B4ONQLO8`+sIs}m3k>0yV4@IPj^w4`t=uIFL=^dm8 z5Tr=&?FRM#KF{;s^5L#^*SdVjIeX5YncvKwJu^Ak1iyJLefRc*+W-LI?h6@7MF0RF z1_0c+fqxxKarUB`$6jujh{=fo0HqPYGd*1F_?o?ci@dWa}g_t&M><&k8G!Qqy?bAGRIglhT=s!->gz4~VI zSu3pC|7U+&G>*&c%g&U50h|FGpUXGMt%!sCwz0-*00b@q_s>TV2zwU<3IhG}f$%r| z_vgQ7{%g`%uPNv6k%v5zT=5G*1~UxHy45~_5LQHU41cjwK@vd#bA;*8cfpuQ&OB3E z7@#Rd68^nC*nvV4IDiAVcnDi(V77a%Iq1qS!JK>P-r3G(=XyTTNT2=Ok7LxsE*A^v zY79edC! z$SN6-2pJ^Hf;wB1*0!OfulKh>VFMVC>xJ@Ac&<-l()6pNEK}k}5G2cpPP5WA-iOoT z8sO3jnFCI+&vKxGU{0b2W1l8U!xQbipZ+)>>|I`NiJbbffk0nqKFd6NK%6{Vv>Vu^ z0Uy`aqJe~iN^6LMu@jyUPmO>%=^Q`Jv1@`kMNM2_jBBb<)wJ zopwcoMhOsDYuv#`^NBz8(&Deq=N1D$9*>%GI@J4BcsR~>J~g-(dmSs!gBhkJr%|__ z;&>0@bS13Y`bj+4fK>xSEz8zY&$6M%`cjHq>A~1_rIs&0;^JRTM#OELKRG=Z5)b*b z`*eDshbfeS`_8*jeJ~_zNcel)vE^=I%G2pX{My&Cy4<11hhfFDwg9guuwlZPVqxUU zwp)PRB_phxk7aZu+9*Lsz3Z|BQdKai6MLPrp!|kee8KoAjPiRNN?`^vNcq~Byw?O$ zkq_xo38-+$*nDK={7MoCIMPB^c~DH)f5&jaSid$y5s_vY?9SPUooXx1x|*2 z{60HGUWq68qc8Bl(c-N+pFHtNCTO!4W=Z>K)YZFWeutPg`c%E-F!GAxu|ki&S$D6*UXBV=Tg#LmwT$hT#q)xH-R z#V_v87Yy5#4FXVXM7AT)TVhBTcLrE=^?_9vqkJ-v8A_NS*}KNq<*^|82Y+;0X(7(-Sak&KmAP_zb8 zW}|k#1h$uCN__Cu7!Fz*7arYZkUTL;T;OlZXOP@E@(?!^a9dwgqHqntvQIWH?VX!$ zUsxp?XomMApsq=%&uSk623wu6dwSNr2<2jS$^Yqx5aUU(Kk_ts87|lhL#~AySx)Fb zb6amMz(xlr%mX=&s8~29L8{;nU8kb`CF?YeK)bk01$a!^Vwho}flK%LDCkU1J&WZd z4)idt(uV8K3zh@=mDC2wwN;LMl5G;R#@IZheb$g}In$5wcxPbR7s zN|(~2ew?(rPt+_hfT)-VzbF1P&i2>$Kn~=O>79_$TCq=?lO!2y1?Y;FAL)&h;u}#? znr+oc4O=!?gc?&s8VaRd5qU8;rc z6?W_3#*<;?S+0%UZj%JFcAmf5TpvKPcBmB-by&*e)H2Qn8(7_K`}ibJDgz}te*pe-N`3EWaGTCyx*+X*DvsqE?1`Jn@SR2r9*e*>d{)5Ozvb8qK^*~RtQ#t&;Yys@l+H%NF~9I4S{{4; zP|@Lx`INk|;}q_Bs%5^>IJ&R&`ZU<=a7g;}m&LQ?^4DH#M<-NxbJjti%9RvVBtR5- z)L{DF^qLR0Y+ytAA?zXSpO3#K2%CKVr(z{b*aik<;w=Du20v`${_9Tk=hq_~pFsnU zYrpSO_jEn3y>a7c0Q~EYQHWdz@Ww5a9q{`uni_leTin0yt^@;QBmNhHvC94>SoA07 ze+vG;VEK&&i|=1p7=^H={dX+?&D{1QoJ)gEEr-d`7y$Xrk3pd`|>cDDd`ghVfK000TX{zd?xssH*OJGT4yj}gZn;2e1MOyY9zUvvJA zie>*h`VV3MJJElH{Z{m!Z2vj>g8?h#|A6R!64K;-gY$_;yL}y}?WtZE=P$6%CBpc9 zTHpmPpo)i=y~}PBHTukbO-nsCgVD-;sxovt1-1X7rp`Fb*JD9a3RCbv8=g z$Oe~&ya9@0w;FpMIt13#m*el>C59d5Vn0w=I^gQ*8z7d+D`GD~{^Y0DgD-`W#X}6} zcCV)D43JRm;Jf9zD)%;*wLyc{8NoLXoO8FGblqQfzpFkw9aXRXo~3qDH?h$(43F{X zFBHqRs&o)Ee-BH=?niE<7W^r%K)Inl2^{6ow|!kxB(7YMU0d}s6V~x-&?^=Fcu?*< zbp`mS@$(}1<#SyLp@G;h)Cn;QWSp}VLR}{Z%zpe=*iZl;8YOsU9#rdzyUXtR>Am#= z5ZCJwxOJXCRYW0k8Ugv_us&t<2Us-tMQNbpWr1gT4bM+=z16XjMyh0SNFw1^0agH3 zN}LjWuko0CjF-9gOxuH%zVt3_(rq#G8}u&Qt_4mhdC&tKl6tea6Fd8AzNe@T@DhkO z(1tciOTuOYy`!f|L)Oz{+$FL0A%li#R@h5$IV8 z?Wj!afqjn{ZtbXr+k@=A%Y#Gt%Hie%y{Wk6@asRTUB5K%Km5ScgYWjhB=!dVMvwR* znf+kF8aJ(ic4@s=Z#~DxxwbcvRw3wKnYv*$eh04kH2^yZl@oQt@eQx%(LT>mT0WE# z&GB8Oa+ofBx#;+Szo^4D5`?lj|Cln2Xy+}9Cf`?o#ye@pH6tbP>_TtyoSwV2|4=>^ zbT8H!?W=XQK8ogPmT7rVs?EZnZUwj?#4ZlTNW~a{AXuEA9o2#pF9rqX_-`C`O?pgE z6)3$R-LPMAo=BeB{vr99sQN7=(N#pZqxvegHuIqgM8O74I%`#pQbIU1m&KbWl<2#t zH<7-`JHt!Ycd`O5&2Mas*QmicorxXi`}3aKmm@TFPRY8eOf-aEZ$C1pWzdgY^8IaR z@jcX5IjpMUc?Mw{43Zd;RWx?=3WDS@P59iqY5=*77-{ay{$5)UXzba`T{yfIKsVf>A7b-yH2@=*i=>!P?3{rWVJbp^PM+28~z{)lk; zt9PWu{Gs_g3YL@OfBxLObbVO=ToKa!8ZuMBXFme05`_@xZ#VE)*3til;W3ODhceL( z#2S1CS*rW4G~XkHLb7fVA3}#QZGJ)Vt!cuv+5YAS<_Z^*7A#+J)pGoG2)Q4^JM8$Y zr0TAM7OV_s1=zAyaL5tD&UEWV#+vNJ197SwWk9!WS-Un%nHPRMX{iwmnXjl^HZQo*E0X{ zNn?BCmljY#^_~O8uLJbl5li}_OHU18bWwWO?R+TkD|jR={Nyv9u zA|)j@P(4$8Yvy+;U8x&a?hl34-A9F%uQQB}rsbUwDH2Z4D0>#*7izkGJ`Y$oQ2-7k zDch8|>*JlQz+Ix<293BjA+(I{=)29FgAR9w6@xQOj;M&+Ol*5uFI11hafsWPu( z;92QCi6C=^V&q+!TS7q*4Z~edJ4Vx%3~v)_a?Un);D&f{6_n3hl|yGHb^}nCVTG9CG1>PWK5EBFMY4<$5^xlXdY5CC+6opUAj|~sNoIc8i89o%j z3{LaxP`HgEa&$F3ij`w(Hh$8G0BKTStpqfUn5VHAWX5C`Q9v(B7G*^Hjh@pe!$I{| z0$GEEt<0~2G6-iDiU?pwbl77r_0A4itz2H!~=YbD(nqXTCFjEsUYvhKR@QVtri?)c*(YEuAUBk{!`)4-h2|>H zH}tFKbMQuiq2_G8Dfj9^kgH?fN$%RaN3g z<8u;hR6R7-^Dgkd1^}?B!TBF64EtxBReT+r`1rFs-8HfHX>U3V$rS0*{dIl!KBtIb zchK}0>=aMH^?PI^AM zdlB!a{a`s57R^Nb>?W~RTv&}S4^kk&{MB+TjL{+|;=F&9I4j{ou^U^h0X`zBpf%Dk zj(1~9wb33uWv4%%L-~I7E!5GQD*&CS4e(!6*+UxAn(qhh%0V2OP41d{th6mYM;*0) zzN&P9zG6_VuZDq&@yc=H>%oxW%VN`54=NPnWGE6}^3GCR{)<%Gf_skUkf8GRU2Khj zGVvCiL zOl+pw_eh|PjJOXWJ>Y=v#OZ^sVpXsaHmuuvPoJVG>8O92Hh>yrBm8-30HJXx36ULd z?g74rj-hhaB#oADo$l^4d1Zrsy@JfJy@7l4U3F4`gdF8Bej>RZ=2!rhf;6GdI6H`xr$7olA2w2)hg z^&ZRfXVGmFG+a=~l!^k}`foHCSQ_Mdz+tbxy*Yf;MM7_MC8z9D_lzJbE=XDu(cO|wdVgHtavl_F&52DvO zi<`#|@iVes4q%?Dyfs5l;ah&WV?Ql>*Lg-UV)1_>CltcFggNnVkR#D#Rf2R6lF$u4 zSxYxlyWZ%QwrQ-iU(#Pu?mEO7rK~so_};~>1(_bV*6aqGnG;WOOgyqSNT69AF8xQA zd>Djx5#xr+8EX!Csk%}(<$oKf?Q~)bmD^APYV)$}t28?J6&x}sZQK|vAUPOxjp~if z9#(qk^b$fH`)4n$kLy1M^W{J%C$=MYW1QpJx$X#;eyr(XZRK%~Jj_LF883*F&cDjM zo6i;*b)xak+bR!Qr?%{9duwbxw_)*qJ#1wx7rpRjQ)Rb5@aH*IHI=vF zM!CGBd$|0gp4C1;hMt;ifs#FFm?ZTjn<0R?f5{QQJHzr)H! z#WHdU!;3Qg6r4td`nl*bx%jbN%}nG?i>D1XcAK)#z3&2?j3eO`BjRccOv(a9N~Vqr zM7`2Oy=2F&S5{ng6Kr6=HFGaW&$uJp?=D0vPwk%#1cYn|e)?Z4%XBVBUQelwwB&@r9 zu;2P$io@wZ&UyaSYzgSpe*bB1te37@7%@`?I6BFkwg*~CPTuV5^A}MvH4Le5TMUyi zLNm5472nkBWDWoLS5%Y){4MJ*RbVc=4}_BTuioqckVR>g4rH$5D%7sJfNhaRNU11f z<{xAxdKG9Kl*{Hn8vGkjd#RwtXMY96eSp>3U!@Cdy3E175`u-D3bN_`JD(s2wDl_4 z@{jR8Fx{)XW`1p}&HP%O&eb9?3N@YL{&U6p;`bPP^%-nA#r=J~{(GX&;Gb)Sg7|nK zZw}4$!#8d|hrk@%^`Oy{ytN*VJKpYv!zY(Wz$O@g8kc5`9oNItJX}f!#Z*hFGT-38YX#yD-!HO zsT8Klls8V^rh)KZ%HwRi`I0YCaH%t!PMV6#n1Z)*(LAbC=i#1TmC7m+JG1e;CfBq2 z{;-ZJHvMaVp{db!u^&0@R(d;XK&En;b|i8)vOfEK!*lp}SChIR&%%OOBO>Nab>QPK z{>**yuW5H&?wm;cUCje!Ao1-QRWEZXAxf^%m3Jr^dWu2(9&>)FVShmq=kH&Dj8v5TQdy`VG`;tK);?7hvCp`OMSSrbv>^Puv~}cBCQe5UA?82K zlI>~=L3vhUR(a^$J0F73Z^Ne7hdc^5k_E6CdmVS+yiyrzxI&orH_XV)Bvn#-a8Yl( zRpC*a={du6pT$-Z7!R{!Sp2$3Bu8*j>e(Ri#nOZXb7FT%O1Q7m)vm$@(>pM8fjp;$ z&t;O1YT`wuM632XQLtj9NPrPUeC%Zk%mw(9dMd~NV_89KHL|>he=jK1^%wp>p%_S` zp3CR_Y+4oWMZO#h^P7*QBRe(M&!2i=VQagU$s8rxw&zjl8Z*ecBlp+6G+BFserA+q zu{SlJq!bBAw#f>1o7GA@Vl|C~*E2fj7T%}(No%JiFHEI>eO_`z@$uuAy7M)954I>? zMx24Iut`)D5-!TK#Qg&wLHT0PMz6C#{cPw&H6a&0xbk^F6aPJ_r#UT)CgBno zEy+7*M@4;+0{ij_n^1@KrOy;&%T)c!W}IN+wFTq@dFYR7OVsjl!*styR5gOYz9p4; zW`nn*8bf|E1Vzh@3_X}LdbUHy^3nzea+mD+5H3Us($`r9V**81}3wUo`> zNS{rytQXSwPW`GKj(rhs`#q;X7=J;sMySYv=QcQn>$wt7wJgL}@$<0qNo+Nq3FW_m zQZuZN_TvL+$XzcyIEB5-6Lv}{way0Ft=zQEaM$|6{X9#BHSgUZyHy@_w0KHh{micH z()L$Y^KCJ6PESuc{@>}C@=lT(s-sjAHYuJ#M-_tY5}Duf<|UF_W`Jg%*pCrbkLC6VyG&%^yQ$fC6iUn zZ3Rg`@QX-8dUbGpe+xa@r*sI()+Jib&Oz^uh}vL_Nh-)X6@>Q+G9JHfFpROl#lFbH z(sIxrN*6l1hX@tmKP^6R{~24Y)dj-Kfv~|UQFQ@M?CNdYwLkyZx$0`Cp zOaEPWwk>}03W>Dxt^R0lcF%)?m0#Te|E@>!EYb|an2iwxoV9nTRr%^&!&N+4DZ@v$ zdL~%2xarxhf&@#gf9>AnRcS zkgZpNt#^6BA>fs)+!En$fj$QL(8e;fTL!u}N@Be)g4z4Z!?*xSElABAV)Krxu})CA z>UkLK^A6tcn%p!$g3y>nD8YYrzW1ZOvJNnJK8#o;GaJU7eQF?3{B7Ti97NVeAs@YW zrbn9bTVP!_EMpFlgWiusXN2Z1+ago4nWz&6myf+=+i323a~rQ!gbnLAq`HMRx(Z`N zx+}lj`Yrqo{Cor>@aj&dxvk^-x3BcRK5;DBZi<%oPOxc(;9(|GCh&eFG-%hA)xJxD zeLmpa4SoSh>B{ZDpzp?nUadCPM}_9ZzVIB-m^3K2fPv}FQuzz>d9SmVpF;jQ3y}AH zHqRfKFel&Ex#8YnrJSN$DM_4c zFGTO~XbEGyOL|qFa~4{!DFJEJ9hTDzkJg(Ry?kGP}V zNVu*iAU-fXBAJ(;g>z;OrZ|Yjr0O|p#=$;6zj54YKHsiZWk~uY`TO4v2{268fxhdn zzC;jeeHrzQ3iKA|)e_FkHA^80$t9(=$(murjeAPbLTP`mxo7!9e&4%2r z5LAr-`}||sn4FCrr0|)C?Gc_FLT0n1oCtzFJurZ|Q1Bq%O7a+ZJEwuv3{asUs$r1q z^(<&a<%qw?Lr5^Y4;ZAp97U5KCWn{*!(-LL!Z3CoS|SXF=!?K8y|J@brmmO0r9ntr zdJmn1^lpI!u;&j3aEKrWhrt={2q@(lKczH$glvEgdvUT**h@#dZGG;wvoTn;aK;{s zK;UwmnwCziTZ`2{)6xn8p{q@aFDM`(^P`9wWA4}&zz=GO zQ^bO0a<}V(Dcg4vIwrqiile1@u3oq%d?8}L60|h;DLjfD9E?7B?;Iai`5U^=gf&D} z4q3HK5Q#|Os=1$9f4rxUp7tJ?C7~at+@X#q)A^UKlg!oJp8I?aYV~di z31&G5&(_3OJq}QRoc-AXIo=pv zaGUg8tzdS`YX6|E&u(kMZEqQSV#L*1=J0+(OT^t-kMFMB=Fh5jxC;ZV6Du3 zGz>fgm%Rk5v9l=#rJcf+SWhqKT5J1XpPgk!yz@?Q`C&UV84){4SUjWu$3@(spxoC4 z`(AW~ZgH@6@4D)xPw+mTi@#{dAzz|s_fcdC#u}xK!-(VDz4HP6vn2nk-z&Qzu#DmQ zwWs@R3xa-OuB>cX;~G~#Q#MT@p!H!ZQ;uI&3(@mhGUj&DCszTBjgLqJJ~Bttvyfdde&p4QV9aiMRS=>~1J1N!l>; zc-ry#{9g+nKx#Ih%SjiDq5hFMYC53(ma^I3#3tkqG;gHo0{Wsz>1uH$fkcpB;h_4s zs6u1C?|E>!#Oy^(Wc@ z1BjZ%W-J=)fh9@!0K(s0;!24q_DGS{ZuB1w99)B1mDjM2=92~v zgC&6+Zf|t386+KVAA77Kl=|OE(w<`fNoraV`-e1u^M~=jNc*_|jf9o>mm~@NJL@0P zm6HD;{n7isArb#Zhn4luEQP;-|BLkhi4ER(t3U*-lL$4^AYH3RFm{nkB%6E_&^f`G zao^jT7Ity*Q>VV!{$k1L6ZxZZAlV5v1SR25+*gI zoaFTO!PrSYcx~-ygTB?H5%K{rc6iwxVg7{FsH6B?hI;k-$RO!&D#`9b!1lm>`mCUa zelWmcL}~8VT_=#f5cEuL73g_QR5eMOeYgDrGD6CPkWltaV+Z_zu(yAQjn(c-OA}+o z5~_NxwGTAx@0wl~vhU$G)#1r-{xWjXV7x5i0c6O z@ZfgG?lb!Hp9)QGt?f^qYcJ2d$i!MG5d1OSrj(Q|nMcf51REnqrW(}VY&YP{ zT4$1DTHOcyTT~J8S1z03(eT5B=qmWb={i6pEVKLTjt-s4*br$#bz+te%|*)4mW?^u zWmo>R(Jo^IH}a`hMS03@*1dJ=oQd0mR=^7Pa5;?1_=WG6vFdm1vi9xToPCDR`ZH|F zsfSfw#Lo2cp)QXaI#d%H8|7d>fx2b%17cNdv=HO#WQN5wB$`isKuFd&J*VcUivyn7C5hZXiZf= zSk%3Q7+jyNYIu2?InAKMim=Zoak1H;ij$TSaW>jNclETjGg2^t_sHr1=z(1nMX4*= zF{Q}M#8gVc!g@Rkc*_s{#i!=`=X##DRz{q^FxXY;;aC;!!|YHaDi@AQFDWMtW_xX2 zd#hq@TR7u;D(WQaXgrn1&1Maus!r>ZW(6{$do}<+#AuhN{@Z+kwfCGYYPK zI`p1MpQ?YP&}90h-aB#V0lOJ@OrKDTXwLX)VpUMhxjUj(R7;d-cqJCit7ddNjbD*Y zAooY^<};0_2aq?Vhn%+C-^=iK-w=a|ZlE|JvTn}H+F$iFpL+2_E<79P;1!m%TP`QG zwx!?7OjT{)SNS|#5r59r9D6@xLazk!T{samwmR^#Y)+2F!0vV5!^YciqF9zFc!S-u z!i-iG2AZiNYH!26Ax3lgwDslggWR+77VdBNsb8x_LMNkTrWbNo2*iLBG{-AyTy1xuc)ke*?!PxxFoFr1f8yb2l~};I zX<=Qt_fvMX<$yMj|MoLYZ_3&PP|rJfNQ9Rtu%?a*BHWM435GMoqR*Y&cfRm5vpvK= zaX?>?;sV1m17<1D4~5&1b9H8C!-C1O33uOHlv-#Bma<;#8*Zb@!RXm8(RfspuD4?*3Y1leE=v7W26@UK8vzYCU||tf3Sh{&{whgVw`@J*SzEw5Y%OkmJmP5P63cMEc%#WU{|yhO3}~K_htzDPW>%z)7v!vZF`yZCttH$j+zMPNt1Nm zMY&AfvysSxfF3q;vSw4%9^QaNd)pu1KTGM{LK_Y-EntpAl_EfW6NureRGk7%d@-GT z{(a>7JPUO%=U4$cTOl&_Z3>~;lv!TY9nqh9(PJ=ngnva5bceaylIYM+_YV9a?G$K< zcY-GB?1_*l9{6Wj8<{r8;}|FRDC&keH`AfP$G=J$M$9T*%&hKs!>tv_!SWEeB&hF@ znV0R(j}&pDeuQOJu)XA)cGnd~&qpxjEh4#Z{L4lD+#saH9kw5)wCD4|B2z78x8q4c z=Rm5tN4-RPw3FiVRqAbK@$V<-2=4b0HOj`lbNN^0>Rw$|bOqlTjtv=d3!G(=~op~(2-bh0C?auY3HjhYVZdRj?MBs_;{xUwd zq@2-RT1F>QN_jYH(x1EPIlb(t%2CR>abT%bHm6Oy-jS3yN#6;nP&tIiNhn6ox zI9EB4RXO^_P+>73)lKV!djmk8yZ5E>@o<<0-d52&sGc&NcX3GoLB>8+KWXU4nrRqN zvGz!ORezZ~c3D*}_4+{{Le?HkB0?dgTy#Wxg@e~1w>QJ}d|w29DZH7eHe?(`698K3 zJ$x`mHwx>W09< zmL&XTP_)48nifzRu*)z<$rmj|(&t=`6idHFIio8x&9CyMPSya~F=?mBE6s!Or_?#I zw6)dt2aTaD6)>=e^f+R(a8L~DUe*VT0a?fLeF90i{<3C~9YjmY@U4j;6gXx@Ck@29 zIQa?k=7MBtK|H$5g7`bkrf~c^l3zzF==A0g=Hwov$T|#&?|Xp{J0qRB@w6WiBdH?1 zD1&5lYDlRD<;sW)ue{=U5mfR*ycI^OA3gqg6jn7`>oCoYubTnwMyn`+$y{lepBzCTqm0C_ce-=>dq+kf6(_RTGU9f8&01OJ6AYU4LhP3C7Lgsb^GZ?Tn-(f zhm32`J_%iC8{P|5zEn2fQYO zjTg-V%(!x_lH#Vq{RWAqpt-_%B5kccS! zgUa*`9|9H>e(_d}z~$vi-NetyyhwCaVNVSwUEc6}H} z3ppE?d1|g0hsRo=C#aGnL02+>!WiklkY8g_=&Q;c2$Bh+WX;>uk_n6l#jxaiCL2G_GzkX+ z!G~d{wj@_RpM!Z+!3;C^^|H{F5OArxKXj<7GKh!|@^y))DWckd z;nPK%tK`eoCkO|zvSDhoaO&7;2ayDJWt6L2u&LjZ!a=^|QM&L|%`NMMzFqRNql#QW zp*FDES&Q`n_@${W_zEd34eBcHH{M4mQK*^;;{l{PR~`|Z6y*ZMkyIQ@=`RX;C?po! z(3Fs0e63jHm-xut7GaihRx-SlUe7CZyBi*Nj+>B|_1FzM+|kg*&-JX*34l|XlPT(K z-iJ-$UWLfcwlsGH5ebs$Q@mUyjx=c50GM)zu*)Rn?Om3i`={l!;BKyhi?g_S{fPS@ z+q{k&knfrxEVdKoE^%j(?<3NoBy>U=dml^RLmsVpz3v311b`r$O{;*iCe{}7Nqu6r zgZuIIwwzM%NiyuNdJ|^Cx#eR3kF=mIz$;CL+$c@Su^+KJd0tyA35Uacf%V0lVYC@D z73x0lB1$`N;7EuGC8ssS^S+sOd*~Gf@S6 zL_ER(4B6y+WqQKgh836J*hkRkh4t(_WEzfnBU+Fed$Ux#V@G z!bFx{@QbJe+m}kWpJ~i~I!StE^ZIPPDbhl$9Lm*4U*Aq7o)L{WR9-PSURSL^2KPyNKkr1FP4VStqxQ`g@RlnR+{@ZtYR2R|oj3DtRl0O4+oL$>qpa zVm$lu)B1fkv@{*Yi#?Eam+LjR+qsA7_I#3mzf)<_yU4HTBHQ_SOvsg!4&*)kZm{m$ zFnMNIC*}8)&yZg8&W8r7g;Vz|`~}ZdD{|trwW`mSTRky&!a)gwnmNd*x8lIBg9Ijt zraF_zk23kFeY+2Fr7c7|aFHV83aB64GeIMSnyu)R3xbW8hNYjTU#-UP;I~p!ovgkl zlRom2UXwOWcQpjguZYG2ZaH1&{#GJ`OD!1sA~13i;Q;t}3l^lOHlxEt+cgmo!(7r& zVH}s|X^glK594V`jNOaInl&T_$^k1 ze~-myUCk0*vyZc8zMz&%w$7HB%Cg}}t0r@awcCRNsA|CN^=n|PDBp{lnk8emuIn%9 z-m?c;eLj4spZHj;Q~Bd)B++|@GvUD$F?1AXW3foK(=uf`)GPJ^aV9_QGZI^&ZeB?Z z1H3=rx`D)gXOS;~KGvu+1X8>Da$W!GU8p$VUlJ}^@zuI?yorRNq?Ke|(k=wVoL}-L zyP$%x;ab#8$*T?r6DY(RCx=JE#3QMyAidbU zPNADW2zs6b9L2eEJw96;<%BJoq$wFo-nMQ+mgsi0Jm^6uarz}P-ptayc7=w$1X|f# zuAWR$_60K7VFi5XtMyIXB=qBuUzC#{cJBpic4JfoVI`e0y<_O?^_yq9sE^PpbsXSy z$qR;nkFuT5)a#ZjnVpgz`BwR)7S}|UHdoWqm#HV$ogibQq&fPh)dgL^3-u&;kG;8ZzR&H!Jh;f{!StG(GDqEAxy|ybt*rZ&g~THY!q}5+ zQ2cpVxCx{VdxEkTQ@tVcwnJ88Su)MvlW*>ISOdH!zUVpGp~$+^E>jJFzqYa?QL404 zbJ6Y_2kbhBD}23^BSsSi(x(o7wI3TZnyKx9(6==9`MbE!Eami&;w--Df^lC@nXCaU9Zyy0wyEia2v-srRjnI)A#{wa?rF+Xi@n0YP3AlaRa-ZC+JRpE z7WEqmSUWoU5uaYLF27Xbyb10xg&a71U%{E{o)JF{)fHczcgc-`ImE&1@`$>_K6Rbh z=6<%_|Lid(#VbTtxYpTPgL0YbNfu&b?LrU2LN`Cr?74Bx67!G4_EN%~3en>br)#?l z#f$F7KWgr?u!f{nAxyuV{}O?M0SpJA_~p&Uj|GQ>z#4Mj*vT=Ju@%n(=JLIo1y48kgR5kMiWl9<(AgdZhn0(n#|?yzNgD_$nr z6>L(@9KfjTa&`sNvoVSO?loUYcT{RzpeB&eblQMXm z`JdiGEd!5W#C-e)E;qC-6%!I3>TeP43+i)hK)-|$J6r=0=i*Y(ZBl+vaWPHPu};YG zv8PMq6!c}QSm}{`$BW`9@Gm)(`hrqkNbki5$Uq+6C|*>@3j}>bzn8hR0}|j+ih(C* z5XtZC9S9JWAZ;CB`kwfmOz^F%jRwd7rL?RuHYHEee%oW~-NnJX7M==6jlpL$pYA>g zaWjt}IYcpne$my8Vf_kFgv(#Z)f8_ohNtTnjx@`WOEU7~B~LL0JKHa>h% zUWi^~lN@*&SxblYqP`-KS5lv8nr~#pD-C_7$?sJ_HsXfYj}Ae(s0TO3S09<^JWw1S z9U!6~W2F0Vl`vi#PLO=A`2@>oPOpAbg0iuS$`m9_HLn;ZOohjQ$5e%~INS_)VvUGm z>p5U{qY7WI!o+sf=8~b9?rj80W=DbFI&ZD%oM>s4HN#|<70Z|gXPD71A01ocz(p;--ikD=vd-H?(IC|7;6uybVozut^p5>%DzBr@9{yZp ziwzJXZOiJMllm^*Tz921A63<=0aS$lW#f8n+yHqtk+*l^@XuKQMG-$XRtrw4yF-Pv z#=--yMiFZkdNuIUsdDd?i^V6V2G_L#iBm8w8HjM0&Biq%y94FtejxK6jjHt^{2DNJ zwLz#z*;mpMp$+N?)Aa_Blo;BS?IepFI_{aXg5xucJySANRkXb*oCz{N-=Lz~_#}{n zU33j|J*SRf)hD{er#rS1hO+^BtsvrjPuqsCTM&mitpB9ch1AGPPlk&X zfnh6!-+SM6)MMSNV$I3Zl-I*D1l*M^6ImPYSjQ#ShV>>xvIzFV1Nk~>ZV1cf4wlgU<7cz zeNnTWhDgDlqVy*#WdZIoAUq8oGlyt2c-2kKd1Ce80HGf3E__>1A|21+nh&bO_a@PM zluVET)bng&$UkzNao*v%=eK7*A6E3at4fL}RX^eLloPu8pynu>#2iY$xx}AX9vUpjmNgzPth$Y{@sl)Bf23@?&?De+Bn_-)pY>)Lpmn z^fuOac8e}jix{Oo%oQA-Ekh^rpzKBx&Cs9z>b0NNi)oPnpGP0M zk%jYPhvp#yb(M+_^ZYQv@C(k9x-S4QpO|J_SQR@nO4XH5;kSH1c?_6s%;Hd#7}rc2~Lo9STh zQnp1(8rfEjXE@i68nCfsA!PW2Xlz}>hF00B{%Fk8m(bn#Taoj}x}#e;Bd1QH_P*b>B(p4=!$L2hrIUUR68yhJo11DlHUqCTT>k=b`rt zjXboH4amLJBECLUkV1U@JfS8CPaDwW@l}r^u-36dzso6>?i#h=tz7GyCYFkh~e+A# z@Km8H7j+&a2DTW-hna3G*w(~HMBiOAWAb*|H;i^pi}wDbr+?_8AFDrNj|dJ{RDZmu zv;8`6vNZfCBt%ij;XNDR;kb5mW*)NlIkHGu1H;lQY)JD?Rs!2T0UG*rI%-=OCu0*s zDN~Mb>_z_gxGIIGdc_22NWh5NcX-}R^8;&Rqr!(>`hV2+-9b%lUEdK4YNUt~^wO~+ zB!E%{L3)wii6DZ4CP?T~q$wa^=+dNW=v_+apn{#6mI-w0j;mHAQVoeJH@y zCy;8`TbJb|5H5F5o4Q*&w<83OpMlqY2#t$+{K8#56wW+mGgdr0$$rFWL%H=cDL>En zNZIhMt-7cCUwpy9>H{i2VON$`6yAIe_xgS*5EPJDlS|fS3;sR!=BfhnkPJ*bX*Z$FbpvZZnF=8ovhEnUn9lqlOW$;kbD`T!7mtQ-c?-Iroak@Jn;zsA=rHch3G1I_`1vR{aA`0}(L$h~lNAn{qQSP)9xD&o%x zB~ztH$nkXft_+&2RL@q;lDY3ZOJu&jciopgiM!c{dRxUgr8{u7e-Ft(4Vc*pt<>WQnKS$ttUU(Z-$L?88@m zT-V9UnF1kB$bl12%YlO+q|f)Pf|thZ?GkYJ0#MvX$c@zx1wjxNsQZgVX(&3{d_?{u z>8>>qrwJ+Qt@?Nq`VbC^mq$~Jz5=U66#&AVZ$cYtkK1|UF(rMFI9|kwb}|QEsDjVN zF%MNT?$_nN?*fx>x|eeo=t>;pd~PX`bTcWSOKy%j5ODs5ONsI%!>%E67fuVsc)}CC z4)yRu`D=A}nGJ^iSh0b}oU08jw&F}VlCY4BE94YKp+CMkmuqX@XUn5#C@19o(W236 zpX>b#k?s8e&MyUk_1}1)>n1!5=4~lLnb((RZer0pXu#wLJO5F z@Y(^kaS)@*4Au90x95u|u3^nHceFa8tOE|WYi$J(H|zajGne)$8jyw-~7{f`?;9EwEhS`CfPNZnRZ zc6?4>|NU3ApYUviq0(;|+g=6Z%?lfkNb%K4!qqbcPn((8JQI50cQ2mlwNM=KJvagjkKUo`<#x8~muc^8zFhWEMN-(D^{Qy(Lb`k(#<60L^)P0taD6PU zL#M(2k!eNi8<9=}T8lt~E(}GPmDrhw`T-{y1$Z*~RK-4MIF#em0}#3W{LTb_`>;ZJ z;=3Km!%(Ib2!{V8f(5u%2bvy3+f(pt0ealb>1qN}ncgUZ=vgxgTgmDR8^1EkbYCOX z!mICxD@+gahvoHrXCn3V};cp8`*y1f28<8 zHG?fn)_S~`d~BLcNxlowmQ^MU(?|+6N0yK7QzPCMfLvkF>>^TqR~nB6sD3s%tbi$nm1MwBFeJLL+pyKx5Ylxk zzOXBPPz8pIy&qFnxAR3Tq@|jKCjS~ zJi(T9lxWwpJ07h`I46^(Uj_58uhltF*E)?XIVDPUDStEDoi>1vn}B8GTB+-!$*&qN z$I2Y~y$w*#HrP#Xy}$mvxuE3plb1Whf|rBg93B=SY*;a!%8_m(dk@s zktV;+SX0^p@i)J~)S73=l^RC2zGqOFRZ~zQ7lzj$-6k4hBwB05}aW4?GbuywYBtGk}K9A=d;$E&rKUzxPh`5uM()W zE}l))H~ z1WyspQExX4aq-Cti}GRK$-@22tr9r*s|tQA?0nD}4F#5<;jTnnQfRmSeptcT*{z$0 zzPW}V26MTHq?yONDoVZNGN*fD=TcD<4Eg>j1rSYIyhxviaME<-4ouR(`azP908UeO z(j@{1ET6grla5ZVo&FC=*AQs?PtuhK$0TXe(Mb~HG3l9$_`gXciGN6l5k256>@2t) zIBlBAB?lZ+&8=i19YFm*lDM6|{%M6KotPyt9+PUf-~F5P{r8V!Qaf;nmc;lsiKOIT zq$9l~63LW9#$(cvb^jn88~kIN4T$?uXaCu=6aOX!lHB)C(jWJcNJmZP<*$z`hemaDR98ZB7G8Zdhk=Ok^dlg9qvRx2-d?SJ=(6Y04WD}8=wJm(I3V? zDRD#-3xP~nt2VhD4%i`tRmn>*>CyqHVlUPzINV9>%EN!|{lWvQaN_BqjDr_#AD6gN zaK9i*B{$MZri}897n)ZtEkq~#u6e8ih2e$${FJ92u899co(Fb@^C5!dEE95=aVgsk zZFBZh;_hlVJd?g_r9PS4P>MEszDbz^byy|zO$rK&*zynjrVoQf;Y=o!vD}>@Lz{9~ zZtHu9LzJS_(@3H^)-o{Fi?e9C**Ov3e+GM4Ohg#fLS7`7+Fc%5(Dal9s+;~$cOq>| z`VTGzXC4*q0@YBvYS7(lE)r1JB)CucfSA-=a0AtPD-)8ERFJcO_h$AyFYHwAL`Sytgp;!3#%JmV+Go}G zokEy-cuyRJz(s1}6Y@C47zbZL)}1J1?}&AOvrH5sRoiTmw^MyQXH_^(gBwfwb(d!L zy#JMWr6|>s(C&0djeP|CyJ7a#`as38%MsWxeNGL>&_{Hbi{t1oPplms*Cc&Tea(^tZN+jdE@1 zZvOk>z;Wrh>OBCDLlv!}gT4|}t?4?^g=7^9%CT2cj`@}fHmhXWWN7iul;+H68*J^6 zSLAFD+-{(umMDJ|1>anYbKH`K^;N}0M~}U%cQQGro*QoHG~P8?PF3&Gc{ACXYgYqF zoGF1U>Y$}5cU9883`oI4w`!v!Rec;!Y+!|1)OC>Emuoe!g49M+Aw9qJ(7cy}LoSBQ zDoJbi>ujV^*m#B%-j>#oe^z||iG~w9pUcQfN}j||!cBcOTESenbA=&vyw0KS67t9S zi$LAkN{56$xAQ!OPr=iQ8X~(+v{FRR?|evM@@@53R6+|G-Vqbb5$mgLED7){VSjyU zztrnQ9Zk=!qv_p!W48dwii*YenLr5^+w%!N92w9|1Bs#xY3`t~W`G5Q4f?Y?d;aLQ`ZS{`rN{;swj7%@LJSk*(QGPtCi=2f7E z-tKcN;cC&Zi_hth)lRJU7^i;}Tr}Vyr#n{Jbt4xyVZ9olPq>~aQfq=$tq1E&ssE-! z?19TB5H#;Y-!nB>Y}S8UB-N2W&4Aq4R`}4lbCNBhr)L0Z%3!CO-Bws`UH!FQN1p>u zz$8Kx@Coo#7_PQVgpts=bcavp?zxYg${7&84+6AuYTXtolKe_vb!c}U`*QHF3z0mh=2^|u zXvnP6lOmP)@*}WcwV+ip&`dC1zblzPa8m}_exX@WJvi_AbL(EeQF6oNWDMPuCi;p& zY%#-_g(;oY5pk|UGjobL!gkQvxvNw{@$k^M=qs7k0($8C*~8Wh*&N&rmoVzx7>HGi z6yN2? ztyl|9l$OD&4uqO9h9ca+%bhWYlQV-FxKH@4I{K@g?)@Z=R#PZp#=nDZK?{7)jCg59 zwLERMIIeMZqu>2fDsFOP4NxWMJlt_#DGAbZV47gey}XUL7OJC}VV(X}?TzGKW=nUU z4VpGH(Cox)HN9@702~@*75-zMmd(yO`Bkz#a=SUbN>#ph?)|S@%2Dv&g3Knkbmc*~ zbE#vnIP|$HczWA%XdO;&edtF^Dd_T`j!A7(c%5ZLxY_TBDA8!FYA+3wDmZp7vi;iR z>p`dN8+`^Po|(8ULKTJCwMx{Y8FA>V`aMH?4|unzYMJX*#7p8JJ9%*$gqYs{1%k@2 zOV9zQ6w&1%N0=Jm3_QpEVV9|8EW1%VR-#l=AoN2uPh$>ES%5$fz-4(NFN-R_}^~*ZIxb4rDBFMRqKCZgD;QsG~f zU!!+{ZB-9VEfK+Fh18m{yJxkETra4e?qGKE^2sXljHT=ORD;;jY?jnRdk7tS*rvz% zPH4O&e|^pMWR$IzJ$A|DO}a(L=wu~?Z=tMUN-GDFohDsA-gg;YDyjX|r7DTiFHyD@ z%cd31a1W}S0!i*Otg?SwnaxwtAXxGv!_s-)RPsGcbwgOQfEZM2uJt(mj=`sS(@)#V zw%M^XC1wWty%lvWqxdh;R3^}XsH0J$iZ0$LoTXg;@PgyD0IbMi@rh+`*YfYA-0Pgn zb=v)}_fBi*=(>)rR+bgSLG|AB4P8h9K+mQ^N>JZfuT+?uHZpA9XQ6R=bhg?QJ|7qJ z;p=u_5A!N22KwtwhCt_>z%J*G&30)y-(0zzxp0P81{Za2+pP^#DCN{q@FU?M=Ky%5 z?S0t?6Ox3^-b#jEwRP-SWBgUd!bETbYl3+D2*VdDLdbfR+&!TrfA4YWv>(_@4-%Q# z^i-Ivwy)b-5?oG!M)!;H`)m>*TET%h9)rU6#+nottZ2X1z*ix+T6(= zBhKaq+#x=rd>G6B*JwPynL7HxZ^v-+Pi8&7eHnxLJ1BCy*L9oU7sm0q(e^K(PlAqM zR|sUT{&2!Wrp(?hHWweAM(xYc^4TWI6fzWjsz>|9zWFZ3M5eZEdj4vjRLNVjw*LK$ z7D>z|^}vFlV_%aeDX^%G)*+!HkuYhN-VmxXKfZnbW;rEn1R3=iA7|7xEm-nXsOVrR z>1CFQzz!mlLn8Jg{jC6)`I?E@rM-$yl+(aBx!HK9_qr=rxayA(W{@YoDL^ZmR1yTX zU0D|$g1i1!5KXAsrNCNFUUE=tImF(HOA^K~0LAoPZ&W%*^pwUKVHg3mx}vjb2z<$mImG2gstDg zV}$!9b@s|07feSCiY_6~kHgV2*I{w%PrI7pdq_^ zh&b68o|-U25WW}Uo<_dudII$43l!-@x&yvQLXN-O(++#~@23CZAT=GN2R~&1fhdJY zzY!1^qTcVka^3USM!;vUue4Xk zCalh=m)xB;K?+2K#eBT0kVRk<5eySfX78W$8&pNh(+dJ+Ww;-X2rdEer)Jh>BD02-uV9ZwhS!}9ACU|djA&}UY;kr@ zIz*Zx{EfPYxdc7x5meFYvVmBku4sfghIL)SgM_~eq=*A8no>8RY1u+(;*(=ROT+ld z2AGZ~7T?R6h-J4`yDr^A6;Q$vJGt+`uDB-+t#at}w374_*JQQKc<0AJhiGD3pRK}U zih|REFCRIFjvT76%<|&8ZN#~Y2B}{JXd;+1F1Zn?g70_mxf|h~z0~^76VIoUf#)U>y=2EN|tJJSG=? zT>xZN_QsIQEcP9KA=~Lc&QxTF`5;Hq^?0kNq!j#ZgQ$c)z#W8|hSsJg#j1yY9ZE`u zIEH8|Y^;=`FjN(AUi?Pr=;`E=dd-cSsov#VEHEE%xTg&?W|mC(h}efnm6m zXL_u6vng54A|lgKhUoRkKvzld4K6IJ#cFKP=r*-~jV7($WiRJCB7yC;)T585gMt6N zoB-t{*DL<){!U<6HK`o9+o;7?m+NWj?e~hwX^wyVFEgE4HBColRI#`=x;;K4kQaC@ zDl*{I_wtYdh7KtsJlO-deM{H0`g6*zv%qu=6q6j(!~827C;LX6^PR_a^*ea71h)AH zWQH(Xy!2R_^yWyP%gVmhDj36$4atyN4YU~ma07%RhFcz-;0GlS_136~@s)L(rm?0T zAU?ktOJ$mIA@N$ZqON5-vr4C7yJP=dg|eJZnJg)xEnX3mykEMP#O%r(>7t#PRiNeS zrelF5$Ze1V6%zZaKsZOFb&KBS^#jg|an0WBhONZq<&b^T(7;IflFYE%$cx^;2A0@2 z)yCf|K?9N@bXZ6*krKO9BV>1Y7lG8vA zXLS3QY7-|945D9$bi#8kQ8X$c`GUJzb7m_A79#U7Z;f8goko43;T5# z7;B)frQ;UhXleGA7aMvneNW|gna5dF1pU`E98ZS?`?s|zQ><#fdiU0T zL@G|?3=rZa2f^_t*zV~w@7Y=og@8YX9?s*#LmJ?sMhaf(7;jDV02Y!D*FD7gc2kAQ zu-X^D4SpAvQhWHs47;@UX|uhHgMPr#q+Pvhp=G($BED9&(or+(%wv?YV^kppuy*Jc z=XV!I8>N$RZi(nw@4D1|IQNvz(>B5p#KRcp#PNxrsO^qcarwuPOdpEPX z+eRNEjl6}6?~8F1DUQ{oEp}AJn>D8Y^(^>A(VQtg#g7j98L!?20|(}rhwo&rjOB%0 zKWCL(93U(p9`xY%!2$^s2Lu9=B;lUGsLUIkEa?OYta+OqJ_2iJO|izkS4PTQpODm^ z$NJ$TK;B9b3S^0Qyj+xxruRs1bcd`{eN^PcWg{&2{Ax~<3H6VN)6927O;#>tr^<9a zAyjofmz`PfhkMV5<0?gtut-NR5EV`E+6(N`P^jqd$*9HWEZgr4i-3D2&~><67C!Y$ zU<#+V%k{(NAT>0zKm6x28S7J3JzQnGo0=@d4$fQVo$o@)J|tIYftg*Zqt%xX+HVX~ z_mD(g66y}fJt56Ymr&LHb<}3dJoCfHeGFO6eLL%xMQyMSopZO1z}gfarZRJRX+o5) z%e$Dr->N14Cc;B#V>c2m0wL|oK*K?5;Cs$3`DG0KnN(KK7Ok!jmQA@+h#C)gkQWWU z8>UJR6tT^Vt4UI)4{fkv4Yj~)udoihM_p_q040e&;!UnR-*~G>FN;Ix>YZUoqEMnQ zTHtIwJW;d8)mhy0PmngF>a=2~ji z>C?kA{_3hYbiAJ8Sq4NH11ao#ztRA^^yLX#l(-zGxT6z}eSoNz5gFZ5L)ShdO+X+9 zC8!kVm_CMfWqg)AO`_YFq4r0-Y>5sOIawWMD;G_Zwqq{T!NuxN4}Y#y{K_!QDml6- zFcmlUC%RX$x>dCCu07HCmYg{Z#Mm-{`b~#KY^h7d*kA4b&4Nk>kC8g`uifx**e^Xa zFn2Blo>T25(?3(W;xRMxkTsHar2SAP?F%NT_lNCtJ)W(JsAAuLK?HGt;f?&C;r!pb&jd?+8P`;Ql45W=BCV%2rF6MFs zd$1*XxuL`7y;u(9qwPE~CTN*04mKKRXqL-$90rL3H879h;@+~gHkgO=fD_5;MZItW z82Vq^xo5kid`jhfQ%z5#S=d&)cA>1z7?TX(%e>fbx}!eSseu8^T&8`7y-WxyNHiT+ z<=h9QcPWGI4V(A+uod$5evPF;6lVRlVWgk0EcKji(R4#fJhwQ`LEODo>K+0`0*diF z{gfZE!dxG*k@Of}Yi(W<+4>2A4*od69rD)HyqTq@2H|_DRnnOrc!6>*O0BZTvhaqSGLiO&W zN^YO0IkCLU$9`3UhTB0D8n!k%nAyX0a{O3}^X+CfYL9qh;GS&fw^Dqy8#W-C`<gyr;#s?G0?>>{C9*AXUdyt|0DT|_bgcpa;sx&CvJOb+0Oto{arNEh4> z0BnzGaYNAG7bG$6({2AH572Nd4}?$1u>c*i{lB&TFYSOm$J#;3vj3$Wu;=gIC", + "Fingerprint": "", + "SSHPublicKeyBody": "", + "Status": "Active", + "UploadDate": "" + } +} +``` + +Run bootstrap using the `SSHPublicKeyId` as the SSH username: + +```sh +flux bootstrap git \ + --url=ssh://@git-codecommit..amazonaws.com/v1/repos/ \ + --branch= \ + --private-key-file= \ + --password= \ + --path=clusters/my-cluster +``` + +You can also pipe the passphrase e.g. `echo key-passphrase | flux bootstrap git`. + +The SSH private key and the known hosts keys are stored in the cluster as a Kubernetes +secret named `flux-system` inside the `flux-system` namespace. + +{{% alert color="info" title="SSH Key rotation" %}} +To rotate the SSH key, delete the `flux-system` secret from the cluster and re-run +the bootstrap command using a new SSH private key. +{{% /alert %}} diff --git a/content/en/flux/installation/bootstrap/azure-devops.md b/content/en/flux/installation/bootstrap/azure-devops.md new file mode 100644 index 000000000..620781793 --- /dev/null +++ b/content/en/flux/installation/bootstrap/azure-devops.md @@ -0,0 +1,90 @@ +--- +title: Flux bootstrap for Azure DevOps +linkTitle: Azure DevOps +description: "How to bootstrap Flux with Azure DevOps" +weight: 60 +--- + +To install Flux on an AKS cluster using an Azure DevOps Git repository as the source of truth, +you can use the [`flux bootstrap git`](generic-git-server.md) command. + +{{% alert color="danger" title="Required permissions" %}} +To bootstrap Flux, the person running the command must have **cluster admin rights** for the target Kubernetes cluster. +It is also required that the person running the command to have **pull and push rights** for the Azure DevOps Git repository. +{{% /alert %}} + +## Azure DevOps PAT + +For accessing the Azure API, the boostrap command requires an Azure DevOps personal access token (PAT) +with pull and push permissions for Git repositories. + +Generate an [Azure DevOps PAT](https://docs.microsoft.com/en-us/azure/devops/organizations/accounts/use-personal-access-tokens-to-authenticate?view=azure-devops&tabs=preview-page) +and create a new repository to hold your Flux install and other Kubernetes resources. + +The Azure DevOps PAT can be exported as an environment variable: + +```sh +export GIT_PASSWORD= +``` + +If the `GIT_PASSWORD` env var is not set, the bootstrap command will prompt you to type it the token. + +You can also supply the token using a pipe e.g. `echo "" | flux bootstrap git`. + +## Bootstrap using a DevOps PAT + +Run the bootstrap for a repository using token-based authentication: + +```sh +flux bootstrap git \ + --token-auth=true \ + --url=https://dev.azure.com///_git/ \ + --branch=main \ + --path=clusters/my-cluster +``` + +When using `--token-auth`, the CLI and the Flux controllers running on the cluster will use the Azure DevOps PAT +to access the Git repository over HTTPS. + +Note that the Azure DevOps PAT is stored in the cluster as a **Kubernetes Secret** named `flux-system` +inside the `flux-system` namespace. + +{{% alert color="info" title="Token rotation" %}} +Note that Azure DevOps PAT have an expiry date. To rotate the token before it expires, +delete the `flux-system` secret from the cluster and re-run +the bootstrap command using a valid PAT. +{{% /alert %}} + +If you want to avoid storing your PAT in the cluster, set `--ssh-hostname` and the Flux controllers will use SSH: + +```shell +flux bootstrap git \ + --url=https://dev.azure.com///_git/ \ + --branch=main \ + --password=${GIT_PASSWORD} \ + --ssh-hostname=ssh.dev.azure.com \ + --ssh-key-algorithm=rsa \ + --ssh-rsa-bits=4096 \ + --path=clusters/my-cluster +``` + +The bootstrap command will generate a new SSH private key for the cluster, +and it will prompt you to add the SSH public key to your personal SSH keys. + +## Bootstrap without a DevOps PAT + +To bootstrap using a SSH key instead of a Azure DevOps PAT, run: + +```sh +flux bootstrap git \ + --url=ssh://git@ssh.dev.azure.com/v3/// + --branch= \ + --private-key-file= \ + --password= \ + --path=clusters/my-cluster +``` + +**Note** that you must generate an SSH private key and set the public key to your personal SSH keys in advance. + +For more information on how to use the `flux bootstrap git` command, +please see the generic Git server [documentation](generic-git-server.md). diff --git a/content/en/flux/installation/bootstrap/bitbucket.md b/content/en/flux/installation/bootstrap/bitbucket.md new file mode 100644 index 000000000..cab23eace --- /dev/null +++ b/content/en/flux/installation/bootstrap/bitbucket.md @@ -0,0 +1,135 @@ +--- +title: Flux bootstrap for Bitbucket +linkTitle: Bitbucket +description: "How to bootstrap Flux with Bitbucket Server and Data Center" +weight: 40 +--- + +The [flux bootstrap bitbucket-server](/flux/cmd/flux_bootstrap_bitbucket-server/) command deploys the Flux controllers +on a Kubernetes cluster and configures the controllers to sync the cluster state from a Bitbucket project. +Besides installing the controllers, the bootstrap command pushes the Flux manifests to the Bitbucket project +and configures Flux to update itself from Git. + +After running the bootstrap command, any operation on the cluster (including Flux upgrades) +can be done via Git push, without the need to connect to the Kubernetes cluster. + +{{% alert color="danger" title="Required permissions" %}} +To bootstrap Flux, the person running the command must have **cluster admin rights** for the target Kubernetes cluster. +It is also required that the person running the command to be the **owner** of the Bitbucket project, +or to have admin rights of a Bitbucket group. +{{% /alert %}} + +{{% alert color="info" title="Bitbucket versions" %}} +This bootstrap command works only with Bitbucket Server and Data Center. +For Bitbucket Cloud, please use the [generic bootstrap](generic-git-server.md) procedure. +{{% /alert %}} + +## Bitbucket HTTP Access Token + +For accessing the Bitbucket API, the bootstrap command requires a +[Bitbucket HTTP Access Token](https://confluence.atlassian.com/bitbucketserver/http-access-tokens-939515499.html) +with administration permissions. + +The Bitbucket HTTP access token can be exported as an environment variable: + +```sh +export BITBUCKET_TOKEN= +``` + +If the `BITBUCKET_TOKEN` env var is not set, the bootstrap command will prompt you to type it the token. +You can also supply the token using a pipe e.g. `echo "" | flux bootstrap bitbucket-server`. + +## Bitbucket Personal Account + +Run the bootstrap for a repository on your personal Bitbucket Server account: + +```sh +flux bootstrap bitbucket-server \ + --token-auth \ + --hostname=my-bitbucket-server.com \ + --owner=my-bitbucket-username \ + --repository=my-repository \ + --branch=main \ + --path=clusters/my-cluster \ + --personal +``` + +If the specified repository does not exist, Flux will create it for you as private. If you wish to create +a public repository, set `--private=false`. + +When using `--token-auth`, the CLI and the Flux controllers running on the cluster will use the Bitbucket +token to access the Git repository over HTTPS. + +{{% alert color="danger" title="PAT secret" %}} +Note that the Bitbucket token is stored in the cluster as a **Kubernetes Secret** named `flux-system` +inside the `flux-system` namespace. If you want to avoid storing your token in the cluster, +please see how to configure [Bitbucket SSH access keys](#bitbucket-ssh-access-keys). +{{% /alert %}} + +## Bitbucket Personal Project + +Run the bootstrap for a repository owned by a Bitbucket Server project: + +```sh +flux bootstrap bitbucket-server \ + --token-auth \ + --hostname=my-bitbucket-server.com \ + --owner=my-bitbucket-project \ + --username=my-bitbucket-username \ + --repository=my-repository \ + --branch=main \ + --path=clusters/my-cluster \ + --group=group-name +``` + +When you specify a list of groups, those teams will be granted write access to the repository. + +**Note:** The `username` is mandatory for `project` owned repositories. +The specified user must own the `BITBUCKET_TOKEN` and have sufficient rights +on the target `project` to create repositories. + +## Bitbucket SSH Access Keys + +If you want to bootstrap Flux using SSH instead of HTTP/S, you can set `--token-auth=false` and the Flux CLI +will use the Bitbucket token to set a SSH access key for your repository. + +When using SSH, the bootstrap command will generate a SSH private key. The private key is stored +in the cluster as a Kubernetes secret named `flux-system` inside the `flux-system` namespace. + +The generated SSH key defaults to `ECDSA P-384`, to change the format use `--ssh-key-algorithm` and `--ssh-ecdsa-curve`. + +By default, the SSH key is set to read-only access. +If you're using Flux image automation, you must give it write access with `--read-write-key=true`. + +To run the bootstrap for Bitbucket server with a custom SSH hostname and port: + +```sh +flux bootstrap bitbucket-server \ + --hostname=my-bitbucket-server.com \ + --ssh-hostname=my-bitbucket-server.com:7999 \ + --owner=my-bitbucket-project \ + --username=my-bitbucket-username \ + --repository=my-repository \ + --branch=main \ + --path=clusters/my-cluster +``` + +## Bootstrap without a Bitbucket token + +For existing Bitbucket repositories, you can bootstrap Flux over SSH without using a Bitbucket token. + +To use a SSH key instead of a Bitbucket token, the command changes to `flux bootstrap git`: + +```shell +flux bootstrap git \ + --url=ssh://git@// \ + --branch= \ + --private-key-file= \ + --password= \ + --path=clusters/my-cluster +``` + +**Note** that you must generate a SSH private key and set the public key as the access key on Bitbucket in advance. + +For more information on how to use the `flux bootstrap git` command, +please see the generic Git server [documentation](generic-git-server.md). diff --git a/content/en/flux/installation/bootstrap/generic-git-server.md b/content/en/flux/installation/bootstrap/generic-git-server.md new file mode 100644 index 000000000..04ca9956e --- /dev/null +++ b/content/en/flux/installation/bootstrap/generic-git-server.md @@ -0,0 +1,114 @@ +--- +title: Flux bootstrap for Git servers +linkTitle: Generic Git server +description: "How to bootstrap Flux with a generic Git server" +weight: 20 +--- + +The [flux bootstrap git](/flux/cmd/flux_bootstrap_git/) command deploys the Flux controllers +on a Kubernetes cluster and configures the controllers to sync the cluster state from a Git repository. +Besides installing the controllers, the bootstrap command pushes the Flux manifests to the Git repository +and configures Flux to update itself from Git. + +After running the bootstrap command, any operation on the cluster (including Flux upgrades) +can be done via Git push, without the need to connect to the Kubernetes cluster. + +{{% alert color="danger" title="Required permissions" %}} +To bootstrap Flux, the person running the command must have **cluster admin rights** for the target Kubernetes cluster. +It is also required that the person running the command to have **push rights** to the Git repository. +{{% /alert %}} + +## SSH Private Key + +Run bootstrap for an exiting Git repository and authenticate with a SSH key which has pull and push access: + +```sh +flux bootstrap git \ + --url=ssh://git@// \ + --branch=main \ + --private-key-file= \ + --password= \ + --path=clusters/my-cluster +``` + +The private key is stored in the cluster as a Kubernetes secret named `flux-system` +inside the `flux-system` namespace. + +{{% alert color="info" title="SSH Key rotation" %}} +To regenerate the SSH private key and known hosts keys, +delete the `flux-system` secret from the cluster and run: + +```shell +flux create secret git flux-system \ + --url=ssh://git@// \ + --ssh-key-algorithm=rsa \ + --ssh-rsa-bits=4096 +``` + +The CLI will prompt you to add the SSH public key as a deploy key to your repository. +{{% /alert %}} + +## SSH Agent + +Run bootstrap for an exiting Git repository and authenticate with your SSH agent: + +```sh +flux bootstrap git \ + --url=ssh://git@// \ + --branch=main \ + --path=clusters/my-cluster +``` + +{{% alert color="warning" title="SSH hostname" %}} +If the Flux controllers must connect to a different SSH endpoint +than the CLI, you can set the SSH hostname and port for the cluster +with `--ssh-hostname=`. +Note that if set, your SSH hostname and port could be overwritten by +your [ssh_config](https://linux.die.net/man/5/ssh_config). +{{% /alert %}} + +When using the SSH Agent, the bootstrap command will generate a new SSH private key for the cluster, +and it will prompt you to add the SSH public key as a deploy key to your repository. + +The generated SSH key defaults to `ECDSA P-384`, to change the format use `--ssh-key-algorithm` and `--ssh-ecdsa-curve`. + +## HTTPS basic auth + +If your Git server has basic auth enabled, you can bootstrap Flux over HTTPS with: + +```sh +flux bootstrap git \ + --url=https://// \ + --username= \ + --password= \ + --token-auth=true \ + --path=clusters/my-cluster +``` + +You can also supply the password or Git token using a pipe e.g. `echo "" | flux bootstrap git`. + +If your Git server uses a self-signed TLS certificate, you can specify the CA file with +`--ca-file=`. + +## Boostrap multiple clusters + +With `--path` you can configure the directory which will be used to reconcile the target cluster. +To control multiple clusters from the same Git repository, you have to set a unique path per +cluster e.g. `clusters/staging` and `clusters/production`: + +```sh +./clusters/ +├── staging # <- path=clusters/staging +│   └── flux-system # <- namespace dir generated by bootstrap +│   ├── gotk-components.yaml +│   ├── gotk-sync.yaml +│   └── kustomization.yaml +└── production # <- path=clusters/production + └── flux-system +``` + +{{% 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 %}} diff --git a/content/en/flux/installation/bootstrap/github.md b/content/en/flux/installation/bootstrap/github.md new file mode 100644 index 000000000..a2b029f44 --- /dev/null +++ b/content/en/flux/installation/bootstrap/github.md @@ -0,0 +1,150 @@ +--- +title: Flux bootstrap for GitHub +linkTitle: GitHub +description: "How to bootstrap Flux with GitHub and GitHub Enterprise" +weight: 20 +--- + +The [flux bootstrap github](/flux/cmd/flux_bootstrap_github/) command deploys the Flux controllers +on a Kubernetes cluster and configures the controllers to sync the cluster state from a GitHub repository. +Besides installing the controllers, the bootstrap command pushes the Flux manifests to the GitHub repository +and configures Flux to update itself from Git. + +After running the bootstrap command, any operation on the cluster (including Flux upgrades) +can be done via Git push, without the need to connect to the Kubernetes cluster. + +{{% alert color="danger" title="Required permissions" %}} +To bootstrap Flux, the person running the command must have **cluster admin rights** for the target Kubernetes cluster. +It is also required that the person running the command to be the **owner** of the GitHub repository, +or to have admin rights of a GitHub organization. +{{% /alert %}} + +## GitHub PAT + +For accessing the GitHub API, the boostrap command requires a GitHub personal access token (PAT) +with administration permissions. + +The GitHub PAT can be exported as an environment variable: + +```sh +export GITHUB_TOKEN= +``` + +If the `GITHUB_TOKEN` env var is not set, the bootstrap command will prompt you to type it the token. + +You can also supply the token using a pipe e.g. `echo "" | flux bootstrap github`. + +## GitHub Personal Account + +If you want to bootstrap Flux for a repository owned by a personal account, you can generate a +[GitHub PAT](https://help.github.com/en/github/authenticating-to-github/creating-a-personal-access-token-for-the-command-line) +that can create repositories by checking all permissions under `repo`. + +If you want to use an existing repository, the PAT's user must have `admin` +[permissions](https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization#permissions-for-each-role). + +Run the bootstrap for a repository on your personal GitHub account: + +```sh +flux bootstrap github \ + --token-auth \ + --owner=my-github-username \ + --repository=my-repository-name \ + --branch=main \ + --path=clusters/my-cluster \ + --personal +``` + +If the specified repository does not exist, Flux will create it for you as private. If you wish to create +a public repository, set `--private=false`. + +When using `--token-auth`, the CLI and the Flux controllers running on the cluster will use the GitHub PAT +to access the Git repository over HTTPS. + +{{% alert color="danger" title="PAT secret" %}} +Note that the GitHub PAT is stored in the cluster as a **Kubernetes Secret** named `flux-system` +inside the `flux-system` namespace. If you want to avoid storing your PAT in the cluster, +please see how to configure [GitHub Deploy Keys](#github-deploy-keys). +{{% /alert %}} + +## GitHub Organization + +If you want to bootstrap Flux for a repository owned by an GitHub organization, +it is recommended to creat a dedicated user for Flux under your organization. + +Generate a GitHub PAT for the Flux user that can create repositories by checking all permissions under `repo`. + +If you want to use an existing repository, the Flux user must have `admin` permissions for that repository. + +Run the bootstrap for a repository owned by a GitHub organization: + +```sh +flux bootstrap github \ + --token-auth \ + --owner=my-github-organization \ + --repository=my-repository \ + --branch=main \ + --path=clusters/my-cluster +``` + +When creating a new repository, you can specify a list of GitHub teams with `--team=team1-slug,team2-slug`, +those teams will be granted maintainer access to the repository. + +## GitHub Enterprise + +To run the bootstrap for a repository hosted on GitHub Enterprise, you have to specify your GitHub hostname: + +```sh +flux bootstrap github \ + --token-auth \ + --hostname=my-github-enterprise.com \ + --owner=my-github-organization \ + --repository=my-repository \ + --branch=main \ + --path=clusters/my-cluster +``` + +If you want use SSH and [GitHub deploy keys](#github-deploy-keys), +set `--token-auth=false` and provide the SSH hostname with `--ssh-hostname=my-github-enterprise.com`. + +## GitHub Deploy Keys + +If you want to bootstrap Flux using SSH instead of HTTP/S, you can set `--token-auth=false` and the Flux CLI +will use the GitHub PAT to set a deploy key for your repository. + +When using SSH, the bootstrap command will generate a SSH private key. The private key is stored +in the cluster as a Kubernetes secret named `flux-system` inside the `flux-system` namespace. + +The generated SSH key defaults to `ECDSA P-384`, to change the format use `--ssh-key-algorithm` and `--ssh-ecdsa-curve`. + +The SSH public key, is used to create a GitHub deploy key. +The deploy key is linked to the personal access token used to authenticate. + +By default, the GitHub deploy key is set to read-only access. +If you're using Flux image automation, you must give it write access with `--read-write-key=true`. + +{{% alert color="info" title="Deploy Key rotation" %}} +Note that when the PAT is removed or when it expires, the GitHub deploy key will stop working. +To regenerate the deploy key, delete the `flux-system` secret from the cluster and re-run +the bootstrap command using a valid GitHub PAT. +{{% /alert %}} + +## Bootstrap without a GitHub PAT + +For existing GitHub repositories, you can bootstrap Flux over SSH without using a GitHub PAT. + +To use a SSH key instead of a GitHub PAT, the command changes to `flux bootstrap git`: + +```shell +flux bootstrap git \ + --url=ssh://git@github.com// \ + --branch= \ + --private-key-file= \ + --password= \ + --path=clusters/my-cluster +``` + +**Note** that you must generate a SSH private key and set the public key as a deploy key on GitHub in advance. + +For more information on how to use the `flux bootstrap git` command, +please see the generic Git server [documentation](generic-git-server.md). diff --git a/content/en/flux/installation/bootstrap/gitlab.md b/content/en/flux/installation/bootstrap/gitlab.md new file mode 100644 index 000000000..c4855338a --- /dev/null +++ b/content/en/flux/installation/bootstrap/gitlab.md @@ -0,0 +1,132 @@ +--- +title: Flux bootstrap for GitLab +linkTitle: GitLab +description: "How to bootstrap Flux with GitLab and GitLab Enterprise" +weight: 30 +--- + +The [flux bootstrap gitlab](/flux/cmd/flux_bootstrap_gitlab/) command deploys the Flux controllers +on a Kubernetes cluster and configures the controllers to sync the cluster state from a GitLab project. +Besides installing the controllers, the bootstrap command pushes the Flux manifests to the GitLab project +and configures Flux to update itself from Git. + +After running the bootstrap command, any operation on the cluster (including Flux upgrades) +can be done via Git push, without the need to connect to the Kubernetes cluster. + +{{% alert color="danger" title="Required permissions" %}} +To bootstrap Flux, the person running the command must have **cluster admin rights** for the target Kubernetes cluster. +It is also required that the person running the command to be the **owner** of the GitLab project, +or to have admin rights of a GitLab group. +{{% /alert %}} + +## GitLab PAT + +For accessing the GitLab API, the boostrap command requires a GitLab personal access token (PAT) +with complete read/write access to the GitLab API. + +The GitLab PAT can be exported as an environment variable: + +```sh +export GITLAB_TOKEN= +``` + +If the `GITLAB_TOKEN` env var is not set, the bootstrap command will prompt you to type it the token. + +You can also supply the token using a pipe e.g. `echo "" | flux bootstrap gitlab`. + +## GitLab Personal Account + +Run the bootstrap for a project on your personal GitLab account: + +```sh +flux bootstrap gitlab \ + --deploy-token-auth \ + --owner=my-gitlab-username \ + --repository=my-project \ + --branch=master \ + --path=clusters/my-cluster \ + --personal +``` + +If the specified project does not exist, Flux will create it for you as private. If you wish to create +a public project, set `--private=false`. + +When using `--deploy-token-auth`, the CLI generates a +[GitLab project deploy token](https://docs.gitlab.com/ee/user/project/deploy_tokens/) +and stores it in the cluster as a Kubernetes Secret named `flux-system` +inside the `flux-system` namespace. + +{{% alert color="danger" title="Deploy token read-only" %}} +Note that project deploy tokens grant read-only access to Git. +If you want to use Flux image automation, please see how to configure +[GitLab Deploy Keys](#gitlab-deploy-keys) with read-write Git accesses. +{{% /alert %}} + +## GitLab Groups + +Run the bootstrap for a project owned by a GitLab (sub)group: + +```sh +flux bootstrap gitlab \ + --deploy-token-auth \ + --owner=my-gitlab-group/my-gitlab-subgroup \ + --repository=my-project \ + --branch=master \ + --path=clusters/my-cluster +``` + +## GitLab Enterprise + +To run the bootstrap for a project hosted on GitLab on-prem or enterprise, you have to specify your GitLab hostname: + +```sh +flux bootstrap gitlab \ + --token-auth \ + --hostname=my-gitlab-enterprise.com \ + --owner=my-gitlab-group \ + --repository=my-project \ + --branch=master \ + --path=clusters/my-cluster +``` + +If you want use SSH and [GitLab deploy keys](#gitlab-deploy-keys), +set `--token-auth=false` and provide the SSH hostname with `--ssh-hostname=my-gitlab-enterprise.com`. + +## GitLab Deploy Keys + +If you want to bootstrap Flux using SSH instead of HTTP/S, you can set `--token-auth=false` +and the Flux CLI will use the GitLab PAT to set a deploy key for your project. + +When using SSH, the bootstrap command will generate a SSH private key. The private key is stored +in the cluster as a Kubernetes secret named `flux-system` inside the `flux-system` namespace. + +The generated SSH key defaults to `ECDSA P-384`, to change the format use `--ssh-key-algorithm` and `--ssh-ecdsa-curve`. + +The SSH public key, is used to create a GitLab deploy key. +By default, the GitLab deploy key is set to read-only access. +If you're using Flux image automation, you must give it write access with `--read-write-key=true`. + +{{% alert color="info" title="Deploy Key rotation" %}} +To regenerate the deploy key, delete the `flux-system` secret from the cluster and re-run +the bootstrap command using a valid GitLab PAT. +{{% /alert %}} + +## Bootstrap without a GitLab PAT + +For existing GitLab repositories, you can bootstrap Flux over SSH without using a GitLab PAT. + +To use an SSH key instead of a GitLab PAT, the command changes to `flux bootstrap git`: + +```shell +flux bootstrap git \ + --url=ssh://git@gitlab.com// \ + --branch= \ + --private-key-file= \ + --password= \ + --path=clusters/my-cluster +``` + +**Note** that you must generate an SSH private key and set the public key as a deploy key on GitLab in advance. + +For more information on how to use the `flux bootstrap git` command, +please see the generic Git server [documentation](generic-git-server.md). diff --git a/content/en/flux/installation/bootstrap/google-cloud-source.md b/content/en/flux/installation/bootstrap/google-cloud-source.md new file mode 100644 index 000000000..5a4dfe8ca --- /dev/null +++ b/content/en/flux/installation/bootstrap/google-cloud-source.md @@ -0,0 +1,40 @@ +--- +title: Flux bootstrap for Google Cloud Source +linkTitle: Google Cloud Source +description: "How to bootstrap Flux with Google Cloud Source Repository" +weight: 70 +--- + +To install Flux on a GKE cluster using a Google Cloud Source repository as the source of truth, +you can use the [`flux bootstrap git`](generic-git-server.md) command. + +{{% alert color="danger" title="Required permissions" %}} +To bootstrap Flux, the person running the command must have **cluster admin rights** for the target Kubernetes cluster. +It is also required that the person running the command to have **pull and push rights** for the Google Cloud Source repository. +{{% /alert %}} + +## Bootstrap over SSH + +First create a new repository to hold your Flux install and other Kubernetes resources. +Then generate a SSH key and add the SSH public key to your personal SSH keys on Google Cloud. + +Run bootstrap using the SSH private key and passphrase: + +```sh +flux bootstrap git \ + --url=ssh://s@source.developers.google.com:2022/p//r/ \ + --branch= \ + --private-key-file= \ + --password= \ + --path=clusters/my-cluster +``` + +You can also pipe the passphrase e.g. `echo key-passphrase | flux bootstrap git`. + +The SSH private key and the known hosts keys are stored in the cluster as a Kubernetes +secret named `flux-system` inside the `flux-system` namespace. + +{{% alert color="info" title="SSH Key rotation" %}} +To rotate the SSH public key, delete the `flux-system` secret from the cluster and re-run +the bootstrap command using a new SSH private key. +{{% /alert %}} From 3ac6e663f508fb6362855cce7ed7b7ce1fa8123c Mon Sep 17 00:00:00 2001 From: Stefan Prodan Date: Thu, 17 Aug 2023 12:35:10 +0300 Subject: [PATCH 3/7] Add bootstrap configuration tasks Signed-off-by: Stefan Prodan --- .../flux/installation/configuration/_index.md | 7 + .../installation/configuration/air-gapped.md | 66 ++++++ .../configuration/boostrap-customization.md | 72 +++++++ .../configuration/deploy-key-rotation.md | 35 ++++ .../configuration/helm-dns-lookup.md | 28 +++ .../configuration/helm-drift-detection.md | 43 ++++ .../configuration/helm-oom-detection.md | 48 +++++ .../installation/configuration/openshift.md | 70 +++++++ .../configuration/optional-components.md | 66 ++++++ .../configuration/proxy-setting.md | 79 +++++++ .../configuration}/sharding.md | 10 +- .../configuration/vertical-scaling.md | 192 ++++++++++++++++++ .../configuration/workload-identity.md | 118 +++++++++++ 13 files changed, 829 insertions(+), 5 deletions(-) create mode 100644 content/en/flux/installation/configuration/_index.md create mode 100644 content/en/flux/installation/configuration/air-gapped.md create mode 100644 content/en/flux/installation/configuration/boostrap-customization.md create mode 100644 content/en/flux/installation/configuration/deploy-key-rotation.md create mode 100644 content/en/flux/installation/configuration/helm-dns-lookup.md create mode 100644 content/en/flux/installation/configuration/helm-drift-detection.md create mode 100644 content/en/flux/installation/configuration/helm-oom-detection.md create mode 100644 content/en/flux/installation/configuration/openshift.md create mode 100644 content/en/flux/installation/configuration/optional-components.md create mode 100644 content/en/flux/installation/configuration/proxy-setting.md rename content/en/flux/{cheatsheets => installation/configuration}/sharding.md (97%) create mode 100644 content/en/flux/installation/configuration/vertical-scaling.md create mode 100644 content/en/flux/installation/configuration/workload-identity.md diff --git a/content/en/flux/installation/configuration/_index.md b/content/en/flux/installation/configuration/_index.md new file mode 100644 index 000000000..80d21bf48 --- /dev/null +++ b/content/en/flux/installation/configuration/_index.md @@ -0,0 +1,7 @@ +--- +title: "Flux configuration" +linkTitle: "Configuration" +description: "How to configure Flux during bootstrap" +weight: 30 +--- + diff --git a/content/en/flux/installation/configuration/air-gapped.md b/content/en/flux/installation/configuration/air-gapped.md new file mode 100644 index 000000000..8a1ffb0f8 --- /dev/null +++ b/content/en/flux/installation/configuration/air-gapped.md @@ -0,0 +1,66 @@ +--- +title: "Flux air-gapped installation" +linkTitle: "Air-Gapped installation" +description: "How to configure Flux for air-gapped clusters" +weight: 15 +--- + +Flux can be installed on air-gapped environments where the Kubernetes cluster, +the container registry and the Git server are not connected to the internet. + +## Copy the container images + +On a machine with access to `github.com` and `ghcr.io`, +download the Flux CLI from [GitHub releases page](https://github.com/fluxcd/flux2/releases). + +List the Flux container images with: + +```console +$ flux install --export | grep ghcr.io +image: ghcr.io/fluxcd/source-controller:v1.0.0 +image: ghcr.io/fluxcd/kustomize-controller:v1.0.0 +image: ghcr.io/fluxcd/helm-controller:v0.35.0 +image: ghcr.io/fluxcd/notification-controller:v1.0.0 +``` + +Copy each controller image to your private container registry using +[crane](https://github.com/google/go-containerregistry/blob/main/cmd/crane/README.md): + +```sh +crane copy ghcr.io/fluxcd/source-controller:v1.0.0 registry.internal/fluxcd/source-controller:v1.0.0 +``` + +## Configure the image pull secret + +From a machine inside the air-gapped network +create the pull secret in the `flux-system` namespace: + +```sh +kubectl create ns flux-system + +kubectl -n flux-system create secret generic regcred \ + --from-file=.dockerconfigjson=/.docker/config.json \ + --type=kubernetes.io/dockerconfigjson +``` + +## Bootstrap Flux + +Copy the Flux CLI binary to the machine inside the air-gapped network and +run bootstrap using the images from your private registry: + +```sh +flux bootstrap git \ + --registry=registry.internal/fluxcd \ + --image-pull-secret=regcred \ + --url=ssh://git@// \ + --branch= \ + --private-key-file= \ + --password= \ + --path=clusters/my-cluster +``` + +**Note** that you must generate a SSH private key and set the public key +as the deploy key on your Git server in advance. + +For more information on how to use the `flux bootstrap git` command, +please see the generic Git server [documentation](/flux/installation/bootstrap/generic-git-server/). diff --git a/content/en/flux/installation/configuration/boostrap-customization.md b/content/en/flux/installation/configuration/boostrap-customization.md new file mode 100644 index 000000000..83fb90158 --- /dev/null +++ b/content/en/flux/installation/configuration/boostrap-customization.md @@ -0,0 +1,72 @@ +--- +title: "Flux bootstrap customization" +linkTitle: "Bootstrap customization" +description: "How to customize the Flux controllers during bootstrap" +weight: 3 +--- + +To customize the Flux controllers during [bootstrap](/flux/installation#bootstrap-with-flux-cli), +first you'll need to create a Git repository and clone it locally. + +Create the file structure required by bootstrap with: + +```sh +mkdir -p clusters/my-cluster/flux-system +touch clusters/my-cluster/flux-system/gotk-components.yaml \ + clusters/my-cluster/flux-system/gotk-sync.yaml \ + clusters/my-cluster/flux-system/kustomization.yaml +``` + +The Flux controller deployments, container command arguments, node affinity, etc can be customized using +[Kustomize strategic merge patches and JSON patches](https://github.com/kubernetes-sigs/kustomize/blob/master/examples/patchMultipleObjects.md). + +You can make changes to all controllers using a single patch or +target a specific controller: + +```yaml +apiVersion: kustomize.config.k8s.io/v1beta1 +kind: Kustomization +resources: # manifests generated during bootstrap + - gotk-components.yaml + - gotk-sync.yaml +patches: + # target all controllers + - patch: | + # strategic merge or JSON patch + target: + kind: Deployment + labelSelector: "app.kubernetes.io/part-of=flux" + # target controllers by name + - patch: | + # strategic merge or JSON patch + target: + kind: Deployment + name: "(kustomize-controller|helm-controller)" + # add a command argument to a single controller + - patch: | + - op: add + path: /spec/template/spec/containers/0/args/- + value: --concurrent=5 + target: + kind: Deployment + name: "source-controller" +``` + +Push the changes to main branch: + +```sh +git add -A && git commit -m "init flux" && git push +``` + +And run the bootstrap for `clusters/my-cluster`: + +```sh +flux bootstrap git \ + --url=ssh://git@// \ + --branch=main \ + --path=clusters/my-cluster +``` + +To make further amendments, pull the changes locally, +edit the kustomization.yaml file, push the changes upstream +and rerun bootstrap. diff --git a/content/en/flux/installation/configuration/deploy-key-rotation.md b/content/en/flux/installation/configuration/deploy-key-rotation.md new file mode 100644 index 000000000..7627b45c4 --- /dev/null +++ b/content/en/flux/installation/configuration/deploy-key-rotation.md @@ -0,0 +1,35 @@ +--- +title: "Flux deploy key rotation" +linkTitle: "Deploy key rotation" +description: "How to rotate the deploy key generated at bootstrap" +weight: 19 +--- + +There are several reasons you may want to rotate the deploy key: + +- The token used to generate the key has expired. +- The key has been compromised. +- You want to change the scope of the key, e.g. to allow write access using the `--read-write-key` flag to `flux bootstrap`. + +While you can run `flux bootstrap` repeatedly, be aware that the `flux-system` Kubernetes Secret is never overwritten. +You need to manually rotate the key as described here. + +To rotate the SSH key generated at bootstrap, first delete the secret from the cluster with: + +```sh +kubectl -n flux-system delete secret flux-system +``` + +Then you have two alternatives to generate a new key: + +1. Generate a new secret with + + ```sh + flux create secret git flux-system \ + --url=ssh://git@// + ``` + The above command will print the SSH public key, once you set it as the deploy key, + Flux will resume all operations. +2. Run `flux bootstrap ...` again. This will generate a new key pair and, + depending on which Git provider you use, print the SSH public key that you then + set as deploy key or automatically set the deploy key (e.g. with GitHub). diff --git a/content/en/flux/installation/configuration/helm-dns-lookup.md b/content/en/flux/installation/configuration/helm-dns-lookup.md new file mode 100644 index 000000000..8105e5a87 --- /dev/null +++ b/content/en/flux/installation/configuration/helm-dns-lookup.md @@ -0,0 +1,28 @@ +--- +title: Flux DNS lookups for Helm Releases +linkTitle: Helm DNS lookups +description: "How to allow Helm DNS lookups" +weight: 22 +--- +By default, the helm-controller will not perform DNS lookups when rendering Helm +templates in clusters because of potential [security +implications](https://github.com/helm/helm/security/advisories/GHSA-pwcw-6f5g-gxf8). + +To enable DNS lookups [during bootstrap](boostrap-customization.md) add the following patches to the flux-system `kustomization.yaml`: + +```yaml +apiVersion: kustomize.config.k8s.io/v1beta1 +kind: Kustomization +resources: + - gotk-components.yaml + - gotk-sync.yaml +patches: + - patch: | + # Allow Helm DNS lookups + - op: add + path: /spec/template/spec/containers/0/args/- + value: --feature-gates=AllowDNSLookups=true + target: + kind: Deployment + name: helm-controller +``` diff --git a/content/en/flux/installation/configuration/helm-drift-detection.md b/content/en/flux/installation/configuration/helm-drift-detection.md new file mode 100644 index 000000000..4bbce3888 --- /dev/null +++ b/content/en/flux/installation/configuration/helm-drift-detection.md @@ -0,0 +1,43 @@ +--- +title: Flux drift detection for Helm Releases +linkTitle: Helm drift detection +description: "How to enable Helm drift detection in Flux" +weight: 20 +--- + +At present, Helm releases are not by default checked for drift compared to +cluster-state. To enable experimental drift detection, you must add the +`--feature-gates=DetectDrift=true` flag to the helm-controller Deployment. + +Enabling it will cause the controller to check for drift on all Helm releases +using a dry-run Server Side Apply, triggering an upgrade if a change is detected. +For detailed information about this feature, [refer to the +documentation](/flux/components/helm/helmreleases/#drift-detection). + +To enable drift detection [during bootstrap](boostrap-customization.md) add the following patches to the flux-system `kustomization.yaml`: + +```yaml +apiVersion: kustomize.config.k8s.io/v1beta1 +kind: Kustomization +resources: + - gotk-components.yaml + - gotk-sync.yaml +patches: + - patch: | + # Enable drift detection and correction + - op: add + path: /spec/template/spec/containers/0/args/- + value: --feature-gates=DetectDrift=true,CorrectDrift=true + # Enable debug logging for diff output (optional) + - op: replace + path: /spec/template/spec/containers/0/args/2 + value: --log-level=debug + target: + kind: Deployment + name: helm-controller +``` + +{{% alert color="info" title="Disable drift correction" %}} +To help aid transition to this new feature, it is possible to enable drift detection without it correcting drift. +This can be done by setting the `CorrectDrift=false` feature flag in the above patch. +{{% /alert %}} diff --git a/content/en/flux/installation/configuration/helm-oom-detection.md b/content/en/flux/installation/configuration/helm-oom-detection.md new file mode 100644 index 000000000..99a203aa6 --- /dev/null +++ b/content/en/flux/installation/configuration/helm-oom-detection.md @@ -0,0 +1,48 @@ +--- +title: Flux near OOM detection for Helm +linkTitle: Helm OOM detection +description: "How to enable Helm near OOM detection" +weight: 21 +--- + +When memory usage of the helm-controller exceeds the configured limit, the +controller will forcefully be killed by Kubernetes' OOM killer. This may result +in a Helm release being left in a `pending-*` state which causes the HelmRelease +to get stuck in an `another operation (install/upgrade/rollback) is in progress` +error loop. + +To prevent this from happening, the controller offers an OOM watcher which can +be enabled with `--feature-gates=OOMWatch=true`. When enabled, the memory usage +of the controller will be monitored, and a graceful shutdown will be triggered +when it reaches a certain threshold (default 95% utilization). + +When gracefully shutting down, running Helm actions may mark the release as +`failed`. Because of this, enabling this feature is best combined with +thoughtful [remediation strategies](/flux/components/helm/helmreleases/#configuring-failure-remediation). + +To enable near OOM detection [during bootstrap](boostrap-customization.md) add the following patches to the flux-system `kustomization.yaml`: + +```yaml +apiVersion: kustomize.config.k8s.io/v1beta1 +kind: Kustomization +resources: + - gotk-components.yaml + - gotk-sync.yaml +patches: + - patch: | + # Enable OOM watch feature + - op: add + path: /spec/template/spec/containers/0/args/- + value: --feature-gates=OOMWatch=true + # Threshold at which to trigger a graceful shutdown (optional, default 95%) + - op: add + path: /spec/template/spec/containers/0/args/- + value: --oom-watch-memory-threshold=95 + # Interval at which to check memory usage (optional, default 500ms) + - op: add + path: /spec/template/spec/containers/0/args/- + value: --oom-watch-interval=500ms + target: + kind: Deployment + name: helm-controller +``` diff --git a/content/en/flux/installation/configuration/openshift.md b/content/en/flux/installation/configuration/openshift.md new file mode 100644 index 000000000..c680eed2a --- /dev/null +++ b/content/en/flux/installation/configuration/openshift.md @@ -0,0 +1,70 @@ +--- +title: "Flux OpenShift installation" +linkTitle: "OpenShift installation" +description: "How to configure Flux for OpenShift" +weight: 15 +--- + +{{% alert color="danger" title="Required permissions" %}} +To bootstrap Flux, the person running the command must have **cluster admin rights** for the target OpenShift cluster. +It is also required to prepare a Git repository as described in the [bootstrap customization](boostrap-customization.md). +{{% /alert %}} + +First allow Flux controllers to run as non-root: + +```shell +#!/usr/bin/env bash +set -e + +FLUX_NAMESPACE="flux-system" +FLUX_CONTROLLERS=( +"source-controller" +"kustomize-controller" +"helm-controller" +"notification-controller" +"image-reflector-controller" +"image-automation-controller" +) + +for i in ${!FLUX_CONTROLLERS[@]}; do + oc adm policy add-scc-to-user nonroot system:serviceaccount:${FLUX_NAMESPACE}:${FLUX_CONTROLLERS[$i]} +done +``` + +Then add the following patches to the flux-system `kustomization.yaml`: + +```yaml +apiVersion: kustomize.config.k8s.io/v1beta1 +kind: Kustomization +resources: + - gotk-components.yaml + - gotk-sync.yaml +patches: + - patch: | + apiVersion: apps/v1 + kind: Deployment + metadata: + name: all + spec: + template: + spec: + containers: + - name: manager + securityContext: + runAsUser: 65534 + seccompProfile: + $patch: delete + target: + kind: Deployment + labelSelector: app.kubernetes.io/part-of=flux + - patch: |- + - op: remove + path: /metadata/labels/pod-security.kubernetes.io~1warn + - op: remove + path: /metadata/labels/pod-security.kubernetes.io~1warn-version + target: + kind: Namespace + labelSelector: app.kubernetes.io/part-of=flux +``` + +Finally, push the changes to the Git repository and run [flux bootstrap](/flux/installation#bootstrap-with-flux-cli). diff --git a/content/en/flux/installation/configuration/optional-components.md b/content/en/flux/installation/configuration/optional-components.md new file mode 100644 index 000000000..f09169495 --- /dev/null +++ b/content/en/flux/installation/configuration/optional-components.md @@ -0,0 +1,66 @@ +--- +title: "Flux optional components" +linkTitle: "Optional components" +description: "How to install Flux optional components" +weight: 2 +--- + +The `flux bootstrap` command deploys a series of Kubernetes controllers along with their CRDs, RBAC +and network policies in the `flux-system` namespace. + +## Default components + +The default components are specified with the `--components` flag. + +```shell +flux bootstrap git \ + --components source-controller,kustomize-controller,helm-controller,notification-controller +``` + +The minim required components for bootstrapping are `source-controller` and `kustomize-controller`. + +When not specifying the `--components` flag, both `flux bootstrap` and `flux install` will +deploy the default components. + +## Extra components + +To enable the Flux [image automation feature](/flux/guides/image-update/), the extra components +can be specified with the `--components-extra` flag. + +```shell +flux bootstrap git \ + --components-extra image-reflector-controller,image-automation-controller +``` + +By default, both `flux bootstrap` and `flux install` commands do not include any extra components. + +## Network policies + +Flux relies on Kubernetes network policies to ensure that only Flux components +have direct access to the source artifacts kept in the `source-controller`. + +The default network policies block all ingress access to the `flux-system` namespace, +except for `notification-controller` webhook receiver. + +While not recommend, you can deploy the Flux components without network policies +using the `--network-policy` flag. + +```shell +flux bootstrap git \ + --network-policy false +``` + +## Cluster domain + +The Flux components are communicating over HTTP with `source-controller` and `notification-controller`. +To reduce the DNS queries performed by each component, the cluster internal domain name is used to +compose the FQDN of each service e.g. `http://source-controller.flux-system.svc.cluster.local./`. + +The cluster domain name can be set using the `--cluster-domain` flag. + +```shell +flux bootstrap git \ + --cluster-domain cluster.internal +``` + +When not specified, the cluster domain defaults to `cluster.local`. diff --git a/content/en/flux/installation/configuration/proxy-setting.md b/content/en/flux/installation/configuration/proxy-setting.md new file mode 100644 index 000000000..50a29bce0 --- /dev/null +++ b/content/en/flux/installation/configuration/proxy-setting.md @@ -0,0 +1,79 @@ +--- +title: "Flux proxy settings" +linkTitle: "Proxy settings" +description: "How to configure proxies for Flux controllers" +weight: 18 +--- + +If the Kubernetes cluster has Internet restrictions, requiring egress traffic to go +through a proxy for accessing external services, you can configure the Flux controllers +to use a HTTP/S and/or SOCKS5 SSH proxy. + +## Using HTTP/S proxy for egress traffic + +If your cluster uses an HTTP proxy to reach GitHub or other external services, +you must set `NO_PROXY=.cluster.local.,.cluster.local,.svc` +to allow the Flux controllers to talk to each other. + +To set the HTTP/S proxy [during bootstrap](boostrap-customization.md), add the following patches to the flux-system `kustomization.yaml`: + +```yaml +apiVersion: kustomize.config.k8s.io/v1beta1 +kind: Kustomization +resources: + - gotk-components.yaml + - gotk-sync.yaml +patches: + - patch: | + apiVersion: apps/v1 + kind: Deployment + metadata: + name: all + spec: + template: + spec: + containers: + - name: manager + env: + - name: "HTTPS_PROXY" + value: "https://proxy.example.com" + - name: "NO_PROXY" + value: ".cluster.local.,.cluster.local,.svc" + target: + kind: Deployment + labelSelector: app.kubernetes.io/part-of=flux +``` + +## Git repository access via SOCKS5 SSH proxy + +To configure a SOCKS5 proxy, set the environment variable `ALL_PROXY` to allow +both source-controller and image-automation-controller to connect through the +proxy. + +To set the SOCKS5 proxy [during bootstrap](boostrap-customization.md), add the following patches to the flux-system `kustomization.yaml`: + +```yaml +apiVersion: kustomize.config.k8s.io/v1beta1 +kind: Kustomization +resources: + - gotk-components.yaml + - gotk-sync.yaml +patches: + - patch: | + apiVersion: apps/v1 + kind: Deployment + metadata: + name: all + spec: + template: + spec: + containers: + - name: manager + env: + - name: "ALL_PROXY" + value: "socks5://proxy.example.com:1080" + target: + kind: Deployment + labelSelector: app.kubernetes.io/part-of=flux + name: "(source-controller|image-automation-controller)" +``` diff --git a/content/en/flux/cheatsheets/sharding.md b/content/en/flux/installation/configuration/sharding.md similarity index 97% rename from content/en/flux/cheatsheets/sharding.md rename to content/en/flux/installation/configuration/sharding.md index 46237fc70..4083f5377 100644 --- a/content/en/flux/cheatsheets/sharding.md +++ b/content/en/flux/installation/configuration/sharding.md @@ -1,8 +1,8 @@ --- -title: "Controller sharding and horizontal scaling" -linkTitle: "Sharding" -description: "Showcase how to configure sharding of Flux controllers at bootstrap time." -weight: 30 +title: "Flux sharding and horizontal scaling" +linkTitle: "Horizontal scaling" +description: "How to configure sharding for Flux controllers" +weight: 11 --- When Flux is managing tens of thousands of applications, it is advised to adopt @@ -15,7 +15,7 @@ shard the reconciliation of Flux resources using the `sharding.fluxcd.io/key` la ## Bootstrap with sharding -At [bootstrap time](bootstrap.md), you can define the number of shards +At [bootstrap time](boostrap-customization.md), you can define the number of shards and spin up a Flux controller instance for each shard. First you'll need to create a Git repository and clone it locally, then diff --git a/content/en/flux/installation/configuration/vertical-scaling.md b/content/en/flux/installation/configuration/vertical-scaling.md new file mode 100644 index 000000000..868bdc01f --- /dev/null +++ b/content/en/flux/installation/configuration/vertical-scaling.md @@ -0,0 +1,192 @@ +--- +title: "Flux vertical scaling" +linkTitle: "Vertical scaling" +description: "How to configure vertical scaling for Flux controllers" +weight: 10 +--- + +When Flux is managing hundreds of applications that are deployed multiple times per day, cluster admins +can fine tune the Flux controller at [bootstrap time](boostrap-customization.md) to run at scale by: + +- [Increasing the number of workers and resource limits](#increase-the-number-of-workers-and-limits) +- [Enabling Helm repository caching to reduce memory usage](#enable-helm-repositories-caching) +- [Enabling persistent storage for internal artifacts](#persistent-storage-for-flux-internal-artifacts) +- [Running the Flux controllers on dedicated nodes](#node-affinity-and-tolerations) + +{{% alert color="info" title="Horizontal scaling" %}} +When vertical scaling is not an option, you can use sharding to horizontally scale +the Flux controllers. For more details please see the [sharding guide](sharding.md). +{{% /alert %}} + +## Increase the number of workers and limits + +If Flux is managing hundreds of applications, it is advised to increase the number of reconciliations +that can be performed in parallel and to bump the resources limits: + +```yaml +apiVersion: kustomize.config.k8s.io/v1beta1 +kind: Kustomization +resources: + - gotk-components.yaml + - gotk-sync.yaml +patches: + - patch: | + - op: add + path: /spec/template/spec/containers/0/args/- + value: --concurrent=20 + - op: add + path: /spec/template/spec/containers/0/args/- + value: --requeue-dependency=5s + target: + kind: Deployment + name: "(kustomize-controller|helm-controller|source-controller)" + - patch: | + apiVersion: apps/v1 + kind: Deployment + metadata: + name: all + spec: + template: + spec: + containers: + - name: manager + resources: + limits: + cpu: 2000m + memory: 2Gi + target: + kind: Deployment + name: "(kustomize-controller|helm-controller|source-controller)" +``` + +## Enable Helm repositories caching + +If Flux connects to Helm repositories hosting hundreds of Helm charts, +it is advised to enable caching to reduce the memory footprint of source-controller: + +```yaml +apiVersion: kustomize.config.k8s.io/v1beta1 +kind: Kustomization +resources: + - gotk-components.yaml + - gotk-sync.yaml +patches: + - patch: | + - op: add + path: /spec/template/spec/containers/0/args/- + value: --helm-cache-max-size=10 + - op: add + path: /spec/template/spec/containers/0/args/- + value: --helm-cache-ttl=60m + - op: add + path: /spec/template/spec/containers/0/args/- + value: --helm-cache-purge-interval=5m + target: + kind: Deployment + name: source-controller +``` + +When `helm-cache-max-size` is reached, an error is logged and the index is instead +read from file. Cache hits are exposed via the `gotk_cache_events_total` Prometheus +metrics. Use this data to fine-tune the configuration flags. + + +## Persistent storage for Flux internal artifacts + +Flux maintains a local cache of artifacts acquired from external sources. +By default, the cache is stored in an `EmptyDir` volume, which means that after a restart, +Flux has to restore the local cache by fetching the content of all Git +repositories, Buckets, Helm charts and OCI artifacts. To avoid losing the cached artifacts, +you can configure source-controller with a persistent volume. + +Create a Kubernetes PVC definition named `gotk-pvc.yaml` and place it in your `flux-system` directory: + +```yaml +apiVersion: v1 +kind: PersistentVolumeClaim +metadata: + name: gotk-pvc + namespace: flux-system +spec: + accessModes: + - ReadWriteOnce + storageClassName: standard + resources: + requests: + storage: 10Gi +``` + +Add the PVC file to the `kustomization.yaml` resources and patch the source-controller volumes: + +```yaml +apiVersion: kustomize.config.k8s.io/v1beta1 +kind: Kustomization +resources: + - gotk-components.yaml + - gotk-sync.yaml + - gotk-pvc.yaml +patches: + - patch: | + - op: add + path: '/spec/template/spec/volumes/-' + value: + name: persistent-data + persistentVolumeClaim: + claimName: gotk-pvc + - op: replace + path: '/spec/template/spec/containers/0/volumeMounts/0' + value: + name: persistent-data + mountPath: /data + target: + kind: Deployment + name: source-controller +``` + +## Node affinity and tolerations + +Pin the Flux controller pods to specific nodes and allow the cluster autoscaler to evict them: + +```yaml +apiVersion: kustomize.config.k8s.io/v1beta1 +kind: Kustomization +resources: + - gotk-components.yaml + - gotk-sync.yaml +patches: + - patch: | + apiVersion: apps/v1 + kind: Deployment + metadata: + name: all + spec: + template: + metadata: + annotations: + cluster-autoscaler.kubernetes.io/safe-to-evict: "true" + spec: + affinity: + nodeAffinity: + requiredDuringSchedulingIgnoredDuringExecution: + nodeSelectorTerms: + - matchExpressions: + - key: role + operator: In + values: + - flux + tolerations: + - effect: NoSchedule + key: role + operator: Equal + value: flux + target: + kind: Deployment + labelSelector: app.kubernetes.io/part-of=flux +``` + +The above configuration pins Flux to nodes tainted and labeled with: + +```sh +kubectl taint nodes role=flux:NoSchedule +kubectl label nodes role=flux +``` diff --git a/content/en/flux/installation/configuration/workload-identity.md b/content/en/flux/installation/configuration/workload-identity.md new file mode 100644 index 000000000..96aa0c268 --- /dev/null +++ b/content/en/flux/installation/configuration/workload-identity.md @@ -0,0 +1,118 @@ +--- +title: "Flux Workload Identity" +linkTitle: "Workload Identity" +description: "How to configure workload identity for Flux controllers" +weight: 13 +--- + +When running Flux on AWS EKS, Azure AKS and Google Cloud GKE you can leverage Kubernetes +Workload Identity to grant Flux controllers access to cloud resources such as container +registries, KMS, S3, etc. + +## AWS IAM roles for service accounts + +To grant Flux access to AWS resources using IRSA [during bootstrap](boostrap-customization.md) add the following patches +to the flux-system `kustomization.yaml`: + +```yaml +apiVersion: kustomize.config.k8s.io/v1beta1 +kind: Kustomization +resources: + - gotk-components.yaml + - gotk-sync.yaml +patches: + - patch: | + apiVersion: v1 + kind: ServiceAccount + metadata: + name: controller + annotations: + eks.amazonaws.com/role-arn: + target: + kind: ServiceAccount + name: "(source-controller|image-reflector-controller)" + - patch: | + apiVersion: v1 + kind: ServiceAccount + metadata: + name: controller + annotations: + eks.amazonaws.com/role-arn: + target: + kind: ServiceAccount + name: "kustomize-controller" +``` + +## Azure Workload Identity + +To grant Flux access to Azure resources [during bootstrap](boostrap-customization.md) add the following patches +to the flux-system `kustomization.yaml`: + +```yaml +apiVersion: kustomize.config.k8s.io/v1beta1 +kind: Kustomization +resources: + - gotk-components.yaml + - gotk-sync.yaml +patches: + - patch: | + apiVersion: v1 + kind: ServiceAccount + metadata: + name: controller + annotations: + azure.workload.identity/client-id: + azure.workload.identity/tenant-id: + target: + kind: ServiceAccount + name: "(source-controller|image-reflector-controller)" + - patch: | + apiVersion: apps/v1 + kind: Deployment + metadata: + name: controller + labels: + azure.workload.identity/use: "true" + spec: + template: + metadata: + labels: + azure.workload.identity/use: "true" + target: + kind: Deployment + name: "(source-controller|image-reflector-controller)" +``` + +## GCP Workload Identity + +To grant Flux access to Google Cloud resources [during bootstrap](boostrap-customization.md) add the following patches +to the flux-system `kustomization.yaml`: + +```yaml +apiVersion: kustomize.config.k8s.io/v1beta1 +kind: Kustomization +resources: + - gotk-components.yaml + - gotk-sync.yaml +patches: + - patch: | + apiVersion: v1 + kind: ServiceAccount + metadata: + name: controller + annotations: + iam.gke.io/gcp-service-account: + target: + kind: ServiceAccount + name: "(source-controller|image-reflector-controller)" + - patch: | + apiVersion: v1 + kind: ServiceAccount + metadata: + name: controller + annotations: + iam.gke.io/gcp-service-account: + target: + kind: ServiceAccount + name: "kustomize-controller" +``` From 935fc2731cf949f99ae4277ca1b7627b9b445929 Mon Sep 17 00:00:00 2001 From: Stefan Prodan Date: Thu, 17 Aug 2023 12:36:24 +0300 Subject: [PATCH 4/7] Add authorisation model and multi-tenancy doc Signed-off-by: Stefan Prodan --- .../configuration/multitenancy.md | 159 ++++++++++++++++++ static/_redirects | 7 + 2 files changed, 166 insertions(+) create mode 100644 content/en/flux/installation/configuration/multitenancy.md diff --git a/content/en/flux/installation/configuration/multitenancy.md b/content/en/flux/installation/configuration/multitenancy.md new file mode 100644 index 000000000..8a4916f4a --- /dev/null +++ b/content/en/flux/installation/configuration/multitenancy.md @@ -0,0 +1,159 @@ +--- +title: "Flux multi-tenancy" +linkTitle: "Multi-tenancy lockdown" +description: "How to configure Flux multi-tenancy lockdown" +weight: 12 +--- + +Flux allows different organizations and/or teams to share the same Kubernetes control plane; this is +referred to as "multi-tenancy". To make this safe, Flux supports segmentation and isolation of +resources by using namespaces and role-based access control (RBAC). + +## Flux authorisation model + +Flux defers to Kubernetes' native RBAC to specify which operations are authorised when processing +its custom resources. By default, this means operations are constrained by the +service account under which the controllers run, which has the `cluster-admin` +role bound to it. This is convenient for a deployment in which all users are trusted. + +In a multi-tenant deployment, each tenant needs to be restricted in the operations that can be done +on their behalf. Since tenants control Flux via its API objects, this becomes a matter of attaching +RBAC rules to Flux API objects. + +To give users control over the authorisation, the Flux controllers can _impersonate_ (assume the +identity of) a service account mentioned in the apply specification (e.g., the field +`.spec.serviceAccountName` in +a [`Kustomization` object](https://fluxcd.io/flux/components/kustomize/kustomization/#role-based-access-control) +or in a [`HelmRelease` object](https://fluxcd.io/flux/components/helm/helmreleases/#role-based-access-control)) +for both accessing resources and applying configuration. +This lets a user constrain the operations performed by the Flux controllers with RBAC. + +## Flux user roles + +The tenancy model assume two types of users: platform admins and tenants. +Besides installing Flux, all the other operations (deploy applications, configure ingress, policies, etc) +do not require users to have direct access to the Kubernetes API. Flux acts as a proxy between users and +the Kubernetes API, using Git and OCI as the source of truth for the cluster desired state. + +### Platform Admins + +The platform admins have unrestricted access to Kubernetes API. +They are responsible for installing Flux and granting Flux +access to the sources (Git, Helm, OCI repositories) that make up the cluster(s) control plane desired state. +The repository(s) owned by the platform admins are reconciled on the cluster(s) by Flux, under +the [cluster-admin](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#user-facing-roles) +Kubernetes cluster role. + +Example of operations performed by platform admins: + +- Bootstrap Flux onto cluster(s). +- Extend the Kubernetes API with custom resource definitions and validation webhooks. +- Configure various controllers for ingress, storage, logging, monitoring, progressive delivery, etc. +- Set up namespaces for tenants and define their level of access with Kubernetes RBAC. +- Onboard tenants by registering their Git repositories with Flux. + +### Tenants + +The tenants have restricted access to the cluster(s) according to the Kubernetes RBAC configured +by the platform admins. The repositories owned by tenants are reconciled on the cluster(s) by Flux, +under the Kubernetes account(s) assigned by platform admins. + +Example of operations performed by tenants: + +- Register their sources with Flux (`GitRepositories`, `HelmRepositories` and `Buckets`). +- Deploy workload(s) into their namespace(s) using Flux custom resources (`Kustomizations` and `HelmReleases`). +- Automate application updates using Flux custom resources (`ImageRepositories`, `ImagePolicies` + and `ImageUpdateAutomations`). +- Configure the release pipeline(s) using Flagger custom resources (`Canaries` and `MetricsTemplates`). +- Setup webhooks and alerting for their release pipeline(s) using Flux custom resources (`Receivers` and `Alerts`). + +## How to configure Flux multi-tenancy + +A platform admin can lock down Flux on multi-tenant clusters [during bootstrap](boostrap-customization.md) with the following patches: + +```yaml +apiVersion: kustomize.config.k8s.io/v1beta1 +kind: Kustomization +resources: + - gotk-components.yaml + - gotk-sync.yaml +patches: + - patch: | + - op: add + path: /spec/template/spec/containers/0/args/- + value: --no-cross-namespace-refs=true + target: + kind: Deployment + name: "(kustomize-controller|helm-controller|notification-controller|image-reflector-controller|image-automation-controller)" + - patch: | + - op: add + path: /spec/template/spec/containers/0/args/- + value: --no-remote-bases=true + target: + kind: Deployment + name: "kustomize-controller" + - patch: | + - op: add + path: /spec/template/spec/containers/0/args/- + value: --default-service-account=default + target: + kind: Deployment + name: "(kustomize-controller|helm-controller)" + - patch: | + - op: add + path: /spec/serviceAccountName + value: kustomize-controller + target: + kind: Kustomization + name: "flux-system" +``` + +With the above configuration, Flux will: + +- Deny cross-namespace access to Flux custom resources, thus ensuring that a tenant can't use another tenant's sources + or subscribe to their events. +- Deny accesses to Kustomize remote bases, thus ensuring all resources refer to local files, meaning only the Flux + Sources can affect the cluster-state. +- All `Kustomizations` and `HelmReleases` which don't have `spec.serviceAccountName` specified, will use the `default` + account from the tenant's namespace. + Tenants have to specify a service account in their Flux resources to be able to deploy workloads in their namespaces + as the `default` account has no permissions. +- The flux-system `Kustomization` is set to reconcile under a service account with cluster-admin role, + allowing platform admins to configure cluster-wide resources and provision the tenant's namespaces, service accounts + and RBAC. + +{{% alert color="info" title="Multi-tenancy example" %}} +The Flux team maintains a dedicated repository +at [github.com/fluxcd/flux2-multi-tenancy](https://github.com/fluxcd/flux2-multi-tenancy) +to showcase how platform admins can onboard tenants +and limit their access to the cluster resources with various policies. +{{% /alert %}} + +### Flux cluster role aggregations + +By default, Flux [RBAC](/flux/security/#controller-permissions) grants Kubernetes builtin +`view`, `edit` and `admin` roles access to Flux custom resources. + +This allows tenants to manage Flux resources in their own namespaces using a Service Account +with a role binding to `admin`. + +If you wish to disable the RBAC aggregation, you can remove the `flux-view` and `flux-edit` +cluster roles with: + +```yaml +apiVersion: kustomize.config.k8s.io/v1beta1 +kind: Kustomization +resources: + - gotk-components.yaml + - gotk-sync.yaml +patches: + - patch: | + apiVersion: rbac.authorization.k8s.io/v1 + kind: ClusterRole + metadata: + name: flux + $patch: delete + target: + kind: ClusterRole + name: "(flux-view|flux-edit)-flux-system" +``` diff --git a/static/_redirects b/static/_redirects index a332e1e98..1c55b48c7 100644 --- a/static/_redirects +++ b/static/_redirects @@ -26,6 +26,13 @@ /flagger/usage/kuma-progressive-delivery /flagger/tutorials/kuma-progressive-delivery 301! /flagger/usage/gatewayapi-progressive-delivery /flagger/tutorials/gatewayapi-progressive-delivery 301! +/flux/use-cases/aws-codecommit /flux/installation/bootstrap/aws-codecommit 301! +/flux/use-cases/azure /flux/installation/bootstrap/azure-devops 301! +/flux/use-cases/gcp-source-repository /flux/installation/bootstrap/google-cloud-source 301! +/flux/use-cases/openshift /flux/installation/configuration/openshift 301! +/flux/cheatsheets/sharding /flux/installation/configuration/sharding 301! +/flux/cheatsheets/bootstrap /flux/installation/configuration 301! + /docs/contributing/* /contributing/:splat 301! /docs/* /flux/:splat 301! From ec1130d1934ac6edb1ad90835de7d66ed27087bb Mon Sep 17 00:00:00 2001 From: Stefan Prodan Date: Thu, 17 Aug 2023 12:38:01 +0300 Subject: [PATCH 5/7] Remove deprecated bootstrap docs Signed-off-by: Stefan Prodan --- content/en/flux/cheatsheets/bootstrap.md | 670 --------------- content/en/flux/installation.md | 794 ------------------ content/en/flux/use-cases/aws-codecommit.md | 115 --- content/en/flux/use-cases/azure.md | 241 ------ .../flux/use-cases/gcp-source-repository.md | 110 --- content/en/flux/use-cases/openshift.md | 179 ---- 6 files changed, 2109 deletions(-) delete mode 100644 content/en/flux/cheatsheets/bootstrap.md delete mode 100644 content/en/flux/installation.md delete mode 100644 content/en/flux/use-cases/aws-codecommit.md delete mode 100644 content/en/flux/use-cases/azure.md delete mode 100644 content/en/flux/use-cases/gcp-source-repository.md delete mode 100644 content/en/flux/use-cases/openshift.md diff --git a/content/en/flux/cheatsheets/bootstrap.md b/content/en/flux/cheatsheets/bootstrap.md deleted file mode 100644 index 68d79b37a..000000000 --- a/content/en/flux/cheatsheets/bootstrap.md +++ /dev/null @@ -1,670 +0,0 @@ ---- -title: "Bootstrap cheatsheet" -linkTitle: "Bootstrap" -description: "Showcase various configurations of Flux controllers at bootstrap time." -weight: 29 ---- - -## How to customize Flux - -To customize the Flux controllers during bootstrap, -first you'll need to create a Git repository and clone it locally. - -Create the file structure required by bootstrap with: - -```sh -mkdir -p clusters/my-cluster/flux-system -touch clusters/my-cluster/flux-system/gotk-components.yaml \ - clusters/my-cluster/flux-system/gotk-sync.yaml \ - clusters/my-cluster/flux-system/kustomization.yaml -``` - -The Flux controller deployments, container command arguments, node affinity, etc can be customized using -[Kustomize strategic merge patches and JSON patches](https://github.com/kubernetes-sigs/kustomize/blob/master/examples/patchMultipleObjects.md). - -You can make changes to all controllers using a single patch or -target a specific controller: - -```yaml -apiVersion: kustomize.config.k8s.io/v1beta1 -kind: Kustomization -resources: # manifests generated during bootstrap - - gotk-components.yaml - - gotk-sync.yaml -patches: - # target all controllers - - patch: | - # strategic merge or JSON patch - target: - kind: Deployment - labelSelector: "app.kubernetes.io/part-of=flux" - # target controllers by name - - patch: | - # strategic merge or JSON patch - target: - kind: Deployment - name: "(kustomize-controller|helm-controller)" - # add a command argument to a single controller - - patch: | - - op: add - path: /spec/template/spec/containers/0/args/- - value: --concurrent=5 - target: - kind: Deployment - name: "image-reflector-controller" -``` - -Push the changes to main branch: - -```sh -git add -A && git commit -m "init flux" && git push -``` - -And run the bootstrap for `clusters/my-cluster`: - -```sh -flux bootstrap git \ - --url=ssh://git@// \ - --branch=main \ - --path=clusters/my-cluster -``` - -To make further amendments, pull the changes locally, -edit the kustomization.yaml file, push the changes upstream -and rerun bootstrap. - -## Customization examples - -### Safe to evict - -Allow the cluster autoscaler to evict the Flux controller pods: - -```yaml -apiVersion: kustomize.config.k8s.io/v1beta1 -kind: Kustomization -resources: - - gotk-components.yaml - - gotk-sync.yaml -patches: - - patch: | - apiVersion: apps/v1 - kind: Deployment - metadata: - name: all - spec: - template: - metadata: - annotations: - cluster-autoscaler.kubernetes.io/safe-to-evict: "true" - target: - kind: Deployment - labelSelector: app.kubernetes.io/part-of=flux -``` - -### Node affinity and tolerations - -Pin the Flux controllers to specific nodes: - -```yaml -apiVersion: kustomize.config.k8s.io/v1beta1 -kind: Kustomization -resources: - - gotk-components.yaml - - gotk-sync.yaml -patches: - - patch: | - apiVersion: apps/v1 - kind: Deployment - metadata: - name: all - spec: - template: - spec: - affinity: - nodeAffinity: - requiredDuringSchedulingIgnoredDuringExecution: - nodeSelectorTerms: - - matchExpressions: - - key: role - operator: In - values: - - flux - tolerations: - - effect: NoSchedule - key: role - operator: Equal - value: flux - target: - kind: Deployment - labelSelector: app.kubernetes.io/part-of=flux -``` - -The above configuration pins Flux to nodes tainted and labeled with: - -```sh -kubectl taint nodes role=flux:NoSchedule -kubectl label nodes role=flux -``` - -### Increase the number of workers - -If Flux is managing hundreds of applications, you may want to increase the number of reconciliations -that can be performed in parallel and bump the resources limits: - -```yaml -apiVersion: kustomize.config.k8s.io/v1beta1 -kind: Kustomization -resources: - - gotk-components.yaml - - gotk-sync.yaml -patches: - - patch: | - - op: add - path: /spec/template/spec/containers/0/args/- - value: --concurrent=20 - - op: add - path: /spec/template/spec/containers/0/args/- - value: --kube-api-qps=500 - - op: add - path: /spec/template/spec/containers/0/args/- - value: --kube-api-burst=1000 - - op: add - path: /spec/template/spec/containers/0/args/- - value: --requeue-dependency=5s - target: - kind: Deployment - name: "(kustomize-controller|helm-controller|source-controller)" - - patch: | - apiVersion: apps/v1 - kind: Deployment - metadata: - name: all - spec: - template: - spec: - containers: - - name: manager - resources: - limits: - cpu: 2000m - memory: 2Gi - target: - kind: Deployment - name: "(kustomize-controller|helm-controller|source-controller)" -``` - -{{% alert color="info" title="Horizontal scaling" %}} -When vertical scaling is not an option, you can use sharding to horizontally scale -the Flux controllers. For more details please see the [sharding guide](sharding.md). -{{% /alert %}} - -### Persistent storage for Flux internal artifacts - -Flux maintains a local cache of artifacts acquired from external sources. -By default, the cache is stored in an `EmptyDir` volume, which means that after a restart, -Flux has to restore the local cache by fetching the content of all Git -repositories, Buckets, Helm charts and OCI artifacts. To avoid losing the cached artifacts, -you can configure source-controller with a persistent volume. - -Create a Kubernetes PVC definition named `gotk-pvc.yaml` and place it in your `flux-system` directory: - -```yaml -apiVersion: v1 -kind: PersistentVolumeClaim -metadata: - name: gotk-pvc - namespace: flux-system -spec: - accessModes: - - ReadWriteOnce - storageClassName: standard - resources: - requests: - storage: 2Gi -``` - -Add the PVC file to the `kustomization.yaml` resources and patch the source-controller volumes: - -```yaml -apiVersion: kustomize.config.k8s.io/v1beta1 -kind: Kustomization -resources: - - gotk-components.yaml - - gotk-sync.yaml - - gotk-pvc.yaml -patches: - - patch: | - - op: add - path: '/spec/template/spec/volumes/-' - value: - name: persistent-data - persistentVolumeClaim: - claimName: gotk-pvc - - op: replace - path: '/spec/template/spec/containers/0/volumeMounts/0' - value: - name: persistent-data - mountPath: /data - target: - kind: Deployment - name: source-controller -``` - -### Enable Helm repositories caching - -For large Helm repository index files, you can enable -caching to reduce the memory footprint of source-controller: - -```yaml -apiVersion: kustomize.config.k8s.io/v1beta1 -kind: Kustomization -resources: - - gotk-components.yaml - - gotk-sync.yaml -patches: - - patch: | - - op: add - path: /spec/template/spec/containers/0/args/- - value: --helm-cache-max-size=10 - - op: add - path: /spec/template/spec/containers/0/args/- - value: --helm-cache-ttl=60m - - op: add - path: /spec/template/spec/containers/0/args/- - value: --helm-cache-purge-interval=5m - target: - kind: Deployment - name: source-controller -``` - -When `helm-cache-max-size` is reached, an error is logged and the index is instead -read from file. Cache hits are exposed via the `gotk_cache_events_total` Prometheus -metrics. Use this data to fine-tune the configuration flags. - -### Enable Helm drift detection - -At present, Helm releases are not by default checked for drift compared to -cluster-state. To enable experimental drift detection, you must add the -`--feature-gates=DetectDrift=true` flag to the helm-controller Deployment. - -Enabling it will cause the controller to check for drift on all Helm releases -using a dry-run Server Side Apply, triggering an upgrade if a change is detected. -For detailed information about this feature, [refer to the -documentation](/flux/components/helm/helmreleases/#drift-detection). - -```yaml -apiVersion: kustomize.config.k8s.io/v1beta1 -kind: Kustomization -resources: - - gotk-components.yaml - - gotk-sync.yaml -patches: - - patch: | - # Enable drift detection feature - - op: add - path: /spec/template/spec/containers/0/args/- - value: --feature-gates=DetectDrift=true - # Enable debug logging for diff output (optional) - - op: replace - path: /spec/template/spec/containers/0/args/2 - value: --log-level=debug - target: - kind: Deployment - name: helm-controller -``` - -### Enable Helm near OOM detection - -When memory usage of the helm-controller exceeds the configured limit, the -controller will forcefully be killed by Kubernetes' OOM killer. This may result -in a Helm release being left in a `pending-*` state which causes the HelmRelease -to get stuck in an `another operation (install/upgrade/rollback) is in progress` -error loop. - -To prevent this from happening, the controller offers an OOM watcher which can -be enabled with `--feature-gates=OOMWatch=true`. When enabled, the memory usage -of the controller will be monitored, and a graceful shutdown will be triggered -when it reaches a certain threshold (default 95% utilization). - -When gracefully shutting down, running Helm actions may mark the release as -`failed`. Because of this, enabling this feature is best combined with -thoughtful [remediation strategies](/flux/components/helm/helmreleases/#configuring-failure-remediation). - -```yaml -apiVersion: kustomize.config.k8s.io/v1beta1 -kind: Kustomization -resources: - - gotk-components.yaml - - gotk-sync.yaml -patches: - - patch: | - # Enable OOM watch feature - - op: add - path: /spec/template/spec/containers/0/args/- - value: --feature-gates=OOMWatch=true - # Threshold at which to trigger a graceful shutdown (optional, default 95%) - - op: add - path: /spec/template/spec/containers/0/args/- - value: --oom-watch-memory-threshold=95 - # Interval at which to check memory usage (optional, default 500ms) - - op: add - path: /spec/template/spec/containers/0/args/- - value: --oom-watch-interval=500ms - target: - kind: Deployment - name: helm-controller -``` - -### Allow Helm DNS lookups - -By default, the helm-controller will not perform DNS lookups when rendering Helm -templates in clusters because of potential [security -implications](https://github.com/helm/helm/security/advisories/GHSA-pwcw-6f5g-gxf8). - -To enable DNS lookups, you must add the `--feature-gates=AllowDNSLookups=true` -flag to the helm-controller Deployment. - -```yaml -apiVersion: kustomize.config.k8s.io/v1beta1 -kind: Kustomization -resources: - - gotk-components.yaml - - gotk-sync.yaml -patches: - - patch: | - # Allow Helm DNS lookups - - op: add - path: /spec/template/spec/containers/0/args/- - value: --feature-gates=AllowDNSLookups=true - target: - kind: Deployment - name: helm-controller -``` - -### Using HTTP/S proxy for egress traffic - -If your cluster must use an HTTP proxy to reach GitHub or other external services, -you must set `NO_PROXY=.cluster.local.,.cluster.local,.svc` -to allow the Flux controllers to talk to each other: - -```yaml -apiVersion: kustomize.config.k8s.io/v1beta1 -kind: Kustomization -resources: - - gotk-components.yaml - - gotk-sync.yaml -patches: - - patch: | - apiVersion: apps/v1 - kind: Deployment - metadata: - name: all - spec: - template: - spec: - containers: - - name: manager - env: - - name: "HTTPS_PROXY" - value: "http://proxy.example.com:3129" - - name: "NO_PROXY" - value: ".cluster.local.,.cluster.local,.svc" - target: - kind: Deployment - labelSelector: app.kubernetes.io/part-of=flux -``` - -### Git repository access via SOCKS5 SSH proxy - -If your cluster has Internet restrictions, requiring egress traffic to go -through a proxy, you must use a SOCKS5 SSH proxy to be able to reach GitHub -(or other external Git servers) via SSH. - -To configure a SOCKS5 proxy set the environment variable `ALL_PROXY` to allow -both source-controller and image-automation-controller to connect through the -proxy. - -``` -ALL_PROXY=socks5://: -``` - -The following is an example of patching the Flux setup kustomization to add the -`ALL_PROXY` environment variable in source-controller and -image-automation-controller: - -```yaml -apiVersion: kustomize.config.k8s.io/v1beta1 -kind: Kustomization -resources: - - gotk-components.yaml - - gotk-sync.yaml -patches: - - patch: | - apiVersion: apps/v1 - kind: Deployment - metadata: - name: all - spec: - template: - spec: - containers: - - name: manager - env: - - name: "ALL_PROXY" - value: "socks5://proxy.example.com:1080" - target: - kind: Deployment - labelSelector: app.kubernetes.io/part-of=flux - name: "(source-controller|image-automation-controller)" -``` - -### Test release candidates - -To test release candidates, you can patch the container image tags: - -```yaml -apiVersion: kustomize.config.k8s.io/v1beta1 -kind: Kustomization -resources: - - gotk-components.yaml - - gotk-sync.yaml -images: - - name: ghcr.io/fluxcd/source-controller - newTag: rc-254ba51d - - name: ghcr.io/fluxcd/kustomize-controller - newTag: rc-ca0a9b8 -``` - -### OpenShift compatibility - -Allow Flux controllers to run as non-root: - -```shell -#!/usr/bin/env bash -set -e - -FLUX_NAMESPACE="flux-system" -FLUX_CONTROLLERS=( -"source-controller" -"kustomize-controller" -"helm-controller" -"notification-controller" -"image-reflector-controller" -"image-automation-controller" -) - -for i in ${!FLUX_CONTROLLERS[@]}; do - oc adm policy add-scc-to-user nonroot system:serviceaccount:${FLUX_NAMESPACE}:${FLUX_CONTROLLERS[$i]} -done -``` - -Set the user to nobody and delete the seccomp profile from the security context: - -```yaml -apiVersion: kustomize.config.k8s.io/v1beta1 -kind: Kustomization -resources: - - gotk-components.yaml - - gotk-sync.yaml -patches: - - patch: | - apiVersion: apps/v1 - kind: Deployment - metadata: - name: all - spec: - template: - spec: - containers: - - name: manager - securityContext: - runAsUser: 65534 - seccompProfile: - $patch: delete - target: - kind: Deployment - labelSelector: app.kubernetes.io/part-of=flux -``` - -### IAM Roles for Service Accounts - -To allow Flux access to an AWS service such as KMS or S3, after setting up IRSA, -you can annotate the controller service account with the role ARN: - -```yaml -apiVersion: kustomize.config.k8s.io/v1beta1 -kind: Kustomization -resources: - - gotk-components.yaml - - gotk-sync.yaml -patches: - - patch: | - apiVersion: v1 - kind: ServiceAccount - metadata: - name: kustomize-controller - annotations: - eks.amazonaws.com/role-arn: arn:aws:iam:::role/ - target: - kind: ServiceAccount - name: kustomize-controller - - patch: | - apiVersion: v1 - kind: ServiceAccount - metadata: - name: source-controller - annotations: - eks.amazonaws.com/role-arn: arn:aws:iam:::role/ - target: - kind: ServiceAccount - name: source-controller -``` - -### Multi-tenancy lockdown - -Lock down Flux on a multi-tenant cluster by disabling cross-namespace references and Kustomize remote bases, and -by setting a default service account: - -```yaml -apiVersion: kustomize.config.k8s.io/v1beta1 -kind: Kustomization -resources: - - gotk-components.yaml - - gotk-sync.yaml -patches: - - patch: | - - op: add - path: /spec/template/spec/containers/0/args/- - value: --no-cross-namespace-refs=true - target: - kind: Deployment - name: "(kustomize-controller|helm-controller|notification-controller|image-reflector-controller|image-automation-controller)" - - patch: | - - op: add - path: /spec/template/spec/containers/0/args/- - value: --no-remote-bases=true - target: - kind: Deployment - name: "kustomize-controller" - - patch: | - - op: add - path: /spec/template/spec/containers/0/args/- - value: --default-service-account=default - target: - kind: Deployment - name: "(kustomize-controller|helm-controller)" - - patch: | - - op: add - path: /spec/serviceAccountName - value: kustomize-controller - target: - kind: Kustomization - name: "flux-system" -``` - -### Disable Kubernetes cluster role aggregations - -By default, Flux [RBAC](/flux/security/#controller-permissions) grants Kubernetes builtin `view`, `edit` and `admin` roles -access to Flux custom resources. To disable the RBAC aggregation, you can remove the `flux-view` and `flux-edit` -cluster roles with: - -```yaml -apiVersion: kustomize.config.k8s.io/v1beta1 -kind: Kustomization -resources: - - gotk-components.yaml - - gotk-sync.yaml -patches: - - patch: | - apiVersion: rbac.authorization.k8s.io/v1 - kind: ClusterRole - metadata: - name: flux - $patch: delete - target: - kind: ClusterRole - name: "(flux-view|flux-edit)-flux-system" -``` - -### Enable notifications for third party controllers - -Enable notifications for 3rd party Flux controllers such as [tf-controller](https://github.com/weaveworks/tf-controller): - -```yaml -apiVersion: kustomize.config.k8s.io/v1beta1 -kind: Kustomization -resources: - - gotk-components.yaml - - gotk-sync.yaml -patches: - - patch: | - - op: add - path: /spec/versions/0/schema/openAPIV3Schema/properties/spec/properties/eventSources/items/properties/kind/enum/- - value: Terraform - - op: add - path: /spec/versions/1/schema/openAPIV3Schema/properties/spec/properties/eventSources/items/properties/kind/enum/- - value: Terraform - target: - kind: CustomResourceDefinition - name: alerts.notification.toolkit.fluxcd.io - - patch: | - - op: add - path: /spec/versions/0/schema/openAPIV3Schema/properties/spec/properties/resources/items/properties/kind/enum/- - value: Terraform - - op: add - path: /spec/versions/1/schema/openAPIV3Schema/properties/spec/properties/resources/items/properties/kind/enum/- - value: Terraform - target: - kind: CustomResourceDefinition - name: receivers.notification.toolkit.fluxcd.io - - patch: | - - op: add - path: /rules/- - value: - apiGroups: [ 'infra.contrib.fluxcd.io' ] - resources: [ '*' ] - verbs: [ '*' ] - target: - kind: ClusterRole - name: crd-controller-flux-system -``` diff --git a/content/en/flux/installation.md b/content/en/flux/installation.md deleted file mode 100644 index d016e28c0..000000000 --- a/content/en/flux/installation.md +++ /dev/null @@ -1,794 +0,0 @@ ---- -title: "Installation" -description: "Flux install, bootstrap, upgrade and uninstall documentation." -weight: 30 ---- - -This guide walks you through setting up Flux to -manage one or more Kubernetes clusters. - -## Prerequisites - -You will need a Kubernetes cluster that matches one of the following versions: - -| Kubernetes version | Minimum required | -|--------------------|------------------| -| `v1.24` | `>= 1.24.0` | -| `v1.25` | `>= 1.25.0` | -| `v1.26` | `>= 1.26.0` | -| `v1.27` and later | `>= 1.27.1` | - -{{% alert color="info" title="Kubernetes EOL" %}} -Note that Flux may work on older versions of Kubernetes e.g. 1.19, -but we don't recommend running [EOL versions](https://endoflife.date/kubernetes) -in production nor do we offer support for these versions. -{{% /alert %}} - -## Install the Flux CLI - -The Flux CLI is available as a binary executable for all major platforms, -the binaries can be downloaded from GitHub -[releases page](https://github.com/fluxcd/flux2/releases). - -{{< tabpane text=true >}} -{{% tab header="Homebrew" %}} - -With [Homebrew](https://brew.sh) for macOS and Linux: - -```sh -brew install fluxcd/tap/flux -``` - -{{% /tab %}} -{{% tab header="bash" %}} - -With [Bash](https://www.gnu.org/software/bash/) for macOS and Linux: - -```sh -curl -s https://fluxcd.io/install.sh | sudo bash -``` - -{{% /tab %}} -{{% tab header="yay" %}} - -With [yay](https://github.com/Jguer/yay) (or another [AUR helper](https://wiki.archlinux.org/title/AUR_helpers)) for Arch Linux: - -```sh -yay -S flux-bin -``` - -{{% /tab %}} -{{% tab header="nix" %}} - -With [nix-env](https://nixos.org/manual/nix/unstable/command-ref/nix-env.html) for NixOS: - -```sh -nix-env -i fluxcd -``` - -{{% /tab %}} -{{% tab header="Chocolatey" %}} - -With [Chocolatey](https://chocolatey.org/) for Windows: - -```powershell -choco install flux -``` - -{{% /tab %}} -{{< /tabpane >}} - -To configure your shell to load `flux` [bash completions](./cmd/flux_completion_bash.md) add to your profile: - -```sh -. <(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. - -A container image with `kubectl` and `flux` is available on DockerHub and GitHub: - -* `docker.io/fluxcd/flux-cli:` -* `ghcr.io/fluxcd/flux-cli:` - -## Bootstrap - -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. - -The Flux component images are published to DockerHub and GitHub Container Registry -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. - -If your Git provider is **AWS CodeCommit**, **Azure DevOps**, **Bitbucket Server**, **GitHub** or **GitLab** please -follow the specific bootstrap procedure: - -* [AWS CodeCommit](./use-cases/aws-codecommit.md#flux-installation-for-aws-codecommit) -* [Azure DevOps](./use-cases/azure.md#flux-installation-for-azure-devops) -* [Bitbucket Server and Data Center](#bitbucket-server-and-data-center) -* [GitHub.com and GitHub Enterprise](#github-and-github-enterprise) -* [GitLab.com and GitLab Enterprise](#gitlab-and-gitlab-enterprise) - -### Generic Git Server - -The `bootstrap git` command takes an existing Git repository, clones it and -commits the Flux components manifests to the specified branch. Then it -configures the target cluster to synchronize with that repository. - -{{% alert color="warning" %}} -:warning: Note that if set, your SSH hostname and port could be overwritten by your [ssh_config](https://linux.die.net/man/5/ssh_config). -{{% /alert %}} - -Run bootstrap for a Git repository and authenticate with your SSH agent: - -```sh -flux bootstrap git \ - --url=ssh://git@// \ - --branch= \ - --path=clusters/my-cluster -``` - -The above command will generate an SSH key (defaults to ECDSA P-384 but can be changed with `--ssh-key-algorithm` and -`--ssh-ecdsa-curve`), and it will prompt you to add the SSH public key as a deploy key to your repository. - -If you want to use your own SSH key, you can provide a private key using -`--private-key-file=` (you can supply the passphrase with `--password=`). -This option can also be used if no SSH agent is available on your machine. - -{{% 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: - -```sh -flux bootstrap git \ - --url=https://// \ - --username= \ - --password= \ - --token-auth=true \ - --path=clusters/my-cluster -``` - -If your Git server uses a self-signed TLS certificate, you can specify the CA file with -`--ca-file=`. - -With `--path` you can configure the directory which will be used to reconcile the target cluster. -To control multiple clusters from the same Git repository, you have to set a unique path per -cluster e.g. `clusters/staging` and `clusters/production`: - -```sh -./clusters/ -├── staging # <- path=clusters/staging -│   └── flux-system # <- namespace dir generated by bootstrap -│   ├── gotk-components.yaml -│   ├── gotk-sync.yaml -│   └── kustomization.yaml -└── production # <- path=clusters/production - └── flux-system -``` - -After running bootstrap you can place Kubernetes YAMLs inside a dir under path -e.g. `clusters/staging/my-app`, and Flux will reconcile them on your cluster. - -For examples on how you can structure your Git repository see: - -* [flux2-kustomize-helm-example](https://github.com/fluxcd/flux2-kustomize-helm-example) -* [flux2-multi-tenancy](https://github.com/fluxcd/flux2-multi-tenancy) - -### GitHub and GitHub Enterprise - -The `bootstrap github` command creates a GitHub repository if one doesn't exist and -commits the Flux components manifests to specified branch. Then it -configures the target cluster to synchronize with that repository by -setting up an SSH deploy key or by using token-based authentication. - -Generate a [personal access token](https://help.github.com/en/github/authenticating-to-github/creating-a-personal-access-token-for-the-command-line) -(PAT) that can create repositories by checking all permissions under `repo`. If -a pre-existing repository is to be used the PAT's user will require `admin` -[permissions](https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization#permissions-for-each-role) -on the repository in order to create a deploy key. - -Export your GitHub personal access token as an environment variable: - -```sh -export GITHUB_TOKEN= -``` - -Run the bootstrap for a repository on your personal GitHub account: - -```sh -flux bootstrap github \ - --owner=my-github-username \ - --repository=my-repository \ - --path=clusters/my-cluster \ - --personal -``` - -{{% 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: - -```sh -flux bootstrap github \ - --owner=my-github-organization \ - --repository=my-repository \ - --team=team1-slug \ - --team=team2-slug \ - --path=clusters/my-cluster -``` - -When you specify a list of teams, those teams will be granted maintainer access to the repository. - -To run the bootstrap for a repository hosted on GitHub Enterprise, you have to specify your GitHub hostname: - -```sh -flux bootstrap github \ - --hostname=my-github-enterprise.com \ - --ssh-hostname=my-github-enterprise.com \ - --owner=my-github-organization \ - --repository=my-repository \ - --branch=main \ - --path=clusters/my-cluster -``` - -If your GitHub Enterprise has SSH access disabled, you can use HTTPS and token authentication with: - -```sh -flux bootstrap github \ - --token-auth \ - --hostname=my-github-enterprise.com \ - --owner=my-github-organization \ - --repository=my-repository \ - --branch=main \ - --path=clusters/my-cluster -``` - -### GitLab and GitLab Enterprise - -The `bootstrap gitlab` command creates a GitLab repository if one doesn't exist and -commits the Flux components manifests to specified branch. Then it -configures the target cluster to synchronize with that repository by -setting up an SSH deploy key or by using token-based authentication. - -Generate a [personal access token](https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html) -that grants complete read/write access to the GitLab API. - -Export your GitLab personal access token as an environment variable: - -```sh -export GITLAB_TOKEN= -``` - -Run the bootstrap for a repository on your personal GitLab account: - -```sh -flux bootstrap gitlab \ - --owner=my-gitlab-username \ - --repository=my-repository \ - --branch=master \ - --path=clusters/my-cluster \ - --token-auth \ - --personal -``` - -To use a [GitLab deploy token](https://docs.gitlab.com/ee/user/project/deploy_tokens/) instead of your personal access token -or an SSH deploy key, you can specify the `--deploy-token-auth` option: - -```sh -flux bootstrap gitlab \ - --owner=my-gitlab-username \ - --repository=my-repository \ - --branch=master \ - --path=clusters/my-cluster \ - --deploy-token-auth -``` - -To run the bootstrap for a repository using deploy keys for authentication, you have to specify the SSH hostname: - -```sh -flux bootstrap gitlab \ - --ssh-hostname=gitlab.com \ - --owner=my-gitlab-username \ - --repository=my-repository \ - --branch=master \ - --path=clusters/my-cluster -``` - -{{% 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: - -```sh -flux bootstrap gitlab \ - --owner=my-gitlab-group/my-gitlab-subgroup \ - --repository=my-repository \ - --branch=master \ - --path=clusters/my-cluster -``` - -To run the bootstrap for a repository hosted on GitLab on-prem or enterprise, you have to specify your GitLab hostname: - -```sh -flux bootstrap gitlab \ - --hostname=my-gitlab.com \ - --token-auth \ - --owner=my-gitlab-group \ - --repository=my-repository \ - --branch=master \ - --path=clusters/my-cluster -``` - -### Bitbucket Server and Data Center - -The `bootstrap bitbucket-server` command creates a Bitbucket Server repository if one doesn't exist and -commits the Flux components manifests to the specified branch. Then it -configures the target cluster to synchronize with that repository by -setting up an SSH deploy key or by using token-based authentication. - -{{% alert color="info" title="Bitbucket versions" %}} -This bootstrap command works with Bitbucket Server and Data Center only because it targets the [1.0](https://developer.atlassian.com/server/bitbucket/reference/rest-api/) REST API. Bitbucket Cloud has migrated to the [2.0](https://developer.atlassian.com/cloud/bitbucket/rest/intro/) REST API. -{{% /alert %}} - -Generate a [personal access token](https://confluence.atlassian.com/bitbucketserver/http-access-tokens-939515499.html) -that grant read/write access to the repository. - -Export your Bitbucket personal access token as an environment variable: - -```sh -export BITBUCKET_TOKEN= -``` - -Run the bootstrap for a repository on your personal Bitbucket Server account: - -```sh -flux bootstrap bitbucket-server \ - --owner=my-bitbucket-username \ - --repository=my-repository \ - --branch=main \ - --path=clusters/my-cluster \ - --hostname=my-bitbucket-server.com \ - --personal -``` - -Run the bootstrap for a repository owned by a Bitbucket Server project: - -```sh -flux bootstrap bitbucket-server \ - --owner=my-bitbucket-project \ - --username=my-bitbucket-username \ - --repository=my-repository \ - --path=clusters/my-cluster \ - --hostname=my-bitbucket-server.com \ - --group=group-name -``` - -When you specify a list of groups, those teams will be granted write access to the repository. - -**Note:** The `username` is mandatory for `project` owned repositories. The specified user must own the `BITBUCKET_TOKEN` and have sufficient rights on the target `project` to create repositories. - -To run the bootstrap for a repository with a different SSH hostname (e.g. with a different port): - -```sh -flux bootstrap bitbucket-server \ - --hostname=my-bitbucket-server.com \ - --ssh-hostname=my-bitbucket-server.com:7999 \ - --owner=my-bitbucket-project \ - --username=my-bitbucket-username \ - --repository=my-repository \ - --branch=main \ - --path=clusters/my-cluster -``` - -If your Bitbucket Server has SSH access disabled, you can use HTTPS and token authentication with: - -```sh -flux bootstrap bitbucket-server \ - --token-auth \ - --hostname=my-bitbucket-server.com \ - --owner=my-bitbucket-project \ - --username=my-bitbucket-username \ - --repository=my-repository \ - --branch=main \ - --path=clusters/my-cluster -``` - -### Air-gapped Environments - -To bootstrap Flux on air-gapped environments without access to github.com and ghcr.io, first you'll need -to download the `flux` binary, and the container images from a computer with access to internet. - -List all container images: - -```sh -$ flux install --export | grep ghcr.io - -image: ghcr.io/fluxcd/helm-controller:v2.0.0-rc.4 -image: ghcr.io/fluxcd/kustomize-controller:v2.0.0-rc.4 -image: ghcr.io/fluxcd/notification-controller:v2.0.0-rc.4 -image: ghcr.io/fluxcd/source-controller:v2.0.0-rc.4 -``` - -Pull the images locally and push them to your container registry: - -```sh -docker pull ghcr.io/fluxcd/source-controller:v2.0.0-rc.4 -docker tag ghcr.io/fluxcd/source-controller:v2.0.0-rc.4 registry.internal/fluxcd/source-controller:v2.0.0-rc.4 -docker push registry.internal/fluxcd/source-controller:v2.0.0-rc.4 -``` - -Copy `flux` binary to a computer with access to your air-gapped cluster, -and create the pull secret in the `flux-system` namespace: - -```sh -kubectl create ns flux-system - -kubectl -n flux-system create secret generic regcred \ - --from-file=.dockerconfigjson=/.docker/config.json \ - --type=kubernetes.io/dockerconfigjson -``` - -Finally, bootstrap Flux using the images from your private registry: - -```sh -flux bootstrap \ - --registry=registry.internal/fluxcd \ - --image-pull-secret=regcred \ - --hostname=my-git-server.internal -``` - -Note that when running `flux bootstrap` without specifying a `--version`, -the CLI will use the manifests embedded in its binary instead of downloading -them from GitHub. You can determine which version you'll be installing, -with `flux --version`. - -## Bootstrap with Terraform - -The bootstrap procedure can be implemented with Terraform using the Flux provider published on -[registry.terraform.io](https://registry.terraform.io/providers/fluxcd/flux). -The provider offers a Terraform resource called -[flux_bootstrap_git](https://registry.terraform.io/providers/fluxcd/flux/latest/docs/resources/bootstrap_git) -that can be used to bootstrap Flux in the same way the Flux CLI does it. - -Example of Git HTTPS bootstrap: - -```hcl -provider "flux" { - kubernetes = { - config_path = "~/.kube/config" - } - git = { - url = var.gitlab_url - http = { - username = var.gitlab_user - password = var.gitlab_token - } - } -} - -resource "flux_bootstrap_git" "this" { - path = "clusters/my-cluster" - network_policy = true - kustomization_override = file("${path.module}/kustomization.yaml") -} -``` - -For more details on how to use the Terraform provider -please see the [Flux docs on registry.terraform.io](https://registry.terraform.io/providers/fluxcd/flux/latest/docs). - -## Customize Flux manifests - -You can customize the Flux components before or after running bootstrap. - -Assuming you want to customise the Flux controllers before they get deployed on the cluster, -first you'll need to create a Git repository and clone it locally. - -Create the file structure required by bootstrap with: - -```sh -mkdir -p clusters/my-cluster/flux-system -touch clusters/my-cluster/flux-system/gotk-components.yaml \ - clusters/my-cluster/flux-system/gotk-sync.yaml \ - clusters/my-cluster/flux-system/kustomization.yaml -``` - -Add patches to `kustomization.yaml`: - -```yaml -apiVersion: kustomize.config.k8s.io/v1 -kind: Kustomization -resources: # manifests generated during bootstrap - - gotk-components.yaml - - gotk-sync.yaml - -patches: # customize the manifests during bootstrap - - target: - kind: Deployment - labelSelector: app.kubernetes.io/part-of=flux - patch: | - # strategic merge or JSON patch -``` - -Push the changes to main branch: - -```sh -git add -A && git commit -m "init flux" && git push -``` - -And run the bootstrap for `clusters/my-cluster`: - -```sh -flux bootstrap git \ - --url=ssh://git@// \ - --branch=main \ - --path=clusters/my-cluster -``` - -To make further amendments, pull the changes locally, -edit the `kustomization.yaml` file, push the changes upstream -and rerun bootstrap or let Flux upgrade itself. - -Checkout the [bootstrap cheatsheet](cheatsheets/bootstrap.md) for various examples of how to customize Flux. - -### Multi-tenancy lockdown - -Assuming you want to lock down Flux on multi-tenant clusters, -add the following patches to `clusters/my-cluster/flux-system/kustomization.yaml`: - -```yaml -apiVersion: kustomize.config.k8s.io/v1 -kind: Kustomization -resources: - - gotk-components.yaml - - gotk-sync.yaml -patches: - - patch: | - - op: add - path: /spec/template/spec/containers/0/args/0 - value: --no-cross-namespace-refs=true - target: - kind: Deployment - name: "(kustomize-controller|helm-controller|notification-controller|image-reflector-controller|image-automation-controller)" - - patch: | - - op: add - path: /spec/template/spec/containers/0/args/- - value: --no-remote-bases=true - target: - kind: Deployment - name: "kustomize-controller" - - patch: | - - op: add - path: /spec/template/spec/containers/0/args/0 - value: --default-service-account=default - target: - kind: Deployment - name: "(kustomize-controller|helm-controller)" - - patch: | - - op: add - path: /spec/serviceAccountName - value: kustomize-controller - target: - kind: Kustomization - name: "flux-system" -``` - -With the above configuration, Flux will: - -- Deny cross-namespace access to Flux custom resources, thus ensuring that a tenant can't use another tenant's sources or subscribe to their events. -- Deny accesses to Kustomize remote bases, thus ensuring all resources refer to local files, meaning only the Flux Sources can affect the cluster-state. -- All `Kustomizations` and `HelmReleases` which don't have `spec.serviceAccountName` specified, will use the `default` account from the tenant's namespace. - Tenants have to specify a service account in their Flux resources to be able to deploy workloads in their namespaces as the `default` account has no permissions. -- The flux-system `Kustomization` is set to reconcile under a service account with cluster-admin role, - allowing platform admins to configure cluster-wide resources and provision the tenant's namespaces, service accounts and RBAC. - -To apply these patches, push the changes to the main branch and run `flux bootstrap`. - -## Dev install - -For testing purposes you can install Flux without storing its manifests in a Git repository: - -```sh -flux install -``` - -Or using kubectl: - -```sh -kubectl apply -f https://github.com/fluxcd/flux2/releases/latest/download/install.yaml -``` - -Then you can register Git repositories and reconcile them on your cluster: - -```sh -flux create source git podinfo \ - --url=https://github.com/stefanprodan/podinfo \ - --tag-semver=">=4.0.0" \ - --interval=1m - -flux create kustomization podinfo-default \ - --source=podinfo \ - --path="./kustomize" \ - --prune=true \ - --validation=client \ - --interval=10m \ - --health-check="Deployment/podinfo.default" \ - --health-check-timeout=2m \ - --target-namespace=default -``` - -You can register Helm repositories and create Helm releases: - -```sh -flux create source helm bitnami \ - --interval=1h \ - --url=https://charts.bitnami.com/bitnami - -flux create helmrelease nginx \ - --interval=1h \ - --release-name=nginx-ingress-controller \ - --target-namespace=kube-system \ - --source=HelmRepository/bitnami \ - --chart=nginx-ingress-controller \ - --chart-version="5.x.x" -``` - -## Deploy key rotation - -There are several reasons you may want to rotate the deploy key: - -- The token used to generate the key has expired. -- The key has been compromised. -- You want to change the scope of the key, e.g. to allow write access using the `--read-write-key` flag to `flux bootstrap`. - -While you can run `flux bootstrap` repeatedly, be aware that the `flux-system` Kubernetes Secret is never overwritten. -You need to manually rotate the key as described here. - -To rotate the SSH key generated at bootstrap, first delete the secret from the cluster with: - -```sh -kubectl -n flux-system delete secret flux-system -``` - -Then you have two alternatives to generate a new key: - -1. Generate a new secret with - - ```sh - flux create secret git flux-system \ - --url=ssh://git@// - ``` - The above command will print the SSH public key, once you set it as the deploy key, - Flux will resume all operations. -2. Run `flux bootstrap ...` again. This will generate a new key pair and, - depending on which Git provider you use, print the SSH public key that you then - set as deploy key or automatically set the deploy key (e.g. with GitHub). - -## Upgrade - -{{% 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). - -Verify that you are running the latest version with: - -```sh -flux --version -``` - -### Bootstrap upgrade - -If you've used the [bootstrap](#bootstrap) procedure to deploy Flux, -then rerun the bootstrap command for each cluster using the same arguments as before: - -```sh -flux bootstrap github \ - --owner=my-github-username \ - --repository=my-repository \ - --branch=main \ - --path=clusters/my-cluster \ - --personal -``` - -The above command will clone the repository, it will update the components manifest in -`/flux-system/gotk-components.yaml` and it will push the changes to the remote branch. - -Tell Flux to pull the manifests from Git and upgrade itself with: - -```sh -flux reconcile source git flux-system -``` - -Verify that the controllers have been upgrade with: - -```sh -flux check -``` - -{{% 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](/flux/flux-gh-action.md). -{{% /alert %}} - -### Terraform upgrade - -Update the Flux provider to the [latest release](https://github.com/fluxcd/terraform-provider-flux/releases) -and run `terraform apply`. - -Tell Flux to upgrade itself in-cluster or wait for it to pull the latest commit from Git: - -```sh -kubectl annotate --overwrite gitrepository/flux-system reconcile.fluxcd.io/requestedAt="$(date +%s)" -``` - -### In-cluster upgrade - -If you've installed Flux directly on the cluster, then rerun the install command: - -```sh -flux install -``` - -The above command will apply the new manifests on your cluster. -You can verify that the controllers have been upgraded to the latest version with `flux check`. - -If you've installed Flux directly on the cluster with kubectl, -then rerun the command using the latest manifests from the `main` branch: - -```sh -kustomize build https://github.com/fluxcd/flux2/manifests/install?ref=main | kubectl apply -f- -``` - -## Uninstall - -You can uninstall Flux with: - -```sh -flux uninstall --namespace=flux-system -``` - -The above command performs the following operations: - -- deletes Flux components (deployments and services) -- deletes Flux network policies -- deletes Flux RBAC (service accounts, cluster roles and cluster role bindings) -- removes the Kubernetes finalizers from Flux custom resources -- deletes Flux custom resource definitions and custom resources -- deletes the namespace where Flux was installed - -If you've installed Flux in a namespace that you wish to preserve, you -can skip the namespace deletion with: - -```sh -flux uninstall --namespace=infra --keep-namespace -``` - -{{% alert color="info" title="Reinstall" %}} -Note that the `uninstall` command will not remove any Kubernetes objects -or Helm releases that were reconciled on the cluster by Flux. -It is safe to uninstall Flux and rerun the bootstrap, any existing workloads -will not be affected. -{{% /alert %}} diff --git a/content/en/flux/use-cases/aws-codecommit.md b/content/en/flux/use-cases/aws-codecommit.md deleted file mode 100644 index de23423c3..000000000 --- a/content/en/flux/use-cases/aws-codecommit.md +++ /dev/null @@ -1,115 +0,0 @@ ---- -title: Using Flux on AWS With CodeCommit -linkTitle: AWS CodeCommit -description: "How to bootstrap Flux on AWS EKS with CodeCommit Git repositories." -weight: 10 ---- - -## EKS Cluster Options - -### VPC CodeCommit Access - -If your VPC is setup without internet access or you would prefer that the access was over a private connection, you -will need to set up a VPC endpoint to have access to CodeCommit. You can do this by following the guide [Using AWS -CodeCommit with interface VPC endpoints](https://docs.aws.amazon.com/codecommit/latest/userguide/codecommit-and-interface-VPC.html). - -### Cluster Creation - -The following creates an EKS cluster with some minimal configuration that will work well with Flux: - -```sh -eksctl create cluster -``` - -For more details on how to create an EKS cluster with `eksctl` please see [eksctl.io](https://eksctl.io). - -## Flux Installation for AWS CodeCommit - -You can install Flux using a AWS CodeCommit repository using the [`flux bootstrap git`](../installation.md#bootstrap) -command. -Ensure you can login to console.aws.amazon.com for your proper organization, and create a new repository to hold your Flux -install and other Kubernetes resources. - -To bootstrap using HTTPS, run the following command: -```sh -flux bootstrap git \ - --url=https://git-codecommit..amazonaws.com/v1/repos/ \ - --branch=main \ - --username= \ - --password= \ - --token-auth=true -``` - -To bootstrap using SSH, you first need to generate a SSH keypair to be used as a deploy key. -AWS CodeCommit does not support repository or org-specific SSH/deploy keys. You may add the deploy -key to a user's personal SSH keys, but take note that revoking the user's access to the repository -will also revoke Flux's access. The better alternative is to create a machine-user whose sole -purpose is to store credentials for automation. Using a machine-user also has the benefit of being -able to be read-only or restricted to specific repositories if this is needed. -```sh -aws iam upload-ssh-public-key --user-name codecommit-user --ssh-public-key-body file://sshkey.pub -``` - -The output shall contain a field `SSHPublicKeyID`, which acts as the SSH username. -```json -{ - "SSHPublicKey": { - "UserName": "codecommit-user", - "SSHPublicKeyId": "", - "Fingerprint": "", - "SSHPublicKeyBody": "", - "Status": "Active", - "UploadDate": "2022-11-14T15:15:12+00:00" - } -} -``` - -Now we can run the bootstrap command: -```sh -flux bootstrap git \ - --url=ssh://@git-codecommit..amazonaws.com/v1/repos/ - --branch=main - --private-key-file= - --password= - --silent -``` - -{{% alert color="info" %}} -Unlike other Git providers, in the case of AWS CodeCommit, you can not use HTTPS for bootstraping -and SSH for driving the reconciliation forward, i.e. you can not provide a HTTPS url without -passing `--token-auth=true` as well. -{{% /alert %}} - -{{% 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. `git-codecommit..amazonaws.com:v1`). -Use the [RFC 3986 compatible syntax](https://tools.ietf.org/html/rfc3986#section-3) instead: `git-codecommit..amazonaws.com/v1`. -{{% /alert %}} - -## Secrets Management with SOPS and AWS KMS - -You will need to use AWS KMS and enable the IAM OIDC provider on the cluster. - -Patch kustomize-controller with the proper IAM credentials, so that it may access your AWS KMS, and then begin -committing SOPS encrypted files to the Git repository with the proper AWS KMS configuration. - -See the [Mozilla SOPS AWS Guide](../guides/mozilla-sops.md#aws) for further detail. - -## Image Updates with Elastic Container Registry - -You will need to create an ECR registry and setup an IAM Role with the [required -permissions](https://docs.aws.amazon.com/AmazonECR/latest/userguide/ECR_on_EKS.html). - -{{% alert color="info" %}} -If you used `eksctl` or the AWS CloudFormation templates in [Getting Started with Amazon -EKS](https://docs.aws.amazon.com/eks/latest/userguide/getting-started.html) to create your cluster and worker -node groups, these IAM permissions are applied to your worker node IAM Role by default. -{{% /alert %}} - -Follow the [Image Update Automation Guide](../guides/image-update.md) and see the -[ECR specific section](../guides/image-update.md#aws-elastic-container-registry) for more details. - -Your EKS cluster's configuration can also be updated to -[allow the kubelets to pull images from ECR](https://docs.aws.amazon.com/AmazonECR/latest/userguide/ECR_on_EKS.html) -without ImagePullSecrets as an optional, complimentary step. diff --git a/content/en/flux/use-cases/azure.md b/content/en/flux/use-cases/azure.md deleted file mode 100644 index 37410ff25..000000000 --- a/content/en/flux/use-cases/azure.md +++ /dev/null @@ -1,241 +0,0 @@ ---- -title: Using Flux on Azure -linkTitle: Azure -description: "How to bootstrap Flux on Azure AKS with DevOps Git repositories." -weight: 10 ---- - -## AKS Cluster Options - -It's important to follow some guidelines when installing Flux on AKS. - -### CNI and Network Policy - -Previously, there has been an issue with Flux and Network Policy on AKS. -([Upstream Azure Issue](https://github.com/Azure/AKS/issues/2031)) ([Flux Issue](https://github.com/fluxcd/flux2/issues/703)) -If you ensure your AKS cluster is upgraded, and your Nodes have been restarted with the most recent Node images, -this could resolve flux reconciliation failures where source-controller is unreachable. -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. - -{{% alert color="warning" %}} -AKS `--network-policy` is currently in Preview -{{% /alert %}} - -### AAD Workload Identity - -[AAD Workload Identities](https://learn.microsoft.com/en-us/azure/aks/workload-identity-overview) can be used -to enable access to AAD resources from workloads in your Kubernetes cluster. - -In order to leverage AAD Workload Identities, you'll need to have `--enable-oidc-issuer` -and `--enable-workload-identity` configured in your AKS cluster. - -You will also need to establish an identity that has access to ACR. - -You can then [establish a federated identity credential](https://azure.github.io/azure-workload-identity/docs/quick-start.html#6-establish-federated-identity-credential-between-the-identity-and-the-service-account-issuer--subject) -between the identity and the Flux source-controller ServiceAccount. - -Please follow guides for [OCIRepositories and AAD Workload Identities](https://fluxcd.io/flux/components/source/ocirepositories/#workload-identity) -and [HelmRepositories and AAD Workload Identities](https://fluxcd.io/flux/components/source/helmrepositories/#azure-workload-identity). - -### AAD Pod Identity - -{{% warning %}} -[AAD Pod Identity has been deprecated](https://github.com/Azure/aad-pod-identity#-announcement) and replaced with -Azure Workload Identity. -{{% /warning %}} - -Depending on the features you are interested in using with Flux, you may want to install AAD Pod Identity. -With [AAD Pod-Identity](https://azure.github.io/aad-pod-identity/docs/), we can create Pods that have their own -cloud credentials for accessing Azure services like Azure Container Registry(ACR) and Azure Key Vault(AKV). - -If you do not use AAD Pod-Identity, you'll need to manage and store Service Principal credentials -in K8s Secrets, to integrate Flux with other Azure Services. - -As a pre-requisite, your cluster must have `--enable-managed-identity` configured. - -This software can be [installed via Helm](https://azure.github.io/aad-pod-identity/docs/getting-started/installation/) -(unmanaged by Azure). -Use Flux's `HelmRepository` and `HelmRelease` object to manage the aad-pod-identity installation -from a bootstrap repository and keep it up to date. - -{{% 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 - -The following creates an AKS cluster with some minimal configuration that will work well with Flux: - -```sh -az aks create \ - --network-plugin="azure" \ - --network-policy="calico" \ - --enable-managed-identity \ - --enable-oidc-issuer \ - --enable-workload-identity \ - --name="my-cluster" -``` - -{{% 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 - -You can install Flux using a Azure Devops repository using the [`flux bootsrap git`](../installation.md#bootstrap) -command. -Ensure you can login to [dev.azure.com](https://dev.azure.com) for your proper organization, -and create a new repository to hold your Flux install and other Kubernetes resources. - -To bootstrap using HTTPS only, run the following command: -```sh -flux bootstrap git \ - --url=https://dev.azure.com///_git/ \ - --branch=main \ - --password=${AZ_PAT_TOKEN} \ - --token-auth=true -``` - -Please consult the [Azure DevOps documentation](https://docs.microsoft.com/en-us/azure/devops/organizations/accounts/use-personal-access-tokens-to-authenticate?view=azure-devops&tabs=preview-page) -on how to generate personal access tokens for Git repositories. -Azure DevOps PAT's always have an expiration date, so be sure to have some process for renewing or updating these tokens. -Similar to the lack of repo-specific deploy keys, a user needs to generate a user-specific PAT. -If you are using a machine-user, you can generate a PAT or simply use the machine-user's password which does not expire. - -To bootstrap using HTTPS but drive the reconciliation in your cluster by cloning the repository using SSH, run: -```sh -flux bootstrap git \ - --url=https://dev.azure.com///_git/ \ - --branch=main \ - --password=${AZ_PAT_TOKEN}} \ - --ssh-hostname=ssh.dev.azure.com -``` - -To bootstrap using SSH, run: -```sh -flux bootstrap git \ - --url=ssh://git@ssh.dev.azure.com/v3/// - --branch=main \ - --ssh-key-algorithm=rsa \ - --ssh-rsa-bits=4096 \ - --interval=1m -``` - -The above two commands will prompt you to add a deploy key to your repository, but Azure DevOps -[does not support repository or org-specific deploy keys](https://developercommunity.visualstudio.com/t/allow-the-creation-of-ssh-deploy-keys-for-vsts-hos/365747). -You may add the deploy key to a user's personal SSH keys, but take note that revoking -the user's access to the repository will also revoke Flux's access. -The better alternative is to create a machine-user whose sole purpose is to store credentials -for automation. Using a machine-user also has the benefit of being able to be read-only or -restricted to specific repositories if this is needed. - -{{% 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 %}} - -## Helm Repositories on Azure Container Registry - -The Flux `HelmRepository` object currently supports -[Chart Repositories](https://helm.sh/docs/topics/chart_repository/) -as well as fetching `HelmCharts` from paths in `GitRepository` sources. - -Azure Container Registry has a sub-command ([`az acr helm`](https://docs.microsoft.com/en-us/cli/azure/acr/helm)) -for working with ACR-Hosted Chart Repositories, but it is deprecated. -If you are using these deprecated Azure Chart Repositories, -you can use Flux `HelmRepository` objects with them. - -### Using Helm OCI with Azure Container Registry - -You can use Helm OCI Charts in Azure Container Registry with Flux. - -You have to declare a `HelmRepository` object on your cluster: - -```sh -flux create source helm podinfo \ - --url=oci://my-user.azurecr.io/charts/my-chart - --username=username \ - --password=password -``` - -or if you are using a private registry: - -```sh -flux create source helm my-helm-repo \ - --url=oci://my-user.azurecr.io/charts/my-chart - --secret-ref=regcred -``` - -You can create the secret by running: - -```sh -kubectl create secret docker-registry regcred \ - --docker-server=my-user.azurecr.io \ - --docker-username=az-user \ - --docker-password=az-token -``` - -Then, you can use the `HelmRepository` object in your `HelmRelease`: - -```sh -flux create hr my-helm-release \ - --interval=10m \ - --source=HelmRepository/my-helm-repo \ - --chart=my-chart \ - --chart-version=">6.0.0" -``` - -## Secrets Management with SOPS and Azure Key Vault - -You will need to create an Azure Key Vault and bind a credential such as a Service Principal or Managed Identity to it. -If you want to use Managed Identities, install or enable [AAD Pod Identity](#aad-pod-identity). - -Patch kustomize-controller with the proper Azure credentials, so that it may access your Azure Key Vault, and then begin -committing SOPS encrypted files to the Git repository with the proper Azure Key Vault configuration. - -See the [Mozilla SOPS Azure Guide](../guides/mozilla-sops.md#azure) for further detail. - -## Image Updates with Azure Container Registry - -You will need to create an ACR registry and bind a credential such as a Service Principal or Managed Identity to it. -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" \ - --export > ./clusters/my-cluster/flux-system/gotk-components.yaml -``` - -Follow the [Image Update Automation Guide](../guides/image-update.md) and see the -[ACR specific section](../guides/image-update.md#azure-container-registry) for more details. - -Your AKS cluster's configuration can also be updated to -[allow the kubelets to pull images from ACR](https://docs.microsoft.com/en-us/azure/aks/cluster-container-registry-integration) -without ImagePullSecrets as an optional, complimentary step. - -## Azure Event Hub with Notification controller - -The Notification Controller supports both JWT and SAS based tokens but it also assumes that you will provide the notification-controller with a fresh token when needed. - -For JWT token based auth we have created a small example on how to automatically generate a new token that the notification-controller can use. - -First you will need to create a Azure Event Hub and bind a [credential](https://docs.microsoft.com/en-us/azure/event-hubs/authenticate-application) such as a Service Principal or Managed Identity to it. -If you want to use Managed Identities, install or enable [AAD Pod Identity](#aad-pod-identity). - -We have two ways to [automatically generate](https://github.com/fluxcd/flux2/tree/main/manifests/integrations/eventhub-credentials-sync) new JWT tokens. Ether running as a deployment or a cronjob. - -If you are using Azure Event Hub in Azure we recommend that you use aadpodidentity. -If you do you will need to update the [AzureIdentity config example](https://github.com/fluxcd/flux2/blob/main/manifests/integrations/eventhub-credentials-sync/azure/config-patches.yaml). - -If you are in none Azure environment like on-prem or another cloud then you can utilize client secret which you will find in the example [generic folder](https://github.com/fluxcd/flux2/tree/main/manifests/integrations/eventhub-credentials-sync/generic). -Just like aadpodidentity you can use deployment based or a cronjob. - -For more info on how to use Azure Event Hub with the [notification controller](../components/notification/provider.md#azure-event-hub). diff --git a/content/en/flux/use-cases/gcp-source-repository.md b/content/en/flux/use-cases/gcp-source-repository.md deleted file mode 100644 index 0535fcfdb..000000000 --- a/content/en/flux/use-cases/gcp-source-repository.md +++ /dev/null @@ -1,110 +0,0 @@ ---- -title: Using Flux on GCP With Source Repository -linkTitle: Google Cloud Source Repositories -description: "How to bootstrap Flux on GCP GKE with Cloud Source repositories." -weight: 10 ---- - -### Cluster Creation - -To create a cluster with Google Cloud you can use the `gcloud` cli or the Google Cloud Console. - -The following command creates a cluster with the default configuration. - -```sh -gcloud containers create sample-cluster -``` - -For more details on how to create a GKE cluster with `gcloud`, -please see [the Cloud SDK Documentation](https://cloud.google.com/sdk/gcloud/reference/container/clusters/create) - -### Source Repository Creation - -Create a Cloud Source Repository that will hold your Flux installation manifests and other Kubernetes resources. -Like the cluster, it can be created with the CLI or the console. - -### Flux Installation - -Download the [Flux CLI](../installation.md#install-the-flux-cli) and bootstrap Flux with: - -```sh -flux bootstrap git \ ---url=ssh://s@source.developers.google.com:2022/p//r/ \ ---branch=master \ ---path=clusters/my-cluster -``` - -The above command will prompt you to add a deploy key to your repository, but Cloud Source Repository -does not support repository or org-specific deploy keys. You may add the deploy key to a user's -personal SSH keys, but take note that revoking the user's access to the repository will -also revoke Flux's access. The better alternative is to create a dedicated user for Flux. - -You can also use a SSH key that was already added to Cloud Source Repository -by adding the `--private-key-file` and `--password` flags. - -### Flux Upgrade - -To upgrade Flux, first you need to download the new CLI binary -from [GitHub release](../installation.md#install-the-flux-cli). - -Flux components can be upgraded by running the `bootstrap` command again with the same arguments as before: - -```sh -flux bootstrap git \ ---url=ssh://s@source.developers.google.com:2022/p//r/ \ ---branch=master \ ---path=clusters/my-cluster -``` - -To upgrade Flux in a GitOps manner, you can generate the components manifests with the `install` command -and commit the changes to your Git repository: - -```sh -flux install --export > clusters/my-cluster/flux-system/gotk-components.yaml -git add -A -git commit -m "Update $(flux -v)" -git push -``` - -Once Flux detects the changes in Git, it will upgrade itself. - -### Secrets Management with SOPS and GCP KMS - -You would need to create GCP KMS key and have -[workload identity](https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity) enabled on the GKE cluster. -Create an IAM service account that has `Cloud KMS CryptoKey Decrypter` role and allow the kustomize-controller -service account to impersonate this service account by adding an IAM policy binding between it and the IAM service account. - -```sh -gcloud iam service-accounts add-iam-policy-binding @.iam.gserviceaccount.com \ - --role roles/iam.workloadIdentityUser \ - --member "serviceAccount:.svc.id.goog[flux-system/kustomize-controller]" -``` - -Patch the kustomize-controller with the -`iam.gke.io/gcp-service-account=@.iam.gserviceaccount.com` -annotation so that it can access GCP KMS. -You can start committing your encrypted files to Git with the proper GCP KMS configuration. - -See the [Mozilla SOPS AWS Guide](../guides/mozilla-sops.md#google-cloud) for further detail. - -### Image Updates with Google Container Registry - -You will need to create an GCR registry. Most new GKE cluster by default have access to -Google Container Registry in the same project. -But if you have enabled Workload Identity on your cluster, -you would need to create an IAM service account that has access to GCR. - -You may need to update your Flux install to include additional components: - -```sh -flux bootstrap git \ ---url=ssh://s@source.developers.google.com:2022/p//r/ \ ---branch=master \ ---path=clusters/my-cluster ---components-extra="image-reflector-controller,image-automation-controller" -``` - -Follow the [Image Update Automation Guide](../guides/image-update.md) and see the -[GCP specific Image Automation Contollers documentation](../components/image/imagerepositories/#gcp) -for more details on how to configure image update automation for GKE. diff --git a/content/en/flux/use-cases/openshift.md b/content/en/flux/use-cases/openshift.md deleted file mode 100644 index a3cc23639..000000000 --- a/content/en/flux/use-cases/openshift.md +++ /dev/null @@ -1,179 +0,0 @@ ---- -title: Using Flux on OpenShift -linkTitle: OpenShift -description: "How to bootstrap Flux on OpenShift." -weight: 20 ---- - -## OpenShift Setup - -Steps described in this document have been tested on OpenShift 4.6, 4.7 and 4.8. -You require cluster-admin privileges to install Flux on OpenShift. -This means that it currently is not possible to install Flux on the OpenShift Developer Sandbox. - -### CodeReady Containers - -An easy way to provision OpenShift is to use CodeReady Containers (CRC) for OpenShift, -which could be obtained from [here](https://developers.redhat.com/products/codeready-containers/overview). -With this setup, you require a physical Linux box. An OpenShift cluster will run inside a VM installed by CRC. - -{{% alert color="info" title="Resource Usage" %}} -Please note that your desktop / laptop should have at least 8 CPU cores with 32 GB of RAM as it is recommended to allocate -at least 4 CPU cores and 18 GB of RAM for the cluster to have a good experience. -{{% /alert %}} - -```sh -# Setup the OpenShift configuration -# You need to paste a pull secret here -crc setup - -# Start the cluster with 18 GB of RAM -crc start -c 4 -m 18432 -``` - -After the cluster is up and running, there will be a message tell us how to login. -Please make sure that you use `kubeadmin` user to login before installing Flux. - -```sh -# Prepare environment setup for the OC command -eval $(crc oc-env) - -# Login -oc login -u kubeadmin -p https://api.crc.testing:6443 -``` - -## Flux Installation with CLI - -The best way to install Flux on OpenShift currently is to use the `flux bootstrap` command. -This command works with GitHub, GitLab as well as generic Git provider. - -Before installing Flux with CLI, you need to set the **nonroot** SCC for all controllers in the `flux-system` namespace, like this: - -```sh -NS="flux-system" -oc adm policy add-scc-to-user nonroot system:serviceaccount:${NS}:kustomize-controller -oc adm policy add-scc-to-user nonroot system:serviceaccount:${NS}:helm-controller -oc adm policy add-scc-to-user nonroot system:serviceaccount:${NS}:source-controller -oc adm policy add-scc-to-user nonroot system:serviceaccount:${NS}:notification-controller -oc adm policy add-scc-to-user nonroot system:serviceaccount:${NS}:image-automation-controller -oc adm policy add-scc-to-user nonroot system:serviceaccount:${NS}:image-reflector-controller -``` - -Also, you have to patch your Kustomization to remove the SecComp Profile and enforce `runUserAs` to the same UID provided by the images to prevent OpenShift to alter the user expected by our controllers, before bootstrapping by. - -1. You’ll need to create a Git repository and clone it locally. - -2. Create the file structure required by bootstrap using the following command: - -```sh -mkdir -p clusters/my-cluster/flux-system -touch clusters/my-cluster/flux-system/gotk-components.yaml \ - clusters/my-cluster/flux-system/gotk-sync.yaml \ - clusters/my-cluster/flux-system/kustomization.yaml -``` - -3. Add the following YAML snippet and its patches section to kustomization.yaml - -```yaml -apiVersion: kustomize.config.k8s.io/v1beta1 -kind: Kustomization -resources: - - gotk-components.yaml - - gotk-sync.yaml -patches: - # Remove seccompProfile from the flux Deployments when running on OpenShift - - patch: | - apiVersion: apps/v1 - kind: Deployment - metadata: - name: all - spec: - template: - spec: - containers: - - name: manager - securityContext: - runAsUser: 65534 - seccompProfile: - $patch: delete - target: - kind: Deployment - labelSelector: app.kubernetes.io/part-of=flux - # OpenShift will overwrite these Namespace labels - # Remove them from the flux definition and leave them to openshift. - - patch: |- - - op: remove - path: /metadata/labels/pod-security.kubernetes.io~1warn - - op: remove - path: /metadata/labels/pod-security.kubernetes.io~1warn-version - target: - kind: Namespace - labelSelector: app.kubernetes.io/part-of=flux -``` - -4. Commit and push the changes to main branch: - -```sh -git add -A && git commit -m "init flux for openshift" && git push -``` - -Then you can continue with the Flux bootstrap process. Assuming that you are a GitHub user, you could start by preparing your GitHub credentials. - -```sh -export GITHUB_TOKEN= -export GITHUB_USER= -``` - -And run the Flux bootstrap command. - -```sh -flux bootstrap github \ - --owner=$GITHUB_USER \ - --repository=openshift-gitops \ - --branch=main \ - --path=./clusters/my-cluster \ - --personal -``` - -Please refer to the command's documentations [here](../installation/_index.md#bootstrap) in details. - -## Flux Upgrade - -Upgrading Flux on OpenShift is very simple and straightforward. -Please just make sure that you are already logged in as `kubeadmin` user. -Assuming you are a Homebrew user, you could upgrade Flux CLI using the following command. - -```sh -# Upgrade Flux -brew upgrade fluxcd/tap/flux - -# Check Flux version -flux -v - -# Login as kubeadmin -oc login -u kubeadmin -p https://api.crc.testing:6443 -``` - -After you obtained the Flux version you wanted, simply re-run the above `flux bootstrap` -command from the previous section, and all of your Flux component will be upgraded. - -```sh -# Re-running the bootstrap command to upgrade -flux bootstrap github \ - --owner=$GITHUB_USER \ - --repository=openshift-gitops \ - --branch=main \ - --path=./clusters/my-cluster \ - --personal -``` - -Please see also the [upgrade](../installation/_index.md#upgrade) -and the [bootstrap upgrade](../installation/_index.md#bootstrap-upgrade) documentations for details. - -## Flux Installation via OperatorHub - -Flux is available on OperatorHub and Red Hat OpenShift Community Operators, which means that you can install Flux directly from the Red Hat OperatorHub user interface. - -On the OpenShift UI, you go to "Operators -> OperatorHub" menu, search for "Flux", click the Flux Operator, then click the "Install" button. - -Here's the link to [Flux on OperatorHub](https://operatorhub.io/operator/flux). From 8ac534596a7e5e3bf8da36177a99f9ab06c80754 Mon Sep 17 00:00:00 2001 From: Stefan Prodan Date: Thu, 17 Aug 2023 12:39:37 +0300 Subject: [PATCH 6/7] Fix and normalise internal links Co-authored-by: Kingdon Barrett Co-authored-by: mehak151 <66996176+mehak151@users.noreply.github.com> Signed-off-by: Stefan Prodan --- content/en/blog/2021-01-06-january-update.md | 2 +- .../index.md | 2 +- .../en/blog/2021-04-29-may-update/index.md | 4 +- .../en/blog/2021-05-31-june-update/index.md | 2 +- .../en/blog/2021-08-02-august-update/index.md | 2 +- .../blog/2021-08-30-september-update/index.md | 6 +-- .../blog/2021-10-29-november-update/index.md | 2 +- .../blog/2021-11-30-december-update/index.md | 6 +-- .../blog/2022-01-31-january-update/index.md | 4 +- .../index.md | 2 +- .../en/blog/2022-02-22-security-fuzzing.md | 2 +- .../blog/2022-03-01-february-update/index.md | 2 +- ...-03-09-pod-security-standard-restricted.md | 2 +- .../index.md | 2 +- ...22-05-10-may-2022-security-announcement.md | 2 +- .../en/blog/2022-08-02-july-update/index.md | 2 +- .../index.md | 8 ++-- .../en/blog/2022-09-05-august-update/index.md | 20 ++++----- .../index.md | 4 +- .../blog/2022-10-04-september-update/index.md | 10 ++--- .../index.md | 2 +- .../blog/2022-10-19-kubecon-2022-na/index.md | 2 +- .../blog/2022-11-01-november-update/index.md | 4 +- .../index.md | 2 +- .../blog/2022-12-01-november-update/index.md | 4 +- content/en/blog/2023-02-01-january-update.md | 4 +- .../blog/2023-03-01-february-update/index.md | 6 +-- .../en/blog/2023-04-01-march-update/index.md | 12 +++--- .../en/blog/2023-05-02-april-update/index.md | 6 +-- .../en/blog/2023-06-06-may-update/index.md | 4 +- .../en/blog/2023-07-17-june-update/index.md | 2 +- .../en/contributing/docs/proposing-changes.md | 4 +- content/en/contributing/docs/style-guide.md | 7 ++-- content/en/contributing/flux-adopters.md | 2 +- .../tutorials/osm-progressive-delivery.md | 2 +- content/en/flagger/usage/how-it-works.md | 2 +- content/en/flagger/usage/webhooks.md | 2 +- content/en/flux/cheatsheets/oci-artifacts.md | 29 +++++++++++++ .../en/flux/cheatsheets/troubleshooting.md | 2 +- content/en/flux/concepts.md | 2 +- content/en/flux/faq.md | 32 ++++++++------ content/en/flux/flux-e2e.md | 41 ++++++++++++++---- content/en/flux/get-started.md | 8 ++-- content/en/flux/guides/cron-job-image-auth.md | 2 +- content/en/flux/guides/helmreleases.md | 2 +- content/en/flux/guides/image-update.md | 2 +- content/en/flux/guides/mozilla-sops.md | 16 +++---- content/en/flux/guides/notifications.md | 4 +- content/en/flux/guides/webhook-receivers.md | 10 ++--- .../migration/flux-v1-automation-migration.md | 8 ++-- .../flux/migration/helm-operator-migration.md | 42 +++++++++---------- content/en/flux/security/_index.md | 4 +- content/en/flux/security/best-practices.md | 2 +- .../flux/security/contextual-authorization.md | 30 ++++++------- .../en/flux/security/secrets-management.md | 2 +- .../use-cases/gh-actions-helm-promotion.md | 8 ++-- .../gh-actions-manifest-generation.md | 4 +- content/en/flux/use-cases/helm.md | 4 +- content/en/flux/use-cases/karmada.md | 2 +- content/en/roadmap.md | 4 +- 60 files changed, 236 insertions(+), 177 deletions(-) diff --git a/content/en/blog/2021-01-06-january-update.md b/content/en/blog/2021-01-06-january-update.md index c645ea537..08f64a4b6 100644 --- a/content/en/blog/2021-01-06-january-update.md +++ b/content/en/blog/2021-01-06-january-update.md @@ -112,7 +112,7 @@ Azure DevOps users will have to specify to use libgit2 in their GitRepository resources. Follow [the generic git server -guide](/flux/installation/#generic-git-server) +guide](/flux/installation/bootstrap/generic-git-server/) for further instructions in how to use Flux with Azure DevOps. Upcoming events diff --git a/content/en/blog/2021-03-08-flux-is-a-cncf-incubation-project/index.md b/content/en/blog/2021-03-08-flux-is-a-cncf-incubation-project/index.md index bfeee32ee..8498b1675 100644 --- a/content/en/blog/2021-03-08-flux-is-a-cncf-incubation-project/index.md +++ b/content/en/blog/2021-03-08-flux-is-a-cncf-incubation-project/index.md @@ -70,7 +70,7 @@ users migrate to Flux v2. Now is the perfect time to familiarise yourself with [Flux v2](/) - the Get Started guide only takes a couple of minutes to complete. -If you prefer a video, check out [our resources section](/#resources). +If you prefer a video, check out [our resources section](/resources/). Migrating from v1 will require some work, but it will definitely be worth it: in this iteration you are going to get diff --git a/content/en/blog/2021-04-29-may-update/index.md b/content/en/blog/2021-04-29-may-update/index.md index 8dc53c094..f9d5e7082 100644 --- a/content/en/blog/2021-04-29-may-update/index.md +++ b/content/en/blog/2021-04-29-may-update/index.md @@ -67,7 +67,7 @@ The Flux v2 CLI and the GitOps Toolkit controllers are now CII Best Practices certified. Checkout the [new bootstrap -procedure](/flux/installation/_index.md#generic-git-server). +procedure](/flux/installation/bootstrap/generic-git-server/). 0.13 comes with **breaking changes to image automation** and has the following highlights: @@ -95,7 +95,7 @@ Please follow the [upgrade procedure for image automation](https://github.com/fluxcd/flux2/discussions/1333). Checkout the [new bootstrap customisation -feature](/flux/installation/_index.md#customize-flux-manifests). +feature](/flux/installation/configuration/boostrap-customization/). The [Image automation guide](/flux/guides/image-update/) has been updated to the new APIs, and also includes a reference to a diff --git a/content/en/blog/2021-05-31-june-update/index.md b/content/en/blog/2021-05-31-june-update/index.md index 8dd57b11b..1a3127f06 100644 --- a/content/en/blog/2021-05-31-june-update/index.md +++ b/content/en/blog/2021-05-31-june-update/index.md @@ -37,7 +37,7 @@ The highlights are: Docs: - 📔 [GitRepository include - documentation](/flux/components/source/gitrepositories/#including-gitrepository) + documentation](/flux/components/source/gitrepositories/#include) - 🎁 Checkout the new [guide on ways of structuring your repositories](/flux/guides/repository-structure/) diff --git a/content/en/blog/2021-08-02-august-update/index.md b/content/en/blog/2021-08-02-august-update/index.md index f7af540fc..b2ee6badb 100644 --- a/content/en/blog/2021-08-02-august-update/index.md +++ b/content/en/blog/2021-08-02-august-update/index.md @@ -165,7 +165,7 @@ scheduling information available on the [CNCF Flux Dev Calendar](https://lists.cncf.io/g/cncf-flux-dev/calendar), usually scheduled opposite the CNCF Flux Project Meeting. You can [subscribe to the -calendar](/community/#subscribing-to-the-flux-dev-calendar) +calendar](/community/#subscribing-to-the-flux-calendar) to receive notifications about upcoming events and schedule changes. The Bug Scrub is an opportunity to meet with other Flux contributors in another setting besides the Dev meeting, where we try to identify "Good diff --git a/content/en/blog/2021-08-30-september-update/index.md b/content/en/blog/2021-08-30-september-update/index.md index ba575df64..3d8786390 100644 --- a/content/en/blog/2021-08-30-september-update/index.md +++ b/content/en/blog/2021-08-30-september-update/index.md @@ -76,7 +76,7 @@ Some of the highlights in this release are: Prometheus Operator and others. - The Notification controller can now send alerts to Telegram, Lark and Matrix in addition to [many - others](/flux/components/notification/provider/#specification). + others](/flux/components/notification/provider/#writing-a-provider-spec). - Kustomize controller has been updated to on a par with the latest Kustomize release v4.3.0. @@ -167,7 +167,7 @@ accessible than ever before. The Zoom link is broadcast via Slack a few minutes before the meeting start time. For more event details, subscribe to the [CNCF Flux Dev -calendar](/community/#subscribing-to-the-flux-dev-calendar). +calendar](/community/#subscribing-to-the-flux-calendar). Attendees all are asked to RSVP in advance, which can be done by posting on the Slack thread for Bug Scrub, and introducing yourself briefly in case you are new to the Flux contributor team. @@ -201,7 +201,7 @@ section - directly on the home page: For this we re-use Flux's calendar that is provided by CNCF infrastructure, so if you [subscribed to -it](/community/#subscribing-to-the-flux-dev-calendar) +it](/community/#subscribing-to-the-flux-calendar) in the past, you will continue to receive all the information there. **🤝 Thanks everyone!** In the last month, 15 people contributed to the diff --git a/content/en/blog/2021-10-29-november-update/index.md b/content/en/blog/2021-10-29-november-update/index.md index 6afcc5a92..c08059d98 100644 --- a/content/en/blog/2021-10-29-november-update/index.md +++ b/content/en/blog/2021-10-29-november-update/index.md @@ -234,7 +234,7 @@ Here is an update from Kingdon and the rest of the Flux team: > calendar](/#calendar), which has the Zoom > link and is in UTC time, or get reminded in your own time zone by > [subscribing to the flux-dev -> calendar](/community/#subscribing-to-the-flux-dev-calendar). +> calendar](/community/#subscribing-to-the-flux-calendar). > > Hope to see you there! diff --git a/content/en/blog/2021-11-30-december-update/index.md b/content/en/blog/2021-11-30-december-update/index.md index 0093425f5..712e787a8 100644 --- a/content/en/blog/2021-11-30-december-update/index.md +++ b/content/en/blog/2021-11-30-december-update/index.md @@ -74,14 +74,14 @@ And finally **0.24** comes with security updates for Alpine CVEs. We are also happy to bring you - New bootstrap command for [Bitbucket Server and Data - Center](/flux/installation/#bitbucket-server-and-data-center) + Center](/flux/installation/bootstrap/bitbucket/) repositories (CLI). - Add support for self-signed certificates when bootstrapping Flux with on-prem GitHub, GitLab and BitBucket servers (CLI). - Improved performance when building Helm charts and introduced limits for Helm index and chart files. (source-controller). - Add support for [Slack Apps - bot](/flux/components/notification/provider/#slack-app) + bot](/flux/components/notification/provider/#slack) alerting provider (notification-controller). Please note that this version comes with breaking changes to Helm users. @@ -98,7 +98,7 @@ Big shout-out to Soulé Ba for adding Bitbucket support to Flux. This will make lots of Flux users happy. Thank you very much! To find out how to bootstrap Flux on Bitbucket Server, please review -[our documentation](/flux/installation/#bitbucket-server-and-data-center). +[our documentation](/flux/installation/bootstrap/bitbucket/). We love feedback, so please reach out if you have any questions or are missing anything. We are also working on support for BitBucket Cloud, for which we might need some help testing, documentation or wherever diff --git a/content/en/blog/2022-01-31-january-update/index.md b/content/en/blog/2022-01-31-january-update/index.md index 1f87060f7..797c8d447 100644 --- a/content/en/blog/2022-01-31-january-update/index.md +++ b/content/en/blog/2022-01-31-january-update/index.md @@ -39,7 +39,7 @@ previously the controllers ignored the service account. #### :lock: Security enhancements - Platform admins have the option to [lock down Flux on multi-tenant - clusters](/flux/installation/#multi-tenancy-lockdown) + clusters](/flux/installation/configuration/multitenancy/) and enforce tenant isolation at namespace level without having to use a 3rd party admission controller. - The Flux installation conforms to the Kubernetes [restricted pod @@ -289,7 +289,7 @@ are less random and we can attract more interest. Look to the schedule for information about how to join at [https://fluxcd.io/\#calendar](/#calendar) or [add the Flux events to your own -calendar](/community/#subscribing-to-the-flux-dev-calendar) +calendar](/community/#subscribing-to-the-flux-calendar) if you want to participate, and be sure you don't miss out on the new Flux Bug Scrub, Special Edition! diff --git a/content/en/blog/2022-02-09-security-the-value-of-sboms/index.md b/content/en/blog/2022-02-09-security-the-value-of-sboms/index.md index 96ea57a64..c60d4bf78 100644 --- a/content/en/blog/2022-02-09-security-the-value-of-sboms/index.md +++ b/content/en/blog/2022-02-09-security-the-value-of-sboms/index.md @@ -14,7 +14,7 @@ resources: You don't get to re-architect a successful project very often, but we did about two years ago. The Flux project was already off to a great -start and had [many happy adopters](/adopters/#flux-v1) and many of +start and had [many happy adopters](/adopters/#flux-legacy) and many of its design principles we kept at the forefront of our mind: - Pull vs Push: if you haven't read this [great blog diff --git a/content/en/blog/2022-02-22-security-fuzzing.md b/content/en/blog/2022-02-22-security-fuzzing.md index 4f6c88ea3..3ef5d96c1 100644 --- a/content/en/blog/2022-02-22-security-fuzzing.md +++ b/content/en/blog/2022-02-22-security-fuzzing.md @@ -40,7 +40,7 @@ fuzzing for open source software](https://github.com/google/oss-fuzz). ## How we got here When we [announced the results of the security -audit](/blog/2021-11-10-flux-security-audit/#flux-coming-to-oss-fuzz) +audit](/blog/2021/11/flux-security-audit/#flux-coming-to-oss-fuzz) back in November, we already shared that the team at [ADA Logics](https://adalogics.com/) had helped put together an initial implementation of Fuzzing for some of the Flux controllers. In this diff --git a/content/en/blog/2022-03-01-february-update/index.md b/content/en/blog/2022-03-01-february-update/index.md index 8736b8bb3..11999502b 100644 --- a/content/en/blog/2022-03-01-february-update/index.md +++ b/content/en/blog/2022-03-01-february-update/index.md @@ -50,7 +50,7 @@ and improvements using the Alert API `spec.eventSources[].matchLabels` field. - Add support to `kustomize-controller` for making the Kubernetes `Secrets` and `ConfigMaps` referenced in `postBuild.substituteFrom` - [optional](/flux/components/kustomize/kustomization/#variable-substitution). + [optional](/flux/components/kustomize/kustomization/#post-build-variable-substitution). - Allow dot-prefixed paths to be used for bootstrap e.g. `flux bootstrap --path=".flux/clusters/my-cluster"`. - All Flux controllers and libraries are now tested by Google's diff --git a/content/en/blog/2022-03-09-pod-security-standard-restricted.md b/content/en/blog/2022-03-09-pod-security-standard-restricted.md index 08ec44d6d..e0653c9c7 100644 --- a/content/en/blog/2022-03-09-pod-security-standard-restricted.md +++ b/content/en/blog/2022-03-09-pod-security-standard-restricted.md @@ -83,7 +83,7 @@ issue](https://github.com/fluxcd/source-controller/issues/582) ([related upstream report](https://github.com/openshift/cluster-kube-apiserver-operator/issues/1325)). The work-around right now is to remove the seccomp profile as -described in [these instructions](/flux/use-cases/openshift/#flux-installation-with-cli). +described in [these instructions](/flux/use-cases/openshift/). {{% /note %}} ## `seccomp` and `RuntimeDefault` diff --git a/content/en/blog/2022-03-25-putting-the-git-into-gitops/index.md b/content/en/blog/2022-03-25-putting-the-git-into-gitops/index.md index 1ade5dfd1..b9ac7a68a 100644 --- a/content/en/blog/2022-03-25-putting-the-git-into-gitops/index.md +++ b/content/en/blog/2022-03-25-putting-the-git-into-gitops/index.md @@ -77,7 +77,7 @@ shortcomings. Things which "just work" in the Git CLI, any of the implementations get subtly wrong, as they work on the ["plumbing" level](https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Porcelain) of Git. In the end we chose to make `gitImplementation` a [configurable -setting](/flux/components/source/gitrepositories/#git-implementation). +setting](/flux/components/source/api/v1beta2/#source.toolkit.fluxcd.io/v1beta2.GitRepository). Just to illustrate what happens when you try to do things just right, here's a couple of pieces of work we needed to get done along diff --git a/content/en/blog/2022-05-10-may-2022-security-announcement.md b/content/en/blog/2022-05-10-may-2022-security-announcement.md index 78517572c..63a0f59d3 100644 --- a/content/en/blog/2022-05-10-may-2022-security-announcement.md +++ b/content/en/blog/2022-05-10-may-2022-security-announcement.md @@ -247,7 +247,7 @@ multi-tenancy: > example](https://github.com/fluxcd/flux2-multi-tenancy) > to help users kick start their multi-tenancy deployments. And also how > to implement control plane isolation with the* -> *[multi-tenancy-lockdown](/flux/cheatsheets/bootstrap/#multi-tenancy-lockdown).* +> *[multi-tenancy-lockdown](/flux/installation/configuration/multitenancy/).* > > ***What\'s next*** > diff --git a/content/en/blog/2022-08-02-july-update/index.md b/content/en/blog/2022-08-02-july-update/index.md index 71e580435..f96a502c0 100644 --- a/content/en/blog/2022-08-02-july-update/index.md +++ b/content/en/blog/2022-08-02-july-update/index.md @@ -300,7 +300,7 @@ couple of small things we landed recently: this document shows how to do just that. - We expanded our documentation on Azure to include [Using Helm OCI with Azure Container - Registry](/flux/use-cases/azure/#using-helm-oci-with-azure-container-registry). + Registry](/flux/components/source/helmrepositories/#provider). - Flagger news! We updated the docs on our website to match the newest version of Flagger (1.22). This adds a tutorial for how to do [Canary analysis with KEDA diff --git a/content/en/blog/2022-09-01-manage-kyverno-policies-as-ocirepositories/index.md b/content/en/blog/2022-09-01-manage-kyverno-policies-as-ocirepositories/index.md index 33a59fa8f..4e278cc0c 100644 --- a/content/en/blog/2022-09-01-manage-kyverno-policies-as-ocirepositories/index.md +++ b/content/en/blog/2022-09-01-manage-kyverno-policies-as-ocirepositories/index.md @@ -27,7 +27,7 @@ The Flux CLI generates a single layer OCI image for storing things. As you can u Today, we’ll leverage the OCI Repositories feature to apply Kyverno policies stored in an OCI registry into the Kubernetes cluster. -First, we need to install Flux CLI, please see the [installation](/docs/installation/) page for more details. +First, we need to install Flux CLI, please see the [installation](/flux/installation/) page for more details. Next, we should have a Kubernetes cluster running. We’ll be using [KinD](https://kind.sigs.k8s.io/docs/user/quick-start#configuring-your-kind-cluster) for this purpose. @@ -156,11 +156,11 @@ spec: kind: ClusterPolicy ``` -I'd like to highlight some key points about the resources above. Here in `OCIRepository` resource, we are using [SemVer](/docs/components/source/ocirepositories/#semver-example) to select the policies that we want to apply. `.spec.ref` is an optional field to specify the OCI reference to resolve and watch for changes. If not specified, the latest version of the repository will be used. You can reach out to the complete list of references supported in Flux, here is the [link](/docs/components/source/ocirepositories/#reference) for you. +I'd like to highlight some key points about the resources above. Here in `OCIRepository` resource, we are using [SemVer](/flux/components/source/ocirepositories/#semver-example) to select the policies that we want to apply. `.spec.ref` is an optional field to specify the OCI reference to resolve and watch for changes. If not specified, the latest version of the repository will be used. You can reach out to the complete list of references supported in Flux, here is the [link](/flux/components/source/ocirepositories/#reference) for you. -Also, in the `Kustomization` resource, we are using `.spec.patches` to apply patches to the policies that we want to enforce. We are using `op: replace` to replace the existing value of the field with the new one. `path` is the path to the field that we want to replace. `value` is the value of the field that we want to replace. To get more detail about the `Patches`, please see the [link](/docs/components/kustomize/kustomization/#patches). +Also, in the `Kustomization` resource, we are using `.spec.patches` to apply patches to the policies that we want to enforce. We are using `op: replace` to replace the existing value of the field with the new one. `path` is the path to the field that we want to replace. `value` is the value of the field that we want to replace. To get more detail about the `Patches`, please see the [link](/flux/components/kustomize/kustomization/#patches). -Last but not least, we are specifying an explicit dependencies for the `Kustomization` resource by using `dependsOn` keyword that ensures the Kyverno deployment is ready before applying the policies. This is important because Kyverno needs to be installed before applying the policies. Otherwise, the policies won't be used because CRD (Custom Resource Definitions) won't exist until Kyverno works. You can learn more about the dependencies of `Kustomization` resource, [here](/flux/components/kustomize/kustomization/#kustomization-dependencies). +Last but not least, we are specifying an explicit dependencies for the `Kustomization` resource by using `dependsOn` keyword that ensures the Kyverno deployment is ready before applying the policies. This is important because Kyverno needs to be installed before applying the policies. Otherwise, the policies won't be used because CRD (Custom Resource Definitions) won't exist until Kyverno works. You can learn more about the dependencies of `Kustomization` resource, [here](/flux/components/kustomize/kustomization/#dependencies). Now, we can apply these manifests by committing and pushing them to the repository and letting Flux take care of the rest but still, one little step left that we need to do, which is authentication. diff --git a/content/en/blog/2022-09-05-august-update/index.md b/content/en/blog/2022-09-05-august-update/index.md index 9ab9307de..7afad4912 100644 --- a/content/en/blog/2022-09-05-august-update/index.md +++ b/content/en/blog/2022-09-05-august-update/index.md @@ -31,7 +31,7 @@ Let's go through the major changes one by one. - Enable contextual login to container registries when pulling Helm charts from Amazon Elastic Container Registry, Azure Container Registry and Google Artifact Registry using - [`HelmRepository.spec.provider`](/docs/components/source/helmrepositories/#provider). + [`HelmRepository.spec.provider`](/flux/components/source/helmrepositories/#provider). - Select which layer contains the Kubernetes configs by specifying a matching OCI media type using [`OCIRepository.spec.layerSelector`](/flux/components/source/ocirepositories/#layer-selector). @@ -51,7 +51,7 @@ Let's go through the major changes one by one. The big news was of course that we added support for distributing Kubernetes manifests, Kustomize overlays and Terraform code as OCI artifacts. For more information on OCI support please see the [Flux -documentation](/docs/cheatsheets/oci-artifacts/). +documentation](/flux/cheatsheets/oci-artifacts/). Big thanks to the Flux contributors that helped us along the way. It took us almost 4 months, from the first RFC version to shipping OCI @@ -244,20 +244,20 @@ We are constantly improving our documentation and website - here are a couple of small things we landed recently: - New security docs on [Secrets - Management](/docs/security/secrets-management/) + Management](/flux/security/secrets-management/) and [Contextual - Authorization](/docs/security/contextual-authorization/). + Authorization](/flux/security/contextual-authorization/). - New blog post: [Managing Kyverno Policies as OCI Artifacts with OCIRepository Sources](/blog/2022/08/manage-kyverno-policies-as-ocirepositories) - Cheatsheet news - [OCI - Artifacts](/docs/cheatsheets/oci-artifacts/) + Artifacts](/flux/cheatsheets/oci-artifacts/) - Bootstrap: [Git repository access via SOCKS5 ssh - proxy](/docs/cheatsheets/bootstrap/#git-repository-access-via-socks5-ssh-proxy) + proxy](/flux/installation/configuration/proxy-setting/#git-repository-access-via-socks5-ssh-proxy) - Bootstrap: [Enable notifications for third party - controllers](/docs/cheatsheets/bootstrap/#enable-notifications-for-third-party-controllers) -- [Flux's Work Well With section](/docs/#flux-works-well-with): find out + controllers](/flux/cheatsheets/bootstrap/#enable-notifications-for-third-party-controllers) +- [Flux's Work Well With section](/flux/#flux-works-well-with): find out how to make Flux work with your favourite other OSS software - Lots of new videos from GitOpsCon / KubeCon on [our resources page](/resources/) @@ -341,7 +341,7 @@ some Flux facts - they are sort of our mission statement with Flux. assessments, alerting to external systems and external events handling. Just "git push", and get notified on Slack and [other chat - systems](https://github.com/fluxcd/notification-controller/blob/main/docs/spec/v1beta1/provider.md). + systems](https://github.com/fluxcd/notification-controller/blob/main/docs/spec/v1beta1/providers.md). 1. 👍 Users trust Flux: Flux is a CNCF Incubating project and was categorised as \"Adopt\" on the [CNCF CI/CD Tech Radar](https://radar.cncf.io/2020-06-continuous-delivery) @@ -364,7 +364,7 @@ good ways to do that: - Join the [planning discussions](https://github.com/fluxcd/flux2/discussions) - And if you are completely new to Flux, take a look at our [Get - Started guide](/docs/get-started/) + Started guide](/flux/get-started/) and give us feedback - Social media: Follow [Flux on Twitter](https://twitter.com/fluxcd), join the diff --git a/content/en/blog/2022-09-28-gitops-without-leaving-your-ide/index.md b/content/en/blog/2022-09-28-gitops-without-leaving-your-ide/index.md index 32d671409..7985e4061 100644 --- a/content/en/blog/2022-09-28-gitops-without-leaving-your-ide/index.md +++ b/content/en/blog/2022-09-28-gitops-without-leaving-your-ide/index.md @@ -11,7 +11,7 @@ resources: --- Welcome to the second [blog post in our Flux Ecosystem category](/tags/ecosystem/)! -This time we are talking about one of the [Flux UIs](/ecosystem/#flux-uis): it's +This time we are talking about one of the [Flux UIs](/ecosystem/#flux-uis--guis): it's the [VS Code GitOps Extension](https://github.com/weaveworks/vscode-gitops-tools). If you already use VS Code, this extension will be straight up your alley: it @@ -32,7 +32,7 @@ the Install button away. Additionally, you will need to - [Install Kubectl](https://kubectl.docs.kubernetes.io/installation/kubectl/) -- [Install Flux CLI](/docs/installation/#install-the-flux-cli) +- [Install Flux CLI](/flux/installation/#install-the-flux-cli) - [Install git](https://git-scm.com/downloads) Optionally, if available, the extension will make use of the `az` tool diff --git a/content/en/blog/2022-10-04-september-update/index.md b/content/en/blog/2022-10-04-september-update/index.md index cd669591f..3f6621446 100644 --- a/content/en/blog/2022-10-04-september-update/index.md +++ b/content/en/blog/2022-10-04-september-update/index.md @@ -40,7 +40,7 @@ features and improvements: - Verify OCI artifacts signed by Cosign (including `keyless` - currently still experimental and only supporting GCP and GHCR) with - [OCIRepository.spec.verify](/docs/components/source/ocirepositories/#verification). + [OCIRepository.spec.verify](/flux/components/source/ocirepositories/#verification). Note this supports contextual login, but not insecure registries. - Allow pulling Helm charts dependencies from HTTPS repositories with mixed self-signed TLS and public CAs. @@ -53,7 +53,7 @@ features and improvements: - The controllers and the Flux CLI are now built with Go 1.19. - Allow pulling artifacts from an in-cluster Docker Registry over plain HTTP with - [`OCIRepository.spec.insecure`](/docs/components/source/ocirepositories/#insecure). + [`OCIRepository.spec.insecure`](/flux/components/source/ocirepositories/#insecure). - Allow defining OCI sources for non-TLS container registries with `flux create source oci --insecure`. - Enable contextual login when publishing OCI artifacts from a Cloud @@ -72,7 +72,7 @@ features and improvements: DockerHub container registries under `fluxcd/flux-manifests`. For more information on OCI and Cosign support please see the [Flux -documentation](/docs/cheatsheets/oci-artifacts/#signing-and-verification). +documentation](/flux/cheatsheets/oci-artifacts/#signing-and-verification). It took us six months to debate, design and implement OCI support in Flux. Big thanks to all the Flux contributors that helped us reach this @@ -443,7 +443,7 @@ couple of small things we landed recently: - We simplified the build process of the website. We are on a very recent version of the Docsy theme again! -- Our [Bootstrap Cheatsheet](/docs/cheatsheets/bootstrap/) +- Our [Bootstrap Cheatsheet](/flux/cheatsheets/bootstrap/) now contains instructions on how to enable notifications for third party controllers. - [Flux End-To-End documentation](/flux/flux-e2e/) was @@ -516,7 +516,7 @@ good ways to do that: - Talk to us in the \#flux channel on [CNCF Slack](https://slack.cncf.io/) - Join the [planning discussions](https://github.com/fluxcd/flux2/discussions) - And if you are completely new to Flux, take a look at our [Get - Started guide](/docs/get-started/) and give us feedback + Started guide](/flux/get-started/) and give us feedback - Social media: Follow [Flux on Twitter](https://twitter.com/fluxcd), join the discussion in the [Flux LinkedIn group](https://www.linkedin.com/groups/8985374/). diff --git a/content/en/blog/2022-10-17-prove-the-authenticity-of-oci-artifacts/index.md b/content/en/blog/2022-10-17-prove-the-authenticity-of-oci-artifacts/index.md index d0d5d64b8..1d18b39aa 100644 --- a/content/en/blog/2022-10-17-prove-the-authenticity-of-oci-artifacts/index.md +++ b/content/en/blog/2022-10-17-prove-the-authenticity-of-oci-artifacts/index.md @@ -30,7 +30,7 @@ But this only covered the first stage of the entire implementation. There is mor One of the most exciting features of this RFC is the [verification of artifacts](https://github.com/fluxcd/flux2/tree/main/rfcs/0003-kubernetes-oci#verify-artifacts). But why, what is it, is it really necessary or just a hype thing? This is a long topic that we need to discuss. Suppose you store the cluster desired state as OCI artifacts in a container registry. How can you be one hundred percent sure that the resources that Flux reconciles are the same as the resources that you've pushed to the OCI registry? This is where the verification of artifacts comes into play. But, how can we do that? 🤔 -Thanks to the [Sigstore](https://www.sigstore.dev) community we have a great set of services and tools for signing and verifying authenticity. One of the tools is [cosign](https://docs.sigstore.dev/cosign/overview) which can be used for container signing, verification, and storage in an OCI registry. We will use it to verify the authenticity of the OCI Artifacts in Flux. Starting with [v0.35](https://github.com/fluxcd/flux2/releases/tag/v0.35.0), Flux comes with support for verifying OCI artifacts signed with Sigstore Cosign. Documentation for setting it up can be found [here](flux/cheatsheets/oci-artifacts/#signing-and-verification). +Thanks to the [Sigstore](https://www.sigstore.dev) community we have a great set of services and tools for signing and verifying authenticity. One of the tools is [cosign](https://docs.sigstore.dev/cosign/overview) which can be used for container signing, verification, and storage in an OCI registry. We will use it to verify the authenticity of the OCI Artifacts in Flux. Starting with [v0.35](https://github.com/fluxcd/flux2/releases/tag/v0.35.0), Flux comes with support for verifying OCI artifacts signed with Sigstore Cosign. Documentation for setting it up can be found [here](/flux/cheatsheets/oci-artifacts/#signing-and-verification). Let's jump right into the details of how we can actually use it. diff --git a/content/en/blog/2022-10-19-kubecon-2022-na/index.md b/content/en/blog/2022-10-19-kubecon-2022-na/index.md index add8a810b..7a2f93d52 100644 --- a/content/en/blog/2022-10-19-kubecon-2022-na/index.md +++ b/content/en/blog/2022-10-19-kubecon-2022-na/index.md @@ -14,7 +14,7 @@ resources: {{< /imgproc >}} Everybody in Team Flux is busy with [the run-up to Flux -GA](/roadmap/#the-road-to-flux-v2-ga), but -- with the help of +GA](/roadmap/#flux-gitops-ga-completed-in-july-2023), but -- with the help of the great folks in our Community and Ecosystem -- we also managed to put together quite a number of talks, tutorials and sessions for you at KubeCon / CloudNativeCon! diff --git a/content/en/blog/2022-11-01-november-update/index.md b/content/en/blog/2022-11-01-november-update/index.md index 20386fca3..aade3c04b 100644 --- a/content/en/blog/2022-11-01-november-update/index.md +++ b/content/en/blog/2022-11-01-november-update/index.md @@ -27,7 +27,7 @@ features further into Flux. Here is a list of features and improvements that were added in the last release: - Verify OCI Helm charts signed by Cosign (including keyless) with - [`HelmChart.spec.verify`](/docs/cheatsheets/oci-artifacts/#verify-helm-charts). + [`HelmChart.spec.verify`](/flux/cheatsheets/oci-artifacts/#verify-helm-charts). - Allow publishing a single YAML file to OCI with `flux push artifact --path=deploy/install.yaml`. - Detect changes to local files before pushing to OCI with @@ -511,7 +511,7 @@ good ways to do that: - Join the [planning discussions](https://github.com/fluxcd/flux2/discussions) - And if you are completely new to Flux, take a look at our [Get - Started guide](/docs/get-started/) + Started guide](/flux/get-started/) and give us feedback - Social media: Follow [Flux on Twitter](https://twitter.com/fluxcd), join the diff --git a/content/en/blog/2022-11-30-flux-is-a-cncf-graduated-project/index.md b/content/en/blog/2022-11-30-flux-is-a-cncf-graduated-project/index.md index b999e8027..4cf9a4e93 100644 --- a/content/en/blog/2022-11-30-flux-is-a-cncf-graduated-project/index.md +++ b/content/en/blog/2022-11-30-flux-is-a-cncf-graduated-project/index.md @@ -93,7 +93,7 @@ these days, a lot of this is based on Flux as a technology and the learnings we made until today. We are extremely pleased to have this [huge ecosystem](/ecosystem/) built on top of and around Flux, including recent [Flux -UIs](/ecosystem/#flux-uis)! +UIs](/ecosystem/#flux-uis--guis)! ## Next up: Flux going GA diff --git a/content/en/blog/2022-12-01-november-update/index.md b/content/en/blog/2022-12-01-november-update/index.md index 75ca5b2cc..f844c3bef 100644 --- a/content/en/blog/2022-12-01-november-update/index.md +++ b/content/en/blog/2022-12-01-november-update/index.md @@ -79,7 +79,7 @@ Check out these new pieces of documentation: - Guide: [AWS CodeCommit bootstrap](/flux/use-cases/aws-codecommit/) - Guide: [Azure DevOps - bootstrap](/flux/use-cases/azure/#flux-installation-for-azure-devops) + bootstrap](/flux/installation/bootstrap/azure-devops/) 💖 Big thanks to all the Flux contributors that helped us with this release! @@ -427,7 +427,7 @@ good ways to do that: - Talk to us in the #flux channel on [CNCF Slack](https://slack.cncf.io/) - Join the [planning discussions](https://github.com/fluxcd/flux2/discussions) - And if you are completely new to Flux, take a look at our [Get - Started guide](/docs/get-started/) and give us feedback + Started guide](/flux/get-started/) and give us feedback - Social media: Follow [Flux on Twitter](https://twitter.com/fluxcd), join the discussion in the [Flux LinkedIn group](https://www.linkedin.com/groups/8985374/). diff --git a/content/en/blog/2023-02-01-january-update.md b/content/en/blog/2023-02-01-january-update.md index d684d4987..4e49c3813 100644 --- a/content/en/blog/2023-02-01-january-update.md +++ b/content/en/blog/2023-02-01-january-update.md @@ -360,7 +360,7 @@ couple of small things we landed recently: come here. - Flagger docs were update to the latest. - Flux Bootstrap: cheatsheet for how to [Persistent storage for Flux - internal artifacts](/flux/cheatsheets/bootstrap/#persistent-storage-for-flux-internal-artifacts) + internal artifacts](/flux/installation/configuration/vertical-scaling/#persistent-storage-for-flux-internal-artifacts) - [Our FAQ](/flux/faq/) now has entries about how to safely rename a Flux Kustomization and how to set local overrides to a Helm chart. As it's one of the very common FAQs: We also mention the different @@ -440,7 +440,7 @@ good ways to do that: - Talk to us in the #flux channel on [CNCF Slack](https://slack.cncf.io/) - Join the [planning discussions](https://github.com/fluxcd/flux2/discussions) - And if you are completely new to Flux, take a look at our [Get - Started guide](/docs/get-started/) and give us feedback + Started guide](/flux/get-started/) and give us feedback - Social media: Follow [Flux on Twitter](https://twitter.com/fluxcd), join the discussion in the [Flux LinkedIn group](https://www.linkedin.com/groups/8985374/). diff --git a/content/en/blog/2023-03-01-february-update/index.md b/content/en/blog/2023-03-01-february-update/index.md index 2b7fa1bed..a5ccde3c4 100644 --- a/content/en/blog/2023-03-01-february-update/index.md +++ b/content/en/blog/2023-03-01-february-update/index.md @@ -99,7 +99,7 @@ Features and improvements include: Documentation - Security: [Software Bill of Materials](/flux/security/#software-bill-of-materials) -- Security: [SLSA Provenance Attestations](/flux/security/#slsa-provenance-attestations) +- Security: [SLSA Provenance Attestations](/flux/security/#slsa-provenance) - Security: [Scanning Flux images for CVEs](/flux/security/#scanning-for-cves) Big thanks to all the Flux contributors that helped us with this release! @@ -350,7 +350,7 @@ We are constantly improving our documentation and website - here are a couple of small things we landed recently: - Bootstrapping: here's how to [disable Kubernetes cluster role - aggregations](/flux/cheatsheets/bootstrap/#disable-kubernetes-cluster-role-aggregations) + aggregations](/flux/installation/configuration/multitenancy/#flux-cluster-role-aggregations) - Update [image-updates guide](/flux/guides/image-update/) to reflect the new API version and recent use of flags, extend examples. @@ -428,7 +428,7 @@ good ways to do that: - Talk to us in the #flux channel on [CNCF Slack](https://slack.cncf.io/) - Join the [planning discussions](https://github.com/fluxcd/flux2/discussions) - And if you are completely new to Flux, take a look at our [Get - Started guide](/docs/get-started/) and give us feedback + Started guide](/flux/get-started/) and give us feedback - Social media: Follow [Flux on Twitter](https://twitter.com/fluxcd), join the discussion in the [Flux LinkedIn group](https://www.linkedin.com/groups/8985374/). diff --git a/content/en/blog/2023-04-01-march-update/index.md b/content/en/blog/2023-04-01-march-update/index.md index 7ba94b31f..0d884964d 100644 --- a/content/en/blog/2023-04-01-march-update/index.md +++ b/content/en/blog/2023-04-01-march-update/index.md @@ -51,11 +51,11 @@ It's important to us to document all the new features, so here goes a list of ne articles and how-tos: - Cheatsheet: [Enable Helm drift - detection](/flux/cheatsheets/bootstrap/#enable-helm-drift-detection) + detection](/flux/installation/configuration/helm-drift-detection/) - Cheatsheet: [Enable Helm near OOM - detection](/flux/cheatsheets/bootstrap/#enable-helm-near-oom-detection) + detection](/flux/installation/configuration/helm-oom-detection/) - Cheatsheet: [Allow Helm DNS - lookups](/flux/cheatsheets/bootstrap/#allow-helm-dns-lookups) + lookups](/flux/installation/configuration/helm-dns-lookup/) - Controller: [New helm-controller feature gates and options](/flux/components/helm/options/#feature-gates) - Controller: [New kustomize-controller feature @@ -365,9 +365,9 @@ couple of small things we landed recently: 2023](/contributing/docs/google-season-of-docs-2023/). If you are interested in the initiative, go and check out the link. - We added information about to [enable Helm drift - detection](/flux/cheatsheets/bootstrap/#enable-helm-drift-detection) + detection](/flux/installation/configuration/helm-drift-detection/) and how to [allow Helm DNS - lookups](/flux/cheatsheets/bootstrap/#allow-helm-dns-lookups). + lookups](/flux/installation/configuration/helm-dns-lookup/). And on top of that countless fixes, small improvements and updates as always. Thanks a lot to these folks who contributed to docs and website: @@ -440,7 +440,7 @@ good ways to do that: - Talk to us in the #flux channel on [CNCF Slack](https://slack.cncf.io/) - Join the [planning discussions](https://github.com/fluxcd/flux2/discussions) - And if you are completely new to Flux, take a look at our [Get - Started guide](/docs/get-started/) and give us feedback + Started guide](/flux/get-started/) and give us feedback - Social media: Follow [Flux on Twitter](https://twitter.com/fluxcd), join the discussion in the [Flux LinkedIn group](https://www.linkedin.com/groups/8985374/). diff --git a/content/en/blog/2023-05-02-april-update/index.md b/content/en/blog/2023-05-02-april-update/index.md index f6ff80ac8..0c417a2c8 100644 --- a/content/en/blog/2023-05-02-april-update/index.md +++ b/content/en/blog/2023-05-02-april-update/index.md @@ -35,7 +35,7 @@ In addition, RC.1 comes with support for auth with Azure Workload Identity when pulling OCI artifacts from ACR and when decrypting secret with Azure Vault. Also, Bootstrap for GitLab was extended with support for generating [GitLab Deploy -Tokens](/flux/installation/#gitlab-and-gitlab-enterprise). +Tokens](/flux/installation/bootstrap/gitlab/). Big thanks to all the Flux contributors that helped us with this release! @@ -73,7 +73,7 @@ reconciliation of multiple resources using `.spec.resources.matchLabels`. The v1 API is backwards compatible with v1beta2, no fields were removed. To upgrade Flux from `v0.x` to `v2.0.0-rc-1` you can either rerun -[flux bootstrap](/flux/installation/#bootstrap-upgrade) +[flux bootstrap](/flux/installation/upgrade/#flux-controllers-upgrade) or use the [Flux GitHub Action](https://github.com/fluxcd/flux2/tree/main/action). To upgrade the APIs from v1beta2, after deploying the new CRDs and controllers, @@ -503,7 +503,7 @@ good ways to do that: - Talk to us in the #flux channel on [CNCF Slack](https://slack.cncf.io/) - Join the [planning discussions](https://github.com/fluxcd/flux2/discussions) - And if you are completely new to Flux, take a look at our [Get - Started guide](/docs/get-started/) and give us feedback + Started guide](/flux/get-started/) and give us feedback - Social media: Follow [Flux on Twitter](https://twitter.com/fluxcd), join the discussion in the [Flux LinkedIn group](https://www.linkedin.com/groups/8985374/). diff --git a/content/en/blog/2023-06-06-may-update/index.md b/content/en/blog/2023-06-06-may-update/index.md index bcddfeb77..24a3ec924 100644 --- a/content/en/blog/2023-06-06-may-update/index.md +++ b/content/en/blog/2023-06-06-may-update/index.md @@ -242,8 +242,8 @@ The next dates are going to be: - 2023-06-08 17:00 UTC, 19:00 CEST [The Flux Bug Scrub](/#calendar) - 2023-06-13 22:00 UTC, 00:00 CEST [The Flux Bug Scrub (AEST)](/#calendar) - 2023-06-14 12:00 UTC, 14:00 CEST [The Flux Bug Scrub](/#calendar) -- 2023-06-15 15:00 UTC, 17:00 CEST [CNCF Flux Project Meeting (late)](#calendar) -- 2023-06-21 12:00 UTC, 19:00 CEST [CNCF Flux Project Meeting (early)](#calendar) +- 2023-06-15 15:00 UTC, 17:00 CEST [CNCF Flux Project Meeting (late)](/#calendar) +- 2023-06-21 12:00 UTC, 19:00 CEST [CNCF Flux Project Meeting (early)](/#calendar) - 2023-06-22 17:00 UTC, 19:00 CEST [The Flux Bug Scrub](/#calendar) - 2023-06-27 22:00 UTC, 14:00 CEST [The Flux Bug Scrub (AEST): playing with ChatGPT!](/#calendar) - 2023-06-28 12:00 UTC, 00:00 CEST [The Flux Bug Scrub: playing with ChatGPT!](/#calendar) diff --git a/content/en/blog/2023-07-17-june-update/index.md b/content/en/blog/2023-07-17-june-update/index.md index 2737f9954..c024dac91 100644 --- a/content/en/blog/2023-07-17-june-update/index.md +++ b/content/en/blog/2023-07-17-june-update/index.md @@ -138,7 +138,7 @@ For more details on the release procedure, take a look at https://fluxcd.io/flux - Watch our [CNCF webinar on Flux 2.0](https://community.cncf.io/events/details/cncf-cncf-online-programs-presents-cncf-on-demand-webinar-flux-20-what-you-need-to-know/), which has an intro to GitOps for newcomers and Flux 2.0-specific updates for existing users. - Need extra support for Flux and Flagger? Check out the - [Flux support page](https://fluxcd.io/support/#my-employer-needs-additional-help) and this + [Flux support page](/support/#commercial-support) and this [August 2 webinar](https://go.weave.works/Webinar-FluxCD-Positioned-for-Growth_LP.html) on Flux 2.0-specific support. diff --git a/content/en/contributing/docs/proposing-changes.md b/content/en/contributing/docs/proposing-changes.md index 84a4d5dfe..10ae02f07 100644 --- a/content/en/contributing/docs/proposing-changes.md +++ b/content/en/contributing/docs/proposing-changes.md @@ -14,7 +14,7 @@ description: > To contribute new pages or improve existing pages, open a pull request (PR). -If your change is small, or you're unfamiliar with git, read [Changes using GitHub](#Changes-using-GitHub). +If your change is small, or you're unfamiliar with git, read [Changes using GitHub](#changes-using-github). ### Changes using GitHub @@ -47,7 +47,7 @@ If you are a maintainer of the repo, the edit page button will not let you work - Leave the **Allow edits from maintainers** checkbox selected. {{% alert title="" color="info" %}} - PR descriptions are a great way to help reviewers understand your change. For more information, see [Opening a PR](#open-a-pr). + PR descriptions are a great way to help reviewers understand your change. For more information, see [Opening a PR](#open-a-pull-request-from-your-fork-to-fluxcdwebsite). {{% /alert %}} 1. Select **Create pull request**. diff --git a/content/en/contributing/docs/style-guide.md b/content/en/contributing/docs/style-guide.md index 298a1e4bf..05ef34304 100644 --- a/content/en/contributing/docs/style-guide.md +++ b/content/en/contributing/docs/style-guide.md @@ -23,7 +23,7 @@ You may use the word "resource", "API", or "object" to clarify a Flux resource t Don't split an API object name into separate words. For example, use HelmRelease, not Helm Release. -The following examples focus on capitalization. For more information about formatting API object names, review the related guidance on [Code Style](#code-style-inline-code). +The following examples focus on capitalization. For more information about formatting API object names, review the related guidance on [Code Style](#use-code-style-for-inline-code-commands-and-api-objects). Do | Don't :--| :----- @@ -204,7 +204,7 @@ You can use a `{{}}` in a list: 1. A second item with an embedded note {{}} - Warning, Caution, and Note shortcodes, embedded in lists, need to be indented four spaces. See [Common Shortcode Issues](#common-shortcode-issues). + Warning, Caution, and Note shortcodes, embedded in lists, need to be indented four spaces. See [Common Shortcode Issues](https://kubernetes.io/docs/contribute/style/style-guide/#common-shortcode-issues). {{}} 1. A third item in a list @@ -219,7 +219,7 @@ The output is: 1. A second item with an embedded note {{< note >}} - Warning, Caution, and Note shortcodes, embedded in lists, need to be indented four spaces. See [Common Shortcode Issues](#common-shortcode-issues). + Warning, Caution, and Note shortcodes, embedded in lists, need to be indented four spaces. See [Common Shortcode Issues](https://kubernetes.io/docs/contribute/style/style-guide/#common-shortcode-issues). {{< /note >}} 1. A third item in a list @@ -286,6 +286,7 @@ Do | Don't Try to keep paragraphs under 6 sentences. | Indent the first paragraph with space characters. For example, ⋅⋅⋅Three spaces before a paragraph will indent it. Use three hyphens (`---`) to create a horizontal rule. Use horizontal rules for breaks in paragraph content. For example, a change of scene in a story, or a shift of topic within a section. | Use horizontal rules for decoration. +   ### Links Do | Don't diff --git a/content/en/contributing/flux-adopters.md b/content/en/contributing/flux-adopters.md index 77de3c20c..15bf620a1 100644 --- a/content/en/contributing/flux-adopters.md +++ b/content/en/contributing/flux-adopters.md @@ -32,7 +32,7 @@ To add your organisation follow these steps: ``` You can just add to the end of the file, we already sort alphabetically by name of organisation. -1. Save the file, then do `git add -A` and commit using `git commit -s -m "Add MY-ORG to adopters"` (commit signoff is required, see [DCO](https://fluxcd.io/contributing/#certificate-of-origin)). +1. Save the file, then do `git add -A` and commit using `git commit -s -m "Add MY-ORG to adopters"` (commit signoff is required, see [DCO](https://fluxcd.io/contributing/flux/#certificate-of-origin)). 1. Push the commit with `git push origin main`. 1. Open a Pull Request to [fluxcd/website](https://github.com/fluxcd/website) and a preview build will turn up. diff --git a/content/en/flagger/tutorials/osm-progressive-delivery.md b/content/en/flagger/tutorials/osm-progressive-delivery.md index 37ffba89d..05e61738a 100644 --- a/content/en/flagger/tutorials/osm-progressive-delivery.md +++ b/content/en/flagger/tutorials/osm-progressive-delivery.md @@ -20,7 +20,7 @@ OSM must have permissive traffic policy enabled and have an instance of Promethe --set=OpenServiceMesh.enablePermissiveTrafficPolicy=true ``` - If a managed instance of OSM is being used: - - [Bring your own instance](docs.openservicemesh.io/docs/guides/observability/metrics/#byo-prometheus) of Prometheus, + - [Bring your own instance](https://docs.openservicemesh.io/docs/guides/observability/metrics/#bring-your-own) of Prometheus, setting the namespace to match the managed OSM controller namespace - Enable permissive traffic policy after installation by updating the OSM MeshConfig resource: ```bash diff --git a/content/en/flagger/usage/how-it-works.md b/content/en/flagger/usage/how-it-works.md index d7c4e9272..95f857352 100644 --- a/content/en/flagger/usage/how-it-works.md +++ b/content/en/flagger/usage/how-it-works.md @@ -205,7 +205,7 @@ spec: Note that the `apex` annotations are added to both the generated Kubernetes Service and the generated service mesh/ingress object. This allows using external-dns with Istio `VirtualServices` -and `TraefikServices`. Beware of configuration conflicts [here](../faq.md#ExternalDNS). +and `TraefikServices`. Beware of configuration conflicts [here](../faq.md#externaldns). Besides port mapping and metadata, the service specification can contain URI match and rewrite rules, timeout and retry polices: diff --git a/content/en/flagger/usage/webhooks.md b/content/en/flagger/usage/webhooks.md index 5fb222116..711a42bfb 100644 --- a/content/en/flagger/usage/webhooks.md +++ b/content/en/flagger/usage/webhooks.md @@ -342,7 +342,7 @@ you'll have to create a dedicated service account and add the release namespace ``` If the test hangs or logs error messages hinting to insufficient permissions it can be related to RBAC, -check the [Troubleshooting](webhooks.md#Troubleshooting) section for an example configuration. +check the [Troubleshooting](webhooks.md#troubleshooting) section for an example configuration. As an alternative to Helm you can use the [Bash Automated Testing System](https://github.com/bats-core/bats-core) to run your tests. diff --git a/content/en/flux/cheatsheets/oci-artifacts.md b/content/en/flux/cheatsheets/oci-artifacts.md index 4f8cfcfd9..992212fbe 100644 --- a/content/en/flux/cheatsheets/oci-artifacts.md +++ b/content/en/flux/cheatsheets/oci-artifacts.md @@ -703,3 +703,32 @@ spec: Based on the above configuration, Flux will scan the container registry every five minutes, and when it finds a newer Helm chart version, it will update the `HelmRelease.spec.chart.spec.chart.version` and will push the change to Git. + +### Diagram: OCI artifacts reconciliation + +```mermaid +sequenceDiagram + actor me + participant git as OCI

repository + participant sc as Flux

source-controller + participant kc as Flux

kustomize-controller + participant kube as Kubernetes

api-server + participant nc as Flux

notification-controller + me->>git: 1. flux push + sc->>git: 2. pull artifact + sc-->>sc: 3. verify signatures + sc->>sc: 4. store artifact revision + sc->>kube: 5. update status for revision + sc-->>nc: 6. emit events + kube->>kc: 7. notify about new revision + kc->>sc: 8. fetch artifact for revision + kc->>kc: 9. extract k8s objects + kc-->>kc: 10. customize objects + kc->>kube: 11. validate objects + kc->>kube: 12. apply objects (ssa) + kc-->>kube: 13. delete objects + kc-->>kube: 14. wait for readiness + kc->>kube: 15. update status for revision + kc-->>nc: 16. emit events + nc-->>me: 17. send alerts for revision +``` diff --git a/content/en/flux/cheatsheets/troubleshooting.md b/content/en/flux/cheatsheets/troubleshooting.md index 95eda45a8..7da871c00 100644 --- a/content/en/flux/cheatsheets/troubleshooting.md +++ b/content/en/flux/cheatsheets/troubleshooting.md @@ -157,7 +157,7 @@ in [`helm/helm#8281`](https://github.com/helm/helm/issues/8281). If you are running into this, confirm first that your chart has all the required excludes in their respective [`.helmignore`](https://helm.sh/docs/chart_template_guide/helm_ignore_file/) and -[`.sourceignore`](/flux/components/source/api/#source.toolkit.fluxcd.io/v1.GitRepository) files. +[`.sourceignore`](/flux/components/source/api/v1/#source.toolkit.fluxcd.io/v1.GitRepository) files. ### How to debug "not ready" errors? diff --git a/content/en/flux/concepts.md b/content/en/flux/concepts.md index b2304c116..75df2adfc 100644 --- a/content/en/flux/concepts.md +++ b/content/en/flux/concepts.md @@ -70,7 +70,7 @@ are created for the Flux components, then the manifests are pushed to an existin The bootstrap is done using the `flux` CLI or using our [Terraform Provider](https://github.com/fluxcd/terraform-provider-flux). -For more information, take a look at [the bootstrap documentation](installation.md#bootstrap). +For more information, take a look at [the bootstrap documentation](/flux/installation/bootstrap/). ## Continuous Delivery diff --git a/content/en/flux/faq.md b/content/en/flux/faq.md index 73c930886..ad18a1a39 100644 --- a/content/en/flux/faq.md +++ b/content/en/flux/faq.md @@ -5,18 +5,26 @@ description: "Flux and the GitOps Toolkit frequently asked questions." weight: 144 --- -{{% alert title="Troubleshooting" %}} -Troubleshooting advice can be found on our [Troubleshooting Cheatsheet](/flux/cheatsheets/troubleshooting/). -{{% /alert %}} - ## General questions ### Does Flux have a UI / GUI? -The Flux project does not provide a UI of its own, but there are a variety of UIs for Flux in the [Flux Ecosystem](/ecosystem/#flux-uis--guis). +The Flux project does not provide a UI of its own, +but there are a variety of UIs for Flux in the [Flux Ecosystem](/ecosystem/#flux-uis--guis). {{< blocks/flux_ui_galleries >}} +### Where can I find information about Flux release cadence and supported versions? + +Flux is _at least_ released at the same rate as Kubernetes, following their cadence of +**three minor releases per year**. + +For Flux the CLI and its controllers, we support the last three minor releases. +Critical bug fixes, such as security fixes, may be back-ported to those three minor +versions as patch releases, depending on severity and feasibility. + +For more details please see the Flux [release documentation](/flux/releases/). + ## Kustomize questions ### Are there two Kustomization types? @@ -484,7 +492,8 @@ spec: and we want to override the chart version per cluster for example to gradually roll out a new version. We have couple options: -#### Using Kustomize patches: +#### Using Kustomize patches + ```yaml --- apiVersion: kustomize.toolkit.fluxcd.io/v1 @@ -514,6 +523,7 @@ spec: ``` #### Using Kustomize variable substitution + ```yaml apiVersion: helm.toolkit.fluxcd.io/v2beta1 kind: HelmRelease @@ -535,7 +545,9 @@ spec: retries: 3 ``` -To enable the replacement of the `PODINFO_CHART_VERSION` variable with a different version than the `6.2.0` default, specify `postBuild` in the `Kustomization`: +To enable the replacement of the `PODINFO_CHART_VERSION` variable with a different +version than the `6.2.0` default, specify `postBuild` in the `Kustomization`: + ```yaml apiVersion: kustomize.toolkit.fluxcd.io/v1 kind: Kustomization @@ -577,9 +589,3 @@ to help you migrate to Flux v2: - [How to manage multi-tenant clusters with Flux v2](https://github.com/fluxcd/flux2-multi-tenancy) - [Migrate from Helm Operator to Flux v2](/flux/migration/helm-operator-migration/) - [How to structure your HelmReleases](https://github.com/fluxcd/flux2-kustomize-helm-example) - -## Release questions - -### Where can I find information on how long versions are supported and how often to expect releases? - -Releases are as needed for now and a release page with the schedule will be created when Flux reaches general availability status ([Flux roadmap can be found here](/roadmap/)). We understand the importance of having a release schedule and are aware that such a schedule will support the users' ability to plan for an upgrade in advance. For now you can expect the current release cadence of at least once per month to continue. diff --git a/content/en/flux/flux-e2e.md b/content/en/flux/flux-e2e.md index f8d1f42c6..fc82e3831 100644 --- a/content/en/flux/flux-e2e.md +++ b/content/en/flux/flux-e2e.md @@ -75,7 +75,7 @@ Source controller. Kustomize controller delivers, or applies, resources into a c user defines how Kustomize controller delivers workloads from sources. The Kustomize controller is responsible for validating manifests against the Kubernetes API, and managing access to permissions in a way that is safe for -multi-tenant clusters through Kubernetes Service Account impersonation. The controller supports health assessment of deployed resources and dependency +multi-tenant clusters through Kubernetes Service Account impersonation. The controller supports health checking of deployed resources and dependency ordering, optionally enabled garbage collection or "pruning" of deleted resources from the cluster when they are removed from the source, and also notification of when cluster state changes – Kustomizations can also target and deliver resources onto a remote cluster, (which can, but does not necessarily also run its own local independent set of Flux controllers.) @@ -120,7 +120,7 @@ changes to a given Git repository. The behavior of the automation process is def That resource defines the way that automated commits are created and pushed. The `ImagePolicy` is another custom resource that determines what image tags go where. `ImagePolicy` can be defined to select the latest image from images within a SemVer range, or more flexible RegEx filters with alphabetical or -numerical sorting to select the "latest" image. Image tags can also be [filtered with FilterTags](/flux/components/image/imagepolicies/#filtertags) +numerical sorting to select the "latest" image. Image tags can also be [filtered with FilterTags](/flux/components/image/imagepolicies/#filter-tags) before they are considered as candidate images by the policy rule. The updates are governed by marking fields to be updated in each YAML file. For each field marked, the automation process checks the image policy named, and @@ -150,7 +150,7 @@ A brief outline of the life cycle of a change as it's processed through Flux, ce 13. [Using a GitRepository-backed or S3-backed HelmRelease][] is an alternative to use Helm without a `HelmRepository`. 14. [Channel-based Providers for Notifications][] re-publish `Events` from Flux resources at-large to a channel where users can see them. 15. [Git Commit Status Provider Notifications][] re-publish `Events` from the Kustomize Controller as commit checks. -16. [Waiting and Health Assessment for Flux Kustomization][]. +16. [Waiting and Health Checking for Flux Kustomization][]. ### Bootstrapping Flux @@ -170,6 +170,29 @@ Once the repository is created and Flux adds its components there as a commit, b cluster, waits for the components to become ready, then applies the Flux sync resources (`GitRepository` and `Kustomization`) and finally waits for a successful reconciliation before reporting back to the user that this was successful. +#### Diagram: Bootstrapping over SSH + + +```mermaid +sequenceDiagram + actor me as admin + participant cli as Flux

CLI + participant kube as Kubernetes

API server + participant flux as Flux

controllers + participant git as Git

repository + me->>cli: 1. flux bootstrap + cli-->>git: 2. push install config + cli->>kube: 3. install controllers + cli-->>git: 4. set deploy key + cli->>kube: 5. set private key + cli-->>git: 6. push sync config + cli->>kube: 7. apply sync config + git-->>flux: 8. pull config + flux->>kube: 9. reconcile + kube->>cli: 10. report status + cli->>me: 11. return status +``` + ### Generating a Flux resource After bootstrapping, the Flux CLI provides `create` generators to help users build more of Flux's Custom Resources that drive the operation of Flux. @@ -405,8 +428,8 @@ that refer to or use them. The Kustomize Controller communicates directly with the Kubernetes API using [server-side apply and update][] API operations instead of running the `kubectl apply` command as a separate forked process and passing it manifest data through a system pipe. Applying resource manifests directly to the Kubernetes API is both more efficient and provides more control over the process, enabling the Kustomize Controller to give real-time feedback on validation errors, -garbage-collection and resource health assessment. It also allows the Kubernetes API to track [field management][], so different management tools or -controllers can set field values within the same resource without interfering with each other. +garbage-collection and resource "health assessment" or health checking. It also allows the Kubernetes API to track [field management][], so different +management tools or controllers can set field values within the same resource without interfering with each other. The server-side apply operation is synchronous rather than asynchronous. If any resources fail to become ready before a specified timeout, the controller can abort the entire transaction. The timeout value is used in two separate contexts, such that either or both of them can take up to `spec.timeout` seconds @@ -546,13 +569,13 @@ commit hash to be present in the metadata. The provider will continuously receive events as they happen, and multiple events may be received for the same commit hash. The Git providers are configured to update the status only if it has changed. This avoids repeatedly spamming the commit status history. -### Waiting and Health Assessment for Flux Kustomization +### Waiting and Health Checking for Flux Kustomization Kustomize Controller can be configured with or without `spec.wait` which decides whether the `Kustomization` will be considered ready as soon as the resources are applied, or if the Kustomization will not be considered ready until the resources it created are all marked as ready. -The health checking feature is called [Health Assessment][] in the Flux Kustomization API. +The health checking feature is called [Health Checks][] in the Flux Kustomization API. [Bootstrapping Flux]: #bootstrapping-flux [Generating a Flux resource]: #generating-a-flux-resource @@ -570,7 +593,7 @@ The health checking feature is called [Health Assessment][] in the Flux Kustomiz [Using a GitRepository-backed or S3-backed HelmRelease]: #using-a-gitrepository-backed-or-s3-backed-helmrelease [Channel-based Providers for Notifications]: #channel-based-providers-for-notifications [Git Commit Status Provider Notifications]: #git-commit-status-provider-notifications -[Waiting and Health Assessment for Flux Kustomization]: #waiting-and-health-assessment-for-flux-kustomization +[Waiting and Health Checking for Flux Kustomization]: #waiting-and-health-checking-for-flux-kustomization [GitOps toolkit]: /flux/components/ [Security]: /flux/security/ @@ -603,4 +626,4 @@ The health checking feature is called [Health Assessment][] in the Flux Kustomiz [Alert API]: /flux/components/notification/alert/ [Event API]: /flux/components/notification/event/ [Setup Git Commit Status Notications]: /flux/guides/notifications/#git-commit-status -[Health Assessment]: /flux/components/kustomize/kustomization/#health-assessment +[Health Checks]: /flux/components/kustomize/kustomization/#health-checks diff --git a/content/en/flux/get-started.md b/content/en/flux/get-started.md index 988ab260d..8dd05986a 100644 --- a/content/en/flux/get-started.md +++ b/content/en/flux/get-started.md @@ -30,7 +30,7 @@ To install the CLI with Homebrew run: brew install fluxcd/tap/flux ``` -For other installation methods, see the [CLI install documentation](installation.md#install-the-flux-cli). +For other installation methods, see the [CLI install documentation](/flux/installation/#install-the-flux-cli). ## Export your credentials @@ -53,7 +53,7 @@ The output is similar to: ``` ► checking prerequisites -✔ kubernetes 1.27.3 >=1.24.0 +✔ kubernetes 1.28.0 >=1.25.0 ✔ prerequisites checks passed ``` @@ -262,14 +262,14 @@ To resume updates run the command `flux resume kustomization `. ## Customize podinfo deployment To customize a deployment from a repository you don't control, you can use Flux -[in-line patches](../components/kustomize/kustomization/#override-kustomize-config). The following example shows how to use in-line patches to change the podinfo deployment. +[in-line patches](/flux/components/kustomize/kustomization/#patches). The following example shows how to use in-line patches to change the podinfo deployment. 1. Add the following to the field `spec` of your `podinfo-kustomization.yaml` file: ```yaml clusters/my-cluster/podinfo-kustomization.yaml patches: - patch: |- - apiVersion: autoscaling/v2beta2 + apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: podinfo diff --git a/content/en/flux/guides/cron-job-image-auth.md b/content/en/flux/guides/cron-job-image-auth.md index 18058fb4e..a494160ac 100644 --- a/content/en/flux/guides/cron-job-image-auth.md +++ b/content/en/flux/guides/cron-job-image-auth.md @@ -301,7 +301,7 @@ Note that the resulting ImagePullSecret for Flux could also be specified by Pods #### Generating Tokens for Managed Identities [short-lived] -As a pre-requisite, your AKS cluster will need [AAD Pod Identity](../use-cases/azure.md#aad-pod-identity) installed. +As a pre-requisite, your AKS cluster will need [AAD Pod Identity](/flux/components/image/imagerepositories/#aad-pod-identity) installed. Once we have AAD Pod Identity installed, we can create a Deployment that frequently refreshes an image pull secret into our desired Namespace. diff --git a/content/en/flux/guides/helmreleases.md b/content/en/flux/guides/helmreleases.md index d338f50ce..da6c1f506 100644 --- a/content/en/flux/guides/helmreleases.md +++ b/content/en/flux/guides/helmreleases.md @@ -382,7 +382,7 @@ spec: {{% alert color="info" title="Garbage Collection" %}} Stale `ConfigMaps`, previously generated by Kustomize, will be removed from the cluster by kustomize-controller if -[pruning](../components/kustomize/kustomization/#garbage-collection) is enabled. +[pruning](/flux/components/kustomize/kustomization/#prune) is enabled. {{% /alert %}} ## Refer to values in Secret generated with Kustomize and SOPS diff --git a/content/en/flux/guides/image-update.md b/content/en/flux/guides/image-update.md index d5d31fbd0..00fee324b 100644 --- a/content/en/flux/guides/image-update.md +++ b/content/en/flux/guides/image-update.md @@ -65,7 +65,7 @@ If you bootstrapped Flux before, 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. Please note that you need to delete the `flux-system` secret before rerunning bootstrap -to [rotate the deploy key](../installation.md#deploy-key-rotation). +to [rotate the deploy key](/flux/installation/configuration/deploy-key-rotation/). {{% /alert %}} Install Flux with the image automation components: diff --git a/content/en/flux/guides/mozilla-sops.md b/content/en/flux/guides/mozilla-sops.md index edfb97b1b..5c3398f2d 100644 --- a/content/en/flux/guides/mozilla-sops.md +++ b/content/en/flux/guides/mozilla-sops.md @@ -13,8 +13,8 @@ Kubernetes secrets with OpenPGP, AWS KMS, GCP KMS and Azure Key Vault. To follow this guide you'll need a Kubernetes cluster with the GitOps toolkit controllers installed on it. -Please see the [get started guide](../get-started/index.md) -or the [installation guide](../installation/). +Please see the [get started guide](/flux/get-started/index.md) +or the [installation guide](/flux/installation/). Install [gnupg](https://www.gnupg.org/) and [SOPS](https://github.com/mozilla/sops): @@ -311,12 +311,12 @@ kubectl -n flux-system rollout restart deployment/kustomize-controller ``` {{% alert color="info" title="Bootstrap" %}} -Note that when using `flux bootstrap` you can [set the annotation](../cheatsheets/bootstrap.md#iam-roles-for-service-accounts) to take effect at install time. +Note that when using `flux bootstrap` you can [set the annotation](/flux/installation/configuration/workload-identity/#aws-iam-roles-for-service-accounts) to take effect at install time. {{% /alert %}} #### Azure -When using Azure Key Vault you need to authenticate kustomize-controller either with [aad-pod-identity](../use-cases/azure.md#aad-pod-identity) +When using Azure Key Vault you need to authenticate kustomize-controller either with [aad-pod-identity](/flux/components/kustomize/kustomization/#aad-pod-identity) or by passing [Service Principal credentials as environment variables](https://github.com/mozilla/sops#encrypting-using-azure-key-vault). Create the Azure Key-Vault: @@ -382,7 +382,7 @@ spec: selector: ${IDENTITY_NAME} ``` -[Customize your Flux Manifests](../installation/_index.md#customize-flux-manifests) so that kustomize-controller has the proper credentials. +[Customize your Flux Manifests](/flux/installation/configuration/workload-identity/#azure-workload-identity) so that kustomize-controller has the proper credentials. Patch the kustomize-controller Pod template so that the label matches the `AzureIdentity` selector. Additionally, the SOPS specific environment variable `AZURE_AUTH_METHOD=msi` to activate the proper auth method within kustomize-controller. @@ -473,7 +473,7 @@ gcloud iam service-accounts add-iam-policy-binding \ flux-gcp@total-mayhem-123456.iam.gserviceaccount.com ``` -3. [Customize your Flux Manifests](../installation/_index.md#customize-flux-manifests) and patch the kustomize-controller service account with the proper annotation so that Workload Identity knows the relationship between the gcp service account and the k8s service account. +3. [Customize your Flux Manifests](/flux/installation/) and patch the kustomize-controller service account with the proper annotation so that Workload Identity knows the relationship between the gcp service account and the k8s service account. ``` yaml ### add this patch to annotate service account if you are using Workload identity @@ -488,7 +488,7 @@ patchesStrategicMerge: iam.gke.io/gcp-service-account: @.iam.gserviceaccount.com ``` -If you didn't bootstap Flux, you can use this instead +If you didn't bootstrap Flux, you can use this instead ``` sh kubectl annotate serviceaccount kustomize-controller \ @@ -498,7 +498,7 @@ iam.gke.io/gcp-service-account=@.iam.gserviceacc ``` {{% alert color="info" title="Bootstrap" %}} -Note that when using `flux bootstrap` you can [set the annotation](../cheatsheets/bootstrap.md#iam-roles-for-service-accounts) to take effect at install time. +Note that when using `flux bootstrap` you can [set the annotation](/flux/installation/configuration/workload-identity/#gcp-workload-identity) to take effect at install time. {{% /alert %}} ## GitOps workflow diff --git a/content/en/flux/guides/notifications.md b/content/en/flux/guides/notifications.md index 4a6b9b03a..141fbda50 100644 --- a/content/en/flux/guides/notifications.md +++ b/content/en/flux/guides/notifications.md @@ -146,9 +146,9 @@ of the event. Therefore 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. +First follow the [get started guide](/flux/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 -the git provider used, refer to the [Provider CRD](../../components/notification/provider/#git-commit-status) +the git provider used, refer to the [Provider CRD](/flux/components/notification/provider/#git-commit-status-updates) for details about how to get the correct token. The guide will use GitHub, but the other providers will work in a very similar manner. The token will need to have write access to the repository it is going to update the commit status in. Store the generated token in a Secret with the following data format in the cluster. diff --git a/content/en/flux/guides/webhook-receivers.md b/content/en/flux/guides/webhook-receivers.md index e531f62d4..90b318789 100644 --- a/content/en/flux/guides/webhook-receivers.md +++ b/content/en/flux/guides/webhook-receivers.md @@ -15,10 +15,10 @@ every time a source changes. Using webhook receivers make To follow this guide you'll need a Kubernetes cluster with the GitOps toolkit controllers installed on it. -Please see the [get started guide](../get-started.md) -or the [installation guide](../installation.md). +Please see the [get started guide](/flux/get-started/) +or the [installation guide](/flux/installation/). -The [notification controller](../components/notification/_index.md) +The [notification controller](/flux/components/notification/) can handle events coming from external systems (GitHub, GitLab, Bitbucket, Harbor, Jenkins, etc) and notify the GitOps toolkit controllers about source changes. @@ -101,7 +101,7 @@ spec: {{% 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. +See the [GitRepository CRD docs](/flux/components/source/gitrepositories/) for more details. {{% /alert %}} ## Define a Git repository receiver @@ -139,7 +139,7 @@ spec: {{% alert color="info" title="Other receiver" %}} 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. +See the [Receiver CRD docs](/flux/components/notification/receiver/) for more details. {{% /alert %}} The notification controller generates a unique URL using the provided token and the receiver name/namespace. diff --git a/content/en/flux/migration/flux-v1-automation-migration.md b/content/en/flux/migration/flux-v1-automation-migration.md index 1101b16ca..43e4716e1 100644 --- a/content/en/flux/migration/flux-v1-automation-migration.md +++ b/content/en/flux/migration/flux-v1-automation-migration.md @@ -143,7 +143,7 @@ guide][flux-v1-migration]. When starting from scratch, you are likely to have used `flux bootstrap`. Rerun the command, and include the image automation controllers in your starting configuration with the flag -`--components-extra`, [as shown in the installation guide][flux-bootstrap]. +`--components-extra`, [as shown in the installation guide][additional components]. This will commit changes to your Git repository and sync them in the cluster. @@ -159,7 +159,7 @@ If you followed the [Flux v1 migration guide][flux-v1-migration], you will alrea Flux v2 controllers. The automation controllers are currently considered an optional extra to those, but are installed and run in much the same way. You may or may not have committed the Flux v2 configuration to your Git repository. If you did, go to the section [After committing Flux v2 -configuration to Git](#after-committing-flux-v2-configuration-to-git). +configuration to Git](#after-committing-a-flux-v2-configuration-to-git). If _not_, you will be installing directly to the cluster: @@ -546,7 +546,7 @@ timestamp part of the tag will be extracted and sorted numerically in ascending reference docs][imagepolicy-ref] for more examples. Once you have made sure you have image tags and an `ImagePolicy`, jump ahead to [Checking -the ImagePolicy works](#checking-that-the-image-policy-works). +the ImagePolicy works](#checking-that-the-imagepolicy-works). ### How to use SemVer image tags @@ -746,7 +746,7 @@ from ["Migrating each manifest to Flux v2"](#migrating-each-manifest-to-flux-v2) [image-update-tute-custom]: /flux/guides/image-update/#configure-image-update-for-custom-resources [flux-v1-migration]: /flux/migration/flux-v1-migration/ [install-cli]: /flux/get-started/#install-the-flux-cli -[flux-bootstrap]: /flux/installation/_index.md#bootstrap +[additional components]: /flux/installation/configuration/optional-components/ [github-pat]: https://docs.github.com/en/github/authenticating-to-github/creating-a-personal-access-token [image-update-tute-creds]: /flux/guides/image-update/#configure-image-scanning [image-update-tute-clouds]: /flux/guides/image-update/#imagerepository-cloud-providers-authentication diff --git a/content/en/flux/migration/helm-operator-migration.md b/content/en/flux/migration/helm-operator-migration.md index 569d5b3e1..1eceb5cce 100644 --- a/content/en/flux/migration/helm-operator-migration.md +++ b/content/en/flux/migration/helm-operator-migration.md @@ -22,13 +22,13 @@ In combination with the fact that [Helm v2 reaches end of life after November 13 When working with the Helm Operator, you had to mount various files to either make it recognize new (private) Helm repositories or make it gain access to Helm and/or Git repositories. While this approach was declarative, it did not provide a great user experience and was at times hard to set up. -By moving this configuration to [`HelmRepository`](../components/source/helmrepositories.md), [`GitRepository`](../components/source/gitrepositories.md), [`Bucket`](../components/source/buckets.md) and [`HelmChart`](../components/source/helmcharts.md) Custom Resources, they can now be declaratively described (including their credentials using references to `Secret` resources), and applied to the cluster. +By moving this configuration to [`HelmRepository`](/flux/components/source/helmrepositories/), [`GitRepository`](/flux/components/source/gitrepositories.md), [`Bucket`](/flux/components/source/buckets/) and [`HelmChart`](/flux/components/source/helmcharts/) Custom Resources, they can now be declaratively described (including their credentials using references to `Secret` resources), and applied to the cluster. -The reconciliation of these resources has been offloaded to a dedicated [Source Controller](../components/source/_index.md), specialized in the acquisition of artifacts from external sources. +The reconciliation of these resources has been offloaded to a dedicated [Source Controller](/flux/components/source/), specialized in the acquisition of artifacts from external sources. The result of this all is an easier and more flexible configuration, with much better observability. Failures are traceable to the level of the resource that lead to a failure, and are easier to resolve. As polling intervals can now be configured per resource, you can customize your repository and/or chart configuration to a much finer grain. -From a technical perspective, this also means less overhead, as the resources managed by the Source Controller can be shared between multiple `HelmRelease` resources, or even reused by other controllers like the [Kustomize Controller](../components/kustomize/_index.md). +From a technical perspective, this also means less overhead, as the resources managed by the Source Controller can be shared between multiple `HelmRelease` resources, or even reused by other controllers like the [Kustomize Controller](/flux/components/kustomize/). ### The `HelmRelease` Custom Resource group domain changed @@ -76,7 +76,7 @@ Getting similar behaviour is still possible [using a workaround that makes use o There was a long outstanding request for the Helm Operator to support merging single values at a given path. -With the Helm Controller this now possible by defining a [`targetPath` in the `ValuesReference`](../components/helm/api.md#helm.toolkit.fluxcd.io/v2beta1.ValuesReference), which 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). +With the Helm Controller this now possible by defining a [`targetPath` in the `ValuesReference`](/flux/components/helm/api.md#helm.toolkit.fluxcd.io/v2beta1.ValuesReference), which 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). ### Support added for depends-on relationships @@ -96,18 +96,18 @@ There is a new `spec.suspend` field, that if set to `true` causes the Helm Contr We have added support for making Helm releases to other clusters. If the `spec.kubeConfig` field in the `HelmRelease` is set, Helm actions will run against the default cluster specified in that KubeConfig instead of the local cluster that is responsible for the reconciliation of the `HelmRelease`. -The Helm storage is stored on the remote cluster in a namespace that equals to the namespace of the `HelmRelease`, or the configured `spec.storageNamespace`. The release itself is made in a namespace that equals to the namespace of the `HelmRelease`, or the configured `spec.targetNamespace`. The namespaces are expected to exist, and can for example be created using the [Kustomize Controller](/flux/components/kustomize/controller/) which has the same cross-cluster support. +The Helm storage is stored on the remote cluster in a namespace that equals to the namespace of the `HelmRelease`, or the configured `spec.storageNamespace`. The release itself is made in a namespace that equals to the namespace of the `HelmRelease`, or the configured `spec.targetNamespace`. The namespaces are expected to exist, and can for example be created using the [Kustomize Controller](/flux/components/kustomize/) which has the same cross-cluster support. Other references to Kubernetes resources in the `HelmRelease`, like `ValuesReference` resources, are expected to exist on the reconciling cluster. ### Added support for notifications and webhooks -Sending notifications and/or alerts to Slack, Microsoft Teams, Discord, or Rocker is now possible using the [Notification Controller](../components/notification/_index.md), [`Provider` Custom Resources](../components/notification/provider.md) and [`Alert` Custom Resources](../components/notification/alert.md). +Sending notifications and/or alerts to Slack, Microsoft Teams, Discord, or Rocker is now possible using the [Notification Controller](/flux/components/notification/), [`Provider` Custom Resources](/flux/components/notification/provider/) and [`Alert` Custom Resources](/flux/components/notification/alert/). -It does not stop there, using [`Receiver` Custom Resources](../components/notification/receiver.md) you can trigger **push based** reconciliations from Harbor, GitHub, GitLab, BitBucket or your CI system by making use of the webhook endpoint the resource creates. +It does not stop there, using [`Receiver` Custom Resources](/flux/components/notification/receiver/) you can trigger **push based** reconciliations from Harbor, GitHub, GitLab, BitBucket or your CI system by making use of the webhook endpoint the resource creates. ### Introduction of the `flux` CLI to create and/or generate Custom Resources -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: +With the new [`flux` CLI](/flux/cmd/flux/) 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: ```sh $ flux create source helm podinfo \ @@ -150,7 +150,7 @@ spec: ## API spec changes -The following is an overview of changes to the API spec, including behavioral changes compared to how the Helm Operator performs actions. For a full overview of the new API spec, consult the [API spec documentation](../components/helm/helmreleases.md#specification). +The following is an overview of changes to the API spec, including behavioral changes compared to how the Helm Operator performs actions. For a full overview of the new API spec, consult the [API spec documentation](/flux/components/helm/helmreleases/#specification). ### Defining the Helm chart @@ -175,7 +175,7 @@ spec: version: 1.2.3 ``` -With the Helm Controller, you now create a `HelmRepository` resource in addition to the `HelmRelease` you would normally create (for all available fields, consult the [Source API reference](../components/source/api.md#source.toolkit.fluxcd.io/v1beta2.HelmRepository)): +With the Helm Controller, you now create a `HelmRepository` resource in addition to the `HelmRelease` you would normally create (for all available fields, consult the [Source API reference](/flux/components/source/api/v1beta2/#source.toolkit.fluxcd.io/v1beta2.HelmRepository)): ```yaml --- @@ -220,7 +220,7 @@ spec: name: my-repository-creds ``` -In the `HelmRelease`, you then use a reference to the `HelmRepository` resource in the `spec.chart.spec` (for all available fields, consult the [Helm API reference](../components/helm/api.md#helm.toolkit.fluxcd.io/v2beta1.HelmChartTemplate)): +In the `HelmRelease`, you then use a reference to the `HelmRepository` resource in the `spec.chart.spec` (for all available fields, consult the [Helm API reference](/flux/components/helm/api/#helm.toolkit.fluxcd.io/v2beta1.HelmChartTemplate)): ```yaml --- @@ -271,7 +271,7 @@ spec: path: ./charts/my-chart ``` -With the Helm Controller, you create a `GitRepository` resource in addition to the `HelmRelease` you would normally create (for all available fields, consult the [Source API reference](../components/source/api.md#source.toolkit.fluxcd.io/v1.GitRepository): +With the Helm Controller, you create a `GitRepository` resource in addition to the `HelmRelease` you would normally create (for all available fields, consult the [Source API reference](/flux/components/source/api/v1/#source.toolkit.fluxcd.io/v1.GitRepository): ```yaml --- @@ -322,7 +322,7 @@ spec: name: my-repository-creds ``` -In the `HelmRelease`, you then use a reference to the `GitRepository` resource in the `spec.chart.spec` (for all available fields, consult the [Helm API reference](../components/helm/api.md#helm.toolkit.fluxcd.io/v2beta1.HelmChartTemplate)): +In the `HelmRelease`, you then use a reference to the `GitRepository` resource in the `spec.chart.spec` (for all available fields, consult the [Helm API reference](/flux/components/helm/api/#helm.toolkit.fluxcd.io/v2beta1.HelmChartTemplate)): ```yaml --- @@ -404,7 +404,7 @@ spec: optional: true ``` -In the new API spec the individual `configMapKeyRef` and `secretKeyRef` objects are bundled into a single [`ValuesReference`](../components/helm/api.md#helm.toolkit.fluxcd.io/v2beta1.ValuesReference) which [does no longer allow refering to resources in other namespaces](#values-from-external-source-references-urls-are-no-longer-supported): +In the new API spec the individual `configMapKeyRef` and `secretKeyRef` objects are bundled into a single [`ValuesReference`](/flux/components/helm/api/#helm.toolkit.fluxcd.io/v2beta1.ValuesReference) which [does no longer allow refering to resources in other namespaces](#values-from-external-source-references-urls-are-no-longer-supported): ```yaml --- @@ -588,7 +588,7 @@ spec: With the Helm Operator the release options used to be configured in the `spec` of the `HelmRelease` and applied to both Helm install and upgrade actions. -This has changed for the Helm Controller, where some defaults can be defined in the [`spec`](../components/helm/api.md#helm.toolkit.fluxcd.io/v2beta1.HelmReleaseSpec), but specific action configurations and overwrites for the defaults can be defined in the [`spec.install`](../components/helm/api.md#helm.toolkit.fluxcd.io/v2beta1.Install), [`spec.upgrade`](../components/helm/api.md#helm.toolkit.fluxcd.io/v2beta1.Upgrade) and [`spec.test`](../components/helm/api.md#helm.toolkit.fluxcd.io/v2beta1.Test) sections of the `HelmRelease`. +This has changed for the Helm Controller, where some defaults can be defined in the [`spec`](/flux/components/helm/api/#helm.toolkit.fluxcd.io/v2beta1.HelmReleaseSpec), but specific action configurations and overwrites for the defaults can be defined in the [`spec.install`](/flux/components/helm/api/#helm.toolkit.fluxcd.io/v2beta1.Install), [`spec.upgrade`](/flux/components/helm/api/#helm.toolkit.fluxcd.io/v2beta1.Upgrade) and [`spec.test`](/flux/components/helm/api/#helm.toolkit.fluxcd.io/v2beta1.Test) sections of the `HelmRelease`. ### Defining a rollback / uninstall configuration @@ -613,11 +613,11 @@ spec: timeout: 300 ``` -The Helm Controller offers an extensive set of configuration options to remediate when a Helm release fails, using [`spec.install.remediation`](../components/helm/api.md#helm.toolkit.fluxcd.io/v2beta1.InstallRemediation), [`spec.upgrade.remediation`](../components/helm/api.md#helm.toolkit.fluxcd.io/v2beta1.UpgradeRemediation), [`spec.rollback`](../components/helm/api.md#helm.toolkit.fluxcd.io/v2beta1.Rollback) and [`spec.uninstall`](../components/helm/api.md#helm.toolkit.fluxcd.io/v2beta1.Uninstall). Some of the new features include the option to remediate with an uninstall after an upgrade failure, and the option to keep a failed release for debugging purposes when it has run out of retries. +The Helm Controller offers an extensive set of configuration options to remediate when a Helm release fails, using [`spec.install.remediation`](/flux/components/helm/api/#helm.toolkit.fluxcd.io/v2beta1.InstallRemediation), [`spec.upgrade.remediation`](/flux/components/helm/api/#helm.toolkit.fluxcd.io/v2beta1.UpgradeRemediation), [`spec.rollback`](/flux/components/helm/api/#helm.toolkit.fluxcd.io/v2beta1.Rollback) and [`spec.uninstall`](/flux/components/helm/api/#helm.toolkit.fluxcd.io/v2beta1.Uninstall). Some of the new features include the option to remediate with an uninstall after an upgrade failure, and the option to keep a failed release for debugging purposes when it has run out of retries. #### Automated uninstalls -The configuration below mimics the uninstall behavior of the Helm Operator (for all available fields, consult the [`InstallRemediation`](../components/helm/api.md#helm.toolkit.fluxcd.io/v2beta1.InstallRemediation) and [`Uninstall`](../components/helm/api.md#helm.toolkit.fluxcd.io/v2beta1.Uninstall) API references): +The configuration below mimics the uninstall behavior of the Helm Operator (for all available fields, consult the [`InstallRemediation`](/flux/components/helm/api/#helm.toolkit.fluxcd.io/v2beta1.InstallRemediation) and [`Uninstall`](/flux/components/helm/api/#helm.toolkit.fluxcd.io/v2beta1.Uninstall) API references): ```yaml apiVersion: helm.toolkit.fluxcd.io/v2beta1 @@ -643,7 +643,7 @@ spec: #### Automated rollbacks -The configuration below shows an automated rollback configuration that equals [the configuration for the Helm Operator showed above](#defining-a-rollback-uninstall-configuration) (for all available fields, consult the [`UpgradeRemediation`](../components/helm/api.md#helm.toolkit.fluxcd.io/v2beta1.UpgradeRemediation) and [`Rollback`](../components/helm/api.md#helm.toolkit.fluxcd.io/v2beta1.Rollback) API references): +The configuration below shows an automated rollback configuration that equals [the configuration for the Helm Operator showed above](#defining-a-rollback--uninstall-configuration) (for all available fields, consult the [`UpgradeRemediation`](/flux/components/helm/api/#helm.toolkit.fluxcd.io/v2beta1.UpgradeRemediation) and [`Rollback`](/flux/components/helm/api/#helm.toolkit.fluxcd.io/v2beta1.Rollback) API references): ```yaml apiVersion: helm.toolkit.fluxcd.io/v2beta1 @@ -682,7 +682,7 @@ Here are some things to know: * If both the Helm Controller and Helm Operator are running, and both a new and old custom resources define a release, they will fight over the release. * The Helm Controller will always perform an upgrade the first time it encounters a new `HelmRelease` for an existing release; this is [due to the changes to release mechanics and bookkeeping](#helm-storage-drift-detection-no-longer-relies-on-dry-runs). -The safest way to upgrade is to avoid deletions and fights by stopping the Helm Operator. Once the operator is not running, it is safe to deploy the Helm Controller (e.g., by following the [Get Started guide](../get-started/index.md), [utilizing `flux install`](../cmd/flux_install.md), or using the manifests from the [release page](https://github.com/fluxcd/helm-controller/releases)), and start replacing the old resources with new resources. You can keep the old resources around during this process, since the Helm Controller will ignore them. +The safest way to upgrade is to avoid deletions and fights by stopping the Helm Operator. Once the operator is not running, it is safe to deploy the Helm Controller (e.g., by following the [Get Started guide](/flux/get-started/), [utilizing `flux install`](../cmd/flux_install.md), or using the manifests from the [release page](https://github.com/fluxcd/helm-controller/releases)), and start replacing the old resources with new resources. You can keep the old resources around during this process, since the Helm Controller will ignore them. ### Steps @@ -845,7 +845,7 @@ Yes, image updates are supported for `HelmRelease` as well as any other Kubernet If you are currently a Flux v1 user, you can commit the `HelmRelease` resources to Git, and Flux will automatically apply them to the cluster like any other resource. -If you are not a Flux v1 user or want to fully migrate to Flux v2, the [Kustomize Controller](/flux/components/kustomize/controller/) will serve your needs. +If you are not a Flux v1 user or want to fully migrate to Flux v2, the [Kustomize Controller](/flux/components/kustomize/) will serve your needs. ### I am still running Helm v2, what is the right upgrade path for me? @@ -860,7 +860,7 @@ Probably, but with some side notes: ### Can I use Helm Controller standalone? -Helm Controller depends on [Source Controller](../components/source/_index.md), you can install both controllers +Helm Controller depends on [Source Controller](/flux/components/source/), you can install both controllers and manager Helm releases in a declarative way without GitOps. For more details please see this [answer]({{< relref "../faq.md#can-i-use-flux-helmreleases-without-gitops" >}}). diff --git a/content/en/flux/security/_index.md b/content/en/flux/security/_index.md index 738917b6d..86f2b036c 100644 --- a/content/en/flux/security/_index.md +++ b/content/en/flux/security/_index.md @@ -212,6 +212,6 @@ as it can be. For more information, checkout the [Flux Security Best Practices]( [^1]: However, by design cross-namespace references are an exception to RBAC. Platform admins have to option to turnoff cross-namespace references as described in the -[installation documentation](../installation/_index.md#multi-tenancy-lockdown). +[installation documentation](/flux/installation/configuration/multitenancy/). [^2]: Platform admins have to option to enforce impersonation as described in the -[installation documentation](../installation/_index.md#multi-tenancy-lockdown). +[installation documentation](/flux/installation/configuration/multitenancy/). diff --git a/content/en/flux/security/best-practices.md b/content/en/flux/security/best-practices.md index 8c6997461..31ccbc2c7 100644 --- a/content/en/flux/security/best-practices.md +++ b/content/en/flux/security/best-practices.md @@ -268,7 +268,7 @@ The recommendations below are based on Flux's latest version. Audit Procedure - Check whether you adhere to [Kubernetes Network Isolation Guidelines](https://kubernetes.io/docs/concepts/security/multi-tenancy/#network-isolation) - - Confirm that the [Network Policy](/flux-e2e/#fluxs-default-configuration-for-networkpolicy) objects created by Flux are being enforced by the CNI. Alternatively, run a tool such as [Cyclonus](https://github.com/mattfenwick/cyclonus) or [Sonobuoy](https://github.com/vmware-tanzu/sonobuoy) to validate NetworkPolicy enforcement by the CNI plugin on your cluster. + - Confirm that the [Network Policy](/flux/flux-e2e/#fluxs-default-configuration-for-networkpolicy) objects created by Flux are being enforced by the CNI. Alternatively, run a tool such as [Cyclonus](https://github.com/mattfenwick/cyclonus) or [Sonobuoy](https://github.com/vmware-tanzu/sonobuoy) to validate NetworkPolicy enforcement by the CNI plugin on your cluster. ## Additional Best Practices for Tenant Dedicated Cluster Multi-tenancy diff --git a/content/en/flux/security/contextual-authorization.md b/content/en/flux/security/contextual-authorization.md index 03d06f303..6d3cc2945 100644 --- a/content/en/flux/security/contextual-authorization.md +++ b/content/en/flux/security/contextual-authorization.md @@ -52,18 +52,18 @@ Support for context-based authorization should only increase over time. For more information, please visit the tracking issue: https://github.com/fluxcd/flux2/issues/3003. -[AWS Buckets]: ../components/source/buckets/#aws -[Azure Buckets]: ../components/source/buckets/#azure -[GCP Buckets]: ../components/source/buckets/#gcp -[AWS OCI Repository]: ../components/source/ocirepositories/#aws -[Azure OCI Repository]: ../components/source/ocirepositories/#azure -[GCP OCI Repository]: ../components/source/ocirepositories/#gcp -[AWS Helm Repository]: ../components/source/helmrepositories/#aws -[Azure Helm Repository]: ../components/source/helmrepositories/#azure -[GCP Helm Repository]: ../components/source/helmrepositories/#gcp -[AWS Container Registry]: ../guides/image-update/#using-native-aws-ecr-auto-login -[Azure Container Registry]: ../guides/image-update/#using-native-azure-acr-auto-login -[GCP Container Registry]: ../guides/image-update/#using-native-gcp-gcr-auto-login -[AWS KMS]: ../guides/mozilla-sops/#aws -[Azure KMS]: ../guides/mozilla-sops/#azure -[GCP KMS]: ../guides/mozilla-sops/#google-cloud +[AWS Buckets]: /flux/components/source/buckets/#aws +[Azure Buckets]: /flux/components/source/buckets/#azure +[GCP Buckets]: /flux/components/source/buckets/#gcp +[AWS OCI Repository]: /flux/components/source/ocirepositories/#aws +[Azure OCI Repository]: /flux/components/source/ocirepositories/#azure +[GCP OCI Repository]: /flux/components/source/ocirepositories/#gcp +[AWS Helm Repository]: /flux/components/source/helmrepositories/#aws +[Azure Helm Repository]: /flux/components/source/helmrepositories/#azure +[GCP Helm Repository]: /flux/components/source/helmrepositories/#gcp +[AWS Container Registry]: /flux/components/image/imagerepositories/#aws +[Azure Container Registry]: /flux/components/image/imagerepositories/#azure +[GCP Container Registry]: /flux/components/image/imagerepositories/#gcp +[AWS KMS]: /flux/guides/mozilla-sops/#aws +[Azure KMS]: /flux/guides/mozilla-sops/#azure +[GCP KMS]: /flux/guides/mozilla-sops/#google-cloud diff --git a/content/en/flux/security/secrets-management.md b/content/en/flux/security/secrets-management.md index 98f10a4f2..da7ac840f 100644 --- a/content/en/flux/security/secrets-management.md +++ b/content/en/flux/security/secrets-management.md @@ -92,7 +92,7 @@ could impact your solution. Flux supports the two main names in Encrypted Secrets and has specific how-to guides for them: - [Mozilla SOPS Guide](/flux/guides/mozilla-sops/) -- [Secrets decryption](/flux/components/kustomize/kustomization/#secrets-decryption) +- [Secrets decryption](/flux/components/kustomize/kustomization/#decryption) #### Secrets Synchronized by Operators diff --git a/content/en/flux/use-cases/gh-actions-helm-promotion.md b/content/en/flux/use-cases/gh-actions-helm-promotion.md index 3386dbee3..a6599b244 100644 --- a/content/en/flux/use-cases/gh-actions-helm-promotion.md +++ b/content/en/flux/use-cases/gh-actions-helm-promotion.md @@ -217,7 +217,7 @@ to the repositories used with `flux bootstrap github`. ## Relevant documentation -- [Guides > Manage Helm Releases](../guides/helmreleases.md) -- [Toolkit Components > Helm Repository API](../components/source/helmrepositories.md) -- [Toolkit Components > Helm Release API](../components/helm/helmreleases.md) -- [Toolkit Components > Notification API > GitHub Dispatch](../components/notification/provider.md#github-repository-dispatch) +- [Guides > Manage Helm Releases](/flux/guides/helmreleases.md) +- [Toolkit Components > Helm Repository API](/flux/components/source/helmrepositories.md) +- [Toolkit Components > Helm Release API](/flux/components/helm/helmreleases.md) +- [Toolkit Components > Notification API > GitHub Dispatch](/flux/components/notification/provider/#github-dispatch) diff --git a/content/en/flux/use-cases/gh-actions-manifest-generation.md b/content/en/flux/use-cases/gh-actions-manifest-generation.md index a88fd8ac7..ca7e24df0 100644 --- a/content/en/flux/use-cases/gh-actions-manifest-generation.md +++ b/content/en/flux/use-cases/gh-actions-manifest-generation.md @@ -1254,7 +1254,7 @@ If you are on GitHub, and are struggling to get started using GitHub Actions, or [image update guide]: /flux/guides/image-update/ [any old app]: https://github.com/kingdonb/any_old_app [Flux bootstrap guide]: /flux/get-started/ -[String Substitution with sed -i]: #string-substitution-with-sed-i +[String Substitution with sed -i]: #string-substitution-with-sed--i [Docker Build and Tag with Version]: #docker-build-and-tag-with-version [Jsonnet for YAML Document Rehydration]: #jsonnet-for-yaml-document-rehydration [Commit Across Repositories Workflow]: #commit-across-repositories-workflow @@ -1291,7 +1291,7 @@ If you are on GitHub, and are struggling to get started using GitHub Actions, or [anguslees example jsonnet]: https://github.com/anguslees/kustomize-libsonnet/blob/master/example.jsonnet [Kubernetes docs on Using Service Accounts]: https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#use-multiple-service-accounts [sops/issues/315]: https://github.com/mozilla/sops/issues/315 -[using various cloud providers]: /guides/mozilla-sops/#using-various-cloud-providers +[using various cloud providers]: /flux/guides/mozilla-sops/#encrypting-secrets-using-various-cloud-providers [Decrypt SOPS Secrets]: https://github.com/marketplace/actions/decrypt-sops-secrets [Sops Binary Installer]: https://github.com/marketplace/actions/sops-binary-installer [04-update-fleet-infra.yaml]: https://github.com/kingdonb/any_old_app/blob/main/.github/workflows/04-update-fleet-infra.yaml diff --git a/content/en/flux/use-cases/helm.md b/content/en/flux/use-cases/helm.md index 1b7b318ac..f407d0751 100644 --- a/content/en/flux/use-cases/helm.md +++ b/content/en/flux/use-cases/helm.md @@ -156,9 +156,9 @@ to a chart. The Flux Kustomize Controller method allows you to accomplish this on any chart without additional templated annotations. You may also use Kustomize Controller -built-in [Mozilla SOPS integration](../components/kustomize/kustomization.md#secrets-decryption) +built-in [Mozilla SOPS integration](/flux/components/kustomize/kustomization/#decryption) to securely manage your encrypted secrets stored in git. -See the [Flux SOPS guide](../guides/mozilla-sops.md) for step-by-step instructions through various use cases. +See the [Flux SOPS guide](/flux/guides/mozilla-sops/) for step-by-step instructions through various use cases. ## Automatic Release Upgrades diff --git a/content/en/flux/use-cases/karmada.md b/content/en/flux/use-cases/karmada.md index 3ac97d164..509f05649 100644 --- a/content/en/flux/use-cases/karmada.md +++ b/content/en/flux/use-cases/karmada.md @@ -62,7 +62,7 @@ flux install --kubeconfig ~/.kube/members.config --context member1 flux install --kubeconfig ~/.kube/members.config --context member2 ``` -Please refer to the documentations [here](../installation.md) for more ways to set up Flux in details. +Please refer to the documentations [here](/flux/installation/) for more ways to set up Flux in details. {{% alert color="info" title="Tip" %}} If you want to manage Helm releases across your fleet of clusters, Flux must be installed on each cluster. diff --git a/content/en/roadmap.md b/content/en/roadmap.md index ee01a842b..3b2256655 100644 --- a/content/en/roadmap.md +++ b/content/en/roadmap.md @@ -20,7 +20,7 @@ from beta to stable. ## Milestones The GA roadmap has been split into separate milestones. -The Flux team's current focus is to finalise the tasks from the [Flux GitOps GA](#flux-gitops-ga-q1-2023) milestone. +The Flux team's current focus is to finalise the tasks from the [Flux GitOps GA](#flux-gitops-ga-completed-in-july-2023) milestone. We estimate that the Flux features part of this milestone will become generally available in the first quarter of 2023. ### Flux GitOps GA (Completed in July 2023) @@ -49,7 +49,7 @@ The completion of this milestone is marked by the [v2.0.0](https://github.com/fl - [x] Multi-tenancy lockdown - [x] [Allow setting a default service account for impersonation](https://github.com/fluxcd/flux2/issues/2340) - [x] [Allow disabling cross-namespace references](https://github.com/fluxcd/flux2/issues/2337) - - [x] [Document multi-tenancy lockdown configuration](flux/installation.md#multi-tenancy-lockdown) + - [x] [Document multi-tenancy lockdown configuration](/flux/installation/configuration/multitenancy/) - [x] Conformance testing - [x] End-to-end testing for bootstrap on AMD64 and ARM64 clusters From b73421b02899f1c3756ce13ff2cf7d2a1be9be2a Mon Sep 17 00:00:00 2001 From: Kingdon Barrett Date: Fri, 18 Aug 2023 08:15:01 -0400 Subject: [PATCH 7/7] Externalize tf-controller notes The bootstrap cheatsheet doc is going away Signed-off-by: Kingdon Barrett --- content/en/blog/2022-09-05-august-update/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/blog/2022-09-05-august-update/index.md b/content/en/blog/2022-09-05-august-update/index.md index 7afad4912..5b0bd72ea 100644 --- a/content/en/blog/2022-09-05-august-update/index.md +++ b/content/en/blog/2022-09-05-august-update/index.md @@ -256,7 +256,7 @@ couple of small things we landed recently: - Bootstrap: [Git repository access via SOCKS5 ssh proxy](/flux/installation/configuration/proxy-setting/#git-repository-access-via-socks5-ssh-proxy) - Bootstrap: [Enable notifications for third party - controllers](/flux/cheatsheets/bootstrap/#enable-notifications-for-third-party-controllers) + controllers](https://weaveworks.github.io/tf-controller/how_to/flux_receiver_and_alert/#enable-notifications-for-third-party-controllers) - [Flux's Work Well With section](/flux/#flux-works-well-with): find out how to make Flux work with your favourite other OSS software - Lots of new videos from GitOpsCon / KubeCon on [our resources