خرابی‌های پروکسی Terraform در دانلودها، ارائه‌دهندگان و اجراهای راه دور
دانلودهای رجیستری Terraform، دریافت ماژول‌های Git، فراخوانی‌های API ارائه‌دهنده و اجرای راه دور را زمانی که پروکسی فقط بخشی از یک اجرا را پوشش می‌دهد از هم تفکیک کنید.
موفقیت در دانلود یک ارائه‌دهنده چیز زیادی درباره فراخوانی بعدی API ابری نمی‌گوید. از نخستین نام میزبان و عملیاتی که شکست می‌خورد شروع کنید و سپس صاحب آن را مشخص کنید:
| عملیات | این مسیر را دنبال کنید |
|---|---|
| جست‌وجوی رجیستری یا دانلود نصب | فرایند Terraform، منبع نصب و محیط پروکسی |
| دریافت ماژول مبتنی بر Git | نشانی منبع و انتقال Git؛ SSH و HTTPS تنظیمات متفاوتی دارند |
| فراخوانی API ابری | افزونه ارائه‌دهنده و پیکربندی مسیریابی و اعتماد SDK آن |
| اجرای راه دور | محیط و شبکه اجراکننده، نه لپ‌تاپ |
برای پروکسی HTTP که CONNECT را پشتیبانی می‌کند، این مقدار محیط می‌تواند آن را برای مقصدهای HTTPS به‌درستی انتخاب کند:
HTTPS_PROXY=http://proxy.example:3128متغیر نام طرح مقصد را می‌آورد؛ مقدار نام انتقال پروکسی را می‌آورد. https:// را فقط زمانی به کار ببرید که شنونده TLS ارائه دهد و کلاینت درخواست‌دهنده آن را پشتیبانی کند. ارائه‌دهندگان افزونه‌های جداگانه‌اند و می‌توانند تنظیمات مخصوص SDK داشته باشند، پس این مقدار وعده‌ای درباره هر ارائه‌دهنده نیست.
در نزد صاحب مشخص‌شده، پیش از تغییر یک تنظیم لایه خطا را تفکیک کنید: اتصال پروکسی ردشده، پروکسی 407، CONNECT ردشده، خطای گواهی و 403 API ابری هرکدام بررسی بعدی را به شکل متفاوتی محدود می‌کنند. مرحله، مقصد، محیط اجرا و نخستین خطا را کنار هم نگه دارید.
تنظیم پشتیبانی‌شده را روی همان مؤلفه اعمال کنید. خروجی گرفتن روی لپ‌تاپ اجراکننده راه دور را پیکربندی نمی‌کند و اعتبارنامه‌های پروکسی به رجیستری یا API ابری احراز هویت نمی‌کنند.