Docker for vSphere Admins

In this post I want to explain what Docker is, in such a simple way, so that every vSphere Admin would get it in seconds :) I was initially having a difficult time understading the value of Docker (vs VMs) etc, but I think the analogy i’ve come up with should be quite simple.

The TL;DR version of what docker is, simply put – Docker is the new shiny linux based Thinapp, for not-necessarily-end-user applications but more for dev apps – DBs, Backends, etc

YES. I’ve said it, and i’ll repeat, docker, in my eyes, is VERY comparable to Thinapp / Appv / any other application virtualization software.

I’ll elaborate.

What docker aims to do initially, is to help applications delivered seamlessly throughout environments using something called LXC / or Linux Containers, which are essentially a method of isolating application processes within linux, dictating which resources are and aren’t available for your specific app.

In a sense, this is exactly what Thinapp / Appv had tried to do in the past, only for the EUC market. You take IE6, you install it in an isolated ‘fake’ environment (with fake registry, face C: , etc) , and there you go. you can deploy it on any windows OS.

Essentially, when you build a Dockerfile, used to create docker images, you are doing the same. You decide on a base OS, with statements like :
“FROM centos7”
or any other OS you wish to build your application on. Then, you describe how your app is installed, whether its running scripts, or yum commands, using the different tools docker provides you with like environment variables etc. So commands like:
“RUN yum install httpd” for example, depict what is necessary to dockerize an apache web server.

Lastly, you create the endpoint for the running container. Meaning, you select which ‘.exe’ should run when the container is started (for those of you who’ve used thinapp) so in linux, you should see something like running a script, starting a service, or running a binary file.

So now, I can build my apache web server docker image, using my Docker file, and run it on any linux distro I want to, since the dockerized apache *thinks* its running on ‘centos7’ using the centos image (which is essentially the centos libraries, and linux filesystem structure) and using the same linux kernel.

That’s why containers best practices dictate its better off to run a single process in a container, since its just virtualizing an app for its OS environment. In that sense, Dockers and VMs are not contrasts at all. VMs, solve an operations issue, for an OS being dependent on hardware, and Docker, solves a developer issue, for an App being dependent on a specific linux OS, or OS packages.

So to finalize my weird but valid (IMO) comparison, if linux had IE6, using docker, you could run IE6 & IE 7 at the same time without any OS issues.


Reset Photon OS root Password

So, you’ve gone cloud native and installed Photon OS. Since my team develops quite a few things here at VMware using Photon OS and docker, i’ve come across a situation where i’ve needed to reset Photon’s root password. Here is how it’s done.

Photon's boot screenphoton_grub2

Shutdown your PhotonOS VM and re-start it, press the ‘e’ button when you get to the boot screen (as seen below). This in turn will get you to Photon’s GRUB2 interface.

From there, the process is fairly simple, as all you have to do is to add a couple of parameters to the end of the linux boot parameters line.

 rw init=/bin/bash 

This should look something like this when you’re done.


Now press Ctrl+X in order to continue with the boot sequence, and your boot process will end in a bash shell, punching in the ‘passwd’ command will reset your root user password.

And remember kids –
He who has console rights to server = owns root/admin privileges (true to any OS)


Docker Machine on OSX, with VMware Fusion

For those of you who want to experiment with new technologies, e.g , docker – here’s a nice tutorial on how to run docker on OSX, without boot2docker which uses VirtualBox. Since I have VMware Fusion on my Mac, I was looking for a way to get rid of VirtualBox while still running docker on OSX with ease, using VMware Fusion instead, and getting direct access to the docker containers like you would on native linux.


In OSX, Docker-daemon can’t run natively, since docker uses a linux kernel feature for containers (or FreeBSD ‘Jails’ ) which Mac OSX simply doesn’t have / was removed / not exposed. Bottom line – you cannot run docker on OSX Natively.

To the rescue – Boot2Docker.


docker on OSX with boot2docker

Boot2Docker is a nice cli & package that installs VirtualBox on your Mac, creates a small VM , with a preconfigured Boot2Docker iso to boot from. Boot2Docker is also a tiny linux distro aimed at doing one thing only – running docker. As this is usually not a real issue, the one thing you cannot do, is connect to the container itself while your on a remote host. that is, unless you expose specific ports to do so, since docker also creates an internal NAT on its hosting box.

So to summerize the problem again – How can I use docker on my OSX Mac, without having to use VirtualBox, while also being able to natively connect to my container’s network?

Fusion & Docker-Machine

To the rescue – Docker-Machine & VMware Fusion!
Docker-Machine is a utility (in beta) that allows you to start simple docker-hosts with ease, and on multiple cloud providers / private cloud providers. It support a really long list of providers at the moment like :

  • VMware vSphere/vCloudAir/Fusion 
  • OpenStack
  • Azure
  • Google
  • EC2
  • list goes on…

So essentially what id does is kind of like the boot2docker cli only not limited to just VirtualBox ( in fact i think they’ve merged their code base with docker-machine, but never mind :) )
First we’ll install docker-machine for OSX by simply downloading it here , renaming the downloaded file to “docker-machine” , giving it right permissions, and moving it to a generally available folder on OSX.
Also, lets download the docker client for OSX with brew.

Now, lets create a docker-machine on our fusion instance


Docker VM on Fusion

This will create a new VM within fusion named osxdock. Now, we can work with our docker as we would on VirtualBox. If we would expose ports to the Boot2Docker host, we would be able to access them by accessing the VMs local ip and port allocated by Fusion. To get to our docker client to connect to our docker vm , we’ll run the command $(docker-machine env osxdock) which will basically set our environment variables to our current active docker-machine. Now, in order for us to be able to natively connect to our docker machine, like we would on other linux distros running docker directly, we’ll fiddle around with Fusion networking. First, lets create a new network (don’t want to modify existing networks, although it should be ok) VMwareFusion – > Prefrences – > Network – > Click Lock to unlock, and Add a network with the + sign. Mark only “Connect the host Mac to this network” & “Provide addresses on this network via DHCP”. I prefer to assign something close to the docker network, like as my dhcp subnet. Lets take our docker-machine offline so we can add it with a network interface:

network settings for the NIC I added to osxdock

Network settings for NIC#2 I added to osxdock VM in Fusion

Open the machine within Fusion and add a NIC that uses the new network you had just created. In order for us to communicate with the containers we’ll have to create a route to that NIC, so each time our MAC tries to access the docker container itself, it would route through the docker-machine new NIC.

Now for the last part. In order for our route to remain static, and for the docker-machine which essentially just boots a Boot2Docker iso, thus , has no persistence, we’ll modify the Fusion network.
open up a terminal and go to the network setting (vmnet<number>) in my case, 4:

We will actually add a DHCP reservation. So our osxdock VM will always get the same IP automatically on the new NIC we’ve configured.
Add the following configuration to the bottom of the file:

Where EE:EE… stands for osxdock’s MAC address, and fixed IP is the fixed IP you want to give it. Make sure that you are allocating an IP from that DHCP’s range configured in the first section of the file.
you will need to restart Fusion after this configuration change, or just run this command to restart Fusion Netwroking:

Lastly, bring up your docker-machine, and make sure it gets the ip address you’ve configured by running ifconfig on the docker vm

Now tell your Mac to route all traffic to container subnets which is by default to the osxdock vm “static” ip like so:

You can also create a permanent static route using the OSX StartupItems options, but I’ll let you google this one since it isn’t short unfortunately.

Presto! You can now run docker with a “native feel” on OSX, using VMware Fusion! You’ll be able to ping containers, access them without exporting ports, and work as if you are working in a native linux environment.

To check this, simply run a docker machine on osxdock, inspect it, and ping it, with the following command:

Happy devving!


It’s vBlog Voting Season!

It’s voting season in the blog-sphere, and you get to influence! For the past ±2 years i’ve been blogging about vRealize Automation (formerly vCAC ) ever since version 5.1 came out :) it only seems like yesterday but I guess its been a while ain’t it?
Since my role shift to the vRealize Air team i’ve been VERY busy, but thats a positive thing! I’m now starting to set up a new lab, and will also blog a whole lot about vRealize Air Automation (vRAA) which is our currently in Beta vRealize Automation as a Service, hosted in vCloud Air. So I expect a LOT of great blogposts in the upcoming year, just for you, my readers! Its very worthwhile to stay tuned via RSS, and even more worth while to help my blog get to the Top 100 mark in the vSphere-Land vBlog contest!

If you’ve enjoyed my work, used my site, asked a question and was replied promptly (I do try my best) please take 5 minutes to vote for my blog, as it would mean a lot to me, and will let me know i’m doing this blogging thing right :)
You can cast your vote here 



vRealize Automation 6.2 (vCAC) – GA! What’s New?

Another yearly quarter, and another product release! vRealize Automation 6.2 is now GA (Grab it!) and it brings so much awaited functionality to the table! This is the first release to have some impressive integration with VMware’s vROPS (formerly vCOPS) product, which is also GA today with version 6.0.

New Features!

vR Automation 6.2 / vR Operations 6.0 integration

Allows for Health badges to be viewed directly from item page, allowing the user to have a brief health summary of his VM. Also, vC-Ops-128xresource reclamation is available with insights from vROPs 6.0. When you’ll filter a VMs performance once vROPs is configured into the system, you’ll be able to search the metrics from vROPs rather then vCenter.
These two features are a huge benefit for day-to-day management of your private cloud VMs, and will surely drive great value in any environment where vROPs & vRA are integrated.

ASD Form vCO Workflow Execution

The ASD functionality of vRealize Automation always keep getting better and better. The latest improvements include being able to invoke a vCO action from the item form, when the form is displayed to the user. This, enables us to retrieve data for that request from 3rd party systems, or calculating addition information within vCO. This also applies to any custom day 2 operations you can build for vRealize Automation.

ASD Import/Export Content

This release also enables us to import and export content from vRA! Stuff like service blueprints can now be transferred from instance to instance.


VAMI Node Mgmt

Proxy Configuration for vCloud Air Endpoint

For those of you managing vCloud Air VMs with vRealize Automation, leveraging vCloud Air through an enterprise proxy is now possible via a special proxy setting in the vCloud endpoint

Centrelized Node info/log collection in vRA-VA

The vRealize Automation VA had it’s management interface revamped, and now allows for a full view of the installed components from a single point, checking if all components had communicated recently with the VA, and also the ability to collect logs in a centrelized fashion, straight from the VA’s VAMI management UI.

vRealize Applications & Custom Properties

For those of you who started exploring vRealize Applications, you can now expose the provisioned App ‘User queried’  properties, into the vRA request. Giving the user the ability to easily modify an application deployment at request time.

Come-Back Features!

Approval Props

Setting Approval Policy

Some of the (awesome) features that went away during the whole 5.2->6.0 transition are now doing a comeback! And these are GREAT news since these were REALLY handy stuff!

Editing Custom Properties on Approval

With vRA 6.2 you will be able to set custom properties to be editable by the approver! This is a wonderful feature that allows for a whole set of business logic approval use cases to be utilized again with vRA 6.2!

Calendar Widget


Approval Editing Properties

The all mighty calendar of events widget is now back, and allows you to view a calendar with all your item expiry / archiving / deletion dates right on the vRealize Automaion home page for every user! This is valuable to keep track on your VMs and leases and is a wonderful feature I really missed from 5.2

Hidden Features!

Wait… What?
So you’re probably wondering – “Why are there hidden features?” Well, the features that i’m going to describe below aren’t really meant for regular use, but are more related to my new role. I did think of some enterprise use cases where these could be beneficial, but keep in mind that they are considered ‘Experimental’.

Installing DEMs / Agents in Different Domains

One of the issues that I came across with some of my former customers (you know who you are!) was the need to manage several, unrelated domains with one vRA instance. This, naturally gets you to a decision point where IAAS is installed in a certain domain, be it management, prod, or where ever you see fit.


Calendar of Events

In order to have DEMs / vSphere Agents in other domains , you would need to do some nasty things. In this release, using the silent installer, you are able to grant a certain user in a remote domain (without any trust relationship) full access tothe IAAS repository. Meaning, that a vSphere Agent / DEM can be installed in a totally separate domain environment, under a different set of credentials from the main IAAS server components!

In order to do so, you’ll need to add two properties to the silent install for the DEM, named WorkflowManagerInstaller.msi . The properties are : DEM_REPO_USER / DEM_REPO_PASSWORD . An example of a silent install including these two properties should look something like this:

For this trick to work on a vSphere Agent, simply run a config command after the agent is installed:

Proxying DEM Workers

When installing a DEM Worker with the silent installer, you’ll be able to add a proxy configuration for that DEM. So if you have any DMZ environments that you want to manage, this could be a great way to do so!

To proxy the DEM / Agent , simply use the silent installer mentioned in the paragraph above, and activate 3 new install parameters:

  • PROXY_ADDRESS <proxy ip addres>:<port>
  • USE_SYSDEFAULT <true/false>
  • BYPASS_ONLOCAL <true/false>

These are pretty self explanatory. The USE_SYSDEFAULT, tells the DEM to grab proxy configuration from the default system configuration found in IE proxy settings. BYPASS_ONLOCAL , will order the DEM to bypass the proxy when it detects a call from the same network he’s on.