DEV Community: Michele Sciabarra

You can run kubectl from a docker container with Docker Desktop

Michele Sciabarra — Sat, 11 Dec 2021 18:38:38 +0000

In the process of setting up the development environment for Nuvolaris, I decided to switch from virtual machines to containers, leveraging the devcontainer feature of VSCode. Then I built a Docker image that is a perfect fit for our needs: there everything is in it to build our project.

But, I almost went on panic when I realized that, since a key component is an operator, and a cli that interacts with Kubernetes, we need to be able to access a Kubernetes cluster for development FROM a container.

In my initial plans, I would have setup a cluster Kubernetes in the virtual machine itself. But now, that everything is in a container? I actually felt initially very smart having the idea of setting up a Kubernetes cluster using kind. It is a tool that can build a Kubernetes cluster just using docker. But my plans went immediately awry because kind expects to be able to access to docker using localhost, and this is not the case within a container.

Even if I was able to access to docker from docker with a non-root user, inside the container there is not the proxy to localhost that is available outside a container. It is probably possible to configure kind to work anyway, but my first attempt failed.

Then I went in deep investigation mode, and I discovered that with Docker Desktop all the services are available using the domain docker.internal. And this domain is available also outside of the container. Then I thought that maybe it is possible to access to the Kubernetes that Docker itself provides from inside a container. maybe changing the configuration. Actually the situation is much better!

When you enable Kubernetes with Docker Desktop it creates a configuration file .kube/config that actually uses the domain kubernetes.docker.internalto talk to Kubernetes from the outside.

So I just copied the generated kubeconfig inside the container:

docker cp $HOME/.kube/conf container:/home/nuvolairs/.kube/config

and kubectl worked from inside the container, talking to Docker's Kubernetes!!!

Yes, this is a feature already available in Docker Desktop but not documented (or at least I was unable to find specific documentation for it).

I discovered it by myself and it saved my day and a week of efforts building the development environment that is now perfectly usable for our needs.

Building a multi-architecture development environment

Michele Sciabarra — Tue, 07 Dec 2021 10:21:25 +0000

When you start a project, that is as complex as nuvolaris (a new distribution of a Apache OpenWhisk), you need to be very careful in what you do, as your initial choices will be the hardest to change later.

Whatever you choose now, it will be shared by a number of people, they will learn your procedures, and they won't be happy if you change them. Also, even if you decide later to update them, your changes will disrupt the workflows and create friction in the team.

I am working hard, but for now is's a solo effort to prepare the development environment. And here I am evolving my decisions on how to develop Nuvolaris.

First I simply wrote a readme, mentioning the required components. But since there are so many, so I wrote a script setup.source using also the various nodenv pyenv and goenv to set the correct version of the programming languages to use.

Then I decided that was also wise to provide a stable environment to run everything, so I considered the option of using a virtual machine to run everything in the same way for everyone. So I spent some time tweaking with multipass to see if I could use this as a standard environment for development, as I mostly develop using VSCode with the Remote-SSH plugin and I use my server.

In the end my conclusion is that setting up multipass is complex enough to not be worth the effort. But I considered to use VSCode Remote-Container plugin, and it was a great find. I was aware of this but I haven't actually used it in the past, but it is great, as there are provisions to initialize the environments for the various programming languages!

A perfect fit for my needs. So I decided to use Remote-Containers instead and built a Dockerfile to create the perfect development environment for Nuvolaris with all the development tools inside. So you can develop on Linux, Mac or Windows, and even on the web using CodeSpaces!

My only regret was that I actually use a Mac with ARM M1. It is not a problem, as I do not develop in it. As I said, I use a remote, Intel based, server with VSCode Remote-SSH. I personally can't use the Remote-Container simply because the image I built is intel based (and please, do not talk of emulating Intel in Docker for ARM as it is considerably slower).

Then I wondered: why not support ALSO ARM? Actually, we would like to support Nuvolaris on multiple Kubernetes distributions, and yesterday we discussed of building clusters of Kubernetes with Raspberry PIs and it would be awesome to have Nuvolaris running on those!

So I decided to go with this option too, and I decided to support ALSO arm64 from day one. In the end we are going to build Nuvolaris to work on a variety of Kubernetes environments, both on Intel and ARM architectures. And I am now building the development environment to be multi-architecture so you can work on a Windows PC, on a Mac with M1 chips and even on a Raspberry PI, as long as you have Docker.

Stay tuned.

Deploy a MicroK8s cluster with cloud-init

Michele Sciabarra — Wed, 09 Jun 2021 21:21:47 +0000

If you need to run Kubernetes, today very frequently you just pick one managed in some cloud provider. However this option is frequently expensive. A cheaper option is to get a bunch of virtual machines and install Kubernetes in it.

Creating a Kubernetes cluster actually today is pretty simple, using tools like MicroK8s but there are still some manual actions to take.

To make cluster building even simpler, you can use for example cloud-init, the standard for cloud image initialization. So I decided to write a cloud-init that can automatically build a cluster for you.

The result is here, you can download it with this command:

curl -sL bit.ly/microk8s-init >microk8s-init.yaml

To entirely automate the cluster generation I had to use a couple of tricks.

First I assigned statically an IP address to virtual machines. I assign ips to virtual machines using a number that is expected to be included in the hostname. Second I generate "programmatically" a token to join the cluster.

There are hence a couple of parameters you may need to customize before using it. You may need to change the NET parameter. All the virtual machines will get an IP in that network according to the host name. For example, the virtual machine kube1 will get the address 10.0.0.1. Also note that the 1 virtual machine is always the one used to join the cluster

Also for security you may want to change the PASS parameter that is the password used to generate the unique token for joining the cluster.

The script can be used in many different environments. The low hanging fruit to use it is wth multipass, another handy tool from Ubuntu to launch virtual machines in multiple environments.

Microk8s requires at least 2gb of memory to run and 2 vcpu. You can hence test the script with the following commands to create the first node of a local cluster:

multipass launch -nkube1 -m3g -c2 --cloud-init microk8s-init.yaml

Sometimes it will time out during the initialization so you may need to wait for it to complete with

multipass exec kube1 -- sudo cloud-init status --wait

You can then launch more instances and wait for them:

multipass launch -nkube2 -m2g -c2 --cloud-init microk8s-init.yaml
multipass exec kube2 -- sudo cloud-init status --wait
multipass launch -nkube3 -m2g -c2 --cloud-init microk8s-init.yaml
multipass exec kube3 -- sudo cloud-init status --wait

You can finally extract the configuration file and check for the cluster status with:

multipass transfer kube1:/etc/kubeconfig ~/.kube/config
kubectl get nodes

How to create a REST API in 1 minute

Michele Sciabarra — Thu, 03 Jun 2021 09:07:18 +0000

go to www.nimbella.com
click on Login
use your GitHub account to sign in
click on Console
go to Workbench
select the playground
edit your serverless code (or just use an example)
copy the URL
curl it!

Nimbella in a nutshell

Michele Sciabarra — Tue, 06 Apr 2021 07:39:12 +0000

So you may wonder what is Nimbella.

Nimbella is a serverless development platform, similar to Amazon Lambda and similar serverless offerings by other cloud providers.

The distinctive feature of Nimbella is that is based on open-source software, Apache OpenWhisk and it is portable among different cloud providers, so you can also install it in your private cloud on-premises.

Nimbella's goal is to make easy cloud-native development and provide an awesome development experience. Developers are entitled to build their applications with microservices from the ground up.

Nimbella offerings include the multi-tenant public offering allowing developers to build their applications in the cloud.

Their applications can then be deployed in a private cloud, either on-premises or in any other public that provides a Kubernetes cluster.

Jump Start with Nimbella

Michele Sciabarra — Mon, 05 Apr 2021 15:12:07 +0000

I am starting a series of posts, that is going to cover Nimbella, an open-source serverless platform.

We start learning how to do the signup in Nimbella, which offers a free account for development. We are going to install the nim tool, the command-line interface to interact with Nimbella. Nimbella is also available on-premises in private clouds.

Then we go through actions, which are the building blocks of Nimbella applications. We will see how to create and update actions. Furthermore, actions can be invoked. Each invocation leaves a track as an activation. We are going to see how to check those activations, inspecting logs and results.

Nimbella also includes event handling, in the form of trigger and rule. We complete the chapter going into the details, with an example using slack, and another using timed execution.

Nimbella in a Nutshell

Learn serverless programming playing a game

Michele Sciabarra — Fri, 18 Dec 2020 06:05:20 +0000

FAAS Wars is a free programming game where you have to write the code that controls a "FAAS fighter". It is availablehere.

The fighter is a spaceship that can move in space and shoot lasers. The goal of the game is to defeat the enemy fighter, hitting it 5 times, and of course avoiding the bullets of the enemy.

To control a fighter you have to write the control code. The control code itself is a Nimbella serverless action. In the following, there is a tutorial about how to write a progressively smarter control action.

We are using javascript as the programming language. You can use however any other programming language available in Nimbella, like Python or Go. All the actions receive their input in JSON format and return the output in JSON, too. So the logic described in javascript can be readily translated into any other programming languages.

Let's start now, discussing how to create your fighter control code with a step by step tutorial.

How to control your fighter

A serverless action suitable for Faas WARS in its simplest form has this format:

function main(args) {
    return {"body": []}
}

Any Nimbella action returns a map. In our case, we need a web action returning JSON, so you have to use body as a mandatory field of your object. The resulting answer has to be an array of maps. In the simplest case, it is just an empty array. However, if you implement this action way your fighter will simply do nothing at all. Just sit down waiting to be hit by the enemy.

You can send commands to the fighter. A command is a map, where the keys are the commands given to the robot and the values are the parameters of the command. For example, you can order the fighter to "yell" something. If you want your robot displays the current time, you can order it with { "yell": new Date().toLocaleTimeString()}. Let's put it in an entire action:

function main(args) {
    let msg = new Date().toLocaleTimeString()
    return {"body": [{"yell":msg}]}
}

If you start the battle, you can see not the fighter is telling the current time. As it is not doing anything else, it will not survive for very long if there is a minimally offensive another fighter in the battleground. Indeed, this example is not very useful, battle-wise, but nonetheless, we see our robot is doing something, now!

Let's learn how to move around our fighter. As we already pointed out, the action returns an array of commands, so you can give multiple orders.

Out first step is to order to the robot to move forward and then turn to the left, as follows:

function main(args) {
    return {"body": [
       {"move_forwards":50},
       {"turn_left":90},
    ]}
}

If you run this code you will note the fighter will move around, following a squared path. Indeed the orders are to move forward 100 pixels and then turn right of 90 degrees, forever. If it is hit, it may change randomly its orientation.

Reacting to events

If you run the robot this way, is it blind and stupid, but it has not to be this way. Actually, the robot receives information about its environment in the args parameter. The most important value to check is args.event. There are basically 4 events our robot can react to:

idle: when the robot is running out of commands and has nothing to do
enemy-spot: when the robot sees the enemy right in front of the turret.
hit: when an enemy bullet hits the robot
wall-collide: when the robot hits the wall and cannot move forward anymore

Now lets add the ability to shot to the enemy when it sees one. For this purpose we instroduce a swich on the event. Also, we use an array where we push the actions we want to sent. Our revised code is thus:

function main(args) {
    let actions = []
    switch(args.event) {
        case "idle":
            actions.push({"move_forwards":50})
            actions.push({"turn_left":90})
            break;
        case "enemy-spot":
            actions.push({"yell": "Fire!"})
            actions.push({"shoot":true})
            break;
    }
    return {"body": actions}
}

Now, another detail. We say command is wrapped in a map, but in a map, there has not to be only one command. It can be multiple commands at the same time. But those have to be something the robot can do at the same time.

So for example a robot cannot move at the same time forward and backward, or move and turn. So the following actions are "sequential", in the sense, you can put only one at a time in the command maps:

move_forwards <number>: move forward of the given number of pixels
move_backwards <number>: move backward of the given number of pixels
move_opposide <number>: move in the opposite direction, useful when you hit a wall
turn_left <degrees>: turn the robot to the left of the given degrees
turn_right <degrees>: turn the robot right of the given degrees

However, you can order at the same time to yell and shot, for example. So this is a valid command: {"yell": "Fire!", "shoot":true}. Those are parallel actions.

In addition, you can also move the turret. This is thus the complete list of parallel actions:

yell <message> show a message
shot: true: order to shot, if the value is true
turn_turret_left <degrees>: turn the robot to the left of the given degrees
turn_turret_right <degrees>: turn the robot to the right of the given degrees
data: <object>: store the object and return it in every further event

Now let's put it all together, handling also the cases of the robot colliding with the wall or being hit. What it follows is the default control program that is the default when you create a new robot.

function main(args){
    let actions = []
    switch(args.event) {
        case "idle":
            actions.push({"turn_turret_left": 45, "move_forwards": 50})
            actions.push({"turn_left": 45})
            break;
        case "wall-collide":
            actions.push({"move_opposide":10})
            actions.push({"turn_left":90})
            break;
        case "hit":
            actions.push({"yell": "Ooops!"})
            break
        case "enemy-spot":
            actions.push({"yell": "Fire!", "shoot":true})
            break
        default:
            console.log(args)
    }
    return { "body": actions}
}