linuxlab.io
Учебники▾
  • Линукс и сети
    Файловая система, процессы, TCP/IP, BGP и OSPF
    →
  • Terraform и IaC
    HCL, state, plan/apply на sandbox LocalStack
    →
  • Git и GitHub
    Объектная модель, plumbing, ветвление, GitHub Actions
    →
Все учебники →
ЦеныО платформеВойтиСоздать аккаунт
/
Intro
Lessons
Footer
linuxlab-УчебникиЦеныО платформеКонфиденциальность и куки
Copyright © 2026 LinuxLab. Все права защищены.
linuxlab.io
Учебники▾
  • Линукс и сети
    Файловая система, процессы, TCP/IP, BGP и OSPF
    →
  • Terraform и IaC
    HCL, state, plan/apply на sandbox LocalStack
    →
  • Git и GitHub
    Объектная модель, plumbing, ветвление, GitHub Actions
    →
Все учебники →
ЦеныО платформеВойтиСоздать аккаунт
/
  • Введение
  • Уроки
  • How it works
  • База знаний
  • Шпаргалка
  • Capstone
  • Собеседование
home/terraform/kb/Основы Terraform/tf-init

kb/core ── Основы Terraform ── beginner

terraform init: первая команда в любом проекте

terraform init скачивает плагины-провайдеры (AWS, GCP и т.д.), создаёт файл с зафиксированными версиями (lockfile) и подготавливает рабочую директорию. Без этого ни plan, ни apply не запустятся.

view as markdown

Что делает terraform init

Когда вы пишете в файле provider "aws" { ... }, Terraform не умеет ходить в AWS сам по себе. Ему нужен плагин-провайдер, отдельная программа, которая знает, как разговаривать с AWS API.

terraform init делает три вещи:

  1. Читает в вашем коде блок required_providers и смотрит, какие плагины нужны.
  2. Скачивает их из реестра Terraform Registry в папку .terraform/ рядом с вашим кодом.
  3. Создаёт файл .terraform.lock.hcl, там зафиксированы точные версии скачанных плагинов и их хеши. См. tf-lockfile.

После init директория готова к работе, можно запускать plan и apply.

Когда запускать

init нужно запустить первый раз после git clone чужого репозитория или после создания нового проекта. Также повторно если:

  • В коде поменялся required_providers (другой провайдер или другая версия).
  • Добавился или сменился блок backend (где хранить state, см. tf-init-backends).
  • Появился новый блок module "...".

Если ничего из этого не менялось, повторно запускать init не нужно.

Что появляется в директории

После первого init:

ваш-проект/
├── main.tf                      # ваш код
├── .terraform/                  # появилось после init
│   └── providers/
│       └── registry.terraform.io/
│           └── hashicorp/
│               └── aws/
│                   └── 5.60.0/
│                       └── linux_amd64/
│                           └── terraform-provider-aws_v5.60.0_x5
└── .terraform.lock.hcl          # тоже появилось

Важно:

  • .terraform/, это кеш. Добавляйте в .gitignore, не коммитьте.
  • .terraform.lock.hcl, наоборот, обязательно коммитьте. Это гарантия, что у коллег скачаются те же версии провайдеров.

Полезные флаги

  • terraform init -upgrade, обновить провайдеры до самых свежих в рамках version constraint. Если в коде написано version = "~> 5.0", то -upgrade поднимет с 5.50 до 5.60, но не до 6.x.
  • terraform init -reconfigure, переинициализировать с нуля. Нужен, когда вы поменяли настройки backend и Terraform спрашивает «мигрировать ли state».
  • terraform init -input=false, не задавать интерактивных вопросов. Это режим для CI/CD.

Подводные камни

  • Без интернета init не работает. Плагины качаются с registry.terraform.io. В корпоративных сетях иногда настраивают зеркало через terraform { provider_installation { ... } } в ~/.terraformrc, см. tf-cli-config.
  • Корпоративный прокси. Если ваш бэкенд в офисе и интернет только через прокси. Нужно переменные HTTPS_PROXY и HTTP_PROXY перед запуском.
  • Lockfile блокирует обновление. Если init ругается «requested version is not the locked version», значит в lockfile стоит одна версия, а вы хотите другую. Решение, либо init -upgrade, либо явно поменяйте constraint.
  • Кеш в .terraform/ зависит от ОС. Если коллега работает на macOS, а вы на Linux, .terraform/ нельзя просто перенести; каждый запускает init у себя.

Что внутри .terraform.lock.hcl

Маленький файл, который выглядит примерно так:

hcl
provider "registry.terraform.io/hashicorp/aws" {
  version     = "5.60.0"
  constraints = "~> 5.60"
  hashes = [
    "h1:abc123...",
    "h1:def456...",
  ]
}

Это гарантия воспроизводимости: следующий init поставит ровно версию 5.60.0 с ровно этими хешами. Если хеши не сошлись, init упадёт. Это защита от подменённых пакетов.

§ команды

bash
terraform init

Базовая инициализация: скачать провайдеры, создать lockfile.

bash
terraform init -upgrade

Обновить провайдеры в рамках version constraint.

bash
terraform init -reconfigure

Переинициализация после смены backend: без миграции state.

bash
TF_LOG=DEBUG terraform init

Если init подвисает или ругается: посмотреть подробный лог, что именно тянется и куда.

§ см. также

  • hcl-syntaxHCL: язык, на котором пишут TerraformHCL (HashiCorp Configuration Language): это язык, на котором описывают желаемое состояние инфраструктуры. Похож на JSON, но людям читать легче: можно писать комментарии, переменные, циклы.
  • tf-planterraform plan: посмотреть, что Terraform собирается сделатьplan, это сухая прогонка: Terraform читает ваш HCL, читает state, и показывает diff между ними. Ничего не меняет в облаке. Главный инструмент, чтобы не сломать прод по ошибке.
  • tf-lockfile.terraform.lock.hcl: фиксация версий провайдеровLockfile фиксирует точные версии провайдеров и их хеши, чтобы у тебя и у CI всегда стояла та же сборка. Создаётся при terraform init, обновляется через init -upgrade. Коммитится в git.
  • tf-version-constraintsVersion constraints в Terraform: required_version и провайдерыrequired_version фиксирует, какие версии terraform запускают этот код. required_providers.version, то же для провайдеров. Pessimistic оператор ~> 5.60, стандарт, разрешает минорные апдейты, запрещает мажорные.
  • tf-init-backendsBackend в Terraform: где живёт stateBackend, это место хранения state-файла. По умолчанию local, рядом с HCL. Remote backends (S3, GCS, Terraform Cloud, http) дают совместный доступ и блокировку. В этом курсе используется только local; remote, обзорно.
  • aws-providerAWS Provider: настройки и где Terraform берёт ключиAWS-провайдер ищет credentials в нескольких местах подряд: env-переменные, ~/.aws/credentials, IAM-роль инстанса. Чаще всего достаточно `aws configure` локально или роль на EC2, больше ничего не настраивать.
Footer
linuxlab-
Copyright © 2026 LinuxLab. Все права защищены.
Учебники
Цены
О платформе
Конфиденциальность и куки