Prepare to use Release

In order to use Release, you must meet the prerequisites mentioned in the Welcome to Release overview.

Release supports building and running complex applications. Release requires a docker-compose.yml , package.json , or a .release.yaml file to be in the root of your application's git repository. Release uses these files to to generate the Application Template that is used as a blueprint to build your environments.

If your application has nested directories where your docker-compose.yaml or package.json files reside, you can add a .release.yaml file to the root of your repository to tell Release where these files are located. See the .release.yaml Reference Guide for more information.

We recommend using a monorepo and a directory-per-service at the project root when your application requires two or more services. Here is an example repository / filesystem layout for three service which require docker builds:

├── README.md
├── docker-compose.yml
├── result
│   └── Dockerfile
├── vote
│   └── Dockerfile
└── worker
    └── Dockerfile

If you're not using a monorepo, you can create an application for each repository and connect them together using environment variables in each of those applications. See Microservices architectures for more information.

Testing docker-compose for Release

The best way to test if your application will run in Release is to start by getting docker-compose to run your application locally. (See docker-compose overview for more details).

Release allows you to quickly spin up containerized services without the traditional wait times involved with cloud native services.

When running an application locally or in a Release Ephemeral Environment, it is recommended that you isolate your application's external dependencies. Consider using off-the-shelf Docker images to represent the cloud native services that your application depends on. (i.e. postgres, redis, etc...), Visit Docker Hub to find many off-the-shelf Docker images.

You can use environment variables to connect Ephemeral Environments to AWS native services such as RDS, however, we recommend using these off-the-shelf Docker images. These will speed up deployment and simplify setup.

This is an example of a docker-compose.yml file that builds three (3) Docker images and leverages two (2) off-the-shelf containers for redis and postgres:

version: "3"
services:
  vote:
    build: ./vote
    command: python app.py
    volumes:
      - ./vote:/app
    ports:
      - "5000:80"
    depends_on:
      - "worker"
​
  result:
    build: ./result
    command: nodemon server.js
    volumes:
      - ./result:/app
    ports:
      - "5001:80"
    depends_on:
      - "worker"
​
  worker:
    build:
      context: ./worker
    depends_on:
      - "redis"
      - "db"
​
  redis:
    image: redis:alpine
    container_name: redis
​
  db:
    image: postgres:9.4
    container_name: db
    volumes:
      - "db-data:/var/lib/postgresql/data"
​
volumes:
  db-data:

Release detects many popular services such as redis, mysql, postgres, rabbitmq, plus many more and will handle opening standard ports for these services.

version: "3"
services:
  redis:
    image: "redis:5-alpine"
​
  rabbitmq:
    image: "rabbitmq:3.7-alpine"
​
  memcached:
    image: "memcached:1.5-alpine"

Adding redis, rabbitmq and memcached with minimal configuration in docker-compose

Building your application

Release supports most options from docker-compose build. Release looks for all services with a build stanza and executes a docker build for each service found.

version: "3"
services:
  app:
    build: .

Specify the current working directory

version: "3"
services:
  vote:
    build: ./vote

Specify a different directory to build

version: "3"
services:
  mysql:
    build:
      context: .
      dockerfile: Dockerfile-mysql
      args:
        S3_BUCKET: "data.example.com"
        MYSQL_VERSION: "5.7"

Specify the dockerfile and pass in build arguments__

Release Ports and DNS Hostnames

Release uses the docker-compose ports (HOST:CONTAINER) definition to determine when a service should be exposed to the Internet. When Release encounters a service with a (HOST:CONTAINER) definition, it creates a node port, load balancer rule and DNS hostname entry for the service.

version: "3"
services:
  frontend:
    build:
      context: .
      dockerfile: Dockerfile-frontend
    ports:
      - "8080:8080"
    command: ["npm", "run", "dev-server-docker"]

In this example Release will create a hostname for the frontend service that exposes port 8080.

Internal services like your datastores, caches and background workers should not be exposed to the Internet and available only internally to other services defined in your docker-compose.

version: "3"
services:
  db:
    image: postgres:9.4
    ports:
      - "5432"

This example shows postgres opening a container port on 5432 that another service can consume.

Environment Variables

Most applications use environment variables to define how services talk to each other and/or change the behavior of an application in a given environment. Release uses the environment variables provided in your docker-compose as a starting point. All of the environment variables for each service defined in your docker-compose are loaded into Release when you initially create an application. Release supports all of the standard docker-compose mechanisms for defining environment variables:

version: "3"
services:
  api:
    build:
      context: ./api
      dockerfile: Dockerfile.django
    ports:
      - "8000:8000"
    env_file: .env

You can use env_file to specify an external env file.

version: "3"
services:
  nginx:
    build: .
    ports:
      - "5000:5000"
    environment:
      - AWS_REGION=us-west-2
      - AWS_SECRET_ACCESS_KEY=XXX
      - RESOLVER=8.8.8.8

Set environment variables directly in your docker-compose file

If you have dynamic or secret environment variables, read more here.