DuploCloud components common to AWS, GCP, and Azure deployments
Several DuploCloud components are used with AWS, GCP, and Azure Services. These include Infrastructures, Plans, Tenants, Hosts, and Load Balancers. To learn more, see the topics below.
Corresponding to each Infrastructure is the concept of a Plan. A Plan is a placeholder or a template for configurations. These configurations are consistently applied to all Tenants within the Plan (or Infrastructure). Examples of such configurations are:
Certificates available to be attached to Load Balancers in Tenants of this Plan
Machine images
WAF web ACLs
Common IAM policies and SG rules to be applied to all resources in Tenants within the Plan
Unique or shared DNS domain name where applications provisioned in Tenants within the Plan can have a unique DNS name in this domain
Resource Quota: The plan also has a resource quota that is enforced in each of the Tenants within that Plan
DB Parameter Groups
Several policies and feature flags are to be applied at the infrastructure level on Tenants within the Plan
The figure below shows a screenshot of the plan constructs:
When creating DuploCloud Plans and DNS names, consider the following to prevent DNS issues:
Plans in different portals will delete each other's DNS records, so each portal must use a distinct subdomain for its Plans.
DuploCloud Plans in the same portal can share a DNS domain without deleting each other's records. Duplo-created DNS names will always include the Tenant name, which prevents collisions.
The recommended practice for most portals is to set all Plans to the same DNS name, including the default
Plan.
Ideally, custom subdomains will be set in the Plans before turning on shell, monitoring, or logging. If the DNS is changed later, those services may need to be updated.
A Tenant is the most fundamental construct in DuploCloud which is essentially like a project or a workspace and is a child of the Infrastructure. While Infrastructure is a VPC level isolation, Tenant is the next level of isolation implemented by segregating Tenants using Security Groups, IAM role, Instance Profile, K8S Namespace, KMS Key, etc., in the case of AWS. Similar concepts are leveraged from other cloud providers like resource groups, managed identity, ASG, etc., in Azure.
A Tenant is fundamentally four things, at the logical level:
Container of resources: All resources (except ones corresponding to infrastructure) are created within the Tenant. If we delete the Tenant then all resources within it are terminated.
Security Boundary: All resources within the Tenant can talk to each other. For example, a Docker container deployed in an EC2 instance within the Tenant will have access to S3 buckets and RDS instances in the same Tenant. RDS instances in another Tenant cannot be reached, by default. Tenants can expose endpoints to each other via ELBs or explicit inter-tenant SG and IAM policies.
User Access Control: Self-service is the bedrock of the DuploCloud platform. To that end, users can be granted Tenant-level access. For example, Joe is an administrator who has access to all Tenants, while John and Jim are developers who can only access the Dev Tenant and Anna is a data scientist who has access only to the data science Tenant.
Billing Unit: Since a Tenant is a container of resources, all resources in the Tenant are tagged with the Tenant's name in the cloud provider, making it easy to segregate usage by Tenant.
Mechanism for Alerting: All alerts represent Faults in any resource within the Tenants.
Mechanism for Logging: Each Tenant has its unique set of logs.
Mechanism for metrics: Each Tenant has its unique set of metrics.
When you create Tenants in an Infrastructure, a namespace is created in the Kubernetes cluster with the name duploservices-TENANT_NAME.
Each Tenant is mapped to a Namespace in Kubernetes. For example, if a Tenant is called Analytics in DuploCloud, the Kubernetes Namespace is called duploservices-analytics
.
All application components within the Analytics Tenant are placed in the duploservices-analytics
namespace. Since nodes cannot be part of a Kubernetes Namespace, DuploCloud creates a tenantname
label for all the nodes that are launched within the Tenant. For example, a node launched in the Analytics Tenant is labeled tenantname: duploservices-analytics
.
Any Pods that are launched using the DuploCloud UI have an appropriate Kubernetes nodeSelector
that ties the Pod to the nodes within the Tenant. If you are deploying via kubectl,
ensure that your deployment is using the proper nodeSelector
.
Many DuploCloud customers create at least two Tenants for both their production and non-production cloud environments (Infrastructures).
You can map Tenants in each or all of your development, testing, staging, Quality Assurance (QA), and production environments.
For example:
Production Infrastructure
Pre-production Tenant - for preparing or reviewing production code
Production Tenant - for deploying tested code
Non-production Infrastructure
Development Tenant - for writing and reviewing code
Quality Assurance Tenant - for automated testing
In larger organizations, some customers create Tenants based on application environments, such as creating a tenant for Data Science applications, another for web applications, etc.
Tenants are sometimes created to isolate a single customer workload, allowing more granular monitoring of performance, the flexibility of scaling, or tighter security. This is referred to as a single-Tenant setup. In this case, a DuploCloud Tenant maps to an environment used exclusively by the end client.
When you have a large set of applications that different teams access, it is helpful to map Tenants to team workloads. For example, you could create Tenants for Dev-analytics, Stage-analytics, and so on.
A Service could be a Kubernetes Deployment, Stateful set or a Daemon set. It can also be a Lambda function or an ECS task or service. It essentially captures a microservice. Each service (except Lambda) can be given a load balancer to expose itself and be assigned a DNS name.
DuploCloud Service should not be confused with a Kubernetes or a ECS service. By service we mean application components that can either be Docker-based or serverless.
Below is an image of some properties of a service:
Cloud Services: DuploCloud supports a simple application specific interface to configure dozens of cloud services like S3, SNS, SQS, Kafka, Elasticsearch, Data Pipeline, EMR, Sagemaker, Azure Redis, Azure SQL, Google Redis, etc. Almost all commonly used services are supported and new ones are constantly added. A typical request to support a new service takes the DuploCloud team a matter of days, based on the complexity of the service.
While users specify application level constructs for provisioning cloud resources, all the underlying DevOps and compliance controls are implicitly added by DuploCloud.
IMPORTANT: All services and cloud features are created within a Tenant.
Infrastructures are abstractions that allow you to create a Virtual Private Cloud (VPC) instance in the DuploCloud Portal. When you create an Infrastructure, a Plan (with the same Infrastructure name) is automatically created and populated with the Infrastructure configuration to supply the network configuration necessary for your Infrastructure to run.
Each Infrastructure represents a network connection to a unique VPC/VNET, in a region with a Kubernetes cluster. In the case of AWS, it can also include an ECS. An Infrastructure can be created with four basic inputs: Name, VPC CIDR, Number of AZs, Region, and the option to enable or disable a K8S/ECS cluster.
When you create the Infrastructure, DuploCloud automatically creates the following components:
VPC with two subnets (private, public) in each availability zone
Required security groups
NAT Gateway
Internet Gateway
Route tables
VPC peering with the master VPC, which is initially configured in DuploCloud
Additional requirements like custom Private/Public Subnet CIDRs can be configured in the Advanced Options area.
A common use for Infrastructure is having two Infrastructures, one for prod and one for non-prod. Another is having an infrastructure in a different region for DR or localized client deployments in that region.
Once the Infrastructure is created, DuploCloud automatically creates a Plan (with the same Infrastructure name) with the Infrastructure configuration. The Plan is used to create Tenants.
The DuploCloud platform automatically orchestrates three main diagnostic functions:
Central Logging: A shared Elasticsearch cluster is deployed and file beat is installed in all worker nodes to fetch the logs from various applications across tenants. The logs are injected with metadata corresponding to Tenant name, service name, container ID, Host name, etc. Further, each tenant has the central logging dashboard which includes the Kibana view of the logs from applications within the service. See the screenshot below:
Metrics: Metrics are fetched from hosts, containers, and cloud services like ELB, RDS, Redis, etc., and displayed in Grafana. Behind the scenes, for cloud services, these are collected by calling cloud provider APIs like CloudWatch and Azure Mon, while for nodes and containers, this is done using Prometheus, Node Exporter, and cAdvisor. Again, the dashboards are Tenant-centric and segregated per application and cloud service as shown in the picture below:
Alarms and Faults: The platform creates faults for many failures automatically, such as Health check, container crashes, node crashes, deployment failures, etc. Further, users can easily set alarms on cloud services like CPU and Memory on EC2 instances, Free Disk space in RDS database, etc. All failures are displayed as faults per tenant. Sentry and Pager Duty projects can be linked to each tenant and DuploCloud will send these faults there so the user can set notification configurations.
Audit Trail: An audit trail of all changes made to the system are logged in Elasticsearch where these can be audited using high level constructs like changes by tenant, by service, by change type, by user and dozens of other such filters.