Интересный комментарий очень практической направленности. Над веб-интерфейсом я, если честно, задумывался, но крайне ненадолго — нашёл, как включить autoindex, и на этом успокоился. Справедливости ради хочу заметить, что для полноценного решения веб-интерфейс действительно необходим.
Правильно ли я понял, что часть загружающая и часть обрабатывающая впрямую не взаимодействуют?
А никто и не обещал, собственно говоря. В начале статьи обозначена задача, ниже приведён вариант её решения. Кому этого достаточно — будут пользоваться, кому мало — не будут. На мой взгляд, важно, чтобы у людей просто был выбор — ставить и поддерживать что-то огромное типа Pulp, либо закупать платные решения (кстати, всё равно потом их кто-то будет ставить и поддерживать), либо вот такие простые штуки использовать. Тут каждый сам для себя должен решить, что ему важнее.
Да, есть такой продукт, но лично для меня существуют несколько важных моментов:
изучение этого продукта не входило в мои задачи;
мне требуется только три типа репозиториев из большого перечня возможностей продукта;
а с точки зрения изначально решаемой задачи лично я не вижу смысла покупать лицензию на Artifactory, чтобы получить результат, аналогичный результату «проекта выходного дня»
На мой вкус, сравнивать работающий концепт, сделанный за выходные, и коммерческий продукт как-то нелогично, не находите? Я никогда не видел, чтобы велосипеды и суперкары участвовали в одних и тех же гонках.
А по поводу поддержки — сервис работает в существующем виде порядка двух месяцев, и мне его даже перезапускать не пришлось ни разу. Единственный озадачивший меня эпизод — когда Jenkins из-за ошибки в скриптах удалил всё в /tmp.
Откровенно говоря, у меня для сборки пакетов тоже используется Jenkins, но мой опыт эксплуатации говорит о том, что делать из него «швейцарский нож» себе дороже. В моей ситуации работа Jenkins заканчивается на этапе отправки пакета на веб-сервер.
Насчёт подписи — да, подписи — это хорошо, но я не считаю для себя возможным обучать читателей правилам хорошего тона при сборке rpm-пакетов.
Кстати, чисто технически интересно, как в описанном вами варианте решён вопрос с гонками при одновременной заливке пакетов?
Вполне возможно, что этот концепт работоспособен, но эксплуатация этого варианта точно не для меня — слишком много движущихся частей, слишком легко чему-то пойти не так.
Прошу извинить, не смог понять из комментария, хотите ли вы уточнить детали или просто троллите — выражения лица не вижу, интонаций не слышу, смайлики отсутствуют.
Мой посыл так же лёгок в понимании и прост, как гвоздодёр из титанового сплава: хотите этот код развивать и поддерживать как Open Source Software — пожалуйста. Хотите зарабатывать на нём деньги — вам придётся делать это вместе со мной, только и всего.
В большом репозитории операция обновления метаданных занимает отнюдь не нулевое время, поэтому я изначально решил, что запускать обновление по событию «загрузка» — не вариант: элементарная ситуация «гонок», когда обновление после предыдущей загрузки ещё идёт, а уже в наличии следующая загрузка, напрочь ломает весь концепт.
Закладываться на то, что эта ситуация никогда не возникнет, я счёл бессмысленным — своими глазами видел, как при почти одновременных загрузках пакетов в один из коммерческих репозиториев (правда, в бесплатной версии) файл с метаданными просто обнуляется в размере. Подобная потеря данных может быть одним из признаков «гонок», то есть некорректной обработки многопоточного доступа. Отсюда и необходимость обработки подобной ситуации.
Я не берусь утверждать, что мой подход — единственно правильный, но факт использования очереди «под капотом» того же Pulp может быть косвенным подтверждением моей позиции.
Прочитал статью, удивился некоторой путанице. Я не беру на себя смелость решать, что именно должно использоваться вами, другое дело, что факты поданы, гхм, своеобразно. Вот по порядку:
Во-первых, меня смутило, что в описании «что и почему» в пользу Salt указаны фичи, имеющие прямые аналоги у Ansible.
Во-вторых, если уж говорить о коммерческих решениях, то утверждение про якобы несуществующего клиента для Ansible оказывается на поверку весьма слабым: клиент очень даже существует и называется Ansible Tower .
В-третьих, Ansible тоже написан на Python.
В-четвёртых, совсем не был упомянут Ansible Galaxy — открытый свободный репозиторий ролей для Ansible, где очень часто можно найти необходимую роль, и она будет работать «из коробки», либо с минимальной подгонкой под ваш конкретный проект.
Ну и в-пятых — документацию к Salt, по ощущениям, действительно писала парочка — Шляпник и Мартовский Заяц, так что она явно проигрывает официальной документации Ansible.
В статье OpenDKIM просят явно слушать сокет только в случае запуска в chroot. "… Если Postfix вы используете без chroot, то для настройки больше ничего не нужно делать..." А насчёт "кошерности" согласен, именно поэтому сам настроил через сокет.
Конечно, упоминание aptitude и тег "debian" прямо говорят, что инструкция для Debian-подобных ОС, но эта информация для обладателей CentOS 6: по дефолту OpenDKIM как раз слушает указанный порт, а не указанный в статье сокет.
Замечание совершенно верное, в конце действительно будет запятая. На момент написания статьи средства для избавления от этой запятой у меня не было, но и необходимости от неё избавляться — тоже: приложение на Java эту запятую благополучно игнорирует.
Однако беглый поиск подсказал, что достаточно заключить разделяющую запятую вот в такую конструкцию:
{% if not loop.last %}
,
{% endif %}
Применительно к строчке из статьи получим вот что:
zk.connect={% for host in groups['zk_nodes'] %}{{ hostvars[host]['ansible_eth0']['ipv4']['address'] }}:{{ zk_port }}{% if not loop.last %},{% endif %} {% endfor %}
Или можно использовать второй вариант, приведённый в комментариях на SO по ссылке выше, но лично я в Jinja2 пока не настолько силён, чтобы уверенно написать, как правильно две подстановочные переменные со статическим символом (",") сцепить в список через фильтр «join» :-)
Правильно ли я понял, что часть загружающая и часть обрабатывающая впрямую не взаимодействуют?
Из бесплатных решений — у Pulp есть что-то очень похожее на «content sources».
На мой вкус, сравнивать работающий концепт, сделанный за выходные, и коммерческий продукт как-то нелогично, не находите? Я никогда не видел, чтобы велосипеды и суперкары участвовали в одних и тех же гонках.
А по поводу поддержки — сервис работает в существующем виде порядка двух месяцев, и мне его даже перезапускать не пришлось ни разу. Единственный озадачивший меня эпизод — когда Jenkins из-за ошибки в скриптах удалил всё в /tmp.
Насчёт подписи — да, подписи — это хорошо, но я не считаю для себя возможным обучать читателей правилам хорошего тона при сборке rpm-пакетов.
Кстати, чисто технически интересно, как в описанном вами варианте решён вопрос с гонками при одновременной заливке пакетов?
Мой посыл так же лёгок в понимании и прост, как гвоздодёр из титанового сплава: хотите этот код развивать и поддерживать как Open Source Software — пожалуйста. Хотите зарабатывать на нём деньги — вам придётся делать это вместе со мной, только и всего.
Закладываться на то, что эта ситуация никогда не возникнет, я счёл бессмысленным — своими глазами видел, как при почти одновременных загрузках пакетов в один из коммерческих репозиториев (правда, в бесплатной версии) файл с метаданными просто обнуляется в размере. Подобная потеря данных может быть одним из признаков «гонок», то есть некорректной обработки многопоточного доступа. Отсюда и необходимость обработки подобной ситуации.
Я не берусь утверждать, что мой подход — единственно правильный, но факт использования очереди «под капотом» того же Pulp может быть косвенным подтверждением моей позиции.
Прочитал статью, удивился некоторой путанице. Я не беру на себя смелость решать, что именно должно использоваться вами, другое дело, что факты поданы, гхм, своеобразно. Вот по порядку:
Во-первых, меня смутило, что в описании «что и почему» в пользу Salt указаны фичи, имеющие прямые аналоги у Ansible.
Во-вторых, если уж говорить о коммерческих решениях, то утверждение про якобы несуществующего клиента для Ansible оказывается на поверку весьма слабым: клиент очень даже существует и называется Ansible Tower .
В-третьих, Ansible тоже написан на Python.
В-четвёртых, совсем не был упомянут Ansible Galaxy — открытый свободный репозиторий ролей для Ansible, где очень часто можно найти необходимую роль, и она будет работать «из коробки», либо с минимальной подгонкой под ваш конкретный проект.
Ну и в-пятых — документацию к Salt, по ощущениям, действительно писала парочка — Шляпник и Мартовский Заяц, так что она явно проигрывает официальной документации Ansible.
P.S. Стаж использования Ansible — больше 2-х лет.
Но он настолько изящен, что я не могу удержаться от того, чтобы привести его прямо здесь:
Правильно ли я понимаю, что в таком варианте требуется прописывать переменную node_zoo_id для каждого хоста вручную?
Однако беглый поиск подсказал, что достаточно заключить разделяющую запятую вот в такую конструкцию:
{% if not loop.last %} , {% endif %}Применительно к строчке из статьи получим вот что:
zk.connect={% for host in groups['zk_nodes'] %}{{ hostvars[host]['ansible_eth0']['ipv4']['address'] }}:{{ zk_port }}{% if not loop.last %},{% endif %} {% endfor %}Или можно использовать второй вариант, приведённый в комментариях на SO по ссылке выше, но лично я в Jinja2 пока не настолько силён, чтобы уверенно написать, как правильно две подстановочные переменные со статическим символом (",") сцепить в список через фильтр «join» :-)