Синхронизация браузера не является внутренней или внешней командой исполняемой программы или пакетного файла

Обновлено: 21.11.2024

Сначала загрузите и установите локально команду esbuild. Готовый собственный исполняемый файл можно установить с помощью npm (который устанавливается автоматически при установке среды выполнения JavaScript узла):

Это должно было установить esbuild в вашу локальную папку node_modules. Вы можете запустить исполняемый файл esbuild, чтобы убедиться, что все работает правильно:

Рекомендуемый способ установки esbuild — установить собственный исполняемый файл с помощью npm. Но если вы не хотите этого делать, есть и другие способы установки.

Это краткий реальный пример того, на что способен esbuild и как его использовать. Сначала установите пакеты react и react-dom:

Затем создайте файл app.jsx, содержащий следующий код:

Наконец, скажите esbuild собрать файл:

Это должно было создать файл с именем out.js, содержащий ваш код и библиотеку React, объединенные вместе. Код полностью автономен и больше не зависит от вашего каталога node_modules. Если вы запустите код с помощью node out.js, вы должны увидеть что-то вроде этого:

Обратите внимание, что esbuild также преобразовал синтаксис JSX в JavaScript без какой-либо настройки, кроме расширения .jsx. Хотя esbuild можно настроить, он пытается использовать разумные значения по умолчанию, чтобы многие распространенные ситуации работали автоматически. Если вместо этого вы хотите использовать синтаксис JSX в файлах .js, вы можете указать esbuild разрешить это, используя флаг --loader:.js=jsx. Подробнее о доступных параметрах конфигурации можно прочитать в документации по API.

Ваша команда сборки — это то, что вы будете запускать неоднократно, поэтому вам нужно автоматизировать ее. Естественный способ сделать это — добавить скрипт сборки в файл package.json следующим образом:

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

Сценарий сборки можно вызвать следующим образом:

Однако использование интерфейса командной строки может стать громоздким, если вам нужно передать много параметров в esbuild. Для более сложных применений вам, вероятно, потребуется написать скрипт сборки на JavaScript с использованием JavaScript API esbuild. Это может выглядеть примерно так:

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

Хотя API buildSync также не является асинхронным, асинхронный API лучше подходит для сценариев сборки, поскольку подключаемые модули работают только с асинхронным API. Подробнее о параметрах конфигурации API сборки можно прочитать в документации по API.

Упаковщик по умолчанию выводит код для браузера, поэтому для начала работы не требуется дополнительная настройка. Для сборок разработки вы, вероятно, захотите включить исходные карты с помощью --sourcemap , а для производственных сборок вы, вероятно, захотите включить минимизацию с помощью --minify . Возможно, вы также захотите настроить целевую среду для поддерживаемых вами браузеров. Все это может выглядеть примерно так:

Иногда пакет, который вы хотите использовать, может импортировать другой пакет, доступный только на узле, например встроенный пакет пути. Когда это произойдет, вы можете заменить пакет удобным для браузера вариантом, используя поле браузера в файле package.json следующим образом:

Некоторые пакеты npm, которые вы хотите использовать, могут быть не предназначены для запуска в браузере. Иногда вы можете использовать параметры конфигурации esbuild, чтобы обойти определенные проблемы и в любом случае успешно собрать пакет. Неопределенные глобальные переменные можно заменить функцией определения в простых случаях или функцией внедрения в более сложных случаях.

Несмотря на то, что сборщик не нужен при использовании узла, иногда все же может быть полезно обработать код с помощью esbuild перед его запуском в узле. Объединение может автоматически удалять типы TypeScript, преобразовывать синтаксис модуля ECMAScript в CommonJS и преобразовывать новый синтаксис JavaScript в старый синтаксис для конкретной версии узла. И может быть полезно собрать пакет перед его публикацией, чтобы он загружался меньше и тратил меньше времени на чтение из файловой системы при загрузке.

Если вы объединяете код, который будет выполняться в узле, вам следует настроить параметр платформы, передав --platform= node в esbuild. Это одновременно изменяет несколько различных настроек на значения по умолчанию, удобные для узлов. Например, все пакеты, встроенные в узел, такие как fs, автоматически помечаются как внешние, поэтому esbuild не пытается их объединить.Этот параметр также отключает интерпретацию поля браузера в package.json .

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

Вы также можете не захотеть связывать свои зависимости с esbuild. Существует множество специфичных для узла функций, которые esbuild не поддерживает при сборке, таких как __dirname , import.meta.url , fs.readFileSync и собственные двоичные модули *.node. Вы можете исключить все свои зависимости из пакета, пометив их как внешние:

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

Вы не можете установить esbuild в одной ОС, скопировать каталог node_modules в другую ОС без переустановки, а затем запустить esbuild в этой другой ОС. Это не сработает, потому что esbuild написан с собственным кодом и требует установки двоичного исполняемого файла для конкретной платформы. Обычно это не проблема, потому что обычно вы регистрируете файл package.json в системе управления версиями, а не в каталоге node_modules, а затем каждый запускает npm install на своем локальном компьютере после клонирования репозитория.

Однако люди иногда попадают в эту ситуацию, устанавливая esbuild в Windows или macOS и копируя свой каталог node_modules в образ Docker, работающий под управлением Linux, или копируя свой каталог node_modules между средами Windows и WSL. Способ заставить это работать зависит от вашего менеджера пакетов:

npm/pnpm: если вы устанавливаете с помощью npm или pnpm, вы можете попробовать не копировать каталог node_modules при копировании файлов и запустить npm ci или npm install на целевой платформе после копирования. Или вы можете вместо этого использовать Yarn со встроенной поддержкой установки пакета на несколько платформ одновременно.

Yarn: если вы устанавливаете с помощью Yarn, вы можете попробовать перечислить эту и другую платформы в файле .yarnrc.yml, используя функцию supportArchitectures. Имейте в виду, что это означает, что в файловой системе будет присутствовать несколько копий esbuild.

Другой альтернативой является использование пакета esbuild-wasm, который работает одинаково на всех платформах. Но это связано с большими потерями производительности и иногда может быть в 10 раз медленнее, чем пакет esbuild, поэтому вы также можете не захотеть этого делать.

Рекомендуемый способ установки esbuild — установить собственный исполняемый файл с помощью npm. Но вы также можете установить esbuild следующими способами:

В дополнение к пакету esbuild npm существует также пакет esbuild-wasm, который работает аналогично, но использует WebAssembly вместо собственного кода. При его установке также будет установлен исполняемый файл esbuild :

Почему это не рекомендуется: версия WebAssembly намного медленнее, чем собственная версия. Во многих случаях это на порядок (т.е. в 10 раз) медленнее. Это происходит по разным причинам, в том числе: а) узел повторно компилирует код WebAssembly с нуля при каждом запуске, б) подход к компиляции WebAssembly в Go является однопоточным, и в) в узле есть ошибки WebAssembly, которые могут задерживать выход из процесса на много секунд. . Версия WebAssembly также исключает некоторые функции, такие как локальный файловый сервер. Вы должны использовать такой пакет WebAssembly только в том случае, если нет другого варианта, например, когда вы хотите использовать esbuild на неподдерживаемой платформе. Пакет WebAssembly в первую очередь предназначен для использования только в браузере.

В основном он имеет тот же API, что и пакет esbuild npm, с одним дополнением: вам нужно вызвать stop(), когда вы закончите, потому что, в отличие от node, Deno не предоставляет необходимых API, позволяющих Deno выйти из внутреннего дочернего элемента esbuild. процесс все еще выполняется.

Чтобы собрать esbuild из исходного кода:

Если вы хотите выполнить сборку для других платформ, вы можете просто указать перед командой сборки информацию о платформе. Например, вы можете собрать 32-битную версию Linux с помощью этой команды:

Почему это не рекомендуется: нативную версию можно использовать только через интерфейс командной строки, что может быть неудобным для сложных случаев использования и не поддерживает подключаемые модули. Вам нужно будет написать код JavaScript или Go и использовать API esbuild для использования плагинов.

Вот пример прямой загрузки двоичного исполняемого файла:

Собственный исполняемый файл в пакете esbuild-darwin-64 предназначен для операционной системы macOS и архитектуры x86-64. На момент написания это полный список собственных исполняемых пакетов для платформ, поддерживаемых esbuild:

Имя пакета	ОС	Архитектура
esbuild-android-arm64	android	arm64
esbuild-darwin-64 < /td>	darwin	x64
esbuild-darwin-arm64	darwin	arm64
esbuild-freebsd-64	freebsd	x64
esbuild -freebsd-arm64	freebsd	arm64
esbuild-linux-32	linux	ia32
esbuild-linux-64	linux	x64
esbuild-linux-arm	linux	arm
esbuild-linux-arm64	linux	arm64
esbuild-linux-mips64le	linux	mips64el 2
esbuild-linux-ppc64le	linux	ppc64
esbuild-linux-riscv64	linux	riscv64 2
esbuild-linux-s390x	linux	s390x
esbuild-netbsd-64	netbsd 1	x64
esbuild-openbsd-64	openbsd	x64
esbuild-sunos-64	sunos	x64
esbuild-windows-32	win32< /td>	ia32
esbuild-windows-64	win32	x64
esbuild-windows-arm64	win32	arm64

Почему это не рекомендуется: это зависит от внутренних деталей реализации собственного исполняемого установщика esbuild. Эти детали могут измениться в какой-то момент, и в этом случае этот подход больше не будет работать для новых версий esbuild. Это лишь незначительный недостаток, поскольку этот подход должен по-прежнему работать вечно для существующих версий esbuild, поскольку пакеты, опубликованные в npm, неизменяемы. Дополнительным недостатком является то, что вы не можете использовать плагины с нативной версией.

1 Эта операционная система отсутствует в списке поддерживаемых платформ узла
2 Эта архитектура отсутствует в списке поддерживаемых архитектур узла

WSUSutil.exe — это инструмент, который можно использовать для управления сервером WSUS из командной строки. WSUSutil.exe находится в папке %drive%\Program Files\Update Services\Tools на вашем сервере WSUS. Вы можете запускать определенные команды с помощью WSUSutil.exe для выполнения определенных функций, как показано в следующей таблице. Синтаксис, который вы будете использовать для запуска WSUSutil.exe с определенными командами, приведен в таблице.

Сводка команд, которые можно использовать с WSUSutil

Экспорт

Синтаксис

В командной строке %drive%\Program Files\Update Services\Tools> введите:

wsusutil экспортирует пакет файл журнала

Параметры определены в следующей таблице.

Вы можете использовать xcopy, утилиту резервного копирования или другие методы, не относящиеся к WSUS, для копирования файлов обновлений из старого расположения в новое. Если вы копируете файлы с помощью метода, отличного от WSUSutil.exe, вам все равно нужно запустить WSUSutil.exe для выполнения второй части перемещения. В этом случае вы должны использовать параметр skipcopy при запуске WSUSutil.exe. Дополнительную информацию см. в разделе "Синтаксис" ниже.

Существует два сценария, в которых вы можете перемещать файлы обновлений с одного диска WSUS на другой:

Если диск заполнен
Если жесткий диск вышел из строя

Если диск заполнен

Если диск, на котором WSUS хранит файлы обновлений, заполнен, вы можете выполнить одно из следующих действий:

Добавьте больше места на текущий диск, используя функции NTFS. Это делается без использования WSUSutil.exe. Этот метод не влияет на настройку или работу WSUS.
Установите новый диск, а затем переместите файлы обновления со старого диска в новое место с помощью Wsusutil.exe.

Если жесткий диск вышел из строя

Если жесткий диск, на котором хранятся файлы обновлений, выходит из строя, необходимо сделать следующее:

Установите новый диск на свой компьютер, а затем восстановите файлы обновления из файлов резервной копии. Примечание. Если вы не создали резервную копию файлов обновлений, WSUSutil.exe загрузит отсутствующие файлы в конце операции перемещения содержимого.
Запустите операцию перемещения содержимого, указав расположение нового диска. Кроме того, вы указываете параметр skipcopy, потому что либо вы кладете файлы в новую папку через утилиту резервного копирования, либо исходная папка не существует; файлы обновлений будут загружены в конце этого процесса.
По завершении операции перемещения все отсутствующие файлы загружаются.

Синтаксис

В командной строке *%drive%\*Program Files\Update Services\Tools> введите:

wsusutil movecontent файл журнала содержимого -skipcopy [/?]

Параметры определены в следующей таблице.

Синтаксис

В командной строке %drive%\Program Files\Update Services\Tools> введите:

wsusutil удалить ненужные версии

Перед выполнением этой команды необходимо остановить службу публикации World Wide Web в IIS. Вы должны перезапустить его только после того, как закончите выполнение этой команды. Чтобы остановить или запустить службу IIS, откройте IIS, перейдите и щелкните правой кнопкой мыши веб-сайт, на котором установлена служба WSUS (по умолчанию это веб-сайт по умолчанию), а затем нажмите "Остановить" или "Пуск".

Список активных одобрений

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

Вот сценарий, в котором это может произойти:

Вы настроили вышестоящий родительский сервер для синхронизации с Центром обновления Майкрософт и оставили для параметра языка значение Все языки (по умолчанию). Затем вы запускаете синхронизацию и утверждаете 300 обновлений, 50 из которых не являются обновлениями на английском языке. Затем вы меняете языковые настройки на сервере только на английский. После этого сервер-реплика синхронизируется с родительским вышестоящим сервером и загружает только «активные» утверждения, которые теперь являются только англоязычными (серверы-реплики всегда синхронизируют только активные утверждения). На этом этапе, если вы посмотрите на консоль WSUS на родительском сервере, вы увидите, что одобрено 300 обновлений. Если вы сделаете то же самое на сервере-реплике, вы увидите, что одобрено только 250. Вы должны использовать listinactiveapprovals, чтобы увидеть список обновлений на родительском восходящем сервере, которые постоянно неактивны — в этом случае вы увидите 50 обновлений, которые не на английском языке. Вы можете запустить эту команду, если хотите просмотреть список неактивных утверждений (например, чтобы решить, хотите ли вы удалить неактивные утверждения). Вам не нужно запускать эту команду перед запуском команды removeinactiveapprovals.

Синтаксис

В командной строке %drive%\Program Files\Update Services\Tools> введите:

wsusutil listinactiveapprovals

Удалить неактивные одобрения

Сценарий, в котором вы будете использовать эту команду, аналогичен сценарию, описанному для listinactiveapprovals. Однако при использовании listinactiveapprovals для перечисления неактивных утверждений на родительском вышестоящем сервере вы используете removeinactiveapprovals для их удаления. Вам не нужно запускать команду listinactiveapprovals перед выполнением этой команды.

Синтаксис

В командной строке %drive%\Program Files\Update Services\Tools> введите:

Для начала мы хотели бы извиниться за то, что вы читаете этот документ вместо того, чтобы хорошо провести время, используя встроенный терминал в Visual Studio Code. Команда VS Code усердно работает над тем, чтобы сделать работу с терминалом максимально удобной, но в некоторых случаях возникают проблемы с оболочкой или конфигурациями терминала, с которыми редактор VS Code не может справиться.

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

Руководство пользователя встроенного терминала

Если вы новичок в использовании интегрированного терминала VS Code, вы можете узнать больше в руководстве пользователя встроенного терминала. Там вы можете прочитать, как настроить терминал, а также ознакомиться с ответами на распространенные вопросы.

Ниже приведены конкретные шаги по устранению неполадок, если руководство пользователя не помогло вам диагностировать сбой при запуске. Шаги по устранению неполадок, такие как проверка настроек и включение ведения журнала, применимы ко всем платформам, поддерживающим VS Code; macOS, Linux и Windows.

Примечание. Если вы работаете в Windows, вы можете сначала просмотреть общие проблемы в разделе Windows.

Этапы устранения неполадок

Чтобы устранить сбои при запуске встроенного терминала в Visual Studio Code, выполните следующие действия для диагностики проблем:

Проверьте настройки пользователя. Просмотрите эти параметры terminal.integrated, которые могут повлиять на запуск:

терминал.интегрированная.оболочка. - Путь к оболочке, которую использует терминал.
terminal.integrated.shellArgs. - Аргументы командной строки при запуске процесса оболочки.
terminal.integrated.cwd — текущий рабочий каталог (cwd) для процесса оболочки.
terminal.integrated.env. - Переменные среды, которые будут добавлены в процесс оболочки.
terminal.integrated.inheritEnv — должны ли новые оболочки наследовать свою среду от VS Code.
terminal.integrated.automationShell. - Путь оболочки для использования терминала, связанного с автоматизацией, например задач и отладки.
terminal.integrated.splitCwd — управляет текущим рабочим каталогом, с которого начинается разделенный терминал.
терминал.интегрированный.windowsEnableConpty — использовать ли ConPTY для связи с терминальным процессом Windows.

Вы можете просмотреть настройки в редакторе настроек (Файл > Настройки > Настройки) и выполнить поиск конкретных настроек по идентификатору настройки.

Быстрый способ проверить, не изменились ли вы настройки, о которых вы могли не знать, — использовать фильтр @modified в редакторе настроек.

Большинство настроек интегрированного терминала необходимо изменить непосредственно в JSON-файле user settings.json. Вы можете открыть settings.json с помощью ссылки Edit in settings.json в редакторе настроек или с помощью команды Preferences: Open Settings (JSON) из палитры команд ( ⇧⌘P (Windows, Linux Ctrl+Shift+P )).< /p>

Протестируйте свою оболочку напрямую. Попробуйте запустить назначенную интегрированную оболочку терминала вне VS Code из внешнего терминала или командной строки. Некоторые сбои при запуске терминала могут быть связаны с установкой вашей оболочки и не относятся к VS Code. Отображаемые коды выхода поступают из оболочки, и вы можете диагностировать проблемы с оболочкой, выполнив поиск в Интернете конкретной оболочки и кода выхода.

Используйте самую последнюю версию VS Code. Каждый ежемесячный выпуск VS Code содержит множество обновлений и исправлений и может включать встроенные улучшения терминала. Вы можете проверить свою версию VS Code через Help > About (в macOS Code > About Visual Studio Code). Чтобы найти последнюю версию VS Code, перейдите к примечаниям к выпуску VS Code. Вы также можете проверить, установлена ли у вас последняя версия оболочки.

Используйте самую последнюю версию оболочки. Если ваша оболочка установлена отдельно от вашей платформы, попробуйте установить последнюю доступную версию оболочки. Тот же совет применим, если вы используете более старую сборку операционной системы. Например, некоторые старые версии Windows 10 плохо работали с терминалом VS Code.

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

Дополнительные шаги по устранению неполадок

Если ни один из этих шагов не помог решить проблему, вы также можете попробовать:

Спросите об этом в Stack Overflow. Зачастую проблемы с запуском связаны с настройкой среды, а не с VS Code.
Если терминал запускается из расширения, сообщите о проблеме расширению, открыв средство создания отчетов о проблемах (Справка > Сообщить о проблеме) и задав для параметра File On = "Расширение"
Если вы считаете, что это ошибка в VS Code, сообщите о проблеме с помощью средства создания отчетов о проблемах (Справка > Сообщить о проблеме). Репортер о проблемах автоматически заполнит соответствующую информацию. Дополнительные сведения о том, что включить в отчет, см. в разделе Создание отличных проблем терминала.
Если вы используете Windows 10 1809 (сборка 17763) или более ранней версии, проблема связана с устаревшей серверной частью winpty. При обновлении до Windows 1903 (сборка 18362) вы перейдете на новую серверную часть conpty, созданную Microsoft, и это может решить вашу проблему.

Коды выхода

Коды выхода, отображаемые в уведомлении об ошибке запуска терминала, возвращаются из процесса оболочки и не генерируются VS Code. Существует множество доступных оболочек, которые можно использовать в терминале, и сотни возможных кодов выхода.

Распространенные проблемы в Windows

Убедитесь, что режим совместимости отключен

При обновлении до Windows 10 для некоторых приложений режим совместимости может включаться автоматически. Когда это происходит с VS Code, терминал ломается, поскольку он выполняет некоторые действия низкого уровня, чтобы включить эмуляцию, которую он использует. Вы можете проверить и отключить режим совместимости, щелкнув правой кнопкой мыши исполняемый файл VS Code и выбрав свойства, а затем снимите флажок «Выполнить эту программу в режиме совместимости» на вкладке совместимости.

Терминал завершил работу с кодом 1 в Windows 10 (с WSL в качестве оболочки по умолчанию)

Это может произойти, если для подсистемы Windows для Linux (WSL) не настроен допустимый дистрибутив Linux по умолчанию.

Примечание. "docker-desktop-data" не является допустимым дистрибутивом.

Откройте PowerShell и введите wslconfig.exe /l, чтобы убедиться, что WSL установлен правильно, и перечислите доступные в настоящее время дистрибутивы Linux в вашей системе. Убедитесь, что рядом с действительным дистрибутивом стоит (по умолчанию).
Чтобы изменить дистрибутив по умолчанию, введите wslconfig.exe /setdefault "distributionNameAsShownInList"

Терминал не работает при запуске 32-битного клиента Windows в 64-битной Windows?

Эту проблему легко решить, используя 64-разрядную версию. Если вы должны использовать 32-разрядную версию, вам нужно использовать путь sysnative при настройке пути оболочки вместо System32. Добавление этого параметра должно решить проблему:

Произошло собственное исключение

Обычно эта ошибка возникает из-за того, что антивирусное программное обеспечение перехватывает и блокирует создание терминального процесса компонентами winpty/conpty. Чтобы обойти эту ошибку, вы можете исключить из антивирусной проверки следующий файл:

Сообщение об этой проблеме команде антивирусного ПО также может помочь полностью устранить проблему.

Общие. Убедитесь, что вы используете последнюю версию интерфейса командной строки AWS.

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

То, как вы обновляете свою версию интерфейса командной строки AWS, зависит от того, как вы ее изначально установили, как описано в разделе Установка или обновление последней версии интерфейса командной строки AWS.

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

Общие: используйте параметр --debug.

Первое, что вы должны сделать, когда интерфейс командной строки AWS сообщает об ошибке, которую вы не сразу понимаете, или выдает результаты, которых вы не ожидаете, — получить более подробную информацию об ошибке. Вы можете сделать это, снова запустив команду и включив параметр --debug в конце командной строки. Это приводит к тому, что интерфейс командной строки AWS сообщает подробности о каждом шаге, необходимом для обработки вашей команды, отправки запроса на серверы AWS, получения ответа и обработки ответа в отображаемый результат. Подробности в выходных данных могут помочь вам определить, на каком этапе возникает ошибка, и получить контекст, который может дать подсказки о том, что ее вызвало.

Вы можете отправить результат в текстовый файл, чтобы записать его для последующего просмотра или отправить в службу поддержки AWS по запросу.

Вот пример запуска команды с параметром --debug и без него.

При включении параметра --debug детали включают (помимо прочего):

Поиск учетных данных

Анализ предоставленных параметров

Создание запроса, отправляемого на серверы AWS

Содержимое запроса, отправленного в AWS

Содержимое необработанного ответа

Отформатированный вывод

Я получаю сообщение об ошибке "команда не найдена" при запуске aws.

Возможная причина: "путь" операционной системы не был обновлен во время установки.

Эта ошибка означает, что операционной системе не удается найти программу AWS CLI. Установка может быть неполной.

Если вы используете pip для установки интерфейса командной строки AWS, вам может потребоваться добавить папку, содержащую программу aws, в переменную среды PATH вашей операционной системы или изменить ее режим, чтобы сделать ее исполняемой.

Возможно, вам потребуется добавить исполняемый файл aws в переменную среды PATH вашей операционной системы. Выполните шаги соответствующей процедуры в разделе Начало работы с интерфейсом командной строки AWS.

Я получаю сообщение об ошибке "отказано в доступе".

Возможная причина: программный файл AWS CLI не имеет разрешения на «запуск».

В Linux или macOS убедитесь, что у программы aws есть разрешения на запуск для вызывающего пользователя. Обычно разрешения устанавливаются на 755 .

Чтобы добавить разрешение на запуск для вашего пользователя, выполните следующую команду, заменив ~/.local/bin/aws на путь к программе на вашем компьютере.

Возможная причина: ваше удостоверение IAM не имеет разрешения на выполнение операции.

Когда вы запускаете команду AWS CLI, операции AWS выполняются от вашего имени с использованием учетных данных, связывающих вас с пользователем или ролью IAM. Политики, связанные с этим пользователем или ролью IAM, должны предоставлять вам разрешение на вызов действий API, соответствующих командам, которые вы запускаете с помощью интерфейса командной строки AWS.

Большинство команд вызывают одно действие с именем, совпадающим с именем команды. Однако пользовательские команды, такие как синхронизация aws s3, вызывают несколько API. Вы можете увидеть, какие API вызывает команда, используя параметр --debug.

Если вы уверены, что у пользователя или роли есть надлежащие разрешения, назначенные политикой, убедитесь, что ваша команда AWS CLI использует ожидаемые учетные данные. См. следующий раздел об учетных данных, чтобы убедиться, что AWS CLI использует именно те учетные данные, которые вы ожидаете.

Информацию о назначении разрешений пользователям и ролям IAM см. в разделе Обзор управления доступом: разрешения и политики в Руководстве пользователя IAM.

Я получаю сообщение об ошибке "неверные учетные данные".

Возможная причина: интерфейс командной строки AWS считывает учетные данные из неожиданного места.

CLI AWS может считывать учетные данные из другого места, чем вы ожидаете. Вы можете запустить список настроек aws, чтобы подтвердить, какие учетные данные используются.

В следующем примере показано, как проверить учетные данные, используемые для профиля по умолчанию.

В следующем примере показано, как проверить учетные данные именованного профиля.

Возможная причина: часы вашего компьютера не синхронизированы.

Если вы используете действительные учетные данные, ваши часы могут быть не синхронизированы. В Linux или macOS запустите дату, чтобы проверить время.

Если ваши системные часы не верны в течение нескольких минут, используйте ntpd для синхронизации.

В Windows используйте параметры даты и времени на панели управления для настройки системных часов.

Я получаю сообщение об ошибке "подпись не соответствует" (SignatureDoesNotMatch).

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

Возможная причина: ваши часы не синхронизированы с серверами AWS.

В Linux или macOS запустите дату, чтобы проверить время.

Если ваши системные часы не верны в течение нескольких минут, используйте ntpd для синхронизации.

В Windows используйте параметры даты и времени на панели управления для настройки системных часов.

Возможная причина: ваша операционная система неправильно обрабатывает секретные ключи AWS, содержащие определенные специальные символы.

Если ваш секретный ключ AWS содержит определенные специальные символы, такие как - , + , / или % , некоторые варианты операционной системы неправильно обрабатывают строку и вызывают неправильную интерпретацию строки секретного ключа.

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

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

Я получаю сообщение "Консоль Windows не найдена. Вы используете cmd.exe?" ошибка.

При использовании команды AWS CLI вы получаете сообщение «Консоль Windows не найдена. Вы используете cmd.exe?» сообщение об ошибке. Обычно это происходит из-за того, что установленный вами Python prompt_toolkit устарел. Чтобы решить эту проблему, установите последнюю версию prompt_toolkit на веб-сайте Python.

Я получаю сообщение об ошибке "[SSL: CERTIFICATE_ VERIFY_FAILED] проверка сертификата не удалась".

При использовании команды AWS CLI вы получаете сообщение об ошибке «[SSL: CERTIFICATE_ VERIFY_FAILED] не удалось проверить сертификат». Это вызвано тем, что интерфейс командной строки AWS не доверяет сертификату вашего прокси-сервера из-за таких факторов, как самоподписанный сертификат вашего прокси-сервера, а ваша компания указана в качестве центра сертификации (ЦС). Это не позволяет интерфейсу командной строки AWS найти корневой сертификат ЦС вашей компании в локальном реестре ЦС.

Чтобы исправить это, укажите интерфейсу командной строки AWS, где найти файл .pem вашей компании, используя параметр файла конфигурации ca_bundle, параметр командной строки --ca-bundle или переменную среды AWS_CA_Bundle.

Дополнительные ресурсы

Чтобы получить дополнительную помощь по своим проблемам с AWS CLI, посетите сообщество AWS CLI на GitHub.

Читайте также: