গোল্ডেন AMI («সোনালি ইমেজ») হলো পূর্বনির্ধারিত, হার্ডেন্ড ও যাচাই করা একটি Amazon Machine Image, যা অভিন্ন EC2 ইনস্ট্যান্স চালু করার একমাত্র টেমপ্লেট হিসেবে কাজ করে। প্রতিবার খালি সার্ভার চালু করে হাতে নির্ভরতা বসানোর বদলে আপনি সবকিছু একবারেই «সেঁকে» ফেলেন —প্যাচ করা অপারেটিং সিস্টেম, এজেন্ট, রানটাইম, কনফিগারেশন ও নিরাপত্তা নিয়ন্ত্রণ— আর প্রতিটি মোতায়েনে সেটিই পুনর্ব্যবহার করেন।
এই দৃষ্টিভঙ্গিই অপরিবর্তনীয় অবকাঠামোর ভিত্তি: চালু সার্ভারে প্যাচ দেওয়া হয় না, বরং নতুন ইমেজ বানিয়ে ইনস্ট্যান্স বদলে ফেলা হয়। ফল: কম কনফিগারেশন বিচ্যুতি, অটোস্কেলিংয়ে দ্রুত বুট, আর এমন মোতায়েন যা নিরীক্ষা ও ফিরিয়ে আনা — দুটোই সম্ভব।
গোল্ডেন AMI বনাম বুটে বুটস্ট্র্যাপিং
দুটি দর্শন আছে। বুটস্ট্র্যাপিং-এ ইনস্ট্যান্স বুটের সময় নিজেকে কনফিগার করে (user-data, Ansible pull, cloud-init)। এটি নমনীয়, কিন্তু ধীর ও ভঙ্গুর: কোনো প্যাকেজ রিপোজিটরি পড়ে গেলে আপনার অটোস্কেলিং ব্যর্থ হয়। গোল্ডেন AMI (বেকিং) মডেলে ভারী কাজ পাইপলাইনে একবারই হয়; বুট প্রায় তাৎক্ষণিক ও নির্ধারিত। পরিণত দলগুলো সাধারণত দুটোই মেলায়: স্থির অংশ সেঁকে নেয়, আর বুটে রাখে কেবল সেই কনফিগারেশন যা পরিবেশভেদে বদলায়।
Packer কেন
HashiCorp-এর Packer একটিমাত্র টেমপ্লেট থেকে স্বয়ংক্রিয় ও বহু-ক্লাউড মেশিন ইমেজ বানানোর কার্যত মানদণ্ড। আপনি ইমেজকে কোড (HCL2) হিসেবে সংজ্ঞায়িত করেন; এটি একটি অস্থায়ী ইনস্ট্যান্স চালায়, আপনার প্রোভিশনার প্রয়োগ করে, AMI বানায় এবং অস্থায়ী রিসোর্স মুছে দেয়। একই টেমপ্লেট AWS, Azure ও GCP-র জন্য ইমেজ বানাতে পারে, যা একাধিক ক্লাউডে প্রকাশ করলে আদর্শ।
- পুনরুৎপাদনযোগ্য: ইমেজ বর্ণিত থাকে Git-এ সংস্করণকৃত একটি ফাইলে।
- বহু-ক্লাউড: AMI, Azure Managed Image ও GCP Custom Image-এর জন্য একটাই প্রবাহ।
- সংযোজনযোগ্য: CI/CD-তে খাপ খায় (GitHub Actions, GitLab CI, CodePipeline)।
- নিরীক্ষাযোগ্য: প্রতিটি বিল্ড নথিভুক্ত থাকে, তার ম্যানিফেস্ট ও আর্টিফ্যাক্টসহ।
একটি Packer টেমপ্লেটের (HCL2) শারীরস্থান
আধুনিক টেমপ্লেট ব্লকে সাজানো। source ব্লক ঠিক করে বিল্ডার (যেমন amazon-ebs), বেস
AMI, ইনস্ট্যান্স টাইপ ও অঞ্চল। build ব্লক সেই প্রোভিশনারগুলো ধারাবাহিকভাবে চালায় যা
সফটওয়্যার ইনস্টল ও কনফিগার করে। post-processor তৈরি করে আর্টিফ্যাক্ট, যেমন ফলস্বরূপ
AMI-এর আইডিসহ JSON ম্যানিফেস্ট।
টীকাসহ ন্যূনতম উদাহরণ
source "amazon-ebs" "app" — অফিসিয়াল বেস AMI থেকে শুরু হয়, যা data "amazon-ami" দিয়ে
মালিক ও নামের ধরণ ছেঁকে গতিশীলভাবে খুঁজে নেওয়া হয়, যাতে মেয়াদোত্তীর্ণ হবে এমন কোনো আইডি
গেঁথে না যায়।
provisioner "shell" — ইনস্টলেশন ও হালনাগাদের স্ক্রিপ্ট চালায় (dnf update -y, রানটাইম,
CloudWatch এজেন্ট, SSM এজেন্ট)।
provisioner "ansible" — আপনার যদি আগেই Ansible রোল থাকে, সেগুলো পুনর্ব্যবহার করে
ইডেমপোটেন্টভাবে ইমেজ কনফিগার করুন।
post-processor "manifest" — manifest.json লেখে, যাতে থাকে artifact_id; আপনার
পাইপলাইন সেটি পড়ে জানে কোন AMI জন্ম নিল।
ধাপে ধাপে পাইপলাইন
কমিট থেকে প্রোডাকশন পর্যন্ত গোল্ডেন AMI নিরাপদে ও পুনরাবৃত্তিযোগ্যভাবে নিতে আমরা এই প্রবাহ সুপারিশ করি:
| ধাপ | কী ঘটে | প্রচলিত সরঞ্জাম |
|---|---|---|
| ১. Commit | টেমপ্লেট বা স্ক্রিপ্ট বদলে Git-এ পুশ করেন | Git / PR পর্যালোচনা |
| ২. Validate | packer fmt + packer validate সিনট্যাক্স যাচাই করে | Packer, CI |
| ৩. Build | Packer অস্থায়ী ইনস্ট্যান্স চালিয়ে প্রোভিশনার প্রয়োগ করে | Packer |
| ৪. Harden | CIS বেঞ্চমার্ক প্রয়োগ ও ক্রেডেনশিয়াল পরিষ্কার | Ansible / CIS |
| ৫. Scan | দুর্বলতা ও সিক্রেট স্ক্যান | Trivy, Inspector |
| ৬. Test | একটি ইনস্ট্যান্স চালিয়ে যাচাই | InSpec / Goss |
| ৭. Tag & version | AMI-তে ট্যাগ (সংস্করণ, কমিট, তারিখ) | AWS CLI |
| ৮. Distribute | অন্য অঞ্চলে বা অ্যাকাউন্টে ভাগ বা কপি | AWS RAM / copy |
| ৯. Deploy | Launch Template-এ AMI-এর উল্লেখ | Terraform / ASG |
নয় ধাপের গোল্ডেন AMI পাইপলাইনের রেফারেন্স প্রবাহ।
যেসব অভ্যাস সত্যিই পার্থক্য গড়ে
- বেস AMI কখনো আইডি দিয়ে বাঁধবেন না: মালিক ও নাম ধরে গতিশীলভাবে খুঁজুন, যাতে সবসময় সাম্প্রতিক প্যাচ উত্তরাধিকারে পান।
- ইমেজের সংস্করণ রাখুন স্পষ্ট স্কিমে (যেমন
app-2026.07.1) এবং Git কমিট AMI ট্যাগে সংরক্ষণ করুন। - সিল করার আগে পরিষ্কার করুন: লগ, শেল ইতিহাস, অস্থায়ী SSH কী ও প্যাকেজ ক্যাশ মুছে দিন, যাতে সিক্রেট ফাঁস না হয়।
- সবসময় স্ক্যান করুন: Trivy বা Amazon Inspector যুক্ত করুন, যাতে জানা CVE প্রকাশ না হয়।
- স্ন্যাপশট এনক্রিপ্ট করুন প্রথম মিনিট থেকেই নিজের KMS কী দিয়ে।
- মেয়াদোত্তীর্ণতা স্বয়ংক্রিয় করুন: পুরোনো সংস্করণ অবচিত চিহ্নিত করে মুছে দিন, যাতে খরচ নিয়ন্ত্রণে থাকে।
Packer না EC2 Image Builder — কোনটি বাছব?
আপনি যদি কেবল AWS-এ কাজ করেন এবং Inspector-এর সঙ্গে নেটিভ সংহতি, ব্যবস্থাপিত CIS কম্পোনেন্ট ও রক্ষণাবেক্ষণহীন অবকাঠামো পছন্দ করেন, তবে EC2 Image Builder শক্ত বিকল্প, লাইসেন্স খরচও নেই। আর যদি একই টেমপ্লেট থেকে একাধিক ক্লাউডের জন্য বানাতে হয়, বা আপনার আগে থেকেই HashiCorp ইকোসিস্টেম (Terraform, Vault) থাকে, তবে Packer বেশি বহনযোগ্যতা দেবে। এরা পরস্পরবিরোধী নয়: বহু দল বহু-ক্লাউড যুক্তির জন্য Packer আর অভ্যন্তরীণ AWS পাইপলাইনের জন্য Image Builder ব্যবহার করে।
প্রায়শই জিজ্ঞাসিত প্রশ্ন
গোল্ডেন AMI কত ঘন ঘন পুনর্নির্মাণ করা উচিত?
অন্তত অপারেটিং সিস্টেমের প্রতিটি প্যাচ চক্রে (মাসিক সাধারণত ভালো ছন্দ) এবং যখনই আপনার স্ট্যাকে গুরুতর CVE প্রকাশ পায়। স্বয়ংক্রিয় পাইপলাইন থাকলে চাহিদামাফিক কয়েক মিনিটেই পুনর্নির্মাণ সম্ভব।
একই Packer টেমপ্লেট কি AWS ও Azure দুটোতেই ব্যবহার করা যায়?
হ্যাঁ। Packer একই বিল্ডে একাধিক বিল্ডার সমর্থন করে। প্রোভিশনার ভাগ করা থাকে, কেবল প্রতিটি ক্লাউডের source ব্লক বদলায়; ফলে সমান্তরালে AMI, Managed Image ও Custom Image তৈরি হয়।
গোল্ডেন AMI না কনটেইনার?
এটি «একটি বা অন্যটি»-র প্রশ্ন নয়। গোল্ডেন AMI হোস্ট স্তরের জন্য এবং কনটেইনারবিহীন ওয়ার্কলোডের জন্য আদর্শ; কনটেইনার চলে তার উপরে। বরং হার্ডেন্ড গোল্ডেন AMI আপনার Kubernetes নোডের চমৎকার ভিত্তি।
imaxe.cloud-এ আমরা হার্ডেন্ড ও হালনাগাদ বেস ইমেজ বানাই ও রক্ষণাবেক্ষণ করি, যাতে আপনার পাইপলাইন নির্ভরযোগ্য ভিত্তি থেকে শুরু হয়।
