Name: marketplace_image
Owner: Chef Partners
Description: A cookbook for building and publishing Chef Marketplace images
Created: 2015-06-10 17:11:34.0
Updated: 2018-05-14 16:19:10.0
Pushed: 2018-05-14 16:19:09.0
Size: 151
Language: Ruby
GitHub Committers
| User | Most Recent Commit | # Commits |
|---|
Other Committers
| User | Most Recent Commit | # Commits |
|---|
marketplace_image is a Chef cookbook for building and publishing images to
various cloud marketplaces
The marketplace_image cookbook has support for the following platforms:
The marketplace_image cookbook has support for the following cloud marketplaces:
Currently there is no scheduled release process for new marketplace images. New images are usually released for public marketplaces when one or more Chef Server or add-on packages are released. Assuming that no bugs are found during manual acceptance testing, the release process can usually be done by one person in a day.
The marketplace_image cookbook is an attribute driven cookbook that iterates
over “builder definitions” that are configured via attributes. Builder
definitions are essentially hashes that conform to the following standard:
ame' => "unique_builder_name_as_a_string",
uilder_options' => {
'key' => 'value',
'pairs' => 'specific'
'to' => 'the',
'packer' => 'driver'
arketplace_config_options' => {
'key' => 'value',
'pairs' => 'specific'
'to' => 'the',
'marketplace' => 'images',
'desired' => 'config'
ample:
ame' => "gce_example",
uilder_options' => {
'type' => 'googlecompute',
'account_file' => node['marketplace_image']['gce']['account_file'],
'project_id' => 'chef-marketplace-dev',
'source_image' => 'centos-7-v20160126',
'zone' => 'us-central1-a',
'ssh_username' => 'marketplace'
arketplace_config_options' => {
'role' => 'aio',
'platform' => 'gce',
'support_email' => 'cloud-marketplaces@chef.io',
'reporting_cron_enabled' => true,
'doc_url' => 'https://docs.chef.io/google_marketplace.html',
'disable_outbound_traffic' => false,
'license_count' => 25,
'license_type' => 'fixed',
'free_node_count' => 5
Attributes for all builders should exist in attributes directory with a named
entry for each cloud.
We configure Packer with the right cloud credentials via a data_bag with a keyed
hash for each cloud. If you wish to run these builders you'll need to create a
data_bags/marketplace_image directory and populate it with a
publishing_credentials.json file with the cloud specific credentials, ie:
d": "publishing_credentials",
zure": {
"subscription_id": "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX",
"subscription_name": "XXXXXXXXXXXXXXXXXXXX",
"client_id": "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX",
"client_secret": "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
ce": {
"account": {
"type": "service_account",
"project_id": "XXXXXXXXXXXXX",
"private_key_id": "XXXXXXXXXXXXXXXXX",
"private_key": "-----BEGIN PRIVATE KEY-----\nXXXXXXXXXXXXXXXXXXXXXXXXX=\n-----END PRIVATE KEY-----\n",
"client_email": "foo@XXXXX.iam.gserviceaccount.com",
"client_id": "XXXXXXXXXXXXXXXXXXXXX",
"auth_uri": "https://accounts.google.com/o/oauth2/auth",
"token_uri": "https://accounts.google.com/o/oauth2/token",
"auth_provider_x509_cert_url": "https://www.googleapis.com/oauth2/v1/certs",
"client_x509_cert_url": "https://www.googleapis.com/robot/v1/metadata/x509/XXXXXXXXXXXXXXXXXXXX.iam.gserviceaccount.com"
}
ws": {
"secret_access_key": "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX",
"secret_key_id": "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
This data_bag should never be committed into source control.
The current data bag item is in the lastpass shared folder marketplace-images.
This data_bag should never be committed into source control.
Test Kitchen has several suites for publishing different combinations of images.
You can specify the channel to use for installing chef-marketplace, chef-server
and automate packages by setting the environment variable CHANNEL. Valid channel
names are; unstable, current, and stable (default without variable defined).
When releasing instaling a new marketplace build from apt or yum it is important to check the resulting installed version is the version expected.
If you're targeting a specific release for a cloud and/or product set you'll probably want to use a targeted combination.
Run kitchen list to view all the release targets:
hen list
Run the kitchen suite for the products that you wish to build, eg:
hen converge aws-all-publish
Note that the kitchen output contains the name and/or location of the built image. Finding the built image in the cloud GUIs can sometimes be more difficult than one would like, so it's worth making a note of these. Example:
on:
Builds finished. The artifacts of successful builds are:
--> aws_public_automate: AMIs were created:
us-east-1: ami-358b7a4f
and
e:
azure_automate_BYOL: Azure.ResourceManagement.VMImage:
ageAccountLocation: eastusOSDiskUri: https://marketplaceimages.blob.core.windows.net/system/Microsoft.Compute/Images/vhds/Chef_Automate_BYOL-osDisk.88a0957e-f746-4baa-9436-6eeb39bfa859.vhd
skUriReadOnlySas: https://marketplaceimages.blob.core.windows.net/system/Microsoft.Compute/Images/vhds/Chef_Automate_BYOL-osDisk.88a0957e-f746-4baa-9436-6eeb39bfa859.vhd?se=2017-11-11T18%3A44%3A13Z&sig=LYS1RULmDLYi1f99kSRa5fwmoTSZXDyuZKwxBjQwZDU%3D&sp=r&spr=https%2Chttp&sr=b&sv=2016-05-31TemplateUri: https://marketplaceimages.blob.core.windows.net/system/Microsoft.Compute/Images/vhds/Chef_Automate_BYOL-vmTemplate.88a0957e-f746-4baa-9436-6eeb39bfa859.json
lateUriReadOnlySas: https://marketplaceimages.blob.core.windows.net/system/Microsoft.Compute/Images/vhds/Chef_Automate_BYOL-vmTemplate.88a0957e-f746-4baa-9436-6eeb39bfa859.json?se=2017-11-11T18%3A44%3A13Z&sig=mS%2BRNR4Uu6fX6qaKFdd0MuGxtXbUggWFOBL1uu0m2uI%3D&sp=r&spr=https%2Chttp&sr=b&sv=2016-05-31
ecute packer build -parallel=true -only=azure_automate_BYOL /tmp/template.json20171011-1631-tmn9y1
ruby_block[cleanup temp file] action run
- execute the ruby block cleanup temp file
Currently there is no automated acceptance testing of marketplace images. In general what we've done is launch one of more of the newly created images and follow the setup AWS or Azure setup documentation to make sure that the user can login and start using the software.
If testing the Chef Sever AIO products you'll want to run chef-server-ctl test
to verify that all the Chef Server endpoints are functioning and verify that
the events made it into Analytics.
After the images have been built there are several manual steps that must be done to stage the images in their respective marketplaces.
After the images have been built you'll need to run them through the AWS Marketplace security scanner.
Log into the AWS Marketplace using the 'aws-marketplace' credentials in lastpass.
Share the AMI's with with Amazon by selecting the AMI's that you've just produced and click the yellow share button.
Wait for the scanning status to be succcessful. (~60 minutes).
Update the AMI ID's in the product load form(s) for the marketplace you're updating. You can find the load forms in the Engineering > Marketplace folder on drive. You should be able to find one with prepopulated data that just needs to be updated.
Upload the new load forms in the AWS Marketplace portal.
Email aws-marketplace-seller-ops@amazon.com to notify them of the changes and that that you'd like a new release done. Generally you'll hear back from them within 24 hours and you'll have the image published in a few days. The IC Marketplace can take upwards of 2 months to become available. Make sure to CC aws-marketplace@chef.io so that all stakeholders are in the loop.
Locate the submittal doc in Engineering > Marketplace > Marketplace Image Submittal History on drive. Add a new entry for the image and cloud.
AWS will announce that the image is staged via email. Test the image. If any issues are found, fix them and repeat the process from step one. If no issues are found, request that they publish the image.
Make sure you update the submittal history document during each stage.
After you've built Azure images you'll need to create a shared access signature, share the image blobs with Azure and update the products with a new revision. In Azure we have seperate marketplace offers. One is the VM image itself, and the other is the ARM Solution Template which is used to configure the instance.
Create the shared access signature with the Azure command line.
Log in to the Azure Portal and navigate to the marketplaceimages storage account image blobs. I know, easier said than done. You get to skip this step if you saved the image URLs from the kitchen output.
Copy the blob URLs for each of the images that you just created to a separate document.
Append the shared access signature to each image blob, eg:
https://marketplaceimages.blob.core.windows.net/system/Microsoft.Compute/Images/<your container>/<your new images>.vhd?<shared access signature>
Login to the Azure Publishing Portal using the 'azurestore' credentials in lastpass. Go to Virtual Machines and say yes, you do want to use the new UI.
Select the offer, e.g. Chef Automate VM Image -> SKUs -> select your SKU. (Currently byol for the Chef Automate VM Image.)
Scroll to the bottom of the page and click on “+ New VM Image”.
For each SKU and license pack add a new VM image version with a your blob link. To turn our package versions into semver versions, concatenate the version number with the iteration, e.g. 1.6.179-1 becomes 1.6.1791.
On the publish tab push to staging.
Locate the submittal doc in Engineering > Marketplace > Marketplace Image Submittal History on drive. Add a new entry for the image and cloud.
Azure will announce that the image is staged via email. Test the image. If any issues are found, fix them and repeat the process from step one. If no issues are found, request that they publish the image.
Make sure you update the submittal history document during each stage.
Note: the publishing portal wants a service-level shared access signature; generating the signature in the azure portal will generated an account-level SAS.
Download and configure the azure cli 2.0 tools.
Determine the primary storage account key
ogin
torage account keys list --resource-group publish-marketplace-images --account-name marketplaceimages
Create a shared access signature that is valid from yesterday to a week from today.
MacOS:
torage container generate-sas --account-name marketplaceimages --account-key '<primary storage account key>' --permissions rl --start `date -u -v -1d "+%FT%TZ"` --expiry `date -u -v +8d "+%FT%TZ"` --name system
GNU/Linux:
torage container generate-sas --account-name marketplaceimages --account-key '<primary storage account key>' --permissions rl --start `date -u --date="-1 day" "+%FT%TZ"` --expiry `date -u --date="+8 days" "+%FT%TZ"` --name system
The basic strategy will be
Using the staged image, boot an instance (AWS, Azure). It takes 10 minutes or so for automate to become available once the instance itself has been booted.
Test the staged image. An incomplete list of tests to run:
Login to the instance
chef-server-ctl test to verify the chef-server install.Set up a user and org in automate using biscotti (link is in the MOTD that appears on login to the instance).
Set up a compliance profile, bootstrap a node with that profile, and verify that node data and compliance data are displayed correctly in the automate UI.
(Amazon) Login to the instance and check the reckoner logs to make sure metering data is being sent.
Verify release-specific features.
If you find any issues, fix them and repeat the process from step one. If no issues are found, request the cloud provider to publish the image.
Currently, when AWS stages an image, they email us the AMI ID. When you start an instance from that AMI, you will need to assign the marketplace metering role to the instance. You will also need to put the instance in a security group that is open on ports 22, 443, and 8989.
Once Azure has staged an image, they will announce it to us in email. By convention, the name of the staged image is the original image name with “preview” appended to it, e.g. “chef-automate-vm-image-preview”. The omnibus-marketplace repo contains a solution template you can use to boot an instance from the preview image:
There is a slightly different process for testing when staging a new ARM template. Assuming you are publishing both a new VM image and a new ARM template you will need to wait for both offers to become available for preview.
Login to the Azure Cloud Partner Portal
Select the Chef Automate offer from the “All offer” section.
Click on the “Status” tab.
Copy the link for Microsoft Azure - allinone (Preview)
Login to the Azure Portal.
Paste the link to create a new Azure instance and fill out the form to create an instance.
This process does not test staged/preview ARM templates.
Make sure the automatearmtest resource group exists in the Chef Partner Engineering Azure portal.
Create a branch of omnibus-marketplace where the imageProduct parameter in arm-templates/automate/mainTemplateParameters.json is set to the name of the preview image.
Push the branch to github.
In arm-templates/automate/mainTemplateParameters.json, set the value of baseUrl to the branch name in github. Push the change.
Create the azure resource group automatearmtest if it does not already exist with: az group create --name automatearmtest -l "East US"
Run make arm-test in the omnibus-marketplace root directory to boot an instance using our current solutions template from github with the staged image.
When you are done with your testing, clean up by removing the automatearmtest resource group.
(More details on working with the solution template.)
Once you've completed your testing to your satisfaction, you will need to publish your image.
Email aws-marketplace-seller-ops@amazon.com and let them know the image is ready for publication. Update the submission history.
Login to the Azure publishing portal and go to Virtual Machines. The portal will ask if you want to go to its new incarnation; say yes. Go to Chef Automate VM Image -> Status and hit Publish. Update the submission history.
Author:: Chef Partner Engineering (partnereng@chef.io)