API Gateway स्टेज और रनटाइम कॉन्फ़िगरेशन

AWS पर Deployments को ऑटोमेट करना

Dunieski Otano

Amazon Web Services Solutions Architect

तीन URLs, एक API

• वही checkout API को dev, staging, और prod चाहिए
• हर environment अलग downstream resources पर जाता है
• वैल्यूज़ हार्डकोड करने से हर environment पर रिबिल्ड करना पड़ता है
• स्टेज variables इसे रनटाइम पर हल करते हैं

API Gateway स्टेज क्या है

• एक स्टेज API का डिप्लॉयमेंट है
• हर स्टेज का अपना URL होता है
• आम स्टेज: dev, staging, prod
• एक API परिभाषा, कई स्टेज

डिप्लॉयमेंट्स में स्टेज क्यों महत्वपूर्ण हैं

• Dev में टेस्ट करें बिना prod को प्रभावित किए
• उसी API को environments से प्रमोट करें
• एक स्टेज को बाकियों को छुए बिना रोल बैक करें
• हर स्टेज अपनी डिप्लॉयमेंट हिस्ट्री ट्रैक करता है

स्टेज variables

• Key-value पेयर्स एक स्टेज तक सीमित
• रेफरेंस करें: ${stageVariables.varName}
• प्रति-Environment कॉन्फ़िग के लिए उपयोग करें
• वैल्यू अलग हों तो भी कोड बदलने की जरूरत नहीं

स्टेज variables का उपयोग

• checkout-api -> dev स्टेज: lambdaAlias = dev
• checkout-api -> prod स्टेज: lambdaAlias = prod
• इंटीग्रेशन कॉल: payments:${stageVariables.lambdaAlias}
• एक API दो अलग Lambda aliases को हिट करता है

कस्टम डोमेन नेम्स

• डिफॉल्ट URL भद्दा है: abc123.execute-api.us-east-1.amazonaws.com/dev
• कस्टम डोमेन: api.example.com
  • TLS के लिए ACM certificate आवश्यक
• Base path mapping paths को stages से जोड़ता है
  • api.example.com/v1 → prod स्टेज

सब कैसे जुड़ता है

• स्टेज variables <-> Lambda aliases वीडियो 2.3 से
• यही विचार ECS task definition versions और DynamoDB table names पर भी लागू
• हर environment में स्वीकृत versions, कोई code changes नहीं
• अध्याय 3 इसे सेवाओं में और बढ़ाता है

अभ्यास करते हैं!

AWS पर Deployments को ऑटोमेट करना