Formatted README and added code highlighting (#115)

.github/ISSUE_TEMPLATE/bug_report.md

@@ -1,10 +1,9 @@
 ---
 name: Bug report
 about: Create a report to help us improve
-title: ''
+title: ""
 labels: bug
-assignees: ''
-
+assignees: ""
 ---
 
 **Describe the bug:**
@@ -18,6 +17,7 @@ assignees: ''
 **Additional context:**
 
 **Desktop (please complete the following information):**
+
 - OS:
 
 **Additional context**

.github/ISSUE_TEMPLATE/feature_request.md

@@ -1,10 +1,9 @@
 ---
 name: Feature request
 about: Suggest an idea for this project
-title: ''
+title: ""
 labels: enhancement
-assignees: ''
-
+assignees: ""
 ---
 
 **As a:**

README.md

@@ -12,20 +12,20 @@ First, install the latest `fab` cli on your local machine from [our releases](ht
 
 Let's walk through building an example Fabrikate definition to see how it works in practice. First off, let's create a directory for our cluster definition:
 
-```
+```sh
 $ mkdir mycluster
 $ cd mycluster
 ```
 
 The first thing I want to do is pull in a common set of observability and service mesh platforms so I can operate this cluster. My organization has settled on a [cloud native](https://github.com/timfpark/fabrikate-cloud-native) stack, and so I'd like to add that in immediately:
 
-```
+```sh
 $ fab add cloud-native --source https://github.com/timfpark/fabrikate-cloud-native --type component
 ```
 
 Since our directory was empty, this creates a component.yaml file in this directory that looks like this:
 
-```
+```yaml
 name: "mycluster"
 subcomponents:
   - name: "cloud-native"
@@ -39,7 +39,7 @@ The `cloud-native` component we added is a remote component backed by a git repo
 
 Looking inside the this component at its own root `component.yaml` definition, you can see that it itself uses a set of remote components:
 
-```
+```yaml
 name: "cloud-native"
 subcomponents:
   - name: "elasticsearch-fluentd-kibana"
@@ -63,7 +63,7 @@ Fabrikate recursively iterates component definitions, so as it processes this lo
 
 Let's look at the component definition for the [elasticsearch-fluentd-kibana component](https://github.com/timfpark/fabrikate-elasticsearch-fluentd-kibana/blob/master/component.json):
 
-```
+```json
 {
   "name": "elasticsearch-fluentd-kibana",
   "generator": "static",
@@ -103,7 +103,7 @@ Secondly, we see that that this component generates resource definitions. In par
 
 With generalized helm charts like the ones used here, its often necessary to provide them with configuration values that vary by environment. This component provides a reasonable set of defaults for its subcomponents in `config/common.yaml`. Since this component is providing these four logging subsystems together as a "stack", or preconfigured whole, we can provide configuration to higher level parts based on this knowledge:
 
-```
+```yaml
 config:
 subcomponents:
   elasticsearch:
@@ -144,7 +144,7 @@ $ fab set azure --subcomponent cloud-native.elasticsearch data.persistence.stora
 
 This creates a file called `config/azure.yaml` that looks like this:
 
-```
+```yaml
 subcomponents:
   cloud-native:
     subcomponents:
@@ -168,9 +168,8 @@ $ fab add simple-service --source https://github.com/timfpark/fabrikate-istio-se
 
 This component creates these traffic split services using the config applied to it. Let's create a `prod` config that does this for a `prod` cluster by creating `config/prod.yaml` and placing the following in it:
 
-```
+```yaml
 subcomponents:
-
   simple-service:
     namespace: services
     config:
@@ -180,7 +179,6 @@ subcomponents:
         name: simple-service
         port: 80
       tiers:
-
         canary:
           image: "docker.io/timfpark/simpleservice:671"
           replicas: 1
@@ -216,13 +214,13 @@ With this, we have a functionally complete Fabrikate definition for our deployme
 
 First, let's install the remote components and helm charts:
 
-```
+```sh
 $ fab install
 ```
 
 This downloads all of the required components and charts locally. With those installed, we can now generate the manifests for our deployment with:
 
-```
+```sh
 $ fab generate prod azure
 ```
 
@@ -230,7 +228,7 @@ This will iterate through our deployment definition, collect configuration value
 
 These manifests are meant to be generated as part of a CI / CD pipeline and applied from a pod within the cluster like [Flux](https://github.com/weaveworks/flux), but if you have a Kubernetes cluster up and running you can also apply them directly with:
 
-```
+```sh
 $ cd generated/prod-azure
 $ kubectl apply --recursive -f .
 ```

azure-pipelines.yml

@@ -2,13 +2,13 @@ trigger:
   batch: true
 
 pool:
-  vmImage: 'Ubuntu-16.04'
+  vmImage: "Ubuntu-16.04"
 
 variables:
-  GOBIN:  '$(GOPATH)/bin' # Go binaries path
-  GOROOT: '/usr/local/go1.11' # Go installation path
-  GOPATH: '$(system.defaultWorkingDirectory)/gopath' # Go workspace path
-  modulePath: '$(GOPATH)/src/github.com/$(build.repository.name)' # Path to the module's code
+  GOBIN: "$(GOPATH)/bin" # Go binaries path
+  GOROOT: "/usr/local/go1.11" # Go installation path
+  GOPATH: "$(system.defaultWorkingDirectory)/gopath" # Go workspace path
+  modulePath: "$(GOPATH)/src/github.com/$(build.repository.name)" # Path to the module's code
 
 steps:
   - script: |
@@ -20,7 +20,7 @@ steps:
       mv !(gopath) '$(modulePath)'
       echo '##vso[task.prependpath]$(GOBIN)'
       echo '##vso[task.prependpath]$(GOROOT)/bin'
-  displayName: 'Set up Go workspace'
+    displayName: "Set up Go workspace"
 
   - script: |
       HELM_URL=https://storage.googleapis.com/kubernetes-helm
@@ -29,21 +29,21 @@ steps:
       tar xzfv ${HELM_TGZ}
       PATH=`pwd`/linux-amd64/:$PATH
       helm init --client-only
-  displayName: 'Install helm'
+    displayName: "Install helm"
 
   - script: |
       go get github.com/golangci/golangci-lint/cmd/golangci-lint
       go get -v -t -d ./...
-  workingDirectory: '$(modulePath)'
-  displayName: 'Get Go dependencies'
+    workingDirectory: "$(modulePath)"
+    displayName: "Get Go dependencies"
 
   - script: |
       golangci-lint run
-  workingDirectory: '$(modulePath)'
-  displayName: 'Lint'
+    workingDirectory: "$(modulePath)"
+    displayName: "Lint"
 
   - script: |
       go test -v -race ./core
       go test -v -race ./cmd
-  workingDirectory: '$(modulePath)'
-  displayName: 'Test'
+    workingDirectory: "$(modulePath)"
+    displayName: "Test"