Wednesday, January 3, 2018

Year in Review 2017


Another year has just started and it's time to look back and see how much I contributed to the community.

2017 was a busy year, with a lot of challenges and work to be done, I had the amazing opportunity to spend 3 months with VMware Technical Marketing Team for Cloud-Native Applications, where I learned a lot about this new emerging world and technology, you might have noted the effect on my post subjects.
The drawback about all this rush, it that I have produced only 27 posts this year, while for the past 3 years it was always over 30, I had to confess I'm a bit disappointed with myself, but that's the thing when you run a personal blog on your own free time.

Interesting though is this 27 posts only generated 64,407 pageviews, a slight increase of 1% from last year, I'll call it a victory.
The audience is coming from all parts of the globe, 164 countries to be more precisely, but mostly coming from US, India, UK, Germany, and Brazil.

These are my Top 10 Blogs for 2017 (in red it's rank # from 2016)

#1.  NSX Reference Poster (#1)
#2.  vSphere Integrated Containers Networking
#3.  VMware Converter Configuration Tips (#4)
#4.  Enable vRealize Orchestrator Control Center
#5.  vSphere Replication Traffic Isolation
#6.  Unlock vRealize Orchestrator default VMware Account (#2)
#7.  ESXi password Complexity Requirements (#3)
#8.  vSAN streched cluster topology explained
#9.  VMware script to delete/remove VMs (#6)
#10. RDM disk corruption on Microsoft Failover Cluster

NSX reference poster made #1 again, I have to admit it's a damn good poster, also I'm glad 50% of the top 10 posts are debuting on the list, which means I'm generating meaningful articles.
One last thing, VMware Converter Configuration Tips post made it again, ranking in the Top 10 since 2013;
Are there still people converting physical machines ?!?! please, if you do let me know ; )

Now, let's make 2018 better !!!!

Friday, November 17, 2017

vSphere Integrated Containers – additional Docker commands

vSphere Integrated Containers brings an enterprise container runtime into vSphere environments, where developers, who are familiar to Docker, can run their containerized applications transparently without even noticing it’s running on a nontraditional Docker host.

In order to provide this seamless experience, VIC must provide a completely parity of supported commands with Docker. VMware has been putting a lot of efforts on each release to add as much commands as possible, making developers life easier and easier.
Along with a bunch of new features and fixes, VIC 1.2 also made a step closer to the 100% parity with Docker adding support for the following most used commands;

- docker cp
description: Copy files to and from containers
syntax: docker cp "src_file" container_ID:"dst_path"
- docker exec 
description: run commands on a running container
syntax: docker exec container_ID [command]

- docker commit
description: Commit changes to a container into a new image
syntax: docker commit container_ID new_image:tag

- docker diff
description: Inspect for differences on the containers’ file system since it’s creation
syntax: docker diff container_ID
A = file added
C = file changed
D = file deleted

- docker stats (not really new, but on 1.2 we added support for network statistics)
description: Shows container’s statistics
syntax: docker stats container_ID

For a full list of supported Docker command on VIC check the documentation.

Tuesday, November 7, 2017

vSphere Integrated Containers - Custom Certificates

vSphere Integrated Containers (VIC) leverages TLS (transport layer security) to ensure communication security between client and Virtual Container Hosts (VCH) providing not only traffic encryption but also guaranteeing the identity of the certificate and it’s creator.

In a previous post I already talked about protecting your VCHs with TLS, but it lacks a process on how to generate your own Certificate Signing Request (CSR), which can be used to request a valid certificate from an internal or public Certificate Authority (CA), keep in mind it’s not intended to be a definitive guide, certificate is a wider subject with a lot of options that can be leveraged, like encryption methods, key size, certificate requirements, etc.. with that said, use at your own risk and make sure to test it before going into production.

I will use Openssl tool to generate an RSA Private Key and CSR, if you don’t have it yet download and install it first, it has a version available for each of the popular O.S.

For the purpose of this example, my VCH will be named vch01, defining a name for your VCH is  important for the certificate specifications like common name, make sure you adjust it accordingly  when creating your owns.

The certificate requirements for VCH are: 
  • an X.509 certificate
  • KeyEncipherment 
  • DigitalSignature 
  • KeyAgreement 
  • ServerAuth
Let’s start creating a directory where we will store our files
Run: mkdir /tmp/vch01

To make things easier I created a configuration file where I added all the certificate settings, it could also be used as a template for future requests
Run: vi /tmp/vch01/vch01.cnf

 Add the fields as the screen bellow, updating the fields related to your environment
Now let’s create our RSA Private Key, this key will be used to signed the CSR
Run: openssl genrsa -des3 -out vch01.key 2048 pkcs8
The options on this command are:
  • des3 is the cryptographic method
  • 2048 is the size of private key 
  • pcks8 is the standard syntax for storing information
VIC does not support PCKS#1, so if you have a key like that convert it before proceed.

To make sure the key is OK
Run: openssl rsa -in /tmp/vch01/vch01.key -check

By default the key is encrypted and some applications does not support it, such as VIC, so to proceed we need to remove the passphrase from it to avoid issues when creating your VCHs
Run: openssl rsa -in vch01.key -out newvch01.key

Now that we have our private key we can generate the CSR.
Run: openssl req -new -key newvch01.key -out vch01.csr -config vch01.cnf

Since we are using a config file to provide the certificate information, nothing will be prompted but the key passphrase
The syntax on this command contains:

  •  -key; which specified what key to use to sign the CSR;
  • -out; csr output file;
  • -config; the configuration file with certificate details;

Before sending the CSR to your CA check if it contains the information you need
Run: openssl req -in vch01.csr -noout -text

If everything is fine you can send it to your CA in order to generated a signed certificate.
Once you get your signed certificate back is just a matter of creating your VCH with the certificate as I stated on Protecting your VCH post.

At this point the process of generating your CSR is done,  but if either you don’t plan on having your certificate signed by a CA or wish to test your new implementation while the CA is signing your certificate what you need then is to self sign your own certificate.

Self-signed certificate can also be done with openssl, you only need a RSA key and a CSR, which we just created so we are good to go.

To generate a self-signed certificate which is good for 365 days, issue the following command
Run: openssl x509 -req -days 365 -in vch01.csr -signkey vch01.key -out vch01.pem

That's it, you now have your self signed certificate to create your VCHs.

  • The certificate process wen fine but during the VCH creation you got the following error:
ERROR Failed to parse certificate: tls: failed to parse private key
ERROR Unable to load certificates: tls: failed to parse private key
ERROR --------------------
ERROR vic-machine-linux create failed: tls: failed to parse private key

It’s just because your key is encrypted, you need to remove the passphrase from the key, check the steps above on how to remove passphrases from your key.

  • Once your VCH is created with a self-signed, the CA cert will be the same as your server certificate, just create a copy of it and name it ca.pem, otherwise when you try to communicate with your host you will got the certificate signed by unkown authority error message
x509: certificate signed by unknown authority 

That's all folks.....

Monday, October 30, 2017

vSphere Integrated Containers – Application Repackaging

When talking about containers it’s inevitable to think about modern application built natively for the cloud, but the reality for most companies is that the majority of, if not all, their applications still traditional applications and probably they will still that way for many years to come.

Does that mean you cannot join the containers party ? ABSOLUTELY NOT !!!

One of vSphere Integrated Containers use cases is target specific for you, Application Repackaging;
What it means is that you can take your traditional application, monolithic or even a 3-tier application and repackage them as containers, without having to change a single line of code.
You don’t even need to change all layers of your application, start simple. Containerize only the web/presentation layer and give it a try.

You will immediately see the benefits of running applications within containers, like:

  • Faster Recovery: in case of disasters, you don’t need to recreate your VMs, patch them, install app, configure etc.. just instantiate a new image in a matter of seconds and you are back in business;
  • Easy scale-out: adding a new node to an application is just as simple as running a new container, just select the same image as a base source and it’s done;
  • Faster life-cycles: upgrading a container with a new application is much simpler and faster, you can upgrade your application in minutes;
  • Portability: container images are becoming the de-facto application delivery method, just because it runs anywhere, desktops, vSphere Infrastructure and to the cloud without any modification what so ever.

And it’s not all, with vSphere Integrated Containers every container is a VM, so you also get all vSphere benefits:

  • Increased availability: leveraging High Availability (HA), in case of hardware failures, your containers will be restarted automatically on another healthy host, reducing your downtime and increasing your application availability
  • Predicted performance: Distributed Resource Scheduler (DRS), will make sure your container gets the performance it needs, moving the VMs/containers around to load balance the workload among the hosts of your cluster, ensuring the ESXi host has the free resource it needs to fulfill your containers needs.

If you are as excited as I am with all these possibilities, watch the demo video to see it in action.


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. Reach me at @dumeirell

Most Viewed Posts

Blog Archive