Registries

When configuring an Darcy Cloud application YAML file, it is necessary to specify the registry of each microservice container image. The field for this specification is spec.microservices.image.registry, and the registry tells the node the microservice is being deployed to how to access the image container.

There are 3 options for a registry:

1. local

   When an image registry is set to local, the container image will be pulled from the local cache of the node when initially deploying the microservice to the node.

2. remote

   When an image registry is set to local, the container image will be pulled from the local cache of the node when initially deploying the microservice to the node.

3. [registry_id]

   When an image registry is set to a specific registry ID, the container image will be pulled using the registry key when initially deploying the microservice to the node. The registry key must have permission to access the container images.

What is a Darcy Cloud Registry? #

Darcy Cloud registries are a clean, convenient way to give Darcy Cloud applications access to private Docker images or other containers that are being deployed to the Darcy Cloud.

Before adding a microservice with private container images (or with images not on Dockerhub) to a node in Darcy Cloud it is necessary to register a key with permissions to access the microservice container images to a project’s Darcy Cloud registry so that the microservice will be able to pull the container images upon being deployed.

Each registry is pre-configured with 2 entries. The first entry is for a remote registry ( the remote registry selection is just an alias for the value 1), and the second entry is for a local registry (the local registry selection is just an alias for the value 2). Additional entries to the registry can be created directly in ioFog as shown here , or they can be managed and created more simply using edgectl directly.

View Current Registry Content #

To see your current registry contents on your node(s), use the following command:

edgectl registry list

By default, this will return a JSON list where the first entry is the remote selection and the second entry is the local selection:

[
  {
    "id": 1,
    "url": "registry.hub.docker.com",
    "isPublic": true,
    "isSecure": true,
    "certificate": "",
    "requiresCert": false,
    "username": "",
    "email": ""
  },
  {
    "id": 2,
    "url": "from_cache",
    "isPublic": true,
    "isSecure": true,
    "certificate": "",
    "requiresCert": false,
    "username": "",
    "email": ""
  }
]

Creating New Entries #

To create a new entry in the registry, use the following command:

edgectl registry create

Use the --help command to see all of the available fields to be set when creating a new registry. If the --project field is empty, the the default project is used (if one is set).

Create a Registry Entry Using Google Cloud #

A simple way to give permissions to the Darcy Cloud to deploy applications is to create a Google Service Account key that has permissions to access the applications containers (whether they be on Dockerhub or elsewhere). A service account can be created by following the tutorial here .

Once a JSON key that has access to the desired containers is created, it can be added to the Darcy Cloud registry as shown below:

edgectl registry create --url "gcr.io" --username "_json_key" --password "$(cat /path/to/json_key_file.json)"

This will print out the information about the newly created entry in the registry:

ID  URL     USERNAME   EMAIL                                        PUBLIC
3   gcr.io  _json_key  s3g9gxfxpixcelledgeproject1@api.edgeworx.io  False

If you want to check all of the settings on the entry, you can run edgectl registry list again and verify that everything is set correctly.

Registry Example #

To use the registry to deploy an example, just add the registry keyword with the registry id to the images section of the microservice definition in the YAML file of the application being deployed to a node.

kind: Application
apiVersion: iofog.org/v3
metadata:
  name: example-private-registry
spec:
  microservices:
    - name: "example"
      agent:
        name: "{% raw %}
{% assign agent = \"\" | findAgent | first %}
{% endraw %}{{ agent.name }}"
      images:
        arm: "gcr.io/my-org/my-private-image:latest"
        x86: "gcr.io/my-org/my-private-image:latest"
        registry: 3 # Use the private registry ID here
      container:
        rootHostAccess: false
        ports: []
      config: {}