Какие возможности предоставляет упаковщик в операционной оболочке Windows Commander
Обновлено: 02.07.2024
Packer — полезный инструмент для создания готовых образов машин. Хотя он обычно связан с созданием образов Linux для различных платформ, он также имеет первоклассную поддержку для Windows.
Мы хотели бы объяснить, почему кто-то должен подумать о добавлении образов, созданных Packer, и подробно рассказать о том, как это приносит пользу среде DevOps на сервере Windows.
Мотивация
Предварительно созданные изображения полезны по-разному. Packer может использовать ту же конфигурацию сборки и рецепт подготовки для создания AWS AMI и образов машин Azure, которые будут использоваться в производстве, а также образов машин для локального тестирования в Virtualbox и Vagrant. Это позволяет командам разрабатывать и тестировать свой код, используя те же настройки, что и в рабочей среде, а также настройки, которые используют их коллеги.
При такой установке вы используете Packer на ранней стадии процесса разработки. Мы следуем рабочему процессу, в котором сначала создается образ, а затем в любой момент в будущем образ доступен для разработки и развертывания. Это смещает работу, связанную с установкой программного обеспечения и настройкой образа, на задолго до развертывания. Таким образом, при развертывании на один шаг меньше, и образ сервера Windows будет полностью настроен и снабжен правильным программным обеспечением и настройками.
Использование предварительно созданного образа также имеет дополнительное преимущество, заключающееся в том, что мы можем выявлять ошибки конфигурации и настройки на раннем этапе создания машины. Любые ошибки, которые могли бы возникнуть во время развертывания, обнаруживаются на ранней стадии, когда мы создаем образ нашего сервера Windows. Мы уверены, что готовый образ сервера Windows будет готов к моменту развертывания.
Это может быть удобно во многих ситуациях. Представьте себе сценарий, в котором нам нужно установить внешнее программное обеспечение на наш сервер Windows. Возможно, нам нужно настроить наш сервер Windows в качестве агента Puppet перед развертыванием. В рамках этого мы хотели бы загрузить пакет .msi с помощью простого сценария Powershell во время установки:
Любая проблема с загрузкой и получением этой части программного обеспечения от ее поставщика может привести к задержке развертывания всего нашего сервера Windows и потенциально вызвать простои или производственные ошибки. Такая проблема может возникнуть по ряду причин:
- Непредвиденная проблема с сетью не позволяет нашему серверу получить файл
- Сайт поставщика программного обеспечения недоступен.
- В URL-адресе для скачивания есть даже скромная опечатка
Такого рода болевые точки DevOps не должны возникать при развертывании. Если бы вместо этого мы начали с предварительно созданного и предварительно настроенного образа для наших производственных серверов Windows, мы могли бы развернуть новые серверы, зная, что они будут безопасно подготовлены и настроены по нашему вкусу.
Что такое Пакер?
До сих пор мы обсуждали, почему инженеры используют готовые образы Windows в своих настройках DevOps, не обсуждая конкретные инструменты и методологию. Давайте познакомимся с инструментом Packer и расскажем, почему он так хорошо подходит для решения этой задачи.
Packer — это инструмент с открытым исходным кодом, разработанный HashiCorp для создания образов машин. Это идеальный инструмент для наших целей, когда мы хотим создавать образы для нескольких платформ (AWS, Azure, Virtualbox) из одного файла шаблона сборки.
На высоком уровне Packer работает, позволяя нам определить, для какой платформы мы хотим создать нашу машину или образ с помощью сборщика. Существуют сборщики для различных платформ, и мы коснемся использования некоторых из них в нашем примере.
Следующее, что Packer позволяет нам сделать, — это использовать средства подготовки для определения шагов, которые мы хотим, чтобы Packer выполнял. Мы определяем эти шаги подготовки в файле конфигурации нашего упаковщика, и упаковщик будет использовать их для идентичной настройки образов машин, независимо от платформ, на которые мы ориентируемся в наших сборщиках.
Как мы упоминали ранее, Packer отлично поддерживает Windows. Позже мы подробно рассмотрим использование средства подготовки файлов, а также средства подготовки PowerShell. На данный момент стоит знать, что мы можем использовать средство подготовки файлов для загрузки файлов на серверы Windows, которые мы создаем. Точно так же мы можем использовать средство подготовки PowerShell для запуска сценариев Powershell, которые у нас есть на нашем хост-компьютере (тот, который мы используем для создания образов нашего сервера Windows) на сервере Windows, который мы создаем.
Деятельность — реальный пример
Packer работает с использованием файла конфигурации в формате JSON. Этот файл конфигурации также называется шаблоном сборки Packer. Вы указываете сборщиков и поставщиков для Packer, которые мы обсуждали ранее в этом шаблоне сборки.
На этом этапе, если вы хотите выполнить следующие несколько шагов в этом примере самостоятельно, вам следует сначала установить Packer на свой компьютер.Официальное руководство по установке Packer находится здесь, и если вам нужно установить Vagrant, следуйте официальному руководству по установке здесь. Кроме того, проверьте соответствующий репозиторий кода для этой записи в блоге здесь.
Packer — это зрелый, хорошо используемый инструмент, для которого доступно множество отличных шаблонов и примеров для различных вариантов использования. В нашем примере мы основываем наш код шаблона на шаблонах Packer Windows от Stefan Scherer. Набор шаблонов, доступных в этом репозитории, является отличным ресурсом для начала работы. Шаблон сборки для нашего примера полностью доступен в репозитории кода, связанном с этим блогом, но далее мы рассмотрим некоторые важные детали.
Первое, о чем мы хотели бы рассказать, — это раздел конструктора. Для построителя ящиков Vagrant мы используем:
имеется в виду переменная autounattend из раздела переменных файла шаблона сборки Packer:
Когда вы загружаете установочный образ сервера Windows (как мы делаем здесь с Packer), вы обычно используете Autounattend.xml для автоматизации инструкций по установке, которые обычно запрашиваются у пользователя. Здесь мы монтируем этот файл на виртуальную машину с помощью дисковода (секция floppy_files). Мы также используем эту функцию для загрузки сценариев PowerShell на виртуальную машину. Например, win-updates.ps1 устанавливает последние обновления во время создания образа сервера Windows.
Мы также собираемся добавить дополнительные скрипты для запуска с поставщиками. Они находятся в разделе подготовки шаблона сборки упаковщика и не зависят от какой-либо конкретной платформы, указанной в каждой из записей раздела сборки.
Раздел средств подготовки в нашем шаблоне сборки выглядит следующим образом:
Мы используем как средство подготовки PowerShell, так и средство подготовки оболочки Windows для старых сценариев Windows CMD. Причина, по которой мы используем средства подготовки для запуска этих сценариев, а не размещаем их на дискете, как мы делали ранее в сборщике для блока Vagrant, заключается в том, что эти сценарии являются общими для всех платформ, на которые мы хотели бы нацелить наш шаблон сборки. По этой причине мы хотели бы, чтобы они работали независимо от платформ, для которых мы используем наш шаблон сборки.
Создание и запуск локального сервера Windows в Vagrant
Общий обзор локального запуска нашего сервера Windows следующий:
- Сначала мы создадим бокс-файл Vagrant для нашего сервера Windows с помощью Packer
- Мы добавим этот ящик в Vagrant
- Затем мы инициализируем его нашим шаблоном Vagrantfile
- И, наконец, мы его загрузим.
Сборка Packer box может быть выполнена с помощью команды packer build. В нашем примере наш шаблон сборки сервера Windows называется windows_2019.json, поэтому мы начинаем сборку упаковщика с
Если у нас есть несколько сборщиков, мы можем сообщить упаковщику, что мы хотели бы использовать только тип виртуального бокса, с помощью команды:
(Обратите внимание, что значение типа, которое мы установили ранее в нашем разделе Vagrant box builder шаблона сборки упаковщика, было: "type": "virtualbox-iso", ).
Далее мы добавим ящик в vagrant с помощью команды vagrant box add, которая используется следующим образом:
Или, точнее, для нашего примера мы вызываем эту команду как:
Затем нам нужно инициализировать наш
и загрузите его с помощью:
На этом этапе у нас будет полностью подготовленный и работающий сервер Windows в Vagrant.
Набор команд, которые мы использовали выше для сборки и использования нашего шаблона сборки Packer, аккуратно инкапсулирован в цели Makefile. Если вы используете пример кода из репозитория, прилагаемого к этому сообщению блога, вы можете просто запустить следующие команды make:
Заключение
На данный момент, несмотря на то, что мы собираемся использовать этот блок Vagrant и связанный с ним файл Vagrant только для целей локального тестирования, мы устранили вероятность ошибок, которые могут возникнуть во время установки нашего сервера Windows. Когда мы используем этот ящик для будущей разработки и тестирования (или передаем его другим коллегам, чтобы сделать то же самое), нам не нужно беспокоиться о том, что один из наших сценариев установки может дать сбой, и нам нужно будет исправить его, чтобы продолжить работу. Мы смогли устранить целую категорию ошибок DevOps и конкретную проблему разработки, используя Packer для создания нашего образа сервера Windows.
Мы также знаем, что если мы сможем собрать нашу коробку с помощью Packer и выполнить этапы подготовки, у нас будет образ, идентичный нашим производственным образам, который мы сможем использовать для тестирования и работы.
Дальнейшие шаги
Если эта запись в блоге показалась вам интересной или вам интересно, как современные инструменты DevOps, такие как Packer, могут улучшить ваши проекты, вам следует ознакомиться с нашими будущими публикациями в блоге. Скоро у нас будет серия статей об использовании таких инструментов, как Packer, для улучшения вашей среды DevOps.
В будущих публикациях мы расскажем о том, как использовать Vagrant с Packer, а также о том, как использовать Packer для создания образов AWS AMI для развертывания вашей производственной среды.Это будут естественные следующие шаги, если вы хотите продолжить тему, затронутую в этом посте.
Мы также постоянно добавляем новые сообщения DevOps, и вы можете подписаться на наш список рассылки DevOps, если хотите, чтобы наши последние статьи DevOps доставлялись на ваш почтовый ящик.
Подпишитесь на наш блог по электронной почте
Подписка по электронной почте поступает из нашего канала Atom и обрабатывается Blogtrottr. Вы будете получать уведомления только о сообщениях блога и можете отказаться от подписки в любое время.
Вам понравилась эта запись в блоге и вам нужна помощь в разработке программного обеспечения нового поколения, DevSecOps или блокчейне и смарт-контрактах? Свяжитесь с нами.
shell-local запустит сценарий оболочки по вашему выбору на машине, на которой запущен Packer. Другими словами, shell-local запустит сценарий оболочки на вашем сервере сборки или на вашем рабочем столе и т. д. удаленный/гостевой компьютер предоставляется Packer.
Удаленный поставщик оболочки выполняет сценарии оболочки на удаленном компьютере.
Пример ниже полностью функционален.
Справочник по доступным параметрам конфигурации указан ниже. Единственным обязательным элементом является command .
Требуется точно один из следующего:
Команда(строка) — это единственная команда для выполнения. Он будет записан во временный файл и запущен с помощью вызова execute_command ниже. Если вы создаете виртуальную машину Windows на AWS, Azure, Google Compute или OpenStack и хотите получить доступ к сгенерированному паролю, который Packer использует для подключения к экземпляру через WinRM, вы можете использовать переменную шаблона >, чтобы установить ее как переменную среды. .
inline (массив строк) — это массив команд для выполнения. Команды объединяются символами новой строки и превращаются в один файл, поэтому все они выполняются в одном контексте. Это позволяет вам менять каталоги в одной команде и использовать что-то в каталоге в следующей и так далее. Встроенные сценарии — это самый простой способ выполнять простые задачи на машине, на которой работает Packer.
script (строка) — путь к скрипту для выполнения. Этот путь может быть абсолютным или относительным. Если он относительный, то он относится к рабочему каталогу при выполнении Packer.
scripts (массив строк) — массив скриптов для выполнения. Скрипты будут выполняться в указанном порядке. Каждый скрипт выполняется изолированно, поэтому такие состояния, как переменные из одного скрипта, не переносятся в следующий.
env (карта строк) — карта пар ключ/значение для ввода до выполнения команды execute_command. Packer также по умолчанию внедряет в среду некоторые переменные среды, которые рассматриваются в разделе ниже. Дублирующиеся настройки env имеют приоритет над настройками environment_vars.
environment_vars (массив строк) — массив пар ключ/значение для вставки перед execute_command. Формат должен быть ключ=значение. Packer также по умолчанию внедряет в среду некоторые переменные среды, которые рассматриваются в разделе ниже. Если вы создаете виртуальную машину Windows на AWS, Azure, Google Compute или OpenStack и хотите получить доступ к сгенерированному паролю, который Packer использует для подключения к экземпляру через WinRM, вы можете использовать переменную шаблона >, чтобы установить ее как переменную среды. . Например: "environment_vars": "WINRMPASS=>"
env_var_format (string) — когда мы анализируем предоставленные вами переменные окружения, это дает нам строковый шаблон, который мы используем, чтобы убедиться, что мы правильно устанавливаем переменные окружения. По умолчанию на хостах Windows этот формат установлен как %s=%s &&, а на Unix — %s='%s'. Вам, вероятно, не потребуется изменять этот формат, но вы можете увидеть примеры использования, где это необходимо, ниже.
execute_command (массив строк) — команда, используемая для выполнения скрипта. По умолчанию это ["/bin/sh", "-c", ">", ">"] в Unix и ["cmd", "/c", ">", ">"] в Windows. Это рассматривается как механизм шаблонов. Доступны две переменные: Script , представляющая собой путь к запускаемому сценарию, и Vars , представляющая собой список переменных окружения, если они настроены.
Если вы решите установить этот параметр, убедитесь, что первым элементом массива является программа оболочки, которую вы хотите использовать (например, "sh"), а последующий элемент массива должен быть > .
Этот вариант обеспечивает большую гибкость. Вы можете указать свою собственную программу-оболочку, например, «/usr/local/bin/zsh» или даже «powershell.exe». Однако с большой силой приходит и большая ответственность — эти команды официально не поддерживаются, и такие вещи, как переменные среды, могут не работать, если вы используете оболочку, отличную от используемой по умолчанию.
Для обратной совместимости вы также можете использовать > , но он расшифровывается так же, как > . Мы рекомендуем использовать > для ясности, так как даже если вы установите для запуска только одну команду, Packer запишет ее во временный файл, а затем запустит как скрипт.
Если вы создаете виртуальную машину Windows на AWS, Azure, Google Compute или OpenStack и хотите получить доступ к сгенерированному паролю, который Packer использует для подключения к экземпляру через WinRM, вы можете использовать переменную шаблона >, чтобы установить его как переменная среды.
inline_shebang (строка) — значение shebang, используемое при выполнении команд, указанных в inline . По умолчанию это /bin/sh -e . Если вы не используете inline , эта конфигурация не действует. Важно: если вы настраиваете это, обязательно включите что-то вроде флага -e, в противном случае сбой отдельных шагов не приведет к сбою поставщика.
only_on (массив строк) — это массив операционных систем времени выполнения, в которых будет выполняться shell-local. Это позволяет выполнять локальную оболочку только в определенных операционных системах. По умолчанию shell-local будет выполняться всегда, если не установлен параметр only_on."
use_linux_pathing (bool) — относится только к хостам Windows. Если вы запускаете Packer в среде Windows с включенной функцией подсистемы Windows для Linux и хотите вызвать сценарий bash, а не сценарий Cmd, вам необходимо установить этот флаг в значение true; он указывает Packer использовать путь подсистемы linux для вашего скрипта, а не путь Windows. (например, /mnt/c/path/to/your/file вместо C:/path/to/your/file). В приведенном ниже примере приведены дополнительные рекомендации по использованию этой функции. Если вы не находитесь на хосте Windows или не собираетесь использовать локальную оболочку для запуска скрипта bash, игнорируйте этот параметр.
valid_exit_codes (список целых чисел) — допустимые коды выхода для скрипта. По умолчанию это 0 .
Параметры, общие для всех поставщиков:
pause_before (duration) — спящий режим перед выполнением.
max_retries (int) — максимальное количество повторных попыток поставщика в случае сбоя. По умолчанию ноль (0). Ноль означает, что ошибка не будет повторена.
Только(массив строк) — запускать средство подготовки только для перечисленных построителей по имени.
переопределить (объект) — переопределить построитель с другими настройками для конкретного построителя, например:
Каждая виртуальная машина (ВМ) в Azure создается из образа, который определяет дистрибутив Windows и версию ОС. Образы могут включать предустановленные приложения и конфигурации. Azure Marketplace предоставляет множество собственных и сторонних образов для наиболее распространенных операционных систем и сред приложений, или вы можете создавать собственные образы, соответствующие вашим потребностям. В этой статье подробно описано, как использовать инструмент Packer с открытым исходным кодом для определения и создания пользовательских образов в Azure.
В последний раз эта статья тестировалась 05.08.2020 с использованием Packer версии 1.6.1.
В Azure теперь есть служба Azure Image Builder для определения и создания собственных настраиваемых образов. Azure Image Builder основан на Packer, поэтому вы даже можете использовать с ним существующие сценарии подготовки оболочки Packer. Чтобы начать работу с Azure Image Builder, см. раздел Создание виртуальной машины Windows с помощью Azure Image Builder.
Создать группу ресурсов Azure
Во время сборки Packer создает временные ресурсы Azure по мере сборки исходной виртуальной машины. Чтобы захватить эту исходную виртуальную машину для использования в качестве образа, необходимо определить группу ресурсов. Выходные данные процесса сборки Packer хранятся в этой группе ресурсов.
Создайте группу ресурсов с помощью командлета New-AzResourceGroup. В следующем примере создается группа ресурсов с именем myPackerGroup в расположении eastus:
Создайте учетные данные Azure
Packer выполняет аутентификацию в Azure с помощью субъекта-службы. Субъект-служба Azure — это удостоверение безопасности, которое можно использовать с приложениями, службами и средствами автоматизации, такими как Packer. Вы контролируете и определяете разрешения на то, какие операции субъект-служба может выполнять в Azure.
Создайте субъект-службу с помощью командлета New-AzADServicePrincipal. Значение для -DisplayName должно быть уникальным; при необходимости замените своим значением.
Затем выведите пароль и идентификатор приложения.
Для аутентификации в Azure вам также необходимо получить идентификаторы клиента и подписки Azure с помощью Get-AzSubscription:
Определить шаблон упаковщика
Для создания изображений вы создаете шаблон в виде файла JSON. В шаблоне вы определяете сборщиков и поставщиков, которые выполняют фактический процесс сборки. У Packer есть построитель для Azure, который позволяет вам определять ресурсы Azure, такие как учетные данные субъекта-службы, созданные на предыдущем шаге.
Создайте файл с именем windows.json и вставьте в него следующее содержимое. Введите собственные значения для следующего:
| Параметр | Где получить |
|---|---|
| client_id | Просмотр идентификатора субъекта-службы с $sp.applicationId |
| client_secret | Просмотр автоматического сгенерированный пароль с помощью $plainPassword |
| tenant_id | Вывод из команды $sub.TenantId |
| subscription_id | Вывод из $sub.Команда SubscriptionId |
| managed_image_resource_group_name | Имя группы ресурсов, созданной на первом шаге | имя_управляемого_образа | Имя создаваемого образа управляемого диска |
Этот шаблон создает виртуальную машину Windows Server 2016, устанавливает IIS, а затем обобщает виртуальную машину с помощью Sysprep. Установка IIS показывает, как вы можете использовать средство подготовки PowerShell для запуска дополнительных команд. Затем окончательный образ Packer включает установку и настройку необходимого программного обеспечения.
Гостевой агент Windows участвует в процессе Sysprep. Агент должен быть полностью установлен до того, как виртуальная машина может быть подготовлена sysprep. Чтобы убедиться в этом, все службы агентов должны быть запущены до запуска sysprep.exe. В предыдущем фрагменте кода JSON показан один из способов сделать это в средстве подготовки PowerShell. Этот фрагмент требуется только в том случае, если виртуальная машина настроена для установки агента, что является значением по умолчанию.
Создать образ упаковщика
Если Packer еще не установлен на вашем локальном компьютере, следуйте инструкциям по установке Packer.
Создайте образ, открыв командную строку и указав файл шаблона Packer следующим образом:
Пример вывода предыдущих команд выглядит следующим образом:
Пакеру требуется несколько минут, чтобы создать виртуальную машину, запустить средства подготовки и очистить развертывание.
Создать виртуальную машину из образа Packer
Теперь вы можете создать виртуальную машину из своего образа с помощью New-AzVM. Поддерживающие сетевые ресурсы создаются, если они еще не существуют. При появлении запроса введите имя пользователя и пароль администратора, которые будут созданы на виртуальной машине. В следующем примере создается виртуальная машина с именем myVM из myPackerImage:
Если вы хотите создать виртуальные машины в другой группе ресурсов или регионе, отличном от вашего образа Packer, укажите идентификатор образа, а не имя образа. Идентификатор изображения можно получить с помощью Get-AzImage.
Создание виртуальной машины из образа Packer занимает несколько минут.
Тестировать виртуальную машину и веб-сервер
Получите общедоступный IP-адрес вашей виртуальной машины с помощью Get-AzPublicIPAddress. В следующем примере получается IP-адрес для myPublicIP, созданный ранее:
Чтобы увидеть свою виртуальную машину, включающую установку IIS из Packer Provisioner, в действии, введите общедоступный IP-адрес в веб-браузере.
Дальнейшие шаги
Вы также можете использовать существующие сценарии подготовки Packer с Azure Image Builder.
Мы рады представить предварительную версию диспетчера пакетов Windows!
Если вы уже знакомы с менеджером пакетов, можете пропустить этот абзац. Если вы все еще читаете, вам это понравится! Менеджер пакетов разработан, чтобы помочь вам сэкономить время и нервы. По сути, это набор программных инструментов, которые помогают автоматизировать процесс установки программного обеспечения на вашу машину. Вы указываете, какие приложения вы хотите установить, а программа находит последнюю версию (или именно ту, которую вы указали) и устанавливает ее на свой компьютер.
Почти каждому разработчику нужен встроенный менеджер пакетов в Windows. Этот день наконец настал. Вы сможете установить winget на свой путь к счастью. Одна из лучших частей заключается в том, что это открытый исходный код. Мне пришлось ущипнуть себя, когда я смог установить терминал winget, а затем установить powershell winget, а затем установить powertoys winget. Вы поняли идею, и если вы не видите используемое приложение, просто создайте новый манифест и отправьте запрос на вытягивание.
Когда можно попробовать?
Какие функции включены?
Вы можете установить любое приложение с допустимым манифестом (даже локальным — manifest ). Клиент командной строки «winget.exe» уже предварительно настроен для указания на репозиторий сообщества Microsoft. Это означает, что вы можете установить любой пакет с опубликованным манифестом.
Приходилось ли вам когда-нибудь полностью переустанавливать все свои приложения и инструменты на свой компьютер? Как долго это займет? Как вы запомнили, где искать, загружать и устанавливать все ваши редакторы и IDE, языки и среды выполнения, инструменты управления версиями и т. д.?
Понравилось? Да, мы тоже… поэтому мы создали Диспетчер пакетов Windows.
Теперь вы можете установить все свои любимые приложения и инструменты, просто набрав winget install в командной строке. Или, что еще лучше, вы можете создать файл сценария, который установит ВСЕ ваши инструменты, пока вы сидите и наслаждаетесь заслуженным перерывом на кофе!»
Как мне его получить?
Мы предоставили вам три разных способа получить доступ к диспетчеру пакетов Windows. Если вы являетесь участником программы предварительной оценки Windows, возможно, он у вас уже есть. Во-первых, вы можете перейти к репозиторию GitHub с открытым исходным кодом для клиента. Во-вторых, вы можете присоединиться к любому кругу участников программы предварительной оценки Windows. В-третьих, вы можете присоединиться к программе предварительной оценки диспетчера пакетов Windows, предоставив свою учетную запись Microsoft (MSA) программе предварительной оценки диспетчера пакетов Windows и запросив включение в предварительную версию. Любая из программ предварительной оценки обеспечит автоматическое получение обновлений по мере того, как мы переходим от предварительной версии к общедоступной. После того, как вы присоединились к любой из программ предварительной оценки, зайдите в Microsoft Store и получите установщик приложений. Диспетчер пакетов Windows будет доступен после получения обновления.
Почему бы не внести свой вклад в другой менеджер пакетов с открытым исходным кодом?
Мы рассмотрели несколько других менеджеров пакетов. Было несколько причин, побудивших нас создать новое решение. Одной из важнейших проблем, с которыми мы столкнулись, было создание репозитория доверенных приложений. Мы автоматически проверяем каждый манифест. Мы используем SmartScreen, статический анализ, проверку хэша SHA256 и несколько других процессов, чтобы снизить вероятность проникновения вредоносного ПО в репозиторий и на ваш компьютер. Еще одна ключевая проблема заключалась во всех изменениях, необходимых для предоставления клиентской программы в качестве родного приложения Windows.
Какие версии Windows будут поддерживаться?
Диспетчер пакетов Windows будет поддерживать все версии Windows 10, начиная с Fall Creators Update (1709)! Диспетчер пакетов Windows будет поставляться с установщиком настольных приложений, когда мы выпустим версию 1.0. Если вы создаете программное обеспечение для работы в Windows 10, у ваших клиентов будет простой способ установить ваше программное обеспечение на миллиарды компьютеров.
А как насчет…
Мы ожидаем, что у вас будет много вопросов. Что это значит для магазина Windows? Это ничего не значит для магазина Windows. Диспетчер пакетов Windows — это интерфейс командной строки, без маркетинга, без изображений, без коммерции. Хотя мы планируем сделать эти приложения доступными для установки.
Как насчет вставить сюда любой другой менеджер пакетов? Мы думаем, что они великолепны. Если они хотят использовать наш репозиторий проверенных пакетов, они могут это сделать. Если они хотят увидеть, как мы это делаем, это с открытым исходным кодом. Мы открыты для отзывов и предложений.
Мы уже поговорили с несколькими известными командами менеджеров пакетов. У Chocolatey активное сообщество с огромной коллекцией приложений и богатая история поддержки как клиентов с открытым исходным кодом, так и корпоративных клиентов. Scoop предоставляет удобный способ установки программного обеспечения без всплывающих окон UAC. Ninite следит за обновлениями всех установленных приложений. Есть много других, таких как AppGet, Npackd и диспетчер-менеджер пакетов OneGet на основе PowerShell.
Если вас устраивает текущий менеджер пакетов, продолжайте его использовать. Наша цель — сделать установку программного обеспечения в Windows удобнее для всех.
Что дальше?
У нас есть длинный список функций, которые, как мы думаем, вам понравятся. Взгляните на список задач, которые мы уже создали на GitHub. Обязательно добавляйте +1 ко всем проблемам, которые вас сильно беспокоят. Если вы чего-то не видите, и хотите, чтобы мы это рассмотрели, просто создайте новую проблему.
Читайте также: