How to create your own BigBoards app?

Using Apache Ignite as an example, you will learn how to assemble your own BigBoards app. Once your BigBoards app is defined on the BigBoards Hive, you deploy it to your BigBoards Hex by the click of 1 button!

Introduction to Apache Ignite

I'm the organiser of BigData.be, the Belgian user community on Big Data, NoSQL and scalable technologies. On Tuesday, November 8th, 2016 we organised our 39th meetup.

In the near future, we'll have a lot more to deploy for you: only technologies, but also datasets, tutorials and many more!

General info

The 2nd step is to complete the general information of your newly created BigBoards app:

name is just a short label that is shown on the card in the library etc.

description is a longer piece of text to explain about the technology stack that you are assembling.

logo url is for showing a recognizable image in the library and on the cluster consoles.

git url points to a version control repository where we'll store all files and artifacts to configure the technologies which we will be deploying. This repository must be publicly accesible as we clone the complete repository to the target cluster on deployment.

Architecture allows you to constrain your BigBoards app to the given CPU architectures. Your BigBoards app will only show up in the library panel of the clusters that adhere to your selected architectures. We currently support Intel and ARM. Whether your BigBoards app supports 1 or the other architecture, or all, totally depends on what you are deploying.

Firmware constrains the availability of your BigBoards app to the BigBoards firmware that is installed on the target cluster. Normally everybody should be on the latest level!

Visibility allows you to keep your BigBoards app private to you and your collaborators, or you can share with the whole community, i.e. public.

Collaborators is the list of users that are allowed to use, but also alter(!) your BigBoards app.

As you can see, setting up your own BigBoards app for Apache Ignite is very simple.

For vanilla technologies, you can easily copy the description from the origin website.

Commit the logo for your BigBoards app to your configuration repository and use the image's raw URL.

Changes to fields are saved automatically while editing. There are no separate OK, Confirm or Save buttons. No confirmation dialogs either!

Containers

3rd, we have to setup what needs to be deployed by your new BigBoards app. The BigBoards infrastructure deploys software services as docker containers.

What is docker? explains how you can package any application into a standardised unit for software development:

Docker containers wrap a piece of software in a complete filesystem, that contains everything needed to run: code, runtime, system tools, system libraries – anything that can be installed on a server. This guarantees that the software will always run the same, regardless of its environment.

But, Docker not only makes technologies, processes and services portable. It also makes them erasable!

Application containers ensure that the base system of your cluster remains clean from foreign contaminations. That is all important for the stability of your system!

In that respect, Apache Ignite is a simple solution: it requires just a single process to be depoyed. 1 docker container!

Use the button with the + sign at bottom right. It slides open to the top

Next, click the Add Container button to setup a new container:

image points to the docker images that needs installing. Notice that you can add a tag (1.7.0 in this case) or omit it entirely to pull the latest image.

registry is used to find the requested docker image. Blank uses the official docker hub.

command allows you to overrule the command inside the docker container. Useful if a single docker container can be used for multiple processes.

networking allows you to chose how the container integrates with the host's network: bridged or host. Most of the time we simply use host.

port mappings allow you to reroute ports from the docker container to other ports of the host. This is only required with networking set to bridged.

environment variables allow you to pass information from the host environment into the container.

volume mappings mount directories from the host as directories inside the containers.

volume links, container links and advanced settings are all advanced settings, only used in exceptional cases.

Use a tag to define your docker image to prevent unexpected behaviour.

Add all ports, even with host networking, to explicitly express which ports get exposed.

For adding an item (like a port mapping) to a list, you have to explicitly save the changes per line. To remove or update an entry, use the drop-down menu via the `hamburger` button.

Groups

Groups are the deployment descriptor of the BigBoards infrastructure: it defines which containers need to end up on which nodes in the cluster.

As your BigBoards app for Apache Ignite only has 1 container, it also only needs 1 group.

Use the button with the + sign at the bottom right. It slides open to the top.

Custom configuration

While auto-discovery is extremely easy, it is also very dangerous in enterprise environments. Suppose that 2 clusters install your new BigBoards app. They would immediately bond together to swarm into a huge Ignite grid!

That's not what you had in mind for your production cluster, when you started your test environment :'‑(

However, as with all distributed technologies, things can get complicated fairly quickly! Your understanding of the technologies and the services in your BigBoards app are crucial for a clean and maintainable solution!

We are still learning. Every day!
Join us! Learn! Improve! Participate!

Share you feedback, so we can all grow together on technology. Data is hard enough on its own!!!