I have a React app created via create-react-app that is my portfolio. It's standard out-of-the-box (not ejected). In the public folder, there are a bunch of my portfolio pieces (interactive websites). Some of the pieces are MASSIVE, so it's not a huge surprise that Heroku chokes (but it never did before this year?).
It looks like the project is building fine, and then I get:
Compiled slug size: 945.3M is too large (max is 500M).
Followed by:
! [remote rejected] master -> master (pre-receive hook declined)
error: failed to push some refs to
'https://git.heroku.com/some-project.git'
A portfolio site isn't going to be much good without portfolio pieces, so I'd like find out what I can do about this. Am I going to have to put my pieces up on a different server, or what?
You can create a Docker image of your app and deploy it on Heroku. AFAIK, Docker images don't have any size limit on Heroku. I have deployed images having a size of around 1.5 GB on Free dyno. This might help: Deploying with Docker
Related
I have a node project deployed in a Heroku server. I have a CDN folder in the project directory that requires file changes and new pushes almost every day. Because my CDN folder holds some static resources which I build locally and then push to Heroku. Now my issue is every time I push to Heroku a new build gets started on the server. But this is not necessary for me as I am just modifying some static contents in my CDN folder. No files related to the server are being changed. Can I any way turn off that automatic building on every push to the Heroku repo? Help me guys...
I followed the documentation here https://devcenter.heroku.com/articles/pipelines and setup a pipeline with two stages:
The above link only talks about how to promote an app, without specifying how to deploy, this section specifically (we can read beyond this point and see there is no instruction on how to deploy):
Pipelines let you define how your deployed code flows from one
environment to the next. For example, you can deploy code to your
staging app (which builds it into a slug) and later promote that same
slug to production. This promotion flow ensures that production
contains the exact same code that you tested in staging, and it’s also
much faster than rebuilding the slug.
So I used the same command we use for deploying non-pipeline based apps (as instructed here):
docker push registry.heroku.com/ultimate-hello-world-cra-stage/web
This appears to be a wrong approach. You can see in snapshot above that STAGING app did get deployed, but when I try to promote the app using this command heroku pipelines:promote --app ultimate-hello-world-cra-stage, I get this error: Error: Pipeline promotions are not supported on apps pushed via Heroku.
What is the correct way to deploy to a pipeline and where can I find it in the docs?
Is it possible, and if so, how? I'd like to be able to reach it from my existing Heroku infrastructure.
Will I need a Procfile? From what I understand it's just a standalone binary written in Go! so it shouldn't be that hard to deploy it, I'm just curious how to deploy it because I don't think I understand the ins and outs of Heroku deployment.
Heroku Dynos should not be used to deploy a database application like InfluxDB.
Dynos are ephemeral servers. Data does not persist between dyno restarts and cannot be shared with other dynos. Practically speaking, any database application deployed on a dyno is essentially useless. This is why databases on Heroku (e.g. Postgres) are all Add-ons. InfluxDB should be set up on a different platform (like, AWS EC2 or a VPS) since a Heroku Add-on is not available.
That said, it is possible to deploy InfluxDB to a Heroku dyno.
To get started, it is important to understand the concept of a 'slug'. Slugs are containers (similar to a Docker images) which hold everything needed to run a program on Heroku's infrastructure. To deploy InfluxDB, an InfluxDB slug needs to be created.* There are two ways to create a slug for Go libraries:
Create a slug directly from a Go executable as described here.**
Build the slug from source using the Heroku Go buildpack (explained below).
To build the slug from source using a buildpack, first clone the InfluxDB Github repo. Then add a Procfile at the root of the repo, which tells Heroku the command to run when the dyno starts up.
echo 'web: ./influxd' > Procfile
The Go buildpack requires all dependencies be included in the directory. Use the godep dependency tool to vendor all dependencies into the directory.
go get github.com/tools/godep
godep save
Next, commit the changes made above to the git repo.
git add -A .
git commit -m dependencies
Finally, create a new app and tell it to compile with the Go buildpack.
heroku create -b https://github.com/kr/heroku-buildpack-go.git
git push heroku master
heroku open // Open the newly created InfluxDB instance in the browser.
Heroku will show an error page. An error will be displayed because Heroku's 'web' process type requires an app to listen for incoming requests on the port described by the $PORT environment variable, otherwise it will kill the dyno. InfluxDB's API and admin panel run on ports 8086 and 8083, respectively.
Unfortunately, InfluxDB does not allow those ports to be set from environment variables, only through the config file (/etc/config.toml). A small bash script executed before InfluxDB starts up could set the correct port in the config file before InfluxDB starts up.
Another problem, Heroku only exposes one port per dyno so the API and the admin panel cannot be exposed to the internet at the same time. A smart reverse proxy could work around that issue using Heroku's X-Forwarded-Port request header.
Bottom line, do not use Heroku dynos to run InfluxDB.
* This means the benefits of a standalone Go executable are lost when deploying to Heroku, since it needs to be recompiled for Heroku's stack.
** Creating a slug directly from the InfluxDB executable does not work because there is no built-in way to listen to the right port given by Heroku in the $PORT environment variable.
I like to think anything is possible on a Heroku node when using a custom buildpack, but there are some considerations when hosting with Heroku:
ops, e.g. backup, monitoring (does it entail installing extra services, opening extra ports, etc - Heroku might get in the way here)
performance, considering dyno size
and if you need a larger dyno, cost becomes an issue. You'll get more bang for your buck when you go the IaaS route.
other "features" of a dyno, e.g. disk ephemerality
I highly recommend hosted InfluxDB or spinning up your own on a VPS, all of which you can point your existing Heroku-based apps to. It will then help to get those instances as close together as possible (i.e. same region, or co-located if possible), presuming a need for low latency between DB and app stack.
I'm trying to setup my app to serve assets over the Amazon S3/Cloudfront CDN. Its a rails app and I use the asset_sync gem to achieve this as per this heroku document.
I push my project up to heroku, and then afterwards run a heroku run rake assets:precompile. This gives me output that looks like this:
I, [2013-09-20T21:19:06.506796 #2] INFO -- : Writing /app/public/assets/application-cb6347d3ce9380e02c37364b541fd8ae.js
I, [2013-09-20T21:19:19.979570 #2] INFO -- : Writing /app/public/assets/application-9dc3068c1bf9290c7eb0493fd36b3587.css
[WARNING] fog: followed redirect to abc123.s3-us-west-1.amazonaws.com, connecting to the matching region will be more performant
[WARNING] fog: followed redirect to abc123.s3-us-west-1.amazonaws.com, connecting to the matching region will be more performant
Take note that the hash it writes for the JS file cb6347d3ce9380e02c37364b541fd8ae.js is correct (as I also ran this in staging under my localhost).
The problem though, is that when I hit my app on heroku and inspect the source, the JS that it is including 50460076f4c6eb614a44b6b17323efa7.js is different than the one that was compiled earlier...
Why isn't heroku picking up the right precompiled asset to use? I deployed locally and did all the same steps, my local server picks up the correct JS with no problem.
Thanks for your help!
After some time, I realized that this was because previously I had compiled assets locally and pushed it up. Because of this, Heroku didn't try to precompile in production and just used the old manifest.json that was previously checked in.
You can either recompile locally and push it up, or run rake assets:clobber to delete all precompiled assets, then commit/push and heroku will realize that it needs to precompile. Afterwards, it should be using the correct manifest file and assets should show as normal.
I found this blog post really useful in understanding the situation: http://www.rubycoloredglasses.com/2013/08/precompiling-rails4-assets-when-deploying-to-heroku/
I just followed the steps to migrate my very small shared db to Heroku's new "dev" plan. Everything went very smoothly until I tried $ heroku addons:remove shared-database
I received the following error:
$ heroku addons:remove shared-database
-----> Removing shared-database from [my_app]... failed
! Shared databases cannot be removed
I have confirmed that my DATABASE_URL matches my HEROKU_POSTGRESQL_[COLOR]_URL, and that my app is fully functioning.
I work at Heroku on the Data team. We're sorry about that: the problem you observed was a temporary problem on our end, not a problem with your code. Please try again, it was an issue on the bamboo stack specifically.
As an aside, consider using the cedar stack. :)