Configure Service Dependency step settings (Deprecated)
The Configure Service Dependency step is deprecated. Instead, use the Background step.
For a short time, this step will be backwards compatible. Any pipelines that include Configure Service Dependency steps will remain valid until the step is removed from Harness CI. You are encouraged to replace Configure Service Dependency steps with Background steps as soon as possible.
A service dependency is a detached service that's accessible to all steps in a stage. Service dependencies support workflows such as:
- Integration testing: You can set up a service and then run tests against this service.
- Running Docker-in-Docker: You can set up a DinD service to process Docker commands in Run Steps.
This topic provides settings and permissions for the Configure Service Dependency step.
Before You Begin
Review this important information about Configure Service Dependency steps.
Add a Health Check to Verify that the Service is Up
while ! docker ps ;do
echo "Docker not available yet"
Service and Step Networking
Service and Step containers within the same Stage all share the same network. To communicate with a Service, use the local-host address and the port number defined in the Docker image. For example, you can use
127.0.0.1:6379 to communicate with a Redis server or
localhost:27017 to communicate with a Mongo database (assuming the default ports aren't overridden).
In a Kubernetes build infrastructure, all steps run in containers. In an AWS build infrastructure, some steps might run directly on the VM. For more information, go to Port Bindings below.
Enter a name summarizing the step's purpose.
For information about this setting, go to Entity Identifier Reference.
Harness Connector for the container registry containing the Service Dependency image, such as Docker Hub.
The name of the Docker image.
The image name should include the tag and will default to the
latest tag if unspecified.
You can use any Docker image from any Docker registry, including Docker images from private registries.
Enable this option to run the container with escalated privileges. This is the equivalent of running a container with the Docker
Add any environment variables you want to inject into the container.
ENTRYPOINT instructions allow you to configure a container that will run as an executable.
You can add commands in Entry Point to override the image ENTRYPOINT. See ENTRYPOINT best practices from Docker.
Commands should be in exec form.
Each command and parameter should be added separately. For example:
For a useful summary of ENTRYPOINT and CMD see Demystifying ENTRYPOINT and CMD in Docker from AWS.
Overrides the image CMD. Each argument should be in exec format. For example:
For a useful summary of ENTRYPOINT and CMD, see Demystifying ENTRYPOINT and CMD in Docker in the AWS docs.
Depending on a pipeline's build infrastructure, some steps might run on a VM and others run in a container. The port used to communicate with the Service Dependency depends on where the step is running: VM steps use the Host Port and containerized steps use the Container Port.
Suppose you create a Service Dependency with the Name and Id
A containerized Step talks to the service using
A Run or Run Test Step that runs directly on the VM or in a Kubernetes cluster talks to the service using
The binding of Host and Container Ports is similar to port mapping in Docker. Usually the ports are the same unless the default Host Port for the service dependency is already in use by another local service.
Image Pull Policy
Select an option to set the pull policy for the image.
- Always: The kubelet queries the container image registry to resolve the name to an image digest every time the kubelet launches a container. If the kubelet encounters an exact digest cached locally, it uses its cached image; otherwise, the kubelet downloads (pulls) the image with the resolved digest, and uses that image to launch the container.
- If Not Present: The image is pulled only if it isn't already present locally.
- Never: The image is assumed to exist locally. The kubelet doesn't try to pull the image.
Run as User
Set the value to specify the user id for all processes in the pod, running in containers. See Set the security context for a pod.
Set container resources
These settings specify the maximum resources used by the container at runtime.
Maximum memory that the container can use. You can express memory as a plain integer or as a fixed-point number using the suffixes
M. You can also use the power-of-two equivalents
The maximum number of cores that the container can use. CPU limits are measured in cpu units. Fractional requests are allowed: you can specify one hundred millicpu as
100m. See Resource units in Kubernetes.
Timeout for the step. Once the timeout is reached, the Step fails and the Pipeline execution continues.