টেরাফর্ম ক্ষতি

লুপ, ইফ স্টেটমেন্ট এবং ডিপ্লোয়মেন্ট কৌশল, সেইসাথে সাধারণভাবে টেরাফর্মকে প্রভাবিত করে এমন আরও সাধারণ সমস্যাগুলি সহ কয়েকটি ত্রুটি হাইলাইট করা যাক:

• গণনা এবং প্রতিটি প্যারামিটারের সীমাবদ্ধতা রয়েছে;
• শূন্য ডাউনটাইম স্থাপনা সীমিত করুন;
• এমনকি একটি ভাল পরিকল্পনা ব্যর্থ হতে পারে;
• রিফ্যাক্টরিং এর ক্ষতি হতে পারে;
• বিলম্বিত সমন্বয় সামঞ্জস্যপূর্ণ... বিলম্বিত সঙ্গে।

গণনা এবং প্রতিটি প্যারামিটারের সীমাবদ্ধতা রয়েছে

এই অধ্যায়ের উদাহরণগুলি কাউন্ট প্যারামিটার এবং লুপ এবং শর্তসাপেক্ষ যুক্তিতে for_each এক্সপ্রেশনের ব্যাপক ব্যবহার করে। তারা ভাল পারফর্ম করে, তবে তাদের দুটি গুরুত্বপূর্ণ সীমাবদ্ধতা রয়েছে যা আপনাকে সচেতন হতে হবে।

• Count এবং for_each কোনো রিসোর্স আউটপুট ভেরিয়েবল উল্লেখ করতে পারে না।
• count এবং for_each মডিউল কনফিগারেশনে ব্যবহার করা যাবে না।

count এবং for_each কোনো রিসোর্স আউটপুট ভেরিয়েবল উল্লেখ করতে পারে না

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

resource "aws_instance" "example_1" {
   count             = 3
   ami                = "ami-0c55b159cbfafe1f0"
   instance_type = "t2.micro"
}

আসুন এক এক করে তাদের দিকে তাকাই।

যেহেতু গণনা পরামিতি একটি স্ট্যাটিক মান সেট করা আছে, এই কোডটি সমস্যা ছাড়াই কাজ করবে: আপনি যখন প্রয়োগ কমান্ড চালাবেন, তখন এটি তিনটি EC2 সার্ভার তৈরি করবে। কিন্তু আপনি যদি আপনার বর্তমান AWS অঞ্চলের মধ্যে প্রতিটি প্রাপ্যতা অঞ্চলে (AZ) একটি সার্ভার স্থাপন করতে চান? আপনি aws_availability_zones ডেটা সোর্স থেকে আপনার কোডটি জোনের একটি তালিকা লোড করতে পারেন এবং তারপর প্রতিটির মাধ্যমে লুপ করুন এবং গণনা প্যারামিটার এবং অ্যারে সূচক অ্যাক্সেস ব্যবহার করে এতে একটি EC2 সার্ভার তৈরি করুন:

resource "aws_instance" "example_2" {
   count                   = length(data.aws_availability_zones.all.names)
   availability_zone   = data.aws_availability_zones.all.names[count.index]
   ami                     = "ami-0c55b159cbfafe1f0"
   instance_type       = "t2.micro"
}

data "aws_availability_zones" "all" {}

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

resource "random_integer" "num_instances" {
  min = 1
  max = 3
}

এই কোডটি 1 এবং 3 এর মধ্যে একটি এলোমেলো সংখ্যা তৈরি করে। আসুন দেখি কি হয় যদি আমরা aws_instance সম্পদের গণনা প্যারামিটারে এই সংস্থানের আউটপুট ব্যবহার করার চেষ্টা করি:

resource "aws_instance" "example_3" {
   count             = random_integer.num_instances.result
   ami                = "ami-0c55b159cbfafe1f0"
   instance_type = "t2.micro"
}

আপনি যদি এই কোডে টেরাফর্ম প্ল্যান চালান, তাহলে আপনি নিম্নলিখিত ত্রুটিটি পাবেন:

Error: Invalid count argument

   on main.tf line 30, in resource "aws_instance" "example_3":
   30: count = random_integer.num_instances.result

The "count" value depends on resource attributes that cannot be determined until apply, so Terraform cannot predict how many instances will be created. To work around this, use the -target argument to first apply only the resources that the count depends on.

টেরাফর্মের প্রয়োজন যে কোনো সম্পদ তৈরি বা পরিবর্তন করার আগে পরিকল্পনা পর্বের সময় গণনা এবং প্রতিটির জন্য গণনা করা। এর মানে হল গণনা এবং for_each আক্ষরিক, ভেরিয়েবল, ডেটা সোর্স এবং এমনকি রিসোর্স তালিকাগুলিকে উল্লেখ করতে পারে (যতক্ষণ তাদের দৈর্ঘ্য নির্ধারিত সময়ে নির্ধারণ করা যেতে পারে), কিন্তু গণনাকৃত রিসোর্স আউটপুট ভেরিয়েবলের জন্য নয়।

count এবং for_each মডিউল কনফিগারেশনে ব্যবহার করা যাবে না

কোন দিন আপনি আপনার মডিউল কনফিগারেশনে একটি গণনা পরামিতি যোগ করতে প্রলুব্ধ হতে পারেন:

module "count_example" {
     source = "../../../../modules/services/webserver-cluster"

     count = 3

     cluster_name = "terraform-up-and-running-example"
     server_port = 8080
     instance_type = "t2.micro"
}

এই কোডটি ওয়েব সার্ভার-ক্লাস্টার রিসোর্সের তিনটি কপি তৈরি করতে একটি মডিউলের ভিতরে গণনা ব্যবহার করার চেষ্টা করে। অথবা আপনি কিছু বুলিয়ান অবস্থার উপর ভিত্তি করে একটি মডিউল সংযোগকে ঐচ্ছিক করতে চাইতে পারেন এর গণনা পরামিতি 0 এ সেট করে। এটি যুক্তিসঙ্গত কোডের মতো দেখতে হতে পারে, কিন্তু টেরাফর্ম পরিকল্পনা চালানোর সময় আপনি এই ত্রুটিটি পাবেন:

Error: Reserved argument name in module block

   on main.tf line 13, in module "count_example":
   13: count = 3

The name "count" is reserved for use in a future version of Terraform.

দুর্ভাগ্যবশত, Terraform 0.12.6 অনুযায়ী, একটি মডিউল রিসোর্সে কাউন্ট বা for_each ব্যবহার করা সমর্থিত নয়। Terraform 0.12 রিলিজ নোট (http://bit.ly/3257bv4) অনুসারে, HashiCorp ভবিষ্যতে এই ক্ষমতা যোগ করার পরিকল্পনা করছে, তাই আপনি এই বইটি কখন পড়বেন তার উপর নির্ভর করে, এটি ইতিমধ্যেই উপলব্ধ হতে পারে। নিশ্চিতভাবে জানতে, এখানে Terraform চেঞ্জলগ পড়ুন.

জিরো ডাউনটাইম স্থাপনার সীমাবদ্ধতা

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

উদাহরণস্বরূপ, ওয়েবসার্ভার-ক্লাস্টার মডিউলটিতে aws_autoscaling_schedule সম্পদের একটি জোড়া রয়েছে, যা সকাল 9টায় ক্লাস্টারে সার্ভারের সংখ্যা দুই থেকে দশ পর্যন্ত বাড়িয়ে দেয়। আপনি যদি সকাল 11 টায় মোতায়েন করেন, নতুন ASG দশটির পরিবর্তে মাত্র দুটি সার্ভারের সাথে বুট আপ হবে এবং পরের দিন সকাল 9 টা পর্যন্ত একইভাবে থাকবে৷

এই সীমাবদ্ধতা বিভিন্ন উপায়ে অতিক্রম করা যেতে পারে।

• aws_autoscaling_schedule-এ পুনরাবৃত্তি পরামিতি 0 9 * * * ("সকাল 9 টায় চালান") থেকে 0-59 9-17 * * * ("সকাল 9 টা থেকে 5 টা পর্যন্ত প্রতি মিনিটে চালান") এর মতো কিছুতে পরিবর্তন করুন। যদি ASG ইতিমধ্যে দশটি সার্ভার থাকে, তাহলে এই অটোস্কেলিং নিয়মটি আবার চালানোর ফলে কিছু পরিবর্তন হবে না, যা আমরা চাই। কিন্তু যদি ASG শুধুমাত্র সম্প্রতি মোতায়েন করা হয়, তাহলে এই নিয়ম নিশ্চিত করবে যে সর্বোচ্চ এক মিনিটের মধ্যে এর সার্ভারের সংখ্যা দশে পৌঁছে যাবে। এটি সম্পূর্ণরূপে মার্জিত পদ্ধতি নয়, এবং দশ থেকে দুটি সার্ভার এবং পিছনে বড় লাফও ব্যবহারকারীদের জন্য সমস্যার কারণ হতে পারে।
• ASG-এ সক্রিয় সার্ভারের সংখ্যা নির্ধারণ করতে AWS API ব্যবহার করে এমন একটি কাস্টম স্ক্রিপ্ট তৈরি করুন, একটি বাহ্যিক ডেটা উত্স ব্যবহার করে এটিকে কল করুন (পৃষ্ঠা 249-এ "বহিরাগত ডেটা উত্স" দেখুন), এবং ASG-এর পছন্দসই_ক্ষমতা পরামিতি সেট করুন এই পান্ডুলিপি. এইভাবে, প্রতিটি নতুন ASG উদাহরণ সর্বদা বিদ্যমান টেরাফর্ম কোডের মতো একই ক্ষমতাতে চলবে এবং এটি বজায় রাখা আরও কঠিন করে তোলে।

অবশ্যই, Terraform আদর্শভাবে শূন্য-ডাউনটাইম স্থাপনার জন্য অন্তর্নির্মিত সমর্থন থাকবে, কিন্তু মে 2019 পর্যন্ত, HashiCorp টিমের এই কার্যকারিতা যুক্ত করার কোন পরিকল্পনা ছিল না (বিস্তারিত - এখানে).

সঠিক পরিকল্পনা অসফলভাবে বাস্তবায়িত হতে পারে

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

resource "aws_iam_user" "existing_user" {
   # Подставьте сюда имя уже существующего пользователя IAM,
   # чтобы попрактиковаться в использовании команды terraform import
   name = "yevgeniy.brikman"
}

এখন, আপনি যদি প্ল্যান কমান্ড চালান, টেরাফর্ম একটি আপাতদৃষ্টিতে যুক্তিসঙ্গত স্থাপনার পরিকল্পনা আউটপুট করবে:

Terraform will perform the following actions:

   # aws_iam_user.existing_user will be created
   + resource "aws_iam_user" "existing_user" {
         + arn                  = (known after apply)
         + force_destroy   = false
         + id                    = (known after apply)
         + name               = "yevgeniy.brikman"
         + path                 = "/"
         + unique_id         = (known after apply)
      }

Plan: 1 to add, 0 to change, 0 to destroy.

আপনি প্রয়োগ কমান্ড চালালে আপনি নিম্নলিখিত ত্রুটি পাবেন:

Error: Error creating IAM User yevgeniy.brikman: EntityAlreadyExists:
User with name yevgeniy.brikman already exists.

   on main.tf line 10, in resource "aws_iam_user" "existing_user":
   10: resource "aws_iam_user" "existing_user" {

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

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

এ থেকে দুটি শিক্ষা নেওয়ার আছে।

• আপনি যদি ইতিমধ্যেই Terraform এর সাথে কাজ শুরু করে থাকেন তবে অন্য কিছু ব্যবহার করবেন না। আপনার পরিকাঠামোর অংশ যদি Terraform ব্যবহার করে পরিচালিত হয়, তাহলে আপনি এটিকে আর ম্যানুয়ালি পরিবর্তন করতে পারবেন না। অন্যথায়, আপনি শুধুমাত্র অদ্ভুত Terraform ত্রুটির ঝুঁকিই রাখেন না, আপনি IaC-এর অনেক সুবিধাও অস্বীকার করেন কারণ কোডটি আর আপনার পরিকাঠামোর সঠিক উপস্থাপনা হবে না।
• আপনার যদি ইতিমধ্যে কিছু অবকাঠামো থাকে তবে আমদানি কমান্ডটি ব্যবহার করুন। আপনি যদি বিদ্যমান অবকাঠামোর সাথে Terraform ব্যবহার করা শুরু করেন, আপনি টেরফর্ম আমদানি কমান্ড ব্যবহার করে স্টেট ফাইলে এটি যোগ করতে পারেন। এইভাবে টেরাফর্ম জানতে পারবে কোন পরিকাঠামো পরিচালনা করতে হবে। আমদানি কমান্ড দুটি আর্গুমেন্ট লাগে। প্রথমটি হল আপনার কনফিগারেশন ফাইলের রিসোর্স ঠিকানা। এখানে সিনট্যাক্স রিসোর্স লিঙ্কের মতোই: _। (যেমন aws_iam_user.existing_user)। দ্বিতীয় যুক্তিটি আমদানি করা সম্পদের আইডি। ধরা যাক রিসোর্স আইডি aws_iam_user হল ব্যবহারকারীর নাম (উদাহরণস্বরূপ, yevgeniy.brikman), এবং রিসোর্স আইডি aws_instance হল EC2 সার্ভার আইডি (যেমন i-190e22e5)। কীভাবে একটি সংস্থান আমদানি করতে হয় তা সাধারণত তার পৃষ্ঠার নীচে ডকুমেন্টেশনে নির্দেশিত হয়।

  নিচে একটি ইম্পোর্ট কমান্ড রয়েছে যা অধ্যায় 2-এ IAM ব্যবহারকারীর সাথে আপনার Terraform কনফিগারেশনে যোগ করা aws_iam_user রিসোর্সকে সিঙ্ক্রোনাইজ করে (অবশ্যই yevgeniy.brikman-এর জন্য আপনার নাম প্রতিস্থাপন):

  $ terraform import aws_iam_user.existing_user yevgeniy.brikman

  Terraform আপনার IAM ব্যবহারকারীকে খুঁজে পেতে AWS API-কে কল করবে এবং আপনার Terraform কনফিগারেশনে এটি এবং aws_iam_user.existing_user রিসোর্সের মধ্যে একটি স্টেট ফাইল অ্যাসোসিয়েশন তৈরি করবে। এখন থেকে, যখন আপনি প্ল্যান কমান্ড চালাবেন, তখন Terraform জানবে যে IAM ব্যবহারকারী ইতিমধ্যেই বিদ্যমান এবং এটি আবার তৈরি করার চেষ্টা করবে না।

  এটি লক্ষণীয় যে যদি আপনার কাছে ইতিমধ্যেই প্রচুর সংস্থান থাকে যা আপনি টেরাফর্মে আমদানি করতে চান, ম্যানুয়ালি কোডটি লিখতে এবং একে একে একে একে আমদানি করা একটি ঝামেলা হতে পারে৷ তাই টেরাফর্মিং (http://terraforming.dtan4.net/) এর মতো একটি টুল সন্ধান করা মূল্যবান, যা আপনার AWS অ্যাকাউন্ট থেকে স্বয়ংক্রিয়ভাবে কোড এবং রাজ্য আমদানি করতে পারে।

  রিফ্যাক্টরিং এর ক্ষতি হতে পারে

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

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

  উদাহরণস্বরূপ, ওয়েবসার্ভার-ক্লাস্টার মডিউলটিতে একটি ইনপুট পরিবর্তনশীল cluster_name রয়েছে:

  variable "cluster_name" {
     description = "The name to use for all the cluster resources"
     type          = string
  }

  কল্পনা করুন যে আপনি foo নামক একটি মাইক্রোসার্ভিস স্থাপন করতে এই মডিউলটি ব্যবহার করা শুরু করেছেন। পরে, আপনি বারে আপনার পরিষেবার নাম পরিবর্তন করতে চান। এই পরিবর্তন তুচ্ছ মনে হতে পারে, কিন্তু বাস্তবে এটি পরিষেবা ব্যাহত হতে পারে।

  আসল বিষয়টি হল যে ওয়েব সার্ভার-ক্লাস্টার মডিউলটি দুটি নিরাপত্তা গোষ্ঠীর নাম পরামিতি এবং ALB সহ বেশ কয়েকটি সংস্থানে cluster_name ভেরিয়েবল ব্যবহার করে:

  resource "aws_lb" "example" {
     name                    = var.cluster_name
     load_balancer_type = "application"
     subnets = data.aws_subnet_ids.default.ids
     security_groups      = [aws_security_group.alb.id]
  }

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

  অন্য ধরনের রিফ্যাক্টরিংয়ে আপনি আগ্রহী হতে পারেন টেরাফর্ম আইডি পরিবর্তন করা। ওয়েব সার্ভার-ক্লাস্টার মডিউলে aws_security_group রিসোর্সটিকে উদাহরণ হিসেবে নেওয়া যাক:

  resource "aws_security_group" "instance" {
    # (...)
  }

  এই সম্পদের শনাক্তকারীকে বলা হয় উদাহরণ। কল্পনা করুন যে রিফ্যাক্টরিংয়ের সময় আপনি এটিকে আরও বোধগম্য (আপনার মতে) নাম ক্লাস্টার_ইনস্ট্যান্সে পরিবর্তন করার সিদ্ধান্ত নিয়েছেন:

  resource "aws_security_group" "cluster_instance" {
     # (...)
  }

  শেষ পর্যন্ত কি হবে? এটা ঠিক: একটা ব্যাঘাত।

  Terraform প্রতিটি রিসোর্স আইডিকে ক্লাউড প্রদানকারী আইডির সাথে সংযুক্ত করে। উদাহরণস্বরূপ, iam_user AWS IAM ব্যবহারকারী আইডির সাথে যুক্ত এবং aws_instance AWS EC2 সার্ভার আইডির সাথে যুক্ত। আপনি যদি রিসোর্স আইডি পরিবর্তন করেন (উদাহরণ থেকে ক্লাস্টার_ইনস্ট্যান্সে বলুন, যেমনটি aws_security_group-এর ক্ষেত্রে হয়), টেরাফর্মে এটি দেখাবে যে আপনি পুরানো সংস্থান মুছে ফেলেছেন এবং একটি নতুন যোগ করেছেন। আপনি এই পরিবর্তনগুলি প্রয়োগ করলে, Terraform পুরানো নিরাপত্তা গোষ্ঠী মুছে ফেলবে এবং একটি নতুন তৈরি করবে, যখন আপনার সার্ভারগুলি কোনও নেটওয়ার্ক ট্র্যাফিক প্রত্যাখ্যান করতে শুরু করবে।

  এখানে চারটি মূল পাঠ রয়েছে যা আপনার এই আলোচনা থেকে নেওয়া উচিত।

  • সর্বদা পরিকল্পনা কমান্ড ব্যবহার করুন. এটা এই সব snags প্রকাশ করতে পারেন. এটির আউটপুট সাবধানে পর্যালোচনা করুন এবং এমন পরিস্থিতিতে মনোযোগ দিন যেখানে Terraform সম্পদগুলি মুছে ফেলার পরিকল্পনা করে যা সম্ভবত মুছে ফেলা উচিত নয়।
  • আপনি মুছে ফেলার আগে তৈরি করুন. আপনি যদি একটি সংস্থান প্রতিস্থাপন করতে চান, তাহলে মূলটি মুছে ফেলার আগে আপনাকে একটি প্রতিস্থাপন তৈরি করতে হবে কিনা সে সম্পর্কে সাবধানে চিন্তা করুন। উত্তর হ্যাঁ হলে, create_before_destroy সাহায্য করতে পারে। একই ফলাফল দুটি ধাপ সম্পাদন করে ম্যানুয়ালি অর্জন করা যেতে পারে: প্রথমে কনফিগারেশনে একটি নতুন সংস্থান যোগ করুন এবং প্রয়োগ কমান্ডটি চালান এবং তারপরে কনফিগারেশন থেকে পুরানো সংস্থানটি সরিয়ে দিন এবং আবার প্রয়োগ কমান্ডটি ব্যবহার করুন।
  • শনাক্তকারী পরিবর্তন করার জন্য অবস্থা পরিবর্তন করা প্রয়োজন। আপনি যদি রিসোর্সের সাথে যুক্ত আইডি পরিবর্তন করতে চান (উদাহরণস্বরূপ, aws_security_group instance থেকে cluster_instance) রিসোর্স ডিলিট না করে এবং এর একটি নতুন ভার্সন তৈরি না করে, আপনাকে অবশ্যই সেই অনুযায়ী Terraform স্টেট ফাইল আপডেট করতে হবে। এটি ম্যানুয়ালি কখনই করবেন না - পরিবর্তে টেরফর্ম স্টেট কমান্ড ব্যবহার করুন। শনাক্তকারীর নাম পরিবর্তন করার সময়, আপনার টেরাফর্ম স্টেট এমভি কমান্ড চালানো উচিত, যার নিম্নলিখিত সিনট্যাক্স রয়েছে:

    terraform state mv <ORIGINAL_REFERENCE> <NEW_REFERENCE>

    ORIGINAL_REFERENCE হল একটি অভিব্যক্তি যা রিসোর্সটিকে তার বর্তমান ফর্মে বোঝায় এবং NEW_REFERENCE হল যেখানে আপনি এটি সরাতে চান৷ উদাহরণস্বরূপ, যখন aws_security_group গ্রুপের নাম পরিবর্তন করে instance থেকে cluster_instance করার জন্য, আপনাকে নিম্নলিখিত কমান্ডটি চালাতে হবে:

    $ terraform state mv 
       aws_security_group.instance 
       aws_security_group.cluster_instance

    এটি টেরাফর্মকে বলে যে রাষ্ট্রটি আগে aws_security_group.instance এর সাথে যুক্ত ছিল এখন aws_security_group.cluster_instance এর সাথে যুক্ত হওয়া উচিত। যদি এই কমান্ডের নাম পরিবর্তন এবং চালানোর পরে টেরাফর্ম প্ল্যান কোনো পরিবর্তন না দেখায়, তাহলে আপনি সবকিছু সঠিকভাবে করেছেন।

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

  বিলম্বিত ধারাবাহিকতা সামঞ্জস্যপূর্ণ... বিলম্বের সাথে

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

  উদাহরণস্বরূপ, কল্পনা করুন যে আপনি AWS কে একটি EC2 সার্ভার তৈরি করতে বলে একটি API কল করছেন। API সার্ভার নিজেই তৈরি হওয়ার জন্য অপেক্ষা না করে প্রায় সঙ্গে সঙ্গে একটি "সফল" প্রতিক্রিয়া (201 তৈরি) ফিরিয়ে দেবে। আপনি যদি এখনই এটির সাথে সংযোগ করার চেষ্টা করেন তবে এটি প্রায় অবশ্যই ব্যর্থ হবে কারণ সেই সময়ে AWS এখনও সংস্থান শুরু করছে বা বিকল্পভাবে, সার্ভারটি এখনও বুট হয়নি। তাছাড়া, আপনি যদি এই সার্ভার সম্পর্কে তথ্য পেতে অন্য কল করেন, তাহলে আপনি একটি ত্রুটি পেতে পারেন (404 পাওয়া যায়নি)। জিনিসটি হল যে এই EC2 সার্ভার সম্পর্কে তথ্যটি এখনও AWS জুড়ে প্রচারিত হতে পারে এটি সর্বত্র উপলব্ধ হওয়ার আগে, আপনাকে কয়েক সেকেন্ড অপেক্ষা করতে হবে।

  যখনই আপনি অলস সামঞ্জস্যের সাথে একটি অ্যাসিঙ্ক্রোনাস API ব্যবহার করেন, আপনাকে অবশ্যই পর্যায়ক্রমে আপনার অনুরোধটি পুনরায় চেষ্টা করতে হবে যতক্ষণ না কাজটি সম্পূর্ণ হয় এবং সিস্টেমের মাধ্যমে প্রচার না হয়। দুর্ভাগ্যবশত, AWS SDK এর জন্য কোন ভালো টুল প্রদান করে না এবং Terraform প্রজেক্টটি 6813 (https://github.com/hashicorp/terraform/issues/6813) এর মতো অনেক বাগ থেকে ভুগছিল:

  $ terraform apply
  aws_subnet.private-persistence.2: InvalidSubnetID.NotFound:
  The subnet ID 'subnet-xxxxxxx' does not exist

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

  এই অংশটি Evgeniy Brikman এর বই থেকে উপস্থাপন করা হয়েছে "টেরাফর্ম: কোড লেভেলে অবকাঠামো".

উত্স: www.habr.com