מאפס לייצור: FastAPI ב-Fly.io וב-GitHub Actions

אתם דוחפים קוד ל-main. הבדיקות רצות. ה-API שלכם עולה לאוויר תוך דקות ספורות.

כך בונים תהליך פריסה (deployment pipeline) מקצועי. אתם לא זקוקים למסד נתונים או ל-Redis עבור ההגדרה הזו. אתם צריכים רק אפליקציית FastAPI אחת, Docker image אחד, קובץ קונפיגורציה (YAML config) אחד, ו-GitHub Actions workflow אחד.

תהליך העבודה נראה כך: git push → GitHub Actions → הרצת בדיקות → בניית image → פריסה ל-Fly.io → live

למערכת זו יש שלושה חלקים:

  • אפליקציית ה-FastAPI שלכם. אתם אורזים אותה בתוך Docker image כדי שהיא תרוץ באותו אופן בכל מקום.
  • Fly.io. הוא מריץ את ה-image שלכם על מכונות קטנות. הוא מטפל עבורכם בניתוב (routing) ובבדיקות תקינות (health checks).
  • GitHub Actions. הוא עוקב אחרי הקוד שלכם ופורס אותו באופן אוטומטי בכל push.

כדי להפוך את התהליך למאובטח, השתמשו ב-scoped deploy token. אל תשתמשו ב-Fly API token האישי שלכם. צרו token שיש לו הרשאה לגעת רק באפליקציה ספציפית אחת. שמרו את ה-token הזה ב-GitHub Secrets תחת השם FLY_API_TOKEN.

פרטים טכניים מרכזיים להגדרה שלכם:

  • השתמשו ב-Dockerfile עם משתמש שאינו root. זה משפר את האבטחה.
  • קשרו (Bind) את האפליקציה שלכם ל-0.0.0.0 בתוך ה-Dockerfile. אם תשתמשו ב-127.0.0.1, Fly לא יוכל להגיע לאפליקציה שלכם.
  • השתמשו בקובץ fly.yaml. הקובץ הזה הוא ה"מקור לאמת" (source of truth) שלכם. הוא מגדיר את האזור (region), הזיכרון והפורט (port).
  • הגדירו endpoint לבדיקת תקינות (health check) ב-FastAPI. Fly משתמש בזה כדי לוודא שהאפליקציה שלכם רצה לפני שהוא שולח אליה תעבורה. זה מאפשר פריסות ללא זמן השבתה (zero-downtime deployments).

ב-GitHub Actions workflow שלכם, השתמשו בפקודה "needs: test". זה מבטיח שהאפליקציה תפורס רק אם הבדיקות עוברות. אם הקוד שלכם שבור, ה-pipeline ייעצר לפני שהוא מגיע לסביבת הייצור (production).

ההגדרה הזו גדלה יחד איתכם. אתם יכולים להוסיף סביבות staging ו-production על ידי שימוש בקובצי קונפיגורציה שונים כמו fly.stg.yaml ו-fly.prod.yaml.

הפסיקו לבצע פריסות ידניות. עברו מ-"runs on my laptop" ל-"ships on every merge".

מקור: https://dev.to/devded/zero-to-production-fastapi-on-flyio-and-github-actions-1ejo