Pulumi vs Terraform w 2026: Infrastructure as Code z TypeScript i Pytania Rekrutacyjne

Pulumi vs Terraform to kluczowa decyzja dotycząca infrastruktury jako kodu dla zespołów DevOps w 2026 roku. Oba narzędzia umożliwiają deklaratywne tworzenie zasobów chmurowych, ale różnią się obsługą języków programowania, zarządzaniem stanem i dojrzałością ekosystemu. To porównanie obejmuje techniczne kompromisy, przykłady kodu w TypeScript i HCL oraz pytania rekrutacyjne, które pojawiają się podczas omawiania wyborów IaC.

Architektura: Silnik Pulumi vs Cykl Plan-Apply Terraform

Terraform wykorzystuje język domenowy (HCL) i dwufazowy przepływ pracy: terraform plan generuje plan wykonania, terraform apply go realizuje. Plik stanu śledzi metadane zasobów i jest przechowywany lokalnie lub w zdalnych backendach takich jak S3 czy Terraform Cloud.

Pulumi osadza swój silnik w środowiskach uruchomieniowych języków ogólnego przeznaczenia. Programy napisane w TypeScript, Python, Go lub C# wykonują się bezpośrednio względem API chmurowych poprzez providerów Pulumi. Stan jest domyślnie przechowywany w Pulumi Cloud, z opcjami samodzielnie zarządzanych backendów, w tym S3, Azure Blob Storage i plików lokalnych.

Różnica architektoniczna ujawnia się natychmiast w sposobie obsługi pętli, warunków i abstrakcji. for_each i count w Terraform działają w ramach ograniczeń HCL. Programy Pulumi wykorzystują natywne konstrukcje językowe: for...of w TypeScript, list comprehensions w Python, range w Go.

import * as aws from "@pulumi/aws";
import * as pulumi from "@pulumi/pulumi";

// Native TypeScript array methods work directly
const environments = ["dev", "staging", "prod"];

const buckets = environments.map(env => 
  new aws.s3.BucketV2(`data-${env}`, {
    bucket: `myapp-data-${env}-${pulumi.getStack()}`,
    tags: {
      Environment: env,
      ManagedBy: "pulumi",
    },
  })
);

// Export bucket ARNs as stack outputs
export const bucketArns = buckets.map(b => b.arn);

Odpowiednia konfiguracja Terraform wymaga składni HCL do iteracji:

# main.tf - Terraform HCL example
variable "environments" {
  type    = list(string)
  default = ["dev", "staging", "prod"]
}

resource "aws_s3_bucket" "data" {
  for_each = toset(var.environments)

  bucket = "myapp-data-${each.key}-${terraform.workspace}"

  tags = {
    Environment = each.key
    ManagedBy   = "terraform"
  }
}

output "bucket_arns" {
  value = [for b in aws_s3_bucket.data : b.arn]
}

Oba fragmenty kodu tworzą trzy buckety S3. Wersja Terraform jest zwięzła i czytelna dla każdego znającego HCL. Wersja Pulumi wykorzystuje standardowy TypeScript, co oznacza autouzupełnianie IDE, sprawdzanie typów i integrację z istniejącymi bazami kodu bez nauki nowego języka.

Obsługa TypeScript: Natywny Język vs CDKTF (Wycofany)

Pulumi obsługuje TypeScript od pierwszego publicznego wydania. SDK udostępnia typowane klasy zasobów, a pulumi.Output<T> opakowuje asynchroniczne wartości, które są rozwiązywane podczas wdrożenia. Narzędzia do refaktoryzacji, lintery i frameworki testowe z ekosystemu TypeScript mają bezpośrednie zastosowanie.

Odpowiedzią Terraform na obsługę języków ogólnego przeznaczenia był CDKTF (Cloud Development Kit for Terraform). CDKTF pozwalał zespołom pisać TypeScript lub Python, które kompilowały się do Terraform JSON. HashiCorp wycofał CDKTF w grudniu 2025 roku i zarchiwizował repozytorium. Istniejące projekty CDKTF nadal działają, ale nie są publikowane aktualizacje dla nowych wersji Terraform ani zmian providerów.

Dla zespołów chcących używać TypeScript IaC w 2026 roku, Pulumi jest aktywnie rozwijaną opcją. Zespoły, które zainwestowały w CDKTF, mogą kontynuować uruchamianie swoich stosów, ale migracja do HCL lub Pulumi jest ścieżką naprzód dla nowych projektów.

import * as aws from "@pulumi/aws";
import * as pulumi from "@pulumi/pulumi";

// Custom component encapsulating VPC, subnets, and routing
export class StandardVpc extends pulumi.ComponentResource {
  public readonly vpcId: pulumi.Output<string>;
  public readonly publicSubnetIds: pulumi.Output<string>[];

  constructor(name: string, args: { cidr: string; azCount: number }, opts?: pulumi.ComponentResourceOptions) {
    super("mycompany:network:StandardVpc", name, {}, opts);

    const vpc = new aws.ec2.Vpc(`${name}-vpc`, {
      cidrBlock: args.cidr,
      enableDnsHostnames: true,
      tags: { Name: name },
    }, { parent: this });

    this.vpcId = vpc.id;

    // Create public subnets across availability zones
    const azs = aws.getAvailabilityZones({ state: "available" });
    this.publicSubnetIds = [];

    for (let i = 0; i < args.azCount; i++) {
      const subnet = new aws.ec2.Subnet(`${name}-public-${i}`, {
        vpcId: vpc.id,
        cidrBlock: `10.0.${i}.0/24`,
        availabilityZone: azs.then(az => az.names[i]),
        mapPublicIpOnLaunch: true,
        tags: { Name: `${name}-public-${i}` },
      }, { parent: this });
      this.publicSubnetIds.push(subnet.id);
    }

    this.registerOutputs({ vpcId: this.vpcId });
  }
}

Ten komponent Pulumi tworzy wielokrotnego użytku abstrakcję VPC. Użytkownicy instancjonują go za pomocą new StandardVpc("prod", { cidr: "10.0.0.0/16", azCount: 3 }). Odpowiednik w Terraform to katalog modułu z zmiennymi, outputami i plikami HCL. Oba podejścia umożliwiają ponowne użycie; wersja Pulumi dziedziczy narzędzia TypeScript do dokumentacji, testowania i wersjonowania.

Zarządzanie Stanem i Opcje Backendów

Zarządzanie stanem to obszar, gdzie pojawiają się różnice operacyjne. Stan Terraform zawiera identyfikatory zasobów, metadane providerów i wrażliwe wartości. Zespoły muszą skonfigurować zdalne backendy, aby umożliwić współpracę i zaimplementować blokowanie, aby zapobiec jednoczesnym modyfikacjom.

Konfiguracja backendu Terraform obsługuje S3, Azure Blob, Google Cloud Storage, Terraform Cloud i inne. Każdy backend wymaga własnej konfiguracji uwierzytelniania. Blokowanie stanu wykorzystuje DynamoDB dla backendów S3, dzierżawy blobów dla Azure lub natywne blokowanie w Terraform Cloud.

Pulumi Cloud domyślnie obsługuje przechowywanie stanu, blokowanie i historię. Zespoły tworzą darmowe konto, uruchamiają pulumi login i zarządzanie stanem jest skonfigurowane. Dla zespołów wymagających samodzielnie zarządzanego stanu, Pulumi obsługuje backendy S3, Azure Blob, GCS i plików lokalnych za pomocą polecenia pulumi login.

# Pulumi: login to self-managed S3 backend
pulumi login s3://my-pulumi-state-bucket

# Terraform: configure S3 backend in HCL
# backend.tf
terraform {
  backend "s3" {
    bucket         = "my-terraform-state"
    key            = "prod/terraform.tfstate"
    region         = "us-east-1"
    dynamodb_table = "terraform-locks"
    encrypt        = true
  }
}

Pulumi Cloud zapewnia interfejs webowy do historii stosów, wizualizacji zasobów i uprawnień zespołu. Terraform Cloud oferuje podobne funkcje z egzekwowaniem polityk poprzez Sentinel. Opcje self-hosted istnieją dla obu: samodzielnie hostowany backend Pulumi i Terraform Enterprise.

Ekosystem Providerów i Wsparcie Multi-Cloud

Ekosystem providerów Terraform jest największy w IaC. Terraform Registry wymienia ponad 4000 providerów obejmujących AWS, Azure, GCP, Kubernetes i setki platform SaaS. Jakość providerów jest zróżnicowana: oficjalni providerzy HashiCorp i dostawców chmurowych otrzymują regularne aktualizacje, podczas gdy providerzy społecznościowi mogą pozostawać w tyle za zmianami API.

Providerzy Pulumi opakowują providerów Terraform za pomocą bridge'a, który generuje typowane SDK. Pulumi Registry udostępnia providerów dla głównych chmur, Kubernetes, baz danych i usług monitoringu. Ponieważ Pulumi wykorzystuje bridge dla providerów Terraform, pokrycie ekosystemu jest porównywalne, choć nowe wersje providerów Terraform wymagają aktualizacji bridge'a, zanim SDK Pulumi odzwierciedlą zmiany.

Pulumi oferuje również natywnych providerów napisanych bezpośrednio przeciwko API chmurowym. Natywni providerzy dla AWS, Azure i Kubernetes dostarczają wsparcie tego samego dnia dla nowych funkcji API. Kompromis polega na tym, że natywni providerzy istnieją tylko dla głównych chmur; mniej popularne usługi wykorzystują providerów opartych na bridge.

// Using Pulumi's native AWS provider for Lambda
import * as aws from "@pulumi/aws";
import * as pulumi from "@pulumi/pulumi";

const role = new aws.iam.Role("lambda-role", {
  assumeRolePolicy: aws.iam.assumeRolePolicyForPrincipal({
    Service: "lambda.amazonaws.com",
  }),
});

const lambdaFunction = new aws.lambda.Function("api-handler", {
  runtime: aws.lambda.Runtime.NodeJS20dX,
  handler: "index.handler",
  role: role.arn,
  code: new pulumi.asset.AssetArchive({
    "index.js": new pulumi.asset.StringAsset(
      `exports.handler = async () => ({ statusCode: 200, body: "OK" });`
    ),
  }),
});

export const functionArn = lambdaFunction.arn;

Testowanie Kodu Infrastruktury

Testowanie to obszar, gdzie wybór języka tworzy różnice. Programy Pulumi to standardowy kod, więc testy jednostkowe wykorzystują znane frameworki. Moduł @pulumi/pulumi/runtime zapewnia mockowanie tworzenia zasobów, pozwalając testom weryfikować konfigurację bez wdrażania zasobów.

import { describe, it, expect, beforeAll } from "vitest";
import * as pulumi from "@pulumi/pulumi";

// Mock Pulumi runtime
pulumi.runtime.setMocks({
  newResource: (args: pulumi.runtime.MockResourceArgs) => {
    return { id: `${args.name}-id`, state: args.inputs };
  },
  call: (args: pulumi.runtime.MockCallArgs) => {
    return args.inputs;
  },
});

describe("S3 Bucket Configuration", () => {
  let bucketTags: Record<string, string>;

  beforeAll(async () => {
    // Import the Pulumi program after mocks are set
    const infra = await import("../infra/index");
    // Extract outputs for testing
    bucketTags = await new Promise(resolve => {
      infra.buckets[0].tags.apply(tags => resolve(tags as Record<string, string>));
    });
  });

  it("should tag buckets with Environment", () => {
    expect(bucketTags).toHaveProperty("Environment");
  });

  it("should tag buckets with ManagedBy", () => {
    expect(bucketTags.ManagedBy).toBe("pulumi");
  });
});

Testowanie Terraform wykorzystuje terraform test (wprowadzony w Terraform 1.6) lub zewnętrzne narzędzia takie jak Terratest. terraform test uruchamia pliki testowe HCL, które tworzą rzeczywiste zasoby w izolowanych konfiguracjach. Terratest to biblioteka Go, która opakowuje polecenia Terraform i zapewnia asercje.

# tests/bucket.tftest.hcl - Terraform native test
run "bucket_tags" {
  command = plan

  assert {
    condition     = aws_s3_bucket.data["dev"].tags["Environment"] == "dev"
    error_message = "Bucket must be tagged with Environment"
  }

  assert {
    condition     = aws_s3_bucket.data["dev"].tags["ManagedBy"] == "terraform"
    error_message = "Bucket must be tagged with ManagedBy"
  }
}

Oba podejścia walidują konfigurację infrastruktury. Zaletą Pulumi jest integracja z runnerami testów TypeScript i narzędziami do pokrycia kodu. Natywne testy Terraform działają bez zewnętrznych zależności, ale wymagają składni HCL.

Pytania Rekrutacyjne: Pulumi vs Terraform

Rozmowy rekrutacyjne DevOps w 2026 roku często zawierają porównania narzędzi IaC. Oto pytania, które wyróżniają kandydatów, którzy używali obu narzędzi w produkcji.

"Co się dzieje, gdy stan Terraform rozchodzi się z rzeczywistą infrastrukturą?"

Oczekiwana odpowiedź: terraform plan wykrywa dryft porównując stan z rzeczywistą infrastrukturą. Plan pokazuje zasoby do aktualizacji, utworzenia lub zniszczenia. Dryft występuje, gdy zmiany są wprowadzane poza Terraform (konsola, CLI, inne narzędzia). Opcje obejmują terraform refresh do aktualizacji stanu, terraform import do objęcia zasobów zarządzaniem lub zaakceptowanie planu w celu przywrócenia pożądanego stanu.

"W jaki sposób Pulumi obsługuje sekrety inaczej niż Terraform?"

Oczekiwana odpowiedź: Pulumi domyślnie szyfruje sekrety w stanie używając hasła lub KMS chmurowego. Funkcja pulumi.secret() oznacza wartości jako wrażliwe i pozostają one zaszyfrowane w spoczynku. Terraform przechowuje sekrety w postaci tekstowej w plikach stanu; zespoły polegają na szyfrowaniu backendu (szyfrowanie po stronie serwera S3) i kontrolach dostępu. Terraform 1.4 dodał oznaczanie zmiennych jako sensitive, ale wartości nadal pojawiają się niezaszyfrowane w stanie.

"Dlaczego HashiCorp wycofał CDKTF i jakie są opcje migracji?"

Oczekiwana odpowiedź: CDKTF dodawał obciążenie związane z utrzymaniem bez dorównywania kadencji aktualizacji Terraform. Nowe wersje providerów i funkcje Terraform wymagały ręcznych aktualizacji bindingów CDK. HashiCorp zdecydował się skupić na HCL i Terraform Cloud. Opcje migracji to: konwersja do HCL za pomocą cdktf convert, przepisanie w Pulumi jeśli TypeScript jest wymagany, lub kontynuowanie uruchamiania istniejących stosów CDKTF bez aktualizacji.

"Kiedy wybrałbyś Pulumi zamiast Terraform dla nowego projektu?"

Oczekiwana odpowiedź: Wybierz Pulumi, gdy zespół już używa TypeScript/Python/Go i chce IaC w tym samym języku co kod aplikacji, gdy złożone abstrakcje wymagają prawdziwych konstrukcji programistycznych (generyki, interfejsy, frameworki testowe), lub gdy wbudowane szyfrowanie sekretów jest wymaganiem. Wybierz Terraform, gdy zespół zna HCL, gdy ekosystem providerów musi obejmować niszowych lub społecznościowych providerów, lub gdy narzędzia organizacyjne (Atlantis, Spacelift) integrują się z Terraform.

Strategie Migracji: Terraform do Pulumi

Pulumi dostarcza pulumi import do objęcia zarządzaniem istniejących zasobów chmurowych bez ich odtwarzania. Dla zespołów ze stanem Terraform, pulumi convert tłumaczy HCL na programy Pulumi. Konwersja nie jest idealna: złożone moduły i dynamiczne bloki wymagają ręcznej korekty.

# Convert Terraform HCL to Pulumi TypeScript
pulumi convert --from terraform --language typescript

# Import existing AWS resources into Pulumi state
pulumi import aws:s3/bucketV2:BucketV2 my-bucket my-existing-bucket-name

Migracja etapowa pozwala zespołom uruchamiać oba narzędzia podczas przejścia. Terraform zarządza istniejącymi stosami, podczas gdy Pulumi udostępnia nową infrastrukturę. Gdy zespoły zdobędą doświadczenie z Pulumi, konwertują stosy Terraform przyrostowo. Stan nie jest współdzielony między narzędziami, więc zarządzanie zasobami musi być wyraźnie podzielone, aby uniknąć konfliktów.

Framework Decyzyjny na 2026 Rok

Kluczowe Wnioski dla Infrastructure as Code w 2026

• Terraform 1.16 to stabilny wybór dla IaC opartego na HCL z największym ekosystemem providerów i dojrzałymi narzędziami (Atlantis, Spacelift, env0).
• Pulumi v3.263 oferuje TypeScript, Python, Go i C# z natywnym testowaniem językowym, integracją IDE i wbudowanym szyfrowaniem sekretów.
• CDKTF jest wycofany od grudnia 2025. Zespoły chcące TypeScript IaC powinny ocenić Pulumi zamiast rozpoczynać nowe projekty CDKTF.
• Oba narzędzia obsługują wdrożenia multi-cloud, zdalne backendy stanu i współpracę zespołową. Wybór zależy od preferencji językowych i istniejącej ekspertyzy zespołu.
• Dyskusje rekrutacyjne powinny demonstrować zrozumienie zarządzania stanem, wykrywania dryftu, ekosystemów providerów i kompromisów między prostotą DSL a mocą języka ogólnego przeznaczenia.
• Migracja z Terraform do Pulumi jest możliwa za pomocą pulumi convert i pulumi import, ale wymaga starannego planowania i etapowego wdrożenia.