تمت ترجمة هذه الصفحة بواسطة Cloud Translation API‏.

دليل 101 حول Cloud Foundation

1. مقدّمة حول CFT 101

تاريخ التعديل الأخير: 11-02-2022

ما هي مجموعة أدوات Cloud Foundation؟

في الواقع، توفّر خدمة CFT نماذج حول أفضل الممارسات للبدء بسرعة في Google Cloud Platform. ستتعرّف في هذا البرنامج التعليمي على كيفية المساهمة في مجموعة أدوات Cloud Foundation.

المتطلبات

حساب على GitHub
Docker مثبّت على جهازك أو يستخدم Cloud Shell ( تثبيت على نظام التشغيل Mac أو تثبيت على نظام التشغيل Windows)
أداة تعديل الرموز لتعديل الرمز (مثال: Visual Studio Code)
الإلمام بأساسيات Git وGitHub
بعض الخبرة في استخدام Terraform والبنية الأساسية كتعليمة برمجية
إذن بمنح دور "مُنشئ المشروع" لحساب الخدمة
مؤسسة Google Cloud ومجلد اختبار وحساب فوترة

ما الذي ستنشئه

في هذا الدرس التطبيقي حول الترميز، ستتعلّم كيفية المساهمة في مجموعة أدوات Cloud Foundation (CFT).

وسوف تقوم بما يلي:

إعداد بيئة تطوير برامج للمساعدة في استخدام ملفات CFT
إضافة ميزة إلى وحدة CFT
إضافة اختبارات للميزة المُضافة
إجراء اختبارات التكامل في واجهة CFT
تنفيذ اختبارات الوبر
الالتزام بالرمز البرمجي إلى GitHub وإرسال طلب سحب (PR)

عليك تنفيذ كل الخطوات المذكورة أعلاه من خلال إضافة ميزة جديدة إلى وحدة CFT في Google Cloud Storage. ستضيف تصنيفًا باسم ""silly_label"" ستتم إضافته تلقائيًا إلى جميع الحِزم التي تم إنشاؤها من خلال وحدة GCS CFT. ستتمكن أيضًا من كتابة اختبارات للتحقق من صحة الميزة وضمان الدمج الكامل.

2. إعداد بيئة تطوير البرامج

ويمكنك استخدام Cloud Shell لأغراض التطوير إن أردت ذلك. إذا كنت لا تريد استخدام Cloud Shell للمساهمة في CFT، يمكنك إعداد بيئة التطوير على جهازك.

إعداد Git

يعتمد GitHub على نظام تحكّم في الإصدار مفتوح المصدر (VCS) يُسمى Git. يكون Git مسؤولاً عن كل العمليات المتعلّقة بـ GitHub والتي تحدث محليًا على جهازك أو Cloud Shell.

عند استخدام Cloud Shell، لن تحتاج إلى تثبيت git وذلك لأنه مثبَّت مسبقًا.

$ git --version
# This will display the git version on the Cloud Shell.

إذا كنت تقوم بإعداد بيئة مطوري البرامج على جهازك، فأنت بحاجة إلى تثبيت Git.

ضبط اسم المستخدم وعنوان البريد الإلكتروني في Git

تستخدم Git اسم مستخدم لربط عمليات الإتمام بهوية. اسم مستخدم Git ليس مطابقًا لاسم مستخدم GitHub.

يمكنك تغيير الاسم المرتبط بـ Git باستخدام الأمر git config. إنّ تغيير الاسم المرتبط بـ Git الذي يلتزم به باستخدام git config سيؤثر فقط في التزاماتك المستقبلية ولن يؤدي إلى تغيير الاسم المستخدَم في عمليات الربط السابقة.

لقد أعددت Git بنجاح وستتمكن من إنشاء فروع وإنشائها واستنساخها. سنستخدم Git على نطاق واسع في هذا الدرس التطبيقي حول الترميز.

3- مستودع GCS الخاص بـ Fork CFT

إنشاء مستودع CFT

في الخطوة السابقة، يمكنك إعداد Git على جهازك المحلي أو Cloud Shell. عليك الآن إرسال مستودع CFT إلى Google Cloud Storage لبدء المساهمة.

الشوكة هي نسخة من مستودع. يتيح لك تشعب المستودع تجربة التغييرات بحرية دون التأثير على المشروع الأصلي.

الأكثر شيوعًا، تُستخدم الشوك إما لاقتراح تغييرات على مشروع شخص آخر أو لاستخدام مشروع شخص آخر كنقطة بداية لفكرتك الخاصة.

على سبيل المثال، يمكنك استخدام الشوك لاقتراح تغييرات تتعلق بإصلاح الأخطاء. لإصلاح خطأ، يمكنك إجراء ما يلي:

إرسال نسخة من المستودع.
إصلاح المشكلة.
أرسل طلب سحب إلى مالك المشروع.

خطوات إنشاء مستودع CFT:

افتح متصفّح الويب وانتقِل إلى مستودع terraform-google-modules/terraform-google-cloud-storage. سنستخدم هذا المستودع للدرس التطبيقي حول الترميز بالكامل.
في أعلى يسار الصفحة، انقر على شوكة.

سيظهر لك خيار تحديد المكان الذي تريد الحصول على معلومات فيه، واختَر ملفك الشخصي، وسيتم تقسيم بيانات المستودع.

استنساخ شوكتك محليًا

الشوكة التي أنشأتها هي نسخة من مستودع وحدات GCS. وستنسخ الآن هذا المستودع إلى بيئتك المحلية لإضافة ميزتك الجديدة.

خطوات استنساخ شوكتك:

افتح متصفّح الويب وانتقِل إلى الشكل على terraform-google-modules/terraform-google-cloud-storage.
في أعلى يسار الشاشة، ستجد "Code" (الرمز). انقر فوقه.

بعد النقر على "المدونة" انقر على الزر "نسخ" لنسخ عنوان URL للشوكة. ستستخدم عنوان URL هذا لاستنساخ شوكتك إلى بيئتك المحلية.

انتقِل إلى نافذة طرفية في VSCode أو في جهازك واستنساخ الشوكة.

$ git clone <url>
# This command will clone your fork locally.
# Paste the copied URL from the previous step.

الآن بعد أن استنسخت شوكتك محليًا، يجب عليك الانتقال إلى مستودعك، وإنشاء فرع جديد من الشوكة وإجراء تغييرات على التعليمات البرمجية للفرع المؤقت.

حسب الاصطلاح، يمكنك تسمية الفرع على النحو التالي:

لطلبات الميزات: feature/feature-name
للحصول على التحديثات الداخلية، internal/change-name
لإصلاح الأخطاء: bugfix/issue-name

بما أنّك تضيف ميزة جديدة، يمكنك الاتصال بفرعك المؤقت feature/silly_label

$ cd terraform-google-cloud-storage
# This command takes you into the cloned directory on your local machine.

$ git branch
# This command tells your current branch
# When you run this for the first time after you have cloned, your 
# output should say "master", that is your fork.

$ git checkout -b feature/silly_label
# This command creates a new branch on your fork and switches your 
# branch to the newly created branch.

$ git branch
# This command will confirm your current branch to be "feature/silly_label"

أصبحت جاهزًا الآن لبدء العمل على مجموعة أدوات Cloud Foundation.

4. إنشاء بيئة اختبار

تعتمد عملية تطوير CFT العادية على استخدام مشروع اختباري معزول للاختبار. سترشدك هذه الخطوة خلال إنشاء المشروع التجريبي (استنادًا إلى الإعدادات العادية) عبر حساب الخدمة.

0. تثبيت Docker Engine

إذا كنت تستخدم جهازك لأغراض التطوير، عليك تثبيت Docker Engine.

1. تثبيت حزمة Google Cloud SDK

لن تحتاج إلى تثبيت Google Cloud SDK إذا كنت تستخدم Cloud Shell على Google Cloud Platform.

انتقِل إلى Google Cloud SDK ونزِّل أداة التثبيت التفاعلية لنظامك الأساسي.

2. ضبط الإعدادات

لإنشاء بيئة اختبار، ستحتاج إلى مؤسسة Google Cloud ومجلد اختبار وحساب فوترة. يجب ضبط هذه القيم عبر متغيرات البيئة:

export TF_VAR_org_id="your_org_id"
export TF_VAR_folder_id="your_folder_id"
export TF_VAR_billing_account="your_billing_account_id"

3. إعداد حساب الخدمة

قبل إنشاء بيئة اختبار، عليك تنزيل مفتاح حساب الخدمة إلى بيئة الاختبار. سيتطلب حساب الخدمة هذا أدوار مُنشئ المشروع، ومستخدم حساب الفوترة، ومُشاهد المؤسسة. تساعدك هذه الخطوات في إنشاء حساب خدمة جديد، ولكن يمكنك أيضًا إعادة استخدام حساب حالي.

3.1 إنشاء مشروع أوّلي في Google Cloud Platform أو اختياره

قبل إنشاء حساب الخدمة، يجب اختيار مشروع لاستضافتها فيه. يمكنك أيضًا إنشاء مشروع جديد.

gcloud config set core/project YOUR_PROJECT_ID

3.2 تفعيل Google Cloud APIs

فعِّل واجهات Google Cloud API التالية في مشروعك الأساسي:

gcloud services enable cloudresourcemanager.googleapis.com
gcloud services enable iam.googleapis.com
gcloud services enable cloudbilling.googleapis.com

3.3 إنشاء حساب الخدمة

أنشئ حساب خدمة جديدًا لإدارة بيئة الاختبار:

# Creating a service account for CFT.
gcloud iam service-accounts create cft-onboarding \
  --description="CFT Onboarding Terraform Service Account" \
  --display-name="CFT Onboarding"

# Assign SERVICE_ACCOUNT environment variable for later steps
export SERVICE_ACCOUNT=cft-onboarding@$(gcloud config get-value core/project).iam.gserviceaccount.com

تأكَّد من إنشاء حساب الخدمة:

gcloud iam service-accounts list --filter="EMAIL=${SERVICE_ACCOUNT}"

3.4 منح أدوار "صانع المشروع" و"مستخدم حساب الفوترة" و"مُشاهد المؤسسة" لحساب الخدمة:

gcloud resource-manager folders add-iam-policy-binding ${TF_VAR_folder_id} \
  --member="serviceAccount:${SERVICE_ACCOUNT}" \
  --role="roles/resourcemanager.projectCreator"
gcloud organizations add-iam-policy-binding ${TF_VAR_org_id} \
  --member="serviceAccount:${SERVICE_ACCOUNT}" \
  --role="roles/billing.user"
gcloud beta billing accounts add-iam-policy-binding ${TF_VAR_billing_account} \
  --member="serviceAccount:${SERVICE_ACCOUNT}" \
  --role="roles/billing.user"
gcloud organizations add-iam-policy-binding ${TF_VAR_org_id} \
  --member="serviceAccount:${SERVICE_ACCOUNT}" \
  --role="roles/resourcemanager.organizationViewer"

لديك الآن حساب خدمة يمكن استخدامه لإدارة بيئة الاختبار.

4- تحضير بيانات اعتماد Terraform

لإنشاء بيئة اختبار، عليك تنزيل مفتاح حساب الخدمة في واجهة الأوامر.

4.1 مفتاح حساب الخدمة

إنشاء مفتاح حساب خدمة وتنزيله لتطبيق Terraform

gcloud iam service-accounts keys create cft.json --iam-account=${SERVICE_ACCOUNT}

4.2 إعداد بيانات اعتماد Terraform

أدخِل المفتاح إلى Terraform باستخدام متغير البيئة SERVICE_ACCOUNT_JSON، مع ضبط القيمة على contents لمفتاح حساب الخدمة.

export SERVICE_ACCOUNT_JSON=$(< cft.json)

بعد تخزين معلومات بيانات الاعتماد في متغيّر البيئة، أزِل ملف المفتاح. يمكنك إعادة إنشاء مفتاح لاحقًا إذا لزم الأمر باستخدام الأمر نفسه الوارد أعلاه.

rm -rf cft.json

5- إنشاء مشروع تجريبي لعمليات نشر Terraform

الآن بعد أن تم إعداد كل شيء، يمكنك إنشاء المشروع التجريبي باستخدام أمر واحد. شغِّل الأمر التالي من جذر الدليل terraform-google-cloud-storage:

make docker_test_prepare

ستظهر لك النتائج أدناه عند تشغيل make docker_test_prepare، وستتلقّى في النهاية مَعلمة project_id التجريبية التي تم إنشاؤها حيث يمكنك نشر وحدة Cloud Storage واختبارها باستخدام ميزتك الجديدة. في حال مواجهة مشاكل في ربط حساب الفوترة، يُرجى الرجوع إلى خطوات تحديد المشاكل وحلّها.

macbookpro3:terraform-google-cloud-storage user$ make docker_test_prepare
docker run --rm -it \
                -e SERVICE_ACCOUNT_JSON \
                -e TF_VAR_org_id \
                -e TF_VAR_folder_id \
                -e TF_VAR_billing_account \
                -v /Users/cft/terraform-google-cloud-storage:/workspace \
                gcr.io/cloud-foundation-cicd/cft/developer-tools:0.8.0 \
                /usr/local/bin/execute_with_credentials.sh prepare_environment
Activated service account credentials for: [cft-onboarding@<project_id>.iam.gserviceaccount.com]
Activated service account credentials for: [cft-onboarding@<project_id>.iam.gserviceaccount.com]
Initializing modules...

Initializing the backend...

Initializing provider plugins...

The following providers do not have any version constraints in configuration,
so the latest version was installed.

To prevent automatic upgrades to new major versions that may contain breaking
changes, it is recommended to add version = "..." constraints to the
corresponding provider blocks in configuration, with the constraint strings
suggested below.

* provider.google-beta: version = "~> 3.9"
* provider.null: version = "~> 2.1"
* provider.random: version = "~> 2.2"

Terraform has been successfully initialized!

You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.

If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.
module.project.module.project-factory.null_resource.preconditions: Refreshing state... [id=8723188031607443970]
module.project.module.project-factory.null_resource.shared_vpc_subnet_invalid_name[0]: Refreshing state... [id=5109975723938185892]
module.project.module.gsuite_group.data.google_organization.org[0]: Refreshing state...
module.project.module.project-factory.random_id.random_project_id_suffix: Refreshing state... [id=rnk]
module.project.module.project-factory.google_project.main: Refreshing state... [id=<project-id>]
module.project.module.project-factory.google_project_service.project_services[0]: Refreshing state... [id=<project-id>/storage-api.googleapis.com]
module.project.module.project-factory.google_project_service.project_services[1]: Refreshing state... [id=<project-id>/cloudresourcemanager.googleapis.com]
module.project.module.project-factory.google_project_service.project_services[2]: Refreshing state... [id=<project-id>/compute.googleapis.com]
module.project.module.project-factory.data.null_data_source.default_service_account: Refreshing state...
module.project.module.project-factory.google_service_account.default_service_account: Refreshing state... [id=projects/ci-cloud-storage-ae79/serviceAccounts/project-service-account@<project-id>.iam.gserv
iceaccount.com]
module.project.module.project-factory.google_project_service.project_services[3]: Refreshing state... [id=<project-id>/serviceusage.googleapis.com]
module.project.module.project-factory.null_resource.delete_default_compute_service_account[0]: Refreshing state... [id=3576396874950891283]
google_service_account.int_test: Refreshing state... [id=projects/<project-id>/serviceAccounts/cft-onboarding@<project-id>.iam.gserviceaccount.com]
google_service_account_key.int_test: Refreshing state... [id=projects/<project-id>/serviceAccounts/cft-onboarding@<project-id>.iam.gserviceaccount.com/keys/351009a1e011e88049ab2097994d1c627a61
6961]
google_project_iam_member.int_test[1]: Refreshing state... [id=<project-id>/roles/iam.serviceAccountUser/serviceaccount:cft-onboarding@<project-id>.iam.gserviceaccount.com]
google_project_iam_member.int_test[0]: Refreshing state... [id=<project-id>/roles/storage.admin/serviceaccount:cft-onboarding@<project-id>.iam.gserviceaccount.com]

Apply complete! Resources: 0 added, 0 changed, 0 destroyed.

Outputs:

project_id = <test-project-id>
sa_key = <sensitive>
Found test/setup/make_source.sh. Using it for additional explicit environment configuration.

لقد أنشأت الآن مشروعًا تجريبيًا تمت الإشارة إليه بواسطة project_id كما ترى في إخراج وحدة التحكم. تم إعداد بيئة التطوير والاختبار.

5- إضافة ميزة جديدة إلى وحدة CFT

بعد الانتهاء من إعداد بيئة التطوير والاختبار، لنبدأ في إضافة التصنيف "silly_label". بوحدة CFT للتخزين في google-cloud.

تأكد من وجودك في terraform-google-cloud-storage وافتح ملف main.tf كما ترى أدناه في هيكل المجلد.

منذ "silly_label" تسمية، ستضيف الميزة في السطر 27 إلى المتغير "labels" في main.tf، كما هو موضّح أدناه:

terraform-google-cloud-storage/main.tf

resource "google_storage_bucket" "buckets" {
 <...>
 storage_class = var.storage_class
 // CODELAB:Add silly label in labels variable
 labels        = merge(var.labels, { name = replace("${local.prefix}${lower(each.value)}", ".", "-") }, { "silly" = var.silly_label })
 force_destroy = lookup(
 <...>
}

الآن، ستضيف المتغير silly_label في ratings.tf الذي تراه في هيكل المجلد أعلاه.

انسخ التعليمة البرمجية أدناه والصقها إلى السطر 31 في ratings.tf وتأكد من أن لديك حرف سطر جديد أعلى وأسفل كتلة المتغير التي تضيفها.

terraform-google-cloud-storage/variables.tf

variable "names" {
 description = "Bucket name suffixes."
 type        = list(string)
}

// CODELAB: Add "silly_label" variable to variables.tf between "names" and "location"
variable "silly_label" {
 description = "Sample label for bucket."
 type        = string
}

variable "location" {
 description = "Bucket location."
 default     = "EU"
}

6- إضافة ميزة جديدة إلى مثال على حزمة تخزين

لقد أضفت ميزتك إلى main.tf للوحدة، والآن ستختبر الميزة المضافة من خلال مثال.

تصنيف "silly_label" يجب إضافته إلى الأمثلة/Multiple-buckets/main.tf

سيتم استخدام هذا المثال في الخطوة التالية لإجراء اختبارات الدمج.

انسخ السطر silly_label أدناه والصقه في السطر 27 في main.tf على العنوان terraform-google-cloud-storage/examples/Multiple-buckets/ كما هو موضّح في بنية المجلد:

terraform-google-cloud-storage/examples/multiple-buckets/main.tf

module "cloud_storage" {
 <...>
 // CODELAB: Add "silly_label" as an example to main.tf.
 silly_label        = "awesome"

 <..>
}

7. تعديل اختبار المخطط للتحقّق من الميزة

لقد أضفت ميزتك إلى main.tf للوحدة النمطية ثم أضفت الميزة إلى مثال Multi_buckets. الآن، تحتاج إلى اختبار الميزة من خلال اختبار دمج مخطط مكتوب بلغة Golang.

ستضيف اختباراتك الجديدة في ملف Multi_buckets_test.go الموجود في بنية المجلد أدناه:

لقد أضفت التصنيف "silly_label" في جميع الحِزم التي يتم إنشاؤها من خلال الوحدة Multi_buckets وعليك الآن كتابة اختبارات لاختبار الميزة الجديدة.

في التعليمة البرمجية أدناه، ستحصل على تسمية كل حزمة من خلال أمر gcloud alpha Storage ثم تتحقق من النتيجة التي تم إرجاعها من الأمر.

test/integration/multiple_buckets/multiple_buckets_test.go

func TestMultipleBuckets(t *testing.T) {
 <..>
op := gcloud.Run(t, fmt.Sprintf("alpha storage ls --buckets gs://%s", bucketName), gcloudArgs).Array()[0]

// verify silly label on each bucket
assert.Equal("awesome", op.Get("metadata.labels.silly").String(), "should have silly label set to awesome")

// verify lifecycle rules
...
}

8. إجراء اختبارات التكامل في واجهة CFT

اختبار الدمج

تُستخدم اختبارات الدمج للتحقق من سلوك الوحدة الجذر والوحدات الفرعية والأمثلة. يجب أن تكون الإضافات والتغييرات والإصلاحات مصحوبة بالاختبارات.

تتم كتابة اختبارات الدمج باستخدام إطار عمل اختبار المخطط ويتم إجراؤها باستخدام CFT CLI. يتم تجميع هذه الأدوات داخل صورة Docker لتسهيل العملية.

تتمثّل الاستراتيجية العامة لهذه الاختبارات في التحقّق من سلوك نماذج الوحدات، وبالتالي ضمان صحة عمل كل من الوحدة الجذر والوحدات الفرعية ونموذج الوحدات.

في عملية التنفيذ التفاعلي، يتم تنفيذ كل خطوة من خلال أوامر متعددة.

شغِّل make docker_run لبدء اختبار حاوية Docker في الوضع التفاعلي.

Make هي أداة لأتمتة الإصدار تنشئ تلقائيًا برامج ومكتبات قابلة للتنفيذ من رمز المصدر عن طريق قراءة ملفات تسمى Makefiles التي تحدد كيفية اشتقاق البرنامج المستهدف. عند إجراء تغييرات على الملف، يجب أن يتم تعديل حاوية Docker تلقائيًا.

عند تشغيل make docker_run، يتم إنشاء مساحة عمل في حاوية Docker وتفعيل بيانات الاعتماد لحساب الخدمة. سيتم استخدام مساحة العمل في الخطوات التالية لإجراء الاختبارات.

سيظهر الناتج أدناه في الوحدة الطرفية:

Activated service account credentials for: [cft@<PROJECT_ID>.iam.gserviceaccount.com]

نفِّذ cft test list لسرد جميع اختبارات المخططات في مساحة العمل.

سيظهر الناتج أدناه في الوحدة الطرفية:

[root@CONTAINER_ID workspace]# cft test list
 NAME                           | CONFIG                    | LOCATION                                                   
--------------------------------+---------------------------+------------------------------------------------------------
 TestAll/examples/simple_bucket | examples/simple_bucket    | test/integration/discover_test.go                          
 TestMultipleBuckets            | examples/multiple_buckets | test/integration/multiple_buckets/multiple_buckets_test.go

شغِّل cft test run <EXAMPLE_NAME> --stage init لإعداد المثال. في هذه الحالة، لإعداد عملية اختبار TestMultipleBuckets، cft test run TestMultipleBuckets --stage init. يمكنك أيضًا استخدام علامة --verbose للحصول على معلومات إضافية عند إجراء الاختبارات.

تؤدي هذه المرحلة الأولية إلى تهيئة مثال Terraform.

سيظهر الناتج أدناه في الوحدة الطرفية.

[root@<CONTAINER_ID> workspace]# cft test run TestMultipleBuckets --stage init --verbose
INFO[02-09|08:24:31] using test-dir: test/integration 
...
TestMultipleBuckets 2022-02-09T08:24:35Z command.go:179: Terraform has been successfully initialized!
...
TestMultipleBuckets 2022-02-09T08:24:35Z command.go:100: Running command terraform with args [validate]
TestMultipleBuckets 2022-02-09T08:24:36Z command.go:179: Success! The configuration is valid.
...
--- PASS: TestMultipleBuckets (4.05s)

شغِّل cft test run <EXAMPLE_NAME> --stage apply لتطبيق نموذج الوحدة.

تطبّق هذه الخطوة المثال الذي تم إعداده في المرحلة السابقة على مشروع Google Cloud Platform الذي تم إنشاؤه مسبقًا في الدرس التطبيقي حول الترميز.

سيظهر الناتج أدناه في الوحدة الطرفية.

[root@<CONTAINER_ID> workspace]# cft test run TestMultipleBuckets --stage apply --verbose
INFO[02-09|08:28:11] using test-dir: test/integration
...
TestMultipleBuckets 2022-02-09T08:28:19Z command.go:179: Apply complete! Resources: 6 added, 0 changed, 0 destroyed.
TestMultipleBuckets 2022-02-09T08:28:19Z command.go:179: 
TestMultipleBuckets 2022-02-09T08:28:19Z command.go:179: Outputs:
TestMultipleBuckets 2022-02-09T08:28:19Z command.go:179: 
TestMultipleBuckets 2022-02-09T08:28:19Z command.go:179: names = {
TestMultipleBuckets 2022-02-09T08:28:19Z command.go:179:   "one" = "multiple-buckets-erp1-eu-one"
...
--- PASS: TestMultipleBuckets (6.51s)
PASS
ok      github.com/terraform-google-modules/terraform-google-cloud-storage/test/integration/multiple_buckets    6.548s

شغِّل cft test run <EXAMPLE_NAME> --stage verify للتحقق من أنّ المثال أنشأ البنية الأساسية المتوقعة.

ستؤدي هذه الخطوة إلى تشغيل دالة التحقّق في TestMultipleBuckets. تتم عادةً عملية إثبات الملكية من خلال تنفيذ الأمر gcloud لاسترداد ناتج JSON للحالة الحالية للمورد والتأكيد على أن الحالة الحالية قد تم تعريفها في المثال.

إذا ظهرت لك أي أخطاء، سترى ما كان متوقّعًا وما تلقّاه الأمر من أجل الاختبار.

سيظهر الناتج أدناه في الوحدة الطرفية.

cft test run TestMultipleBuckets --stage verify --verbose
INFO[02-09|08:30:19] using test-dir: test/integration
...
TestMultipleBuckets 2022-02-09T08:30:27Z command.go:100: Running command terraform with args [output -no-color -json names_list]
TestMultipleBuckets 2022-02-09T08:30:27Z command.go:179: ["multiple-buckets-erp1-eu-one","multiple-buckets-erp1-eu-two"]
TestMultipleBuckets 2022-02-09T08:30:27Z command.go:100: Running command gcloud with args [alpha storage ls --buckets gs://multiple-buckets-erp1-eu-one --project ci-cloud-storage-8ce9 --json]
TestMultipleBuckets 2022-02-09T08:30:28Z command.go:179: [
TestMultipleBuckets 2022-02-09T08:30:28Z command.go:179: {
TestMultipleBuckets 2022-02-09T08:30:28Z command.go:179:   "url": "gs://multiple-buckets-erp1-eu-one/",
...
TestMultipleBuckets 2022-02-09T08:30:33Z command.go:179: ]
2022/02/09 08:30:33 RUN_STAGE env var set to verify
2022/02/09 08:30:33 Skipping stage teardown
--- PASS: TestMultipleBuckets (12.32s)
PASS
ok      github.com/terraform-google-modules/terraform-google-cloud-storage/test/integration/multiple_buckets    12.359s

يجب تنفيذ cft test run <EXAMPLE_NAME> --stage teardown لتحليل المثال.

تؤدي هذه الخطوة إلى تدمير البنية التحتية التي أنشأتها في الخطوات أعلاه. ستؤدي هذه الخطوة أيضًا إلى إتلاف حِزم GCS التي تم إنشاؤها في المشروع إلى جانب التصنيف الذي أضفته إلى وحدة GCS.

يمكنك الاطّلاع على الناتج أدناه في الوحدة الطرفية.

[root@<CONTAINER_ID> workspace]# cft test run TestMultipleBuckets --stage teardown --verbose
INFO[02-09|08:36:02] using test-dir: test/integration
...
TestMultipleBuckets 2022-02-09T08:36:06Z command.go:100: Running command terraform with args [destroy -auto-approve -input=false -lock=false]
TestMultipleBuckets 2022-02-09T08:36:07Z command.go:179: module.cloud_storage.random_id.bucket_suffix: Refreshing state... [id=mNA]
TestMultipleBuckets 2022-02-09T08:36:07Z command.go:179: random_string.prefix: Refreshing state... [id=erp1]
TestMultipleBuckets 2022-02-09T08:36:08Z command.go:179: module.cloud_storage.google_storage_bucket.buckets["two"]: Refreshing state... [id=multiple-buckets-erp1-eu-two]
...
TestMultipleBuckets 2022-02-09T08:36:10Z command.go:179: Destroy complete! Resources: 6 destroyed.
TestMultipleBuckets 2022-02-09T08:36:10Z command.go:179: 
--- PASS: TestMultipleBuckets (6.62s)
PASS
ok      github.com/terraform-google-modules/terraform-google-cloud-storage/test/integration/multiple_buckets    6.654s

شغِّل exit للخروج من حاوية الاختبار.

9. إنشاء وثائق للمدخلات والمخرجات

يتم تلقائيًا إنشاء جدولَي "الإدخالات" و"المخرجات" في الملفات بتنسيق README للوحدة الجذر والوحدات الفرعية ونماذج الوحدات استنادًا إلى variables وoutputs للوحدات المعنيّة. يجب إعادة تحميل هذه الجداول في حال تغيير واجهات الوحدات.

التشغيل:

make generate_docs
# This will generate new Inputs and Outputs tables

10. تنفيذ اختبارات الوبر في CFT

linter هي أداة تحلِّل رمز المصدر لوضع علامة على الأخطاء البرمجية والأخطاء في الأسلوب والتركيبات المريبة.

يمكن استخدام أداة Lint أو تنسيق العديد من الملفات في المستودع للحفاظ على معايير الجودة. لضمان الجودة في CFT، يجب استخدام اختبار الوبر.

التشغيل:

make docker_test_lint
# This will run all lint tests on your repo

11. تقديم مسؤول العلاقات العامة على جيت هب

الآن بعد أن غيّرت رمزك محليًا واختبرته من خلال اختبارات الدمج، ستحتاج إلى نشر هذا الرمز في المستودع الرئيسي.

لإتاحة الرمز في المستودع الرئيسي، عليك إجراء تغييرات على الرمز في فرعك وإرساله إلى المستودع الرئيسي. لإضافة الرمز إلى المستودع الرئيسي الذي أنشأته في بداية "الدرس التطبيقي حول الترميز"، عليك تقديم "طلب سحب" (PR) في المستودع الرئيسي بعد تطبيق الرمز عليه.

وعند تقديم عرض عام، سيتم إشعار مشرف المستودع لمراجعة التغييرات المقترَحة في الرمز. بالإضافة إلى ذلك، يمكنك إضافة مستخدمين آخرين كمراجعين للحصول على ملاحظات حول التغييرات التي أجريتها على الرمز البرمجي. سيؤدّي مسؤول العلاقات العامة إلى إطلاق Cloud Build الذي سيُجري اختبارات على المستودع.

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

اتّبِع الخطوات التالية لإضافة الرمز إلى الفرع المتشعّب لإرسال الرمز إلى الفرع المتشعّب:

الخطوة الأولى هي إضافة الملفات التي تم تغييرها إلى المستودع المحلي.

$ git add main.tf
$ git add README.md
$ git add variables.tf
$ git add examples/multiple-buckets/main.tf
$ git add test/integration/multiple_buckets/multiple_buckets_test.go
# The ‘git add' command adds the file in the local repository and 
# stages the file for commit. To unstage a file, use git reset HEAD YOUR-FILE

يتم الآن تنظيم ملفاتك، وبعد ذلك ستنفّذ التغييرات.

$ git commit -m "First CFT commit"
# This will commit the staged changes and prepares them to be pushed 
# to a remote repository. To remove this commit and modify the file, 
# use 'git reset --soft HEAD~1' and commit and add the file again.

يمكنك دفع التغييرات الملتزمة في مستودعك المحلي إلى GitHub لإنشاء طلب سحب (PR).

$ git push -u origin feature/silly_label
# Pushes the changes in your local repository up to the remote
# repository you specified as the origin

تغييرات التعليمات البرمجية جاهزة الآن لطلب سحب

نفِّذ الخطوات التالية لإنشاء مسؤول علاقات عامة في مستودع terraform-google-modules/terraform-google-cloud-storage :

في متصفّح الويب، انتقِل إلى صفحة المستودع الرئيسية.
سترى اقتراحًا عبر البانر لفتح عرض عام من الشوكة. انقر على "مقارنة الطلب وسحبه".

أدخِل عنوانًا ووصفًا لطلب السحب لوصف التغييرات في الرمز البرمجي. كن محددًا قدر الإمكان في حين أن تكون موجزًا.

لإنشاء طلب سحب جاهز للمراجعة، انقر على "إنشاء طلب سحب".
ستظهر لك "مشغِّلات Cloud Build" التي يتم تشغيلها بسبب "PR".
يمكنك الرجوع إلى مستندات GitHub الرسمية بشأن فتح طلبات السحب من الشوك إذا واجهتك أي مشاكل.

لقد نجحت في تطبيق أول تغيير لك على الرمز في فرعك المتشعّب ورفعت أول إصدار CFT PR مقابل الفرع الرئيسي.

12. تهانينا

تهانينا، لقد أضفت بنجاح ميزة إلى وحدة CFT وأرسلت "معايير العلاقات العامة" لمراجعتها.

لقد أضفت ميزة إلى وحدة CFT، واختبرتها محليًا من خلال مثال، وأجريت اختبارات قبل تطبيق التعليمة البرمجية على GitHub. وأخيرًا، جمعتم العلاقات العامة لمراجعتها والدمج النهائي في CFT.

أنت تعرف الآن الخطوات المهمة لبدء استخدام مجموعة أدوات Cloud Foundation.