আমি এক মাস আগে একটি নিবন্ধে লিখেছিলাম, আমি কীভাবে আপনার পাইথন ওয়েব অ্যাপ্লিকেশনটিকে একটি উত্পাদন (বা প্রি-ডেভ/স্টেজিং) পরিবেশে ক্রমাগত স্থাপন করতে হয় সে সম্পর্কে কথা বলেছিলাম।
অন্য কোনো ভাষায় আপনার আবেদন স্থাপন করতে আপনি পূর্ববর্তী নিবন্ধটি উল্লেখ করতে পারেন। শুধু ওয়ার্কফ্লো ফাইল সংশোধন করতে ভুলবেন না.
আমাকে সম্প্রতি একটি মাইক্রোসার্ভিস তৈরি করার দায়িত্ব দেওয়া হয়েছিল (পাইথন এবং ফাস্টএপিআই ব্যবহার করে) দুটি ভয়েসকে মেলানোর জন্য এবং একটি ভবিষ্যদ্বাণী স্কোর দেওয়ার জন্য যদি তারা উভয়ই মিলে যায় বা না হয়। স্টেকহোল্ডাররা একটি ভয়েস আনলক বৈশিষ্ট্যের জন্য অনুরোধ করেছিল।
আমাদের একটি ইঞ্জিনিয়ারিং মিটিং ছিল, এবং আমি কাজটি নিতে উঠে দাঁড়ালাম (বা আমার নেতৃত্ব আমার পক্ষে দাঁড়িয়েছে, হাহা)।
এটি একটি আকর্ষণীয় কাজ ছিল, কারণ আমি আগে কখনও এমএল মডেলের সাথে কাজ করিনি (প্রশিক্ষিত বা কী নয়)। একটি AWS EC2 দৃষ্টান্তে কোডটি ডিজাইন, বিল্ড এবং শিপ করতে আমার এক সপ্তাহ লেগেছে। আমি CI/CD-এর একজন বড় অনুরাগী, তাই আমি যা ব্যবহার করেছি তাতে আমি সবচেয়ে আরামদায়ক ছিলাম- GitHub অ্যাকশন।
এক সপ্তাহ পরে... পরিবর্তনের অনুরোধ করা হয়েছিল, এবং আমি একটি নতুন [নিয়োজন] কৌশল ব্যবহার করতে চেয়েছিলাম যা আমি গবেষণা করছিলাম। আমি পুনরায় স্থাপন করার সময় কোনো ডাউনটাইম অনুভব না করার জন্য AWS EC2 ইন্সট্যান্স-এ সুন্দরভাবে চলমান ডকারাইজড মাইক্রোসার্ভিস অ্যাপ্লিকেশনটি প্রয়োজন।
এবং আমি আমার ভেতরে নিখুঁত কৌশল আপ ছিল.
সেই কৌশলটি হল: নীল-সবুজ কৌশল ।
নীল/সবুজ স্থাপনার উপর AWS হোয়াইটপেপার অনুসারে, এটি একটি স্থাপনার কৌশল যেখানে আপনি দুটি পৃথক, কিন্তু অভিন্ন পরিবেশ তৈরি করেন।
একটি পরিবেশ (নীল) বর্তমান অ্যাপ্লিকেশন সংস্করণ চালাচ্ছে এবং একটি পরিবেশ (সবুজ) নতুন অ্যাপ্লিকেশন সংস্করণ চালাচ্ছে। একটি নীল/সবুজ স্থাপনার কৌশল ব্যবহার করলে অ্যাপ্লিকেশনের প্রাপ্যতা বৃদ্ধি পায় এবং কোনো স্থাপনা ব্যর্থ হলে রোলব্যাক প্রক্রিয়াকে সরলীকরণ করে স্থাপনার ঝুঁকি হ্রাস করে।
একবার সবুজ পরিবেশে পরীক্ষা শেষ হয়ে গেলে, লাইভ অ্যাপ্লিকেশন ট্র্যাফিক সবুজ পরিবেশে নির্দেশিত হয় এবং নীল পরিবেশ অবহেলিত হয়।
সহজ কথায়, নীল/সবুজ স্থাপনার কৌশল হল দুটি অভিন্ন উৎপাদন পরিবেশ চালিয়ে ডাউনটাইম এবং ঝুঁকি কমানোর একটি উপায়।
যদি এই ধরনের স্থাপনার কৌশল আপনার প্রথমবার শোনা হয়, তাহলে ভয় পাওয়ার একেবারেই কিছু নেই, আমি আপনাকে বিস্তারিত পদক্ষেপগুলি সরবরাহ করব যা আপনাকে নীল-সবুজ স্থাপনা অর্জনে সহায়তা করবে।
আমরা উদাহরণের উদ্দেশ্যে একটি কাল্পনিক পণ্য ব্যবহার করব কারণ এনডিএ কারণে আমি আমার কোম্পানির জন্য যে পণ্যটি তৈরি করেছি তার সাথে আমি স্থাপনের ধাপগুলি অতিক্রম করতে চাই না। হাহাহা।
আসুন সরাসরি ধাপে প্রবেশ করি:
আপনার আপডেট করা কোড দিয়ে একটি নতুন ডকার ইমেজ তৈরি করে শুরু করুন এবং একটি নতুন সংস্করণ নম্বর দিয়ে ট্যাগ করুন।
$ docker build -t myexample:v2 .
এটি বর্তমান ডিরেক্টরিতে Dockerfile
ব্যবহার করে myexample:v2
ট্যাগ সহ একটি নতুন ডকার চিত্র তৈরি করবে।
যেখানে myexample:v2
হল নতুন বিল্ড ডকার ইমেজের নাম। আমার ক্ষেত্রে, এটি এমএল প্রকল্পের নাম ছিল। যেমন, docker build -t companyx-servicename-backend:v2
নতুন ইমেজ থেকে একটি নতুন ডকার কন্টেইনার শুরু করুন, কিন্তু বাইরের বিশ্বের কাছে এটি প্রকাশ করবেন না।
$ docker run -d --name myexample-v2 myexample:v2
এটি myexample:v2
চিত্র থেকে myexample-v2
নামের একটি নতুন ডকার কন্টেইনার শুরু করবে।
নতুন কন্টেইনারটি সঠিকভাবে কাজ করছে তা নিশ্চিত করে, শুরু এবং আরম্ভ করার জন্য অপেক্ষা করুন।
$ docker logs myexample-v2
এটি সঠিকভাবে শুরু হয়েছে এবং শুরু হয়েছে তা নিশ্চিত করতে নতুন কন্টেইনারের লগগুলি পরীক্ষা করতে ডকার লগ কমান্ডটি ব্যবহার করুন।
এখানে একটি NGINX কনফিগারেশনের একটি উদাহরণ যা দুটি কন্টেইনারকে রুট করে:
upstream myexample { server myexample-v1:8000; server myexample-v2:8000 backup; } server { listen 80; server_name myexample.com; location / { proxy_pass http://myexample; } }
এই কনফিগারেশনটি দুটি সার্ভার সহ myexample নামে একটি আপস্ট্রিম গ্রুপ সেট আপ করে: myexample-v1
এবং myexample-v2
। backup
কীওয়ার্ডটি দ্বিতীয় সার্ভারটিকে ব্যাকআপ হিসাবে চিহ্নিত করতে ব্যবহৃত হয়। proxy_pass
নির্দেশিকাটি myexample
আপস্ট্রিম গ্রুপে অনুরোধ ফরোয়ার্ড করতে ব্যবহৃত হয়।
আপনার অ্যাপ্লিকেশনের নাম এবং পোর্ট প্রতিফলিত করতে বিপরীত প্রক্সি কনফিগারেশন আপডেট করা নিশ্চিত করুন।
বিপরীত প্রক্সি কনফিগারেশন সামঞ্জস্য করে ধীরে ধীরে পুরানো কন্টেইনার থেকে নতুন কন্টেইনারে ট্রাফিক স্থানান্তর করুন।
নতুন কন্টেইনারে ট্রাফিক স্থানান্তর করতে, নতুন কন্টেইনারে আরও ওজন দিতে বিপরীত প্রক্সি কনফিগারেশন সামঞ্জস্য করুন। সার্ভার নির্দেশিকা থেকে ব্যাকআপ কীওয়ার্ডটি সরিয়ে এটি করা যেতে পারে:
upstream myexample { server myexample-v1:8000; server myexample-v2:8000; } server { listen 80; server_name myexample.com; location / { proxy_pass http://myexample; } }
এর ফলে NGINX myexample-v2
কন্টেইনারে আরও অনুরোধ পাঠাবে। আপনার অ্যাপ্লিকেশন নিরীক্ষণ করুন, এবং সমস্ত ট্র্যাফিক নতুন পাত্রে প্রবাহিত না হওয়া পর্যন্ত প্রয়োজন অনুসারে কনফিগারেশন সামঞ্জস্য করুন।
একবার সমস্ত ট্র্যাফিক নতুন কন্টেইনারে প্রবাহিত হলে, আপনি নিরাপদে থামাতে এবং পুরানো কন্টেইনারটি সরাতে পারেন।
$ docker stop myexample-v1 $ docker rm myexample-v1
এটি সার্ভারে রিসোর্স মুক্ত করে পুরানো কন্টেইনারটি বন্ধ করে সরিয়ে ফেলবে।
যদি আপনার অ্যাপ্লিকেশন একটি রিলেশনাল ডাটাবেসের উপর নির্ভর করে, নীল-সবুজ স্থাপনার কৌশলটি আপডেট করার সময় নীল এবং সবুজ ডাটাবেসের মধ্যে অসঙ্গতি সৃষ্টি করতে পারে।
সর্বোচ্চ স্তরের ডেটা অখণ্ডতা নিশ্চিত করতে, অতীত এবং ভবিষ্যত উভয় সংস্করণের সাথে সামঞ্জস্যপূর্ণ একটি ইউনিফাইড ডাটাবেস সেট আপ করার পরামর্শ দেওয়া হয়৷
আমি এই প্রযুক্তিতে নতুন, এবং স্পষ্টতই, এটি সম্পর্কে অনেক কিছু জানি না। কিন্তু আমি এর ট্রেডঅফ এবং অন্যান্য কৌশল সম্পর্কে শিখতে যাচ্ছি যা আরও ভাল কাজ করবে। আপনি কি আপনার হাতা মধ্যে একটি কৌশল বা দুই আপ আছে যে আপনি আমার সাথে শেয়ার করতে চান?
আমি এটা প্রশংসা করব. আমাকে এটা (মন্তব্য বিভাগে) আছে.
ওহ, ওহ। আমার বিরক্তিকর নিউজলেটার সাবস্ক্রাইব করতে ভুলবেন না. আমি Q1 থেকে অনেক কিছু শিখেছি এবং শীঘ্রই সেগুলি শেয়ার করব৷ সিয়াও।