Terraform vs. CloudFormation: The Definitive Guide

ถ้าคุณค้นหาอินเทอร์เน็ตเพื่อช่วยคุณเลือกระหว่าง CloudFormation และ Terraform เป็นเครื่องมือแบบโครงสร้างพื้นฐาน (Infrastructure-as-code) (IaC) ตัวถัดไปของคุณโดยที่คุณไม่ได้ค้นหาคำตอบที่แน่ชัด เช่นเดียวกับฉัน หากคุณไม่ได้ค้นหาคำตอบที่แน่ชัด ฉันก็แบ่งปันความเจ็บปวดของคุณมาสักพักแล้ว ตอนนี้ ฉันมีประสบการณ์ที่สำคัญกับทั้งสองเครื่องมือ และฉันสามารถตัดสินใจได้อย่างมีข้อมูลว่าควรใช้เครื่องมือใด

การแยกความแตกต่างระหว่างโค้ดและการสร้างอินสแตนซ์

ข้อแตกต่างอย่างหนึ่งระหว่าง CloudFormation และ Terraform คือความเกี่ยวข้องของโค้ดและการสร้างอินสแตนซ์ภายในแต่ละบริการ

CloudFormation มีแนวคิดของ stack ซึ่งเป็นการสร้างอินสแตนซ์ของเทมเพลต เทมเพลตเดียวกันสามารถสร้างอินสแตนซ์ ad infinitum โดยลูกค้าที่กำหนดในบัญชีที่กำหนด ข้ามบัญชี หรือโดยลูกค้าที่แตกต่างกัน

Terraform ไม่มีแนวคิดดังกล่าวและต้องการความสัมพันธ์แบบหนึ่งต่อหนึ่งระหว่างโค้ดกับการสร้างอินสแตนซ์ มันจะคล้ายกับการทำซ้ำซอร์สโค้ดของเว็บเซิร์ฟเวอร์สำหรับแต่ละเซิร์ฟเวอร์ที่คุณต้องการเรียกใช้ หรือการทำซ้ำโค้ดทุกครั้งที่คุณจำเป็นต้องเรียกใช้แอปพลิเคชัน แทนที่จะเรียกใช้เวอร์ชันที่คอมไพล์แล้ว

ประเด็นนี้ค่อนข้างไม่สำคัญในกรณีของการตั้งค่าง่ายๆ แต่จะกลายเป็นจุดปวดที่สำคัญสำหรับการดำเนินการขนาดกลางถึงขนาดใหญ่อย่างรวดเร็ว ใน Terraform ทุกครั้งที่คุณจำเป็นต้องสร้างสแต็คใหม่จากโค้ดที่มีอยู่ คุณจะต้องทำซ้ำโค้ด และการคัดลอก/วางไฟล์สคริปต์เป็นวิธีที่ง่ายมากในการก่อวินาศกรรมและทำลายทรัพยากรที่คุณไม่ได้ตั้งใจจะสัมผัส

ที่จริงแล้ว Terraform ไม่มีแนวคิดเรื่อง สแต็ก อย่าง CloudFormation ซึ่งแสดงให้เห็นชัดเจนว่า Terraform ได้รับการสร้างขึ้นจากพื้นฐานเพื่อให้มีการจับคู่แบบหนึ่งต่อหนึ่งระหว่างโค้ดและทรัพยากรที่จัดการ ภายหลังได้รับการแก้ไขบางส่วนโดยแนวคิดเรื่อง สภาพแวดล้อม (ซึ่งนับตั้งแต่นั้นมาเปลี่ยนชื่อเป็น "พื้นที่ทำงาน") แต่วิธีการใช้สิ่งเหล่านั้นทำให้ง่ายต่อการปรับใช้ในสภาพแวดล้อมที่ไม่ต้องการอย่างเหลือเชื่อ เนื่องจากคุณต้องเรียกใช้การ terraform workspace select ก่อนที่จะปรับใช้ และการลืมขั้นตอนนี้จะทำให้ใช้งานได้กับพื้นที่ทำงานที่เลือกไว้ก่อนหน้านี้ ซึ่งอาจใช่หรือไม่ใช่สิ่งที่คุณต้องการก็ได้

ในทางปฏิบัติ ปัญหานี้บรรเทาได้ด้วยการใช้โมดูล Terraform แต่ในกรณีที่ดีที่สุด คุณจะต้องใช้รหัสสำเร็จรูปจำนวนมาก อันที่จริง ปัญหานี้รุนแรงมากจนผู้คนจำเป็นต้องสร้างเครื่องมือห่อหุ้มรอบ Terraform เพื่อแก้ไขปัญหานี้: Terragrunt

การจัดการและการอนุญาตของรัฐ

ข้อแตกต่างที่สำคัญอีกประการระหว่าง CloudFormation และ Terraform คือวิธีที่แต่ละส่วนจัดการสถานะและการอนุญาต

CloudFormation จัดการสถานะสแต็กให้กับคุณและไม่ได้ให้ตัวเลือกใดๆ แก่คุณ แต่สถานะสแต็ก CloudFormation นั้นแข็งแกร่งในประสบการณ์ของฉัน นอกจากนี้ CloudFormation ยังช่วยให้ผู้ใช้ที่มีสิทธิพิเศษน้อยกว่าสามารถจัดการสแต็กได้โดยไม่ต้องมีสิทธิ์ที่จำเป็นทั้งหมดที่สแต็กต้องการ ทั้งนี้เนื่องจาก CloudFormation สามารถรับสิทธิ์จากบทบาทบริการที่แนบมากับสแตก แทนที่จะได้รับสิทธิ์จากผู้ใช้ที่เรียกใช้การดำเนินการสแต็ก

Terraform ต้องการให้คุณจัดเตรียมแบ็คเอนด์บางส่วนเพื่อจัดการสถานะ ค่าดีฟอลต์คือไฟล์ในเครื่อง ซึ่งไม่น่าพอใจโดยสิ้นเชิง โดยให้:

1. ความทนทานของไฟล์สถานะของคุณเชื่อมโยงกับความทนทานของเครื่องที่จัดเก็บไว้ทั้งหมด
2. นั่นทำให้การทำงานเป็นทีมเป็นไปไม่ได้

ดังนั้น คุณจึงต้องมีสถานะที่แข็งแกร่งและมีการแบ่งปัน ซึ่งโดยปกติแล้วบน 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 เป็นเครื่องมือบรรทัดคำสั่ง แต่ก็ชัดเจนมากว่ามันคาดหวังให้มนุษย์เรียกใช้มัน เพราะมันมีการโต้ตอบกันอย่างมาก เป็นไปได้ที่จะเรียกใช้ในโหมดแบตช์ (เช่น จากสคริปต์) แต่ต้องมีอาร์กิวเมนต์บรรทัดคำสั่งเพิ่มเติม ความจริงที่ว่า Terraform ได้รับการพัฒนาให้ทำงานโดยมนุษย์โดยค่าเริ่มต้นนั้นค่อนข้างทำให้งง เนื่องจากจุดประสงค์ของเครื่องมือ IaC คือระบบอัตโนมัติ

Terraform นั้นยากต่อการดีบัก ข้อความแสดงข้อผิดพลาดมักเป็นข้อความพื้นฐานและไม่อนุญาตให้คุณเข้าใจว่าเกิดอะไรขึ้น ในกรณีนี้ คุณจะต้องเรียกใช้ Terraform ด้วย TF_LOG=debug ซึ่งสร้างเอาต์พุตจำนวนมากเพื่อสืบค้น ทำให้เกิดความซับซ้อนในบางครั้ง Terraform ทำให้การเรียก API ไปยัง AWS ที่ล้มเหลวในบางครั้ง แต่ความล้มเหลวไม่ใช่ปัญหากับ Terraform ในทางตรงกันข้าม CloudFormation จะแสดงข้อความแสดงข้อผิดพลาดที่ชัดเจนพอสมควรพร้อมรายละเอียดที่เพียงพอเพื่อให้คุณเข้าใจว่าปัญหาอยู่ที่ไหน

ตัวอย่างข้อความแสดงข้อผิดพลาด Terraform:

 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 ที่ทำลายบัคเก็ตนั้นด้วยเหตุผลบางอย่าง เช่น ใน "การเปลี่ยนแปลงหมายถึงการลบและสร้าง" ก็อตชาที่อธิบายข้างต้น— 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 สิ่งที่สำคัญที่สุดในความคิดของฉันคือ เมื่อใช้การอัปเดต 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 เป็นแบบมัลติคลาวด์ คุณสามารถใช้เครื่องมือเดียวในการปรับใช้โครงการทั้งหมดของคุณ ไม่ว่าพวกเขาจะทำบนแพลตฟอร์มคลาวด์ใดก็ตาม ในทางเทคนิค สิ่งนี้เป็นความจริง แต่ก็ไม่ใช่ข้อได้เปรียบที่ใหญ่หลวงนัก โดยเฉพาะอย่างยิ่งเมื่อจัดการโปรเจ็กต์ระบบคลาวด์เดียวทั่วไป ความจริงก็คือมีความสอดคล้องกันเกือบหนึ่งต่อหนึ่งระหว่างทรัพยากรที่ประกาศใน (เช่น) CloudFormation และทรัพยากรเดียวกันที่ประกาศในสคริปต์ Terraform เนื่องจากคุณต้องทราบรายละเอียดของทรัพยากรเฉพาะบนคลาวด์ไม่ว่าจะด้วยวิธีใด ความแตกต่างจึงอยู่ที่ไวยากรณ์ ซึ่งแทบจะไม่เป็นปัญหาใหญ่ที่สุดในการจัดการการปรับใช้

บางคนโต้แย้งว่าการใช้ Terraform สามารถหลีกเลี่ยงการล็อคอินของผู้ขายได้ อาร์กิวเมนต์นี้ไม่ได้มีความหมายว่าการใช้ Terraform คุณถูกล็อคโดย HashiCorp (ผู้สร้าง Terraform) เช่นเดียวกับการใช้ CloudFormation คุณถูกล็อคโดย AWS และอื่นๆ สำหรับคลาวด์อื่น แพลตฟอร์ม

ความจริงที่ว่าโมดูล Terraform ใช้งานง่ายกว่าสำหรับฉันมีความสำคัญน้อยกว่า ก่อนอื่น ฉันเชื่อว่า AWS ตั้งใจหลีกเลี่ยงการโฮสต์ที่เก็บเดียวสำหรับเทมเพลต CloudFormation แบบชุมชน เนื่องจากการรับรู้ความรับผิดชอบต่อช่องโหว่ด้านความปลอดภัยที่ผู้ใช้สร้างขึ้นและการละเมิดโปรแกรมการปฏิบัติตามข้อกำหนดต่างๆ

ในระดับที่เป็นส่วนตัวมากขึ้น ฉันเข้าใจถึงประโยชน์ของการใช้ไลบรารีในกรณีของการพัฒนาซอฟต์แวร์อย่างถ่องแท้ เนื่องจากไลบรารีเหล่านั้นสามารถเรียกใช้โค้ดหลายหมื่นบรรทัดได้อย่างง่ายดาย อย่างไรก็ตาม ในกรณีของ IaC ขนาดของโค้ดมักจะน้อยกว่ามาก และโมดูลดังกล่าวมักจะยาวสองสามโหล การใช้การคัดลอก/วางจริงๆ แล้วไม่ใช่ความคิดที่แย่ในแง่ที่ว่ามันจะหลีกเลี่ยงปัญหาในการรักษาความเข้ากันได้และการมอบความปลอดภัยของคุณให้กับบุคคลที่ไม่รู้จัก

นักพัฒนาและวิศวกร DevOps หลายคนไม่เห็นด้วยกับการใช้การคัดลอก/วาง และมีเหตุผลดีๆ อยู่เบื้องหลัง อย่างไรก็ตาม มุมมองของฉันคือการใช้การคัดลอก/วางสำหรับส่วนย่อยของโค้ดช่วยให้คุณปรับแต่งให้เข้ากับความต้องการของคุณได้อย่างง่ายดาย และไม่จำเป็นต้องสร้างไลบรารี่ขึ้นมาและใช้เวลามากในการทำให้เป็นแบบทั่วไป ความเจ็บปวดในการเก็บรักษาข้อมูลโค้ดเหล่านั้นมักจะต่ำมาก เว้นแต่โค้ดของคุณจะซ้ำซ้อนในเทมเพลตหลายสิบแบบขึ้นไป ในกรณีเช่นนี้ การปรับโค้ดให้เหมาะสมและใช้เป็นสแต็กที่ซ้อนกันนั้นสมเหตุสมผล และประโยชน์ของการไม่ซ้ำรอยอาจมากกว่าความรำคาญที่ไม่สามารถดูว่ามีอะไรให้อัปเดตภายในสแต็กที่ซ้อนกันเมื่อคุณทำการอัปเดต การดำเนินการ.

CloudFormation กับ Terraform Conclusion

ด้วย CloudFormation AWS ต้องการให้ลูกค้ามีเครื่องมือที่แข็งแกร่งซึ่งจะทำงานตามที่ตั้งใจไว้ตลอดเวลา แน่นอนว่าทีมของ Terraform ก็เช่นกัน—แต่ดูเหมือนว่าแง่มุมที่สำคัญของเครื่องมือ การจัดการการพึ่งพาของพวกเขานั้นไม่น่ามีความสำคัญ

Terraform อาจมีที่ในโปรเจ็กต์ของคุณ โดยเฉพาะอย่างยิ่งหากคุณมีสถาปัตยกรรมมัลติ-คลาวด์ ซึ่งในกรณีนี้ สคริปต์ Terraform เป็นวิธีหนึ่งในการรวมการจัดการทรัพยากรจากผู้จำหน่ายคลาวด์ต่างๆ ที่คุณใช้เป็นอันหนึ่งอันเดียวกัน แต่คุณยังสามารถหลีกเลี่ยงข้อเสียของ Terraform ได้ในกรณีนี้โดยใช้ Terraform เพื่อจัดการสแต็กที่นำไปใช้แล้วโดยใช้เครื่องมือ IaC เฉพาะบนคลาวด์ที่เกี่ยวข้องเท่านั้น

ความรู้สึกโดยรวมของ Terraform กับ CloudFormation คือ CloudFormation แม้ว่าจะไม่สมบูรณ์ แต่ก็มีความเป็นมืออาชีพและเชื่อถือได้มากกว่า และฉันอยากจะแนะนำอย่างแน่นอนสำหรับโครงการใดๆ ที่ไม่ใช่มัลติ-คลาวด์โดยเฉพาะ