Merge branch 'main' into MarcGueury-patch-6

Author: anshoracle

.gitignore

@@ -3,3 +3,34 @@ shared-assets/bastion-py-script/.oci/
 shared-assets/bastion-py-script/temp/
 temp/
 app-dev/app-integration-and-automation/oracle-integration-cloud/01-oic-connectivity-agent/README_tmp.html
+
+
+# Local .terraform directories
+**/.terraform/*
+
+
+# Crash log files
+crash.log
+crash.*.log
+
+# Exclude all .tfvars files, which are likely to contain sensitive data, such as
+# password, private keys, and other secrets. These should not be part of version
+# control as they are data points which are potentially sensitive and subject
+# to change depending on the environment.
+*.tfvars
+*.tfvars.json
+
+
+# Ignore override files as they are usually used to override resources locally and so
+# are not checked in
+override.tf
+override.tf.json
+*_override.tf
+*_override.tf.json
+
+# Ignore CLI configuration files
+.terraformrc
+terraform.rc
+
+# Terraform lock files
+*.lock.hcl

app-dev/devops-and-containers/oke/oke-gitops/README.md

@@ -0,0 +1,145 @@
+# OKE GitOps with ArgoCD
+
+This repository's objective is to get you started quickly adopting a GitOps strategy for managing your OKE cluster.
+GitOps is just a series of best practices to manage operation using a Git repository.
+Administering a Kubernetes cluster is not an easy task, and I often see people getting lost in the forest of YAMLs and, with time,
+losing track of what is actually deployed in the cluster.
+
+To help simplifying the experience, it would be optimal to have all the configurations in a Git repository, so that we
+can organize our YAMLs in folders and inspect the code when we forget some nuances abut what has been already deployed.
+
+Problem is, GitOps requires a shift in mentality, as most of the operation team I have met are not familiar with Kubernetes, Git and modern operations.
+
+Hence, the idea of creating this template to get people started with GitOps and ArgoCD to manage OKE clusters.
+
+Before actually starting, it's good to remind us some best practices and concepts.
+
+## WHY GitOps?
+
+Traditionally, a Git repository is used by developers to version their custom application code.
+With recent years, the types of things we can create through code has drastically spiked, so Git repositories are also used by operation teams.
+Some examples:
+
+* Application code
+* Configuration as Code
+* Infrastructure as Code
+
+Having everything as code might seem something difficult and pointless at first, but with time, as the number of components increases, you will find out that it's way easier to debug complex and big
+systems if you have them defined as code.
+
+After all, the key to effectively manage a complex infrastructure is to have everything visible and do not lose control as complexity spikes.
+Some other advantages of GitOps are:
+* Faster and safer deployments
+* Easier rollbacks
+* Straightforward auditing
+* Better traceability
+* Eliminating configuration drift
+
+## WHY Kubernetes?
+
+When organizations start thinking of adopting Kubernetes as the reference development platform, I have always seen people struggling
+to get used to it, especially the operation teams who were used to managing on-prem servers or VMs.
+Some people even fear Kubernetes, saying it adds too much complexity in any architecture, and also that there is too much to study to get used to it.
+Working with customers, I have heard many good and bad things about Kubernetes, but in my opinion the truth lies in between.
+Let's see some common thinking I have observed over these years:
+* Kubernetes is just another system we need to take care of.
+  * A: no it is not! Kubernetes is a PLATFORM where other platforms are deployed on top of it. Think about it, in Kubernetes you can deploy anything: database systems, applications, Kafka, OpenSearch, caching systems and so on. Potentially, you could have your entire IT infrastructure deployed in a single Kubernetes cluster.
+* Kubernetes is too complex to actually use it
+  * A: it is indeed complex, as it is a very powerful platform, but once you get the hang of it, it will become eventually easy. Not everything can be easy at first, especially if we want to manage a platform to create other platforms.
+  * A: There are also many tutorials and a rich documentation, as well as certifications and courses. But of course, the best way to learn is always through practice.
+* Q: Why is Kubernetes so complex?
+  * A: Kubernetes is an Open Source platform, where people are supposed to deploy applications and the tools they prefer.
+    Being an open and customizable platform, there are a lot of choices to make and a lot of possibilities. If people are given
+    a lot of options, they tend to get lost in this maze of choices, especially if it is the first time they are dealing with Kubernetes.
+    For example, I often get these questions:
+    * How can we secure our Kubernetes cluster?
+    * Which ingress controller should we use? Or is it better to use Gateway API?
+    * Which tools are we supposed to use for logging? And what about monitoring and tracing?
+    * How many Kubernetes clusters should we have?
+    * How can we manage certificates?
+    * Should we have a service mesh in place?
+  * As a general suggestion, freedom of choice shouldn't be seen as something overwhelming, but it should be regarded as something positive.
+    You can start by deploying a tool based on some suggestions, evaluate it and uninstall it from the cluster if you don't like it.
+* Q: What is the main challenge of managing a Kubernetes cluster?
+  * A: In my opinion, what I have seen is that people struggle to administer a cluster because of lack of experience, automations and standards.
+    Because of deadlines and other priorities, it is also difficult for people in the operation teams to study Kubernetes.
+  * Although documentation is there, nothing beats actual experience, and most of the problems actually come to light when you have already started.
+
+In short, complexity is the main problem with Kubernetes, but there are some ways to mitigate complexity, and even some unexpected allies.
+
+## Provisioning Kubernetes: cloud providers are your best friends
+
+Provisioning a Kubernetes cluster is actually quite a daunting task. You need machines for the control plane and the data plane (the worker nodes), build some specific OS images and a way to bootstrap the cluster. One common way is to use tools like Kubeadm to bootstrap a cluster.
+You should also size properly the control plane, install etcd, install MetalLB if you want to expose services with a Load Balancer, provision a storage infrastructure, install a CNI for the cluster, create periodic backups of etcd and so on...
+In short, provisioning a new Kubernetes cluster is really difficult as it involves a lot of decisions in the process.
+
+But let's not panic, as luckily all cloud providers offer a managed Kubernetes cluster as a service!
+Let's take Oracle Cloud and the service OKE (Oracle Kubernetes Engine).
+With OKE, the whole Control Plane is managed by Oracle, and compared to provisioning an on-prem cluster, you get the following advantages:
+
+* No need to provision machines for the control plane, as the OKE service will take care of it
+* No need to think of making the control plane highly available, as OKE offers guaranteed SLAs
+* Backup of etcd is done by Oracle automatically every 15 minutes, and restored automatically in case of disruption
+* No need to learn Kubeadm, as the bootstrapping process is automated
+* No need to install MetalLB, as service of type LoadBalancer will provision a physical Load Balancer by exploiting the OCI Load Balancer service
+* No need to provision a storage infrastructure, as there are integration with native Oracle Cloud storage services
+* No need to install a CNI, as it is by default provisioned by the OKE service
+* No need to install CoreDNS or kube-proxy, as they are already installed and upgraded automatically by Oracle
+* No need to build custom OS images for the nodes, as Oracle already gives you pre-built images ready to use
+* No need to configure audit logs, they are always enabled and available to inspect
+* Easier upgrade process for the whole cluster
+* Possibility to automatically scale worker nodes
+* Security compliance and certification of the infrastructure
+* Support available, as long as you keep your OKE cluster updated
+* Integrated Container Registry service for container images
+* Possibility to standardize provisioning and do it with the as code approach (oci Terraform provider)
+
+In short, everything is way easier and secured. In addition, if you want more control, you can opt to deploy the control plane using the ClusterAPI provider.
+
+With the help of cloud providers, provisioning a new Kubernetes cluster should take about 15-20 minutes.
+
+## I have got my OKE cluster, so what?
+
+Having the capability to instantly spin up new infrastructure doesn’t always mean that your application developers can take advantage of the new infrastructure in the most optimal way.
+Provisioning a Kubernetes cluster is only the first step, and the next step is configuring and administering it.
+This step here is where people usually get lost, but here we will try to explain concepts so that they are easily understood and adopting the "as code" strategy.
+
+Generally speaking, there are always 3 kinds of code:
+
+* Application code
+* Cluster configurations + Infra applications
+* Infrastructure (IaC, Terraform)
+
+Understanding what these codes are and who is responsible for it is essential:
+
+* Application code = Kubernetes manifests to deploy the custom applications built by the Software Development team.
+  * This is different from the application source code, as the best practice is to separate the source code and the Kubernetes manifests so that they are in different repositories
+  * There should be 1 Git repository for every development team containing the Kubernetes manifests to deploy an application. The development team is the owner of the repository, not the operation team
+* Cluster configurations + Infra applications = Kubernetes manifests to deploy infrastructure related applications and configure the OKE cluster
+  * Infra applications are those applications that are not developed internally and that serves to maintain the whole cluster.
+    * Example: cert-manager is an infra application that will automatically generate certificates and renew them before they expire
+  * There should be 1 Git repository dedicated to infra applications and cluster configurations, to be used by the cluster administrators
+* IaC Infrastructure = Terraform code to provision an OKE cluster
+  * There should be 1 Git repository dedicated to the Terraform infrastructure for the chosen cloud provider
+
+For the IaC infrastructure in Oracle Cloud, you can use also OCI Resource Manager to manage the Terraform state and quickly provision an OKE cluster by using [this stack](../oke-rm)
+
+Next we will focus on the **"cluster administrator"** repository and the way to automate configurations and infra applications provisioning.
+
+## Cluster administration with ArgoCD
+
+ArgoCD is an open source, CNCF graduated project to implement GitOps in Kubernetes clusters.
+The base concept is very simple: the ArgoCD controller will be connected to a Git repository and will continuously pull the Kubernetes manifests and deploy them.
+So the role of the controller is to keep what is defined as code in the Git repository aligned with the "live" cluster configurations.
+The cluster administrators will then configure the cluster through code, and ArgoCD will keep everything in sync and consistent.
+
+With this repository, I want to propose a quick way to install ArgoCD in an OKE cluster and propose a Git template the administer OKE clusters.
+This stack will:
+* Provision a new OCI DevOps project
+* Create 2 OCI Code Repositories: one with pipelines definitions, and another one called "oke-cluster-config" with the git template for the OKE cluster administrators
+* Create an OCI Build Pipeline that will mirror the ArgoCD Helm Chart inside the Oracle Cloud Registry, and deploy it in the chosen cluster
+
+[![Deploy to Oracle Cloud](https://oci-resourcemanager-plugin.plugins.oci.oraclecloud.com/latest/deploy-to-oracle-cloud.svg)](https://cloud.oracle.com/resourcemanager/stacks/create?zipUrl=https://github.com/oracle-devrel/technology-engineering/releases/download/oke-gitops-1.0.0/stack.zip)
+
+Once the stack has been provisioned, you can modify the ArgoCD version to deploy by editing the `mirror_argo.yaml` file in the `pipelines` repository.
+By default, ArgoCD will be deployed in an "insecure" mode to disable the default SSL certificate, but feel free to modify the chart values in the `argo-cd-chart-values` artifact.

app-dev/devops-and-containers/oke/oke-gitops/data.tf

@@ -0,0 +1,11 @@
+data "oci_identity_user" "current_user" {
+  user_id = var.current_user_ocid
+}
+
+data "oci_identity_tenancy" "current_tenancy" {
+  tenancy_id = var.tenancy_ocid
+}
+
+data "oci_identity_region_subscriptions" "region_subscriptions_data" {
+  tenancy_id = var.tenancy_ocid
+}

app-dev/devops-and-containers/oke/oke-gitops/local.tf

@@ -0,0 +1,3 @@
+locals {
+  git_username = "${data.oci_identity_tenancy.current_tenancy.name}/${data.oci_identity_user.current_user.name}"
+}

app-dev/devops-and-containers/oke/oke-gitops/main.tf

@@ -0,0 +1,41 @@
+module "devops" {
+  source = "./modules/devops"
+  compartment_id = var.devops_compartment_id # Both DevOps project and OCIR will be here
+  region = var.region
+  tenancy_id = var.tenancy_ocid
+  create_notification_topic = var.create_notification_topic
+  notification_topic_id = var.notification_topic_id
+  notification_topic_name = var.notification_topic_name
+  notification_topic_description = var.notification_topic_description
+  devops_project_name = var.devops_project_name
+  devops_project_description = var.devops_project_description
+  devops_log_group_name = var.devops_log_group_name
+  devops_log_group_description = var.devops_log_group_description
+  devops_log_retention_period_in_days = var.devops_log_retention_period_in_days
+
+  git_username = local.git_username
+  git_password = var.auth_token
+  ocir_repo_path_prefix = var.ocir_repo_path_prefix
+
+  # OKE ENVIRONMENT
+  oke_cluster_id = var.oke_cluster_id
+  oke_environment_name = var.oke_environment_name
+  oke_environment_description = var.oke_environment_description
+  is_oke_cluster_private = var.is_oke_cluster_private
+  oke_worker_subnet_id = var.oke_worker_subnet_id
+  oke_worker_nsg_id = var.oke_worker_nsg_id
+}
+
+module "iam" {
+  source = "./modules/iam"
+  tenancy_id = var.tenancy_ocid
+  compartment_id = var.devops_compartment_id
+  network_compartment_id = var.network_compartment_id
+  oke_compartment_id = var.oke_compartment_id
+  devops_policy_name = var.devops_policy_name
+  domain_name = var.identity_domain_name
+  dynamic_group_name = var.devops_dynamic_group_name
+  is_oke_cluster_private = var.is_oke_cluster_private
+  count = var.create_iam ? 1 : 0
+  providers = {oci = oci.home}
+}

app-dev/devops-and-containers/oke/oke-gitops/modules/devops/artifact.tf

@@ -0,0 +1,41 @@
+data "oci_artifacts_container_configuration" "ocir_config" {
+  compartment_id = var.compartment_id
+}
+
+data "oci_identity_region_subscriptions" "oci_region_subscriptions" {
+  tenancy_id = var.tenancy_id
+}
+
+locals {
+  region_key = lower([for s in data.oci_identity_region_subscriptions.oci_region_subscriptions.region_subscriptions : s if s.region_name == var.region][0].region_key)
+  namespace = data.oci_artifacts_container_configuration.ocir_config.namespace
+}
+
+
+resource oci_devops_deploy_artifact argo_chart {
+  argument_substitution_mode = "NONE"
+  deploy_artifact_source {
+    chart_url = "oci://${local.region_key}.ocir.io/${local.namespace}/${var.ocir_repo_path_prefix}/argo-cd"
+    deploy_artifact_source_type = "HELM_CHART"
+    deploy_artifact_version     = "$${version}"
+    helm_verification_key_source {
+      verification_key_source_type = "NONE"
+    }
+  }
+  deploy_artifact_type = "HELM_CHART"
+  description          = "Location to the internal argo-cd chart generated by the build pipeline"
+  display_name         = "argo-cd-chart"
+  project_id = oci_devops_project.devops_project.id
+}
+
+resource oci_devops_deploy_artifact argo_chart_values {
+  argument_substitution_mode = "SUBSTITUTE_PLACEHOLDERS"
+  deploy_artifact_source {
+    base64encoded_content = filebase64("${path.root}/templates/argo-values.yml")
+    deploy_artifact_source_type = "INLINE"
+  }
+  deploy_artifact_type = "GENERIC_FILE"
+  description          = "Values of the argo-cd Helm Charts"
+  display_name         = "argo-cd-chart-values"
+  project_id = oci_devops_project.devops_project.id
+}

app-dev/devops-and-containers/oke/oke-gitops/modules/devops/build_pipeline.tf

@@ -0,0 +1,44 @@
+resource "oci_devops_build_pipeline" "mirror_argocd" {
+  project_id = oci_devops_project.devops_project.id
+  display_name = "mirror-argocd"
+  description = "Pipeline to mirror the public Helm Chart of ArgoCD into the tenancy OCIR"
+}
+
+resource "oci_devops_build_pipeline_stage" "mirror_argocd_stage" {
+  build_pipeline_id         = oci_devops_build_pipeline.mirror_argocd.id
+  build_pipeline_stage_type = "BUILD"
+  build_pipeline_stage_predecessor_collection {
+    items {
+      id = oci_devops_build_pipeline.mirror_argocd.id
+    }
+  }
+  build_source_collection {
+    items {
+      connection_type = "DEVOPS_CODE_REPOSITORY"
+      branch = "main"
+      name = "pipelines"
+      repository_id = oci_devops_repository.devops_pipelines_repo.id
+      repository_url = oci_devops_repository.devops_pipelines_repo.http_url
+    }
+  }
+  build_spec_file = "mirror_argo.yaml"
+  display_name = "Mirror Helm Chart"
+  description = "Stage to import a public Helm Chart into the tenancy Oracle Container Registry"
+  primary_build_source = "pipelines"
+  image = "OL7_X86_64_STANDARD_10"
+  stage_execution_timeout_in_seconds = 36000
+}
+
+resource "oci_devops_build_pipeline_stage" "trigger_helm_deploy" {
+  build_pipeline_id         = oci_devops_build_pipeline.mirror_argocd.id
+  build_pipeline_stage_type = "TRIGGER_DEPLOYMENT_PIPELINE"
+  build_pipeline_stage_predecessor_collection {
+    items {
+      id = oci_devops_build_pipeline_stage.mirror_argocd_stage.id
+    }
+  }
+  deploy_pipeline_id = oci_devops_deploy_pipeline.deploy_pipeline_helm.id
+  description = "Trigger CD pipeline to deploy on OKE"
+  display_name = "Trigger Helm Deployment pipeline"
+  is_pass_all_parameters_enabled = true
+}

app-dev/devops-and-containers/oke/oke-gitops/modules/devops/deployment.tf

@@ -0,0 +1,33 @@
+
+resource "oci_devops_deploy_pipeline" "deploy_pipeline_helm" {
+  project_id = oci_devops_project.devops_project.id
+  display_name = "helm-install-pipeline"
+  description = "Deployment pipeline to install Helm charts on a OKE cluster"
+}
+
+
+
+resource oci_devops_deploy_stage deploy_helm_stage {
+  are_hooks_enabled = true
+  deploy_pipeline_id = oci_devops_deploy_pipeline.deploy_pipeline_helm.id
+  deploy_stage_predecessor_collection {
+    items {
+      id = oci_devops_deploy_pipeline.deploy_pipeline_helm.id
+    }
+  }
+  deploy_stage_type = "OKE_HELM_CHART_DEPLOYMENT"
+  description  = "Install the Helm chart on the specified OKE environment"
+  display_name = "deploy-helm"
+  helm_chart_deploy_artifact_id = oci_devops_deploy_artifact.argo_chart.id
+  max_history = 5
+  namespace = "$${namespace}"
+  oke_cluster_deploy_environment_id = var.is_oke_cluster_private ? oci_devops_deploy_environment.oke_environment_private.0.id : oci_devops_deploy_environment.oke_environment_public.0.id
+  purpose      = "EXECUTE_HELM_UPGRADE"
+  release_name = "$${artifact}"
+  rollback_policy {
+    policy_type = "AUTOMATED_STAGE_ROLLBACK_POLICY"
+  }
+  should_skip_crds = false
+  timeout_in_seconds = "300"
+  values_artifact_ids = [oci_devops_deploy_artifact.argo_chart_values.id]
+}