run
The hyper run
command first creates
a writeable container layer over the specified image, and then starts
it using the specified Docker images. That is, hyper run
is equivalent to the API /container/create
then /container/(id)/start
. A stopped container can be restarted with all its previous changes intact using hyper start
. See hyper ps -a
to view a list of all containers.
Examples
Set working directory (-w)
The -w
lets the command being executed inside directory given, here /path/to/dir/
. If the path does not exists it is created inside the container.
Note: this works when there is only one Docker image in the container
Mount volume (-v)
The mount is created inside the container's /world
directory. Hyper does not support relative paths for mount points inside the container.
Load data (-v)
Besides mounting a volume, -v
also allows to load data from either local computer (where the command is issued) or a URI:
A new volume will be automatically created and populated with data, and then mounted onto the container.
Set environment variables (-e, --env, --env-file)
This sets environmental variables in the container. For illustration all three flags are shown here. Where -e
, --env
take an environment variable and value, or if no =
is provided, then that variable's current value is passed through (i.e. $MYVAR1
from the host is set to $MYVAR1
in the container). When no =
is provided and that variable is not defined in the client's environment then that variable will be removed from the container's list of environment variables. All three flags, -e
, --env
and --env-file
can be repeated.
Regardless of the order of these three flags, the --env-file
are processed first, and then -e
, --env
flags. This way, the -e
or --env
will override variables as needed.
The --env-file
flag takes a filename as an argument and expects each line to be in the VAR=VAL
format, mimicking the argument passed to --env
. Comment lines need only be prefixed with #
An example of a file passed with --env-file
Expose incoming ports
With the exception of the EXPOSE
directive, an image developer hasn’t got much control over networking. The EXPOSE
instruction defines the initial incoming ports that provide services. These ports are available to processes inside the container. An operator can use the --expose
option to add to the exposed ports.
Container's exposed ports are only accessible by user's containers by default, even a fip is attached to the container. To publish a container’s internal port to public, an operator can start the container with the -P
or -p
flag. The published port is available to any client that can reach the container.
Note: The maximum published ports are 32.
Set metadata on container (-l, --label, --label-file)
A label is a key=value
pair that applies metadata to a container. To label a container with two labels:
The my-label
key doesn't specify a value so the label defaults to an empty string(""
). To add multiple labels, repeat the label flag (-l
or --label
).
The key=value
must be unique to avoid overwriting the label value. If you specify labels with identical keys but different values, each subsequent value overwrites the previous. Hyper uses the last key=value
you supply.
Use the --label-file
flag to load multiple labels from a file. Delimit each label in the file with an EOL mark. The example below loads labels from a labels file in the current directory:
The label-file format is similar to the format for loading environment variables. (Unlike environment variables, labels are not visible to processes running inside a container.) The following example illustrates a label-file format:
You can load multiple label-files by supplying multiple --label-file
flags.
Attach to STDIN/STDOUT/STDERR (-a)
The -a
flag tells hyper run
to bind to the container's STDIN
, STDOUT
or STDERR
. This makes it possible to manipulate the output and input as needed.
This pipes data into a container and prints the container's ID by attaching only to the container's STDIN
.
This isn't going to print anything unless there's an error because we've only attached to the STDERR
of the container. The container's logs still store what's been written to STDERR
and STDOUT
.
This is how piping a file into a container could be done for a build. The container's ID will be printed after the build is done and the build logs could be retrieved using hyper logs
. This is useful if you need to pipe a file or something else into a container and `retrieve the container's ID once the container has finished running.
Restart policies (--restart)
Use Hyper's --restart
to specify a container's restart policy. A restart policy controls whether to restart a container after exit. The policy will be triggered if the uptime of a container is more than 10 seconds. Hyper supports the following restart policies:
Policy | Result |
no | Do not automatically restart the container when it exits. This is the default. |
on-failure[:max-retries] | Restart only if the container exits with a non-zero exit status. Optionally, limit the number of restart retries |
always | Always restart the container regardless of the exit status. When you specify always, Hyper will try to restart the container indefinitely. The container will also always start on daemon startup, regardless of the current state of the container. |
unless-stopped | Always restart the container regardless of the exit status, but do not start it on daemon startup if the container has been put to a stopped state before. |
This will run the redis
container with a restart policy of always so that if the container exits, Hyper will restart it.
Add security groups(--sg)
The --sg
flag tells hyper run
to add security groups to the container. A security group acts as a virtual firewall that controls the traffic for one or more containers.
Note:
ssh
andweb
are the name of security groups associated with the new container.
No automatic image volumes (--noauto-volume)
The --noauto-volume
option tells Hyper service not to create new volumes for VOLUME
sections in the container image. If not specified, hyper run
will automatically create volumes for each VOLUME
section in the container image.
Enable termination protection (--protection)
The --protection
flag enables (disable) termination protection to container. A protected container cannot be removed unless the protection is disabled by hyper update --protection=false <container>
.
Mount shared volumes (--volumes-from)
The --volumes-from
option mount all shared volumes from another container using NFS protocol. The volumes must be created with hyperhq/nfs-server
image, which automatically expose all volumes via NFS. The volumes will be mounted under the same paths as in the hyperhq/nfs-server
container.
Last updated