ONE Service Appliances in the Marketplace

A short time ago we made a quick introduction to one of our recent efforts in OpenNebula – ONE service appliances. In particular, the CMS platform WordPress. It was just a short announcement in the forum to let you know that we started to expand the OpenNebula’s Marketplace. If you missed this news, you can take a quick look here: Release of WordPress 5.0 appliance

This new endeavor is not just about a preinstalled software package where every new installation/instantiation requires configuration – either by hand or via ansible/saltstack/chef/puppet or another automation tool of your choice. That would be too easy (for us) and not of much use for you. Eventually you may do some reconfiguration anyway to meet your needs, but we tried to make the appliance deployment as automated and straightforward for you as possible. For example, some appliances support username, password and email (where it makes sense) as a contextualization – you can deploy multiple of these appliances at once and each with its own credentials. But we don’t stop there. Even if you decide to not provide any contextualization at all, the appliance will still not have any passwords or sensitive security information baked inside the image. Every time you instantiate a ONE service appliance, it will first configure itself and generate a new set of credentials, tokens and similar, as needed.

For more general information about ONE service appliances, visit the documentation.

The aforementioned announcement serves as a sneak peak and we promised to give you more info about it and more appliances to play with. Let us first take a deeper look at the WordPress appliance. After that we will cover another new appliance – GitLab, the popular CI/CD platform for developers!

WordPress – Let’s write some blog!

• WordPress – Official website
• The WordPress appliance on the marketplace
• Documentation for the WordPress appliance

We will now create yet another blog. All the necessary steps are in the documentation so you just need to follow the Quick Start first, but don’t leave the contextualization parameters empty. Instead, fill up the bootstrapping variables and save your time by avoiding the need to go through the setup wizard.

Bootstrapped WordPress:

Running WordPress

GitLab – It’s time to develop!

• GitLab – Official website
• The GitLab appliance on the marketplace
• Documentation for the GitLab appliance

GitLab is definitively one of the most popular CI/CD tools these days and we are happy to include it in our marketplace. Again, all the necessary steps are described in the documentation – follow the Quick Start and before you instantiate, fill up the bootstrapping variables. If you fail to do so, GitLab will greet you with the prompt for password setup.

Bootstrapped GitLab:

GitLab login screen

This concludes our introduction to the first batch of ONE service appliances. Stay tuned for the next addition!

Do you have a tip for some other great service? Let us know what you think in the comment section!

As part of OpenNebula v.5.8 “Edge”, we have designed a new method for self-provisioning virtual networks. OpenNebula already has two ways for creating virtual networks:

• Just create it from scratch.
• Reserve a slice of an existing virtual network.

Typically the virtual networks are created by the cloud administrators and the end user just makes reservations from those virtual networks. However, this method does not allow the end user to make changes at a logic level like changes to IP ranges, the DNS server, etc.

Now, with the new virtual network template, an end user will be able to do just that. The cloud administrator will be able to create a virtual network template with all the required physical attributes, like the driver (VN_MAD), the bridge, the VLAN_ID (it can be set to be automatically generated), etc. and can still use the restricted attributes to manage the end users’ control. Yet in the end, the end user will be able to create a virtual network by means of the template.

For example, the administrator could create a virtual network like this:

cat template.txt
  NAME="vn_template"
  VN_MAD=bridge
  BRIDGE=virbr0
  AUTOMATIC_VLAN_ID=yes
$ onevntemplate create template.txt
  ID: 3
$ onevntemplate show 3
   TEMPLATE 3 INFORMATION
   ID             : 3
   NAME           : vn_template
   USER           : oneadmin
   GROUP          : oneadmin
   LOCK           : None
   REGISTER TIME  : 11/29 14:12:01

   PERMISSIONS                                                 
   OWNER          : um-
   GROUP          : ---
   OTHER          : ---

   TEMPLATE CONTENTS
   AUTOMATIC_VLAN_ID="yes"
   BRIDGE="virbr0"
   VN_MAD="bridge"

And make it available for all end users:

$ onevntemplate chmod 3 604
$ onevntemplate show 3
   …
   PERMISSIONS                                                        
   OWNER          : um-
   GROUP          : ---
   OTHER          : u--
   …

Once the virtual network template is created and ready to use, the end user will be able to create customized virtual networks.

During the instantiation the user can create a new address range:

You can go to the “Virtual Networks” section and check that the virtual network is already there:

Test out this new feature – it’s available now in our v.5.8 beta version – and let us know if you have any suggestions!