https://github.com/cloudfoundry-community/windows-stemcell-concourse
Provides tasks to take a Windows ISO and transform to a Windows stemcell for Cloud Foundry, in VSphere.
https://github.com/cloudfoundry-community/windows-stemcell-concourse
Last synced: 9 months ago
JSON representation
Provides tasks to take a Windows ISO and transform to a Windows stemcell for Cloud Foundry, in VSphere.
- Host: GitHub
- URL: https://github.com/cloudfoundry-community/windows-stemcell-concourse
- Owner: cloudfoundry-community
- License: mit
- Created: 2019-10-22T19:41:28.000Z (over 6 years ago)
- Default Branch: master
- Last Pushed: 2024-08-08T17:58:09.000Z (almost 2 years ago)
- Last Synced: 2024-08-08T20:49:09.932Z (almost 2 years ago)
- Language: Shell
- Size: 360 KB
- Stars: 13
- Watchers: 45
- Forks: 6
- Open Issues: 6
-
Metadata Files:
- Readme: README.md
- License: LICENSE
Awesome Lists containing this project
README
# Windows Stemcell Automation
Provides tasks to create a Windows stemcell for Cloud Foundry, in VSphere. The tasks are intended to be open and extensible as bash scripts. While life becomes a little more managable using [concourse](https://concourse-ci.org) for automation of these tasks, everything is arranged in a way that you could manually run them or plug them in to some other automation tool. The job of each task follows Pivotal's recommended way of creating a base image, cloning it, and running their stembuild tool on it. Read more about "Creating a Windows Stemcell for vSphere Using stembuild" in [their docs](https://docs.pivotal.io/platform/application-service-windows/2-7/create-vsphere-stemcell-automatically.html).
One notable design choice of this approach is the use of the [Windows answer file](https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/automate-windows-setup) (also known as the autounattend file). An alternate option to this would be to use [packer cli](https://github.com/hashicorp/packer) made by Hashicorp. This project is focused on the Winodws operating system solely and wants to follow Microsoft's recommended approach to automating Windows installs. There are many many customizations that one could want to do to a Windows install and the autounattend approach is a guarantee to offer all possibilities.
That said, the autounattend xml is complex and confusing. So attempts are made to abstract most of that away by pulling out specific settings as pipeline variables and templatizing the XML.
## Documentation
For your reading pleasure we have moved documentation of the project to wiki. [Have a look](https://github.com/cloudfoundry-community/windows-stemcell-concourse/wiki).
## Best practice for patching the base operating system
Naturally you would think patch tuesday is the trigger to update the base VM and run stembuild to create a patched stemcell. But doing this would leave compatability between OS patches and the stembuild tool up to you. The Cloud Foundry windows team does this validation for the community each month and releases a patched version of stembuild, signifying compatability with everything.
The new release of stembuild is the trigger of the pipeline. Specifically the `update-base` task. The flow should be to update the base VM's operating system, clone it with a name of the intended stembuild version, and run the latest version of stembuild on it. The output is an up to date stemcell that can trigger other pipelines for deployment and repaving of the Windows cells.
There are two ways to watch for a new stembuild release. Pivotal customers can have concourse watch [Pivotal Stemcells product page](https://network.pivotal.io/products/stemcells-windows-server) for a new version, or non-Pivotal customers can have concourse watch the [GitHub> releases](https://github.com/cloudfoundry-incubator/stembuild/releases) for a new version. If you would like to make the pipeline run automatically when a new release is posted, uncomment `trigger: true` in the `update-base` task.
More details about monthly stemcell upgrade can be found in the [creating vsphere stemcell with stembuild](https://docs.pivotal.io/pivotalcf/2-6/windows/create-vsphere-stemcell-automatically.html#upgrade-stemcell) documentation.
## Change Log
### 2/27/2020
- Updated `cfcommunity/windows-stemcell-concourse` image with latest Ubuntu, added unzip package, and updated govc to 0.22.1.
- Made `vcenter-ca-certs` optional and added ability to download certificate from vCenter as a part of initializing govc.
### 2/25/2020
- Added `timeout` var to apply to certain VM functions that could run wild.
- Added `windows-install-timeout` var to apply to windows install that could run forever if the install gets in a bad state.
### 2/24/2020
- Added `vmware-tools-status` var to allow for 2 different vmware tools state - current and supported. Look at the [vars](https://github.com/cloudfoundry-community/windows-stemcell-concourse/wiki/Build-Variables) for more explaination.
- Added validateToolsVersionStatus function in govc.sh to do a deeper lookup into the current state of the tools.
- Built out waitForToolStatus in govc.sh to be patient and wait/timeout for a proper tools status.
- Added support in all VM startup/shutdown/restart functions for waitForToolStatus
### 2/20/2020
- Added vmware tools validation in create-base task. The pipeline should not continue if tools are not in an acceptable state.
For even more info have a look at [commit history](https://github.com/cloudfoundry-community/windows-stemcell-concourse/commits/master)