netlify / addons

Netlify add-on documentation
34 stars 16 forks source link

[Addons] Add ability to specify add-on configuration in toml file for provisioning a new site #5

Open phae opened 5 years ago

calavera commented 5 years ago

This need to be defined beyond the title @DavidWells

DavidWells commented 5 years ago

The general idea is to allow for addons to be defined in the netlify.toml file. This being our config into the realm of Infrastructure as code, much like terraform & Cloudformation.

Defining addons via netlify.toml will:

  1. Eliminate the need for users to manually run netlify addons:create xyz over and over to recreate a site. Add-ons will automatically be created when site is created, updated when netlify.toml inputs change and get removed completely (if safe), when the site is deleted
  2. Make site dependancies explicit and repeatable. (a clone will reproduce the same site/app)
  3. Allow for larger, more robust applications to be deployed via Netlify. Because we are privisioning the resources, we will have the ability to weaving together addon inputs & outputs. IE if I provision begin.com functions via netlify.toml (see below) I might need to reference an APIKey output by FaunaDB add-on to make SDK calls.
  4. Putting Netlify at the center of provisioning third party resources gives us a very strong strategic advantage over "duct tape" put it together yourself tools and ultimately will result in stickier users

Here is an example of the addon config in yml

Note the shape of the object can change based on requirements we discover. Aka don't get hung up on the finer details until we iron them out =)

addons:
  # Provision Contentful space
  ContentfulOne:
    type: 'Contentful'
    config:
      spaceName: 'Space name'
      spaceModel: github.com/contentful/content-models/blob/master/the-example-app/contentful-export.json
      settingThree: cdn.contentful.com
  # Provision Contentful space
  ContentfulTwo:
    type: 'Contentful'
    config:
      spaceName: 'Space name two'
      spaceModel: github.com/contentful/content-models/blob/master/the-example-app/contentful-export-two.json
      settingThree: cdn.contentful.com
  # Provision Fauna DB
  FaunaTodosDb:
    type: 'Fauna'
    config:
      regional: true
      schema: ./bootstrap-todo-schema.js
  # Provision Fauna DB two
  FaunaUsersDb:
    type: 'Fauna'
    config:
      api: 'lololol'
      schema: ./bootstrap-user-schema.js
  # Provision begin.com app
  BeginApp:
    type: 'Begin'
    config:
      arc: ${file(./arc)}
      environment:
        # reference to output of other resource FaunaUsersDb
        faunaUserKey: ${FaunaUsersDb.apiKey}
  # Provision AWS resources
  AWS:
    type: 'CloudFormation'
    config: ...CF config

Or toml

[addons]
  [addons.ContentfulOne]
  type = "Contentful"
    [addons.ContentfulOne.config]
    spaceName = "Space name"
    spaceModel = "github.com/contentful/content-models/blob/master/the-example-app/contentful-export.json"
    settingThree = "cdn.contentful.com"
  [addons.ContentfulTwo]
  type = "Contentful"
    [addons.ContentfulTwo.config]
    spaceName = "Space name two"
    spaceModel = "github.com/contentful/content-models/blob/master/the-example-app/contentful-export-two.json"
    settingThree = "cdn.contentful.com"
  [addons.FaunaTodosDb]
  type = "Fauna"
    [addons.FaunaTodosDb.config]
    regional = true
    schema = "./bootstrap-todo-schema.js"
  [addons.FaunaUsersDb]
  type = "Fauna"
    [addons.FaunaUsersDb.config]
    api = "lololol"
    schema = "./bootstrap-user-schema.js"
  [addons.BeginApp]
  type = "Begin"
    [addons.BeginApp.config]
    arc = "${file(./arc)}"
      [addons.BeginApp.config.environment]
      faunaUserKey = "${FaunaUsersDb.apiKey}"
  [addons.AWS]
  type = "AWS::CloudFormation"
  config = "...CF config"

It is an object for a couple reasons:

  1. This allows for support of multiple resources of the same type. IE "My app needs 2 fauna tables" etc.
  2. The top level keys can be used to reference output values of other addons. So If I need live URLs, APIKeys, TableNames, etc that are created from another addon I can reference them by name.

The shape of the object is not super important (as long as it ergonomically friendly to devs).

Being able to reference output values from other Add-ons allows for more robust applications to be built. We will need to generate a DAG if outputs are references to provision add-ons in the correct order

Flow

  1. Developer runs CLI netlify addons:create addonName and configures required values
  2. The netlify config file is updated with the addon and values. Secrets are stored remotely or as file references.
  3. The netlify config is committed to git and is now reusable for future deployments
DavidWells commented 5 years ago

We should likely have a meeting to discuss this in detail

DavidWells commented 5 years ago

Related https://github.com/netlify/product/issues/185