在docker compose环境中，python应用连接mysql容器时，常见的连接失败问题源于对端口映射的误解。核心在于，应用在docker网络内部应使用mysql容器的默认监听端口（3306），而非宿主机映射端口。本文将详细解释docker compose的端口映射机制，并提供正确的配置方法，确保容器间通信顺畅。
理解Docker Compose中的端口映射
当在Docker Compose文件中定义服务并进行端口映射时，例如ports: - "3307:3306"，这表示将宿主机的3307端口映射到Docker容器内部的3306端口。这里的关键区别在于：
- 宿主机端口 (3307): 这是宿主机上暴露的端口，用于允许外部（即不在Docker网络内部）的应用程序或用户访问Docker容器内的服务。
- 容器内部端口 (3306): 这是Docker容器内部服务实际监听的端口。对于在同一个Docker Compose网络中的其他容器，它们应该通过这个内部端口来访问服务。
在提供的场景中，MySQL容器在内部监听3306端口（这是MySQL的默认端口），并通过3307:3306映射到宿主机的3307端口。Python应用与MySQL容器同处于sql_network这一自定义Docker网络中。因此，Python应用在尝试连接MySQL时，应使用MySQL容器在内部网络中监听的端口，即3306。
识别与修正连接问题
根据日志输出ERROR:services.dbService:Unable to create tables due to 2003 (HY000): Can't connect to MySQL server on 'mysql:3307'，可以明确看到Python应用试图连接到mysql:3307。这里的mysql是服务名称，Docker Compose会自动将其解析为MySQL容器在内部网络中的IP地址。然而，连接端口使用了宿主机的映射端口3307，而非MySQL容器内部实际监听的3306端口，这导致了连接失败。
要解决此问题，需要修改Python应用中的数据库连接配置，将端口从3307更改为3306。
立即学习“Python免费学习笔记（深入）”；
错误的配置示例 (dbService.py)
config = {
'host': 'mysql',
'port': '3307', # 错误：应使用容器内部端口
'user': 'user',
'password': 'password',
'database': 'db',
}正确的配置示例 (dbService.py)
config = {
'host': 'mysql',
'port': '3306', # 正确：使用MySQL容器内部监听的端口
'user': 'user',
'password': 'password',
'database': 'db',
}完整的Docker Compose和应用配置
以下是修正后的dbService.py相关部分和docker-compose.yml文件的示例，展示了正确的端口配置。
docker-compose.yml (保持不变)
version: '3'
services:
mysql:
image: mysql:latest
ports:
- "3307:3306" # 宿主机3307映射到容器3306
environment:
MYSQL_ROOT_PASSWORD: root
MYSQL_DATABASE: db
MYSQL_USER: user
MYSQL_PASSWORD: password
networks:
- sql_network
volumes:
- /mysql_data:/var/lib/mysql
python_app:
build: .
ports:
- "5000:5000"
networks:
- sql_network
depends_on:
- mysql
networks:
sql_network:dbService.py (修改端口配置)
import mysql.connector
import logging
import time
logger = logging.getLogger(__name__)
config = {
'host': 'mysql', # Docker Compose服务名称，解析为容器IP
'port': '3306', # MySQL容器内部监听的端口
'user': 'user',
'password': 'password',
'database': 'db',
}
def create_tables():
logger.info("Entering create tables method from dbservice")
connection = None # 初始化connection变量
try:
# 增加连接重试机制，以应对MySQL容器启动慢的情况
retries = 5
for i in range(retries):
try:
connection = mysql.connector.connect(**config)
logger.info("Successfully connected to MySQL.")
break
except mysql.connector.Error as err:
logger.warning(f"Attempt {i+1}/{retries}: Could not connect to MySQL: {err}. Retrying in 5 seconds...")
time.sleep(5)
if not connection or not connection.is_connected():
raise Exception("Failed to establish MySQL connection after multiple retries.")
cursor = connection.cursor()
# 检查'emails'表是否已存在
cursor.execute("SHOW TABLES LIKE 'emails'")
table_exists = cursor.fetchone()
if not table_exists:
cursor.execute(
'''
CREATE TABLE emails (
id INT PRIMARY KEY AUTO_INCREMENT,
created TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
email VARCHAR(255) NOT NULL,
verified BOOLEAN NOT NULL,
flatType VARCHAR(255) NOT NULL,
streetName VARCHAR(255) NOT NULL,
blkFrom INT NOT NULL,
blkTo INT NOT NULL,
lastSent TIMESTAMP,
token VARCHAR(255))
''')
connection.commit()
logger.info("Table 'emails' created successfully.")
else:
logger.info("Table 'emails' already exists.")
except Exception as e:
logger.error(f"Unable to create tables due to {e}")
finally:
if connection and connection.is_connected():
connection.close()
logger.info("MySQL connection closed.")
app.py (保持不变，但建议优化启动等待机制)
# ... 其他导入和应用初始化代码 ... # time.sleep(10) # 这种硬编码的等待方式不够健壮 create_tables() # 结合dbService中的重试机制会更可靠 # ... 其他应用逻辑 ...
注意事项与最佳实践
- 内部端口与外部端口： 始终记住，在Docker Compose网络内部，容器之间通信使用服务名称和内部监听端口。宿主机映射端口仅用于宿主机或外部网络访问容器服务。
- 服务启动顺序与就绪状态： depends_on仅保证容器的启动顺序，但不保证服务已完全就绪并接受连接。像time.sleep(10)这样的硬编码等待是一种简单的解决方案，但在生产环境中，更推荐使用健康检查（healthcheck）或在应用代码中实现连接重试逻辑，以确保服务真正可用后再尝试连接。上述修改后的dbService.py中已添加了简单的重试机制。
- 网络配置： Docker Compose默认会为所有服务创建一个桥接网络。通过networks关键字可以自定义网络，这有助于隔离不同应用栈的网络，提高安全性。
- 日志分析： 仔细阅读Docker Compose的日志输出是诊断问题的关键。错误信息通常会明确指出连接失败的原因，例如本例中的Can't connect to MySQL server on 'mysql:3307'。
总结
在Docker Compose环境中，Python应用连接MySQL容器时遇到Can't connect to MySQL server错误，最常见的原因是混淆了宿主机端口和容器内部端口。解决方案是确保应用程序在Docker网络内部连接MySQL时，使用MySQL容器实际监听的内部端口（通常是3306），而不是宿主机上映射的端口。通过正确理解和配置端口映射，并结合健壮的连接重试机制，可以有效解决此类连接问题，确保容器化应用的稳定运行。
