What is CodeReady Containers and why?
When you want to set up an Openshift cluster for personal use eg learning, development, doing demos, etc., you have the following choices:
- Installer Provisioned Infrastructure (IPI) requires 3 master and 2 worker + 1 Bootstrap servers (on AWS, Azure). Note that the Bootstrap server is only needed during the creation of the Openshift cluster and not after the setup.
- User Provisioned Infrastructure (UPI) requires 3 masters and 2 workers + Bootstrap servers (VMs and bare metal)
- CodeReady Containers on your laptop or desktop computer. CodeReady Containers allows you to run a minimal, preconfigured OpenShift 4.X cluster to your local laptop or desktop computer for development and testing purposes.
For personal use and learning purposes, Options 3 is orders of magnitude cheaper (1 laptop vs 5 AWS EC2 instances or VMs) and easier to set up compared to Options 1 and 2.
Reasons for Remote Access
By remote access, I mean that there is a computer (laptop or desktop) running CodeReady Containers and I am using my laptop to interact with it ie, accessing the Openshift console and logging in, issuing “oc” commands to it, etc. Things you do with Openshift.
You probably want to ask: if CodeReady Containers can run on a laptop, why don’t we just run it on the laptop and why do we need remote access? Good question.
The reason why you need remote access could be:
- Your laptop does not have enough memory or cpu power
- You need your dev or demo env always running
- You deployed your applications running on CodeReady Containers on you home server with lots of memory
- Cheaper to run as a demo system. This holds true even if you deploy it on AWS using nested virtualisation (1 EC2 instance instead of 5)
Running Openshift with a reasonable amount of workload requires memory and cpu power. Your laptop may not have enough of them especially memory. I find that dedicating 8G of memory on a 16G laptop to CodeReady Containers cannot handle my workload with acceptable performance. Of course, it all depends on the type of workload you run. It may be usable for your workload. For me, I need to dedicate at least 16G of memory or more to CodeReady Containers. Not many laptops have more than 16G memory. Certainly not mine.
My Use Case
I happen to have a server with 32G memory at home doing nothing. I want to set up CodeReady Containers and some middleware demos on it so that I can remotely access it for demo and experimentation purposes via my laptop if I wanted to. The pictorial representation of this use case is shown below:
Please note that this article does not cover how to install CodeReady Containers on your laptop. You can learn more from the following articles:
How this is Accomplished
The solution that I came up with is depicted below:
The solution is based on tinyproxy, a light-weight HTTP/HTTPS proxy daemon that proxies requests from the laptop on ports 6443 and 443 to the corresponding ports on the server. Both CodeReady Containers and tinyproxy run on the server. The connection between the laptop and tinyproxy is protected by a ssh-tunnel as shown in the diagram.
The solution assumes you have working ssh client and server installed on both server and laptop.
Setting up the server running CodeReady Containers:
My server is running Fedora 29 and CodeReady Containers 1.5 based on Openshift 4.2.14.
On the server, do the following:
sudo yum install tinyproxy.x86_64
comment out Allow 127.0.0.1
add ConnectPort 6443
The following shows only the changes:
... # The order of the controls are important. All incoming connections are # tested against the controls based on order. # #Allow 127.0.0.1 … # # ConnectPort: This is a list of ports allowed by tinyproxy when the # CONNECT method is used. To disable the CONNECT method altogether, set # the value to 0. If no ConnectPort line is found, all ports are # allowed (which is not very secure.) # # The following two ports are used by SSL. # ConnectPort 443 ConnectPort 563 ConnectPort 6443
And issue the commands:
sudo systemctl enable tinyproxy sudo systemctl start tinyproxy
Setting up my laptop:
My laptop is a Macbook. If you are not using a Macbook, you have to download the oc client for your platform.
Do the following:
Download and install oc client matching that of CodeReady Containers version. Openshift CLI client 4.2.14
Accessing your CodeReady Containers remotely:
Do the following on your laptop:
Create a secure tunnel to tinyproxy
ssh user@serverNameOrIPAddress -L 8888:127.0.0.1:8888 -N
Replace user@serverNameOrIPAddress with your values.
Login to Openshift using oc client
From command line:
export https_proxy=http://127.0.0.1:8888 oc login -u developer -p developer https://api.crc.testing:6443
Access the Openshift Console
Set proxy for http as well as ssl in your browser to point to: 127.0.0.1:8888
This is shown in a Firefox dialog box below:
And point your browser at:
Using tinyproxy on the server running CodeReady Containers, we can access it remotely easily using SSH to form a tunnel and simple proxy settings on the laptop to access CodeReady Containers anywhere an Internet connection is available. Using one computer to set up a working Openshift cluster using CodeReady Containers for personal use is a convenient way to experience and learn Openshift. If your laptop is powerful enough (with sufficient memory and cpu power although the former appears to be more important), you can install it on it and use it directly. Otherwise, like me, you have to install it on a powerful enough machine and access it anywhere you go using your memory-challenged laptop with an Internet connection which is the next best thing to installing it on the laptop itself.
The demo video shows the interaction with CodeReady Containers remotely using my laptop.
Using oc commands to interact with the remote CodeReady Containers Openshift cluster works faultlessly. The only thing that does not work is binary S2I (Source to Image) using FMP (Fabric8 Maven Plugin), FMP fails to connect to Openshift via the proxy as it does not honour either the https_proxy environment variable no the “proxy” configuration in maven settings.xml. An enhancement request has been submitted and rejected. Hence, don’t expect this feature to be available anytime soon. This, however, is not a showstopper for the use case I have at hand. I can access the remote CodeReady Containers server directly using ssh and do my binary S2I build there or use source S2I. A bit inconvenient but manageable. A better approach would be to install CodeReady Workspaces (browser-based IDE) on the CodeReady Containers Openshift cluster for development and deployment. And that is the approach I am going to try out next. Stay tuned!