ฉันอยู่ระหว่างการเปลี่ยนโครงสร้างพื้นฐานของเราให้กลายเป็นพื้นดิน แนวทางปฏิบัติที่ดีที่สุดในการจัดการไฟล์ Terraform และสถานะคืออะไร? ฉันรู้ว่าโครงสร้างพื้นฐานเป็นรหัสและฉันจะส่งไฟล์. tf ของฉันไปยัง git แต่ฉันจะผูกมัด tfstate ด้วยหรือไม่ ควรอยู่ที่ไหนสักแห่งเช่น S3 หรือไม่? ในที่สุดฉันก็ต้องการให้ CI จัดการทั้งหมดนี้ แต่มันยืดออกไปไกลและต้องการให้ฉันคิดหาชิ้นส่วนที่เคลื่อนไหวสำหรับไฟล์
ฉันแค่ต้องการดูว่าผู้คนที่นั่นใช้ประโยชน์จากสิ่งประเภทนี้ในการผลิตได้อย่างไร
คำตอบ:
ฉันยังอยู่ในสถานะของการย้ายโครงสร้างพื้นฐาน AWS ที่มีอยู่ไปยัง Terraform ดังนั้นฉันจะพยายามอัปเดตคำตอบเมื่อฉันพัฒนา
ฉันพึ่งพาตัวอย่าง Terraform อย่างเป็นทางการและการทดลองและข้อผิดพลาดหลายครั้งเพื่อดึงประเด็นที่ฉันไม่แน่ใจออกมา
.tfstate ไฟล์
สามารถใช้การกำหนดค่า Terraform เพื่อจัดเตรียมกล่องจำนวนมากบนโครงสร้างพื้นฐานที่แตกต่างกันซึ่งแต่ละกล่องอาจมีสถานะที่แตกต่างกัน เนื่องจากสามารถดำเนินการโดยคนหลายคนสถานะนี้ควรอยู่ในตำแหน่งที่รวมศูนย์ (เช่น S3) แต่ไม่ใช่คอมไพล์
นี้สามารถยืนยันได้มองหาที่ .gitignoreterraform
การควบคุมของนักพัฒนา
เป้าหมายของเราคือให้การควบคุมโครงสร้างพื้นฐานแก่นักพัฒนามากขึ้นในขณะที่รักษาการตรวจสอบทั้งหมด (บันทึกคอมไพล์) และความสามารถในการตรวจสอบการเปลี่ยนแปลง (คำขอดึง) ด้วยเหตุนี้เวิร์กโฟลว์โครงสร้างพื้นฐานใหม่ที่ฉันตั้งเป้าไว้คือ:
แก้ไข 1 - อัปเดตสถานะปัจจุบัน
ตั้งแต่เริ่มคำตอบนี้ฉันได้เขียนรหัส TF จำนวนมากและรู้สึกสบายใจมากขึ้นในสถานการณ์ของเรา เราพบข้อบกพร่องและข้อ จำกัด ระหว่างทาง แต่ฉันยอมรับว่านี่เป็นลักษณะของการใช้ซอฟต์แวร์ใหม่ที่เปลี่ยนแปลงอย่างรวดเร็ว
เค้าโครง
เรามีโครงสร้างพื้นฐาน AWS ที่ซับซ้อนพร้อมด้วย VPC หลายตัวแต่ละตัวมีเครือข่ายย่อยหลายเครือข่าย กุญแจสำคัญในการจัดการสิ่งนี้อย่างง่ายดายคือการกำหนดอนุกรมวิธานที่ยืดหยุ่นซึ่งครอบคลุมภูมิภาคสภาพแวดล้อมบริการและเจ้าของซึ่งเราสามารถใช้เพื่อจัดระเบียบรหัสโครงสร้างพื้นฐานของเรา (ทั้งพื้นดินและหุ่น)
โมดูล
ขั้นตอนต่อไปคือการสร้างที่เก็บ git เดียวเพื่อจัดเก็บโมดูล Terraform ของเรา โครงสร้าง dir ระดับบนสุดของเราสำหรับโมดูลมีลักษณะดังนี้:
tree -L 1 .ผลลัพธ์:
├── README.md
├── aws-asg
├── aws-ec2
├── aws-elb
├── aws-rds
├── aws-sg
├── aws-vpc
└── templatesแต่ละคนตั้งค่าเริ่มต้นที่ดี แต่แสดงให้เห็นว่าเป็นตัวแปรที่ "กาว" ของเราสามารถเขียนทับได้
กาว
เรามีที่เก็บข้อมูลที่สองglueซึ่งใช้ประโยชน์จากโมดูลที่กล่าวถึงข้างต้น วางไว้ตามเอกสารอนุกรมวิธานของเรา:
.
├── README.md
├── clientA
│ ├── eu-west-1
│ │ └── dev
│ └── us-east-1
│ └── dev
├── clientB
│ ├── eu-west-1
│ │ ├── dev
│ │ ├── ec2-keys.tf
│ │ ├── prod
│ │ └── terraform.tfstate
│ ├── iam.tf
│ ├── terraform.tfstate
│ └── terraform.tfstate.backup
└── clientC
├── eu-west-1
│ ├── aws.tf
│ ├── dev
│ ├── iam-roles.tf
│ ├── ec2-keys.tf
│ ├── prod
│ ├── stg
│ └── terraform.tfstate
└── iam.tfภายในระดับไคลเอนต์เรามี.tfไฟล์เฉพาะของบัญชี AWS ที่จัดเตรียมทรัพยากรทั่วโลก (เช่นบทบาท IAM) ต่อไปคือระดับภูมิภาคที่มีคีย์สาธารณะ EC2 SSH สุดท้ายในสภาพแวดล้อมของเรา ( dev, stg, prodฯลฯ ) จะ VPC การตั้งค่าการสร้างอินสแตนซ์และ peering การเชื่อมต่อของเรา ฯลฯ จะถูกเก็บไว้
หมายเหตุด้านข้าง:อย่างที่คุณเห็นฉันกำลังต่อต้านคำแนะนำของตัวเองข้างต้นterraform.tfstateในการคอมไพล์ นี่เป็นมาตรการชั่วคราวจนกว่าฉันจะย้ายไปใช้ S3 แต่เหมาะกับฉันเพราะตอนนี้ฉันเป็นนักพัฒนาเพียงคนเดียว
ขั้นตอนถัดไป
นี่ยังคงเป็นกระบวนการแบบแมนนวลและยังไม่ได้อยู่ใน Jenkins แต่เรากำลังย้ายโครงสร้างพื้นฐานที่ค่อนข้างใหญ่ซับซ้อนและจนถึงตอนนี้ก็ดี อย่างที่บอกข้อบกพร่องน้อย แต่ไปได้ดี!
แก้ไข 2 - การเปลี่ยนแปลง
เป็นเวลาเกือบหนึ่งปีแล้วที่ฉันเขียนคำตอบเริ่มต้นนี้และสถานะของ Terraform และตัวฉันเองก็เปลี่ยนไปอย่างมาก ตอนนี้ฉันในตำแหน่งใหม่โดยใช้ terraform การจัดการคลัสเตอร์ Azure และ terraform v0.10.7อยู่ในขณะนี้
สถานะ
มีคนบอกฉันหลายครั้งว่าไม่ควรเข้า Git - และถูกต้อง เราใช้สิ่งนี้เป็นมาตรการชั่วคราวกับทีมงานสองคนที่อาศัยการสื่อสารและระเบียบวินัยของนักพัฒนา ด้วยทีมงานที่มีขนาดใหญ่ขึ้นเราจึงใช้ประโยชน์จากสถานะระยะไกลใน S3 ได้อย่างเต็มที่ด้วยการล็อกโดย DynamoDB ตามหลักการแล้วสิ่งนี้จะถูกย้ายไปที่กงสุลตอนนี้เป็น v1.0 เพื่อตัดผู้ให้บริการคลาวด์ข้าม
โมดูล
ก่อนหน้านี้เราได้สร้างและใช้โมดูลภายใน ยังคงเป็นเช่นนั้น แต่ด้วยการถือกำเนิดและการเติบโตของรีจิสทรี Terraformเราจึงพยายามใช้สิ่งเหล่านี้เป็นฐานอย่างน้อยที่สุด
โครงสร้างไฟล์
ตำแหน่งใหม่มีอนุกรมวิธานง่ายมากมีเพียงสองสภาพแวดล้อม infx - และdev prodแต่ละตัวมีตัวแปรและเอาต์พุตของตัวเองโดยนำโมดูลของเราที่สร้างไว้ด้านบนกลับมาใช้ใหม่ remote_stateผู้ให้บริการยังช่วยในการเอาท์พุทใช้ทรัพยากรร่วมกันสร้างขึ้นระหว่างสภาพแวดล้อม สถานการณ์ของเราคือโดเมนย่อยในกลุ่มทรัพยากร Azure ที่แตกต่างกันไปจนถึง TLD ที่มีการจัดการทั่วโลก
├── main.tf
├── dev
│ ├── main.tf
│ ├── output.tf
│ └── variables.tf
└── prod
├── main.tf
├── output.tf
└── variables.tfการวางแผน
อีกครั้งด้วยความท้าทายพิเศษของทีมแบบกระจายตอนนี้เราบันทึกผลลัพธ์ของterraform planคำสั่งไว้เสมอ เราสามารถตรวจสอบและรู้ว่าจะดำเนินการอะไรโดยไม่ต้องเสี่ยงกับการเปลี่ยนแปลงบางอย่างระหว่างขั้นตอนplanและapplyขั้นตอน (แม้ว่าการล็อกจะช่วยในเรื่องนี้ก็ตาม) อย่าลืมลบไฟล์แผนนี้เนื่องจากอาจมีตัวแปร "ความลับ" ที่เป็นข้อความธรรมดา
โดยรวมแล้วเรามีความสุขมากกับ Terraform และยังคงเรียนรู้และปรับปรุงคุณสมบัติใหม่ที่เพิ่มเข้ามา
เราใช้ Terraform อย่างหนักและการตั้งค่าที่เราแนะนำมีดังต่อไปนี้:
เราขอแนะนำอย่างยิ่งให้จัดเก็บโค้ด Terraform สำหรับแต่ละสภาพแวดล้อมของคุณ (เช่น stage, prod, qa) ในชุดเทมเพลตแยกกัน (และ.tfstateไฟล์แยกกัน) นี่เป็นสิ่งสำคัญเพื่อให้สภาพแวดล้อมที่แยกจากกันของคุณถูกแยกออกจากกันในขณะที่ทำการเปลี่ยนแปลง มิฉะนั้นในขณะที่กำลังส่งรหัสบางอย่างในการจัดเตรียมการจัดเตรียมบางอย่างก็ง่ายเกินไป ดูTerraform, VPC และเหตุผลที่คุณต้องการไฟล์ tfstate ต่อ envเพื่อการสนทนาที่มีสีสันว่าทำไม
ดังนั้นเค้าโครงไฟล์ทั่วไปของเราจึงมีลักษณะดังนี้:
stage
└ main.tf
└ vars.tf
└ outputs.tf
prod
└ main.tf
└ vars.tf
└ outputs.tf
global
└ main.tf
└ vars.tf
└ outputs.tfรหัส Terraform ทั้งหมดสำหรับขั้นตอน VPC จะเข้าไปในstageโฟลเดอร์รหัสทั้งหมดสำหรับ prod VPC จะเข้าไปในprodโฟลเดอร์และรหัสทั้งหมดที่อยู่นอก VPC (เช่นผู้ใช้ IAM หัวข้อ SNS ถัง S3) จะเข้าไปในglobalโฟลเดอร์ .
โปรดทราบว่าโดยปกติแล้วเราจะแบ่งโค้ด Terraform ออกเป็น 3 ไฟล์:
vars.tf: ตัวแปรอินพุตoutputs.tf: ตัวแปรเอาต์พุตmain.tf: ทรัพยากรที่แท้จริงโดยทั่วไปเรากำหนดโครงสร้างพื้นฐานของเราในสองโฟลเดอร์:
infrastructure-modules: โฟลเดอร์นี้มีโมดูลขนาดเล็กที่ใช้ซ้ำได้ ให้คิดว่าแต่ละโมดูลเป็นพิมพ์เขียวสำหรับวิธีสร้างโครงสร้างพื้นฐานชิ้นเดียวเช่น VPC หรือฐานข้อมูลinfrastructure-live: โฟลเดอร์นี้มีโครงสร้างพื้นฐานที่ใช้งานจริงซึ่งสร้างขึ้นโดยการรวมโมดูลเข้าinfrastructure-modulesด้วยกัน คิดว่ารหัสในโฟลเดอร์นี้เป็นบ้านจริงที่คุณสร้างจากพิมพ์เขียวของคุณโมดูล terraformเป็นเพียงชุดใด ๆ ของแม่ terraform ในโฟลเดอร์ ยกตัวอย่างเช่นเราอาจจะมีโฟลเดอร์ที่เรียกว่าvpcในinfrastructure-modulesกำหนดว่าทุกตารางเส้นทางเครือข่ายย่อยเกตเวย์ ACLs ฯลฯ สำหรับ VPC เดียว:
infrastructure-modules
└ vpc
└ main.tf
└ vars.tf
└ outputs.tfจากนั้นเราสามารถใช้โมดูลนั้นในinfrastructure-live/stageและinfrastructure-live/prodเพื่อสร้างสเตจและผลิต VPCs ตัวอย่างเช่นนี่คือสิ่งที่infrastructure-live/stage/main.tfอาจมีลักษณะดังนี้:
module "stage_vpc" {
source = "git::git@github.com:gruntwork-io/module-vpc.git//modules/vpc-app?ref=v0.0.4"
vpc_name = "stage"
aws_region = "us-east-1"
num_nat_gateways = 3
cidr_block = "10.2.0.0/18"
}ในการใช้โมดูลคุณใช้moduleทรัพยากรและชี้sourceฟิลด์ไปที่เส้นทางภายในฮาร์ดไดรฟ์ของคุณ (เช่นsource = "../infrastructure-modules/vpc") หรือตามตัวอย่างข้างต้นคือ Git URL (ดูที่มาของโมดูล ) ข้อดีของ Git URL คือเราสามารถระบุ git sha1 หรือ tag ( ref=v0.0.4) ที่เฉพาะเจาะจงได้ ตอนนี้เราไม่เพียง แต่กำหนดโครงสร้างพื้นฐานของเราเป็นโมดูลขนาดเล็กจำนวนมากเท่านั้น แต่เราสามารถสร้างเวอร์ชันของโมดูลเหล่านั้นและอัปเดตหรือย้อนกลับอย่างระมัดระวังได้ตามต้องการ
เราได้สร้างชุดโครงสร้างพื้นฐานที่ใช้ซ้ำได้ทดสอบและจัดทำเป็นเอกสารจำนวนมากสำหรับการสร้าง VPCs คลัสเตอร์ Docker ฐานข้อมูลและอื่น ๆ และภายใต้ประทุนนั้นส่วนใหญ่เป็นเพียงโมดูล Terraform เวอร์ชัน
เมื่อคุณใช้ Terraform เพื่อสร้างทรัพยากร (เช่นอินสแตนซ์ EC2, ฐานข้อมูล, VPCs) จะบันทึกข้อมูลเกี่ยวกับสิ่งที่สร้างขึ้นใน.tfstateไฟล์ ในการเปลี่ยนแปลงทรัพยากรเหล่านั้นทุกคนในทีมของคุณจำเป็นต้องเข้าถึง.tfstateไฟล์เดียวกันนี้แต่คุณไม่ควรตรวจสอบใน Git (ดูคำอธิบายที่นี่สำหรับคำอธิบาย )
แต่ขอแนะนำให้จัดเก็บ.tfstateไฟล์ใน S3 โดยเปิดใช้งานTerraform Remote Stateซึ่งจะผลัก / ดึงไฟล์ล่าสุดโดยอัตโนมัติทุกครั้งที่คุณเรียกใช้ Terraform ตรวจสอบให้แน่ใจว่าได้เปิดใช้งานการกำหนดเวอร์ชันในที่เก็บข้อมูล S3 ของคุณเพื่อให้คุณสามารถย้อนกลับไปใช้.tfstateไฟล์รุ่นเก่าได้ในกรณีที่เวอร์ชันล่าสุดเสียหาย อย่างไรก็ตามหมายเหตุสำคัญ: terraform ไม่ได้ให้ล็อค ดังนั้นหากสมาชิกในทีมสองคนทำงานterraform applyพร้อมกันใน.tfstateไฟล์เดียวกันพวกเขาอาจเขียนทับการเปลี่ยนแปลงของกันและกัน
เพื่อแก้ปัญหานี้เราได้สร้างเครื่องมือโอเพนซอร์สที่เรียกว่าTerragruntซึ่งเป็นกระดาษห่อหุ้มแบบบางสำหรับ Terraform ที่ใช้ Amazon DynamoDB ในการล็อก (ซึ่งควรจะฟรีสำหรับทีมส่วนใหญ่) ตรวจสอบเพิ่มการล็อกสถานะระยะไกลอัตโนมัติและการกำหนดค่าไปยัง Terraform ด้วย Terragruntสำหรับข้อมูลเพิ่มเติม
เราเพิ่งเริ่มบล็อกโพสต์ชุดหนึ่งชื่อคำแนะนำที่ครอบคลุมสำหรับ Terraformซึ่งอธิบายรายละเอียดเกี่ยวกับแนวทางปฏิบัติที่ดีที่สุดทั้งหมดที่เราได้เรียนรู้สำหรับการใช้ Terraform ในโลกแห่งความเป็นจริง
อัปเดต: คำแนะนำที่ครอบคลุมสำหรับซีรี่ส์บล็อกโพสต์ Terraform ได้รับความนิยมมากจนเราขยายเป็นหนังสือชื่อTerraform: Up & Running !
remote configหากคุณเพิ่งตรวจสอบการกำหนดค่า Terraform ของคุณหรือหากคุณต้องการเปลี่ยนการกำหนดค่าระยะไกลก่อนหน้านี้ Terraform 0.9 จะนำเสนอแนวคิดbackendsซึ่งจะช่วยลดความซับซ้อนของสิ่งนี้ได้มาก ดูPR นี้สำหรับรายละเอียดเพิ่มเติม
remote configคำสั่งอีกครั้งเพื่อชี้ไปที่สถานะแยง สมมติว่าสถานะที่แตกต่างกันต่อสภาพแวดล้อม นั่นถูกต้องใช่ไหม? ฉันหวังว่าจะได้ v0.9
.tfไฟล์เดียวกันกับสองสภาพแวดล้อมที่แตกต่างกันใช่คุณจะต้องเรียกใช้remote configทุกครั้งที่เปลี่ยน เห็นได้ชัดว่านี่เป็นข้อผิดพลาดได้ง่ายดังนั้นฉันไม่แนะนำให้ใช้เทคนิคนี้จริงๆ ลองดูรูปแบบไฟล์ Terraform ที่แนะนำในบล็อกโพสต์นี้พร้อมวิธีใช้โมดูล Terraform ในบล็อกโพสต์นี้
ก่อนหน้านี้remote configอนุญาตสิ่งนี้ แต่ตอนนี้ถูกแทนที่ด้วย " แบ็กเอนด์ " ดังนั้นรีโมต Terraform จึงไม่สามารถใช้งานได้อีกต่อไป
terraform remote config -backend-config="bucket=<s3_bucket_to_store_tfstate>" -backend-config="key=terraform.tfstate" -backend=s3
terraform remote pull
terraform apply
terraform remote pushดูรายละเอียดในเอกสาร
ครอบคลุมในเชิงลึกมากขึ้นโดย @Yevgeny Brikman แต่ตอบคำถามของ OP โดยเฉพาะ:
แนวทางปฏิบัติที่ดีที่สุดในการจัดการไฟล์ Terraform และสถานะคืออะไร?
ใช้ git สำหรับไฟล์ TF แต่อย่าตรวจสอบไฟล์สถานะใน (เช่น tfstate) แทนที่จะใช้Terragruntสำหรับการซิงค์ / ล็อกไฟล์สถานะไปยัง S3
แต่ฉันยอมรับ tfstate ด้วยหรือไม่?
ไม่
ควรอยู่ที่ไหนสักแห่งเช่น S3 หรือไม่?
ใช่
ฉันรู้ว่ามีคำตอบมากมายที่นี่ แต่แนวทางของฉันค่อนข้างแตกต่างกัน
⁃ Modules
⁃ Environment management
⁃ Separation of dutiesโมดูล
การจัดการสิ่งแวดล้อม
IaC ทำให้กระบวนการ SDLC เกี่ยวข้องกับการจัดการโครงสร้างพื้นฐานและไม่ใช่เรื่องปกติที่จะคาดหวังว่าจะมีโครงสร้างพื้นฐานการพัฒนารวมถึงสภาพแวดล้อมแอปพลิเคชันการพัฒนา
การแบ่งแยกหน้าที่
หากคุณอยู่ในองค์กรขนาดเล็กหรือใช้โครงสร้างพื้นฐานส่วนบุคคลสิ่งนี้ไม่ได้ใช้ แต่จะช่วยให้คุณจัดการการดำเนินงานของคุณได้
นอกจากนี้ยังช่วยคลายข้อกังวลเนื่องจากคุณจะพบว่าแหล่งข้อมูลบางอย่างไม่ค่อยมีการเปลี่ยนแปลงในขณะที่แหล่งข้อมูลอื่น ๆ เปลี่ยนแปลงตลอดเวลา การแบ่งแยกช่วยขจัดความเสี่ยงและความซับซ้อน
กลยุทธ์นี้มีความคล้ายคลึงกับกลยุทธ์หลายบัญชีของ AWS อ่านข้อมูลเพิ่มเติม
CI / ซีดี
นี่เป็นหัวข้อของตัวเอง แต่ Terraform ทำงานได้ดีมากภายในท่อที่ดี ข้อผิดพลาดที่พบบ่อยที่สุดคือการถือว่า CI เป็นกระสุนเงิน ในทางเทคนิค Terraform ควรจัดเตรียมโครงสร้างพื้นฐานในระหว่างขั้นตอนของการประกอบท่อเท่านั้น สิ่งนี้จะแยกออกจากสิ่งที่เกิดขึ้นในขั้นตอน CI ซึ่งโดยทั่วไปจะตรวจสอบและทดสอบเทมเพลต
NB เขียนบนมือถือดังนั้นโปรดขออภัยในข้อผิดพลาด
ก่อนที่คำตอบจะชัดเจนและให้ข้อมูลฉันจะพยายามเพิ่ม 2 เซ็นต์ของฉันที่นี่
ง่ายและเร็วกว่าในการทำงานกับทรัพยากรจำนวนน้อย:
terraform planและterraformใช้ทั้งการเรียก API บนคลาวด์เพื่อตรวจสอบสถานะของทรัพยากรรัศมีการระเบิดเล็กลงโดยใช้ทรัพยากรน้อยลง:
เริ่มโครงการของคุณโดยใช้สถานะระยะไกล:
tfstateไฟล์ในคอมไพล์เป็นฝันร้ายพยายามฝึกโครงสร้างและหลักการตั้งชื่อที่สอดคล้องกัน:
ทำให้โมดูลทรัพยากรธรรมดาที่สุด
อย่าฮาร์ดโค้ดค่าที่สามารถส่งผ่านเป็นตัวแปรหรือค้นพบโดยใช้แหล่งข้อมูล
ใช้dataแหล่งที่มาและterraform_remote_stateโดยเฉพาะเป็นกาวระหว่างโมดูลโครงสร้างพื้นฐานภายในองค์ประกอบ
( บทความอ้างอิง: https://www.terraform-best-practices.com/code-structure )
ตัวอย่าง:
ง่ายและรวดเร็วกว่าในการทำงานกับทรัพยากรจำนวนน้อยดังนั้นเราจึงนำเสนอเค้าโครงโค้ดที่แนะนำด้านล่าง
หมายเหตุ: เช่นเดียวกับการอ้างอิงที่ไม่ควรปฏิบัติตามอย่างเคร่งครัดเนื่องจากแต่ละโครงการมีลักษณะเฉพาะของตนเอง
.
├── 1_tf-backend #remote AWS S3 + Dynamo Lock tfstate
│ ├── main.tf
│ ├── ...
├── 2_secrets
│ ├── main.tf
│ ├── ...
├── 3_identities
│ ├── account.tf
│ ├── roles.tf
│ ├── group.tf
│ ├── users.tf
│ ├── ...
├── 4_security
│ ├── awscloudtrail.tf
│ ├── awsconfig.tf
│ ├── awsinspector.tf
│ ├── awsguarduty.tf
│ ├── awswaf.tf
│ └── ...
├── 5_network
│ ├── account.tf
│ ├── dns_remote_zone_auth.tf
│ ├── dns.tf
│ ├── network.tf
│ ├── network_vpc_peering_dev.tf
│ ├── ...
├── 6_notifications
│ ├── ...
├── 7_containers
│ ├── account.tf
│ ├── container_registry.tf
│ ├── ...
├── config
│ ├── backend.config
│ └── main.config
└── readme.mdฉันเชื่อว่ามีแนวทางปฏิบัติที่ดีที่สุดบางประการที่ต้องปฏิบัติตามในขณะที่ใช้พื้นระเบียงเพื่อจัดโครงสร้างพื้นฐาน
- อย่าเขียนรหัสเดิมอีก (การใช้ซ้ำ)
- แยกการกำหนดค่าสภาพแวดล้อมเพื่อให้ดูแลรักษาได้ง่าย
- ใช้รีโมตแบ็กเอนด์ s3 (เข้ารหัส) และไดนาโม DB เพื่อจัดการการล็อกพร้อมกัน
- สร้างโมดูลและใช้โมดูลนั้นในโครงสร้างพื้นฐานหลักหลาย ๆ ครั้งเหมือนกับฟังก์ชันที่ใช้ซ้ำได้ซึ่งสามารถเรียกใช้ได้หลายครั้งโดยส่งผ่านพารามิเตอร์ที่แตกต่างกัน
จัดการกับสภาพแวดล้อมที่หลากหลาย
วิธีที่แนะนำส่วนใหญ่คือการใช้ 'พื้นที่ทำงาน' ของ Terraform เพื่อจัดการกับสภาพแวดล้อมที่หลากหลาย แต่ฉันเชื่อว่าการใช้พื้นที่ทำงานอาจแตกต่างกันไปตามวิธีการทำงานในองค์กร อื่น ๆ กำลังจัดเก็บรหัส Terraform สำหรับแต่ละสภาพแวดล้อมของคุณ (เช่น stage, prod, QA) เพื่อแยกสถานะสภาพแวดล้อม อย่างไรก็ตามในกรณีนี้เราแค่คัดลอกโค้ดเดียวกันในหลาย ๆ ที่
├── main.tf
├── dev
│ ├── main.tf
│ ├── output.tf
│ └── variables.tf
└── prod
├── main.tf
├── output.tf
└── variables.tfฉันทำตามแนวทางที่แตกต่างกันในการจัดการและหลีกเลี่ยงการทำซ้ำรหัสพื้นผิวเดียวกันโดยเก็บไว้ในโฟลเดอร์สภาพแวดล้อมแต่ละโฟลเดอร์เนื่องจากฉันเชื่อว่าส่วนใหญ่สภาพแวดล้อมทั้งหมดจะเหมือนกัน 90%
├── deployment
│ ├── 01-network.tf
│ ├── 02-ecs_cluster.tf
│ ├── 03-ecs_service.tf
│ ├── 04-eks_infra.tf
│ ├── 05-db_infra.tf
│ ├── 06-codebuild-k8s.tf
│ ├── 07-aws-secret.tf
│ ├── backend.tf
│ ├── provider.tf
│ └── variables.tf
├── env
│ ├── dev
│ │ ├── dev.backend.tfvar
│ │ └── dev.variables.tfvar
│ └── prod
│ ├── prod.backend.tfvar
│ └── prod.variables.tfvar
├── modules
│ └── aws
│ ├── compute
│ │ ├── alb_loadbalancer
│ │ ├── alb_target_grp
│ │ ├── ecs_cluster
│ │ ├── ecs_service
│ │ └── launch_configuration
│ ├── database
│ │ ├── db_main
│ │ ├── db_option_group
│ │ ├── db_parameter_group
│ │ └── db_subnet_group
│ ├── developertools
│ ├── network
│ │ ├── internet_gateway
│ │ ├── nat_gateway
│ │ ├── route_table
│ │ ├── security_group
│ │ ├── subnet
│ │ ├── vpc
│ └── security
│ ├── iam_role
│ └── secret-manager
└── templatesการกำหนดค่าที่เกี่ยวข้องกับสภาพแวดล้อม
เก็บคอนฟิกูเรชันและพารามิเตอร์ที่เกี่ยวข้องกับสภาวะแวดล้อมแยกกันในไฟล์ตัวแปรและส่งผ่านค่านั้นเพื่อกำหนดคอนฟิกโครงสร้างพื้นฐาน เช่นด้านล่าง
dev.backend.tfvar
region = "ap-southeast-2"
bucket = "dev-samplebackendterraform"
key = "dev/state.tfstate"
dynamo_db_lock = "dev-terraform-state-lock"dev.variable.tfvar
environment = "dev"
vpc_name = "demo"
vpc_cidr_block = "10.20.0.0/19"
private_subnet_1a_cidr_block = "10.20.0.0/21"
private_subnet_1b_cidr_block = "10.20.8.0/21"
public_subnet_1a_cidr_block = "10.20.16.0/21"
public_subnet_1b_cidr_block = "10.20.24.0/21"การข้ามส่วนโครงสร้างพื้นฐานอย่างมีเงื่อนไข
สร้างการกำหนดค่าในไฟล์ตัวแปรเฉพาะ env และขึ้นอยู่กับตัวแปรนั้นตัดสินใจที่จะสร้างหรือข้ามส่วนนั้น ด้วยวิธีนี้ขึ้นอยู่กับความต้องการส่วนเฉพาะของโครงสร้างพื้นฐานสามารถข้ามไปได้
variable vpc_create {
default = "true"
}
module "vpc" {
source = "../modules/aws/network/vpc"
enable = "${var.vpc_create}"
vpc_cidr_block = "${var.vpc_cidr_block}"
name = "${var.vpc_name}"
}
resource "aws_vpc" "vpc" {
count = "${var.enable == "true" ? 1 : 0}"
cidr_block = "${var.vpc_cidr_block}"
enable_dns_support = "true"
enable_dns_hostnames = "true"
}คำสั่งด้านล่างนี้จำเป็นสำหรับการเริ่มต้นและดำเนินการเปลี่ยนแปลงอินฟาเรดสำหรับแต่ละสภาพแวดล้อม cd ไปยังโฟลเดอร์สภาพแวดล้อมที่ต้องการ
terraform init -var-file=dev.variables.tfvar -backend-config=dev.backend.tfvar ../../deployment/
terraform apply -var-file=dev.variables.tfvar ../../deploymentสำหรับการอ้างอิง: https://github.com/mattyait/devops_terraform
ฉันไม่ชอบแนวคิดของโฟลเดอร์ย่อยเพราะจะทำให้เกิดแหล่งที่มาที่แตกต่างกันตามสภาพแวดล้อมและสิ่งนี้มีแนวโน้มที่จะล่องลอย
แนวทางที่ดีกว่าคือการมีสแต็กเดียวสำหรับทุกสภาพแวดล้อม (สมมติว่า dev, preprod และ prod) terraform workspaceในการทำงานในสภาพแวดล้อมการใช้งานเพียงครั้งเดียว
terraform workspace new devสิ่งนี้จะสร้างพื้นที่ทำงานใหม่ ซึ่งรวมถึงไฟล์สถานะเฉพาะและตัวแปรที่terraform.workspaceคุณสามารถใช้ในโค้ดของคุณ
resource "aws_s3_bucket" "bucket" {
bucket = "my-tf-test-bucket-${terraform.workspace}"
}ด้วยวิธีนี้คุณจะได้รับการเรียกถัง
หลังจากใช้กับพื้นที่ทำงานด้านบน (ใช้terraform workspace select <WORKSPACE>เพื่อเปลี่ยนสภาพแวดล้อม) ในการทำให้รหัสมีการพิสูจน์หลายภูมิภาคให้ทำดังนี้:
data "aws_region" "current" {}
resource "aws_s3_bucket" "bucket" {
bucket = "my-tf-test-bucket-${data.aws_region.current.name}-${terraform.workspace}"
}ที่จะได้รับ (สำหรับ us-east-1 ภูมิภาค)
แนวทางปฏิบัติที่ดีที่สุดของ Terraform ที่ควรปฏิบัติตาม:
หลีกเลี่ยงการเข้ารหัสยาก: บางครั้งนักพัฒนาสร้างทรัพยากรด้วยตนเองโดยตรง คุณต้องทำเครื่องหมายทรัพยากรเหล่านี้และใช้การนำเข้าพื้นดินเพื่อรวมไว้ในรหัส ตัวอย่าง:
account_number =“ 123456789012 "account_alias =" mycompany "
เรียกใช้ Terraform จากคอนเทนเนอร์นักเทียบท่า: Terraform เผยแพร่คอนเทนเนอร์ Docker อย่างเป็นทางการที่ช่วยให้คุณควบคุมเวอร์ชันที่คุณสามารถเรียกใช้ได้อย่างง่ายดาย
ขอแนะนำให้รันคอนเทนเนอร์ Terraform Docker เมื่อคุณตั้งค่างานสร้างในท่อ CI / CD
TERRAFORM_IMAGE=hashicorp/terraform:0.11.7
TERRAFORM_CMD="docker run -ti --rm -w /app -v ${HOME}/.aws:/root/.aws -v ${HOME}/.ssh:/root/.ssh -v `pwd`:/app $TERRAFORM_IMAGE"สำหรับข้อมูลเพิ่มเติมโปรดดูที่บล็อกของฉัน: https://medium.com/tech-darwinbox/how-darwinbox-manages-infrastructure-at-scale-with-terraform-371e2c5f04d3
ฉันต้องการมีส่วนร่วมในหัวข้อนี้
ในบางกรณีพิเศษจำเป็นต้องมีการเข้าถึงไฟล์สถานะ Terraform ด้วยตนเอง สิ่งต่างๆเช่นการปรับโครงสร้างใหม่การทำลายการเปลี่ยนแปลงหรือการแก้ไขข้อบกพร่องจะต้องใช้การดำเนินการของสถานะ Terraform โดยเจ้าหน้าที่ฝ่ายปฏิบัติการ ในโอกาสดังกล่าวให้วางแผนการเข้าถึงสถานะ Terraform ที่มีการควบคุมพิเศษโดยใช้ bastion host, VPN เป็นต้น
ตรวจสอบบล็อกแนวทางปฏิบัติที่ดีที่สุดที่ยาวขึ้นซึ่งครอบคลุมรายละเอียดนี้รวมถึงแนวทางสำหรับไปป์ไลน์ CI / CD
หากคุณยังคงมองหาโซลูชันที่ดีกว่าให้ดูที่พื้นที่ทำงานซึ่งสามารถแทนที่การรักษาโครงสร้างโฟลเดอร์สภาพแวดล้อมที่แตกต่างกันได้โดยสามารถมีตัวแปรเฉพาะของพื้นที่ทำงานได้
ดังที่Yevgeniy Brikman กล่าวว่าควรมีโครงสร้างโมดูล
ใช้ Terraform Cloud เพื่อจัดการและบันทึกสถานะพร้อมกับคำแนะนำด้านบน