mirror of
https://github.com/yeasy/docker_practice.git
synced 2026-08-10 08:27:25 +00:00
yeasy
0cfd55af7b
Follow-ups to the 9 secret-hardening commits (each verified against docs.docker.com / vendor docs; one outright new bug found and fixed): - 11.6:eb5e4397changed settings.py to a hard os.environ lookup but the web service never receives POSTGRES_PASSWORD (only db does; DATABASE_URL is set but never read) -> step-6 'docker compose up' crashed with KeyError. Pass the var to web; harden the leftover literal password in the 配置详解 snippet that contradicted the new guidance two lines down; blank line after the inserted sentence (bold heading merged into the paragraph); dev/prod table no longer claims dev uses 明文 passwords - 11.8: FAQ still told readers to check passwords in .env after the same file banned passwords in .env -> point at secrets/db_password.txt; backup sidecar env vars updated to tiredofit/db-backup 4.x interface (DB01_* + DB01_PASS_FILE + DB01_BACKUP_INTERVAL - the unprefixed DB_* names are ignored by current :latest; verified against upstream README) - demo/wordpress: compose now references secrets files that ship nowhere -> add README with the creation commands from 11.8; demo/django: align with the hardened 11.6 (env-injected password, passed to web too) - 04_image multistage demos: go build without go.mod fails on module-mode Go (reproduced by reviewer on go1.26) -> add 'go mod init helloworld' matching the 7.17 doc pattern in all three Dockerfiles - 21.7: init script reworked init-db.sql -> init-db.sh per the official image's env-reading .sh hook - removes the baked 'secure_password' AND the CREATE DATABASE myappdb collision with POSTGRES_DB that aborted first-boot init (ON_ERROR_STOP); compose passes APP_DB_PASSWORD; microservices init.sql mount annotated schema-only (POSTGRES_USER: appuser would collide with CREATE USER); Dockerfile-redis healthcheck now authenticates via REDISCLI_AUTH read from redis.conf (plain redis-cli ping gets NOAUTH against requirepass - same class as the compose siblingeb5e4397already fixed); dev-container dev/dev creds annotated local-only - 19.3: Grafana admin password 'admin' sat directly under the newly added security warning -> env-injected like the rest of the stack
第二十一章 实战案例 - DevOps
版本说明
本章示例中使用的镜像版本遵循以下原则：
- GitHub Actions (
actions/checkout@v6等) 采用大版本标签，代表最新的功能版本与稳定性的平衡 - 编程语言镜像 (
golang:1.26-alpine、rust:1.95-alpine等) 采用次版本标签，确保 API 稳定性同时获得安全更新 - 数据库镜像 (
postgres:16-alpine、redis:8-alpine等) 采用大版本标签，便于获得修复和改进 - 基础镜像 (
alpine:3.21、debian:12等) 采用大版本或次版本标签，避免latest以确保可再现性 - 实际项目中应根据需求调整版本，生产环境建议定期更新以获取安全补丁
DevOps 背景介绍
DevOps 是一种重要的开发和运维文化，强调开发团队和运维团队之间的协作和自动化。它致力于通过自动化和流程优化，加快软件交付速度，同时提高系统的稳定性和可靠性。Docker 作为容器化技术的领导者，已成为现代 DevOps 工作流中不可或缺的工具。通过容器化应用，开发团队可以确保“一次构建，处处运行”，消除开发、测试和生产环境的差异，大大简化了部署流程。
Docker 在 DevOps 中的角色
Docker 在 DevOps 工作流中承担多个关键角色。首先，它标准化了应用的开发和部署环境，使得团队成员在相同的 Docker 容器中工作，避免了“在我的机器上可以运行”的问题。其次，Docker 与 CI/CD 流程无缝集成，通过自动化的镜像构建、测试和部署，实现快速的迭代周期。此外，Docker 还支持微服务架构和容器编排，使团队能够更灵活地扩展应用和管理基础设施。
CI/CD 管道的重要性
持续集成与持续部署 (CI/CD) 是现代 DevOps 的核心。通过自动化的代码检测、测试、构建和部署流程，团队可以更加频繁地发布新版本，同时保持系统的稳定性和可靠性。Docker 在 CI/CD 中扮演了重要角色：
- 标准化构建环境 - Docker 确保开发、测试和生产环境完全一致，消除了环境差异带来的问题
- 加速流水线 - 容器的快速启动和轻量级特性，大幅加快了 CI/CD 流程的执行效率
- 灵活的测试框架 - 可以轻松创建短生命周期的测试容器，并行运行多个测试
- 自动化镜像发布 - CI/CD 工具可以自动构建、扫描、标记和推送 Docker 镜像到仓库
- 蓝绿部署和金丝雀发布 - 利用容器的隔离性和可重复性，实现高级发布策略
本章将通过介绍 GitHub Actions、Drone 等流行的 CI/CD 工具，展示如何在实际项目中构建完整的自动化流水线。我们还将演示如何在本地开发环境中集成 Docker，使用 IDE 的容器开发插件，加快本地迭代周期。
本章学习目标
通过学习本章内容，你将能够：
- 理解 DevOps 文化、CI/CD 流程和容器化的紧密关系
- 掌握完整的 Docker 工作流，从代码提交到线上部署的每一个环节
- 学习如何使用 GitHub Actions 实现自动化 CI/CD，以及工作流的编写和优化
- 了解 Drone 等第三方 CI/CD 工具的架构、部署和配置方式
- 学会在本地 IDE (VS Code) 中集成 Docker，利用容器开发工具提升开发效率
- 掌握实战中常见的 DevOps 场景、最佳实践和故障排查方法
章节内容导航
- DevOps 完整工作流 — 从代码到部署的全流程
- GitHub Actions — 使用 GitHub Actions 实现 CI/CD
- Drone — Drone CI/CD 平台简介和配置
- Drone Demo — Drone 实战演示和应用
- 在 IDE 中使用 Docker — IDE 与 Docker 集成的好处
- VS Code — Visual Studio Code 容器开发指南
- 实战例子 — 真实项目中的 DevOps 应用案例
- 本章小结