The best OpenShift Labs from Red Hat Summit 2018

At this year’s Red Hat Summit there have been some great sessions on containers and OpenShift. All session materials and source have already been published on GitHub: https://github.com/RedHatOfficial/rhsummitlabs-2018.

Here are the best sessions for OpenShift users:

Have fun!
Sebastian

How to use custom Docker images on OpenShift Online

This quick tip describes how to use your custom built docker images on OpenShift Online (Red Hat’s SaaS based container platform).

Create a new project and get login token

Login to OpenShift Online at https://manage.openshift.com/ and create a new project (for the sake of this demo I use “my-external-project” as the name for it).

Click of the question mark (upper right corner) and select “Command Line Tools”.

Then copy your access token into your clipboard according to the instructions shown.

Login to the OpenShift Online Docker Registry

Now login to the OpenShift Online Docker registry using the following command:

docker login -u YOUR_OPENSHIFT_ONLINE_USER -p YOUR_ACCESS_TOKEN https://registry.CLUSTER_ID.openshift.com:443

e.g.

docker login -u sfaulhab@redhat.com -p SECRET_TOKEN https://registry.rh-us-east-1.openshift.com:443

If the connection can be established you should receive a “Login succeeded” message.

Prepare your local image to be pushed

In this demo I will be using a the basic “hello-world” image provided by Docker. Firstly you will need to find out the image id:

docker images

Now we tag the image with a new repository id:

docker tag IMAGE_ID registry.CLUSTER_ID.openshift.com:443/PROJECT_NAME/hello-world

e.g.

docker tag f2a91732366c registry.rh-us-east-1.openshift.com:443/my-external-project/hello-world

Now you should see the newly tagged image in your local registry:

Now we can directly push the image to the OpenShift Online registry (since we’ve authenticated before):

docker push registry.rh-us-east-1.openshift.com:443/my-external-project/hello-world

In the background OpenShift Online will import the image into its internal registry and will furthermore create an according image stream for it.

The resulting image stream can then be used to create a new deployment from that image. Click “Add to Project” and then “Deploy image”:

Have fun bringing your own Docker based applications onto OpenShift Online!

Cheers,

Sebastian

Background information

Managing images

Getting started with Ansible Playbook Bundles on CDK

Install Ansible Service Broker addon into your CDK installation

Start your CDK environment with registration (important as yum get’s used during addon installation)

export MINISHIFT_ENABLE_EXPERIMENTAL=y
minishift start --service-catalog

Clone the addon repository and install Ansible Service Broker addon:

git clone https://github.com/minishift/minishift-addons.git
cd minishift-addons/add-ons/
minishift addon install ansible-service-broker
minishift addon apply ansible-service-broker

When logging in to your CDK console you should already see the preinstalled APB’s:

Install the ABP command line on your client machine

Configure your shell to use the minishift Docker daemon

eval $(minishift docker-env)

Fetch the APB command line script and make it available in your PATH

wget https://raw.githubusercontent.com/ansibleplaybookbundle/ansible-playbook-bundle/master/scripts/apb-docker-run.sh && mv apb-docker-run.sh apb && chmod +x apb

Verify that your installation works

apb --help

If everything went well you should see something like this:

Test the connection between ABP CLI and CDK

You will need special permissions to work with the broker on your CDK installation. Therefore we need to execute the following:

oc login -u system:admin
oc adm policy add-cluster-role-to-user cluster-admin developer
oc login -u developer

Now let’s see if we can list the preinstalled APB’s:

apb list

Configure Ansible Service Broker to pull images from local registry

In the default config of our Ansible Service Broker the APB’s are pulled from “https://registry.hub.docker.com/”. We need to change this to our local registry running within CDK.

registry:
  - type: local_openshift
    name: lo
    namespaces:
      - openshift
    white_list:
      - ".*-apb$"

The Ansible Service Broker pod now needs to be restarted in order to pull in the new configuration.

Create your first APB

Firstly we use the CLI to scaffold our new service:

apb init sample-service-apb
cd sample-service-apb

Now we locally build our APB. After the process has completed, the newly build APB docker image should appear in your local docker registry:

apb build

Finally we need to push the Docker image to our Service Broker inside CDK:

apb push

Now you should be able to see your first APB in your CDK’s service catalog.

Reference Information

Ansible Playbook Documentation

Getting started with APB development

Minishift Addon – Ansible Service Broker

Ansible Service Broker Configuration

Solving problems with Eclipse Secure Storage

I am an active long time user of Eclipse and Red Hat’s distribution called JBoss Developer Studio (https://developers.redhat.com/products/devstudio/overview/). The tool suite has a very nice feature called Eclipse Secure Storage, which allows me to save development related passwords (Github, OpenShift, etc.) in a secure manner on my local system. However, in the last couple of months I regularly had problems with Eclipse Secure Storage feature not allowing me to use/save any passwords. Even reinstalling and deleting user specific preferences in my home folder did not work. If you google for this type of problem you’ll find a number of users reporting similar issues, but neither a resolution nor a proper workaround.

Today I managed to fix my problem on Mac OS as follows:

  1. Open the “Keychain Access” application.
  2. Search for an entry called “equinox.secure.storage” and delete it.
  3. Open JBoss Developer Studio and go to Preferences.
  4. Open the “Secure Storage” preferences and delete the entry “[Default Secure Storage]”. Be aware that you saved passwords are lost by doing this.
  5. Restart JDBS and try to save your passwords again.

 

Additional things to try

 

How to set up wordpress on OpenShift in 10 minutes

What this is about?

A lot of customers would like to give the brave new container world (based on Docker technology) a try with real life workload. The WordPress content management system (yes, it has become more than a simple blog) seems to be an application that many customers know and use (and that I’ve been asked for numerous times). From a technical point of view the WordPress use case is rather simple, since we only need a PHP runtime and a database such as MySQL. Therefore it is a perfect candidate to pilot container aspects on OpenShift Container Platform.

Preparation

Install Container Development Kit

I highly recommend to install the freely available Red Hat Container Development Kit (shortly CDK). It will give you a ready to use installation of OpenShift Container Platform based on a Vagrant image. So you’re up to speed in absolutely no time:

Please follow the installation instructions here: https://developers.redhat.com/products/cdk/get-started/

Setup resources on OpenShift

Spin up your CDK environment and ssh into the system:

vagrant up
vagrant ssh

Create a new project and import the template for an ephemeral MySQL (since this is not included in the CDK V2.3 distribution by default). If you prefer to use another database or even one with persistent storage, then you can find additional templates here.

oc new-project wordpress
oc create -f https://raw.githubusercontent.com/openshift/openshift-ansible/master/roles/openshift_examples/files/examples/v1.3/db-templates/mysql-ephemeral-template.json

Now we create one pod for our MySQL database and create our WordPress application based on the source code. OpenShift will automatically determine that it is based on PHP and will therefore choose the PHP builder image to create a Docker image from our WordPress source code.

oc new-app mysql-ephemeral
oc new-app https://github.com/wordpress/wordpress
oc expose service wordpress

Now let’s login to the OpenShift management console and see what has happened:

We now have a pod that runs our WordPress application (web server, PHP, source code) and one pod running our ready to use ephemeral (= non-persistent) MySQL database.

Install wordpress

Before we need to note down the connection settings for our MySQL database. Firstly we look up the cluster IP of our mysql service; secondly we look up the database name, username & password. Have a look at the following screenshots:

Now it is time to setup and configure wordpress. Simply click on the route that has been created for your wordpress pod (in my case the hostname is “http://wordpress-wordpress.rhel-cdk.10.1.2.2.xip.io/wp-admin/setup-config.php”).

Congratulations for installing WordPress on OpenShift!

What’s next

For now we’ve created all the resources manually in a not yet reusable fashion. Therefore one of the next steps could be to create a template from our resources, import it into the OpenShift namespace and make it available for our users as a service catalog item. So our users could provision a fully installed WordPress with the click of a button.

OpenShift Quicktip: Testdriving persistent storage with NFS

Creating a persistent volume for NFS storage plugin

The administrator is responsible for creating volumes (PV). The administrator assigns some external thing (partition, entire device, NFS volume, whatever) to a PV.

  1. Login to OpenShift with an admin user
  2. Create persistent volume:
oc create -f persistent-volume-nfs.yaml
  1. Check status of persistent volume:
oc get pv

Creating a persistent volume claim

The end-user/developer/user/whatever is responsible for making a request for a volume (PVC). They get assigned some volume, and they don’t really know what it is. Keep in mind that there is a 1:1 mapping between PV and PVCs.

  1. Login to OpenShift
  2. Create persistent volume claim:
oc create -f persistent-volume-claim.yaml

The source code can be found on my Github page: https://github.com/sebastianfaulhaber/openshift-v3-showcase/tree/master/openshift-resources

OpenShift Quicktip: Limiting resource consumption for users

A. Resource limits

Resource limits allow you to set boundaries (max/min & default) for the compute resources a developer can define on pod/container level (see https://docs.openshift.com/enterprise/3.1/dev_guide/compute_resources.html).

  1. Login to OpenShift with an admin user
  2. Change to target project with
oc project <my-project>
  1. Import limit range (see https://docs.openshift.com/enterprise/3.1/dev_guide/limits.html on what options are available)
oc create -f limit-range.json
  1. Browse to OpenShift admin console, select the project and then “Settings”.

B. Quotas

A quota allows you to set hard limits on the overall resource consumption on project level. This is in particular useful to create a t-shirt size based accounting model (small, medium, large) for OpenShift. See also https://docs.openshift.com/enterprise/3.1/dev_guide/quota.html.

  1. Login to OpenShift with an admin user
  2. Change to target project with
oc project <my-project>
  1. Create quota for project:
oc create -f resource-quota.json
  1. Browse to OpenShift admin console, select the project and then “Settings”.

The source code can be found on my Github page: https://github.com/sebastianfaulhaber/openshift-v3-showcase/tree/master/openshift-resources

IBM WebSphere Application Server Liberty Core on OpenShift V3 Tutorial

A. Synopsis

What this is about

This project demonstrates how to use IBM WebSphere Liberty (a lightweight Java EE container comparable with Apache Tomcat) on Red Hat’s leading Platform-as-a-Service (PaaS) solution OpenShift Enterprise V3 (https://enterprise.openshift.com/. Since OpenShift is perfectly suited for running containerized workloads based on the Docker format, we could reuse the officially supported image built by IBM. Additionally we’ve added OpenShifts powerful templating mechanism in order to create a superior developer experience:

  • Self-service based provisioning of new IBM WebSphere Application Server Liberty Core containers
  • Existing, not yet containerized applications can simply be reused
  • No prior experience with Docker needed
  • Automated build & deploy life cycle

The source code can be found here: https://github.com/sebastianfaulhaber/openshift-v3-showcase/tree/master/websphere-liberty

Screenshots

1. Select WebSphere Liberty template

2. Provide details on application

3. Application artifacts successfully created

4. OpenShift automatically builds initial Docker image for application

5. Build and deployment completed successfully

6. IBM WebSphere Liberty startup screen

9. Demo application running

B. Installation

1. Setup OSE Environment

There are multiple ways to spin up a new OpenShift environment:

All-In-One VM

This community provided Vagrant box probably provides the most convenient and fastest way to start your OpenShift developer experience. It features a complete OpenShift installation within one VM that allows you to test all aspects of a container application platform.

See for detailed instructions: http://www.openshift.org/vm/

On premise installation

The instructions for setting up an on premise installation of OpenShift Enterprise V3 can be found here: ([https://docs.openshift.com/enterprise/3.1/install_config/install/index.html]https://docs.openshift.com/enterprise/3.1/install_config/install/index.html).

OpenShift Dedicated

OpenShift Dedicated is a new offering from OpenShift Online. OpenShift Dedicated offers a hosted OpenShift 3 environment to run the containers powering your applications. This offering provides an isolated instance hosted on Amazon Web Services (AWS), providing increased security and management by the OpenShift operations team, so that you have peace of mind about the stability and availability of the platform.

See https://www.openshift.com/dedicated/

2. Enable OpenShift to run Docker images with USER in the Dockerfile

The currently provided version of IBM’s WebSphere Liberty Docker image requires the use of USER in the Dockerfile. Due to the security implications raised by USER statements OpenShift restricts the use by default. In order to make this project work, you will need to relax the security settings as described here: https://docs.openshift.com/enterprise/3.1/admin_guide/manage_scc.html#enable-images-to-run-with-user-in-the-dockerfile.

# Login to your OpenShift master via SSH
su -
oc edit scc restricted
# Change the runAsUser.Type strategy to RunAsAny

3. Import template into your OpenShift environment

wget https://raw.githubusercontent.com/sebastianfaulhaber/openshift-v3-showcase/master/websphere-liberty/websphere-liberty-template.json
oc create -f websphere-liberty-template.json -n openshift

C. User guide

1. How can I access the provided demo application?

This project provides a simple Java EE web application that can be used to verify that the showcase is working. It can be accessed after provisioning via: /Sample1/SimpleServlet (e.g. http://liberty-app-http-route-demo.apps.example.com/Sample1/SimpleServlet).

2. How can I use this showcase in my own OpenShift installation?

  1. Create a fork of the repository in your own GIT environment
  2. Add your applications to the app/ folder. They will be picked up and get deployed automatically.
  3. Specify the URL to the forked project as SOURCE_REPOSITORY_URL when creating a new application.
  4. Done.

3. How can I automate the build & deployment lifecycle

The project template comes with preconfigured OpenShift webhook triggers for Github and a generic system (see https://docs.openshift.com/enterprise/3.1/dev_guide/builds.html#webhook-triggers for more details).

20. Configure webhook triggers

In order to automate the build and deployment lifecycle you simply need to integrate the webhook URLs according to your SCM specific instructions:

4. How can I view the logs of my application?

The logs can be accessed via the OpenShift Enterprise console:
Browse &gt; Pods &gt; YOUR_LIBERTY_POD &gt; Logs. Alternatively you could also use the CLI command oc logs YOUR_LIBERTY_POD (https://docs.openshift.com/enterprise/3.1/cli_reference/basic_cli_operations.html#troubleshooting-and-debugging-cli-operations).

21. View application logs

5. How can I connect to the container instance that is running my application?

You can open a terminal connection to the container via the OpenShift Enterprise console: Browse &gt; Pods &gt; YOUR_LIBERTY_POD &gt; Terminal. Alternatively you could also use the CLI command oc rsh YOUR_LIBERTY_POD (https://docs.openshift.com/enterprise/3.1/cli_reference/basic_cli_operations.html#troubleshooting-and-debugging-cli-operations.

22. Connecting to the container

D. Reference Information

WebSphere specific

OpenShift specific

E. Credits

Special thanks to Chris Eberle <ceberle@redhat.com>

IBM WebSphere Application Server Liberty Core on OpenShift V2 Tutorial

A. Synopsis

What this is about

We’ve created a IBM WebSphere Application Server Liberty Core cartridge in order to demonstrate the power and flexibility of Red Hat’s Open Hybrid Cloud strategy. Liberty Core provides a lightweight alternative to the classic WebSphere Application Server ND (cartridge available here: https://github.com/juhoffma/openshift-origin-websphere-cartridge) mainly targeting web applications using JEE web profile.

The cartridge currently supports the following features:

  • Provisioning of new IBM WebSphere Application Server Liberty Core instances in seconds (!)
  • Full build & Deploy life cycle (as with JBoss EAP cartridge)
  • Hot Deployment
  • Auto Scaling with web traffic
  • Jenkins Integration
  • Integration into JBoss Developer Studio

The source code can be found here: https://github.com/juhoffma/openshift-origin-liberty-cartridge

Screenshots

1. Create new Gear

2. Select WebSphere Application Server Cartridge

2. Select WebSphere Application Server Cartridge - Scaling

3. Cartridge creation is finished

4. Overview of newly created application

5. View of created sample application

6. HAProxy Scaling demo

B. Installation

1. Setup OSE Environment

You have the following deployment options for this cartridge:

2. Cartridge Installation

This cartridge does not actually ship the Liberty Profile binaries. These
have to be installed manually before this cartridge actually works. The Binaries can
be installed in 2 different ways:

  • OPTION 1 – Install the Liberty Core underneath the versions directory
  • OPTION 2 – Install Liberty Core outside of the cartridge context

The following sections describe the 2 different methods.

Prepare the installation

Download the required IBM WebSphere Application Server Liberty Core Installer from the IBM developer site https://developer.ibm.com/wasdev/downloads/liberty-profile-using-non-eclipse-environments/:

node# cd /opt
node# wget https://public.dhe.ibm.com/ibmdl/export/pub/software/websphere/wasdev/downloads/wlp/8.5.5.4/wlp-developers-runtime-8.5.5.4.jar

Clone the cartridge repository:

node# git clone https://github.com/juhoffma/openshift-origin-liberty-cartridge.git

Initialized empty Git repository in /opt/openshift-origin-liberty-cartridge/.git/
remote: Counting objects: 139, done.
remote: Compressing objects: 100% (103/103), done.
Receiving objects: 100% (139/139), 898.18 KiB | 1.33 MiB/s, done.
remote: Total 139 (delta 46), reused 106 (delta 15), pack-reused 0
Resolving deltas: 100% (46/46), done.

OPTION 1 – Install the Liberty Core underneath the versions directory

node# java -jar /opt/wlp-developers-runtime-8.5.5.4.jar --acceptLicense /opt/openshift-origin-liberty-cartridge/versions/8.5.5.4

Before you can use, extract, or install IBM WebSphere Application
Server for Developers V8.5.5, you must accept the terms of
International License Agreement for Non-Warranted Programs and
additional license information. Please read the following license
agreements carefully.


The --acceptLicense argument was found. This indicates that you have
accepted the terms of the license agreement.


Extracting files to /opt/openshift-origin-liberty-cartridge/versions/8.5.5.4/wlp
Successfully extracted all product files.

OPTION 2 – Install Liberty Core outside of the cartridge context

Binary installation

You can also install IBM WebSphere Application Server Liberty Core outside of the cartridge and
define the location using a node level variable like you can do with the full
WebSphere cartridge.

To make this work all you have to do is to create the file
/etc/openshift/env/OPENSHIFT_LIBERTY_INSTALL_DIR and put the installation location into
it. See the Official Documentation for an example on how to configure node level variables.

Customize SELinux Configuration

Since IBM WebSphere Application Server Liberty Core is installed outside of the gear’s sandbox, you need to customize SELinux permission settings in a way that the installation directory “/opt/IBM/” can be accessed with according permissions.

As a workaround and/or for testing purposes you could also temporarily disable SELinux policy enforcement:

setenforce 0

Install and activate the cartridge

node# oo-admin-cartridge --action install -s /opt/openshift-origin-liberty-cartridge --mco


1 / 1
vm.openshift.example.com
   output: install succeeded for /opt/openshift-origin-liberty-cartridge
Finished processing 1 / 1 hosts in 3174.10 ms

broker# oo-admin-ctl-cartridge -c import-node --activate --obsolete --force
Importing cartridges from node 'vm.openshift.example.com'.
Updating 26 cartridges ...
54f62e57e659c5cd31000001 # U mysql-5.5 (active)
54f62e57e659c5cd31000002 # U mysql-5.1 (active)
54f62e57e659c5cd31000003 # U jenkins-1 (active)
54f62e57e659c5cd31000004 # U nodejs-0.10 (active)
54f62e57e659c5cd31000005 # U haproxy-1.4 (active)
54f62e57e659c5cd31000006 # U jbosseap-6 (active)
54f62e57e659c5cd31000007 # U jbossews-2.0 (active)
54f62e57e659c5cd31000008 # U jbossews-1.0 (active)
54f62e57e659c5cd31000009 # U php-5.4 (active)
54f62e57e659c5cd3100000a # U php-5.3 (active)
54f62e57e659c5cd3100000b # U mongodb-2.4 (active)
54f62e57e659c5cd3100000c # U postgresql-9.2 (active)
54f62e57e659c5cd3100000d # U postgresql-8.4 (active)
54f62e57e659c5cd3100000e # U python-3.3 (active)
54f62e57e659c5cd3100000f # U python-2.7 (active)
54f62e57e659c5cd31000010 # U python-2.6 (active)
54f62e57e659c5cd31000011 # U perl-5.10 (active)
54f62e57e659c5cd31000012 # U diy-0.1 (active)
54f62e57e659c5cd31000013 # U jenkins-client-1 (active)
54f62e57e659c5cd31000014 # U ruby-1.8 (active)
54f62e57e659c5cd31000015 # U ruby-1.9 (active)
54f62e57e659c5cd31000016 # U ruby-2.0 (active)
54f62e57e659c5cd31000017 # U amq-6.1.1 (active)
54f62e57e659c5cd31000018 # U cron-1.4 (active)
54f62e57e659c5cd31000019 # U fuse-6.1.1 (active)
54f62e57e659c5cd3100001a # A hoffmann-liberty-8.5.5.4 (active)

Make sure you see the line reporting the cartridge 54f62e57e659c5cd3100001a # A hoffmann-liberty-8.5.5.4 (active)

broker# oo-admin-broker-cache --clear; oo-admin-console-cache --clear

C. Reference Information

WebSphere specific

OpenShift specific