I would like to share my story about how my Blogpost Openshift vs Rancher gone viral, which is:
- On the top page when you search Openshift vs Rancher on Google (The first two, rancher.com and kloia.com both pointing to my comparison)
- Viewed more than 250.000 times
- Several comments from the readers
- Republished by the vendor itself
- Translated by several consultancies in different countries
As kloia, our engineering team focus became dominantly Kubernetes for the platform projects, where OpenShift was a dominant player especially after the acquisition of IBM. We have been implementing OpenShift in one of our major Enterprise customer. Since we are an engineering company, our consultants became frustrated with OpenShift with the following feedbacks:
- OpenShift has its own way of doing things, no CNCF
- No/less engineering, more operator mindset
- Major problems during version upgrades
As an engineering-driven company, (Decisions are given by the engineering team, rather than Sales) we stopped working with RedHat, although we invested a lot with certifications and time…
Meanwhile, we began also experimenting with Rancher in several projects and I decided to make such an honest comparison by the end of 2019 based on
- Our engineering team’s feedback
- My own experience
- Several customer feedback
- Technical evidence
My intention was to reveal the realities, as an engineer who has been in the “Pledge to Professionalism” ceremony during my graduation:)
- I gathered data from anyone who can contribute: internal, external
- I interviewed several professionals: The ones using OpenShift, the ones using Rancher…
Based on all those data, I began to write an honest comparison.
There have been major debates around that post on social media and also in the comments of the post (I published all comments regardless of the positive or negative views, except the ones which have annoying language)
In a conclusion, I think the honesty of the comparison and maybe the reason I expressed how the engineering mindset professionals feel working with OpenShift made the success of that blogpost. It was not intentional, all happened organically!
During the pandemic, many companies have gone remote, while many of them struggling with it as their processes are not remote-complaint.
In Kloia, we were already Remote even before the pandemic.
I tried to explain that Remote does not necessarily mean Home and some aspects that we find important for this transition:
Google recently announced that, Chrome will alert “NOT SECURE” for the websites not running under HTTPS:
Starting October 2017, Chrome (version 62) will show a “NOT SECURE” warning when users enter text in a form on an HTTP page, and for all HTTP pages in Incognito mode.
In case you have a WordPress site, there are 2 main ways to do that:
1- Converting WordPress to HTTPS mode:
1-a: Change the site URL: The siteurl can only be changed by command line. Find the wp-config.php and update it.
1-b: Change the existing http links: Go to DB and update the links. Beside in case there are plugins which inject their code seperately, you need find all. This is very painful!
1-c: Create a SSL certificate and verify it on a certificate authority.
2- Keeping WordPress a usual and use CloudFlare:
2-a Force HTTPS
2-b Enable HTTPS Rewrite: This is the crucial point. By that, you do not need to edit WordPress http links, as CloudFlare will be replacing them on the fly! (In case you are not under HSTS, it will not replace image links)
2-c Now you should see that links except images are not converted on the fly. Go to https://hstspreload.org and register your domain for HSTS.
**** Be careful! All subdomains and subsubdomains from now on should work under https! ****
Here is my latest kloia blog post:
Here is my post on kloia blog:
Whenever you need to enable the HTTPS secure communication for your website, if your are using AWS, ELB is a cool service on which you can define your SSL certificate and termination and scale the nodes without considering the certificate. ELB is able to perform SSL termination and communicate with the nodes with HTTP.
First of all you need to create a CSR (Certificate Signing Request), assuming you need Wildcard SSL, CN is *.domain.com :
openssl req -new -newkey rsa:2048 -nodes -out star_domain_com.csr -keyout star_domain_com_private.key -subj "/C=TR/ST=Istanbul/L=Istanbul/O=domain/OU=IT/CN=*.domain.com"
There will be 2 output files:
1. star_domain_com_private.key : This will be your private key
2. star_domain_com.csr : This will be used to request the certificate from a Certificate Authority
Next step is, by the help of CSR, to initiate the SSL certificate request from a certificate authority of your choice.
You will be provided from Certificate Authority, a Public Key:
AWS is expecting from you a PEM format. In order to achieve that, you need to convert your certificate from CRT to PEM using openssl:
openssl x509 -in d06409309fccd3b.crt -out domain_public.pem -outform PEM
For the private key you already created, which is RSA, you also need to convert it to PEM:
openssl rsa -in star_domain_com_private.key -text > domain_private.pem
The next phase is uploading the public and private key to AWS in PEM format:
AWS –> EC2 –> Load Balancers
Create or open a current Load Balancer –> Listeners –> Add –> HTTPS –> Change –> Upload a new SSL Certificate
Copy and paste the public and private keys into the fields and Save