Firebase Extensions পরিষেবাটি অপ্রচলিত হয়ে গেছে এবং এটি ৩১শে মার্চ, ২০২৭-এ বন্ধ হয়ে যাবে। যদিও ইতিমধ্যে ইনস্টল করা এক্সটেনশনগুলি অনির্দিষ্টকালের জন্য চালু থাকবে, এই তারিখের পর মূল ব্যবস্থাপনা বৈশিষ্ট্যগুলি আর উপলব্ধ থাকবে না। অতিরিক্ত মাইগ্রেশন নির্দেশিকা এবং সরঞ্জাম সেপ্টেম্বর ২০২৬-এ প্রকাশ করা হবে।
অবচয় ওভারভিউ
আমরা কেন Firebase Extensions বাতিল করছি?
আমাদের মূল Google Cloud পরিকাঠামোতে আসন্ন পরিবর্তন এবং পরিষেবা বাতিলের কারণে, আমরা পরিচালিত Firebase Extensions পরিষেবাটি বন্ধ করে দেব।
বিদ্যমান ডেপ্লয় করা এক্সটেনশনগুলো কি ৩১ মার্চ, ২০২৭-এর পর কাজ করা বন্ধ করে দেবে?
না। ইতিমধ্যে ডেপ্লয় করা এক্সটেনশনগুলি সরাসরি স্ট্যান্ডার্ড Google Cloud পরিকাঠামোতে (যেমন Cloud Functions , Eventarc , Cloud Run এবং Cloud Tasks ) চলে এবং অনির্দিষ্টকালের জন্য চলতে থাকবে।
তবে, ৩১ মার্চ, ২০২৭-এর পর, আপনি Firebase কনসোল বা সিএলআই (CLI)-এর মাধ্যমে এই এক্সটেনশনগুলি আপডেট, পুনঃকনফিগার বা আনইনস্টল করার সমস্ত ক্ষমতা হারাবেন। একটি ফাংশন কিটে স্থানান্তরের সুবিধার্থে আপনার বিদ্যমান এক্সটেনশন কনফিগারেশন ডাউনলোড করার ক্ষমতাও আপনি হারাবেন। আমরা ৩১ মার্চ, ২০২৭-এর মধ্যে এক্সটেনশন কনফিগারেশন স্থানান্তর বা এক্সপোর্ট করার জন্য দৃঢ়ভাবে সুপারিশ করছি।
ব্যবহারকারী যদি কিছুই না করে তাহলে কী হবে?
যদি কোনো ব্যবহারকারী কোনো পদক্ষেপ না নেন, তাহলে তাদের বিদ্যমান ডেপ্লয় করা ফাংশনগুলো স্ট্যান্ডার্ড অ্যাসেট হিসেবে চলতে থাকবে। তবে ৩১ মার্চ, ২০২৭-এর পর:
- তারা কনফিগারেশন প্যারামিটার পরিবর্তন করতে বা এনভায়রনমেন্ট ভেরিয়েবল আপডেট করতে পারে না।
- তারা বাগ ফিক্স, সিকিউরিটি প্যাচ বা ডিপেন্ডেন্সি আপগ্রেড প্রয়োগ করতে পারে না।
- তারা একটি প্রতিস্থাপন ফাংশন কিটকে হুবহু কনফিগার করতে সাহায্য করার জন্য এক্সটেনশন কনফিগারেশন ডাউনলোড করতে পারে না।
- অধিকাংশ এক্সটেনশন বর্তমানে লিগ্যাসি Cloud Functions v1 SDK-এর উপর ভিত্তি করে তৈরি, যা পুরোনো Node.js রানটাইমগুলোর সাথে আবদ্ধ। Google Cloud এই লিগ্যাসি রানটাইমগুলো সম্পূর্ণরূপে বন্ধ করে দিলে, ফাংশনগুলো কাজ করা বন্ধ করে দিতে পারে বা নিষ্ক্রিয় হয়ে যেতে পারে। রানটাইম সাপোর্ট দেখুন।
ফায়ারবেস এক্সটেনশনের বিকল্প কিছু কি আসছে?
এক্সটেনশনের বিকল্প হিসেবে Cloud Functions আরও কার্যকর করে তোলার জন্য আমরা এতে অনেক নতুন ফিচার যুক্ত করেছি। এর মধ্যে সবচেয়ে উল্লেখযোগ্য হলো ফাংশন কিট, যা npm ব্যবহার করে ডিস্ট্রিবিউট করা যায় এবং আপনাকে একটি প্রোজেক্টে একাধিকবার এক্সটেনশন ইনস্টল করার মতোই ফাংশনের একাধিক ইনস্ট্যান্স ডেপ্লয় করার সুযোগ দেয়।
তবে, প্রতিটি এক্সটেনশন প্রকাশক npm-এ একটি আনুষ্ঠানিক ফাংশন কিট প্রতিস্থাপন প্রকাশ করতে চান কিনা, সেই সিদ্ধান্ত নেওয়ার ভার তাদের উপরই। যেহেতু এক্সটেনশনগুলো ওপেন সোর্স, তাই প্রকাশক যদি কোনো আনুষ্ঠানিক প্রতিস্থাপন তৈরি করতে না চান, তবে যেকোনো ডেভেলপার আমাদের Node SDK-এর ২য় প্রজন্মের API ব্যবহার করে Cloud Functions মাধ্যমে একটি অনানুষ্ঠানিক প্রতিস্থাপন তৈরি করার জন্য এটিকে ফোর্ক করতে পারেন।
যেসব প্রকাশক প্রতিস্থাপন করতে ইচ্ছুক, তাদের প্রকাশকদের জন্য মাইগ্রেশন গাইডে দেওয়া নির্দেশনাগুলো অনুসরণ করা উচিত।
যেসব ব্যবহারকারী অফিসিয়াল রিপ্লেসমেন্ট প্যাকেজগুলোর সুবিধা নিতে চান বা নিজেদের রিপ্লেসমেন্ট তৈরি করতে চান, তারা ব্যবহারকারীদের জন্য মাইগ্রেশন গাইডে দেওয়া নির্দেশনাগুলো অনুসরণ করতে পারেন।
এক্সটেনশন ব্যবহারকারী হিসেবে আমার কী করা উচিত?
আপনি যদি এক্সটেনশন ব্যবহারকারী হন এবং আপনার ইনস্টল করা এক্সটেনশনগুলো আর ব্যবহার না করেন, তাহলে ৩১ মার্চ, ২০২৭-এর আগে সেগুলো আনইনস্টল করুন ।
নিষ্ক্রিয়করণের পর, Firebase কনসোলের "Uninstall" বাটন এবং সংশ্লিষ্ট CLI কমান্ডগুলো সরিয়ে ফেলা হবে। আপনাকে অবশ্যই Google Cloud কনসোল ব্যবহার করে স্বতন্ত্র Cloud Functions , Secret Manager secrets, Cloud Tasks queues, এবং কাস্টম IAM সার্ভিস অ্যাকাউন্ট সহ সমস্ত সংশ্লিষ্ট Google Cloud Google Cloud রিসোর্স ম্যানুয়ালি ডিলিট করতে হবে।
তবে, আপনি যদি আপনার ইনস্টল করা এক্সটেনশনগুলি সক্রিয়ভাবে ব্যবহার করেন, তাহলে আমরা ফাংশন কিটে স্থানান্তরিত হওয়ার জন্য দৃঢ়ভাবে সুপারিশ করছি। ফাংশন কিটে স্থানান্তরিত হতে, ব্যবহারকারীদের জন্য আমাদের মাইগ্রেশন গাইডে দেওয়া নির্দেশাবলী অনুসরণ করুন।
আপনি ফাংশন কিটে মাইগ্রেট না করার সিদ্ধান্ত নিতে পারেন, এবং সেক্ষেত্রে আমরা দৃঢ়ভাবে সুপারিশ করি যে আপনি আপনার সমস্ত এক্সটেনশনকে তাদের সর্বশেষ সংস্করণে আপডেট করুন , সেগুলোকে হালনাগাদ রাখুন, এবং পরবর্তীতে মাইগ্রেট করার প্রয়োজন হলে আপনার বিদ্যমান এক্সটেনশন কনফিগারেশনগুলো এক্সপোর্ট করে রাখুন।
একজন এক্সটেনশন প্রকাশক হিসেবে আমার কী করা উচিত?
আমরা আপনাকে আপনার প্রকাশিত এক্সটেনশনগুলিকে npm-এ প্রকাশিত ফাংশন কিটে স্থানান্তরিত করতে উৎসাহিত করছি। আপনি আপনার এক্সটেনশনকে ২য় প্রজন্মের ফাংশনে স্থানান্তরিত করার মাধ্যমে শুরু করতে পারেন, যা একটি ফাংশন কিট তৈরির জন্য পূর্বশর্ত। এর জন্য Cloud Functions v2 SDK ব্যবহার করে আপনার এক্সটেনশন লজিক প্যাকেজ করতে হবে। আমরা ডিক্লারেটিভ সিকিউরিটি এবং লাইফসাইকেল ইভেন্টের মতো ফিচারগুলির সাপোর্ট সহ Cloud Functions v2 SDK আপডেট করেছি। আপনি এখন আপনার মূল বিজনেস লজিকে ন্যূনতম পরিবর্তন করে আপনার বিদ্যমান এক্সটেনশন কোডকে একটি ২য় প্রজন্মের ফাংশনে স্থানান্তরিত করতে পারেন। এই ফাংশনগুলি একটি npm প্যাকেজ ব্যবহার করে প্রকাশ করা যেতে পারে। বিস্তারিত জানতে, প্রকাশকদের জন্য আমাদের মাইগ্রেশন গাইড দেখুন।
আমার যদি অন্য প্রশ্ন থাকে তাহলে কী হবে?
যেসব ব্যবহারকারীর প্রশ্ন আছে, তারা আমাদের ইউজার মাইগ্রেশন গাইড ব্যবহার করতে পারেন। গাইডটি ব্যবহার করার পরেও যদি আপনার কোনো প্রশ্ন থাকে, তাহলে আপনি ফায়ারবেস সাপোর্টের সাথে যোগাযোগ করতে পারেন।
যেসব পাবলিশারের Firebase Extensions মাইগ্রেট করার পদ্ধতি নিয়ে প্রশ্ন আছে, তারা পাবলিশারদের জন্য আমাদের মাইগ্রেশন গাইডটি ব্যবহার করতে পারেন। এই গাইডে আপডেট সম্পর্কে অবগত থাকার এবং আপনার প্রকাশিত এক্সটেনশনগুলোর বিকল্প প্রদানে সহায়তা পাওয়ার নির্দেশনা রয়েছে।
অভিবাসনের বিকল্প এবং প্রযুক্তিগত বাস্তবায়ন
মাইগ্রেশনের জন্য প্রধান উপায়গুলো কী কী?
২০২৬ সালের সেপ্টেম্বর থেকে, Firebase আনুষ্ঠানিকভাবে দুটি প্রধান মাইগ্রেশন পথ সমর্থন করে:
- একটি NPM-শেয়ার্ড ফাংশন ("ফাংশন কিট")-এ মাইগ্রেট করুন : স্ট্রিম ফায়ারস্টোর টু বিগকোয়েরি এবং npm-এ উপলব্ধ হওয়া অন্য যেকোনো ফাংশন কিটের জন্য এটি সুপারিশ করা হয়। এর মূল লজিকটি Cloud Functions v2 SDK ব্যবহার করে একটি স্ট্যান্ডার্ড NPM লাইব্রেরি হিসেবে প্যাকেজ করা হয়েছে। ব্যবহারকারীরা একটি স্ট্যান্ডার্ড Cloud Functions কোডবেস ইনিশিয়ালাইজ করেন, প্যাকেজটি ইনস্টল করেন, ফাংশনগুলো পুনরায় এক্সপোর্ট করেন এবং CLI ব্যবহার করে সেগুলোকে স্বাধীনভাবে ডিপ্লয় করেন।
- ফর্ক এবং স্ব-পরিচালনা : যেসব এক্সটেনশনের জন্য npm-এ কোনো ফাংশন কিট উপলব্ধ নেই, তাদের সকলের জন্য এটি সুপারিশ করা হয়। ব্যবহারকারীরা ওপেন-সোর্স এক্সটেনশনের সোর্স কোড কপি বা ফর্ক করেন, সর্বোত্তম এআই মাইগ্রেশন দক্ষতা বা ম্যানুয়াল গাইড ব্যবহার করে ট্রিগারগুলোকে স্ট্যান্ডার্ড Firebase v2 ফাংশনে রিফ্যাক্টর করেন এবং কোডবেস ও এর চলমান রক্ষণাবেক্ষণের সম্পূর্ণ মালিকানা গ্রহণ করেন।
কোন এক্সটেনশনগুলো ফাংশন কিটে স্থানান্তরিত করা হচ্ছে?
Stream Firestore to BigQuery এক্সটেনশনটিকে একটি ফাংশন কিটে স্থানান্তরিত করা হয়েছে, যা @firebase-function-kits/firestore-bigquery-export npm প্যাকেজ হিসেবে উপলব্ধ।
মাইগ্রেশনের জন্য কেন Cloud Functions v1 থেকে v2-তে আপগ্রেড করার প্রয়োজন হয়?
Node.js 22 রানটাইম চালু হওয়ার সাথে সাথে Cloud Functions v1-এর স্ট্যান্ডার্ড সাপোর্ট শেষ হয়ে যাচ্ছে। "ডাবল মাইগ্রেশন" এড়ানোর জন্য—যেখানে ডেভেলপাররা Firebase Extensions থেকে সরে আসার পর পুরোনো রানটাইমগুলোর মেয়াদ শেষ হয়ে গেলে দ্বিতীয়বার ম্যানুয়াল রিফ্যাক্টরিং করতে বাধ্য হন— Firebase এই রূপান্তরের সময় অবিলম্বে সমস্ত মাইগ্রেট করা ফাংশনকে v2 SDK-তে আপগ্রেড করার জন্য জোরালোভাবে সুপারিশ করে, এবং ফাংশন কিটগুলোর জন্য এটি আবশ্যক।
এক্সটেনশন ব্যবহারকারী হিসেবে, আপনি ব্যবহারকারী মাইগ্রেশন গাইড ব্যবহার করে আপনার নিজস্ব ফাংশন কিটও তৈরি করতে পারেন।
বিলিং এবং মূল্য নির্ধারণ
সেলফ-ম্যানেজড Cloud Functions স্থানান্তরিত হলে গ্রাহকের বিলিং-এ কি কোনো পরিবর্তন আসবে?
সাধারণত, না। ডেপ্লয় করা এক্সটেনশনগুলো তাদের ব্যবহৃত Google Cloud রিসোর্স, যেমন Cloud Functions ইনভোকেশন, Cloud Storage , বা BigQuery স্টোরেজ ও কোয়েরির জন্য গ্রাহকদের কাছ থেকে ইতিমধ্যেই চার্জ নিয়ে থাকে। তবে, মাইগ্রেশন চলাকালীন, একটি নিরাপদ কাটওভার নিশ্চিত করার জন্য গ্রাহকদের যদি পুরোনো Firebase Extensions এবং তার নতুন ডেপ্লয় করা প্রতিস্থাপন ফাংশন উভয়ই সমান্তরালভাবে চালাতে হয়, তাহলে তাদের একটি ছোট, অস্থায়ী অতিরিক্ত খরচ হতে পারে।
ম্যান্ডিয়েন্ট বা অন্যান্য বিশেষায়িত এন্টারপ্রাইজ অ্যাকাউন্টগুলোর বিলিং কীভাবে পরিচালনা করা হয়?
এই বাতিলকরণটি একটি প্ল্যাটফর্ম-ব্যাপী পরিবর্তন যা সমস্ত Firebase এবং Google Cloud প্রোজেক্টকে প্রভাবিত করছে। সাধারণ বিলিং এবং সাবস্ক্রিপশন ব্যবস্থা এর দ্বারা প্রভাবিত হবে না। যদি গ্রাহকরা বাতিলকরণের কারণে সৃষ্ট ডাউনটাইমের জন্য SLA ক্রেডিটের অনুরোধ করেন অথবা জটিল বিলিং ব্যতিক্রমের সম্মুখীন হন, তবে সাধারণ বিলিং সাপোর্ট চ্যানেলের মাধ্যমে সরাসরি বিষয়টি ঊর্ধ্বতন কর্তৃপক্ষের কাছে জানান।
সমস্যা সমাধান এবং ঝুঁকি প্রশমন
মাইগ্রেশনের সময় ডেটা নষ্ট হওয়া বা পরিষেবা বন্ধ হয়ে যাওয়ার ঝুঁকি কী?
পরিচালিত রিসোর্সগুলোকে স্ব-পরিচালিত কোডবেসে রূপান্তর করার ফলে পরিষেবা ব্যাহত হওয়া বা কোনো ইভেন্ট হারিয়ে যাওয়ার সামান্য ঝুঁকি থাকে।
- ট্রিগার বিঘ্ন : নতুন ট্রিগার সক্রিয় হওয়ার আগে যদি পুরানো ট্রিগারগুলি মুছে ফেলা হয়, তাহলে একটি শূন্যস্থান তৈরি হয় যেখানে ইভেন্টগুলি (যেমন, Cloud Firestore ডকুমেন্ট রাইট) বাদ পড়ে যায় এবং স্থায়ীভাবে হারিয়ে যায়। যেকোনো ডেটা ক্ষতি এড়াতে, এক্সটেনশনটি সরানোর আগে আমরা প্রতিস্থাপন কিটটি স্থাপন এবং যাচাই করার পরামর্শ দিই।
- অনুমতির ঘাটতি : যদি নতুনভাবে ডেপ্লয় করা কোডবেসে প্রয়োজনীয় IAM অনুমতি না থাকে, তাহলে BigQuery তে লেখার মতো অপারেশনগুলো নীরবে ব্যর্থ হবে অথবা রানটাইমে ক্র্যাশ করবে। আমরা ফাংশনগুলোর জন্য ডিক্লারেটিভ সিকিউরিটি যুক্ত করেছি, তাই যে অ্যাকাউন্ট কোয়েরি করতে, রোল সেট করতে এবং একটি সার্ভিস অ্যাকাউন্ট তৈরি করতে পারে, সেই অ্যাকাউন্ট দিয়ে প্রথম কিট ডেপ্লয় করলে এই সমস্যাটির সমাধান হওয়া উচিত।
গুরুত্বপূর্ণ Cloud Firestore -টু- BigQuery এক্সপোর্ট এক্সটেনশনের ক্ষেত্রে আমরা কীভাবে ডেটা ক্ষতি রোধ করতে পারি?
একটি নিরাপদ ও ডেটা-ক্ষতিহীন রূপান্তর নিশ্চিত করতে, সাপোর্ট টিমকে অবশ্যই ব্যবহারকারীদের গ্যাপ-ভিত্তিক কাটওভারের পরিবর্তে ওভারল্যাপ-ভিত্তিক কাটওভার অনুসরণ করার পরামর্শ দিতে হবে। কিট-এ মাইগ্রেশনের ক্ষেত্রে এটিই ডিফল্ট ব্যবস্থা:
- এক্সটেনশনটি ইনস্টল এবং চালু থাকা অবস্থাতেই প্রতিস্থাপন ফাংশন কিটটি স্থাপন করুন। ইভেন্টার্ক সম্পূর্ণরূপে প্রোভিশন হওয়ার জন্য কয়েক মিনিট অপেক্ষা করুন।
- পর্যবেক্ষণাধীন Cloud Firestore কালেকশনে একটি টেস্ট ডকুমেন্ট লিখুন এবং যাচাই করুন যে নতুন সেলফ-ম্যানেজড ফাংশনটি সফলভাবে BigQuery চেঞ্জলগ টেবিলে একটি নতুন ইভেন্ট আইডি সহ সংশ্লিষ্ট সারিটি লিখছে।
- নতুন ডেপ্লয়মেন্টটি সঠিকভাবে কাজ করছে বলে নিশ্চিত হওয়ার পর, ডাবল-রাইটিং আচরণটি বন্ধ করতে অবিলম্বে লিগ্যাসি এক্সটেনশনটি আনইনস্টল বা নিষ্ক্রিয় করুন।
- প্রতিটি রাইটের ডুপ্লিকেট প্রসেসিংয়ের খরচ এবং র BigQuery চেঞ্জলগে ডুপ্লিকেট সারির সম্ভাবনা কমানোর জন্য ওভারল্যাপ উইন্ডোটি যথাসম্ভব ছোট রাখুন।
- বেশিরভাগ ক্ষেত্রে Raw Changelog Table (
*_raw_changelog)insertIDদ্বারা ডুপ্লিকেট সারিগুলো অপসারণ করে এবং এমনকি চেঞ্জলগে ডুপ্লিকেট সারি পাওয়া গেলেও টেবিলের সর্বশেষ ভিউ (*_raw_latest) সঠিক থাকবে।
বিশেষ করে এই এক্সটেনশনটি মাইগ্রেট করার বিষয়ে এবং যেকোনো ডেটা ক্ষতি থেকে কীভাবে পুনরুদ্ধার করা যায়, সে সম্পর্কে আরও বিস্তারিত তথ্য কিটটির README.md- এ দেওয়া আছে।
লাইফসাইকেল প্রভিশনিং ধাপটি ব্যর্থ হলে আমার কী করা উচিত?
ম্যানেজড সার্ভিসের অধীনে, সেটআপের কাজগুলো (যেমন BigQuery ডেটাসেট, টেবিল এবং ভিউ তৈরি করা) স্বয়ংক্রিয়ভাবে সম্পন্ন হতো। সেলফ-ম্যানেজড NPM মডেলে, একটি লাইফসাইকেল টাস্ক কিউ ফাংশন ব্যবহার করে এগুলোকে ট্রিগার করা হয়; উদাহরণস্বরূপ, firestore-bigquery-export এ এটিকে initBigQuerySync বলা হয়।
যদি এই ধাপটি ব্যর্থ হয় বা স্বয়ংক্রিয়ভাবে না চলে:
যাচাই করুন যে Cloud Functions রানটাইম সার্ভিস অ্যাকাউন্টকে প্রয়োজনীয় IAM রোলগুলো প্রদান করা হয়েছে। উদাহরণস্বরূপ,
firestore-bigquery-exportজন্য এর মধ্যে অন্তর্ভুক্ত রয়েছে:- রিসোর্স তৈরি করতে এবং সারি সন্নিবেশ করতে:
roles/bigquery.dataEditor - জব চালাতে ও ভিউ তৈরি করতে:
roles/bigquery.user - প্রোভিশনিং টাস্কটি কিউতে যুক্ত করতে:
roles/cloudtasks.enqueuer
- রিসোর্স তৈরি করতে এবং সারি সন্নিবেশ করতে:
নিশ্চিত করুন যে কলারের
roles/cloudtasks.enqueuerপারমিশন আছে।CLI ব্যবহার করে ম্যানুয়ালি লাইফসাইকেল ইনিশিয়ালাইজেশন কমান্ডটি পুনরায় চালান:
firebase functions:lifecycle:run afterInstall KIT_INSTANCE_IDকোনো অনুমতি বা কনফিগারেশন ত্রুটি নির্ণয় করতে ট্রিগার ফাংশন এবং টাস্ক কিউ এক্সিকিউশন উভয়ের Cloud Logging লগ পরীক্ষা করুন।
Secret Manager ক্রেডেনশিয়ালগুলো কীভাবে মাইগ্রেট করা হয়?
ম্যানেজড মডেলে, Secret Manager রিসোর্সগুলো স্বয়ংক্রিয়ভাবে এক্সটেনশন ইনস্ট্যান্সগুলোর সাথে আবদ্ধ হয়ে যেত। যখন আপনি আপনার এক্সটেনশন কনফিগারেশন একটি ফাংশন কিটে এক্সপোর্ট করার জন্য ext:migrate বা ext:export --mode functions কমান্ড ব্যবহার করেন, তখন আমরা এক্সটেনশনগুলোকে এই সিক্রেটগুলো পরিচালনা করা থেকে বিরত রাখি, ফলে এক্সটেনশনটি আনইনস্টল করার পরেও সেগুলো আপনার প্রোজেক্টে থেকে যায়। ভবিষ্যতে যদি আপনি এই সিক্রেটগুলো সরাতে চান, তবে আপনাকে অবশ্যই Google Cloud কনসোলে ম্যানুয়ালি তা করতে হবে।
যদি কোনো ব্যবহারকারী স্থানান্তরিত এক্সটেনশনের একাধিক ইনস্ট্যান্স চালাতে চান, তাহলে কী হবে?
একটি এক্সটেনশনের একাধিক ভার্সন থাকার মতোই, একটি ফাংশনের একাধিক ইনস্ট্যান্সকে সাপোর্ট করার উপায় হিসেবে আমরা ফাংশন কিট চালু করেছি। প্রতিটি কিট একটি অনন্য কিট ইনস্ট্যান্স আইডি পাবে, যা একটি কোডবেসের মতো এবং CLI কমান্ডে কোডবেসের পরিবর্তে ব্যবহার করা যাবে। ডিপ্লয় করার পর, প্রতিটি ফাংশনের একটি অনন্য নাম নিশ্চিত করতে, এক্সটেনশনের ext-<extension-instance-id>- প্রিফিক্সের মতো, একটি কিট ইনস্ট্যান্সের সমস্ত ফাংশনের নামের আগে kit-<instance-id>- প্রিফিক্সটি যুক্ত করা হবে। মাইগ্রেট করার অংশ হিসেবে কীভাবে ফাংশন কিট ব্যবহার করতে হয় সে সম্পর্কে আরও জানতে, আমাদের ইউজার মাইগ্রেশন গাইড দেখুন।
কিট ইনস্টল করতে npm ব্যবহৃত হয়; কিন্তু আমি যদি Yarn বা অন্য কোনো নোড-উপযোগী প্যাকেজ ম্যানেজার ব্যবহার করতে চাই, তাহলে কী হবে?
বর্তমানে আমাদের ইয়ার্ন (Yarn) বা অন্যান্য প্যাকেজ ম্যানেজার সমর্থন করার কোনো পরিকল্পনা নেই। প্রথমবার ইনস্টলের সময় কিট সোর্স কোড সেট আপ করার জন্য সরাসরি এনপিএম (npm) কমান্ড চালানোর মাধ্যমেই কিট ইনস্টল প্রক্রিয়াটি সম্পন্ন হয়।
বিকল্প হিসেবে, আপনি একটি সোর্স ডিরেক্টরি তৈরি করতে পারেন, নিজে কিট এনপিএম প্যাকেজটি ইনস্টল করতে পারেন এবং উপযুক্ত বিল্ড ও এক্সপোর্ট দিয়ে এটি সেট আপ করতে পারেন। firebase-tools এ আমাদের TypeScript index-kit টেমপ্লেটগুলো দেখুন অথবা উদাহরণ হিসেবে একটি এনপিএম-ইনস্টল করা কিট দেখুন। একবার এটি করে ফেললে, আপনি --package পরিবর্তে --directory ব্যবহার করে এটিকে একটি লোকাল কিটের মতো ইনস্টল করতে পারবেন। এরপর থেকে, আপনাকে ডিরেক্টরি বা আইডি দ্বারা কিটটি শনাক্ত করতে হবে, কিন্তু আপনি ইনস্ট্যান্স যোগ এবং অপসারণ করতে কিট কমান্ডগুলো ব্যবহার করতে পারবেন।
আমার এক্সটেনশনটি ডকার রিপোজিটরি বা কেএমএস কী অ্যাডভান্সড সিস্টেম প্যারামিটার ব্যবহার করে; আমি ফাংশন কিটগুলিতে এটি কীভাবে কনফিগার করতে পারি?
বর্তমানে, আমরা Cloud Functions for Firebase এ ডকার রিপোজিটরি বা কেএমএস কী কনফিগার করা সমর্থন করি না। আপনি যদি এমন কোনো এক্সটেনশন থেকে মাইগ্রেট করেন যেখানে এই সিস্টেম প্যারামিটারগুলো কনফিগার করা আছে এবং এই কার্যকারিতাটি বজায় রাখতে চান, তাহলে আপনি gcloud CLI ব্যবহার করে আপনার নতুন কিটের ফাংশনগুলোতে প্যারামিটারগুলো প্রয়োগ করতে পারেন।
পূর্বশর্ত
- প্রাথমিকভাবে মাইগ্রেশন গাইডগুলো অনুসরণ করে আপনার ফাংশন কিটটি ডেপ্লয় করুন, যাতে ফাংশনগুলো Google Cloud বিদ্যমান থাকে।
আপনার টার্মিনালে এনভায়রনমেন্ট ভেরিয়েবলগুলো নির্ধারণ করুন:
export PROJECT_ID="YOUR_PROJECT_ID" export FUNCTION_REGION="YOUR_REGION" # e.g. us-east1 export KIT_NAME="YOUR_KIT_NAME" # e.g. firestore-bigquery-export export SOURCE_DIR="YOUR_KIT_SOURCE_DIR" # e.g. "./function-kits/${KIT_NAME}/source" export REPO_NAME="YOUR_DOCKER_REPO_NAME" export KEY_RING="YOUR_KMS_KEY_RING" export KEY_NAME="YOUR_KMS_KEY_NAME" # Retrieve Project Number automatically export PROJECT_NUMBER=$(gcloud projects describe "$PROJECT_ID" --format="value(projectNumber)")কিটের সোর্স রুটে আগে থেকেই
.gcloudignoreতৈরি করে রাখুন, যাতে কম্পাইল করা বিল্ড ফাইলগুলো.gitignoreদ্বারা উপেক্ষিত না হয়।cat << 'EOF' > "${SOURCE_DIR}/.gcloudignore" .gcloudignore .git .gitignore node_modules #!include:.gitignore !lib/** EOFপ্রয়োজনীয় IAM অনুমতি প্রদান করুন:
KMS কী-গুলির জন্য (যা সার্ভিস এজেন্টদের ডিক্রিপশন অ্যাক্সেস প্রদান করে):
for SERVICE_ACCOUNT in \ "service-${PROJECT_NUMBER}@serverless-robot-prod.iam.gserviceaccount.com" \ "service-${PROJECT_NUMBER}@gcf-admin-robot.iam.gserviceaccount.com" \ "service-${PROJECT_NUMBER}@gcp-sa-artifactregistry.iam.gserviceaccount.com" do gcloud kms keys add-iam-policy-binding "$KEY_NAME" \ --keyring="$KEY_RING" \ --location="$FUNCTION_REGION" \ --project="$PROJECT_ID" \ --member="serviceAccount:${SERVICE_ACCOUNT}" \ --role="roles/cloudkms.cryptoKeyEncrypterDecrypter" doneArtifact Registry জন্য (যা Cloud Build এ লেখার এবং Cloud Run -এ পড়ার অনুমতি দেয়):
# Grant the Cloud Build / Compute Service Account permission to write images to the repository gcloud artifacts repositories add-iam-policy-binding "$REPO_NAME" \ --location="$FUNCTION_REGION" \ --project="$PROJECT_ID" \ --member="serviceAccount:${PROJECT_NUMBER}-compute@developer.gserviceaccount.com" \ --role="roles/artifactregistry.writer" # Grant Cloud Run permission to pull images from the repository gcloud artifacts repositories add-iam-policy-binding "$REPO_NAME" \ --location="$FUNCTION_REGION" \ --project="$PROJECT_ID" \ --member="serviceAccount:service-${PROJECT_NUMBER}@serverless-robot-prod.iam.gserviceaccount.com" \ --role="roles/artifactregistry.reader"
gcloud CLI ব্যবহার করে সেটিংস প্রয়োগ করা
আপনার কিটের প্রতিটি ফাংশনের জন্য gcloud functions deploy চালান:
gcloud functions deploy FUNCTION_NAME \
--project="$PROJECT_ID" \
--region="$FUNCTION_REGION" \
--source="./function-kits/${KIT_NAME}/source" \
--docker-repository="projects/${PROJECT_ID}/locations/${FUNCTION_REGION}/repositories/${REPO_NAME}" \
--kms-key="projects/${PROJECT_ID}/locations/${FUNCTION_REGION}/keyRings/${KEY_RING}/cryptoKeys/${KEY_NAME}"
উল্লেখ্য যে, নিম্নলিখিত শর্তগুলির অধীনে এই বিকল্প সমাধানটি অকার্যকর হয়ে যায়:
- নতুন কিট ইনস্ট্যান্স :
firebase.jsonএ একটি ইনস্ট্যান্স যোগ করলে একটি নতুন Cloud Functions v2 রিসোর্স তৈরি হয়, যা ডিফল্টরূপে গুগল-পরিচালিত কী এবংgcf-artifactsব্যবহার করে। প্রতিটি নতুন ইনস্ট্যান্সের জন্য আপনাকে অবশ্যইgcloudচালাতে হবে। - ফাংশন পুনঃসৃষ্টি : ট্রিগারের ধরন পরিবর্তন করলে (উদাহরণস্বরূপ, HTTPS থেকে Cloud Firestore ট্রিগারে), এন্ট্রি পয়েন্ট বদলালে, বা নাম পরিবর্তন করলে, Firebase CLI পুরোনো ফাংশনটি মুছে ফেলে এবং একটি নতুন ফাংশন তৈরি করে। নতুন ফাংশনটি তার এই সেটিংসগুলো হারিয়ে ফেলে, যতক্ষণ না আপনি আবার
gcloudচালান। - কনফিগারেশন পরিবর্তন : Firebase CLI,
firebase functions:listঅথবা diff লগ-এ KMS বা Docker রিপোজিটরির স্ট্যাটাস প্রদর্শন করে না, যা ইনফ্রাস্ট্রাকচার অডিটিংকে কঠিন করে তোলে।
সফলতা যাচাই করা হচ্ছে
রিপোজিটরি এবং এনক্রিপশন কী প্রয়োগ করা হয়েছে কিনা তা নিশ্চিত করতে, নিম্নলিখিত কমান্ডটি চালান:
gcloud functions describe FUNCTION_NAME \
--region="$FUNCTION_REGION" \
--project="$PROJECT_ID" \
--format="yaml(state, buildConfig.dockerRepository, kmsKeyName)"