Projekt jednorazowy, średniej wielkości infrastruktura zakupiona jako kod, co byście wybrali do jej napisania CLI, czy ARM(bicep)/cloudformation
sytuacja hipotetyczna.
0
3
Terraform
0
To na czym się ty i twoj zespół znacie zeby zrobic to dobrze. Nie ma nic gorszego niż przejmowanie projektu po ludziach którzy uczyli się danego narzędzia na żywym projekcie.
2
Terraform. Pisałem w Pulumi, CloudFormation i Terraform wygrywa póki co.
Jeżeli nie używa się "null resources" i helm chartów oraz skryptów bashowych (nawet twórcy to odradzają) ,tylko czysty, deklaratywny Terraform to ma się gwarancję idempotentności cały czas i stabilności na poziomie 99% jeżeli chodzi o stawianie infrastruktury.
0
oliver_ napisał(a):
Terraform. Pisałem w Pulumi, CloudFormation i Terraform wygrywa póki co.
Jeżeli nie używa się "null resources" i helm chartów oraz skryptów bashowych (nawet twórcy to odradzają) ,tylko czysty, deklaratywny Terraform to ma się gwarancję idempotentności cały czas i stabilności na poziomie 99% jeżeli chodzi o stawianie infrastruktury.
Terraform jest fajny dopóki coś się nie wyłoży, wtedy szukaj gdzie leży problem, po twojej stronie, chmury, czy terraforma, a tak możesz pisać ticket to supporta cloud provaidera, a z terraformem możesz pisać list rozpaczy, poza tym CLI i ARM są native, terraform, już nie, więc terraform to najgorsza z możliwych opcji, którą jako tako można przełknąć z bólem, przy cross cloud, ale za to opcja mocno promowana przez rożnych marketingowców
3
Michał karwec napisał(a):
oliver_ napisał(a):
Terraform. Pisałem w Pulumi, CloudFormation i Terraform wygrywa póki co.
Jeżeli nie używa się "null resources" i helm chartów oraz skryptów bashowych (nawet twórcy to odradzają) ,tylko czysty, deklaratywny Terraform to ma się gwarancję idempotentności cały czas i stabilności na poziomie 99% jeżeli chodzi o stawianie infrastruktury.
Terraform jest fajny dopóki coś się nie wyłoży, wtedy szukaj gdzie leży problem, po twojej stronie, chmury, czy terraforma, a tak możesz pisać ticket to supporta cloud provaidera, a z terraformem możesz pisać list rozpaczy,
Podaj proszę konkretne przykłady, bo takie ogólniki to sobie można pisać
0
oliver_ napisał(a):
Michał karwec napisał(a):
oliver_ napisał(a):
Terraform. Pisałem w Pulumi, CloudFormation i Terraform wygrywa póki co.
Jeżeli nie używa się "null resources" i helm chartów oraz skryptów bashowych (nawet twórcy to odradzają) ,tylko czysty, deklaratywny Terraform to ma się gwarancję idempotentności cały czas i stabilności na poziomie 99% jeżeli chodzi o stawianie infrastruktury.
Terraform jest fajny dopóki coś się nie wyłoży, wtedy szukaj gdzie leży problem, po twojej stronie, chmury, czy terraforma, a tak możesz pisać ticket to supporta cloud provaidera, a z terraformem możesz pisać list rozpaczy,
Podaj proszę konkretne przykłady, bo takie ogólniki to sobie można pisać
Kiedyś mieliśmy buga w Azure, nie chciało wdrożyć bicepa(w sumie to arm), sprawa była o tyle prosta że mógł być to albo kod, albo chmura, albo oba, po sprawdzeniu tego co napisaliśmy poszedł ticket do supporta, pomogli, tymczasem terraform nie jest obsługiwany przez support chmury( chyba że coś się zmieniło) jako narzędzie za które provider nie odpowiada, teraz do kogo piszesz i jak znajdziesz po czyjej stronie leży problem? gdzie wywaliło buga, jak ci wywali arma możesz wdrożyć go na osobnym koncie, wtedy masz prawie pewność czyja to wina jak ci wywali terraforma to dalej pozostaje albo kod albo bug w terraform.
2
Michał karwec napisał(a):
teraz do kogo piszesz i jak znajdziesz po czyjej stronie leży problem?
W skrócie to odpalasz Terraforma w trybie debug, podglądasz jakie requesty leciały do cloud providera i na tej podstawie stwierdzasz czy to bug w TF czy w providerze ;)
2
Na 100% nie skrypty w bashu. Będziesz miał ochotę się zabić własną pięścią. W przypadku Azure i zakładając, że nie potrzebujesz możliwości "łatwej migracji" do innej chmury, to bicep jest OK. Jak potrzebujesz opowiadać komuś, że "da się zmigrować", albo potrzebujesz do CV, to Terraform.