Jestem również w stanie migracji istniejącej infrastruktury AWS do Terraform, więc będę starał się aktualizować odpowiedź w miarę rozwoju.
W dużej mierze polegałem na oficjalnych przykładach Terraform i wielu próbach i błędach, aby opracować obszary, w których nie byłem pewien.
.tfstate pliki
Konfiguracja Terraform może służyć do obsługi wielu skrzynek w innej infrastrukturze, z których każda może mieć inny stan. Ponieważ może być również uruchamiany przez wiele osób, stan ten powinien znajdować się w scentralizowanej lokalizacji (takiej jak S3), ale nie w git.
Można to potwierdzić patrząc na Terraform .gitignore.
Kontrola dewelopera
Naszym celem jest zapewnienie deweloperom większej kontroli nad infrastrukturą przy jednoczesnym zachowaniu pełnego audytu (dziennik git) oraz możliwości sprawdzania poprawności zmian (pull requesty). Mając to na uwadze, nowy przepływ pracy dotyczący infrastruktury, do którego dążę, to:
- Podstawowy fundament powszechnych AMI, które obejmują moduły wielokrotnego użytku, np. Marionetka.
- Infrastruktura podstawowa udostępniana przez DevOps przy użyciu Terraform.
- Deweloperzy w razie potrzeby zmieniają konfigurację Terraform w Git (liczba wystąpień, nowy VPC, dodanie regionu / strefy dostępności itp.).
- Konfiguracja Git została wypchnięta, a żądanie ściągnięcia zostało przesłane do sprawdzenia przez członka zespołu DevOps.
- Po zatwierdzeniu wywołuje element webhook do CI w celu kompilacji i wdrożenia (nie jest w tej chwili pewna, jak podzielić wiele środowisk na partycje)
Edycja 1 - aktualizacja aktualnego stanu
Odkąd zacząłem tę odpowiedź, napisałem dużo kodu TF i czuję się bardziej komfortowo w naszym stanie rzeczy. Po drodze napotkaliśmy błędy i ograniczenia, ale zgadzam się, że jest to cecha charakterystyczna używania nowego, szybko zmieniającego się oprogramowania.
Układ
Mamy skomplikowaną infrastrukturę AWS z wieloma VPC z wieloma podsieciami. Kluczem do łatwego zarządzania tym było zdefiniowanie elastycznej taksonomii obejmującej region, środowisko, usługę i właściciela, której możemy użyć do uporządkowania kodu naszej infrastruktury (zarówno terraform, jak i marionetki).
Moduły
Następnym krokiem było utworzenie jednego repozytorium git do przechowywania naszych modułów terraform. Nasza struktura katalogów najwyższego poziomu dla modułów wygląda następująco:
tree -L 1 .
Wynik:
├── README.md
├── aws-asg
├── aws-ec2
├── aws-elb
├── aws-rds
├── aws-sg
├── aws-vpc
└── templates
Każdy z nich ustawia rozsądne wartości domyślne, ale ujawnia je jako zmienne, które mogą zostać nadpisane przez nasz „klej”.
Klej
Posiadamy drugie repozytorium z naszym, gluektóre korzysta z modułów wymienionych powyżej. Jest ułożony zgodnie z naszym dokumentem taksonomicznym:
.
├── 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
Na poziomie klienta mamy .tfpliki specyficzne dla konta AWS , które udostępniają globalne zasoby (takie jak role IAM); następny to poziom regionu z kluczami publicznymi EC2 SSH; W końcu w naszym środowisku ( dev, stg, prodetc) są naszą konfiguracje VPC, tworzenie instancji i zaglądanie połączeń itd są przechowywane.
Uwaga boczna: Jak widać, sprzeciwiam się mojej własnej radzie powyżej, trzymając się terraform.tfstategit. Jest to środek tymczasowy, dopóki nie przejdę na S3, ale mi odpowiada, ponieważ obecnie jestem jedynym programistą.
Następne kroki
Jest to nadal proces ręczny i jeszcze nie w Jenkinsie, ale przenosimy dość dużą, skomplikowaną infrastrukturę i jak dotąd jest to dobre. Jak powiedziałem, kilka błędów, ale wszystko idzie dobrze!
Edycja 2 - zmiany
Minął prawie rok, odkąd napisałem tę wstępną odpowiedź, a stan Terraform i mnie znacznie się zmienił. Jestem teraz na nowej pozycji przy użyciu Terraform do zarządzania klastrem Azure, a Terraform jest teraz v0.10.7.
Stan
Ludzie wielokrotnie powtarzali mi, że stan nie powinien wchodzić w Git - i mają rację. Wykorzystaliśmy to jako środek tymczasowy z dwuosobowym zespołem, który polegał na komunikacji i dyscyplinie programistów. W większym, rozproszonym zespole w pełni wykorzystujemy stan zdalny w S3 z blokadą zapewnianą przez DynamoDB. Najlepiej byłoby, gdyby zostało to przeniesione do Consul, teraz jest to wersja 1.0, aby zmniejszyć liczbę dostawców usług w chmurze.
Moduły
Wcześniej tworzyliśmy i używaliśmy modułów wewnętrznych. Nadal tak jest, ale wraz z pojawieniem się i rozwojem rejestru Terraform staramy się wykorzystać je przynajmniej jako podstawę.
Struktura plików
Nowa pozycja ma znacznie prostszą taksonomię z tylko dwoma środowiskami infx - devi prod. Każdy ma własne zmienne i dane wyjściowe, wykorzystując ponownie nasze moduły utworzone powyżej. remote_stateDostawca pomaga w dzieleniu się wyjść tworzonych zasobów pomiędzy środowiskami. Nasz scenariusz obejmuje subdomeny w różnych grupach zasobów platformy Azure do globalnie zarządzanej domeny TLD.
├── main.tf
├── dev
│ ├── main.tf
│ ├── output.tf
│ └── variables.tf
└── prod
├── main.tf
├── output.tf
└── variables.tf
Planowanie
Ponownie z dodatkowymi wyzwaniami rozproszonego zespołu, teraz zawsze zapisujemy nasze wyniki terraform planpolecenia. Możemy sprawdzić i wiedzieć, co zostanie uruchomione bez ryzyka pewnych zmian między sceną plana apply(chociaż pomaga w tym blokowanie). Pamiętaj, aby usunąć ten plik planu, ponieważ może on potencjalnie zawierać „tajne” zmienne tekstowe.
Ogólnie jesteśmy bardzo zadowoleni z Terraform i nadal się uczymy i ulepszamy dzięki dodanym nowym funkcjom.