從 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中文網其他相關文章！