Setting up an apt-cacher is easy, and so is injecting the apt_proxy attribute to cloudconfig so you can use it in instances:

#cloud-config
apt_proxy: http://192.168.1.42:3142

When developing tools that depend on relatively useful IaaS APIs it becomes blatantly obvious which providers fail to provide the necessary APIs to perform the fundamental tasks required to build cloud tools and applications. It also becomes very frustrating when a provider claims to be something it clearly is not.

Rackspace does not support public key authentication out of the box, which is something so fundamental to the way cloud developers work, that it is difficult to consider Rackspace a serious cloud provider.

If you say you’re running OpenStack, you should really be running OpenStack with full API support…

/rant

p.s. I’m working on cloud agnosticism for CloudEnvy, and my biggest frustration thus far has been Rackspace.

For the last few years I’ve been working on OpenStack, and one of the aspirations many of us in the community have had from the beginning was to actually be able to use OpenStack for our own personal projects. A while ago I started working on a project called CloudEnvy which has potential to change the development patterns of web developers everywhere.

What is CloudEnvy?

CloudEnvy is a tool which allows you to configure and distribute reproducible development environments in the cloud. Basically you create an Envyfile.yml in the root of your project’s git repo, which defines things like environment name (translates to instance hostname), server image to use (for example ubuntu or centos), what type of instance to launch (m1.tiny, etc), and any provision scripts required to build out the environment. (right now provision scripts are primarily bash, but realistically they could be ruby, python, perl, or whatever…)

Now I know you’re thinking “Wait, isn’t that the same thing as Vagrant?” The answer to that question is YES! Vagrant is amazing, but there are some pretty significant advantages of using CloudEnvy over Vagrant.

Advantages of cloud development environments

  • Datacenter internet (download at 10,000kb/s instead of 100kb/s)
  • Cloud Mentality (If somethings broken, just kill it and spawn a new environment. It only takes 20 seconds.)
  • Local machine performance (I own a macbook air with 4gb of ram, launching more than a single tiny vm locally is futile)

Using CloudEnvy

To get started you first need to install CloudEnvy. We (aka Brian Waldon) regularly update and maintain packages on PIP, so the following should get you the most recent release:

sudo pip install cloudenvy

Next you need to setup your global configuration file – this is located at ~/.cloudenvy.yml. This is where you define your cloud credentials.

cloudenvy:
  clouds:
    cloud01:
      os_username: username
      os_password: password
      os_tenant_name: tenant_name
      os_auth_url: http://keystone.example.com:5000/v2.0/

      # Optional
      #os_region_name: RegionOne

Now that you can actually connect to a cloud, it’s time to get your project setup. As an example of how things work I will be outlining how to launch Devstack as a cloud environment (Devstack is an OpenStack development environment).
The following would be in the Envyfile.yml of your project’s root directory:

project_config:
  name: devstack
  image: 'Ubuntu 12.04 cloudimg amd64'
  remote_user: ubuntu
  flavor_name: m1.large
  provision_scripts:
    - provision.sh
  sec_groups:
    - icmp, -1, -1, 0.0.0.0/0
    - tcp, 22, 22, 0.0.0.0/0
    - tcp, 80, 80, 0.0.0.0/0
    - tcp, 8770, 8770, 0.0.0.0/0
    - tcp, 8774, 8774, 0.0.0.0/0
    - tcp, 8775, 8775, 0.0.0.0/0
    - tcp, 8776, 8776, 0.0.0.0/0
    - tcp, 9292, 9292, 0.0.0.0/0

Currently the best way to provision an environment is by running a bash script. Note that in the Envyfile.yml we have defined a single provision script; now lets actually flesh it out. The following bash script can live anywhere, as long as the path is correctly defined in the Envyfile.yml. In our example it’s located in the same directory as the Envyfile.yml at provision.sh:

#!/bin/bash

# Skip ssh new host check.
cat<<EOF | tee ~/.ssh/config
Host *
  StrictHostKeyChecking no
  UserKnownHostsFile /dev/null
  User ubuntu
EOF

sudo apt-get update
sudo apt-get install -y git python-netaddr

git clone https://github.com/openstack-dev/devstack.git #-b stable/folsom

cd devstack/

cat<<LOCALRC | tee localrc
FIXED_RANGE=192.168.2.0/24
MYSQL_PASSWORD=secrete
RABBIT_PASSWORD=secrete
SERVICE_TOKEN=secrete
SERVICE_PASSWORD=secrete
ADMIN_PASSWORD=secrete
LOCALRC

./stack.sh

Once the provision script is written it’s time to actually launch your first cloud environment. For your first launch I recommend using the -v tag to get useful output for debugging. Running the following command will launch an instance using your public key, create a security group for this specific environment, allocate and assign a floating ip, and run the provision.sh script.

envy -v up

You should see output saying what CloudEnvy is doing, and you should see all of the output from the provision script. When your environment is complete it should return the instance ip address. In case you forget it and need it for something you can always get it again by running:

envy ip

Having multiple environments makes it kind of difficult to remember all of the ips for all of your environments, so we have a command which will ssh into your current project’s environment:

envy ssh

That’s really all you need to know to get started.

Where is envy going from here?

CloudEnvy is very useful in several different use cases, and I’ve been very happy to see it being used regularly by a whole slew of people from different backgrounds.

Going forward there are a few things on my priority list

  1. Cloud Agnosticism Right now CloudEnvy only works with OpenStack, but honestly that’s not enough. CloudEnvy needs to work with Amazon EC2, Rackspace Cloud, HP Cloud, and all other providers with a sane API.
  2. Multi-node Environments Not sure if this is ever going to make it into CloudEnvy, but it would really be nice if there was a recommended, or at least documented path for deploying multi-node development environments.
  3. Building a community Tools mean nothing if there isnt a community around them that documents what can be done, and outlines best practices. I would love to see envyfiles for projects and platforms I have never heard of, currently there are only a few examples of this located here: http://github.com/cloudenvy

If you have any questions, or would like to contribute feel free to hit me up on twitter @jakedahn