Use cases exist where it may not be desirable to start a deployment “from scratch” with a newly deployed on-demand instance from a SUSE released SUSE Linux Enterprise Server image. However, if you are on the fence and your primary concern is uncertainty about achieving an equivalent system when starting from scratch then Machinery may be able to help.  With Machinery you can also compare two systems and thus moving from point A to point B, where point B is an equivalent system is not as painful as it might appear.

In any event, if the “equivalent system” route is not for you and you want an on-demand image, there is a solution. The background processes in such cases may include the conversion of an existing Virtual Machine (VM) or the transformation of a physical system into a VM.

For the rest of this article I will assume that you have arrived at a suitable “disk.raw” file, using information in the Google Documentation , that could be booted in GCE. The second underlying assumption is that the OS in the image is of a SUSE Linux Enterprise Server version that is considered supported in the Public Cloud.

While SLES 11 SP4 is still supported, i.e. SUSE releases and maintains a SLES 11 SP4 image in GCE, the described processes are not suitable for SLES 11 SP4 as not all necessary packages are available for download. For SUSE Linux Enterprise Server For SAP Applications you want to have at least a version based on 12 SP2.

You can go about creating your on-demand images in a couple of ways, both are more or less involved depending on your point of view. In one approach the preparation of the disk.raw file is minimal and no access to the SUSE Customer Center (SCC) is required, in the other approach there is a bit more prep work to the disk.raw file and access to SCC is required, but less work is required once the image is uploaded to GCE.

Some background

The fundamental difference between a Bring Your Own Subscription (BYOS) and an on-demand image is a metadata entry associated with an image that references license information. This license information triggers the platform (GCE framework) to track an instance per usage hour in a way that the SUSE update infrastructure in GCE can verify the instance and thus grant access to the repositories.

There are a couple of ways to add a license to an image. One is to use the API which takes the URI for the license you want to attach, and the other is to use the “gcloud” command line tool.

Here is an example of a command line to attach the sles-12 license to an image:

gcloud compute images create YOUR_IMAGE –family FAMILY \

–source-uri gs://BUCKET/path/image.tar.gz \

–licenses=”https://www.googleapis.com/compute/v1/projects/suse-cloud/global/licenses/sles-12″

The key here is the URI for the license. All the SUSE licenses for SLES are in the suse-cloud project and licenses for SLES For SAP are in the suse-sap-cloud project. The license names for SLES are sles-12 and sles-15 when SUSE Linux Enterprise Server version 15 is released later this year. For SLES For SAP the names are sles-sap-12 and sles-sap-15 when SLES 15 For SAP gets released.

With this the URI for SLES 15 For SAP would be

https://www.googleapis.com/compute/v1/projects/suse-sap-cloud/global/licenses/sles-sap-15

Once an image is created with the license information attached it can be verified by the SUSE update infrastructure as a SLES or SLES For SAP instance and access to the update repositories will be granted. But the image needs a “little” more than just have the license attached.

Option 1: The lesser image prep approach

With the information above you already know how to create an on-demand image. The next step is to get the benefits of the on-demand image, i.e. registration with the SUSE operated update infrastructure in GCE. Once you have your custom image tarball uploaded and you have created an image with the license attached start and instance and login. You will need root access.

In this approach we spent no time to prepare the image (disk.raw) to be an on-demand source for on-demand instances. Therefore we need to fiddle with the running instance and then create a new image-from it to avoid having to do the same fiddling for every instance started from the original image.

First you want o gather information from pint about the update infrastructure in the region you are running. You can install pint from source or from the openSUSE Build Service, python3 is needed.

Lets say you are running in us-east1 and thus you’d run the following command:

pint google servers –region us-east1

and that will produce the following output:

<?xml version=’1.0′ encoding=’UTF-8′?>
<servers>
<server ip=”104.196.61.109″ name=”smt-gce.susecloud.net” region=”us-east1″ type=”smt-sles”/>
<server ip=”104.196.26.155″ name=”smt-gce.susecloud.net” region=”us-east1″ type=”smt-sles”/>
<server ip=”104.196.220.87″ name=”smt-gce.susecloud.net” region=”us-east1″ type=”smt-sap”/>
<server ip=”35.185.34.152″ name=”smt-gce.susecloud.net” region=”us-east1″ type=”smt-sap”/>
</servers>

If you are running SLES you will want to point your instance to one of the two servers with ‘type=”smt-sles”‘ and if it is SLES For SAP, stating the obvious, you want to point to one of the servers with ‘type=”smt-sap”‘.

The next step is to get the certificate from the SMT server. The update infrastructure uses self signed certificates and you need to install the cert into the chain of trust on your instance. First lets add the host to your hosts file, as the hosts are not resolvable via DNS. Assuming I have a SLES instance and continuing under the assumption we are in us-east1 the following example will do the trick:

echo “# Added by SMT registration do not remove, retain comment as well” >> /etc/hosts
echo “104.196.61.109 smt-gce.susecloud.net smt-gce” >> /etc/hosts

The IP address above is based on your choice from the pint output. The comment is needed for later when we tie everything together to be fully automagic.

With the host entry added:

wget http://smt-gce.susecloud.net/smt.crt

The next step is to add the cert to the trust chain.

cp smt.crt /usr/share/pki/trust/anchors
update-ca-certificates

Next you need the gcemetadata tool. You can install this from source or from OBS.

Once gcemetadata is installed and operational, test simply by running ‘gcemetadata‘, you need to collect the proper metadata to make authentication with the update infrastructure work. this happens as follows:

gcemetadata –query instance –identity http://smt-gce.susecloud.net –identity-format full –xml >& instance_md.xml

With this you are ready to register your system.

SUSEConnect –url https://smt-gce.susecloud.net –instance-data instance_md.xml

Next you need to add the Public Cloud Module repository explicitly as follows:

SUSEConnect –url https://smt-gce.susecloud.net -p sle-module-public-cloud/12/x86_64 –instance-data instance_md.xml

The next steps are to make the instance look more like an instance started from a SUSE released image and include registration automation.

On SLES 12:

zypper in google-compute-engine-init cloud-regionsrv-client cloud-regionsrv-client-plugin-gce regionServiceClientConfigGCE regionServiceCertsGCE

On SLES 12 For SAP:

zypper in google-compute-engine-init cloud-regionsrv-client cloud-regionsrv-client-plugin-gce regionServiceClientConfigSAPGCE regionServiceCertsSAPGCE

If you want other SLES 12 module repositories you need to register each of them:

SUSEConnect –url https://smt-gce.susecloud.net -p sle-module-adv-systems-management/12/x86_64 –instance-data instance_md.xml
SUSEConnect –url https://smt-gce.susecloud.net -p sle-module-containers/12/x86_64 –instance-data instance_md.xml
SUSEConnect –url https://smt-gce.susecloud.net -p sle-module-hpc/12/x86_64 –instance-data instance_md.xml
SUSEConnect –url https://smt-gce.susecloud.net -p sle-module-legacy/12/x86_64 –instance-data instance_md.xml
SUSEConnect –url https://smt-gce.susecloud.net -p sle-module-toolchain/12/x86_64 –instance-data instance_md.xml
SUSEConnect –url https://smt-gce.susecloud.net -p sle-module-web-scripting/12/x86_64 –instance-data instance_md.xml

This works on SLES 12 and SLES 12 For SAP.

The next step is to enable the necessary services.

On SLES 12 and SLES 12 For SAP:

systemctl enable google-accounts-daemon.service
systemctl enable google-clock-skew-daemon.service
systemctl enable google-instance-setup.service
systemctl enable google-ip-forwarding-daemon.service
systemctl enable google-shutdown-scripts.service
systemctl enable google-startup-scripts.service
systemctl enable guestregister.service
systemctl enable haveged.service

If you want root disk resize to work you need to install the growpart-rootgrow package. At the time of this writing the package has not been released in the Public Cloud Module, thus you can get the build from OBS.

Once installed enable the service the package provides

systemctl enable rootgrow.service

With that we are almost there. Now it is time to clean up and then create a new image from the running instance.

rm -rf /etc/zypp/{repos.d,credentials.d,services.d}/*
rm -rf /etc/SUSEConnect

The last step is to create a new image from the running instance, please refer to the Google Cloud Platform documentation for details.

Option 2: More prep less fiddling once uploaded

Lets assume that you have a running SLES system that you want to convert into an on-demand image for GCE. The system is already registered against SCC and you have access to all the packages. In this process you just install the necessary packages, clean up, and then create disk.raw and the tarball. It is reasonably similar to the previous approach and therefore I will be a little less explicit.

As in the example above you need the Public Cloud Module enabled on your running system but the command is a bit shorter since the system is already registered against SCC.

SUSEConnect -p sle-module-public-cloud/12/x86_64

Then install the packages:

zypper in google-compute-engine-init cloud-regionsrv-client cloud-regionsrv-client-plugin-gce regionServiceClientConfigGCE regionServiceCertsGCE

On SLES 12 For SAP:

zypper in google-compute-engine-init cloud-regionsrv-client cloud-regionsrv-client-plugin-gce regionServiceClientConfigSAPGCE regionServiceCertsSAPGCE

If you want all the SLES 12 module repositories enabled by the registration automation you will want to install the following packages:

SUSEConnect –url https://smt-gce.susecloud.net -p sle-module-adv-systems-management/12/x86_64 –instance-data instance_md.xml
SUSEConnect –url https://smt-gce.susecloud.net -p sle-module-containers/12/x86_64 –instance-data instance_md.xml
SUSEConnect –url https://smt-gce.susecloud.net -p sle-module-hpc/12/x86_64 –instance-data instance_md.xml
SUSEConnect –url https://smt-gce.susecloud.net -p sle-module-legacy/12/x86_64 –instance-data instance_md.xml
SUSEConnect –url https://smt-gce.susecloud.net -p sle-module-toolchain/12/x86_64 –instance-data instance_md.xml
SUSEConnect –url https://smt-gce.susecloud.net -p sle-module-web-scripting/12/x86_64 –instance-data instance_md.xml

The registration of these repos installs the -release packages for each module which triggers the automatic set up for these repos in GCE.

This works on SLES 12 and SLES 12 For SAP.

Enable the services

systemctl enable google-accounts-daemon.service
systemctl enable google-clock-skew-daemon.service
systemctl enable google-instance-setup.service
systemctl enable google-ip-forwarding-daemon.service
systemctl enable google-shutdown-scripts.service
systemctl enable google-startup-scripts.service
systemctl enable guestregister.service
systemctl enable haveged.service

As in the previous section if you want root disk resize to work you need growpart-rootgrow.

If your running system is a VM and you have any special initialization code that runs on boot you need to disable that. Next is the clean up part:

rm -rf /etc/zypp/{repos.d,credentials.d,services.d}/*
rm -rf /etc/SUSEConnect

Once this step is complete create the disk.raw file by which ever process you prefer. Once you have the disk.raw file create the tarball:

tar –format gnu -cSzf my_custom_image.tar.gz disk.raw

Create an image from the tarball, don’t forget to attach the license, and you should be off to the races.

Last but not least you will want to login to the SUSE Customer Center and remove the system you just moved from your registrations since it is now an on-demand instance.

The proceses above will upon instance start up configure an instance to meet the GCE “default” settings, i.e. ssh login and user creation. If this is not desired do not enable the google-accounts-daemon.service.

Thanks to Google and Velostrata for feedback on the draft and for testing.

(Visited 1 times, 1 visits today)
Tags:
Category: Cloud Computing, Server, SUSE in the Cloud, SUSE Linux Enterprise Server, SUSE Linux Enterprise Server for SAP Applications, SUSE News
This entry was posted Friday, 2 February, 2018 at 7:24 pm
You can follow any responses to this entry via RSS.

Leave a Reply

Your email address will not be published. Required fields are marked *

No comments yet