ટેરાફોર્મ મુશ્કેલીઓ

ચાલો લૂપ્સ, જો નિવેદનો અને જમાવટ તકનીકો, તેમજ સામાન્ય રીતે ટેરાફોર્મને અસર કરતા વધુ સામાન્ય મુદ્દાઓ સહિત, કેટલીક મુશ્કેલીઓને પ્રકાશિત કરીએ:

• ગણતરી અને for_each પરિમાણોની મર્યાદાઓ છે;
• શૂન્ય ડાઉનટાઇમ જમાવટને મર્યાદિત કરો;
• સારી યોજના પણ નિષ્ફળ થઈ શકે છે;
• રિફેક્ટરિંગમાં તેની મુશ્કેલીઓ હોઈ શકે છે;
• વિલંબિત સુસંગતતા સુસંગત છે... સ્થગિત સાથે.

ગણતરી અને for_each પરિમાણોની મર્યાદાઓ છે

આ પ્રકરણના ઉદાહરણો લૂપ્સ અને શરતી તર્કમાં કાઉન્ટ પેરામીટર અને for_each અભિવ્યક્તિનો વ્યાપક ઉપયોગ કરે છે. તેઓ સારું પ્રદર્શન કરે છે, પરંતુ તેમની પાસે બે મહત્વપૂર્ણ મર્યાદાઓ છે જેના વિશે તમારે જાગૃત રહેવાની જરૂર છે.

• કાઉન્ટ અને ફોર_એચ કોઈપણ સંસાધન આઉટપુટ ચલોનો સંદર્ભ આપી શકતા નથી.
• ગણતરી અને for_each નો ઉપયોગ મોડ્યુલ રૂપરેખાંકનમાં કરી શકાતો નથી.

ગણતરી અને 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 એ શાબ્દિક, ચલો, ડેટા સ્ત્રોતો અને સંસાધન સૂચિનો પણ સંદર્ભ લઈ શકે છે (જ્યાં સુધી તેમની લંબાઈ શેડ્યુલિંગ સમયે નક્કી કરી શકાય છે), પરંતુ ગણતરી કરેલ સંસાધન આઉટપુટ ચલોનો નહીં.

ગણતરી અને 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.

કમનસીબે, ટેરાફોર્મ 0.12.6 મુજબ, મોડ્યુલ સંસાધનમાં ગણતરી અથવા for_each નો ઉપયોગ સપોર્ટ કરતું નથી. ટેરાફોર્મ 0.12 રીલીઝ નોટ્સ (http://bit.ly/3257bv4) મુજબ, HashiCorp ભવિષ્યમાં આ ક્ષમતા ઉમેરવાની યોજના ધરાવે છે, તેથી તમે આ પુસ્તક ક્યારે વાંચશો તેના આધારે, તે પહેલેથી જ ઉપલબ્ધ હોઈ શકે છે. ખાતરી માટે શોધવા માટે, ટેરાફોર્મ ચેન્જલોગ અહીં વાંચો.

શૂન્ય ડાઉનટાઇમ જમાવટની મર્યાદાઓ

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 દાખલા હંમેશા હાલના ટેરાફોર્મ કોડની સમાન ક્ષમતા પર ચાલશે અને તેને જાળવવાનું વધુ મુશ્કેલ બનાવે છે.

અલબત્ત, ટેરાફોર્મ આદર્શ રીતે શૂન્ય-ડાઉનટાઇમ જમાવટ માટે બિલ્ટ-ઇન સપોર્ટ ધરાવશે, પરંતુ મે 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 વપરાશકર્તાઓ માટે જ નહીં, પરંતુ લગભગ કોઈપણ સંસાધન માટે થઈ શકે છે. શક્ય છે કે કોઈએ આ સંસાધન મેન્યુઅલી બનાવ્યું હોય અથવા કમાન્ડ લાઇનનો ઉપયોગ કર્યો હોય, પરંતુ કોઈપણ રીતે, મેળ ખાતા ID તકરાર તરફ દોરી જાય છે. આ ભૂલની ઘણી ભિન્નતાઓ છે જે ઘણીવાર ટેરાફોર્મમાં નવા આવનારાઓને આશ્ચર્યચકિત કરે છે.

મુખ્ય મુદ્દો એ છે કે ટેરાફોર્મ પ્લાન કમાન્ડ ફક્ત તે સંસાધનોને ધ્યાનમાં લે છે જે ટેરાફોર્મ સ્ટેટ ફાઇલમાં ઉલ્લેખિત છે. જો સંસાધનો કોઈ અન્ય રીતે બનાવવામાં આવ્યા હોય (ઉદાહરણ તરીકે, AWS કન્સોલમાં મેન્યુઅલી ક્લિક કરીને), તો તે સ્ટેટ ફાઇલમાં સમાપ્ત થશે નહીં અને તેથી પ્લાન આદેશનો અમલ કરતી વખતે ટેરાફોર્મ તેમને ધ્યાનમાં લેશે નહીં. પરિણામે, પ્રથમ નજરે સાચી લાગતી યોજના અસફળ સાબિત થશે.

આમાંથી બે પાઠ શીખવા જેવા છે.

• જો તમે પહેલાથી જ ટેરાફોર્મ સાથે કામ કરવાનું શરૂ કર્યું હોય, તો બીજું કંઈપણ વાપરશો નહીં. જો તમારા ઈન્ફ્રાસ્ટ્રક્ચરનો ભાગ ટેરાફોર્મનો ઉપયોગ કરીને મેનેજ કરવામાં આવે છે, તો તમે તેને મેન્યુઅલી સંશોધિત કરી શકશો નહીં. નહિંતર, તમે માત્ર વિચિત્ર ટેરાફોર્મ ભૂલોનું જોખમ લેતા નથી, પરંતુ તમે IaC ના ઘણા ફાયદાઓને પણ નકારી શકો છો કારણ કે કોડ હવે તમારા ઇન્ફ્રાસ્ટ્રક્ચરનું ચોક્કસ પ્રતિનિધિત્વ રહેશે નહીં.
• જો તમારી પાસે પહેલેથી જ કેટલીક ઈન્ફ્રાસ્ટ્રક્ચર છે, તો આયાત આદેશનો ઉપયોગ કરો. જો તમે હાલના ઈન્ફ્રાસ્ટ્રક્ચર સાથે ટેરાફોર્મનો ઉપયોગ કરવાનું શરૂ કરી રહ્યા છો, તો તમે ટેરાફોર્મ આયાત આદેશનો ઉપયોગ કરીને તેને સ્ટેટ ફાઇલમાં ઉમેરી શકો છો. આ રીતે ટેરાફોર્મ જાણશે કે કઈ ઈન્ફ્રાસ્ટ્રક્ચરનું સંચાલન કરવાની જરૂર છે. આયાત આદેશ બે દલીલો લે છે. પ્રથમ તમારી રૂપરેખાંકન ફાઇલોમાં સંસાધન સરનામું છે. અહીંની વાક્યરચના સંસાધન લિંક્સ જેવી જ છે: _. (જેમ કે aws_iam_user.existing_user). બીજી દલીલ આયાત કરવાના સંસાધનનું ID છે. ચાલો કહીએ કે સંસાધન ID aws_iam_user એ વપરાશકર્તા નામ છે (ઉદાહરણ તરીકે, yevgeniy.brikman), અને સંસાધન ID aws_instance એ EC2 સર્વર ID છે (જેમ કે i-190e22e5). સંસાધનને કેવી રીતે આયાત કરવું તે સામાન્ય રીતે તેના પૃષ્ઠના તળિયે દસ્તાવેજીકરણમાં સૂચવવામાં આવે છે.

  નીચે એક આયાત આદેશ છે જે aws_iam_user સંસાધનને સમન્વયિત કરે છે જે તમે પ્રકરણ 2 માં IAM વપરાશકર્તા સાથે તમારા ટેરાફોર્મ રૂપરેખાંકનમાં ઉમેર્યું છે (અલબત્ત, yevgeniy.brikman માટે તમારું નામ બદલીને):

  $ terraform import aws_iam_user.existing_user yevgeniy.brikman

  Terraform તમારા IAM વપરાશકર્તાને શોધવા માટે AWS API ને કૉલ કરશે અને તમારી Terraform રૂપરેખાંકનમાં તેની અને aws_iam_user.existing_user રિસોર્સ વચ્ચે સ્ટેટ ફાઇલ એસોસિએશન બનાવશે. હવેથી, જ્યારે તમે પ્લાન કમાન્ડ ચલાવો છો, ત્યારે ટેરાફોર્મ જાણશે કે IAM વપરાશકર્તા પહેલેથી જ અસ્તિત્વમાં છે અને તેને ફરીથી બનાવવાનો પ્રયાસ કરશે નહીં.

  એ નોંધવું યોગ્ય છે કે જો તમારી પાસે પહેલાથી જ ઘણા બધા સંસાધનો હોય કે જેને તમે ટેરાફોર્મમાં આયાત કરવા માંગો છો, તો મેન્યુઅલી કોડ લખવા અને દરેક એકને એક સમયે આયાત કરવું એ મુશ્કેલી બની શકે છે. તેથી તે ટેરાફોર્મિંગ (http://terraforming.dtan4.net/) જેવા ટૂલમાં જોવા યોગ્ય છે, જે આપમેળે તમારા AWS એકાઉન્ટમાંથી કોડ અને સ્ટેટને આયાત કરી શકે છે.

  રિફેક્ટરિંગમાં તેની મુશ્કેલીઓ હોઈ શકે છે

  રિફૅક્ટરિંગ પ્રોગ્રામિંગમાં એક સામાન્ય પ્રથા છે જ્યાં તમે બાહ્ય વર્તનને યથાવત રાખીને કોડની આંતરિક રચનામાં ફેરફાર કરો છો. આ કોડને વધુ સ્પષ્ટ, સુઘડ અને જાળવવામાં સરળ બનાવવા માટે છે. રિફેક્ટરિંગ એ એક અનિવાર્ય તકનીક છે જેનો નિયમિત ઉપયોગ થવો જોઈએ. પરંતુ જ્યારે ટેરાફોર્મ અથવા અન્ય કોઈપણ IaC ટૂલની વાત આવે છે, ત્યારે તમારે કોડના ભાગની "બાહ્ય વર્તણૂક" દ્વારા તમારો અર્થ શું છે તે વિશે અત્યંત સાવચેત રહેવું જોઈએ, અન્યથા અણધારી સમસ્યાઓ ઊભી થશે.

  ઉદાહરણ તરીકે, એક સામાન્ય પ્રકારનું રિફેક્ટરિંગ એ વેરિયેબલ અથવા ફંક્શનના નામોને વધુ સમજી શકાય તેવા નામો સાથે બદલવાનું છે. ઘણા IDE માં રિફેક્ટરિંગ માટે બિલ્ટ-ઇન સપોર્ટ હોય છે અને સમગ્ર પ્રોજેક્ટ દરમિયાન વેરિયેબલ્સ અને ફંક્શન્સનું નામ આપોઆપ બદલી શકે છે. સામાન્ય હેતુવાળી પ્રોગ્રામિંગ ભાષાઓમાં, આ એક તુચ્છ પ્રક્રિયા છે જેના વિશે તમે કદાચ વિચારી પણ ન શકો, પરંતુ ટેરાફોર્મમાં તમારે આ બાબતે ખૂબ કાળજી રાખવી પડશે, અન્યથા તમે આઉટેજ અનુભવી શકો છો.

  ઉદાહરણ તરીકે, વેબસર્વર-ક્લસ્ટર મોડ્યુલમાં ઇનપુટ ચલ cluster_name છે:

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

  કલ્પના કરો કે તમે આ મોડ્યુલનો ઉપયોગ foo નામની માઇક્રોસર્વિસ જમાવવા માટે શરૂ કર્યો છે. બાદમાં, તમે તમારી સેવાનું નામ બદલીને બાર કરવા માંગો છો. આ ફેરફાર મામૂલી લાગે છે, પરંતુ વાસ્તવમાં તે સેવામાં વિક્ષેપ પેદા કરી શકે છે.

  હકીકત એ છે કે વેબસર્વર-ક્લસ્ટર મોડ્યુલ સંખ્યાબંધ સંસાધનોમાં ક્લસ્ટર_નામ વેરીએબલનો ઉપયોગ કરે છે, જેમાં બે સુરક્ષા જૂથોના નામ પરિમાણ અને એએલબીનો સમાવેશ થાય છે:

  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]
  }

  જો તમે સંસાધન પર નામ પરિમાણ બદલો છો, તો ટેરાફોર્મ તે સંસાધનનું જૂનું સંસ્કરણ કાઢી નાખશે અને તેની જગ્યાએ એક નવું બનાવશે. પરંતુ જો તે સંસાધન એક ALB છે, તો તેને કાઢી નાખવા અને નવું સંસ્કરણ ડાઉનલોડ કરવા વચ્ચે, તમારી પાસે તમારા વેબ સર્વર પર ટ્રાફિકને રીડાયરેક્ટ કરવાની કોઈ પદ્ધતિ નથી. તેવી જ રીતે, જો કોઈ સુરક્ષા જૂથ કાઢી નાખવામાં આવે છે, તો તમારું સર્વર નવું જૂથ ન બને ત્યાં સુધી કોઈપણ નેટવર્ક ટ્રાફિકને નકારવાનું શરૂ કરશે.

  અન્ય પ્રકારનું રિફેક્ટરિંગ તમને રસ હોઈ શકે છે તે ટેરાફોર્મ ID ને બદલવું છે. ચાલો વેબસર્વર-ક્લસ્ટર મોડ્યુલમાં aws_security_group સંસાધનને ઉદાહરણ તરીકે લઈએ:

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

  આ સંસાધનના ઓળખકર્તાને ઉદાહરણ કહેવામાં આવે છે. કલ્પના કરો કે રિફેક્ટરિંગ દરમિયાન તમે તેને વધુ સમજી શકાય તેવા (તમારા મતે) નામ ક્લસ્ટર_ઇન્સ્ટન્સમાં બદલવાનું નક્કી કર્યું છે:

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

  અંતે શું થશે? તે સાચું છે: એક વિક્ષેપ.

  ટેરાફોર્મ દરેક સંસાધન ID ને ક્લાઉડ પ્રદાતા ID સાથે સાંકળે છે. ઉદાહરણ તરીકે, iam_user એ AWS IAM વપરાશકર્તા ID સાથે સંકળાયેલ છે, અને aws_instance એ AWS EC2 સર્વર ID સાથે સંકળાયેલ છે. જો તમે સંસાધન ID (ઉદાહરણથી ક્લસ્ટર_ઇન્સ્ટન્સમાં કહો, જેમ કે aws_security_group સાથે કેસ છે) બદલો છો, તો તે ટેરાફોર્મમાં દેખાશે કે તમે જૂના સંસાધનને કાઢી નાખ્યું હોય અને નવું ઉમેર્યું હોય. જો તમે આ ફેરફારો લાગુ કરો છો, તો Terraform જૂના સુરક્ષા જૂથને કાઢી નાખશે અને એક નવું બનાવશે, જ્યારે તમારા સર્વર્સ કોઈપણ નેટવર્ક ટ્રાફિકને નકારવાનું શરૂ કરશે.

  અહીં ચાર મુખ્ય પાઠ છે જે તમારે આ ચર્ચામાંથી દૂર કરવા જોઈએ.

  • હંમેશા પ્લાન આદેશનો ઉપયોગ કરો. તે આ તમામ snags જાહેર કરી શકે છે. તેના આઉટપુટની કાળજીપૂર્વક સમીક્ષા કરો અને એવી પરિસ્થિતિઓ પર ધ્યાન આપો જ્યાં ટેરાફોર્મ સંસાધનોને કાઢી નાખવાની યોજના ધરાવે છે જે મોટાભાગે કાઢી નાખવામાં ન આવે.
  • તમે કાઢી નાખો તે પહેલાં બનાવો. જો તમે સંસાધનને બદલવા માંગતા હો, તો મૂળ કાઢી નાખતા પહેલા તમારે રિપ્લેસમેન્ટ બનાવવાની જરૂર છે કે કેમ તે વિશે કાળજીપૂર્વક વિચારો. જો જવાબ હા હોય, તો create_before_destroy મદદ કરી શકે છે. સમાન પરિણામ બે પગલાંઓ કરીને જાતે જ પ્રાપ્ત કરી શકાય છે: પહેલા રૂપરેખાંકનમાં એક નવું સંસાધન ઉમેરો અને લાગુ કરો આદેશ ચલાવો, અને પછી રૂપરેખાંકનમાંથી જૂના સંસાધનને દૂર કરો અને ફરીથી લાગુ કરો આદેશનો ઉપયોગ કરો.
  • ઓળખકર્તા બદલવા માટે સ્થિતિ બદલવી જરૂરી છે. જો તમે સંસાધનને કાઢી નાખ્યા વિના અને તેનું નવું સંસ્કરણ બનાવ્યા વિના સંસાધન સાથે સંકળાયેલ ID (ઉદાહરણ તરીકે, aws_security_groupનું નામ બદલીને ક્લસ્ટર_instance કરો) બદલવા માંગો છો, તો તમારે તે મુજબ ટેરાફોર્મ સ્ટેટ ફાઇલ અપડેટ કરવી પડશે. આ જાતે ક્યારેય કરશો નહીં - તેના બદલે ટેરાફોર્મ સ્ટેટ આદેશનો ઉપયોગ કરો. ઓળખકર્તાઓનું નામ બદલતી વખતે, તમારે ટેરાફોર્મ સ્ટેટ એમવી આદેશ ચલાવવો જોઈએ, જેમાં નીચેનો વાક્યરચના છે:

    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 સાથે સંકળાયેલું હોવું જોઈએ. જો આ આદેશનું નામ બદલ્યા પછી અને ચલાવ્યા પછી ટેરાફોર્મ પ્લાન કોઈ ફેરફારો બતાવતું નથી, તો તમે બધું બરાબર કર્યું છે.

  • કેટલીક સેટિંગ્સ બદલી શકાતી નથી. ઘણા સંસાધનોના પરિમાણો અપરિવર્તનશીલ છે. જો તમે તેમને બદલવાનો પ્રયાસ કરો છો, તો Terraform જૂના સંસાધનને કાઢી નાખશે અને તેની જગ્યાએ એક નવું બનાવશે. દરેક સંસાધન પૃષ્ઠ સામાન્ય રીતે સૂચવે છે કે જ્યારે તમે કોઈ ચોક્કસ સેટિંગ બદલો ત્યારે શું થાય છે, તેથી દસ્તાવેજીકરણ તપાસવાની ખાતરી કરો. હંમેશા પ્લાન આદેશનો ઉપયોગ કરો અને create_before_destroy વ્યૂહરચનાનો ઉપયોગ કરવાનું વિચારો.

  વિલંબિત સુસંગતતા સુસંગત છે... સ્થગિત સાથે

  કેટલાક ક્લાઉડ પ્રદાતાઓના API, જેમ કે AWS, એસિંક્રોનસ છે અને તેમાં વિલંબિત સુસંગતતા છે. અસિંક્રોનો અર્થ એ છે કે ઇન્ટરફેસ વિનંતી કરેલ ક્રિયા પૂર્ણ થવાની રાહ જોયા વિના તરત જ પ્રતિસાદ આપી શકે છે. વિલંબિત સુસંગતતાનો અર્થ એ છે કે ફેરફારોને સમગ્ર સિસ્ટમમાં ફેલાવવામાં સમય લાગી શકે છે; જ્યારે આ થઈ રહ્યું છે, ત્યારે તમારા પ્રતિસાદો અસંગત હોઈ શકે છે અને તમારા API કૉલ્સને કયા ડેટા સ્ત્રોતની પ્રતિકૃતિ પ્રતિભાવ આપી રહી છે તેના પર નિર્ભર હોઈ શકે છે.

  ઉદાહરણ તરીકે, કલ્પના કરો કે તમે AWS ને EC2 સર્વર બનાવવા માટે કહીને API કૉલ કરો છો. API સર્વર પોતે જ બને તેની રાહ જોયા વિના, લગભગ તરત જ "સફળ" પ્રતિસાદ (201 બનાવાયેલ) આપશે. જો તમે તેને તરત જ કનેક્ટ કરવાનો પ્રયાસ કરો છો, તો તે લગભગ ચોક્કસપણે નિષ્ફળ જશે કારણ કે તે સમયે AWS હજુ પણ સંસાધનો શરૂ કરી રહ્યું છે અથવા, વૈકલ્પિક રીતે, સર્વર હજુ સુધી બુટ થયું નથી. વધુમાં, જો તમે આ સર્વર વિશે માહિતી મેળવવા માટે બીજો કૉલ કરો છો, તો તમને એક ભૂલ (404 મળી નથી) પ્રાપ્ત થઈ શકે છે. વાત એ છે કે આ EC2 સર્વર વિશેની માહિતી હજી પણ AWS માં પ્રચારિત થઈ શકે છે તે પહેલાં તે સર્વત્ર ઉપલબ્ધ થાય તે પહેલાં, તમારે થોડી સેકંડ રાહ જોવી પડશે.

  જ્યારે પણ તમે સુસ્ત સુસંગતતા સાથે અસુમેળ API નો ઉપયોગ કરો છો, ત્યારે તમારે સમયાંતરે તમારી વિનંતીનો ફરીથી પ્રયાસ કરવો જોઈએ જ્યાં સુધી ક્રિયા પૂર્ણ ન થાય અને સિસ્ટમ દ્વારા પ્રચાર ન થાય. કમનસીબે, AWS SDK આ માટે કોઈ સારા સાધનો પ્રદાન કરતું નથી, અને ટેરાફોર્મ પ્રોજેક્ટ 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

  બીજા શબ્દોમાં કહીએ તો, તમે સંસાધન બનાવો (જેમ કે સબનેટ) અને પછી તેના વિશે કેટલીક માહિતી મેળવવાનો પ્રયાસ કરો (જેમ કે નવા બનાવેલા સબનેટનું ID), અને ટેરાફોર્મ તેને શોધી શકતું નથી. આમાંની મોટાભાગની ભૂલો (6813 સહિત) ઠીક કરવામાં આવી છે, પરંતુ તે હજુ પણ સમય સમય પર પાકતી રહે છે, ખાસ કરીને જ્યારે ટેરાફોર્મ નવા સંસાધન પ્રકાર માટે સમર્થન ઉમેરે છે. આ હેરાન કરે છે, પરંતુ મોટાભાગના કિસ્સાઓમાં કોઈ નુકસાન થતું નથી. જ્યારે તમે ટેરાફોર્મ એપ્લાય ફરીથી ચલાવો છો, ત્યારે બધું કામ કરવું જોઈએ, કારણ કે આ સમય સુધીમાં માહિતી સમગ્ર સિસ્ટમમાં ફેલાઈ ગઈ હશે.

  આ અવતરણ Evgeniy Brikman દ્વારા પુસ્તકમાંથી રજૂ કરવામાં આવ્યું છે "ટેરાફોર્મ: કોડ લેવલ પર ઇન્ફ્રાસ્ટ્રક્ચર".

સોર્સ: www.habr.com