Ansible: Добавить опцию 'update' в ansible-galaxy

Спасибо, ансибот :)

: +1:

Кроме того, я думаю, было бы неплохо, если бы установка ansbile-galaxy не загружала zip-файл до того, как обнаружила, что папка уже существует.

Если вы добавляете роль в список зависимостей, вы можете обновить -i (игнорировать ошибки), но все роли будут загружены.

Звучит хорошо, но я думаю, что для обновления также потребуется дополнительная версия. У меня есть инструменты, которые создают приложение для рельсов вместе с книгой / инвентарем для игр.

Я хотел бы, чтобы в конечном итоге он обновлял роли автоматически, но я бы не хотел всегда переходить к последней версии. Если я перейду к последней версии, я буду вынужден обновлять свой инструмент всякий раз, когда я выпускаю новую роль или кто-то выпускает критическое изменение роли, которую они выпускают.

@nickjj, почему бы не использовать
вам нужно будет пометить репо вашей роли.

- src: git+ssh://git<strong i="8">@host</strong>:port/repo/myrole.git
  version: v1.0.0-1  # git tag that you want to download
  name: myrole
  scm: git

$ ansible-galaxy install -r requirements.yml

для обновления вам может потребоваться создать сценарий для удаления ролей, поскольку мне не удалось выполнить принудительную установку с использованием файла требований.

#!/bin/bash
# update-roles.sh
grep 'name:' requirements.yml | awk -F: '{print $2}' | xargs -I {} ansible-galaxy remove {}
ansible-galaxy install -r requirements.yml

Я полностью поддерживаю этот запрос функции, даже без управления версиями на первых порах.

Обновление было бы очень полезно. При использовании роли со многими зависимостями все они должны быть вручную установлены на install --force .

+1

: +1:

@nickjj - Я обновил исходный запрос, добавив примечание о необязательном указании [version] после имени роли.

: +1:

+1

+1

@geerlingguy Звучит хорошо.

: +1:
Было бы здорово.

Я использую install --force, но он систематически удаляет мой каталог vars, даже если он не входит в роль galax.
Было бы неплохо, если бы мы могли оставить в пути файл, не являющийся галактикой (очистка только файла роли галактики)

+1

Бывает ли, я нашел способ сделать что-то очень близкое
Я устанавливаю свои доступные роли в свой каталог ролей.

Затем я создаю роль, которая зависит от этой, куда я помещаю свой файл vars.
В моем сборнике пьес я использую только ту роль, которая зависит от ансибл-галактики.

чтобы быть более конкретным, скажем, у меня есть роль галактики 'bob / galaxy-mysql'
Мой файл requirements.yml выглядел бы так:

- src: bob/galaxy-mysql
  version: v1.0.0
  name: myrole
  path: ./roles

Потом бегу:

$ ansible-galaxy install -r requirements.yml

Затем я создаю в ./roles/mysql роль, которая зависит от моей локальной роли в галактике.

роли / mysql / meta / main.yml:

---
dependencies:
  - { role: bob.galaxy-mysql, sudo: yes}

и в ролях / mysql / vars / main.yml:

---
bob_mysql_var: "MySpecificValue"

Затем в моей книге я никогда не использую напрямую bob.galaxy-mysql, но мою роль mysql

Надеюсь, это поможет тебе

+1

+1

Это очень нужно.

: +1:

Было бы здорово, если бы он работал Композитором.
Мы изменили файл requirements.yml и установили / обновили все роли без использования --force или --ignore-errors

: +1:

: +1:

+1

: +1:

+1

: +1:

+1
но IMO еще важнее исправить https://github.com/ansible/ansible/issues/11266

+1

: +1:

+1

+1 Я вижу одну проблему: должна ли ansible-galaxy обнаруживать какие-либо изменения, сделанные вручную в роли, или нет.

+1

: +1: +1

: +1: +1

: +1: +2 .. это плюс за каждый год, когда этот запрос открыт :)

Я знаю, это страшно, но это работает

<?php
$items=[];
exec('ansible-galaxy list', $items);

foreach ($items as $package) {
  preg_match("/^- (.*?),/", $package, $found);
  $package = $found[1];
  system("ansible-galaxy remove $package");
  system("ansible-galaxy install $package");
}

+1

+1 как это еще не реализовано?

+1

+1

Пожалуйста, прекратите добавлять бесполезные сообщения +1 и уведомлять всех. Вместо этого используйте функцию «реакции» GitHub.
@Wtower @skornehl @gniltaws

Я не думаю, что кто-то верит, что кто-то обращает внимание на «большие пальцы», отсюда +1.

Это необходимая особенность. Впоследствии должна быть возможность включить репозиторий .git.

Проблема, с которой я сталкиваюсь, связана с _Я не могу обновить роль_, мне приходится тратить время на сортировку того, что было обновлено мной, и что было обновлено в репо, которое, как я предполагал, было той же версии, что и то, что я загрузил из ansible-galaxy. Это может вызвать у меня двойные коммиты, и, как правило, мне будет намного сложнее отправлять запросы на откат.

В дальнейшем _Я НЕ буду использовать ansible-galaxy во время разработки моей книги_ , а вместо этого сам клонирую репозитории, чтобы смягчить эту проблему.

Мы заботимся о @xenithorb. Трудно сказать, что здесь происходит, потому что там много плюсов и обсуждение дополнительных идей, которые не были частью PR в течение длительного периода времени. Неясно, знают ли многие из группы +1 о некоторых функциях, которые были доступны в галактике в течение некоторого времени. У меня такое чувство, что многие - нет. Если да, то еще более непонятно, что предлагается. (Вот почему я склоняюсь к тому, чтобы этот поток был закрыт не для завершения разговора, а для его сброса и фокусировки.)

Я не уверен, почему основная команда разработчиков не предприняла действий или не прокомментировала первоначальный PR на раннем этапе. Я могу немного порассуждать, но на самом деле не знаю.

Как упоминает --force . Возможно, это не самая четкая маркировка желаемой функции, но она выйдет, получит последнюю версию и заменит все, что у вас есть локально. Обозначение этой опции командной строки «обновление» так же неясно, поскольку галактика поддерживается git / github и нет никаких контрактов или требований к выпускам версий. Инструмент не может действительно гарантировать, что вы получите обновление в том виде, в котором он был разработан. (Совершается ли фиксация 01d4e до или после ef40ae? Мы не знаем.) Также --force можно использовать для понижения статуса роли. Отчасти поэтому я был бы против подкоманды «upgrade».

Что касается использования вашей собственной пропатченной / разветвленной версии роли @geerlingguy - используйте requirements.yml как было предложено steenzout 18 месяцев назад здесь: https://github.com/ansible/ansible/issues/6466 #issuecomment -65454871. Со спецификацией, которую вы можете иметь в файле ролей, вы можете перейти непосредственно к репозиторию git, а не через общедоступное репо галактики. (Вот как корпоративные клиенты, разрабатывающие частные роли для своих внутренних систем, используют Galaxy сегодня.)

На самом деле, если вы работаете с несколькими ролями, в любом случае неплохо иметь файл requirements.yml . Рекомендуется привязать версию, которую вы используете, чтобы указать конкретный тег или выполнить фиксацию, чтобы избежать неожиданного выдергивания коврика из-под вас. (Я несколько раз усвоил это на собственном горьком опыте - использовал роль из Galaxy, автор решил провести большой рефакторинг, нарушает обратную совместимость и ломает мой производственный код.)

Я ленив и ненавижу многократно набирать длинные строки командной строки со всеми спецификациями версии / источника и т. Д. Роли. Поэтому я помещаю его в этот файл ролей и использую переключатель -r . Бонус - то, какие роли и версии, которые я использую в своем проекте, можно отслеживать в системе управления версиями моего проекта.

Файл ролей больше соответствует духу Ansible (я определяю состояние, в котором я хочу, чтобы мои роли из внешнего источника находились, и galaxy получает это таким образом, даже если это ничего не означает изменения), чем ручное управление ролями, которое предлагает PR.

Надеюсь, это поможет.

См. Также: https://github.com/ansible/galaxy-issues/issues/168

В настоящее время одна проблема заключается в том, что Galaxy не может видеть «версии» ролей, используя что-то вроде semver - я думаю, что интерфейс командной строки Galaxy взаимодействует только с version как с идеей хэша / тега / ветки git (в отличие от таких менеджеров пакетов, как Composer, NPM, pip и т. Д., Которые имеют идею «2.5.1 выше, чем 2.5.0».

Кроме того, я искренне +1 комментарий @tima выше; Несколько месяцев назад я переключился на явное определение версий ролей в файле requirements.yml для виртуальной машины Drupal, и все стало НАСТОЛЬКО более стабильным / поддерживаемым, даже с причудами обновления галактики.

Кроме того, на следующей неделе я сделаю презентацию о лучших практиках / советах, которые я почерпнул за последние несколько лет, на AnsibleFest SF, так что, если вы там, приходите ко мне! Думаю, вскоре после этого Ansible опубликует слайды (а может, и видео?). Одна из основных тем - использование ролей в проектах через форки, частные репозитории, requirements.yml и т. Д.

Спасибо за советы! Я буду следить за видео вашего выступления, так как, к сожалению, я не буду участвовать в конференции. Обязательно взгляну на requirements.xml и переключусь.

В настоящее время одна проблема заключается в том, что Galaxy не видит «версии» ролей ...

Верно. Вот что я имел в виду, когда сказал ...

нет контракта или требований к выпускам версий. Инструмент не может действительно гарантировать, что вы получите обновление в том виде, в котором он был разработан.

Весь бэкэнд Galaxy нужно будет переписать (то есть нужно будет заменить git), чтобы заставить много политик, рабочего процесса и накладных расходов, которые есть в системе управления пакетами. (Кстати, Galaxy не является менеджером пакетов.)

Я считаю, что являюсь ведущим вашего трека

Если Ansible (RedHat) не начнет тратить деньги на управление тщательно подобранным набором сценариев, сообщество обречено иметь дело с галактическим беспорядком. Теперь Galaxy - не что иное, как кухонный гарнитур ролей, которые разделяют люди с добрыми намерениями. Нельзя сказать, что раковина хорошо пахнет, когда овощи внутри свежие, но вскоре они начинают гнить, и никто не вынимает вещи из этой раковины.

Тем не менее, никто не должен ожидать, что ему придется поддерживать анзибл-роли только потому, что он в какой-то момент разделял их. Вот почему проекты с открытым исходным кодом, выполняемые одним человеком, в большинстве случаев терпят неудачу, поскольку у них есть единственная точка отказа, которая рано или поздно сработает.

Единственный способ снова сделать Ansible великим! ;) заключается в том, чтобы гарантировать, что роль будет поддерживаться, но будет существовать сообщество опытных пользователей ansible (пользователи, которые имеют больший опыт работы с ansible, чем средний пользователь).

@ssbarnea - Пока мы немного Собор и Базар , хотя, похоже, вы не можете любезно относиться к базарной стороне вещей :)

Открытый исходный код - это беспорядок, независимо от того, есть ли у вас один или тысяча разработчиков, стоящих за конкретным проектом, но собранные наборы ролей или проприетарное / официальное / централизованное поддерживаемое программное обеспечение (сродни примерам в ядре Ansible) поставляются со своим собственным набором тоже ... в большинстве сообществ OSS между этими двумя идеями идет постоянная борьба.

Я, например, поддерживаю около 100 различных небольших проектов OSS (некоторые из них имеют более 500 звезд на GitHub), и я приветствую PR, хотя из-за упомянутого вами SPOF я также призываю людей _ настоятельно_ к форкнуть и повторно использовать. Я горжусь тем фактом, что многие из моих самых популярных проектов имеют почти столько же вилок, сколько звезд, то есть люди модифицируют их в точном соответствии со своими потребностями. Это открытый исходный код в действии!

Стиль Bazaar, поддерживаемый Galaxy, не идеален, но это означает, что есть роль для всего, что находится под солнцем, и, как правило, нескольких разных. Теперь поиск лучшего - это еще одна тема, и ее также следует изучить вне этой проблемы. Несомненно, есть возможности для улучшения пользовательского интерфейса и интерфейса командной строки Galaxy.

Хотя я согласен с вами (и я также пытаюсь сопротивляться тому, чтобы испачкать эту ошибку, но не могу) - я думаю, что RH, просто в хорошем деловом смысле и в качестве демонстрации профессионализма, должен кому-то заплатить ... ну, в основном поддерживать ваши роли. (Поскольку у вас это в основном хорошо загнано в угол). Если вы не платите буквально вам, у них должен быть сотрудник RH, поддерживающий их как работу с полной или частичной занятостью. По сути, должен существовать хорошо поддерживаемый набор сценариев для 100 лучших проектов с открытым исходным кодом.

Я так чувствую, потому что начать работу с анзиблем сложно (настоящий вид анзибля, а не одноразовые специальные команды и простые плейбуки, которые они преподают в документации), и первое впечатление имеет значение.

Итак, когда я беру на себя широко известную и явно популярную роль, чтобы установить инструмент, который, как я полагаю, достаточно популярен, чтобы привлечь внимание, которого он заслуживает - и он не работает с первого раза, - я сомневаюсь, действительно ли я » m даже использую правильный инструмент для правильной работы, или делаю ли я это из собственных соображений, потому что мне нравится безагентный подход и отсутствие рубина. Это действительно так просто. Я думаю, что хорошие рабочие и доступные роли взлетят вверх по проекту и сделают его более ценным. Это пиар-ход, по крайней мере, имеющий бизнес-смысл.

Изменить: также, поскольку я все равно говорю здесь, и я не знаю, где еще это поставить: @geerlingguy, не

: +1:

https://github.com/ansible/proposals/issues/23

Я голосую.

Поскольку это было перенесено в предложение, мы продолжим и закроем этот вопрос сейчас.

Спасибо!