Infrastructure as Code: Terraform, Ansible

Infrastructure as Code: Terraform, Ansible

1) რატომ არის IaC და რით განსხვავდება ინსტრუმენტები?

Terraform არის დეკლარაციული orchestrator-IaC: ქმნის/ცვლის ღრუბლოვან ინფრასტრუქტურას (VPC, K8s, LB, BD, IAM) პროვაიდერების საშუალებით. აკონტროლებს რესურსების სასიცოცხლო ციკლს და ინახავს მდგომარეობას.
Ansible - პროცედურული config-IaC და კონფიგურაციის მენეჯმენტი: კონფიგურაცია მასპინძლები/პროგრამული უზრუნველყოფა (პაკეტები, ფაილები, სერვისები), იცის როგორ უნდა გააკეთოს აპლიკაციების რევიზია, ტემპლეიტინგი, ნაბიჯების ორკესტრი. აგენტის გარეშე (SSH/WinRM), დავალებების იდემპოტენტურობით.

კომბინაცია: Terraform - „საიდანაც გაკეთდა პლატფორმა“, Ansible - „როგორ არის მორგებული და ამოქმედებულია“.

2) საცავებისა და ფენების სტრუქტურა

1. ფონდი (Landing Zone): ქსელები, IAM, KMS, ძირითადი ჟურნალები/მონიტორინგი.

2. პლატფორმა: Kubernetes მტევანი, ბაზები, რიგები, observability დასტის.

3. Workloads: სივრცეები/ნეიმსპეები, მომსახურების ანგარიშები, პოლიტიკოსები, კონფისკაცია.

• 'iac/terraform/' - მოდულები და გარემო (' მოდულები/', 'envs/').
• 'iac/ansible/' - როლები (' roles/'), playbooks ('playbooks/'), ინვენტარი (' ინვესტიციები/').
• 'policies/' - OPA/Conftest წესები.
• 'pipelines/' - CI/CD სკრიპტები (lint/plan/apply/test).

3) Terraform: მოდულები, სტატი, გარემო

3. 1 მოდული

მცირე, გამოყენებული: 'vpc', 'eks', 'rdis', 'redis', 'alb', 'iam-role'.
შესასვლელი 'variables. tf ', გამოშვებები. tf ', ვერსიები - მოდულის/git ჭდეების რეესტრის საშუალებით.

hcl module "vpc" {
source = "git::ssh://git@repo/iac. git//modules/vpc? ref=v1. 6. 0"
name  = "prod-core"
cidr  = "10. 0. 0. 0/16"
azs  = ["eu-central-1a","eu-central-1b"]
}

3. 2 სახელმწიფო (სახელმწიფო)

დისტანციური ჩამკეტი (S3/GCS + DynamoDB/LockTable) + დაბლოკვა.
დაყოფა გარემოში: 'moden. tfstate`, `staging. tfstate`.
სახელმწიფო დრიფტი: 'terraform plan' CI- ში გრაფიკით; ალერტი დრიფტის დროს.

hcl terraform {
backend "s3" {
bucket     = "iac-state"
key      = "prod/network/terraform. tfstate"
region     = "eu-central-1"
dynamodb_table = "iac-locks"
encrypt    = true
}
}

3. 3 Workspaces / Envs

• ცალკეული კატალოგები 'envs/stage', 'envs/stage' (ვიზუალურად).
• Workspaces მსუბუქი ცვალებადობისთვის, მაგრამ თავიდან აიცილეთ საიდუმლოებების შერევა.
• პარამეტრები 'tfvars' - ის საშუალებით: 'წამყვანები. tfvars`, `stage. tfvars`.

4) Ansible: როლები, ინვენტარი, იდემპოტენტობა

4. 1 როლები და ფლეიბუკები

roles/
nginx/
tasks/main. yml templates/.j2 handlers/main. yml defaults/main. yml playbooks/
site. yml

yaml
- hosts: web become: true roles:
- role: nginx vars:
nginx_listen_port: 8080

4. 2 ინვენტარი და დინამიკა

`inventories/prod/hosts. yml '+ ცვლადი' group _ vars/host _ vars '.
დინამიური ინვენტარი: 'aws _ ec2', 'gcp _ compute', 'kubernetes. core`.

4. 3 იდემპოტენტობა

გამოიყენეთ მოდულები (არა 'shell') იქ, სადაც შესაძლებელია.
'changed _ when '/' check _ mode' მშრალი პროგონებისთვის.
Handlers ასახავს მხოლოდ ცვლილებების დროს.

5) საიდუმლოებები და კონფისკაცია

Terraform: მნიშვნელობების სეკრეცია 'sensitive = true'; თავად საიდუმლოებები არ არის სახელმწიფო (შეინახეთ AWS საიდუმლო მენეჯერი/HashiCorp Vault/KMS და მოიხსენიეთ მონაცემთა წყარო).
Ansible: Vault ცვლადის დაშიფვრისთვის ('ansible-vault encrypt'), ინტეგრაცია HashiCorp Vault/KMS- სთან.
GitOps: საიდუმლოებები ცალკეულ რეპო/საცავში, წვდომა Least privilege.

6) პოლიტიკა და შესაბამისობა

OPA/Conftest Terraform- ისთვის: საჯარო S3 აკრძალვა, ღია SG, შეუსაბამო რესურსები (tags).
Terraform Cloud/Enterprise - Sentinel, როგორც ალტერნატივა.
Ansible Lint: სტილი და უსაფრთხოება ('sudo: yes' - ს გარეშე, სადაც არ არის საჭირო, raw-shell- ის გარეშე).

rego package terraform. security

deny[msg] {
input. resource_type == "aws_security_group_rule"
input. values. cidr_blocks[_] == "0. 0. 0. 0/0"
input. values. from_port == 22 msg:= "SSH from 0. 0. 0. 0/0 is forbidden"
}

7) IaC ტესტირება

Terraform: 'tflint', 'tfsec '/' checkov', Terratest (Go) ინტეგრაციის შემოწმებისთვის.
Ansible: 'ansible-lint', Molecule (+ Docker/Podman/EC2) როლების შესამოწმებლად.
სმოკის ტესტები appy შემდეგ: HTTP probes, პორტი/პროცესები, უფლებები.

8) CI/CD и GitOps

1. Lint/Sec: tflint, tfsec/checkov, ansible-lint.

2. პლანი: 'terraform plan' არტეფაქტის გამოქვეყნებით (კომენტარი MR- ში).

3. Policy Gate: Conftest/Sentinel.

4. Apply (approved): მხოლოდ მაღაროში, არტეფაქტების ხელმოწერით.

5. Ansible deploy: '-check' სცენაზე, შემდეგ '-diff' -ში.

6. Post-checks: სინთეზური/Probe, გამოშვების პრეზენტაციის დაშლა.

• შეინახეთ მანიფესტები, როგორც სიმართლის წყარო; Argo CD/Flux for Kubernetes, მაგრამ ძირითადი მტევანი/პრიმიტივები - Terraform- ის საშუალებით.

9) ნიმუშები კუბერნეტებისთვის, ქსელები, BD

9. 1 Kubernetes

Terraform: EKS/GKE/AKS მტევანი, კვანძები, IAM, StorageClass, LB.
Ansible: AMI/სარდაფების მომზადება, სურათების/საცავის შეკრება, პოსტის ინსტალაცია (ლოგერები/აგენტები/OTel).

9. 2 ქსელები და პერიმეტრი

Terraform: VPC/ქვესახეები/NAT/Transit-Gateway/WAF, მარშრუტები.
Ansible: NGINX/Envoy/HAProxy, TLS, WAF- ის კონფიგურაცია.

9. 3 ბაზა/ქეში/რიგები

Terraform: RDS/CloudSQL ჯგუფის პარამეტრი, Redis/ElastiCache, Kafka/MSK.
Ansible: ქეში დათბობა, მიგრაციის დავალებები, ბომბების/აგენტების კონფიგურაცია.

10) ჩამორთმევის მაგალითები

10. 1 Terraform — RDS PostgreSQL + SG

hcl module "db" {
source        = "terraform-aws-modules/rds/aws"
engine        = "postgres"
engine_version    = "15. 4"
instance_class    = "db. m6g. large"
allocated_storage  = 100 name         = "core"
username       = var. db_user password       = var. db_password # см. secret data source vpc_security_group_ids = [module. db_sg. security_group_id]
multi_az       = true backup_retention   = 7
}

module "db_sg" {
source = "terraform-aws-modules/security-group/aws"
name  = "db-core"
vpc_id = module. vpc. vpc_id ingress_cidr_blocks = ["10. 0. 0. 0/8"]
ingress_rules    = ["postgresql-tcp"]
}

10. 2 Terraform - მონაცემთა საიდუმლოების წყარო

hcl data "aws_secretsmanager_secret_version" "db" {
secret_id = "prod/db/core"
}
variable "db_password" {
type   = string sensitive = true default  = jsondecode(data. aws_secretsmanager_secret_version. db. secret_string). password
}

10. 3 Ansible - postgresql-client- ის როლი (ფრაგმენტი)

yaml
- name: Install packages apt:
name: [ "postgresql-client-15" ]
state: present update_cache: yes

- name: Create. pgpass copy:
dest: /home/deploy/.pgpass mode: '0600'
content: "{{ db_host }}:5432:core:{{ db_user }}:{{ db_password }}"
no_log: true

- name: Smoke query shell: psql -h {{ db_host }} -U {{ db_user }} -d core -c "select 1"
register: psql_out changed_when: false

10. 4 Ansible - NGINX Template

yaml
- name: Deploy nginx. conf template:
src: templates/nginx. conf. j2 dest: /etc/nginx/nginx. conf notify: Restart nginx

- name: Ensure nginx running service:
name: nginx state: started enabled: true

handlers:
- name: Restart nginx service: { name: nginx, state: restarted }

11) დრიფტის მართვა და შესაბამისობა

პერიოდული 'terraform plan' read-only გასაღები; განშორების დროს ქმნის ტიკეტს.
Ansible -check გრაფიკის კრიტიკული როლებისთვის (აუდიტის რეჟიმი).
მოხსენებები: შეუსრულებელი პოლიტიკოსები OPA/Conftest, რესურსები ჭდეების/backup/მონიტორინგის გარეშე.

12) დაკვირვება და აუდიტი

logs 'terraform apply' და გეგმების ნიმუშები - შეინახეთ ობიექტის საცავში.
Ansible: 'callback _ plugins' (json) - ცენტრალური ჟურნალი/ELK; ჩართეთ job ID, commit SHA, trace _ id.
მეტრიკა: გეგმების/პლეიბუკების შესრულების დრო, ცვლილებების სიხშირე, ტესტების დაფარვა.

13) უსაფრთხოება

მოდულის/როლების ხელმოწერა ან ფიქსირებული ჭდეები/ჰეში.
მინიმალური IAM უფლებები ('plan' apply '), გაიზიარეთ CI და approver- ის როლები.
სახელმწიფო/ლოგოების დაშიფვრა, მოდულის/როლების პირადი რეესტრები.
პოლიტიკა „no plaintext საიდუმლოებები VCS- ში“, საიდუმლო სკანერები (gitleaks/trufflehog).

14) ანტი შაბლონები

ერთი მონსტრი მოდული Terraform „ყველაფრისთვის“; მოდულის ვერსიების არარსებობა.
ადგილობრივი 'terraform. tfstate 'და საკეტების ნაკლებობა.
IaC- ის თავზე ღრუბელში ხელით გამოსწორება მარადიული დრიფტია.
მოდულის ნაცვლად Ansible 'shell '/' command' (არღვევს idempotence).
ინვენტარი „ერთ ფაილში“ ჯგუფების/ცვლადის გარეშე, შერევა/ეტაპი.
საიდუმლოებები vars/საცავებში, Vault/KMS- ის არარსებობა.
Apply გარეშე Plan და Peer Review.

15) განხორციელების სიის სია (0-45 დღე)

0-10 დღე

დისტანციური პაკეტის/ლოკის კონფიგურაცია, Terraform მოდულების დაშლა.
ჩართეთ tflint/tfsec/checkov, ansible-lint; შეთანხმდნენ რესურსების ტეგებზე/ეტიკეტებზე.
შეასრულეთ Ansible როლი NGINX/აგენტებისთვის/ლოგერებისთვის; ინვენტარის ორგანიზება.

11-25 დღე

დაამატეთ Conftest/OPA, Terratest და Molecule კრიტიკული მოდულები/როლებისთვის.
CI: 'plan' on MR, გეგმის არტეფაქტი, მანუალური-აპლუსი აპლოვით; Ansible `--check` на stage.
საიდუმლო საცავის ინტეგრაცია (Vault/KMS/Secrets მენეჯერი).

26-45 დღე

საგზაო გეგმა დრიფტის დეტალებისთვის, მოხსენებები პოლიტიკოსების შესახებ.
ვერსიით მოდულის/როლების კატალოგი; დოკუმენტაცია 'README. თითოეულში md '.
GitOps: გამოშვების ვიდეოები, მონიტორინგი და ალერტის კარიბჭეები.

16) სიმწიფის მეტრიკა

დისტანციური სახელმწიფო და ხალიჩების მქონე გარემოს% = 100%.
ტესტებით მოდულის/როლების წილი (Terratest/Molecule) 70% -ს შეადგენს.
საშუალო დრო MR- დან appy- მდე (mosh) არის საათი, არა დღეები.
ნულოვანი „სახელმძღვანელო დრიფტი“ (ყველა ცვლილება გადის MR).
კრიტიკული რესურსების 100% დაფარულია Policy as Code- ით (ჭდეები, დაშიფვრა, ქილა).

17) დასკვნა

Terraform ადგენს პროგნოზირებადი, განმეორებით ინფრასტრუქტურის ბაზას; Ansible მასპინძლებს და მომსახურებებს მიაქვს საჭირო მდგომარეობაში. დაამატეთ Policy as Code, წაშლილი სახელმწიფო, ტესტები, საიდუმლო მენეჯმენტი და CI/CD პლანის მიმოხილვით - და თქვენი IaC წრე გახდება კონტროლირებადი, უსაფრთხო და სწრაფი, ხოლო გამოშვებები იქნება ატომური და შექცევადი.