* adds migrations closes #57 migrations only run if the database is not brand new. brand new databases will contain all the right fields when CREATE TABLE is called, this is for readability mostly more than efficiency (do not want to have to go through all of the database migrations to ascertain what columns a table has). upon startup of a new database, the migrations will be analyzed and the highest version set, so that future migrations will be run. this should also avoid running through all the migrations, which could bork db's easily enough (if the user just exits from impatience, say). otherwise, all migrations that a db has not yet seen will be run against it upon startup, this should be seamless to the user whether they had a db that had 0 migrations run on it before or N. this means users will not have to explicitly run any migrations on their dbs nor see any errors when we upgrade the db (so long as things go well). if migrations do not go so well, users will have to manually repair dbs (this is the intention of the `migrate` library and it seems sane), this should be rare, and I'm unsure myself how best to resolve not having gone through this myself, I would assume it will require running down migrations and then manually updating the migration field; in any case, docs once one of us has to go through this. migrations are written to files and checked into version control, and then use go-bindata to generate those files into go code and compiled in to be consumed by the migrate library (so that we don't have to put migration files on any servers) -- this is also in vcs. this seems to work ok. I don't like having to use the separate go-bindata tool but it wasn't really hard to install and then go generate takes care of the args. adding migrations should be relatively rare anyway, but tried to make it pretty painless. 1 migration to add created_at to the route is done here as an example of how to do migrations, as well as testing these things ;) -- `created_at` will be `0001-01-01T00:00:00.000Z` for any existing routes after a user runs this version. could spend the extra time adding 'today's date to any outstanding records, but that's not really accurate, the main thing is nobody will have to nuke their db with the migrations in place & we don't have any prod clusters really to worry about. all future routes will correctly have `created_at` set, and plan to add other timestamps but wanted to keep this patch as small as possible so only did routes.created_at. there are tests that a spankin new db will work as expected as well as a db after running all down & up migrations works. the latter tests only run on mysql and postgres, since sqlite3 does not like ALTER TABLE DROP COLUMN; up migrations will need to be tested manually for sqlite3 only, but in theory if they are simple and work on postgres and mysql, there is a good likelihood of success; the new migration from this patch works on sqlite3 fine. for now, we need to use `github.com/rdallman/migrate` to move forward, as getting integrated into upstream is proving difficult due to `github.com/go-sql-driver/mysql` being broken on master (yay dependencies). Fortunately for us, we vendor a version of the `mysql` bindings that actually works, thus, we are capable of using the `mattes/migrate` library with success due to that. this also will require go1.9 to use the new `database/sql.Conn` type, CI has been updated accordingly. some doc fixes too from testing.. and of course updated all deps. anyway, whew. this should let us add fields to the db without busting everybody's dbs. open to feedback on better ways, but this was overall pretty simple despite futzing with mysql. * add migrate pkg to deps, update deps use rdallman/migrate until we resolve in mattes land * add README in migrations package * add ref to mattes lib
Fn is an event-driven, open source, functions-as-a-service compute platform that you can run anywhere. Some of it's key features:
- Write once
- Run anywhere
- Public, private and hybrid cloud
- Import functions directly from Lambda and run them wherever you want
- Easy to use for developers
- Easy to manage for operators
- Written in Go
- Simple yet powerful extensibility
Prequisites
- Docker 17.05 or later installed and running
- A Docker Hub account (Docker Hub) (or other Docker-compliant registry)
- Log Docker into your Docker Hub account:
docker login
Quickstart
Install CLI tool
The command line tool isn't required, but it sure makes things a lot easier. There are a few options to install it:
1. Homebrew - MacOS
If you're on a Mac and use Homebrew, this one is for you:
brew install fn
2. Shell script
This one works on Linux and MacOS (partially on Windows):
curl -LSs https://raw.githubusercontent.com/fnproject/cli/master/install | sh
This will download a shell script and execute it. If the script asks for a password, that is because it invokes sudo.
3. Download the bin
Head over to our releases and download it.
Run Fn Server
Now fire up an Fn server:
fn start
This will start Fn in single server mode, using an embedded database and message queue. You can find all the configuration options here. If you are on Windows, check here.
Your First Function
Functions are small but powerful blocks of code that generally do one simple thing. Forget about monoliths when using functions, just focus on the task that you want the function to perform.
First, create an empty directory called hello and cd into it.
The following is a simple Go program that outputs a string to STDOUT. Copy and paste the code below into a file called func.go.
package main
import (
"fmt"
)
func main() {
fmt.Println("Hello from Fn!")
}
Now run the following CLI commands:
# Initialize your function
# This detects your runtime from the code above and creates a func.yaml
fn init
# Set your Docker Hub username
export FN_REGISTRY=<DOCKERHUB_USERNAME>
# Test your function
# This will run inside a container exactly how it will on the server
fn run
# Deploy your functions to the Fn server (default localhost:8080)
# This will create a route to your function as well
fn deploy --app myapp
Now you can call your function:
curl http://localhost:8080/r/myapp/hello
# or:
fn call myapp /hello
Or in a browser: http://localhost:8080/r/myapp/hello
That's it! You just deployed your first function and called it. To update your function
you can update your code and run fn deploy myapp again.
User Interface
We also have an open source graphical user interface for Fn. It's very easy to use, simply run the command below:
docker run --rm -it --link functions:api -p 4000:4000 -e "API_URL=http://api:8080" fnproject/ui
For more information, see: https://github.com/fnproject/ui
Learn More
- Visit our Functions Tutorial Series. This tutorial will demonstrate some of the core Fn capabilities through a series of examples. We'll try to show examples in most major languages. This is a great Fn place to start!
- See our full documentation
- View all of our examples
- View our YouTube Channel
- View our API Docs
Get Help
- Ask your question on StackOverflow and tag it with
fn - Join our Slack Community
Get Involved
- Join our Slack Community
- Learn how to contribute
- See milestones for detailed issues
