Thursday, October 19, 2017

vSphere Integrated Containers – working with variables



If you play long enough with vSphere Integrated Containers (VIC), sooner you will realize how long and tedious are the vic-machine commands.

Do you know you can make use of VIC variables to simplify those day to day activities?!?

Taking as an example the simple task of listing all your created VCHs, you would need a command like that:

vic-machine ls --target vcenter.vsphere.local --user administrator@vsphere.local --password Secure123 --thumbprint 2F:C3:3C:5D:99:B6:31:87:77:58:4D:8F:2F:75:D9:0C:01:F8:FE:6B

As I said….loooong !!!!
What if I tell you can just run: vic-machine ls instead
Much simpler, right ?!?!

Well, that’s all possible setting up the VIC variables, that will store your values and use them on future commands; these are the ones:

  • VIC_MACHINE_TARGET: that’s the variable that tells which is your target vCenter to use;  
  • VIC_MACHINE_USER: the username with privileges to run commands against your target vCenter;   
  • VIC_MACHINE_PASSWORD: the password for the username you just specified with VIC_MACHINE_USER;
  • THUMBPRINT: the variable that contains the thumbprint of your target vCenter;

You just need to set your environment variables to make it works.
Depending on your operations system the command to set environment variables are different;
For Linux:       export “variable”=”value”
For Windows: set “variable”=”value”

Now, let’s see how our example will looks like:

Run: export VIC_MACHINE_TARGET=vcenter.vsphere.local
Run: export VIC_MACHINE_PASSWORD=Secure123
Run: Export VIC_MACHINE_THUMBPRINT=2F:C3:3C:5D:99:B6:31:87:77:58:4D:8F:2F:75:D9:0C:01:F8:FE:6B
Run: vic-machine ls

Now you can just run vic-machine commands like ls, create, delete, configure and others without having to provide the same information over and over again.

Since we are talking about making your life easier, do you know Docker has it’s own variables too?

To check the information of your docker host you would run a command like that:
docker –H 192.168.10.10:2376 --tls --tlscacert /home/vch01/ca.pem --tlscert /home/vch01/cert.pem --tlskey /home/vch01/key.pem info

Would it not be better just run: docker info

Yes you can, it works the same way, setting up DOCKER variables, these are the most common ones;

  • DOCKER_HOST: set your target docker host or VCH in our case; 
  • DOCKER_TLS_VERIFY: set your docker client to check for TLS, set to 1 to enable verification; 
  • DOCKER_CERT_PATH: the path where docker host certificate and keys could be found, keep all certificates for the same docker host on the same folder, that makes things easier down the road;   
  • DOCKER_CONTENT_TRUST: when set to 1, it enables content trust;  
  • DOCKER_CONTENT_TRUST_SERVER: set your notary server for content trust verification and signature;
 Give it a shot, I bet you will feel more productive and less tedious.

See you next.
 

Monday, October 9, 2017

vSphere Integrated Containers – Name Convention


During the past several years, infrastructure Administrators came up with different methods to organize its vCenters, some with folders structures, some with fancy VMs nomenclature and prefixes.

When we think about vSphere Integrated Containers (VIC) consumption model, containers as Virtual Machines (containerVMs), we realize it kinds of disrupted this organizational model, mainly because VM's creation is no longer under administrators control,  but also because developers are now creating and deleting their own containerVMs inside vCenter without even noticing the existence of it, breaking the standards and controls applied so far by this new dynamic nature.

When a container is created by a developer within VIC, it’s respective containerVM, by default, is created in vCenter using the nomenclature of CONTAINER NAME + CONTAINER ID



For an infrastructure administrator, these VMs names are not very helpful, especially if you have controls and policies in place which depend on those VMs name.
Tools like vRealize Operations, VMware NSX or chargeback tools, might be ineffective when trying to manage and control those containerVMs.

To address these challenges, VIC 1.2.1 introduces the --container-name-convention option, which allows you to specify a prefix that will be applied to every containerVM during its creation, giving back to the administrator the control they require.

This convention option is determined during Virtual Container Host (VCH) creation. When creating your VCH there are many options available depending on your environment and your needs, I’m just focusing on --container-name-convention today, but if you are interested, check this link for the full options.

First, let’s check the prefix option based on the container name.
--container-name-convention “prefix”-{name}


This option enforces that each containerVM name will be made of the prefix you specify (in this example DEV) + the CONTAINER NAME


The second option is the prefix based on the container ID. 
--container-name-convention “prefix”-{id}


This option enforces that each containerVM name will be made of the prefix you specify (in this example PROD) + the CONTAINER ID


As you can see, it’s a win-win situation; from a developer’s point of view, nothing changes, they can still see it’s containers name and IDs just before, from a vSphere Infrastructure point of view it can create a standard that will be honored during containerVMs creation.




Monday, October 2, 2017

vSphere Integrated Containers – Developer Workflow



There’s no doubt vSphere Integrated Containers (VIC), is getting more and more powerful at each version, just check the several enhancements and capabilities which were released with version 1.2 and you will see what I'm talking about.

Today, I wanna walk you through a developer point of view workflow where we can create an image, storage it on a registry and then run it in production, with just 6 easy steps, all within VIC 1.2.

note: I already deployed a Virtual Container Host (VCH),  I'm leveraging Harbor, which is also part of VIC as my registry. If you think you need some help with those steps, let me know and I'll write another post explaining how I did it.

Let's do it;

Step 1 – run my Docker Container Host
Since VIC engine does not support (yet), docker build and docker push I will make use of a Docker Container Host (DCH), a native Docker host leveraged directly from VCH.


With the use of port mapping, DCH's services will be available through my VCH on port 12375.

docker run -d -p 12375:2375 vmware/dch-photon:1.13

Wait until it pulls the image from Docker Hub and starts it.
 
Step 2 – Set my docker client to the newly DCH
From this point on, I want all my commands to run against the recently created DCH, pointing my docker client to it. not really a required step but it makes things easier.

export DOCKER_HOST=192.168.100.160:12375

Step 3 – Build my image
It’s time to build my new image.
I’m using a simple Dockerfile, which uses nginx:latest image and update it. 
But you can be as much creative as Docker permits, remember; DCH is 100% Docker API compatible.

For easier identification, I’m building it and tagging it with a meaningful name. 
You can tag it something else later as well.

docker build -t registry.corp.local/justait/nginx:patched . 

it will take some time to pull the image and apply the updates. don't you worry.

Step 4 – Push to registry
My image is ready!! 
Now I can push it to my registry, everyone will be able to consume it.

docker push registry.corp.local/justait/nginx:patched 


I also pushed the unpatched version of nginx, just in case someone wants to use it too.
As you can see, both images are now stored in my registry under justait project


Step 5 – Set my docker client to my VCH
I want all my production containers to run on VIC, where they can benefit from vSphere features like DRS and HA.
So, let's set my docker client back to VCH,  

export DOCKER_HOST=192.168.100.160:2375

Step 6 – Run your container
It’s just a matter of running the container based on the new image.
But I'll not just simply run the container, I want to use this unique VIC feature of exposing the container's service directly on the network (Container Network).

docker run -d --net routable registry.corp.local/justait/nginx:patched

Here it is, from building an image to running a container in production and all we needed was a VCH. 

Writing a blog on your own free time, sometimes leave you without imagination, this topic was a suggestion from one of my readers, if you want to see something here, please, leave a comment or contact me on twitter, I really appreciate those ideas ;)
 

Who am I

My photo
I’m an IT specialist with over 15 years of experience, working from IT infrastructure to management products, troubleshooting and project management skills from medium to large environments. Nowadays I'm working for VMware as a Consulting Architect, helping customers to embrace the Cloud Era and make them successfully on their journey. Despite the fact I'm a VMware employee these postings reflect my own opinion and do not represents VMware's position, strategies or opinions.

Most Viewed Posts

Blog Archive