Service Discovery Mechanisms in the Replicated Native Scheduler

Service Discovery Mechanisms in the Replicated Native Scheduler

The Replicated Native Scheduler achieves service discovery through different means than one is used to when using Kubernetes or Docker Swarm. It does not attempt to support DNS based service discovery and overlay networks. All container communication can occur over the host networking stack for multi-node clusters, or over the docker0 bridge network when deploying to a single node. The Replicated Native Scheduler chooses to use its powerful internal templating engine to allow you to expose the address of services across a single node or a cluster. Template output can be used as input to the service’s containers via environment variables, config files, or directly in the container command.

Using the Host Networking Stack

When deploying an application to a multi-node cluster, the host networking stack is the best choice for service discovery. Replicated chooses not to use overlay networks to keep our stack minimal and compatible with versions of Docker down to 1.7.1. The address of a container or multiple containers in the host networking stack can be accessed from the template functions NodePrivateIPAddress and NodePrivateIPAddressAll respectively. When integrating, you may or may not choose to explicitly bind a container port to the host network. it is most common to expose a port if the service needs to be exposed to the internet or some external service or must access it on a known port. In most other cases the exposed and dynamically bound port can be accessed via the ContainerExposedPort and ContainerExposedPortAll template functions.

Example

components:
  - name: DB
    containers:
      - source: public
        image_name: redis
        version: latest
        publish_events:
          - name: Container redis started
            trigger: container-start
            subscriptions:
              - component: App
                container: freighter/counter
                action: start
  - name: App
    containers:
      - source: public
        image_name: freighter/counter
        version: "1.0"
        env_vars:
          - name: REDIS_HOST
            value: '{{repl NodePrivateIPAddress "DB" "redis" }}'
          - name: REDIS_PORT
            value: '{{repl ContainerExposedPort "DB" "redis" "6379" }}'

Using the docker0 Bridge Network

When deploying an application to a single node, it is recommended to use the default bridge network that ships with docker. Using this network increases security through isolation and increases interoperability, reducing complexity in your Replicated integration. Replicated exposes the bridge network address using the template function ThisNodeDockerAddress. Since all ports are exposed to each other automatically between containers on the bridge network, it is not recommended to expose ports to the host networking stack unless they need to be accessible by an external service.

Example

components:
  - name: DB
    containers:
      - source: public
        image_name: redis
        version: latest
        publish_events:
          - name: Container redis started
            trigger: container-start
            subscriptions:
              - component: App
                container: freighter/counter
                action: start
  - name: App
    containers:
      - source: public
        image_name: freighter/counter
        version: "1.0"
        env_vars:
          - name: REDIS_HOST
            value: '{{repl ThisNodeDockerAddress }}'
          - name: REDIS_PORT
            value: 6379