Non-HTTP based deployments

Squash supports launching service based deployments without an HTTP end point. This is helpful if you want to spin up a read-only database or any services that you want to share with one or more feature deployments. This is currently only supported within the Squash YAML file.

How it works

• First you need to define one or more services within the Squash YAML file, see examples below.
• Each non-HTTP service is defined almost the same way as an application. The main different is that it requires the “check_service_ports” field, which will tell Squash not to expect an HTTP response. Squash will instead ping one or more port numbers defined in this field as a way to check if the service is up.
• Squash uses the deployment dependencies feature in order to facilitate the communication between these services and regular apps. In a nutshell, Squash automatically sets environment variables within the VM running your app containing the private IP of each non-HTTP service that is required by your application.
• It’s possible to share a non-HTTP deployment with multiple feature/app deployments.

Example 1: Separate database service with a Docker app

In this example we are going to share a PostgreSQL database with an application named “MyApp”. A few important notes:

• Squash will create two separate VMs for the example below, one VM for MyApp and another VM for the service named “postgres”.
• As defined in the “depends_on” field, Squash will only use the “postgres” service in branch master. This will essentially allow Squash to attach this database service to multiple app deployments.
• Behind the scenes Squash will automatically set an environment variable $POSTGRESQL within the MyApp deployment with the exact IP and port number of the database service. You can use this information to make your application communicate with the database.

Squash YAML file:

deployments:
  MyApp:
    filename:
      ./src/docker-compose.yml
    port_forwarding: 80:8069
    depends_on:
      - POSTGRESQL:
          app: my-repo/master:postgres
  postgres:
    dockerimage: postgres:9.4
    run_options: -e POSTGRES_PASSWORD=passwd -e POSTGRES_USER=user
    check_service_ports: 5432
    port_forwarding: 5432:5432

Example 2: Database service built from scratch + Docker app

In this example we are building the database service from scratch, based on a given Ubuntu OS image.

• Squash will create two separate VMs for the example below, a VM for DatabaseService and a VM for the app InventoryApp.
• Behind the scenes Squash will automatically set an environment variable $DATABASE_SERVICE within the InventoryApp deployment with the exact IP and port number of the database service. You can use this information to make your application communicate with the database.
• The depends_on field has no branch name specified, this will make Squash create a separate deployment matching the same branch used by InventoryApp. Every time you start  InventoryApp Squash will also start a new VM for DatabaseService.

Squash YAML file:

deployments:
  DatabaseService:
    dockerimage:
      # This is the base OS image we want to use
      # for this service
      ubuntu:14.04
    build_steps:
      # This is where we install all the essential packages
      # needed
      - DEBIAN_FRONTEND=noninteractive apt-get update
      - DEBIAN_FRONTEND=noninteractive apt-get install -y 
      software-properties-common
      - DEBIAN_FRONTEND=noninteractive apt-get install -y 
        locales gcc postgresql postgresql-contrib 
        postgresql-9.3 sudo supervisor
    launch_steps:
      - service postgresql start
      # Squash will ping/telnet this port number as a
      # way to ensure the service is up and running
    check_service_ports: 5432
    port_forwarding: 5432:5432

  InventoryApp:
    filename:
      ./src/Dockerfile
    depends_on:
      - DATABASE_SERVICE:
          app: myrepo:DatabaseService

How to seed data into a database or other services

You can use the Squash assets storage to upload test data and then load it using the Squash YAML file. For more information: how to automatically load data into my services and keep my test data up-to-date.