initial commit

README.md

+# GitOps Getting Started
+
+This repo acts as an example to manage application deployment and configuration
+using GitOps and the tool Flux.
+
+The sample application has two parts:
+* a frontend based on wordpress
+* a backend MySQL database 
+
+It should be enough to give you hints on how to manage your own deployments in
+the same way.
+
+## Pre-Requisites
+
+First get a Kubernetes cluster up and running, [check here](https://clouddocs.web.cern.ch/containers/quickstart.html).
+
+Make sure you also [deploy Helm](https://clouddocs.web.cern.ch/containers/tutorials/helm.html).
+
+## Flux Overview
+
+Flux has two main components:
+* *Flux* itself, which is responsible of syncing with the remote git
+  repository. We rely on the Helm integration, so Flux will instantiate in the
+  cluster the *HelmRelease* custom resources defined in the *releases*
+  directory
+* *Helm Operator*, which watches for the *HelmRelease* custom resources and
+  applies them in the cluster - basically by doing helm install/upgrade/...
+
+Check the helm releases defined in this repo under the *releases* directory to
+see what goes in these resources.
+
+## Structure and Releases
+
+The structure of this repo is as follows:
+* **chart**: the umbrella chart, with defaults and any extra setup required
+* **releases**: the different deployments of the application (staging, production),
+each with overrides or complements of the default values. These are defined as
+Flux HelmRelease resources
+
+## Secrets
+
+Secrets are stored along the release values, but encrypted using the [helm
+secrets](https://gitlab.cern.ch/helm/plugins/barbican) plugin - this makes them
+also version controlled.
+
+To achieve this it means that for the moment they are not managed by Flux, a
+better integration will appear later.
+
+You need to do the following once before installing flux:
+```bash
+kubectl -n hub create -f releases/prod/hub-secrets.yaml
+kubectl -n hub-stg create -f releases/stg/hub-secrets.yaml
+```
+
+and update them manually everytime when you update secrets.
+
+## Deployment
+
+Next deploy the secrets - see the *secrets* section above.
+
+Finally deploy Flux and point it to this repository (the git.url value below):
+```bash
+$ cat flux-values.yaml
+git:
+  path: releases,namespaces
+  pollInterval: 1m
+  readonly: true
+rbac:
+  create: true
+
+$ helm install fluxcd/flux --namespace flux --name flux --values flux-values.yaml \
+    --set git.url=https://gitlab.cern.ch/helm/releases/gitops-getting-started
+
+$ cat helm-operator-values.yaml
+createCRD: true
+chartsSyncInterval: 1m
+configureRepositories:
+  enable: true
+  repositories:
+  - name: cern 
+    url: https://registry.cern.ch/cern/charts
+rbac:
+  create: true
+git:
+  pollInterval: 1m
+
+$ helm install fluxcd/helm-operator --namespace flux --name helm-operator --values helm-operator-values.yaml
+```
+
+Check the logs to see the multiple releases are being picked up:
+```
+$ kubectl -n flux logs -f deployment.apps/flux-helm-operator
+```
+
+All going well you should see them in helm:
+```bash
+$ helm ls
+NAME    REVISION    UPDATED                     STATUS      CHART       APP VERSION NAMESPACE
+```
+
+## FAQ
+
+#### What's the best practice to update the release values?
+
+It depends which releases you want to affect.
+
+* If you want the change to impact all releases (prod, staging, ...), change
+  the values in the chart/<application name>/values.yaml file. These are the
+  *defaults* for all releases
+* If you want the change to impact only one release, change the corresponding
+  yaml file in the releases/<release-to-be-changed> directory
+
+Flux will detect the change and apply it locally on the cluster(s) where it is
+deployed.
+
+#### How do i force Flux to sync with the remote repository?
+
+Flux will sync periodically, following the value in the *git.pollInterval*
+parameter. If you've set this value conservatively and want to get Flux to sync
+right now, try:
+```bash
+$ export FLUX_FORWARD_NAMESPACE=flux
+$ fluxctl sync
+```
+
+#### How do i add custom manifests not part of any existing Helm chart?
+
+You can add these additional manifests in the same way you would do for
+a normal chart. Put them under *charts/<application-name>/templates* and they
+will be picked up during the installation (and updates). You can use values as
+usual as well.
+
+#### How do i restrict the deployment to only one release?
+
+To restrict the deployment in this cluster to a single release, pass the allowed namespace:
+```bash
+helm install fluxcd/helm-operator --namespace flux --name helm-operator --values helm-operator-values.yaml --set allowNamespace=stg
+```
+