Images¶

The process with which we place our product range into cloud marketplaces is outlined below.
1. Set up a LBN cloud account¶
This is normally performed through a web browser; inputting credit card details et al.
2. Configure Compute Services¶
We use Hashicorp/Terraform to set up VPC’s, subnets, security group on the cloud vendor. It is necessary for the vendor to have a terraform provider. We build this provider from source and ship it as a RPM. Our current list of supported providers is terraform-provider
3. Build BastionLinux/Core¶
BastionLinux is essentially a Fedora spin; with a huge number of additional packages which underly the products we ship into clouds. We use Fedora because it has a Foundation behind it which ensures unencumbered access to the software.
We have an Apache/Airflow process to take a Fedora baseline; configure BastionLinux/DNF and BastionLinux/Chef and deploy our baseline software and configuration.
Our baseline images are Qemu/qcow2 format; which we can stream onto a vendor cloud; but would prefer the vendor has Fedora images available which we can convert.
4. Build Marketplace Products¶
We have an Apache/Airflow process to take our base BastionLinux image and BastionLinux/Chef a marketplace/product. We have a chef recipe for each product and a chef role for each marketplace/vendor.
We have a number of cloud-init extensions that ship with Marketplace products which ensure unique passwords to meet the vendor’s image security policies and to register customer entitlement to access our software repos to access software updates to the product, and security updates to the image.

We have a strong preference for the vendor to have a Python API for their cloud, preferably available on PyPi. If that is not available, then we do require an Open Source command-line tool which we could integrate within our Airflow pipeline.
Our product pipeline includes comprehensive testing where we stand up an instance based upon this image and run our governance suites across it. This includes a specialist marketplace profile assuring vendor marketplace/security policies.

Our build pipeline has very detailed instrumentation and we have/can provide logs
5. Engage Marketplace Team¶
There is normally a process, documents, and signatures to create a Marketplace account.
It is quite likely necessary to engage with a Marketplace operations team to publish new products and images. For example, to security scan the image.
Where possible; we will use the Vendor’s Marketplace API’s to auto-manage this within our Airflow work flows.
Our listing generation process has a dedicated application which captures and maintains product documentation, release notes et al; provider information; listing documentation which is collated by the pipeline and mapped into your marketplace/catalog APIs to automate our seller operations.
6. Product Lifecycle Management¶
Since we ship all of our software via RPM; our lifecycle management simply involves repeating this above process against our latest versions of the product and our BastionLinux stack.
We do this whenever we do a major release of the software; and/or whenever there is any security errata against anything in the image.
If you have a BastionLinux subscription; then your existing instances can also remain up-to-date.
7. Troubleshooting¶
Our Marketplace processes use the industry-standard cloud-init for everything. We need the Datasource for your cloud to be functional in that we rely upon this for customer account number, instance id, marketplace id.
Cloud-init has a whole bunch of analysis tools and logging.
$ cloud-init collect-logs [--redact-sensitive]
We may ask you to ship the generated tarball to us for further analysis.