parallelize_app_imports
to deploy all the apps at the same time.kubernetes.io/os=windows
and kuberenetes.io/arch=arm64
. Click here for more information.setup
and patch
. When a new environment is created setup
is ran, and when code is pushed a patch
is run against that environment.Rules Schema
Rules Example
Example: App Imports excluding a service
Example: App Imports with many apps utilizing the parallel deploys
image
or from_services
must be present.Example cron job definitions to poll the frontend service and ping Redis
from_services
is not a good fitminute
hour
dayofmonth
month
dayofweek
Example proxy buffer settings for large web requests
Example settings for stickiness settings using a cookie
Example settings for applying a WAF ruleset to the ALB in (AWS-only)
cookie
to enable session affinity. See https://kubernetes.github.io/ingress-nginx/examples/affinity/cookie/balanced
to redistribute some sessions when scaling pods or persistent
for maximum stickiness.false
nginx ingress will send request to upstream pointed by sticky cookie even if previous attempt failed. When set to true
and previous attempt failed, sticky cookie will be changed to point to another upstream.Max-Age
cookie directive.INGRESSCOOKIE
).image
or from_services
must be present.Jobs Example
memory
: Limits and requests for memory are measured in bytes. You can express memory as a plain integer or as a fixed-point integer using one of these suffixes: E, P, T, G, M, K. You can also use the power-of-two equivalents: Ei, Pi, Ti, Gi, Mi, Ki. For example, the following represent roughly the same value: 128974848, 129e6, 129M, 123Minvidia_com_gpu
: Limits for Nvidia GPU units. (Do not specify requests:
). GPU limits can only be integer values and cannot be shared concurrently with other containers. You must also specify a node_selector to schedule a job or service on the correct worker node(s).cpu
: Limits and requests for cpu are represented in millicpu. This is represented by '{integer}m', e.x: 100m (guarantees that service will receive 1/10 of 1000m, or 1/10 of 1 cpu). You can also represent the cpu resources as fractions of integers, e.x. 0.1, is equivalent to 100m. Precision finer than '1m' is not allowed.replicas
: This number is the number of containers that will run during normal operation. This field is an integer, e.x: 5, that would make 5 of each service.storage
: Consists of two values size and type. Size accepts the same values as memory and type is the type of storage, whether aws-efs, empty_dir, or host_path.kubernetes.io/os=windows
and kuberenetes.io/arch=arm64
. Click here for more information.limits:
must be an integer value. Do not specify requests:
. GPU processors cannot be overprovisioned or shared with other containers.stateful
provides a StatefulSet which creates guarantees about the naming, ordering and uniqueness of a service.has_repo: true
.Example image scan that will fail the build if any CVE's with a serverity level of high are found. The scan also skips over CVE-123 because it is known that Release created that fake CVE in this documentation.
resources
key is removed and each directive cpu
, memory
, storage
, and replicas
can be defined individually. If they are not specified the defaults will be used.cpu
, memory
, nvidia_com_gpu
, and storage
define resource guarantees. The service definition for cpu, memory, nvidia_com_gpu, and storage overrides the values in resource_defaults. In the case of nvidia_com_gpu
, Kubernetes recommends setting limits:
but not requests:
, unless they are the same. You can use the service definition to more finely tune the amount cpu, memory, nvidia_com_gpu, and storage for each service.replicas
allows you to specify different amount of pods that will be deployed for your particular service.Example init container which inherits image from the main service
Example init container using busybox to wait for another service to startup
liveness_probe
and readiness_probe
are used to check the health of your service. When your code is deployed via a rolling deployment, the readiness_probe will determine if the service is ready to serve traffic before adding it to the load balancer. Release will convert the docker-compose healthcheck to a liveness_probe and readiness_probe. Both liveness_probe and readiness_probe allow for more advanced configuration beyond the docker-compose healthcheck definition.In this example we show the various types of probes that you can define for services along with overrides for resources and timeouts, while also defining static builds.