Зачем chef provisioning пересоздал всё в AWS и как это поправить.

21.05.2018

Для того, что бы накатывать изминения в этот и некоторые другие сайты очень удобно пользоваться инструментами конфигурационного управления(Configuration Management tools), такими как OpsCode Chef, Puppet, RedHad Ansible. Мне ближе всего и удобнее использовать Chef потому что, это DSL к Ruby и код легко читается и пишется, а к тому же несколько лет назад был дополнен ещё надстройкой для создания и конфигурирования облачных ресурсов Chef Provisioning.

Понадобилось мне как-то кое-что поправить в конфигурации сайта с другого компьютера, и хотелось всё сделать правильно, тоесть в код прописать, закоммитить, нажать кнопку и всё чтобы стало хорошо. Залогинился я в консоль aws, создал там дополнительную пару ключей, потому как старая осталась на другом компе, к которому на тот момент доступа совершенно не было, и прописал эти ключи в aws config. Запустил chef-client ... и обалдел…

Не понятно почему, chef стал создавать все ресурсы (VPC, Internet Gateway, Subnets) заново, хотя такие уже существуют. Я полез, проверил конфиги - там всё правильно. Затем стал смотреть по статусу git, там тоже всё без изменений. Пошел в веб консоль, удалил новосозданные ресурсы и полез проверить структуру папок, не появилось ли чего нового. Оказалось, что появилось 2 новые папки: nodes и _databags. Вот в этих папках и храниться метадата ресурсов, о которой будет несколько подробнее.

Как сказано в документации, в nodes сохранятются все атрибуты о машинах, на которых запускался chef, в том числе и её id.

На cоставе данных в _databags я бы хотел остановиться по-подробнее, потому что мне пришлось почти вручную воссоздавать структуру с нужными параметрами. Что из себя представляет эта дирректория:

Структура _databags

data_bags/
├── aws_internet_gateway
│   └── igw-managed-by-VPCID.json
├── aws_subnet
│   └── mysite_subnet.json
└── aws_vpc
    └── vpc-vpc.json

aws_vpc

Цель - хранение информации о VPC. Посмотрим на файл mysite-vpc.json по-ближе:

{
  "id": "mysite-vpc",
  "reference": {
    "id": "VPCID"
  },
  "driver_url": "aws:mysite:eu-central-1"
}

, в котором:

id - название vpc, записанное в рецепте создания инфраструктуры,

reference.id - идентификатор vpc в AWS, вида vpc-123abcde

driver_url - строка драйвера для chef-provisioning, где aws - мы работаем с AWS, mysite - имя профиля конфигурации AWS, eu-central-1 - регион AWS, где будет создаваться оборудование.

aws_internet_gateway

Как нетрудно догадаться из названия, здесь храниться настройки AWS internet gateway. Как устроен файл igw-managed-by-VPCID.json:

{
  "id": "igw-managed-by-VPCID",
  "reference": {
    "id": "VPCID"
  },
  "driver_url": "aws:vervedea:eu-central-1"
}

Структурно, очень похоже на mysite-vpc.json

id - идентификатор, под которым chef-provisioning записал internet gateway

Всё остальное точно такое же, как и в конфиге VPC.

aws_subnet

Ссылка на подсети.

_mysitesubnet.json:

{
  "id": "vervedea_subnet",
  "reference": {
    "id": "subnet-7b93d410"
  },
  "driver_url": "aws:vervedea:eu-central-1"
}

id - идентификатор, под которым chef-provisioning записал подсеть (subnet)

reference.id - идентификатор подсети в AWS, вида subnet-123abcde

driver_url - точно так же, как и в первом файле.

Вывод

Так как _databags и nodes были сгенерированы chef-ом автоматически, я не стал их добавлять в репозиторий, думая, что в следующий раз они заново сгенерируются. Так и оказалось, просто были созданны новые ресурсы. В принципе нет никакой причины не добавлять _databags и nodes в репозиторий, тем более, что такие конфигурации не храняться в публичных репозиториях.

comments powered by Disqus



По годам

2019 (8)
2018 (12)
2017 (2)