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
    ...

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:

Parameter Valid Values Default Description
command any command, e.g. ["/bin/sh", "-c", "curl -s http://localhost:5000/healthz \| grep pong"] - Specifies the command that is used to determine the App’s health.
interval 1-30 10 Determines the interval in which the App’s health is checked in seconds.
timeout 1-30 10 Specifies the time in seconds the App has to respond in.
retries 1-30 5 Configures the number of retries the health check will attempt before declaring the App not healthy.
start-period 0-60 15 Defines when the health check is attempted for the first time after starting the App.

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.

Going further #

Configure Network Settings