Как artifactory, chef и chocolatey работают вместе?

Мы находимся в процессе реализации конвейера CI / CD и используем TFS в качестве репозитория кода и инструмента сборки и выпуска. У меня есть следующие конкретные вопросы:

  1. В настоящее время мы храним библиотеки и сторонние инструменты, которые потребуются нам во время сборки, в нашем репозитории кода. Мы хотели бы проанализировать другие способы хранения и доступа к сторонним инструментам и библиотекам.
    • Будет ли Artifactory подходящим инструментом для их хранения? Насколько я понимаю, Artifactory следует использовать только для хранения артефактов сборки, которые можно выбросить и воссоздать.
    • ИЛИ использовать Chocolatey лучше? Насколько я понимаю, нам нужно будет создавать пакеты Chocolatey из наших сторонних инструментов и библиотек. Где же:
      • источник этих пакетов, например (.exe, .dll, .zip, .msi) обычно находятся?
        • В расположении файла UNC?
        • Или в бинарном репозитории вроде Artifactory?
        • Является ли использование двоичного репозитория для хранения зависимостей времени сборки правильным подходом? Он должен постоянно находиться там, и каждая новая версия будет увеличивать размер репозитория.
      • сами пакеты Chocolatey проживают?
        • В расположении файла UNC?
        • Или в бинарном репозитории вроде Artifactory?
        • Является ли использование двоичного репозитория для хранения зависимостей времени сборки правильным подходом? Он должен находиться там постоянно, и каждая новая версия будет увеличивать размер репозитория.
  2. Если мы храним сторонние инструменты и библиотеки вне нашего репозитория кода
    • Нужно ли нам использовать Chef и Chocolatey для доступа к ним?
    • ИЛИ можем ли мы получить к ним доступ напрямую из TFS с помощью Chocolatey без использования Chef в процессе сборки?
  3. Правильно ли я полагаю, что Chef в основном используется для настройки среды сборки с необходимым программным обеспечением и переменными среды перед запуском процесса сборки?

«Насколько я понимаю, Artifactory следует использовать только для хранения артефактов сборки, которые можно выбросить и воссоздать». Не уверен, откуда вы получаете эту информацию, нет причин не помещать все ваши двоичные файлы в Artifactory. Два наиболее распространенных варианта использования - это хранение внутренних сборок (которые обычно можно выбросить и воссоздать заново) и сторонних зависимостей (часто через удаленный репозиторий, проксирующий сторонний источник, но не всегда). Мне ваш случай кажется довольно стандартным использованием Artifactory.

DarthFennec 31.10.2018 22:55
2
1
597
1
Перейти к ответу Данный вопрос помечен как решенный

Ответы 1

Ответ принят как подходящий

Давай посмотрим, смогу ли я рассказать тебе об этом.

  1. We currently store the libraries and 3rd party tools that we require during our build in our code repository. We would like to analyze other ways of storing and accessing 3rd party tools and libraries.

    • Would Artifactory be a right tool to store them into?

Да, Artifactory и другие серверы репозитория пакетов обычно имеют двоичный / необработанный репозиторий, что было бы хорошим вариантом. Думайте об Artifactory как о месте, где можно разместить артефакты производственного использования. Таким образом, эти библиотеки, сторонние инструменты, стороннее программное обеспечение, модули и т. д. Могут храниться в различных типах репозиториев в Artifactory. Artifactory будет менеджером репозитория пакетов корпоративного уровня, оптимизированным для этого, обрабатывать High Available и многое другое. Здесь вы храните, защищаете и развертываете двоичные файлы, пакеты, программное обеспечение и т. д. Это могут быть среды разработки, тестирования, стадии и производственной среды.

  • As far as I understand Artifactory should only be used for storing build artifacts that can be thrown away and recreated.

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

  • OR is using Chocolatey a better option?

Это не вариант, конкурирующий с Artifactory. Шоколадные пакеты можно хранить в Artifactory (Pro) в репозитории типа NuGet. Двоичные файлы будут либо В пакетами Chocolatey, либо могут находиться в двоичном / необработанном репозитории.

Artifactory - это хранилище репозиториев пакетов, где Chocolatey - менеджер пакетов (управление и развертывание программного обеспечения) для Windows.

As far as I understand we would need to create Chocolatey packages from our 3rd party tools and libraries. Where does: the source of those packages e.g. (.exe, .dll, .zip, .msi) usually reside?

  • In an UNC file location?
  • Or in a binary repository like Artifactory?
  • Is using a binary repository to store build-time dependencies the correct approach?

Вы забыли наиболее часто используемый и рекомендуемый подход:

  • В самой упаковке

В самом пакете Chocolatey это наиболее рекомендуемое место для хранения двоичных файлов, представляемых пакетом. Это наиболее детерминированный и надежный метод для пакетов.

Проблема в том, что вы можете рассматривать репозиторий пакетов сообщества в качестве примера упаковки - мы бы рекомендовали НЕ делать этого, поскольку он не представляет, но, возможно, 5% пакетов. Мы не рекомендуем следовать этому подходу, поскольку это ненадежный подход.

  • It would need to reside there permanently and every new version is going to add to the repository size.

Это правда, однако в Artifactory действительно есть подход отбраковки (я считаю), и он оптимизирован для таких сценариев. Мы изучаем рекомендации по системным требованиям для различных коммерческих репозиториев в https://chocolatey.org/docs/how-to-host-feed#commercial-repository-system-requirements.

  • the Chocolatey packages themselves reside?
    • In an UNC file location?

Они абсолютно могут, но имейте в виду, как разрешения работают с общими файловыми ресурсами и разрешениями Windows - https://chocolatey.org/docs/how-to-host-feed#local-folder-permissions

  • Or in a binary repository like Artifactory?

Нет, это будет репозиторий NuGet OData, доступный в Artifactory Pro. Да, репозиторий NuGet Artifactory был бы отличным местом, и можно было бы использовать несколько репозиториев для разных сред, разрешений и т. д. Все, что имеет смысл для вашей среды.

  • Is using a binary repository to store build-time dependencies the correct approach? It would need to reside there permanently and every new version is going to add to the repository size.

Я думаю, что этим занимались в другом месте.

  1. If we store the 3rd party tools and libraries outside of our code repository
    • Do we need to use Chef and Chocolatey to access them?
    • OR can we access them directly from TFS using Chocolatey without having to use Chef in the build process?

Вы можете сделать и то, и другое. Если вы поместите сторонние инструменты в пакеты развертывания программного обеспечения (также известные как пакеты Chocolatey), вам понадобится Chocolatey для управления развертыванием.

  1. Am I correct into thinking that Chef is primarily used to setup build environments with the required software and environment variables before starting a build process?

Я бы сказал, что вы неправильно понимаете Chef - это решение для управления конфигурацией. Он может настраивать среды сборки и поддерживать их в желаемом состоянии, но это ограничивает возможности. Chef (и другие менеджеры конфигурации) используются для написания сценария состояния ожиданий (желаемого состояния) для вашей инфраструктуры (инфраструктуры как кода), которое вы можете проверить в системе управления версиями и протестировать все изменения инфраструктуры перед развертыванием, возможно, с использованием непрерывной интеграции (CI ) серверы, такие как Jenkins, TeamCity, TFS, для этого (что приводит к тестированию вашей инфраструктуры, тестированию инфраструктуры и т. д.) и т. д. чтобы внедрить эти методы разработки в работу. Я называю это современной автоматизацией, но некоторые называют такие сдвиги DevOps.

Рекомендация

Вы можете использовать решение Chef + Chocolatey + Artifactory для управления программным обеспечением и конфигурациями компьютеров в вашей организации, а не только в средах разработки. Я думаю, что возможно вы подходите ко всем этим инструментам с точки зрения позиции типа разработчика и, таким образом, просто думаете в контексте предоставления, а не долгосрочного управления развертываниями, конфигурацией и т. д., Что операционный / системный администратор может быть смотря на. Все эти инструменты, безусловно, добавляют что-то к этому, но все они дополняют друг друга, а не конкурируют друг с другом. Для многих более крупных организаций установка этих или аналогичных компонентов создает архитектуру, которая может удовлетворить критически важные инфраструктурные потребности сегодняшних организаций.

Другие вопросы по теме