Terraformer - Infrastructure To Code

მინდა გითხრათ ახალი CLI ინსტრუმენტის შესახებ, რომელიც დავწერე ძველი პრობლემის გადასაჭრელად.

პრობლემა

Terraform დიდი ხანია სტანდარტია Devops/Cloud/IT საზოგადოებაში. ეს არის ძალიან მოსახერხებელი და გამოსადეგი ინფრასტრუქტურის, როგორც კოდის მოსაგვარებლად. Terraform-ში ბევრი სიამოვნებაა, ასევე ბევრი ჩანგალი, ბასრი დანები და საკომისიო.
Terraform-ით ძალიან მოსახერხებელია ახალი ნივთების შექმნა და შემდეგ მათი მართვა, შეცვლა ან წაშლა. რა უნდა გააკეთოს მათ, ვისაც უზარმაზარი ინფრასტრუქტურა აქვს ღრუბელში და არ არის შექმნილი Terraform-ის საშუალებით? მთელი ღრუბლის ხელახლა დაწერა და ხელახლა შექმნა გარკვეულწილად ძვირი და სახიფათოა.
მე შემხვდა ეს პრობლემა 2 სამუშაოზე, უმარტივესი მაგალითია, როცა გინდა რომ ყველაფერი იყოს git ფორმაში, როგორც ტერაფორმული ფაილები, მაგრამ გაქვს 250+ თაიგულები და ბევრია მათი ხელით ტერაფორმაში ჩაწერა.
არსებობს საკითხი 2014 წლიდან ტერაფომში რომელიც 2016 წელს დაიხურა იმ იმედით რომ იქნება იმპორტი.

ზოგადად, ყველაფერი ისეა როგორც სურათზე მხოლოდ მარჯვნიდან მარცხნივ

გაფრთხილება: ავტორი ნახევარი სიცოცხლე რუსეთში არ ცხოვრობს და რუსულად ცოტას წერს. უფრთხილდით ორთოგრაფიულ შეცდომებს.

გადაწყვეტილებები

1. არსებობს AWS-ის მზა და ძველი გადაწყვეტა ტერაფორმირება. როდესაც ვცადე ჩემი 250+ თაიგულის გადატანა, მივხვდი, რომ იქ ყველაფერი ცუდად იყო. AWS უკვე დიდი ხანია შემოგვთავაზებს უამრავ ახალ ვარიანტს, მაგრამ ტერაფორმირებამ არ იცის მათ შესახებ და ზოგადად ეს ლალისფერია შაბლონი იშვიათია. საღამოს 2-ის მერე გავგზავნე გაიყვანეთ მოთხოვნა მეტი ფუნქციების დამატება იქ და მივხვდი, რომ ასეთი გამოსავალი საერთოდ არ არის შესაფერისი.
როგორ მუშაობს ტერაფორმირება: ის იღებს მონაცემებს AWS SDK-დან და ქმნის tf და tfstate შაბლონის მეშვეობით.
აქ 3 პრობლემაა:
1. ყოველთვის იქნება შეფერხება განახლებებში
2. tf ფაილები ზოგჯერ გატეხილი გამოდის
3. tfstate გროვდება tf-სგან განცალკევებით და ყოველთვის არ იყრის თავს
ზოგადად, ძნელია ისეთი შედეგის მიღება, რომელშიც `ტერაფორმული გეგმა~ ამბობს, რომ ცვლილებები არ არის

2. `terraform import` არის ჩაშენებული ბრძანება terraform-ში. Როგორ მუშაობს?
თქვენ წერთ ცარიელ TF ფაილს რესურსის სახელით და ტიპით, შემდეგ გაუშვით `terraform import` და გადასცემთ რესურსის ID-ს. terraform დაუკავშირდება პროვაიდერს, იღებს მონაცემებს და ქმნის tfstate ფაილს.
აქ 3 პრობლემაა:
1. ჩვენ ვიღებთ მხოლოდ tfstate ფაილს და tf ცარიელია, თქვენ უნდა დაწეროთ ის ხელით ან გადაიყვანოთ tfstate-დან
2. შეუძლია მხოლოდ ერთი რესურსით მუშაობა ერთდროულად და არ უჭერს მხარს ყველა რესურსს. და 250+ თაიგულს ისევ რა ვქნა?
3. თქვენ უნდა იცოდეთ რესურსების ID - ანუ, თქვენ უნდა შეფუთოთ ის კოდით, რომელიც მიიღებს რესურსების ჩამონათვალს
ზოგადად, შედეგი არის ნაწილობრივი და არ არის კარგად მასშტაბური

ჩემი გადაწყვეტილება

მოთხოვნები:
1. რესურსებისთვის tf და tfstate ფაილების შექმნის შესაძლებლობა. მაგალითად, ჩამოტვირთეთ ყველა თაიგულები/უსაფრთხოების ჯგუფი/ჩატვირთვის ბალანსერი და რომ `ტერაფორმული გეგმა` დააბრუნა, რომ ცვლილებები არ არის
2. გჭირდებათ 2 GCP + AWS ღრუბელი
3. გლობალური გადაწყვეტა, რომელიც ადვილად განახლდება ყოველ ჯერზე და არ კარგავს დროს თითოეულ რესურსზე 3 დღის მუშაობისთვის
4. გახადე ღია წყარო - ყველას აქვს იგივე პრობლემა

Go ენა იმიტომ მიყვარს, რომ მას აქვს ბიბლიოთეკა HCL ფაილების შესაქმნელად, რომელიც გამოიყენება ტერაფორმაში + ბევრი კოდი ტერაფორმში, რომელიც შეიძლება სასარგებლო იყოს

გზა

პირველი მცდელობა
დავიწყე მარტივი ვერსიით. ღრუბელთან დაკავშირება SDK-ის საშუალებით საჭირო რესურსისთვის და მისი გადაქცევა ველებად ტერაფორმისთვის. მცდელობა მაშინვე გარდაიცვალა უსაფრთხოების ჯგუფზე, რადგან არ მომეწონა 1.5 დღე მხოლოდ უსაფრთხოების ჯგუფის კონვერტაციისთვის (და უამრავი რესურსია). დიდი ხნის განმავლობაში და შემდეგ ველების შეცვლა/დამატება შეიძლება

მეორე მცდელობა
აღწერილ იდეაზე დაყრდნობით აქ. უბრალოდ აიღეთ და გადააკეთეთ tfstate tf-ად. ყველა მონაცემი არსებობს და ველები იგივეა. როგორ მივიღოთ სრული tfstate მრავალი რესურსისთვის?? სწორედ აქ მოვიდა ბრძანება `terraform refresh~. terraform იღებს ყველა რესურსს tfstate-ში და ID-ით ამოიღებს მათზე არსებულ მონაცემებს და ყველაფერს წერს tfstate-ში. ანუ შექმენით ცარიელი tfstate მხოლოდ სახელებით და ID-ებით, გაუშვით `terraform refresh` და შემდეგ მივიღებთ სრულ tfstates. ჰორი!
ახლა მოდით გავაკეთოთ რეკურსიული პორნოგრაფია tfstate-სთვის tf-ზე გადამყვანის დაწერისთვის. მათთვის, ვისაც არასოდეს წაუკითხავს tfstate, ეს არის JSON, მაგრამ განსაკუთრებული.
აქ არის მისი მნიშვნელოვანი ნაწილის ატრიბუტები

 "attributes": {
                            "id": "default/backend-logging-load-deployment",
                            "metadata.#": "1",
                            "metadata.0.annotations.%": "0",
                            "metadata.0.generate_name": "",
                            "metadata.0.generation": "24",
                            "metadata.0.labels.%": "1",
                            "metadata.0.labels.app": "backend-logging",
                            "metadata.0.name": "backend-logging-load-deployment",
                            "metadata.0.namespace": "default",
                            "metadata.0.resource_version": "109317427",
                            "metadata.0.self_link": "/apis/apps/v1/namespaces/default/deployments/backend-logging-load-deployment",
                            "metadata.0.uid": "300ecda1-4138-11e9-9d5d-42010a8400b5",
                            "spec.#": "1",
                            "spec.0.min_ready_seconds": "0",
                            "spec.0.paused": "false",
                            "spec.0.progress_deadline_seconds": "600",
                            "spec.0.replicas": "1",
                            "spec.0.revision_history_limit": "10",
                            "spec.0.selector.#": "1",

Იქ არის:
1. id - სტრიქონი
2. მეტამონაცემები - 1 ზომის მასივი და მასში ობიექტი ველებით, რომელიც აღწერილია ქვემოთ
3. spec - ჰეში 1 ზომის და გასაღები, მნიშვნელობა მასში
მოკლედ, სახალისო ფორმატი, ყველაფერი შეიძლება რამდენიმე დონეზე იყოს ღრმა

                   "spec.#": "1",
                            "spec.0.min_ready_seconds": "0",
                            "spec.0.paused": "false",
                            "spec.0.progress_deadline_seconds": "600",
                            "spec.0.replicas": "1",
                            "spec.0.revision_history_limit": "10",
                            "spec.0.selector.#": "1",
                            "spec.0.selector.0.match_expressions.#": "0",
                            "spec.0.selector.0.match_labels.%": "1",
                            "spec.0.selector.0.match_labels.app": "backend-logging-load",
                            "spec.0.strategy.#": "0",
                            "spec.0.template.#": "1",
                            "spec.0.template.0.metadata.#": "1",
                            "spec.0.template.0.metadata.0.annotations.%": "0",
                            "spec.0.template.0.metadata.0.generate_name": "",
                            "spec.0.template.0.metadata.0.generation": "0",
                            "spec.0.template.0.metadata.0.labels.%": "1",
                            "spec.0.template.0.metadata.0.labels.app": "backend-logging-load",
                            "spec.0.template.0.metadata.0.name": "",
                            "spec.0.template.0.metadata.0.namespace": "",
                            "spec.0.template.0.metadata.0.resource_version": "",
                            "spec.0.template.0.metadata.0.self_link": "",
                            "spec.0.template.0.metadata.0.uid": "",
                            "spec.0.template.0.spec.#": "1",
                            "spec.0.template.0.spec.0.active_deadline_seconds": "0",
                            "spec.0.template.0.spec.0.container.#": "1",
                            "spec.0.template.0.spec.0.container.0.args.#": "3",

ზოგადად, თუ ვინმეს უნდა ინტერვიუსთვის პროგრამირების პრობლემა, უბრალოდ სთხოვეთ დაწეროს ამ ამოცანისთვის პარსერი :)
მრავალი მცდელობის შემდეგ, დამეწერა პარსერი შეცდომების გარეშე, მისი ნაწილი ვიპოვე ტერაფორმულ კოდში და ყველაზე მნიშვნელოვანი ნაწილი. და თითქოს ყველაფერი კარგად მუშაობდა

ცდა სამი
terraform პროვაიდერები არის ბინარები, რომლებიც შეიცავს კოდს ყველა რესურსით და ლოგიკით ღრუბლოვანი API-სთან მუშაობისთვის. თითოეულ ღრუბელს აქვს საკუთარი პროვაიდერი და თავად ტერაფორმი მათ მხოლოდ თავისი RPC პროტოკოლით უწოდებს ორ პროცესს შორის.
ახლა გადავწყვიტე დაკავშირება ტერაფორმის პროვაიდერებთან პირდაპირ RPC ზარების საშუალებით. მშვენივრად გამოვიდა და შესაძლებელი გახადა ტერაფორმის პროვაიდერების ახალზე შეცვლა და ახალი ფუნქციების მიღება კოდის შეცვლის გარეშე. ისიც გამოდის, რომ tfstate-ში ყველა ველი არ უნდა იყოს tf-ში, მაგრამ როგორ შეიძლება ამის გარკვევა? უბრალოდ ჰკითხეთ თქვენს პროვაიდერს ამის შესახებ. შემდეგ დაიწყო რეგულარული გამონათქვამების აწყობის კიდევ ერთი რეკურსიული პორნოგრაფია, რომელიც ეძებდა ველებს tfstate-ში ყველა დონეზე სიღრმისეულად.

საბოლოო ჯამში, ჩვენ მივიღეთ სასარგებლო CLI ინსტრუმენტი, რომელსაც აქვს საერთო ინფრასტრუქტურა ყველა ტერაფორმის პროვაიდერისთვის და თქვენ შეგიძლიათ მარტივად დაამატოთ ახალი. ასევე, რესურსების დამატებას მცირე კოდი სჭირდება. პლუს ყველა სახის სიკეთე, როგორიცაა კავშირები რესურსებს შორის. რა თქმა უნდა, იყო მრავალი განსხვავებული პრობლემა, რომელთა აღწერა შეუძლებელია.
ცხოველს ტერაფომერი დავარქვი.

საბოლოო

Terrafomer-ის გამოყენებით ორი ღრუბლიდან შევქმენით tf + tfstate კოდის 500-700 ათასი ხაზი. ჩვენ შევძელით მემკვიდრეობითი ნივთების აღება და მათთან შეხება მხოლოდ ტერაფორმის საშუალებით, როგორც საუკეთესო ინფრასტრუქტურაში, როგორც კოდის იდეები. უბრალოდ ჯადოსნურია, როცა იღებთ უზარმაზარ ღრუბელს და იღებთ მას გუნდის მეშვეობით ტერაფორმული მუშა ფაილების სახით. და შემდეგ grep/replace/git და ასე შემდეგ.

დავავარცხნე და დავალაგე, ნებართვა ავიღე. გამოვიდა GitHub-ზე ყველასთვის ხუთშაბათს (02.05.19/XNUMX/XNUMX). github.com/GoogleCloudPlatform/terraformer
უკვე მიღებულია 600 ვარსკვლავი, 2 pull მოთხოვნა openstack-ისა და kubernetes-ის მხარდაჭერის დასამატებლად. კარგი გამოხმაურება. ზოგადად, პროექტი სასარგებლოა ხალხისთვის
ვურჩევ ყველას, ვისაც სურს დაიწყოს მუშაობა Terraform-თან და არ გადაწეროს ყველაფერი ამისთვის.
სიამოვნებით გამოვიტან თხოვნებს, საკითხებს, ვარსკვლავებს.

დემო


წყარო: www.habr.com