2016-07-21 4 views
0

В 3 из моих 6 пространств CloudFoundry из Swisscom я получаю следующую ошибку при развертывании с тем же (обычным) buildpack.

Starting app my-app-name in org my-org/    space my-space as [email protected] 
Creating container 
Successfully created container 
Downloading app package... 
Downloaded app package (26M) 
Staging... 
exec: "git": executable file not found in $PATH 
Exit status 1 
Staging failed: Exited with status 1 

FAILED 
StagingError 

Я использую следующий buildpack в manifest.yml:

--- 
buildpack: https://github.com/shiftcode/java-buildpack-mongodb 
domain: scapp.io 
path: target/my-app-name.zip 
disk_quota: 1024M 
domains: 
    - scapp.io 
services: 
- my-service-one 
- my-service-two 
... 

env: 
    JBP_CONFIG_OPEN_JDK_JRE : '[jre: {version: 1.8.0_+}, memory_calculator: {memory_heuristics: {heap: 35, metaspace: 30, stack: 5, native: 30}}]' 
    MONGO_DB_VERSION : '3.2.0' 
    MONGODB_CMD_PATH : '.mongo/bin/' 
    MONGODB_MAX_POOLSIZE : '1' 
    MALLOC_ARENA_MAX : '2' 
    MALLOC_MMAP_THRESHOLD_ : '131072' 
    MALLOC_TRIM_THRESHOLD_ : '131072' 
    MALLOC_TOP_PAD_ : '131072' 
    MALLOC_MMAP_MAX_ : '65536' 

# app specific configuration 
applications: 
- name: my-app-name-development 
    memory: 512M 
    instances: 2 
    host: my-app-name-development 

- name: my-app-name-staging 
    memory: 512M 
    instances: 2 
    host: my-app-name-staging 

Это buildpack расширяет обычный Java-buildpack путем добавления установки MongoDB (мы используем mongodump команду для резервного копирования). Тот же buildpack с одним и тем же кодом и теми же параметрами manifest.yml работает на некоторых пространствах, но не на других. Я попытался удалить приложение, прежде чем снова нажать его без успеха. У меня есть доступ к ssh (diego) во всех пространствах и приложениях.

Любые идеи о том, почему исполняемый файл git недоступен во время постановки и как исправить это или устранить его? Я хотел бы избежать хлопот (и стоимости) удаления пробелов и их воссоздания.

+0

отредактируйте вашу публикацию с помощью используемого вами 'Manifest.yml'. Кажется, что Cloud Foundry думает, что вы используете GO buildpack вместо Java buildpack. Также в портале разработчиков он отображает логотип GO.Ошибка 'exec:" git ": исполняемый файл, не найденный в $ PATH', поступает из GO buildpack. –

+0

Я обновил manifest.yml. Но даже если cloudfoundry думает, что я использую GO buildpacks, как может быть, что то же самое работает на других пространствах? То же самое происходит в «плохих» пространствах, когда я использую сборку сборки из 'https: // github.com/cloudfoundry/java-buildpack' или предоставленного' java_buildpack', что приводит к 'exec:" tar ": исполняемый файл не найденный в $ PATH'. –

ответ

2

Это проблема с технологией контейнеризации садово-runc в Cloud Foundry версии 0.7.0 и ранее. Как предположил принятый ответ, если переменная env содержала строку «PATH», в Garden появляется ошибка, которая неправильно устанавливает PATH.

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

https://www.pivotaltracker.com/story/show/129773615

и коммят, который устраняет эту проблему здесь:

https://github.com/cloudfoundry/guardian/commit/e191b2ca8365f44c812cb8feb70c722391886063

Обойти этот вопрос должен установить другой переменный ENV для ваше приложение:

PATH: /usr/local/bin:/usr/bin:/bin

0

После того, как много разворачивались переменные env, я узнал, что проблема связана с переменной env MONGODB_CMD_PATH от моего manifest.yml. Кажется, что любая переменная env, заканчивающаяся на PATH, влияет/переопределяет значение $PATH env, что приводит к сбою процесса промежуточного этапа, поскольку требуемые исполняемые файлы больше не находятся на системном пути.

0

У меня была такая же проблема, и принятый ответ сработал для меня. В интересах гуглеров:

Я установил переменную PYTHONPATH в свой манифест. CloudFoundry правильно установил env var PYTHONPATH, но он также использовал его для перезаписи переменной PATH. Обходным пути для меня было установить PYTHONPATH на $PATH:/my/python/path. Хотя это добавляет посторонние каталоги как к PATH, так и кPYTHONPATH, он функционирует должным образом.