Introduction
Architecture
Onboard
Introduction
Teams
Users
Introduction
IntroductionPromote an image in Amazon ECRDownload a file from JFrog ArtifactoryMove or copy an image from JFrog ArtifactoryUpload a file to JFrog ArtifactoryStore an object on Amazon S3Retrieve an object from Amazon S3
IntroductionCreate or update a functionInvoke a function
IntroductionRun an AWS CodePipelineRun a Bamboo projectRun a Bitbucket pipelineRun a CloudBees CI jobRun a CircleCI workflowRun a GitHub Actions workflowRun a GitLab pipelineRun a Harness pipelineRun a Jenkins® jobRun a JFrog pipelineRun a TeamCity project
Check out a Git repository
IntroductionAWS credentialsECR credentialsEKS credentialsGit global credentialsOCI credentials
IntroductionRun Argo WorkflowsCopy a remote image with CraneDeploy a binary with EC2Deploy to ECSRender an ECS task definitionBuild a container image with KanikoDeploy with OctopusDeploy with SpinnakerRun Ansible Playbook
Publish evidence items
IntroductionHelm chart installHelm chart packageHelm chart publishHelm chart uninstall
IntroductionCreate a Kubernetes namespaceCreate/update a Kubernetes resourceDeploy to a Kubernetes cluster
IntroductionVerify with NewRelic
Execute remote commands via SSH
IntroductionAnchoreAquasecJFrog XraySnyk ContainerSonatype (Nexus) ContainerTrivy
IntroductionStackhawkZAP
IntroductionCheckmarxFind Security BugsGitHub Security ScannerGosecMendNexus IQSnykSonarQube bundledSonarQube
IntroductionMendSnyk
IntroductionTruffleHog ContainerTruffleHog CodeTruffleHog S3
Publish test results
CI insights for Jenkins

CloudBees platform architecture

2 minute read

The CloudBees platform is built using a microservice architecture. Services are containerized and deployed using Helm and Pulumi automation scripts. The infrastructure is deployed in an Amazon Web Services (AWS) region or multi-regions (for users requiring higher availability).

YAML configuration file

Automation scripts include a YAML configuration file that defines:

  • Regions / Availability zones

  • Access control list rules

  • Security groups

  • Resources

  • Relational database service (RDS)

  • OpenSearch

  • Amazon Elastic Kubernetes Service (EKS) clusters

    • Two clusters per region are expected — one for Tekton and one for platform services.

    • Clusters are configurable.

  • Virtual private cloud (VPC)

  • Subnets

  • Route 53 Domain name system (DNS)

  • S3 object storage

  • Hosted zone for specific domain routing

  • Certificate manager

  • CloudFront content delivery network (CDN)

  • Datadog monitoring

Standard single region

The AWS EKS clusters are configurable, although two deployed per region is standard. One cluster is generally used to host most services required to run the platform. The other cluster hosts Tekton itself, platform-specific services for managing Tekton, and it is also where customer workflows run.

Single AWS region
Figure 1. Diagram of an AWS single region.

Standard multi-region

The multi-region deployment for higher availability users has replication among regions. S3 data, and RDS, OpenSearch, and Cassandra databases are replicated. Using DNS traffic distribution, users can access the platform interface that runs in the region closest to them. Workloads are distributed between regions when they are run.

Single AWS region
Figure 2. Diagram of an AWS multi-region.

Customer-managed VPC requirements

Customers who manage their own VPC must provide an AWS account. If your account uses single sign-on (SSO), you must export one of the following two options to access the account:

  • AWS_PROFILE.

  • AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY.

The account used requires administrator-level access for the resources being created. After the hosted zone is created by running the initialization script, the name server (NS) record domain delegation occurs.

The following types of customers do not need to provide an AWS account:

  • Single-tenant SaaS

  • Multi-tenant SaaS

  • CloudBees-managed VPC
Introduction