Friday, August 21, 2015

Using AWS CloudFormation - In Search of Software Defined Infrastructure

I have a simple DevOps setup I want to put into the cloud. I was looking at the fastest way I could repeatability set up an infrastructure. I found AWS CloudFormation to be pretty straight forward. And I found that I can use my same CloudFormation Templates in my OpenStack cloud as well as AWS.
TeamCity.png
Deployment Diagram
In this configuration I am setting up a BuildServer(TeamCity), BuildAgents, and a Defect/Work Management Server (YouTrack). Since these tools come from the same vendor they have nice integrations that I want to take advantage.
As you can see in the Deployment diagram I put the ports that I want exposed in the deployment.




CloudFormation Templates

CloudFormation templates are XML or JSON files that are used to describe resources, their configuration and applications running on those resources. When I first started looking at CloudFormation I put all three nodes into the same Template file. This did not work since I can only define one EC2 instance per Template file. You can describe multiple resources like Databases, Storage, Load Balanacers, etc...

The Template has two major parts: the Description and the Resources.
  • Description
  • Resources
    • Auto Scaling Group – Ensure that at least one is running
    • Launch Group – Defines the EC2 Image, Init Scripts and where to get binary.
      • EC2 image – ami file, Instance Type, and Security key to use for SSH
      • Init Scripts- Installation scripts, start server scripts, stop server scripts.
      • Sources for installation – Stored in an S3 location. Automatically unzips in specified directory.
    • Security Group
      • Defines the ports to open in the firewall.

Installations of Applications

Inside the CloudFormation Template you can specify the installation zip or tar file that can be used for the installation of the application. It will automatically unzip/untar the file and put it in the directory you specify. Make sure the installation zip file is in a location that your instances can use. I use S3 containers to do this. It helps decrease cost from loading over the internet everytime it starts up. It also gives me a way to do "poor-mans" configuration management. I couple of things to remember when you are doing this.
  • Make sure you set permission so your instances can access them.
  • Get the install zip file URL and put it in your Template file.
  • If you are using public installations. You can make use the Public URL and set the Permission to public (readonly).

Init Scripts

These are used to setup and tear-down your applications on the Instances. I use the cfn-init helper script that gives my instance access to the template file.
The cfn-init helper script reads template metadata from the AWS::CloudFormation::Init key and acts accordingly to:
  • Fetch and parse metadata from CloudFormation
  • Install packages
  • Write files to disk
  • Enable/disable and start/stop services
Store the stop, start, install scripts in the metadata in the template file. It allows for multiple configsets, which gives me the ability to use the same template file for different configurations of the same application or different platform configurations.

Kicking off your instance

There are two ways to kick off your instances.
  • AWS Console UI
    • https://console.aws.amazon.com/cloudformation

  • AWS Command Line
    • aws cloudformation …
    • aws cloudformation create-stack –-stack-name “MyStack”  -–template_body file://home/mystack.template ...

CloudFormation Learnings

Here are some key learnings
  • One Node - One Template File
  • Only one type of EC2 Image can be used in a CloudFormation File. (No-heterogeneous environments). You can have more than one instance in your autoscaling group but they must all be the same instance type.
  • Most AWS services can be used. ElasticBeanStalk, OpsWare, EC2, S3, SecurityGroups, etc..
  • Use a Common SSH key for everything in the same infrastructure deployment. It makes it easier to check on everything.
  • Create an Custom Image for instance that you want quick spin up times. No additional installation of software or packages. (BuildAgents are images).

TeamCity Template File

  • For the TeamCity Template file I set up the following for AWS:
  • EC2 Image – ami-e7527ed7 – AWS Linx image
  • Instance Type – t2.micro
  • Ports: 3389, 80, 8111, and 22
  • Init Scripts
    • 01-stop - teamcity-server.sh stop
    • 02-start - teamcity-server.sh start
TeamCity.template file
 

{
  "AWSTemplateFormatVersion": "2010-09-09",
  "Description": "TeamCity Server for Linux",
  "Resources": {
    "TeamCityAS": {
      "Type": "AWS::AutoScaling::AutoScalingGroup",
      "Properties": {
        "AvailabilityZones": {
          "Fn::GetAZs": ""
        },
        "LaunchConfigurationName": {
          "Ref": "TeamCityLC"
        },
        "MaxSize": "1",
        "MinSize": "0",
        "DesiredCapacity": "1"
      }
    },
    "TeamCityLC": {
      "Type": "AWS::AutoScaling::LaunchConfiguration",
      "Properties": {
        "ImageId": "ami-e7527ed7",
        "InstanceType": "t2.micro",
        "KeyName": "teamcity",
        "SecurityGroups": [
          {
            "Ref": "SecurityGroup"
          }
        ],
        "UserData": {
          "Fn::Base64": {
            "Fn::Join": [
              "",
              [
                "#!/bin/bash\n",
                "yum update -y aws-cfn-bootstrap\n",
                "# Install the files and packages from the metadata\n",
                "/opt/aws/bin/cfn-init -v ",
                "         --stack ",
                { "Ref": "AWS::StackName" },
                "         --resource TeamCityLC",
                "         --configsets all ",
                "         --region ",
                { "Ref": "AWS::Region" },
                "\n"
              ]
            ]
          }
        }
      },
      "Metadata": {
        "AWS::CloudFormation::Init": {
          "configSets": {
            "all": [
              "server"
            ]
          },
          "server": {
            "commands": {
              "01-stop": {
                "command": "/opt/TeamCity/bin/teamcity-server.sh stop",
                "waitAfterCompletion": 5,
                "ignoreErrors": "true"
              },
              "02-start": {
                "command": "/opt/TeamCity/bin/teamcity-server.sh start",
                "waitAfterCompletion": 120
              }
            },
            "sources": {
              "/opt/": "https://s3-us-west-1.amazonaws.com/com.yoly.teamcity.installation/installations/TeamCity-9.1.tar.gz"
            }
          }
        }
      }
    },
    "SecurityGroup": {
      "Type": "AWS::EC2::SecurityGroup",
      "Properties": {
        "GroupDescription": "TeamCity Server Security Group",
        "SecurityGroupIngress": [
          { "IpProtocol": "tcp", "CidrIp": "0.0.0.0/0", "FromPort": "3389", "ToPort": "3389" },
          { "IpProtocol": "tcp", "CidrIp": "0.0.0.0/0", "FromPort": "80", "ToPort": "80" },
          { "IpProtocol": "tcp", "CidrIp": "0.0.0.0/0", "FromPort": "8111", "ToPort": "8111" },
          {"IpProtocol" : "tcp", "FromPort" : "22", "ToPort" : "22", "CidrIp" : "0.0.0.0/0"}
        ]
      }
    }
  }
}


YouTrack Template File

  • EC2 Image – ami-e7527ed7 – AWS Linx image
  • Instance Type – t2.micro
  • Ports: 3389, 8080, 80, and 22
  • Init Scripts
    • 01-permissions – chmod –R 755 /opt/YouTrack
    • 02-stop – youtrack.sh stop
    • 03-start – youtrack.sh start

{
  "AWSTemplateFormatVersion": "2010-09-09",
  "Description": "YouTrack Server for Linux",
  "Resources": {
    "YouTrackAS": {
      "Type": "AWS::AutoScaling::AutoScalingGroup",
      "Properties": {
        "AvailabilityZones": {
          "Fn::GetAZs": ""
        },
        "LaunchConfigurationName": {
          "Ref": "YouTrackLC"
        },
        "MaxSize": "1",
        "MinSize": "0",
        "DesiredCapacity": "1"
      }
    },
    "YouTrackLC": {
      "Type": "AWS::AutoScaling::LaunchConfiguration",
      "Properties": {
        "ImageId": "ami-e7527ed7",
        "InstanceType": "t2.micro",
        "KeyName": "teamcity",
        "SecurityGroups": [
          {
            "Ref": "SecurityGroup"
          }
        ],
        "UserData": {
          "Fn::Base64": {
            "Fn::Join": [
              "",
              [
                "#!/bin/bash\n",
                "yum update -y aws-cfn-bootstrap\n",
                "# Install the files and packages from the metadata\n",
                "/opt/aws/bin/cfn-init -v ",
                "         --stack ",
                { "Ref": "AWS::StackName" },
                "         --resource YouTrackLC ",
                "         --configsets youtrack ",
                "         --region ",
                { "Ref": "AWS::Region" },
                "\n"
              ]
            ]
          }
        }
      },
      "Metadata": {
        "AWS::CloudFormation::Init": {
          "configSets": {
            "youtrack": [
              "youtrack"
            ]
          },
          "youtrack": {
            "commands": {
              "01-permissions": {
                "command": "chmod -R 777 /opt/YouTrack",
                "waitAfterCompletion": 1,
                "ignoreErrors": "true"
              },
              "02-stop": {
                "command": "/opt/YouTrack/bin/youtrack.sh stop",
                "waitAfterCompletion": 5,
                "ignoreErrors": "true"
              },
              "03-start": {
                "command": "/opt/YouTrack/bin/youtrack.sh start",
                "waitAfterCompletion": 120
              }
            },
            "sources": {
              "/opt/YouTrack": "https://s3.....installation/installations/youtrack-6.0.12634.zip"
            }
          }
        }
      }
    },


    "SecurityGroup": {
      "Type": "AWS::EC2::SecurityGroup",
      "Properties": {
        "GroupDescription": "TeamCity Server Security Group",
        "SecurityGroupIngress": [
          { "IpProtocol": "tcp", "CidrIp": "0.0.0.0/0", "FromPort": "3389", "ToPort": "3389" },
          { "IpProtocol": "tcp", "CidrIp": "0.0.0.0/0", "FromPort": "80", "ToPort": "80" },
          { "IpProtocol": "tcp", "CidrIp": "0.0.0.0/0", "FromPort": "8080", "ToPort": "8080" },
          {"IpProtocol" : "tcp", "FromPort" : "22", "ToPort" : "22", "CidrIp" : "0.0.0.0/0"}
        ]
      }
    }
  }
}

Monday, June 22, 2015

Toolbox Full of Container Technology


This last weekend I started cleaning out my garage. I said I started, because my garage will never completely be cleaned out. But I did manage to clean up my tool box. I found lots of interesting things in my tool box. Some broken tools, some tools that I have no idea how they got there. I am sure my neighbors and friends probably are missing them.  I also found half started projects that just got thrown in their that don't matter anymore. Probably in a hurry to clean up the mess in the garage. Anyway. I started thinking about all of these tools in my tool box, and of course comparing them to the tools I use at work. They are not things I can touch like the hardware in my tool box, but they are invaluable tools that I can use to get jobs done. I quickly broke down the tools into categories and found a group of tools that I have downloaded, played with and am using everyday that fit in the "Container Technology" category. So I gathered those tools together and decided to write this blog to help me keep track of what container tool to use for what job. This is what I have so far. Please note this is not a complete list, but a good start I think.


Container Tools

  • Docker - Container Definition and nice CLI to control Containers
  • Docker Compose - Define applications that contain more than one container.
  • Mesos - Meta-scheduler, Distribute Kernel
  • Docker Swarm - Container Scheduler that can talk to MesosS
  • Kubernetes - Container Scheduler that can schedule and control Containers.
  • Marathon - Service based scheduler for containers. Plugin to Mesos
  • Chronos - Temporal Based Scheduler for containers. Plugin to Mesos

This is how I see everything fitting together.

Docker (Production - 1.7.0)

This helps developers define how to configure a container. Starts with a base image and then allows you to run commands, expose ports, and copy data into the container through a simple configuration file. Docker also gives CLI and REST API to allow users to control the individual containers. It requires a Docker controller running on a physical or virtual machine.

Docker Compose (Beta - 1.7.0)

Gives developers the ability to define an application as a set of micro-services. It shows the dependencies between the micro-services (containers). Which ports they expose to each other, their startup order, and any shared resources(data) between the containers that make up the application.

MesosMesosArchitecture.png (Production - 0.23.0)

"A distributed systems kernel" from the mesos web site.
Mesos describes itself as a distributed system kernel. It is responsible for picking physical compute nodes to run containers, jobs, micro-services, etc... I gets telemetry from the physical hardware and can determine which machines can best handle incoming jobs. It then provisions machines and executes job on those machines. Schedulers like Kubernetes, Marathon, Chronos, and Docker Swarm sit ontop of Mesos and act as the orchestrator for the containers running in the cloud.

Schedulers

Docker Swarm (Still in Alpha - 0.3.0 )

If you want to use a familiar Docker API you can use Docker Swarm with Mesos to control multiple containers on mutilple hosts. There is rumor it may also allow you to talk to Kubernetes in the future. Check out http://www.techrepublic.com/article/docker-and-mesos-like-peanut-butter-and-jelly/ for more information.

Kubernetes ( pre-production Beta - 0.19.0 )

  • If you want to launch groups of containers (K8 Pods) co-scheduled and co-located together, sharing resources on the same machine.
  • If you want to launch a service alongside one or more sidekick containers (e.g. log archiver, metrics monitor) that live next to the parent container.
  • if you want to use the K8s label-based service-discovery, load-balancing, and replication control. Very cool stuff for managing large number of containers.
  • If you want to manage groups of containers(K8 Pods).
  • If you want to load balance in isolation (K8 Pods).

Marathon (Production - 0.8.2)

  • If you want to launch applications that contain long running heterogeneous apps/services (Docker and Non-Docker).
  • If you want to use Mesos attributes for constraint-based scheduling.
  • If you want to use application groups and dependencies to launch, scale, or upgrade related services.
  • If you want to use event driven health checks to automatically restart unhealthy services.
  • If you want to integrate HAProxy or Consul for service discovery.
  • If you want a nice web UI or REST API to launch and monitor apps.

Chronos (Production - 2.3.4)

  • If you want to launch applications that contain short running heterogeneous apps/services (Docker and Non-Docker).
  • If you want to schedule a remporal task to run at a specific time/schedule, just like cron.
  • If you want to schedule a DAG workflow of dependent tasks.
  • If you want a nice web UI or REST API to launch and monitor apps.
  • If  you want to use a scheduler that was built from the start with Mesos in mind.


Ok. This is the start. I am sure many of you have more to add to the list. Please let me know what I am missing.

DWP.

Sunday, June 21, 2015

Automating SailsJS Testing with a CI tool

I recently started working with SailsJS. I am enjoying some of the libraries and how easy and fast it is to get things up and running. But I do miss some of the built in tools that come with Grails. A good example of this is the "grails test" tool. This made it easy to run unit level tests, integration or functional tests from the command line with the same command line for all of my projects.

grails test-app 

This made it very easy to integrate into a CI tool like TeamCity. I didn't need any special scripts, relative paths or some dark art of getting environment variables right. Things just worked out of the box.

Since SailsJS lets you plug in any testing you want. AKA it does not come built into the framework. I had to figure out how to run the tests in my IDE (Intellij in this case), and in my CI system (TeamCity). As you can see I am trying to keep the tool set in the same family.

I decided to use Mocha as the test framework. It seemed to have everything that I wanted and was the closest to what I was familiar with in the grails framework. But the commands to get it running were a little more than just typing "sailjs test" in my application directory. But I found a cool little trick to make it easy. Using npm and my package.json file. I can use the same command for both CI and IDE.

By simply adding a line to the package.json file in the root directory of the application source I can then call

npm test

Here is an example of my package.json file.

...
  "sails-mongo": "^0.11.1"},
"scripts": {
  "start": "node app.js",
  "test": "node ./node_modules/mocha/bin/_mocha --recursive --ui bdd ./test",
  "debug": "node debug app.js"},
"main": "app.js",
...


The test script calls the node command with the proper mocha script to run my tests. Notice that the path to the mocha script is relative to the application root directory. It is important in the IDE and CI that you set the working directory to the application root. Which should be the default for both. Now I can simply call: 

npm test

from the command line, in the IDE, or in the CI system.

DWP

Tuesday, February 11, 2014

Comparisons of CI Build Systems


There are several dozen CI Build tools available in the industry. I recently did some research on some of the tools and this is what I found. This is not a comprehensive list but a good start to I hope a heated discussion about the benefits of these tools. The tools I evaluated are:
  • Bamboo - Atlassian
  • TeamCity - JetBrains
  • QuickBuild (Formally LuntBuild) - PMease
  • Jenkins (Formally Hudson) - Open Source 

CI Build Benefits

I found that these four tools have many of the same benefits such as:
  • Integration
    • Defect Management Tools - Jira, Bugzilla, Redmine, TeamForge, Trac
    • SCM Tools - Subversion, CVS, Perforce, ClearCase, Git, TFS, etc…
  • Features
    • Pre-Commit Test and Continuous Integration
    • Extendable through REST API
    • Supports ( Ant, Maven, MSBuild, Nant, Rake, …)
    • Security Access Control
    • Build Notification and System Alerts
    • Metrics Aggregation
    • Custom User Dashboards
    • Build Setup and Workflow Design
    • Integration with Static Analysis
    • Test Insight and Statistics
    • Advanced Build Grid and Cloud Integration
    • Build Pipelining and Continuous Deployment

CI Build Tool Differentiation

All of these tools have these features that in common and I would say these are necessary in order to have a CI Build System. Without these they would not be feasible for the type of software development work.
So there has to be something that differentiates the different tools from each other. I found three key differentiators in these tools.
  • Build and Workflow Definition
  • Machine Health and Monitoring
  • SCM Integration

Build and Workflow Definition

Build and Workflow Definition show how easy it is to define build steps, dependencies between builds, and aggregate build definitions.

Bamboo * * *

Bamboo has the concept of Phases, Stages, Jobs and Tasks.
Stages can be run sequentially or in parallel and artifacts are passed between stages. Stages are made up of several jobs that are run in parallel. Jobs are made up of tasks. Tasks are commands that are run on Build Agents. Tasks are run sequentially. Bamboo focuses on a very Release Management tops down approach.
Artifacts are essential to passing data between stages of the build. Bamboo is built with a multi-tiered/multi-component pattern in mind. Where products are made of releases from multiple component releases and tested together.

Jenkins *

Jenkins is one of the older tools out there and is in the open source community. It came from the Java world and is still very Java centric. Most jobs are commands and/or maven targets. This works great for simple builds that run command and/or tests. There is a Multi-job plugin for Jenkins but it is not as powerful as the other tools.

TeamCity * * * * *

Looking at TeamCity it appears that it was built around a great workflow engine. You can tell it was built from the ground up with complex workflow and simple workflows in mind. They have the concept of Hierarchical Projects, Job Configurations, Parameterized Jobs, and a cool concept call Meta-runners that let you reuse parts of your build in other builds. They  have both Screen driven workflow definitions as well as XML text based definitions. Artifacts are part of their system but not to the same degree as Bamboo. This tool ranks the highest in Workflow and Build Definition.

QuickBuild * * * *

QuickBuild takes a close second to TeamCity for Workflow and Build Definition in my book. They have many of the same concepts of TeamCity but does not take it to the same level. They have Hierarchical Projects, Jobs, and Job Templates. They do not have the Meta-runner concept that TeamCity has which is a small negative for them. But they share many of the same types of Screens and Workflow Editors that are found in TeamCity. Artifacts are part of the their system but again they are not as good as Bamboo in this respect. This tool ranks second right behind TeamCity in this category.

SCM Integration

All of these systems do a good job with integrating with SCM triggers for changes, displaying change lists for each build and polling the SCM systems for changes. But there are some differences that make one of the tools standout.

Bamboo * * * *

Bamboo has the best integration with the SCM systems especially Git. Bamboo was built around the concept of moving things from one stage to another and promoting build artifacts and their code to different branches in the SCM system. This concept works really well to keep large team isolated from build breaks of components that are still trashing with change. They also have the tightest integration with Jira with automated Release Notes, Build Break Reports, Recurring Issue Build reports etc... Very well done for Bamboo on it integration into the SCM system for this they get the highest ranking.

Jenkins * *

Jenkins has good integration with the SCM systems and allows for quick build trigger definition when changes happen in the SCM system. They also do a good job showing changes for each build. And surprising for the simpleness of the tool they have build promotion built into many of the default jobs. Most of these are very Java and Artifactory centric, but they do get the job done. It is not the top in this category, but it gets 2 stars for having everything necessary and a couple of extras.

TeamCity * * * *

TeamCity has the standard tools needed for integration into the SCM system but it does not have the integration with branch and merge management that Bamboo has. You can define the jobs yourself with their robust job definition tools, but it is not first class like Bamboo. They do have a good interface to Defect managment tools and to build break reporting. They have recently introduced Remote run and Pre-Test Commits to their tool box to help cover many of the holes that organizations have in their build infrastructure. That helps but it still is not at the level as Bamboo for their integrations. So I am giving it 4 stars. Right behind Bamboo.

QuickBuild * * * *

QuickBuild and TeamCity are equally matched in the integration they have with SCM and Defect managment tools. QuickBuild has all of the normal trigger based and polling SCM systems for changes and listing Change sets like all of the other tools. They still don't have the tight integration to branching and build promotion that Bamboo uses, but they have their own unique Build Promotion concepts that give it an advantage over Jenkins. Because you can make QuickBuild do everything that Bamboo can do with its build and branch management through the Build Definitions, I am giving QuickBuild 4 stars to match that of TeamCity.

Machine and Resource Health and Montiroing

Bamboo - * * * *

In the last 4 years bamboo has done a great job at integrating with Amazon's EC2. The integration allows users to define Capabilities of EC2 images and then define their jobs that use the capabilities. This concept reminds me of the old Distributed resource management days with tools like Condor and PBS. Mapping supply and demand to run jobs. They have done this with a simple to use interface. You will however need to get on your EC2 Ninja belt to make sure that your EC2 image actually has the capability. [:)]  Build agent reports are available for viewing, but the tools and reports are not at the level of a grid technology solution. For this reason I am giving Bamboo 4 stars.

Jenkins - *

Jenkins allows you to have multiple build agents, but the agents are tied to specific jobs/builds. Basically a poor mans server farm.  But its simplicity is its strength. It gets the job done for small teams, and small builds. Which for most projects is just right. Because it does not have a dynamic resource pool of machines I am giving Jenkins 1 star.

TeamCity - * * *

Team City recently added an Amazon EC2 extension to their library of tools. This extension is still in the beginning and does not have all of the features that Bamboo or QuickBuild has. TeamCity has the concept of pools of build agents or machines that are assigned to projects, builds, and/or steps. This allows for different teams to be using the same machines with different priorities on builds in the machine pools. Because TeamCity does not have has much as the dynamic tools I would like to see I am ranking right below Bamboo and giving it 3 stars.

QuickBuild * * * * *

QuickBuild looks like it was built with Grid Technology in mind. The tools and screens that manage the machine resources are great and you can quickly see what is going on. They have the concept of mapping resources and jobs together. Jobs have a set of resources that they consume and machines have resources to be consumed. They have an integration with Amazon EC2 much the same way as Bamboo. Because Quickbuild was built with multi-platform/OS builds and tests in mind they get 5 stars for this category.

Summary of findings

After all of this I don't have a good answer to what tool is best. They have great benefits that cannot be overlooked. As with many development tools it is based on the work that you are doing. So here is the summary of the tools and their strengths.

Bamboo

  • Good for Component team fitting in a bigger group.
  • Learning curve just above Jenkins, but not much.
  • Simple to get up and running and easy to create more complex jobs
  • SCM/Release/Deployment centric.
  • Great integration with EC2 and VMWare

Jenkins

  • Good for a small group.
  • Simple to get up and running.
  • Free for download

TeamCity

  • Learning curve higher than Jenkins similar to Bamboo
  • Job and Project Definition the easiest to understand and get up and working.
  • Most Build Definition Centric tool

QuickBuild

  • Learning curve is higher than Jenkins or Bamboo
  • Very Grid Technology centric. Build Server Farms
  • Great for very large and complex builds and teams.
  • Very flexible and extendable
Have fun choosing a tool that best fits you
DWP

Friday, January 24, 2014

Google Test and Google Mock Using Matchers to change default behavior

This blog is in a series of blogs that talks about how to use Google Test and Google Mock in the VS2012 environment. This is the 8th blog in that series.

Matchers

—Matchers let developers set the default behavior based on the parameters passed into the macro. —Google Mock gives several matching macros

Wildcard

"_"argument can be any value of the correct type.
"A<type>() or An<type>()"argument can be any value of type type.

Generic Comparison

Eq(value) or valueargument == value
Ge(value)argument >= value
Gt(value)argument > value
Le(value)argument <= value
Lt(value)argument < value
Ne(value)argument != value
IsNull()argument is a NULL pointer (raw or smart).
NotNull()argument is a non-null pointer (raw or smart).
Ref(variable)argument is a reference to variable.
TypedEq<type>(value)argument has type type and is equal to value. You may need to use this instead of Eq(value) when the mock function is overloaded.

String Matchers

The argument can be either a C string or a C++ string object:
ContainsRegex(string)argument matches the given regular expression.
EndsWith(suffix)argument ends with string suffix.
HasSubstr(string)argument contains string as a sub-string.
MatchesRegex(string)argument matches the given regular expression with the match starting at the first character and ending at the last character.
StartsWith(prefix)argument starts with string prefix.
StrCaseEq(string)argument is equal to string, ignoring case.
StrCaseNe(string)argument is not equal to string, ignoring case.
StrEq(string)argument is equal to string.
StrNe(string)argument is not equal to string.
ContainsRegex() and MatchesRegex() use the regular expression syntax defined hereStrCaseEq()StrCaseNe()StrEq(), and StrNe()work for wide strings as well.

—Class Tested -

If you want to test for specific value returned from a method.
EXPECT_THAT(value, matcher)
ASSERT_THAT(value, matcher)
Here is an example
#include "gmock/gmock.h"

using ::testing::AllOf;
using ::testing::Ge;
using ::testing::Le;
using ::testing::MatchesRegex;
using ::testing::StartsWith;
...

  EXPECT_THAT(bankMock->getAccount(), StartsWith("MyAcc"));
  EXPECT_THAT(bankMock->getAccount(), MatchesRegex("MyAccount \\d+"));
  ASSERT_THAT(bankMock->getBalance(), AllOf(Ge(500), Le(1000)));

—Mocked Class -

If you want the behavior of a MOCKED class to behave based on the values of parameters passed to a method.
ON_CALL(mock_object, method(matchers))
EXPECT_CALL(mock_object, method(matchers) ...
Set up default behavior for you MOCK class in your test fixture SetUp() Method
virtual void SetUp() {

ExternalService::theBank = bankMock = new BitcoinBank_Mock();
ON_CALL(*bankMock,changeBalance(_,_))
   .WillByDefault(Return(100));

}
Override mock behavior in specific test cases.
TEST_F(BitcoinWallet_ULT,updateLocalBalanceTest) {

ON_CALL(*bankMock, changeBalance(StrEq("MyAccount"),_))
.WillByDefault(Return(100));

}
This gives me the ability to set up default behavior in the SetUp of the fixture and override it in the test case run of the Test.

I hope this helps clarify more about Matchers. There is actually even more information available at https://code.google.com/p/googlemock/wiki/CheatSheet#Matcher
DWP