У нас нет товера, но пулл работает с гитом нормально, ЧЯДНТ? Я даже больше скажу, вообще не понимаю нахрена он нужен для ansible-pull, товер же не выступает репозиторием для ансибла никак.
Если я верно вас понял то вы имеете в виду pull из git с последующим локальным запуском плейбука, в нашей задаче мы не могли использовать этот подход, а сам ansible не имеет возможности стянуть все необходимое как это делают те же Chef-Client или Salt-Minion с соотвественно Chef-Server'a и Salt-Master'a
Какой к нему фреймворк лепить то?
Задача была не к нему фреймворк сделать, а на его основе сделать свой для простого и удобного написания CLI интерфейса который смогут использовать как продуктовые команды(те кто делают непосредственно само ПО которое мы разворачиваем) так и инженеры в поле(те кто этот продукт соотвественно настраивает в датацентре заказчика)
Когда я говорил про перформанс то имел ввиду накладные расходы на само «содержание» контейнера, а не то что в Docker'е приложение будет работать медленнее, видимо не сумел правильно передать свою мысль.
Docker — он, на самом деле, не про контейнеры. Он про tooling. Т.е. они не придумали особо ничего нового в мире контейнеризации, они написали отличный tooling вокруг неё — и стрельнуло.
Совершенно согласен: Docker это больше про инструменты вокруг него и именно по этому когда я говорил что Docker'у как тогда когда на него переходили мы так и сейчас нет особых альтернатив.
Это сами придумали, или проводили замеры? Потому что это откровенный Bullshit.
Мы упирались на мастере в производительность и на железной машине, да, нам приходилось несколько раз добавлять в нее памяти и вы хотите сказать что с Decker'ом у нас бы этого не произошло?
Я конечно понимаю, что модно писать «Супир Сервис Лтд»
Тут полностью согласен имелась в виду именно Docker-Machine
А вы не думайте, а проверяйте.
Я верно понимаю что вы бы Docker использовали даже на рендер-фермах и вычеслителях-геномов, а я думал это я лютый фанат Docker
Дополнительные рецепты также могут быть включены, но тогда это правильнее называть application cookbook (прим. переводчика).
С моей точки зрения wrapper-cookbook не перестает быть wrapper'ом при расширении, например Jetty-cookbook не умеет ставить Jetty9 если мы в своей обертке добавим эту возможность, разве он станет при таком подходе App-cookbook'ом?
Если я верно вас понял то вы имеете в виду pull из git с последующим локальным запуском плейбука, в нашей задаче мы не могли использовать этот подход, а сам ansible не имеет возможности стянуть все необходимое как это делают те же Chef-Client или Salt-Minion с соотвественно Chef-Server'a и Salt-Master'a
Задача была не к нему фреймворк сделать, а на его основе сделать свой для простого и удобного написания CLI интерфейса который смогут использовать как продуктовые команды(те кто делают непосредственно само ПО которое мы разворачиваем) так и инженеры в поле(те кто этот продукт соотвественно настраивает в датацентре заказчика)
Такой комментарии был и в зале во время доклада, я же хотел показать пример именно с `delegate`
Да, но к сожалению для el6(Centos/RHEL) он всё ещё актуален
Очень даже пригоден, ведь уже очень много всего написано готового и шанс найти что-то подходящее достаточно велик. Особенно в сравнении с SaltStack.
Они оба(Puppet и Chef) «выросли» из CFEngine и очень на него похожи.
Когда я говорил про перформанс то имел ввиду накладные расходы на само «содержание» контейнера, а не то что в Docker'е приложение будет работать медленнее, видимо не сумел правильно передать свою мысль.
Этого не имелось в виду, от слова совсем, но как мне кажется в всегда нужно выбирать инструмент под задачу а не наоборот.
Совершенно согласен: Docker это больше про инструменты вокруг него и именно по этому когда я говорил что Docker'у как тогда когда на него переходили мы так и сейчас нет особых альтернатив.
Мы упирались на мастере в производительность и на железной машине, да, нам приходилось несколько раз добавлять в нее памяти и вы хотите сказать что с Decker'ом у нас бы этого не произошло?
Тут полностью согласен имелась в виду именно Docker-Machine
Я верно понимаю что вы бы Docker использовали даже на рендер-фермах и вычеслителях-геномов, а я думал это я лютый фанат Docker
С моей точки зрения wrapper-cookbook не перестает быть wrapper'ом при расширении, например Jetty-cookbook не умеет ставить Jetty9 если мы в своей обертке добавим эту возможность, разве он станет при таком подходе App-cookbook'ом?