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…
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)
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
#!/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
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:
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:
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
- 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.
- 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.
- 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