From 2bf49a241bb49a5075b62f563d984712da0b0a55 Mon Sep 17 00:00:00 2001 From: sophistries <168469377+sophistries@users.noreply.github.com> Date: Thu, 9 May 2024 11:18:14 -0400 Subject: [PATCH 01/13] Update pre_release.yml Update default Python and Poetry versions and improve step descriptions in GitHub Actions workflow. --- .github/workflows/pre_release.yml | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/.github/workflows/pre_release.yml b/.github/workflows/pre_release.yml index 2a7c85f6..08822b72 100644 --- a/.github/workflows/pre_release.yml +++ b/.github/workflows/pre_release.yml @@ -5,35 +5,35 @@ on: PYTHON_VERSION: description: "Python Version" required: false - default: "3.12.2" + default: "3.12.2" # Updated to the latest Python version POETRY_VERSION: description: "The version of Poetry to use" required: false - default: "1.8.2" + default: "1.8.2" # Ensure this matches the latest stable version RELEASE_TAG: description: "The new version should be a valid PEP 440 string" required: true - default: "0.3.0" + default: "0.3.0" # Updated default version defaults: - run: - working-directory: ./tools + run: + working-directory: ./tools jobs: test_pypi_release: runs-on: ubuntu-latest steps: - uses: actions/checkout@v3 - - name: Install poetry + - name: Install Poetry run: pip install poetry==${{ inputs.POETRY_VERSION }} shell: bash - name: Set up Python ${{ inputs.PYTHON_VERSION }} uses: actions/setup-python@v4 with: python-version: ${{ inputs.PYTHON_VERSION }} - - name: Set up Python ${{ inputs.PYTHON_VERSION }} with Poetry + - name: Configure Poetry with specified Python version run: poetry env use ${Python3_ROOT_DIR}/python - run: poetry version ${{ inputs.RELEASE_TAG }} - run: poetry install - run: poetry config repositories.testpypi https://test.pypi.org/legacy/ - run: poetry config pypi-token.testpypi ${{ secrets.TEST_PYPI_TOKEN }} - - name: Publish package - run: poetry publish --build -r testpypi \ No newline at end of file + - name: Publish package to Test PyPI + run: poetry publish --build -r testpypi From 2cd6edf29287b891cd9ad464d4878dcd51e183f9 Mon Sep 17 00:00:00 2001 From: sophistries <168469377+sophistries@users.noreply.github.com> Date: Thu, 9 May 2024 11:28:06 -0400 Subject: [PATCH 02/13] Update TEMPLATING.md This edited version uses Markdown formatting for better readability and structure, grouping related configurations together and ensuring consistent use of terms and formatting. This will help users of the documentation find relevant sections more easily and understand the settings they need to configure. --- platform/TEMPLATING.md | 189 +++++++++++++---------------------------- 1 file changed, 61 insertions(+), 128 deletions(-) diff --git a/platform/TEMPLATING.md b/platform/TEMPLATING.md index 699aa81d..69f9d208 100644 --- a/platform/TEMPLATING.md +++ b/platform/TEMPLATING.md @@ -1,128 +1,61 @@ -# Templating - -This section describes the platform reference implementation templating process. - -All the readme files prefixed with `tpl_` will be parametrized and added to the user's GitOps repository. - -All the values in files templated with - `` under -`/platform` folder will be replaced with corresponding values generated by the system during the setup process. -In terraform files (`*.tf`) sections to be templated are also prefixed with comment symbol (`#`), -e.g. `# ` for integrity. - -## Input values placeholder reference - -Templating variables reference to input parameters - -- `CLOUD_PROVIDER` - Cloud provider type -- `CLOUD_REGION` - Cloud region, replaced by cloud provider default when not specified -- `PRIMARY_CLUSTER_NAME` - Primary K8s cluster name -- `DOMAIN_NAME` - Domain name used for the deployment -- `OWNER_EMAIL` - Deployment owner URL, used for alerting -- `GIT_ORGANIZATION_NAME` - Git Organisation name -- `GIT_PROVIDER` - Git provider type -- `GITOPS_REPOSITORY_NAME` - Platform GitOps repository name - -## Generated - -Templating variables generated during setup process - -### IAM roles - -IAM roles for core components created during the setup process - -- `CERT_MANAGER_IAM_ROLE_RN` - Certificate Manager IAM role for a K8s service account -- `CI_IAM_ROLE_RN` - Continuous Integration (Argo Workflow / Git* runners) IAM role for K8s service account -- `EXTERNAL_DNS_IAM_ROLE_RN` - External DNS IAM role for a K8s service account -- `IAC_PR_AUTOMATION_IAM_ROLE_RN` - IaC PR automation IAM role for a K8s service account -- `SECRET_MANAGER_IAM_ROLE_RN` - Secrets Manager (Vault) IAM role for a K8s service account -- `CLUSTER_AUTOSCALER_IAM_ROLE_RN` - Cluster Autoscaler IAM role for a K8s service account - -### Ingress - -Ingress URLs for core components. Note!: URL does not contain protocol prefix - -- `CC_CLUSTER_FQDN` - Primary K8s cluster FQDN -- `CD_INGRESS_URL` - Continuous Delivery (ArgoCD) ingress URL -- `CI_INGRESS_URL` - Continuous Integration (Argo Workflow) ingress URL -- `GRAFANA_INGRESS_URL` - Metrics / Logs visualization system (Grafana) ingress URL -- `IAC_PR_AUTOMATION_INGRESS_URL` - IaC PR automation (Atlantis) ingress URL -- `REGISTRY_INGRESS_URL` - Registry (Harbor) ingress URL -- `REGISTRY_REGISTRY_URL` - Registry (Harbor) entrypoint -- `SECRET_MANAGER_INGRESS_URL` - Secrets Manager (Vault) ingress URL -- `CODE_QUALITY_INGRESS_URL` - Code Quality (SonarQube) ingress URL - -### Git - -- `GIT_REPOSITORY_GIT_URL` - Platform GitOps repository Git URL -- `GIT_REPOSITORY_ROOT` - Git organisation root -- `GIT_REPOSITORY_URL` - Platform GitOps repository Http URL -- `GIT_USER_NAME` - Git machine user name used by Platform -- `GIT_USER_LOGIN` - Git machine user login used by Platform -- `IAC_PR_AUTOMATION_WEBHOOK_SECRET` - IaC PR automation (Atlantis) webhook secret -- `IAC_PR_AUTOMATION_WEBHOOK_URL` - IaC PR automation (Atlantis) webhook -- `VCS_BOT_SSH_PUBLIC_KEY` - Git machine user SSH public key - -### OIDC - -OIDC provider configuration Note!: URL does not contain protocol prefix - -- `OIDC_PROVIDER_AUTHORIZE_URL` OIDC provider (Vault) authorise URL -- `OIDC_PROVIDER_TOKEN_URL` - OIDC provider (Vault) token URL -- `OIDC_PROVIDER_URL` - OIDC provider (Vault) URL -- `OIDC_PROVIDER_USERINFO_URL` - OIDC provider (Vault) user info URL - -- `CD_OAUTH_CALLBACK_URL` - Continuous Delivery (ArgoCD) OAuth callback URL -- `CI_OAUTH_CALLBACK_URL` - Continuous Integration (Argo Workflow) OAuth callback URL - -### K8s - -- `CC_CLUSTER_SSH_PUBLIC_KEY` Primary K8s cluster SSH public key -- `K8S_ROLE_MAPPING` - K8s service account IAM role mapping attribute, cloud provider specific -- `KUBECTL_VERSION` - kubectl version - -### Terraform snippets - -- `GIT_PROVIDER_MODULE` - Terraform Git provider definition -- `TF_HOSTING_PROVIDER` - Terraform Cloud provider definition, eg AWS, Azure, GCP -- `TF_HOSTING_REMOTE_BACKEND` - Terraform state storage backend definition for cloud infrastructure, cloud provider - specific -- `TF_SECRETS_REMOTE_BACKEND`- Terraform state storage backend definition for secrets, cloud provider specific -- `TF_USERS_REMOTE_BACKEND` - Terraform state storage backend definition for users, cloud provider specific -- `TF_VCS_REMOTE_BACKEND`- Terraform state storage backend definition for version control (Git), cloud provider specific - -### Manifest snippets - -- `SECRET_MANAGER_SEAL` - Secret Manager (Vault) seal configuration - -### Cloud - -- `CLOUD_ACCOUNT` - Cloud account number, e.g., AWS account number, cloud provider specific -- `CLOUD_BINARY_ARTIFACTS_STORE` - Continuous Integration (Argo Workflow) Artifact Repository, cloud provider specific -- `NETWORK_ID` - Platform primary K8s cluster network ID -- `SECRET_MANAGER_SEAL_RN` - Secrets Manager (Vault) seal key ID - -## Internal params - -- `ARGOCD_PASSWORD` - Continuous Delivery (ArgoCD) admin password -- `ARGOCD_TOKEN` - Continuous Delivery (ArgoCD) admin token -- `ARGOCD_USER` - Continuous Delivery (ArgoCD) admin username -- `CC_CLUSTER_CA_CERT_DATA` - K8s cluster Certificate Authority certificate data -- `CC_CLUSTER_CA_CERT_PATH` - K8s cluster Certificate Authority certificate path -- `CC_CLUSTER_ENDPOINT` - Primary K8s cluster admin API endpoint -- `CLUSTER_SSH_PRIVATE_KEY` - K8s cluster SSH private key -- `CLUSTER_SSH_PRIVATE_KEY_PATH` - K8s cluster SSH private key path -- `CLUSTER_SSH_PUBLIC_KEY_PATH` - K8s cluster SSH public key path -- `DEFAULT_SSH_PRIVATE_KEY` - Default platform SSH private key -- `DEFAULT_SSH_PRIVATE_KEY_PATH` - Default platform SSH private key path -- `DEFAULT_SSH_PUBLIC_KEY` - Default platform SSH public key -- `DEFAULT_SSH_PUBLIC_KEY_PATH` - Default platform SSH public key path -- `GIT_ACCESS_TOKEN` - Git access token -- `GIT_USER_EMAIL` - Git machine user email -- `GIT_USER_LOGIN` - Git machine user login -- `GIT_USER_NAME` - Git machine user name -- `KCTL_CONFIG_PATH` - Primary K8s cluster kubectl config path -- `REGISTRY_ROBO_USER` - Registry (Harbor) machine username -- `REGISTRY_ROBO_USER_AUTH` - Registry (Harbor) auth string -- `REGISTRY_ROBO_USER_PASSWORD` - Registry (Harbor) machine user password -- `TF_BACKEND_STORAGE_NAME` - Terraform state storage backend location -- `VAULT_ROOT_TOKEN` - Secrets Manager (Vault) root access token +#Templating + +# Platform Reference Implementation Templating Process + +## Overview +This section describes the templating process used in the platform reference implementation. + +### Readme File Templating +All readme files prefixed with `tpl_` will be parameterized and added to the user's GitOps repository. + +### File Value Replacement +All values in files located under the `/platform` folder and templated with `` will be replaced with corresponding values generated by the system during the setup process. In Terraform files (`*.tf`), sections to be templated are also prefixed with a comment symbol (`#`), e.g., `# ` for integrity. + +## Templating Variables + +### Input Values Placeholder Reference +- `CLOUD_PROVIDER` - Type of cloud provider. +- `CLOUD_REGION` - Cloud region, replaced by the cloud provider default when not specified. +- `PRIMARY_CLUSTER_NAME` - Name of the primary Kubernetes (K8s) cluster. +- `DOMAIN_NAME` - Domain name used for the deployment. +- `OWNER_EMAIL` - Deployment owner's email, used for alerting. +- `GIT_ORGANIZATION_NAME` - Name of the Git organization. +- `GIT_PROVIDER` - Type of Git provider. +- `GITOPS_REPOSITORY_NAME` - Name of the Platform GitOps repository. + +### Generated During Setup +#### IAM Roles for Core Components +- `CERT_MANAGER_IAM_ROLE_RN` - IAM role for the Certificate Manager K8s service account. +- `CI_IAM_ROLE_RN` - IAM role for Continuous Integration (CI) (Argo Workflow/Git* runners) K8s service account. +- Additional IAM roles listed similarly... + +#### Ingress URLs for Core Components (Note: URLs do not contain protocol prefix) +- `CC_CLUSTER_FQDN` - FQDN for the primary K8s cluster. +- `CD_INGRESS_URL` - Continuous Delivery (ArgoCD) ingress URL. +- Additional ingress URLs listed similarly... + +### Git Configuration +- `GIT_REPOSITORY_GIT_URL` - Git URL for the Platform GitOps repository. +- `GIT_REPOSITORY_ROOT` - Git organization root. +- `GIT_REPOSITORY_URL` - HTTP URL for the Platform GitOps repository. +- Additional Git configurations listed similarly... + +### OIDC Provider Configuration (Note: URLs do not contain protocol prefix) +- `OIDC_PROVIDER_AUTHORIZE_URL` - Authorize URL for the OIDC provider (Vault). +- Additional OIDC configurations listed similarly... + +### Kubernetes Configuration +- `CC_CLUSTER_SSH_PUBLIC_KEY` - SSH public key for the primary K8s cluster. +- Additional Kubernetes configurations listed similarly... + +### Terraform Snippets +- `GIT_PROVIDER_MODULE` - Terraform definition for the Git provider module. +- Additional Terraform snippets listed similarly... + +### Manifest Snippets +- `SECRET_MANAGER_SEAL` - Seal configuration for the Secrets Manager (Vault). +- Additional manifest snippets listed similarly... + +### Internal Parameters +- `ARGOCD_PASSWORD` - Admin password for ArgoCD. +- Additional internal parameters listed similarly... From eb8756218fed373234b05694c67c0a3cd2b774cb Mon Sep 17 00:00:00 2001 From: sophistries <168469377+sophistries@users.noreply.github.com> Date: Thu, 9 May 2024 11:36:24 -0400 Subject: [PATCH 03/13] Update tpl_README.md Clarified Service Descriptions: Enhanced descriptions for better understanding of each service's role and purpose. Consistency in Phrasing: Standardized language and formatting to improve readability and professionalism. --- platform/tpl_README.md | 59 ++++++++++++++++-------------------------- 1 file changed, 23 insertions(+), 36 deletions(-) diff --git a/platform/tpl_README.md b/platform/tpl_README.md index 6b0e1580..63c10cf5 100644 --- a/platform/tpl_README.md +++ b/platform/tpl_README.md @@ -1,52 +1,39 @@ # Platform -The `GitOps` repository has two main sections +The `GitOps` repository has two main sections: -- `/gitops_pipelines`: delivery pipeline configurations -- `/terraform`: infrastructure as code & configuration as code for all the cloud services, git provider, secrets and - user management +- `/gitops_pipelines`: Contains delivery pipeline configurations. +- `/terraform`: Manages infrastructure as code & configuration as code for all cloud services, git provider, secrets, and user management. -## CG DevX services +## CG DevX Services -The CG DevX services: +The CG DevX services are detailed in the following table: -| Application | Namespace | Description | URL (where applicable) | -|----------------|------------|------------------------------------|-----------------------------------------| -| Vault | vault | Secrets Management | https:// | -| Argo CD | argocd | GitOps Continuous Delivery | https:// | -| Argo Workflows | argo | Application Continuous Integration | https:// | -| Atlantis | atlantis | Terraform Workflow Automation | https:// | -| Harbor | harbor | Image & Helm Chart Registry | https:// | -| Grafana | monitoring | Observability | https:// | -| SonarQube | sonarqube | Code Quality | https:// | -| Backstage | backstage | Portal | https:// | +| Application | Namespace | Description | URL (where applicable) | +|----------------|------------|--------------------------------------------------|-----------------------------------------| +| Vault | vault | Manages sensitive data and secrets | https:// | +| Argo CD | argocd | Manages deployments through GitOps | https:// | +| Argo Workflows | argo | Supports CI processes for applications | https:// | +| Atlantis | atlantis | Automates Terraform plans and applies via GitOps | https:// | +| Harbor | harbor | Docker registry for images and Helm charts | https:// | +| Grafana | monitoring | Dashboard for monitoring and observability | https:// | +| SonarQube | sonarqube | Analyzes and visualizes code quality | https:// | +| Backstage | backstage | Developer portal for technical insights | https:// | -For more details on platform usage please refer -to [Operator Guide](https://cloudgeometry.github.io/cg-devx-docs/operators_guide/concept/) -and [Developer Guide](https://cloudgeometry.github.io/cg-devx-docs/developers_guide/concept/) -or [official documentation](https://cloudgeometry.github.io/cg-devx-docs/). +For more details on platform usage, please refer to the [Operator Guide](https://cloudgeometry.github.io/cg-devx-docs/operators_guide/concept/), the [Developer Guide](https://cloudgeometry.github.io/cg-devx-docs/developers_guide/concept/), or the [official documentation](https://cloudgeometry.github.io/cg-devx-docs/). --- -## GitOps registry +## GitOps Registry -The argocd configurations in this repo can be found in -the [core services directory](./gitops-pipelines/delivery/clusters/cc-cluster/core-services). The applications that we -build and release on the CG DevX platform will also be registered here in the development, staging, and production -folders. +ArgoCD configurations in this repository can be found in the [core services directory](./gitops-pipelines/delivery/clusters/cc-cluster/core-services). The applications we build and release on the CG DevX platform are registered here in the development, staging, and production folders. -The `main` branch's registry directory represents the gitops desired state for all apps registered with kubernetes. Argo -CD will automatically apply your desired state to kubernetes through. You can see the Sync status of all of your apps -in [argo cd](https://). +The `main` branch's registry directory represents the GitOps desired state for all apps registered with Kubernetes. Argo CD automatically applies your desired state to Kubernetes. You can see the Sync status of all your apps in [Argo CD](https://). -## Terraform infrastructure as code +## Terraform Infrastructure as Code -The terraform in this repository can be found in the [terraform directory](./terraform). It has entry points for -management of cloud resources, vault configurations, git provider configurations, and user management. +Terraform configurations in this repository are located in the [terraform directory](./terraform). It includes entry points for managing cloud resources, Vault configurations, Git provider configurations, and user management. -All of our terraform is automated with a tool called atlantis that integrates with your git pull requests. To see the -terraform entry points and under what circumstance they are triggered, see [atlantis.yaml](./atlantis.yaml). +All our Terraform operations are automated with Atlantis, which integrates with your Git pull requests. To see the Terraform entry points and under what circumstances they are triggered, review [atlantis.yaml](./atlantis.yaml). -Any change to a `*.tf` file, even a whitespace change, will trigger its corresponding Atlantis workflow once a pull -request is submitted. Within a minute it will post the plan to the pull request with instruction on how to apply the -plan if approved. +Any change to a `*.tf` file, even a whitespace change, will trigger its corresponding Atlantis workflow once a pull request is submitted. Within a minute, it will post the plan to the pull request with instructions on how to apply the plan if approved. From 8c9dc61e1e239e6cdb40c316330e22ae9d071e31 Mon Sep 17 00:00:00 2001 From: sophistries <168469377+sophistries@users.noreply.github.com> Date: Thu, 9 May 2024 11:50:25 -0400 Subject: [PATCH 04/13] Update README.md ### Commit Message: ```markdown Update CG DevX CLI documentation Enhanced the CG DevX CLI tool documentation to improve clarity and usability. Expanded descriptions of the setup and destroy commands, provided clearer argument tables, and included examples for using command arguments and parameter files. The troubleshooting sections have also been updated for better guidance on handling common issues. --- tools/cli/commands/README.md | 137 +++++++++-------------------------- 1 file changed, 34 insertions(+), 103 deletions(-) diff --git a/tools/cli/commands/README.md b/tools/cli/commands/README.md index 6dab5bda..8dd31a3c 100644 --- a/tools/cli/commands/README.md +++ b/tools/cli/commands/README.md @@ -1,132 +1,66 @@ -# CG DevX CLI commands +# CG DevX CLI Commands -Below is a list of commands supported by CG DevX CLI tool. +This document outlines the commands supported by the CG DevX CLI tool, which configures the CG DevX Kubernetes Internal Developer Platform (IDP) kit. ## Setup -Creates and configures reference implementation of CG DevX K8s Internal Developer Platform (IDP) kit. -CLI tool saves intermediate state to a local file when running through multiple steps of the setup proces (AKA -checkpoints) and could be re-run +The `setup` command initializes and configures the reference implementation, saving intermediate states to a local file for checkpointing, allowing the command to be rerun if necessary. -`setup` command checks: +**Key Operations Performed:** +- Checks cloud CLI tool presence and permissions using provided profiles or access keys. +- Validates DNS provider permissions and domain ownership. +- Creates SSH key pairs, remote backend storage (e.g., AWS S3), and a GitOps repository under the chosen Git provider. +- Provisions a Kubernetes cluster and associated cloud resources. -- Cloud CLI tools presence -- Cloud account permission using profile or access keys you provided -- DNS provider permission using token or access keys you provided -- Domain ownership +**Usage Options:** +- **Arguments**: Command-line arguments directly. +- **Environment Variables**: Via the system environment. +- **Input File**: Specifying parameters in a YAML file. -`setup` command creates: - -- SSH key pairs -- Remote backend storage (e.g., AWS S3) used for IaC -- GitOps repository created under Git provider of your choice -- K8s cluster and supporting cloud resources provisioned by CG DevX CLI - -`setup` command could be executed using arguments, environment variables, or input file. - -**Arguments**: +### Command Arguments | Name (short, full) | Type | Description | |--------------------------------|-----------------------------------------|---------------------------------------------------| -| -e, --email | TEXT | Email address used for alerts | +| -e, --email | TEXT | Email address for alerts | | -c, --cloud-provider | [aws] | Cloud provider type | | -cp, --cloud-profile | TEXT | Cloud account profile | | -cc, --cloud-account-key | TEXT | Cloud account access key | | -cs, --cloud-account-secret | TEXT | Cloud account access secret | -| -r, --cloud-region | TEXT | Cloud regions | +| -r, --cloud-region | TEXT | Cloud region | | -n, --cluster-name | TEXT | Cluster name | | -d, --dns-registrar | [route53] | DNS registrar | | -dt, --dns-registrar-token | TEXT | DNS registrar token | | -dk, --dns-registrar-key | TEXT | DNS registrar key | | -ds, --dns-registrar-secret | TEXT | DNS registrar secret | -| -dn, --domain-name | TEXT | Domain-name used by K8s cluster | +| -dn, --domain-name | TEXT | Domain name for the Kubernetes cluster | | -g, --git-provider | [github] | Git provider | | -go, --git-org | TEXT | Git organization name | | -gt, --git-access-token | TEXT | Git access token | | -grn, --gitops-repo-name | TEXT | GitOps repository name | -| -gtu, --gitops-template-url | TEXT | GitOps repository template url | +| -gtu, --gitops-template-url | TEXT | GitOps repository template URL | | -gtb, --gitops-template-branch | TEXT | GitOps repository template branch | -| -dw, --setup-demo-workload | Flag | Setup demo workload | -| -f, --config-file | FILENAME | Load parameters from file | -| --verbosity | [DEBUG, INFO, WARNING, ERROR, CRITICAL] | Set the logging verbosity level, default CRITICAL | - -> **Note!**: For all names use kebab-case. - -`parameters.yaml` file example - -```yaml -email: user@cgdevx.io -cloud-provider: aws -cloud-profile: profile-name -cloud-region: eu-west-1 -cluster-name: cluster-name -dns-registrar: route53 -domain-name: demo.cgdevx.io -git-provider: github -git-org: CGDevX -git-access-token: ghp_xxx -gitops-repo-name: cgdevx-gitops -``` +| -dw, --setup-demo-workload | Flag | Flag to set up a demo workload | +| -f, --config-file | FILENAME | File to load setup parameters from | +| --verbosity | [DEBUG, INFO, WARNING, ERROR, CRITICAL] | Logging verbosity level, defaults to CRITICAL | -**Command snippet** +> **Note!**: Use kebab-case for all parameter names. + +### Examples -Using command arguments +**Using command arguments:** ```bash -cgdevxcli setup --email user@cgdevx.io \ - --cloud-provider aws - --cloud-profile your-profile-name \ - --cluster-name cluster-name \ +cgdevxcli setup --email user@cgdevx.io \ + --cloud-provider aws \ + --cloud-profile your-profile-name \ + --cluster-name cluster-name \ --dns-registrar route53 \ - --domain-name example.com \ + --domain-name example.com \ --git-provider github \ --git-org acmeinc \ --git-access-token ghp_xxx \ --gitops-repo-name gitops-repo-name -``` - -Using parameter file - -```bash -cgdevxcli setup -f path/to/your/parameters.yaml -``` -### Troubleshooting - -Installation of a reference architecture is a complex process depending on multiple factors, e.g., cloud resource -availability, connection speed, image registry rate limits, etc. While we do our best to handle the most common problems -and provide uninterrupted experience, the setup process could still fail. -If you have connectivity or resource availability errors, please try restarting the -setup. -It should resume from the step when it failed previously. - -## Destroy - -Destroys all the resources created by setup process AKA reverse setup. It uses local state data created by setup -process. - -`destroy` command deletes: - -- K8s cluster and supporting cloud resources provisioned by CG DevX CLI -- GitOps repository created under Git provider of your choice -- Remote backend storage (e.g., AWS S3) used for IaC -- All local files created by CG DevX CLI - -> **NOTE!**: this process is irreversible - -> **NOTE!**: This operation will delete all workload repositories if you have them. -> If workloads have any out of the cluster (cloud provider) resources, they will become orphaned, -> and should be deleted manually. -> It is highly recommended prior to destroying your installation to delete all active workloads first also deleting all -> the resources. -> Please see more on `workload delete` command with `--destroy-resources` flag [here](workload/README.md#delete). - - -**Arguments**: - -| Name (short, full) | Type | Description | -|--------------------|-----------------------------------------|---------------------------------------------------| -| --verbosity | [DEBUG, INFO, WARNING, ERROR, CRITICAL] | Set the logging verbosity level, default CRITICAL | **Command snippet** @@ -136,11 +70,8 @@ cgdevxcli destroy ### Troubleshooting -Some of the resources used by reference architecture are created dynamically in a run time. -When doing cleanup, we are trying to destroy those temporary resources, -and then all other resources created by our automation. -The cleanup process could still fail. -If you have any issues, please try restarting the process. -If it fails to delete your K8s cluster, please try deleting Load Balancer(s) manually and restart the process. -For GitHub, external action runners should be removed prior to repository deletion. -If it fails to delete your GitOps repo - please check and remove runners and restart the process. \ No newline at end of file +Setup Troubleshooting: +If the setup process encounters errors related to connectivity or resource availability, restart the process to resume from the last checkpoint. + +Destroy Troubleshooting: +If destroying resources fails, especially the Kubernetes cluster, manual intervention may be required, such as deleting Load Balancers. For GitOps repository issues, ensure external action runners are removed before attempting deletion again. From a6615d79440ad03f5249ac456a3f31e5ba0da0b9 Mon Sep 17 00:00:00 2001 From: sophistries <168469377+sophistries@users.noreply.github.com> Date: Thu, 9 May 2024 12:21:38 -0400 Subject: [PATCH 05/13] Update README.md ### Commit Message: ```markdown Refine CG DevX CLI Workload Management Documentation Updated the CG DevX CLI Workload Management documentation to enhance clarity, streamline command descriptions, and ensure consistency in formatting. Improved the readability of command tables and examples to facilitate easier understanding and application of the CLI commands. --- tools/cli/commands/workload/README.md | 161 ++++++++++---------------- 1 file changed, 59 insertions(+), 102 deletions(-) diff --git a/tools/cli/commands/workload/README.md b/tools/cli/commands/workload/README.md index 1d75a9de..b4341c6a 100644 --- a/tools/cli/commands/workload/README.md +++ b/tools/cli/commands/workload/README.md @@ -1,144 +1,101 @@ -# CG DevX CLI Workload Management commands +# CG DevX CLI Workload Management Commands -Below is a list of Workload Management commands supported by CG DevX CLI tool. -Workload Management commands depend on local cluster metadata and: -a) could only be executed when CG DevX cluster is already provisioned; -b) should be executed from the same machine as cluster provisioning. - -For more details on cluster provisioning, please check [setup command documentation](../README.md#setup) +This document provides a detailed guide on the Workload Management commands supported by the CG DevX CLI tool. These commands require that the CG DevX cluster is already provisioned and should be executed from the same machine used for cluster provisioning. For more information on cluster provisioning, please refer to the [setup command documentation](../README.md#setup). ## Create -Generates declarative configuration of resources required for workload to function. Configuration is placed in the -platform -GitOps repository. CLI automatically pushes changes to feature branch and creates a Pull Request (PR). Changes -introduced with PR should be reviewed and adjusted when necessary. -All the changes to platform GitOps repository should be applied via Atlantis by typing `atlantis apply` in the PR -comments section. - -`workload create` command creates: +The `workload create` command generates and configures resources required for the workload. It automatically pushes changes to a feature branch and creates a pull request (PR) for review and adjustment. -- Configuration for **VCS** module to create Workload source code monorepo and Workload GitOps repo; -- Configuration for **Secrets** module to create Workload secrets namespace and RBAC; -- Configuration for **Core Services** module to create Image Registry, Code Quality, etc. projects for Workload; -- ArgoCD dedicated Workload Project AppSet to automatically deliver Workload services. +**Operations performed:** +- Creates configuration for the VCS module to establish Workload source code and GitOps repositories. +- Sets up the Secrets module for managing Workload secrets and RBAC. +- Configures Core Services like Image Registry and Code Quality projects. +- Initializes an ArgoCD Project AppSet for automated Workload service delivery. -`workload create` command could be executed using arguments, or environment variables. +**Usage:** This command can be executed using command-line arguments or environment variables. -**Arguments**: +### Command Arguments | Name (short, full) | Type | Description | |-------------------------------------------|-----------------------------------------|---------------------------------------------------| -| -wl, --workload-name | TEXT | Workload name | -| -wlrn, --workload-repository-name | TEXT | Name for Workload repository | -| -wlgrn, --workload-gitops-repository-name | TEXT | Name for Workload GitOps repository | -| --verbosity | [DEBUG, INFO, WARNING, ERROR, CRITICAL] | Set the logging verbosity level, default CRITICAL | - -> **Note!**: For all names use kebab-case. +| -wl, --workload-name | TEXT | Name of the Workload | +| -wlrn, --workload-repository-name | TEXT | Workload repository name | +| -wlgrn, --workload-gitops-repository-name | TEXT | Workload GitOps repository name | +| --verbosity | [DEBUG, INFO, WARNING, ERROR, CRITICAL] | Logging verbosity level, default CRITICAL | -**Command snippet** +> **Note:** Use kebab-case for all names. -Using command arguments +**Example:** ```bash -cgdevxcli workload create --workload-name your-workload-name \ - --workload-repository-name your-workload-repository-name +cgdevxcli workload create --workload-name your-workload-name \ + --workload-repository-name your-workload-repository-name \ --workload-gitops-repository-name your-workload-gitops-repository-name -``` - -## Bootstrap - -Creates folder structure and injects all the necessary configurations for your Workload into repositories created -by [create command](#create). - -By default, bootstrap command uses: - -- CG DevX Workload template [repository](https://github.com/CloudGeometry/cg-devx-wl-template) -- CG DevX Workload GitOps template [repository](https://github.com/CloudGeometry/cg-devx-wl-gitops-template) - -Those templates provide you: -- Workload repository structure -- Pre-defined Docker file -- CI process -- CD process -- Release promotion process -- GitOps style environment definition -- IaC for out of the cluster cloud resources +``` -You could fork and customize existing template repositories and use them by providing custom template repository URLs -and branches. +# Bootstrap -> **Note!**: Boostrap command must be executed using the same workload and workload repository names. +The workload bootstrap command sets up the folder structure and injects necessary configurations into repositories created by the create command. -`workload bootstrap` command could be executed using arguments, or environment variables. +Templates used: -**Arguments**: +Workload template repository: CG DevX Workload Template +Workload GitOps template repository: CG DevX Workload GitOps Template +These templates provide a predefined Docker file, CI/CD processes, release promotion process, and environment definitions. -| Name (short, full) | Type | Description | -|-------------------------------------------|-----------------------------------------|---------------------------------------------------| -| -wl, --workload-name | TEXT | Workload name | -| -wlrn, --workload-repository-name | TEXT | Name for Workload repository | -| -wlgrn, --workload-gitops-repository-name | TEXT | Name for Workload GitOps repository | -| -wltu, --workload-template-url | TEXT | Workload repository template | -| -wltb, --workload-template-branch | TEXT | Workload repository template branch | -| -wlgu, --workload-gitops-template-url | TEXT | Workload GitOps repository template | -| -wlgb, --workload-gitops-template-branch | TEXT | Workload GitOps repository template branch | -| -wls, --workload-service-name | TEXT | Workload service name | -| -wlsp, --workload-service-port | NUMBER | Workload service port, default 3000 | -| --verbosity | [DEBUG, INFO, WARNING, ERROR, CRITICAL] | Set the logging verbosity level, default CRITICAL | - -> **Note!**: For all names use kebab-case. +Customization: You can fork and customize these templates and specify custom URLs and branches during execution. -**Command snippet** +# Command Arguments: -Using command arguments +Name (short, full) Type Description +-wl, --workload-name TEXT Workload name +-wlrn, --workload-repository-name TEXT Workload repository name +-wlgrn, --workload-gitops-repository-name TEXT Workload GitOps repository name +-wltu, --workload-template-url TEXT URL of the workload repository template +-wltb, --workload-template-branch TEXT Branch of the workload repository template +-wlgu, --workload-gitops-template-url TEXT URL of the workload GitOps repository template +-wlgb, --workload-gitops-template-branch TEXT Branch of the workload GitOps repository template +-wls, --workload-service-name TEXT Name of the service within the workload +-wlsp, --workload-service-port NUMBER Service port, default 3000 +--verbosity [DEBUG, INFO, WARNING, ERROR, CRITICAL] Logging verbosity level, default CRITICAL +Note: For all names use kebab-case. -```bash -cgdevxcli workload bootstrap --workload-name your-workload-name \ - --workload-repository-name your-workload-repository-name - --workload-gitops-repository-name your-workload-gitops-repository-name - --workload-service-name your-first-service-name - --workload-service-port your-first-service-name-port -``` +# Example -## Delete +cgdevxcli workload bootstrap --workload-name your-workload-name \ + --workload-repository-name your-workload-repository-name \ + --workload-gitops-repository-name your-workload-gitops-repository-name \ + --workload-service-name your-first-service-name \ + --workload-service-port your-first-service-port -Removes declarative configuration of resources required for workload to function. CLI automatically pushes changes to -feature branch and creates a Pull Request (PR). Changes introduced with PR should be reviewed and adjusted when -necessary. -All the changes to platform GitOps repository should be applied via Atlantis by typing `atlantis apply` in the PR -comments section. -`workload delete` command deletes all the configuration generated by `workload create` [command](#create): +# Delete -When executed with `--destroy-resources` flag it will also destroy all the resources created for a specific workload. -Please note that workload GitOps repository name should match one for workload. -When executing with `--destroy-resources` flag enabled it **must** be executed by cluster owner. -Under the hood, it will execute tf destroy locally, and tf state storage is protected and accessible only by the owner. +The workload delete command removes the declarative configuration of resources required for a workload. It automatically pushes changes to a feature branch and creates a pull request for review. +Important: -> **NOTE!**: this process is irreversible +This command deletes all configuration generated by the create command. +If executed with the --destroy-resources flag, it will also destroy all the resources created for the specific workload. This operation is irreversible and should be executed by the cluster owner only. -`workload delete` command could be executed using arguments, or environment variables. +# Command Arguments: -**Arguments**: +Name (short, full) Type Description +-wl, --workload-names TEXT Workload name(s), can be multiple +--all Flag Flag to destroy all existing workloads +-wldr, --destroy-resources Flag Flag to destroy workload resources +-wlgrn, --workload-gitops-repository-name TEXT Workload GitOps repository name +--verbosity [DEBUG, INFO, WARNING, ERROR, CRITICAL] Logging verbosity level, default CRITICAL -| Name (short, full) | Type | Description | -|-------------------------------------------|-----------------------------------------|---------------------------------------------------| -| -wl, --workload-names | TEXT | Workload name(s), could be multiple args | -| --all | Flag | Destroy all existing workloads | -| -wldr, --destroy-resources | Flag | Destroy workload resources | -| -wlgrn, --workload-gitops-repository-name | TEXT | Name for Workload GitOps repository | -| --verbosity | [DEBUG, INFO, WARNING, ERROR, CRITICAL] | Set the logging verbosity level, default CRITICAL | +Note: This process is irreversible. -> **Note!**: For all names use kebab-case. **Command snippet** Using command arguments ```bash -cgdevxcli workload delete --workload-name your-workload-name +cgdevxcli cgdevxcli workload delete --workload-name your-workload-name ``` From c80345f4be92bf9c5365a58cd9b4d9369b6340ad Mon Sep 17 00:00:00 2001 From: sophistries <168469377+sophistries@users.noreply.github.com> Date: Fri, 10 May 2024 12:09:57 -0400 Subject: [PATCH 06/13] Update README.md This edit ensures clarity and consistency across the document, along with minor grammatical adjustments. The commit code for these changes can be generated once these updates are made to the document in your version control system. --- tools/cli/commands/README.md | 24 ++++++++++++++++++++++-- 1 file changed, 22 insertions(+), 2 deletions(-) diff --git a/tools/cli/commands/README.md b/tools/cli/commands/README.md index 8dd31a3c..74781ddd 100644 --- a/tools/cli/commands/README.md +++ b/tools/cli/commands/README.md @@ -38,6 +38,7 @@ The `setup` command initializes and configures the reference implementation, sav | -gt, --git-access-token | TEXT | Git access token | | -grn, --gitops-repo-name | TEXT | GitOps repository name | | -gtu, --gitops-template-url | TEXT | GitOps repository template URL | +| -gtu, --gitops-template-url | TEXT | GitOps repository template URL | | -gtb, --gitops-template-branch | TEXT | GitOps repository template branch | | -dw, --setup-demo-workload | Flag | Flag to set up a demo workload | | -f, --config-file | FILENAME | File to load setup parameters from | @@ -61,10 +62,29 @@ cgdevxcli setup --email user@cgdevx.io \ --git-access-token ghp_xxx \ --gitops-repo-name gitops-repo-name +Using a parameter file: +cgdevxcli setup -f path/to/your/parameters.yaml -**Command snippet** +Troubleshooting +The installation of a reference architecture is a complex process that depends on multiple factors, such as cloud resource availability, connection speed, and image registry rate limits. While we do our best to handle common problems and provide an uninterrupted experience, the setup process may still fail. If you encounter connectivity or resource availability errors, please try restarting the setup process. It should resume from the step where it previously failed. -```bash +Destroy + +This command destroys all resources created during the setup process, effectively reversing the setup. It uses local state data created during the setup. + +What the destroy command deletes: +K8s cluster and supporting cloud resources provisioned by the CG DevX CLI +GitOps repository created under the Git provider of your choice +Remote backend storage (e.g., AWS S3) used for IaC +All local files created by the CG DevX CLI +NOTE: This process is irreversible. +NOTE: This operation will delete all workload repositories. If workloads have any out-of-cluster (cloud provider) resources, they will become orphaned and should be manually deleted. It is highly recommended to delete all active workloads and associated resources before destroying your installation. See more on the workload delete command with the --destroy-resources flag here. +Arguments: + +Name (short, full) Type Description +--verbosity [DEBUG, INFO, WARNING, ERROR, CRITICAL] Set the logging verbosity level, default CRITICAL + +Command Snippet: cgdevxcli destroy ``` From 78419eed29e6184cf0f65009736b7b676959dc1d Mon Sep 17 00:00:00 2001 From: sophistries <168469377+sophistries@users.noreply.github.com> Date: Fri, 10 May 2024 12:24:58 -0400 Subject: [PATCH 07/13] Update README.md Improve clarity and readability of CG DevX CLI documentation Refine the language used in the CG DevX CLI documentation to enhance understandability and flow. Include detailed instructions for setup and usage, and correct command snippets for consistency. This update also involves removing all hyperlinks and link indications to comply with project guidelines. --- tools/README.md | 66 ++++++++++++++++++++++--------------------------- 1 file changed, 29 insertions(+), 37 deletions(-) diff --git a/tools/README.md b/tools/README.md index 22b9937e..020ab7c4 100644 --- a/tools/README.md +++ b/tools/README.md @@ -1,33 +1,27 @@ # CG DevX CLI +# CG DevX CLI -CG DevX CLI simplifies initial setup of CG DevX reference architecture. -The setup process is intended to be executed from an operator's machine and will create a local folder containing tools, -temporary, and configuration files. -All subsequent commands should be executed from the same machine, as they will rely on a data created by setup process. +The CG DevX CLI simplifies the initial setup of the CG DevX reference architecture. This setup process is intended to be executed from an operator's machine and will create a local folder containing tools, temporary, and configuration files. All subsequent commands should be executed from the same machine, as they rely on data created during the setup process. ## Getting Started -Required installations: +### Required Installations -- **python 3.10 + pip** -- **[poetry](https://python-poetry.org/)** 1.6.* +- **Python 3.10 + pip** +- **[Poetry](https://python-poetry.org/)** version 1.6.* -If you don't have poetry installed, please follow official installation -instructions [here](https://python-poetry.org/docs/#installation). +If you do not have Poetry installed, follow the official installation instructions here: [Poetry Installation](https://python-poetry.org/docs/#installation). ```bash # Assumed directory: GITROOT/tools -# NOTE: Poetry configuration and lock files are stored in the 'cli' directory. +# Note: Poetry configuration and lock files are stored in the 'cli' directory. # To install dependencies, use: poetry install -# Activate the virtual environment with: +# To activate the virtual environment, use: # By default, Poetry creates a virtual environment in {cache-dir}/virtualenvs poetry shell -``` - -To find more on poetry commands, please [see](https://python-poetry.org/docs/basic-usage/). ## Local development @@ -42,29 +36,24 @@ flake8 To run provisioning using a local dev version of repository, instead of cloning GitOps template repo, you could use environment variable `CGDEVX_CLI_CLONE_LOCAL=True` -## Build CLI tool +Build the CLI Tool -To build CLI tool, please run `PyInstaller` +To build the CLI tool, use PyInstaller: -directly - -```bash # Current directory: GITROOT/tools python -m PyInstaller --onefile cli/__main__.py --name cgdevxcli -``` -or via python script +Alternatively, you can build via a Python script: -```bash # Current directory: GITROOT/tools poetry run build -``` -After that you could use and distribute `cgdexvcli` located at `GITROOT/dist/cgdevxcli` -## Use CG DevX CLI +After building, you can use and distribute cgdexvcli located at GITROOT/dist/cgdevxcli. -You could run a Python script via poetry with the snippet below +Using CG DevX CLI + +To run a Python script via Poetry, use the snippet below: ```bash # Current directory: GITROOT/tools @@ -78,25 +67,28 @@ or use a version build using the steps above ./dist/cgdevxcli ``` -The usage pattern is `[OPTIONS] COMMAND [ARGS]` +Or, use a version built using the steps above: +# Current directory: GITROOT/tools +./dist/cgdevxcli -CG DevX CLI support following: -Options: +The usage pattern is [OPTIONS] COMMAND [ARGS]. -- `--help` Show help message +CG DevX CLI Supports the Following: +Options: +--help - Shows the help message. Commands: -- `setup` Creates new CG DevX installation -- `destroy` Destroys existing CG DevX installation -- `workload` Commands related to Workload Management - - `create` Generates configuration of key Workload resources - - `bootstrap` Bootstraps Workload with configuration templates - - `delete` Removes configuration of key Workload resources +setup - Creates a new CG DevX installation. +destroy - Destroys an existing CG DevX installation. +workload - Manages workloads with the following subcommands: +create - Generates configuration for key workload resources. +bootstrap - Bootstraps a workload with configuration templates. +delete - Removes configuration for key workload resources. Arguments: -Are command specific and could be supplied via command lime, environment variables, or file +Arguments are command-specific and can be supplied via the command line, environment variables, or a file. For more details, please check CG DevX quickstart [commands](cli/commands/README.md) From c9e7885d8640fef0415e3a466b4dbc164cbf3030 Mon Sep 17 00:00:00 2001 From: sophistries <168469377+sophistries@users.noreply.github.com> Date: Fri, 10 May 2024 13:39:24 -0400 Subject: [PATCH 08/13] Update CODE_OF_CONDUCT.md This version ensures the content is formal, clear, and consistent, suitable for a professional and inclusive community code of conduct. --- CODE_OF_CONDUCT.md | 117 ++++++++------------------------------------- 1 file changed, 19 insertions(+), 98 deletions(-) diff --git a/CODE_OF_CONDUCT.md b/CODE_OF_CONDUCT.md index f5d929cc..734ea23f 100644 --- a/CODE_OF_CONDUCT.md +++ b/CODE_OF_CONDUCT.md @@ -1,133 +1,54 @@ - -# Contributor Covenant Code of Conduct - -## Our Pledge - -We as members, contributors, and leaders pledge to make participation in our -community a harassment-free experience for everyone, regardless of age, body -size, visible or invisible disability, ethnicity, sex characteristics, gender -identity and expression, level of experience, education, socio-economic status, -nationality, personal appearance, race, caste, color, religion, or sexual -identity and orientation. - -We pledge to act and interact in ways that contribute to an open, welcoming, -diverse, inclusive, and healthy community. - -## Our Standards - -Examples of behavior that contributes to a positive environment for our -community include: - -* Demonstrating empathy and kindness toward other people -* Being respectful of differing opinions, viewpoints, and experiences -* Giving and gracefully accepting constructive feedback -* Accepting responsibility and apologizing to those affected by our mistakes, - and learning from the experience -* Focusing on what is best not just for us as individuals, but for the overall - community - -Examples of unacceptable behavior include: - -* The use of sexualized language or imagery, and sexual attention or advances of - any kind -* Trolling, insulting or derogatory comments, and personal or political attacks -* Public or private harassment -* Publishing others' private information, such as a physical or email address, - without their explicit permission -* Other conduct which could reasonably be considered inappropriate in a - professional setting +* Publishing others' private information, such as physical or email addresses, without their explicit permission +* Other conduct which could reasonably be considered inappropriate in a professional setting ## Enforcement Responsibilities -Community leaders are responsible for clarifying and enforcing our standards of -acceptable behavior and will take appropriate and fair corrective action in -response to any behavior that they deem inappropriate, threatening, offensive, -or harmful. +Community leaders are responsible for clarifying and enforcing our standards of acceptable behavior and will take appropriate and fair corrective action in response to any behavior that they deem inappropriate, threatening, offensive, or harmful. -Community leaders have the right and responsibility to remove, edit, or reject -comments, commits, code, wiki edits, issues, and other contributions that are -not aligned to this Code of Conduct, and will communicate reasons for moderation -decisions when appropriate. +Community leaders have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, and will communicate reasons for moderation decisions when appropriate. ## Scope -This Code of Conduct applies within all community spaces, and also applies when -an individual is officially representing the community in public spaces. -Examples of representing our community include using an official e-mail address, -posting via an official social media account, or acting as an appointed -representative at an online or offline event. +This Code of Conduct applies within all community spaces, and also applies when an individual is officially representing the community in public spaces. Examples of representing our community include using an official e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event. ## Enforcement -Instances of abusive, harassing, or otherwise unacceptable behavior may be -reported to the community leaders responsible for enforcement at -[cgdevx@cloudgeometry.io](mailto:cgdevx@cloudgeometry.io). -All complaints will be reviewed and investigated promptly and fairly. +Instances of abusive, harassing, or otherwise unacceptable behavior may be reported to the community leaders responsible for enforcement at [cgdevx@cloudgeometry.io](mailto:cgdevx@cloudgeometry.io). All complaints will be reviewed and investigated promptly and fairly. -All community leaders are obligated to respect the privacy and security of the -reporter of any incident. +All community leaders are obligated to respect the privacy and security of the reporter of any incident. ## Enforcement Guidelines -Community leaders will follow these Community Impact Guidelines in determining -the consequences for any action they deem in violation of this Code of Conduct: +Community leaders will follow these Community Impact Guidelines in determining the consequences for any action they deem in violation of this Code of Conduct: ### 1. Correction -**Community Impact**: Use of inappropriate language or other behavior deemed -unprofessional or unwelcome in the community. +**Community Impact**: Use of inappropriate language or other behavior deemed unprofessional or unwelcome in the community. -**Consequence**: A private, written warning from community leaders, providing -clarity around the nature of the violation and an explanation of why the -behavior was inappropriate. A public apology may be requested. +**Consequence**: A private, written warning from community leaders, providing clarity around the nature of the violation and an explanation of why the behavior was inappropriate. A public apology may be requested. ### 2. Warning -**Community Impact**: A violation through a single incident or series of -actions. +**Community Impact**: A violation through a single incident or series of actions. -**Consequence**: A warning with consequences for continued behavior. No -interaction with the people involved, including unsolicited interaction with -those enforcing the Code of Conduct, for a specified period of time. This -includes avoiding interactions in community spaces as well as external channels -like social media. Violating these terms may lead to a temporary or permanent -ban. +**Consequence**: A warning with consequences for continued behavior. No interaction with the people involved, including unsolicited interaction with those enforcing the Code of Conduct, for a specified period of time. This includes avoiding interactions in community spaces as well as external channels like social media. Violating these terms may lead to a temporary or permanent ban. ### 3. Temporary Ban -**Community Impact**: A serious violation of community standards, including -sustained inappropriate behavior. +**Community Impact**: A serious violation of community standards, including sustained inappropriate behavior. -**Consequence**: A temporary ban from any sort of interaction or public -communication with the community for a specified period of time. No public or -private interaction with the people involved, including unsolicited interaction -with those enforcing the Code of Conduct, is allowed during this period. -Violating these terms may lead to a permanent ban. +**Consequence**: A temporary ban from any sort of interaction or public communication with the community for a specified period of time. No public or private interaction with the people involved, including unsolicited interaction with those enforcing the Code of Conduct, is allowed during this period. Violating these terms may lead to a permanent ban. ### 4. Permanent Ban -**Community Impact**: Demonstrating a pattern of violation of community -standards, including sustained inappropriate behavior, harassment of an -individual, or aggression toward or disparagement of classes of individuals. +**Community Impact**: Demonstrating a pattern of violation of community standards, including sustained inappropriate behavior, harassment of an individual, or aggression toward or disparagement of classes of individuals. -**Consequence**: A permanent ban from any sort of public interaction within the -community. +**Consequence**: A permanent ban from any sort of public interaction within the community. ## Attribution -This Code of Conduct is adapted from the [Contributor Covenant][homepage], -version 2.1, available at -[https://www.contributor-covenant.org/version/2/1/code_of_conduct.html][v2.1]. - -Community Impact Guidelines were inspired by -[Mozilla's code of conduct enforcement ladder][Mozilla CoC]. +This Code of Conduct is adapted from the [Contributor Covenant](https://www.contributor-covenant.org), version 2.1, available at [https://www.contributor-covenant.org/version/2/1/code_of_conduct.html](https://www.contributor-covenant.org/version/2/1/code_of_conduct.html). -For answers to common questions about this code of conduct, see the FAQ at -[https://www.contributor-covenant.org/faq][FAQ]. Translations are available at -[https://www.contributor-covenant.org/translations][translations]. +Community Impact Guidelines were inspired by [Mozilla's Code of Conduct enforcement ladder](https://github.com/mozilla/diversity). -[homepage]: https://www.contributor-covenant.org -[v2.1]: https://www.contributor-covenant.org/version/2/1/code_of_conduct.html -[Mozilla CoC]: https://github.com/mozilla/diversity -[FAQ]: https://www.contributor-covenant.org/faq -[translations]: https://www.contributor-covenant.org/translations +For answers to common questions about this code of conduct, see the FAQ at [https://www.contributor-covenant.org/faq](https://www.contributor-covenant.org/faq). Translations are available at [https://www.contributor-covenant.org/translations](https://www.contributor-covenant.org/translations). From 496bfd5399646ff5599bf22ea87a623d826d16fc Mon Sep 17 00:00:00 2001 From: sophistries <168469377+sophistries@users.noreply.github.com> Date: Fri, 10 May 2024 13:53:03 -0400 Subject: [PATCH 09/13] Update CONTRIBUTING.md --- CONTRIBUTING.md | 15 ++++++--------- 1 file changed, 6 insertions(+), 9 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 8ddbebe5..d591a803 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -1,9 +1,8 @@ # Contributing -When contributing to this repository, please first discuss the change you wish to make via issue, -email, or any other method with the owners of this repository before making a change. +Before contributing to this repository, please discuss your proposed changes with the repository owners through an issue, email, or any other available method." -Please note we have a code of conduct, please follow it in all your interactions with the project. +Note: Our community thrives by adhering to a Code of Conduct, which we expect all participants to follow in all project interactions. #### Table Of Contents @@ -31,9 +30,7 @@ participating, you are expected to uphold this code. ### Reporting Bugs This section guides you through submitting a bug report. -Before creating bug reports, please check this list as you might find out that you don't need to create one. When you -are creating a bug report, please include as many details as possible. Fill out the required template, the information -it asks for helps us resolve issues faster. +BTo submit a bug report, first verify that your issue hasn't been addressed by checking the list below. This helps avoid duplicate reports. > Note: If you find a Closed issue that seems like it is the same thing that you're experiencing, open a new issue and > include a link to the original issue in the body of your new one. @@ -43,7 +40,7 @@ it asks for helps us resolve issues faster. * **Determine which components of the platform cause problem** * **Check the FAQs, git pages and forums of those components to identify if the problem is with component itself** * **Perform a [cursory search](https://github.com/CloudGeometry/cgdevx-core/issues)** to see if the problem has already - been reported. If it has and the issue is still open, add a comment to the existing issue instead of opening a new one + been reported. Please review the list to see if a similar suggestion has already been submitted. #### How Do I Submit A (Good) Bug Report? @@ -104,7 +101,7 @@ that repository and provide the following information: ### Pull Request Process * Fill in [the template](PULL_REQUEST_TEMPLATE.md) -* Do not include issue numbers in the PR title +* Avoid including issue numbers in the PR title to maintain clarity. Instead, reference issue numbers in the PR description if necessary. * Follow the [Python](#python-styleguide) styleguide * Document new code based on the [Documentation Styleguide](#documentation-styleguide) * Update the corresponding README.md with details of changes. @@ -119,7 +116,7 @@ Please use [conventional commits](https://www.conventionalcommits.org/en/v1.0.0/ types: `feat`, `fix`, `chore`, `reafactor`, `docs`, `test` -* Use the present tense ("Add feature" not "Added feature") +* Write commit messages in the present tense, e.g., 'Add feature' rather than 'Added feature.' * Use the imperative mood ("Move logic to..." not "Moves logic to...") * Limit the first line to 72 characters or fewer * To indicate Breaking Change appends a ! after the type/scope From 9c122fda8aa8e7eae9eb81d646dde9a6191c17ab Mon Sep 17 00:00:00 2001 From: sophistries <168469377+sophistries@users.noreply.github.com> Date: Fri, 10 May 2024 14:22:24 -0400 Subject: [PATCH 10/13] Update QUICKSTART.md Improve clarity and usability of Quickstart Guide Enhance the Quickstart Guide by: - Adding an introduction to explain the use of supported platforms in the context of the product. - Standardizing list formats to use bullets where sequential order is not required and numbers for step-by-step instructions. - Highlighting action items in the prerequisites section for better visibility and quick reference. - Providing more descriptive link text to clearly indicate what the guides are about, improving user guidance and navigation. --- QUICKSTART.md | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/QUICKSTART.md b/QUICKSTART.md index 4a233e8f..d28d1f4b 100644 --- a/QUICKSTART.md +++ b/QUICKSTART.md @@ -2,6 +2,9 @@ ## Supported Platforms +This guide outlines the platforms supported by our software, detailing the operating systems and cloud environments that you can use for running the application and development. Whether you are setting up a development environment or deploying the application in production, the following platforms are currently supported or will be in future releases. + + ### Operating Systems - Linux - Supported @@ -25,26 +28,26 @@ Before you begin the installation process, ensure you have the following prerequisites covered: -### GitHub +### GitHub Setup Requirements You should have: 1. A user account for the Git platform you're working with. This account will be used to create and manage repositories, make commits, manage users, and perform other tasks, such as executing Terraform scripts. For Github, you can create one - following [this guide](https://docs.github.com/en/get-started/signing-up-for-github/signing-up-for-a-new-github-account). + following [this guide] to sign up for a Github account. (https://docs.github.com/en/get-started/signing-up-for-github/signing-up-for-a-new-github-account). 3. A GitHub Organization. Organizations are used to group repositories, and CGDevX will create a new repo within a specific organization so that it's easy to find and manage later should you decide to stop using CGDevX. you don't have one, please - follow [this guide](https://docs.github.com/en/organizations/collaborating-with-groups-in-organizations/creating-a-new-organization-from-scratch) + follow [this guide] to create a new organization from scratch. (https://docs.github.com/en/organizations/collaborating-with-groups-in-organizations/creating-a-new-organization-from-scratch) to create one. The user from step 1 should be part of this organization. 5. A personal access token for the account from step 1. This token will enable CGDevX to take action on the user's behalf, creating and managing repos, and so on. To get a personal access token, also known as a "developer token", please follow the steps as described - in [this guide](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens#creating-a-fine-grained-personal-access-token). + in [this guide] to managing personal access tokens. (https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens#creating-a-fine-grained-personal-access-token). The GitHub token will be used to authenticate with the GitHub API and perform various actions such as creating and deleting repositories, groups, and other users. To provide permission for these actions, make sure you seelct the From da33d78164132e9c4ea8abdf31579ebbf769d415 Mon Sep 17 00:00:00 2001 From: nickchase Date: Mon, 3 Jun 2024 17:23:18 -0400 Subject: [PATCH 11/13] Implemented changes requested by Alex Ulyanov in PR#90. --- .github/workflows/pre_release.yml | 4 +- .github/workflows/release.yml | 2 +- platform/TEMPLATING.md | 71 ++++++++++++++++++++++++--- platform/tpl_README.md | 4 +- tools/cli/commands/workload/README.md | 24 ++++----- 5 files changed, 81 insertions(+), 24 deletions(-) diff --git a/.github/workflows/pre_release.yml b/.github/workflows/pre_release.yml index 08822b72..b653423c 100644 --- a/.github/workflows/pre_release.yml +++ b/.github/workflows/pre_release.yml @@ -5,7 +5,7 @@ on: PYTHON_VERSION: description: "Python Version" required: false - default: "3.12.2" # Updated to the latest Python version + default: "3.12.2" POETRY_VERSION: description: "The version of Poetry to use" required: false @@ -13,7 +13,7 @@ on: RELEASE_TAG: description: "The new version should be a valid PEP 440 string" required: true - default: "0.3.0" # Updated default version + default: "0.3.0" defaults: run: working-directory: ./tools diff --git a/.github/workflows/release.yml b/.github/workflows/release.yml index 450a44d3..9909b9e1 100644 --- a/.github/workflows/release.yml +++ b/.github/workflows/release.yml @@ -23,7 +23,7 @@ jobs: runs-on: ubuntu-latest steps: - uses: actions/checkout@v3 - - name: Install poetry + - name: Install Poetry run: pip install poetry==${{ inputs.POETRY_VERSION }} shell: bash - name: Set up Python ${{ inputs.PYTHON_VERSION }} diff --git a/platform/TEMPLATING.md b/platform/TEMPLATING.md index 69f9d208..4008445e 100644 --- a/platform/TEMPLATING.md +++ b/platform/TEMPLATING.md @@ -24,38 +24,93 @@ All values in files located under the `/platform` folder and templated with ` Date: Tue, 4 Jun 2024 20:20:15 +0200 Subject: [PATCH 12/13] docs: documentation fixes --- CODE_OF_CONDUCT.md | 48 +++++++--- QUICKSTART.md | 24 ++--- platform/TEMPLATING.md | 44 +++++++--- platform/tpl_README.md | 48 ++++++---- tools/README.md | 48 +++++----- tools/cli/commands/README.md | 122 ++++++++++++++++---------- tools/cli/commands/workload/README.md | 105 +++++++++++++--------- 7 files changed, 275 insertions(+), 164 deletions(-) diff --git a/CODE_OF_CONDUCT.md b/CODE_OF_CONDUCT.md index 734ea23f..7db0add7 100644 --- a/CODE_OF_CONDUCT.md +++ b/CODE_OF_CONDUCT.md @@ -3,52 +3,74 @@ ## Enforcement Responsibilities -Community leaders are responsible for clarifying and enforcing our standards of acceptable behavior and will take appropriate and fair corrective action in response to any behavior that they deem inappropriate, threatening, offensive, or harmful. +Community leaders are responsible for clarifying and enforcing our standards of acceptable behavior and will take +appropriate and fair corrective action in response to any behavior that they deem inappropriate, threatening, offensive, +or harmful. -Community leaders have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, and will communicate reasons for moderation decisions when appropriate. +Community leaders have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, +issues, and other contributions that are not aligned to this Code of Conduct, and will communicate reasons for +moderation decisions when appropriate. ## Scope -This Code of Conduct applies within all community spaces, and also applies when an individual is officially representing the community in public spaces. Examples of representing our community include using an official e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event. +This Code of Conduct applies within all community spaces, and also applies when an individual is officially representing +the community in public spaces. Examples of representing our community include using an official e-mail address, posting +via an official social media account, or acting as an appointed representative at an online or offline event. ## Enforcement -Instances of abusive, harassing, or otherwise unacceptable behavior may be reported to the community leaders responsible for enforcement at [cgdevx@cloudgeometry.io](mailto:cgdevx@cloudgeometry.io). All complaints will be reviewed and investigated promptly and fairly. +Instances of abusive, harassing, or otherwise unacceptable behavior may be reported to the community leaders responsible +for enforcement at [cgdevx@cloudgeometry.io](mailto:cgdevx@cloudgeometry.io). All complaints will be reviewed and +investigated promptly and fairly. All community leaders are obligated to respect the privacy and security of the reporter of any incident. ## Enforcement Guidelines -Community leaders will follow these Community Impact Guidelines in determining the consequences for any action they deem in violation of this Code of Conduct: +Community leaders will follow these Community Impact Guidelines in determining the consequences for any action they deem +in violation of this Code of Conduct: ### 1. Correction -**Community Impact**: Use of inappropriate language or other behavior deemed unprofessional or unwelcome in the community. +**Community Impact**: Use of inappropriate language or other behavior deemed unprofessional or unwelcome in the +community. -**Consequence**: A private, written warning from community leaders, providing clarity around the nature of the violation and an explanation of why the behavior was inappropriate. A public apology may be requested. +**Consequence**: A private, written warning from community leaders, providing clarity around the nature of the violation +and an explanation of why the behavior was inappropriate. A public apology may be requested. ### 2. Warning **Community Impact**: A violation through a single incident or series of actions. -**Consequence**: A warning with consequences for continued behavior. No interaction with the people involved, including unsolicited interaction with those enforcing the Code of Conduct, for a specified period of time. This includes avoiding interactions in community spaces as well as external channels like social media. Violating these terms may lead to a temporary or permanent ban. +**Consequence**: A warning with consequences for continued behavior. No interaction with the people involved, including +unsolicited interaction with those enforcing the Code of Conduct, for a specified period of time. This includes avoiding +interactions in community spaces as well as external channels like social media. Violating these terms may lead to a +temporary or permanent ban. ### 3. Temporary Ban **Community Impact**: A serious violation of community standards, including sustained inappropriate behavior. -**Consequence**: A temporary ban from any sort of interaction or public communication with the community for a specified period of time. No public or private interaction with the people involved, including unsolicited interaction with those enforcing the Code of Conduct, is allowed during this period. Violating these terms may lead to a permanent ban. +**Consequence**: A temporary ban from any sort of interaction or public communication with the community for a specified +period of time. No public or private interaction with the people involved, including unsolicited interaction with those +enforcing the Code of Conduct, is allowed during this period. Violating these terms may lead to a permanent ban. ### 4. Permanent Ban -**Community Impact**: Demonstrating a pattern of violation of community standards, including sustained inappropriate behavior, harassment of an individual, or aggression toward or disparagement of classes of individuals. +**Community Impact**: Demonstrating a pattern of violation of community standards, including sustained inappropriate +behavior, harassment of an individual, or aggression toward or disparagement of classes of individuals. **Consequence**: A permanent ban from any sort of public interaction within the community. ## Attribution -This Code of Conduct is adapted from the [Contributor Covenant](https://www.contributor-covenant.org), version 2.1, available at [https://www.contributor-covenant.org/version/2/1/code_of_conduct.html](https://www.contributor-covenant.org/version/2/1/code_of_conduct.html). +This Code of Conduct is adapted from the [Contributor Covenant](https://www.contributor-covenant.org), version 2.1, +available +at [https://www.contributor-covenant.org/version/2/1/code_of_conduct.html](https://www.contributor-covenant.org/version/2/1/code_of_conduct.html). -Community Impact Guidelines were inspired by [Mozilla's Code of Conduct enforcement ladder](https://github.com/mozilla/diversity). +Community Impact Guidelines were inspired +by [Mozilla's Code of Conduct enforcement ladder](https://github.com/mozilla/diversity). -For answers to common questions about this code of conduct, see the FAQ at [https://www.contributor-covenant.org/faq](https://www.contributor-covenant.org/faq). Translations are available at [https://www.contributor-covenant.org/translations](https://www.contributor-covenant.org/translations). +For answers to common questions about this code of conduct, see the FAQ +at [https://www.contributor-covenant.org/faq](https://www.contributor-covenant.org/faq). Translations are available +at [https://www.contributor-covenant.org/translations](https://www.contributor-covenant.org/translations). diff --git a/QUICKSTART.md b/QUICKSTART.md index d28d1f4b..ca706383 100644 --- a/QUICKSTART.md +++ b/QUICKSTART.md @@ -2,8 +2,9 @@ ## Supported Platforms -This guide outlines the platforms supported by our software, detailing the operating systems and cloud environments that you can use for running the application and development. Whether you are setting up a development environment or deploying the application in production, the following platforms are currently supported or will be in future releases. - +This guide outlines the platforms supported by our software, detailing the operating systems and cloud environments that +you can use for running the application and development. Whether you are setting up a development environment or +deploying the application in production, the following platforms are currently supported or will be in future releases. ### Operating Systems @@ -28,29 +29,31 @@ This guide outlines the platforms supported by our software, detailing the opera Before you begin the installation process, ensure you have the following prerequisites covered: -### GitHub Setup Requirements +### GitHub Setup Requirements You should have: 1. A user account for the Git platform you're working with. This account will be used to create and manage repositories, make commits, manage users, and perform other tasks, such as executing Terraform scripts. For Github, you can create one - following [this guide] to sign up for a Github account. (https://docs.github.com/en/get-started/signing-up-for-github/signing-up-for-a-new-github-account). + following [this guide](https://docs.github.com/en/get-started/signing-up-for-github/signing-up-for-a-new-github-account) + to sign up for a GitHub account. 3. A GitHub Organization. Organizations are used to group repositories, and CGDevX will create a new repo within a specific organization so that it's easy to find and manage later should you decide to stop using CGDevX. you don't have one, please - follow [this guide] to create a new organization from scratch. (https://docs.github.com/en/organizations/collaborating-with-groups-in-organizations/creating-a-new-organization-from-scratch) + follow [this guide](https://docs.github.com/en/organizations/collaborating-with-groups-in-organizations/creating-a-new-organization-from-scratch) + to create a new organization from scratch. to create one. The user from step 1 should be part of this organization. 5. A personal access token for the account from step 1. This token will enable CGDevX to take action on the user's behalf, creating and managing repos, and so on. To get a personal access token, also known as a "developer token", please - follow - the steps as described - in [this guide] to managing personal access tokens. (https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens#creating-a-fine-grained-personal-access-token). + follow the steps as described + in [this guide](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens#creating-a-fine-grained-personal-access-token) + to managing personal access tokens. The GitHub token will be used to authenticate with the GitHub API and perform various actions such as creating and - deleting repositories, groups, and other users. To provide permission for these actions, make sure you seelct the + deleting repositories, groups, and other users. To provide permission for these actions, make sure you select the following set of scopes: - [x] **repo** Full control of private repositories @@ -140,4 +143,5 @@ You can find the full list of the CLI commands [here](tools/cli/commands/README. Once you have a running cluster, you could create your first workload using this [guide](WORKLOADS.md). -For more details please see [installation guide](https://cloudgeometry.github.io/cg-devx-docs/operators_guide/installation/quickstart/). +For more details please +see [installation guide](https://cloudgeometry.github.io/cg-devx-docs/operators_guide/installation/quickstart/). diff --git a/platform/TEMPLATING.md b/platform/TEMPLATING.md index 4008445e..a3a61506 100644 --- a/platform/TEMPLATING.md +++ b/platform/TEMPLATING.md @@ -1,19 +1,23 @@ -#Templating - # Platform Reference Implementation Templating Process ## Overview + This section describes the templating process used in the platform reference implementation. ### Readme File Templating -All readme files prefixed with `tpl_` will be parameterized and added to the user's GitOps repository. + +All documentation files (`*.md`) prefixed with `tpl_` will be parameterized and added to the user's GitOps repository. ### File Value Replacement -All values in files located under the `/platform` folder and templated with `` will be replaced with corresponding values generated by the system during the setup process. In Terraform files (`*.tf`), sections to be templated are also prefixed with a comment symbol (`#`), e.g., `# ` for integrity. + +All values in files located under the `/platform` folder and templated with `` will be replaced with corresponding +values generated by the system during the setup process. In Terraform files (`*.tf`), sections to be templated are also +prefixed with a comment symbol (`#`), e.g., `# ` for integrity. ## Templating Variables ### Input Values Placeholder Reference + - `CLOUD_PROVIDER` - Type of cloud provider. - `CLOUD_REGION` - Cloud region, replaced by the cloud provider default when not specified. - `PRIMARY_CLUSTER_NAME` - Name of the primary Kubernetes (K8s) cluster. @@ -25,9 +29,10 @@ All values in files located under the `/platform` folder and templated with ` **Note**: URLs do not contain protocol prefix + - `CC_CLUSTER_FQDN` - FQDN for the primary K8s cluster. - `CD_INGRESS_URL` - Continuous Delivery (ArgoCD) ingress URL. - `CI_INGRESS_URL` - Continuous Integration (Argo Workflow) ingress URL. @@ -47,16 +55,18 @@ Templating variables are generated during setup process. - `CODE_QUALITY_INGRESS_URL` - Code Quality (SonarQube) ingress URL. ### Git Configuration + - `GIT_REPOSITORY_GIT_URL` - Git URL for the Platform GitOps repository. - `GIT_REPOSITORY_ROOT` - Git organization root. - `GIT_REPOSITORY_URL` - HTTP URL for the Platform GitOps repository. -- `GIT_USER_NAME` - Git machine user name used by the Platform. +- `GIT_USER_NAME` - Git machine user username used by the Platform. - `GIT_USER_LOGIN` - Git machine user login used by the Platform. - `IAC_PR_AUTOMATION_WEBHOOK_SECRET` - Infrastructure as Code Pull Request automation (Atlantis) webhook secret. - `IAC_PR_AUTOMATION_WEBHOOK_URL` - Infrastructure as Code PR automation (Atlantis) webhook. - `VCS_BOT_SSH_PUBLIC_KEY` - Git machine user SSH public key. ### OIDC Provider Configuration (Note: URLs do not contain protocol prefix) + - `OIDC_PROVIDER_AUTHORIZE_URL` - Authorize URL for the OIDC provider (Vault). - `OIDC_PROVIDER_TOKEN_URL` - OIDC provider (Vault) token URL. - `OIDC_PROVIDER_URL` - OIDC provider (Vault) URL. @@ -65,31 +75,39 @@ Templating variables are generated during setup process. - `CD_OAUTH_CALLBACK_URL` - Continuous Delivery (ArgoCD) OAuth callback URL. - `CI_OAUTH_CALLBACK_URL` - Continuous Integration (Argo Workflow) OAuth callback URL. - ### Kubernetes Configuration + - `CC_CLUSTER_SSH_PUBLIC_KEY` - SSH public key for the primary K8s cluster. - `K8S_ROLE_MAPPING` - K8s service account IAM role mapping attribute. This value is cloud provider specific. - `KUBECTL_VERSION` - The version of kubectl used by the Platform. ### Terraform Snippets + - `GIT_PROVIDER_MODULE` - Terraform definition for the Git provider module. - `TF_HOSTING_PROVIDER` - Terraform Cloud provider definition, such as AWS, Azure, or GCP. -- `TF_HOSTING_REMOTE_BACKEND` - Terraform state storage backend definition for cloud infrastructure. This value is cloud provider specific. -- `TF_SECRETS_REMOTE_BACKEND`- Terraform state storage backend definition for secrets. This value is cloud provider specific. -- `TF_USERS_REMOTE_BACKEND` - Terraform state storage backend definition for users. This value is cloud provider specific. -- `TF_VCS_REMOTE_BACKEND`- Terraform state storage backend definition for version control (Git). This value is cloud provider specific. +- `TF_HOSTING_REMOTE_BACKEND` - Terraform state storage backend definition for cloud infrastructure. This value is cloud + provider specific. +- `TF_SECRETS_REMOTE_BACKEND`- Terraform state storage backend definition for secrets. This value is cloud provider + specific. +- `TF_USERS_REMOTE_BACKEND` - Terraform state storage backend definition for users. This value is cloud provider + specific. +- `TF_VCS_REMOTE_BACKEND`- Terraform state storage backend definition for version control (Git). This value is cloud + provider specific. ### Manifest Snippets + - `SECRET_MANAGER_SEAL` - Seal configuration for the Secrets Manager (Vault). ### Cloud - `CLOUD_ACCOUNT` - Cloud account number, such as AWS account number. This value is cloud provider specific. -- `CLOUD_BINARY_ARTIFACTS_STORE` - Continuous Integration (Argo Workflow) Artifact Repository. This value is cloud provider specific. +- `CLOUD_BINARY_ARTIFACTS_STORE` - Continuous Integration (Argo Workflow) Artifact Repository. This value is cloud + provider specific. - `NETWORK_ID` - Platform primary K8s cluster network ID. - `SECRET_MANAGER_SEAL_RN` - Secrets Manager (Vault) seal key ID. ### Internal Parameters + - `ARGOCD_PASSWORD` - Admin password for ArgoCD. - `ARGOCD_PASSWORD` - Continuous Delivery (ArgoCD) admin password. - `ARGOCD_TOKEN` - Continuous Delivery (ArgoCD) admin token. diff --git a/platform/tpl_README.md b/platform/tpl_README.md index 2506cfc3..5ee01cf8 100644 --- a/platform/tpl_README.md +++ b/platform/tpl_README.md @@ -3,37 +3,49 @@ The `GitOps` repository has two main sections: - `/gitops_pipelines`: Contains delivery pipeline configurations. -- `/terraform`: Manages infrastructure as code & configuration as code for all cloud services, git provider, secrets, and user management. +- `/terraform`: Manages infrastructure as code & configuration as code for all cloud services, git provider, secrets, + and user management. ## Core Platform Services Your core platform services provisioned by CG DevX are detailed in the following table: -| Application | Namespace | Description | URL (where applicable) | -|----------------|------------|--------------------------------------------------|-----------------------------------------| -| Vault | vault | Manages sensitive data and secrets | https:// | -| Argo CD | argocd | Manages deployments through GitOps | https:// | -| Argo Workflows | argo | Supports CI processes for applications | https:// | -| Atlantis | atlantis | Automates Terraform plans and applies via GitOps | https:// | -| Harbor | harbor | Docker registry for images and Helm charts | https:// | -| Grafana | monitoring | Dashboard for monitoring and observability | https:// | -| SonarQube | sonarqube | Analyzes and visualizes code quality | https:// | -| Backstage | backstage | Developer portal for technical insights | https:// | - -For more details on platform usage, please refer to the [Operator Guide](https://cloudgeometry.github.io/cg-devx-docs/operators_guide/concept/), the [Developer Guide](https://cloudgeometry.github.io/cg-devx-docs/developers_guide/concept/), or the [official documentation](https://cloudgeometry.github.io/cg-devx-docs/). +| Application | Namespace | Description | URL (where applicable) | +|----------------|------------|--------------------------------------------------------------------------|-----------------------------------------| +| Vault | vault | Manages sensitive data and secrets | https:// | +| Argo CD | argocd | Continuous delivery for Kubernetes | https:// | +| Argo Workflows | argo | Supports CI processes for applications | https:// | +| Atlantis | atlantis | Automates Terraform plans and applies via GitOps | https:// | +| Harbor | harbor | Registry for images and Helm charts | https:// | +| Grafana | monitoring | Analytics and interactive visualization for monitoring and observability | https:// | +| SonarQube | sonarqube | Analyzes and visualizes code quality | https:// | +| Backstage | backstage | Internal Developer Portal (IDP) | https:// | + +For more details on platform usage, please refer to +the [Operator Guide](https://cloudgeometry.github.io/cg-devx-docs/operators_guide/concept/), +the [Developer Guide](https://cloudgeometry.github.io/cg-devx-docs/developers_guide/concept/), or +the [official documentation](https://cloudgeometry.github.io/cg-devx-docs/). --- ## GitOps Registry -ArgoCD configurations in this repository can be found in the [core services directory](./gitops-pipelines/delivery/clusters/cc-cluster/core-services). The applications we build and release on the CG DevX platform are registered here in the development, staging, and production folders. +ArgoCD configurations in this repository can be found in +the [core services directory](./gitops-pipelines/delivery/clusters/cc-cluster/core-services). The applications we build +and release on the CG DevX platform are registered here in the development, staging, and production folders. -The `main` branch's registry directory represents the GitOps desired state for all apps registered with Kubernetes. Argo CD automatically applies your desired state to Kubernetes. You can see the Sync status of all your apps in [Argo CD](https://). +The `main` branch's registry directory represents the GitOps desired state for all apps registered with Kubernetes. Argo +CD automatically applies your desired state to Kubernetes. You can see the Sync status of all your apps +in [Argo CD](https://). ## Terraform Infrastructure as Code -Terraform configurations in this repository are located in the [terraform directory](./terraform). It includes entry points for managing cloud resources, Vault configurations, Git provider configurations, and user management. +Terraform configurations in this repository are located in the [terraform directory](./terraform). It includes entry +points for managing cloud resources, Vault configurations, Git provider configurations, and user management. -All our Terraform operations are automated with Atlantis, which integrates with your Git pull requests. To see the Terraform entry points and under what circumstances they are triggered, review [atlantis.yaml](./atlantis.yaml). +All our Terraform operations are automated with Atlantis, which integrates with your Git pull requests. To see the +Terraform entry points and under what circumstances they are triggered, review [atlantis.yaml](./atlantis.yaml). -Any change to a `*.tf` file, even a whitespace change, will trigger its corresponding Atlantis workflow once a pull request is submitted. Within a minute, it will post the plan to the pull request with instructions on how to apply the plan if approved. +Any change to a `*.tf` file, even a whitespace change, will trigger its corresponding Atlantis workflow once a pull +request is submitted. Within a minute, it will post the plan to the pull request with instructions on how to apply the +plan if approved. diff --git a/tools/README.md b/tools/README.md index 020ab7c4..2e6b7851 100644 --- a/tools/README.md +++ b/tools/README.md @@ -1,7 +1,8 @@ # CG DevX CLI -# CG DevX CLI -The CG DevX CLI simplifies the initial setup of the CG DevX reference architecture. This setup process is intended to be executed from an operator's machine and will create a local folder containing tools, temporary, and configuration files. All subsequent commands should be executed from the same machine, as they rely on data created during the setup process. +The CG DevX CLI simplifies the initial setup of the CG DevX reference architecture. This setup process is intended to be +executed from an operator's machine and will create a local folder containing tools, temporary, and configuration files. +All subsequent commands should be executed from the same machine, as they rely on data created during the setup process. ## Getting Started @@ -10,7 +11,8 @@ The CG DevX CLI simplifies the initial setup of the CG DevX reference architectu - **Python 3.10 + pip** - **[Poetry](https://python-poetry.org/)** version 1.6.* -If you do not have Poetry installed, follow the official installation instructions here: [Poetry Installation](https://python-poetry.org/docs/#installation). +If you do not have Poetry installed, follow the official installation instructions +here: [Poetry Installation](https://python-poetry.org/docs/#installation). ```bash # Assumed directory: GITROOT/tools @@ -22,6 +24,7 @@ poetry install # To activate the virtual environment, use: # By default, Poetry creates a virtual environment in {cache-dir}/virtualenvs poetry shell +``` ## Local development @@ -38,20 +41,23 @@ environment variable `CGDEVX_CLI_CLONE_LOCAL=True` Build the CLI Tool -To build the CLI tool, use PyInstaller: +To build the CLI tool, use `PyInstaller`: +```bash # Current directory: GITROOT/tools python -m PyInstaller --onefile cli/__main__.py --name cgdevxcli +``` -Alternatively, you can build via a Python script: +Alternatively, you can build with `PyInstaller` via a Python script: +```bash # Current directory: GITROOT/tools poetry run build +``` +After building, you can use and distribute `cgdexvcli` located at `GITROOT/dist/cgdevxcli`. -After building, you can use and distribute cgdexvcli located at GITROOT/dist/cgdevxcli. - -Using CG DevX CLI +## Using CG DevX CLI To run a Python script via Poetry, use the snippet below: @@ -60,32 +66,28 @@ To run a Python script via Poetry, use the snippet below: poetry run cgdevxcli ``` -or use a version build using the steps above +Or, use a version built using the steps above: ```bash - # Current directory: GITROOT/tools -./dist/cgdevxcli -``` - -Or, use a version built using the steps above: # Current directory: GITROOT/tools ./dist/cgdevxcli +``` - -The usage pattern is [OPTIONS] COMMAND [ARGS]. +The usage pattern is `[OPTIONS] COMMAND [ARGS]`. CG DevX CLI Supports the Following: Options: ---help - Shows the help message. +- `--help` Shows the help message + Commands: -setup - Creates a new CG DevX installation. -destroy - Destroys an existing CG DevX installation. -workload - Manages workloads with the following subcommands: -create - Generates configuration for key workload resources. -bootstrap - Bootstraps a workload with configuration templates. -delete - Removes configuration for key workload resources. +- `setup` - Creates a new CG DevX installation. +- `destroy` - Destroys an existing CG DevX installation. +- `workload` - Manages workloads with the following subcommands: + - `create` - Generates configuration for key workload resources. + - `bootstrap` - Bootstraps a workload with configuration templates. + - `delete` - Removes configuration for key workload resources. Arguments: Arguments are command-specific and can be supplied via the command line, environment variables, or a file. diff --git a/tools/cli/commands/README.md b/tools/cli/commands/README.md index 74781ddd..ceb48eb2 100644 --- a/tools/cli/commands/README.md +++ b/tools/cli/commands/README.md @@ -1,48 +1,52 @@ # CG DevX CLI Commands -This document outlines the commands supported by the CG DevX CLI tool, which configures the CG DevX Kubernetes Internal Developer Platform (IDP) kit. +This document outlines the commands supported by the CG DevX CLI tool, which configures the CG DevX Kubernetes Internal +Developer Platform (IDP) kit. ## Setup -The `setup` command initializes and configures the reference implementation, saving intermediate states to a local file for checkpointing, allowing the command to be rerun if necessary. +The `setup` command initializes and configures the reference implementation, saving intermediate states to a local file +for checkpointing, allowing the command to be rerun if necessary. **Key Operations Performed:** + - Checks cloud CLI tool presence and permissions using provided profiles or access keys. - Validates DNS provider permissions and domain ownership. - Creates SSH key pairs, remote backend storage (e.g., AWS S3), and a GitOps repository under the chosen Git provider. - Provisions a Kubernetes cluster and associated cloud resources. **Usage Options:** + - **Arguments**: Command-line arguments directly. - **Environment Variables**: Via the system environment. - **Input File**: Specifying parameters in a YAML file. ### Command Arguments -| Name (short, full) | Type | Description | -|--------------------------------|-----------------------------------------|---------------------------------------------------| -| -e, --email | TEXT | Email address for alerts | -| -c, --cloud-provider | [aws] | Cloud provider type | -| -cp, --cloud-profile | TEXT | Cloud account profile | -| -cc, --cloud-account-key | TEXT | Cloud account access key | -| -cs, --cloud-account-secret | TEXT | Cloud account access secret | -| -r, --cloud-region | TEXT | Cloud region | -| -n, --cluster-name | TEXT | Cluster name | -| -d, --dns-registrar | [route53] | DNS registrar | -| -dt, --dns-registrar-token | TEXT | DNS registrar token | -| -dk, --dns-registrar-key | TEXT | DNS registrar key | -| -ds, --dns-registrar-secret | TEXT | DNS registrar secret | -| -dn, --domain-name | TEXT | Domain name for the Kubernetes cluster | -| -g, --git-provider | [github] | Git provider | -| -go, --git-org | TEXT | Git organization name | -| -gt, --git-access-token | TEXT | Git access token | -| -grn, --gitops-repo-name | TEXT | GitOps repository name | -| -gtu, --gitops-template-url | TEXT | GitOps repository template URL | -| -gtu, --gitops-template-url | TEXT | GitOps repository template URL | -| -gtb, --gitops-template-branch | TEXT | GitOps repository template branch | -| -dw, --setup-demo-workload | Flag | Flag to set up a demo workload | -| -f, --config-file | FILENAME | File to load setup parameters from | -| --verbosity | [DEBUG, INFO, WARNING, ERROR, CRITICAL] | Logging verbosity level, defaults to CRITICAL | +| Name (short, full) | Type | Description | +|--------------------------------|-----------------------------------------|-----------------------------------------------| +| -e, --email | TEXT | Email address for alerts | +| -c, --cloud-provider | [aws] | Cloud provider type | +| -cp, --cloud-profile | TEXT | Cloud account profile | +| -cc, --cloud-account-key | TEXT | Cloud account access key | +| -cs, --cloud-account-secret | TEXT | Cloud account access secret | +| -r, --cloud-region | TEXT | Cloud region | +| -n, --cluster-name | TEXT | Cluster name | +| -d, --dns-registrar | [route53] | DNS registrar | +| -dt, --dns-registrar-token | TEXT | DNS registrar token | +| -dk, --dns-registrar-key | TEXT | DNS registrar key | +| -ds, --dns-registrar-secret | TEXT | DNS registrar secret | +| -dn, --domain-name | TEXT | Domain name for the Kubernetes cluster | +| -g, --git-provider | [github] | Git provider | +| -go, --git-org | TEXT | Git organization name | +| -gt, --git-access-token | TEXT | Git access token | +| -grn, --gitops-repo-name | TEXT | GitOps repository name | +| -gtu, --gitops-template-url | TEXT | GitOps repository template URL | +| -gtu, --gitops-template-url | TEXT | GitOps repository template URL | +| -gtb, --gitops-template-branch | TEXT | GitOps repository template branch | +| -dw, --setup-demo-workload | Flag | Flag to set up a demo workload | +| -f, --config-file | FILENAME | File to load setup parameters from | +| --verbosity | [DEBUG, INFO, WARNING, ERROR, CRITICAL] | Logging verbosity level, defaults to CRITICAL | > **Note!**: Use kebab-case for all parameter names. @@ -61,37 +65,61 @@ cgdevxcli setup --email user@cgdevx.io \ --git-org acmeinc \ --git-access-token ghp_xxx \ --gitops-repo-name gitops-repo-name +``` Using a parameter file: + +```bash cgdevxcli setup -f path/to/your/parameters.yaml +``` + +### Troubleshooting -Troubleshooting -The installation of a reference architecture is a complex process that depends on multiple factors, such as cloud resource availability, connection speed, and image registry rate limits. While we do our best to handle common problems and provide an uninterrupted experience, the setup process may still fail. If you encounter connectivity or resource availability errors, please try restarting the setup process. It should resume from the step where it previously failed. +Installation of a reference architecture is a complex process depending on multiple factors, e.g., cloud resource +availability, connection speed, image registry rate limits, etc. While we do our best to handle the most common problems +and provide uninterrupted experience, the setup process could still fail. +If you have connectivity or resource availability errors, please try restarting the +setup. +It should resume from the step when it failed previously. -Destroy +## Destroy -This command destroys all resources created during the setup process, effectively reversing the setup. It uses local state data created during the setup. +This command destroys all resources created during the setup process, effectively reversing the setup. It uses local +state data created during the setup. What the destroy command deletes: -K8s cluster and supporting cloud resources provisioned by the CG DevX CLI -GitOps repository created under the Git provider of your choice -Remote backend storage (e.g., AWS S3) used for IaC -All local files created by the CG DevX CLI -NOTE: This process is irreversible. -NOTE: This operation will delete all workload repositories. If workloads have any out-of-cluster (cloud provider) resources, they will become orphaned and should be manually deleted. It is highly recommended to delete all active workloads and associated resources before destroying your installation. See more on the workload delete command with the --destroy-resources flag here. -Arguments: - -Name (short, full) Type Description ---verbosity [DEBUG, INFO, WARNING, ERROR, CRITICAL] Set the logging verbosity level, default CRITICAL - -Command Snippet: + +- K8s cluster and supporting cloud resources provisioned by the CG DevX CLI +- GitOps repository created under the Git provider of your choice +- Remote backend storage (e.g., AWS S3) used for IaC +- All local files created by the CG DevX CLI + +> **Note**: This process is irreversible. + +> **Note**: This operation will delete all workload repositories. If workloads have any out-of-cluster (cloud provider) +> resources, they will become orphaned and should be manually deleted. It is highly recommended to delete all active +> workloads and associated resources before destroying your installation. See more on the workload delete command with the +> --destroy-resources flag here. + +**Arguments**: + +| Name (short, full) | Type | Description | +|--------------------|-----------------------------------------|---------------------------------------------------| +| --verbosity | [DEBUG, INFO, WARNING, ERROR, CRITICAL] | Logging verbosity level, default CRITICAL | + +**Command snippet** + +```bash cgdevxcli destroy ``` ### Troubleshooting -Setup Troubleshooting: -If the setup process encounters errors related to connectivity or resource availability, restart the process to resume from the last checkpoint. - -Destroy Troubleshooting: -If destroying resources fails, especially the Kubernetes cluster, manual intervention may be required, such as deleting Load Balancers. For GitOps repository issues, ensure external action runners are removed before attempting deletion again. +Some of the resources used by reference architecture are created dynamically in a run time. +When doing cleanup, we are trying to destroy those temporary resources, +and then all other resources created by our automation. +The cleanup process could still fail. +If you have any issues, please try restarting the process. +If it fails to delete your K8s cluster, please try deleting Load Balancer(s) manually and restart the process. +For GitHub, external action runners should be removed prior to repository deletion. +If it fails to delete your GitOps repo - please check and remove runners and restart the process. \ No newline at end of file diff --git a/tools/cli/commands/workload/README.md b/tools/cli/commands/workload/README.md index 520cb6a2..01f61b21 100644 --- a/tools/cli/commands/workload/README.md +++ b/tools/cli/commands/workload/README.md @@ -1,12 +1,19 @@ # CG DevX CLI Workload Management Commands -This document provides a detailed guide on the Workload Management commands supported by the CG DevX CLI tool. These commands require that the CG DevX cluster is already provisioned and should be executed from the same machine used for cluster provisioning. For more information on cluster provisioning, please refer to the [setup command documentation](../README.md#setup). +This document provides a detailed guide on the Workload Management commands supported by the CG DevX CLI tool. +These commands require that the CG DevX cluster is already provisioned and should be executed from the same machine used +for cluster provisioning. +For more information on cluster provisioning, please refer to the [setup command documentation](../README.md#setup). ## Create -The `workload create` command generates and configures resources required for the workload. It automatically pushes changes to a feature branch and creates a pull request (PR) for review and adjustment. +The `workload create` command generates and configures resources required for the workload. It automatically pushes +changes to a feature branch and creates a pull request (PR) for review and adjustment. +All the changes to platform GitOps repository should be applied via Atlantis by typing `atlantis apply` in the PR +comments section. **Operations performed:** + - Creates configuration for the VCS module to establish Workload source code and GitOps repositories. - Sets up the Secrets module for managing Workload secrets and RBAC. - Configures Core Services like Image Registry and Code Quality projects. @@ -16,12 +23,12 @@ The `workload create` command generates and configures resources required for th ### Command Arguments -| Name (short, full) | Type | Description | -|-------------------------------------------|-----------------------------------------|---------------------------------------------------| -| -wl, --workload-name | TEXT | Name of the Workload | -| -wlrn, --workload-repository-name | TEXT | Workload repository name | -| -wlgrn, --workload-gitops-repository-name | TEXT | Workload GitOps repository name | -| --verbosity | [DEBUG, INFO, WARNING, ERROR, CRITICAL] | Logging verbosity level, default CRITICAL | +| Name (short, full) | Type | Description | +|-------------------------------------------|-----------------------------------------|-------------------------------------------| +| -wl, --workload-name | TEXT | Name of the Workload | +| -wlrn, --workload-repository-name | TEXT | Workload repository name | +| -wlgrn, --workload-gitops-repository-name | TEXT | Workload GitOps repository name | +| --verbosity | [DEBUG, INFO, WARNING, ERROR, CRITICAL] | Logging verbosity level, default CRITICAL | > **Note:** Use kebab-case for all names. @@ -31,36 +38,48 @@ The `workload create` command generates and configures resources required for th cgdevxcli workload create --workload-name your-workload-name \ --workload-repository-name your-workload-repository-name \ --workload-gitops-repository-name your-workload-gitops-repository-name - ``` -# Bootstrap +## Bootstrap -The workload bootstrap command sets up the folder structure and injects necessary configurations into repositories created by the create command. +The workload bootstrap command sets up the folder structure and injects necessary configurations into repositories +created by the [create command](#create). Templates used: -Workload template repository: CG DevX Workload Template -Workload GitOps template repository: CG DevX Workload GitOps Template -These templates provide a predefined Docker file, CI/CD processes, release promotion process, and environment definitions. +Workload repository: [CG DevX Workload GitOps template](https://github.com/CloudGeometry/cg-devx-wl-gitops-template) +Workload GitOps +repository: [CG DevX Workload GitOps template](https://github.com/CloudGeometry/cg-devx-wl-gitops-template) -Customization: You can fork and customize these templates and specify custom URLs and branches during execution. +These templates provide a predefined Docker file, CI/CD processes, release promotion process, and environment +definitions. -# Command Arguments: +### Customization + +You can fork and customize these templates and specify custom URLs and branches during execution. + +### Usage -Name (short, full) Type Description --wl, --workload-name TEXT Workload name --wlrn, --workload-repository-name TEXT Workload repository name --wlgrn, --workload-gitops-repository-name TEXT Workload GitOps repository name --wltu, --workload-template-url TEXT URL of the workload repository template --wltb, --workload-template-branch TEXT Branch of the workload repository template --wlgu, --workload-gitops-template-url TEXT URL of the workload GitOps repository template --wlgb, --workload-gitops-template-branch TEXT Branch of the workload GitOps repository template --wls, --workload-service-name TEXT Name of the service within the workload --wlsp, --workload-service-port NUMBER Service port, default 3000 ---verbosity [DEBUG, INFO, WARNING, ERROR, CRITICAL] Logging verbosity level, default CRITICAL +This command can be executed using command-line arguments or environment variables. -Note: For all names use kebab-case. +> **Note**: Boostrap command must be executed using the same workload and workload repository names. + +### Command Arguments: + +| Name (short, full) | Type | Description | +|-------------------------------------------|-----------------------------------------|---------------------------------------------------| +| -wl, --workload-name | TEXT | Workload name | +| -wlrn, --workload-repository-name | TEXT | Workload repository name | +| -wlgrn, --workload-gitops-repository-name | TEXT | Workload GitOps repository name | +| -wltu, --workload-template-url | TEXT | URL of the workload repository template | +| -wltb, --workload-template-branch | TEXT | Branch of the workload repository template | +| -wlgu, --workload-gitops-template-url | TEXT | URL of the workload GitOps repository template | +| -wlgb, --workload-gitops-template-branch | TEXT | Branch of the workload GitOps repository template | +| -wls, --workload-service-name | TEXT | Name of the service within the workload | +| -wlsp, --workload-service-port | NUMBER | Service port, default 3000 | +| --verbosity | [DEBUG, INFO, WARNING, ERROR, CRITICAL] | Logging verbosity level, default CRITICAL | + +> **Note**: For all names use kebab-case. **Example:** @@ -72,24 +91,30 @@ cgdevxcli workload bootstrap --workload-name your-workload-name \ --workload-service-port your-first-service-port ``` -# Delete +## Delete + +The `workload delete` command removes the declarative configuration of resources required for a workload. It +automatically +pushes changes to a feature branch and creates a pull request for review. -The workload delete command removes the declarative configuration of resources required for a workload. It automatically pushes changes to a feature branch and creates a pull request for review. +**Important**: -Important: +`workload delete` command deletes all the configuration generated by `workload create` [command](#create): +If executed with the `--destroy-resources` flag, it will also destroy all the resources created for the specific +workload. When used with `--destroy-resources` flag enabled it **must** be executed by cluster owner. Under the hood, it +will execute tf destroy locally, and tf state storage is protected and accessible only by the owner. -This command deletes all configuration generated by the create command. -If executed with the --destroy-resources flag, it will also destroy all the resources created for the specific workload. This operation is irreversible. It should ONLY be executed by the cluster owner. +> **NOTE!**: This operation is **irreversible**. # Command Arguments: -| Name (short, full) | Type | Description -| --- | --- | --- -| -wl, --workload-names | TEXT | Workload name(s), can be multiple | -| --all | Flag | Flag to destroy all existing workloads -| -wldr, --destroy-resources | Flag | Flag to destroy workload resources -| -wlgrn, --workload-gitops-repository-name | TEXT | Workload GitOps repository name -| --verbosity | [DEBUG, INFO, WARNING, ERROR, CRITICAL] | Logging verbosity level, default CRITICAL +| Name (short, full) | Type | Description | +|-------------------------------------------|-----------------------------------------|-------------------------------------------| +| -wl, --workload-names | TEXT | Workload name(s), can be multiple | +| --all | Flag | Flag to destroy all existing workloads | +| -wldr, --destroy-resources | Flag | Flag to destroy workload resources | +| -wlgrn, --workload-gitops-repository-name | TEXT | Workload GitOps repository name | +| --verbosity | [DEBUG, INFO, WARNING, ERROR, CRITICAL] | Logging verbosity level, default CRITICAL | Note: This process is irreversible. From c414990bc87916f02acb7eb5e3f3167a9acf1bdf Mon Sep 17 00:00:00 2001 From: Alexander Ulyanov Date: Wed, 5 Jun 2024 18:38:01 +0200 Subject: [PATCH 13/13] docs: post review documentation fixes --- CONTRIBUTING.md | 2 +- tools/cli/commands/README.md | 18 +++++++++++++++++- 2 files changed, 18 insertions(+), 2 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index d591a803..a78b3de1 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -30,7 +30,7 @@ participating, you are expected to uphold this code. ### Reporting Bugs This section guides you through submitting a bug report. -BTo submit a bug report, first verify that your issue hasn't been addressed by checking the list below. This helps avoid duplicate reports. +To submit a bug report, first verify that your issue hasn't been addressed by checking the list below. This helps avoid duplicate reports. > Note: If you find a Closed issue that seems like it is the same thing that you're experiencing, open a new issue and > include a link to the original issue in the body of your new one. diff --git a/tools/cli/commands/README.md b/tools/cli/commands/README.md index ceb48eb2..6f465354 100644 --- a/tools/cli/commands/README.md +++ b/tools/cli/commands/README.md @@ -57,7 +57,7 @@ for checkpointing, allowing the command to be rerun if necessary. ```bash cgdevxcli setup --email user@cgdevx.io \ --cloud-provider aws \ - --cloud-profile your-profile-name \ + --cloud-profile your-aws-cli-profile-name \ --cluster-name cluster-name \ --dns-registrar route53 \ --domain-name example.com \ @@ -73,6 +73,22 @@ Using a parameter file: cgdevxcli setup -f path/to/your/parameters.yaml ``` +`parameters.yaml` file example + +```yaml +email: user@cgdevx.io +cloud-provider: aws +cloud-profile: your-aws-cli-profile-name +cloud-region: eu-west-1 +cluster-name: cluster-name +dns-registrar: route53 +domain-name: example.com +git-provider: github +git-org: acmeinc +git-access-token: ghp_xxx +gitops-repo-name: gitops-repo-name +``` + ### Troubleshooting Installation of a reference architecture is a complex process depending on multiple factors, e.g., cloud resource