Как вы управляете версиями изображений с помощью Packer и Terraform?

Это в значительной степени зависит от поставщика, и вы не указали облачного поставщика, который используете, но AWS представляет собой хороший пример использования здесь.

И Terraform, и Packer могут выбрать самый последний AMI, соответствующий фильтру.

Конструктор AWS AMI от Packer использует source_ami_filter, который можно использовать для выбора самое последнее изображение, на основе которого будет создано ваше изображение. Пример приведен в amazon-ebs документации по построителю:

{
  "source_ami_filter": {
    "filters": {
      "virtualization-type": "hvm",
      "name": "ubuntu/images/\*ubuntu-xenial-16.04-amd64-server-\*",
      "root-device-type": "ebs"
    },
    "owners": ["099720109477"],
    "most_recent": true
  }
}

Типичный случай здесь - всегда использовать для сборки последний официальный образ Ubuntu. Если вы создаете несколько AMI для разных вариантов использования (например, рабочие узлы Kubernetes и узлы etcd), вы можете затем создать золотой базовый образ с известной схемой именования (например, ubuntu/20.04/base/{{isotime | clean_resource_name}}), в котором есть все, что вы хотите, в каждом Создаваемый вами AMI, а затем другие AMI также могут использовать source_ami_filter для выбора самого последнего опубликованного вами базового AMI.

Провайдер AWS Terraform имеет aws_ami источник данных, который работает в таким же образом и может использоваться для автоматического выбора последнего AMI, который соответствует фильтру, чтобы публикация нового AMI и последующий запуск Terraform генерировали план для замены вашего экземпляра или запуска конфигурации / шаблона, который ссылается на источник данных AMI.

Пример приведен в aws_instance ресурсной документации:

data "aws_ami" "ubuntu" {
  most_recent = true

  filter {
    name   = "name"
    values = ["ubuntu/images/hvm-ssd/ubuntu-trusty-14.04-amd64-server-*"]
  }

  filter {
    name   = "virtualization-type"
    values = ["hvm"]
  }

  owners = ["099720109477"] # Canonical
}

resource "aws_instance" "web" {
  ami           = "${data.aws_ami.ubuntu.id}"
  instance_type = "t2.micro"

  tags = {
    Name = "HelloWorld"
  }
}

В общем, вы должны полагаться на такие механизмы, чтобы автоматически выбирать последний опубликованный AMI и использовать его вместо жесткого кодирования идентификаторов AMI в коде.

Управление жизненным циклом образов выходит за рамки самого Packer, и его следует использовать как часть более крупной системы. Если вы хотите откатить изображение, вам доступны два варианта:

• Если ваша сборка воспроизводима, и проблема в этой воспроизводимой вещи, вы можете создать и зарегистрировать новое изображение со старым кодом, чтобы ваше новейшее изображение теперь было таким же, как и изображение, которое было 2 изображения назад.
• Отмените регистрацию самого нового изображения, чтобы вы снова начали собирать старое изображение при поиске последнего. Это зависит от облачного провайдера, но с AWS это можно сделать программно, например, с помощью _ 9_ командная строка

Хотя Packer может автоматически копировать изображения в разные регионы (см. ami_regions для AWS) и разные учетные записи (используйте ami_users, чтобы поделиться создал AMI с другой учетной записью или постпроцессором для создания отдельных копий в разных учетных записях) он не может легко делать что-то условно, если у вас нет разных файлов конфигурации Packer для каждой комбинации способов, которыми вы хотите делиться вещами, и не может отделить развертывание, поэтому вы выпускаете для непроизводственной учетной записи, прежде чем выпускать для производственный счет и т. д.

Если вы хотите развернуть AMI в некоторых учетных записях и регионах, но не во всех, вам нужно будет разместить эту логику в месте более высокого порядка, например, в механизме оркестрации, таком как ваша система CI / CD.

Как бы то ни было, управление версиями образов полезно, потому что вы можете сохранить некоторые значения по умолчанию для таких вещей, как хост-узлы kubernetes (предварительно загруженные образы докеров и т. Д.), Поэтому к тому времени, когда он пройдет проверки AWS, он уже присоединяется к кластеру.

Я не делал этого для многих приложений и обнаружил, что обычно лучше сделать что-то вроде ниже

vendor-app-appversion-epoch

Этот подход позволяет вам создавать версии вашего Ami вместе с вашими приложениями, а затем вы можете обращаться с вашими экземплярами как со скотом (на убой) по сравнению с домашними животными (о которых нужно заботиться на протяжении всей их жизни).

data "aws_ami" "amazon_linux2" {
  most_recent = true
  filter {
    name = "name"
    values = ["amzn2-ami-*-x86_64-gp2"]
  }

  filter {
    name = "virtualization-type"
    values = ["hvm"]
  }

  owners = ["amazon"]
}

Это приведет к получению последнего образа для linux2, когда вы примените terraform.

Я написал сообщение в блоге по этой теме, Сохранение версий изображений Packer и Terraform , синхронизировано и СУХОЕ.

В итоге:

Наши цели

• Образы, созданные Packer, должны иметь версии.
• Управление версиями образа должно быть СУХИМ (храниться в одном месте) и совместно использоваться Packer и Terraform, чтобы избежать рассинхронизации по ошибке.
• Файлы конфигурации для Packer, Terraform и информация об управлении версиями изображений должны храниться в git, так что проверка конкретной фиксации и выполнение terraform apply должно быть достаточно для выполнения отката.
• Terraform должен автоматически определять, основываясь только на локальной информации, наличие более новой версии одного или нескольких изображений ИЛИ необходимость создания более новой версии.
• Должна быть возможность иметь N независимых сред разработки / подготовки, в которых управление версиями образов не зависит от производства.
• Подход должен быть независимым от IaaS (должен работать с любым облачным провайдером).

Краткое изложение подхода

Используйте соглашение об именах, например

<IMAGE-NAME> ::= <ROLE>__<BRANCH>-<REVISION>

Задайте значение переменной в отдельном файле packer/versions.pkvars.hcl:

service-a-img-name = "service-a__main-3"

Создайте образ с помощью:

$ packer build -var-file=versions.pkrvars.hcl minimal.pkr.hcl

На стороне Terraform, поскольку файл packer/versions.pkvars.hcl находится в HCL, мы можем прочитать его из Terraform:

$ terraform apply -var-file=../../packer/versions.pkrvars.hcl

Все подробности в упомянутом выше сообщении блога.