Is there a way to forward traffic from an old heroku app hosted on their (no longer supported) cedar-14 stack to the new version of the app (on heroku-18)? I can no longer build to the cedar-14 site. Both apps are using Heroku's default domains, [app name].herokuapp.com.
The goal is to keep the old code in case it is needed while directing people visiting the old domain access to the newly written site. This can be accomplished with carefully sequenced site name changes. Heroku describes how to change site names here. You will also have to update git remotes and such on your local machine but the Heroku instructions tell you how to do that, too.
The now somewhat obvious sequence is:
change name of [old site] to something like [old_site]-backup
change name of [new site] to [old site]
Related
I'm currently using Heroku Pipeline feature for automatically detecting, building and deploying pull requests for review.
✓ Create new review apps for new pull requests automatically
URL pattern
Pattern: Random pipeline-xxxxxx-xxxxxx.herokuapp.com
The problem is that my app needs a combination of 2 buildpacks in a specific order in order to boot properly.
The main/production app has this settings and it works fine(e.g. after each time a PR is merged).
From what I see Review Apps doesn't have a concept of buildpack settings and it tries to autodetect it each time.
What I've tried:
Open the latest Review App, set buildpacks, rebuild or push a new commit. It works fine in that Pull Request/branch/Review App but for each new PR this process has to be repeated manually.
Is there any way to overcome this issue?
In case you have a similar issue, one approach that you can use(that worked for me)
app.json Heroku's convention file where you can list your buildpacks among many other settings.
I am trying to get heroku setup locally on my new laptop to be able to access an existing heroku account that has two existing rails apps on it. I was able to install heroku cli locally and I was able to login to heroku. If I run "heroku apps" it lists my two apps. But two things I need help with:
1) I can't remember how to tell heroku which app the git repo in the current folder on my laptop should work with on heroku server. in other words, how do i "select" which app i want to current work with after logging into heroku.
2) when I tried running the "heroku config" command to list existing config vars after logging it it gave me some kind of error message. need some suggestions on what might be causing that too.
Sorry to not include screen shots of errors but on a different company right now. hopefully you can at least help me answer the first question.
Thanks,
Edward
ps. I found this Q&A, does the answer here apply to my question (1)?
How to link a folder with an existing Heroku app
The cause turned out to be that I needed to add the heroku app location as a remote repo using the heroku cli from within my local git repo I had created. I used the following command:
heroku git:remote -a thawing-inlet-61413
where "thawing-inlet-61413" is the name of the app. You can get this by running:
heroku apps
and it will list them.
reference: https://devcenter.heroku.com/articles/git#creating-a-heroku-remote
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.
It's a pretty simple problem. I need to get my heroku CLI app working with an app I have. I already have the git repo checked out (from github though, not sure if that matters).
A google search suggests this page is the place to go to get help, but the page doesn't tell me anything useful:
http://devcenter.heroku.com/articles/heroku-command
If you've already checked out the code all you need to need is setup a git remote pointing at heroku.
Locate your apps Gtit url - easiest place is from the 'My Apps' on Heroku in the 'Git Repo' panel, it will look something like git#heroku.com:stark-beach-5145.git
Back in your local git repo do (replacing with your app URL):
git remote add heroku git#heroku.com:stark-beach-5145.git
Now you will be able to perform git push heroku etc.
However, if you just want to use heroku commands as long as you explicitly pass in the application name you don't actually need to perform steps 1 and 2 above. eg
heroku ps --app <appname>
would show you the running processes for your application etc. Here appname is the name of the app as listed on the 'My Apps' page.
When I do
heroku create
then a remote is added with name heroku.
I want that name to be changed to "heroku1". Is it possible?
I know it might be a bad practice but we have a complicated situation.
Not bad practice at all - I very rarely even have heroku in there at all - it's just a name for how you want to refer to the remote. I typically use development or production.
To rename a remote is easy;
git remote rename heroku heroku1
You can specify the name of the remote as part of the heroku create command, as well:
heroku create --remote heroku1
There are other useful options as well, heroku help create for details.
I don't see why it's bad practice — the name should be whatever helps you (or any other developers on the project) understand the process. For example, one of my apps has two Heroku remotes, staging and heroku. The staging app lets us test things out and is just on the free service level, where the heroku app is the live user-facing site, and is scaled up appropriately.