[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["很难理解","hardToUnderstand","thumb-down"],["信息或示例代码不正确","incorrectInformationOrSampleCode","thumb-down"],["没有我需要的信息/示例","missingTheInformationSamplesINeed","thumb-down"],["翻译问题","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC)：2025-08-29。"],[[["\u003cp\u003eCloud Composer 1 environments can be configured with Public IP, Private IP with VPC peerings, or Private IP with Domain Restricted Sharing (DRS) architectures, each with varying levels of resource distribution between tenant and customer projects.\u003c/p\u003e\n"],["\u003cp\u003eCloud Composer environments consist of components such as an environment's cluster, environment's bucket, Airflow web server, and Airflow database, which run either in a tenant or customer project and contribute to the managed Airflow infrastructure.\u003c/p\u003e\n"],["\u003cp\u003eThe tenant project in Cloud Composer 1 typically hosts the Airflow web server and database, while the customer project hosts other components like the environment's bucket, schedulers, and workers, with the specific arrangement varying by the chosen IP architecture.\u003c/p\u003e\n"],["\u003cp\u003ePrivate IP architectures, including the DRS variant, utilize HAProxy and dual Cloud SQL Proxy instances within the tenant project to manage traffic and maintain access to the Airflow database, due to network restrictions that prevent the customer project from direct access.\u003c/p\u003e\n"],["\u003cp\u003eCloud Composer integrates with Cloud Logging and Cloud Monitoring, offering centralized access to Airflow and DAG logs, as well as enabling the monitoring of environment metrics and events for generating insights.\u003c/p\u003e\n"]]],[],null,["# Environment architecture\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n\n[Cloud Composer 3](/composer/docs/composer-3/environment-architecture \"View this page for Cloud Composer 3\") \\| [Cloud Composer 2](/composer/docs/composer-2/environment-architecture \"View this page for Cloud Composer 2\") \\| **Cloud Composer 1**\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\nThis page describes the architecture of Cloud Composer environments.\n\nEnvironment architecture configurations\n---------------------------------------\n\n\u003cbr /\u003e\n\nCloud Composer 1 environments can have the following architecture\nconfigurations:\n\n- [Public IP architecture](#public-ip)\n- [Private IP architecture with VPC peerings](#private-ip)\n- [Private IP with Domain restricted sharing (DRS) architecture](#private-ip-drs)\n\nCustomer and tenant projects\n----------------------------\n\nWhen you create an environment, Cloud Composer distributes the\nenvironment's resources between a tenant and a customer project:\n\n- *Customer project* is a Google Cloud project where you create your\n environments. You can create more than one environment in a single customer\n project.\n\n- *Tenant project* is a Google-managed [tenant project](/service-infrastructure/docs/glossary#tenant) and\n belongs to the Google.com organization. The tenant project provides unified\n access control and an additional layer of data security to your\n environment. Each Cloud Composer environment has its own tenant\n project.\n\nEnvironment components\n----------------------\n\nA Cloud Composer environment consists of environment components.\n\nAn *environment component* is an element of a managed Airflow infrastructure\nthat runs on Google Cloud, as a part of your environment. Environment\ncomponents run either in the tenant or in the customer project of\nyour environment.\n\n### Environment's cluster\n\n\u003cbr /\u003e\n\n*Environment's cluster* is a [Standard](/kubernetes-engine/docs/concepts/types-of-clusters#modes) mode\n[VPC-native](/kubernetes-engine/docs/concepts/types-of-clusters#vpc-clusters) or\n[Routes-based](/kubernetes-engine/docs/concepts/types-of-clusters#vpc-clusters) Google Kubernetes Engine cluster of your\nenvironment:\n| **Caution:** Do not introduce changes in the environment's cluster. Clusters for Cloud Composer and workloads deployed into them are managed by Google. It is possible to change the configuration of your environment's cluster, but doing so might break your environment. If you delete an environment's cluster, it cannot be restored; you must delete the environment and create a new environment.\n\nBy default, Cloud Composer enables\n[node auto-upgrades](/kubernetes-engine/docs/how-to/node-auto-upgrades) and [node auto-repair](/kubernetes-engine/docs/how-to/node-auto-repair)\nto protect your environment's cluster from security vulnerabilities. These\noperations happen during maintenance windows that you specify for your\nenvironment.\n\n### Environment's bucket\n\n*Environment's bucket* is a [Cloud Storage bucket](/composer/docs/composer-1/cloud-storage)\nthat stores DAGs, plugins, data dependencies, and Airflow logs. Environment's\nbucket is located in the customer project.\n\nWhen you [upload your DAG files](/composer/docs/composer-1/manage-dags) to the `/dags` folder in your\nenvironment's bucket, Cloud Composer synchronizes the DAGs to Airflow components of your environment.\n| **Note:** Because of a service restriction on App Engine, the `data/` and `logs/` folders are not available to the Airflow web server.\n\n### Airflow web server\n\n*Airflow web server* runs the Airflow UI of your environment.\n\n\u003cbr /\u003e\n\nIn Cloud Composer 1, Airflow web server runs in the tenant project\nof your environment.\n\nThe Airflow web server is integrated with Identity-Aware Proxy.\nCloud Composer hides the IAP integration\ndetails, and provides access to the web server based on user identities\nand IAM policy bindings defined for users.\n\nIn Cloud Composer 1, the Airflow web server run on a different service account\nthan Airflow workers and Airflow schedulers. The service account for web server\nis auto-generated during the environment creation and is derived from the web\nserver domain. For example, if the domain is `example.appspot.com`, the\nservice account is `example@appspot.gserviceaccount.com`.\n\n### Airflow database\n\n*Airflow database* is a [Cloud SQL instance](/sql/docs/introduction)\nthat runs in the tenant project of your environment. It hosts the Airflow\nmetadata database.\n\nTo protect sensitive connection and workflow information,\nCloud Composer allows database access only to\nthe [service account](/composer/docs/composer-1/access-control#service-account) of your environment.\n\n### Other airflow components\n\nOther Airflow components that run in your environment are:\n\n- *Airflow schedulers* parse DAG definition files, schedule DAG runs\n based on the schedule interval, and queues tasks for execution by\n Airflow workers.\n\n In Cloud Composer 1\n Airflow DAG processors run as a part of scheduler components.\n\n- *Airflow workers* execute tasks that are scheduled by Airflow\n schedulers.\n\nPublic IP environment architecture\n----------------------------------\n\n\u003cbr /\u003e\n\n[](/static/composer/docs/images/composer-1-public-ip-architecture.svg) **Figure 1.** Public IP environment architecture (click to enlarge)\n\nIn a Public IP environment architecture for Cloud Composer 1:\n\n- The tenant project hosts a Cloud SQL instance, Cloud SQL storage, and a App Engine Flex instance that runs the Airflow web server.\n- The customer project hosts all other components of the environment.\n- Airflow schedulers and workers in the customer project communicate with the Airflow database through a Cloud SQL proxy instances located in the customer project.\n- Airflow web server in the tenant project communicates with the Airflow database through a Cloud SQL proxy instance located in the tenant project.\n\nPrivate IP environment architecture\n-----------------------------------\n\n[](/static/composer/docs/images/composer-1-private-ip-architecture.svg) **Figure 2.** Private IP environment architecture (click to enlarge)\n\nIn a Private IP environment architecture:\n\n- The tenant project hosts a Cloud SQL instance, Cloud SQL storage, and **two App Engine instances** that run the Airflow web server.\n- The customer project hosts all other components of the environment.\n- Airflow schedulers and workers connect to the Airflow database through the **HAProxy process** in the environment's cluster.\n- The HAProxy process load balances traffic to the Cloud SQL instance between **two Cloud SQL Proxy instances** that are located in the tenant project. Private IP environments use two Cloud SQL Proxy instances because the customer project does not access the database directly due to network limitations. Two instances are needed to ensure that components of your environment have access to the database at all times.\n\nPrivate IP with DRS\n-------------------\n\n[](/static/composer/docs/images/composer-1-private-ip-drs-architecture.svg) **Figure 3.** Private IP environment architecture (click to enlarge)\n\nIf the [Domain Restricted Sharing (DRS) organizational policy](/resource-manager/docs/organization-policy/org-policy-constraints)\nis turned on in your project, then Cloud Composer uses the Private IP\nwith DRS environment architecture.\n\nIn the Private IP with DRS environment architecture:\n\n- The tenant project hosts a Cloud SQL instance,\n Cloud SQL storage, and two App Engine instances that\n run the Airflow web server.\n\n- The tenant project hosts an **additional environment's bucket**. Airflow web\n server accesses this bucket directly.\n\n- The customer project hosts all other components of the environment.\n\n- The customer project hosts the **Bucket Syncing process** in\n the environment's cluster. This process synchronizes two environment\n buckets.\n\n- Airflow schedulers and workers connect to the Airflow database through\n the HAProxy process in the environment's cluster.\n\n- The HAProxy process load balances traffic to the Cloud SQL\n instance between **two Cloud SQL Proxy instances** that are\n located in the tenant project. Private IP environments use two Cloud SQL Proxy instances because the customer project does not\n access the database directly due to network limitations. Two instances\n are needed to ensure that components of your environment have access to\n the database at all times.\n\nIntegration with Cloud Logging and Cloud Monitoring\n---------------------------------------------------\n\nCloud Composer integrates with Cloud Logging and\nCloud Monitoring of your Google Cloud project, so that you have a\ncentral place to view [Airflow and DAG logs](/composer/docs/composer-1/view-logs).\n\nCloud Monitoring collects and ingests metrics, events, and metadata\nfrom Cloud Composer to\n[generate insights through dashboards and charts](/composer/docs/composer-1/monitor-environments).\n\nBecause of the streaming nature of Cloud Logging, you can view logs emitted by Airflow components immediately instead of waiting for Airflow logs to appear in the Cloud Storage bucket of your environment.\n\nTo limit the number of logs in your Google Cloud project,\nyou can [stop all logs ingestion](/logging/docs/exclusions#stop-logs). Do not\ndisable Logging.\n\nWhat's next\n-----------\n\n- [Create an environment](/composer/docs/composer-1/create-environments)\n- [Versioning overview](/composer/docs/composer-versioning-overview)"]]
