CMD
and/or ENTRYPOINT
declaration, a single implicit cmd
service will be created for it when you deploy your App.
Containers for the implicit cmd
Service will execute the CMD
your image defines (if you have an ENTRYPOINT
defined, then the CMD
will be passed as arguments to the ENTRYPOINT
).
This corresponds to Docker’s behavior when you use docker run
, so if you’ve started Containers for your image locally using docker run my-image
, you can expect Containers started on Aptible to behave identically.
Typically, the CMD
declaration is something you’d add in your Dockerfile, like so:
📘 Using an implicit service is recommended if your App only has one Service.
web
or worker
while implicit services use the cmd
or ENTRYPOINT
defined in the image.
Procfile
at the root of your repository.
/.aptible/Procfile
in your Docker image. See
Procfiles and .aptible.yml
with Direct Docker Image Deploy
for more information.
📘 Note the following when using Procfile:
-Procfile syntax: The Procfile syntax is standardized, and consists of a mapping of one or more Service names to commands that should be executed for those Services. The two should be separated by a :
character.
-Procfile commands: The commands in your Procfile (i.e. the section to the right of the : character) is interpreted differently depending on whether your image has an ENTRYPOINT or not:
ENTRYPOINT
ENTRYPOINT
, the Procfile will be executed using a shell (/bin/sh
). This means you can use shell syntax, such as:
📘 The following is advanced information. You don’t need to understand or leverage this information to use Aptible, but it might be relevant if you want to precisely control the behavior of your Containers. PID 1 is the process that receives signals when your Container is signaled (e.g. PID receivesIf you’d like to get the shell out of the equation when running your Containers, you can use the exec call, like so:SIGTERM
when your Container needs to shut down during a deployment). Since a shell is used as the command in your Containers to interpret your Procfile, this means PID 1 will be a shell. Shells don’t typically forward signals, which means that when your Containers receiveSIGTERM
, they’ll do nothing if a shell is running as PID 1. As a result, running a shell there may not be desirable.
ENTRYPOINT
ENTRYPOINT
, Aptible will not use a shell to interpret your Procfile. Instead, your Procfile line is split according to shell rules, then simply passed to your Container’s ENTRYPOINT
as a series of arguments.
For example, if your Procfile looks like this:
ENTRYPOINT
will receive the literal strings run
and $ENVIRONMENT
as arguments (i.e. the value for $ENVIRONMENT
will not be interpolated).
This means your Procfile doesn’t need to reference commands that exist in your Container: it only means to reference commands that make sense to your ENTRYPOINT
.
However, it also means that you can’t interpolate variables in your Procfile line. If you do need shell processing for interpolation with an ENTRYPOINT
, here are two options:
Call a shell from the Procfile
The simplest option is to alter your Procfile
to call a shell itself, like so:
/app.sh
in your image, with the following contents, and make it executable:
/app.sh
isn’t the only one that works! Just make sure the Procfile references the launcher script.