شبکه، هویت و مجوز را جداگانه بررسی کنید
نام میزبان را از محیط اپلیکیشن بررسی کنید. اتصال روی لپتاپ، دسترسی از محیط اجرا را ثابت نمیکند. پروژههای پاستا ممکن است روی کلاسترها یا ناحیههای مختلف باشند؛ خصوصی یا مشترکبودن شبکه را فرض نکنید.
در PostgreSQL خودمیزبان، پذیرش اتصال به تنظیماتی مانند listen_addresses و قواعد pg_hba.conf وابسته است. این قواعد مبدا، دیتابیس، کاربر و روش احراز هویت مجاز را مشخص میکنند. در سرویس مدیریتشده، روش اعمال محدودیتها را از ارائهدهنده بگیرید. مستندات احراز هویت PostgreSQL
کاربر اجرای اپلیکیشن را از کاربر مدیریت و migration، یعنی تغییر ساختار دیتابیس، جدا کنید. فقط مجوزهای لازم روی دیتابیس، schema و اشیای مورد نیاز را بدهید. ورود موفق به سرور لزوماً به معنی اجازه خواندن یا نوشتن جدول نیست. مستندات مجوزها
رمز را با Secret به بکاند برسانید
رمز یا رشته اتصال حاوی آن را در Repository، Dockerfile، لاگ یا کد مرورگر قرار ندهید. پاستا از متغیر محیطی و Secret پشتیبانی میکند؛ تنظیمات محرمانه را از این مسیر به بکاند برسانید.
در Kubernetes، Base64 بودن Secret به معنی رمزنگاری نیست. دسترسی به Secret و حفاظت از ذخیرهسازی آن نیز اهمیت دارد. این توضیح درباره سازوکار عمومی Kubernetes است، نه تنظیمات داخلی پاستا. مستندات Secret
برای تفکیک تنظیمات عادی از اعتبارنامهها، راهنمای «ConfigMap و Secret؛ مدیریت امن تنظیمات» را دنبال کنید. بررسی کنید برنامه در پیام خطا رشته اتصال کامل را چاپ نکند.
اتصال TLS را با اعتبارسنجی سرور آزمایش کنید
HTTPS اپلیکیشن، اتصال PostgreSQL را رمزنگاری نمیکند؛ این دو مسیر جدا هستند.
در کلاینتهای مبتنی بر libpq، حالت verify-full زنجیره گواهی و نام میزبان سرور را بررسی میکند. سرور باید TLS داشته باشد و گواهی مرجع معتبر در اختیار کلاینت قرار بگیرد. require را معادل بررسی هویت میزبان ندانید. مستندات TLS در PostgreSQL
مثال فرضی: سرویس اطلاعات زیر را ارائه کرده و فایل CA را در مسیر مشخصشده قرار دادهاید. مقادیر را با اطلاعات سرویس خود جایگزین کنید؛ اینها مشخصات پاستا نیستند:
psql "host=db.example.com port=5432 dbname=appdb user=app_runtime sslmode=verify-full
sslrootcert=/path/to/ca.crt" -W
گزینه -W رمز را تعاملی میپرسد؛ رمز داخل دستور و history قرار نمیگیرد. هر بار اجرای دستور، جلسه اتصال تازهای باز میکند و دادهای را تغییر نمیدهد. مستندات psql
داخل جلسه اجرا کنید:
\conninfo
SELECT current_database(), current_user;
دستور اول اطلاعات اتصال و دستور دوم نام دیتابیس و کاربر فعلی را نشان میدهد. تکرارشان داده را تغییر نمیدهد. نتیجه باید با مقصد مورد نظر تطابق داشته باشد.
این آزمون دسترسی به جدولها را ثابت نمیکند. یک عملیات مورد نیاز برنامه را هم در محیط آزمایشی بررسی کنید. اگر TLS شکست خورد، نام میزبان و CA را بررسی و اصلاح کنید؛ اعتبارسنجی را خاموش نکنید. تنظیم معادل را در درایور اپلیکیشن نیز اعمال کنید.

اتصال موفق را به مدیریت دیتابیس قابل اتکا تبدیل کنید
برنامه را با تعداد اتصال نامحدود منتشر نکنید. Connection pool مجموعهای از اتصالهای قابل استفاده مجدد است. مجموع سقف pool نمونههای اپ و کارهای پسزمینه را با ظرفیت سرویس تطبیق دهید و برای عملیات مدیریتی جا بگذارید. افزایش تعداد نمونههای اپ میتواند سقف اتصال همزمان PostgreSQL را مصرف کند. مستندات تنظیمات اتصال
دیسک پایدار جای بکاپ نیست. پیش از ورود داده واقعی، مشخص کنید چه میزان از داده اخیر قابل ازدسترفتن است و بازیابی چقدر میتواند طول بکشد. سپس روش بکاپ را انتخاب کنید؛ از جمله dump یا آرشیو پیوسته برای بازیابی. مستندات بکاپ و بازیابی
یک نسخه را در مقصد جداگانه بازیابی و با اپ آزمایش کنید. برای برنامهریزی، «استراتژی بکاپ دیتابیس که واقعاً نجاتتان میدهد» را دنبال کنید. وجود قابلیت بکاپ در پاستا، سیاست نگهداری یا بازیابی تا یک لحظه مشخص را برای هر پلن ثابت نمیکند.
برای عملیات از ایران، دسترسی به مقصد بکاپ و منابع دریافت ابزارها را از محیط اجرای همان عملیات بسنجید. این آزمون را به زمان اختلال موکول نکنید.
خطاهای اتصال را از روی نشانه تفکیک کنید
اتصال از محیط اپلیکیشن برقرار نمیشود
-
آنچه کاربر میبیند: درخواست اتصال منتظر میماند یا پیش از ورود رد میشود.
-
علتهای محتمل و تأییدشده: میزبان یا پورت اشتباه، محدودیت شبکه یا نپذیرفتن اتصال روی آدرس مورد نظر.
-
روش تشخیص: مقصد و دسترسی را از محیط اپ بررسی و با وضعیت سرور مقایسه کنید.
-
اقدام بعدی: مسیر یا قاعده دسترسی را اصلاح کنید؛ دسترسی عمومی گسترده نسازید.
-
آیا داده کاربر در خطر است؟ شکست اتصال اولیه نشانه حذف داده نیست؛ وضعیت نوشتنهایی که اتصالشان قطع شده را جدا بررسی کنید.
سرور در دسترس است، اما ورود پذیرفته نمیشود
-
آنچه کاربر میبیند: برنامه به احراز هویت میرسد، ولی جلسه باز نمیشود.
-
علتهای محتمل و تأییدشده: اعتبارنامه نادرست یا قواعد دسترسی ناسازگار با کاربر و مبدأ.
-
روش تشخیص: نام کاربر، دیتابیس و Secret مورد استفاده را بدون چاپ رمز بررسی کنید.
-
اقدام بعدی: اعتبارنامه یا قاعده مربوط را اصلاح و دریافت مقدار تازه توسط اپ را بررسی کنید.
-
آیا داده کاربر در خطر است؟ این نشانه حذف یا افشای داده را ثابت نمیکند؛ اعطای دسترسی مدیریتی راهحل آن نیست.
اتصال با اعتبارسنجی گواهی شکست میخورد
-
آنچه کاربر میبیند: کلاینت اتصال TLS معتبر برقرار نمیکند.
-
علتهای محتمل و تأییدشده: CA نامعتبر یا ناقص، یا تطابقنداشتن نام میزبان با گواهی.
-
روش تشخیص: فایل CA و نام میزبان را با اطلاعات سرویس تطبیق دهید.
-
اقدام بعدی: گواهی یا مقصد را اصلاح کنید؛ غیرفعالکردن بررسی هویت، رفع علت نیست.
-
آیا داده کاربر در خطر است؟ رد اتصال نشانه حذف داده نیست؛ حذف اعتبارسنجی میتواند حفاظت اتصال را کاهش دهد.
چکلیست پیش از ورود داده واقعی
-
نسخه و افزونههای موردنیاز با پلن انتخابی سازگارند.
-
اتصال را از محیط اپلیکیشن آزمایش کردهاید.
-
کاربر اجرا مجوز مدیریتی غیرضروری ندارد.
-
رمز در سورس، لاگ و history نیست.
-
کلاینت هویت سرور TLS را بررسی میکند.
-
مجموع ظرفیت pool ها با سقف اتصال سازگار است.
-
بکاپ را در مقصد جداگانه بازیابی کردهاید.
-
هزینه، نگهداری بکاپ و مسئول ارتقا مشخصاند.
تصمیم را بر اساس مسئولیت عملیات بگیرید
اگر امکانات سرویس نیاز برنامه را پوشش میدهد و میخواهید بخشی از نگهداری را واگذار کنید، دیتابیس مدیریتشده را بررسی کنید. نیاز به تنظیمات خارج از سرویس میتواند دلیل خودمیزبانی باشد؛ مشروط به پذیرش مسئولیت عملیات.
قدم بعدی، بررسی گزینههای دیتابیس مدیریتشده پاستا و تطبیق نسخه، اتصال و شرایط بازیابی با نیاز اپلیکیشن شماست.