كيفية تحويل حالة Terraform إلى GitLab CI/CD

الدروس التعليمية
AWS GitLab GraphQL

كما عالم برمجيات يتعامل مع بنية التطبيق كـ “شفرة البناء” (Infrastructure as Code – IaC)، من المحتمل أنك تعمل كثيرًا مع Terraform. عندما تساعد عملاء جدد في استخدام IaC، من الشائع تبسيط الأمور، لكن إدارة حافظة Terraform هي التحدي الأول الذي تواجهه. في الأساس، تحتوي حافظة Terraform على معلومات حساسة، والتي لا ينبغي تخزينها بواسطة نظام التحكم في المصادر، ولكن في نفس الوقت، لن تتصرف إذا كان لديك مستخدمون متعددون يعملون على نفس حافظة Terraform. الحل لذلك؟ الخلفيات.

من المهم أن نلاحظ أنه يمكنك تخزين تلك الحافظة في سلة ملفات S3 واستخدام DynamoDB لإدارة القفل الحالي. ومع ذلك، سيجبرك هذا النهج على إنشاء موارد إضافية، مما يجعله خيارًا معقدًا خاصة إذا كان العميل يستخدم GitLab. انخفضت GitLab مؤخرًا حاجز الدخول لدمج Terraform من خلال توفير طريقة لتخزين وإدارة حالة Terraform، وكذلك طريقة سهلة لإعداد CI حوله.

في هذا المقال، سنوضح ما هي حافظة Terraform، كيفية نقلها إلى GitLab، وإعداد خطوط الانتاج المستقلة لها. يمكنك زيارة مستودعنا هنا.

فهرس المحتويات

  • ما هي حافظة Terraform؟
  • كيفية الحصول على GitLab لإدارة حالة Terraform
  • كيفية الحصول على GitLab لتشغيل IaC الخاص بك من خلال خط CI
    • نصيحة إضافية: Infracost
  • الخاتمة

ما هي حافظة Terraform؟

تسجل Terraform أي معلومات حول البنية التحتية المحددة في رمزك عبر ملف الحالة. مكتوب بلغة JSON، يسجل بشكل أساسي تعيينًا من التعليمات البرمجية لـ Terraform إلى الموارد الحقيقية التي تم إنشاؤها. الآن إليك مثالًا على ما سيبدو عليه terraform.tfstate. بشكل أساسي، في كل مرة يتم فيها تشغيل Terraform سيجلب أحدث حالة لمثيل EC2 الخاص به ويقارنها مع تكوين Terraform الخاص بك لتحديد التغييرات التي تحتاج إلى تطبيقها:

  

{   
     "version": 4,    
     "terraform_version": "0.12.0",    
     "serial": 1,    
     "lineage": "1f2087f9-4b3c-1b66-65db-8b78faafc6fb",    
     "outputs": {},    
     "resources": [     
      {        
         "mode": "managed",        
         "type": "aws_instance",       
         "name": "example",       
         "provider": "provider.aws",       
         "instances": [         
           {           
             "schema_version": 1,           
             "attributes": {              
               "ami": "ami-0c55b159cbfafe1f0",             
               "availability_zone": "us-west-2a",             
               "id": "i-00a123a0accffffff",            
               "instance_state": "running",             
               "instance_type": "t2.micro",            
               "(...)": "(truncated)"           
            }         
          }       
        ]      
      }   
    ]  
 }

بشكل افتراضي، يتم تخزين هذا terraform.tfstate محليًا حيث لديك ملفات Terraform وخطط وتطبيق تغييراتك. بالنسبة لمشروع شخصي حيث تقوم فقط ببعض الاختبارات؛ هذا جيد، لكنه ليس الطريقة الموصى بها، وهنا السبب:

  • تخزين في موقع مشترك: إذا كنت تستضيف ملف الحالة هذا على جهاز الكمبيوتر المحلي وكان عليك العمل مع مهندس آخر، ستزداد الأمور تعقيدًا. يجب على كلاكما التأكد من استخدام أحدث نسخة من الحالة ويمكن أن تواجه حالات السباق إذا تم تشغيل خطط Terraform أو تطبيقات في نفس الوقت.
  • حماية المعلومات الحساسة: يمكن أن يحتوي ملف الحالة المولد على مفاتيح التشفير وكلمات سر البنية التحتية. ومع ذلك، لا يتم تشفير ملفات الحالة بشكل افتراضي، وتخزين المعلومات الحساسة في النص العادي هو فكرة سيئة.
  • القفل: لا تدعم معظم أنظمة التحكم الموردي أي شكل من القفل، مما يمنع عضوين من الفريق من تشغيل Terraform apply بشكل متزامن على نفس ملف الحالة. هذا سبب آخر لعدم رؤيتنا ملف الحالة المُدار بواسطة التحكم الموردي.

كيفية تحقيق تحكم GitLab في حالة Terraform

بما أن Terraform يعتبر المعيار في توفير البنية التحتية للغرض السحابية، كان هناك عام أو نحو ذلك منذ أن بدأ GitLab في تقديم طريقة لتخزين وإدارة حالة Terraform الخاصة بك. ولهذا السبب، أردنا مشاركة عملية الترحيل معك حيث بدأنا مؤخرًا استخدام GitLab لإدارة بنيتنا التحتية لأجهزة الكمبيوتر.

في هذا المقال، نفترض أنك تستخدم حالة محلية، ولديك حالتك المدارة مع خزانة AWS S3 أو حل آخر للخلفية. 

أولاً، ستحتاج إلى تغيير backend.tf الخاص بك لاستخدام HTTP: 

  

terraform {  
    backend "http" {} 
  }

بعد ذلك، ستحتاج إلى إعداد أربعة متغيرات في терمينالك:

1. PROJECT_ID: يمكنك العثور على هذا بسهولة عن طريق التنقل إلى مستودعك على صفحة “النظرة العامة”Project Overview.

2. TF_USERNAME: اسم المستخدم Gitlab الذي لديه حق الوصول إلى المستودع الذي تعمل عليه.

3. TF_PASSWORD: رمز المصادقة التي تم إنشاؤه من حساب مستخدم GitLab الخاص بك.

4. TF_ADDRESS: عنوان URL لخلفية الحالة البعيدة.

  

PROJECT_ID="28450092"
TF_USERNAME="florianpialoux"
TF_PASSWORD="123456789"
TF_ADDRESS="https://gitlab.com/api/v4/projects/${PROJECT_ID}/terraform/state/aws-buckets"

يمكنك الآن تشغيل أمر الترحيل الذي سينقل حالة Terraform الخاصة بك من مكانه السابق إلى GitLab باستخدام الأمر التالي:

  

  terraform init \  
    -migrate-state \  
    -backend-config=address=${TF_ADDRESS} \  
    -backend-config=lock_address=${TF_ADDRESS}/lock \ 
    -backend-config=unlock_address=${TF_ADDRESS}/lock \  
    -backend-config=username=${TF_USERNAME} \ 
    -backend-config=password=${TF_PASSWORD} \  
    -backend-config=lock_method=POST \ 
    -backend-config=unlock_method=DELETE \ 
    -backend-config=retry_wait_min=5

سيحتاج إلى توفير تأكيد من خلال “نعم”yes حتى يتمكن GitLab من البدء في إدارة حالة ملف الخاص بك. إليك مثال من حالة محلية إلى GitLab:


مثال S3 إلى GitLab:

Now, you can navigate to Infrastructure > Terraform from the GitLab interface and see your state:

I noticed for some of the state files I had from S3 will be blank even after using the migrate-state command ran previously. In this case, you can run this:  

  
terraform state pull > aws-buckets.json

انسخ والصق محتوى حالة S3 وقم بتشغيل دفع:

  
terraform state push -lock=true aws-buckets.json

تدعم GitLab تسجيل الإصدارات لملف حالة Terraform الخاص بك ولكن مشاهدة/استعادة الإصدارات السابقة من خلال واجهة المستخدم الإنترنت سيتطلب منك استخدام خطة GitLab Premium. إذا لم تكن كذلك، ستحتاج إلى إجراء طلب API GraphQL طلب.

كيف تجعل GitLab تعمل برمجتك الأساسية من خلال خطوط الإنتاج المستمرة

يوفر GitLab صورة Docker تحتوي على GitLab-Terraform، وهو سكريبت لفائف رقيق حول الباينري الرسمي لـ Terraform. بديلًا، يمكنك استخدام صورة Docker الرسمية من Hashicorp. يمكنك العثور على مزيد من المعلومات حول صورة GitLab Terraform هنا.

بمجرد تشغيل مهمة Terraform apply، ستتمكن من رؤية متى تم استخدام الحالة ومع أي خط الإنتاج.

Learn more about what our gitlab-ci.yml looks like here. Below, are the variables that will need to be defined on the project level.

نصيحة إضافية: Infracost

قد تكون قد لاحظت، بالنظر إلى gitlab-ci.yaml الخاص بنا، إضافة Infracost، والذي يتيح لنا الحصول على المزيد من السيطرة على فواتيرنا السحابية لأنه يمنحك تقديرًا للتكلفة كلما عرّفت موردًا جديدًا لبرمجتك الأساسية.

الخاتمة

توفير حالة Terraform الخاصة بك وتشغيل CI على Gitlab هو طريقة رائعة لمتابعة أفضل الممارسات في GitOps. كلاهما يجعل مزيجًا ممتازًا لتطوير ونشر IaC. نظرًا لأن معظمكم قد يكون قد استخدم بالفعل GitLab لمستودعاتكم، يصبح الأمر أبسط بكثير لديهم IaC تحت سقف واحد وترك GitLab إدارة حالة Terraform الخاصة بك عن طريق دعم التشفير في النقل وعند الراحة، وكذلك التعديل التسلسلي وقفل وفتح الحالة.

Source:
https://dzone.com/articles/how-to-migrate-terraform-state-to-gitlab-cicd