Terraform vs. Ansible: Pa Un sydd Ei Angen Mewn Gwirionedd?

Mae pobl newydd i Infrastructure as Code fel arfer yn gofyn am hyn mewn un o ddau ffordd: "pa dŵl ddylwn i ddysgu yn gyntaf" neu "pam mae timau'n defnyddio'r ddau." Yr ateb byr yw bod Terraform ac Ansible yn datrys problemau gwahanol, ac mae'r rhan fwyaf o setiau cynhyrchu yn eu defnyddio gyda'i gilydd yn hytrach na dewis un.

Beth mae Terraform mewn gwirionedd ar gyfer

Terraform yw tŵl darpariaethu. Mae'n datgan beth ddylai'r seilwaith fodoli: VPC, tri achos EC2, cronfa ddata RDS, bwced S3 gyda pholisi penodol. Rydych chi'n ysgrifennu HCL yn disgrifio'r cyflwr terfynol, yn rhedeg terraform plan i weld beth fydd yn newid, ac yna terraform apply i'w wneud yn digwydd. Mae Terraform yn cadw ffeil cyflwr (yn lleol neu mewn cefndir fel bwced S3 gyda chloi DynamoDB) sy'n mapio'ch ffurfweddiad i adnodd go iawn yn y darparwr cwmwl.

Yr heddwch yma yw datrys dibyniaethau ar draws darparwyr. Os ydych chi'n dweud wrth Terraform i greu grŵp diogelwch ac yna'i atodi i achos EC2, mae'n gweithio'r trefn yn awtomatig. Mae hefyd yn gweithio ar draws AWS, Azure, GCP, Cloudflare, Datadog, a duzinau o ddarparwyr eraill drwy'r un llif gwaith, sy'n bwysig pan mae'ch seilwaith yn ymestyn dros fwy nag un darparwr.

Mae Terraform yn wael ar unrhyw beth sy'n digwydd y tu mewn i'r peiriant ar ôl iddo fodoli. Nid yw'n gosod pecynnau, yn golygu ffeiliau ffurfweddiad, neu'n ail-ddechrau gwasanaethau mewn unrhyw ffordd ystyrlon parhaus. Mae darparwyr fel remote-exec yn bodoli ond mae HashiCorp ei hun yn argymell eu hosgoi ar gyfer unrhyw beth y tu hwnt i asgwrn cefn.

Beth mae Ansible mewn gwirionedd ar gyfer

Ansible yw tŵl rheoli ffurfweddiad. Mae'n cysylltu dros SSH (neu WinRM ar gyfer Windows) ac yn rhedeg tasgau yn erbyn peirianau sy'n bodoli'n barod: gosod nginx, templed ffeil ffurfweddiad, creu defnyddiwr, ail-ddechrau gwasanaeth, gorfodi bod gwaith cron yn bresennol. Mae Playbooks yn YAML, ac mae modiwlau'n idempotent yn ôl dyluniad, felly ni ddylai rhedeg yr un playbook ddwywaith newid dim byd yr ail dro os yw'r system yn barod yn cyd-fynd â'r cyflwr dymunol.

Nid oes angen i Ansible fod ag asiantau wedi'u gosod ar leoliadau targed, dim ond Python ac mynediad SSH, sy'n ei gwneud yn hawdd ei bolltio i seilwaith sy'n bodoli'n barod. Mae hefyd yn dda ar dasgau trefnu nad ydynt yn gwbl "darparu" — ail-ddechrau cyn belled ag yn ôl holl y fflyd, camau glas-gwyrdd, rhedeg symudiad cronfa ddata ar un lleoliad ac yna diweddaru llwybrydd llwytho.

Lle maent yn gorgyffwrdd a lle mae pobl yn drysu

Mae'r ddau dŵl yn gallu yn dechnegol wneud ychydig o waith y llall. Mae gan Ansible fodiwoau cwmwl (amazon.aws.ec2_instance, azure.azcollection.azure_rm_virtualmachine) a all droi i fyny seilwaith. Mae gan Terraform ddarparwyr a all redeg gorchmynion cragen ar achos newydd. Ond defnyddio Ansible ar gyfer darpariaethu yn golygu ildio dilyniant cyflwr Terraform a llif gwaith cynllun/gwahaniaeth, ac mae defnyddio darparwyr Terraform ar gyfer ffurfweddiad yn golygu ildio rheoli ffurfweddiad idempotent, ailadroddus.

Y rhaniad ymarferol y mae'r rhan fwyaf o dimau'n glanio arno:

• Mae Terraform yn adeiladu'r seilwaith: rhwydweithiau, achosion cyfrifiant, llwybrydd llwytho, cronfeydd data rheoledig, rolau IAM.
• Mae Ansible yn ffurfweddu beth sydd ar ei ben: gosodiadau meddalwedd, defnyddwyr, ffeiliau ffurfweddiad, cyflwr gwasanaeth, camau gweithredu gweithredu cymhwysiad.

Enghraifft bendant o'r trosglwyddo

Dywedwch eich bod yn sefydlu tri gweinydd gwe y tu ôl i lwybrydd llwytho ar AWS.

resource "aws_instance" "web" {
  count         = 3
  ami           = data.aws_ami.ubuntu.id
  instance_type = "t3.medium"
  tags = { Name = "web-${count.index}" }
}

output "web_ips" {
  value = aws_instance.web[*].public_ip
}

Mae Terraform yn creu'r achosion ac yn allbwn eu IPs. Gallwch chi fwydo'r allbwn hwnnw i eiddo Ansible deinamig (mae'r ategyn eiddo amazon.aws.aws_ec2 yn darllen tagiau EC2 yn uniongyrchol, dim copïo-gludio â llaw) ac yna rhedeg:

ansible-playbook -i aws_ec2.yml site.yml

lle mae site.yml yn gosod nginx, yn gollwng ffurfweddiad yr ap, ac yn dechrau'r gwasanaeth. Nid yw Terraform byth yn cyffwrdd nginx. Nid yw Ansible byth yn cyffwrdd y VPC. Mae pob tŵl yn aros yn ei lôn, ac mae gan bob un ei ddilyniant cyflwr / model idempotency ei hun nad yw'n gwrthdaro â'r llall.

Camgymeriadau cyffredin sy'n werth eu hosgoi

Storio cyflwr Terraform mewn git yw'r camgymeriad cynnar mwyaf cyffredin — gall ffeiliau cyflwr gynnwys cyfrinachau mewn testun plaen a achosi gwrthdrawiadau cydgludo sy'n llygru'ch model seilwaith. Defnyddiwch gefndir pell o ddiwrnod cyntaf.

Gydag Ansible, y camgymeriad yw ysgrifennu playbooks nad ydynt mewn gwirionedd idempotent — defnyddio modiwlau shell neu command ar gyfer pethau sydd â modiwl priodol (ansible.builtin.apt, ansible.builtin.copy, ansible.builtin.systemd) sy'n barod yn trin y rhesymeg gwiriad-ac-weithred yn gywir.

Os ydych chi'n penderfynu beth i'w ddysgu yn gyntaf: dysgwch Terraform os ydych chi'n gwneud darpariaethu cwmwl a setups aml-amgylchedd, dysgwch Ansible os ydych chi'n rheoli gludir ffurfweddiad ar weinyddion sydd gennych eisoes. Mae'r rhan fwyaf o rolau DevOps yn disgwyl cyfarwyddyd â'r ddau o fewn y flwyddyn gyntaf.

Am ragor ar reolaeth cyflwr, eiddo deinamig, ac adeiladu poiplen CI/CD llawn o amgylch yr offer hyn, gwiriwch y segmentau DevOps a Chwmwl cysylltiedig ar Korra Studio.