从 Docker 到 Lambda：AWS 管理员的 Python 应用程序之旅

从 Python 脚本到无服务器 AWS：我的投资组合之旅

我从用于 AWS 自动化的简单 Python 脚本开始，逐渐演变成一个更复杂的项目。 三个月前，我几乎不懂元类；现在，我已经建立了一个成熟的投资组合经理。

我的旅程

多年来使用 Python 进行 AWS 自动化（包括臭名昭著的“does-everything”脚本）让我构建了一个合适的应用程序。 借助我过去的脚本、Stack Overflow 以及 Claude 的 AI 帮助，我终于掌握了软件开发原理。

应用截图（种子数据，非实际投资）。

厌倦了手动更新我的投资组合的 Excel 电子表格，我自动化了该过程。 这个Python应用程序管理投资组合、跟踪交易、处理股息，甚至自动更新价格。 最初，它在我的家庭服务器上的 Docker 中运行良好（Flask 后端、React 前端、SQLite 数据库）。

“爱好变成工作”难题

在我的家庭服务器上运行它感觉效率很低。 作为一名 AWS 专业人士，在我的硬件上管理容器似乎违反直觉。解决方案似乎显而易见：ECS。我已经有了 docker-compose 文件：

<code>services:
  backend:
    build: ./backend
    container_name: investment-portfolio-backend
    environment:
      - DB_DIR=/data/db
      - LOG_DIR=/data/logs
      - DOMAIN=${DOMAIN:-localhost}
    volumes:
      - /path/to/your/data:/data
    networks:
      - app-network

  frontend:
    build:
      context: ./frontend
      args:
        - DOMAIN=${DOMAIN:-localhost}
        - USE_HTTPS=${USE_HTTPS:-false}
    container_name: investment-portfolio-frontend
    environment:
      - DOMAIN=${DOMAIN:-localhost}
      - USE_HTTPS=${USE_HTTPS:-false}
    ports:
      - "80:80"
    depends_on:
      - backend
    networks:
      - app-network</code>

但是，AWS 架构师的观点（以及定价计算器）建议采用无服务器方法：

• 每日价格更新和不频繁访问建议避免 24/7 容器。
• 静态前端文件非常适合 S3 网站托管。
• API 网关和 Lambda 将处理 API 调用。
• Aurora Serverless 适合关系数据。
• DynamoDB 可以存储价格历史记录（尽管我没有达到这个阶段）。

这让我陷入了无服务器的兔子洞。 我之前有过无服务器经验 - 与我的妻子一起进行温度跟踪项目，使用 KNMI 数据并为手工项目生成颜色编码表。

<code>| Date       | Min.Temp | Min.Kleur   | Max.Temp | Max.Kleur   |
----------------------------------------------------------------
| 2023-03-01 |   -4.1°C | darkblue   |    7.1°C | lightblue  |
| 2023-03-02 |    1.3°C | blue       |    6.8°C | lightblue  |
...</code>

该项目在本地运行或通过 Lambda/API Gateway 运行，采用日期参数。 事实证明，将其扩展到具有 SQLAlchemy、后台作业和复杂关系的完整 Flask 应用程序具有挑战性。

无服务器的魅力

我的容器化应用程序运行良好，但无服务器服务的吸引力很强。 自动扩展和消除容器管理的潜力非常诱人。

因此，我为无服务器环境重新构建了我的应用程序。 最初的项目花了两个月的时间；这会是一件轻而易举的事……至少我是这么想的。

数据库决策

SQLite 对 Lambda 的限制让我考虑使用 PostgreSQL Aurora Serverless，以保持与我的 SQLAlchemy 知识的兼容性。 我创建了一个双处理程序：

<code>services:
  backend:
    build: ./backend
    container_name: investment-portfolio-backend
    environment:
      - DB_DIR=/data/db
      - LOG_DIR=/data/logs
      - DOMAIN=${DOMAIN:-localhost}
    volumes:
      - /path/to/your/data:/data
    networks:
      - app-network

  frontend:
    build:
      context: ./frontend
      args:
        - DOMAIN=${DOMAIN:-localhost}
        - USE_HTTPS=${USE_HTTPS:-false}
    container_name: investment-portfolio-frontend
    environment:
      - DOMAIN=${DOMAIN:-localhost}
      - USE_HTTPS=${USE_HTTPS:-false}
    ports:
      - "80:80"
    depends_on:
      - backend
    networks:
      - app-network</code>

Lambda 学习曲线

将 Flask 应用程序转换为 Lambda 函数比预期的更复杂。 我最初的尝试很笨拙：

<code>| Date       | Min.Temp | Min.Kleur   | Max.Temp | Max.Kleur   |
----------------------------------------------------------------
| 2023-03-01 |   -4.1°C | darkblue   |    7.1°C | lightblue  |
| 2023-03-02 |    1.3°C | blue       |    6.8°C | lightblue  |
...</code>

为了提高可维护性，我创建了一个装饰器：

<code>@contextmanager
def db_session():
    # ... (code for environment-aware database session management) ...</code>

改进的 Lambda 函数结构：

<code># ... (initial, inefficient Lambda handler code) ...</code>

然而，这打破了Flask原来的路线。 新的装饰器启用了双重功能：

<code>def lambda_response(func):
    # ... (decorator for cleaner Lambda responses) ...</code>

支持功能确保一致的响应：

<code>@lambda_response
def get_portfolios(event, context):
    # ... (simplified Lambda function) ...</code>

这允许 Flask 和 Lambda 使用相同的路由：

<code>def dual_handler(route_path, methods=None):
    # ... (decorator for both Flask routes and Lambda handlers) ...</code>

前端简单性

前端很简单。 S3 静态网站托管和 CloudFront 提供轻松部署。 一个简单的脚本将前端上传到 S3 并使 CloudFront 缓存失效：

<code>def create_lambda_response(flask_response):
    # ... (function to convert Flask response to Lambda response format) ...

def create_flask_request(event):
    # ... (function to convert Lambda event to Flask request) ...</code>

结果

经过几周的工作，我的应用程序已经实现了无服务器。 虽然出于安全考虑我不会将其保留在网上，但我学到了宝贵的经验教训：

1. Python 的功能超出了脚本编写的范围。
2. AWS 免费套餐对于开发来说非常宝贵。
3. CloudWatch Logs 对于调试至关重要。
4. “正确”的方式并不总是 AWS 方式。

我可以重复一遍吗？可能不会。 但这次旅程是有益的，教会了我有关 Python 和双栈开发的知识。 我的投资组合经理现在可以在我的专用网络上安全运行。

以上是从 Docker 到 Lambda：AWS 管理员的 Python 应用程序之旅的详细内容。更多信息请关注PHP中文网其他相关文章！