In the previous post, Getting started with Kubernetes on Azure, we talked about creating a Kubernetes cluster and deploying a couple of services. There are basically two services:
- Data: a service that exposes an endpoint to pick up data for an IoT device; you call it with http://service_endpoint:8080/data/devicename
- Device: a service that can be used by the Data API to check if a device exists; if the device exists you will see that in the response
When you call the Data service, it will call the Device service using gRPC, using HTTP as the transport protocol. You define the service using Protocol Buffers. gRPC works across languages and platforms, so I could have implemented each service using a different language like Go for the Device service and Node.js for the Data service. In this example, I decided to use Go in both cases and use Go Micro, a pluggable RPC framework for microservices. Go Micro uses gRPC and protocol buffers under the hood with changes specific to Go Micro.
Ok, enough with the talk, let’s take a look how it is done. The Device service is kept extremely simple for an abvious reason: I just started with Go Micro and then it is best to start with something simple. I do expect you know a bit of Go from here on out. All the code can be found at https://github.com/gbaeke/go-device.
Lets start with the definition of Protocol Buffers, found in proto/device.proto:
syntax = "proto3";
service DevSvc {
rpc Get(DeviceName) returns (Device) {}
}
message DeviceName {
string name = 1;
}
message Device {
string name = 1;
bool active = 2;
}
We define one RPC call here that expects a DeviceName message as input and returns a Device message. Simple enough but this does not get us very far. To actually use this in Go (or another supported language), we will generate some code from the above definition. You need a couple of things to do that though:
- protoc compiler: download from Github for your platform
- protobuf plugins for code generation for Go Micro: run
go get github.com/micro/protobuf/{proto,protoc-gen-go}(if you have issues, use 2 gets, one for proto and one for protoc-gen-go)
To actually compile the proto file, use the following command:
protoc --go_out=plugins=micro:. device.proto
That compiles device.proto to device.pb.go with help from the micro plugin. You can check the generated code here. Among other things, there are Go structs for the DeviceName and Device message plus several methods you can call on these structs such as Reset() and String().
Now for main.go! You’ll need several imports: for the generated code but also for the dependencies to build the service with Go Micro. If you check the code, you will also find the following import:
_ "github.com/micro/go-plugins/registry/kubernetes"
As stated above, Go Micro is a pluggable RPC framework. Out of the box, a microservice written with Go Micro will try to register itself with Consul on localhost for service discovery and configuration. We could run the Consul service in Kubernetes but Kubernetes supports service registration natively. Kubernetes support is something you add with the import above. That is not enough though! You still need to tell Go Micro to use Kubernetes as the registry, either with the —registry command line parameter or with an environment variable MICRO_REGISTRY. Check https://github.com/gbaeke/go-device/blob/master/go-device-dep.yaml file where that environment variable is set. Besides Consul and Kubernetes, there are other alternatives. One of them is multicast DNS (mdns) which is handy when you are testing services on your local machine and you don’t have something like Consul running.
If you want to check the information that is registered, you can do the following (after running kubectl proxy --port=8080):
curl http://localhost:8080/api/v1/pods | grep micro
Each pod will have an annotation with key micro.mu/service-<servicename> with information about the service such as its name, IP address, port, and much more.
Now really over to main.go, which is pretty self explanatory. There’s a struct called DevSvc which has a field called devs which holds the map of strings to Device structs. The DevSvc actually defines the service and you write the RPC calls as methods of that struct. Check out the following code snippet:
// DevSvc defines the service
type DevSvc struct {
devs map[string]*device.Device
}
func (d *DevSvc) Get(ctx context.Context, req *device.DeviceName, rsp *device.Device) error {
device, ok := d.devs[req.Name]
if !ok {
fmt.Println("Device does not exist")
return nil
}
fmt.Println("Will respond with ", device)
// this also works
rsp.Name = device.Name
rsp.Active = device.Active
return nil
}
The Get function implements what was defined in the .proto file earlier and uses pointers to a DeviceName struct as input and a pointer to a Device struct as output. The code itself is of course trivial and just looks up a device in the map and returns it with rsp.
Of course, this handler needs to be registered and this happens in the main() function (besides setting up the service and implementing a custom flag):
// register handler and initialise devs map with a list of devices
device.RegisterDevSvcHandler(service.Server(), &DevSvc{devs: LoadDevices()})
If you want to test the service and call it (e.g. on the local machine) then clone the repository (or get it) and run the server as follows:
go run main.go --registry=mdns
In another terminal, run:
go run main.go --registry=mdns --run_client
When you run the code with the run_client option, the runClient function is called which looks like:
func runClient(service micro.Service) {
// Create new client to call DevSvc service
DevClient := device.NewDevSvcClient("go.micro.srv.device", service.Client())
// Call Get to get a device
rsp, err := DevClient.Get(context.TODO(), &device.DeviceName{Name: "device2"})
if err != nil {
fmt.Println(err)
return
}
// Print response
fmt.Println("Response: ", rsp)
}
This again shows the power of using a framework like Go Micro: you create a client for the DevSvc service and then simply perform the remote procedure call with the Get method, passing in a DeviceName struct with the Name field set to the device you want to check. The client uses the service registry to know where and how to connect. All the serialization and deserialization is handled for you as well using protocol buffers.
So great, you now have a little bit more information about the Device service and you know how to deploy it to Kubernetes. In another post, we’ll see how the Data service works and explore some other options to write that service.
