用docker-py启动容器后，需验证服务真实就绪：先检查container.attrs'state'和health状态，再通过端口探测、http请求或自定义命令确认；未配健康检查时，用socket或requests轮询，设超时与重试。
用 docker-py 启动容器后怎么确认它真跑起来了？
直接调用 container.start() 不代表服务就绪——比如 PostgreSQL 要等几秒才接受连接，Nginx 可能已启动但还没加载完配置。健康检查不能只看容器状态是 running，得验证端口通、HTTP 返回 200 或执行自定义命令。
实操建议：
- 别依赖
container.status，改用container.attrs['State']['Status']+container.attrs['State']['Health']['Status']（前提是镜像有HEALTHCHECK） - 没配健康检查的镜像，用
socket.create_connection((host, port), timeout=2)测端口，或用requests.get(f"http://{host}:{port}/health", timeout=3) - 超时必须设，否则脚本卡死；建议最多重试 10 次，每次间隔 1–2 秒
部署时怎么传环境变量和挂载目录不写死？
硬编码 environment={'DB_HOST': 'localhost'} 或 volumes={'/data': {'bind': '/app/data', 'mode': 'rw'}} 会让脚本无法复用。实际部署中，环境变量常来自 .env 文件或 CI/CD 注入，路径需适配不同宿主机结构。
实操建议：
- 用
python-dotenv加载.env，再传给client.containers.run(..., environment=dict(dotenv_values())) - 挂载路径用
os.path.abspath('./local-config')转绝对路径，避免相对路径在不同工作目录下失效 -
volumes字典的 key 是宿主机路径，value 里bind是容器内路径，mode必须显式写'ro'或'rw'，省略会默认只读
容器启动失败时，docker-py 报什么错？怎么定位？
常见错误不是 Python 异常，而是容器静默退出，container.logs() 返回空或只有警告。真正有用的线索藏在 container.attrs['State']['Error'] 或 container.wait() 的返回值里。
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
实操建议：
- 启动后立刻调用
container.wait(timeout=30)，它返回{'StatusCode': 0}表示正常退出（对长期运行容器这反而是异常信号），非 0 值说明启动阶段崩溃 - 查日志别只看
container.logs()，加参数stdout=True, stderr=True, timestamps=True并用decode('utf-8')处理字节流 - 如果
container.attrs['State']['Status'] == 'exited'，立刻读container.attrs['State']['Error']—— 这里常有 “port already allocated” 或 “no such file or directory”
为什么用 subprocess 调 docker run 比用 docker-py 更难 debug？
表面上 subprocess.run(['docker', 'run', '-d', '--name', 'app', 'nginx']) 更轻量，但错误信息全被吞进 stderr，容器 ID 需手动解析，且没法直接获取容器对象做后续操作（如日志、重启、健康轮询）。
实操建议：
- 除非必须用 Docker CLI 特性（如
--gpus旧版docker-py不支持），否则坚持用docker-py - 若必须用
subprocess，至少加上check=True和capture_output=True，出错时打印result.stderr.decode() -
docker-py的client.containers.run(..., detach=True)返回的就是可操作的Container对象，比解析 CLI 输出稳定得多
健康检查逻辑最容易被忽略的点：不是所有服务都监听 0.0.0.0 —— 容器内应用可能只绑定了 127.0.0.1，导致从宿主机 curl localhost:8080 失败，但容器内 curl 127.0.0.1:8080 成功。部署前务必确认应用的监听地址配置。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
