Terraform i OpenTofu – nowoczesne zarządzanie chmurą i automatyzacja DevOps

Infrastruktura jako kod – nowy standard w IT

Współczesne środowiska IT są dynamiczne, wielochmurowe i wymagają pełnej automatyzacji. Ręczne tworzenie maszyn wirtualnych, sieci czy baz danych w panelach administracyjnych AWS, Azure czy GCP nie tylko spowalnia pracę, ale zwiększa ryzyko błędów.

Odpowiedzią na te wyzwania jest Infrastructure as Code (IaC) – podejście, w którym cała infrastruktura opisywana jest w kodzie. Najpopularniejszymi narzędziami w tym obszarze są dziś Terraform oraz OpenTofu. Infrastructure as Code (IaC) przestało być luksusem, a stało się niezbędnym elementem nowoczesnego podejścia do zarządzania infrastrukturą. W tym artykule przyjrzymy się dwóm najpotężniejszym narzędziom w tej dziedzinie – Terraform i OpenTofu – oraz ich zastosowaniu w zarządzaniu wieloma platformami chmurowymi.

Sprawdź szczegóły: https://asdevops.pl/n8n

 

 

 

Terraform i OpenTofu – czym są i czym się różnią?

Terraform

Terraform, stworzony przez HashiCorp, to de facto standard rynkowy w zakresie IaC. Pozwala deklaratywnie opisać infrastrukturę i wdrażać ją w niemal każdej chmurze publicznej i prywatnej.

OpenTofu

OpenTofu to open‑source’owy fork Terraforma, rozwijany przez społeczność po zmianach licencyjnych HashiCorp. Dla użytkownika końcowego OpenTofu:

• korzysta z tej samej składni (HCL),
• obsługuje te same providery,
• jest w pełni kompatybilny z istniejącymi projektami Terraform,
• gwarantuje otwarty rozwój i brak ograniczeń licencyjnych.

W praktyce wiele organizacji traktuje dziś Terraform i OpenTofu zamiennie.

Automatyzacja procesów DevOps – przykłady praktyczne

Terraform i OpenTofu najlepiej pokazują swoją wartość w realnych scenariuszach DevOps. Poniżej kilka konkretnych przykładów, jak IaC automatyzuje codzienną pracę zespołów IT.

Przykład 1: Automatyczne środowiska dev / test / prod

Zamiast ręcznie tworzyć infrastrukturę dla każdego środowiska, definiujesz ją raz, a różnice obsługujesz przez zmienne:

• environment = dev | test | prod
• inne rozmiary maszyn
• różne limity autoskalowania

Efekt:

• jedno repozytorium kodu,
• identyczna architektura,
• brak problemów typu „u mnie działa”.

Przykład 2: Skalowanie infrastruktury

Zmiana liczby instancji w Auto Scaling Group w AWS lub node pool w AKS/GKE to często jedna linijka kodu. Terraform porównuje stan aktualny z docelowym i wykonuje tylko niezbędne zmiany.

Przykład 3: Disaster Recovery

Cała infrastruktura opisana w kodzie pozwala:

• odtworzyć środowisko w innej chmurze lub regionie,
• uruchomić je od zera w kilkanaście minut,
• przetestować scenariusze awaryjne bez ryzyka.

Kod infrastruktury przechowywany w repozytorium Git daje pełną historię zmian oraz możliwość pracy zespołowej.

Zarządzanie multi-cloud: Jeden język, wiele chmur

Prawdziwa siła Terraform/OpenTofu objawia się w środowiskach multi-cloud. Oto przykład zarządzania identyczną infrastrukturą w różnych chmurach:

AWS: Tworzenie środowiska web

hcl
provider "aws" {
  region = "eu-central-1"
}

resource "aws_vpc" "main" {
  cidr_block = "10.0.0.0/16"
  
  tags = {
    Name        = "production-vpc"
    Environment = "production"
  }
}

resource "aws_instance" "web" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t3.medium"
  
  vpc_security_group_ids = [aws_security_group.web.id]
  subnet_id              = aws_subnet.public.id
  
  tags = {
    Name = "web-server"
  }
}

resource "aws_s3_bucket" "static_assets" {
  bucket = "my-app-static-assets"
}

Azure: Równoległa infrastruktura

hcl
provider "azurerm" {
  features {}
}

resource "azurerm_resource_group" "main" {
  name     = "production-rg"
  location = "West Europe"
}

resource "azurerm_virtual_network" "main" {
  name                = "production-vnet"
  address_space       = ["10.0.0.0/16"]
  location            = azurerm_resource_group.main.location
  resource_group_name = azurerm_resource_group.main.name
}

resource "azurerm_linux_virtual_machine" "web" {
  name                = "web-vm"
  resource_group_name = azurerm_resource_group.main.name
  location            = azurerm_resource_group.main.location
  size                = "Standard_B2s"
  
  admin_username = "adminuser"
  
  network_interface_ids = [
    azurerm_network_interface.main.id,
  ]
}

GCP: Infrastruktura w Google Cloud

hcl
provider "google" {
  project = "my-project-id"
  region  = "europe-west3"
}

resource "google_compute_network" "vpc" {
  name                    = "production-vpc"
  auto_create_subnetworks = false
}

resource "google_compute_instance" "web" {
  name         = "web-server"
  machine_type = "e2-medium"
  zone         = "europe-west3-a"
  
  boot_disk {
    initialize_params {
      image = "debian-cloud/debian-11"
    }
  }
  
  network_interface {
    network = google_compute_network.vpc.name
  }
}

resource "google_storage_bucket" "static" {
  name     = "my-app-static-assets"
  location = "EU"
}

DigitalOcean: Prosta i efektywna infrastruktura

hcl
provider "digitalocean" {
  token = var.do_token
}

resource "digitalocean_vpc" "main" {
  name   = "production-vpc"
  region = "fra1"
}

resource "digitalocean_droplet" "web" {
  image  = "ubuntu-22-04-x64"
  name   = "web-server"
  region = "fra1"
  size   = "s-2vcpu-4gb"
  vpc_uuid = digitalocean_vpc.main.id
}

resource "digitalocean_spaces_bucket" "static" {
  name   = "my-app-static-assets"
  region = "fra1"
}

Terraform i OpenTofu w pipeline CI/CD – przykłady

Prawdziwa moc IaC ujawnia się po integracji z pipeline’ami CI/CD.

Przykład: Jenkins + Terraform

Typowy pipeline Jenkins wygląda następująco:

1. Pobranie kodu z repozytorium Git
2. terraform init
3. terraform plan
4. Manualna akceptacja zmian
5. terraform apply

Taki pipeline gwarantuje, że żadna zmiana infrastruktury nie trafi na produkcję bez kontroli.

Przykład: GitHub Actions + Terraform

GitHub Actions idealnie pasuje do GitOps:

• push lub pull request uruchamia pipeline,
• terraform plan generowany automatycznie,
• wynik planu dodawany jako komentarz do PR,
• apply możliwy tylko po merge.

Efekt: infrastruktura zmienia się tylko przez Git, a każdy krok jest audytowalny.

To idealne rozwiązanie dla zespołów pracujących w modelu GitOps.

Najlepsze praktyki DevOps z Terraform/OpenTofu

1. Struktura projektu

infrastructure/
├── environments/
│   ├── dev/
│   │   ├── main.tf
│   │   ├── variables.tf
│   │   └── terraform.tfvars
│   ├── staging/
│   └── prod/
├── modules/
│   ├── networking/
│   ├── compute/
│   └── database/
├── policies/
│   └── sentinel/ (lub OPA)
└── scripts/
    ├── validate.sh
    └── deploy.sh

2. Remote State z blokowaniem

hcl
terraform {
  backend "s3" {
    bucket         = "my-terraform-state"
    key            = "prod/terraform.tfstate"
    region         = "eu-central-1"
    encrypt        = true
    dynamodb_table = "terraform-locks"
    
    # OpenTofu dodaje enkrypcję state'u:
    # state_encryption = true
  }
}

3. Moduły wielokrotnego użytku

hcl
module "web_cluster" {
  source = "./modules/compute-cluster"
  
  for_each = {
    aws    = "us-east-1"
    azure  = "westeurope"
    gcp    = "europe-west1"
  }
  
  cloud_provider = each.key
  region         = each.value
  instance_count = 3
  environment    = "production"
}

4. Testy infrastruktury

hcl
# test/main_test.go
package test

import (
    "testing"
    "github.com/gruntwork-io/terratest/modules/terraform"
)

func TestWebServerDeployment(t *testing.T) {
    terraformOptions := &terraform.Options{
        TerraformDir: "../environments/dev",
    }
    
    defer terraform.Destroy(t, terraformOptions)
    terraform.InitAndApply(t, terraformOptions)
    
    instanceIP := terraform.Output(t, terraformOptions, "instance_ip")
    // Sprawdź czy serwer odpowiada...
}

GitOps i kontrola infrastruktury

Połączenie Terraform / OpenTofu z GitOps daje:

• jedyne źródło prawdy (repozytorium Git)
• pełną audytowalność zmian
• łatwy rollback
• spójne procesy w całej organizacji

Infrastruktura przestaje być „czarną skrzynką” – staje się czytelnym, wersjonowanym kodem.

---

Dlaczego warto inwestować w Terraform i OpenTofu?

Znajomość IaC to dziś jedna z najbardziej poszukiwanych kompetencji w IT.

Korzyści biznesowe:

• szybsze wdrożenia
• mniejsze ryzyko błędów
• łatwiejsze skalowanie
• niższe koszty utrzymania

Korzyści dla specjalistów IT:

• realna przewaga na rynku pracy
• praca z nowoczesnymi technologiami
• możliwość pracy w projektach multi‑cloud

Terraform i OpenTofu to fundament nowoczesnego zarządzania infrastrukturą w chmurze. Niezależnie od tego, czy pracujesz z AWS, Azure, GCP czy DigitalOcean, te narzędzia pozwalają Ci automatyzować, standaryzować i skalować środowiska w sposób bezpieczny i przewidywalny.

W połączeniu z pipeline’ami CI/CD, Jenkins czy GitHub Actions, IaC staje się kluczowym elementem dojrzałych procesów DevOps.

Jeśli myślisz o rozwoju w kierunku DevOps lub Cloud Engineer – Terraform i OpenTofu to umiejętności, które po prostu musisz mieć.

Chcesz więcej? Zerknij na nasz kurs pod adresem:

https://grupadm.pl/product/kurs-terraform