ভবিষ্যতের জন্য টেরাফর্মে অবকাঠামোর বর্ণনা। অ্যান্টন বাবেনকো (2018)

অনেক লোক তাদের দৈনন্দিন কাজে Terraform জানে এবং ব্যবহার করে, কিন্তু এখনও এটির জন্য কোন সেরা অনুশীলন নেই। প্রতিটি দলকে তার নিজস্ব পদ্ধতি এবং পদ্ধতি উদ্ভাবন করতে হবে।

আপনার অবকাঠামো প্রায় অবশ্যই সহজ থেকে শুরু হয়: কয়েকটি সংস্থান + কয়েকটি বিকাশকারী। সময়ের সাথে সাথে, এটি সমস্ত দিকে বৃদ্ধি পায়। আপনি কি টেরাফর্ম মডিউলগুলিতে সংস্থানগুলিকে গোষ্ঠীভুক্ত করার উপায়গুলি খুঁজে পান, কোডগুলিকে ফোল্ডারে সংগঠিত করতে এবং সম্ভবত আর কী ভুল হতে পারে? (আলোচিত শেষ শব্দগুলো)

সময় চলে যায় এবং আপনি মনে করেন আপনার অবকাঠামো আপনার নতুন পোষা প্রাণী, কিন্তু কেন? আপনি অবকাঠামোর অবর্ণনীয় পরিবর্তন নিয়ে চিন্তিত, আপনি অবকাঠামো এবং কোড স্পর্শ করতে ভয় পান - ফলস্বরূপ, আপনি নতুন কার্যকারিতা বিলম্বিত করেন বা গুণমান হ্রাস করেন ...

Github-এ AWS-এর জন্য Terraform সম্প্রদায়ের মডিউলগুলির একটি সংগ্রহ এবং উৎপাদনে Terraform-এর দীর্ঘমেয়াদী রক্ষণাবেক্ষণের তিন বছর পরিচালনা করার পর, Anton Babenko তার অভিজ্ঞতা শেয়ার করতে প্রস্তুত: TF মডিউলগুলি কীভাবে লিখতে হয় যাতে ভবিষ্যতে ক্ষতি না হয়।

আলোচনার শেষে, অংশগ্রহণকারীরা টেরাফর্মের সম্পদ ব্যবস্থাপনার নীতি, টেরাফর্মের মডিউলগুলির সাথে যুক্ত সর্বোত্তম অনুশীলন এবং অবকাঠামো ব্যবস্থাপনার সাথে যুক্ত কিছু অবিচ্ছিন্ন একীকরণ নীতির সাথে আরও বেশি পরিচিত হবে।

দাবি পরিত্যাগী: আমি লক্ষ্য করি যে এই প্রতিবেদনটি নভেম্বর 2018 তারিখের - ইতিমধ্যে 2 বছর অতিক্রান্ত হয়েছে৷ প্রতিবেদনে আলোচিত Terraform 0.11 এর সংস্করণটি আর সমর্থিত নয়। গত 2 বছরে, 2টি নতুন রিলিজ প্রকাশিত হয়েছে, যাতে প্রচুর উদ্ভাবন, উন্নতি এবং পরিবর্তনগুলি উপস্থিত হয়েছে। এই মনোযোগ দিন এবং ডকুমেন্টেশন চেক করুন.

রেফারেন্স:

• টেরাফর্ম-কমিউনিটি-মডিউল + terraform-aws-মডিউল
• antonbabenko/pre-commit-terraform — স্বয়ংক্রিয় ফর্ম্যাটিং কোড এবং ডকুমেন্টেশন
• অ্যান্টনবাবেনকো/টেরাপিন — টেরাফর্ম মডিউলের জেনারেটর (WIP)
• antonbabenko/modules.tf-lambda - ভিজ্যুয়াল ডায়াগ্রাম (WIP) থেকে টেরাফর্ম কোড জেনারেটর
• www.terraform-best-practices.com
• medium.com/@anton.babenko (নতুন পোস্টগুলি আমার ব্যক্তিগত ওয়েবসাইটে রয়েছে www.antonbabenko.com/)
• @antonbabenko - টুইটার, এবং বিভিন্ন স্ল্যাকের একটি গুচ্ছ

আমার নাম আন্তন বাবেনকো। আপনার মধ্যে কেউ কেউ সম্ভবত আমার লেখা কোড ব্যবহার করেছেন। আমি এখন আগের চেয়ে আরও বেশি আত্মবিশ্বাসের সাথে এই বিষয়ে কথা বলব, কারণ আমার পরিসংখ্যানে অ্যাক্সেস আছে।

আমি Terraform-এ কাজ করি এবং 2015 সাল থেকে Terraform এবং Amazon-এর সাথে সম্পর্কিত প্রচুর সংখ্যক ওপেন সোর্স প্রকল্পে সক্রিয় অংশগ্রহণকারী এবং অবদানকারী।

তারপর থেকে আমি এটি একটি আকর্ষণীয় উপায়ে রাখার জন্য যথেষ্ট কোড লিখেছি। এবং আমি এখন এই সম্পর্কে আপনাকে বলার চেষ্টা করব।

আমি Terraform এর সাথে কাজ করার জটিলতা এবং সুনির্দিষ্ট বিষয়ে কথা বলব। কিন্তু আসলে এটি হাইলোডের জন্য একটি বিষয় নয়। এবং এখন আপনি কেন বুঝতে পারবেন।

সময়ের সাথে সাথে, আমি টেরাফর্ম মডিউল লিখতে শুরু করি। ব্যবহারকারীরা প্রশ্ন লিখেছেন, আমি সেগুলি আবার লিখেছি। তারপর আমি প্রি-কমিট হুক ইত্যাদি সহ বিভিন্ন কোড ফরম্যাটিং ইউটিলিটি লিখেছিলাম।

অনেক আকর্ষণীয় প্রকল্প ছিল. আমি কোড জেনারেশন পছন্দ করি কারণ আমি কম্পিউটার আমার এবং প্রোগ্রামারের জন্য আরও বেশি কাজ করতে পছন্দ করি, তাই আমি বর্তমানে ভিজ্যুয়াল ডায়াগ্রাম থেকে একটি টেরাফর্ম কোড জেনারেটরে কাজ করছি। সম্ভবত আপনি কেউ তাদের দেখেছেন. এগুলি তীর সহ সুন্দর বাক্স। এবং আমি মনে করি এটি দুর্দান্ত যদি আপনি "রপ্তানি" বোতামটি ক্লিক করতে পারেন এবং এটি সমস্ত কোড হিসাবে পেতে পারেন।

আমি ইউক্রেইন্ থেকে এসেছি. আমি অনেক বছর ধরে নরওয়েতে বসবাস করছি।

এছাড়াও, এই প্রতিবেদনের জন্য তথ্য সংগ্রহ করা হয়েছিল যারা আমার নাম জানেন এবং আমাকে সামাজিক নেটওয়ার্কগুলিতে খুঁজে পান। আমি প্রায় সবসময় একই ডাকনাম আছে.

https://github.com/terraform-aws-modules
https://registry.terraform.io/namespaces/terraform-aws-modules

আমি যেমন উল্লেখ করেছি, আমি Terraform AWS মডিউলগুলির প্রধান রক্ষণাবেক্ষণকারী, যা GitHub-এর বৃহত্তম সংগ্রহস্থলগুলির মধ্যে একটি যেখানে আমরা সবচেয়ে সাধারণ কাজের জন্য মডিউলগুলি হোস্ট করি: VPC, Autoscaling, RDS৷

এবং আপনি এখন যা শুনেছেন তা সবচেয়ে মৌলিক। যদি আপনি সন্দেহ করেন যে আপনি Terraform কি তা বুঝতে পারেন, তাহলে আপনার সময় অন্য কোথাও কাটানো ভাল। এখানে অনেক টেকনিক্যাল টার্ম থাকবে। এবং আমি রিপোর্টের স্তরকে সর্বোচ্চ বলে ঘোষণা করতে দ্বিধা করিনি। এর মানে হল যে আমি অনেক ব্যাখ্যা ছাড়াই সমস্ত সম্ভাব্য পদ ব্যবহার করে কথা বলতে পারি।

টেরাফর্ম 2014 সালে একটি ইউটিলিটি হিসাবে উপস্থিত হয়েছিল যা আপনাকে কোড হিসাবে পরিকাঠামো লিখতে, পরিকল্পনা করতে এবং পরিচালনা করতে দেয়। এখানে মূল ধারণা হল "কোড হিসাবে অবকাঠামো"।

সমস্ত ডকুমেন্টেশন, যেমন আমি বলেছি, লেখা আছে terraform.io. আমি আশা করি বেশিরভাগ লোকেরা এই সাইটটি সম্পর্কে জানেন এবং ডকুমেন্টেশন পড়েছেন। যদি তাই হয়, তাহলে আপনি সঠিক জায়গায় আছেন।

একটি রেগুলার টেরাফর্ম কনফিগারেশন ফাইল এইরকম দেখায়, যেখানে আমরা প্রথমে কিছু ভেরিয়েবল সংজ্ঞায়িত করি।

এই ক্ষেত্রে, আমরা "aws_region" সংজ্ঞায়িত করি।

তারপরে আমরা বর্ণনা করি যে আমরা কী সম্পদ তৈরি করতে চাই।

আমরা কিছু কমান্ড চালাই, বিশেষ করে "terraform init" নির্ভরতা, প্রদানকারী লোড করার জন্য।

এবং নির্দিষ্ট কনফিগারেশন আমাদের তৈরি করা সংস্থানগুলির সাথে মেলে কিনা তা পরীক্ষা করার জন্য আমরা "terraform apply" কমান্ডটি চালাই। যেহেতু আমরা আগে কিছু তৈরি করিনি, তাই টেরাফর্ম পরামর্শ দেয় যে আমরা এই সংস্থানগুলি তৈরি করি।

আমরা এটি নিশ্চিত করি। এভাবেই আমরা seasnail নামক একটি বালতি তৈরি করি।

এছাড়াও বেশ কয়েকটি অনুরূপ ইউটিলিটি রয়েছে। আপনারা যারা Amazon ব্যবহার করেন তারা অনেকেই AWS CloudFormation বা Google Cloud Deployment Manager বা Azure রিসোর্স ম্যানেজার জানেন। এই সকল পাবলিক ক্লাউড প্রদানকারীর প্রত্যেকের মধ্যে সংস্থান পরিচালনার জন্য তাদের প্রত্যেকেরই কিছু ধরণের বাস্তবায়ন রয়েছে। Terraform বিশেষভাবে উপযোগী কারণ এটি আপনাকে 100 টিরও বেশি প্রদানকারী পরিচালনা করতে দেয়। (আরো বিস্তারিত এখানে)

টেরাফর্ম প্রথম থেকেই যে লক্ষ্যগুলি অনুসরণ করেছে:

• Terraform সম্পদের একটি একক দৃশ্য প্রদান করে।
• আপনাকে সমস্ত আধুনিক প্ল্যাটফর্ম সমর্থন করার অনুমতি দেয়।
• এবং Terraform প্রথম থেকেই একটি ইউটিলিটি হিসাবে ডিজাইন করা হয়েছিল যা আপনাকে নিরাপদে এবং অনুমানযোগ্যভাবে পরিকাঠামো পরিবর্তন করতে দেয়।

2014 সালে, এই প্রসঙ্গে "অনুমান করা যায়" শব্দটি খুব অস্বাভাবিক বলে মনে হয়েছিল।

টেরাফর্ম একটি সর্বজনীন ইউটিলিটি। আপনার যদি একটি API থাকে, তাহলে আপনি একেবারে সবকিছু নিয়ন্ত্রণ করতে পারেন:

• আপনার হৃদয়ের ইচ্ছার সবকিছু পরিচালনা করতে আপনি 120 টিরও বেশি প্রদানকারী ব্যবহার করতে পারেন।
• উদাহরণস্বরূপ, আপনি GitHub সংগ্রহস্থলগুলিতে অ্যাক্সেস বর্ণনা করতে Terraform ব্যবহার করতে পারেন।
• এমনকি আপনি জিরাতে বাগ তৈরি এবং বন্ধ করতে পারেন।
• আপনি নতুন রিলিক মেট্রিক্স পরিচালনা করতে পারেন।
• আপনি যদি সত্যিই চান তাহলে আপনি ড্রপবক্সে ফাইল তৈরি করতে পারেন।

এটি সবই টেরাফর্ম প্রদানকারীদের ব্যবহার করে অর্জন করা হয়েছে, যার একটি খোলা API রয়েছে যা Go-তে বর্ণনা করা যেতে পারে।

ধরা যাক আমরা Terraform ব্যবহার শুরু করেছি, সাইটে কিছু ডকুমেন্টেশন পড়েছি, কিছু ভিডিও দেখেছি, main.tf লেখা শুরু করেছি, যেমনটি আমি আগের স্লাইডে দেখিয়েছি।

এবং আপনার সাথে সবকিছু শান্ত, আপনার কাছে একটি ফাইল আছে যা একটি ভিপিসি তৈরি করে।

আপনি যদি একটি VPC তৈরি করতে চান, তাহলে আপনি প্রায় এই 12টি লাইন নির্দিষ্ট করুন। আপনি কোন অঞ্চলে তৈরি করতে চান, আইপি ঠিকানাগুলির কোন cidr_block ব্যবহার করতে চান তা বর্ণনা করুন। এখানেই শেষ.

স্বাভাবিকভাবেই, প্রকল্পটি ধীরে ধীরে বাড়বে।

এবং আপনি সেখানে একগুচ্ছ নতুন জিনিস যোগ করবেন: সংস্থান, ডেটা উত্স, আপনি নতুন সরবরাহকারীদের সাথে একীভূত হবেন, হঠাৎ করে আপনি আপনার GitHub অ্যাকাউন্টে ব্যবহারকারীদের পরিচালনা করার জন্য Terraform ব্যবহার করতে চাইবেন, ইত্যাদি। আপনি বিভিন্ন ব্যবহার করতে চাইতে পারেন DNS প্রদানকারী, সবকিছু অতিক্রম করুন. Terraform এটি সহজ করে তোলে।

চলুন নিম্নলিখিত উদাহরণ তাকান.

আপনি ধীরে ধীরে ইন্টারনেট_গেটওয়ে যোগ করছেন কারণ আপনি আপনার VPC থেকে সংস্থানগুলিকে ইন্টারনেটে অ্যাক্সেস করতে চান৷ এটা একটা ভালো বুদ্ধি.

ফলাফল হল এই main.tf:

এটি main.tf এর উপরের অংশ।

এটি main.tf এর নিচের অংশ।

তারপর আপনি সাবনেট যোগ করুন। আপনি যখন NAT গেটওয়ে, রুট, রাউটিং টেবিল এবং অন্যান্য সাবনেটের একটি গুচ্ছ যোগ করতে চান, তখন আপনার কাছে 38টি লাইন থাকবে না, তবে প্রায় 200-300 লাইন থাকবে।

অর্থাৎ, আপনার main.tf ফাইল ধীরে ধীরে বৃদ্ধি পায়। এবং প্রায়ই মানুষ একটি ফাইল সবকিছু রাখা. main.tf এ 10-20 Kb প্রদর্শিত হয়। কল্পনা করুন যে 10-20 Kb হল পাঠ্য বিষয়বস্তু। এবং সবকিছু সবকিছুর সাথে সংযুক্ত। এর সাথে কাজ করা আরও কঠিন হয়ে উঠছে। 10-20 Kb একটি ভাল ব্যবহারকারীর ক্ষেত্রে, কখনও কখনও আরও বেশি। এবং লোকেরা সবসময় এটি খারাপ বলে মনে করে না।

নিয়মিত প্রোগ্রামিংয়ের মতো, অর্থাৎ কোড হিসাবে অবকাঠামো নয়, আমরা বিভিন্ন ক্লাস, প্যাকেজ, মডিউল, গ্রুপিংগুলির একটি গুচ্ছ ব্যবহার করতে অভ্যস্ত। Terraform আপনাকে একই জিনিস করতে দেয়।

• কোড বাড়ছে।
• সম্পদের মধ্যে নির্ভরতাও বাড়ছে।

এবং আমরা একটি মহান, মহান প্রয়োজন আছে. আমরা বুঝতে পারি যে আমরা আর এভাবে বাঁচতে পারি না। আমাদের কোড অপরিমেয় হয়ে ওঠে. 10-20 Kb, অবশ্যই, খুব বিস্তৃত নয়, তবে আমরা কেবল নেটওয়ার্ক স্ট্যাক সম্পর্কে কথা বলছি, অর্থাৎ আপনি শুধুমাত্র নেটওয়ার্ক সংস্থান যোগ করেছেন। আমরা অ্যাপ্লিকেশন লোড ব্যালেন্সার, ডিপ্লয়মেন্ট ইএস ক্লাস্টার, কুবারনেটস ইত্যাদির কথা বলছি না, যেখানে 100 Kb সহজেই বুনা যায়। আপনি যদি এই সব লিখে রাখেন, আপনি খুব শীঘ্রই শিখবেন যে Terraform Terraform মডিউল প্রদান করে।

টেরাফর্ম মডিউল হল স্বয়ংসম্পূর্ণ টেরাফর্ম কনফিগারেশন যা একটি গ্রুপ হিসাবে পরিচালিত হয়। টেরাফর্ম মডিউল সম্পর্কে আপনার এতটুকুই জানা দরকার। তারা মোটেও স্মার্ট নয়, তারা আপনাকে কোনও কিছুর উপর নির্ভর করে কোনও জটিল সংযোগ করতে দেয় না। এই সব ডেভেলপারদের কাঁধে পড়ে. অর্থাৎ, এটি শুধুমাত্র এক ধরনের Terraform কনফিগারেশন যা আপনি ইতিমধ্যেই লিখেছেন। এবং আপনি এটিকে কেবল একটি গ্রুপ হিসাবে কল করতে পারেন।

তাই আমরা বোঝার চেষ্টা করছি কিভাবে আমরা আমাদের 10-20-30 Kb কোড অপ্টিমাইজ করব। আমরা ধীরে ধীরে বুঝতে পারছি যে আমাদের কিছু মডিউল ব্যবহার করতে হবে।

আপনি সম্মুখীন প্রথম ধরনের মডিউল সম্পদ মডিউল হয়. তারা বুঝতে পারে না আপনার পরিকাঠামো কী, আপনার ব্যবসা কী, কোথায় এবং কী শর্ত। এগুলি ঠিক সেই মডিউলগুলি যা আমি, ওপেন সোর্স সম্প্রদায়ের সাথে একত্রে পরিচালনা করি এবং যেগুলিকে আমরা আপনার অবকাঠামোর প্রাথমিক বিল্ডিং ব্লক হিসাবে সামনে রেখেছি।

একটি সম্পদ মডিউল একটি উদাহরণ.

যখন আমরা একটি রিসোর্স মডিউল কল করি, তখন আমরা নির্দিষ্ট করি কোন পথ থেকে এর বিষয়বস্তু লোড করা উচিত।

আমরা কোন সংস্করণটি ডাউনলোড করতে চাই তা আমরা নির্দেশ করি।

আমরা সেখানে যুক্তি একটি গুচ্ছ পাস. এখানেই শেষ. আমরা যখন এই মডিউলটি ব্যবহার করি তখন আমাদের এইটুকুই জানতে হবে।

অনেকে মনে করেন লেটেস্ট ভার্সন ব্যবহার করলে সবকিছু স্থিতিশীল হয়ে যাবে। কিন্তু না. অবকাঠামোটি অবশ্যই সংস্করণ করা উচিত; আমাদের অবশ্যই স্পষ্টভাবে উত্তর দিতে হবে যে এই বা সেই উপাদানটি কোন সংস্করণে স্থাপন করা হয়েছিল।

এই মডিউলের ভিতরের কোডটি এখানে। নিরাপত্তা-গ্রুপ মডিউল। এখানে স্ক্রোলটি 640 তম লাইনে যায়। অ্যামাজনে সমস্ত ধরণের কনফিগারেশনে একটি সংস্থান সুরক্ষা-ক্রুপ তৈরি করা একটি খুব তুচ্ছ কাজ। শুধুমাত্র একটি নিরাপত্তা গোষ্ঠী তৈরি করা এবং এটিতে কোন নিয়মগুলি পাস করতে হবে তা বলাই যথেষ্ট নয়। এটা খুব সহজ হবে. আমাজনের ভিতরে এক মিলিয়ন বিভিন্ন সীমাবদ্ধতা রয়েছে। উদাহরণস্বরূপ, যদি আপনি ব্যবহার করেন ভিপিসি এন্ডপয়েন্ট, প্রিফিক্স তালিকা, বিভিন্ন এপিআই এবং সবকিছু দিয়ে এটিকে অতিক্রম করার চেষ্টা করে, তারপর টেরাফর্ম আপনাকে এটি করতে দেয় না। এবং অ্যামাজন API এটির অনুমতি দেয় না। অতএব, আমাদের একটি মডিউলে এই সমস্ত ভয়ানক যুক্তি লুকিয়ে রাখতে হবে এবং ব্যবহারকারীকে এমন একটি কোড দিতে হবে যা দেখতে এইরকম।

এটি ভিতরে কীভাবে তৈরি হয় তা ব্যবহারকারীর জানার প্রয়োজন নেই।

দ্বিতীয় ধরনের মডিউল, যা রিসোর্স মডিউল নিয়ে গঠিত, ইতিমধ্যেই আপনার ব্যবসার জন্য আরও প্রযোজ্য কাজগুলি সমাধান করে। প্রায়শই এটি এমন একটি স্থান যা টেরাফর্মের জন্য একটি এক্সটেনশন এবং কোম্পানির মানগুলির জন্য ট্যাগের জন্য কিছু কঠিন মান সেট করে। আপনি সেখানে কার্যকারিতা যোগ করতে পারেন যেটি Terraform বর্তমানে আপনাকে ব্যবহার করার অনুমতি দেয় না। এটা এখনই। এখন সংস্করণ 0.11, যা অতীতের জিনিস হয়ে উঠতে চলেছে। কিন্তু তবুও, প্রিপ্রসেসর, জসননেট, কুকিকাটার এবং অন্যান্য জিনিসগুলির একটি গুচ্ছ হল সহায়ক প্রক্রিয়া যা সম্পূর্ণ কাজের জন্য ব্যবহার করা আবশ্যক।

পরবর্তী আমি এর কিছু উদাহরণ দেখাব।

অবকাঠামো মডিউল ঠিক একই ভাবে বলা হয়.

কোথা থেকে কন্টেন্ট ডাউনলোড করতে হবে তার উৎস উল্লেখ করে।

মানগুলির একটি গুচ্ছ পাস করা হয়, যা এই মডিউলে পাস করা হয়।

এর পরে, এই মডিউলের ভিতরে, একটি ভিপিসি বা অ্যাপ্লিকেশন লোড ব্যালেন্সার তৈরি করতে বা একটি নিরাপত্তা-গ্রুপ তৈরি করতে বা একটি ইলাস্টিক কন্টেইনার পরিষেবা ক্লাস্টার তৈরি করতে একগুচ্ছ রিসোর্স মডিউল ডাকা হয়।

দুই ধরনের মডিউল আছে। এটি বোঝা গুরুত্বপূর্ণ কারণ এই প্রতিবেদনে আমি যে সমস্ত তথ্য গোষ্ঠীবদ্ধ করেছি তার বেশিরভাগই ডকুমেন্টেশনে লেখা নেই।

এবং টেরাফর্মের ডকুমেন্টেশনটি এখন বেশ সমস্যাযুক্ত, কারণ এটি কেবল বলে যে এই ধরনের বৈশিষ্ট্য রয়েছে, আপনি সেগুলি ব্যবহার করতে পারেন। তবে তিনি এই বৈশিষ্ট্যগুলি কীভাবে ব্যবহার করবেন, কেন সেগুলি ব্যবহার করা ভাল তা বলেন না। অতএব, একটি খুব বড় সংখ্যক লোক এমন কিছু লেখে যা তারা বাঁচতে পারে না।

দেখা যাক কিভাবে এই মডিউলগুলো লিখতে হয়। তারপর আমরা দেখব কিভাবে তাদের কল করতে হয় এবং কিভাবে কোড দিয়ে কাজ করতে হয়।

টেরাফর্ম রেজিস্ট্রি - https://registry.terraform.io/

টিপ #0 হল রিসোর্স মডিউল না লেখা। এই মডিউলগুলির বেশিরভাগই ইতিমধ্যে আপনার জন্য লেখা হয়েছে। আমি যেমন বলেছি, এগুলি ওপেন সোর্স, এগুলিতে আপনার কোনও ব্যবসায়িক যুক্তি নেই, আইপি ঠিকানা, পাসওয়ার্ড ইত্যাদির জন্য তাদের হার্ডকোড মান নেই। মডিউলটি খুব নমনীয়। এবং এটি সম্ভবত ইতিমধ্যেই লেখা হয়েছে। আমাজন থেকে সম্পদের জন্য অনেক মডিউল আছে। প্রায় 650. এবং তাদের বেশিরভাগই ভাল মানের।

এই উদাহরণে, কেউ আপনার কাছে এসে বলল, "আমি একটি ডাটাবেস পরিচালনা করতে সক্ষম হতে চাই। একটি মডিউল তৈরি করুন যাতে আমি একটি ডাটাবেস তৈরি করতে পারি।" ব্যক্তিটি Amazon বা Terraform এর বাস্তবায়নের বিশদ জানেন না। এটি শুধু বলে "আমি MSSQL পরিচালনা করতে চাই"। অর্থাৎ, আমরা বলতে চাচ্ছি যে এটি আমাদের মডিউলকে কল করবে, সেখানে ইঞ্জিনের ধরণটি পাস করবে এবং সময় অঞ্চল নির্দেশ করবে।

এবং একজন ব্যক্তির জানা উচিত নয় যে আমরা এই মডিউলের মধ্যে দুটি ভিন্ন সংস্থান তৈরি করব: একটি MSSQL এর জন্য, দ্বিতীয়টি অন্য সবকিছুর জন্য, শুধুমাত্র কারণ Terraform 0.11-এ আপনি ঐচ্ছিক হিসাবে সময় অঞ্চলের মান নির্দিষ্ট করতে পারবেন না।

এবং এই মডিউল থেকে প্রস্থান করার সময়, একজন ব্যক্তি কেবল একটি ঠিকানা পেতে সক্ষম হবেন। সে জানবে না কোন ডাটাবেস থেকে, কোন রিসোর্স থেকে আমরা অভ্যন্তরীণভাবে এসব তৈরি করছি। এটি গোপন করার একটি খুব গুরুত্বপূর্ণ উপাদান। এবং এটি শুধুমাত্র সেই সমস্ত মডিউলগুলির জন্য প্রযোজ্য যা ওপেন সোর্সে সর্বজনীন, তবে সেই মডিউলগুলির ক্ষেত্রেও প্রযোজ্য যা আপনি আপনার প্রকল্প এবং দলগুলির মধ্যে লিখবেন৷

এটি দ্বিতীয় যুক্তি, যেটি বেশ গুরুত্বপূর্ণ যদি আপনি কিছু সময়ের জন্য Terraform ব্যবহার করে থাকেন। আপনার একটি সংগ্রহস্থল রয়েছে যেখানে আপনি আপনার কোম্পানির জন্য আপনার সমস্ত Terraform মডিউল রাখেন। এবং এটি খুবই স্বাভাবিক যে সময়ের সাথে সাথে এই প্রকল্পটি এক বা দুই মেগাবাইটের আকারে বৃদ্ধি পাবে। এই জরিমানা.

কিন্তু সমস্যা হল কিভাবে Terraform এই মডিউলগুলিকে কল করে। উদাহরণস্বরূপ, যদি আপনি প্রতিটি স্বতন্ত্র ব্যবহারকারী তৈরি করার জন্য একটি মডিউল কল করেন, তাহলে Terraform প্রথমে সম্পূর্ণ সংগ্রহস্থল ডাউনলোড করবে এবং তারপরে এই নির্দিষ্ট মডিউলটি অবস্থিত ফোল্ডারে যাবে। এভাবে আপনি প্রতিবার এক মেগাবাইট ডাউনলোড করবেন। আপনি যদি 100 বা 200 ব্যবহারকারী পরিচালনা করেন, তাহলে আপনি 100 বা 200 মেগাবাইট ডাউনলোড করবেন এবং তারপর সেই ফোল্ডারে যান। সুতরাং, স্বাভাবিকভাবেই, আপনি প্রতিবার "Terraform init" আঘাত করার সময় একগুচ্ছ জিনিস লোড করতে চান না।

https://github.com/mbtproject/mbt

এই সমস্যার দুটি সমাধান আছে। প্রথমটি হল আপেক্ষিক পাথ ব্যবহার করা। এইভাবে আপনি কোডে উল্লেখ করেন যে ফোল্ডারটি স্থানীয় (./)। এবং আপনি কিছু চালানোর আগে, আপনি স্থানীয়ভাবে সেই সংগ্রহস্থলের একটি গিট ক্লোন করেন। এইভাবে আপনি একবার এটি করুন।

অবশ্যই, অনেক খারাপ দিক আছে। উদাহরণস্বরূপ, আপনি সংস্করণ ব্যবহার করতে পারবেন না। এবং কখনও কখনও এটির সাথে বেঁচে থাকা কঠিন।

দ্বিতীয় সমাধান। আপনার যদি অনেকগুলি সাবমডিউল থাকে এবং আপনার কাছে ইতিমধ্যেই কিছু ধরণের ইনস্টল করা পাইপলাইন থাকে, তবে একটি এমবিটি প্রকল্প রয়েছে যা আপনাকে মনোরপোজিটরি থেকে বিভিন্ন প্যাকেজ সংগ্রহ করতে এবং সেগুলিকে S3 এ আপলোড করতে দেয়। এটি একটি খুব ভাল উপায়. এইভাবে, iam-user-1.0.0.zip ফাইলের আকার হবে মাত্র 1 Kb, কারণ এই রিসোর্স তৈরির কোড খুবই ছোট। এবং এটি অনেক দ্রুত কাজ করবে।

আসুন মডিউলগুলিতে কী ব্যবহার করা যায় না সে সম্পর্কে কথা বলি।

কেন এটা মডিউল মন্দ? সবচেয়ে খারাপ জিনিস ব্যবহারকারী অনুমান করা হয়. অনুমান ব্যবহারকারী একটি প্রদানকারী প্রমাণীকরণ বিকল্প যা বিভিন্ন লোক ব্যবহার করতে পারে। উদাহরণস্বরূপ, আমরা সকলেই ভূমিকাটি আত্মসাৎ করব। এর মানে হল যে Terraform এই ভূমিকা নেবে। এবং তারপর এই ভূমিকা সঙ্গে এটি অন্যান্য কর্ম সঞ্চালন করা হবে.

এবং মন্দটি হল যে যদি ভাস্য এক উপায়ে আমাজনের সাথে সংযোগ করতে পছন্দ করে, উদাহরণস্বরূপ, ডিফল্ট পরিবেশ পরিবর্তনশীল ব্যবহার করে এবং পেটিয়া তার ভাগ করা কী ব্যবহার করতে পছন্দ করে, যা তার গোপন স্থানে রয়েছে, তবে আপনি উভয়ই নির্দিষ্ট করতে পারবেন না। টেরাফর্ম এবং যাতে তারা দুর্ভোগের অভিজ্ঞতা না পায়, মডিউলে এই ব্লকটি নির্দেশ করার দরকার নেই। এটি একটি উচ্চ স্তরে নির্দেশিত করা আবশ্যক. অর্থাৎ, আমাদের কাছে একটি রিসোর্স মডিউল, একটি অবকাঠামো মডিউল এবং উপরে একটি রচনা রয়েছে। এবং এটি উচ্চতর কোথাও নির্দেশ করা উচিত।

দ্বিতীয় মন্দ হল রিযিকদাতা। এখানে মন্দটি এত তুচ্ছ নয়, কারণ আপনি যদি কোড লিখেন এবং এটি আপনার জন্য কাজ করে তবে আপনি ভাবতে পারেন যে এটি যদি কাজ করে তবে কেন এটি পরিবর্তন করুন।

মন্দ এই সত্যের মধ্যে রয়েছে যে আপনি সর্বদা এই বিধানকারীকে নিয়ন্ত্রণ করেন না যখন এটি বিশেষভাবে চালু করা হবে, প্রথমত। এবং দ্বিতীয়ত, আপনি aws ec2 এর অর্থ কী তা নিয়ন্ত্রণ করেন না, অর্থাৎ আমরা এখন লিনাক্স বা উইন্ডোজ সম্পর্কে কথা বলছি। তাই আপনি এমন কিছু লিখতে পারবেন না যা বিভিন্ন অপারেটিং সিস্টেমে বা বিভিন্ন ব্যবহারকারীর ক্ষেত্রে একই কাজ করবে।

সবচেয়ে সাধারণ উদাহরণ, যা অফিসিয়াল ডকুমেন্টেশনেও ইঙ্গিত করা হয়েছে, আপনি যদি aws_instance লিখেন এবং একগুচ্ছ আর্গুমেন্ট উল্লেখ করেন, তাহলে তাতে কোনো ভুল নেই যদি আপনি সেখানে প্রভিশনার "local-exec" উল্লেখ করেন এবং আপনার দায়বদ্ধতা চালান- প্লেবুক

আসলে, হ্যাঁ, এতে দোষের কিছু নেই। কিন্তু আক্ষরিক অর্থে শীঘ্রই আপনি বুঝতে পারবেন যে এই স্থানীয়-নির্বাহী জিনিসটি বিদ্যমান নেই, উদাহরণস্বরূপ, launch_configuration এ।

এবং আপনি যখন লঞ্চ_কনফিগারেশন ব্যবহার করেন, এবং আপনি একটি উদাহরণ থেকে একটি অটোস্কেলিং গ্রুপ তৈরি করতে চান, তখন লঞ্চ_কনফিগারেশনে "প্রভিশনার" এর কোন ধারণা নেই। "ব্যবহারকারীর ডেটা" ধারণা রয়েছে।

অতএব, একটি আরো সার্বজনীন সমাধান হল ব্যবহারকারীর ডেটা ব্যবহার করা। এবং এটি হয় ইনস্ট্যান্সে চালু করা হবে, যখন ইনস্ট্যান্সটি চালু থাকে, অথবা একই ব্যবহারকারীর ডেটাতে, যখন অটোস্কেলিং গ্রুপ এই লঞ্চ_কনফিগারেশন ব্যবহার করে।

যদি, তবুও, একটি প্রোভিজার চালু করার ইচ্ছা থাকে, কারণ এটি একটি আঠালো উপাদান, যখন একটি সংস্থান তৈরি করা হয় এবং এই মুহুর্তে আপনাকে আপনার প্রোভিজার, আপনার দল চালু করতে হবে। এরকম অনেক পরিস্থিতি আছে।

এবং এই জন্য সবচেয়ে সঠিক সম্পদ বলা হয় null_resource. Null_resource হল একটি ডামি রিসোর্স যা আসলে কখনো তৈরি হয় না। এটি কোন কিছুই স্পর্শ করে না, কোন API, কোন অটোস্কেলিং। কিন্তু এটি আপনাকে কখন কমান্ড চালাতে হবে তা নিয়ন্ত্রণ করতে দেয়। এই ক্ষেত্রে, কমান্ডটি সৃষ্টির সময় চালানো হয়।

লিংক http://bit.ly/common-traits-in-terraform-modules

বেশ কিছু লক্ষণ আছে। আমি খুব বিস্তারিতভাবে সমস্ত লক্ষণে যাব না। এটি সম্পর্কে একটি নিবন্ধ আছে. কিন্তু আপনি যদি Terraform এর সাথে কাজ করে থাকেন বা অন্য লোকের মডিউল ব্যবহার করে থাকেন, তাহলে আপনি প্রায়ই লক্ষ্য করেছেন যে অনেক মডিউল, যেমন ওপেন সোর্সের বেশিরভাগ কোড, মানুষ তাদের নিজস্ব প্রয়োজনে লিখে থাকে। একজন ব্যক্তি এটি লিখে তার সমস্যার সমাধান করেছেন। আমি এটিকে গিটহাবে আটকে রেখেছি, এটিকে বাঁচতে দিন। এটি বেঁচে থাকবে, কিন্তু যদি কোন ডকুমেন্টেশন এবং উদাহরণ না থাকে, তাহলে কেউ এটি ব্যবহার করবে না। এবং যদি এমন কোনও কার্যকারিতা না থাকে যা আপনাকে তার নির্দিষ্ট কাজের চেয়ে একটু বেশি সমাধান করতে দেয়, তবে কেউ এটি ব্যবহার করবে না। ব্যবহারকারী হারানোর অনেক উপায় আছে।

আপনি যদি এমন কিছু লিখতে চান যাতে লোকেরা এটি ব্যবহার করে তবে আমি এই লক্ষণগুলি অনুসরণ করার পরামর্শ দিই।

এটি হল:

• ডকুমেন্টেশন এবং উদাহরণ।
• সম্পূর্ণ কার্যকারিতা।
• যুক্তিসঙ্গত ডিফল্ট।
• ক্লিন কোড।
• পরীক্ষা।

পরীক্ষাগুলি একটি ভিন্ন পরিস্থিতি কারণ সেগুলি লিখতে বেশ কঠিন। আমি ডকুমেন্টেশন এবং উদাহরণ আরো বিশ্বাস করি.

তাই আমরা দেখেছি কিভাবে মডিউল লিখতে হয়। দুটি যুক্তি আছে। প্রথমত, এবং সবচেয়ে গুরুত্বপূর্ণ, আপনি যদি পারেন তবে লিখবেন না, কারণ একগুচ্ছ লোক ইতিমধ্যেই আপনার আগে এই কাজগুলি করেছে। এবং দ্বিতীয়, আপনি যদি এখনও সিদ্ধান্ত নেন, তাহলে মডিউল এবং প্রোভিজারে প্রদানকারী ব্যবহার না করার চেষ্টা করুন।

এটি ডকুমেন্টেশনের ধূসর অংশ। আপনি এখন ভাবছেন: "কিছু অস্পষ্ট। বিশ্বাস হচ্ছে না।" তবে আমরা ছয় মাসের মধ্যে দেখতে পাব।

এখন এই মডিউলগুলিকে কীভাবে কল করবেন সে সম্পর্কে কথা বলা যাক।

আমরা বুঝতে পারি যে আমাদের কোড সময়ের সাথে বৃদ্ধি পায়। আমাদের কাছে আর একটি ফাইল নেই, আমাদের ইতিমধ্যে 20টি ফাইল রয়েছে। তারা সব এক ফোল্ডারে আছে. অথবা পাঁচটি ফোল্ডারে। হয়তো আমরা কোনো না কোনোভাবে অঞ্চলভেদে, কোনো কোনো উপাদানের মাধ্যমে সেগুলো ভেঙে ফেলতে শুরু করছি। তাহলে আমরা বুঝতে পারি যে এখন আমাদের কাছে সিঙ্ক্রোনাইজেশন এবং অর্কেস্ট্রেশনের কিছু রুডিমেন্ট রয়েছে। অর্থাৎ, আমাদের অবশ্যই বুঝতে হবে যে আমরা নেটওয়ার্ক সংস্থানগুলি পরিবর্তন করলে আমাদের কী করা উচিত, আমাদের বাকি সংস্থানগুলির সাথে আমাদের কী করা উচিত, কীভাবে এই নির্ভরতা সৃষ্টি করা যায় ইত্যাদি।

দুটি চরম আছে। প্রথম চরম সব এক. আমরা একটি মাস্টার ফাইল আছে. আপাতত, এটি ছিল টেরাফর্ম ওয়েবসাইটে অফিসিয়াল সেরা অনুশীলন।

কিন্তু এখন এটি অবলোচিত এবং অপসারিত হিসাবে লেখা হয়। সময়ের সাথে সাথে, টেরাফর্ম সম্প্রদায় বুঝতে পেরেছিল যে এটি সর্বোত্তম অনুশীলন থেকে দূরে ছিল, কারণ লোকেরা বিভিন্ন উপায়ে প্রকল্পটি ব্যবহার করতে শুরু করেছিল। এবং সমস্যা আছে. উদাহরণস্বরূপ, যখন আমরা এক জায়গায় সমস্ত নির্ভরতা নির্দিষ্ট করি। এমন পরিস্থিতি আছে যখন আমরা "টেরাফর্ম প্ল্যান" এ ক্লিক করি এবং যতক্ষণ না টেরাফর্ম সমস্ত সম্পদের অবস্থা আপডেট করে, ততক্ষণ অনেক সময় কেটে যেতে পারে।

অনেক সময়, উদাহরণস্বরূপ, 5 মিনিট। কারো কারো জন্য এটা অনেক সময়। আমি এমন কেস দেখেছি যেখানে 15 মিনিট সময় লেগেছে। AWS API প্রতিটি সম্পদের অবস্থার সাথে কি ঘটছে তা বের করার চেষ্টা করার জন্য 15 মিনিট ব্যয় করেছে। এটা অনেক বড় এলাকা।

এবং, স্বাভাবিকভাবেই, একটি সম্পর্কিত সমস্যা প্রদর্শিত হবে যখন আপনি একটি জায়গায় কিছু পরিবর্তন করতে চান, তারপর আপনি 15 মিনিট অপেক্ষা করুন, এবং এটি আপনাকে কিছু পরিবর্তনের একটি ক্যানভাস দেয়। আপনি থুথু দিয়েছেন, "হ্যাঁ" লিখেছেন এবং কিছু ভুল হয়েছে৷ এটি একটি খুব বাস্তব উদাহরণ. টেরাফর্ম আপনাকে সমস্যা থেকে বিচ্ছিন্ন করার চেষ্টা করে না। অর্থাৎ আপনি যা চান তা লিখুন। সমস্যা হবে-আপনার সমস্যা। যদিও Terraform 0.11 আপনাকে কোনোভাবেই সাহায্য করার চেষ্টা করে না। 0.12-এ কিছু আকর্ষণীয় স্থান রয়েছে যা আপনাকে বলতে দেয়: "ভাস্যা, আপনি সত্যিই এটি চান, আপনি কি আপনার জ্ঞানে আসতে পারেন?"

দ্বিতীয় উপায় হল এই এলাকা কমানো, অর্থাৎ এক জায়গা থেকে কল অন্য জায়গা থেকে কম কানেক্ট করা যাবে।

একমাত্র সমস্যা হল আপনাকে আরও কোড লিখতে হবে, যেমন আপনাকে প্রচুর সংখ্যক ফাইলে ভেরিয়েবল বর্ণনা করতে হবে এবং এটি আপডেট করতে হবে। কিছু মানুষ এটা পছন্দ না. এটা আমার জন্য স্বাভাবিক। এবং কিছু লোক মনে করে: "কেন এটি বিভিন্ন জায়গায় লিখুন, আমি এটি সব এক জায়গায় রাখব।" এটি সম্ভব, তবে এটি দ্বিতীয় চরম।

কে এই সব এক জায়গায় বাস করে? এক, দুই, তিন জন অর্থাৎ কেউ ব্যবহার করছে।

এবং কে একটি নির্দিষ্ট উপাদান, একটি ব্লক বা একটি অবকাঠামো মডিউল কল? পাঁচ সাত জন। এই শান্ত.

সবচেয়ে সাধারণ উত্তর হল মাঝখানে কোথাও। যদি প্রকল্পটি বড় হয়, তবে আপনার প্রায়শই এমন পরিস্থিতি হবে যেখানে কোনও সমাধান উপযুক্ত নয় এবং সেখানে সবকিছু কাজ করে না, তাই আপনি একটি মিশ্রণ দিয়ে শেষ করবেন। এতে দোষের কিছু নেই, যতক্ষণ না আপনি বুঝতে পারেন যে উভয়েরই সুবিধা রয়েছে।

যদি স্ট্যাক ভিপিসিতে কিছু পরিবর্তন হয় এবং আপনি এই পরিবর্তনগুলি EC2 এ প্রয়োগ করতে চান, যেমন আপনি একটি নতুন সাবনেট থাকার কারণে অটোস্কেলিং গ্রুপ আপডেট করতে চান, তাহলে আমি এই ধরনের নির্ভরতা অর্কেস্ট্রেশনকে বলি। কিছু সমাধান আছে: কে কি ব্যবহার করে?

আমি সমাধান কি প্রস্তাব করতে পারেন. আপনি জাদু করতে Terraform ব্যবহার করতে পারেন, অথবা আপনি Terraform ব্যবহার করার জন্য makefiles ব্যবহার করতে পারেন। এবং দেখুন, যদি সেখানে কিছু পরিবর্তন হয়, আপনি এটি এখানে চালাতে পারেন।

আপনি এই সিদ্ধান্ত কিভাবে পছন্দ করেন? কেউ কি বিশ্বাস করেন যে এটি একটি দুর্দান্ত সমাধান? আমি একটি হাসি দেখতে, আমি সন্দেহ creeped দেখতে.

অবশ্যই, বাড়িতে এটি পুনরাবৃত্তি করবেন না। টেরাফর্ম কখনই টেরাফর্মের মধ্যে থেকে চালানোর জন্য ডিজাইন করা হয়নি।

একটি প্রতিবেদনে তারা আমাকে বলেছিল: "না, এটি কাজ করবে না।" বিন্দু হল যে এটি কাজ করা উচিত নয়। যদিও এটি খুব চিত্তাকর্ষক দেখায় যখন আপনি Terraform থেকে Terraform চালু করতে পারেন, এবং Terraform এছাড়াও আছে, কিন্তু আপনাকে তা করতে হবে না। Terraform সবসময় খুব সহজে শুরু করা উচিত।

https://github.com/gruntwork-io/terragrunt/

এক জায়গায় কিছু পরিবর্তিত হলে আপনার কল অর্কেস্ট্রেশনের প্রয়োজন হলে, টেরাগ্রান্ট আছে।

Terragrunt হল একটি ইউটিলিটি, টেরাফর্মের একটি অ্যাড-অন, যা আপনাকে অবকাঠামো মডিউলগুলিতে কল সমন্বয় ও অর্কেস্ট্রেট করতে দেয়।

একটি সাধারণ Terraform কনফিগারেশন ফাইল এই মত দেখায়.

আপনি কোন নির্দিষ্ট মডিউলটি কল করতে চান তা উল্লেখ করুন।

মডিউল কি নির্ভরতা আছে?

এবং কি আর্গুমেন্ট এই মডিউল গ্রহণ করে. টেরাগ্রান্ট সম্পর্কে জানার জন্য এতটুকুই।

ডকুমেন্টেশন আছে, এবং GitHub এ 1টি তারা আছে। কিন্তু বেশিরভাগ ক্ষেত্রেই, এটি আপনার জানা দরকার। এবং যে কোম্পানিগুলো সবেমাত্র Terraform এর সাথে কাজ শুরু করেছে তাদের ক্ষেত্রে এটি বাস্তবায়ন করা খুবই সহজ।

তাই অর্কেস্ট্রেশন হল টেরাগ্রান্ট। অন্যান্য বিকল্প আছে.

এখন আসুন কোড দিয়ে কিভাবে কাজ করবেন সে সম্পর্কে কথা বলা যাক।

আপনি যদি আপনার কোডে নতুন বৈশিষ্ট্য যোগ করতে চান তবে বেশিরভাগ ক্ষেত্রে এটি সহজ। আপনি একটি নতুন সম্পদ লিখছেন, সবকিছু সহজ.

আপনার যদি এমন কিছু সংস্থান থাকে যা আপনি আগে থেকেই তৈরি করেন, উদাহরণস্বরূপ, আপনি একটি AWS অ্যাকাউন্ট খোলার পরে Terraform সম্পর্কে জানতে পেরেছেন এবং আপনার কাছে ইতিমধ্যে থাকা সংস্থানগুলি ব্যবহার করতে চান, তাহলে এইভাবে আপনার মডিউলটি প্রসারিত করা উপযুক্ত হবে, তাই যে এটি বিদ্যমান সম্পদ ব্যবহার সমর্থন করে.

এবং ব্লক রিসোর্স ব্যবহার করে নতুন রিসোর্স তৈরিকে সমর্থন করে।

আউটপুটে, আমরা সবসময় কি ব্যবহার করা হয়েছে তার উপর নির্ভর করে একটি আউটপুট আইডি ফেরত দেই।

টেরাফর্ম 0.11-এ দ্বিতীয় অত্যন্ত গুরুত্বপূর্ণ সমস্যা হল তালিকা নিয়ে কাজ করা।

অসুবিধা এই সত্য যে আমরা যদি ব্যবহারকারীদের যেমন একটি তালিকা আছে.

এবং যখন আমরা ব্লক রিসোর্স ব্যবহার করে এই ব্যবহারকারীদের তৈরি করি, তখন সবকিছু ঠিকঠাক হয়ে যায়। আমরা প্রতিটির জন্য একটি ফাইল তৈরি করে, সম্পূর্ণ তালিকার মধ্য দিয়ে যাই। সবকিছু ঠিক আছে. এবং তারপরে, উদাহরণস্বরূপ, মাঝখানে থাকা user3 কে এখান থেকে সরানো উচিত, তারপরে তার পরে তৈরি করা সমস্ত সংস্থান পুনরায় তৈরি করা হবে কারণ সূচকটি পরিবর্তন হবে।

একটি রাষ্ট্রীয় পরিবেশে তালিকার সাথে কাজ করা। একটি রাষ্ট্রীয় পরিবেশ কি? এই অবস্থা যেখানে সম্পদ তৈরি করা হলে একটি নতুন মান ঘটে। উদাহরণস্বরূপ, AWS Access Key বা AWS সিক্রেট কী, অর্থাৎ যখন আমরা একজন ব্যবহারকারী তৈরি করি, তখন আমরা একটি নতুন অ্যাক্সেস বা গোপন কী পাই। এবং প্রতিবার আমরা একটি ব্যবহারকারী মুছে ফেলি, সেই ব্যবহারকারীর একটি নতুন কী থাকবে। কিন্তু এটি ফেং শুই নয়, কারণ ব্যবহারকারী আমাদের সাথে বন্ধু হতে চাইবে না যদি আমরা প্রতিবার কেউ দল ত্যাগ করে তার জন্য একজন নতুন ব্যবহারকারী তৈরি করি।

এটাই সমাধান। এটি Jsonnet এ লেখা কোড। Jsonnet হল Google থেকে একটি টেমপ্লেটিং ভাষা।

এই কমান্ডটি আপনাকে এই টেমপ্লেটটি গ্রহণ করতে দেয় এবং আউটপুটে এটি একটি json ফাইল ফেরত দেয় যা আপনার টেমপ্লেট অনুযায়ী তৈরি করা হয়।

টেমপ্লেট এই মত দেখায়.

Terraform আপনাকে HCL এবং Json উভয়ের সাথে একইভাবে কাজ করতে দেয়, তাই আপনার যদি Json তৈরি করার ক্ষমতা থাকে, তাহলে আপনি এটিকে Terraform-এ স্লিপ করতে পারেন। .tf.json এক্সটেনশন সহ ফাইলটি সফলভাবে ডাউনলোড করা হবে।

এবং তারপরে আমরা যথারীতি এটির সাথে কাজ করি: টেরাফর্ম ইনিট, টেরামর্ম প্রযোজ্য। এবং আমরা দুটি ব্যবহারকারী তৈরি করি।

এখন কেউ দল ছেড়ে গেলে আমরা ভয় পাই না। আমরা শুধু json ফাইলটি সম্পাদনা করব। ভাস্য পুপকিন চলে গেলেন, পেটিয়া পাইটোচকিন থেকে গেলেন। Petya Pyatochkin একটি নতুন কী পাবেন না।

অন্যান্য সরঞ্জামের সাথে টেরাফর্মকে একীভূত করা আসলে টেরাফর্মের কাজ নয়। টেরাফর্ম একটি সম্পদ তৈরির প্ল্যাটফর্ম হিসাবে তৈরি করা হয়েছিল এবং এটিই। এবং এর পরে যা আসে তা টেরাফর্মের উদ্বেগের বিষয় নয়। এবং আপনি সেখানে এটি করা হবে না. সেখানে Ansible আছে, যা যা প্রয়োজন তা করে।

কিন্তু পরিস্থিতি দেখা দেয় যখন আমরা Terraform প্রসারিত করতে চাই এবং কিছু সম্পন্ন হওয়ার পরে কিছু কমান্ড কল করতে চাই।

প্রথম উপায়. আমরা আউটপুট তৈরি করি যেখানে আমরা এই কমান্ডটি লিখি।

এবং তারপর আমরা শেল টেরাফর্ম আউটপুট থেকে এই কমান্ডটিকে কল করি এবং আমরা যে মানটি চাই তা নির্দিষ্ট করি। সুতরাং, কমান্ডটি সমস্ত প্রতিস্থাপিত মান সহ কার্যকর করা হয়। এটা খুবই আরামদায়ক।

দ্বিতীয় উপায়। এটি আমাদের পরিকাঠামোর পরিবর্তনের উপর নির্ভর করে null_resource এর ব্যবহার। কিছু রিসোর্সের আইডি পরিবর্তনের সাথে সাথে আমরা একই স্থানীয়-exe কল করতে পারি।

স্বাভাবিকভাবেই, এই সব কাগজে মসৃণ, কারণ অন্যান্য সকল পাবলিক প্রোভাইডারদের মতো অ্যামাজনেরও নিজস্ব এজ কেস রয়েছে।

সবচেয়ে সাধারণ এজ কেস হল যে আপনি যখন একটি AWS অ্যাকাউন্ট খোলেন, তখন আপনি কোন অঞ্চল ব্যবহার করেন তা গুরুত্বপূর্ণ; এই বৈশিষ্ট্যটি সেখানে অন্তর্ভুক্ত কিনা; সম্ভবত আপনি এটি ডিসেম্বর 2013 এর পরে খুলেছেন; হয়তো আপনি VPC ইত্যাদিতে ডিফল্ট ব্যবহার করছেন। অনেক সীমাবদ্ধতা রয়েছে। এবং আমাজন তাদের সমস্ত ডকুমেন্টেশনে ছড়িয়ে দিয়েছে।

আমি এড়াতে সুপারিশ করা কয়েকটি জিনিস আছে।

শুরুতে, টেরাফর্ম প্ল্যান বা টেরাফর্ম সিএলআই-এর ভিতরে সমস্ত অ-গোপন যুক্তি এড়িয়ে চলুন। এই সব একটি tfvars ফাইল বা একটি পরিবেশ পরিবর্তনশীল মধ্যে রাখা যেতে পারে.

কিন্তু আপনাকে এই পুরো ম্যাজিক কমান্ডটি মুখস্থ করতে হবে না। টেরাফর্ম প্ল্যান – var এবং বন্ধ আমরা যাই। প্রথম চলকটি var, দ্বিতীয়টি var, তৃতীয়টি, চতুর্থটি। কোড হিসাবে অবকাঠামোর সবচেয়ে গুরুত্বপূর্ণ নীতি যা আমি প্রায়শই ব্যবহার করি তা হল কোডটি দেখে, সেখানে কী স্থাপন করা হয়েছে, কোন অবস্থায় এবং কোন মানগুলির সাথে আমার একটি পরিষ্কার বোঝা উচিত। এবং তাই আমাকে ডকুমেন্টেশন পড়তে হবে না বা ভাস্যাকে জিজ্ঞাসা করতে হবে না যে তিনি আমাদের ক্লাস্টার তৈরি করতে কী প্যারামিটার ব্যবহার করেছিলেন। আমাকে শুধু tfvars এক্সটেনশনের সাথে একটি ফাইল খুলতে হবে, যা প্রায়শই পরিবেশের সাথে মেলে এবং সেখানে সবকিছু দেখতে হবে।

এছাড়াও সুযোগ কমাতে লক্ষ্য আর্গুমেন্ট ব্যবহার করবেন না. এর জন্য ছোট অবকাঠামো মডিউল ব্যবহার করা অনেক সহজ।

এছাড়াও, সীমাবদ্ধ করবেন না এবং সমান্তরালতা বাড়াবেন না। যদি আমার কাছে 150টি সংস্থান থাকে এবং আমি ডিফল্ট 10 থেকে 100 এ অ্যামাজন সমান্তরালতা বাড়াতে চাই, তাহলে সম্ভবত কিছু ভুল হবে। অথবা এটা এখন ভাল যেতে পারে, কিন্তু যখন Amazon বলে যে আপনি অনেক বেশি কল করছেন, আপনি সমস্যায় পড়বেন।

Terraform এই সমস্যাগুলির বেশিরভাগ পুনরায় চালু করার চেষ্টা করবে, কিন্তু আপনি প্রায় কিছুই অর্জন করতে পারবেন না। সমান্তরালতা=1 ব্যবহার করা একটি গুরুত্বপূর্ণ জিনিস যদি আপনি AWS API এর ভিতরে বা Terraform প্রদানকারীর ভিতরে কিছু বাগ দেখেন। এবং তারপরে আপনাকে নির্দিষ্ট করতে হবে: parallelism=1 এবং অপেক্ষা করুন যতক্ষণ না Terraform একটি কল শেষ করে, তারপর দ্বিতীয়টি, তারপর তৃতীয়টি। সে একে একে চালু করবে।

লোকেরা প্রায়শই আমাকে জিজ্ঞাসা করে: "কেন আমি মনে করি যে টেরাফর্ম ওয়ার্কস্পেসগুলি খারাপ?"। আমি বিশ্বাস করি কোড হিসাবে অবকাঠামোর নীতি হল কী অবকাঠামো তৈরি করা হয়েছে এবং কী মান দিয়ে তা দেখা।

ওয়ার্কস্পেস ব্যবহারকারীদের দ্বারা তৈরি করা হয়নি. এর মানে এই নয় যে ব্যবহারকারীরা গিটহাব ইস্যুতে লিখেছেন যে তারা টেরাফর্ম ওয়ার্কস্পেস ছাড়া বাঁচতে পারবেন না। না এভাবে না। Terraform Enterprise একটি বাণিজ্যিক সমাধান। HashiCorp থেকে Terraform সিদ্ধান্ত নিয়েছে যে আমাদের ওয়ার্কস্পেস প্রয়োজন, তাই আমরা এটি জমা দিয়েছি। আমি এটি একটি পৃথক ফোল্ডারে রাখা অনেক সহজ খুঁজে. তারপরে আরও কিছু ফাইল থাকবে, তবে এটি আরও পরিষ্কার হবে।

কোড দিয়ে কিভাবে কাজ করবেন? আসলে, তালিকা নিয়ে কাজ করাই একমাত্র কষ্ট। এবং Terraform সহজ নিন. এটি এমন কিছু নয় যা আপনাকে দুর্দান্ত বোধ করবে। সেখানে ডকুমেন্টেশনে লিখিত সমস্ত কিছু ঠেলে দেওয়ার দরকার নেই।

প্রতিবেদনের বিষয় "ভবিষ্যতের জন্য" লেখা ছিল। আমি খুব সংক্ষেপে এই কথা বলব. ভবিষ্যতের জন্য, এর মানে হল যে 0.12 শীঘ্রই মুক্তি পাবে।

0.12 হল একগুচ্ছ নতুন জিনিস। আপনি যদি নিয়মিত প্রোগ্রামিং থেকে আসেন, তাহলে আপনি সমস্ত ধরণের গতিশীল ব্লক, লুপ, সঠিক এবং শর্তসাপেক্ষ তুলনামূলক ক্রিয়াকলাপগুলি মিস করবেন, যেখানে বাম এবং ডান দিকগুলি একই সাথে গণনা করা হয় না, তবে পরিস্থিতির উপর নির্ভর করে। আপনি এটি খুব মিস করেন, তাই 0.12 আপনার জন্য এটি সমাধান করবে।

কিন্তু! আপনি যদি তৈরি মডিউল, তৃতীয় পক্ষের সমাধান ব্যবহার করে কম এবং সহজে লেখেন, তাহলে আপনাকে অপেক্ষা করতে হবে না এবং আশা করি 0.12 এসে আপনার জন্য সবকিছু ঠিক করে দেবে।

প্রতিবেদনের জন্য ধন্যবাদ! আপনি কোড হিসাবে অবকাঠামো সম্পর্কে কথা বলেছেন এবং আক্ষরিক অর্থে পরীক্ষা সম্পর্কে একটি শব্দ বলেছেন। মডিউলে পরীক্ষা প্রয়োজন? এটা কার দায়িত্ব? আমি কি এটা নিজে লিখতে হবে নাকি এটা মডিউলের দায়িত্ব?

পরের বছর আমরা সবকিছু পরীক্ষা করার সিদ্ধান্ত নিয়েছি এমন রিপোর্টের সাথে বোমাবর্ষণ করা হবে। কি পরীক্ষা করতে হবে সবচেয়ে বড় প্রশ্ন। অনেক নির্ভরতা আছে, বিভিন্ন প্রদানকারীর কাছ থেকে অনেক সীমাবদ্ধতা রয়েছে। যখন আপনি এবং আমি কথা বলছি এবং আপনি বলেন: "আমার পরীক্ষা দরকার," তখন আমি জিজ্ঞাসা করি: "আপনি কী পরীক্ষা করবেন?" আপনি বলছেন আপনার এলাকায় পরীক্ষা দেবেন। তখন আমি বলি আমার অঞ্চলে এটা চলে না। অর্থাৎ, আমরা আপনার সাথে এই বিষয়ে একমত হতে পারি না। বলার অপেক্ষা রাখে না যে প্রচুর প্রযুক্তিগত সমস্যা রয়েছে। অর্থাৎ, এই পরীক্ষাগুলি কীভাবে লিখতে হয় যাতে তারা পর্যাপ্ত হয়।

আমি সক্রিয়ভাবে এই বিষয়টি নিয়ে গবেষণা করছি, যেমন আপনি যে পরিকাঠামো লিখেছেন তার উপর ভিত্তি করে কীভাবে স্বয়ংক্রিয়ভাবে পরীক্ষা তৈরি করা যায়। অর্থাৎ, আপনি যদি এই কোডটি লিখে থাকেন, তাহলে আমাকে এটি চালাতে হবে, এর ভিত্তিতে আমি পরীক্ষা তৈরি করতে পারি।

টেরেটেস্ট - এটি সবচেয়ে ঘন ঘন উল্লিখিত লাইব্রেরিগুলির মধ্যে একটি যা আপনাকে Terraform-এর জন্য ইন্টিগ্রেশন পরীক্ষা লিখতে দেয়। এটি ইউটিলিটিগুলির মধ্যে একটি। আমি DSL প্রকার পছন্দ করি, উদাহরণস্বরূপ, rspec.

অ্যান্টন, রিপোর্টের জন্য ধন্যবাদ! আমার নাম ভ্যালেরি। আমাকে একটু দার্শনিক প্রশ্ন জিজ্ঞাসা করা যাক. আছে, শর্তসাপেক্ষে, বিধান, সেখানে স্থাপনা আছে। প্রভিশনিং আমার ইনফ্রাস্ট্রাকচার তৈরি করে, ডিপ্লোয়মেন্টে আমরা এটিকে প্রয়োজনীয় কিছু দিয়ে পূরণ করি, উদাহরণস্বরূপ, সার্ভার, অ্যাপ্লিকেশন, ইত্যাদি। এবং এটা আমার মাথায় আছে যে টেরাফর্ম প্রভিশনিংয়ের জন্য বেশি, এবং আনসিবল ডিপ্লোয়িংয়ের জন্য আরও বেশি, কারণ অ্যান্সিবল হল শারীরিক অবকাঠামোর জন্যও আপনাকে nginx, Postgres ইনস্টল করার অনুমতি দেয়। কিন্তু একই সময়ে, Ansible প্রভিশনের অনুমতি দেয় বলে মনে হচ্ছে, উদাহরণস্বরূপ, Amazon বা Google সম্পদের। কিন্তু Terraform আপনাকে এর মডিউল ব্যবহার করে কিছু সফ্টওয়্যার স্থাপন করার অনুমতি দেয়। আপনার দৃষ্টিকোণ থেকে, Terraform এবং Ansible এর মধ্যে চলে এমন কিছু সীমানা আছে কি, কোথায় এবং কি ব্যবহার করা ভাল? অথবা, উদাহরণস্বরূপ, আপনি কি মনে করেন যে Ansible ইতিমধ্যেই আবর্জনা, আপনার কি সবকিছুর জন্য Terraform ব্যবহার করার চেষ্টা করা উচিত?

ভাল প্রশ্ন, ভ্যালেরি। আমি বিশ্বাস করি যে 2014 সাল থেকে টেরাফর্ম উদ্দেশ্যের পরিপ্রেক্ষিতে পরিবর্তিত হয়নি। এটি অবকাঠামোর জন্য তৈরি করা হয়েছিল এবং অবকাঠামোর জন্য মারা গিয়েছিল। আমাদের এখনও কনফিগারেশন ম্যানেজমেন্টের জন্য প্রয়োজন ছিল এবং থাকবে। চ্যালেঞ্জ হল লঞ্চ_কনফিগারেশনের ভিতরে ব্যবহারকারীর ডেটা রয়েছে। এবং সেখানে আপনি Ansible, ইত্যাদি টানুন। এটি হল আদর্শ পার্থক্য যা আমি সবচেয়ে বেশি পছন্দ করি।

যদি আমরা সুন্দর পরিকাঠামোর কথা বলি, তাহলে প্যাকারের মতো ইউটিলিটি রয়েছে যা এই চিত্রটি সংগ্রহ করে। এবং তারপরে Terraform এই চিত্রটি খুঁজে পেতে এবং এর লঞ্চ_কনফিগারেশন আপডেট করতে ডেটা উত্স ব্যবহার করে। অর্থাৎ, এইভাবে পাইপলাইন হল যে আমরা প্রথমে Tracker টান, তারপর Terraform টান। এবং যদি একটি বিল্ড ছিল, তাহলে একটি নতুন পরিবর্তন ঘটে।

হ্যালো! প্রতিবেদনের জন্য ধন্যবাদ! আমার নাম মিশা, আরবিএস কোম্পানি। একটি সংস্থান তৈরি করার সময় আপনি একজন প্রভিশনারের মাধ্যমে Ansible কল করতে পারেন। এবং অ্যানসিবলেও ডায়নামিক ইনভেন্টরির মতো একটি বিষয় রয়েছে। এবং আপনি প্রথমে Terraform কল করতে পারেন, এবং তারপর Ansible কল করতে পারেন, যা রাষ্ট্র থেকে সংস্থান নেবে এবং এটি কার্যকর করবে। কি ভাল?

এবং যে এবং যে মানুষ অভিন্ন সাফল্য সঙ্গে ব্যবহার. এটা আমার মনে হয় যে Ansible মধ্যে গতিশীল ইনভেন্টরি একটি সুবিধাজনক জিনিস, যদি আমরা অটোস্কেলিং গ্রুপ সম্পর্কে কথা না বলি। কারণ অটোস্কেলিং গ্রুপে আমাদের ইতিমধ্যেই চালু_কনফিগারেশন নামে নিজস্ব টুলকিট রয়েছে। আমরা লঞ্চ_কনফিগারেশনে লিখি যা কিছু লঞ্চ করা দরকার যখন আমরা একটি নতুন সংস্থান তৈরি করি। অতএব, অ্যামাজনের সাথে, গতিশীল ইনভেন্টরি ব্যবহার করা এবং Terraform ts ফাইল পড়া আমার মতে ওভারকিল। এবং আপনি যদি এমন অন্যান্য সরঞ্জাম ব্যবহার করেন যেখানে "অটোস্কেলিং গ্রুপ" এর কোন ধারণা নেই, উদাহরণস্বরূপ, আপনি DigitalOcean বা অন্য কোনো প্রদানকারী ব্যবহার করেন যেখানে কোনো অটোস্কেলিং গ্রুপ নেই, তাহলে সেখানে আপনাকে API হ্যান্ডলগুলি টানতে হবে, IP ঠিকানাগুলি খুঁজে বের করতে হবে, তৈরি করতে হবে একটি ডাইনামিক ইনভেন্টরি ফাইল, এবং Ansible ইতিমধ্যে এটি ঘোরাফেরা করবে। অর্থাৎ, অ্যামাজনের জন্য রয়েছে লঞ্চ_কনফিগারেশন, এবং অন্য সবকিছুর জন্য ডায়নামিক ইনভেন্টরি রয়েছে।

উত্স: www.habr.com