একটু তত্ত্ব দিয়ে শুরু করা যাক। কি হয়ছে ?
সহজ কথায়, এই নথিটি SaaS অ্যাপ্লিকেশনগুলির বিকাশকে সহজ করার জন্য ডিজাইন করা হয়েছে, যা আধুনিক অ্যাপ্লিকেশনগুলির বিকাশে প্রায়শই সম্মুখীন হওয়া সমস্যা এবং অনুশীলনগুলি সম্পর্কে ডেভেলপার এবং DevOps ইঞ্জিনিয়ারদের সচেতন করে তুলতে সহায়তা করে৷
নথিটি হেরোকু প্ল্যাটফর্মের বিকাশকারীরা তৈরি করেছিলেন।
বারো-ফ্যাক্টর অ্যাপ পদ্ধতিটি যেকোন প্রোগ্রামিং ভাষায় লিখিত অ্যাপ্লিকেশনগুলিতে এবং তৃতীয়-পক্ষের ব্যাকিং পরিষেবাগুলির (ডাটাবেস, বার্তা সারি, ক্যাশে, ইত্যাদি) ব্যবহার করে প্রয়োগ করা যেতে পারে।
সংক্ষিপ্তভাবে যে কারণগুলির উপর ভিত্তি করে এই পদ্ধতিটি তৈরি করা হয়েছে:
- কোডবেস - একটি উৎস-ট্র্যাক কোডবেস - একাধিক স্থাপনা
- নির্ভরতা - স্পষ্টভাবে ঘোষণা করুন এবং নির্ভরতা বিচ্ছিন্ন করুন
- কনফিগারেশন - রানটাইমে কনফিগারেশন সংরক্ষণ করুন
- তৃতীয় পক্ষের পরিষেবা (ব্যাকিং পরিষেবা) - ব্যাকিং পরিষেবাগুলিকে প্লাগযোগ্য সংস্থান হিসাবে বিবেচনা করুন
- নির্মাণ, মুক্তি, চালান - কঠোরভাবে আলাদা বিল্ড এবং রান স্টেজ
- প্রসেস - এক বা একাধিক রাষ্ট্রবিহীন প্রক্রিয়া হিসাবে অ্যাপ্লিকেশনটি চালান
- পোর্ট বাঁধাই - পোর্ট বাইন্ডিংয়ের মাধ্যমে রপ্তানি পরিষেবা
- উপমা - প্রসেস সহ আপনার অ্যাপ স্কেল করুন
- নিষ্পত্তিযোগ্যতা - দ্রুত স্টার্টআপ এবং আকর্ষণীয় শাটডাউন সহ নির্ভরযোগ্যতা সর্বাধিক করুন
- অ্যাপ্লিকেশন ডেভেলপমেন্ট/অপারেশন প্যারিটি - যতটা সম্ভব উন্নয়ন, মঞ্চায়ন এবং উৎপাদন পরিবেশকে একই রকম রাখুন
- লগিং - লগকে ইভেন্টের স্ট্রীম হিসাবে বিবেচনা করুন
- প্রশাসনের কাজ - এককালীন প্রক্রিয়া সহ প্রশাসন/ব্যবস্থাপনা কার্য সম্পাদন করুন
12টি বিষয় সম্পর্কে আরও তথ্যের জন্য, নিম্নলিখিত সংস্থানগুলি দেখুন:
- - অবশ্যই পরুন
- - অফিসিয়াল অনুবাদ
- — উন্নত করার জন্য 12টি বিষয়ের উপর একটি নতুন চেহারা।
নীল-সবুজ স্থাপনা কি?
নীল-সবুজ স্থাপনা হল একটি অ্যাপ্লিকেশন সরবরাহ করার একটি উপায় প্রকাশনা এমনভাবে যাতে শেষ ক্লায়েন্ট তার পক্ষ থেকে কোনো পরিবর্তন দেখতে না পায়। অন্য কথায়, শূন্য দিয়ে একটি অ্যাপ্লিকেশন স্থাপন করা ডাউনটাইম.
ক্লাসিক BG ডিপ্লোয় স্কিম নিচের ছবির মত দেখায়।
- শুরুতে, ঠিক একই কোড, অ্যাপ্লিকেশন, প্রকল্প সহ 2টি শারীরিক সার্ভার রয়েছে এবং একটি রাউটার (ব্যালেন্সার) রয়েছে।
- রাউটার প্রাথমিকভাবে সার্ভারগুলির একটিতে সমস্ত অনুরোধ নির্দেশ করে (সবুজ).
- এই মুহুর্তে যখন আপনাকে আবার রিলিজ করতে হবে, পুরো প্রকল্পটি অন্য সার্ভারে আপডেট করা হয় (নীল), যা বর্তমানে কোনো অনুরোধ প্রক্রিয়া করছে না।
- জন্য কোড পরে নীল সার্ভার সম্পূর্ণ আপডেট করা হয়েছে, রাউটার থেকে স্যুইচ করার জন্য একটি কমান্ড দেওয়া হয়েছে সবুজ উপর নীল সার্ভার
- এখন সমস্ত ক্লায়েন্ট কোডের সাথে ফলাফল দেখতে পায় নীল সার্ভার
- কিছু সময়ের জন্য, সবুজ একটি অসফল স্থাপনার ক্ষেত্রে সার্ভারটি ব্যাকআপ হিসাবে কাজ করে নীল সার্ভার এবং ব্যর্থতা এবং বাগগুলির ক্ষেত্রে, রাউটার ব্যবহারকারীর প্রবাহকে ফিরিয়ে দেয় সবুজ পুরানো স্থিতিশীল সংস্করণ সহ সার্ভার, এবং নতুন কোড সংশোধন এবং পরীক্ষার জন্য পাঠানো হয়েছে।
- এবং প্রক্রিয়া শেষে, এটি একই ভাবে আপডেট করা হয় সবুজ সার্ভার এবং এটি আপডেট করার পরে, রাউটারটি অনুরোধের প্রবাহটিকে আবার সুইচ করে সবুজ সার্ভার
এটি সব খুব ভাল দেখায় এবং প্রথম নজরে এটির সাথে কোন সমস্যা হওয়া উচিত নয়।
কিন্তু যেহেতু আমরা আধুনিক বিশ্বে বাস করি, শাস্ত্রীয় স্কিমে নির্দেশিত শারীরিক স্যুইচিংয়ের বিকল্পটি আমাদের উপযুক্ত নয়। আপাতত তথ্য রেকর্ড করুন, আমরা পরে এটিতে ফিরে আসব।
খারাপ এবং ভাল উপদেশ
দায়িত্ব অস্বীকার: নীচের উদাহরণগুলি আমি যে ইউটিলিটি/পদ্ধতি ব্যবহার করি তা দেখায়, আপনি অনুরূপ ফাংশনগুলির সাথে একেবারে যেকোনো বিকল্প ব্যবহার করতে পারেন।
বেশিরভাগ উদাহরণই পিএইচপি এবং ডকারের সাথে ওয়েব ডেভেলপমেন্ট (কি আশ্চর্যের) সাথে ছেদ করবে।
নীচের অনুচ্ছেদগুলিতে নির্দিষ্ট উদাহরণগুলিতে কারণগুলির ব্যবহারের একটি সহজ ব্যবহারিক বর্ণনা রয়েছে, আপনি যদি এই বিষয়ে আরও তত্ত্ব পেতে চান তবে মূল উত্সের উপরের লিঙ্কগুলি দেখুন৷
1. কোডবেস
একবারে সার্ভারে ফাইল আপলোড করতে FTP এবং FileZilla ব্যবহার করুন, প্রোডাকশন সার্ভার ছাড়া কোথাও কোড সংরক্ষণ করবেন না।
একটি প্রকল্পের সর্বদা একটি একক কোড বেস থাকা উচিত, অর্থাৎ, সমস্ত কোড একটি থেকে আসে git ভান্ডার সার্ভারগুলি (উৎপাদন, মঞ্চায়ন, পরীক্ষা1, পরীক্ষা2 ...) একটি ভাগ করা সংগ্রহস্থলের শাখা থেকে কোড ব্যবহার করে। এইভাবে, আমরা কোড সামঞ্জস্য অর্জন করি।
2. নির্ভরতা
ফোল্ডারের সমস্ত লাইব্রেরি সরাসরি প্রকল্পের রুটে ডাউনলোড করুন। লাইব্রেরির বর্তমান সংস্করণের সাথে ফোল্ডারে নতুন কোড স্থানান্তর করে সহজভাবে আপডেট করুন। সমস্ত প্রয়োজনীয় ইউটিলিটিগুলি সরাসরি হোস্ট সার্ভারে রাখুন যেখানে আরও 20টি পরিষেবা চলছে৷
প্রকল্পের সর্বদা নির্ভরতার একটি পরিষ্কারভাবে বোধগম্য তালিকা থাকা উচিত (নির্ভরতা দ্বারা, আমি পরিবেশকেও বোঝাতে চাই)। সমস্ত নির্ভরতা স্পষ্টভাবে সংজ্ঞায়িত এবং বিচ্ছিন্ন করা আবশ্যক।
উদাহরণ হিসেবে ধরা যাক সুরকার и ডকশ্রমিক.
সুরকার - একটি প্যাকেজ ম্যানেজার যা আপনাকে পিএইচপি-তে লাইব্রেরি ইনস্টল করতে দেয়। সুরকার আপনাকে কঠোরভাবে বা কঠোরভাবে সংস্করণ নির্দিষ্ট করার ক্ষমতা দেয়, এবং স্পষ্টভাবে তাদের সংজ্ঞায়িত করে। একটি সার্ভারে 20টি ভিন্ন প্রকল্প থাকতে পারে এবং প্রতিটির প্যাকেজ এবং লাইব্রেরির একটি ব্যক্তিগত তালিকা থাকবে অন্যটির থেকে স্বতন্ত্র।
ডকশ্রমিক - একটি ইউটিলিটি যা আপনাকে অ্যাপ্লিকেশনটি কাজ করবে এমন পরিবেশকে সংজ্ঞায়িত এবং বিচ্ছিন্ন করতে দেয়। তদনুসারে, সুরকারের মতোই, তবে আরও পুঙ্খানুপুঙ্খভাবে, আমরা নির্ধারণ করতে পারি যে অ্যাপ্লিকেশনটি কী কাজ করে। পিএইচপি-র একটি নির্দিষ্ট সংস্করণ চয়ন করুন, অতিরিক্ত কিছু যোগ না করে শুধুমাত্র প্রকল্পের কাজ করার জন্য প্রয়োজনীয় প্যাকেজগুলি ইনস্টল করুন। এবং সবচেয়ে গুরুত্বপূর্ণ, প্যাকেজ এবং হোস্ট মেশিন এবং অন্যান্য প্রকল্পের পরিবেশে হস্তক্ষেপ ছাড়াই। অর্থাৎ, ডকারের মাধ্যমে চলমান সার্ভারের সমস্ত প্রকল্পগুলি একেবারে যে কোনও প্যাকেজ সেট এবং সম্পূর্ণ ভিন্ন পরিবেশ ব্যবহার করতে পারে।
3. কনফিগারেশন
কনফিগারগুলিকে কোডের মধ্যেই ধ্রুবক হিসাবে সংরক্ষণ করুন। পরীক্ষার সার্ভারের জন্য পৃথক ধ্রুবক, উৎপাদনের জন্য পৃথক। ইফ else কনস্ট্রাক্ট ব্যবহার করে প্রজেক্টের ব্যবসায়িক যুক্তিতে সরাসরি পরিবেশের উপর নির্ভর করে অ্যাপ্লিকেশনটির কাজ টাই করুন।
কনফিগারেশন - এটিই একমাত্র জিনিস যা প্রকল্পের স্থাপনার (মোতায়েনের) মধ্যে ভিন্ন হওয়া উচিত। আদর্শভাবে, কনফিগারেশনগুলি এনভায়রনমেন্ট ভেরিয়েবল (env vars) এর মাধ্যমে পাস করা উচিত।
অর্থাৎ, এমনকি আপনি যদি বেশ কয়েকটি কনফিগারেশন ফাইল .config.prod .config.local সংরক্ষণ করেন এবং .config (প্রধান কনফিগারেশন যা থেকে অ্যাপ্লিকেশনটি ডেটা পড়ে)-তে স্থাপনের সময় তাদের নাম পরিবর্তন করেন - এটি সঠিক পদ্ধতি হবে না, কারণ এই ক্ষেত্রে কনফিগারেশন থেকে তথ্য সকল অ্যাপ্লিকেশন ডেভেলপারদের কাছে সর্বজনীনভাবে উপলব্ধ হবে এবং উৎপাদন সার্ভার থেকে ডেটা আপস করা হবে। সমস্ত কনফিগারেশন অবশ্যই ডিপ্লয়মেন্ট সিস্টেমে (CI / CD) সরাসরি সংরক্ষণ করতে হবে এবং স্থাপনার সময় একটি নির্দিষ্ট পরিবেশের জন্য প্রয়োজনীয় বিভিন্ন মান সহ বিভিন্ন পরিবেশের জন্য তৈরি করা উচিত।
4. তৃতীয় পক্ষের পরিষেবা (ব্যাকিং পরিষেবা)
পরিবেশের উপর শক্ত বাঁধন, নির্দিষ্ট পরিবেশে একই পরিষেবার জন্য বিভিন্ন সংযোগ ব্যবহার করুন।
প্রকৃতপক্ষে, এই আইটেমটি কনফিগারেশন সম্পর্কিত আইটেমের সাথে দৃঢ়ভাবে ছেদ করা হয়েছে, যেহেতু এই আইটেমটির উপস্থিতি ছাড়া, সাধারণ কনফিগারেশন ডেটা তৈরি করা যাবে না এবং সাধারণভাবে, কনফিগার করার সম্ভাবনা অদৃশ্য হয়ে যাবে।
বাহ্যিক পরিষেবাগুলির সমস্ত সংযোগ যেমন সারি সার্ভার, ডেটাবেস, ক্যাশিং পরিষেবাগুলি স্থানীয় পরিবেশ এবং তৃতীয়-পক্ষ/উৎপাদন পরিবেশ উভয়ের জন্যই একই হতে হবে৷ অন্য কথায়, যে কোনো সময় আমি অ্যাপ্লিকেশন কোড পরিবর্তন না করে বেস # 1 এর সাথে বেস # 2-এ কল প্রতিস্থাপন করতে সংযোগ স্ট্রিং পরিবর্তন করতে পারি। অথবা, সামনের দিকে তাকিয়ে, উদাহরণ হিসাবে, পরিষেবাটি স্কেল করার সময়, আপনাকে অতিরিক্ত ক্যাশে সার্ভারের জন্য কিছু বিশেষ উপায়ে সংযোগ নির্দেশ করতে হবে না।
5. নির্মাণ, মুক্তি, চালানো
সার্ভারে কোডের শুধুমাত্র চূড়ান্ত সংস্করণটি রাখুন, রিলিজ ফিরিয়ে আনার কোন সুযোগ নেই। ডিস্কের জায়গা পূরণ করার দরকার নেই। যিনি মনে করেন যে তিনি একটি ত্রুটির সাথে কোডটি উত্পাদন করতে পারেন তিনি একজন খারাপ প্রোগ্রামার!
সমস্ত স্থাপনার পর্যায় একে অপরের থেকে আলাদা করা উচিত।
রোল ব্যাক একটি সুযোগ আছে. ত্রুটির ক্ষেত্রে পুরানো সংস্করণ পুনরুদ্ধার করার জন্য অ্যাপ্লিকেশনটির পুরানো অনুলিপিগুলিতে দ্রুত অ্যাক্সেস সহ রিলিজগুলি তৈরি করুন (ইতিমধ্যেই একত্রিত এবং যুদ্ধের জন্য প্রস্তুত)। যে, শর্তসাপেক্ষে একটি ফোল্ডার আছে রিলিজ এবং ফোল্ডার বর্তমান, এবং সফল স্থাপনা এবং সমাবেশের পরে, ফোল্ডারটি বর্তমান ভিতরে থাকা নতুন রিলিজের একটি প্রতীকী লিঙ্কের সাথে যুক্ত রিলিজ রিলিজ নম্বরের শর্তসাপেক্ষ নামের সাথে।
এখানেই আমরা ব্লু-গ্রিন স্থাপনার কথা মনে রাখি, যা আপনাকে শুধুমাত্র কোডের মধ্যেই স্যুইচ করতে দেয় না, বরং সমস্ত রিসোর্স এবং এমনকি পরিবেশের মধ্যেও স্যুইচ করতে দেয় এবং সবকিছু ফিরিয়ে আনার ক্ষমতা রাখে।
6. প্রক্রিয়া
অ্যাপ্লিকেশন স্টেট ডেটা সরাসরি অ্যাপ্লিকেশনেই সংরক্ষণ করুন। অ্যাপ্লিকেশনের RAM-তে সেশন ব্যবহার করুন। তৃতীয় পক্ষের পরিষেবাগুলির মধ্যে শেয়ার করা যতটা সম্ভব ব্যবহার করুন। এই বিষয়টিতে টাই করুন যে অ্যাপ্লিকেশনটিতে শুধুমাত্র একটি প্রক্রিয়া থাকতে পারে এবং স্কেলিংকে অনুমতি দেয় না।
সেশন সম্পর্কে, শুধুমাত্র তৃতীয় পক্ষের পরিষেবা (মেমক্যাশেড, রেডিস) দ্বারা নিয়ন্ত্রিত ক্যাশে ডেটা সঞ্চয় করুন, তাই আপনার 20টি অ্যাপ্লিকেশন প্রক্রিয়া চলমান থাকলেও, তাদের মধ্যে যে কেউ ক্যাশে অ্যাক্সেস করে একই অবস্থায় ক্লায়েন্টের সাথে কাজ চালিয়ে যেতে সক্ষম হবে। যেখানে ব্যবহারকারী অন্য প্রক্রিয়ায় অ্যাপ্লিকেশনের সাথে কাজ করছিলেন। এই পদ্ধতির সাথে, এটি দেখা যাচ্ছে যে আপনি তৃতীয় পক্ষের পরিষেবাগুলির কতগুলি অনুলিপি ব্যবহার করেন না কেন, সবকিছু সঠিকভাবে এবং ডেটা অ্যাক্সেসের সমস্যা ছাড়াই কাজ করবে।
7. পোর্ট বাঁধাই
তৃতীয় পক্ষের পরিষেবাগুলির সাথে কীভাবে কাজ করতে হয় তা কেবল ওয়েব সার্ভারেরই জানা উচিত। এবং সাধারণত ওয়েব সার্ভারের ভিতরে তৃতীয় পক্ষের পরিষেবাগুলি বাড়াতে ভাল৷ উদাহরণস্বরূপ, অ্যাপাচিতে একটি পিএইচপি মডিউল হিসাবে।
আপনার সমস্ত পরিষেবাগুলি অবশ্যই কিছু ঠিকানা এবং পোর্টে একটি কলের মাধ্যমে একে অপরের কাছে অ্যাক্সেসযোগ্য হতে হবে (localgost:5432, localhost:3000, nginx:80, php-fpm:9000), অর্থাৎ, nginx থেকে আমি php-fpm এবং উভয়ই অ্যাক্সেস করতে পারি postgres, এবং php-fpm থেকে postgres এবং nginx পর্যন্ত, এবং প্রতিটি পরিষেবা থেকেই, আমি অন্য পরিষেবা অ্যাক্সেস করতে পারি। সুতরাং, একটি পরিষেবার স্বাস্থ্য অন্য পরিষেবার স্বাস্থ্যের সাথে আবদ্ধ নয়।
8. সমান্তরালতা
একটি প্রক্রিয়ার সাথে কাজ করুন, এবং তারপরে হঠাৎ বেশ কয়েকটি প্রক্রিয়া একে অপরের সাথে চলতে পারবে না!
স্কেল করার বিকল্পটি ছেড়ে দিন। ডকার ঝাঁক এই জন্য মহান.
ডকার সোয়ার্ম হল একই মেশিনে বিভিন্ন মেশিন এবং একগুচ্ছ কন্টেইনার উভয়ের মধ্যে পাত্রের ক্লাস্টার তৈরি এবং পরিচালনা করার জন্য একটি টুল।
ঝাঁক ব্যবহার করে, আমি নির্ধারণ করতে পারি যে আমি প্রতিটি প্রক্রিয়ার জন্য কতগুলি সংস্থান বরাদ্দ করব এবং একই পরিষেবার কতগুলি প্রক্রিয়া আমি চালাব, এবং অভ্যন্তরীণ ব্যালেন্সার, একটি প্রদত্ত পোর্টে ডেটা গ্রহণ করে, এটি স্বয়ংক্রিয়ভাবে প্রক্রিয়াগুলিতে প্রক্সি করবে৷ এইভাবে, সার্ভারে লোড বেড়েছে দেখে, আমি আরও প্রসেস যোগ করতে পারি, যার ফলে নির্দিষ্ট প্রসেসের উপর লোড কমে যায়।
9. নিষ্পত্তিযোগ্যতা
প্রসেস এবং ডেটা নিয়ে কাজ করার জন্য সারি ব্যবহার করবেন না। একটি প্রক্রিয়া হত্যা পুরো অ্যাপ্লিকেশনের অপারেশন প্রভাবিত করা উচিত. যদি একটি পরিষেবা বন্ধ হয়ে যায়, তবে সবকিছু ভেঙে যায়।
প্রতিটি প্রক্রিয়া এবং পরিষেবা যে কোনও সময় বন্ধ করা যেতে পারে এবং এটি অন্য পরিষেবাগুলিকে প্রভাবিত করবে না (অবশ্যই, এটি এই সত্যটি সম্পর্কে নয় যে পরিষেবাটি অন্য কোনও পরিষেবাতে অ্যাক্সেসযোগ্য হবে না, তবে এটির পরে অন্য পরিষেবাটি বন্ধ হবে না) . সমস্ত প্রক্রিয়া নরমভাবে বন্ধ করা উচিত, যাতে সেগুলি বন্ধ হয়ে গেলে, ডেটা প্রভাবিত না হয় এবং পরবর্তী সময়ে এটি চালু হলে সিস্টেমটি সঠিকভাবে কাজ করবে। অর্থাৎ, গর্ভপাতের ক্ষেত্রেও, ডেটা প্রভাবিত হওয়া উচিত নয় (লেনদেনের প্রক্রিয়াটি এখানে উপযুক্ত, ডাটাবেসের প্রশ্নগুলি শুধুমাত্র গোষ্ঠীতে কাজ করে, এবং যদি গ্রুপ থেকে অন্তত একটি ক্যোয়ারী ব্যর্থ হয় বা একটি ত্রুটির সাথে কার্যকর করা হয় , তারপর গ্রুপ থেকে অন্য কোন প্রশ্ন অবশেষে বাস্তবে মৃত্যুদন্ড কার্যকর করা হয় না)।
10. অ্যাপ্লিকেশন ডেভেলপমেন্ট/অপারেশন প্যারিটি
অ্যাপ্লিকেশনটির উত্পাদন, মঞ্চায়ন এবং স্থানীয় সংস্করণ অবশ্যই আলাদা হতে হবে। উৎপাদনে, আমাদের কাছে Yii Lite ফ্রেমওয়ার্ক আছে, এবং স্থানীয়ভাবে Yii, যাতে এটি উৎপাদনে দ্রুত কাজ করে!
বাস্তবে, কোড সহ সমস্ত স্থাপনা এবং কাজ প্রায় অভিন্ন পরিবেশে হওয়া উচিত (আমরা শারীরিক হার্ডওয়্যার সম্পর্কে কথা বলছি না)। এছাড়াও, যেকোন ডেভেলপমেন্ট কর্মচারীকে প্রয়োজনে প্রোডাকশনে কোড স্থাপন করতে সক্ষম হওয়া উচিত, এবং কিছু বিশেষভাবে প্রশিক্ষিত ডিভোপস ডিপার্টমেন্ট নয়, যা শুধুমাত্র বিশেষ শক্তির কারণে উৎপাদনে অ্যাপ্লিকেশন বাড়াতে পারে।
Docker এছাড়াও এটি আমাদের সাহায্য করে. পূর্ববর্তী সমস্ত পয়েন্টের সাপেক্ষে, ডকার ব্যবহার করে পরিবেশ স্থাপনের প্রক্রিয়াটি উৎপাদনে এবং স্থানীয় মেশিনে এক বা দুটি কমান্ড প্রবেশ করার জন্য নিয়ে আসবে।
11. লগিং (লগ)
আমরা ফাইল এবং ডাটাবেসে লগ লিখি! আমরা লগ থেকে ফাইল এবং ডাটাবেস পরিষ্কার করি না। আসুন শুধু 9000 পেটা বাইট এবং নিয়মের জন্য একটি হার্ড ড্রাইভ কিনুন।
সমস্ত লগ ইভেন্টের একটি প্রবাহ হিসাবে বিবেচনা করা উচিত. অ্যাপ্লিকেশন নিজেই লগ প্রক্রিয়াকরণ সঙ্গে মোকাবিলা করা উচিত নয়. লগগুলি হয় stdout-এ জারি করা উচিত বা udp-এর মতো প্রোটোকলের মাধ্যমে পাঠানো উচিত যাতে অ্যাপ্লিকেশনটি লগগুলির সাথে কোনও সমস্যা তৈরি না করে। Graylog এই জন্য ভাল কাজ করে। গ্রেলগ udp-এর মাধ্যমে সমস্ত লগ গ্রহণ করে (এই প্রোটোকল ব্যবহার করে, প্যাকেটের সফল অভ্যর্থনা সম্পর্কে কোনও প্রতিক্রিয়ার জন্য অপেক্ষা করার প্রয়োজন নেই) কোনওভাবেই অ্যাপ্লিকেশনটিতে হস্তক্ষেপ করে না এবং শুধুমাত্র লগ গঠন এবং প্রক্রিয়াকরণে নিযুক্ত থাকে। এই পদ্ধতির সাথে কাজ করার জন্য অ্যাপ্লিকেশন যুক্তি পরিবর্তন হয় না।
12. প্রশাসনিক কাজ
ডেটা, ডাটাবেস ইত্যাদি আপডেট করতে, এপিআই-তে একটি পৃথকভাবে তৈরি এন্ডপয়েন্ট ব্যবহার করুন, যার সঞ্চালন একটি সারিতে 2 বার এই সত্যের দিকে পরিচালিত করবে যে সবকিছু আপনার জন্য নকল করা যেতে পারে। কিন্তু আপনি বোকা নন, আপনি 2 বার ক্লিক করবেন না এবং আমাদের মাইগ্রেশনের দরকার নেই।
সমস্ত প্রশাসনিক কাজ অবশ্যই সমস্ত কোডের মতো একই পরিবেশে, রিলিজ স্তরে সম্পাদন করতে হবে। অর্থাৎ, যদি আমাদের ডাটাবেসের কাঠামো পরিবর্তন করতে হয়, তবে আমরা কলামগুলির নাম পরিবর্তন করে এবং কিছু ভিজ্যুয়াল ডাটাবেস পরিচালনার সরঞ্জামগুলির মাধ্যমে নতুন যুক্ত করে ম্যানুয়ালি তা করব না। এই ধরনের জিনিসগুলির জন্য, আমরা আলাদা স্ক্রিপ্ট তৈরি করি - মাইগ্রেশন যা সর্বত্র এবং সমস্ত পরিবেশে একই সাধারণ এবং বোধগম্য ফলাফল সহ সঞ্চালিত হয়। অন্যান্য সমস্ত কাজের জন্য, যেমন ডেটা সহ একটি প্রকল্প জনবহুল করার জন্য, অনুরূপ পদ্ধতি প্রয়োগ করা উচিত।
পিএইচপি, লারাভেল, লারাডক, ডকার-কম্পোজে বাস্তবায়নের উদাহরণ
PS সমস্ত উদাহরণ MacOS এ তৈরি করা হয়েছে। বেশিরভাগই লিনাক্সের জন্যও কাজ করবে। দুঃখিত, উইন্ডোজ ব্যবহারকারীরা, কিন্তু আমি দীর্ঘদিন ধরে উইন্ডোজের সাথে কাজ করিনি।
এমন একটি পরিস্থিতি কল্পনা করুন যে আমাদের পিসিতে পিএইচপি-এর কোনো সংস্করণ ইনস্টল করা নেই এবং কিছুই নেই।
ডকার এবং ডকার-কম্পোজের সর্বশেষ সংস্করণ ইনস্টল করুন। (এটি অনলাইনে পাওয়া যাবে)
docker -v &&
docker-compose -v
1. আমরা রাখি
git clone https://github.com/Laradock/laradock.git &&
ls
লারাডক সম্পর্কে, আমি বলব যে এটি একটি খুব দুর্দান্ত জিনিস, যাতে প্রচুর পাত্র এবং সহায়ক জিনিস সংগ্রহ করা হয়। কিন্তু উৎপাদনে কোনো পরিবর্তন ছাড়াই লারাডক ব্যবহার করার জন্য - আমি এর অপ্রয়োজনীয়তার কারণে এটি সুপারিশ করব না। ল্যারাডকের উদাহরণের উপর ভিত্তি করে আপনার পাত্রে তৈরি করা ভাল, তাই সেখানে অনেক অপ্টিমাইজেশন হবে, কারণ একই সময়ে সেখানে থাকা সমস্ত কিছুর প্রয়োজন নেই।
2. আমাদের অ্যাপ্লিকেশন কাজ করার জন্য Laradock কনফিগার করা।
cd laradock &&
cp env-example .env
2.1। যে কোনো এডিটরে habr ডিরেক্টরিটি খুলুন (যে মূল ফোল্ডারে laradock ক্লোন করা হয়েছে)। (আমার PHPStorm ক্ষেত্রে)
এই পর্যায়ে, আমরা শুধু প্রকল্পের নাম রাখি।
2.2। আমরা ওয়ার্কস্পেস ইমেজ চালু করি। (আপনার ক্ষেত্রে, ছবিগুলি কিছু সময়ের জন্য তৈরি হবে)
ওয়ার্কস্পেস হল ডেভেলপারের পক্ষ থেকে ফ্রেমওয়ার্কের সাথে কাজ করার জন্য একটি বিশেষভাবে প্রস্তুত করা ছবি।
সঙ্গে পাত্রের ভিতরে যান
docker-compose up -d workspace &&
docker-compose exec workspace bash
2.3। লারাভেল ইনস্টল করা হচ্ছে
composer create-project --prefer-dist laravel/laravel application
2.4। ইনস্টলেশনের পরে, আমরা প্রকল্পের সাথে ডিরেক্টরি তৈরি করা হয়েছে কিনা তা পরীক্ষা করি এবং কম্পোজ কিল করি।
ls
exit
docker-compose down
2.5। আমরা PHPStorm এ ফিরে আসি এবং .env ফাইলে আমাদের ল্যারাভেল অ্যাপ্লিকেশনের সঠিক পথ সেট করি।
3. Git-এ সমস্ত কোড যোগ করুন।
এটি করার জন্য, আমরা Github (বা অন্য কোথাও) একটি সংগ্রহস্থল তৈরি করব। টার্মিনালে habr ডিরেক্টরিতে যান এবং নিম্নলিখিত কোডটি চালান।
echo "# habr-12factor" >> README.md
git init
git add README.md
git commit -m "first commit"
git remote add origin [email protected]:nzulfigarov/habr-12factor.git # здесь будет ссылка на ваш репо
git push -u origin master
git status
সবকিছু ঠিকঠাক আছে কিনা তা আমরা পরীক্ষা করি।
সুবিধার জন্য, আমি গিটের জন্য কিছু ধরণের ভিজ্যুয়াল ইন্টারফেস ব্যবহার করার পরামর্শ দিই, আমার ক্ষেত্রে এটি . (এখানে রেফারেল লিঙ্ক)
4. লঞ্চ!
শুরু করার আগে, নিশ্চিত করুন যে আপনার পোর্ট 80 এবং 443 এ কিছু ঝুলছে না।
docker-compose up -d nginx php-fpm
সুতরাং, আমাদের প্রকল্প 3টি পৃথক পরিষেবা নিয়ে গঠিত:
- nginx - ওয়েব সার্ভার
- php-fpm - একটি ওয়েব সার্ভার থেকে অনুরোধ পাওয়ার জন্য php
- কর্মক্ষেত্র - বিকাশকারীর জন্য পিএইচপি
এই মুহুর্তে, আমরা অর্জন করেছি যে আমরা 4টির মধ্যে 12টি পয়েন্টের সাথে সম্পর্কিত একটি অ্যাপ্লিকেশন তৈরি করেছি, যথা:
1. কোডবেস - সমস্ত কোড একটি সংগ্রহস্থলে রয়েছে (একটি ছোট নোট: লারাভেল প্রকল্পের ভিতরে ডকার আনা ঠিক হতে পারে, তবে এটি গুরুত্বপূর্ণ নয়)।
2. নির্ভরতা - আমাদের সমস্ত নির্ভরতা স্পষ্টভাবে application/composer.json এবং প্রতিটি কন্টেইনারের প্রতিটি ডকারফাইলে লেখা আছে।
3. তৃতীয় পক্ষের পরিষেবা (ব্যাকিং পরিষেবা) - প্রতিটি পরিষেবা (php-fom, nignx, ওয়ার্কস্পেস) তার নিজস্ব জীবনযাপন করে এবং বাইরে থেকে সংযুক্ত এবং একটি পরিষেবার সাথে কাজ করার সময়, অন্যটি প্রভাবিত হবে না৷
4. প্রসেস প্রতিটি পরিষেবা একটি প্রক্রিয়া। প্রতিটি পরিষেবা অভ্যন্তরীণ অবস্থা সংরক্ষণ করে না।
5. পোর্ট বাঁধাই
docker ps
আমরা দেখতে পাচ্ছি, প্রতিটি পরিষেবা তার নিজস্ব পোর্টে চলছে এবং অন্যান্য সমস্ত পরিষেবার জন্য উপলব্ধ।
6. উপমা
ডকার আমাদের তাদের মধ্যে স্বয়ংক্রিয় লোড ব্যালেন্সিং সহ একই পরিষেবাগুলির একাধিক প্রক্রিয়া তৈরি করতে দেয়।
পাত্রে থামুন এবং একটি পতাকা দিয়ে শুরু করুন --স্কেল
docker-compose down &&
docker-compose up -d --scale php-fpm=3 nginx php-fpm
আমরা দেখতে পাচ্ছি, php-fpm কন্টেইনারে কপি আছে। এই ধারকটির সাথে কাজ করার জন্য আমাদের কিছু পরিবর্তন করার দরকার নেই। আমরা 9000 পোর্টে এটি অ্যাক্সেস করা চালিয়ে যাচ্ছি এবং ডকার আমাদের জন্য কন্টেইনারগুলির মধ্যে লোড নিয়ন্ত্রণ করে।
7. নিষ্পত্তিযোগ্যতা - প্রতিটি পাত্রে অন্যটিকে ক্ষতি না করে হত্যা করা যেতে পারে। কন্টেইনার বন্ধ করা বা পুনরায় চালু করা পরবর্তী লঞ্চে অ্যাপ্লিকেশনটির ক্রিয়াকলাপকে প্রভাবিত করবে না। প্রতিটি কন্টেইনার যে কোন সময় উত্তোলন করা যেতে পারে।
8. অ্যাপ্লিকেশন ডেভেলপমেন্ট/অপারেশন প্যারিটি আমাদের সব পরিবেশ একই। উৎপাদনে সার্ভারে সিস্টেম চালানোর মাধ্যমে, আপনাকে আপনার কমান্ডে কিছু পরিবর্তন করতে হবে না। সবকিছু একইভাবে ডকারের উপর ভিত্তি করে হবে।
9. লগিং - এই পাত্রে থাকা সমস্ত লগ স্ট্রীমে যায় এবং ডকার কনসোলে দৃশ্যমান হয়। (এই ক্ষেত্রে, প্রকৃতপক্ষে, অন্যান্য বাড়িতে তৈরি পাত্রের সাথে, আপনি এটির যত্ন না নিলে এটি নাও হতে পারে)
docker-compose logs -f
তবে, পিএইচপি এবং এনজিনেক্সের ডিফল্ট মানগুলি একটি ফাইলে লগ লিখতেও একটি ক্যাচ রয়েছে। 12টি বিষয় পূরণ করতে আপনার প্রয়োজন বাহিরে রাখা প্রতিটি কন্টেইনারের কনফিগারেশনে আলাদাভাবে একটি ফাইলে লগ লেখা।
ডকার শুধু stdout-এ নয়, graylog-এর মতো জিনিসগুলিতেও লগ পাঠানোর ক্ষমতা প্রদান করে, যা আমি উপরে উল্লেখ করেছি। এবং গ্রেলগের ভিতরে, আমরা আমাদের পছন্দ মতো লগগুলি দিয়ে কাজ করতে পারি এবং আমাদের অ্যাপ্লিকেশন কোনওভাবেই এটি লক্ষ্য করবে না।
10. প্রশাসনের কাজ - 12 ফ্যাক্টর অ্যাপ্লিকেশনের নির্মাতারা ঠিক যেমনটি চান কারিগর সরঞ্জামের জন্য সমস্ত প্রশাসনিক কাজ লারাভেলের মাধ্যমে সমাধান করা হয়।
একটি উদাহরণ হিসাবে, আমি দেখাব কিভাবে কিছু কমান্ড নির্বাহ করা হয়।
আমরা পাত্রে যেতে.
docker-compose exec workspace bash
php artisan list
এখন আমরা যেকোনো কমান্ড ব্যবহার করতে পারি। (দয়া করে মনে রাখবেন যে আমরা ডাটাবেস এবং ক্যাশে সেট আপ করিনি, তাই অর্ধেক কমান্ড সঠিকভাবে কার্যকর করা হবে না, কারণ সেগুলি ক্যাশে এবং ডাটাবেসের সাথে কাজ করার জন্য ডিজাইন করা হয়েছে)।
11. কনফিগারেশন এবং 12। নির্মাণ, মুক্তি, চালান
আমি এই অংশটি নীল-সবুজ স্থাপনার জন্য উত্সর্গ করতে চেয়েছিলাম, কিন্তু এটি এই নিবন্ধটির জন্য খুব বিশদ হতে দেখা গেছে। আমি এই সম্পর্কে একটি পৃথক নিবন্ধ লিখব.
সংক্ষেপে, ধারণাটি সিআই/সিডি সিস্টেমের উপর ভিত্তি করে জেনকিন্স и গিটল্যাব সিআই. উভয় ক্ষেত্রে, আপনি একটি নির্দিষ্ট পরিবেশের সাথে সম্পর্কিত পরিবেশ ভেরিয়েবল সেট করতে পারেন। তদনুসারে, এই দৃশ্যে, আইটেম গ কনফিগারেশন.
এবং সম্পর্কে বিন্দু নির্মাণ, মুক্তি, চালান উভয় ইউটিলিটি নামক বিল্ট-ইন ফাংশন দ্বারা সমাধান করা হয় পাইপলাইন.
পাইপলাইন সমাবেশ, প্রকাশ এবং সম্পাদনের পর্যায়গুলিকে হাইলাইট করে আপনাকে স্থাপনার প্রক্রিয়াটিকে অনেকগুলি পর্যায়ে ভাগ করতে দেয়। এছাড়াও পাইপলাইনে, আপনি ব্যাকআপ তৈরি করতে পারেন, এবং প্রকৃতপক্ষে কিছু। এই টুল সীমাহীন সম্ভাবনা আছে.
অ্যাপ্লিকেশন কোড চালু আছে .
এই সংগ্রহস্থলটি ক্লোন করার সময় সাবমডিউলটি আরম্ভ করতে ভুলবেন না।
PS: এই সমস্ত পদ্ধতি অন্য কোন ইউটিলিটি এবং প্রোগ্রামিং ভাষার সাথে ব্যবহার করা যেতে পারে। প্রধান জিনিস হল যে সারাংশ ভিন্ন হয় না।
উত্স: www.habr.com