示例工程【免费下载链接】python-docs-samplesCode samples used on cloud.google.com项目地址https://gitcode.com/GitHub_Trending/py/python-docs-samples点击查看免费下载本指南以 python-docs-samples 仓库中kubernetes_engine/django_tutorial示例为核心完整讲解如何将 Django 官方教程中的 Polls 投票应用教程第一、二部分容器化并部署到 Google Kubernetes EngineGKE。你将掌握从项目结构、Docker 镜像构建、Cloud SQL 数据库接入、Kubernetes Deployment/Service 编排到 Makefile 一键部署的完整链路可直接照搬到自己的 Django 项目。示例项目定位用真实应用跑通 GKE 部署kubernetes_engine/django_tutorial目录是一个完整的 Django 项目其 README 明确说明它以 Django 官方《Writing your first Django app》教程中的 Polls 应用第一部分和第二部分作为待部署示例下文统一称其为 polls 应用。项目并非仅仅堆砌 YAML 文件而是将 Django 代码、Dockerfile、Kubernetes 清单、Makefile 自动化脚本和 Cloud SQL 集成放在一起构成一个从代码到线上的闭环样例。整个部署方案的技术要点可概括为三条主线容器化通过 Dockerfile 将 Django 应用打包使用 Gunicorn 作为 WSGI 生产服务器云数据库接入通过 Cloud SQL Proxy 边车容器sidecar将 Cloud SQL PostgreSQL 实例暴露为127.0.0.1:5432Django 侧无需任何网络改动Kubernetes 编排通过 polls.yaml 定义 3 副本 Deployment 和对外 LoadBalancer Service。项目结构一个标准的 Django 单项目布局kubernetes_engine/django_tutorial/ ├── mysite/ # Django 项目settings、urls、wsgi │ ├── settings.py # 面向 GKE 的数据库与静态文件配置 │ ├── urls.py # 根路由 │ └── wsgi.py # WSGI 入口 ├── polls/ # Django 应用投票应用本体 │ ├── migrations/ │ │ └── 0001_initial.py # 模型迁移 │ ├── admin.py │ ├── apps.py │ ├── models.py # Question / Choice 模型 │ ├── tests.py │ ├── urls.py │ └── views.py # index 视图 ├── manage.py # Django 管理脚本 ├── Dockerfile # 容器镜像构建 ├── Makefile # 集群、镜像、部署自动化 ├── polls.yaml # Kubernetes Deployment Service ├── requirements.txt # 运行时依赖 └── requirements-test.txt # 测试依赖从源码结构看这对应 Django 教程第一、二部分的完成形态polls应用已包含模型、管理后台注册、迁移和基础视图mysite项目负责路由与全局配置。根路由在 mysite/urls.py 中把根路径/交给polls.urls并将admin/指向 Django 自带管理后台urlpatterns [ path(admin/, admin.site.urls), path(, include(polls.urls)), ]polls 应用教程第一、二部分的代码载体示例中的投票应用核心是两个模型定义在 polls/models.pyfrom django.db import models class Question(models.Model): question_text models.CharField(max_length200) pub_date models.DateTimeField(date published) class Choice(models.Model): question models.ForeignKey(Question, on_deletemodels.CASCADE) choice_text models.CharField(max_length200) votes models.IntegerField(default0)这正是 Django 官方教程第一部分的经典模型Question问题含文本与发布时间与Choice选项通过外键关联问题含文本与票数对应迁移文件 polls/migrations/0001_initial.py 已随仓库提供部署后可据此初始化数据库表结构。视图层目前保持教程早期形态polls/views.py 仅返回一个占位响应from django.http import HttpResponse def index(request): return HttpResponse(Hello, world. Youre at the polls index.)并在 polls/urls.py 中注册空路径路由。这个简化形态正是教程循序渐进思路的体现——重点是演示应用如何跑起来而非复杂的业务逻辑。容器化Dockerfile 与依赖管理Dockerfile 逐段解读Dockerfile 展示了将 Django 应用打包为可运行镜像的最小实践FROM gcr.io/google_appengine/python # 创建虚拟环境并安装依赖 RUN virtualenv -p python3 /env ENV PATH /env/bin:$PATH ADD requirements.txt /app/requirements.txt RUN /env/bin/pip install --upgrade pip /env/bin/pip install -r /app/requirements.txt ADD . /app CMD gunicorn -b :$PORT mysite.wsgi关键点基础镜像基于 Google 提供的 App Engine Python 运行时镜像Debian 系预置 Python内含常用 OS 级包便于安装主流 Python 库虚拟环境用virtualenv -p python3 /env创建隔离环境并把/env/bin加入PATH后续pip与gunicorn均使用该环境分层缓存先单独ADD requirements.txt并安装依赖再ADD . /app复制源码这样依赖未变化时镜像构建可复用缓存层加速迭代启动命令gunicorn -b :$PORT mysite.wsgi使用 Gunicorn 绑定环境变量$PORT指定的端口这是 GKE/Cloud Run 等平台注入端口约定WSGI 应用对象来自 mysite/wsgi.py加载mysite.settings配置并调用get_wsgi_application()。依赖清单 requirements.txtrequirements.txt 是本次部署的运行时依赖精确清单Django6.1.1; python_version 3.12 wheel0.47.0 gunicorn23.0.0; python_version 3.0 psycopg2-binary2.9.11要点说明Django 6.1.1当前示例锁定的 Django 版本并带python_version 3.12标记说明运行环境需 Python 3.12 及以上wheel用于加速纯 Python 包安装Gunicorn 23.0.0生产级 WSGI 服务器负责承载 Django 应用psycopg2-binary2.9.11PostgreSQL 的 Python 驱动。文件内注释同时给出两条切换线索若使用 MySQL需改用mysqlclient1.4.1并安装 MySQL 客户端若倾向从源码编译可将psycopg22.8.4取消注释替换 binary 版本。面向 GKE 的 Django 配置settings.py 关键点mysite/settings.py 是示例中与云上运行关系最密切的配置值得逐项分析。数据库环境变量 本地代理端口DATABASES { default: { ENGINE: django.db.backends.postgresql, NAME: os.getenv(DATABASE_NAME), USER: os.getenv(DATABASE_USER), PASSWORD: os.getenv(DATABASE_PASSWORD), HOST: 127.0.0.1, PORT: 5432, } }这套配置的运行逻辑是数据库连接信息全部来自环境变量DATABASE_NAME、DATABASE_USER、DATABASE_PASSWORD不在镜像内硬编码任何凭据HOST固定为127.0.0.1、PORT固定为5432意味着 Django 只与本机回环地址通信——真正的 Cloud SQL 实例由部署清单中的 Cloud SQL Proxy 边车容器转发应用代码无需感知云数据库的网络细节文件注释提示若使用 Cloud SQL for MySQL只需把ENGINE改为django.db.backends.mysql并相应切换依赖为mysqlclient。静态文件开发与生产两种形态STATIC_URL /static/ # STATIC_URL https://storage.googleapis.com/[YOUR_GCS_BUCKET]/static/ STATIC_ROOT static/开发阶段使用/static/并配合 mysite/urls.py 中仅在settings.DEBUG为真时挂载的staticfiles_urlpatterns()提供静态资源生产形态则预留了将静态文件上传至 Google Cloud Storage 桶、通过storage.googleapis.comURL 直出的方案——注释行即该切换入口。同时在 Makefile 中提供了create-bucket目标用于创建承载静态文件的 GCS 桶。安全与运行面配置示例保留了教程默认的开发期设置并明确标注了三类生产前必须处理的警告SECRET_KEY当前为硬编码值注释强调生产中务必保密DEBUG True不适合生产注释明确警告不要在开启 debug 的情况下上生产ALLOWED_HOSTS [*]是开发期放行配置注释要求生产部署时设置为合适的 Host。另外TIME_ZONE UTC、USE_TZ True等国际化设置保持默认DEFAULT_AUTO_FIELD django.db.models.BigAutoField指定主键默认类型INSTALLED_APPS与MIDDLEWARE为 Django 6.x 标准集合并将polls应用注册进项目。Kubernetes 编排polls.yaml 深度解析polls.yaml 是部署的核心清单由两个资源组成Deployment应用本体 数据库代理边车和Service对外负载均衡。清单中的[START/END gke_kubernetes_deployment_yaml_python]标记还承担着云端文档代码片段嵌入的职责。Deployment3 副本 Cloud SQL Proxy 边车apiVersion: apps/v1 kind: Deployment metadata: name: polls labels: app: polls spec: replicas: 3 selector: matchLabels: app: polls template: metadata: labels: app: polls spec: containers: - name: polls-app image: gcr.io/your-project-id/polls imagePullPolicy: Always env: - name: DATABASE_NAME valueFrom: secretKeyRef: name: cloudsql key: database - name: DATABASE_USER valueFrom: secretKeyRef: name: cloudsql key: username - name: DATABASE_PASSWORD valueFrom: secretKeyRef: name: cloudsql key: password ports: - containerPort: 8080 - image: gcr.io/cloudsql-docker/gce-proxy:1.16 name: cloudsql-proxy command: [/cloud_sql_proxy, --dir/cloudsql, -instancesyour-cloudsql-connection-stringtcp:5432, -credential_file/secrets/cloudsql/credentials.json] volumeMounts: - name: cloudsql-oauth-credentials mountPath: /secrets/cloudsql readOnly: true - name: ssl-certs mountPath: /etc/ssl/certs - name: cloudsql mountPath: /cloudsql volumes: - name: cloudsql-oauth-credentials secret: secretName: cloudsql-oauth-credentials - name: ssl-certs hostPath: path: /etc/ssl/certs - name: cloudsql emptyDir: {}逐项拆解副本数replicas: 3清单注释说明该前端至少保持 3 个实例在集群中运行提供基本的高可用与滚动发布空间镜像占位gcr.io/your-project-id/polls需要替换为真实项目 IDMakefile 的template目标正是用sed自动完成这一替换见后文imagePullPolicy: Always清单注释明确说明该策略让节点在每次启动 Pod 前都拉取最新镜像便于调试生产环境应评估改为按需拉取环境变量注入DATABASE_NAME、DATABASE_USER、DATABASE_PASSWORD三个变量均通过secretKeyRef从名为cloudsql的 Kubernetes Secret 中读取key 分别为database、username、password与 settings.py 中的os.getenv(...)一一对应凭据全程不落明文边车容器 cloudsql-proxy使用官方gcr.io/cloudsql-docker/gce-proxy:1.16镜像命令将your-cloudsql-connection-string指定的 Cloud SQL 实例转发到本 Pod 的tcp:5432并以-credential_file指定服务账号凭据三个卷挂载分别提供 OAuth 凭据只读、宿主机的 SSL 证书、以及/cloudsql运行目录emptyDir对外端口应用容器暴露containerPort: 8080与 Dockerfile 中 Gunicorn 监听的$PORT约定一致。这一双容器应用 代理模式是 GKE 上安全连接 Cloud SQL 的经典做法数据库流量经加密代理转发Django 只需访问本地回环地址。Service外部 HTTP 负载均衡apiVersion: v1 kind: Service metadata: name: polls labels: app: polls spec: type: LoadBalancer ports: - port: 80 targetPort: 8080 selector: app: polls该 Service 通过selector: app: polls将流量路由到带app: polls标签的 Pod即 Deployment 管理的实例type: LoadBalancer让 Kubernetes Engine 自动创建外部 HTTP 负载均衡器入站端口80转发到 Pod 的targetPort: 8080正好落在应用容器的监听端口上。一键自动化Makefile 目标详解Makefile 把从建集群到删除服务的完整生命周期封装成目标顶部通过gcloud config list project动态读取当前项目 IDGCLOUD_PROJECT:$(shell gcloud config list project --formatvalue(core.project))各目标及其作用目标命令作用alldeploy默认目标等价于执行完整部署create-clustergcloud container clusters create polls --scopes https://www.googleapis.com/auth/userinfo.email,cloud-platform创建名为polls的 GKE 集群并授予 userinfo.email 与 cloud-platform 两个 OAuth 范围使节点可访问云 APIcreate-bucketgcloud storage buckets create gs://$(GCLOUD_PROJECT)后接--predefined-default-object-aclpublicRead创建以项目 ID 命名的 GCS 桶并设置默认公开读 ACL用于承载静态资源builddocker build -t gcr.io/$(GCLOUD_PROJECT)/polls .基于当前目录 Dockerfile 构建镜像并打上 GCR 标签push依赖buildgcloud docker push -- gcr.io/$(GCLOUD_PROJECT)/polls构建后推送镜像到 Google Container Registrytemplatesed -i .tmpl s/\$$GCLOUD_PROJECT/$(GCLOUD_PROJECT)/g polls.yaml用真实项目 ID 替换 polls.yaml 中的$GCLOUD_PROJECT占位符deploy依赖push与templatekubectl create -f polls.yaml推送镜像、渲染模板后向集群提交 Deployment 与 Service 清单updatekubectl patch deployment polls -p ...为 Pod 模板追加带当前时间戳的date标签通过变更 Pod 模板触发滚动更新强制拉取最新镜像deletekubectl delete rc polls与kubectl delete service polls删除 replication controller 与服务清理部署这条链路清晰地展现了典型工作流create-cluster → create-bucket → build → push → template → deploy日常发布则可用update触发滚动更新。端到端部署步骤综合 README 的教程定位与仓库内自动化脚本在 GKE 上部署该示例的完整路径如下准备环境安装并登录gcloud、docker、kubectl确认gcloud config已选中目标项目Makefile 会读取该值作为GCLOUD_PROJECT创建集群执行make create-cluster创建带必要 OAuth 范围的polls集群准备静态资源桶可选执行make create-bucket创建 GCS 桶并按需切换 settings.py 中注释掉的 GCS 静态文件 URL准备数据库与凭据创建 Cloud SQL PostgreSQL 实例并将实例连接串、数据库名、用户名、密码以 Kubernetes Secret 形式准备好——Deployment 需要的 Secret 名为cloudsql键database/username/passwordCloud SQL Proxy 需要的 OAuth 凭据 Secret 名为cloudsql-oauth-credentials构建并推送镜像执行make push构建gcr.io/project/polls镜像并推送到 GCR渲染清单并部署执行make deploy先由template将$GCLOUD_PROJECT替换为真实项目 IDpolls.yaml 中镜像字段与注释同步更新再由kubectl create -f polls.yaml提交 Deployment 与 Service初始化数据库对 Pod 执行 Django 迁移命令仓库已包含 manage.py 与 0001_initial.py完成表结构创建与管理后台所需表验证访问通过kubectl get service polls获取 LoadBalancer 外部 IP浏览器访问http://外部IP/即可看到 polls index 页面/admin/可进入管理后台。发布更新与清理日常迭代发布可用make update它通过kubectl patch为 Pod 模板注入带秒级时间戳的date标签强制触发 Deployment 滚动更新并重新拉取镜像实现新镜像 → 新 Pod的平滑替换。需要下线环境时make delete会同时删除 replication controller 与 Service若需彻底销毁集群另行执行gcloud container clusters delete polls即可。测试与质量配套仓库为该项目准备了 requirements-test.txt测试依赖清单与 polls/tests.pyDjango 测试占位文件。从文件组织看示例保留了标准 Django 测试体系可在本地用manage.py test polls运行应用测试在 CI 中再叠加镜像构建、YAML 校验等环节。这种代码 测试 部署清单同仓维护的方式也符合本仓库作为 Google Cloud Python 官方示例集合的整体风格根目录另有 CONTRIBUTING.md 与 LICENSE 管理贡献与授权。小结kubernetes_engine/django_tutorial用不到二十个文件完整示范了 Django 应用上云 GKE 的最小可行路径polls 应用提供业务代码settings.py 通过环境变量与本地代理端口解耦云数据库Dockerfile 产出 Gunicorn 托管的镜像polls.yaml 用 Deployment 边车代理 LoadBalancer Service 完成集群编排Makefile 则将全部环节封装为一条命令链。照此模式你可以在数分钟内把自己的 Django 项目同样搬上 Kubernetes Engine并直接复用其 Cloud SQL 接入与滚动更新方案。赞分享示例工程【免费下载链接】python-docs-samplesCode samples used on cloud.google.com项目地址https://gitcode.com/GitHub_Trending/py/python-docs-samples点击查看免费下载相关推荐如何在Google Compute Engine上部署IncludeOS完整指南与实战教程如何在Google Compute Engine上部署IncludeOS完整指南与实战教程 IncludeOS 是一个极简、资源高效的 云服务单内核操作系统操作系统云原生虚拟化网络python-docs-samples 实战将 Django Hello World 应用部署到 Google App Engine Flexible Environmentpython docs samples 实战将 Django Hello World 应用部署到 Google App Engine Flexible Env示例工程在 Google Cloud 上部署 GelCloud SQL Kubernetes 完整实战指南在 Google Cloud 上部署 GelCloud SQL Kubernetes 完整实战指南 本指南以 docs/reference/running数据库图数据库关系型数据库上一篇PHPStan 错误指南phpstanPlayground.staticWithoutType——静态变量缺少类型注解的成因、修复与规则实现解析下一篇终极网盘下载解决方案八大平台直链解析工具完全指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 在 Google Kubernetes Engine 上部署 Django：python-docs-samples 的 polls 应用完整实战指南
示例工程【免费下载链接】python-docs-samplesCode samples used on cloud.google.com项目地址https://gitcode.com/GitHub_Trending/py/python-docs-samples点击查看免费下载本指南以 python-docs-samples 仓库中kubernetes_engine/django_tutorial示例为核心完整讲解如何将 Django 官方教程中的 Polls 投票应用教程第一、二部分容器化并部署到 Google Kubernetes EngineGKE。你将掌握从项目结构、Docker 镜像构建、Cloud SQL 数据库接入、Kubernetes Deployment/Service 编排到 Makefile 一键部署的完整链路可直接照搬到自己的 Django 项目。示例项目定位用真实应用跑通 GKE 部署kubernetes_engine/django_tutorial目录是一个完整的 Django 项目其 README 明确说明它以 Django 官方《Writing your first Django app》教程中的 Polls 应用第一部分和第二部分作为待部署示例下文统一称其为 polls 应用。项目并非仅仅堆砌 YAML 文件而是将 Django 代码、Dockerfile、Kubernetes 清单、Makefile 自动化脚本和 Cloud SQL 集成放在一起构成一个从代码到线上的闭环样例。整个部署方案的技术要点可概括为三条主线容器化通过 Dockerfile 将 Django 应用打包使用 Gunicorn 作为 WSGI 生产服务器云数据库接入通过 Cloud SQL Proxy 边车容器sidecar将 Cloud SQL PostgreSQL 实例暴露为127.0.0.1:5432Django 侧无需任何网络改动Kubernetes 编排通过 polls.yaml 定义 3 副本 Deployment 和对外 LoadBalancer Service。项目结构一个标准的 Django 单项目布局kubernetes_engine/django_tutorial/ ├── mysite/ # Django 项目settings、urls、wsgi │ ├── settings.py # 面向 GKE 的数据库与静态文件配置 │ ├── urls.py # 根路由 │ └── wsgi.py # WSGI 入口 ├── polls/ # Django 应用投票应用本体 │ ├── migrations/ │ │ └── 0001_initial.py # 模型迁移 │ ├── admin.py │ ├── apps.py │ ├── models.py # Question / Choice 模型 │ ├── tests.py │ ├── urls.py │ └── views.py # index 视图 ├── manage.py # Django 管理脚本 ├── Dockerfile # 容器镜像构建 ├── Makefile # 集群、镜像、部署自动化 ├── polls.yaml # Kubernetes Deployment Service ├── requirements.txt # 运行时依赖 └── requirements-test.txt # 测试依赖从源码结构看这对应 Django 教程第一、二部分的完成形态polls应用已包含模型、管理后台注册、迁移和基础视图mysite项目负责路由与全局配置。根路由在 mysite/urls.py 中把根路径/交给polls.urls并将admin/指向 Django 自带管理后台urlpatterns [ path(admin/, admin.site.urls), path(, include(polls.urls)), ]polls 应用教程第一、二部分的代码载体示例中的投票应用核心是两个模型定义在 polls/models.pyfrom django.db import models class Question(models.Model): question_text models.CharField(max_length200) pub_date models.DateTimeField(date published) class Choice(models.Model): question models.ForeignKey(Question, on_deletemodels.CASCADE) choice_text models.CharField(max_length200) votes models.IntegerField(default0)这正是 Django 官方教程第一部分的经典模型Question问题含文本与发布时间与Choice选项通过外键关联问题含文本与票数对应迁移文件 polls/migrations/0001_initial.py 已随仓库提供部署后可据此初始化数据库表结构。视图层目前保持教程早期形态polls/views.py 仅返回一个占位响应from django.http import HttpResponse def index(request): return HttpResponse(Hello, world. Youre at the polls index.)并在 polls/urls.py 中注册空路径路由。这个简化形态正是教程循序渐进思路的体现——重点是演示应用如何跑起来而非复杂的业务逻辑。容器化Dockerfile 与依赖管理Dockerfile 逐段解读Dockerfile 展示了将 Django 应用打包为可运行镜像的最小实践FROM gcr.io/google_appengine/python # 创建虚拟环境并安装依赖 RUN virtualenv -p python3 /env ENV PATH /env/bin:$PATH ADD requirements.txt /app/requirements.txt RUN /env/bin/pip install --upgrade pip /env/bin/pip install -r /app/requirements.txt ADD . /app CMD gunicorn -b :$PORT mysite.wsgi关键点基础镜像基于 Google 提供的 App Engine Python 运行时镜像Debian 系预置 Python内含常用 OS 级包便于安装主流 Python 库虚拟环境用virtualenv -p python3 /env创建隔离环境并把/env/bin加入PATH后续pip与gunicorn均使用该环境分层缓存先单独ADD requirements.txt并安装依赖再ADD . /app复制源码这样依赖未变化时镜像构建可复用缓存层加速迭代启动命令gunicorn -b :$PORT mysite.wsgi使用 Gunicorn 绑定环境变量$PORT指定的端口这是 GKE/Cloud Run 等平台注入端口约定WSGI 应用对象来自 mysite/wsgi.py加载mysite.settings配置并调用get_wsgi_application()。依赖清单 requirements.txtrequirements.txt 是本次部署的运行时依赖精确清单Django6.1.1; python_version 3.12 wheel0.47.0 gunicorn23.0.0; python_version 3.0 psycopg2-binary2.9.11要点说明Django 6.1.1当前示例锁定的 Django 版本并带python_version 3.12标记说明运行环境需 Python 3.12 及以上wheel用于加速纯 Python 包安装Gunicorn 23.0.0生产级 WSGI 服务器负责承载 Django 应用psycopg2-binary2.9.11PostgreSQL 的 Python 驱动。文件内注释同时给出两条切换线索若使用 MySQL需改用mysqlclient1.4.1并安装 MySQL 客户端若倾向从源码编译可将psycopg22.8.4取消注释替换 binary 版本。面向 GKE 的 Django 配置settings.py 关键点mysite/settings.py 是示例中与云上运行关系最密切的配置值得逐项分析。数据库环境变量 本地代理端口DATABASES { default: { ENGINE: django.db.backends.postgresql, NAME: os.getenv(DATABASE_NAME), USER: os.getenv(DATABASE_USER), PASSWORD: os.getenv(DATABASE_PASSWORD), HOST: 127.0.0.1, PORT: 5432, } }这套配置的运行逻辑是数据库连接信息全部来自环境变量DATABASE_NAME、DATABASE_USER、DATABASE_PASSWORD不在镜像内硬编码任何凭据HOST固定为127.0.0.1、PORT固定为5432意味着 Django 只与本机回环地址通信——真正的 Cloud SQL 实例由部署清单中的 Cloud SQL Proxy 边车容器转发应用代码无需感知云数据库的网络细节文件注释提示若使用 Cloud SQL for MySQL只需把ENGINE改为django.db.backends.mysql并相应切换依赖为mysqlclient。静态文件开发与生产两种形态STATIC_URL /static/ # STATIC_URL https://storage.googleapis.com/[YOUR_GCS_BUCKET]/static/ STATIC_ROOT static/开发阶段使用/static/并配合 mysite/urls.py 中仅在settings.DEBUG为真时挂载的staticfiles_urlpatterns()提供静态资源生产形态则预留了将静态文件上传至 Google Cloud Storage 桶、通过storage.googleapis.comURL 直出的方案——注释行即该切换入口。同时在 Makefile 中提供了create-bucket目标用于创建承载静态文件的 GCS 桶。安全与运行面配置示例保留了教程默认的开发期设置并明确标注了三类生产前必须处理的警告SECRET_KEY当前为硬编码值注释强调生产中务必保密DEBUG True不适合生产注释明确警告不要在开启 debug 的情况下上生产ALLOWED_HOSTS [*]是开发期放行配置注释要求生产部署时设置为合适的 Host。另外TIME_ZONE UTC、USE_TZ True等国际化设置保持默认DEFAULT_AUTO_FIELD django.db.models.BigAutoField指定主键默认类型INSTALLED_APPS与MIDDLEWARE为 Django 6.x 标准集合并将polls应用注册进项目。Kubernetes 编排polls.yaml 深度解析polls.yaml 是部署的核心清单由两个资源组成Deployment应用本体 数据库代理边车和Service对外负载均衡。清单中的[START/END gke_kubernetes_deployment_yaml_python]标记还承担着云端文档代码片段嵌入的职责。Deployment3 副本 Cloud SQL Proxy 边车apiVersion: apps/v1 kind: Deployment metadata: name: polls labels: app: polls spec: replicas: 3 selector: matchLabels: app: polls template: metadata: labels: app: polls spec: containers: - name: polls-app image: gcr.io/your-project-id/polls imagePullPolicy: Always env: - name: DATABASE_NAME valueFrom: secretKeyRef: name: cloudsql key: database - name: DATABASE_USER valueFrom: secretKeyRef: name: cloudsql key: username - name: DATABASE_PASSWORD valueFrom: secretKeyRef: name: cloudsql key: password ports: - containerPort: 8080 - image: gcr.io/cloudsql-docker/gce-proxy:1.16 name: cloudsql-proxy command: [/cloud_sql_proxy, --dir/cloudsql, -instancesyour-cloudsql-connection-stringtcp:5432, -credential_file/secrets/cloudsql/credentials.json] volumeMounts: - name: cloudsql-oauth-credentials mountPath: /secrets/cloudsql readOnly: true - name: ssl-certs mountPath: /etc/ssl/certs - name: cloudsql mountPath: /cloudsql volumes: - name: cloudsql-oauth-credentials secret: secretName: cloudsql-oauth-credentials - name: ssl-certs hostPath: path: /etc/ssl/certs - name: cloudsql emptyDir: {}逐项拆解副本数replicas: 3清单注释说明该前端至少保持 3 个实例在集群中运行提供基本的高可用与滚动发布空间镜像占位gcr.io/your-project-id/polls需要替换为真实项目 IDMakefile 的template目标正是用sed自动完成这一替换见后文imagePullPolicy: Always清单注释明确说明该策略让节点在每次启动 Pod 前都拉取最新镜像便于调试生产环境应评估改为按需拉取环境变量注入DATABASE_NAME、DATABASE_USER、DATABASE_PASSWORD三个变量均通过secretKeyRef从名为cloudsql的 Kubernetes Secret 中读取key 分别为database、username、password与 settings.py 中的os.getenv(...)一一对应凭据全程不落明文边车容器 cloudsql-proxy使用官方gcr.io/cloudsql-docker/gce-proxy:1.16镜像命令将your-cloudsql-connection-string指定的 Cloud SQL 实例转发到本 Pod 的tcp:5432并以-credential_file指定服务账号凭据三个卷挂载分别提供 OAuth 凭据只读、宿主机的 SSL 证书、以及/cloudsql运行目录emptyDir对外端口应用容器暴露containerPort: 8080与 Dockerfile 中 Gunicorn 监听的$PORT约定一致。这一双容器应用 代理模式是 GKE 上安全连接 Cloud SQL 的经典做法数据库流量经加密代理转发Django 只需访问本地回环地址。Service外部 HTTP 负载均衡apiVersion: v1 kind: Service metadata: name: polls labels: app: polls spec: type: LoadBalancer ports: - port: 80 targetPort: 8080 selector: app: polls该 Service 通过selector: app: polls将流量路由到带app: polls标签的 Pod即 Deployment 管理的实例type: LoadBalancer让 Kubernetes Engine 自动创建外部 HTTP 负载均衡器入站端口80转发到 Pod 的targetPort: 8080正好落在应用容器的监听端口上。一键自动化Makefile 目标详解Makefile 把从建集群到删除服务的完整生命周期封装成目标顶部通过gcloud config list project动态读取当前项目 IDGCLOUD_PROJECT:$(shell gcloud config list project --formatvalue(core.project))各目标及其作用目标命令作用alldeploy默认目标等价于执行完整部署create-clustergcloud container clusters create polls --scopes https://www.googleapis.com/auth/userinfo.email,cloud-platform创建名为polls的 GKE 集群并授予 userinfo.email 与 cloud-platform 两个 OAuth 范围使节点可访问云 APIcreate-bucketgcloud storage buckets create gs://$(GCLOUD_PROJECT)后接--predefined-default-object-aclpublicRead创建以项目 ID 命名的 GCS 桶并设置默认公开读 ACL用于承载静态资源builddocker build -t gcr.io/$(GCLOUD_PROJECT)/polls .基于当前目录 Dockerfile 构建镜像并打上 GCR 标签push依赖buildgcloud docker push -- gcr.io/$(GCLOUD_PROJECT)/polls构建后推送镜像到 Google Container Registrytemplatesed -i .tmpl s/\$$GCLOUD_PROJECT/$(GCLOUD_PROJECT)/g polls.yaml用真实项目 ID 替换 polls.yaml 中的$GCLOUD_PROJECT占位符deploy依赖push与templatekubectl create -f polls.yaml推送镜像、渲染模板后向集群提交 Deployment 与 Service 清单updatekubectl patch deployment polls -p ...为 Pod 模板追加带当前时间戳的date标签通过变更 Pod 模板触发滚动更新强制拉取最新镜像deletekubectl delete rc polls与kubectl delete service polls删除 replication controller 与服务清理部署这条链路清晰地展现了典型工作流create-cluster → create-bucket → build → push → template → deploy日常发布则可用update触发滚动更新。端到端部署步骤综合 README 的教程定位与仓库内自动化脚本在 GKE 上部署该示例的完整路径如下准备环境安装并登录gcloud、docker、kubectl确认gcloud config已选中目标项目Makefile 会读取该值作为GCLOUD_PROJECT创建集群执行make create-cluster创建带必要 OAuth 范围的polls集群准备静态资源桶可选执行make create-bucket创建 GCS 桶并按需切换 settings.py 中注释掉的 GCS 静态文件 URL准备数据库与凭据创建 Cloud SQL PostgreSQL 实例并将实例连接串、数据库名、用户名、密码以 Kubernetes Secret 形式准备好——Deployment 需要的 Secret 名为cloudsql键database/username/passwordCloud SQL Proxy 需要的 OAuth 凭据 Secret 名为cloudsql-oauth-credentials构建并推送镜像执行make push构建gcr.io/project/polls镜像并推送到 GCR渲染清单并部署执行make deploy先由template将$GCLOUD_PROJECT替换为真实项目 IDpolls.yaml 中镜像字段与注释同步更新再由kubectl create -f polls.yaml提交 Deployment 与 Service初始化数据库对 Pod 执行 Django 迁移命令仓库已包含 manage.py 与 0001_initial.py完成表结构创建与管理后台所需表验证访问通过kubectl get service polls获取 LoadBalancer 外部 IP浏览器访问http://外部IP/即可看到 polls index 页面/admin/可进入管理后台。发布更新与清理日常迭代发布可用make update它通过kubectl patch为 Pod 模板注入带秒级时间戳的date标签强制触发 Deployment 滚动更新并重新拉取镜像实现新镜像 → 新 Pod的平滑替换。需要下线环境时make delete会同时删除 replication controller 与 Service若需彻底销毁集群另行执行gcloud container clusters delete polls即可。测试与质量配套仓库为该项目准备了 requirements-test.txt测试依赖清单与 polls/tests.pyDjango 测试占位文件。从文件组织看示例保留了标准 Django 测试体系可在本地用manage.py test polls运行应用测试在 CI 中再叠加镜像构建、YAML 校验等环节。这种代码 测试 部署清单同仓维护的方式也符合本仓库作为 Google Cloud Python 官方示例集合的整体风格根目录另有 CONTRIBUTING.md 与 LICENSE 管理贡献与授权。小结kubernetes_engine/django_tutorial用不到二十个文件完整示范了 Django 应用上云 GKE 的最小可行路径polls 应用提供业务代码settings.py 通过环境变量与本地代理端口解耦云数据库Dockerfile 产出 Gunicorn 托管的镜像polls.yaml 用 Deployment 边车代理 LoadBalancer Service 完成集群编排Makefile 则将全部环节封装为一条命令链。照此模式你可以在数分钟内把自己的 Django 项目同样搬上 Kubernetes Engine并直接复用其 Cloud SQL 接入与滚动更新方案。赞分享示例工程【免费下载链接】python-docs-samplesCode samples used on cloud.google.com项目地址https://gitcode.com/GitHub_Trending/py/python-docs-samples点击查看免费下载相关推荐如何在Google Compute Engine上部署IncludeOS完整指南与实战教程如何在Google Compute Engine上部署IncludeOS完整指南与实战教程 IncludeOS 是一个极简、资源高效的 云服务单内核操作系统操作系统云原生虚拟化网络python-docs-samples 实战将 Django Hello World 应用部署到 Google App Engine Flexible Environmentpython docs samples 实战将 Django Hello World 应用部署到 Google App Engine Flexible Env示例工程在 Google Cloud 上部署 GelCloud SQL Kubernetes 完整实战指南在 Google Cloud 上部署 GelCloud SQL Kubernetes 完整实战指南 本指南以 docs/reference/running数据库图数据库关系型数据库上一篇PHPStan 错误指南phpstanPlayground.staticWithoutType——静态变量缺少类型注解的成因、修复与规则实现解析下一篇终极网盘下载解决方案八大平台直链解析工具完全指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考