Using Vagrant and VirtualBox to Run Sandbox Environments

Transcription

1 Using Vagrant and VirtualBox to Run Sandbox Environments One of the things that I ve done lately is to ensure that I keep my laptop clean of any development tools. The reason is that I have run into a lot of problems with conflicts around versions, platforms, and general oddities that come as I deploy more and more different environments onto a single machine. Using Virtualbox and Vagrant for Sandboxes Luckily, using Vagrant and VirtualBox is both free and simple. I ve even saved some of the steps by storing basic configs on my GitHub to share and to let the community save some steps. Install VirtualBox Got to and you will see a nice shiny button on the main page to take you to the latest download, or you can also just got to to see the various versions. In my case, I m running Mac OSX, so I will choose the appropriate version. Once it is installed (just take the defaults) then you can run VirtualBox for the first time to complete the initial configuration. Install VirtualBox Guest Additions When you launch VirtualBox for the first time, it will prompt you to install the VirtualBox Guest Additions. This is some add-on features to correct problems on some Linux guests. Since we are going to be using lots of Linux guests, you should run the update. There is no other configuration needed for your VirtualBox because we are going to let Vagrant do all of the configuration from here on in. Install Vagrant Go to to get the latest and greatest Vagrant version, and install for your particular Operating System. There are no configuration steps required at all, so just take the defaults and you will be ready to go in a few minutes once the install wizard completes. Install Git Client If you are running OSX, just try to run Git from the command line and it will prompt you to install Xcode. Follow the steps and you will be Git-tastic in no time. Unfortunately, it does take a long time and download a lot of other stuff along with the Git client. For Windows and Linux folks, go to and pick out the version of choice to install.

2 Create your GitHub Repository For my instances, I use the naming structure virtualbox-productname-sandbox, so if I want to create one to do some nginx testing, I would call it virtualbox-nginx-sandbox as an example. Go to your GitHub account and create a new repository: You will want to do the following steps: Name the repo (virtualbox-nginx-sandbox in my case Set the repo as Public Initialize with a README Add the Apache License 2.0

3 Next, let s get the URL of the git repo to download and work with: Use your nifty git command line to clone the repository and then we can get started with creating the basic machine:

4 Make sure that you cd into your folder for the next steps to create the configuration files. Configure a Basic Machine My goto standard is usually an Ubuntu LTS instance. This has been the classic for many build environments, so I will just need to set up a very simple Vagrantfile to do this. The Vagrantfile file contents will look as follows: # -*- mode: ruby -*- # vi: set ft=ruby : VAGRANTFILE_API_VERSION = "2" ENV['VAGRANT_DEFAULT_PROVIDER'] = 'virtualbox' Vagrant.configure(VAGRANTFILE_API_VERSION) do config config.vm.define mysandbox" do mysandbox mysandbox.vm.hostname = mysandbox" mysandbox.vm.box = "trusty-server" mysandbox.vm.box_url = " amd64-vbox.box" mysandbox.vm.provision :shell, :path => "build.sh" end end This basic configuration creates an Ubuntu machine named mysandbox and uses NAT networking on an internal network which will have access to the internet and your local network, but does not have a bridged NIC to connect back inside from external resources. You will see that it also calls a shell script named build.sh which is our configuration file to do the basic installs and any customized package deployments. For a basic machine, this is what the build.sh looks like: #!/bin/bash # build.sh Authors: Eric Wright (@DiscoPosse) export DEBIAN_FRONTEND=noninteractive echo "set grub-pc/install_devices /dev/sda" debconf-communicate sudo apt-get update && sudo apt-get upgrade -y

5 sudo apt-get install -y git vim openssh-server && sudo reboot We are setting the machine to run updates, a kernel upgrade to the latest revision, install a few packages, and then reboot. Configure your.gitignore The most important, but seemingly forgettable step is to create a.gitignore file which stops files from being ingested into a git repository. This is particularly helpful when you have downloads of base boxes, configuration files with passwords and other such local content you want to NOT go back up to the central repo. Here is my basic.gitignore file: *.box.vagrant/ The file is designed to not allow VirtualBox images to be captures, and it also protects the.vagrant folder which creates temporary SSH keys and other content that is mean to be volatile and instancespecific. Now you can simply do a git add to add your files, run a git commit to commit the changes, and finally a big old git push to push your changes up to the remote repository on GitHub. Running your Sandbox Instance It s as easy as vagrant up and once your instance is started, you can run vagrant ssh YOURHOSTNAME where YOURHOSTNAME is the name of the host from your Vagrantfile. Now you have a nifty little sandbox server to run all of your testing without having to much around with tons of configuration and local conflicts. WARNING: You have to remember that this is a sandbox instance and is not storing your changes anywhere except locally. Because you excluded the.box in our.gitignore file, the machine itself is not being backed up to the repository. You won t want to use GitHub to hold your sandbox servers, but you may want the internal code to be stored somewhere. For that reason, please make sure that back up any code you create or special files that need to be saved. Oops I need to Rebuild It s as easy as vagrant destroy and then running vagrant up and you are back up and running with your basic sandbox server. This is helpful when things go a little sideways and you need to go back to the beginning. You can also take snapshots within Virtualbox which I will put into another post soon. Happy sandboxing!

6 Updating Forked Git Repository from Upstream Source (aka Rebase all the things!) As you can imagine, the world of IaC (Infrastructure-as-Code) means that we are going to have to dabble a lot more in the world of code repositories. Git is the most common tool I have found in use for code version control, and along with it, Github.com is the most common place that people (including myself store their project code. All Forked Up When the first work happens with using Github is that you may find yourself forking a repository to create a point-in-time snapshot under your own repositories. This is done for a variety of reasons like contributing upstream code, and keeping a safe stable release of a particular codebase that could change and affect other work you are doing with it. As you can see in the image above, I have a forked copy of the Lattice framework from Cloud Foundry. Nice and easy to do, but as you look at the bottom of the image, you will also see that I ve been falling behind on updates. So, how does someone fix this situation? Let s assume that we are testing locally and find a bug, but then realize that the upstream repository has already fixed the bug. Rather than wiping out the repository altogether and re-cloning, let s fix it in place! Updating a Forked Repository from Upstream Source Let s jump in the command line, and see what s happening. In my lattice folder, I will do a git status to see the current state of things: We can see that we show as up to date, but I know that I am 649 commits behind the upstream source. Time to get ourselves up to date for real. The way we do this is by syncing up our repositories here locally, and then pushing the changes back up to our forked repository. First, let s check our remote source by typing git remote to see what s happening locally: We have one source called origin which is our forked repository. We are going to add one more source called upstream to point to the original repo using the command git remote add upstream in my case and then run our git remote again to confirm the change: Now we can see both of our sources. We are assuming that you are using the master branch of your

7 repo, but just in case, we can also do a git checkout master first for safety. As you can see in my case, it will complain that I am already on master and nothing will happen: Now let s do the next steps which is to fetch the upstream and rebase our local repo. Yes, these are funny sounding terms to some, but you will get used to them. This is done by using the git fetch upstream command followed by the git rebase upstream/master to sync them up: Lots of updates came down, and you can see that our rebase has done all the changes locally and if we had any updates, they would be left in place with the underlying repo updates done at the same time. We need to check our status first using the git status and as you can see here, it will show the 649 commits ahead of origin/master which is my forked repo on Github: Now it s time to push all the updates! This will commit the changes to the Github forked repo for you and then we are up to date with the upstream source. We will use the git push origin master which pushes the local changes to the master branch of our origin source (in our case discoposse/lattice) and then we can confirm the changes are committed with a git status afterwards: There you go! Now your forked repository is up to date with the upstream source and you can get back to the coding! If you check your Gitub page also, you will see the change there: Hopefully this is helpful, because I have been asked a few times recently about dealing with this issue as people get started with Git. I hope to bring some more quick Git tips as I hear questions come from the community, so feel free to drop me a comment with any question you have! OpenStack by the Numbers: Welcome Kilo! As April 30th arrived, so did the next named release of OpenStack. Kilo is the 11th official release of OpenStack since its inception in Born of the with great hopes and minds at Rackspace and NASA, the widely known open cloud ecosystem continues to gain steam, awareness, and sometimes a little bit of criticism. Whether you re using OpenStack today or investigating it for down the road, this is a good time to take a quick look at what went into the Kilo release.

8 By the People, For the People Not even taking into account the corporate support and customer side of the equation, I always like to see how the developer and operations side of OpenStack fares as each release comes out. One thing that is undeniable is that the velocity continues to increase for OpenStack development, and the stability is also doing the same. The program list (aka project list and probably both because that keeps changing) is widening with the official integration of Ironic, a bare metal provisioning project. Features are growing rapidly also, with a lot of fixes and enhancements that have been wrapped into this release. Juno in Review How does 18,992 code commits sound? That s pretty impressive if you ask me, and what is just as impressive is if you look at how we assessed Juno in the past here. So, with Juno in the bank, how about we look at how Kilo measured up by these numbers. Kilo Kicking it up a Notch As we took a look at the analytics from activity.openstack.org, the numbers were both impressive and telling. 21,125 code commits from 1,593 developers and a total of 1,839 submitters which covers code, documentation, and training. Looking at Juno in comparison shows that we have a continued rise above a linear scale with the Kilo release. This is telling as we can see the velocity of development and the growth of the ecosystem which is increasing at each release. If we look at the picture since the beginning, from 124,499 total code commits, 3,279 total developers, and 3,611 total submitters, it tells us that Kilo produces 16.96% of the total code in just the Kilo release alone! Code counting doesn t tell you success stories. What does show a positive story in these numbers is that they keep moving up and to the right. Increasing both on participation, fixes, features, and total growth. OpenStack Kilo Presentation As the launch press makes its way around, we will see a lot of good detail on features, advancements, and also on challenges. One thing I do appreciate about a lot of the OpenStack community is that they acknowledge that the challenges are real, and are being taken on as much as possible. Here is a quick view of the Kilo release as presented by the OpenStack Foundation: OpenStack Kilo April 2015 from OpenStack Foundation

9 Eric s Favorite Features There are lots of very interesting features and improvements that were packed into the Kilo development cycle. According to the OpenStack Foundation there were 394 to be exact. I don t have an exhaustive list, but I can tell you a couple of things that I am particularly keen on that arrived with Kilo. Keystone-to-Keystone Federation Identity federation was available in previous releases, but was well known to be challenging to work with and very new. The Kilo release of Keystone has seen the federation features listed as stable with much more documentation and working examples of how to federate your OpenStack clouds to one another. As people explored OpenStack without federation, the issue rose that if more than one OpenStack cloud was implemented that the identity environments were separated, and thus difficult to manage. By adding stable Keystone to Keystone federation we have the ability to create a true hybrid OpenStack cloud. This is also important as companies are embracing OpenStack and the potential for two organizations to have to merge during a purchase or partnership was a bit limiter up to this point. Ironic for VirtualBox (experimental) Although this is an experimental feature within the Ironic (bare-metal provisioning) program, the availability of a way to test out Ironic deployment for people is going to be very helpful as we get more folks exploring OpenStack. It s one thing to have a working OpenStack environment, and a whole other thing to have procedures and methods to build, deploy, and grow the infrastructure. Using VirtualBox as the test bed for Ironic will allow more people to test the waters and provide feedback to the development teams. This can only lead to good things. Scale Preparation for Neutron This is a work in progress, but it is top of mind as we head into the Liberty release. Networking within the OpenStack environment has often been shown to have scale challenges when growing in large environments. Many won t hit any of the scale limits that are currently a challenge, but it is important just the same that the teams are working to address this and have done lots of work to build in future improvements as upcoming releases come out. People Yes, people are a feature. This includes a growing community, an eager developer ecosystem, and the most important thing of all which is people using OpenStack. The focus on the operator and what is called the superuser has been big with the last couple of OpenStack Summits, and with good reason. The more people who are using OpenStack in some form, the better the overall ecosystem will do. Looking forward to an equally exciting Liberty release, and I hope to see lots of you in Vancouver at the OpenStack Summit!

10 DiscoPosse Review: ios 6 Programming Cookbook Vandad Nahavandipoor One word review: Complete. The ios 6 Programming Cookbook by Vandad Nahavandipoor from O Reilly Publishing is not just a cookbook, but a full end-to-end recipe guide for every aspect of ios application development for iphone and ipad using Xcode from Apple. The audience is definitely developers. As a system admin with some dabbling in development along the way, I found that the subject matter was deep almost immediately. That being said though, I ve been able to use the guide to develop a couple of sample apps and I plan to continue working on it. If mobile app development is on your radar, then this book is right in your wheelhouse. Vandad provides detailed code samples, clear and concise solutions and a well organized set of recipes to touch on every imaginable component of the ios ecosystem. As a straight read, and as a reference, I would definitely recommend this book. Thanks again O Reilly for another excellent product!