[MUSIC] The next step is for us to create a Heroku application. Now, our application is Prometheus, we should name our application with our username followed by the dash prompt so that we know it's the Prometheus application on Heroku. So Heroku create will help us do that. Now I'm going to use the help documentation to see if we can specifically give it a particular name. And we'll call it heroku just like it says there, apps:create and then the name. So for us, my username is wenlockca-prom for the Prometheus app. And we don't need any special build packs or anything like that, so let's go ahead and create that application. Great, I now have an application that's mapped to our source code repository, and we should be able to see new git remote called Heroku has been configured to the source code repository on Heroku for our local repository. The dashboard should also show us a new application for that, and that's in the wenlockca-prom. Now, for deploying this application, we're going to use a container deployment. So if we click on the container deployment instructions here, give that just a second. We should be able to see the instructions on how that's going to work. Now, locally we have a script called publish and if we look at that script, it's basically going to verify that we're logged in to the container registry. And running this command is going to configure our Heroku application to accept containers as push targets. And then we have a container that we've already created. So we'll run a container push command here and what will be done is that the Heroku client will look for a dockerfile and build that dockerfile and then push that client to an application called web. And then finally, once the container is pushed up to the Heroku registry, we'll run a release command. And the release command will basically enable Heroku to start running that docker container on Heroku. Now, those are the same instructions that are published here. So we'll skip that section for now. But before we run this application, we do need to set some configuration values for our Probot app. So if we remember it correctly our Probot app was named our user id, and actually the probot app URL, there's actually an easier way to get this, is to go look at the actual Probot app. So I called it probot-wenlockca And if we click on Settings and scroll down, So let's just scroll down a little. Slight scrolling issue. Let me refresh this page. There we go, there's my scroll bar. It will be right down here. Your app can be found at this URL. So let's highlight that URL and then if we go back to our command line and we type the command Heroku config:set, that set say configuration setting on our Heroku app. And we use the configuration value called PROBOT_HOST and then we set this value to the host name, not the URL but the host name of our application. Then this configures Prometheus, the configuration file in Prometheus to use this Probot variable for our application so that Prometheus will know where to go to scrape the metrics for our Probot app. So you can actually see that configuration in the configuration directory, under config. And it's very simple, it's one scraper with the target of PROBOT_HOST. Now Prometheus doesn't automatically provide this environment variable substitution capability. This is something that we built into the entry script, as so if we look at the source entry script. You'll notice that there is a simple set command that will search for that PROBOT_HOST environment variable and replace it with the configured value of the docker container when the Prometheus server is stood up. So this is just a little magic that's happening here under the covers because of the docker container and the Heroku orchestration that we're doing for this Prometheus app. So it's good to be aware of that during the publishing phase. Now, let's run the script publish, script which as a reminder runs the Heroku container login, then it builds the container so that you can push this container to our Heroku registry. So you can actually see that it's pushing that Heroku container with the Prometheus docker container to our Heroku Application, and this will take just a few seconds. And then ones the Heroku container is actually published, then the Heroku release command or a container release command will make that or will attempt to run that Heroku docker container and start that application up. And we'll be able to look at it and make sure that it's up and running. So this will just take a few seconds here. So we can see that the image was released with the container release command and was successfully published. Now, just as a fun exercise you may think of some additional ways that you can publish this with your tavis.yamel file and you can always fork this repo and do that. So I welcome you to go do that as an exercise. So let's go back to Heroku and let's take a look at how it's going, that icon has now turned purple that's great. And under the settings tab, we should have a URL for our Prometheus wenlockca-prom URL. So if we click on that, there's Prometheus, it's up an running. There's not very many metrics here yet because we haven't configured Prometheus to scrape our Probot application, but that will come up soon. You can see the up-time metric now, and the up-time metric will give us information about the up-time of Prometheus, so we should get a solid answer here. Actually no, it's doing the up-time of our Probot app. So because the scraper is actually trying to scrape a URL that's not up and running, it's saying that our Probot application is not up and running. But once we configure the scraper or Probot to provide the metrics back, then Prometheus will quickly see that this application is up and running. But the good news here is that it's at least monitoring the Probot URL that we provided so that it can begin to try to capture that data. Now just a word of caution, if our application shuts down, Heroku free applications shut down every, I believe, 30 minutes. If they do shut down, we lose all our data. So because this is a classic size, this is really great for the exercise. However, for production environments, that could be really bad if you're losing your data all the time, because it can be very difficult to kind of aggregate data over a large period of time. But for this exercise, we won't need that. I did add some ping timers to give us some extended time, I'm estimating about 14 days, and that will use up all of your free credits in your Heroku or console. If you don't want that, I'll show you a little later on how to configure it so that it doesn't do that.
