Предоставление нативного инструмента с сохранением максимальной переносимости

В манифесте Twelve-Factor App говорится, что именно веб-приложения "... имеют четкий контракт с базовая операционная система, предлагающая максимальную переносимость между средами выполнения" [курсив добавлен мной]

Но затем он говорит:

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

и они ранее определили «поставщик в приложение» как:

в каталоге, содержащем приложение (известном как «поставщик» или «пакет»).

Как это сделать, если (по крайней мере, в Linux) собственные 64-битные исполняемые файлы не запускаются, например, в 32-битных средах, не говоря уже о других операционных системах? Или есть лучший способ решить эту проблему переносимости?


dependencies 12factor native-code
person Robin Green    schedule 04.06.2012    source источник
comment
Кроме того, они, похоже, не рассматривали возможность того, что вы можете разрабатывать для Windows и хотите использовать системный инструмент. Лицензионное соглашение Windows запрещает торговлю, как и многие другие лицензионные соглашения!   -  person Robin Green    schedule 12.06.2012

Ответы (2)


arrow_upward
3
arrow_downward

На мой взгляд, это вообще не нужно делать. Это потому что:

  • Если встроенные исполняемые файлы динамически связаны, есть вероятность, что они не смогут работать только в будущих выпусках ОС, не говоря уже о будущих или прошлых архитектурах процессоров.
  • Насколько я понимаю, невозможно полностью защитить нативный исполняемый файл от будущего путем его статической компоновки. У вас все еще могут быть проблемы. Solaris даже не поддерживает статическое связывание системных библиотек!
  • Библиотечные зависимости — не единственный вид зависимостей, которые могут иметь собственные инструменты. Могут быть и другие проблемы.
  • Старые ImageMagick или даже curl могут иметь ошибки безопасности, которые могут позволить скомпрометировать ваше приложение. (Это немного спорный момент — его достоверность зависит от того, кому вы больше доверяете в отслеживании/применении обновлений безопасности — людям, которые обслуживают и обновляют серверы, или разработчикам? Конечно, это могут быть одни и те же люди — пока , Но мое рабочее предположение заключается в том, что в конечном итоге к серверам будут применяться обновления, что, в свою очередь, защитит ваше приложение от дыр в безопасности в исполняемых файлах системы, которые были исправлены в обновлениях.)

Мое мнение: если выбранная вами система управления зависимостями просто в упор не может обрабатывать собственные исполняемые файлы, вставьте примечание в README и покончите с этим. Если у вас нет файла README, создайте его. И (для внутренних веб-приложений) добавьте необходимые собственные инструменты в свой стандартный образ сервера или скрипт, который вы используете при настройке сервера, и убедитесь, что у вас есть дополнительные примечания о для чего они нужны.

person Robin Green    schedule 04.06.2012

arrow_upward
0
arrow_downward

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

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

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

person willoller    schedule 21.01.2014