AK
Простой пример: создать пользователя со случайным именем и ид чтоб избежать коллизий - как такую задачу в ансибле решать? Надо куда то сохранять имя.
Size: a a a
2019 December 10
AK
В неслучайное место.
AK
надеюсь, объяснил
k
@kvaps state полезен, когда:
* У тебя есть ресурсы, которыми ты не управляешь. Тогда ты можешь отличить "твой" ec2 от тех, которые трогать не надо. В случае ансибла тебе придётся городить искусственный "state" в виде меток, или запоминать id куда-нибудь. При этом код, который об этом заботится не несёт смысловой нагрузки, он описывает не желаемый результат, а как его отличить.
* есть сторонний проект, который зависит от результата. Стейт позволяет взять выхлоп твоего проекта и использовать его. Например, один стек у тебя разворачивает базу, а второй приложение,и второй стек может взять случайно сгенерированный пароль базы из стейта первого. В ансибле тебе для этого опять же придётся стейт эмулировать
* У тебя есть ресурсы, которыми ты не управляешь. Тогда ты можешь отличить "твой" ec2 от тех, которые трогать не надо. В случае ансибла тебе придётся городить искусственный "state" в виде меток, или запоминать id куда-нибудь. При этом код, который об этом заботится не несёт смысловой нагрузки, он описывает не желаемый результат, а как его отличить.
* есть сторонний проект, который зависит от результата. Стейт позволяет взять выхлоп твоего проекта и использовать его. Например, один стек у тебя разворачивает базу, а второй приложение,и второй стек может взять случайно сгенерированный пароль базы из стейта первого. В ансибле тебе для этого опять же придётся стейт эмулировать
> ты можешь отличить "твой" ec2 от тех, которые трогать не надо. В случае ансибла тебе придётся городить искусственный "state" в виде меток, или запоминать id куда-нибудь.
Эта задача легко решается добавлением уникального префикса к имени каждого ресурса, префикс можно сделать настраиваемым глобально на весь деплой и хранить в vars прямо в репозитории.
> есть сторонний проект, который зависит от результата. Стейт позволяет взять выхлоп твоего проекта и использовать его. Например, один стек у тебя разворачивает базу, а второй приложение, и второй стек может взять случайно сгенерированный пароль базы из стейта первого. В ансибле тебе для этого опять же придётся стейт эмулировать
Предпочитаю пароли генерировать заранее и хранить в зашифрованном виде в git, как часть задеплоенной инфраструктуры.
Для всего остального стейт можно собрать на лету непосредственно перед запуском нужного модуля.
В целом соглашусь, юзкейс сохранения стейта мне понятен.
Ансибл и терраформ используют два разных подхода, у каждого из них есть свои плюсы и минусы.
К тераформу у меня только одна претензия, в том что если стейт-файл является такой-же критической частью для задеплоенной инфраструктуры как и код который её генерит, то на мой взгляд было бы логично хранить его там же в vcs, просто для того чтобы в один прекрасный момент не просрать все айдишники.
Эта задача легко решается добавлением уникального префикса к имени каждого ресурса, префикс можно сделать настраиваемым глобально на весь деплой и хранить в vars прямо в репозитории.
> есть сторонний проект, который зависит от результата. Стейт позволяет взять выхлоп твоего проекта и использовать его. Например, один стек у тебя разворачивает базу, а второй приложение, и второй стек может взять случайно сгенерированный пароль базы из стейта первого. В ансибле тебе для этого опять же придётся стейт эмулировать
Предпочитаю пароли генерировать заранее и хранить в зашифрованном виде в git, как часть задеплоенной инфраструктуры.
Для всего остального стейт можно собрать на лету непосредственно перед запуском нужного модуля.
В целом соглашусь, юзкейс сохранения стейта мне понятен.
Ансибл и терраформ используют два разных подхода, у каждого из них есть свои плюсы и минусы.
К тераформу у меня только одна претензия, в том что если стейт-файл является такой-же критической частью для задеплоенной инфраструктуры как и код который её генерит, то на мой взгляд было бы логично хранить его там же в vcs, просто для того чтобы в один прекрасный момент не просрать все айдишники.
IM
> ты можешь отличить "твой" ec2 от тех, которые трогать не надо. В случае ансибла тебе придётся городить искусственный "state" в виде меток, или запоминать id куда-нибудь.
Эта задача легко решается добавлением уникального префикса к имени каждого ресурса, префикс можно сделать настраиваемым глобально на весь деплой и хранить в vars прямо в репозитории.
> есть сторонний проект, который зависит от результата. Стейт позволяет взять выхлоп твоего проекта и использовать его. Например, один стек у тебя разворачивает базу, а второй приложение, и второй стек может взять случайно сгенерированный пароль базы из стейта первого. В ансибле тебе для этого опять же придётся стейт эмулировать
Предпочитаю пароли генерировать заранее и хранить в зашифрованном виде в git, как часть задеплоенной инфраструктуры.
Для всего остального стейт можно собрать на лету непосредственно перед запуском нужного модуля.
В целом соглашусь, юзкейс сохранения стейта мне понятен.
Ансибл и терраформ используют два разных подхода, у каждого из них есть свои плюсы и минусы.
К тераформу у меня только одна претензия, в том что если стейт-файл является такой-же критической частью для задеплоенной инфраструктуры как и код который её генерит, то на мой взгляд было бы логично хранить его там же в vcs, просто для того чтобы в один прекрасный момент не просрать все айдишники.
Эта задача легко решается добавлением уникального префикса к имени каждого ресурса, префикс можно сделать настраиваемым глобально на весь деплой и хранить в vars прямо в репозитории.
> есть сторонний проект, который зависит от результата. Стейт позволяет взять выхлоп твоего проекта и использовать его. Например, один стек у тебя разворачивает базу, а второй приложение, и второй стек может взять случайно сгенерированный пароль базы из стейта первого. В ансибле тебе для этого опять же придётся стейт эмулировать
Предпочитаю пароли генерировать заранее и хранить в зашифрованном виде в git, как часть задеплоенной инфраструктуры.
Для всего остального стейт можно собрать на лету непосредственно перед запуском нужного модуля.
В целом соглашусь, юзкейс сохранения стейта мне понятен.
Ансибл и терраформ используют два разных подхода, у каждого из них есть свои плюсы и минусы.
К тераформу у меня только одна претензия, в том что если стейт-файл является такой-же критической частью для задеплоенной инфраструктуры как и код который её генерит, то на мой взгляд было бы логично хранить его там же в vcs, просто для того чтобы в один прекрасный момент не просрать все айдишники.
А для чего придумали по вашему ремоут стейт? Чтобы не потерять инфраструктуру и сравнивать стейтфул со стейтлес то такое и стейтлес заведомо проиграет
A
> ты можешь отличить "твой" ec2 от тех, которые трогать не надо. В случае ансибла тебе придётся городить искусственный "state" в виде меток, или запоминать id куда-нибудь.
Эта задача легко решается добавлением уникального префикса к имени каждого ресурса, префикс можно сделать настраиваемым глобально на весь деплой и хранить в vars прямо в репозитории.
> есть сторонний проект, который зависит от результата. Стейт позволяет взять выхлоп твоего проекта и использовать его. Например, один стек у тебя разворачивает базу, а второй приложение, и второй стек может взять случайно сгенерированный пароль базы из стейта первого. В ансибле тебе для этого опять же придётся стейт эмулировать
Предпочитаю пароли генерировать заранее и хранить в зашифрованном виде в git, как часть задеплоенной инфраструктуры.
Для всего остального стейт можно собрать на лету непосредственно перед запуском нужного модуля.
В целом соглашусь, юзкейс сохранения стейта мне понятен.
Ансибл и терраформ используют два разных подхода, у каждого из них есть свои плюсы и минусы.
К тераформу у меня только одна претензия, в том что если стейт-файл является такой-же критической частью для задеплоенной инфраструктуры как и код который её генерит, то на мой взгляд было бы логично хранить его там же в vcs, просто для того чтобы в один прекрасный момент не просрать все айдишники.
Эта задача легко решается добавлением уникального префикса к имени каждого ресурса, префикс можно сделать настраиваемым глобально на весь деплой и хранить в vars прямо в репозитории.
> есть сторонний проект, который зависит от результата. Стейт позволяет взять выхлоп твоего проекта и использовать его. Например, один стек у тебя разворачивает базу, а второй приложение, и второй стек может взять случайно сгенерированный пароль базы из стейта первого. В ансибле тебе для этого опять же придётся стейт эмулировать
Предпочитаю пароли генерировать заранее и хранить в зашифрованном виде в git, как часть задеплоенной инфраструктуры.
Для всего остального стейт можно собрать на лету непосредственно перед запуском нужного модуля.
В целом соглашусь, юзкейс сохранения стейта мне понятен.
Ансибл и терраформ используют два разных подхода, у каждого из них есть свои плюсы и минусы.
К тераформу у меня только одна претензия, в том что если стейт-файл является такой-же критической частью для задеплоенной инфраструктуры как и код который её генерит, то на мой взгляд было бы логично хранить его там же в vcs, просто для того чтобы в один прекрасный момент не просрать все айдишники.
Стейт-файл важен, поэтому лучше его хранить в удалённом и надёжном месте
Например, в облачном блоб-сторейдже, который в среднем надёжнее и долговечнее, чем твой гит ;)
Например, в облачном блоб-сторейдже, который в среднем надёжнее и долговечнее, чем твой гит ;)
AK
> ты можешь отличить "твой" ec2 от тех, которые трогать не надо. В случае ансибла тебе придётся городить искусственный "state" в виде меток, или запоминать id куда-нибудь.
Эта задача легко решается добавлением уникального префикса к имени каждого ресурса, префикс можно сделать настраиваемым глобально на весь деплой и хранить в vars прямо в репозитории.
> есть сторонний проект, который зависит от результата. Стейт позволяет взять выхлоп твоего проекта и использовать его. Например, один стек у тебя разворачивает базу, а второй приложение, и второй стек может взять случайно сгенерированный пароль базы из стейта первого. В ансибле тебе для этого опять же придётся стейт эмулировать
Предпочитаю пароли генерировать заранее и хранить в зашифрованном виде в git, как часть задеплоенной инфраструктуры.
Для всего остального стейт можно собрать на лету непосредственно перед запуском нужного модуля.
В целом соглашусь, юзкейс сохранения стейта мне понятен.
Ансибл и терраформ используют два разных подхода, у каждого из них есть свои плюсы и минусы.
К тераформу у меня только одна претензия, в том что если стейт-файл является такой-же критической частью для задеплоенной инфраструктуры как и код который её генерит, то на мой взгляд было бы логично хранить его там же в vcs, просто для того чтобы в один прекрасный момент не просрать все айдишники.
Эта задача легко решается добавлением уникального префикса к имени каждого ресурса, префикс можно сделать настраиваемым глобально на весь деплой и хранить в vars прямо в репозитории.
> есть сторонний проект, который зависит от результата. Стейт позволяет взять выхлоп твоего проекта и использовать его. Например, один стек у тебя разворачивает базу, а второй приложение, и второй стек может взять случайно сгенерированный пароль базы из стейта первого. В ансибле тебе для этого опять же придётся стейт эмулировать
Предпочитаю пароли генерировать заранее и хранить в зашифрованном виде в git, как часть задеплоенной инфраструктуры.
Для всего остального стейт можно собрать на лету непосредственно перед запуском нужного модуля.
В целом соглашусь, юзкейс сохранения стейта мне понятен.
Ансибл и терраформ используют два разных подхода, у каждого из них есть свои плюсы и минусы.
К тераформу у меня только одна претензия, в том что если стейт-файл является такой-же критической частью для задеплоенной инфраструктуры как и код который её генерит, то на мой взгляд было бы логично хранить его там же в vcs, просто для того чтобы в один прекрасный момент не просрать все айдишники.
"эта задача легко решается" - а ты посмотри мои замечания в этом же тексте. Ты начинаешь решать задачу сохранения состояния, то есть делаешь работу, которую инструмент мог бы сделать за тебя. Далее, по поводу хранения стейта в гит: никто не мешает хранить его там. Просто стейт и iac - это разные вещи, код всегда один, а результат вычислений может быть разный. Задеплоил в другой аккаунт,в другой домен, в другой момент времени, стг или прод, и тд
AK
Ну и про то, что стейт является критической частью - чудес не бывает, в ансибле искусственный стейт в виде сохранённых ид и паролей - такая же критическая часть. Нужно понимать что и тф и ансибл это просто инструменты с разной имплементацией и подходом, но законы природы они не меняют. Вы можете в коде постоянно вычислять число пи, а можете его запомнить - либо тратьте циклы цпу либо место на диске
AD
Ансибл в другом чатике. Там вам Тимур расскажет, зачем он нужен. Тут про Тераформ.
Имхо ансибл для другого. В проде (да и вообще) им менеджить инфру может только большой смельчак работающий в маленькой команде на маленьком проекте.
Имхо ансибл для другого. В проде (да и вообще) им менеджить инфру может только большой смельчак работающий в маленькой команде на маленьком проекте.
VT
Ансибл в другом чатике. Там вам Тимур расскажет, зачем он нужен. Тут про Тераформ.
Имхо ансибл для другого. В проде (да и вообще) им менеджить инфру может только большой смельчак работающий в маленькой команде на маленьком проекте.
Имхо ансибл для другого. В проде (да и вообще) им менеджить инфру может только большой смельчак работающий в маленькой команде на маленьком проекте.
👍
GK
коллеги приветствую, кто подскажет пример как в селектел создать сервер указав фиксированный IP
GK
речь о локальной сети .
AU
коллеги приветствую, кто подскажет пример как в селектел создать сервер указав фиксированный IP
#Добавляем приватную сеть
resource "openstack_networking_network_v2" "private" {
name = "${var.network_name_private}"
}
resource "openstack_networking_subnet_v2" "subnet-private" {
network_id = "${openstack_networking_network_v2.private.id}"
name = "${var.subnet_cidr_private}"
cidr = "${var.subnet_cidr_private}"
}
#Создаем порт приватной сети
resource "openstack_networking_port_v2" "port_2" {
name = "${var.server_name}-eth0"
network_id = "${openstack_networking_network_v2.private.id}"
#Указываем очередность выполнения, зависимость от результатов модуля по созданию сети
depends_on = ["openstack_networking_subnet_v2.subnet-private"]
#Назначем ip из dhcp диапазона
fixed_ip {
subnet_id = "${openstack_networking_subnet_v2.subnet-private.id}"
ip_address = "${var.fixed_ip_v4}"
}
}
A
кажется вопрос был про селектел, а ответили про опенстек
AU
кажется вопрос был про селектел, а ответили про опенстек
а у них openstack )
A
даже апи тот же, что ли?
GK
#Добавляем приватную сеть
resource "openstack_networking_network_v2" "private" {
name = "${var.network_name_private}"
}
resource "openstack_networking_subnet_v2" "subnet-private" {
network_id = "${openstack_networking_network_v2.private.id}"
name = "${var.subnet_cidr_private}"
cidr = "${var.subnet_cidr_private}"
}
#Создаем порт приватной сети
resource "openstack_networking_port_v2" "port_2" {
name = "${var.server_name}-eth0"
network_id = "${openstack_networking_network_v2.private.id}"
#Указываем очередность выполнения, зависимость от результатов модуля по созданию сети
depends_on = ["openstack_networking_subnet_v2.subnet-private"]
#Назначем ip из dhcp диапазона
fixed_ip {
subnet_id = "${openstack_networking_subnet_v2.subnet-private.id}"
ip_address = "${var.fixed_ip_v4}"
}
}
дай вам бог здоровица =)
AU
даже апи тот же, что ли?
да, но не все ресурсы есть. а их провайдер они чот не хотят обновлять. цитирую
Благодарим за длительное ожидание.
К сожалению, в ближайшее время обновления не ожидается.
Конечно, нами в будущем планируется обновление этой части, однако назвать точные сроки на данный момент не представляется возможным.
A
прикольно
GK
#Добавляем приватную сеть
resource "openstack_networking_network_v2" "private" {
name = "${var.network_name_private}"
}
resource "openstack_networking_subnet_v2" "subnet-private" {
network_id = "${openstack_networking_network_v2.private.id}"
name = "${var.subnet_cidr_private}"
cidr = "${var.subnet_cidr_private}"
}
#Создаем порт приватной сети
resource "openstack_networking_port_v2" "port_2" {
name = "${var.server_name}-eth0"
network_id = "${openstack_networking_network_v2.private.id}"
#Указываем очередность выполнения, зависимость от результатов модуля по созданию сети
depends_on = ["openstack_networking_subnet_v2.subnet-private"]
#Назначем ip из dhcp диапазона
fixed_ip {
subnet_id = "${openstack_networking_subnet_v2.subnet-private.id}"
ip_address = "${var.fixed_ip_v4}"
}
}
а не сочтите за наглость но может это часть какой то статейки полезной ? уж больно коментарии подробны ) не поделитесь ссылкой на полный пример ?