Update README + add Dockerfile

[KyleAMathews]

Woah this is awesome! I'd kinda totally forgotten about getting around to setting this up so thanks!

One thought/question for you. What I'd imagined for this is that the onbuild would actually run gatsby build and then serve the site. I build my Docker images on a build server so I don't have node/npm installed there. Right now I check-in my public directory but it'd be nice if I could avoid that and have the site get built as part of creating the Docker image. What do you think about that? Good idea? Bad?

[cusspvz]

@KyleAMathews I've already an internal image for building gatsby images, but at the time I've created this PR I didn't.

Here are my thoughts:

• I propose to have here three images:
  • a latest image, probably based on cusspvz/nginx:latest :D
  • a development, which should have, by default, gatsby and its resources installed, probably based on cusspvz/node:development :D
  • a onbuild image, which should be based on gatsby/gatsby:development and have the gatsby build and other related commands and export the generated assets by creating a docker image internally based on latest image.

What do you think about it?

[KyleAMathews]

Seems promising! And totally fine basing the Gatsby images on yours as long as you're planning on owning this :-) Looking forward to the updated PR!

[cusspvz]

@KyleAMathews nice to hear !

So here's my proposal for being responsible for this repo:

• Having read/write access to this repo
• Having this repo on travis-ci so we can have more control over the autobuild process and have some tests over it so we avoid issues on who's gonna use it.
• I will be responsible for managing PRs and Issues on a 48h window.
• I will develop those three images as soon as I got access to things and later I will try to provide some test cases.

Questions:

• Do you have semantic rules for repo's names such as all of them having gatsby- prefix?
• Do you have a Slack/Asana or other collaborative software rather than GitHub for Gatsby?

[KyleAMathews]

Hey awesome! Welcome aboard :-)

So I've added you to the new gatsby-deploy team which has responsibility for making it easy to deploy Gatsby sites and gives you ownership over this repo.

You should have permission to setup Travis CI, let me know if not.

Repo names should be gatsby-* but I prefer monorepos whenever possible so keep all Docker images inside this repo. Or perhaps we might even move them into the main Gatsbyjs repo. I'm planning on moving the starters into the main repo soon actually.

Discord is the main chat room. https://discord.gg/0ZcbPKXt5bVoxkfV

[cusspvz]

Hey awesome! Welcome aboard :-)

Naiiisseeeeeeee, Thanks! :-)

You should have permission to setup Travis CI, let me know if not.

Gonna try it right away.

Repo names should be gatsby-* but I prefer monorepos whenever possible so keep all Docker images inside this repo.

I was asking because I want to maintain them all over this repo, but gatsbyjs/gatsby-nginx seemed too "technical" and not SEO friendly, probably people that want to get gatsby on docker would search for "gatsby js docker", so if I have vote here I would rather choose gatsbyjs/docker instead.

Or perhaps we might even move them into the main Gatsbyjs repo. I'm planning on moving the starters into the main repo soon actually.

It's something we have to think, imo the way gatsby is built, as a dependency module that needs some bootstrapping such as express or even webpack which seems evenly more appropriate to compare, they can be shipped on docker but as a dependency not as a SaaS. The idea to have this separated seems indicated.

Also came to mind while driving home that gatsby cli could have the deployment (docker image build) itself as a subcommand.

Something like:

gatsby push/deploy [--docker-image=[registry/]username/static[:latest]]

# docker-image must be able to be set over `config.toml`, and could default to `${package.name}/gatsby`.

The command above would build an ready-to-use nginx image base on the latest tag of this repo and push it to the registry.

The onbuild tag of this repo would run over the development tag:

gatsby build
gatsby push

# configuration would be read from `config.toml`
# don't know if configs from the `config.toml` could be overlapped by
# environment variables, but such would facilitate a lot those images. 

What do you think about it?

[cusspvz]

Gonna close this PR since things have evolved and development of this is already in progress.