Heroku docs Notes

Getting started with Python
* Heroku CLI - Heroku command line interface
	* we can use this tool to manage our apps, add add-ons, view logs, etc.
* prepare the app source code
* create an app in Heroku
* deploy the app
* The application is now deployed. We can ensure that at least one instance of the app is running with this command:
	heroku ps:scale web=1
* create a "Procfile" to explicitly declare what command should be executed to start your app
* scale the app
	* now, our app is running on as single web dyno
		* dyno - lightweight container that run the command specified in the Procfile
		* we can check how many dynos are running using this command:
			heroku ps
	* by default an app is deployed on a free dyno
		* free dynos sleep after a half hour of inactivity
		* they have delay of a few seconds for the first request upon waking
		* subsiquent requests will perform normally
		* they consume from a monthly, account-level quantity of free dyno hours
		* scaling an app on Heroku is equivalent to changing the number of dynos that are running
			* you can scale the number of web dynos to zero using this command:
				heroku ps:scale web=0
			* or scale the number of web dynos to one using the same command:
				heroku ps:scale web=1
* declare app dependencies
	* Heroku recognizes an app as a Pyhton app by existence of a Pipfile or requirements.txt in the root directory
		* Pipfile - lists the app dependencies with their versions
* provision add-ons
	* add-ons are third-party cloud services that provide additional services for your app
* start a console
	* you can run a command, typically scripts and applications that are part of your app in a one-off dyno using the "heroku run" command
* definde confing files
	* you can define config files using:
		heroku config:set VARIABLE=42
* provision a database
	* The add-on marketplace has a large number of data stores like: Redis, MongoDB, Postgres, MySQL, etc

How Heroku Works
* Defining app
	* dependency mechanisms vary across languages
		* Ruby - Gemfile
		* Python - requirements.txt
		* Node.js - package.json
		* Java - pom.xml
	* the source code and the dependency file for your app should provide enough info for the Heroku platform to build your app, to produce something that can be executed
* Knowing what to execute
	* for some apps you don't need to make many changes to an app in order to run it on Heroku
		* one requirement is informing the platform as to which parts of your app are runnable
		* if you use some established framework, Heroku can figure it out.
			* examples
				* Rails - rails server
				* Django - python <app>/manage.py runserver
				* Node.js - main field in package.json
	* for other apps you may need to explicitly declare what can be executed. You can do this in a text file that is in you source code - "Procfile"
		* example: https://devcenter.heroku.com/articles/how-heroku-works#knowing-what-to-execute
* Deploying Apps
	* Heroku platform uses Git
	* when you create an app in Heroku, it creates a new Git remote (by default named: "Heroku")
		* you can use this command to deploy your code:
			git push heroku master
* Building apps
	* when the Heroku platform receives the application source, it initiates a build of the source application.
	* the build mechanism is typically language specific, but follows the same pattern
		* retrieving the specified dependencies
		* create any necessary assets
			* examples
				* processing style sheets
				* compiling code
	* Advanced: buildpacks lie behind the "slug" compilation process
		* they take your app, it's dependencies, the language runtime, and produce "slugs"
		* they are open source
		* we can extend them to other languages and frameworks
		* slug - a bundle of:
			* your source
			* fetched dependencies
			* the language runtime
			* compiled/generated output of the build system - ready for execution
		* The slugs are a fundamental aspect of what happens during application execution
* Running applications on dynos
	* Heroku executes apps by running a command you specified in your Procfile, on a dyno that is preloaded with your prepared slug.
	* We can think of a running dyno as a lightweight, secure, virtualized Unix container that contains your app slug in its file system
	* Dyno - isolated, virtualized Unix container, that provides the required environment to run an app.
	* to see all working dynos we can use the command:
		heroku ps
* Config vars
	* An app's configuration is everything that is likely to vary between environments (staging, production, developer environments, etc.)
		* This includes backing services such as databases, credentials or environment variables that provide some specific info to your app
	* The configuration is stored in config vars
		* example:
			* Heroku config:set ENCRYPTION_KEY=my_secret_launch_codes
			* we can acces the above config var using this code: ENV["ENCRYPTION_KEY"]
	* Config vars contain customizable data that can be changed independently of your source code. The configuration is exposed to a running app via environment variables.
	* All dynos will have the exact same set of config variables at runtime.
Releases
	* the combination of slug and configuration is called release
	* releases are an append-only ledger of slugs and config vars
	* to see all releases you can use the command: heroku releases
	* we can rollback and deploy a previos release using this command: heroku releases:rollback NUMBER_OF_THE_RELEASE
	* whenever you change a set of config vars associated with your app, a new release is generated
Dyno manager
	* the dyno manager of the Heroku platform is responsible for managing dynos across all apps on Heroku
	* apps that use free dyno type will sleep, when sleeping app receives a HTTP traffic, it will be awaken - causing a delay of few seconds
	* one-off dynos are temporary dynos that can run with their input/output attached to your local machine. They're loaded with your lastest
	release.
		* example:
			* heroku run bash
			* this will spin up a new dyno, loaded with your release, and then run the "bash" command - which will provide you with a Unix shell. Once you've terminated your session, or after a period of inactivity, the dyno will be removed.
		!!! * Changes to the filesystem on one dyno are not propagated to other dynos and are not persisted across deploys and dyno restarts.
			* Each dyno gets it's own "emphemerical filesystem" - with a fresh copy fo the most recent release. It can be used as temporary scratch, but changes to the filesystem are not reflected to other dynos.
Add-ons
	* Dynos don't share file state, and so add-ons that provide some kind of storage are typically used as a means of communication between dynos in an app.
		* exaple: Redis or Postgres can be used as the backing machanism in a queue.
	* add-ons are third party, specialized, value-added cloud services that can be easily attached to an application, extending it's functionality
		* examples
			* databases
			* queueing & caching systems
			* storage
			* email services
	* much like config vars, whenever you add, remove or changes add-on, a new release is created
Logging and Monitoring
	* Heroku treat logs as streams of time-stamped events, and collates the stream of logs produced from all of the processes running in all dynos, and Heroku platform components, into "Logplex" - a high-performance, real-time system for log delivery.
	* Logplex automatically collates log entries from all the running dynos of your app,
		as well as other components such as routers, providing a single source of activity.
	* we can see our app's logs using the command:
		heroku logs
	* Logplex keeps a LIMITED buffer of log entries.
HTTP Routing
	* Heroku's HTTP routers distribute incoming requests for your app across you running web dynos
	* scaling an app's capacity to handle web traffic involves scaling the number of web dynos:
		heroku ps:scale web+5