This is an automated email from the ASF dual-hosted git repository. pcongiusti pushed a commit to branch main in repository https://gitbox.apache.org/repos/asf/camel-k.git
commit 01c4e3303f7236630409b23fd2df0f2cbdc35f22 Author: Pasquale Congiusti <[email protected]> AuthorDate: Sat Jan 11 09:29:09 2025 +0100 chore(doc): gitops tooling Closes #5998 --- docs/modules/ROOT/pages/running/promoting.adoc | 82 ++++++++++++++++++++++++++ 1 file changed, 82 insertions(+) diff --git a/docs/modules/ROOT/pages/running/promoting.adoc b/docs/modules/ROOT/pages/running/promoting.adoc index 29204d356..b884bc271 100644 --- a/docs/modules/ROOT/pages/running/promoting.adoc +++ b/docs/modules/ROOT/pages/running/promoting.adoc @@ -64,3 +64,85 @@ When you use the `promote` subcommand, you're also keeping the status of any con This is particularly nice when you have certain traits which are requiring the scan the source code (for instance, Service trait). In this way, when you promote the new Integration, the traits will be automatically configured to copy any parameter, replicating the very exact behavior between the source and destination environment. With this approach, you won't need to worry any longer about any trait which was requiring the source to be attached in order to automatically scan for features. + +[[gitops]] +== GitOps + +NOTE: this feature is available starting from version 2.6 + +The promote has also the possibility to create a Kustomize based overlay structure in order to simplify the creation of a **GitOps based deployment** process. Let's pretend we want to create a GitOps pipeline for two environments, as an example, *staging* and *production*. For each environment we can call the export command: + +``` +$ kamel promote promote-server -n development --to staging --export-gitops-dir /tmp/integrations +$ kamel promote promote-server -n development --to production --export-gitops-dir /tmp/integrations +``` + +NOTE: you can call this command for as many environments you manage + +The result will be a directory with the following structure: + +``` +$ tree /tmp/integrations/ +/tmp/integrations/ +└── promote-server + ├── base + │ ├── integration.yaml + │ └── kustomization.yaml + ├── overlays + │ ├── production + │ │ ├── kustomization.yaml + │ │ └── patch-integration.yaml + │ └── staging + │ ├── kustomization.yaml + │ └── patch-integration.yaml + └── routes + └── PromoteServer.java + +6 directories, 7 files +``` +The `promote-server` directory contains the Integration named as `promote-server` (the one we created in the previous chapter). Then, you can see a *base* directory which contains the base Integration custom resource. Additionally you will find the *staging* and *production* overlays which contains the patches you may want to apply in each given environment. + +``` +$ cat /tmp/integrations/promote-server/overlays/production/patch-integration.yaml +apiVersion: camel.apache.org/v1 +kind: Integration +metadata: + creationTimestamp: null + name: promote-server +spec: + traits: + mount: + configs: + - configmap:my-cm +status: {} +``` + +The CLI has a predetermined set of configuration (traits) which are typically subject of environment patching, such as Camel properties or any Kubernetes resource configuration. You will need to change those parameters accordingly or add any one else required for your specific use case. + +The above structure could be used directly with `kubectl` (eg, `kubectl apply -k /tmp/integrations/promote-server/overlays/production`). For this reason it can be used *as is* to feed a Git repository and referenced in any CICD pipeline. + +=== Running Camel with ArgoCD + +Once you have stored the project in a Git repository, if you're using a CICD technology like https://argo-cd.readthedocs.io[ArgoCD] you can run immediately your *production* pipeline as: + +``` +argocd app create my-ck-it-prod --repo https://git-server/repo/promote-server.git --path overlays/production --dest-server https://kubernetes.default.svc --dest-namespace prod +``` + +From this moment onward any change can be performed on the repository and it will be automatically refreshed by the CICD pipeline accordingly. + +NOTE: any other CICD technology can be adopted using the Git repository as source. + +=== Predetermined configuration + +The CLI will add a patch configuration for any of the following trait configuration found in the source base Integration: + +* Affinity configuration +* Camel properties +* Container resources +* Environment variables +* JVM options +* Mount configuration +* Toleration configuration + +NOTE: feel free to ask to add any further configuration you require.
