Terraform 0.11 - Debugging Terraform

डीबगिंग टेराफॉर्म




terraform

डीबगिंग टेराफॉर्म

टेराफॉर्म में विस्तृत लॉग हैं जिन्हें किसी भी मूल्य पर TF_LOG पर्यावरण चर सेट करके सक्षम किया जा सकता है। यह stderr पर प्रदर्शित होने के लिए विस्तृत लॉग का कारण होगा।

आप लॉग के स्तर TF_LOG , DEBUG , INFO , WARN या ERROR से किसी एक में TF_LOG सेट कर सकते हैं TF_LOG लॉग की वर्बोसिटी बदल सके। TRACE सबसे TF_LOG है और यह डिफ़ॉल्ट है यदि TF_LOG लॉग स्तर नाम के अलावा किसी अन्य चीज़ पर सेट है।

लॉग आउटपुट को जारी रखने के लिए आप लॉग को सक्षम करने के लिए लॉग को हमेशा किसी विशेष फ़ाइल में संलग्न करने के लिए TF_LOG_PATH सेट कर सकते हैं। ध्यान दें कि TF_LOG_PATH सेट होने पर भी, किसी भी लॉगिंग को सक्षम करने के लिए TF_LOG को सेट किया जाना चाहिए।

यदि आपको टेराफॉर्म के साथ एक बग मिल जाता है, तो जिस्ट जैसी सेवा का उपयोग करके विस्तृत लॉग शामिल करें।

क्रैश लॉग की व्याख्या करना

यदि टेराफॉर्म कभी दुर्घटनाग्रस्त हो जाता है (गो रनटाइम में एक "आतंक"), तो यह सत्र से डीबग लॉग के साथ लॉग फ़ाइल को बचाता है और साथ ही पैनिक मैसेज और बैकट्रेस को crash.log कर crash.log । सामान्यतया, यह लॉग फ़ाइल डेवलपर्स के साथ एक GitHub इश्यू के माध्यम से पारित करने के लिए होती है। एक उपयोगकर्ता के रूप में, आपको इस फ़ाइल में खुदाई करने की आवश्यकता नहीं है।

हालाँकि, यदि आप यह पता लगाने में रुचि रखते हैं कि कोई समस्या दर्ज करने से पहले क्या गलत हो सकता है, तो यहां क्रैश लॉग को पढ़ने का मूल विवरण दिया गया है।

क्रैश लॉग का सबसे दिलचस्प हिस्सा पैनिक मैसेज ही है और तुरंत पीछे चल रहा है। तो पहली बात यह है कि panic: लिए फ़ाइल की खोज करें panic: जो आपको इस संदेश के लिए सही कूदना चाहिए। यह कुछ इस तरह दिखेगा:

panic: runtime error: invalid memory address or nil pointer dereference

goroutine 123 [running]:
panic(0xabc100, 0xd93000a0a0)
    /opt/go/src/runtime/panic.go:464 +0x3e6
github.com/hashicorp/terraform/builtin/providers/aws.resourceAwsSomeResourceCreate(...)
    /opt/gopath/src/github.com/hashicorp/terraform/builtin/providers/aws/resource_aws_some_resource.go:123 +0x123
github.com/hashicorp/terraform/helper/schema.(*Resource).Refresh(...)
    /opt/gopath/src/github.com/hashicorp/terraform/helper/schema/resource.go:209 +0x123
github.com/hashicorp/terraform/helper/schema.(*Provider).Refresh(...)
    /opt/gopath/src/github.com/hashicorp/terraform/helper/schema/provider.go:187 +0x123
github.com/hashicorp/terraform/rpc.(*ResourceProviderServer).Refresh(...)
    /opt/gopath/src/github.com/hashicorp/terraform/rpc/resource_provider.go:345 +0x6a
reflect.Value.call(...)
    /opt/go/src/reflect/value.go:435 +0x120d
reflect.Value.Call(...)
    /opt/go/src/reflect/value.go:303 +0xb1
net/rpc.(*service).call(...)
    /opt/go/src/net/rpc/server.go:383 +0x1c2
created by net/rpc.(*Server).ServeCodec
    /opt/go/src/net/rpc/server.go:477 +0x49d

इस संदेश का मुख्य भाग पहली दो पंक्तियाँ हैं जिनमें hashicorp/terraform शामिल हैं। इस उदाहरण में:

github.com/hashicorp/terraform/builtin/providers/aws.resourceAwsSomeResourceCreate(...)
    /opt/gopath/src/github.com/hashicorp/terraform/builtin/providers/aws/resource_aws_some_resource.go:123 +0x123

पहली पंक्ति हमें बताती है कि जो विधि विफल हो गई है, वह है aws_some_resource , जिसे हम aws_some_resource सकते हैं जिसमें एक (काल्पनिक) aws_some_resource का निर्माण शामिल है।

दूसरी पंक्ति कोड की सटीक रेखा की ओर इशारा करती है जिससे घबराहट हुई, जो - पैनिक मैसेज के साथ संयुक्त रूप से - आमतौर पर किसी डेवलपर के लिए समस्या के कारण का पता लगाने के लिए पर्याप्त है।

एक उपयोगकर्ता के रूप में, यह जानकारी एक चुटकी में समस्या के आसपास काम करने में मदद कर सकती है, क्योंकि यह उम्मीद है कि कोड बेस के क्षेत्र को इंगित करना चाहिए जिसमें दुर्घटना हो रही है।