Added docker support

[octavifs]

Changes

• Created a custom Dockerfile with all the necessary dependencies to build Chalk
• Created a series of scripts to build, serve and deploy chalk via the docker image
• Modified README.md with usage examples

Rationale

The docker image uses volumes to mount the repo. This allows us to generate the _site in the repo itself but using the docker binaries instead of the local install. That works seamlessly in OSX, since the default volume behaviour is that the ownership of the files will be mapped depending on whether you are in the container or outside of it (files inside the container would be owned by root, whereas outside of it by your local user). This is NOT the case in Linux. Basically Linux maintains the user that created the files, so if you build your site using docker, as root, the _site folder will be owned by root, even outside the container. This is why all the file operations in the deploy script are executed inside the container.

Testing

The PR has been tested on both OSX (High Sierra) and Ubuntu 16.04.

[nielsenramon]

@migueldemoura What do you think about adding this? I feel it's a bit too complex for the general users of Chalk.

[migueldemoura]

There are a few dependencies that a user must install and maintain to use chalk (git, ruby, npm). The bin/ scripts are also specific to unix-like systems, i.e, windows users have to resort to WSL or similar solutions. This shouldn't be an issue anyways, as someone using jekyll is likely technical enough to deal with these hurdles.

Having Docker simplifies dependency management, "solves" cross-platform issues (you can use it on every major OS) and makes it easier to use chalk, but it does force one to install and possibly debug docker issues.

If this is simply a pre-packaged option, I think it's useful. This, however, needs to be fixed:

This is NOT the case in Linux. Basically Linux maintains the user that created the files, so if you build your site using docker, as root, the _site folder will be owned by root, even outside the container. This is why all the file operations in the deploy script are executed inside the container. @octavifs

I would also consolidate the scripts, or use a flag to determine if the user is using docker on not, i.e, the instructions would always be the same, but the command that is run depends on the docker/local flag status. Example:

bin/console setup
bin/console serve
bin/console deploy

bin/console script imports env var inside bin/.env and determines whether to use docker or not.

[nbulischeck]

@octavifs This failed to build for me unless I added the zlib-dev package to the list of packages installed at the top of the Dockerfile. jemoji requires html-pipeline which requires nokogiri which requires the zlib package.

Full output here:

Fetching nokogiri 1.8.2
Installing nokogiri 1.8.2 with native extensions
Gem::Ext::BuildError: ERROR: Failed to build gem native extension.

    current directory: /usr/lib/ruby/gems/2.4.0/gems/nokogiri-1.8.2/ext/nokogiri
/usr/bin/ruby -r ./siteconf20180422-14-y1267q.rb extconf.rb
checking if the C compiler accepts ... yes
Building nokogiri using packaged libraries.
Using mini_portile version 2.3.0
checking for gzdopen() in -lz... no
zlib is missing; necessary for building libxml2
*** extconf.rb failed ***
Could not create Makefile due to some reason, probably lack of necessary
libraries and/or headers.  Check the mkmf.log file for more details.  You may
need configuration options.

Provided configuration options:
    --with-opt-dir
    --without-opt-dir
    --with-opt-include
    --without-opt-include=${opt-dir}/include
    --with-opt-lib
    --without-opt-lib=${opt-dir}/lib
    --with-make-prog
    --without-make-prog
    --srcdir=.
    --curdir
    --ruby=/usr/bin/$(RUBY_BASE_NAME)
    --help
    --clean
    --use-system-libraries
    --enable-static
    --disable-static
    --with-zlib-dir
    --without-zlib-dir
    --with-zlib-include
    --without-zlib-include=${zlib-dir}/include
    --with-zlib-lib
    --without-zlib-lib=${zlib-dir}/lib
    --enable-cross-build
    --disable-cross-build

To see why this extension failed to compile, please check the mkmf.log which can
be found here:

  /usr/lib/ruby/gems/2.4.0/extensions/x86_64-linux/2.4.0/nokogiri-1.8.2/mkmf.log

extconf failed, exit code 1

Gem files will remain installed in /usr/lib/ruby/gems/2.4.0/gems/nokogiri-1.8.2
for inspection.
Results logged to
/usr/lib/ruby/gems/2.4.0/extensions/x86_64-linux/2.4.0/nokogiri-1.8.2/gem_make.out

An error occurred while installing nokogiri (1.8.2), and Bundler cannot
continue.
Make sure that `gem install nokogiri -v '1.8.2'` succeeds before bundling.

In Gemfile:
  jemoji was resolved to 0.6.2, which depends on
    html-pipeline was resolved to 2.7.1, which depends on
      nokogiri
The command '/bin/sh -c bin/setup' returned a non-zero code: 5

Made a PR to this PR here: https://github.com/octavifs/chalk/pull/1