Deploy Our Microservice

In this step we'll learn how to deploy our newly created microservice to our ioFog tutorial environment.

Before deploying our new microservice, take a look at the current output of the Freeboard at http://localhost:10102/?load=dashboard.json

Register Our Docker Image

With our Docker image from the previous step in hand, it's time to publish it to a Docker Registry.

While we can use a custom registry (or the public Docker Hub), the Controller also comes with a built-in private registry that represents the local cache on the ioFog edge compute nodes.

To get a list of the container registries, we can use the legacy Controller CLI registry list command:

iofogctl legacy controller local-controller registry list

We should see two registries. The first is Docker Hub and the second is the built-in private registry, which we're going to use.

{
  "id": 2,
  "url": "from_cache",
  "isPublic": true,
  "isSecure": true,
  "certificate": "",
  "requiresCert": false,
  "username": "",
  "userEmail": "",
  "userId": null
}

The unique ID for the built-in registry is always 2, and always 1 for Docker hub.

Add Our Microservice

The Docker image containing our microservice code is registered with our local image cache. We can spin up new copies of it using the Controller through iofogctl.

If you spent some time looking around the folder structure, you might have noticed the file init/tutorial/config.yaml

$ cat init/tutorial/config.yaml
---
apiVersion: iofog.org/v1
kind: Application
metadata:
  name: tutorial
spec:
  microservices:
    - name: Sensors
      agent:
        name: local-agent
      config: {}
      images:
        x86: iofog/sensors:latest
        registry: remote
      volumes: []
      ports: []
      env: []
    - name: Rest API
      agent:
        name: local-agent
      config: {}
      images:
        x86: iofog/freeboard-api:latest
        registry: remote
      volumes: []
      ports:
        - internal: 80
          external: 10101
      env: []
    - name: Freeboard
      agent:
        name: local-agent
      config: {}
      images:
        x86: iofog/freeboard:latest
        registry: remote
      volumes: []
      ports:
        - internal: 80
          external: 10102
      env: []
  routes:
    - from: Sensors
      to: Rest API

This yaml file has been used to describe to iofogctl what our set of microservices (application) should look like, and how they are configured. You can find a complete description of the YAML format here, but for now let's focus on the main parts.

The file describes an application, named tutorial.
It has 3 microservices.
Each microservice runs on the agent named local-agent.
Each microservice has its own docker image for x86 devices.
Some microservices expose ports.
There is a route from the Sensors microservice to the Rest API microservice.

To add our new microservice, go ahead and edit this file by adding our new microservice to the list of microservices:

---
- name: Moving Average
  agent:
    name: local-agent
  config:
    maxWindowSize: 40
  images:
    x86: iofog-tutorial/moving-average:v1
    registry: local
  volumes: []
  ports: []
  env: []

It is very important to note that we are specifying local as the value for images:registry (instead of remote for the other microservices), this instructs the ioFog Agent to use its local cache, and not Docker hub.

Setup Our Routes

Let's change our routes so that our new microservice is placed between the Sensors and the REST API.

Edit the routes section from the YAML file to the following.

routes:
  - from: Sensors
    to: Moving Average
  - from: Moving Average
    to: Rest API

Which will effectively create the following pipeline for our data Sensor -> Moving Average -> Rest API

Update the application

Now that our config YAML file is ready and describes the new state of our application, we can use iofogctl to deploy our application.

$ iofogctl deploy application -f init/tutorial/config.yaml

Verify that the application got updated as expected

$ iofogctl get microservices

MICROSERVICE	STATUS		AGENT		CONFIG		          ROUTES		    VOLUMES		PORTS
Rest API	    RUNNING		local-agent	{}						                            10101:80
Freeboard	    RUNNING		local-agent	{}						                            10102:80
Moving Average	QUEUED		local-agent	{"maxWindowSize":40}  Rest API
Sensors		    RUNNING		local-agent	{}		              Moving Average

It will take some time for the ioFog Agent to spin up the new microservice. You can monitor the status of our newly created microservice using iofogctl get microservices.

If you don't have access to the YAML file describing your application, you can always retrieve it using iofogctl and running: iofogctl describe application APPLICATION_NAME [-o config.yaml]

Update a Microservice

Once a microservice is up and running, we will probably need to modify it later, which we can also do with the Controller.

You can either redeploy the entire application using the same steps we just did. Iofogctl is smart enough to only patch the required changes to an existing application.

But you can also directly deploy a microservice! First, let's use iofogctl to retrieve the microservice configuration for our Moving Average microservice.

$ iofogctl describe microservice 'Moving Average' -o moving-average.yaml && cat moving-average.yaml

apiVersion: iofog.org/v1
kind: Microservice
metadata:
  name: Moving Average
  namespace: default
spec:
  uuid: H3cZ2LQ9hxyM6X7X6xV2q2w6mH3zp7Wc
  name: Moving Average
  agent:
    name: local-agent
    config:
      dockerUrl: unix:///var/run/docker.sock
      diskLimit: 50
      diskDirectory: /var/lib/iofog-agent/
      memoryLimit: 1024
      cpuLimit: 80
      logLimit: 10
      logDirectory: /var/log/iofog-agent/
      logFileCount: 10
      statusFrequency: 30
      changeFrequency: 60
      deviceScanFrequency: 60
      bluetoothEnabled: false
      watchdogEnabled: false
      abstractedHardwareEnabled: false
  images:
    catalogId: 0
    x86: iofog-tutorial/moving-average:v1
    arm: ""
    registry: local
  config:
    maxWindowSize: 40
  rootHostAccess: false
  ports: []
  volumes: []
  env: []
  routes:
  - Rest API
  application: tutorial

You will notice a few minor changes compared to the description we provided when we deployed the microservice as part of our application:

We now have an application field. This is required for iofogctl to know which application the microservice is part of.
The microservice routes destinations are listed under a routes field.
We have many more fields related to the required configuration of the ioFog Agent.

Find the complete yaml description here

Now let's say we want to update the configuration of our microservice!

Go ahead and edit the newly created moving-average.yaml file, and update the config field (Warning: not the agent:config, but the root config field) to the following:

config:
  maxWindowSize: 100

Then you can use iofogctl to deploy your microservice

$ iofogctl deploy -f moving-average.yaml

And see the result with

$ iofogctl get microservices

MICROSERVICE	STATUS		AGENT		CONFIG			        ROUTES		VOLUMES		PORTS
Rest API	    RUNNING		local-agent	{}							                    10101:80
Freeboard	    RUNNING		local-agent	{}							                    10102:80
Moving Average	RUNNING		local-agent	{"maxWindowSize":100}	Rest API
Sensors		    RUNNING		local-agent	{}			            Moving Average

Conclusion

Have a look at new output of the Freeboard dashboard. This should now display the values modified by moving average and look similar to this:

The magic about microservices and ioFog is that none of those microservice is specifically designed or requires to work with the other microservice. Using ioFog, you can create smart and secure communication channels between independant microservices and easily manage a fleet of Edge devices and microservices.

Congratulations! You've now have the fundamentals of ioFog. Next, try developing Microservices on an ECN deployed on remote hosts. See this guide for deploying remotely.