Hogyan kezeli a Terraform az infrastruktúra tervet és alkalmazást?

A Terraform olyan eszköz, amely lehetővé teszi az infrastruktúra kezelését és automatizálását kód alapú konfigurációkkal. A folyamatok több lépésben zajlanak, és mindegyik kulcsfontosságú a megfelelő infrastruktúra kiépítéséhez és karbantartásához. Az egyik legfontosabb lépés a „plan” fázis, amely biztosítja, hogy az infrastruktúra a kívánt módon jöjjön létre, és megfeleljen a beállított elvárásoknak. Ezen kívül az „apply” és a „destroy” parancsok lehetővé teszik az erőforrások alkalmazását és eltávolítását, a különböző problémák megoldására pedig az automatikusan generált üzenetek segítenek.

A „terraform plan” parancs segítségével előre megtervezhetjük, hogyan fog kinézni az új infrastruktúra. Ha egy új projektet hozunk létre, amelyhez nincs előzetesen meghatározott erőforrás, a tervben több elem is szerepelhet, amelyeket „+” jellel jelölnek, ami azt jelzi, hogy létrehozásra kerülnek. A tervben szereplő erőforrásokkal kapcsolatos részletek, mint például az automatikusan generált nevek vagy ID-k, szintén szerepelnek, így biztosak lehetünk abban, hogy a kívánt elemek jönnek létre.

A Terraform ezt követően egy hosszú kimenetet generálhat, amelyet fájlba menthetünk, hogy a csapat tagjai más módokon is ellenőrizhessék és véleményezhessék. Ehhez a „terraform plan -out=myplan.out” parancsot használhatjuk, és így a fájlban mentett tervet később alkalmazhatjuk, például egy folyamatos integrációs rendszerben. Miután minden részletet ellenőriztünk és megerősítettük, a „terraform apply” parancsot adhatjuk ki, hogy végrehajtsuk a tervet, és létrehozzuk az erőforrásokat.

Az alkalmazás folyamata úgy kezdődik, hogy a „terraform apply” parancsot kiadjuk. Amikor nem mentettük el előzőleg a tervet fájlba, a Terraform újraszámolja a tervet, majd megjeleníti az elvárt változtatásokat, és felkéri a felhasználót, hogy erősítse meg azokat. A „yes” billentyű lenyomása után a Terraform csatlakozik a felhőszolgáltatóhoz, és létrehozza az erőforrásokat. Például ha a „main.tf” fájlban szereplő konfigurációban egy „ProjectRG” nevű Azure Resource Group-ot hozunk létre a „WestUS” régióban, a Terraform az egyes létrehozási lépéseket logolja, és a kimeneti konzolon megjelenítenek minden egyes lépést.

Miután a művelet befejeződött, a Terraform frissíti a helyi vagy távoli állapotfájlt, hogy tükrözze a létrehozott erőforrást, ezzel biztosítva, hogy a jövőben ne próbálja újra létrehozni azt. Amennyiben az erőforrások nem hozhatók létre, például jogosultsági vagy konfigurációs problémák miatt, a Terraform leáll és hibát jelez. Az ilyen típusú problémákat a kódban vagy a hitelesítési adatokban történt javításokkal orvosolhatjuk, majd újabb „apply” parancsot kiadva folytathatjuk az infrastruktúra kiépítését.

Amikor az erőforrásokra már nincs szükség, vagy egy ideiglenes tesztkörnyezetet törlünk, a „terraform destroy” parancs segítségével eltávolíthatjuk őket. Ez a parancs végigmegy az aktuális állapotfájlban szereplő erőforrásokon, és törlésre jelöli őket. A törlés terve is megjelenik, a Terraform jelezni fogja, hogy mely erőforrások kerülnek eltávolításra, és ezek adatait a rendszer automatikusan kitakarítja. Ha egy erőforrás nincs a konfigurációban, de a szolgáltató környezetében jelen van, a Terraform nem fogja azt automatikusan törölni, hacsak nem importáltuk vagy nem követtük nyomon.

A Terraform konfigurálásához elengedhetetlen a megfelelő változók használata. A változók lehetővé teszik, hogy a konfigurációk rugalmasak legyenek, és különböző környezetekben könnyen alkalmazhatók legyenek anélkül, hogy minden alkalommal módosítanunk kellene a kódot. A változók segítségével paraméterezhetjük az infrastruktúra elemeit, és biztosíthatjuk, hogy az ugyanazon kód alapján különböző környezetekben is másképp viselkedjen. A változók így a kód újrafelhasználhatóságát is növelik, ami elősegíti a fenntarthatóságot.

A változók deklarálása általában a „variables.tf” fájlban történik. A deklarálás során megadhatjuk a típusukat, alapértelmezett értéküket és leírásukat is. A deklarált változókat a kódban egyszerűen referálhatjuk, például a „var.location” formában. Ha valahol a kódban más értékre van szükség, azokat könnyen felülírhatjuk egy „terraform.tfvars” fájlban, környezeti változók segítségével, vagy a parancssoron keresztül.

A változók típusa lehet egyszerűbb, mint például egy string, de a Terraform lehetőséget ad komplexebb típusok, mint például listák, térképek vagy objektumok kezelésére is. A komplexebb típusok lehetővé teszik a dinamikus erőforrás-számok vagy többszörös tulajdonságok kezelését, például virtuális gépek méretének listáját vagy adatközponti térképeket.

Fontos megérteni, hogy bár a Terraform rendkívül erőteljes eszköz, a helyes alkalmazása az infrastruktúra teljes életciklusának kezelésében az alapvető. A helyes használat során a Terraform nem csupán egy erőforráskezelő eszköz, hanem a teljes infrastruktúra automatizálásának kulcsa, amely megkönnyíti az alkalmazások fejlesztését, tesztelését és üzemeltetését a felhőben. Az erőforrások alkalmazása, módosítása és törlése mind jól átgondolt tervet igényel, hogy elkerüljük a nem kívánt hatásokat, például az erőforrások véletlenszerű újraképződését vagy törlését.

Miért fontos az Infrastruktúra kód általi kezelése, és hogyan valósítja meg ezt a Terraform?

A mai modern fejlesztési és üzemeltetési gyakorlatok folyamatosan igyekeznek csökkenteni a manuális lépések számát, amelyek hibákhoz, következetlenségekhez és lassú munkafolyamatokhoz vezethetnek. Az Infrastruktúra kód általi (IaC) kezelés megoldást kínál ezekre a kihívásokra. Az IaC célja, hogy a környezetet kód formájában határozza meg – például egy virtuális hálózat, alhálózat és virtuális gép konfigurációját egy fájlban – amely lehetővé teszi az eszközök, mint például a Terraform számára, hogy automatikusan hozzák létre az előírt erőforrásokat ismételhető módon.

Vegyünk egy példát egy több szintű webalkalmazás telepítésére. Ha nem alkalmaznánk IaC-t, akkor egy rendszergazda bejelentkezik a felhő konzolra, végigmegy a varázslókon minden egyes komponenshez (hálózat, VM, adatbázis), és manuálisan összekapcsolja azokat. Ha egy második környezetre van szükség teszteléshez, akkor meg kell ismételni ezt a lépést – ami könnyen hibához vezethet, például kihagyott részletekhez vagy elfelejtett beállításokhoz. Az automatizált provisioning viszont kicseréli ezeket a lépéseket kódra, amely a megfelelő erőforrás paramétereket hivatkozza. A fejlesztő egyszerűen klónozhatja vagy újra felhasználhatja ezt a kódot, megváltoztathatja a környezeti változókat, majd hagyhatja, hogy a Terraform azonos környezetet hozzon létre. Ez a következetesség kiküszöböli a driftet a fejlesztési és éles környezetek között, és gyorsítja a hibák elhárítását, mivel minden környezet azonos alapértelmezett konfigurációval rendelkezik.

A kódolt provisioning előnyei nem csupán a következetességben rejlenek. A verziókezelő rendszerek (például a Git) tárolják az infrastruktúra minden definícióját, biztosítva egy változáskövetési naplót. Amikor egy környezet elromlik egy commit után, visszaállíthatunk egy korábbi jól működő verzióra. Az infrastruktúra provisioning kódja továbbá beépítheti a biztonság és teljesítmény legjobb gyakorlatait is, így az új telepítések automatikusan öröklik az ajánlott konfigurációkat. Ezen kívül az ephemérikus vagy rövid életű környezetek alkalmazása is könnyebbé válik, hiszen az erőforrások gyors elindítása vagy leállítása egyszerűen egy Terraform parancs végrehajtásával megoldható. Ez az ephemérikus megközelítés segít optimalizálni a költségeket és elősegíti a gyakori tesztelést.

Terraform implementálja a provisioning logikát a „provisioner”-ek segítségével, amelyek a erőforrások létrehozását és az azt követő beállítási feladatokat kötik össze. Bár a Terraform képes kezelni mindent a hálózatoktól és tárolástól kezdve a terheléselosztókig, bizonyos feladatok – mint például csomagok telepítése egy újonnan indított virtuális gépre – nem mindig rendelkeznek közvetlen erőforrás megfelelőikkel. A provisionerek segítenek kitölteni ezeket a réseket azáltal, hogy lehetőséget biztosítanak a végső szkriptek futtatására vagy fájlok átvitelére erőforrás létrehozása után.

Például egy shell scriptet tölthetünk fel a Terraform segítségével, majd futtathatjuk azt a biztonsági javítások konfigurálására. A provisionerek a Terraform alapmodelljén kívül működnek, így csak akkor alkalmazzuk őket, amikor nincs jobb megoldás. Ha a felhőszolgáltató natív erőforrása vagy egy dedikált konfigurációkezelő eszköz (mint például az Ansible) képes ugyanazokat a műveleteket elvégezni, akkor általában érdemes azokat a megoldásokat választani, mivel stabilabbak és karbantarthatóbbak.

A Terraform négy fő beépített provisionert kínál: file, local-exec, remote-exec és null_resource. Mindegyik kicsit eltérő forgatókönyveket céloz meg. A file provisioner például fájlokat másol a helyi rendszerből egy távoli gépre, így lehetővé téve szkriptek, konfigurációs fájlok vagy egész könyvtárak átvitelét. A local-exec provisioner parancsot futtat a Terraform által futtatott gépen, például külső API-k hívására vagy a helyi adatbázis frissítésére. A remote-exec provisioner a távoli erőforráshoz való bejelentkezést biztosít SSH vagy WinRM segítségével, és a parancsokat a VM-en hajtja végre, például szoftverek telepítésére. Végül a null_resource egy speciális "dummy" erőforrás, amely provisionereket tartalmaz anélkül, hogy azok bármilyen valódi infrastruktúra erőforráshoz kapcsolódnának.

A provisionerek általában vagy erőforrás létrehozásakor, vagy törlésük után kerülnek végrehajtásra, a konfigurációtól függően. Ha egy provisioner hibát észlel, a Terraform jellemzően "megtépázott" erőforrásként jelöli azt. A következő futtatáskor a Terraform újraépíti a erőforrást, próbálkozva a hiba kijavításával. Ez azonban zűrzavart okozhat a termelési rendszerekben, ha egy apró provisioning hiba miatt az egész erőforrást újra kell építeni. Továbbá, ezek a szkriptek nem futnak automatikusan újra erőforrás frissítésekor. Ha folyamatos változtatásokra van szükség, akkor egy dedikált konfigurációkezelő eszköz (például Ansible) általában robusztusabb megoldást nyújt.

A provisionerek helyes használata fontos, különösen a fájlok átvitele vagy a kezdő szkriptek futtatása esetén. Azonban, mivel a provisionerek a legjobb megoldást nem mindig kínálják, a környezetek és telepítések kezelése során mindig ügyelni kell arra, hogy a megfelelő eszközt válasszuk. Az optimális megoldás érdekében a Terraformot és más konfigurációkezelő eszközöket kombinálva is alkalmazhatjuk, hogy a lehető legjobb eredményt érjük el.

Hogyan végezhetünk automatizált tesztelést Terraform konfigurációkhoz Terratest használatával?

A Terraform konfigurációk tesztelése kulcsfontosságú ahhoz, hogy biztosak legyünk abban, hogy az infrastruktúra, amit létrehozunk, megfelelően működik, és az elvárt eredményeket hozza. Ehhez használhatjuk a Terratest-et, amely egy Go-alapú keretrendszer, és lehetővé teszi a Terraform konfigurációk tesztelését és automatizálását. Az alábbiakban bemutatjuk, hogyan végezhetünk unit és integrációs tesztelést, valamint hogyan alkalmazhatjuk ezeket a gyakorlatban.

Képzeljük el, hogy van egy Terraform modulunk, amely egy erőforrás csoportot és egy Azure Storage Account-ot hoz létre. A konfiguráció egy egyszerű main.tf fájlt tartalmaz, amely a következőket tartalmazza:

hcl
Copy code
provider "azurerm" {
  features {}
}

variable "resource_group_name" {
  type        = string
  description = "Name for the resource group."
}

variable "storage_account_name" {
  type        = string
  description = "Name for the storage account."
}

resource "azurerm_resource_group" "rg" {
  name     = var.resource_group_name
  location = "East US"
}

resource "azurerm_storage_account" "acct" {
  name                     = var.storage_account_name
  resource_group_name       = azurerm_resource_group.rg.name
  location                 = azurerm_resource_group.rg.location
  account_tier              = "Standard"
  account_replication_type = "LRS"
}

output "storage_id" {
  value = azurerm_storage_account.acct.id
}

A fenti konfiguráció két változót vár: resource_group_name és storage_account_name. A Terraform létrehozza az erőforrás csoportot és a tároló fiókot, majd visszaadja a tároló fiók azonosítóját.

A tesztkódunk a következőképpen nézhet ki a test/unit_test.go fájlban:

go
Copy code
package test

import (
  "fmt"
  "testing"
  "github.com/gruntwork-io/terratest/modules/terraform"
  "github.com/stretchr/testify/assert"
)

func TestStorageAccountUnit(t *testing.T) {
  t.Parallel()

  // Változók meghatározása
  rgName := "test-rg"
  storageName := "teststoracctxyz"

  // Terratest beállítások
  terraformOptions := &terraform.Options{
    TerraformDir: "../",
    Vars: map[string]interface{}{
      "resource_group_name":  rgName,
      "storage_account_name": storageName,
    },
  }

  // Futás előtt tisztítás
  defer terraform.Destroy(t, terraformOptions)
  terraform.InitAndApply(t, terraformOptions)

  // Kimenet lekérése
  storageID := terraform.Output(t, terraformOptions, "storage_id")

  // Ellenőrzés
  assert.NotEmpty(t, storageID, "Storage ID should not be empty")
  expected := fmt.Sprintf("teststoracctxyz")
  assert.Contains(t, storageID, expected, "Storage ID should contain the provided storage account name")
}

Ebben a tesztkódban a terraformOptions a szülő könyvtárra mutat, és beállítja a resource_group_name és storage_account_name változókat. A terraform.InitAndApply futtatása után lekérhetjük az output blokkból a storage_id értéket, és azt ellenőrizhetjük, hogy nem üres-e, illetve hogy tartalmazza-e a megadott tároló fiók nevét.

A teszt futtatása a következő parancsokkal történik:

bash
Copy code
go mod init github.com/youruser/yourrepo
go get github.com/gruntwork-io/terratest/modules/terraform
go get github.com/stretchr/testify
go test -v

Ez a folyamat inicializálja a Go modult, letölti a Terratest és testify függőségeket, majd lefuttatja a tesztet. Ha sikeres, a logok azt mutatják, hogy a Terraform sikeresen alkalmazta a konfigurációt, és minden állítás teljesült. Ha a teszt nem sikerül, a logok tájékoztatást adnak arról, hogy a hiba az erőforrás létrehozásából vagy a váratlan kimenetből ered-e.

A fenti teszt egy egyszerű unit teszt, amely csak egy kis részegység viselkedését ellenőrzi. Az integrációs tesztelés azonban ennél összetettebb feladatokat végez.

Integrációs tesztelés során több modult vagy összetevőt vizsgálunk meg, hogy azok együttműködése megfelelő-e. Például, ha egy virtuális hálózat (VNet) modult, egy virtuális gép (VM) modult és egy biztonsági csoport (NSG) modult integrálunk, akkor nemcsak azt kell ellenőriznünk, hogy az egyes erőforrások helyesen lettek-e létrehozva, hanem azt is, hogy ezek az erőforrások megfelelően integrálódnak egymással. A kódunk a következő módon nézhet ki:

hcl
Copy code
module "vnet_module" {
  source     = "./modules/vnet_module"
  vnet_name  = "integration-vnet"
  cidr_block = "10.0.0.0/16"
  subnet_cidr = "10.0.1.0/24"
}

module "vm_module" {
  source     = "./modules/vm_module"
  vm_name    = "int-test-vm"
  subnet_id  = module.vnet_module.subnet_id
}

A test/integration_test.go fájlban a következő kódot használhatjuk:

go
Copy code
package test

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

func TestIntegrationModules(t *testing.T) {
  t.Parallel()

  // Teszt változók
  vnetName := "integration-vnet"
  vmName := "int-test-vm"

  // Terratest beállítások
  terraformOptions := &terraform.Options{
    TerraformDir: "../",
    Vars: map[string]interface{}{
      "vnet_name": vnetName,
      "vm_name":   vmName,
    },
  }

  // Teszt utáni tisztítás
  defer terraform.Destroy(t, terraformOptions)
  terraform.InitAndApply(t, terraformOptions)

  // Kimenetek lekérése
  actualVnetID := terraform.Output(t, terraformOptions, "vnet_id")
  actualSubnetID := terraform.Output(t, terraformOptions, "subnet_id")
  actualVMID := terraform.Output(t, terraformOptions, "vm_id")

  // Ellenőrzések
  assert.NotEmpty(t, actualVnetID, "VNet ID should be set")
  assert.NotEmpty(t, actualSubnetID, "Subnet ID should be set")
  assert.NotEmpty(t, actualVMID, "VM ID should be set")
}

Az integrációs teszt során a rendszer több komponenst hoz létre, például egy virtuális hálózatot, egy alhálózatot és egy virtuális gépet. Ezáltal biztosíthatjuk, hogy a különböző modulok megfelelően működnek együtt, és hogy az egyes modulok kimenetei összhangban vannak a várakozásokkal.

Fontos megérteni, hogy az integrációs tesztelés célja nem csupán az egyes modulok működésének ellenőrzése, hanem azok együttműködésének vizsgálata is. A teszt során előfordulhatnak olyan problémák, mint a rosszul megnevezett erőforrások vagy a nem megfelelő sorrendben történő erőforrások létrehozása, amelyeket a megfelelő hibaüzenetek segíthetnek azonosítani.

A validációs tesztelés már a ténylegesen éles környezetben történő működést ellenőrzi, és biztosítja, hogy az infrastruktúra valóban megfeleljen a valós igényeknek és elvárásoknak.

Hogyan állítsuk be a Terraform környezetet az Azure számára?

A Microsoft Azure felhőplatformjára történő beállítás és integráció különböző módszerekkel végezhető el, de a Terraform a legnépszerűbb és legkényelmesebb eszköz az infrastruktúra kezelésére, különösen a vállalatok és fejlesztők számára. A következő részletes leírás bemutatja a legfontosabb lépéseket és eljárásokat, hogy miként állíthatunk be egy működőképes Terraform-környezetet, és hogyan végezhetünk el alapvető feladatokat az Azure-ban.

Az Azure Portal felhasználói felülete már az első belépéskor hozzáférhetővé válik, és számos gyorsparancsot kínál a mindennapi feladatokhoz, például Windows vagy Linux virtuális gép létrehozásához, adatbázisok kezeléséhez vagy fejlettebb funkciók, mint például a szerver nélküli funkciók felfedezéséhez. Az egyszerű felhasználók gyakran kezdhetik a platform tesztelését egy alapvető feladattal, például egy erőforrás-csoport létrehozásával és egy virtuális gép beállításával. Az erőforrások kezelésére többféle módszer is létezik, de a Terraform lehetőséget ad a teljes körű automatizálásra, így nem szükséges kézzel konfigurálni a beállításokat.

A legelső lépés az Azure fiók regisztrálása, ami telefonos ellenőrzést is igényel. Ez gyorsan megerősíti a felhasználó személyazonosságát, és megelőzi a csalásokat a platformon. Az Azure fiók aktiválása után célszerű a többfaktoros hitelesítést (MFA) engedélyezni, hogy ha valaki megszerzi a jelszót, akkor sem férhessen hozzá könnyedén a fiókhoz. Ezt a Microsoft fiók biztonsági beállításainál találhatjuk. Ha több felhasználóval dolgozunk ugyanazon a bérlőn, akkor az adminisztrátorok alkalmazhatják az MFA-t minden fiókra, javítva ezzel a csapat biztonságát.

A szerepkör-alapú hozzáférés-vezérlés (RBAC) segíthet a különböző felhasználói jogosultságok pontosabb meghatározásában. Az Azure-ban alapértelmezés szerint a fiók létrehozója széleskörű jogosultságokkal rendelkezik, de célszerű korlátozni a hozzáférést és beállítani a szerepeket. Például előfordulhat, hogy egy felhasználónak csak olvasási jogosultságot adunk, így nem tud új erőforrást létrehozni vagy törölni.

A Terraform működéséhez szükség van a megfelelő jogosultságokkal rendelkező szolgáltatói alapú hitelesítésre, amelyet a szolgáltatói elvégzése biztosít. A CLI segíti a parancsok kiadását és az Azure erőforrások kezelését. Ehhez az Azure CLI-t kell telepíteni, majd az az login parancs segítségével belépni a rendszerbe, ezután már programozott módon kérdezhetjük le vagy módosíthatjuk az Azure erőforrásokat. Az Azure CLI telepítése Linux vagy macOS rendszereken a Microsoft hivatalos tárolójából, vagy csomagkezelővel, mint például a Homebrew segítségével történhet. A Windows felhasználók egyszerűen az MSI csomagot vagy a Microsoft Store-t használhatják.

A szolgáltatói fiók egy dedikált identitás, amelyet a Terraform használ a hitelesítéshez. Létrehozása az az ad sp create-for-rbac --role="Contributor" parancs segítségével történik. Az így létrejövő outputban szereplő appId, clientSecret és tenant értékeket be kell helyettesíteni a Terraform konfigurációs fájlba. A következő konfiguráció egy alapvető példa arra, hogyan nézhet ki egy Terraform main.tf fájl az Azure szolgáltató beállításához:

hcl
Copy code
provider "azurerm" {
  features {}
  subscription_id = "YOUR_SUBSCRIPTION_ID"
  client_id       = "YOUR_APP_ID"
  client_secret   = "YOUR_CLIENT_SECRET"
  tenant_id       = "YOUR_TENANT_ID"
}

A titkos kulcsok biztonságos tárolása fontos, ezért ajánlott azokat környezeti változóban vagy titkos tárolókban kezelni, elkerülve azok közvetlen tárolását a kódban. A titkos adatokat az Azure tárolók, mint a Key Vault is kezelhetik.

A következő lépésként létrehozhatunk egy erőforrás-csoportot, hogy teszteljük az Azure környezetünket és a Terraform beállításokat. Egy egyszerű main.tf fájl a következőképpen nézhet ki:

hcl
Copy code
terraform {
  required_providers {
    azurerm = {
      source  = "hashicorp/azurerm"
      version = "=3.0.0"
    }
  }
}

provider "azurerm" {
  features {}
  subscription_id = var.azure_subscription_id
  client_id       = var.azure_client_id
  client_secret   = var.azure_client_secret
  tenant_id       = var.azure_tenant_id
}

resource "azurerm_resource_group" "example_rg" {
  name     = "example-resource-group"
  location = "EastUS"
}

Ez a kód létrehoz egy erőforrás-csoportot az Azure-ban. Az erőforrás-csoport egy logikai tároló, amely az Azure erőforrásait szervezi. A Terraform terraform init parancsával letöltjük a szükséges szolgáltatói kódot, majd a terraform plan parancs segítségével ellenőrizhetjük a létrehozandó erőforrást. Ha minden rendben van, a terraform apply parancs végrehajtja a kívánt műveleteket. Az erőforrás-csoportot az Azure Portálon is ellenőrizhetjük.

A későbbiekben más összetettebb erőforrásokat is létrehozhatunk, például virtuális hálózatokat vagy tárolókat, amelyek még erősebbé teszik az infrastruktúrát. A megfelelő beállítások és a biztonságos kezelési elvek figyelembevételével az Azure és a Terraform kombinációja lehetővé teszi a dinamikus és rugalmas infrastruktúra menedzsmentet, amely kiválóan alkalmazható a vállalati környezetekben.

A tervezésnél és a megvalósításnál mindig ügyeljünk arra, hogy a jogosultságok minimalizálására törekedjünk, különösen, ha több felhasználó dolgozik egy projekten. A legjobb gyakorlat, ha a titkos adatokat biztonságos módon, például környezeti változóként vagy külső titkos tárolóban kezeljük, és a kódot nem tároljuk verziókezelő rendszerekben. Ez jelentősen csökkenti az adatvesztés vagy adatlopás kockázatát.