Skip to main content

How can VMware Integrated Containers be useful in real life scenario - PART1


What is VIC:

VIC - vSphere Integrated Containers enable IT, teams, to seamlessly run traditional workloads and container workloads side-by-side on existing vSphere infrastructure.

The solution is delivered in the form of an appliance just like any other VMware mgmt solution. The appliance comprises of, 

  • vSphere Integrated Containers Engine, a container runtime for vSphere that allows you to provision containers as virtual machines, offering the same security and functionality of virtual machines in VMware ESXi™ hosts or vCenter Server® instances.
  • vSphere Integrated Containers Plug-In for vSphere Client, that provides information about your vSphere Integrated Containers set up and allows you to deploy virtual container hosts directly from the vSphere Client.
  • vSphere Integrated Containers Registry (Harbor), an enterprise-class container registry server that stores and distributes container images. vSphere Integrated Containers Registry extends the Docker Distribution open source project by adding the functionalities that an enterprise requires, such as security, identity, and management.
  • vSphere Integrated Containers Management Portal, a container management portal, built on the VMware Admiral project, that provides a UI for DevOps teams to provision and manage containers, including the ability to obtain statistics and information about container instances. Management Portal administrators can manage container hosts and apply governance to their usage, including capacity quotas and approval workflows. Management Portal administrators can create projects, and assign users and resources such as registries and virtual container hosts to those projects.

All components run on Photon OS 2.0. These components currently support the Docker image format. vSphere Integrated Containers is entirely Open Source and free to use. 
Why VIC and how does it differ from other services: 
As the VIC is entirely Open source and freeware, it can be tested in any existing VMware environment. We do not need many efforts or changes to introduce VIC in our setup. 
With no or minimal efforts we can get the VIC up and running. The VIC can be used for any container/cloud-native application testing. If you are a starter or new to cloud-native application hosting/testing then VIC is a great place to start.   
Being said if you are a learner or new to container apps, then VIC will become handy, as you don't need to spend much time on setting up the foundation. 
Unlike any other cloud-native platforms, VIC doesn't require much time to set up the base infrastructure. Once you deploy the VIC, you are ready to spin up the 1st container., 
Deployment of VIC: 
The deployment of VIC appliance is as same as any other vmware appliance and pretty straight forward. 

Important note regarding Network:
VCH Networking

Configuration steps : 
Once we deploy the appliance successfully the next is to configure it for use. 
1. Open Chrome and access the appliance to get the administration portal. 

2.  This is the landing page of the VIC 

3.  Next step is to configure the users who can manage the VIC and VCH. This can be done in Identity management. 



4. Create a new Project. The project can be either allocated to a team or for a specific application hosting. This is a logical grouping of containers 

5. There will be a default project as well and we can add the projects based on the necessity 


6.  Each project should have a members or entitlements, internal repositories settings, Infrastructure ( where we add the VCH) etc 




7.  We can add the users from the Identity manager ( integrated with LDAP or AD). Assign the role of the user in the specific project 




8.  We can add users and groups for multiple projects at once 


9. 




Next topic we cover : 
1. How to deploy a VCH 
2. Add VCH host to the Project 
3. Spin up the first container in the project 

Thanks for reading! 



Popular posts from this blog

HOW TO EDIT THE BCD REGISTRY FILE

The BCD registry file controls which operating system installation starts and how long the boot manager waits before starting Windows. Basically, it’s like the Boot.ini file in earlier versions of Windows. If you need to edit it, the easiest way is to use the Startup And Recovery tool from within Vista. Just follow these steps: 1. Click Start. Right-click Computer, and then click Properties. 2. Click Advanced System Settings. 3. On the Advanced tab, under Startup and Recovery, click Settings. 4. Click the Default Operating System list, and edit other startup settings. Then, click OK. Same as Windows XP, right? But you’re probably not here because you couldn’t find that dialog box. You’re probably here because Windows Vista won’t start. In that case, you shouldn’t even worry about editing the BCD. Just run Startup Repair, and let the tool do what it’s supposed to. If you’re an advanced user, like an IT guy, you might want to edit the BCD file yourself. You can do this

AD LDS – Syncronizing AD LDS with Active Directory

First, we will install the AD LDS Instance: 1. Create and AD LDS instance by clicking Start -> Administrative Tools -> Active Directory Lightweight Directory Services Setup Wizard. The Setup Wizard appears. 2. Click Next . The Setup Options dialog box appears. For the sake of this guide, a unique instance will be the primary focus. I will have a separate post regarding AD LDS replication at some point in the near future. 3. Select A unique instance . 4. Click Next and the Instance Name dialog box appears. The instance name will help you identify and differentiate it from other instances that you may have installed on the same end point. The instance name will be listed in the data directory for the instance as well as in the Add or Remove Programs snap-in. 5. Enter a unique instance name, for example IDG. 6. Click Next to display the Ports configuration dialog box. 7. Leave ports at their default values unless you have conflicts with the default values. 8. Click N

DNS Scavenging.

                        DNS Scavenging is a great answer to a problem that has been nagging everyone since RFC 2136 came out way back in 1997.  Despite many clever methods of ensuring that clients and DHCP servers that perform dynamic updates clean up after themselves sometimes DNS can get messy.  Remember that old test server that you built two years ago that caught fire before it could be used?  Probably not.  DNS still remembers it though.  There are two big issues with DNS scavenging that seem to come up a lot: "I'm hitting this 'scavenge now' button like a snare drum and nothing is happening.  Why?" or "I woke up this morning, my DNS zones are nearly empty and Active Directory is sitting in a corner rocking back and forth crying.  What happened?" This post should help us figure out when the first issue will happen and completely avoid the second.  We'll go through how scavenging is setup then I'll give you my best practices.  Scavenging s