Container Parameters #

...
apps:
  <APPNAME>:
    ...
    container:
      command:
        - server
        - start
      entrypoint:
        - /entrypoint.sh
      health_check:
        command:
          - /bin/sh
          - -c
          - "curl -s http://localhost:$PORT/.well-known/health-check | grep ok"
        interval: 10
        timeout: 5
        retries: 3
        start_period: 5
      timeouts:
        start_timeout: 60
        stop_timeout: 120
    ...

command (optional) #

Every App has a command with which the container is started. If you don’t set a command for an app, the default command specified in the Dockerfile (or in the upstream Docker image) is used. Every parameter is a separate list item.

entrypoint (optional) #

The entrypoint of an App is used to configure the executable binary to start the container with. For example, when developing a Rails app, the entrypoint could be ["/usr/bin/bundle", "exec"], with:

• ["rails server"] as a command for the web app
• ["rake jobs:work"] as a command for the worker app.

The entrypoint in SetOps works just like the ENTRYPOINT directive in a Dockerfile.

If you don’t set an entrypoint for an app, the default entrypoint specified in the Dockerfile (or in the upstream Docker image) is used. Every parameter is a separate list item.

health_check (optional) #

The Container health check configuration determines how the health of a container is monitored. The system periodically runs a command you specify inside your App’s container. The command exit code determines the healthiness of the container. When it returns with exit code 0, the check is deemed successful. Should it return with any other exit code, the check is failed and the container is unhealthy. After the given grace period specified by interval, timeout, retries, and start_period, the container will be terminated and replaced with a new one. It is recommended to set the start_period to a big enough value so that the app can start and warm up and the interval, timeout and retries to a low value so that downtimes are quickly detected.

Check out the health checks section for more details about the difference between the container.health_check and network.health_check fields.

The Container health check is optional (off by default), but highly recommended. When configured, all parameters are required:

For an App with Protocol http, you could use curl (or wget) as a command to verify the app server is running correctly:

...
apps:
  <APPNAME>:
    ...
    container:
      ...
      health_check:
        command:
          - /bin/sh
          - -c
          - "curl -s http://localhost:$PORT/.well-known/health-check | grep ok"

You can use automatically configured environment variables such as $PORT in you command. Ensure that you are using a shell like /bin/sh in your command so that the variables get interpreted and replaced correctly.

For an App with Protocol tcp, you could use nc (netcat) to verify the app server is running. Note this only checks whether the port is open, not if the app is doing something useful.

...
apps:
  <APPNAME>:
    ...
    container:
      ...
      health_check:
        command:
          - /bin/sh
          - -c
          - "/bin/sh -c \"echo '' | nc localhost 5000\""

The health check command must be installed within the App’s Docker image. For example, when using curl for the Health Check command, make sure the curl binary is present in the image and the $PATH environment variable is set correctly.

timeouts (optional) #

You may configure two timeout values for a container, the start_timeout and stop_timeout.

The start timeout is the time duration (in seconds) to wait before giving up on resolving dependencies for a container. For example, you specify two containers in a task definition with containerA having a dependency on containerB reaching a COMPLETE, SUCCESS, or HEALTHY status. If a start_timeout value is specified for containerB and it doesn’t reach the desired status within that time then containerA gives up and not start. This results in the task transitioning to a STOPPED state.

| Usually you will not need to change the default value for the stop_timeout.

The stop timeout (in seconds) is a value between 2 and 120 and determines the duration to wait before the container is forcefully killed if it doesn’t exit normally on its own. The default value is 60 seconds, if an app requires more time for a graceful shutdown, it can be increased up to 120 seconds. An app containe in a STOPPING status first sends a SIGTERM signal, which an app may react to with a graceful shutdown procedure. After the stop timeout, a SIGKILL signal stops the container.

Going further #

Configure Network Settings