I was helping out a fellow colleague yesterday who was having some troubles handling a multiline echo statement within his Dockerfile. There are multiple ways in which you can create multiline Dockerfiles, the web is full of examples from using multiple echo statements (pretty ugly) to using heredocs which is easier to read and manage. The challenge was that he also wanted to substitute some variables into his multiline statement which apparently there were no examples online, at least neither of us could find.
Taking a closer look, I found that we can just leverage Bash's ANSI-C Quoting syntax $'string' to do what we want, which was actually something new to me as well. You can then pass in the variable like you normally would between the strings and that would give you the readability of heredocs and still be able to use Docker variables. I am sure there are other methods with more extensive escapes with single-ticks, but I also prefer a solution that is easy to read and use in case others need to manage it.
Here is a quick sample Dockerfile which demonstrates how this works:
RUN echo $'[powershell]\n\
name=VMware Photon Linux 1.0(x86_64)\n\
Basically the echo statement has $'SOME-STRING'$VARIABLE$'SOME-STRING'
If we build and run this Docker image, we can see that we have properly substituted the BASEURL variable into our file as seen in the screenshot below.
docker build -t sample .
docker run --rm -it sample cat /etc/yum.repos.d/powershell.repo
I personally prefer to keep such logic within a separate script which the Dockerfile can reference, but I was also sympathetic to that fact that my colleague wanted to keep things simple and just have everything within the Dockerfile. I figure I would share this in case other comes across this problem as well as benefiting myself as I will probably forget in a months time 🙂
The ESXi MAC Learn dvFilter Fling was released a little over two years ago and it has become a must have when it comes to running our ESXi Hypervisor within a VM, also referred to as Nested ESXi. The reason this Fling has become such a popular hit amongst our customers and partners is that it greatly improves the performance when “Promiscuous Mode” is enabled on a Virtual or Distributed Virtual Portgroup, which is a requirement for using Nested ESXi. Although this Fling works great, there are a couple of limitations with this solution today. The first of which is called out in the original Fling release notes, that once a MAC Address has been learned, it never ages out which is not ideal for long running Nested ESXi environments that generates a large amount of new MAC Addresses. The second, is the lack of vMotion support where the learned MAC Address table is not transfered to the destination ESXi host and must be re-learned.
To help address both of these limitations, the folks over in the Network and Security Business Unit (NSBU) have been working hard to improve upon the existing solution and have developed a new native MAC Learning VMkernel module called the Learnswitch. This new Learnswitch not only helps improves Nested ESXi workloads but it can also potentially benefit other workloads such as Nested Containers or other 3rd Party network inspection software. One immediate difference from the previous MAC Learn dvFilter solution is that rather than operating on the Network IO Chain, the filtering is now performed within the outer virtual switch layer itself which will provide some additional performance gains. The other added benefit from an internal VMware standpoint is that the Learnswitch is now vmkapi compatible, which means we will have a better backwards compatible story for supporting old releases of ESXi. One downside to this new solution compared to the previous one is that because the dvFilter operated below the virtual switch layer, it could support both a Virtual Standard Switch as well as the Distributed Virtual Switch. With the new Learnswitch, a Distributed Virtual Switch will be required. If you currently do not meet the requirements of the new Learnswitch, you can continue using the dvFilter, but it is recommended that you do not mix both on a single system but you can definitely make use of both solutions across different ESXi hosts depending on the constraints of your environment.
Here are some of the new capabilities provided by the new Learnswitch module:
- Overlay Network based that learning and filtering are done in Etherswitch forwarding check
- MAC Address learning is based on VLAN ID or VXLAN ID on uplink and leaf port
- Packet is filtered on uplink and leaf port if the MAC is learned on a different port
- MAC Address table size is 32k per system
- MAC Address aging support with default aging time of 5 minutes and configurable
- Unknown unicast packet is flooded by default and configurable to drop
- vMotion support that the MAC table learned on the port is transferred to destination host and RARP packet is sent
- Standalone VMkernel module available as a VIB
- net-learnswitch CLI to display MAC Address table, configuration and stats
One neat capability that was introduced with vSAN 6.6 is the ability to "silence" and disable specific vSAN Health Checks. A recent use for this came up on Duncan's blog where the vMotion health check would fail if you are using a vMotion network stack. As you can imagine, this feature can also come in handy for vSphere Home Labs where your hardware may not be on the official VMware HCL and wish to disable those specific vSAN Health Checks.
I know many of my readers have inquired about VCSIM (vCenter Server Simulator) which was a really useful tool that served a variety of use cases, but unfortunately it had stopped working with the VCSA 6.0 release. VCSIM is another topic that is near and dear to me and it is something I continue to push and advocate for internally at VMware. Earlier this week, I came to learn about a cool new incubation project that Doug MacEachern had been working on for some time now. Doug is an awesome VMware developer working on the vSphere Integrated Containers (vIC) project and he is also well known for his active contributions to both govmomi (vSphere SDK for Go) and govc CLI.
As you can probably guess from the title, the name of the project is called govcsim and it is a vCenter Server and ESXi API based simulator written using govmomi. It creates a vCenter Server model with a datacenter, hosts, cluster, resource pools, networks and a datastore. The naming of the objects is similar to that of the original VCSIM mode that was included with the VCSA. The number of resources can be increased or decreased using the various resource type flags. Resources can also be created and removed using the API. Doug had developed the tool to provide an easy way for their team to test some of the work they are doing with vIC. The tool is still under incubation but continues to received enhancements. In fact, the other day when I had used it for the first time, I had found a couple of issues which Doug resolved immediately.
I got a chance to give govcsim a spin the other day and currently you can connect to it using govmomi, govc, pyvomi (vSphere SDK for Python) or rbvmomi (vSphere SDK for Ruby). It currently does not work with PowerCLI (connects but no inventory), I know this is something Doug is currently looking into. You might also be able to connect using other vSphere SDKs but these are the ones that Doug and I have tried so far.
One of the things that I am most excited about from an Automation standpoint with the vSAN 6.6 release is that customers using PowerCLI will now have complete access to the vSAN Management API which we had initially introduced back in vSphere 6.0 Update 2. In PowerCLI 6.5R1, customers only had access to high level vSAN cmdlets which did a pretty good job covering the broad set of vSAN functionality. However, it did not expose the complete vSAN Management API and this has been something many customers have been asking about.
With the new PowerCLI 6.5.1 release, a new Get-VsanView cmdlet is now available that will exposes the complete vSAN Management API using PowerCLI. Since the vSAN Management API has been around since vSphere 6.0 Update 2, you will also be able to use this new cmdlet against a vSAN 6.2, vSAN 6.5 and vSAN 6.6 environment! You simply just need to update your PowerCLI installation which you should always do to get the latest fixes and enhancements.
When you connect to either a vCenter Server and/or ESXi host, you will be able to view all available vSAN Managed Objects for the system by simply running the cmdlet without any arguments as shown in the screenshot below.
If you wish to access a specific vSAN Managed Object type, then you will need to pass in the vSAN MoRef ID from the given list. Here is an example of accessing the "VsanVcClusterHealthSystem-vsan-cluster-health-system" which will give us access to the VsanVcClusterHealthSystem.