ถ้าเช่นฉันคุณใช้อินเทอร์เน็ตเพื่อช่วยคุณเลือกระหว่าง CloudFormation และ Terraform ในฐานะเครื่องมือโครงสร้างพื้นฐาน as-code (IaC) ตัวถัดไปของคุณโดยไม่พบคำตอบที่ชัดเจนฉันแบ่งปันความเจ็บปวดของคุณมานานแล้ว ตอนนี้ฉันมีประสบการณ์ที่สำคัญเกี่ยวกับเครื่องมือทั้งสองและฉันสามารถตัดสินใจได้อย่างมีข้อมูลว่าจะใช้เครื่องมือใด
สำหรับโครงการ IaC ของคุณบน AWS ให้เลือก CloudFormation เนื่องจาก:
ความแตกต่างอย่างหนึ่งระหว่าง CloudFormation และ Terraform คือการที่โค้ดและอินสแตนซ์เกี่ยวข้องกันภายในแต่ละบริการอย่างไร
CloudFormation มีแนวคิดของไฟล์ ซ้อนกัน ซึ่งเป็นอินสแตนซ์ของเทมเพลต เทมเพลตเดียวกันสามารถสร้างอินสแตนซ์ได้ ไม่มีที่สิ้นสุด โดยลูกค้าที่ระบุในบัญชีที่ระบุข้ามบัญชีหรือโดยลูกค้ารายอื่น
Terraform ไม่มีแนวคิดดังกล่าวและต้องการความสัมพันธ์แบบหนึ่งต่อหนึ่งระหว่างรหัสและการสร้างอินสแตนซ์ มันจะคล้ายกับการทำสำเนาซอร์สโค้ดของเว็บเซิร์ฟเวอร์สำหรับแต่ละเซิร์ฟเวอร์ที่คุณต้องการเรียกใช้หรือทำซ้ำโค้ดทุกครั้งที่คุณต้องเรียกใช้แอปพลิเคชันแทนที่จะเรียกใช้เวอร์ชันที่คอมไพล์
ประเด็นนี้เป็นเรื่องเล็กน้อยในกรณีของการตั้งค่าที่เรียบง่าย แต่มันกลายเป็นจุดเจ็บปวดที่สำคัญอย่างรวดเร็วสำหรับการดำเนินงานขนาดกลางถึงใหญ่ ใน Terraform ทุกครั้งที่คุณต้องหมุนสแต็กใหม่จากโค้ดที่มีอยู่คุณจะต้องทำโค้ดซ้ำ และการคัดลอก / วางไฟล์สคริปต์เป็นวิธีที่ง่ายมากในการบ่อนทำลายตัวเองและทำให้ทรัพยากรเสียหายโดยที่คุณไม่ได้ตั้งใจจะแตะต้อง
จริงๆแล้ว Terraform ไม่มีแนวคิด กอง เช่น CloudFormation ซึ่งแสดงให้เห็นอย่างชัดเจนว่า Terraform ถูกสร้างขึ้นจากพื้นฐานเพื่อให้มีการจับคู่แบบหนึ่งต่อหนึ่งระหว่างโค้ดและทรัพยากรที่จัดการ ต่อมาได้รับการแก้ไขบางส่วนโดยแนวคิดของ สภาพแวดล้อม (ซึ่งตั้งแต่นั้นมาถูกเปลี่ยนชื่อเป็น“ พื้นที่ทำงาน”) แต่วิธีการใช้งานเหล่านี้ทำให้ง่ายต่อการปรับใช้กับสภาพแวดล้อมที่ไม่ต้องการ นี่เป็นเพราะคุณต้องวิ่ง terraform workspace select ก่อนที่จะปรับใช้และการลืมขั้นตอนนี้จะนำไปใช้กับพื้นที่ทำงานที่เลือกไว้ก่อนหน้านี้ซึ่งอาจใช่หรือไม่ใช่ที่คุณต้องการ
ในทางปฏิบัติเป็นเรื่องจริงที่ปัญหานี้ได้รับการบรรเทาลงโดยการใช้โมดูล Terraform แต่ในกรณีที่ดีที่สุดคุณจะต้องใช้รหัสสำเร็จรูปจำนวนมาก ในความเป็นจริงปัญหานี้รุนแรงมากจนผู้คนต้องสร้างเครื่องมือห่อหุ้ม Terraform เพื่อแก้ไขปัญหานี้: Terragrunt .
ความแตกต่างที่สำคัญอีกประการระหว่าง CloudFormation และ Terraform คือการจัดการสถานะและสิทธิ์แต่ละรายการ
CloudFormation จัดการสถานะสแต็กให้คุณและไม่มีตัวเลือกใด ๆ ให้คุณ แต่สถานะสแต็ก CloudFormation นั้นมั่นคงในประสบการณ์ของฉัน นอกจากนี้ CloudFormation ยังอนุญาตให้ผู้ใช้ที่มีสิทธิพิเศษน้อยกว่าในการจัดการสแต็กโดยไม่ต้องมีสิทธิ์ที่จำเป็นทั้งหมดที่สแตกต้องการ เนื่องจาก CloudFormation สามารถรับสิทธิ์จากบทบาทบริการที่เชื่อมต่อกับสแต็กแทนที่จะเป็นสิทธิ์จากผู้ใช้ที่รันการดำเนินการสแต็ก
Terraform ต้องการให้คุณจัดหาส่วนหลังเพื่อจัดการสถานะ ค่าดีฟอลต์คือไฟล์ในเครื่องซึ่งไม่เป็นที่น่าพอใจโดยสิ้นเชิงเนื่องจาก:
ดังนั้นคุณจึงต้องมีสถานะที่แข็งแกร่งและใช้ร่วมกันได้ซึ่งโดยปกติแล้วบน AWS จะทำได้โดยใช้ที่เก็บข้อมูล S3 เพื่อจัดเก็บไฟล์สถานะพร้อมด้วยตาราง DynamoDB เพื่อจัดการการทำงานพร้อมกัน
ซึ่งหมายความว่าคุณต้องสร้างบัคเก็ต S3 และตาราง DynamoDB ด้วยตนเองสำหรับแต่ละสแต็กที่คุณต้องการสร้างอินสแตนซ์และยังจัดการสิทธิ์ด้วยตนเองสำหรับออบเจ็กต์ทั้งสองนี้เพื่อ จำกัด ผู้ใช้ที่มีสิทธิ์น้อยกว่าไม่ให้เข้าถึงข้อมูลที่พวกเขาไม่ควรเข้าถึง หากคุณมีสแต็กเพียงไม่กี่สแต็กนั่นก็จะไม่เป็นปัญหามากนัก แต่ถ้าคุณมี 20 สแต็กที่ต้องจัดการนั่นก็จะยุ่งยากมาก
อย่างไรก็ตามเมื่อใช้พื้นที่ทำงาน Terraform จะไม่สามารถมีตาราง DynamoDB หนึ่งตารางต่อพื้นที่ทำงานได้ ซึ่งหมายความว่าหากคุณต้องการให้ผู้ใช้ IAM ที่มีสิทธิ์น้อยที่สุดในการปรับใช้ผู้ใช้นั้นจะสามารถดำเนินการกับล็อกของพื้นที่ทำงานทั้งหมดได้เนื่องจากสิทธิ์ DynamoDB ไม่ได้กำหนดระดับไอเท็มอย่างละเอียด
ในประเด็นนี้ทั้ง CloudFormation และ Terraform อาจเป็นเรื่องยุ่งยากเล็กน้อย หากคุณเปลี่ยนรหัสตรรกะ (เช่นชื่อ) ของทรัพยากรทั้งคู่จะพิจารณาว่าทรัพยากรเก่าจะต้องถูกทำลายและสร้างขึ้นมาใหม่ ดังนั้นโดยทั่วไปจึงเป็นความคิดที่ดีที่จะเปลี่ยนรหัสตรรกะของทรัพยากรในเครื่องมือใดเครื่องมือหนึ่งโดยเฉพาะอย่างยิ่งสำหรับสแต็กที่ซ้อนกันใน CloudFormation
ดังที่กล่าวไว้ในส่วนแรก Terraform ไม่จัดการการอ้างอิงพื้นฐาน น่าเสียดายที่นักพัฒนา Terraform ไม่ให้ ปัญหาที่มีมายาวนาน ให้ความสนใจมากแม้จะเห็นได้ชัด ขาดวิธีแก้ปัญหา .
เนื่องจากการจัดการการพึ่งพาที่เหมาะสมมีความสำคัญอย่างยิ่งต่อเครื่องมือ IaC ปัญหาดังกล่าวใน Terraform จึงเรียกความเหมาะสมเป็นคำถามทันทีที่เกี่ยวข้องกับการดำเนินงานที่สำคัญทางธุรกิจเช่นการปรับใช้กับสภาพแวดล้อมการผลิต CloudFormation ให้ความรู้สึกเป็นมืออาชีพมากขึ้นและ AWS มักจะใส่ใจในการตรวจสอบให้แน่ใจว่าได้นำเสนอเครื่องมือระดับการผลิตให้กับลูกค้า ตลอดหลายปีที่ฉันใช้ CloudFormation ฉันไม่เคยพบปัญหาเกี่ยวกับการจัดการการพึ่งพา
CloudFormation อนุญาตให้สแต็กส่งออกตัวแปรเอาต์พุตบางตัวซึ่งสแต็กอื่นสามารถนำกลับมาใช้ใหม่ได้ ตามจริงแล้วฟังก์ชันนี้มีข้อ จำกัด เนื่องจากคุณจะไม่สามารถสร้างอินสแตนซ์มากกว่าหนึ่งสแต็กต่อภูมิภาคได้ เนื่องจากคุณไม่สามารถส่งออกตัวแปรสองตัวที่มีชื่อเดียวกันได้และตัวแปรที่ส่งออกจะไม่มีเนมสเปซ
Terraform ไม่มีสิ่งอำนวยความสะดวกเช่นนี้ดังนั้นคุณจึงเหลือตัวเลือกที่ไม่ต้องการ Terraform ช่วยให้คุณสามารถนำเข้าสถานะของสแต็กอื่นได้ แต่จะช่วยให้คุณสามารถเข้าถึงข้อมูลทั้งหมดในสแต็กนั้นรวมถึงความลับมากมายที่เก็บไว้ในสถานะ หรืออีกวิธีหนึ่งสแต็กสามารถส่งออกตัวแปรบางตัวในรูปแบบของไฟล์ JSON ที่เก็บไว้ในบัคเก็ต S3 แต่อีกครั้งตัวเลือกนี้ยุ่งยากกว่า: คุณต้องตัดสินใจว่าจะใช้บัคเก็ต S3 ใดและให้สิทธิ์ที่เหมาะสมและเขียนทั้งหมด รหัสท่อประปาด้วยตัวคุณเองทั้งด้านผู้เขียนและผู้อ่าน
ข้อดีอย่างหนึ่งของ Terraform คือมีแหล่งข้อมูล Terraform จึงสามารถสืบค้นทรัพยากรที่ไม่ได้จัดการโดย Terraform อย่างไรก็ตามในทางปฏิบัติสิ่งนี้มีความเกี่ยวข้องเพียงเล็กน้อยเมื่อคุณต้องการเขียนเทมเพลตทั่วไปเพราะคุณจะไม่คิดอะไรเกี่ยวกับบัญชีเป้าหมาย สิ่งที่เทียบเท่าใน CloudFormation คือการเพิ่มพารามิเตอร์เทมเพลตเพิ่มเติมซึ่งเกี่ยวข้องกับการทำซ้ำและอาจเกิดข้อผิดพลาด อย่างไรก็ตามจากประสบการณ์ของฉันสิ่งนี้ไม่เคยเป็นปัญหา
กลับไปที่ปัญหาของการจัดการการพึ่งพาของ Terraform อีกตัวอย่างหนึ่งคือคุณได้รับข้อผิดพลาดเมื่อพยายามอัปเดตการตั้งค่าสำหรับตัวจัดสรรภาระงานและรับสิ่งต่อไปนี้:
Error: Error deleting Target Group: ResourceInUse: Target group 'arn:aws:elasticloadbalancing:us-east-1:723207552760:targetgroup/strategy-api-default-us-east-1/14a4277881e84797' is currently in use by a listener or a rule status code: 400, request id: 833d8475-f702-4e01-aa3a-d6fa0a141905 พฤติกรรมที่คาดหวังคือ Terraform ตรวจพบว่ากลุ่มเป้าหมายเป็นแหล่งที่มาของทรัพยากรอื่น ๆ ที่ไม่ได้ถูกลบดังนั้นจึงไม่ควรพยายามลบ แต่ก็ไม่ควรทำให้เกิดข้อผิดพลาด
แม้ว่า Terraform จะเป็นเครื่องมือบรรทัดคำสั่ง แต่ก็เป็นที่ชัดเจนว่าคาดว่าจะมีมนุษย์เรียกใช้เนื่องจากมีการโต้ตอบเป็นอย่างมาก เป็นไปได้ที่จะเรียกใช้ในโหมดแบตช์ (เช่นจากสคริปต์) แต่ต้องใช้อาร์กิวเมนต์บรรทัดคำสั่งเพิ่มเติม ความจริงที่ว่า Terraform ได้รับการพัฒนาให้ทำงานโดยมนุษย์โดยค่าเริ่มต้นนั้นค่อนข้างทำให้งงเนื่องจากจุดประสงค์ของเครื่องมือ IaC คือระบบอัตโนมัติ
Terraform คือ ยากที่จะแก้ไขข้อบกพร่อง . ข้อความแสดงข้อผิดพลาดมักจะเป็นพื้นฐานมากและไม่อนุญาตให้คุณเข้าใจว่าเกิดอะไรขึ้นซึ่งในกรณีนี้คุณจะต้องเรียกใช้ Terraform ด้วย TF_LOG=debug ซึ่งจะสร้างผลลัพธ์จำนวนมากในการลากผ่าน ในบางครั้ง Terraform ก็ทำให้การเรียก API ไปยัง AWS ล้มเหลว แต่ความล้มเหลวไม่ใช่ปัญหากับ Terraform ในทางตรงกันข้าม CloudFormation ให้ข้อความแสดงข้อผิดพลาดที่ชัดเจนพอสมควรพร้อมรายละเอียดเพียงพอที่จะช่วยให้คุณเข้าใจว่าปัญหาอยู่ที่ใด
ตัวอย่างข้อความแสดงข้อผิดพลาด Terraform:
ฝั่งไคลเอ็นต์ vs ฝั่งเซิร์ฟเวอร์
Error: error reading S3 bucket Public Access Block: NoSuchBucket: The specified bucket does not exist status code: 404, request id: 19AAE641F0B4AC7F, host id: rZkgloKqxP2/a2F6BYrrkcJthba/FQM/DaZnj8EQq/5FactUctdREq8L3Xb6DgJmyKcpImipv4s= ข้อความแสดงข้อผิดพลาดด้านบนแสดงข้อความแสดงข้อผิดพลาดที่ชัดเจนซึ่งจริงๆแล้วไม่ได้แสดงถึงปัญหาที่อยู่เบื้องหลัง (ซึ่งในกรณีนี้คือปัญหาการอนุญาต)
ข้อความแสดงข้อผิดพลาดนี้ยังแสดงให้เห็นว่า Terraform สามารถระบายสีตัวเองเข้ามุมได้อย่างไร ตัวอย่างเช่นหากคุณสร้างที่เก็บข้อมูล S3 และ aws_s3_bucket_public_access_block ทรัพยากรในที่เก็บข้อมูลนั้นและหากคุณทำการเปลี่ยนแปลงบางอย่างในโค้ด Terraform ที่ทำลายที่เก็บข้อมูลนั้นด้วยเหตุผลบางประการเช่นใน 'การเปลี่ยนแปลงหมายถึงการลบและสร้าง' gotcha ที่อธิบายไว้ข้างต้น Terraform จะติดขัดเมื่อพยายามโหลด aws_s3_bucket_public_access_block แต่ล้มเหลวอย่างต่อเนื่องกับข้อผิดพลาดข้างต้น พฤติกรรมที่ถูกต้องจาก Terraform คือการแทนที่หรือลบ aws_s3_bucket_public_access_block ตามความเหมาะสม.
สุดท้ายนี้คุณไม่สามารถใช้สคริปต์ตัวช่วย CloudFormation กับ Terraform ได้ นี่อาจเป็นเรื่องที่น่ารำคาญโดยเฉพาะอย่างยิ่งหากคุณต้องการใช้ cfn-signal ซึ่งจะบอก CloudFormation ว่าอินสแตนซ์ EC2 ได้เริ่มต้นตัวเองเสร็จแล้วและพร้อมที่จะให้บริการตามคำขอ
Terraform ที่ฉลาดทางไวยากรณ์มีข้อได้เปรียบที่ดีเมื่อเทียบกับ CloudFormation - รองรับลูป แต่จากประสบการณ์ของตัวเองคุณลักษณะนี้อาจเป็นอันตรายได้เล็กน้อย โดยปกติแล้วการวนซ้ำจะถูกใช้เพื่อสร้างทรัพยากรที่เหมือนกันจำนวนมาก อย่างไรก็ตามเมื่อคุณต้องการอัปเดตสแต็กด้วยจำนวนที่แตกต่างกันอาจมีโอกาสที่คุณอาจต้องเชื่อมโยงทรัพยากรเก่าและทรัพยากรใหม่ (ตัวอย่างเช่นการใช้ zipmap() เพื่อรวมค่าจากสองอาร์เรย์ซึ่งเกิดขึ้นในขณะนี้ ให้มีขนาดแตกต่างกันเนื่องจากอาร์เรย์หนึ่งมีขนาดของขนาดลูปเก่าและอีกอันมีขนาดของขนาดลูปใหม่) เป็นเรื่องจริงที่ปัญหาดังกล่าวสามารถเกิดขึ้นได้โดยไม่ต้องวนซ้ำ แต่หากไม่มีการวนซ้ำปัญหาจะชัดเจนมากขึ้นสำหรับคนเขียนบท การใช้ลูปในกรณีเช่นนี้ทำให้ปัญหาสับสน
ไม่ว่าไวยากรณ์ของ Terraform หรือไวยากรณ์ของ CloudFormation จะดีกว่านั้นส่วนใหญ่เป็นคำถามเกี่ยวกับความชอบ CloudFormation ในตอนแรกรองรับเฉพาะ JSON แต่เทมเพลต JSON นั้นอ่านยากมาก โชคดีที่ CloudFormation รองรับ YAML ซึ่งอ่านและแสดงความคิดเห็นได้ง่ายกว่ามาก ไวยากรณ์ของ CloudFormation มีแนวโน้มที่จะค่อนข้างละเอียด
ไวยากรณ์ของ Terraform ใช้ HCL ซึ่งเป็นอนุพันธ์ JSON ชนิดหนึ่งและค่อนข้างแปลกประหลาด Terraform มีฟังก์ชันมากกว่า CloudFormation และโดยปกติแล้วจะง่ายกว่าที่จะเข้าใจ ดังนั้นจึงอาจเป็นที่ถกเถียงกันอยู่ว่า Terraform มีข้อได้เปรียบเล็กน้อยในประเด็นนี้
ข้อดีอีกอย่างของ Terraform คือชุดโมดูลที่ดูแลโดยชุมชนที่พร้อมใช้งานและทำให้เทมเพลตการเขียนง่ายขึ้น ปัญหาหนึ่งอาจเกิดจากโมดูลดังกล่าวอาจไม่ปลอดภัยเพียงพอที่จะปฏิบัติตามข้อกำหนดขององค์กร ดังนั้นสำหรับองค์กรที่ต้องการความปลอดภัยระดับสูงการตรวจสอบโมดูลเหล่านี้ (รวมถึงเวอร์ชันเพิ่มเติมตามที่มีมา) อาจเป็นสิ่งจำเป็น
โดยทั่วไปโมดูล Terraform มีความยืดหยุ่นมากกว่าสแต็กที่ซ้อนกันของ CloudFormation สแต็กที่ซ้อนกันของ CloudFormation มีแนวโน้มที่จะซ่อนทุกอย่างไว้ด้านล่าง จากสแต็กที่ซ้อนกันการดำเนินการอัปเดตจะแสดงว่าสแต็กที่ซ้อนกันจะได้รับการอัปเดต แต่จะไม่แสดงรายละเอียดว่าจะเกิดอะไรขึ้นภายในสแต็กที่ซ้อนกัน
ประเด็นสุดท้ายซึ่งอาจเป็นที่ถกเถียงกันอยู่ก็คือ CloudFormation พยายามย้อนกลับการปรับใช้ที่ล้มเหลว นี่เป็นคุณสมบัติที่ค่อนข้างน่าสนใจ แต่น่าเสียดายที่อาจใช้เวลานานมาก (เช่นอาจใช้เวลาถึงสามชั่วโมงกว่าที่ CloudFormation จะตัดสินใจว่าการปรับใช้กับ Elastic Container Service ล้มเหลว) ในทางตรงกันข้ามในกรณีของความล้มเหลว Terraform จะหยุดนิ่งไม่ว่าจะอยู่ที่ใดก็ตาม ไม่ว่าคุณลักษณะการย้อนกลับจะเป็นสิ่งที่ดีหรือไม่เป็นที่ถกเถียงกันอยู่ แต่ฉันต้องขอบคุณความจริงที่ว่าสแต็กได้รับการบำรุงรักษาให้อยู่ในสถานะใช้งานได้มากที่สุดเมื่อการรอนานกว่านั้นเป็นการแลกเปลี่ยนที่ยอมรับได้
Terraform มีข้อดีกว่า CloudFormation สิ่งที่สำคัญที่สุดในความคิดของฉันคือเมื่อใช้การอัปเดต Terraform จะแสดงให้คุณเห็น ทั้งหมด การเปลี่ยนแปลงที่คุณกำลังจะทำรวมถึงการเจาะลึกลงไปในโมดูลทั้งหมดที่ใช้อยู่ ในทางตรงกันข้าม CloudFormation เมื่อใช้สแต็กที่ซ้อนกันจะแสดงให้คุณเห็นว่าสแต็กที่ซ้อนกันนั้นต้องการการอัปเดตเท่านั้น แต่ไม่มีวิธีเจาะลึกลงไปในรายละเอียด ซึ่งอาจเป็นเรื่องที่น่าหงุดหงิดเนื่องจากข้อมูลประเภทนี้ค่อนข้างสำคัญที่ต้องรู้ก่อนกดปุ่ม 'ไป'
ทั้ง CloudFormation และ Terraform รองรับส่วนขยาย ใน CloudFormation คุณสามารถจัดการสิ่งที่เรียกว่า“ ทรัพยากรที่กำหนดเอง” ได้โดยใช้ฟังก์ชัน AWS Lambda ของการสร้างของคุณเองเป็นส่วนหลัง สำหรับ Terraform ส่วนขยายนั้นง่ายกว่ามากในการเขียนและเป็นส่วนหนึ่งของโค้ด ดังนั้นจึงมีข้อได้เปรียบสำหรับ Terraform ในกรณีนี้
Terraform สามารถรองรับผู้ค้าระบบคลาวด์จำนวนมาก สิ่งนี้ทำให้ Terraform อยู่ในตำแหน่งที่สามารถรวมการปรับใช้ที่กำหนดระหว่างแพลตฟอร์มคลาวด์หลาย ๆ แพลตฟอร์มได้ ตัวอย่างเช่นสมมติว่าคุณมีภาระงานเดียวที่กระจายระหว่าง AWS และ Google Cloud Platform (GCP) โดยปกติส่วน AWS ของเวิร์กโหลดจะถูกปรับใช้โดยใช้ CloudFormation และส่วน GCP โดยใช้ Cloud Deployment Manager ของ GCP ด้วย Terraform คุณสามารถใช้สคริปต์เดียวเพื่อปรับใช้และจัดการสแต็กทั้งสองในแพลตฟอร์มคลาวด์ของตนได้ ด้วยวิธีนี้คุณจะต้องปรับใช้เพียงกองเดียวแทนที่จะเป็นสองกอง
มีไม่กี่ข้อโต้แย้งที่ยังคงแพร่กระจายไปทั่วอินเทอร์เน็ต สิ่งที่ใหญ่ที่สุดคือเนื่องจาก Terraform เป็นระบบมัลติคลาวด์คุณสามารถใช้เครื่องมือเดียวในการปรับใช้โครงการทั้งหมดของคุณไม่ว่าจะทำในแพลตฟอร์มคลาวด์ใดก็ตาม ในทางเทคนิคนี่เป็นเรื่องจริง แต่ก็ไม่ใช่ข้อได้เปรียบใหญ่ที่ดูเหมือนจะเป็นโดยเฉพาะอย่างยิ่งเมื่อจัดการโครงการระบบคลาวด์เดี่ยวทั่วไป ความจริงก็คือแทบจะมีการติดต่อกันแบบหนึ่งต่อหนึ่งระหว่างทรัพยากรที่ประกาศใน (ตัวอย่าง) CloudFormation และทรัพยากรเดียวกันที่ประกาศในสคริปต์ Terraform เนื่องจากคุณต้องทราบรายละเอียดของทรัพยากรเฉพาะระบบคลาวด์ไม่ว่าจะด้วยวิธีใดความแตกต่างจึงเกิดขึ้นกับไวยากรณ์ซึ่งแทบจะไม่เป็นจุดเจ็บปวดที่ใหญ่ที่สุดในการจัดการการปรับใช้
บางคนโต้แย้งว่าการใช้ Terraform ทำให้เราสามารถหลีกเลี่ยงการล็อกอินของผู้ขายได้ อาร์กิวเมนต์นี้ไม่ถือในแง่ที่ว่าเมื่อใช้ Terraform คุณจะถูกล็อกโดย HashiCorp (ผู้สร้าง Terraform) ในลักษณะเดียวกับที่ใช้ CloudFormation AWS ล็อกคุณและอื่น ๆ สำหรับคลาวด์อื่น ๆ แพลตฟอร์ม
ความจริงที่ว่าโมดูล Terraform นั้นใช้งานง่ายกว่าสำหรับฉันแล้วมีความสำคัญน้อยกว่า ก่อนอื่นฉันเชื่อว่า AWS จงใจที่จะหลีกเลี่ยงการโฮสต์ที่เก็บเดียวสำหรับเทมเพลต CloudFormation ที่ใช้ชุมชนเนื่องจากรับรู้ถึงความรับผิดชอบต่อช่องโหว่ด้านความปลอดภัยที่ผู้ใช้สร้างขึ้นและการละเมิดโปรแกรมการปฏิบัติตามข้อกำหนดต่างๆ
ในระดับที่เป็นส่วนตัวมากขึ้นฉันเข้าใจถึงประโยชน์ของการใช้ไลบรารีในกรณีของการพัฒนาซอฟต์แวร์เนื่องจากไลบรารีเหล่านั้นสามารถทำงานในโค้ดนับหมื่นบรรทัดได้อย่างง่ายดาย อย่างไรก็ตามในกรณีของ IaC ขนาดของโค้ดมักจะน้อยกว่ามากและโมดูลดังกล่าวมักจะมีความยาวไม่กี่บรรทัด การใช้การคัดลอก / วางไม่ได้เป็นความคิดที่ไม่ดีในแง่ที่ว่าหลีกเลี่ยงปัญหาในการรักษาความเข้ากันได้และมอบหมายความปลอดภัยของคุณให้กับคนที่ไม่รู้จัก
การใช้การคัดลอก / วางนั้นถูกมองข้ามโดยนักพัฒนาและวิศวกร DevOps จำนวนมากและมีเหตุผลที่ดีอยู่เบื้องหลังนี้ อย่างไรก็ตามมุมมองของฉันคือการใช้การคัดลอก / วางสำหรับตัวอย่างโค้ดช่วยให้คุณปรับแต่งตามความต้องการของคุณได้อย่างง่ายดายและไม่จำเป็นต้องสร้างไลบรารีจากมันและใช้เวลาส่วนใหญ่เพื่อทำให้เป็นแบบทั่วไป ความเจ็บปวดในการดูแลรักษาส่วนย่อยของโค้ดเหล่านี้มักจะต่ำมากเว้นแต่ว่าโค้ดของคุณจะซ้ำกันในเทมเพลตหลายสิบแบบขึ้นไป ในกรณีเช่นนี้การกำหนดโค้ดให้เหมาะสมและใช้เป็นสแต็กที่ซ้อนกันเป็นเรื่องที่สมเหตุสมผลและประโยชน์ของการไม่ทำซ้ำตัวเองนั้นน่าจะมากกว่าความรำคาญที่ไม่สามารถเห็นสิ่งที่จะได้รับการอัปเดตภายในสแต็กที่ซ้อนกันเมื่อคุณทำการอัปเดต การดำเนินการ.
ด้วย CloudFormation AWS ต้องการมอบเครื่องมือที่แข็งแกร่งให้กับลูกค้าซึ่งจะทำงานได้ตามที่ตั้งใจไว้ตลอดเวลา แน่นอนว่าทีมของ Terraform ก็เช่นกัน แต่ดูเหมือนว่าสิ่งสำคัญของการใช้เครื่องมือการจัดการการพึ่งพาของพวกเขานั้นไม่ใช่สิ่งสำคัญ
Terraform อาจมีสถานที่ในโครงการของคุณโดยเฉพาะอย่างยิ่งหากคุณมีสถาปัตยกรรมแบบมัลติคลาวด์ซึ่งในกรณีนี้สคริปต์ Terraform เป็นวิธีหนึ่งในการรวมการจัดการทรัพยากรในผู้ให้บริการคลาวด์ต่างๆที่คุณใช้อยู่ แต่คุณยังคงสามารถหลีกเลี่ยงข้อเสียของ Terraform ได้ในกรณีนี้โดยใช้ Terraform เพื่อจัดการสแต็กที่ใช้งานแล้วโดยใช้เครื่องมือ IaC เฉพาะระบบคลาวด์ตามลำดับ
ความรู้สึกโดยรวม Terraform เทียบกับ CloudFormation ก็คือ CloudFormation แม้ว่าจะไม่สมบูรณ์แบบ แต่ก็มีความเป็นมืออาชีพและเชื่อถือได้มากกว่าและฉันอยากจะแนะนำอย่างแน่นอนสำหรับโครงการใด ๆ ที่ไม่ใช่ระบบมัลติคลาวด์โดยเฉพาะ
CloudFormation เป็นซอฟต์แวร์โครงสร้างพื้นฐานเป็นรหัส (IaC) อย่างเป็นทางการสำหรับ Amazon Web Services CloudFormation ดำเนินการสร้างอัปเดตและลบทรัพยากร AWS โดยอัตโนมัติ นอกจากนี้ CloudFormation ยังให้สิทธิ์แบบละเอียดและสามารถย้อนกลับการปรับใช้ที่ล้มเหลวได้
CloudFormation สามารถใช้เพื่อดำเนินการสร้างอัปเดตและลบทรัพยากร AWS โดยอัตโนมัติตามสคริปต์ สิ่งนี้ช่วยให้การจัดทำเอกสารโครงสร้างพื้นฐานการกำหนดเวอร์ชันและการจัดเก็บโครงสร้างพื้นฐานเป็นชุดของไฟล์ข้อความความสามารถในการทำซ้ำในบัญชีและสภาพแวดล้อมและการปรับใช้อย่างต่อเนื่อง
องค์ประกอบหลักของ CloudFormation ได้แก่ : เทมเพลต CloudFormation (สคริปต์ที่เปิดเผยซึ่งกำหนดโครงสร้างพื้นฐานที่ควรเป็น) สแต็ก (อินสแตนซ์ของเทมเพลต CloudFormation ที่สามารถซ้อนกันได้) และ StackSets (ซึ่งช่วยให้คุณจัดการสแต็ก CloudFormation ในบัญชีและภูมิภาคต่างๆได้)
Terraform และ CloudFormation เป็นเครื่องมือโครงสร้างพื้นฐานเป็นรหัส (IaC) CloudFormation พัฒนาโดย AWS และจัดการทรัพยากร AWS เท่านั้น Terraform ได้รับการพัฒนาโดย HashiCorp และสามารถจัดการทรัพยากรจากผู้ค้าระบบคลาวด์ที่หลากหลาย
CloudFormation ดีกว่า Terraform สำหรับปริมาณงานการผลิตที่ จำกัด เฉพาะ AWS เหตุผลหลักคือในบางสถานการณ์ Terraform ไม่ได้จัดการกับการอ้างอิงอย่างถูกต้องและกฎนี้ออกมาเป็นซอฟต์แวร์โครงสร้างพื้นฐานเป็นรหัส (IaC) ที่พร้อมใช้งานจริง
Terraform เป็นเครื่องมือโครงสร้างพื้นฐานเป็นรหัส (IaC) และด้วยเหตุนี้จึงใช้เพื่อสร้างและจัดการทรัพยากรระบบคลาวด์โดยอัตโนมัติ คุณสมบัติที่โดดเด่นของ Terraform คือรองรับแพลตฟอร์มคลาวด์ที่หลากหลาย
Terraform เป็นซอฟต์แวร์โครงสร้างพื้นฐานเป็นรหัส (IaC) ที่สร้างโดย HashiCorp เขียนด้วยภาษา Golang และเปิดตัวครั้งแรกในปี 2014 Terraform เป็นซอฟต์แวร์โอเพนซอร์สฟรี
ใช่ Terraform เป็นเครื่องมือ DevOps เป็นซอฟต์แวร์โครงสร้างพื้นฐานเป็นรหัส (IaC) และซอฟต์แวร์ดังกล่าวเป็นส่วนสำคัญของกลยุทธ์ในการปรับใช้โดยอัตโนมัติ
