VMware Cloud Foundation (VCF) communicates periodically through the internet with a hosted web service in order to check for and retrieve software updates and bundles. What if you don’t have internet access? Today, I’m going to demonstrate how you can build out your own software repository for VCF.
Before we begin, it’s important to note that this process is not supported for production environments. To understand why, I need to give you a short overview of what I will be showing you today.
In a production VCF environment, the SDDC Manager is configured to communicate through the internet on port 443 (HTTPS) to a hosted web service at depot.vmware.com. It automatically polls this site frequently to check for new updates or software packages that may be applicable to the environment. If it finds an applicable bundle, it provides the user with an option to download the software bundle locally. Once downloaded locally, the software bundle can then be deployed as desired by the administrator.
Some environments may utilize certain network services, such as firewalls or proxies, to restrict network access. VCF supports the use of proxy servers and even provides several methods to manually download the bundles in the event that no internet access is able to be provided.
What I’ll be showing you here is how to setup a local system that will act like the web service at depot.vmware.com. Once it has been manually populated with the software bundles, you can point a SDDC Manager to it and it will act exactly like the official depot at depot.vmware.com.
You might be wondering then, given that there are already support for proxy servers and methods to download bundles when you don’t have internet access, then why would someone want to setup a local depot?
One reason is that you want to mimic the experience of obtaining the bundles in a production environment. For example, I’ve used this method to provide training to others on VCF. It allows me to inject problems for students to troubleshoot. It also allows me to have several sandboxed VCF environments where issues with one environment will not bleed over into another environment. Of course, I can also use this to make demos as well as the process looks exactly the same as it would in a production environment.
Another reason for building a local depot is in the event that you have multiple VCF environments, like in a lab. Not only can you provide bundles to all the various VCF environments, you can selectively choose what bundles you want to make available. This can be helpful if you are testing certain aspects.
The problem with setting up a local depot is that it is manually populated and configured. This means that the reliance is now on the maintainer of this local depot to maintain and update the bundles appropriately and in a timely manner. Additionally, security and general maintenance of the local depot is also dependent on the user. In a lab environment, especially one that is sandboxed (or isolated), then security within the sandbox may not be as stringent. That’s not to say it’s not important, however. All this manual effort takes away from the ease of use VCF provides in a production environment and adds more potential failure points.
Assuming you still have a good reason to build a local depot, here’s how to get it done…
The depot is simply a web server. Although we could configure this using IIS on Windows, for this example I’m going to show you how to do it on a Linux-based system. In particular, I’m going to use Ubuntu 19.10, however any Linux system would work – there would just be slightly different commands used.
As this is just for a lab environment, I’m not going to worry too much about the security aspects. For example, I won’t be generating SSL certificates to be used and so on. This could certainly be done, but I simply do not need it for my lab environment.
- Deploy Ubuntu
- Just perform a standard deployment of Ubuntu. It doesn’t matter if you do it as a virtual machine or a physical system. Some things to note:
- Give the system a static IP. This will prevent you from having to reconfigure the SDDC Manager if the system gets a different IP.
- You need some space available. The software bundles can get quite large, with some individual bundles exceeding 8 gigs. I setup mine with about 300 gigs of space, but your needs may vary.
- Assign it a DNS name. This isn’t a requirement, but it does make things a bit easier.
- Just perform a standard deployment of Ubuntu. It doesn’t matter if you do it as a virtual machine or a physical system. Some things to note:
- Update and upgrade the base system
- It’s always good to update everything before you begin. Just connect to your newly deployed Ubuntu system and use the following commands:
- # apt-get update
- # apt-get upgrade
- It’s always good to update everything before you begin. Just connect to your newly deployed Ubuntu system and use the following commands:
- Install SSH
- I find things are easier if I can SSH into the systems. To do this, we’ll need to install the SSHD server on the system and get it started:
- # apt-get install openssh-server
- # systemctl enable ssh
- After this, you should be able to SSH directly to the system. (Note, if you want to do this as the root user, you will have to edit the sshd_config file and restart the SSH service)
- I find things are easier if I can SSH into the systems. To do this, we’ll need to install the SSHD server on the system and get it started:
- Add a Depot user
- We will add a user that will be used by the SDDC Manager to connect to this depot.
- # adduser depot_user
- We will add a user that will be used by the SDDC Manager to connect to this depot.
- Install required packages
- We are going to need to add in some software packages from the base Ubuntu deployment. In particular, we are going to add a web server (nginx) and some other utilities.
- # apt-get install nginx ssl-cert apache2-utils
- We are going to need to add in some software packages from the base Ubuntu deployment. In particular, we are going to add a web server (nginx) and some other utilities.
- Edit the nginx configuration file
- We are going to make several changes to the default nginx configuration file. These changes will allow for us to use SSL to communicate to the server, sets the web home directory, and allows for the use of basic authentication. Just add/modify the lines to match the sample shown below (make sure to scroll down in the window to see everything):
server {
listen 80 default_server;
listen [::]:80 default_server;
# SSL configuration
#
listen 443 ssl default_server;
listen [::]:443 ssl default_server;
#
# Note: You should disable gzip for SSL traffic.
# See: https://bugs.debian.org/773332
#
# Read up on ssl_ciphers to ensure a secure configuration.
# See: https://bugs.debian.org/765782
#
# Self signed certs generated by the ssl-cert package
# Don't use them in a production server!
#
include snippets/snakeoil.conf;
#root /var/www/html;
root /home/depot_user;
# Add index.php to the list if you are using PHP
index index.html index.htm index.nginx-debian.html;
server_name _;
location / {
autoindex on;
auth_basic "Restricted Content";
auth_basic_user_file /home/depot_user/.htpasswd;
# First attempt to serve request as file, then
# as directory, then fall back to displaying a 404.
try_files $uri $uri/ =404;
}
- Restart the nginx service
- Since we made changes to the nginx configuration file, we now need to restart the service to have it re-read the configuration file and use our new values.
- # /etc/init.d/nginx restart
- Since we made changes to the nginx configuration file, we now need to restart the service to have it re-read the configuration file and use our new values.
- Change to the depot_user
- We want to perform the next series of commands as the depot user. This will help us maintain the correct permissions.
- # su – depot_user
- We want to perform the next series of commands as the depot user. This will help us maintain the correct permissions.
- Create a base index.html file
- This is just a simple web page so we know the web server is running.
- $ vi ~/index.html
<html> <head> <title>Welcome to nginx</title> </head> <body bgcolor="white" text="black"> <center><h1>Test depot is working</h1></center> </body> </html>
- Create a .htpasswd file
- This is the password that we will use to access the local depot with the previously defined depot_user username.
- $ htpasswd -c ~/.htpasswd depot_user
- Create the required directory structure
- We need to create the appropriate directories needed to store the bundles, the manifest, and the signature files.
- $ mkdir -p ./PROD2/evo/vmw/manifests
- $ mkdir -p ./PROD2/evo/vmw/bundles
- We need to create the appropriate directories needed to store the bundles, the manifest, and the signature files.
- Create depot index
- We need to create an index file for the local depot. This index file will contain a list of bundles that this server ‘knows’ about. The index file is just a simple text file consisting of the bundle ID and the manifest name.
- The easiest way to get this is to just download the one from depot.vmware.com. Just use your web browser and access https://depot.vmware.com/PROD2/evo/vmw/index.v3. If you are asked to authenticate, provide your MyVMware username and password. Save this as a text file and copy it over to your local depot, or just cut and paste – whichever is easier for you.
- It’s important to note here that you don’t need ALL of the line entries contained in the index file available on depot.vmware.com. Some of the bundles may be for earlier versions of VCF and not applicable to your environment. In some cases, you may want to have different index files that contain only a subset of bundles. This means that you can have all the bundles on your local depot, but use different index files as a method to only present specific bundles to a SDDC Manager instance.
- If you do have a line in the index file, you need to ensure you actually have the bundle files download and in place.
- For this example, you can just create the file with the following command and copy the contents I have below.
- $ vi ~/PROD2/evo/vmw/index.v3
- For VCF 3.9.1, these are the line items I have in my local depot:
3d8f87a3-d120-443d-a789-184b0b73b7ae bundle-9927.manifest ee40643e-740e-481b-ab01-feb46bebaa5c bundle-11815.manifest 67b27323-ca8d-4e74-adcc-35271fb2c329 bundle-14546.manifest 15b80d10-dae5-4e1d-b3f9-b8b070474e69 bundle-14548.manifest 7ef354ab-13a6-4e39-9561-10d2c4de89db bundle-14551.manifest 7d6e5874-accb-4203-ab90-1a6703a96e2f bundle-14553.manifest 11e8430e-1e2d-484c-b742-807f247ac504 bundle-14555.manifest 90483ef2-adb6-4e67-b5ef-de430dc0179a bundle-14557.manifest c82b7d63-3a87-4453-bfd7-edf054f7ffab bundle-14560.manifest 8aad9e98-b5b6-41cb-8d83-589e867d3faf bundle-14561.manifest 63e05cf5-96ef-4b5d-ac54-3b40009bcd4d bundle-16157.manifest 21b98a4c-e9c0-4da2-b26b-3ff547fefabd bundle-16166.manifest 0e0b6d5b-6c6f-449f-bb1e-06a36727c012 bundle-18144.manifest 18cc0773-aef2-428e-9444-79bfc4b2e366 bundle-18186.manifest 9631c096-f832-48bd-bfb1-14a78c7064bf bundle-20106.manifest cae1dca5-5444-4c2c-901c-04b19e14821e bundle-19712.manifest acfd90e6-309f-4afb-8450-645819f14847 bundle-19836.manifest 7b71abc9-dd41-4c94-b7f1-c5f074cb045e bundle-20107.manifest
- Populate the local depot
- Now you need to download the bundle files for each bundle that you have listed in your index file. Using the example above, I have 18 bundles that I would need to do this for. You could certainly do more, this is just what you may want for a virgin VCF 3.9.1 deployment.
- Each ‘bundle’ consists of three files; a tarball of the software bits, a signature file, and a manifest that describes the bundle.
- You can download each of these from the server at depot.vmware.com using your MyVMware credentials.
- Make sure you save the signature and manifest files as plain text (NOT HTML).
- For example, say you wanted to get the files for the first line shown above in my example of the index.v3 contents. This is for bundle-9927. In this case, we would get the files using the following links:
- Repeat for each of the bundles that you have specified in your index.v3 file.
- Copy them over to your local depot and follow the same directory structure. After you are done, just ensure you have the permissions set so that depot_user is the owner and has at least a permission set of 755.
- Edit the LCM configuration
- Now that you have the files loaded in your local depot, we need to change the LCM configuration on the SDDC Manager to point to it.
- In this example, we only really need to change two lines. One is to point to the FQDN or IP of your new local depot and the other is to turn off the SSL certificate verification (as we are not using ‘real’ SSL certificates).
- Take notice of the other attributes here. You should see why we named the directories the way we did previously…
- Restart the LCM service
- As we have changed the LCM configuration file, we need to restart the LCM service on the SDDC Manager for our changes to take effect. Wait for about 5 minutes after restarting the LCM service for it to fully come online.
- # systemctl restart lcm
- Add the depot credentials
- Just add in the credentials into VCF like you would normally. Ensure that you see a green check and that it’s marked as active.
All that’s left is to sit back and relax. By default, the LCM service will poll the depot every 5 minutes. So give it 5 minutes and then check for any ‘new’ bundles.
Note that this will only work for the VMware VCF bundles. If you have a vxRail system, there’s a completely different depot that is used in addition to this.