Reed Allman 61b416a9b5 automagic sql db migrations (#461)
* 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
2017-11-14 12:54:33 -08:00
2017-11-14 12:54:33 -08:00
2017-11-14 12:54:33 -08:00
2017-11-14 02:09:38 +00:00
2017-10-31 15:37:13 +00:00
2017-11-14 12:54:33 -08:00
2017-11-14 12:54:33 -08:00
2017-09-18 23:33:47 -07:00
2017-07-25 10:29:20 -07:00
2017-11-13 09:13:21 -08:00
2017-05-18 18:59:34 +00:00
2017-10-17 01:55:17 -07:00
2017-11-14 12:54:33 -08:00
2017-11-14 12:54:33 -08:00
2017-10-06 08:42:33 -07:00
2017-05-18 18:59:34 +00:00
2017-07-26 10:50:19 -07:00
2017-10-06 08:42:33 -07:00
2017-10-11 06:50:32 -07:00
2017-08-23 22:51:27 -07:00
2017-11-14 12:54:33 -08:00

Fn Project

CircleCI GoDoc Go Report Card

Fn is an event-driven, open source, functions-as-a-service compute platform that you can run anywhere. Some of it's key features:

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

Get Help

Get Involved

Stay Informed

Description
The container native, cloud agnostic serverless platform.
Readme Apache-2.0 170 MiB
Languages
Go 97.4%
Shell 1.2%
Ruby 0.5%
Makefile 0.4%
Dockerfile 0.4%
Other 0.1%