হাতে ক্লিক করার চারটে দাম, IaC-র সরঞ্জামগুলোর সৎ তুলনা, template আর stack-এর পার্থক্য, template-এর ঘরগুলো, একটা resource-এর আকৃতি, parameter আর তার সীমা, আর সেই hardcoded AMI id-টা যেটা একটা template-কে এক region-এর করে ফেলে।
পর্ব ১৮-এর শেষে একটা প্রশ্ন রেখে এসেছি: যদি হাতে করা প্রতিটা কাজ একটা ঘটনা হয়ে যেতে পারে, তাহলে হাতে কাজ করাটাই কমানো যায় না?
এই পর্বটা সেই প্রশ্নের উত্তর। কিন্তু তার আগে সৎভাবে দেখা দরকার হাতে কাজ করার দামটা আসলে কী — কারণ "অটোমেশন ভালো" একটা অলস উত্তর, আর ওটা কাউকে রাজি করায় না।
চারটে দাম, আর সময়টা তার মধ্যে সবচেয়ে কম গুরুত্বপূর্ণ।
দাম ১ — এটা পুনরুৎপাদনযোগ্য নয়।
পর্ব ৮-এ এই কথাটা একটা সার্ভারের প্রসঙ্গে বলেছি; এখন এটা পুরো অবকাঠামোর প্রসঙ্গে। একটা VPC, তিনটে subnet, একটা gateway, দুটো route table, তিনটে security group, একটা load balancer — ত্রিশটা ক্লিকের একটা ক্রম।
ওটা দ্বিতীয়বার হুবহু করতে পারবে? না। আর staging আর production যদি হুবহু এক না হয়, তাহলে staging-এ পরীক্ষা করার কোনো মানে নেই — কারণ তুমি যা পরীক্ষা করলে সেটা production নয়।
দাম ২ — মুছে ফেলা অসম্পূর্ণ হয়।
এটা সবচেয়ে বেশি টাকা খায়, আর পর্ব ৪-এ আমরা এর লক্ষণগুলো দেখেছি: একটা বিচ্ছিন্ন ডিস্ক, একটা একা পড়ে থাকা Elastic IP। কারণটা এখন বলা যায়: হাতে বানানো জিনিসের কোনো তালিকা নেই।
ত্রিশটা ক্লিক করে কিছু বানালে, মুছতে ত্রিশটা ক্লিক লাগে — আর তুমি মনে রাখবে না ক-টা ছিল। তিনটে থেকে যায়, আর তিন মাস পরে কেউ জিজ্ঞেস করে "এই security group-টা কীসের?"
দাম ৩ — কোনো পর্যালোচনা নেই।
তোমার কোডের প্রতিটা লাইন একটা pull request-এ যায়, কেউ পড়ে, কেউ অনুমোদন করে। আর তোমার অবকাঠামো? কেউ একটা কনসোলে কিছু ক্লিক করল, আর ওটা এখন production-এ চলছে।
ভেবে দেখো এর অসঙ্গতিটা: একটা ফাংশনের নাম বদলানো পর্যালোচনা লাগে, আর একটা firewall-এর নিয়ম বদলানো লাগে না।
দাম ৪ — কোনো ইতিহাস নেই।
"এই subnet-টা কেন এভাবে সাজানো?" — এর উত্তর হাতে করা অবকাঠামোতে নেই। পর্ব ১৮-এর CloudTrail বলতে পারে কে আর কখন, কিন্তু কেন বলতে পারে না। আর "কেন"-টাই সবচেয়ে বেশি দরকার হয়, যখন কিছু বদলাতে হয়।
এই চারটে দামের একটাই সমাধান, আর সেটা একটা ধারণার বদল:
অবকাঠামোটা একটা ফাইলে লিখে রাখো, আর ফাইলটাকে উৎস হিসেবে ধরো।
তারপর চারটে দামই মিটে যায়: ফাইলটা পুনরুৎপাদনযোগ্য, ফাইলটাই তালিকা, ফাইলটা pull request-এ যায়, আর git-এর ইতিহাসই "কেন"-এর উত্তর — প্রতিটা পরিবর্তনের সাথে একটা commit message।
আর এটার নাম Infrastructure as Code, বা IaC। শব্দটা বড়, ধারণাটা এক বাক্য।
IaC-র কয়েকটা সরঞ্জাম আছে, আর এগুলো নিয়ে অনলাইনে অনেক পক্ষপাতদুষ্ট লেখা আছে। একটা সৎ তুলনা দরকার, কারণ পছন্দটা প্রসঙ্গের উপর নির্ভর করে।
তিনটে সারি আলাদা করে বোঝা দরকার।
"অবস্থা কোথায়" সারিটা সবচেয়ে বড় ব্যবহারিক পার্থক্য। Terraform একটা state file রাখে — একটা ফাইল যেটা জানে কোন সম্পদ ওর তৈরি। ওই ফাইলটা তোমার, আর তোমাকে ওটা সুরক্ষিত রাখতে হবে, ভাগ করতে হবে, আর locking সাজাতে হবে (নইলে দুজন একসাথে চালালে অবকাঠামো ভাঙে)।
CloudFormation-এ ওই ফাইলটা নেই — AWS নিজে stack-এর অবস্থা রাখে। এটা একটা আসল সুবিধা, আর শেখার সময় এটা একটা বড় জিনিস কম ভাবার।
"কোন ক্লাউড" সারিটা Terraform-এর প্রধান যুক্তি, আর সেটা বৈধ — যদি তুমি একাধিক ক্লাউড ব্যবহার করো। কিন্তু সৎ থাকো: বেশিরভাগ দল একটাই ক্লাউড ব্যবহার করে, আর তখন ওই সুবিধাটা তাত্ত্বিক।
"নতুন সেবা" সারিটা কম আলোচিত কিন্তু কাজের: AWS একটা নতুন সেবা বা একটা নতুন সেটিং ছাড়লে CloudFormation-এ সেটা প্রথম দিনেই থাকে, কারণ একই সংস্থা দুটো বানায়। Terraform-এ provider হালনাগাদ হওয়া পর্যন্ত অপেক্ষা।
আর CDK নিয়ে একটা কথা, কারণ এটা একটা আকর্ষণীয় বিকল্প: CDK-তে তুমি Python বা TypeScript-এ অবকাঠামো লেখো, আর সেটা CloudFormation template তৈরি করে। অর্থাৎ CDK একটা উপরের স্তর, প্রতিযোগী নয়।
সুবিধা: লুপ, শর্ত, ফাংশন — একটা আসল ভাষার সব কিছু। অসুবিধা: আরেকটা স্তর বোঝার দরকার, আর নিচে কী তৈরি হচ্ছে সেটা না জানলে ডিবাগ করা কঠিন।
এই কোর্সে CloudFormation, তিনটে কারণে:
১. কোনো state file নেই — একটা কম জিনিস ভুল হওয়ার।
২. কোনো অতিরিক্ত সরঞ্জাম বসাতে হয় না — CLI-তেই আছে।
৩. CDK শিখতে চাইলেও CloudFormation জানা দরকার, কারণ CDK এটাই তৈরি করে। আর Terraform শিখতে চাইলেও ধারণাগুলো একই — template, state, plan, apply।
অর্থাৎ এটা শেখা অপচয় নয়, যেদিকেই যাও।
দুটো শব্দ, আর এই দুটো আলাদা রাখাটাই CloudFormation বোঝার চাবি:
ছবিটা দেখো — একটা template, তিনটে stack। আর প্রতিটা stack-এর নিজের parameter-এর মান, নিজের আসল সম্পদ, আর নিজের জীবনচক্র।
এটা পর্ব ৮-এর launch template-এর ধারণাটার একটা বড় সংস্করণ, আর সাদৃশ্যটা কাজের: template একটা বর্ণনা, stack একটা উদাহরণ।
আর এই ভাগটার তিনটে ব্যবহারিক ফল আছে:
ফল ১ — একই template দিয়ে dev, staging আর production।
আর শুধু "একই রকম" নয় — হুবহু একই, কারণ উৎসটা এক ফাইল। পার্থক্যটা শুধু parameter-এর মানে: dev-এ t3.micro, production-এ m5.large।
এটাই দাম ১-এর উত্তর। এবার staging-এ পরীক্ষা করার একটা মানে আছে, কারণ staging আর production একই বর্ণনা থেকে এসেছে।
ফল ২ — একটা stack-এর একটা জীবনচক্র আছে।
১৮৯টি অংশের ৩৮টি দেখানো হয়েছে, ১৫১টি বাকি