Add language to each codeblock

[ci skip]

docs/deployment/buildpacks.md

@@ -75,7 +75,7 @@ The syntax for declaring a `Procfile` is as follows. Note that the format is one
 
 If, for example, you have multiple queue workers and wish to scale them separately, the following would be a valid way to work around the requirement of not duplicating process types:
 
-```
+```Procfile
 worker:           env QUEUE=* bundle exec rake resque:work
 importantworker:  env QUEUE=important bundle exec rake resque:work
 ```

docs/deployment/deployment-tasks.md

@@ -18,7 +18,7 @@ Simply place an `app.json` file in the root of your repository or for dockerfile
 
 ### Example app.json
 
-```
+```json
 {
   "name": "barebones nodejs",
   "description": "A barebones Node.js app using Express 4.",

docs/deployment/dockerfiles.md

@@ -27,13 +27,13 @@ When ports are exposed through the default nginx proxy, they are proxied externa
 
 By default no arguments are passed to `docker run` when deploying the container and the `CMD` or `ENTRYPOINT` defined in the `Dockerfile` are executed. You can take advantage of docker ability of overriding the `CMD` or passing parameters to your `ENTRYPOINT` setting `$DOKKU_DOCKERFILE_START_CMD`. Let's say for example you are deploying a base nodejs image, with the following `ENTRYPOINT`:
 
-```
+```Dockerfile
 ENTRYPOINT ["node"]
 ```
 
 You can do:
 
-```
+```shell
 dokku config:set APP DOKKU_DOCKERFILE_START_CMD="--harmony server.js"
 ```
 
@@ -52,14 +52,14 @@ When you deploy your app a Docker image will be built, the `Procfile` will be ex
 (it must be in the folder defined in your `Dockerfile` as `WORKDIR` or `/app`) and the commands
 in it will be passed to `docker run` to start your process(es). Here's an example `Procfile`:
 
-```
+```Procfile
 web: bin/run-prod.sh
 worker: bin/run-worker.sh
 ```
 
 And `Dockerfile`:
 
-```
+```Dockerfile
 FROM debian:jessie
 WORKDIR /app
 COPY . ./

docs/deployment/domain-configuration.md

@@ -71,7 +71,7 @@ dokku domains:remove myapp example.com
 
 By default, dokku will route any received request with an unknown HOST header value to the lexicographically first site in the nginx config stack. If this is not the desired behavior, you may want to add the following configuration to the global nginx configuration. This will catch all unknown HOST header values and return a `410 Gone` response. You can replace the `return 410;` with `return 444;` which will cause nginx to not respond to requests that do not match known domains (connection refused).
 
-```
+```nginx
 server {
   listen 80 default_server;
   listen [::]:80 default_server;
@@ -84,7 +84,7 @@ server {
 
 You may also wish to use a separate vhost in your `/etc/nginx/sites-enabled` directory. To do so, create the vhost in that directory as `/etc/nginx/sites-enabled/00-default.conf`. You will also need to change two lines in the main `nginx.conf`:
 
-```
+```nginx
 # Swap both conf.d include line and the sites-enabled include line. From:
 include /etc/nginx/conf.d/*.conf;
 include /etc/nginx/sites-enabled/*;

docs/deployment/one-off-processes.md

@@ -95,7 +95,7 @@ dokku enter node-js-app web python script/background-worker.py
 
 Your procfile can have the following entry:
 
-```
+```Procfile
 cron: sleep infinity
 ```
 
@@ -138,7 +138,7 @@ Regularly scheduled tasks can be a bit of a pain with dokku. The following are g
 
 The following is a sample cronfile that you can use for your applications:
 
-```
+```cron
 # server cron jobs
 MAILTO="mail@example.com"
 PATH=/usr/local/bin:/usr/bin:/bin

docs/deployment/ssl-configuration.md

@@ -83,7 +83,7 @@ Your application has access to the HTTP headers `X-Forwarded-Proto`, `X-Forwarde
 
 If your server runs behind an HTTP/S load balancer, then Nginx will see all requests as coming from the load balancer. If your load balancer sets the `X-Forwarded-` headers, you can tell Nginx to pass these headers from load balancer to your application by using the following [nginx custom template](/dokku/nginx/#customizing-the-nginx-configuration)
 
-```shell
+```go
 server {
   listen      [::]:{{ .NGINX_PORT }};
   listen      {{ .NGINX_PORT }};

docs/deployment/user-management.md

@@ -33,13 +33,13 @@ At it's base, the `sshcommand` *must* be run under a user with sudo access, as i
 
 For instance, if you stored your public key at `~/.ssh/id_rsa.pub-open` and are deploying to EC2 where the default root-enabled user is `ubuntu`, you can run the following command to add your key under the `superuser` username:
 
-```
+```shell
 cat ~/.ssh/id_rsa.pub-open | ssh ubuntu@dokku.me "sudo sshcommand acl-add dokku superuser"
 ```
 
 If you are using the vagrant installation, you can also use the `make vagrant-acl-add` target to add your public key to dokku (it will use your host username as the `USER`):
 
-```
+```shell
 cat ~/.ssh/id_rsa.pub | make vagrant-acl-add
 ```