Update from Capgemini/blog-private@1fee208

_posts/2014-10-10-testing-for-poodle.md

@@ -17,12 +17,12 @@ add infrastructure tests to your regression tests
 
 [ServerSpec][2] is a solid way of testing for this, and can be done as follows:
 
-{% highlight bash %}
+```bash 
 describe command 'openssl s_client -connect localhost:443 -ssl3 < /dev/null' do
     its(:exit_status) { should eq 1 }
     its(:stdout) { should match /no peer certificate available/ }
 end
-{% endhighlight %}
+```
 
 Use of the `< /dev/null` is to force the openssl client to terminate instead of
 waiting for input from the shell as we are only interested in the key exchange.

_posts/2014-11-10-automation.md

@@ -28,7 +28,7 @@ A "behat service" will be created to check if the selenium container is ready us
 
 We use  [fig](http://www.fig.sh/) for running the [containers](https://github.com/docker/docker/blob/master/README.md) and managing our basic UAT environment.
 You can add as many selenium services as you need to your fig.yml and run different behaviour-tests projects simultaneously because as we are [linking containers](http://docs.docker.com/userguide/dockerlinks/) we don't have to worry about port collision troubles.
-{% highlight bash %}
+```bash 
 selenium:
  build: dockerfiles/selenium-image
 behat:
@@ -37,7 +37,7 @@ behat:
   - behat/:/behat/
  links:
   - selenium:selenium
-{% endhighlight %}
+```
 
 Run “fig up” or any other fig command for automating and orchestrating your services.
 

_posts/2015-01-14-drupal-7-psr-forms.md

@@ -27,7 +27,7 @@ The information on [autoloading and folder structure for PSR-4 in Drupal 8](http
 
 We can get round this by providing our own `hook_forms()` as laid out in the [Cool](https://www.drupal.org/project/cool) module:
 
-{% highlight php %}
+```php 
 /**
 * Implements hook_forms().
 */
@@ -45,31 +45,31 @@ function psr4_form_forms($form_id, $args) {
 
   return $forms;
 }
-{% endhighlight %}
+```
 
 If you are ok placing your class in the `FormControllers` folder then you can omit the above function to keep your `.module` file simple or you could put the hook in another module. Potentially the [Cool](https://www.drupal.org/project/cool) module could be updated to reflect this.
 
 This class requires a namespace of the form `Drupal\<module_name>\Form`. It also extends the BaseForm class provided by the [Cool](https://www.drupal.org/project/cool) module so we don't need to explicitly create our form functions:
 
-{% highlight php %}
+```php 
 namespace Drupal\psr4_form\Form;
 
 class FormExample extends \Drupal\cool\BaseForm {
   ...
 }
-{% endhighlight %}
+```
 
 Within our FormExample class we need a method `getId()` to expose the `form_id` to Drupal:
 
-{% highlight php %}
+```php 
 public static function getId() {
   return 'psr4_form';
 }
-{% endhighlight %}
+```
 
 And of course we need the form builder:
 
-{% highlight php %}
+```php 
 public static function build() {
   $form = parent::build();
   $form['my_textfield'] = array(
@@ -79,7 +79,7 @@ public static function build() {
 
    return $form;
 }
-{% endhighlight %}
+```
 
 All that is left is to define your validate and submit methods following [the Drupal 8 form API](https://www.drupal.org/node/2117411).
 

_posts/2015-03-06-why-microservices-are-right-for-us-pt1.md

@@ -26,10 +26,10 @@ What is more, not only are they human-sized for us as developers, they are also
 
 But perhaps even better than both these is the fact that Microservices are also consumer-sized.  We write all ours so that with only a Java and Maven dependency installed you can check them out and have them running locally with two commands:
 
-{% highlight php %}
+```php 
 git clone
 mvn spring-boot:run
-{% endhighlight %}
+```
 
 We set up our code so that, when the Microservice starts up, it's automatically in stub-mode, by which I mean it's downstream Microservice and other dependencies are stubbed out. The range of requests you can send in, and the various valid and failure states you'll mimic as a result are specified in standard README.md files at the top of each Microservice git repo.  
 

_posts/2015-04-29-code-beauty.md

@@ -44,19 +44,19 @@ I could stop here, but there’s one last gotcha regarding code beauty that I th
 
 As an example, you might prefer this code, written in C# in an imperative style.
 
-{% highlight c# %}
+```c# 
 int sum = 0; 
 foreach (int i in mylist)
 {
    sum += (i + 1);
 }
-{% endhighlight %}
+```
 
 Or you might prefer this code, written in Clojure in a functional style.
 
-{% highlight clojure %}
+```clojure 
 (reduce + (map inc mylist))
-{% endhighlight %}
+```
 
 They both do the same thing and your preference probably depends on what sort of code style and language you usually use.
 

_posts/2015-06-24-apollo-launch-aws.md

@@ -35,34 +35,34 @@ It's worth reading through our [getting started guide for AWS public cloud](http
   - An active account setup on [Amazon AWS](http://aws.amazon.com/)
   - An account setup on [Hashicorp Atlas](https://atlas.hashicorp.com)
   - An SSH key created, ready for pushing to AWS:
-{% highlight bash %}
+```bash 
 cd ~/.ssh
 ssh-keygen -P "" -t rsa -f id_rsa_aws -b 4096 -C "email@example.com"
 openssl rsa -in ~/.ssh/id_rsa_aws -outform pem > id_rsa_aws.pem
 chmod 400 id_rsa_aws.pem
 eval `ssh-agent -s`
 ssh-add id_rsa_aws.pem
-{% endhighlight %}
+```
   - [Terraform](https://terraform.io) installed and in your $PATH
   - [Python](https://www.python.org/) >= 2.7.5 installed along with [pip](https://pip.pypa.io/en/latest/installing.html).
 
 ## Get the code
 
 To start, lets clone the repo and install some dependencies -
 
-{% highlight bash %}
+```bash 
 git clone https://github.com/Capgemini/Apollo
 cd Apollo
 pip install -r requirements.txt
-{% endhighlight %}
+```
 
 ## Set some configuration variables
 
 Next, we need to set some environment variables in our shell. Usually I like to keep a little script that i can ```source``` to bring those into my current shell environment, but its up to you, you can simply ```export``` the variables on the command-line if you wish.
 
 To create the file containing the environment variables ```vi aws-public.env``` and the contents of this file should look similar to this -
 
-{% highlight bash %}
+```bash 
 export APOLLO_PROVIDER=aws-public
 export TF_VAR_access_key=$AWS_ACCESS_KEY_ID
 export TF_VAR_secret_key=$AWS_SECRET_ACCESS_KEY
@@ -71,7 +71,7 @@ export TF_VAR_key_file=~/.ssh/id_rsa_aws.pub
 export TF_VAR_key_name=capgeminiapollo
 export TF_VAR_slaves=2
 export ATLAS_INFRASTRUCTURE=capgemini/apollo-aws-public
-{% endhighlight %}
+```
 
 Lets just step through and explain what each of these variables do -
 
@@ -97,9 +97,9 @@ you already have in your AWS account.
 
 To launch the cluster execute -
 
-{% highlight bash %}
+```bash 
 source aws-public.env && sh bootstrap/apollo-launch.sh
-{% endhighlight %}
+```
 
 This will bring the environment variables into your shell and kick off the launch process
 which should start bootstrapping the cluster on AWS.

_posts/2015-06-30-how-apollo-uses-weave.md

@@ -46,14 +46,14 @@ Our [Ansible role for Weave is here](https://github.com/Capgemini/Apollo/tree/ma
 
 We configure ```/etc/network/interfaces.d/weave.cfg``` with the following -
 
-{% highlight bash %}
+```bash 
 auto weave
 iface weave inet manual
   pre-up /usr/local/bin/weave create-bridge
   post-up ip addr add dev weave WEAVE_BRIDGE
   pre-down ifconfig weave down
   post-down brctl delbr weave
-{% endhighlight %}
+```
 
 ```WEAVE_BRIDGE``` is a dynamic Ansible variable that changes for each host in the Weave network. For example on HOST1 the WEAVE_BRIDGE would be ```10.2.0.1/16``` but on HOST2 it would be
 ```10.2.0.2/16.```, and so on.
@@ -62,9 +62,9 @@ iface weave inet manual
 
 Next, we bring up the Weave network by executing
 
-{% highlight bash %}
+```bash 
 ifup weave
-{% endhighlight %}
+```
 
 This gives us a network bridge on the host for the Weave network.
 
@@ -75,18 +75,18 @@ This allows us to enable Weave as a service.
 
 Inside that file we have -
 
-{% highlight bash %}
+```bash 
 start on started docker
 stop on stopping docker
-{% endhighlight %}
+```
 
 This ensures that when the Docker service is started, Weave is also started, and similar behaviour occurs on stop.
 
 When the Weave service starts it will launch Weave with the following command -
 
-{% highlight bash %}
+```bash 
 ${WEAVE} launch ${PEERS}
-{% endhighlight %}
+```
 
 Where ```${WEAVE}``` is the path to the Weave binary and ```${PEERS}``` are the other peer nodes in the cluster to join on launch.
 
@@ -127,9 +127,9 @@ To launch it we are going to use [marathonctl](https://github.com/shoenig/marath
 
 We do that by executing -
 
-{% highlight bash %}
+```bash 
 marathonctl -h=MARATHON_IP:MARATHON_PORT app create nodejs-rest-api-v1.json
-{% endhighlight %}
+```
 
 This calls the Marathon REST API to initiate the deployment. When its up you should see something like this in the Marathon web interface, showing that we have 2 instances of our service container running -
 

_posts/2015-07-03-continuously-deploying-apollo.md

@@ -30,30 +30,30 @@ Every time a Pull Request is created the build steps below will run:
 
 - Syntax checks against all our json packer templates using [packer validate](https://www.packer.io/docs/command-line/validate.html).
 
-{% highlight yaml %}
+```yaml 
 script:
   cwd: packer/
   name: validate packer template for AMI
   code: ./packer validate ubuntu-14.04_amd64-amis.json
-{% endhighlight %}
+```
 
 - Linting checks against the ansible code using our custom [step-ansible-lint](https://github.com/Capgemini/step-ansible-lint) that relies on [https://github.com/willthames/ansible-lint](https://github.com/willthames/ansible-lint).
 
-{% highlight bash %}
+```bash 
 capgemini/ansible-lint:
   name: run ansible-lint against the site.yml playbook
   playbook: site.yml
-{% endhighlight %}
+```
 
 - [Very simplistic Bash unit testing](https://github.com/Capgemini/Apollo/blob/master/bootstrap/tests/test.sh) for ensuring our bash functions do what they are meant to do.
 
-{% highlight yaml %}
+```yaml 
 script:
   name: scripts testing
   cwd: bootstrap/tests
   code: |
     /bin/bash test.sh
-{% endhighlight %}
+```
 
 In the future we might be adding a new step here for "packer push" the images into [Atlas](https://atlas.hashicorp.com/) when merging into master branch.
 
@@ -71,7 +71,7 @@ Every successful build from any specific commit can be deployed either automatic
 
 At the moment we are continuously deploying Apollo into Amazon and Digitalocean using a [step-apollo-deploy](https://github.com/Capgemini/step-apollo-deploy/).
 
-{% highlight yaml %}
+```yaml 
 deploy:
     steps:
     - install-packages:
@@ -84,7 +84,7 @@ deploy:
         artifact_version: $ARTIFACT_VERSION
         terraform_version: 0.5.3
         run_tests: true
-{% endhighlight %}
+```
 
 Environment variables can be set for every target you create in wercker:
 
@@ -99,12 +99,12 @@ We have created [step-apollo-deploy](https://github.com/Capgemini/step-apollo-de
 
 Every change in step-apollo-deploy is also continuously integrated by wercker itself using [step-validate-wercker-step](https://github.com/wercker/step-validate-wercker-step):
 
-{% highlight yaml %}
+```yaml 
 box: wercker/default
 build:
   steps:
     - validate-wercker-step
-{% endhighlight %}
+```
 
 So in essence with both "build" and "deploy" in place we have the ability to automatically triggering a fully tested ephemeral Apollo deployment for any specific commit.
 
@@ -124,10 +124,10 @@ We use ansible roles for installing and running [dockerbench](https://github.com
 
 Testing during a deploy can be optionally enabled using a toggle environment variable.
 
-{% highlight bash %}
+```bash 
 export APOLLO_serverspec_run_tests=true
 export APOLLO_dockerbench_run_test=true
-{% endhighlight %}
+```
 
 ### Dockerbench
 
@@ -141,7 +141,7 @@ The dockerbench project is still fairly young, and is still to settle on a stand
 
 Apollo default deployment provides 3 machines playing mesos master role and running zookeeper and marathon. As some configuration like the ips can be assigned on deployment time we need to populate some of the serverspecs dynamically by using an ansible [j2 template](http://docs.ansible.com/template_module.html).
 
-{% highlight ruby %}
+```ruby 
 {% raw %}
 describe command("curl --silent --show-error --fail --dump-header /dev/stderr --retry 2 http://{{ marathon_hostname }}:8080/v2/info") do
   its(:stdout) { should match '.*"master":"zk://"{{ marathon_peers|join(',') }}/mesos".*' }
@@ -152,12 +152,12 @@ describe command("curl --silent --show-error --fail --dump-header /dev/stderr --
   its(:exit_status) { should eq 0 }
 end
 {% endraw %}
-{% endhighlight %}
+```
 
 
 Below are some examples with more of the serverspecs we run for marathon:
 
-{% highlight ruby %}
+```ruby 
 describe docker_container('marathon') do
   it { should be_running }
   it { should have_volume('/store','/etc/marathon/store') }
@@ -189,19 +189,19 @@ describe command("curl -s 127.0.0.1:8080/v2/apps/serverspecs-app") do
   its(:stdout) { should match '.*"tasksRunning":1.*' }
   its(:exit_status) { should eq 0 }
 end
-{% endhighlight %}
+```
 
 ## Feedback
 
 Finally we get the feeback for the deployment in every cloud in our Slack channel using [wantedly/pretty-slack-notify](https://github.com/wantedly/step-pretty-slack-notify):
 
-{% highlight yaml %}
+```yaml 
 after-steps:
     - wantedly/pretty-slack-notify:
         webhook_url: $SLACK_WEBHOOK_URL
         channel: apollo
         username: wercker-bot
-{% endhighlight %}
+```
 ![Fig 4. Slack notification](/images/2015-07-03-continuously-deploying-apollo/slack.png)
 
 You can check out the [full wercker.yml file here](https://github.com/Capgemini/Apollo/blob/master/wercker.yml)