Boto3 — Python থেকে AWS চালানো

পর্ব ১৩-এ দেখেছি CLI দিয়ে কত কিছু করা যায় — প্রশ্ন করা, ফিল্টার করা, গুনতে। তাহলে SDK-র দরকার কোথায়?

উত্তরটা একটা নির্দিষ্ট জায়গায়: যখন একটা সিদ্ধান্ত নিতে হয়।

একটা উদাহরণ দিয়ে দেখি। কাজটা: "যেসব EC2 instance-এ Environment tag নেই, তাদের Environment=unknown tag লাগাও, আর একটা তালিকা একটা ফাইলে লেখো।"

CLI-তে এটা করা যায় — --query দিয়ে তালিকা বের করা, তারপর একটা shell লুপ, তারপর প্রতিটায় create-tags। কাজ করবে। কিন্তু কয়েকটা জিনিস অস্বস্তিকর হয়ে যায়:

• JSON পার্স করা shell-এ ভঙ্গুর (jq লাগবে, আর উদ্ধৃতিচিহ্নের ঝামেলা)

• একটা instance-এ ব্যর্থ হলে বাকিগুলো চালিয়ে যাওয়া — এটা লিখতে হয়

• পরিসংখ্যান রাখা, একটা প্রতিবেদন লেখা — shell-এ এগুলো কষ্টের

আর ঠিক এই জায়গাগুলোতেই একটা প্রোগ্রামিং ভাষা ভালো। লুপ, শর্ত, ত্রুটি সামলানো, ডেটা গঠন — এগুলোর জন্যই ভাষাটা তৈরি।

তাই ভাগটা এরকম, আর এটা একটা ব্যবহারিক নিয়ম:

শেষ সারিটা গুরুত্বপূর্ণ, আর পর্ব ১৬-তে সেটাই লাগবে: একটা Lambda ফাংশনের ভেতরে কোনো shell নেই, কোনো CLI নেই। ওখানে AWS-এর সাথে কথা বলার একমাত্র পথ SDK।

আর একটা জিনিস জেনে রাখা দরকার, যেটা পুরো ছবিটা পরিষ্কার করে দেয়: CLI নিজেই Python-এ লেখা, আর সে Boto3-র উপরে দাঁড়িয়ে (আরো সঠিকভাবে, botocore-এর উপরে)।

অর্থাৎ তুমি যখন aws s3 ls চালাও, তখন একটা Python প্রোগ্রাম চলছে যেটা ঠিক ওই কলগুলোই করছে যেগুলো তুমি নিজে লিখতে পারতে। CLI আর SDK প্রতিযোগী নয় — একটা অন্যটার উপরে বসা।

আর তার নিচে? HTTPS। প্রতিটা AWS কাজ একটা সই করা HTTPS অনুরোধ। তুমি চাইলে curl দিয়েও করতে পারো — কিন্তু করবে না, কারণ সইটা তৈরি করা জটিল (AWS Signature v4), আর ওটাই SDK-র প্রধান কাজ।

তাহলে SDK আসলে তিনটে কাজ করে, আর তিনটেই না করলে অনেক কষ্ট:

১. অনুরোধটা সই করে — AWS Signature v4, যেটা হাতে লেখার মতো জিনিস নয়
২. ব্যর্থ হলে আবার চেষ্টা করে, বাড়তে থাকা বিরতি দিয়ে — নেটওয়ার্কের ক্ষণিক সমস্যায় এটা বিনামূল্যের নির্ভরযোগ্যতা
৩. উত্তরটা একটা dictionary-তে বদলে দেয় — XML বা JSON পার্স করার কাজটা তোমার থাকে না

Boto3 একটা জিনিস দু-ভাবে বলতে দেয়, আর নতুন ব্যবহারকারীরা এখানেই সবচেয়ে বেশি বিভ্রান্ত হয়। ছবিটা দেখো — দুটো পথ, একই HTTPS অনুরোধ।

Client — প্রতি API কলের জন্য একটা ফাংশন

s3 = boto3.client("s3")
s3.upload_file("report.json", "devops-lab-artifacts", "reports/report.json")

বৈশিষ্ট্য:

• প্রতিটা method হুবহু একটা API operation — list_buckets, put_object, describe_instances

• নামকরণ CLI-র সাথে মেলে, শুধু --এর জায়গায় _ (describe-instances → describe_instances)

• সব সেবার জন্য আছে, সব operation-এর জন্য

• উত্তর আসে একটা dictionary হিসেবে, আর কাঠামোটা API-র প্রতিচ্ছবি

Resource — বস্তু, যাদের method আছে

bucket = boto3.resource("s3").Bucket("devops-lab-artifacts")
bucket.upload_file("report.json", "reports/report.json")

বৈশিষ্ট্য:

• পড়তে অনেক সুন্দর — একটা bucket একটা বস্তু, আর তার method আছে

• সম্পর্কগুলো স্বাভাবিকভাবে আসে: for obj in bucket.objects.all()

• শুধু কয়েকটা সেবার জন্য আছে — S3, EC2, DynamoDB, SQS, IAM আর আরো দু-তিনটে

• AWS এটায় নতুন কিছু যোগ করা বন্ধ করেছে, আর এটাই সিদ্ধান্তটা সহজ করে দেয়

তাহলে কোনটা ব্যবহার করবে? সৎ উত্তর:

Client ডিফল্টে ব্যবহার করো। Resource ব্যবহার করো যেখানে ওটা একটা নির্দিষ্ট কোডকে স্পষ্টভাবে ভালো করে।

তিনটে কারণে:

১. Client সব জায়গায় আছে। Resource শিখলে অর্ধেক সেবায় সেটা কাজে লাগবে না, আর তখন দুটোই জানতে হবে।