Steal Time. Что это такое и как работает

да, можно и так сформулировать, спасибо!

Steal Time. Что это такое и как работает

если кратко

 - если вм не имеет доступа к CPU то она не запустится совсем и разговаривать нечего

 - почти такая же сиутация будет в случае если оверселинг очень высок и фактически вм не дают времени поработать.

в обоих этих ситуациях нам не важно значение steal time - мы де факто не работаем.

это значеие важно когда мы работаем - когда мы свободно имеем доступ к цпу с тз виртуальной машины.

но тк может присутствовать эффект оверселинга, чтобы администратор VM мог его отследить и введено это понятие.

надеюсь так понятнее

Как мы переложили управление инфраструктурой на Terraform — и начали жить

спасибо что подсказали, попробуем. Мы использовали дефолтные опции валидации, без сторонних линтеров. И судя по их репе они уже могут в 0.12
github.com/wata727/tflint
«TFLint is a Terraform linter focused on possible errors, best practices, etc. (Terraform >= 0.12)»

Как мы переложили управление инфраструктурой на Terraform — и начали жить

Про Terragrunt читали но пока не дошло до практики его применения и не знаем дойдем ли. Пока просто своими силами поддерживаем конфигурации модулей и связи между ними.

По вашему вопросу — мы храним tfstate в s3 что дает его версионирование из коробки на любой чих, поэтому частично проблему это решает. И да, уже несколько раз это спасало правда не на проде.

Второй момент, как я уже упоминал это разделение проекта и соответственно разделение tfstate. У нас он вырос до неприличных размеров и сложности с тз построения плана, в итоге удалось разрезать его на несколько логически обособленных кусков, добившись во первых — более быстрого построения плана, во вторых — страхуя себя (опять же частично) от упомянутых проблем.

Ну и да, в случае если что-то идет не так — ручная работа с использованием terraform target, terraform taint

Как мы переложили управление инфраструктурой на Terraform — и начали жить

у вас версия 0.12, я в начале статьи указываю что у нас 0.11 (последняя из этой линейки) и на 0.12 мы пока не переходили. Да, возможно поведение изменилось. У нас это выглядит вот так. Вызываем мы вот так

module "test-ec" {
   count            = "1"
   count_offset     = "10"
   source           = "git::ssh://FQDN/terraform/modules/vm-general.git?ref=1.0.0"
   host_name_prefix = "${var.hostname_prefix}-srv"
   ami_id           = "${data.aws_ami.XXXXX-ami-al-2018.id}"
...

а внутри модуля оно выглядит вот так:

resource "aws_network_interface" "nic0" {
  count             = "${var.count}"
  subnet_id         = "${element(var.subnet_ids, count.index)}"
  security_groups   = ["${var.sgs_ids}"]
  source_dest_check = true
...

data "aws_subnet" "subnet" {
  count = "${var.count}"
  id    = "${aws_network_interface.nic0.*.subnet_id[count.index]}"
}


resource "aws_instance" "instance" {
  count      = "${var.count}"
....

resource "aws_ebs_volume" "ebs_volume" {
  count             = "${length(var.ebs_volumes) * var.count}"
...

resource "aws_volume_attachment" "ebs_attachment" {
  count       = "${length(var.ebs_volumes) * var.count}"
...

но мы еще дополнительно в input.tf ( мы разделяем модуль на 3 файла — описание модуля, input для входных данных и output для выходных) описываем cpunt как переменную, которая уже потом, как Вы видите выше обращается в count ресурса.
Возможно в 0.12 это слово внесли в список служебных и больше такой красивый хак не проходит

variable "count" {
  description = "Number of EC2 instances."
  default     = 0
}

variable "count_offset" {
  description = "Offset of instances. It uses for naming."
  default     = 0
}

Как мы переложили управление инфраструктурой на Terraform — и начали жить

Вы приводите ссылку на оооочень старый комит) Давно уже есть поддержка. Используем очень просто — count передается внутрь модуля, во все зависимые сущности, помогая 1 шаблоном создавать нужное число ресурсов. Плюс внутри модуля через связку count, element и еще ряда функций зашита логика связывания этих ресурсов. Так например мы передаем в модуль число хостов, которые должны быть развернуты и список подсетей. Модуль сделает указанное число EC2 инстансов, сетевых интерфейсов, дисков, rt53 записей и пр, свяжет их и раскидает по сеткам.

Как мы переложили управление инфраструктурой на Terraform — и начали жить

Используем terraforming. Сейчас уже почти нет, тк изначально все изменения совершаются через TF. Ранее приходилось применять довольно часто. Плюс мы достигли такого уровня «дзен» когда можем описать весь набор ресурсов в виде модуля, импортнуть все связанные AWS сущности внутрь и потом при помощи plan ( как тест/сравнение) довести конфигурацию до нужного вида. То есть миновать шаг «получили машинно сгеренированный код, надо его причесать»
Про структуру репозиториев — их много. По сути каждый модуль ( вернее то, что его реализует) — это репозиторий. Есть репозитории ресурсных модулей, есть инфраструктурных, есть проекты которые все это исмпользуют. Вас интересуют все они в каком-то «общем» виде или что-то конкретное? Напишите, я постараюсь пояснить.

Стейты у нас хранятся в S3 бакете с шифрованием и версионированием. Ну и конечно ограничением чрез IAM. 1 бакет на aws аккаунт, стейт каждого проекта имеет уникальное имя. Была сначала идея делать бакет под проект но отказались.

Интеграции с Atlantis как и самого Atlantis нет. Есть Gitlab + Gitlab CI, есть Ansible (как средство управления конфигурацией того, что было создано TF и мы сейчас все на него переводим), и немного легаси в виде puppet+foreman + RackTables с которыми ранее интегрировались при помощи самописных плагинов для TF.

Тесты пока не пишем и не понятно будем ли писать

Как мы переложили управление инфраструктурой на Terraform — и начали жить

Поясните пожалуйста что Вы имеете ввиду, то есть конкретней. Если я сейчас правильно понял Ваш вопрос, тогда следующим образом — любой модуль, любое изменение проходит тестирование в Lab на тестовом окружении нашей команды. Потом оно «долетает» до других Lab окружений разработчиков где уже интегрируется с изменениями софта, настроек и тп. Когда мы считаем что изменение готово — оно идет в stage и после — в prod.

Как мы переложили управление инфраструктурой на Terraform — и начали жить

Нет. Если честно вот только из Вашего комментария о нем узнал. Посмотрел их гихаб. Первый коммит в сентябре 17 года. Наш проект в то время уже жил в проде и управлялся TF, поэтому без шансов.
github.com/pulumi/pulumi/releases?after=v0.9.2

Как мы переложили управление инфраструктурой на Terraform — и начали жить

Спасибо, учту и внесу исправление!