Docker

Squash has native & first-class support for Dockerfiles and Docker-compose.

Using the Squash Deployment UI

The best way to start testing your first deployments is by using the Squash deployment interface, this interface will guide you through a few steps and questions in order to get your deployment up and running.

Automatic Docker detection

By default we will attempt to detect a Dockerfile or docker-compose file at the root path of your application code as follows:

./Dockerfile

or for a docker-compose file:

./docker-compose.yml

You may define custom Dockerfile locations in the Squash YAML file.

Multiple Dockerfiles or docker-compose files

Squash supports multiple Dockerfiles or docker-compose files within the same repository, on any path. For such cases each Dockerfile or docker-compose file is considered a unique application. And each application will receive their own unique URL running on its own virtual machine.

For example, let’s explore a scenario where a repository has the following files (let’s assume the branch name is “lib_upgrades”):

• src/crm/Dockerfile
• src/coreapp/docker-compose.yml
• src/store/Dockerfile-Store

You can configure Squash in such a way that when you create a Pull Request you will get a comment like this:

And because each of the Squash URLs above are unique, each of them will trigger separate deployments running off their own virtual machines.

Currently you must use the Squash YAM file to define such deployments.

Here is a .squash.yml file example of how the example above would look like:

deployments:
  CRM:
    filename:
      ./src/crm/Dockerfile
    context_path:
      ./src
    vm_size:
      1GB
    port_forwarding:
    # Squash by default expects an HTTP service running on port 80.
    # For this example the HTTP service is listening to port 3000.
      80:3000
    # these are built-in environment variables that you can pass to the
    # application's container. You may also define custom environment
    # variables from the Squash interface and use them here.
    run_options: --hostname ${SQUASH_BRANCH_WITH_ID}
  CoreApp:
    filename:
      ./src/coreapp/docker-compose.yml
    context_path:
      ./src
    environment:
    # You may also define environment variables in this section.
    # Then add these variables within the run_options command to set
    # them inside the docker container.
      - SERVICE_TYPE=CRM
    ready_wait:
    # This will tell Squash to wait up to 50 min (3000 seconds) for a
    # success response from the app. The count down only starts after
    # the build process is finished.
      3000
    vm_size:
      2GB
    copy_files_build_process:
    # This application requires loading a Solr search index during
    # build time. We are storing the index using Squash's Assets
    # storage feature.
      - /assets/solr-index/index.tar.gz ~/code/src/index.tar.gz
    copy_files:
    # And we can also copy files that are needed for the actual app
    # startup process
      - /assets/jetty.xml ~/code/jetty.xml
    run_options: --env SERVICE_TYPE=${SERVICE_TYPE}
  Store:
    filename:
      ./src/store/Dockerfile-Store
    context_path:
      ./src
    vm_size:
      2GB

Private Docker images

Squash supports private Docker images. For repos with only one Dockerfile or docker-compose file you may define the image details in the Squash Deployment UI as follows, this works for both Dockerfiles or docker-compose files:

 

 

Using Private Docker images in the Squash YAML fle

You can also specify the access information for private Docker images in the Squash YAML file. This is a great solution If you have multiple Dockerfiles within the same repository or simply want more flexibility

Here is a sample of how to define a private Docker image in the YAML file, for this example we have previously defined a REGISTRY_PASSWORD environment variable within the Squash interface. Thus, we are prefixing the variable name with a dollar (“$”) symbol to indicate to Squash that this is an environment variable. You may also use plain text values without any environment variable reference, though this is not recommended.

deployments:
  MyApp:
    dockerimage:
      example.io/bobkane/bobkane/myapp-repo:master
    docker_registry:
      server: example.io
      username: bobkane
      password: $REGISTRY_PASSWORD

We strongly recommend defining environments variables using the Squash interface to keep them secure.