Sample YAML file configurations
Docker & Docker Compose configurations
Here you have a web app defined in a Dockerfile, this web app has an HTTP service running on port 3000.
deployments: MyApp: filename: ./src/Dockerfile context_path: ./src 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
Loading data during the build process
The example below will copy a development database (from Squash’s assets storage) to the same folder where the Dockerfile is built. You can then reference this datafile within your application build process as you see fit. For more details, see copy_files and copy_files_build_process.
deployments: MyApp: filename: ./Dockerfile copy_files_build_process: - /assets/sanitized-db.zip ~/code/sanitized-db.zip
Docker Compose example
With Docker Compose you can define clusters with multiple containers. Here is a basic example of a Squash YAML file using Docker Compose:
deployments: MyApp: filename: ./docker-compose.yml 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
Accessing specific microservices from subdomains
Using subdomain port mapping you can associate specific microservices to a unique HTTP endpoint. In the example below we have two microservices running on ports 8085 and port 8082. We have mapped them to subdomains “inventory-api” and “sales-api”. You can access these endpoints from a web browser by using the following syntax, assuming a deployment for branch name “cartv3” (note the double dash
"--" bit to indicate a Squash subdomain):
deployments: MyApp: filename: ./docker-compose.yml 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 subdomain_port_mapping: - inventory-api:8085 - sales-api:8082
Using a private Docker Registry
The app below is entirely defined within a Docker image stored in a private Docker Registry:
deployments: MyApp: dockerimage: my-registry.io/ace-corp/my-repo:master docker_registry: server: my-registry.io username: my-username password: $REGISTRY_PASSWORD
Using a separate database service
For this example we want to share a database with multiple feature deployments. This is easy to do with Non-HTTP based deployments. Note that the InventoryApp defined at the bottom is relying on a DatabaseService deployment. With the setup below you can have multiple feature branches of InventoryApp accessing the same instance of DatabaseService.
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/master:DatabaseService
YAML file based Apps (Apps without Docker)
If your applications are not currently defined as Docker files you can still use Squash by defining the entire build process within the Squash YAML file.
Example of a Python based web app:
deployments: MyWebApp: dockerimage: ubuntu:14.04 build_steps: - apt-get update && apt-get install -y libssl-dev libpq-dev git \ python python-dev python-pip python-virtualenv - pip install setuptools pip - pip install /code launch_steps: - cd /myproject/mysite - python manage.py runserver 0.0.0.0:80
You may also define your own private images when the “docker_registry” field is defined.
Please refer to our Kubernetes page for configuration samples.