Basics

Bosco knows about all of your repositories, so it isn't a big stretch to also have Bosco provide some helpful tools for starting, stopping, watching and restarting your services.

Node Services

If your project is a node project, Bosco will look for a 'start' script within the package.json, and start the project via PM2.

An extract from one of our service package.json files can be seen below:

{
  "name": "service-resource-api",
  "version": "0.0.1",
  "description": "Resource API",
  "main": "service.js",
  "scripts": {
    "start": "node cluster",
    "test": "make acceptance-test",
    "lint": "make lint"
  }
}

To start this project:

bosco run -r resource-api

Docker

At TES we use Docker to manage all of the infrastructure elements that development teams may depend on, as well as the packaging and deployment of services in the live environments.

To make use of Docker images during development, we have Bosco do the stopping / starting of them for you. For this to work, you need to create a bosco-service.json file within the service repository that is the infrastructure - for example, the file below is for our mongodb Docker image:

{
	"tags": ["upload", "search"],
	"service": {
		"type":"docker",
		"name":"infra-mongodb",
		"registry":"docker-registry.tescloud.com",
		"username": "tescloud",
		"version": "latest",
    "alwaysPull": true,
    "checkTimeout": 30000,
    "docker":{
      "HostConfig": {
        "PortBindings": {
          "27017/tcp": [{
            "HostIp": "0.0.0.0",
            "HostPort": "27017"
          }],
          "28017/tcp":  [{
            "HostIp": "0.0.0.0",
            "HostPort": "28017"
          }]
        }
      }
    }
	}
}

Bosco will simply use this configuration to pull the Docker image from the registry and run it locally.

To start this project:

bosco run -r mongodb

Note that Bosco does not package up and run the project from its source, so any changes made in the project are not reflected immediately. At the moment our build server creates the docker images when it is pushed and publishes to the registry, which means if you are working on infrastructure images at the moment the end to end flow is relatively cumbersome.

We have so far not found this to be an issue as in most instances infra-* projects tend to be very slow moving and change relatively infrequently.