CERA Architecture
The CERA demo environment is broken into 3 main layers. This is both for some practical technical reasons, and also allows a better isolation of traditional roles across Application, Platform, and Infrastructure teams.
- Global Layer
Would be run by your Central IT/Infrastructure team with access priveleged (not root) acces to AWS environment. In our demo environment we use SSO roles to access this profile. - EKS Layer
Provisions the EKS cluster and network. The only K8s interactions are the Istio (and friends) installation for basic network routing with HTTPS. - Platform Layer (consumed by app teams)
The final piece of the monorepo creates the core services and a handful of empty namespaces with pre-configured OIDC access to Vault and K8s.
Our own demo cluster, (supporting this fieldguide!) is HA across 2-3 regions at a time. This is controlled with a pipeline enum and some regional mapping rules.
fieldguide.circleci-fieldeng.com resolves the closest, but you can directly view cluster sites with
fieldguide.REGION.circleci-fieldeng.com
(currently EMEA or NAMER)
Structure of modules in https://github.com/AwesomeCICD/ceratf-deployment-monorepo/tree/main
--- title: Monorepo layers --- classDiagram Global <|-- EKS_Layer Global : +String aws_account Global : +String operator_iam_role Global : +String pipeline_iam_role Global : +String circleci_org_id Global : +String root_domain Global : +String common_aws_tags Global : +String user_login_ids Global : +String dyanmo_db_table Global : +String s3_bucket_path Global: +create_iam_policies() Global: +route_domain() Global: +setup_oidc() EKS_Layer <|-- Platform_Layer class EKS_Layer{ +String region_name +provision_network() +provision_eks() +regional_dns_records() +istio_ingress() +vault_install() } class Platform_Layer{ +String cci_release_token +String nexus_admin_password +Array[String] app_namespaces +install_nexus() +create_custom_appspaces() +configure_vault_policies() +install_argo_rollouts() +install_cci_releases() }