How you can manage templates in Abiquo using Packer

By Marc Cirauqui, Support Engineer @ Abiquo

One of the questions we most frequently get from customers is regarding the management of the templates catalogue. In Abiquo, every enterprise has its own appliance library where templates are stored and can be added to the library in many different ways.

Templates consist of a default VM configuration (such as CPU, RAM or NIC drivers) and a set of disks. Although templates in Abiquo can have multiple disks, basic templates consist of only the boot disk for the OS guest, leaving further storage configuration to the user at deploy time.

Packer is a tool from Hashicorp that allows creation of such templates in a programmatic way. The basic idea is to provide the ISO image to install the OS along some kickstart or preseed file (although you can just type in commands using VNC capabilities in Packer) to get the OS installed, then run some scripts or provisioning steps, and finally process the resulting artifacts to get some valuable output. Of course, you have multiple builders allowing you to build templates in different systems, multiple kinds of provisioners and post processors, and of course there is plenty of documentation on how to write your custom plugins for Packer.

That last part is the one I want to talk about today.

As of now, you can find a Packer post processor that takes the resulting artifact of a local build and uploads it to Abiquo as a template. You can find the code in GitHub, as usual. The “readme” file in the repo will show you how to compile the plugin yourself or where to grab the latest binary release.

Now, assuming you have some Packer template, adding the Abiquo post processor is pretty straightforward. In the `post-processors` block of the template, you will need to add a block like the following:

{
  "variables": {
    "abiquo_username": "{{env `ABIQUO_USERNAME`}}",
    "abiquo_password": "{{env `ABIQUO_PASSWORD`}}"
  },
  "builders": [
    {
      "type": "vmware-iso",
      "boot_command": [
        "root",
...
  ],
  "post-processors": [
...
    {
      "type": "abiquo",
      "api_url": "https://my.abiquo.com/api",
      "api_username": "{{user `abiquo_username`}}",
      "api_password": "{{user `abiquo_password`}}",
      "datacenter": "MyDC",
      "template_name": "{{user `vm_name`}}",
      "description": "{{user `info`}} {{timestamp}}",
      "category": "{{user `category`}}",
      "cpu": "{{user `cpu`}}",
      "ram_mb": "{{user `ram`}}",
      "login_user": "{{user `ssh_username`}}",
      "login_password": "{{user `ssh_password`}}",
      "eth_driver": "VIRTIO",
      "chef_enabled": "false",
      "icon_url": "{{user `icon`}}"
    }
  ]
}

As you can see in this example there are 2 variables defined at the top to get the username and password for the Abiquo API from environment variables. In the post processor configuration you can see entries to configure the Abiquo API endpoint and several parameters of the template (for a complete reference check the GitHub repo README file)

Now, when you run this build, the post processor will connect to the specified API endpoint using the provided credentials and create a template in the apps library for the specified datacenter and that template will have one disk, which will be the VM disk built by Packer. Since Abiquo supports multiple disk formats and has a V2V conversion system, you can upload any supported disk format and Abiquo will run the necessary conversions so you can deploy your new image without issues.

Another feature regarding templates that was introduced back in Abiquo 3.6 is the ability to replace the boot disk of a template. This allows you to do some kind of versioning on a template. Imagine you have a Windows 2012 R2 template, you run the Packer build and upload it to Abiquo using the name “Windows Server 2012 R2 base OS”. At some point (probably next month) Microsoft will publish a new set of patches for Windows 2012 R2, so your template will need to be updated. With this feature, you keep the same template named “Windows Server 2012 R2 base OS” but replacing the base disk with a new one including the new patches. From that point forward, VMs deployed from that template will already include this new patches.

The Packer post processor for Abiquo also uses this feature, so if it founds a template with the same name it will replace its disk with the current build instead of creating a new template. That way, every time you run the Packer build you will get the template (or templates) updated in Abiquo.

About Abiquo

Abiquo delivers the industry’s leading cloud orchestration software for service provider clouds; allowing customers to quickly build and monetise cloud services, whilst managing hybrid, private or public cloud infrastructure from one intuitive portal – adding value through greater efficiency, visibility, simplicity and control.

Abiquo is privately held, and operates from headquarters in the UK with offices in Europe, and through its extensive global partner network. For more information, contact us.

By Marc Cirauqui, Support Engineer @ Abiquo

For those of you who don’t know about Vagrant, it is an open-source software product for building and maintaining portable virtual software development environments and, so, helping you to move forward in adopting a devops culture, making possible for a developer to bring up more similar environments to those deployed in production.

Out of the box, Vagrant supports some providers like Virtualbox, VMware (Fusion or Workstation) or Hyper-V. This means that Vagrant can automatically create the VMs your environment needs in these providers, then apply the configuration needed for your application to run. Well, as of now, you can add Abiquo as a provider for Vagrant, making it capable of deploying new VMs in Abiquo and applying the configuration over those VMs.

In order to work with Vagrant, you need a Vagrantfile where you define all the VMs your environment needs, and for every VM, the provisioning steps needed (configuration). Let’s take a look at a very basic Vagrantfile.

VAGRANTFILE_API_VERSION = "2"

Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|
  config.vm.synced_folder ".", "/vagrant", type: "rsync"

  config.vm.define "test" do |test|
    test.vm.provision "shell",
      inline: "echo Hello, World"
  end
end

If you just run vagrant up with this Vagrantfile, a VM will be created in VirtualBox (the default provider unless otherwise specified), and a single configuration step will be run, a simple Hello, World message will be displayed.
Now, getting the Abiquo plugin for Vagrant is quite straightforward. Of course you need Vagrant installed, then launch a terminal and type:

vagrant plugin install abiquo_vagrant

This will download and install the necessary files so Vagrant can deploy VMs in Abiquo. Now we can modify a bit our Vagrantfile. Let’s make it look like:

VAGRANTFILE_API_VERSION = "2"

Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|
  config.vm.synced_folder ".", "/vagrant", type: "rsync"

  config.vm.define "test" do |test|
    test.vm.provision "shell",
      inline: "echo Hello, World"
  end

  config.vm.provider :abiquo do |provider, override|
    override.vm.box = 'abiquo'
    override.vm.box_url = "https://github.com/abiquo/vagrant_abiquo/raw/master/box/abiquo.box"
    override.vm.hostname = 'abiquo-test'

    provider.abiquo_connection_data = {
      abiquo_api_url: 'https://my.abiquo.cloud/api',
      abiquo_username: 'myself',
      abiquo_password: 'mypass'
    }
    provider.virtualdatacenter = 'Barcelona'
    provider.virtualappliance = 'Vagrant Tests'
    provider.template = 'Centos 7 x86_64'

    override.ssh.private_key_path = '~/.ssh/id_rsa'
  end
end

Now, we added a new block, describing the configuration of the Abiquo provider in this environment. As you can see, we have to provide a fake box as we will be deploying one of the templates available in Abiquo instead of the regular boxes used in VirtualBox. Then we provide the connection info for the Abiquo API, providing its endpoint and credentials, and finally, the VirtualDatacenter and VirtualAppliance where we want to deploy the VM and which template shall it use.
Great! Now it’s as simple as running:

vagrant up --provider=abiquo

You will see Vagrant connects and checks for the availability of the template, VirtualDatacenter, etc. Then creates and deploys the VM, and finally will connect to it and run the provisioning step defined for the VM. Easy!

Now, this is a very basic example on how to get Vagrant to work with Abiquo, but there are a lot of examples on different application environments that can be deployed with Vagrant, which you can now modify so the application they describe runs in your Abiquo based cloud instead of your development workstation.

For example, the guys from CoreOS have a Vagrantfile to deploy Kubernetes on top of CoreOS, which you can modify to launch the Kubernetes cluster over your Abiquo based cloud.

About Vagrant

Vagrant is a tool for building and managing virtual machine environments in a single workflow. With an easy-to-use workflow and focus on automation, Vagrant lowers development environment setup time, increases production parity, and makes the “works on my machine” excuse a relic of the past.

As well as Abiquo, Vagrant is trusted by thousands of developers, operators, and designers everyday.

You can find all the information about Vagrant in its website, vagrantup.com

About Abiquo

Abiquo delivers the industry’s leading cloud orchestration software for service provider clouds; allowing customers to quickly build and monetise cloud services, whilst managing hybrid, private or public cloud infrastructure from one intuitive portal – adding value through greater efficiency, visibility, simplicity and control.

Abiquo is privately held, and operates from headquarters in the UK with offices in Europe, and through its extensive global partner network. For more information, contact us.

Abiquo offer software defined networking with CohesiveFT‘s VNS3

With CohesiveFT their VNS3 product is available to all Abiquo customers through the default Abiquo repository. VNS3 is a hybrid overlay networking appliance built for Abiquo integrated cloud deployments
VNS3 acts as 6 devices in one: router, switch, firewall, VPN concentrator, protocol redistributor and scriptable SDN. It’s different from other SDN and network function virtualization (NFV) solutions because of the customer-controlled overlay network built on top of the underlying cloud network.

CohesiveFT SDN

The inclusion of VNS3 means that you can easily create secure overlay networks to allow our customers to:

1. Use VNS3 to create overlay networks between your Abiquo private cloud and public clouds such as Amazon AWS
2. Use VNS3 to create overlay networks between Virtual Datacenters within your Abiquo cloud. Perhaps you have virtual datacenters in different physical locations, or even countries?
3. Use VNS3 to create overlay networks between Virtual Datacenters hosted by our Service Provider customers

In each case the use of VNS3 means that you configure your application network once. Even if you move that application between the three use cases or move between private, public and hybrid Cloud configurations.

You can find out more about VNS3 here, including technical information and pricing.

A quick look at the Abiquo user interface makes it easy for our users to meter and charge for compute, storage and network resources of various types.

Dashboard

Abiquo’s interactive user interface makes metering easy!

But did you know that you can meter your customers’ usage at a more granular level?

Lets take a look at the levels at which you can meter usage with Abiquo:

Hypervisor Type
Abiquo tracks which machine is deployed on which hypervisor, so for those for which you have to pay a license fee, like VMware ESX, you can charge the customer appropriately. Where you have a lower cost of ownership, such as KVM, you could reduce the charge. You can use this, and the reporting of it, to enhance sales engagement and advise your customer of the best platform for the workload.

Here is a list of the hypervisor technologies that Abiquo supports.

Reserved Machine
Abiquo lets you dedicate a physical machine to an Enterprise, creating what you might call a “virtual private cloud” in your shared infrastructure. You can combine this with dedicated storage tiers and even physical networks, but more of that another time. You can also let customers choose whether to use these dedicated machines or a shared resource, and meter for the usage of those reserved machines.

Anti-Affinity 
Using anti-affinity (preventing selected virtual machines from running on the same physical machine) reduces the efficiency of your platform, so you may want to charge extra for it. In a self-service environment your customers can configure their own anti-affinity rules through Abiquo Layers, which works on all our supported hypervisors, not just VMware. We meter use of Anti-affinity layers so you can charge for it.

VM Template Cost Codes
In the App Library template configuration you can assign cost codes to templates. These are configured through the pricing screens. You can then use these for all kinds of billing and reporting purposes; charging by OS, maybe just for customers with a managed service; charging by application, if your templates contain pre-configured applications; charging for use of Chef, for example.

 Have a look at the Abiquo Wiki for more information on clever charging!

Contact us here if you have any questions.

A key characteristic of a cloud solution is self-service – allowing the cloud consumer to provision their computing capabilities without the intervention of an administrator. Many IT administrators will shudder at the thought of providing the user with a full self service experience.

Scared Yao

                                                                                                                     Frightened IT- guy meme

Abiquo helps here by providing self service to the cloud consumers, whilst allowing the cloud administrator, or infrastructure owner to remain in complete control. Abiquo’s controlled self service is delivered through several different features:

1. The Cloud administrator controls which logical pools of private resource (Abiquo data centers), or public cloud regions any tenant (Abiquo enterprise) can use

2. The cloud administrator sets resource limits to control how much resource a tenant can use in any one datacenter. Read how to do this here.

3. The cloud administrator defines allocation rules, so that when a consumer deploys through self service the administrator has control over where the workload is provisioned and how the infrastructure is utilised.

4. Finally how the consumers self service capabilities are controlled by over 56 separate privileges (that can be grouped into roles), that define what information can be viewed in the Abiquo UI, and what tasks the user can perform. By configuring roles the  cloud administrator can delegate as much (or as little) self-service as required.

Watch to learn more about self-service and other Abiquo features. Contact us for more information or visit the Abiquo Wiki