From 57f79f806c75afedf6157a65897fad7e47af21cf Mon Sep 17 00:00:00 2001 From: edp-bot Date: Mon, 4 Mar 2024 11:51:52 +0000 Subject: [PATCH] Update documentation --- 404.html | 2 +- compliance/index.html | 2 +- .../annotations-and-labels/index.html | 2 +- developer-guide/autotest-coverage/index.html | 2 +- .../aws-deployment-diagram/index.html | 2 +- .../aws-reference-architecture/index.html | 2 +- developer-guide/edp-workflow/index.html | 2 +- developer-guide/index.html | 2 +- .../kubernetes-deployment/index.html | 2 +- developer-guide/local-development/index.html | 2 +- .../mk-docs-development/index.html | 2 +- .../reference-architecture/index.html | 2 +- .../reference-cicd-pipeline/index.html | 2 +- developer-guide/telemetry/index.html | 2 +- faq/index.html | 2 +- features/index.html | 2 +- glossary/index.html | 2 +- index.html | 2 +- operator-guide/add-ons-overview/index.html | 2 +- .../advanced-installation-overview/index.html | 2 +- operator-guide/argocd-integration/index.html | 2 +- .../artifacts-verification/index.html | 2 +- .../aws-marketplace-install/index.html | 2 +- operator-guide/capsule/index.html | 2 +- .../configure-keycloak-oidc-eks/index.html | 2 +- .../container-registries/index.html | 2 +- .../index.html | 2 +- operator-guide/delete-edp/index.html | 2 +- operator-guide/dependency-track/index.html | 2 +- operator-guide/deploy-aws-eks/index.html | 2 +- operator-guide/deploy-okd-4.10/index.html | 2 +- operator-guide/deploy-okd/index.html | 2 +- operator-guide/ebs-csi-driver/index.html | 2 +- operator-guide/edp-access-model/index.html | 2 +- operator-guide/edp-kiosk-usage/index.html | 2 +- .../eks-oidc-integration/index.html | 2 +- operator-guide/enable-irsa/index.html | 2 +- .../index.html | 2 +- .../github-debug-webhooks/index.html | 2 +- .../gitlab-debug-webhooks/index.html | 2 +- operator-guide/harbor-oidc/index.html | 2 +- operator-guide/headlamp-oidc/index.html | 2 +- .../import-strategy-tekton/index.html | 2 +- operator-guide/index.html | 2 +- operator-guide/install-argocd/index.html | 2 +- operator-guide/install-defectdojo/index.html | 2 +- operator-guide/install-edp/index.html | 2 +- .../index.html | 2 +- operator-guide/install-harbor/index.html | 2 +- .../install-ingress-nginx/index.html | 2 +- operator-guide/install-keycloak/index.html | 2 +- operator-guide/install-kiosk/index.html | 2 +- operator-guide/install-loki/index.html | 2 +- .../install-reportportal/index.html | 2 +- operator-guide/install-tekton/index.html | 2 +- operator-guide/install-velero/index.html | 2 +- operator-guide/install-via-civo/index.html | 2 +- .../install-via-helmfile/index.html | 2 +- .../installation-overview/index.html | 2 +- .../jira-gerrit-integration/index.html | 2 +- operator-guide/jira-integration/index.html | 2 +- operator-guide/kaniko-irsa/index.html | 2 +- operator-guide/kibana-ilm-rollover/index.html | 2 +- .../kubernetes-cluster-settings/index.html | 2 +- .../logsight-integration/index.html | 2 +- operator-guide/loki-irsa/index.html | 2 +- .../manage-custom-certificate/index.html | 2 +- .../index.html | 2 +- operator-guide/multitenant-logging/index.html | 2 +- .../namespace-management/index.html | 2 +- operator-guide/nexus-sonatype/index.html | 2 +- .../notification-msteams/index.html | 2 +- operator-guide/oauth2-proxy/index.html | 2 +- .../openshift-cluster-settings/index.html | 2 +- operator-guide/overview-devsecops/index.html | 2 +- .../overview-multi-tenancy/index.html | 2 +- operator-guide/overview-sast/index.html | 2 +- operator-guide/prerequisites/index.html | 2 +- .../index.html | 2 +- .../reportportal-keycloak/index.html | 2 +- .../restore-edp-with-velero/index.html | 2 +- .../schedule-pods-restart/index.html | 2 +- operator-guide/sonarqube/index.html | 2 +- operator-guide/ssl-automation-okd/index.html | 2 +- operator-guide/tekton-monitoring/index.html | 2 +- operator-guide/tekton-overview/index.html | 2 +- operator-guide/upgrade-edp-3.0/index.html | 2 +- operator-guide/upgrade-edp-3.1/index.html | 2 +- operator-guide/upgrade-edp-3.2/index.html | 2 +- operator-guide/upgrade-edp-3.3/index.html | 2 +- operator-guide/upgrade-edp-3.4/index.html | 2 +- operator-guide/upgrade-edp-3.5/index.html | 2 +- operator-guide/upgrade-edp-3.6/index.html | 2 +- operator-guide/upgrade-edp-3.7/index.html | 2 +- .../upgrade-keycloak-19.0/index.html | 2 +- operator-guide/vcs/index.html | 2 +- operator-guide/velero-irsa/index.html | 2 +- .../waf-tf-configuration/index.html | 2 +- overview/index.html | 2 +- pricing/index.html | 2 +- quick-start/create-application/index.html | 20 +- quick-start/deploy-application/index.html | 2 +- quick-start/integrate-argocd/index.html | 2 +- .../integrate-container-registry/index.html | 2 +- quick-start/integrate-github/index.html | 2 +- quick-start/integrate-sonarcloud/index.html | 2 +- quick-start/platform-installation/index.html | 4 +- quick-start/quick-start-overview/index.html | 2 + roadmap/index.html | 2 +- search/search_index.json | 2 +- sitemap.xml | 295 +++++++++--------- sitemap.xml.gz | Bin 1472 -> 1476 bytes supported-versions/index.html | 2 +- use-cases/application-scaffolding/index.html | 2 +- use-cases/autotest-as-quality-gate/index.html | 2 +- use-cases/external-secrets/index.html | 2 +- use-cases/index.html | 2 +- use-cases/tekton-custom-pipelines/index.html | 2 +- user-guide/add-application/index.html | 2 +- user-guide/add-autotest/index.html | 2 +- user-guide/add-cd-pipeline/index.html | 2 +- user-guide/add-cluster/index.html | 2 +- user-guide/add-git-server/index.html | 2 +- user-guide/add-infrastructure/index.html | 2 +- user-guide/add-library/index.html | 2 +- user-guide/add-marketplace/index.html | 2 +- user-guide/add-quality-gate/index.html | 2 +- user-guide/application/index.html | 2 +- user-guide/autotest/index.html | 2 +- user-guide/build-pipeline/index.html | 2 +- user-guide/cd-pipeline-details/index.html | 2 +- user-guide/ci-pipeline-details/index.html | 2 +- user-guide/cicd-overview/index.html | 2 +- user-guide/cluster/index.html | 2 +- user-guide/code-review-pipeline/index.html | 2 +- user-guide/components/index.html | 2 +- user-guide/configuration-overview/index.html | 2 +- user-guide/git-server-overview/index.html | 2 +- user-guide/gitops/index.html | 2 +- user-guide/index.html | 2 +- user-guide/infrastructure/index.html | 2 +- user-guide/library/index.html | 2 +- user-guide/manage-branches/index.html | 2 +- .../manage-container-registries/index.html | 2 +- user-guide/manage-environments/index.html | 2 +- user-guide/marketplace/index.html | 2 +- user-guide/opa-stages/index.html | 2 +- user-guide/prepare-for-release/index.html | 2 +- user-guide/quick-links/index.html | 2 +- user-guide/terraform-stages/index.html | 2 +- 150 files changed, 315 insertions(+), 296 deletions(-) create mode 100644 quick-start/quick-start-overview/index.html diff --git a/404.html b/404.html index fa545b575..8f09f38b4 100644 --- a/404.html +++ b/404.html @@ -1 +1 @@ - EPAM Delivery Platform

404 - Not found

\ No newline at end of file + EPAM Delivery Platform

404 - Not found

\ No newline at end of file diff --git a/compliance/index.html b/compliance/index.html index 086e74d2a..ea5f4f5d1 100644 --- a/compliance/index.html +++ b/compliance/index.html @@ -1 +1 @@ - Compliance - EPAM Delivery Platform
Skip to content

Compliance⚓︎

The integrity of your deployments is our paramount commitment. We are devoted to strengthening our Kubernetes platform to comply with the most stringent security standards. Trust is the bedrock of our relationships, and we manifest this commitment by undergoing rigorous third-party audits to ensure compliance. We pledge unwavering support as you manage and deploy solutions within your environment, emphasizing security and reliability. Examine our compliance with various frameworks, laws, and regulations to understand our dedication to upholding robust security standards for the solutions you manage and deploy.

the EDP Badge

\ No newline at end of file + Compliance - EPAM Delivery Platform
Skip to content

Compliance⚓︎

The integrity of your deployments is our paramount commitment. We are devoted to strengthening our Kubernetes platform to comply with the most stringent security standards. Trust is the bedrock of our relationships, and we manifest this commitment by undergoing rigorous third-party audits to ensure compliance. We pledge unwavering support as you manage and deploy solutions within your environment, emphasizing security and reliability. Examine our compliance with various frameworks, laws, and regulations to understand our dedication to upholding robust security standards for the solutions you manage and deploy.

the EDP Badge

\ No newline at end of file diff --git a/developer-guide/annotations-and-labels/index.html b/developer-guide/annotations-and-labels/index.html index dcbe6cc9d..cf5ba93fe 100644 --- a/developer-guide/annotations-and-labels/index.html +++ b/developer-guide/annotations-and-labels/index.html @@ -1,4 +1,4 @@ - Annotations and Labels - EPAM Delivery Platform
Skip to content

Annotations and Labels⚓︎

EPAM Delivery Platform uses labels to interact with various resources in a Kubernetes cluster. This guide details the resources, annotations, and labels used by the platform to streamline operations, enhance monitoring, and enforce governance.

Labels⚓︎

The table below contains all the labels used in EDP:

Label Key Target Resources Possible Values Description
app.edp.epam.com/secret-type Secrets jira, nexus, sonar, defectdojo, dependency-track,repository Identifies the type of the secret.
app.edp.epam.com/integration-secret Secrets true Indicates if the secret is used for integration.
app.edp.epam.com/codebase PipelineRun <codebase_name> Identifies the codebase associated with the PipelineRun.
app.edp.epam.com/codebasebranch PipelineRun <codebase_name>-<branch_name> Identifies the codebase branch associated with the PipelineRun.
app.edp.epam.com/pipeline PipelineRun, Taskrun <environment_name> Used by the EDP Portal to display autotests status(on Deploy environment)
app.edp.epam.com/pipelinetype PipelineRun, Taskrun autotestRunner, build, review Identifies the type of the Pipeline.
app.edp.epam.com/parentPipelineRun PipelineRun <cd-pipeline-autotest-runner-name> Used by the EDP Portal to display autotests status(on Deploy environment)
app.edp.epam.com/stage PipelineRun, Taskrun <stage_name> Used by the EDP Portal to display autotests status(on Deploy environment)
app.edp.epam.com/branch PipelineRun <branch_name> Identifies the branch associated with the PipelineRun.
app.edp.epam.com/codebaseType Codebase system,application Identify the type of the codebase.
app.edp.epam.com/systemType Codebase gitops Identify system repositories.
app.edp.epam.com/gitServer Ingress <gitServer_name> Identifies the ingress associated with the GitServer.

Labels Usage in Secrets⚓︎

The table below shows what labels are used by specific secrets:

Secret Name Labels
ci-argocd app.edp.epam.com/integration-secret=true
app.edp.epam.com/secret-type=argocd
ci-defectdojo app.edp.epam.com/integration-secret=true
app.edp.epam.com/secret-type=defectdojo
ci-dependency-track app.edp.epam.com/integration-secret=true
app.edp.epam.com/secret-type=dependency-track
ci-jira app.edp.epam.com/secret-type=jira
ci-nexus app.edp.epam.com/integration-secret=true
app.edp.epam.com/secret-type=nexus
ci-sonarqube app.edp.epam.com/integration-secret=true
app.edp.epam.com/secret-type=sonar
gerrit-ciuser-sshkey app.edp.epam.com/secret-type=repository
kaniko-docker-config app.edp.epam.com/integration-secret=true
app.edp.epam.com/secret-type=registry
regcred app.edp.epam.com/integration-secret=true
app.edp.epam.com/secret-type=registry

Labels Usage in Tekton Pipeline Runs⚓︎

The table below displays what labels are used in specific Tekton pipelines:

PipelineRun Labels
review-pipeline app.edp.epam.com/codebase: <codebase_name>
app.edp.epam.com/codebasebranch: <codebase_name>-<branch_name>
app.edp.epam.com/pipelinetype: review
build-pipeline app.edp.epam.com/codebase: <codebase_name>
app.edp.epam.com/codebasebranch: <codebase_name>-<branch_name>
app.edp.epam.com/pipelinetype: build
autotest-runner-pipeline app.edp.epam.com/pipeline: <pipeline_name>
app.edp.epam.com/pipelinetype: autotestRunner
app.edp.epam.com/stage: <stage>
autotest-pipeline app.edp.epam.com/branch: <branch>
app.edp.epam.com/codebase: <codebase_name>
app.edp.epam.com/parentPipelineRun: <cd_pipeline>-<stage>
app.edp.epam.com/pipeline: <cd_pipeline>
app.edp.epam.com/stage: <stage>

Pipeline Usage Example⚓︎

To demonstrate label usage in the EDP Tekton pipelines, find below some EDP resource examples:

Codebase specification
metadata:
+ Annotations and Labels - EPAM Delivery Platform      
  
 
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
 
Annotations and Labels⚓︎
 
EPAM Delivery Platform uses labels to interact with various resources in a Kubernetes cluster. This guide details the resources, annotations, and labels used by the platform to streamline operations, enhance monitoring, and enforce governance.
 
Labels⚓︎
 
The table below contains all the labels used in EDP:
 
  
 Label Key Target Resources Possible Values Description 
   
 app.edp.epam.com/secret-type Secrets jira, nexus, sonar, defectdojo, dependency-track,repository Identifies the type of the secret. 
 
 app.edp.epam.com/integration-secret Secrets true Indicates if the secret is used for integration. 
 
 app.edp.epam.com/codebase PipelineRun <codebase_name> Identifies the codebase associated with the PipelineRun. 
 
 app.edp.epam.com/codebasebranch PipelineRun <codebase_name>-<branch_name> Identifies the codebase branch associated with the PipelineRun. 
 
 app.edp.epam.com/pipeline PipelineRun, Taskrun <environment_name> Used by the EDP Portal to display autotests status(on Deploy environment) 
 
 app.edp.epam.com/pipelinetype PipelineRun, Taskrun autotestRunner, build, review Identifies the type of the Pipeline. 
 
 app.edp.epam.com/parentPipelineRun PipelineRun <cd-pipeline-autotest-runner-name> Used by the EDP Portal to display autotests status(on Deploy environment) 
 
 app.edp.epam.com/stage PipelineRun, Taskrun <stage_name> Used by the EDP Portal to display autotests status(on Deploy environment) 
 
 app.edp.epam.com/branch PipelineRun <branch_name> Identifies the branch associated with the PipelineRun. 
 
 app.edp.epam.com/codebaseType Codebase system,application Identify the type of the codebase. 
 
 app.edp.epam.com/systemType Codebase gitops Identify system repositories. 
 
 app.edp.epam.com/gitServer Ingress <gitServer_name> Identifies the ingress associated with the GitServer. 
  
 
Labels Usage in Secrets⚓︎
 
The table below shows what labels are used by specific secrets:
 
  
 Secret Name Labels 
   
 ci-argocd app.edp.epam.com/integration-secret=true
 app.edp.epam.com/secret-type=argocd		 
 
 ci-defectdojo app.edp.epam.com/integration-secret=true
 app.edp.epam.com/secret-type=defectdojo		 
 
 ci-dependency-track app.edp.epam.com/integration-secret=true
 app.edp.epam.com/secret-type=dependency-track		 
 
 ci-jira app.edp.epam.com/secret-type=jira 
 
 ci-nexus app.edp.epam.com/integration-secret=true
 app.edp.epam.com/secret-type=nexus		 
 
 ci-sonarqube app.edp.epam.com/integration-secret=true
 app.edp.epam.com/secret-type=sonar		 
 
 gerrit-ciuser-sshkey app.edp.epam.com/secret-type=repository 
 
 kaniko-docker-config app.edp.epam.com/integration-secret=true
 app.edp.epam.com/secret-type=registry		 
 
 regcred app.edp.epam.com/integration-secret=true
 app.edp.epam.com/secret-type=registry		 
  
 
Labels Usage in Tekton Pipeline Runs⚓︎
 
The table below displays what labels are used in specific Tekton pipelines:
 
  
 PipelineRun Labels 
   
 review-pipeline app.edp.epam.com/codebase: <codebase_name> 
 app.edp.epam.com/codebasebranch: <codebase_name>-<branch_name>
 app.edp.epam.com/pipelinetype: review		 
 
 build-pipeline app.edp.epam.com/codebase: <codebase_name> 
 app.edp.epam.com/codebasebranch: <codebase_name>-<branch_name>
 app.edp.epam.com/pipelinetype: build		 
 
 autotest-runner-pipeline app.edp.epam.com/pipeline: <pipeline_name>
 app.edp.epam.com/pipelinetype: autotestRunner 
 app.edp.epam.com/stage: <stage>		 
 
 autotest-pipeline app.edp.epam.com/branch: <branch>
 app.edp.epam.com/codebase: <codebase_name>
 app.edp.epam.com/parentPipelineRun: <cd_pipeline>-<stage>
 app.edp.epam.com/pipeline: <cd_pipeline>
 app.edp.epam.com/stage: <stage>		 
  
 
Pipeline Usage Example⚓︎
 
To demonstrate label usage in the EDP Tekton pipelines, find below some EDP resource examples:
 
Codebase specification
metadata:
   ...
   name: demo
   ...
diff --git a/developer-guide/autotest-coverage/index.html b/developer-guide/autotest-coverage/index.html
index 4954236ef..69989c6f2 100644
--- a/developer-guide/autotest-coverage/index.html
+++ b/developer-guide/autotest-coverage/index.html
@@ -1 +1 @@
- Quality Control - EPAM Delivery Platform      
  
 
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
 
Quality Control⚓︎
 
In EPAM Delivery Platform, we guarantee the quality of the product not only by using the most advanced tools and best practices but also by covering the whole product functionality with our dedicated automated tests.
 
Autotest Coverage Scheme⚓︎
 
Autotests are significant part of our verification flow. Continuous improvement of the verification mechanisms quality is performed to provide users with the most stable version of the platform.
 
The autotest coverage status is presented on the scheme below:
 
 
Autotest coverage status
Autotest coverage status
 
 
 
Release Testing⚓︎
 
In our testing flow, each release is verified by the following tests:
 
  
 Test Group Description What's Covered 
   
 API Tests Tekton Gerrit, GitHub, and GitLab API long regression Codebase provisioning, reviewing and building pipelines, adding new branches, deploying applications (in a custom namespace), Jira integration, and rechecking for review pipeline. 
 
 UI Tests Tekton Gerrit, GitHub, and GitLab UI long regression Codebase provisioning, reviewing and building pipelines, adding new branches, deploying applications (in a custom namespace), Jira integration, and rechecking for review pipeline. 
 
 Short Tests Tekton Gerrit , GitHub, and GitLab API short regression Codebase provisioning, reviewing and building pipelines, deploying applications (in a custom namespace), rechecking for review pipeline 
 
 Smoke Tekton Gerrit Smoke Codebase provisioning, reviewing and building pipelines, deploying applications. 
  
  
   
 
  
  
  
 
 
 
          
\ No newline at end of file
+ Quality Control - EPAM Delivery Platform      
  
 
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
 
Quality Control⚓︎
 
In EPAM Delivery Platform, we guarantee the quality of the product not only by using the most advanced tools and best practices but also by covering the whole product functionality with our dedicated automated tests.
 
Autotest Coverage Scheme⚓︎
 
Autotests are significant part of our verification flow. Continuous improvement of the verification mechanisms quality is performed to provide users with the most stable version of the platform.
 
The autotest coverage status is presented on the scheme below:
 
 
Autotest coverage status
Autotest coverage status
 
 
 
Release Testing⚓︎
 
In our testing flow, each release is verified by the following tests:
 
  
 Test Group Description What's Covered 
   
 API Tests Tekton Gerrit, GitHub, and GitLab API long regression Codebase provisioning, reviewing and building pipelines, adding new branches, deploying applications (in a custom namespace), Jira integration, and rechecking for review pipeline. 
 
 UI Tests Tekton Gerrit, GitHub, and GitLab UI long regression Codebase provisioning, reviewing and building pipelines, adding new branches, deploying applications (in a custom namespace), Jira integration, and rechecking for review pipeline. 
 
 Short Tests Tekton Gerrit , GitHub, and GitLab API short regression Codebase provisioning, reviewing and building pipelines, deploying applications (in a custom namespace), rechecking for review pipeline 
 
 Smoke Tekton Gerrit Smoke Codebase provisioning, reviewing and building pipelines, deploying applications. 
  
  
   
 
  
  
  
 
 
 
          
\ No newline at end of file
diff --git a/developer-guide/aws-deployment-diagram/index.html b/developer-guide/aws-deployment-diagram/index.html
index 60f787b9d..830d1bf96 100644
--- a/developer-guide/aws-deployment-diagram/index.html
+++ b/developer-guide/aws-deployment-diagram/index.html
@@ -1 +1 @@
- EDP Deployment on AWS - EPAM Delivery Platform      
  
 
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
 
EDP Deployment on AWS⚓︎
 
This document describes the EPAM Delivery Platform (EDP) deployment architecture on AWS. It utilizes various AWS services such as Amazon Elastic Kubernetes Service (EKS), Amazon EC2, Amazon Route 53, and others to build and deploy software in a repeatable, automated way.
 
Overview⚓︎
 
The EDP deployment architecture consists of two AWS accounts: Shared and Explorer. The Shared account hosts shared services, while the Explorer account runs the development team workload and EDP services. Both accounts have an AWS EKS cluster deployed in multiple Availability Zones (AZs). The EKS cluster runs the EDP Services, development team workload, and shared services in the case of the Shared account.
 
 
EPAM Delivery Platform Deployment Diagram on AWS
EPAM Delivery Platform Deployment Diagram on AWS
 
 
 
Key Components⚓︎
 
     
  1. AWS Elastic Kubernetes Service (EKS): A managed Kubernetes service used to run the EDP Services, development team workload, and shared services. EKS provides easy deployment and management of Kubernetes clusters.
    2.  
  2. Amazon EC2: Instances running within private subnets that serve as nodes for the EKS cluster. Autoscaling Groups are used to deploy these instances, allowing for scalability based on demand.
    3.  
  3. Amazon Route 53: A DNS web service manages external and internal DNS records for the EDP deployment. It enables easy access to resources using user-friendly domain names.
    4.  
  4. AWS Application Load Balancer (ALB): Used for managing ingress traffic into the EDP deployment. Depending on requirements, ALBs can be configured as internal or external load balancers.
    5.  
  5. AWS WAF: Web Application Firewall service used to protect external ALBs from common web exploits by filtering malicious requests.
    6.  
  6. AWS Certificate Manager (ACM): A service that provisions manages, and deploys SSL/TLS certificates for use with AWS services. ACM is used to manage SSL certificates for secure communication within the EDP deployment.
    7.  
  7. AWS Elastic Container Registry (ECR): A fully-managed Docker container registry that stores and manages Docker images. ECR provides a secure and scalable solution for storing container images used in the EDP deployment.
    8.  
  8. AWS Systems Manager Parameter Store: Used to securely store and manage secrets required by various components of the EDP deployment. Parameter Store protects sensitive information such as API keys, database credentials, and other secrets.
    9.  
 
High Availability and Fault Tolerance⚓︎
 
The EKS cluster is deployed across multiple AZs to ensure high availability and fault tolerance. This allows for automatic failover in case of an AZ outage or instance failure. Autoscaling Groups automatically adjust the number of EC2 instances based on demand, ensuring scalability while maintaining availability.
 
Design Considerations⚓︎
 
Reliability⚓︎
 
     
  • Using multiple AZs ensures high availability and fault tolerance for the EKS cluster.
    •  
  • Autoscaling Groups enable automatic scaling of EC2 instances based on demand, providing reliability during peak loads.
    •  
  • Multiple NAT gateways are deployed in each AZ to ensure reliable outbound internet connectivity.
    •  
 
Performance Efficiency⚓︎
 
     
  • Utilizing AWS EKS allows for efficient management of Kubernetes clusters without the need for manual configuration or maintenance.
    •  
  • Spot instances can be utilized alongside on-demand instances within the EKS cluster to optimize costs while maintaining performance requirements.
    •  
  • Amazon Route 53 enables efficient DNS resolution by managing external and internal DNS records.
    •  
 
Security⚓︎
 
     
  • External ALBs are protected using AWS WAF, which filters out malicious traffic and protects against common web exploits.
    •  
  • ACM is used to provision SSL/TLS certificates, ensuring secure communication within the EDP deployment.
    •  
  • Secrets required by various components are securely stored and managed using the AWS Systems Manager Parameter Store.
    •  
 
Cost Optimization⚓︎
 
     
  • Utilizing spot and on-demand instances within the EKS cluster can significantly reduce costs while maintaining performance requirements.
    •  
  • Autoscaling Groups allow for automatic scaling of EC2 instances based on demand, ensuring optimal resource utilization and cost efficiency.
    •  
 
Conclusion⚓︎
 
The EPAM Delivery Platform (EDP) deployment architecture on AWS follows best practices and patterns from the Well-Architected Framework. By leveraging AWS services such as EKS, EC2, Route 53, ALB, WAF, ACM, and Parameter Store, the EDP provides a robust and scalable CI/CD system that enables developers to deploy and manage infrastructure and applications quickly. The architecture ensures high availability, fault tolerance, reliability, performance efficiency, security, and cost optimization for the EDP deployment.
   
 
  
  
  
 
 
 
          
\ No newline at end of file
+ EDP Deployment on AWS - EPAM Delivery Platform      
  
 
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
 
EDP Deployment on AWS⚓︎
 
This document describes the EPAM Delivery Platform (EDP) deployment architecture on AWS. It utilizes various AWS services such as Amazon Elastic Kubernetes Service (EKS), Amazon EC2, Amazon Route 53, and others to build and deploy software in a repeatable, automated way.
 
Overview⚓︎
 
The EDP deployment architecture consists of two AWS accounts: Shared and Explorer. The Shared account hosts shared services, while the Explorer account runs the development team workload and EDP services. Both accounts have an AWS EKS cluster deployed in multiple Availability Zones (AZs). The EKS cluster runs the EDP Services, development team workload, and shared services in the case of the Shared account.
 
 
EPAM Delivery Platform Deployment Diagram on AWS
EPAM Delivery Platform Deployment Diagram on AWS
 
 
 
Key Components⚓︎
 
     
  1. AWS Elastic Kubernetes Service (EKS): A managed Kubernetes service used to run the EDP Services, development team workload, and shared services. EKS provides easy deployment and management of Kubernetes clusters.
    2.  
  2. Amazon EC2: Instances running within private subnets that serve as nodes for the EKS cluster. Autoscaling Groups are used to deploy these instances, allowing for scalability based on demand.
    3.  
  3. Amazon Route 53: A DNS web service manages external and internal DNS records for the EDP deployment. It enables easy access to resources using user-friendly domain names.
    4.  
  4. AWS Application Load Balancer (ALB): Used for managing ingress traffic into the EDP deployment. Depending on requirements, ALBs can be configured as internal or external load balancers.
    5.  
  5. AWS WAF: Web Application Firewall service used to protect external ALBs from common web exploits by filtering malicious requests.
    6.  
  6. AWS Certificate Manager (ACM): A service that provisions manages, and deploys SSL/TLS certificates for use with AWS services. ACM is used to manage SSL certificates for secure communication within the EDP deployment.
    7.  
  7. AWS Elastic Container Registry (ECR): A fully-managed Docker container registry that stores and manages Docker images. ECR provides a secure and scalable solution for storing container images used in the EDP deployment.
    8.  
  8. AWS Systems Manager Parameter Store: Used to securely store and manage secrets required by various components of the EDP deployment. Parameter Store protects sensitive information such as API keys, database credentials, and other secrets.
    9.  
 
High Availability and Fault Tolerance⚓︎
 
The EKS cluster is deployed across multiple AZs to ensure high availability and fault tolerance. This allows for automatic failover in case of an AZ outage or instance failure. Autoscaling Groups automatically adjust the number of EC2 instances based on demand, ensuring scalability while maintaining availability.
 
Design Considerations⚓︎
 
Reliability⚓︎
 
     
  • Using multiple AZs ensures high availability and fault tolerance for the EKS cluster.
    •  
  • Autoscaling Groups enable automatic scaling of EC2 instances based on demand, providing reliability during peak loads.
    •  
  • Multiple NAT gateways are deployed in each AZ to ensure reliable outbound internet connectivity.
    •  
 
Performance Efficiency⚓︎
 
     
  • Utilizing AWS EKS allows for efficient management of Kubernetes clusters without the need for manual configuration or maintenance.
    •  
  • Spot instances can be utilized alongside on-demand instances within the EKS cluster to optimize costs while maintaining performance requirements.
    •  
  • Amazon Route 53 enables efficient DNS resolution by managing external and internal DNS records.
    •  
 
Security⚓︎
 
     
  • External ALBs are protected using AWS WAF, which filters out malicious traffic and protects against common web exploits.
    •  
  • ACM is used to provision SSL/TLS certificates, ensuring secure communication within the EDP deployment.
    •  
  • Secrets required by various components are securely stored and managed using the AWS Systems Manager Parameter Store.
    •  
 
Cost Optimization⚓︎
 
     
  • Utilizing spot and on-demand instances within the EKS cluster can significantly reduce costs while maintaining performance requirements.
    •  
  • Autoscaling Groups allow for automatic scaling of EC2 instances based on demand, ensuring optimal resource utilization and cost efficiency.
    •  
 
Conclusion⚓︎
 
The EPAM Delivery Platform (EDP) deployment architecture on AWS follows best practices and patterns from the Well-Architected Framework. By leveraging AWS services such as EKS, EC2, Route 53, ALB, WAF, ACM, and Parameter Store, the EDP provides a robust and scalable CI/CD system that enables developers to deploy and manage infrastructure and applications quickly. The architecture ensures high availability, fault tolerance, reliability, performance efficiency, security, and cost optimization for the EDP deployment.
   
 
  
  
  
 
 
 
          
\ No newline at end of file
diff --git a/developer-guide/aws-reference-architecture/index.html b/developer-guide/aws-reference-architecture/index.html
index b2f442d9c..c1a90d510 100644
--- a/developer-guide/aws-reference-architecture/index.html
+++ b/developer-guide/aws-reference-architecture/index.html
@@ -1 +1 @@
- EDP Reference Architecture on AWS - EPAM Delivery Platform      
  
 
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
 
EDP Reference Architecture on AWS⚓︎
 
The reference architecture of the EPAM Delivery Platform (EDP) on AWS is designed to provide a robust and scalable CI/CD system for developing and deploying software in a repeatable and automated manner. The architecture leverages AWS Managed Services to enable developers to quickly deploy and manage infrastructure and applications. EDP recommends to follow the best practices and patterns from the Well-Architected Framework, the AWS Architecture Center, and EKS Best Practices Guide.
 
Architecture Details⚓︎
 
The AWS Cloud comprises three accounts: Production, Shared, and Development.
 
 
Note
 
AWS Account management is out of scope for this document.
 
 
Each account serves specific purposes:
 
     
  • The Production account is used to host production workloads. The Production account serves as the final destination for deploying business applications. It maintains a separate ECR registry to store Docker images for production-level applications. The environment is designed to be highly resilient and scalable, leveraging the EPAM Delivery Platform's CI/CD pipeline to ensure consistent and automated deployments. With proper access control and separation from development environments, the Production account provides a stable and secure environment for running mission-critical applications.
    •  
  • The Development account is dedicated to development workload and lower environments. This account hosts the EDP itself, running on AWS EKS. It provides developers an isolated environment to build, test, and deploy their applications in lower environments, ensuring separation from production workloads. Developers can connect to the AWS Cloud using a VPN, enforcing secure access.
    •  
  • The Shared holds shared services that are accessible to all accounts within the organization. These services include SonarQube, Nexus, and Keycloak, which are deployed in Kubernetes Clusters managed by AWS Elastic Kubernetes Service (EKS). The shared services leverage AWS RDS, AWS EFS, and AWS ALB/NLB. The deployment of the shared services is automated using Kubernetes cluster-addons approach with GitOps and Argo CD.
    •  
 
 
EPAM Delivery Platform Reference Architecture on AWS
EPAM Delivery Platform Reference Architecture on AWS
 
 
 
Infrastructure as Code⚓︎
 
Infrastructure as Code (IaC) is a key principle in the EPAM Delivery Platform architecture. Terraform is the IaC tool to provision and manage all services in each account. AWS S3 and AWS DynamoDB serve as the backend for Terraform state, ensuring consistency and reliability in the deployment process. This approach enables the architecture to be version-controlled and allows for easy replication and reproducibility of environments.
 
Docker Registry⚓︎
 
The architecture utilizes AWS Elastic Container Registry (ECR) as a Docker Registry for container image management. ECR offers a secure, scalable, and reliable solution for storing and managing container images. It integrates seamlessly with other AWS services and provides a highly available and durable storage solution for containers in the CI/CD pipeline.
 
IAM Roles for Service Accounts (IRSA)⚓︎
 
The EPAM Delivery Platform implements IAM Roles for Service Accounts (IRSA) to provide secure access to AWS services from Kubernetes Clusters. This feature enables fine-grained access control with individual Kubernetes pods assuming specific IAM roles for authenticated access to AWS resources. IRSA eliminates the need for managing and distributing access keys within the cluster, significantly enhancing security and reducing operational complexity.
 
SSL Certificates⚓︎
 
The architecture uses the AWS Certificate Manager (ACM) to secure communication between services to provide SSL certificates. ACM eliminates the need to manually manage SSL/TLS certificates, automating the renewal and deployment process. The EDP ensures secure and encrypted traffic within its environment by leveraging ACM.
 
AWS WAF⚓︎
 
The architecture's external Application Load Balancer (ALB) endpoint is protected by the AWS Web Application Firewall (WAF). WAF protects against common web exploits and ensures the security and availability of the applications hosted within the EDP. It offers regular rule updates and easy integration with other AWS services.
 
Parameter Store and Secrets Manager⚓︎
 
The architecture leverages the AWS Systems Manager Parameter Store and Secrets Manager to securely store and manage all secrets and parameters utilized within the EKS clusters—parameter Store stores general configuration information, such as database connection strings and API keys. In contrast, Secrets Manager securely stores sensitive information, such as passwords and access tokens. By centralizing secrets management, the architecture ensures proper access control and reduces the risk of unauthorized access.
 
Summary⚓︎
 
The reference architecture of the EPAM Delivery Platform on AWS provides a comprehensive and scalable environment for building and deploying software applications. With a strong focus on automation, security, and best practices, this architecture enables developers to leverage the full potential of AWS services while following industry-standard DevOps practices.
   
 
  
  
  
 
 
 
          
\ No newline at end of file
+ EDP Reference Architecture on AWS - EPAM Delivery Platform      
  
 
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
 
EDP Reference Architecture on AWS⚓︎
 
The reference architecture of the EPAM Delivery Platform (EDP) on AWS is designed to provide a robust and scalable CI/CD system for developing and deploying software in a repeatable and automated manner. The architecture leverages AWS Managed Services to enable developers to quickly deploy and manage infrastructure and applications. EDP recommends to follow the best practices and patterns from the Well-Architected Framework, the AWS Architecture Center, and EKS Best Practices Guide.
 
Architecture Details⚓︎
 
The AWS Cloud comprises three accounts: Production, Shared, and Development.
 
 
Note
 
AWS Account management is out of scope for this document.
 
 
Each account serves specific purposes:
 
     
  • The Production account is used to host production workloads. The Production account serves as the final destination for deploying business applications. It maintains a separate ECR registry to store Docker images for production-level applications. The environment is designed to be highly resilient and scalable, leveraging the EPAM Delivery Platform's CI/CD pipeline to ensure consistent and automated deployments. With proper access control and separation from development environments, the Production account provides a stable and secure environment for running mission-critical applications.
    •  
  • The Development account is dedicated to development workload and lower environments. This account hosts the EDP itself, running on AWS EKS. It provides developers an isolated environment to build, test, and deploy their applications in lower environments, ensuring separation from production workloads. Developers can connect to the AWS Cloud using a VPN, enforcing secure access.
    •  
  • The Shared holds shared services that are accessible to all accounts within the organization. These services include SonarQube, Nexus, and Keycloak, which are deployed in Kubernetes Clusters managed by AWS Elastic Kubernetes Service (EKS). The shared services leverage AWS RDS, AWS EFS, and AWS ALB/NLB. The deployment of the shared services is automated using Kubernetes cluster-addons approach with GitOps and Argo CD.
    •  
 
 
EPAM Delivery Platform Reference Architecture on AWS
EPAM Delivery Platform Reference Architecture on AWS
 
 
 
Infrastructure as Code⚓︎
 
Infrastructure as Code (IaC) is a key principle in the EPAM Delivery Platform architecture. Terraform is the IaC tool to provision and manage all services in each account. AWS S3 and AWS DynamoDB serve as the backend for Terraform state, ensuring consistency and reliability in the deployment process. This approach enables the architecture to be version-controlled and allows for easy replication and reproducibility of environments.
 
Docker Registry⚓︎
 
The architecture utilizes AWS Elastic Container Registry (ECR) as a Docker Registry for container image management. ECR offers a secure, scalable, and reliable solution for storing and managing container images. It integrates seamlessly with other AWS services and provides a highly available and durable storage solution for containers in the CI/CD pipeline.
 
IAM Roles for Service Accounts (IRSA)⚓︎
 
The EPAM Delivery Platform implements IAM Roles for Service Accounts (IRSA) to provide secure access to AWS services from Kubernetes Clusters. This feature enables fine-grained access control with individual Kubernetes pods assuming specific IAM roles for authenticated access to AWS resources. IRSA eliminates the need for managing and distributing access keys within the cluster, significantly enhancing security and reducing operational complexity.
 
SSL Certificates⚓︎
 
The architecture uses the AWS Certificate Manager (ACM) to secure communication between services to provide SSL certificates. ACM eliminates the need to manually manage SSL/TLS certificates, automating the renewal and deployment process. The EDP ensures secure and encrypted traffic within its environment by leveraging ACM.
 
AWS WAF⚓︎
 
The architecture's external Application Load Balancer (ALB) endpoint is protected by the AWS Web Application Firewall (WAF). WAF protects against common web exploits and ensures the security and availability of the applications hosted within the EDP. It offers regular rule updates and easy integration with other AWS services.
 
Parameter Store and Secrets Manager⚓︎
 
The architecture leverages the AWS Systems Manager Parameter Store and Secrets Manager to securely store and manage all secrets and parameters utilized within the EKS clusters—parameter Store stores general configuration information, such as database connection strings and API keys. In contrast, Secrets Manager securely stores sensitive information, such as passwords and access tokens. By centralizing secrets management, the architecture ensures proper access control and reduces the risk of unauthorized access.
 
Summary⚓︎
 
The reference architecture of the EPAM Delivery Platform on AWS provides a comprehensive and scalable environment for building and deploying software applications. With a strong focus on automation, security, and best practices, this architecture enables developers to leverage the full potential of AWS services while following industry-standard DevOps practices.
   
 
  
  
  
 
 
 
          
\ No newline at end of file
diff --git a/developer-guide/edp-workflow/index.html b/developer-guide/edp-workflow/index.html
index 28f6d3c99..c9923e5c9 100644
--- a/developer-guide/edp-workflow/index.html
+++ b/developer-guide/edp-workflow/index.html
@@ -1,4 +1,4 @@
- EDP Project Rules. Working Process - EPAM Delivery Platform      
  
 
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
 
EDP Project Rules. Working Process⚓︎
 
This page contains the details on the project rules and working process for EDP team and contributors. Explore the main points about working with Gerrit, following the main commit flow, as well as the details about commit types and message below.
 
Project Rules⚓︎
 
Before starting the development, please check the project rules:
 
     
  1.  
    It is highly recommended to become familiar with the Gerrit flow. For details, please refer to the Gerrit official documentation and pay attention to the main points:
     
    a. Voting in Gerrit.
     
    b. Resolution of Merge Conflict.
     
    c. Comments resolution.
     
    d. One Jira task should have one Merge Request (MR). If there are many changes within one MR, add the next patch set to the open MR by selecting the Amend commit check box.
     
    2.  
  2.  
    Only the Assignee is responsible for the MR merge and Jira task status.
     
    3.  
  3.  
    Every MR should be merged in a timely manner.
     
    4.  
  4.  
    Log time to Jira ticket.
     
    5.  
 
Working Process⚓︎
 
With EDP, the main workflow is based on the getting a Jira task and creating a Merge Request according to the rules described below.
 
 
Workflow
 
Get Jira task → implement, verify by yourself the results → create Merge Request (MR) → send for review → resolve comments/add changes, ask colleagues for the final review → track the MR merge → verify by yourself the results → change the status in the Jira ticket to CODE COMPLETE or RESOLVED → share necessary links with a QA specialist in the QA Verification channel → QA specialist closes the Jira task after his verification → Jira task should be CLOSED.
 
 
Commit Flow
 
     
  1.  
    Get a task in the Jira/GitHub dashboard. Please be aware of the following points:
     
     
     
     
    a. Every task has a reporter who can provide more details in case something is not clear.
     
    b. The responsible person for the task and code implementation is the assignee who tracks the following:
     
       
    • Actual Jira task status.
      •  
     
       
    • Time logging.
      •  
     
       
    • Add comments, attach necessary files.
      •  
     
       
    • In comments, add link that refers to the merged MR (optional, if not related to many repositories).
      •  
     
       
    • Code review and the final merge.
      •  
     
       
    • MS Teams chats - ping other colleagues, answer questions, etc.
      •  
     
       
    • Verification by a QA specialist.
      •  
     
       
    • Bug fixing.
      •  
     
    c. Pay attention to the task Status that differs in different entities, the workflow will help to see the whole task processing:
     
     
    View Jira workflow
    View Jira workflow
     
     
     
    d. There are several entities that are used on the EDP project: Story, Improvement, Task, Bug.
     
     
     
    a. Every task has a reporter who can provide more details in case something is not clear.
     
    b. The responsible person for the task and code implementation is the assignee who tracks the following:
     
       
    • Actual GitHub task status.
      •  
     
       
    • Add comments, attach necessary files.
      •  
     
       
    • In comments, add link that refers to the merged MR (optional, if not related to many repositories).
      •  
     
       
    • Code review and the final merge.
      •  
     
       
    • MS Teams chats - ping other colleagues, answer questions, etc.
      •  
     
       
    • Verification by a QA specialist.
      •  
     
       
    • Bug fixing.
      •  
     
    c. If the task is created on your own, make sure it is populated completely. See an example below:
     
     
    GitHub issue
    GitHub issue
     
     
     
     
     
     
    2.  
  2.  
    Implement feature, improvement, fix and check the results on your own. If it is impossible to check the results of your work before the merge, verify all later.
     
    3.  
  3.  
    Create a Merge Request, for details, please refer to the Code Review Process.
     
    4.  
  4.  
    When committing, use the pattern: commit type: Commit message (#GitHub ticket number).
     
    a. commit type:
     
    feat: (new feature for the user, not a new feature for build script)
     
    fix: (bug fix for the user, not a fix to a build script)
     
    docs: (changes to the documentation)
     
    style: (formatting, missing semicolons, etc; no production code change)
     
    refactor: (refactoring production code, eg. renaming a variable)
     
    test: (adding missing tests, refactoring tests; no production code change)
     
    chore: (updating grunt tasks etc; no production code change)
     
    !: (added to other commit types to mark breaking changes) For example:
     
    feat!: Add ingress links column into Applications table on stage page (#77)
+ EDP Project Rules. Working Process - EPAM Delivery Platform      
      
     
      
     
      
     
     
     
     
      
     
     
     
     
     
      
     
     
     
     
     
    EDP Project Rules. Working Process⚓︎
     
    This page contains the details on the project rules and working process for EDP team and contributors. Explore the main points about working with Gerrit, following the main commit flow, as well as the details about commit types and message below.
     
    Project Rules⚓︎
     
    Before starting the development, please check the project rules:
     
       
    1.  
      It is highly recommended to become familiar with the Gerrit flow. For details, please refer to the Gerrit official documentation and pay attention to the main points:
       
      a. Voting in Gerrit.
       
      b. Resolution of Merge Conflict.
       
      c. Comments resolution.
       
      d. One Jira task should have one Merge Request (MR). If there are many changes within one MR, add the next patch set to the open MR by selecting the Amend commit check box.
       
      2.  
    2.  
      Only the Assignee is responsible for the MR merge and Jira task status.
       
      3.  
    3.  
      Every MR should be merged in a timely manner.
       
      4.  
    4.  
      Log time to Jira ticket.
       
      5.  
     
    Working Process⚓︎
     
    With EDP, the main workflow is based on the getting a Jira task and creating a Merge Request according to the rules described below.
     
     
    Workflow
     
    Get Jira task → implement, verify by yourself the results → create Merge Request (MR) → send for review → resolve comments/add changes, ask colleagues for the final review → track the MR merge → verify by yourself the results → change the status in the Jira ticket to CODE COMPLETE or RESOLVED → share necessary links with a QA specialist in the QA Verification channel → QA specialist closes the Jira task after his verification → Jira task should be CLOSED.
     
     
    Commit Flow
     
       
    1.  
      Get a task in the Jira/GitHub dashboard. Please be aware of the following points:
       
       
       
       
      a. Every task has a reporter who can provide more details in case something is not clear.
       
      b. The responsible person for the task and code implementation is the assignee who tracks the following:
       
         
      • Actual Jira task status.
        •  
       
         
      • Time logging.
        •  
       
         
      • Add comments, attach necessary files.
        •  
       
         
      • In comments, add link that refers to the merged MR (optional, if not related to many repositories).
        •  
       
         
      • Code review and the final merge.
        •  
       
         
      • MS Teams chats - ping other colleagues, answer questions, etc.
        •  
       
         
      • Verification by a QA specialist.
        •  
       
         
      • Bug fixing.
        •  
       
      c. Pay attention to the task Status that differs in different entities, the workflow will help to see the whole task processing:
       
       
      View Jira workflow
      View Jira workflow
       
       
       
      d. There are several entities that are used on the EDP project: Story, Improvement, Task, Bug.
       
       
       
      a. Every task has a reporter who can provide more details in case something is not clear.
       
      b. The responsible person for the task and code implementation is the assignee who tracks the following:
       
         
      • Actual GitHub task status.
        •  
       
         
      • Add comments, attach necessary files.
        •  
       
         
      • In comments, add link that refers to the merged MR (optional, if not related to many repositories).
        •  
       
         
      • Code review and the final merge.
        •  
       
         
      • MS Teams chats - ping other colleagues, answer questions, etc.
        •  
       
         
      • Verification by a QA specialist.
        •  
       
         
      • Bug fixing.
        •  
       
      c. If the task is created on your own, make sure it is populated completely. See an example below:
       
       
      GitHub issue
      GitHub issue
       
       
       
       
       
       
      2.  
    2.  
      Implement feature, improvement, fix and check the results on your own. If it is impossible to check the results of your work before the merge, verify all later.
       
      3.  
    3.  
      Create a Merge Request, for details, please refer to the Code Review Process.
       
      4.  
    4.  
      When committing, use the pattern: commit type: Commit message (#GitHub ticket number).
       
      a. commit type:
       
      feat: (new feature for the user, not a new feature for build script)
       
      fix: (bug fix for the user, not a fix to a build script)
       
      docs: (changes to the documentation)
       
      style: (formatting, missing semicolons, etc; no production code change)
       
      refactor: (refactoring production code, eg. renaming a variable)
       
      test: (adding missing tests, refactoring tests; no production code change)
       
      chore: (updating grunt tasks etc; no production code change)
       
      !: (added to other commit types to mark breaking changes) For example:
       
      feat!: Add ingress links column into Applications table on stage page (#77)
 
 BREAKING CHANGE: Ingress links column has been added into the Applications table on the stage details page
 
       
      b. Commit message:
       
         
      •  
        brief, for example:
         
        fix: Remove secretKey duplication from registry secrets (#63)
         
        or
         
        •