For this workshop, you will request and use your own virtual machine from the LinuxONE Community Cloud. Setup for the virtual machine should take about 30-45 minutes.
Visit the LinuxONE Community Cloud and request a new VM using the Try a LinuxONE Virtual Server button.
Complete the form and confirm your email to activate your LinuxONE Community Cloud account.
| #!/bin/bash | |
| ############################################################################### | |
| # # | |
| # delete-orphans.sh (c) 2021,2023 IBM Corporation and Tim Robinson # | |
| # # | |
| # IBM Cloud Kubernetes service can leave behind block and file volumes in # | |
| # some cases. Whether by using -retain storage classes or deleting clusters # | |
| # from the API without specifying to remove cluster volumes, these volumes # | |
| # can accumulate in an account and prevent creation of new volumes. # |
| #!/bin/bash | |
| ############################################################################### | |
| # # | |
| # delete-sl-storage.sh (c) 2021,2023 IBM Corporation and Tim Robinson # | |
| # # | |
| # IBM Cloud Kubernetes service can leave behind block and file volumes in # | |
| # some cases. Whether by using -retain storage classes or deleting clusters # | |
| # from the API without specifying to remove cluster volumes, these volumes # | |
| # can accumulate in an account and prevent creation of new volumes. # |
Begin with a Red Hat OpenShift on IBM Cloud (ROKS) cluster with private endpoints only (public endpoints disabled). Private endpoints resolve in the DNS to IP addresses that are provided by Private Service Endpoints which typically begin with IP address octets of 166. Although the Private Service Endpoints are routable through the implicit internal router that VPC hosts can reach, these addresses are not routed over VPN connections to a VPC. Therefore, in order to manage this cluster from off the VPC, an additional load-balanced service will be added for Kubernetes API access. For more information in the IBM documentation see Accessing VPC clusters through the private service endpoint
The most straightforward way to initially manage a VPC-based ROKS cluster is by adding a Linux VM to one of the subnets where the workers reside (install the ibmcloud and oc cli's
Begin with a Red Hat OpenShift on IBM Cloud (ROKS) cluster with private endpoints only (public endpoints disabled). Private endpoints resolve in the DNS to IP addresses that are provided by Private Service Endpoints which typically begin with IP address octets of 166. Although the Private Service Endpoints are routable through the implicit internal router that VPC hosts can reach, these addresses are not routed over VPN connections to a VPC. Therefore, in order to manage this cluster from off the VPC, an additional load-balanced service will be added for Kubernetes API access. For more information in the IBM documentation see Accessing VPC clusters through the private service endpoint
The most straightforward way to initially manage a VPC-based ROKS cluster is by adding a Linux VM to one of the subnets where the workers reside (install the ibmcloud an
The IBM Kubernetes service free clusters consist of a single worker node with 2 CPU and 4 GB of memory for experimenting with Kubernetes. Unlike the fee-based service, these clusters do not include capabilities for application load balancing using ingress out-of-the-box. However, if you manage a DNS domain (any provider will suffice) and can add an A record, it's possible for you to configure your own ingress that can provide http and https session termination for your containerized applications. Getting a TLS-enabled website or simply an external REST API couldn't be easier!
mycluster
OpenShift Container Platform typically supports edge-terminated TLS applications in a simple way for application developers through the route resource. This is accomplished through a wildcard certificate which will usually take a form like *.apps.cluster.domain.example.com. By default when exposing a service in OpenShift, a hostname is created by combining the service name (such as console) with a project (like openshift-console) to create a FQDN for a host, resulting in a host name like console-openshift-console.apps.cluster.domain.example.com. This just "works" due to the cluster wildcard certificate.
However, it is possible to manage custom certificates for use with OpenShift routes or Kubernetes ingress resources. The Cert-Manager CNCF project provides a handy tool to request custom TLS certificates for OpenShift, or any other Kubernetes platform. This gist will walk through setting
Load balancing services on IBM Cloud VPC currently leverage access to the primary NIC associated with the instance. By default, F5 BIG-IP configures to run management traffic on the primary NIC (eth0) and data plane on other NICS. This can be manually switched as follows.
Note - applying a license to a BIG-IP creates a dependency on the mac address of the management interface. Perform all of these steps before applying the BIG-IP license.
Starting point - deployment of F5 BIG-IP using terraform code from https://github.com/f5devcentral/ibmcloud_schematics_bigip_multinic_declared . This can be performed from the command line or schematics. Since the later intent is to have the NIC referred to as management in the code be a public interface, it can be convenient to assign a floating IP address to this interface by setting bigip_management_floating_ip to true.
When created by the terraform code, there will be a root and admin user defined. T
| #!/bin/bash | |
| ############################################################################### | |
| # # | |
| # delete-pvc-orphans.sh (c) 2022 IBM Corporation and Tim Robinson # | |
| # # | |
| # IBM Cloud Kubernetes service can leave behind block and file volumes in # | |
| # some cases. Whether by using -retain storage classes or deleting clusters # | |
| # from the API without specifying to remove cluster volumes, these volumes # | |
| # can accumulate in an account and prevent creation of new volumes. # |
Everyone gets that you need to run containers as non-root users whenever possible. This is preferred everywhere, and I think it's just a good habit overall. For trivial applications, this isn't a very big deal, but what about applications which depend on mounting to persistent storage, especially of the NFS flavor. And it might be that when you get the NFS export, the userid for the mount needs to be changed, perhaps to a random userid that's being dictated to you. If you're looking for an example scenario like this, look no further.
I'll assume you have a Dockerfile already, probably one that looks a bit like the one attached to this gist. This is a straight up example where during the container build, some things are done as root and ultimately we specify that the container intends to run as a specific user java_user in this example:
FROM adoptopenjdk/openjdk8-openj9:ubi-jre
USER root