استقرار پراکسی‌های API بااستفاده از API

درحال مشاهده اسناد Apigee Edge هستید.
به اسناد Apigee X بروید.
اطلاعات

هر سازمانی چرخه عمر توسعه نرم‌افزار (SDLC) منحصربه‌فردی دارد. اغلب لازم است استقرار پراکسی API با فرایندهای استفاده‌شده برای سرویس‌های زیرینه همگام‌سازی و هماهنگ شود.

از روش‌های «میانای برنامه‌سازی کاربردی Edge» که در این موضوع نشان داده شده است می‌توان برای ادغام مدیریت پراکسی API در «چرخه توسعه نرم‌افزار» سازمانتان استفاده کرد. یکی از کاربردهای رایج این API نوشتن دستورگان یا کد برای استقرار پراکسی‌های API یا انتقال پراکسی‌های API از یک محیط به محیط دیگر به‌عنوان بخشی از فرایند خودکارسازی بزرگ‌تری است که برنامه‌های دیگر را نیز مستقر یا منتقل می‌کند.

‫Edge API هیچ فرضی درباره SDLC شما (یا هر کس دیگری) ندارد. بلکه، این API توابع اتمی را آشکار می‌کند که تیم توسعه شما می‌تواند آن‌ها را هماهنگ کند تا چرخه حیات توسعه API شما را خودکارسازی و بهینه کند.

برای اطلاعات کامل، میاناهای برنامه‌سازی کاربردی Edge را ببینید.

برای استفاده از Edge API، باید خودتان را در تماس‌هایتان اصالت‌سنجی کنید. می‌توانید این کار را با یکی از روش‌های زیر انجام دهید:

این موضوع بر مجموعه میاناهای برنامه‌سازی کاربردی که برای مدیریت پراکسی‌های میانای برنامه‌سازی کاربردی هستند تمرکز دارد.

ویدیو: برای آشنایی با نحوه استقرار یک API، این ویدیو کوتاه را ببینید.

تعامل با «میانای برنامه‌سازی کاربردی»

مراحل زیر شما را در تعاملات ساده با «میاناهای برنامه‌سازی کاربردی» راهنمایی می‌کند.

فهرست کردن «میاناهای برنامه‌سازی کاربردی» در سازمان شما

می‌توانید با فهرست کردن همه پراکسی‌های API در سازمانتان شروع کنید. (به‌خاطر داشته باشید که ورودی‌های را برای EMAIL:PASSWORD و ORG_NAME جایگزین کنید. برای دریافت دستورالعمل‌ها، به استفاده از Edge API مراجعه کنید.

curl -u EMAIL:PASSWORD \
  https://api.enterprise.apigee.com/v1/o/ORG_NAME/apis

پاسخ نمونه:

[ "weatherapi" ]

دریافت میانای برنامه‌سازی کاربردی

می‌توانید روش GET را در هر پراکسی API در سازمانتان فراخوانی کنید. این تماس فهرستی از همه نسخه‌های اصلاح‌شده دردسترس پراکسی API را برمی‌گرداند.

curl -u EMAIL:PASSWORD -H "Accept: application/json" \
  https://api.enterprise.apigee.com/v1/o/ORG_NAME/apis/weatherapi

پاسخ نمونه:

{
  "name" : "weatherapi",
  "revision" : [ "1" ]
}

تنها جزئیاتی که این روش برمی‌گرداند نام پراکسی API به‌همراه نسخه منسوب است که شماره منسوب دارد. پراکسی‌های میانای برنامه‌سازی کاربردی از بسته‌ای از فایل‌های پیکربندی تشکیل شده‌اند. بازبینی‌ها سازوکار سبکی برای مدیریت به‌روزرسانی‌های پیکربندی شما درحین تکرار ارائه می‌دهند. بازبینی‌ها به‌ترتیب شماره‌گذاری می‌شوند و به شما امکان می‌دهند با استقرار بازبینی قبلی کارگزار پراکسی API، تغییر را برگردانید. همچنین می‌توانید نسخه اصلاح‌شده یک پراکسی API را در محیط تولید مستقر کنید، درحالی‌که به ایجاد نسخه‌های اصلاح‌شده جدید از آن پراکسی API در محیط آزمایش ادامه می‌دهید. وقتی آماده بودید، می‌توانید نسخه بازبینی بالاتر کارگزار API خود را از محیط آزمایش به نسخه بازبینی قبلی کارگزار API در محیط تولید ارتقا دهید.

در این مثال، فقط یک بازبینی وجود دارد زیرا پراکسی API به‌تازگی ایجاد شده است. وقتی کارگزار API از چرخه حیات پیکربندی و استقرار تکرارشونده عبور می‌کند، عدد بازبینی با اعداد صحیح افزایش می‌یابد. بااستفاده از فراخوانی‌های مستقیم میانای برنامه‌سازی کاربردی برای استقرار، می‌توانید به‌صورت اختیاری عدد بازبینی میانای برنامه‌سازی کاربردی را افزایش دهید. گاهی اوقات وقتی تغییرات جزئی ایجاد می‌کنید، ممکن است نخواهید نسخه را افزایش دهید.

دریافت نسخه اصلاح‌شده میانای برنامه‌سازی کاربردی

نسخه «میانای برنامه‌سازی کاربردی» (برای نمونه، api.company.com/v1) باید به‌ندرت تغییر کند. وقتی نسخه میانای برنامه‌سازی کاربردی را افزایش می‌دهید، به توسعه‌دهندگان نشان می‌دهد که تغییر قابل‌توجهی در امضای واسط خارجی که توسط میانای برنامه‌سازی کاربردی نمایان شده است رخ داده است.

نسخه پراکسی API یک عدد افزایشی مرتبط با پیکربندی پراکسی API است. «سرویس‌های API» نسخه‌های بازبینی پیکربندی‌های شما را حفظ می‌کند تا درصورت بروز مشکل بتوانید پیکربندی را به حالت قبل برگردانید. به‌طور پیش‌فرض، هر بار که یک کارگزار پروکسی API را بااستفاده از API وارد کردن کارگزار پروکسی API وارد می‌کنید، نسخه اصلاحی کارگزار پروکسی API به‌طور خودکار افزایش می‌یابد. اگر نمی‌خواهید نسخه بازبینی کارگزار نیابتی میانای برنامه‌سازی کاربردی را افزایش دهید، از میانای برنامه‌سازی کاربردی به‌روزرسانی نسخه بازبینی کارگزار نیابتی میانای برنامه‌سازی کاربردی استفاده کنید. اگر از Maven برای استقرار استفاده می‌کنید، از گزینه‌های clean یا update، همان‌طور که در فایل خودخوان افزایه Maven توضیح داده شده است، استفاده کنید.

برای مثال، می‌توانید روش GET را در نسخه اصلاح‌شده 1 پراکسی API فراخوانی کنید تا نمای دقیقی دریافت کنید.

curl -u EMAIL:PASSWORD -H "Accept:application/json" \
  https://api.enterprise.apigee.com/v1/o/ORG_NAME/apis/weatherapi/revisions/1

پاسخ نمونه

{
  "configurationVersion" : {
    "majorVersion" : 4,
    "minorVersion" : 0
  },
  "contextInfo" : "Revision 1 of application weatherapi, in organization {org_name}",
  "createdAt" : 1343178905169,
  "createdBy" : "andrew@apigee.com",
  "lastModifiedAt" : 1343178905169,
  "lastModifiedBy" : "andrew@apigee.com",
  "name" : "weatherapi",
  "policies" : [ ],
  "proxyEndpoints" : [ ],
  "resources" : [ ],
  "revision" : "1",
  "targetEndpoints" : [ ],
  "targetServers" : [ ],
  "type" : "Application"
}

این عناصر پیکربندی پراکسی API در مرجع پیکربندی پراکسی API به‌طور مفصل مستند شده‌اند.

استقرار دادن میانای برنامه‌سازی کاربردی در محیط

پس‌از اینکه پراکسی API شما برای دریافت و بازارسال درست درخواست‌ها پیکربندی شد، می‌توانید آن را در یک یا چند محیط مستقر کنید. معمولاً در test روی پراکسی‌های API تکرار می‌کنید و سپس، وقتی آماده شد، نسخه اصلاح‌شده پراکسی API را به prod ارتقا می‌دهید. اغلب متوجه خواهید شد که نسخه‌های بازبینی بسیار بیشتری از پراکسی API در محیط آزمایش دارید، عمدتاً به این دلیل که تکرار بسیار کمتری در محیط تولید انجام خواهید داد.

تا زمانی که کارگزار نیابتی API در محیطی مستقر نشده باشد، نمی‌توان آن را فراخوانی کرد. پس‌از اینکه نسخه بازبینی کارگزار نیابتی API را در محیط تولید مستقر کردید، می‌توانید نشانی وب prod را برای توسعه‌دهندگان برون‌سازمانی منتشر کنید.

نحوه فهرست کردن محیط‌ها

هر سازمان در Apigee Edge حداقل دو محیط دارد: test و prod. این تمایز خودسرانه است. هدف این است که فضایی دراختیارتان قرار دهیم تا قبل‌از اینکه پراکسی API خود را دراختیار توسعه‌دهندگان خارجی قرار دهید، عملکرد صحیح آن را بررسی کنید.

هر محیط درواقع فقط یک نشانی شبکه است که به شما امکان می‌دهد ترافیک را بین پراکسی‌های میانای برنامه‌سازی کاربردی که روی آن‌ها کار می‌کنید و پراکسی‌هایی که برنامه‌ها در زمان اجرا به آن‌ها دسترسی دارند تفکیک کنید.

محیط‌ها همچنین داده‌ها و منابع را تفکیک می‌کنند. برای مثال، می‌توانید در محیط‌های آزمایش و تولید، حافظه‌های نهان مختلفی راه‌اندازی کنید که فقط ازطریق پراکسی‌های میانای برنامه‌سازی کاربردی که در آن محیط اجرا می‌شوند قابل‌دسترسی باشند.

مشاهده محیط‌ها در سازمان

curl -u EMAIL:PASSWORD \
  https://api.enterprise.apigee.com/v1/o/ORG_NAME/environments

پاسخ نمونه

[ "test", "prod" ]

کاوش پیاده‌سازی‌ها

استقرار یک بازبینی از پراکسی API است که در یک محیط مستقر شده است. کارگزار میانای برنامه‌سازی کاربردی که در وضعیت استقراریافته باشد ازطریق شبکه و در نشانی‌های تعریف‌شده در عنصر <VirtualHost> برای آن محیط دردسترس است.

استقرار پراکسی‌های میانای برنامه‌سازی کاربردی

تا زمانی که پراکسی‌های API مستقر نشده باشند، نمی‌توان آن‌ها را فراخوانی کرد. «سرویس‌های API» میاناهای برنامه‌سازی کاربردی RESTful را آشکار می‌کند که بر فرایند استقرار کنترل ارائه می‌دهد.

در هر زمان معین، فقط یک نسخه بازبینی از پراکسی API می‌تواند در محیطی مستقر شود. بنابراین نسخه پیاده‌شده باید لغو پیاده‌سازی شود. می‌توانید کنترل کنید که آیا دسته جدید به‌عنوان بازبینی جدید پیاده‌سازی شود یا بازبینی موجود را بازنویسی کند.

درحال مشاهده اسناد Apigee Edge هستید.
به اسناد Apigee X بروید.
اطلاعات

ابتدا نسخه اصلاح‌شده موجود را لغو استقرار کنید. نام محیط و شماره بازبینی کارگزار پراکسی API را که می‌خواهید لغو استقرار کنید مشخص کنید:

curl -X DELETE \
  https://api.enterprise.apigee.com/v1/o/ORG_NAME/environments/ENV_NAME/apis/API_NAME/revisions/REVISION_NUMBER/deployments \
  -u EMAIL:PASSWORD

سپس نسخه جدید را مستقر کنید. نسخه جدید بازبینی کارگزار پراکسی API باید ازقبل وجود داشته باشد:

curl -X POST -H "Content-type:application/x-www-form-urlencoded" \
  https://api.enterprise.apigee.com/v1/o/ORG_NAME/environments/ENV_NAME/apis/API_NAME/revisions/REVISION_NUMBER/deployments \
  -u EMAIL:PASSWORD

استقرار یکپارچه (بدون زمان اَکار)

برای به‌حداقل رساندن احتمال زمان اَکار درطول استقرار، از پارامتر override در روش استقرار استفاده کنید و آن را روی true تنظیم کنید.

نمی‌توانید یک نسخه مرور از پراکسی API را روی نسخه دیگری مستقر کنید. اولین مورد همیشه باید ازهم باز شود. با تنظیم override روی true، نشان می‌دهید که یک بازبینی از پراکسی API باید روی بازبینی درحال استقرار مستقر شود. نتیجه این است که توالی استقرار معکوس می‌شود--نسخه جدید مستقر می‌شود، و پس‌از تکمیل استقرار، نسخه قبلاً مستقر شده لغو استقرار می‌شود.

مثال زیر مقدار override را با ارسال آن به‌عنوان پارامتر فرم تنظیم می‌کند:

curl -X POST -H "Content-type:application/x-www-form-urlencoded" \
  https://api.enterprise.apigee.com/v1/o/ORG_NAME/e/ENV_NAME/apis/API_NAME/revisions/REVISION_NUMBER/deployments" \
  -d "override=true" \
  -u EMAIL:PASSWORD

با تنظیم پارامتر delay می‌توانید استقرار را بیشتر بهینه‌سازی کنید. پارامتر delay فاصله زمانی را برحسب ثانیه مشخص می‌کند که قبل‌از آن نسخه قبلی باید لغو استقرار شود. تأثیر این است که تراکنش‌های درحال انجام یک بازه زمانی دارند که در آن باید تکمیل شوند، وگرنه کارگزار میانای برنامه‌سازی کاربردی که تراکنش آن‌ها را پردازش می‌کند ازکار می‌افتد. در ادامه آنچه با override=true و پارامتر delay تنظیم‌شده رخ می‌دهد آمده است:

  • نسخه ۱ درحال رسیدگی به درخواست‌ها است.
  • نسخه اصلاح‌شده ۲ به‌صورت موازی درحال استقرار است.
  • وقتی «بازبینی ۲» به‌طور کامل مستقر شد، ترافیک جدید به «بازبینی ۲» ارسال می‌شود. ترافیک جدیدی به «بازبینی ۱» ارسال نمی‌شود.
  • بااین‌حال، «بازبینی ۱» ممکن است همچنان درحال پردازش تراکنش‌های موجود باشد. با تنظیم پارامتر delay (برای مثال، ۱۵ ثانیه)، به «نسخه اصلاح‌شده ۱» ۱۵ ثانیه فرصت می‌دهید تا پردازش تراکنش‌های موجود را تمام کند.
  • پس‌از فاصله تأخیر، «نسخه اصلاح‌شده ۱» لغو استقرار می‌شود.
curl -X POST -H "Content-type:application/x-www-form-urlencoded" \
  https://api.enterprise.apigee.com/v1/o/ORG_NAME/e/ENV_NAME/apis/API_NAME/revisions/REVISION_NUMBER/deployments?delay=15" \
  -d "override=true" \
  -u EMAIL:PASSWORD
پارامتر پُرسمان شرح
override

پیش‌فرض false است (عملکرد استقرار معمولی: نسخه اصلاح‌شده موجود لغو استقرار می‌شود، سپس نسخه اصلاح‌شده جدید مستقر می‌شود).

برای ملغی کردن رفتار استقرار عادی و ارائه استقرار یکپارچه، روی true تنظیم کنید. نسخه اصلاح‌شده موجود همچنان مستقر می‌ماند و نسخه اصلاح‌شده جدید نیز درحال استقرار است. وقتی نسخه جدید گسترش داده می‌شود، نسخه قدیمی گسترش داده نمی‌شود. برای کنترل زمان لغو استقرار، همراه با پارامتر delay استفاده کنید.

delay

برای اینکه پردازش تراکنش در نسخه اصلاح‌شده موجود قبل‌از برداشتن استقرار تکمیل شود—و احتمال 502 Bad Gateway یا 504 Gateway Timeout errors را ازبین ببرید—این پارامتر را روی تعداد ثانیه‌هایی که می‌خواهید برداشتن استقرار به‌تأخیر بیفتد تنظیم کنید. هیچ محدودیتی برای تعداد ثانیه‌هایی که می‌توانید تنظیم کنید وجود ندارد و هیچ پیامد عملکردی برای تنظیم تعداد زیادی ثانیه وجود ندارد. درطول این تأخیر، هیچ ترافیک جدیدی به نسخه قدیمی ارسال نمی‌شود.

پیش‌فرض ۰ (صفر) ثانیه است. وقتی override روی درست تنظیم شده باشد و delay روی ۰ تنظیم شده باشد، نسخه اصلاح موجود بلافاصله پس‌از استقرار نسخه اصلاح جدید لغو استقرار می‌شود. مقادیر منفی به‌عنوان ۰ (صفر) ثانیه درنظر گرفته می‌شوند.

وقتی override=true همراه با delay استفاده می‌شود، پاسخ‌های HTTP 5XX درطول استقرار می‌تواند حذف شود. دلیل این است که هر دو نسخه بازبینی کارگزار نیابتی API به‌طور هم‌زمان مستقر می‌شوند و نسخه بازبینی قدیمی‌تر پس‌از تأخیر مستقر نمی‌شود.

دیدن همه استقرارها در نسخه API

گاهی لازم است فهرستی از همه نسخه‌های بازبینی استقراریافته فعلی یک پراکسی API واکشی شود.

curl https://api.enterprise.apigee.com/v1/o/ORG_NAME/apis/weatherapi/revisions/1/deployments \
  -u EMAIL:PASSWORD
{
  "aPIProxy" : "weatherapi",
  "environment" : [ {
    "configuration" : {
      "basePath" : "",
      "steps" : [ ]
    },
    "name" : "test",
    "server" : [ {
      "status" : "deployed",
      "type" : [ "message-processor" ],
      "uUID" : "90096dd1-1019-406b-9f42-fbb80cd01200"
    }, {
      "status" : "deployed",
      "type" : [ "message-processor" ],
      "uUID" : "7d6e2eb1-581a-4db0-8045-20d9c3306549"
    }, {
      "status" : "deployed",
      "type" : [ "router" ],
      "uUID" : "1619e2d7-c822-45e0-9f97-63882fb6a805"
    }, {
      "status" : "deployed",
      "type" : [ "router" ],
      "uUID" : "8a5f3d5f-46f8-4e99-b4cc-955875c8a8c8"
    } ],
    "state" : "deployed"
  } ],
  "name" : "1",
  "organization" : "org_name"
}

پاسخ بالا حاوی بسیاری از ویژگی‌های خاص زیرساخت داخلی Apigee Edge است. مگر اینکه از Apigee Edge در محل استفاده کنید، نمی‌توانید این تنظیمات را تغییر دهید.

دارایی‌های مهم موجود در پاسخ عبارت‌اند از organization، environment، aPIProxy، name، و state. با مرور کردن این مقادیر دارایی، می‌توانید تأیید کنید که نسخه اصلاح‌شده خاصی از پراکسی API در محیطی استقرار یافته است.

دیدن همه استقرارها در محیط آزمایش

همچنین می‌توانید وضعیت استقرار را برای محیطی خاص (ازجمله شماره بازبینی کارگزار پراکسی API مستقرشده فعلی) بااستفاده از تماس زیر بازیابی کنید:

curl -u EMAIL:PASSWORD
  https://api.enterprise.apigee.com/v1/o/ORG_NAME/environments/test/deployments

این دستور همان نتیجه بالا را برای هر API مستقرشده در محیط آزمایش برمی‌گرداند

دیدن همه استقرارها در سازمان شما

برای واکشی فهرست همه نسخه‌های پیاده‌سازی‌شده فعلی همه پراکسی‌های API در همه محیط‌ها، از روش API زیر استفاده کنید:

curl https://api.enterprise.apigee.com/v1/o/ORG_NAME/deployments \
  -u EMAIL:PASSWORD

این دستور همان نتیجه بالا را برای همه پراکسی‌های API که در همه محیط‌ها مستقر شده‌اند برمی‌گرداند.

ازآنجایی‌که API از نوع RESTful است، می‌توانید به‌سادگی از روش POST، به‌همراه داده‌بر JSON یا XML دربرابر همان منبع برای ایجاد پراکسی API استفاده کنید.

نمایه‌ای برای پراکسی API شما تولید می‌شود. نمایش پیش‌فرض پراکسی API در نشان‌گذاری شیء جاوا اسکریپت (JSON) است. در زیر پاسخ JSON پیش‌فرض به درخواست POST در بالا آمده است که یک پراکسی API به‌نام weatherapi ایجاد کرده است. توضیح هر عنصر در نمایه در زیر آمده است:

{
  "configurationVersion" : {
    "majorVersion" : 4,
    "minorVersion" : 0
  },
  "contextInfo" : "Revision 1 of application weatherapi, in organization {org_name}",
  "createdAt" : 1357172145444,
  "createdBy" : "you@yourcompany.com",
  "displayName" : "weatherapi",
  "lastModifiedAt" : 1357172145444,
  "lastModifiedBy" : "you@yourcompany.com",
  "name" : "weatherapi",
  "policies" : [ ],
  "proxyEndpoints" : [ ],
  "resources" : [ ],
  "revision" : "1",
  "targetEndpoints" : [ ],
  "targetServers" : [ ],
  "type" : "Application"
}

نمایه پراکسی میانای برنامه‌سازی کاربردی تولیدشده ساختار کامل پراکسی میانای برنامه‌سازی کاربردی را نشان می‌دهد:

  • APIProxy revision: تکرار شماره‌گذاری ترتیبی پیکربندی پراکسی API که توسط «خدمات API» نگهداری می‌شود
  • ‫APIProxy name: نام یکتای پراکسی API
  • ConfigurationVersion: نسخه «سرویس‌های API» که پیکربندی کارگزار API با آن مطابقت دارد
  • ‫CreatedAt: زمان تولید پراکسی میانای برنامه‌سازی کاربردی، قالب‌بندی‌شده در زمان یونیکس
  • CreatedBy: نشانی ایمیل کاربر Apigee Edge که پراکسی API را ایجاد کرده است
  • ‫DisplayName: نام کاربرپسند برای پراکسی API
  • ‫LastModifiedAt: زمان تولید پراکسی میانای برنامه‌سازی کاربردی، قالب‌بندی‌شده در زمان یونیکس
  • LastModifiedBy: نشانی ایمیل کاربر Apigee Edge که پراکسی API را ایجاد کرده است
  • Policies: فهرستی از خط‌مشی‌هایی که به این پراکسی API اضافه شده است
  • ProxyEndpoints: فهرستی از ProxyEndpoints نام‌گذاری‌شده
  • ‫Resources: فهرستی از منابع (JavaScript،‏ Python،‏ Java،‏ XSLT) که برای اجرا در این پراکسی API دردسترس است
  • TargetServers: فهرستی از «سرورهای هدف» نام‌گذاری‌شده (که می‌توانند بااستفاده از management API ایجاد شوند)، که در پیکربندی‌های پیشرفته برای اهداف تراز بار استفاده می‌شوند
  • TargetEndpoints: فهرستی از «نقطه‌های پایانی هدف» نام‌گذاری‌شده

توجه داشته باشید که بسیاری از عناصر پیکربندی پراکسی API که بااستفاده از روش ساده POST در بالا ایجاد شده‌اند، خالی هستند. در موضوعات زیر، با نحوه افزودن و پیکربندی کردن اجزای کلیدی پراکسی API آشنا خواهید شد.

همچنین می‌توانید درباره این عناصر پیکربندی در مرجع پیکربندی پراکسی API بخوانید.

دستورگان‌نویسی دربرابر میانای برنامه‌سازی کاربردی

استفاده از پراکسی‌های API نمونه، که در GitHub دردسترس است، پوسته‌هایی را ارائه می‌دهد که ابزار استقرار Apigee را می‌پیچند. اگر به دلیلی نمی‌توانید از ابزار استقرار Python استفاده کنید، می‌توانید مستقیماً با API تماس بگیرید. هر دو رویکرد در نمونه متن‌های زیر نشان داده شده است.

پیچیدن ابزار استقرار

ابتدا مطمئن شوید که ابزار استقرار Python در محیط محلی شما دردسترس باشد.

سپس فایلی برای نگهداری اطلاعات اعتباری‌تان ایجاد کنید. دستورگان استقراری که می‌نویسید این تنظیمات را وارد می‌کند و به شما کمک می‌کند تا اطلاعات اعتباری حسابتان را به‌صورت مرکزی مدیریت کنید. در نمونه پلاتفرم API، این فایل setenv.sh نامیده می‌شود.

#!/bin/bash

org="Your ORG on enterprise.apigee.com"
username="Your USERNAME on enterprise.apigee.com"

# While testing, it's not necessary to change the setting below
env="test"
# Change the value below only if you have an on-premise deployment
url="https://api.enterprise.apigee.com"
# Change the value below only if you have a custom domain
api_domain="apigee.net"

export org=$org
export username=$username
export env=$env
export url=$url
export api_domain=$api_domain

فایل بالا همه تنظیمات شما را برای دستورات پوسته که ابزار استقرار را می‌پیچند دردسترس قرار می‌دهد.

اکنون دستورگان پوسته‌ای ایجاد کنید که آن تنظیمات را وارد می‌کند و از آن‌ها برای فراخوانی ابزار پیاده‌سازی استفاده می‌کند. (برای نمونه، نمونه‌های پلاتفرم Apigee API را ببینید.)

#!/bin/bash

source path/to/setenv.sh

echo "Enter your password for the Apigee Enterprise organization $org, followed by [ENTER]:"

read -s password

echo Deploying $proxy to $env on $url using $username and $org

path/to/deploy.py -n {api_name} -u $username:$password -o $org -h $url -e $env -p / -d path/to/apiproxy

برای اینکه کارتان واقعاً آسان شود، یک دستورگان هم برای فراخوانی و آزمایش کردن «میانای برنامه‌سازی کاربردی» ایجاد کنید، به این صورت: :

#!/bin/bash

echo Using org and environment configured in /setup/setenv.sh

source /path/to/setenv.sh

set -x

curl "http://$org-$env.apigee.net/{api_basepath}"

فراخوانی مستقیم API

نوشتن دستورگان‌های ساده شل که فرایند بارگذاری و استقرار پراکسی‌های API را خودکارسازی می‌کنند می‌تواند مفید باشد.

اسکریپت زیر مستقیماً API مدیریت را فراخوانی می‌کند. نسخه اصلاح‌شده موجود از پراکسی API را که درحال به‌روزرسانی آن هستید لغو استقرار می‌کند، از دایرکتوری /apiproxy حاوی فایل‌های پیکربندی پراکسی شما فایل ZIP ایجاد می‌کند، و سپس پیکربندی را بارگذاری، وارد، و مستقر می‌کند.

#!/bin/bash

#This sets the name of the API proxy and the basepath where the API will be available
api=api

source /path/to/setenv.sh

echo Delete the DS_store file on OSX

echo find . -name .DS_Store -print0 | xargs -0 rm -rf
find . -name .DS_Store -print0 | xargs -0 rm -rf

echo "Enter your password for the Apigee Enterprise organization $org, followed by [ENTER]:"

read -s password

echo Undeploy and delete the previous revision

# Note that you need to explicitly update the revision to be undeployed.
# One benefit of the Python deploy tool is that it manages this for you.

curl -k -u $username:$password "$url/v1/o/$org/e/$env/apis/$api/revisions/1/deployments" -X DELETE

curl -k -u $username:$password -X DELETE "$url/v1/o/$org/apis/$api/revisions/1"

rm -rf $api.zip

echo Create the API proxy bundle and deploy

zip -r $api.zip apiproxy

echo Import the new revision to $env environment 

curl -k -v -u $username:$password "$url/v1/o/$org/apis?action=import&name=$api" -T $api.zip -H "Content-Type: application/octet-stream" -X POST

echo Deploy the new revision to $env environment 

curl -k -u $username:$password "$url/v1/o/$org/e/$env/apis/$api/revisions/1/deployments" -X POST