Multi-repository applications

Squash supports applications made of several microservices defined within separate repositories. There are currently three ways to get such apps running in Squash:

• Using the deployment dependencies feature. Squash creates a unique VM for each independent repository and attach them all together through environment variables. This requires very little setup. You may also share one or more microservices with multiple feature branch deployments. This is useful when certain microservices don't change very often.
• Using Docker Compose and separate docker images for each repository. This requires more work if you don't currently have a Docker Compose file for your main application.
• Using Kubernetes and multiple helm charts.

Below we will cover each implementation in detail. For the examples listed below we will be using the following common use case with two repositories:

• API service defined in its own repository.
• A Web application (MyWebApp ) also defined in its own repository. MyWebApp consumes (depends on) the API service listed above.

Using Deployment Dependencies

Both the web app and API service are defined using a Squash YAML file.

API service - this is a simple app defined in a Dockefile. This service lives on its own repository, called "api-repo".

deployments:
  APIService:
    filename:
      ./src/Dockerfile
    port_forwarding: 80:8069

Web application definition (MyWebApp ). This is a Python based app defined entirely in the Squash YAML file (see YAML based apps).

deployments:
  MyWebApp:
    dockerimage: python:latest
    build_steps:
      - apt-get update && apt-get install -y libssl-dev libpq-dev git
      - pip install setuptools pip
      - pip install /code
    launch_steps:
      - cd /myproject/mysite
      - python manage.py runserver 0.0.0.0:80
    depends_on:
      - API_SERVICE:
          app: api-repo/master

On the snipped above, note the "depends_on" field. This is how Squash will "attach" the web app and API service in the same deployment chain. Squash will create two separate VMs for the config file above, one VM for MyWebApp and another VM for the API service.

It's also worth noting that we are specifically using branch master within the depends_on field mentioned above.  This is handy in case you decide to start multiple Squash deployments for different branches of MyWebApp. In that case each MyWebApp deployment will be attached to the same API service (and VM) that is running off branch master.

For more details please refer to the Deployment Dependencies page.

Using a Docker Compose file

The following steps are required in order to configure a Docker Compose file for this example:

• Setup a Docker file for the API service
• Configure your Continuous Integration (CI/CD) service to automatically build and push a Docker image to a Docker registry every time code gets merged into branch "master" of API repository.
• Setup a Docker Compose file for MyWebApp using the docker image defined above for the API service.
• Define a Squash YAML file for MyWebApp with a reference to the Docker Compose file and access credentials to the Docker registry.

Here is an example of how the Docker Compose file of MyWebApp would look like:

version: '3.1'
services:
  api:
    image: my-registry.io/ace-corp/my-repo:master
    ports:
      - 8000:80

  postgres:
    image: postgres:9.6.5-alpine
    environment:
      - POSTGRES_PASSWORD
      - POSTGRES_USER
      - POSTGRES_DB
    volumes:
      - postgres-data:/var/lib/postgresql/data/

  webapp:
    build: .
    environment:
      - POSTGRES_PASSWORD
      - POSTGRES_USER
      - POSTGRES_DB
      - POSTGRES_HOST=postgres
    depends_on:
      - postgres
      - api

In the example above we are defining the API service at the top with a reference to the Docker image that was pushed to a given registry. There is also a database service (postgres) and the web app itself, which depends on both the database and API service.

And here is a sample of the Squash YAML file:

deployments:
  MyApp:
    filename:
      ./src/docker-compose.yml
    port_forwarding: 80:8069
    docker_registry:
      server: my-registry.io
      username: my-username
      password: $REGISTRY_PASSWORD

Using Kubernetes

Please refer to our Kubernetes page for samples using multiple helm charts and a private registry.