ЕС
понял спасибо
Size: a a a
2019 October 08
TG
Если таски сильно совпадают, а отличия лишь в паре отдельных тасков, то можно использовать delegate_to для выполнения на конкретном сервере
J
Доброго дня! подскажите пжлста чем отличаеться latest и present в yum модуле. смотрю вот в ансибл.доокс но вижу фигу ) - name: install the latest version of Apache from the testing repo
yum:
name: httpd
enablerepo: testing
state: present или - name: install the latest version of Apache
yum:
name: httpd
state: latest
yum:
name: httpd
enablerepo: testing
state: present или - name: install the latest version of Apache
yum:
name: httpd
state: latest
ЕС
Доброго дня! подскажите пжлста чем отличаеться latest и present в yum модуле. смотрю вот в ансибл.доокс но вижу фигу ) - name: install the latest version of Apache from the testing repo
yum:
name: httpd
enablerepo: testing
state: present или - name: install the latest version of Apache
yum:
name: httpd
state: latest
yum:
name: httpd
enablerepo: testing
state: present или - name: install the latest version of Apache
yum:
name: httpd
state: latest
я так понимаю что если latest то пакет будет обновлен если есть обновления. а present проверяет только наличие пакета и все...
BS
Доброго дня! подскажите пжлста чем отличаеться latest и present в yum модуле. смотрю вот в ансибл.доокс но вижу фигу ) - name: install the latest version of Apache from the testing repo
yum:
name: httpd
enablerepo: testing
state: present или - name: install the latest version of Apache
yum:
name: httpd
state: latest
yum:
name: httpd
enablerepo: testing
state: present или - name: install the latest version of Apache
yum:
name: httpd
state: latest
present - тру если пакет установлег
latest- тру если установлен пакет последней версии из репозитория
latest- тру если установлен пакет последней версии из репозитория
ЕС
я размышлял по поводу задачи заменить активный сервер на другой. по сути это два разных состояния инфраструктуры и не корректно создавать общую роль для описания этих двух состояний. лучше сделать две разные роли "server1_active" и "server2_active" и по необходимости запускать нужную роль. (т.е. не нужно делать общую роль которая может переключать состояния с одного сервера на другой). Как Вы думаете?
BS
я размышлял по поводу задачи заменить активный сервер на другой. по сути это два разных состояния инфраструктуры и не корректно создавать общую роль для описания этих двух состояний. лучше сделать две разные роли "server1_active" и "server2_active" и по необходимости запускать нужную роль. (т.е. не нужно делать общую роль которая может переключать состояния с одного сервера на другой). Как Вы думаете?
сколько таких серверов? в чем заключается активность и пассивность серверов?
J
спасибо большое
ЕС
серверов пока два но скоро появиться еще одни. это сервера SIP телефонии. при этом логика переключения с одно сервера на другой разная.
ЕС
т.е. скажем логика перколючения с сервера 1 на сервер 2 отличается от логики переключения с сервера 2 на сервер 1
ЕС
можно конечно сделать одно общую роль. но она тогда получиться сложной. много будет условий
BS
серверов пока два но скоро появиться еще одни. это сервера SIP телефонии. при этом логика переключения с одно сервера на другой разная.
ну в таком случае, 1) пишешь плей на проверку состояния сервера 2) в зависимости от состояния условием when запускаешь нужный таск для активного,Ю или пассивного сервера
ЕС
тогда пользователь не сможет контролировать на какой сервер переключаться
ЕС
если он добавит еще один сервер
BS
тогда пользователь не сможет контролировать на какой сервер переключаться
так может пользователь и не должен знать ? для него должен быть некий фронт. который разруливает активные бэкэнды в виде твоих серверов ?
GK
а переключение активного и пасивного сервера разве не задача всяких keepalived ?
ЕС
а переключение активного и пасивного сервера разве не задача всяких keepalived ?
возможно
ЕС
суть такая что нужно поменять настройки на трех узлах. на старом сервере на новом сервере и на роутере.
GK
GK
концепция файловера тут раскрыта