Героку и разбухание
Я начинаю удариться о стену с помощью своего приложения Heroku.
Мне хорошо знакомы с обычными проблемами с размером пули, re: изображениями, PDF файлами и другими материалами, но моя проблема, вероятно, будет связана с другими активами, привезенными с помощью беседки или, возможно, создания пакетов.
https://devcenter.heroku.com/articles/slug-compiler
Размер Heroku Slug после нескольких развертываний
My Heroku починил слизню, выглядит так:
$ du -h --max-depth=1
4.0K ./.bower-tmp
30M ./tmp
24K ./features
236K ./config
195M ./public
4.0K ./log
34M ./bin
792K ./db
355M ./vendor
8.0K ./.heroku
22M ./app
64K ./lib
8.0K ./.bundle
136K ./.bower-registry
22M ./.bower-cache
24M ./node_modules
12K ./.profile.d
На сегодняшний день самым большим является Vendor (355M), но моя локальная папка поставщика на самом деле пуста, как и публика (195M).
Но на героку это выглядит так:
40M vendor/ruby-2.0.0
21M vendor/node
32K vendor/heroku
12K vendor/assets
103M vendor/jvm
192M vendor/bundle
195M public/assets (bower bloat?)
Я предполагаю, что это один из нескольких сборных пакетов для бесед и для генерации PDF.
https://github.com/heroku/heroku-buildpack-nodejs
https://github.com/heroku/heroku-buildpack-ruby
https://github.com/razorfly/wkhtmltopdf-buildpack
Мое приложение само по себе выглядит скудным на 22М, но мой текущий герою SLUG составляет 298,4 МБ! и только каталог поставщика больше, чем в соответствии с du
, не следует ли использовать эти сборные пакеты и вместо этого переносить на компиляцию активов на моей локальной машине между сборками? Я не уверен, какая хорошая стратегия развертывания (/slug diet) должна выглядеть, любые идеи были бы оценены.
UPDATE:
Я также попытался восстановить пул из того, что я читал, работал для других, но не имел никакого эффекта. Размер сгустка после компиляции остался прежним.
heroku plugins:install https://github.com/heroku/heroku-repo.git
heroku repo:rebuild -a appname
GIST сборки: https://gist.github.com/holden/b4721fc798bdaddf52c6
ОБНОВЛЕНИЕ 2 (после отличной идеи, представленной drorb)
12K ./.profile.d
21M ./app
4.0K ./log
812K ./db
8.0K ./.heroku
236K ./config
195M ./public
19M ./.bower-cache
60K ./lib
253M ./vendor
4.0K ./.bower-tmp
128K ./.bower-registry
34M ./bin
30M ./tmp
24M ./node_modules
24K ./features
8.0K ./.bundle
Vendor
12K vendor/assets
193M vendor/bundle
21M vendor/node
32K vendor/heroku
40M vendor/ruby-2.0.0
Public/Assets (очень длинный)
https://gist.github.com/holden/ee67918c79dd3d197a6b
Ответы
Ответ 1
Размер vendor/jvm
равен 103M. Поскольку вы не используете JRuby, единственная причина, по которой я мог бы найти, что он использует жемчужину yui-compressor. Глядя на heroku-buildpack-ruby, похоже, что JVM установлен в этом случае:
def post_bundler
if bundler.has_gem?('yui-compressor') && !ruby_version.jruby?
install_jvm(true)
ENV["PATH"] += ":bin"
end
end
Если вы можете избежать использования yui-компрессора, вы должны иметь возможность сохранить 103M на вашем размере слизи.
Ответ 2
FWIW, мы удалили Bower из нашего приложения и заменили его на Rails Assets. Мы пришли к выводу, что использование Bower в Rails-приложении было несколько бессмысленным, поскольку Bundler по существу выполняет ту же функцию.
Ответ 3
Часть проблемы может указывать на Git repos в вашем Gemfile. В какой-то момент мне нужно было указать на фиксацию Rails, которая не была выпущена, и она добавилa > 100 МБ к моему размеру пули, указав на выпущенную версию.