כמומחה בתחום התוכנה המטפל בתשתית כקוד (IaC), סביר להניח שאתה עובד הרבה עם Terraform. כאשר אתה עוזר ללקוחות חדשים להשתמש ב-IaC, זה נפוץ לפשט דברים, אך ניהול קובץ מצב Terraform הוא האתגר הראשון שאתה נתקל בו. בעצם, מצב Terraform מכיל מידע רגיש, שלא צריך לאחסן על ידי שיטת בקרת גישה, אבל באותו זמן, לא יתרומם אם יש לך מספר משתמשים שעובדים על אותו מצב Terraform. התשובה לכך? מאחסנים.
חשוב לציין שאפשר לאחסן את קובץ המצב הזה בפחית S3 ולהשתמש ב-DynamoDB לניהול המצב הנעילה. עם זאת, גישה זו תאלץ אותך ליצור משאבים נוספים, מה שהופך אותה לאפשרות מורכבת, במיוחד אם הלקוח משתמש ב-GitLab. GitLab לאחרונה הוריד את מחסום הכניסה לשילוב Terraform על ידי מתן דרך לאחסן ולנהל את מצב Terraform, כמו גם דרך קלה להקמת CI סביב זה.
במאמר זה, נסביר מהו קובץ מצב Terraform, איך להעביר אותו ל-GitLab, ולהקים קו תעבורה CI עבורו. אתה יכול לבקר במאגר שלנו כאן.
תוכן העניינים
- מהו מצב Terraform?
- איך לגרום ל-GitLab לנהל את מצב Terraform
- איך לגרום ל-GitLab להריץ את ה-IaC שלך דרך קו תעבורה CI
- טיפ נוסף: Infracost
- סיכום
מהו מצב Terraform?
Terraform מקליד מידע כלשהו על התשתית המוגדרת בקוד שלך באמצעות קובץ מצב. כתוב ב-JSON, הוא בעצם מקליד התאמה מהקוד של Terraform למשאבים האמיתיים שנוצרו. להלן דוגמה למה terraform.tfstate
יראה כמו. בעיקרון, בכל פעם שאתה מריץ את Terraform הוא ישאב את המצב העדכני ביותר עבור ה-EC2 instance שלו ויבדוק אותו עם הconfiguration של 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 לניהול ה-IaC שלנו.
למאמר זה, אנו מניחים שאתה משתמש במצב מקומי ושמצבך מנוהל עם חסימת S3 ב-AWS או עם פתרון מאחסן אחר.
ראשית, תצטרך לשנות את backend.tf
שלך להשתמש ב-HTTP:
terraform {
backend "http" {}
}
לאחר מכן, תצטרך להגדיר ארבעה משתנים במסוף שלך:
1. PROJECT_ID
: אתה יכול למצוא את זה בקלות על ידי גישה למאגר שלך בדף "סקירת פרויקט".
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
תצטרך לספק אישור על ידי "כן" כך ש-GitLab יוכל להתחיל לנהל את קובץ המצב שלך. הנה דוגמה ממצב מקומי ל-GitLab:
דוגמת S3 ל-GitLab:

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 להריץ את IaC שלך דרך קו ספירת CI
GitLab מספק תמונת Docker המכילה GitLab-Terraform, שהיא תכנית עיטוף דקה סביב הבינארי הרשמי של Terraform. כפול כן, ניתן להשתמש בתמונת Docker הרשמית של Hashicorp. תוכל למצוא מידע נוסף על תמונת GitLab Terraform כאן.
ברגע שהפעלת Terraform פועלת, תוכל לראות מתי נמצא בשימוש ועם איזה קו ספירה.
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, שמאפשר לנו שליטה רבה יותר על חשבון הענן שלנו מאחר שהוא מעניק הערכת עלות כל פעם שמגדירים משאב חדש לIaC שלך.
סיכום
בעזרת מצב Terraform שלך והCI שמתקיים ב-GitLab ניתן לעקוב אחרי טיפוסי GitOps המצטיינים. שניהם משתלבים טובות מאוד כדי לפתח ולבצע פריסת IaC. מאחר ורובכם כנראה כבר משתמשים ב-GitLab עבור המאגרים שלכם, נהיה פשוט יותר לשמור את IaC שלכם תחת גג אחד ולתת ל-GitLab לנהל את מצב Terraform שלכם על ידי תמיכה בהצפנה במרחב ובמדרון, כמו גם ברישום גירסאות, נעילה ופתיחת המצב.
Source:
https://dzone.com/articles/how-to-migrate-terraform-state-to-gitlab-cicd