Managing SUSE Workloads in AWS – When do you need a private repository?

This article applies to customers running on-demand/PAYG instances in AWS deployed from AMIs published by SUSE.

The need to patch.

Patching is an important part of managing any OS infrastructure with updates providing security related enhancements along with stability improvements.  SUSE recommend patching your systems as soon as updates are available.  So where, and how can customers running SUSE Linux  instances on the AWS Cloud consume patches?

On-demand customers have two choices, use SUSE’s Public Cloud Update Infrastructure (PCUI) or deploy their own private repository.

SUSE’s Public Cloud Update Infrastructure

The easiest and the default solution is to use the Public Cloud Update Infrastructure (PCUI).  This is a global fleet of update servers maintained by SUSE on the AWS Cloud which provides low latency access to patches from the on-demand instances.   Access to this update infrastructure is provided at no additional cost to the customer, with access to updates being included in the OS subscription.

Customers in AWS have the option of connecting to the PCUI either via an AWS Internet Gateway (IGW) in a public subnet, an Amazon NAT Gateway in a private subnet, or via a local data center.  The outbound firewall and network security need to allow this.

By default, SUSE Linux Enterprise Server On-demand instances in AWS will automatically connect to the SUSE’s Update Infrastructure on boot.

The following blog [1] investigates the mechanics of this process in more detail.

When might you need to deploy a private repository server?

The second option is to deploy a private repository.

This may be needed in several scenarios, two of which are:

• Connectivity/Security.
  This is the most common reason, in that the SUSE Instances which require patching have absolutely no outbound connectivity to the internet, by any route. In this example a Private Repository server is used as the proxy and is the only instance with outbound/internet connectivity.  The rest of the SUSE instances can consume patches from this repository.
• Staging.
  When mission critical production workloads need a fixed, curated and consistent set of patches deployed to them, it’s important to deploy a solution to support this.   Both the SCC and PCUI will see the repository manifest change as new updates are released which may lead to inconsistency across the production fleet.  By introducing a private repository that supports staging, production workloads can be kept in a consistent state.  New updates can be tested without impacting production environments.

A private repository service is customer maintained using additional SUSE products and if running in AWS would require the deployment of an Amazon EC2 (Elastic Compute Cloud) instance running in an Amazon Virtual Private Cloud (Amazon VPC).    The private repository does not have to reside within the same VPC or subnet as your managed instances, but there should be connectivity between VPC’s, Subnets etc. and the instances that need to be updated etc.  (You can find out a little more information below under “Architectural Considerations”).

Private Repository Options

Customers have two options available from SUSE.

SUSE Multi Linux Manager (SMLM)

The recommended option is SUSE Multi Linux Manager. This is more than a local ‘Repository’.  SUSE Multi-Linux Manager [2] is a best-in-class Linux management solution designed for enterprise DevOps and IT operations teams. Providing the ability to patch, configure and audit your systems.  One of Multi-Linux Manager’s key capabilities is the ability to stage updates, providing that consistent set of patches to various environments.  It manages more than SUSE Linux too, it can manage 16 other Linux distributions, including Amazon Linux.

You can view the various options for deploying SUSE Multi-Linux Manager on AWS here [3]

Repository Management Tool (RMT)

RMT  [4] allows customers to build a simple private repository of SUSE Updates and acts as a proxy to the SUSE Customer Center, mirroring new content as it is released.

For customers interested in using AWS Systems Manager to manage the OS Lifecycle, it is possible to use RMT as the patch repository behind this management tool.

How does the private repo mirror patches?

The private repository instance will mirror content from the SUSE Customer Center (SCC) or with the new functionality in SUSE Multi-linux Manager, the Public Cloud Update Infrastructure. Connectivity to the SCC (or Update Infrastructure Servers) can either be via an AWS Internet Gateway in a public subnet or traffic can flow via the customer data center.

It is worth noting that both these solutions connect directly to SUSE’s Customer Center, there are three key prerequisites in order for PAYG customers to be able to connect a private repo to the SCC.

• Outbound connectivity as illustrated above.
• An account in the SUSE Customer Center
• In the case of RMT, SUSE Subscription entitlement needs to exist in the SCC for the products that need to be patched. When needed, customers choose to buy this subscription entitlement and use a BYOS instance as the private repository.
  Exactly what subscriptions are required and how these are purchased depends on which versions of SUSE Linux Enterprise Sever (SLES) or SUSE Linux Enterprise Server for SAP Applications (SLES for SAP) are running and which Private Repository Tool is used (SUSE Multi-Linux Manager or RMT).
  Customers / partners are welcome to contact their local SUSE Sales Teams for assistance with this.

Architectural Considerations

Repository placement

It is recommended to put your EC2 instance running your private repository ‘near’ to the instances you need to manage, in AWS this would ideally be the same region.  By doing this, it will reduce latency when running any patching operations and reduce any data transfer charges.  Whilst this may not be possible with larger global deployments, you should place the private repository near to the majority of your managed instances.   Multi-Linux Manager offers additional capabilities in the form of a ‘proxy’ component will allows for more complex deployments.

Connectivity

We have mentioned above, that SUSE RMT and SUSE Multi-Linux Manager are deployed on Amazon EC2 instances and require connectivity to both the SUSE Customer Center, and any managed instances.  So which network ports need to be opened?

RMT

For RMT, it is fairly simple, for outbound connectivity between the RMT instance and the SUSE Customer Center,  Ports 80 (HTTP) and 443 (HTTPS) should be open.

For inbound connectivity (from the managed instances), ports 80 (HTTP) & 443 (HTTPS) in addition to port 22 for SSH for OS and repository management).

Multi-Linux Manager

For outbound connectivity, Port 80 (HTTP) and 443 (HTTPS) – this is to the SCC or PCUI servers.

Inbound to the Multi-Linux Manager server: 443 (HTTPS) for managed instances to access updates and for access to the Web UI, 4505 & 4506 are also needed for encrypted communication between the server and managed instances.

For both RMT and Multi-Linux Manager deployments, an AWS Security group is the simplest way to configure the inbound connectivity required.

Connecting instances to the Private Repository.

Customers first need to prepare the on-demand instances for connection to a private Repository.   This involves removing a small number of packages and configuration entries.

Remove packages that automate the configuration of the Amazon EC2 instance to connect to the SUSE Public Cloud Update Server.

zypper rm cloud-regionsrv-client

zypper rm regionServiceClientConfigEC2

Remove the /etc/hosts entry for smt-ec2.susecloud.net. The client automation software adds the host file entry for smt-ec2.susecloud.net which is the SUSE Public Cloud Update Server. Since a private repository server is being created, the entry will not be needed.

Remove the following directories before you register your Amazon EC2 instance to your private repository server.

rm /etc/SUSEConnect

rm /etc/zypp/credentials.d/*

rm /etc/zypp/services.d/*

rm /var/lib/cloudregister/*

At this point you can connect your instance to the private repository.

The links to the documentation for each of the options will document how to register the SUSE instance to the private repository of choice.

SUSE Multi-Linux Manager Client Configuration

https://documentation.suse.com/multi-linux-manager/5.1/en/docs/client-configuration/client-config-overview.html

RMT (SUSEConnect)

https://documentation.suse.com/sles/15-SP1/single-html/SLES-rmt/index.html#cha-rmt-mirroring

References

[1] https://www.suse.com/c/accessing-the-public-cloud-update-infrastructure-via-a-proxy/

[2] https://www.suse.com/products/suse-manager/

[3] https://www.suse.com/c/suse-multi-linux-manager-on-the-public-cloud-deployment-and-consumption-choices/

[4] https://documentation.suse.com/sles/15-SP1/single-html/SLES-rmt/index.html