Daniel Watrous on Software Engineering

A Collection of Software Problems and Solutions

Posts tagged Windows

Software Engineering

Explore CloudFoundry using bosh-lite on Windows

It seems like most of the development around CloudFoundry and bosh happen on Linux or Mac. Getting things up and running in Windows was a real challenge. Below is how I worked things out.

**Make sure you have a modern processor that supports all virtualization technologies, such as VTx and extended paging.

Aside from the deviations mentioned below, I’m following the steps documented at https://github.com/cloudfoundry/bosh-lite

Changes to Vagrantfile

I’m using VirtualBox on Windows 7. To begin with, I modified the Vagrantfile to create two VMs rather than a single VM. The first is the VM that will run CloudFoundry. The second is to run bosh for the deployment of CloudFoundry. I use a second Linux VM to execute the bosh deployment since all the commands and files were developed in a *nix environment.

I am also more explicit in my network setup. I want the two hosts to have free communication on a local private network. I leave the default IP address assignment for the CloudFoundry host. For the bosh host I change the last octet of the IP address to 14.

  config.vm.define "cf" do |cf|
    cf.vm.provider :virtualbox do |v, override|
      override.vm.box = 'cloudfoundry/bosh-lite'
      override.vm.box_version = '388'
 
      # To use a different IP address for the bosh-lite director, uncomment this line:
      override.vm.network :private_network, ip: '192.168.50.4', id: :local
      override.vm.network :public_network
    end
  end
 
  config.vm.define "boshlite" do |boshlite|
    boshlite.vm.provider :virtualbox do |v, override|
      override.vm.box = 'ubuntu/trusty64'
 
      # To use a different IP address for the bosh-lite director, uncomment this line:
      override.vm.network :private_network, ip: '192.168.50.14', id: :local
      override.vm.network :public_network
      v.memory = 6144
      v.cpus = 2
    end
  end

At this point you can spin up the two hosts.

vagrant up --provider=virtualbox

The remaining steps need to happen on your bosh deployment host (192.168.0.14 based on the Vagrantfile above). In case you need it, here is a refresher on setting up Vagrant SSH connectivity using PuTTY on Windows.

Prepare for provision_cf

If you are in a proxied environment, you’ll need to set the environment variables, including no_proxy for the CloudFoundry host. I include xip.io for ease of access in future steps.

export http_proxy=http://proxy.domain.com:8080
export https_proxy=https://proxy.domain.com:8080
export no_proxy=192.168.50.4,xip.io

Next we need to get prerequisites going and then install the bosh CLI. You may have some of these already, and you may need some additional libraries. This is based on a clean Ubuntu trusty 64 box.

sudo -E add-apt-repository multiverse
sudo -E apt-get update
sudo -E apt-get -y install build-essential linux-headers-`uname -r`
sudo -E apt-get -y install ruby ruby-dev git zip

Now bosh_cli can be installed. I’ve added flags to skip ‘ri’ and ‘rdoc’ since they take a long time. If you really want those, you can drop those arguments.

sudo -E gem install bosh_cli --no-ri --no-rdoc

We also need spiff on this system. Here I grab and unzip the latest spiff, then move the binary into /usr/local/bin.

wget https://github.com/cloudfoundry-incubator/spiff/releases/download/v1.0.3/spiff_linux_amd64.zip
unzip spiff_linux_amd64.zip
sudo mv spiff /usr/local/bin/

Next we need to clone both bosh-lite and cf-release. Even though the contents of bosh-lite are available in “/vagrant”, we need these two directories side by side, so it’s easiest to just clone them both into the home directory of the bosh deployment host. We then change into the bosh-lite directory.

git clone https://github.com/cloudfoundry/bosh-lite.git
git clone https://github.com/cloudfoundry/cf-release
cd bosh-lite/

The script ./bin/provision_cf needs to be edited so that get_ip_from_vagrant_ssh_config simply outputs the private network IP address that was assigned in the Vagrant file. The default functionality assumes that the provision script is run from the the host running Vagrant and VirtualBox. However, these commands are running on the bosh deployment host, which doesn’t know anything about vagrant or virtualbox. Here’s what the function should look like.

get_ip_from_vagrant_ssh_config() {
  echo 192.168.50.4
}

Target bosh and provision

Everything is set to target the bosh host, set the route and provision CloudFoundry. When you first target the cloudfoundry host, it will as for credentials to login.

vagrant@vagrant-ubuntu-trusty-64:~/bosh-lite$ bosh target 192.168.50.4 lite
Target set to `Bosh Lite Director'
Your username: admin
Enter password: *****
Logged in as `admin'

Next we can add the route to the bosh deployment host.

vagrant@vagrant-ubuntu-trusty-64:~/bosh-lite$ ./bin/add-route
Adding the following route entry to your local route table to enable direct warden container access. Your sudo password may be required.
  - net 10.244.0.0/19 via 192.168.50.4

Provision CloudFoundry

The only thing left to do is provision CloudFoundry.

./bin/provision_cf
...
Started         2014-09-29 18:54:39 UTC
Finished        2014-09-29 19:36:11 UTC
Duration        00:41:32
 
Deployed `cf-manifest.yml' to `Bosh Lite Director'

This takes quite a while (possibly hours depending on your hardware). If you have an older processor that doesn’t support all the modern virtualization technologies, this could take much longer.

Verify your new CloudFoundry deployment

In order to use CloudFoundry we need the ‘cf’ client. The cf client is available as a binary download from the main GitHub page for CloudFoundry. The following commands will prepare the cf CLI for use.

wget http://go-cli.s3-website-us-east-1.amazonaws.com/releases/v6.6.1/cf-linux-amd64.tgz
tar xzvf cf-linux-amd64.tgz
sudo mv cf /usr/local/bin/

With the cf CLI installed, it is now possible connect to the API and setup org and space details.

cf api --skip-ssl-validation https://api.10.244.0.34.xip.io
cf auth admin admin
cf create-org myorg
cf target -o myorg
cf create-space mydept
cf target -o myorg -s mydept

You should now have an environment that matches the below.

API endpoint:   https://api.10.244.0.34.xip.io (API version: 2.14.0)
User:           admin
Org:            myorg
Space:          mydept

Deploy an app

You can now deploy an application. To verify, create a directory can add a file:

index.php

<?php phpinfo(); ?>

Now push that app as follows:

vagrant@vagrant-ubuntu-trusty-64:~/test-php$ cf push test-php
Creating app test-php in org myorg / space mydept as admin...
OK
 
Creating route test-php.10.244.0.34.xip.io...
OK
 
Binding test-php.10.244.0.34.xip.io to test-php...
OK
 
Uploading test-php...
Uploading app files from: /home/vagrant/test-php
Uploading 152, 1 files
OK
 
Starting app test-php in org myorg / space mydept as admin...
OK
-----> Downloaded app package (4.0K)
Use locally cached dependencies where possible
 !     WARNING:        No composer.json found.
       Using index.php to declare PHP applications is considered legacy
       functionality and may lead to unexpected behavior.
       See https://devcenter.heroku.com/categories/php
-----> Setting up runtime environment...
       - PHP 5.5.12
       - Apache 2.4.9
       - Nginx 1.4.6
-----> Installing PHP extensions:
       - opcache (automatic; bundled, using 'ext-opcache.ini')
-----> Installing dependencies...
       Composer version ac497feabaa0d247c441178b7b4aaa4c61b07399 2014-06-10 14:13:12
       Warning: This development build of composer is over 30 days old. It is recommended to update it by running "/app/.heroku/php/bin/composer self-update" to get the latest version.
       Loading composer repositories with package information
       Installing dependencies
       Nothing to install or update
       Generating optimized autoload files
-----> Building runtime environment...
       NOTICE: No Procfile, defaulting to 'web: vendor/bin/heroku-php-apache2'
-----> Uploading droplet (64M)
 
0 of 1 instances running, 1 starting
1 of 1 instances running
 
App started
 
Showing health and status for app test-php in org myorg / space mydept as admin...
OK
 
requested state: started
instances: 1/1
usage: 256M x 1 instances
urls: test-php.10.244.0.34.xip.io
 
     state     since                    cpu    memory          disk
#0   running   2014-09-29 07:52:38 PM   0.0%   84.9M of 256M   0 of 1G

It’s now possible to view the app using a browser. From the command line you can access it using this command:

w3m http://test-php.10.244.0.34.xip.io

Observations

In my tests, the xip.io resolution was flaky. I saw intermittent failures with the response:

dial tcp: lookup api.10.244.0.34.xip.io: no such host

In some cases I would have to run the same command a few times before it could resolve the host.

The VMs I setup obtained IP addresses on my network. However, when I tried to access apps or the API over that IP address, the connection is refused. Despite adding the domain (e.g. dhcpip.xip.io) to CloudFoundry and creating routes to my application, all attempts to use the API or load apps over the external IP failed.

Software Engineering

Windows net use command examples

Recently I’ve been accessing a lot of network resources from Windows. This is pretty easy in principle, but can become complicated when there are various credentials available, and each set of credentials provides a different level of access.

For example, a single share may have two different levels of access based on two unique usernames and their corresponding passwords. The first provides read only access, the second provides full write access. There may be times that it’s desirable to be connected read only and other cases where you require full write access.

That’s where the ‘net use’ command comes in. You can learn more about net use here. In this article I cover these cases.

  • Connect to a network resource (authentication)
  • Disconnect from a network resource. This is generally in order to reconnect with different credentials.

Connect to a network resource

This is really pretty easy to do. You begin by opening up the windows command line. Lately I like to use Console2 more than the built in command line. If you wanted to connect to the network share “\\myhost\myresource” and the domain, username and password were respectively “mydomain”, “myuser” and “mypass” the command you would type in is:

net use \\myhost\myresource mypass /USER:mydomain\myuser

It’s also possible to leave out the password in the above example and you will be prompted as follows:

The password is invalid for \\myhost\myresource.

Enter the password for 'mydomain\myuser' to connect to 'myhost':

 

That way you don’t inadvertently cache the password in the history of your console window (although this is more short lived than in Linux since it clears each time the window is closed).

It is also possible to leave out the domain and provide just a username if a domain isn’t used for authentication on your network.

Disconnect from a network resource

Disconnecting wasn’t obvious at first, but it’s really quite easy. Simply use the “/d” option to delete the cached credentials for the specified resource.

net use \\myhost\myresource /d /yes

 

What’s surprising is that Windows only has a command line interface to accommodate these details 🙂